« なんかかっこいいセキュリティ対策ソフト | Main | 14 年振りの海水浴 »
このエントリから使用するブログツールが iBlog から Thingamablog に切り替わります。そこで、Thingamablog を iBlog との比較を中心に紹介し、それを通してなぜ切り替えたのかについて述べてみます。(長文注意)
Thingamablog は Java で作られたマルチプラットフォームなブログ作成 GUI アプリケーションです。Java で作られているので Java の動作環境があり、GUI を備えているので Window System があれば、OS を問わずに動作します。しかもデータは OS に依存していません。
ネイティブなバイナリコードが共通の OS を一つの OS として勘定すると、僕は自宅で使用するパソコンで過去に七つの OS を使用してきました。前のバージョンの OS のバイナリコードを使用できるものも一つに勘定しても四つの OS ということになります。OS ジプシーですね。ですから複数のプラットフォームで使用できるというのが僕がメインで使うアプリケーションの重要な要素になっています。ブラウザやメーラーに Mozilla 系を使用してきた理由はまさにそれです。それは複数の OS 用のものがリリースされています。しかしその点で Thingamablog は更に上をいきます。同じものが複数の OS で使用できるのです。
Thingamablog はオープンソースプロジェクトでしかも無料(GPL ライセンス)で使うことができます。現在のところ Bob Tantlinger さんが一人で保守&開発しているようですが、バグや欠点をユーザが手直しすることが可能です。実際に私はそうしてきました。そしてそれを寄贈または提案すれば受け入れられて次のバージョンに反映されます。実際に Thingamablog 1.5 は私の提案が幾つか織り込まれています。
今まで使用してきた iBlog は有料アプリケーションでバイナリで提供されています。私は利用しているサービス .Mac で無料で配布されて手に入れましたが一般には有料です。
この点のみではどちらがよいか歴然としています。無料で済むのなら無料がいいに決まっています。バイナリだけの提供とバイナリとソースの両方の提供とならソースもあった方がいいに決まっています。たとえ自分がソースをどうにもできなくとも誰かがどうにかできます。作者や開発元に事故があったり開発や保守が停止されてもオープンソースなら誰かが引き継ぐこともできます。
加えて上述のように Thingamablog はマルチプラットフォームです。iBlog は Mac OS そのものが消滅したり使わなくなったら使えませんが、Thingamablog はたとえ Mac OS X が無くなっても遜色はありません。全く新しいプラットフォームでも使える可能性がとても高いです。
iBlog、Thingamablog 共にブログを公開するサーバに対する要求は最低限のものです。つまり HTTP サーバであれば十分で CGI が使えなくても、DB が備わっていなくてもブログを構築できます。これは他のツールには滅多に見られない特徴です。ブログを公開するためにサーバを選定する必要はありません。いや、ローカルで読むためだけなら HTTP サーバすら必要ありません。
iBlog はサーバへのアップロードを最小限にするために、CGI でやりたいところを JavaScript に背負わせています。アプリ作成者とそのユーザにとってはメリットがあります。しかしこれは読み手にはメリットがありません。動的なコンテンツならともかく静的なものに JavaScript は本来必要ありません。ここで動的というのはユーザが見ている前でコンテンツに変化があることだけではなく、見ているページ自体に変化がなくとも別なところが影響して表示内容に変化があることも含みます。例えば昔のエントリに手を加えなくても新しいエントリを書くと総エントリ数に変化があります。iBlog では総エントリ数の表示は JavaScript を用いています。もしこれをページに直接書き込むと一つエントリする度に全てをアップロードする羽目になってしまいます。
Thingamablog ではそういうものは排除されています。ですから iBlog にできて Thingamablog にできないこともあります。しかしそれらは必須のものではありません。総エントリ数を気にする読み手は極めて少数のはずです。
ということは Thingamablog によるブログは読み手に JavaScript を要求しません。更にマルチプラットフォームであることで書き手にも OS の種類を要求しません。iBlog は Mac OS X ユーザでなければ使うことはできませんが Thingamablog は Mac OS X である必然性がありません。むしろ Mac OS X ユーザで Thingamablog を使っている人は少数派だと思います。
iBlog と比較して Thingamablog のテンプレートは実に柔軟です。
例えば iBlog でも Thingamablog でもエントリのタイトルを表すのは <$EntryTitle$> です。iBlog では常にエントリを書くときに付けたタイトルのとおりに置き換えられます。Thingamablog では <$EntryTitle$> と書けば同様に、<$EntryTitle encode_html="1"$> と書くとその中の HTML 予約文字 '&', '<', '"', '>' がそれぞれ "&", "<", """, ">" に置き換えられます。
このため iBlog では <$EntryTitle$> は PCDATA といって文字を書くところ(開始タグと終了タグの間)でしか使えませんが、Thingamablog では HTML の属性値の中でも使用できます。ブログページからエントリページへのリンクでは僕は iBlog でも <a href="エントリページのURL" title="エントリのタイトルを含んだ文字列">リンクの文言</a> というようにしたかったのですが、このためエントリのタイトルの代わりにエントリの ID を用いていました。しかしエントリの ID は読む人にとって意味の分からないものです。title 属性に入れる意義があまりありません。
一方で Thingamablog では encode_html="1" という属性を付けることで要素(タグ)の属性値でも使えるようになり、望みのリンクを作ることができます。
例えばエントリが投稿された日付を表すのは、iBlog では <$EntryPostDate$> で Thingamablog では <$DayHeaderDate$> です。iBlog ではシステムのロケールに従って年月日の個々の要素が生成された上で並び順が英語式になります。ですから日本語のロケールで使用している場合、日本語で書かれた英語順の日付になってしまってとても変です。
一方で Thingamablog では特に指定しない場合の書式をブログの設定で幾つかの中から選べるだけでなく、それぞれのテンプレートタグで書式を指定できます。例えば <$DayHeaderDate format="yyyy年M M月dd日"$> とすると日本語として意味のある書式の日付に置き換えられます。
iBlog では設定によりブログページやカテゴリページで幾つかの古いエントリのリンクだけを載せることができます。これは Thingamablog にはない機能です。しかしこのリンク群の作り方がまずいです。個々のエントリのリンクが div 要素で囲まれて、更に後ろに強制改行の br 要素が付いてきています。見た目をマークアップでしている XHTML コードが強制的に入れられてしまいます。
一方で Thingamablog ではテンプレートタグは XHTML の個々の部品であって、XHTML コード自体はテンプレートに必ず書くようになっています。つまりアプリがページのマークアップを強制しません。
これはブログを XHTML で構成しなくともよいことに繋がります。iBlog では生成されるページは全て index.html ですが、Thingamablog はファイル名や拡張子を設定することができるのです。PHP を利用したブログ、Perl の HTML::Template を利用した CGI によるブログ、Java の JSP などで動的なサイトに組み込むことも可能なだけでなく、各ページを XML で出力して AJAX で表示するなんてことも可能です。
iBlog でも Thingamablog でもエントリを書くときは備え付けのリッチテキストエディタで書きます。書いているときの表示がほぼそのまま公開後のエントリの見た目になるので XHTML を知らなくても気軽に書くことができます。iBlog は OS ネイティブな機能を使っているのでこの点では iBlog の方が優れていてエントリを書くときの見た目と Safari での表示は iBlog の方が一致しています。
しかしこの機能自体は読み手にあまり意義がありません。読み手にとって重要なのはそれが読みやすいかどうかです。読み手も Safari を使うとは限りませんし、IE や Safari や Firefox のような視覚的なブラウザを使用しているとも前提できません。読み上げブラウザや点字ディスプレイを使っているかもしれないし、RSS リーダによって制限された HTML 表示をしているかもしれません。何を使ってどうやって読むかは読み手が決めるものです。
こういう観点に立つとこの機能の意義が少ないだけでなく結果がまずいことにも気付くはずです。エントリの中で強調したいところを太字にしたとしたら結果は b 要素によって太字にされます。それは見ている場合に意味がありますが、聞いているときや触っているときには全く意味がありません。それどころか太字であることと強調してあることとは直接の関連はありません。見ていたとしてもそれが強調であると解釈されないかもしれません。解釈されるとしたら読み手が視覚的に読んでいる上で、たまたま使用しているブラウザの strong 要素の表現が太字にしていて見た目が一致し、ユーザスタイルシートを設定していないかしていたとしても strong 要素が太字に見えてそれ以外の表現はとくにしていない、そういう条件が成立しているときだけです。
強調されているという意図を伝えるためにはそういう意図を伝える strong 要素を使った方がより直接的なだけでなくより広範囲に意図が伝えられます。そうすれば人にだけでなく検索エンジンにも伝えることができます。意図を伝えた上で、それをどのように表現するかは CSS に書いておけば意図も表現も両方表明できます。b 要素だと表現だけだったのが意図も表現も両方伝えられるのです。そして読み手は自分が使用しているブラウザの表現やユーザスタイルシートによる自分にとってわかりやす表現に差し替えることも可能になります。
このような欠点を解消するには、太字ボタンではなく強調ボタンがあればよいのですが iBlog も Thingamablog もこのような最近の考え方に基づいて作られた HTML エディタを備えていません。その代わりどちらも XHTML を直接書くことができます。iBlog は <HTMLCode>, </HTMLCode> で挟まれた箇所が XHTML と解釈される埋め込み方式で、Thingamablog はエディタのモードを切り替える切り替え方式です。iBlog はユーザがリッチテキストを書くのが基本で、その拡張として実装しているのに対し、Thingamablog は書き方をユーザが選べるようにしています。
セクション「テンプレートが柔軟であること」も合わせて考えてみると、iBlog はアプリケーションが用意したものをそのまま使ってそこそこのものを作り、好みに応じて多少のカスタマイズを加えることができるようにという発想でデザインされているのがわかってきます。これは特別な予備知識がなくてもある程度の結果を出すことができるというメリットがありますが、そこまでです。アプリケーションが想定した範囲を超えて使いこなそうとしたとき、しなくてもいい苦労をユーザにかけることになります。一方で Thingamablog は特別な予備知識がなくとも始められそこそこの結果を出せるようになっているだけでなく、それを超えて使いたいときにもなるべく自由度を維持しようというデザインになっています。
両者のどちらがよいか。それは特別なカイスタマイズをしなくても達成できる結果の良さと、アプリが意図している範囲で予備知識無く結果を好みに合わせられる GUI の柔軟さにあると言えるでしょう。そしてパワーユーザにとっては、それらを土台にしてどこまでうまくできるかという設計センスの良さも重要です。
アプリが想定した範囲でしっかした結果を出せるのならそれはそれでよいと思います。Apple の iLife などは満足できる結果を出してくれています。しかし iBlog はそうではないのです。日本語環境でなんのカスタマイズせずに使い始めれば一発でわかります。ブログページの日付の文字列が変なのです。僕が使い始めた頃の iBlog は詳しくページの作りを見ていけば見ていくほどボロが出てきました。結果としてその意図するところによって自由に使いこなせないようになっているだけでなく、その意図で期待されるそこそこの結果という効果も出せないものに仕上がっています。はっきいり言って駄目アプリです。使い始めて一ヶ月も経たないうちにその駄目さを補うための支援ツール iblogPatcher を作って公開したほどです。
その結果、iBlog + iblogPatcher の組み合わせは潜在的に強力なものにはなりました。ただしそれと引き換えに、目標とする結果を出すためのセッティングが複雑になりました。iBlog の発想の中の「そのままで気軽に」という部分は全く取り払われてしまいました。
Thingamablog の方はどうかというと、単体でしっかりした結果を出してくれます。複雑でない GUI も備わっています。使い続けるために何かに登録したりお金を払ったりする必要もありません。サーバも HTTP サーバならなんでもよいし、CGI を設置するためにパーミッションがどうのこうのというややこしいこともありません。エンドユーザにとってどちらが取っ付きやすいか、それは明白です。
そしてアプリの通常の範囲内での柔軟さはどうでしょうか? これまで見てきたように Thingamablog の方が遥かに柔軟です。iBlog はそれぞれのテンプレートタグが使えるところの中でもどのように使うかに制限がありますが Thingamablog にはほとんどそういう制限はありません。唯一 iBlog の方がカスタマイズ性で優れているのはテンプレートセットと CSS を GUI で切り替えられることです。Thingamablog はファイルの入れ替えによってそれができ、多くの人にとっては GUI の方がよくても僕にはどちらも大して変わりありません。
そしてアプリの想定外の柔軟さはどうでしょう? これは現時点では iBlog の方が優れています。ただし単体でということではありません。iblogPatcher などの支援ツールがあって初めて柔軟さを手に入れることができます。「など」と書きましたが、拡張性を備えた支援ツールで iblogPatcher 以外のものを僕は目にしたことがないので恐らく唯一のものでしょう。
では Thingamablog はオープンソースであることを利用したプログラミングによる拡張以外にそういう柔軟性を獲得する手段はないのでしょうか? そんなことはありません。Thingamablog も iBlog のように一旦ローカルにプレビューブログを生成するようにして使うこともできます。実際にこのブログはそうしています。そしてこのことは iblogPatcher 本体自体はそのまま Thingamablog にも使えることを意味しています。iblogPatcher はその設計自体が特定の処理のみを目的としたものではなく、処理の具体的内容はプラグインと呼んでいる機能拡張ファイルに記述します。Thingamablog 用のプラグインを作れば、iBlog と同等の柔軟さを手に入れることができます。したがって、現時点は様々な機能拡張ファイルがある iBlog の方が拡張性が高いですが、潜在能力としてはどちらも同じです。
まとめると、初級者、中級者、上級者、これらどの段階のユーザにとっても Thingamablog の方が優れているか、潜在的に同等であるかだということです。そして .Mac サービスの web スペースで共に使え、たとえ Mac OS X を使わなくなっても、余計な出費なく変なバグもなく使い続けられるとしたら、iBlog ではなく Thingamablog を使わない理由はありません。逆に iBlog を使う理由はないと言った方がよいかもしれません。
上の結論は機能的な評価です。アプリを使う上でそのアプリが醸し出す雰囲気というのも大切な要素である場合があります。更に困ったときやに助けてくれる他のユーザがいることも大切な場合もあります。今までのデータを引き継げるかどうかも重要ですね。
ですから Java で作られて Mac OS X アプリとは異なった look&feel を持っている Thingamablog ではなく iBlog を、ユーザコミュニティが日本にはない Thingamablog よりも iBJ や t0mo レンジャー がいる iBlog を、今まで iBlog だったから iBlog を、そういう選択は十分に考えられますし、それはそれで納得できるものです。
しかしこれは僕の理由にはなりません。look&feel はそれほど気になりません。なぜなら僕は過去に七回も OS を変えてきたくらいですし、look&feel がない CUI アプリ NanoBlogger だってよいくらいです。iBlog を使い始めるときに色々な方のサイトを参考にさせていただきましたが、それは過去の iBlog の困ったチャンなところの現象把握が主です。そもそも Thingamablog には致命的な困ったチャンなところがありません。Java は読めるし書けるし XHTML や CSS もそうですからなんとかなります。そしてこのブログが実証しているように iBlog で書いたことを全て引き継ぐことに成功しています。Thingamablog には他のブログシステムからデータをまるまるインポートするインターフェースがありませんが方法はあるのです。ローカルアプリケーションだからこそインターフェースがなくても方法があると言えます。
とはいえ、致命的でなくても困ったチャンなところはあります。Mac OS X 限定だと思いますが、Thingamablog に備え付けのエディタがキータイプのスピードに追いつかないのです。仮名漢字変換のとりまわしが悪いようです。Mac OS X ではあまり使い物になりません。しかし JEdit など他のエディタで書いてコピペすればよいので致命的ではありません。その方が使い慣れて高機能なエディタが使えるので iBlog であろうがなんであろうが、ある程度まとまったことを書くにはそうしてしまいます。不満ではありますが致命的ではありません。
そして GUI を通して保存したエントリやテンプレートは勝手に整形されてしまいます。しかもその整形がべた書きの言語を考慮していないようで気に入らないこと甚だしいです。XHTML としてはほぼ問題がありませんが pre 要素や CSS で改行や空白をそのまま表示するようにしているところでは困りものです。(今現在の Thingamablog の回避できない不具合はこれだけだと思います。)
それと RSS ではエントリの中の日本語が実体参照にされてしまいます。これは Thingamablog が使用している tagsoup のせいなのですが、その現象を抑えるカスタム版の tagsoup を作成して公開してあるのでこの問題は消滅しました。日本語で Thingamablog を使う人にとってはこれを見つけ出せるかどうか次第ですが。
以前に「iBlog vs. Thingamablog : 比較」というエントリを書いたことがあります。それを読んだ方はそこに書いたこととえらく論調が違うことに気付くでしょう。
しかし上に述べてきたことを読んだ上でもう一度そのエントリを読んでみてください。そこで iBlog の方が優れているとされた事項を挙げてみましょう。
Thingamablog もちょっとした工夫でそのようにできます。
これは文句無く iBlog の方が優れています。でも僕はあまり活用していません。
Thingamablog 自身はサポートしていませんが、Mac OS X が iDisk や WebDAV ボリュームのマウントをサポートしているので Thingamablog が大きく劣るわけではありません。
これは文句無く iBlog の方が優れています。最近 Thingamablog ユーザも少しずつ増えてきたようです。特に困ることがないのでユーザ間での情報交換はあまり活発ではありませんが。しかし、このことはアプリケーション自体の特性ではありません。
つまり僕自身に限定すると iBlog 自体に目立ってよいところは皆無なのです。Thingamablog が辛勝と判定した事項も iBlog の利点として見てみましょう。
これは GUI で CSS を書かなくても CSS をある程度カスタマイズできることを指しています。しかし、僕がこの機能を実用したのは iBlog を使い始めた初日だけです。iBlog の動作を研究する目的でその後も弄ったりしましたが、この機能でできるカスタマイズの範囲が狭いとカスタマイズしたい人にはすぐに思われてしまうはずです。
実際にそうしたいと思ったことは僕は一度もありません。
確かにそのとおりです。
僕自身に限定していなくても Thingamablog の方がよいとしたことを敢えて iBlog のメリットとして記述し直してみました。唯一説得力があるのが Thingamablog 備え付けのエディタの回避可能な問題点から来る相対的な iBlog の良さです。ネガティブな理由であって積極的に iBlog を選択する理由にはなりません。回避可能ですし。
それでも合理的でない理由で iBlog は使い続けるつもりです。なにしろ毎年高いお金を払って .Mac を利用しています。そこで無料で配布された iBlog ですからその高いお金の分を取り戻さないと気が済みません。それに駄目アプリのところを押して頑張ってそれなりに満足できる結果を出せるようにしてきた iBlog です。苦労した分愛着があります。それが将来にわたってメリットをもたらさないのならばっさり捨てることも必要でしょうが、個人ですから愛着とか意地とかそういうのを満たすのもれっきとしたメリットです。
合理的な理由としては今現在は iblogPatcher がある iBlog の方が実装できている機能が豊富なので一度に全てのブログを Thingamablog に移行するとその恩恵にあずかれません。敢えてこれを捨て去る必要もないでしょう。しかし、それに甘んじていては上に述べてきたように僕にとってより優れたツールである Thingamablog のメリットも享受できませんから、まずは実験場でもあるこのブログから移行してみたというわけです。