Jun 30, 2006

Movable Type 3.3リリース

既報ですが、Movable Type 3.3がリリースされました。まずはおめでとうございます。

Six Apart - Movable Type News: Movable Type 3.3 正式リリース

私もベータテスト当初は、MT_3_2_ja2_UO_Patch - ogawa - Google Codeのうち、ベータ版で漏れていた分を中心にバグレポートを上げたり、そのほかの点についても指摘したりしました。正式版はまだ目にしていませんが、svn logを見ている限り、指摘した事項のうち、ちゃんと対処されたものもあり対処されているけど不十分なものもありスルーされたものもありという感じです。正式版で不具合が見つかれば、その点に関してはまたWikiにでもまとめていくつもりです。というか、SixApartでWikiを立ち上げたらよいのに…。

さてベータテストなのですが、私の偽らざる印象を述べれば、まったく「ブラインドテスト」のようでした。目隠ししてBeta 2とBeta 3のどっちの「味」がいいですかと言われたようなもの。

テスターにはコメント投稿インタフェースだけが提供されていて、具体的にどういうバグが問題になっているのかまったく見えませんでした。リリースノートには修正されたバグについて掲示されていましたが、それが具体的にどう達成されたのかについては、svn logを慎重に読んでいる人にしか分からず、そこに挙げられている問題が全部なのか一部なのかについては把握しようがないという状況でした。それらの事柄に関してはSAだけが支配的に知っていればよく、結果として(開発者にとってはS/N比が改善して?)以前のベータテストより短いテスト期間にも関わらずより多くのバグ修正ができたのは確かだろうと思います。しかしながら、上で述べたような情報の非対称性に加えて、テスト期間が短くかつ早いサイクルで次のベータ版がリリースされたことは、テスターにとってはなお望ましからざる状況を生み出しました。例えば、自分が発見・報告したバグらしき現象が「正しく」認識され、BTSにファイルされたことが(ACKメールを受け取ったにせよ)確認できなかったことは、テスターの動機付けをより弱いものにしたでしょう。また、デフォルトテンプレートが更新されることは、テンプレートにある組み合わせ以外でMTタグを使ったときに生じるであろう問題の追究を、テスターに躊躇わせるのに十分だったでしょう。そうしたことが潜在的なバグの発見を遅らせしめた(あるいは困難ならしめた)可能性についてひとまず指摘(憶測)しておきます。

また、バグレポートとしては上げませんでしたが、正直なところブートストラップとDB周りを何とかして欲しかったです。例えば、MySQL 4.1以降の対応部分ではshow variablesまでしてcharacter-setを確認しているのだから、バージョンチェックして4.1以降だったらTemporary tableを使わずにサブクエリーを使うようにチューニングできたはずです。Postgres/SQLite対応の改善も積み残しです。また、設定ファイルが分かりにくいのは、多数の項目をフラットな名前空間に押し込んでいるせいです。設定ファイルの下位互換性の問題はありますが、YAMLあたりを採用して階層化する方法もあり得ました(そうすれば機能モジュール間で独立でない変数があることも容易に発見でき、改善に役立てることが可能だったでしょう)。

くどくどしいことを書きましたが、正式版がリリースされ、副産物としてユーザやサードパーティ開発者との間にsvnという新しい「絆」ができました。このまま放置せず、メンテナンスリリースなどに活用されることを期待するとともに、御社のますますのご発展を祈っております。

P.S. Six Apart - Movable Type プラグインには、recently-ping-onプラグインが掲載されたようです。SAから委託を受けた業者から掲載許可を求めるメールが来ましたが、返答するまでもなく掲載されています。(物事の順序について苦言を呈したいところですが)断る理由もないのでこのまま放置しておきます(OKということです)。あと日米で2回ポストしなくてはならないのだとすると面倒で仕方がないです(これは仕方がないことでしょうかね…)。


ところで私はまだ移行していないのです。移行の前にApache httpdを1.3.xから2.2.2に、MySQLを4.1から5.0にバージョンアップしようと思っているので。httpdは上げたのですが、Aliasの振る舞いが変わっていて久々に嵌りました。php5をモジュール版からFastCGI版にしてみたり。

Jun 24, 2006

VPSLink

また性懲りもなく(Ogawa::Buzz: VPS7難民)、VPS (Virtual Private Server)を借りてみたYO。

VPSLink

今はさくらの専用サーバを借りてFreeBSDで使っているのだけれど、月額料金がお小遣い程度とは言いがたい状況だった。それだけの価値があるのは確かだけれども、sustainable blogは、広告料と釣り合う程度のコストを支払いつつ、知的好奇心を多少なりとも満たせるホスティングサービス上で運営したいものだ(AdSense狩りがかえすがえす口惜しいわけだが…)。

で、VPSLink。ありし日のVPS7並(それ以下?)の料金で利用できるOpenVZ(OS上のVirtualization)サービス。ここが面白いのは、安いことだけではなくて複数のLinux distroから選択してデプロイできるということ。コントロールパネルから今までのはなかったことにして他のdistroをデプロイし直すなんてことができる。しかもほとんど時間もかからない。リブートの方が時間がかかるくらいだ。

ひとまず、VPSLink 3を借りてUbuntu 6.06をデプロイしてみた。nslookupとかfileとか基本的なコマンドが入っていなかったりtimezoneがUTCだったりしたのはご愛嬌。Webminとか変な管理ツールが入っていない素っ気なさにも愛を感じる。少し手を動かして、公開しているsvn repositoryを移行してみたところだ。

そうそう。OpenVZのGuaranteed RAMというのは結構曲者っぽい。普通メモリ256MBのマシンなら256MB+swap分の(optimisticなallocatorならそれ以上の)メモリをアロケートできてしかるべきだが、Guaranteed RAMというのは仮想的なメモリに対する制限らしい。例えば、MySQLでQuery Cacheを16MBほど採る設定にしてあると、(まだそのページに触ってもおらず)実際には実メモリが未アロケートな状態でも16MB分のVirtual Memoryがメモリ使用量に加算されるだろう。だから、パラメータの設定には慎重になる必要があるし、そういうことに対する負担を軽減したければVPSLinkで契約するときになるべく上位のプランを利用すべきだということになる。

本当のところを言うと、Para-virtualizationやVirtual Machine技術を使ったサービスが望ましい(そうすればOpenVZのメモリシステムに煩わされることもない)のだが、まだ安定性や料金の点で厳しい。Xenを仕事で使っていると分かるのだが、たとえシングルCPUノードに2GBメモリが積まれていたとしても、256MBのKernel-XenUを数台動かすというのはあまり現実的でない。満足いく性能を達成するにはVM数を物理CPU数+αかせいぜい定数倍まで減らす必要がある。つまりはプロビジョニングの手段としては相当に有効でもパーティショニングの手段としては疑問符を付けざるを得ない。一方でコストを低廉化するのはパーティションの個数だ。結局のところ、1ノードまるごと借りるよりコストを数分の一にできるかもしれないが、十~数十分の一にするのは無理であるか性能・安定性を犠牲にするということだ。Virtual Machineならば状況はなお厳しいってこったね。

Jun 18, 2006

Gmail for your domainを試験利用中

だいぶ前にGmail for your domainに申し込んでいたのだが(Ogawa::Buzz: Gmail for your domain)、二週間くらい前にめでたくbeta testerに割り当てられた。

Googleに申し込んだドメインのMXを、Googleに指定されたホスト名に、DNSで設定すればよいだけ。なのだが、これを設定してしまうと、当然そのドメイン宛ての(SMTP)メールによるinbound messagingをトリガーとして利用するサービスを、自分のサーバで提供することができなくなってしまう。端的な例を挙げれば、自サーバでメーリングリストサービスやmoblogサービスをホスティングできなくなる。したがって、そういうサービスを作り込んでしまっている場合には軽々に移行できなくて嬉しさ半減なわけだ。

そんな重要なことに今更気が付いても遅いのだが(というかもちろん承知の上で私は申し込んでいるのだが)、Gmail for your domainに申し込むときは、自分の持っているドメインのサブドメインを登録した方がよい。あるいは逆転の発想で、申し込んでしまったものはしょうがないので、自分のドメインのMXはGmailにホスティングしてもらい、そのサブドメインのMXを自分のサーバに向け、moblogなどのホスティングはサブドメインで運用するという方法を採ることもできる。

で、結局私はどう考えているのかというと、自前で動かすMTAなんてスパムやDoSアタックの源になるだけで、意味がないというのは言い過ぎにしても、間違いなくMTAの保有コストは年々上昇している。だから保有コストを実質ゼロにしてくれるGmail for your domainを使わない手はない。Inbound messagingに関しても、SMTPのようないにしえの道具で実現するよりはHTTPだけで実現するという割り切りも必要だろう、なぜなら資源は限られているのだから。

そういうわけで、私は素直にMXをGoogle MXに設定した。またその上で、postfixのmain.cfで以下のように設定して、localhostからのメッセージ(sendmailコマンド経由、port 25経由)だけは処理するようにしてみた。/etc/mail/aliasesでは必要最小限のローカルなmailbox名を外部の(Gmailの)メールアドレスにマップしておけばいい。

myhostname = www.example.com
myorigin = $myhostname
relayhost = example.com
inet_interfaces = localhost
alias_maps = hash:/etc/mail/aliases
alias_database = hash:/etc/mail/aliases

とりあえず、長大なmaillogを見ずに済むようになっただけでも快適である。


「Gmail for your domain」の自然な拡張を考えると、Googleの他のサービスを独自ドメインで提供することができるのではないか。例えば、Google Bloggerでは現状、(1)blogspot.comドメインを使用するか、(2)自サーバ上にFTPサーバを用意してアップロードしてもらうことで独自ドメインを使用するか、を選べる。しかし、MXと同様、Googleの用意したリダイレクトサービスを指すように独自ドメインのCNAMEを設定しておけば、(3)ブログ自体はGoogleにホストさせた独自ドメインのブログサービス、を簡単に実現できるだろう。

もちろんこれは、はてなダイアリーや他のブログサービスでもできるはず。なんでやらないんだろうね。

Jun 12, 2006

持病

職業病というか持病というかそういうものに苦しめられている。闘病生活だ。この持病の悪化を防ぐには禁酒しなくてはならない。これはつらい。ほどなく日本-オーストラリア戦が始まろうとしているのに、中日ドラゴンズが交流戦で昨年よりはマシな戦いをしているのに、楽しみも半減というものだ。冷えたビールがないなんて~♪ とはいうもののなんとか一週間以上禁酒を継続できている。だが改めて気が付いたのはアルコールを摂取しないと塩辛いものと脂っこいものは食べられないということだ。これらの食品を食べるとビールを注文したくなってしまうので食べない。断じて食べない。寿司だって少量以上食べることは不可能だ。並大抵の覚悟で外食はできないということだ。一方で、飲酒もせずにこうした食品を食べられるという人は、少なからずいるわけだが、もっともっとずっと賞賛されてよいと思うようになった。例えば、どんな飲み会でもウーロン茶しか飲まない参加者が一人や二人はいるだろう。彼らはすごいぞ。アルコールなしでシーチキンやコンビーフうま盛りのサラダや寄せ鍋を食べているんだからな。それが済んだかと思ったら揚げ物が出てきたりする。正直アルコールがなければフザケンナコンナモンクエルカヨーってメニューだ。それでいてメートル上がったおやじに絡まれたりすることも辞さない。おまいらすげえよと思った。もうね種族がホビットとエルフくらい全然違うんじゃないかと思った。脳内で。ま、それはともかくとして、私の普段の食卓からは脂っこいものや塩辛いものは姿を消しつつある。そうすると食事を終えても茫洋とした虚無感が残るわけだ。で自然に甘いものに手が…。Σ( ゚Д゚)ハッ これか、こういうカラクリだったのか。確かにこの虚無を埋めるには甘いものしかない。そう、今私は猛烈に自分を恥じている。加藤大や数多くのダイエッターに向かってクワナキャヤセルノニーとか暴言を繰り返していたことを…。正直すまんかった。確かにダイエットは大変っぽい。この虚無感との戦いなのだから…。というわけで、今週には手術をする予定で来週の今頃には快気祝いができるかなというところなのだがそううまく行くかどうかは私の体しか知らないことだ。ハヤクケンコウニナリタイ!

てわけで、日本対オーストラリアは1対3で負け。早くも秋風を感じる今宵。

Jun 8, 2006

TagSupplementals Plugin公開

Movable Type 3.3以降のタグに、いくつか便利機能を追加・拡張するプラグインを公開しておきます。今のところ、まだ3.3自体ベータテスト中なのでほとんどの方には恩恵はありませんけど。

TagSupplementals - ogawa - 「タグ」機能を追加・拡張するプラグイン。 - Google Code

Movable Type 3.3でタグ機能がネイティブ対応されましたが、標準で用意されているテンプレートタグだけではTagwire Pluginなどと比較して機能が不足しているため、不便を感じなくはありません。

TagSupplementals Pluginは、MT 3.3の提供するテンプレートタグに加えて「あったらいいな」と思われる機能のコレクションを提供することを目指しています。今のところ以下のテンプレートタグを提供しています。

MTEntryTagsCount変数タグ
現在のエントリーが持つタグの個数を返す変数タグ。
MTRelatedEntriesコンテナタグ
現在のエントリーと類似度の高い(タグの共起度の高い)エントリーをリストするコンテナタグ。

他に必要そうな機能があれば、コメント・トラックバックでお知らせください。簡単に実現できるものなら対応したいと思います。


2006-06-18追記:
その後、MT-XSearchに対応しました。また、以下のタグを追加しました。

MTRelatedTagsコンテナタグ
現在のタグと関連する(一つ以上のエントリーにおいて共起する)タグをリストするコンテナタグ。
MTTagXSearchLink変数タグ(*)
MTTagSearchLinkのMT-XSearch版。
MTXSearchTagsコンテナタグ(*)
MT-XSearchのクエリー文字列として与えられたタグをリストするコンテナタグ

(*)の付いた機能はMT-XSearchがインストールされている場合のみ利用できます。それ以外の機能はインストールされていなくても利用できます。

あまり動作確認していないのでバグ出しにご協力いただければ幸いです。

Jun 5, 2006

mt-keywords2tags / mt-cats2tags公開

エントリーの「キーワード」を、MT 3.3以降でネイティブにサポートされた「タグ」にコンバートするCGIスクリプトを公開します。

MTKeywords2Tags - ogawa - Google Code

Movable Type 3.3以降では、ネイティブにTaggingをサポートするようになりましたが、それ以前のバージョン用に作られたTaggingプラグインの多く(Tags Plugin, Tagwire Plugin, Tags.Appなど)は、エントリーのキーワード欄をタグ入力欄として使用してきました。

このCGIスクリプトは、エントリーのキーワードをMT 3.3ネイティブなタグに変換することで、従来のTaggingプラグインユーザのネイティブタグへの移行を支援するものです。


さらに!

エントリーの「カテゴリーラベル」を、MT 3.3以降でネイティブにサポートされた「タグ」にコンバートするCGIスクリプトも公開します。

MTCats2Tags - ogawa - Google Code

このCGIスクリプトは、エントリーのカテゴリーラベルをMT 3.3ネイティブなタグに変換することで、従来「カテゴリー」を活用してきたユーザのネイティブタグへの移行を容易にするものです。

ところでSQLiteでは、mt-search.cgiによるタグサーチがうまく機能せずにロードが1に張り付いてしまう現象が観測された。MySQLで試した限りは問題ないので、少し調べる必要がありそう。
Ogawa::Buzz: MT 3.31 SQLiteがベラボーに遅い件について。がことの真相。

Movable Type 3.3ベータテスト

先週末からMovable Type 3.3 Beta1が出ています。

Six Apart - Movable Type News: Movable Type 3.3 ベータテスト開始

改善点は実はものすごくたくさんあります(日本語訳は今のところ提供されていません)。

Movable Type 3.3 Beta - Bug Sumbissions for Movable Type 3.3 (beta)

以下雑感。

  • Transformer機能

    プラグインから管理画面のインタフェースをカスタマイズできる機能が追加されています。直感に従えば、この機能はBigPAPIとほぼ同等の機能なのでしょう。なのでやっぱりBigPAPIとコンフリクトします。MT 3.3では、BigPAPIをdisableする必要がありますし、BigPAPIに依存するプラグインは(Transformer用に書き換えない限り)動作しないでしょう。

  • Tagging機能

    だいたい予想していた通りです(機能的に不足も感じますが、それはTagwire同様作ればできるというだけのことです)。が、コア機能として提供すべきものなのかどうかについては疑問を感じなくはないところ。また、棚ぼた的ではありますが、3.0以来あんまりメンテナンスされていなかったMT::App::Searchが3.2以降のアーキテクチャに合わせて書き換えられたというメリットがあります。

    それとですね、Tags Pluginのユーザは山と作られたカテゴリーをどうすればいいんでしょうね。あと既存のTags, Tagwire, Tags.Appなどのプラグインではエントリーのキーワード欄をタグ入力に使っていましたが、これを3.3のタグに変換する簡単なツールは、近々作ってリリースしたいと思います。

  • Activity Feeds機能

    …あまり重視していません。やろうと思えば適当なMTアプリを書けば前からできたことなので。

  • Task Manager機能

    定期的に行いたい処理をMovable Typeに実行させることができます。cronの簡易な代替品として使えます(invocationはMTアプリの起動時に制限されますが)。例えば、一日一回はてなブックマーク件数取得APIでブックマーク件数を取得して更新、みたいなアプリ・プラグインが割と簡単に書けます。MTの中では今のところJunkFolderのクリアと指定日公開するのに使われているだけのようです。

  • mt-config.cgiの大幅な簡略化

    これは今リリース最悪の変更。ミニマムな設定だけで使えるようになるのはよいのですが、それ以外の設定がDB上にストアされるのかと思いきやそんなことはなく、手でmt-config.cgiに追加しなくてはなりません。Movable Type 3.3 マニュアル(ベータ版)を見ながら書き写せってことなんでしょうが、設定ファイルがself-documentedであることで回避できているhuman errorの量を過小評価しているのではないでしょうか。ミニマム設定以外にもクリティカルな設定はたくさんあるので、minimum版に加えてself-documentedなfull版を提供するとよいと思います。

  • その他

    単調な機能追加が行われた結果、モノリシックなブログシステムとしてこれ以上機能が多いものはありません。CMS.pmに限ってみても、2.661のときには3632行でしたが、いまや9882行あります。Bugshooterの立場からもいい加減リファクタリングしてほしいところですし、システムとしてもPerformance Tuningなどほとんど不可能ですし、20MBを超えるアプリケーションインスタンスのメモリフットプリントもスタートアップタイムも大き過ぎます。とりわけスタートアップタイムの長さが、スパム攻撃を(単なる露出や広告効果を目的とした迷惑行為というだけでなく)DoS攻撃たらしめている元凶なのだという認識をもっとコミュニティが共有すべきでしょうね。

    Wordpressの隆盛もあって個人/SOHO向けのブログシステムとしては収束しつつある今、個人的には、Movable TypeはBlogging System Construction Toolkitとして頑張って欲しいと思っています。モノリシックシステムはWordpressに任せて、ユーザが機能追加・削減して、スタートアップタイムに特化したシステムを作れるとか、ケータイに特化したCMSが作れるとか、エントリーボディに画像が格納できてそれに対する編集・タギングができるシステムを作れるとかそれがAtom APIで操作できるとか(今のembedded imageのアップロード機能はしょーもなさ過ぎる)、ブックマーク専用システムを作れるとか。それらをcooperativeに利用してブログシステムを実現するとか。ね、夢が広がるでしょ?

About Me

My Photo

つくばで働く研究者LV15

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com