調べてみたところ Amazon Webサービス (ECS3) の応答メッセージ自体が文字化けしているようで、ちょっといかんともしがたい状況です。先方のシステム復旧待ちです。
15:32 追記: 直りました
]]>いずれ、フィードのURLも301で向こうに飛ばすかもしれませんが、とりあえずはフィードは現状維持させておきます。
]]>一方、はてなRSS は http://r.hatena.ne.jp/xmlrpc に ping することでクロール間隔を早めることができる。
この両者に ping を飛ばす場合、順番に気をつけないと、FeedBurner との同期が完了するまえに巡回君が来てしまう可能性があり、いや〜んなことになる、というのに気付きました。FeedBurner → はてなRSS の順番が正解。
ということでテスト中です。
あ、最近はnaoyaのはてなダイアリーの方をメインに更新していますので、こちらもよろしくお願いします。NDO::Weblogを今後どうするかは検討中。
]]>ということで、コメントでやりとりしていた話を ishinao さんがまとめています。とてもよくまとまっているので、御一読を。
あと、今回の件でMT に脆弱性が、という記事を書かれた方は、その後のフォローとしてこういった記事も一緒に引用あるいは参照として記載しておくと、周囲の人の理解が正しい方向へ向かうので有益ではないかと思います。
]]>というアナウンスが出ていてるのですが、これに関してメディアとか巷の blog で過剰に反応しているものが散見されます。
が、アナウンスで赤字で強調し指摘れてるところを良く読んでからも分かるとおり、これは Movable Type そのものの脆弱性ではないですし、そもそも脆弱性なのかどうかも怪しいという話です。
第三者が、Cookieの値を取得する。
Cookie の値を取得されたら、Movable Type に限らず大概のどんなブログ、どんなツールでも不正アクセスが可能です。(AtomAPIとログインパスワードが..とありますが、実際には Cookie を抜かれたらその Cookie を仕込んで mt.cgi そのものにログインが可能です。)
近頃の一般的なウェブアプリケーションでは Cookie によるログインのセッション保持というのをやるので、Cookie の値そのものがパスワードと同等の役割を持っています。それゆえ、(アプリケーションの欠陥で)Cookie が漏れるような事態は脆弱性と言えるでしょうが、今回の件は Movable Type に Cookie 漏洩の脆弱性が見つかったわけではないです。
Cookie を抜かれないために http から https にするとか、それはもう Movable Type の問題ではなくそのシステムを個人としてどうするかという問題ですね。
技術について詳しくない個人の方はともかくとして、メディアの人はもう少し考察してから記事を書くなりなんなりした方がよいんじゃないでしょうか。
追記
mt.cfg を隠さないとやばい、見たいな話にもなっています。確かに人に見せるような代物ではないので見えないように対処を行っておいたほうが良いとは思いますが、これも見えたからといってじゃあそのサイトが何か問題を突かれて云々かというとそういうものではないです。
mt.cgi のパスが知れてしまうと問題、という認識は間違いです。mt.cgi は普通コメントとかトラックバックとかの cgi と同じパスに置かれているのだし、HTML や rsd.xml の中身を見ればそんなものはすぐにでも分かります。そこにアクセスされたら危険というものはアクセスされないように任意の名前で隠せばセキュアという認識が間違っています。(この辺の語りは高木さんの役割かもｗ)
mt.cfg の中には、ログインに必要なパスワードであるとか、DB に接続するためのパスワード、それから Cookie の値を何らかの方法で知るための値が記述されているわけではないので、見られたからってサイトが不正アクセスの被害を被るわけではないのです。
見られたら危険、というものだったらそれを、一般のアクセスからは物理的に見れない場所におく、例えばウェブサーバがハンドリングしていないディレクトリに置くとか、それが適切な対処ですが、mt.cfg はパッケージの中ではウェブに公開される可能性のある領域にもともと置かれています。開発者側の判断は、特に mt.cfg が見られたからといって脆弱性が発生するわけではないという認識の元でしょう。見られたら気持ち悪いファイルではあるので、隠しておくに越したことはない、程度のものです。
この話に関しても Six Apart Japan の文書が誤解を招きやすい表現になっているという点は否めないですけれども。
]]>東工大の奥村研究室の研究成果である blogWatcher、その 2.0 が公開されています。なんというか、内部的に GETA から Lucene に変更されたなどの点もあるものの、外側のインタフェースが改良されていて、2.0 というより別物に近い印象。実用性を考えていろいろ変更したというのがよくわかります。
API があったり (OKUMURANK!) いろいろ面白いのですが、僕個人として一番これはいいと思ったのは、メインの blogWatcher ではなく blogWatcher の研究成果を利用して作られたなんでもRSSの方ですね。
名前のとおり(日付情報のあるサイトを)なんでもRSSに変換しちゃいますという代物で、ためしに僕が手HTMLで作っていたゲームサイト（オタい)のURLを突っ込んでみました。
その結果がこれ。正直かなりびっくりしました。HTMLをコピペしながら作ったものなので、規則性が若干崩れてるところがあったりするのに、その辺はちゃんと補正してかなり正確に記事を分割してRSSを生成しています。こりゃすげーや。
以前に東工大でblogWatcherのプレゼンを聴かせてもらったときに、その内部で利用しているコンテンツ・フィルタ (ページの日付情報やHTMLの規則性から、そのページがブログかどうかを判定し、かつデータ記事単位に分割するフィルタ) の仕組みを見せてもらって、これでなんでもRSSとか作れそうですねみたいなことをみんなでワイワイ言ってたんですけど、その成果物ですね、素晴らしいです。
早速色々使わせてもらいます。
]]>例えば、はてなブックマークは自分のブックマークにブックマークを追加するのに Bookmarklet を使うのですが、何か Bookmarklet の JavaScrpipt のコード側にバグがあったとか、機能を追加したいという場合に毎回アナウンスして Bookmarklet をセットアップし直してもらう必要があります。(今のところ、そういったことはないのですが。) ウェブアプリケーション、というかサーバーサイドアプリケーションの最大のメリットである、徐々に機能を追加していくというフローに、配布型の Bookmarklet の仕組みが合わないんですね。
それが悩ましいので、はてなブックマークの Bookmarklet は、それを実行した先でサーバーサイドのプログラムを呼び出して、そちら側になるべく機能を集中させるようにしています。
が、今日素晴らしい情報を発見。
bookmarkletを作るとき、IEでは500文字ちょい、Firefoxでは2000文字ぐらい(?)の文字数制限がある。また、作った後に一行にまとめたり、デバッグしたりも大変面倒。でもそれがとても簡単な方法でどうにでもなることをインターフェイス！インターフェイス！の人に教わった。
表題は文字数制限をなくす、ということなのですが、実際のコードは document.createElement で script エレメントを作ってやってそこで src で外部ファイルを読むようにしてやるというもの。
この方法を使えば、JavaScript のコードそのものをサーバー側に置いた Bookmarklet が作れます。素晴らしい。
Perl の O/R マッピングのデファクトは多分 Class::DBI で、Class::DBI と相性が良いテンプレートエンジンと言えば Template-Toolkit。という感じで、自然とモデルとビューに何を使うかは決まってきます。そこであとはコントローラ、というわけですが、Catalyst は主にそのコントローラの部分です。CDBI + TT なアプリケーション向けのコントローラですが、モデルやテンプレートは CDBI と TT に限定されてるわけではないので、別の組み合わせでも使えます。
と、いうことでちょっとお勉強がてらいじってみました。以下、そのメモというか解説です。Perl でウェブアプリケーション作りたいけど良いフレームワークはないかなあ、とお嘆きの方は一読していただければこれ幸い。
]]><p><a href="http://naoya.dyndns.org/~naoya/mt/archives/001682.html#more">続きを読む "Perl の MVC フレームワーク Catalyst に入門してみた"</a><p>そこで新しいのを買おうかと思いましたが、せっかくなので別の物を試してみようと思い、購入したのはこれ。
思っていたより静か
びっくり！ 値段からすれば大変お買い得以前の下敷きタイプのものではなく、ファンのものにしました。ノートPCの後部をこのクーラーに載せて使います。ファンが熱気を吸い取って側面から冷却風を流します。これでノートPCの底面が冷却されます。電源は USB から取ります。
効果の程ですが、さすがにファン付ということもあって、下敷きタイプのものよりかなり冷える。PCの底面を触ると冷たいぐらいです。ちょっとファンの音がしますが、気になるほどではないです。
PC が斜めになって、ちょうどデスクトップ用キーボードの足を立てた状態のようになるので、タイピングがしやすくなるというメリットもあります。(人によってはタイプしづらいかな?)
さくっと下に敷いて用が終わったらPCと一緒にかばんにしまえるという意味では下敷きタイプのものがよかったですが、オフィスなんか定位置で使うのであればこっちのタイプでもいいかもしれませんね。
]]>傭兵日記でyoheiさんがREST入門として、RESTアーキテクチャの解説を日々アップしています。日ごろ何気なくしている HTTP GET とかの処理が、アーキテクチャ的にはどういう意味を持っているのかとかがよくわかって面白いです。要チェック。
ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。
第5回目の今日ははてなブックマークAtomAPIを題材にPUT, DELETE, POST について解説しています。確かに、REST を理解するにはその具体例として AtomAPI の仕様を学ぶとわかりやすいですよね。
]]>これはいいと思い、早速ノートPCに導入。
coLinux は Windows の中で動く Linux なんですが、coLinux そのものはディストリビューションではなく、Windows などの OS の上で、その OS と協調して動作する Linux カーネルです。なので、coLinux を使って Linux 環境を PC に作るにあたっては、ディストリビューションを選択することができます。Fedora Core、Debian、Gentoo なんかがサポートされてます。(他のものでもイメージを作れば動くんでしょう。) 僕は Debian を選択。
インストール方法は blog.bulknews.net でも紹介されていたcoLinuxのメモ - coLinuxのインストールが詳しいです。
coLinux インストール時に TAP-WIN32 とかいう仮想ドライバがインストールされるのですが、これが素晴らしい働きをしてくれます。
ネットワーク接続の方法はいろいろあるのですが、その一つの方法でこの仮想ドライバによってWindows 側にインタフェースを追加しそれを NAT にすることができます。つまり、Windows に、既存のネットワークインタフェースに加えてもう一本足ができて片足をインターネットに、片足を coLinux 側に突っ込んだ環境が構築できると。
coLinux からは TAP-WIN32インタフェース経由でインターネットに接続できるし、Windows から coLinux へも直接アクセスできる。一方外部のホストからは coLinux にはアクセスできないので、ちょうどファイアウォールの内側にあるような状態になり、開発機にはもってこいの環境が構築できます。
ここに Apache、mod_perl、MySQL なんかを放り込んで Perl モジュールも入れて Catalyst が使える状態になりました。楽しいなあ。ノートPCを畳んでスリープモードにして、そこから立ち上げてもちゃんと Linux が動いててすぐ開発に入れるっていうのはかなり感動です。Windows内部にウェブアプリケーション開発環境を持つ、というのを Cygwin でがんばろうと思ったけど mod_perl やなんやが動かなくて諦めてたんですが、coLinux で実現できた感じです。サンキュー miyagawa 氏。
以下、メモっておきます。