« 2006年05月 | メイン | 2006年07月 »
2006年06月30日
TypePadでは、存在しないファイルもHTTP Status 200を返す！？
6月22日付けの、TypePadのバージョンアップで、BlogWriteからの画像等のファイルの上書き確認が上手く行かないとの報告をサポートフォーラムで頂いたので、調査していたのですが...
TypePadの新機能
ウェブページ上に破損画像（参照先（src）にファイルが存在しない画像タグ（img））がある場合、従来はブラウザの設定に準じた表示となっていましたが、1.8から破損画像があった場合は「Image not available」という画像を表示するように仕様変更しています。
アカウントをもっていないのでBlogWriteでの確認は出来ていないのですが、上記の記述とヘッダーを見る限り、存在しないファイルに対して、別ファイルを返すようで、つまり302で飛ばして、結果別ファイルをHTTP Status Codeの 200で返すように変更したようです。
うーむ、存在しないファイルはHTTPヘッダーに404 Not Foundで返すべきなんじゃなかったでしたっけ？
GIFファイルをアップロードしようとしていて、HEADしたら、
HTTP/1.0 200 OK
Content-Type: image/gif
が返ってきたら、そのファイルは存在する、と判断する他ないでしょう。
ということは、現実世界では結局、一つ前に書いたように、HTTPのステータスコードなんてまったくもってあてになりません。 このサイトを運用しているレンタルサーバーでもページが存在しないとデフォルトで「見つかりません」ページが200で返ってくるので時々問題にはまります。（ま、.htaccessで設定を上書きするなど方法はありますが）
BlogWriteでは画像ファイルを投稿する時、既存のファイルを誤って上書きしてしまわないように、事前に存在するかどうかHEADリクエストで確認しています。（デジカメ写真とかだと同じファイル名になりがちで、複数人で投稿するブログだと、意図しないで上書きしてしまう事があるため、BlogWriteでは上書き確認機能として持っています。個人的にはBlogWriteの優れた点の一つだと思っています）
TypePad側としてはユーザーの利便性を考えてのことだと思いますし、その姿勢は分かるのですが...。 HTTPの仕様違反というか、その副作用は理解されているのか、気になります。
Update： 検討した結果、上書き確認の機能を設定で、ブログごとにオン・オフできるようにする方向で対処したいと思います。
参考ー＞ Web屋のネタ帳： ステータス200なのに「その商品はありません」
投稿者 BlogWrite担当 : 15:12 | コメント (1) | トラックバック
2006年06月16日
REST原理主義
ってのがあると思うのです。つぶやきモードです...。
RESTってのは既存のWebアーキテクチャを有効利用するというもので、SOAPやWS-*と比べてすごくシンプルな解決策で素晴らしいと思うのだけど、例えばAtomPPでも最近顕著に見られるような気がしてならないのは、既存のWebアーキテクチャ絶対主義というかなんというか...それ以外の解決策は認めない、という雰囲気。
しかし、既存のWebアーキテクチャが完全かというとそうでもなく、問題はいろいろ存在しているのではないかと思うわけです。例えば...
HTTPステータスコードは信頼できない。
ファイルが見つからないときには４０４ではなく「見つかりません」ページが２００で返ってくるとか、５００インターナルサーバーエラーだけじゃユーザには何が起きたか分からない、というか独自のエラー文を返したい時はどうするのかなど、もろもろ。
MIMEタイプは意図した通りに動かず、誤用され無視される。
IEなどはファイルの中身を解析して判断してるし。charsetの指定も嘘が多い（apacheのデフォルトcharsetのままとか）。さらに言えば、セキュリティホールを突く攻撃にも利用される。
ここら辺、色々苦労があってノウハウが溜まってなんとかやってきた所があるわけで、決して銀の弾丸だとは言えないはずです。
にも関らず、例えば、プロトコルの通信時にエラーが起きたら、「HTTPステータスコードを返すだけで良いのだ」というのは原理主義的だと思う。ボディに含まれるのは、バイナリのJpeg画像かもしれないし、XMLかもしれないし、HTMLかもしれない。それがHTTPでありWebだ、と言われればそうだけれど、それでは何の解決にもならないと思います。
なんか、現状ある問題点の解決をするのではなく、単にWebアーキテクチャを再定義して原点に無理やり引き戻したいだけなんじゃないかと。
上記のケースであれば、上手くハンドリングして表示できるクライアントは、Webブラウザのみという事になってしまいます。で、現状WebブラウザはPUT、DELETEしないからまともなRESTクライアントアプリは存在しない、という事になってしまう...。
Webアーキテクチャにこだわるのは良いけれど、自分で自分の首を絞めるようなことにならなければ、と願って止みません。
投稿者 BlogWrite担当 : 19:45 | コメント (0) | トラックバック
2006年06月11日
Windows Vista と BlogWrite
動きました！
実は、サードパーティ製のコンポーネントが悪さをしていて、始めはエラってたのですが、実のところBlogWriteには直接必要のないコンポーネントなので削除したらすんなり動きました。
どうも、レジストリの書き込み関連で問題があったようです。Vistaになってレジストリの構造またはアクセス権限などが変わったのでしょうね... このあたりは後で要調査です。
投稿者 BlogWrite担当 : 15:54 | コメント (4) | トラックバック
2006年06月10日
Livedoor ブログのAtomAPIで障害発生中
です。
11:40 2006/06/12 現在は回復している事を確認しました 。ただし別件の報告している不具合（カテゴリが取得出来ない件）はまだ修正されていないようです。
追記：先ほどLivedoorサポートの担当者の方からメールを頂いたのですが、どうも私のテスト環境だけ再構築して頂いたようで、回復しているのは私のLivedoorテストブログだけかもしれません。
Livedoor Blogサポート：RSS読込みエラーにつきまして
にあるように、フィードの再構築をすれば直るとの事です。
この件につきましては、既にユーザーの方からも複数御報告いただいております。
現象は、BlogWriteがLivedoorブログと通信（投稿、過去記事取得もろもろ）すると、Livedoorブログから、不正なXMLが返るというもので、確認した所、データの先頭に不必要な改行が５、６っ個紛れこんでいます。XMLの仕様では、先頭行が空行ではまずいです。なので、XMLパーサーが不正なXMLと判断し、処理できなくなってしまっています。
実は、丁度この数日前に、LivedoorブログでのAtomAPI経由の不具合報告として、別件で窓口に報告していたのですが、それと関連があるのかどうかは分かりません。過去記事を取得すると、設定したはずのカテゴリ情報が消失している、という現象です。これとともに、 波ダッシュの件もお願いはしています。
私が報告した不具合の修正中に、別のバグを埋め込んでしまったとかでなければ良いのですが...orz
という事で、BlogWrite等のソフトウェアを利用してLivedoorブログへ投稿されている方はご迷惑をおかけしますが、Livedoorブログさん側の対応を少々お待ちいただくのと同時にLivedoorブログからの公式発表をお待ちくださればと思います。
投稿者 BlogWrite担当 : 23:51 | コメント (0) | トラックバック
2006年06月06日
波ダッシュ、チルダの件
ずっと昔からの問題となっていたわけですが、最近やっとチラホラと表舞台？で広く取り上げられつつある（というかそう期待している）波ダッシュとShift_JIS（CP932）の件なのですが...。
特に最近になって問題が表面化したのは、APIやRSS関連で、下記のようなケースが増えてきたからではないでしょうか。
（１）サーバー側でEUC-JPベースでデータを保存、または開発コードを作成。
（２）クライアント側がWindows（つまりShift_JIS）環境。
（３）両者のやり取りはUTF-8で行なわれる。
XML-RPCとかAtomAPIとかもろにこのようなケースに当てはまる事あ多く、実際BlogWriteでは以前から内部的に非常に美しくない様々な対処をしています。
■Livedoorブログ
「～」が「?」になってしまいます。ちょっと前までは、「～」が「〜」になってしまうだけで、少なくとも無理やり置換する事で対処出来ました。「〜」は普通にWindowsでは扱えず(左のは数値参照で表示させています)、「？」「・」「〓」に化けたりします。
ところが、いつの頃からかLivedoorブログ側で変更があったようで、投稿した段階かデータを取得した時点で既に「？」になってしまっています。これ BlogWrite側では復帰出来ない（本来の「?」と区別がつかない）感じ。
■Seesaaブログ
ちょと前まで、livedoorブログと同じく「～」が「〜」または化けた状態になってしまっていた。
という事で、仕方がないので、両者に対応するため、「～」をBlogWrite側で事前に、数値参照「～」に置換して送信していました。 所が、Seesaaブログでは何時の頃からか、「～」が表示されないという現象が起きるとの報告を最近ユーザーの方から頂きました...。数値参照を表示させない仕様になったようです。理由はわかりません。しかし、「～」自体は化けることはなくなったので、これに関しては内部で対処されたのでしょう。
という事で、Livedoorブログでの問題に対処しようとすると、Seesaaブログで問題が... Seesaaブログも数値参照を非表示にするなんて意味わからない...。
もうお手上げ状態。
大体において、Perlの例えば、Jcode.pm等を素で使ってEUC-JP <＝> UTF-8変換した日本語をWindows環境で読み書きしたりすると化ける訳で、私の場合、Danさんには本当に申し訳ないですが、２年ほど前から自分が開発するPerlのアプリでは一切Jcodeの利用を取りやめ、代わりにUnicode::Japaneseを利用させてもらっています。
Jcode.pm等をメンテされてこられた開発者の立場のDanさんの仰っている事は１００％納得できる訳で（対処しろとか言うつもりもまったくないです。Jcodeが悪いわけじゃないですから）すが、利用者としてはより実際問題として問題の起きない方を利用したい（して欲しい）となるのも同様に御理解いただきたいところであります。
なので、Livedoorさんも化けない方法を模索していただきたいなぁと思ったりしています。
関連リソース
http://www.kawa.net/works/jcode/uni-escape.html
http://as-is.net/blog/archives/000735.html
http://ja.wikipedia.org/wiki/%E6%B3%A2%E3%83%80%E3%83%83%E3%82%B7%E3%83%A5
http://www.asahi-net.or.jp/~wq6k-yn/code/wavedash.html
投稿者 BlogWrite担当 : 18:43 | コメント (2) | トラックバック
Movable Type 3.3 Beta 1 日本語版 と BlogWrite
Update: 2006/06/30 正式版が公開されたので、ベータから正式版の3.3に更新して見た所、下記エラー文字列の件、通常の日本語として受け取れるようになりました。開発者の方お疲れ様です m(_'_)m
ユーザーの方から早速、「BlogWriteはそのまま使えるのでしょうか？まだ、ベータ版の段階で取り越し苦労でしょうがいかがお考えでしょうか？」等の御連絡を幾つか頂いているので、一応「Movable Type 3.3 Beta 1 日本語版」をBlogWriteで動作確認した結果の御報告をさせていただきます。
Movable Type 3.3 Beta 1 日本語版、普通に動きました。BlogWriteで今までどおり利用できます。気をつけたいのは「APIパスワード」が「Webサービスのパスワード」になっている事ぐらいでしょうか。
しかし、最近特にお世話になってばかりいるのでとても言いにくいのだけど、一番失望したのは、（というよりか完全に脱力した）のは、未だにMTがXML-RPCで返すエラー文字列が日本語だけBase64エンコードされていることです。 これ、以前からずっと残ってます。
この件、去年の秋に詳しく丁寧に、１）問題点と理由、２）影響、３）原因、４）解決策を書いて直接窓口に報告し、返事までもらっているのに、未だに直っていないのでとても残念です。 私も人のこと言えないですけど（済みませんm(_'_)m）。
具体的に例を上げると、例えば利用者が「Webサービスのパスワード」何？って状態でログインすると、エラー文字列として、 下記が返ります。
44Ot44Kw44Kk44Oz44Gn44GN44G+44Gb44KT
XMLなんですし、何故に記事エントリは素の日本語で、エラー文字列だけBase64にエンコードするのでしょうか。
上記の文字列がBase64ではないかと検討をつけて、デコードすると「ログインできません」となるわけですが、デコード後のものが文字列であるかどうかも分からない、文字コードも不明な言語も不明なものをソフトウェアの中で、自動でデコードして表示、なんて気が進みません。というかそもそも、バグに依存した機能をつける事自体避けたい...。
Movable Type 3.2では、そもそも日本語ではなくて、「invalid login」というそっけない英語のメッセージが返ってきます。どっちにしても、ちょっと...という感じです。
今はMTのベータ段階でもある事なので改めて、お願いです...、エンコードした文字列を返さないでください...。
追記！
XMLRPC support for tags
リリースノートを読んでいたら、XML-RPC経由の投稿でタグのサポートが追加されるらしい。タグっていってもHTMLのタグのことではなくて、あれの事です..あれ。
なるべく対応する方向で調査検討実装したいと思います。
投稿者 BlogWrite担当 : 13:26 | コメント (1) | トラックバック
2006年06月01日
クロスプラットフォームでのアプリケーション開発のまとめ
アプリケーションを開発、頒布していると、たまにMac版はありませんか？とかLinux版は？といったお声をいただきます。ですが、現実は中々難しい所があって、往々にしてそれぞれのOSにあわせて一から作り直すぐらいの労力がかかります。
しかし、やはり多環境向けのソフトウェア提供というニーズは以前からあり、特に最近になって要望が増えている気がします。そこで、最近の状況をちょっと調査してみました。ここでは、Windows、Mac、Linux上でのGUIアプリケーションについてのみ扱います。フォームがあってボタンをクリックしたりして操作するアプリケーションのことです。
wine - Linuxなどの環境で、Win32アプリケーションを動かす。Win32API互換を目指している。
BlogWriteを含む一般的なWindowsアプリケーションは、Windowsに用意されているWin32APIを直接・間接的に叩いて動作します。wineはそのWin32API環境を用意することによってLinux上などでWindowsアプリケーションを動かすものです。
wineの完成度はかなり高いのですが、Win32APIすべてに対応しているわけではなく、対応されていない部分も多いです。ですが、試しにシンプルなアプリケーションを作って、wineで動かして見たら、ちょっと見た目が崩れる所もありましたが普通に動きました。動かない代表的な例として、IEコンポーネント（MSHTML）を利用したアプリケーション（BlogWrite含む）は使えません。WinInet（インターネット通信）周りも動作がかなり微妙。その他地雷多数あり。
結局、一部のアプリケーションしか完全には動かないのと、wineで動かす事を考慮に入れつつ開発しなければならないという制約が出てきてしまいます。その上、wineで動かしても、ネイティブな環境の動作や見た目（テーマや外観）からするととても違和感があります。MacOSX上でWiindowsアプリが動いている感じ。最近出たLinux向けPicasaなんかはかなりの出来だけれどもやっぱり一部機能は削ってあるようですね。
上記の制約をクリアすれば、とりあえず動作させることは可能ですが、ちょっとした修正で動くものでない限り、あえてwineを選択するのは現状ではお勧め出来ない感じがします。
Java - かつてwrite once run anywhereと喧伝されたが...
Javaで開発されたアプリケーションは、
１）大きなJavaランタイムをダウンロードして入れなきゃ動かない。
２）GUIアプリは動作が重い（ネイティブウィジェット使っても）。
３）見た目に違和感がある。
４）Javaランタイムのバージョン違いで動かなくなるとか、
５）他
など、色々あって、Javaで作られた一般向けデスクトップアプリケーションにはほとんどお目にかかったことがありません。というかよく使われるJavaアプリでは開発用のIDE、eclipseぐらいしか個人的には聞かないかも...。
.NET/mono - マイクロソフトが推し進めるJava対抗路線。複数言語による共通ランタイムによるアプリケーション実行環境。
伏兵。もしかしたら将来的に、一番可能性があるかもしれない。けれども...
現状では、.NETを利用する意義はほとんどない感じです。.NET上じゃないと出来ない事っていっても特にない（文字コード周りがすっきりしているのが一番の利点、とかぐらい？）ですし...。（もっともVB6とかで業務アプリ等を使っているなら.NETに限らずどれかに移行した方が良いけれど...。）
１）.NETランタイムをダウンロードしてインストールしなければならない。
２）ネイティブのアプリケーションと比較してやっぱり動作がもっさり。
上記二つは時間が解決する感じです。次期WindowsのVistaが出てくる頃には、上記の問題は無くなっているとなると、複数言語で共同開発出来るのと、ランタイムさえあれば何所でも動くという利点が急に光って見えてきます。
そこで登場するのが、monoです。monoはNovellが中心となって勧めている、Linux（＋MacOSX）環境での.NET環境（ランタイム）で、既に最近のLinuxでは実用的に使われています。例えばSuSEでは、デフォルトでmonoが入っていてパッケージ管理やらデジカメ画像管理ソフトや音楽プレーヤ等々mono上作られて動くアプリケーションが幾つもバンドルされています。
つまり、純.NET向けのアプリケーションであれば、今後WindowsとLinux環境（あとMacもか...）で違和感なく簡単に動作するようになる可能性大、と個人的に感じました。但しmonoが頑張ってくれれば、の話です。現状、GUIデザイナーの出来がまだまだなのと、Windows.Formsの扱いや複数言語のサポートなど、まだまだの所があります。あとIEコンポーネントの代わりにMozillaエンジンをどれだけシームレスに扱えるのかとか個人的に興味あり。
ただ、速度や機能を求めて.NET外のネイティブ機能を利用したくなるものですが、それをしたとたんクロスプラットフォーム性がなくなるという制約もありますが、ある程度は仕方が無なくて、コンパイラスイッチみたいなので対応するしかないのかなと。
Linux上でのRAD環境が無いと言っていい現状、monoとmonodevelopによってLiunx上でのアプリケーション開発容易になるというキラーアプリな感じ...。ただ、現状各環境に合わせたUIの切り分けがイマイチはっきりと見えないのが残念。
Python - 地味に使われてたりする
Pythonには元々GUIライブラリというかウィジェットは無い感じなのだけど、好きに選んで利用出来るというもので、幾つか個人的にも使ってた事もあるクロスプラットフォームのJuiceとかPythonで作られてました。ただやっぱり各プラットフォーム毎に作リ直す作業は膨大なもの。
あと、個人的には..Pythonという言語的には好きな系統なのだけれども...Delphiの洗練されたコンポーネント指向の開発に慣れているとあえて手を出しにくい感じが...。
Delphi/Kylix
元々本命と目されていた？Delphi言語によるクロスプラットフォーム向けの開発ですが...ボーランドがLinux上でのKylixというIDEの開発をパタっと止めてしまっていて頓挫中。物凄く可能性があるんですけどねぇ。
Delphiという言語＋VCL（ビジュアルコンポーネントライブラリ）は、Cの柔軟性と、C++のオブジェクト指向と、VBのコンポーネント指向を合わせた感じの開発言語、IDE、ライブラリ環境です。ただ、最近ボーランドによる、Delphi Studio等IDE関連の再編でゴタゴタしています。いっそのこと、NovellあたりがKylixだけでも買収して欲しいなとか密かに希望してたりします。
一応、Delphi互換のフリーの実装として、Lazarusなんてのもあります。Linux上では元祖RAD環境と言って良いかもしれません。Write once compile everywhereって事で、とりあえず、Mac、Windowsでも動くようです。でもKylixの方が良かったと個人的に思うのでまだ手は出してません。Lazarusもやっぱり動きの速いLinux環境に対応していくのに苦労している感じです。
Xul - Mozillaのツールキット
FireFoxとかのやつ。XULrunnerを使えば単体で動くクロスプラットフォームのアプリケーションが作れる、らしいですが、本格的なのは微妙かもしれません。詳しくは触っていないのですが...。
以上、クロスプラットフォーム向けのアプリケーション開発の現状簡単なまとめでした。
一言でいうと、ずいぶん進んだけれど、まだあと一歩かなという所のようです。ただ、実感したのがLinuxの勢いです。個人的にはとても注目していますが、逆に進歩が早すぎて逆に対応が難しかったりします。Macも旧Mac9からMacOSXで*nix系に移行して直ぐにIntelのCPUに移行したりで大変そうです。そんな中で、意外に.NET/monoが色々な違いを吸収できる可能性が一番大きいのでは、と感じました。もっとも余裕であと数年は必要かと思いますが..。
そんなこんなで、もしかしたら仮想PC、特にVmwareやXenなどを使って、OSの中で異なるOSを動かすという形が一般的になって一気に解決してしまうかも知れませんね。vmwareの完成度はもうまったく素晴らしい出来で、Linux上でWindowsを動かすなんて事が簡単に出来ます。まったくもって、どう転ぶのか分かりません。
左の画像は、SuSE Linux上でSuSE LinuxとWindows 2000が同時に動いている所。複数のバージョンのWindowsを動かして動作テストや英語版を入れて国際版の開発、はたまた仮想ネットワークを作って負荷試験など色々使えそうです。一昔前は何台も実際のPCを使ってテストしたものですが...便利になったものです。