2006年7月アーカイブ

以前書いたリージョンをPHP-evalするスクリプトが動かなくなってたので、修正。
EmacsでPHP-eval

リージョンの範囲指定を、"(point-min) (point-max)"で指定していた部分を、"(region-beginning) (region-end)"に修正したら動いた。Emacs22へのバージョンアップが原因?それとも、最初から間違ってた?

コマンドラインだと"php -r '...'"で実行出来るんだけど、これをEmacsから渡す方法がよく分からないので、PHPスクリプトにパイプでリージョンを渡す方法を採用。なんとなく気持ち悪いけど、動くからよし。

MTのスタイル変えてみた

いい加減、デフォルトってのも嫌になってきたので変更。
http://www.thestylecontest.com/browseからStyleCatcherで変更。

StyleCatcherから変更すると段組みが上手く表示出来なくて困ってたんだけど、どうやら"base-weblog.css"が無くなってたかららしい。MT3.3へのアップデート手順で、色々と消すように指示されてたので一緒に消してたみたい。MT3.3標準のstyles-site.cssからbase-weblog.css部分をコピーして対応。base-weblog.css部分はコメントブロックから判断。

"the Style Contest"はなんだかテーマ取得までに結構時間がかかる。大人気?

PHPで並列処理

PHP で並列処理 - 個人的なメモと備忘録より。
ちょいといじくって『出来てる』気分に浸ってみた。実際のforkとかシグナルとかは曖昧なまま。

今の仕事で『GETクエリを変更して作った複数のURLに対して、複数クライアントからの同時リクエスト』についてのプチストレステストをする事になった。で、abで『異なるURL』に対してリクエストする事が出来るか分からないし、他のツールも思いつかない。探すのも面倒だし、あまり時間もないしという事でスクリプト書いた方が早いかなと思って家で調査。

きっと、RubyとかPerlとかだと普通にマルチスレッド使えて分かり易いんだろうけど、テスト対象のシステムがPHPで書かれてるし、そのリポジトリには出来るだけPHPコードを入れた方がいい気がしたのでPHPで調査。参考にした記事が2003年に書かれたものだったので、PHP5系ではこの方法じゃなくても出来るのかも。けど、動いたし問題無さげだからこれでよし。

今日書いたコードをテスト用に修正して明日実行予定。『複数URLの同時リクエスト』って本当はどうやるんだろう?

ドキュメントをぼーっと眺めてたら、なんだかそれっぽいものを発見。
PHP: levenshtein - Manual

計算量はO(m*n)。mとnは比較する2つの文字列の長さ。

% php -r 'echo levenshtein("macbook", "powerbook") . "\n";'
5

何個か試さないと実際に使えるかは微妙な気がするけど、『すぐ使える』訳だしサンプルをとる方が、他のアルゴリズムを自分で実装するよりは楽。

まだ発見がありそうだし、もうちょっと眺めてみる予定。


Classkitとかrunkitとかに興味あり。『それRuby』はなしで。。。

(きっと)虚弱体質なので、上手に休憩をとりつつ仕事をしないと駄目な子なんだと思うこのごろ。

今の会社に入社したての頃は、アドバイスを受けたばかりだったので適当なインターバルで仕事をしてたんだけど、最近あまり意識してない気がする。ゾーンに入ったまま8時間過ごせればいいけど、そうもいかず適度に休憩を取らないと帰る頃には頭がぼんやりしてくる。いわゆる『デキル』人はそんな事無いんだろうけど。

で、どうもこのごろ肩こりがひどくて、左手の小指がしびれ気味。もしかしたら病なんだけど、睡眠時の腕の圧迫と仕事中の姿勢とかを考えると、普段の生活態度とか心構えをただす方が健全だろうと。近くの病院は総合病院だし、『紹介料』だかなんだかのよく分からないお金をとられるくらいなら、しばらく様子を見ましょう、と。

で、とりあえず以下を試してみる。

  • 仕事中の姿勢を正す
  • こまめに休憩をとって首周りのストレッチ
  • 休憩中は動く(同じ姿勢とか座りっぱなしは危険な香り)
  • 部屋でもなるべく正しい姿勢で過ごす
  • 時間を取ってストレッチ

首周りを鍛えて疲労しないようにするといいらしいので、軽いトレーニングもしてみる。季節的にちょうどいいので、プールに通う事も視野に。クロールとかよさそう。

体が悲鳴をあげてきたのに軽いショックを受けつつ、『もう年なんだ』と黄昏れてみる。生活習慣病とかを患う前に、本気で運動不足と食生活の改善に取り組まないとね。


ここ最近、バランスボールに座って仕事をしてたんだけど、このせいかも。バランスボールが悪い訳じゃなくて、机の高さと合ってないから、変な姿勢で仕事してた気がする。

文字列の近似について調べ中。
文字列の比較と照合(PDFです)

『A.4 文字列の近似照合』のアルゴリズムを参考にテストしてみようと思ったんだけど、アルゴリズム中の関数の戻りがよく分からない。挿入/削除/置換について関数が定義されてるんだけど、内部操作は予想出来てもそこからの戻りが全く分からない。多分、整数値が返ってくる事を期待してると思うんだけど、何を整数で返せばいいんだ?

文字列の近似は、2つの文字列の『編集距離』で求めるらしい事は分かった。編集距離は、片方の文字列に編集操作を行いもう一方の文字列に近づけていき、2つの文字列が等価になるまでに要した操作回数。で、その編集操作が、挿入/削除/置換。

動的計画法ってのを理解しないとスタート地点にも立てないってことか?付録だけ読んでも駄目ってこと?それともどこか別のところに書いてあるのかな?

Cのライブラリとかで探した方が早いのかな。。。

(SBMとかの)タグの類似を文字列の近似から求めようとして、その方法をググってみたら論文にぶつかった。

近似文字列照合とかなんとかっていうやつらしいんだけど、論文中の数式がわけわかんない。出てくる言葉とか記号自体は見覚えがあるんだけど、さっぱり理解出来ない。

斜め読みどころかちょっと眺めただけなんだけど、理解する気力すらわいてこない。お盆に里帰り出来たら、懐かしの教科書類をもってかいらないと駄目だ。

近似文字列に限った事じゃないけど、こういう解析手法とかで最適なものを選別してプログラム(アプリ)に落とし込めるかどうかが違いになるんだろうな。

(休みは取れそうにないけど)夏の宿題がまた増えたかも。


タグの類似は文字列の近似よりも、実際の使われ方を観察した方が精度は高いのかも。

前にも似た事をしたんだけど、またやってみた。

今日を含む過去7日分の自分のブックマークについて、'entry/rss'からブックマークしてるユーザとつけられてるタグを取得して集計。

意外とユーザでの集計は一見さんが多かった。かぶり1回のユーザだとそれだけではおすすめブックマークは取得出来ない。で、タグの方は当然、複数回出現するんだけどちょっと難しい。1つのブックマーク内で複数回出現する事と各ブックマークでの出現回数とでは意味が違う気がする。かといって、1つのブックマーク内で複数回出現しても1回と数えていいものか微妙。

とりあえず、『数を数える』だけなのでここで得られたデータから何かが出来る訳じゃない。ユーザに対する重み付けとか、タグの出現場所による重み付けとか、色々調整しないと『おすすめブックマーク』みたいな情報を得る事は難しげ。

さくっと出来そうならやってみようと思って、とりあえずでデータ集計してみたけどちょっと簡単ではないかも。重み付けの方法とか、継続的なデータの積み上げとか、本当に意味のある事をやろうとしたら、やらないといけない事はたくさんありそう。

ソーシャルブックマークでソーシャル故に集まったデータを、ユーザに上手に還元しているところはどこだろう?単純な数でのランキングもいいけど、ユーザごとにそれぞれの個性に合わせた情報提供とか出来ると思うんだけど。ユーザ行動から、提供データをパーソナライズするってのは、割と一般的な動きだよね?

このごろソーシャルサービスについてほったらかしにしてるし、久しぶりに色々見てみた方がいいのかも。(Safariに戻ったので)Ajaxがどうこうってのはあまり興味が無くて、使い続けるほどに面白いフィードバックを得られるようなサービスってのが嬉しいかも。

Googleが狙い目かな?

PEARとか使ってる場合に、パッケージングはどうするのがベストだろう。

パッケージングというか、ようはコマンド1つもしくはワンクリックでインストール(セットアップ)出来るようにするという事。

ライセンスの問題が無いようなら、パッケージ内に含めちゃった方が確実かな?セットアップとは別に環境整備ってのもめんどくさい気がする。パッケージ内(ソースツリー)にあれば、少なくとも依存関係での面倒は解消?

バージョンの問題もあるかも。いつの間にか利用しているライブラリが挙動を変えていて、それに引っ張られてエラーを吐くなんて嫌。検証済みの安定したバージョンのライブラリをパッケージに入れておけば、少なくとも想定する環境下での問題は最小限に抑えられる(気がする)。

ライブラリのバージョンアップがバグフィックスだとすると、含めない方がいいのかな。ライブラリがpearの想定するパスにあれば、アプリケーションとは別にアップデート出来る訳だし。まあ、そのバグフィックスで挙動が変わってたりすると結局アプリケーションもアップデートする事になるんだけど。

pearのインストール先をコントロールしたらいいのかな?ソースツリーに含めるんじゃなくて、セットアップツールの1タスクとして、外部ライブラリのセットアップを用意しておく。アーカイブの検出/ダウンロード/展開とか。

PHPとかApacheとかMySQLのセットアップについては、まあ仕方が無い。これをワンクリックセットアップでやるってのはちょっと色々と面倒がありそうだし。ただ、イメージなりなんなりで(サーバの)初期状態のものを用意しておいて、それをコピーしたら準備完了っていうかたちはありなきがする。最低限のネットワーク設定とかは必要だろうけど。その辺も最低限の労力で済ませられる仕組みは十分考えられるでしょう。

さて、PEARとかCPANとかgemっていうライブラリはサーバ(全体で使えるよう)に入れるのが普通なのか、アプリケーションに含めてしまうのが普通なのか。あくまで、複数の新しい環境にインストールする事がよくある場合についてだけど、どうなんだろ。

そういえば、パッケージ管理ツールへの対応ってのもあるのか。Plaggerがaptで入れられたのは嬉しかったし。

まあ、こんな場面に遭遇する機会があれば改めて考えて対応します。きっと、ケースバイケースだろうし。


明日で今週が終わる。。。終わるべき仕事は終わるか微妙。。。ある程度余裕は確保出来てるけど、変なところで時間がかかってる気がする。まあ、割とクリティカルな部分なので焦らず落ち着いて進めないとね。このごろ帰る頃には頭がパンクしそうになってて困り気味。食生活がよくないのかな。。。

ユーザ単位と記事単位で、おすすめとか関連記事とか類似記事とか。あるんだっけ?

単純に『被ブックマーク』でもいいんだけど、『このごろ追いかけてる分野』についてプッシュしてくれると嬉しいかも。別のサービスとかでこの辺提供してくれてるやつあった気がするけど、一応はてなユーザーなのではてなに期待。

とりあえず、急に欲しくなったのでメモ。

たのしいRuby予約注文

うさぎの本で勉強中なんだけどRubyで何をしたらいいのか思いつかなかったので、練習問題があるらしい『たのしいRuby』を予約。

過去に出版されてるようだけど、8/5に2版が出るとの事なのでそちらを購入予定。夏の課題です。

Ruby関係の本は買いだめ状態でまともに読めてない。言語どうこうというよりも、プログラミング自体の基礎がなってないので、そっちを集中的にやりなおしてるつもり。

まあ、プログラミング(アプリケーション)よりももっと基本的なネットワークとかの下の層からなんだけど。。。

Rubyはまだろくに勉強出来てないんだけど、なんとなく好きになれそうな予感。Railsはよく分からないけど、Rubyのスタンスみたいな所で。yieldとかなんでもオブジェクトとか。派手目で分かり易いところしか目がいってないけど、クラスの動的なオーバーライドだかなんだかも面白そう。

さて、8/5まで何もしないというのもあれなので、Web上にある練習問題でもあさってみます。


トレーニングプログラムはお金がとれるところだと思うけど、その辺無料で開放してたりすると嬉しい。あるかな?

忍び寄る魔の手

部屋のどこかから怪しい物音がします。

「ぼこん、ぼこん」

未だに原因が分からず、気の利いたジョークで切り返す余裕すらありません。

今のところ、水道管が詰まったかなんかで、水が流れる時に空気がぼこぼこいってる説が有力です。さだ子さんは旬も過ぎたので実家でのんびりしてるはずですし。

今日の帰りにコンビニでジャバを買おうとしたら見当たらず、途方に暮れながら店を後にしました。明日は駅前のスーパーによろうと思います。小さめのラバーカップでも買っておこうかな。

汚れを吐き出すとか吸い出す系はちょっと心配。さだ子さんを一本釣りしたりしそうです。『錠剤を排水溝に入れたらすっきり解決!』みたいな素敵商品があるように思うのですが、どうでしょう。

ラバーカップを右手に、なべぶたを左手に。ドラクエ気分でれっつラスボス攻略。


さだ子さんが釣れたら、説教してやる予定です。

MySQLのユーザ変数

MySQLのユーザ変数(@hoge:=var)でサブクエリの代替を、と思って試してみたけどよく分からない。

単純に1レコード(カラム)を限定する場合なら問題ないんだけど、複数の結果が返る場合はどうすればいいんだろう。配列みたくなって、"... IN (@hoge)"で出来ればいいんだけど、それは駄目っぽい。最後の結果で上書きされていく?

ドキュメントを軽くあさって見ても複数レコードを入れる場合については見当たらず。MySQL4.0でちょっと複雑な事をしようと思ったら、スクリプトから実行しないと駄目なのかな?初期化スクリプトで、とあるステータスのレコードだけを対象にしたいだけなんだけど、それをスクリプトで書こうとすると簡単だけどめんどくさい。

どうしてもやらなきゃいけない事ではない(全部を対象にしても問題ない)んだけど、簡単なやり方があるなら出来た方がベター。いっそ、その辺のサブクエリ代替処理系を作った方がいいのかな?サブクエリを見つけたら、妥当なクエリに分割して、結果を使い回してクエリを発行していく、みたいに。そっちのがめんどうかな?OSは無茶だけど、その程度なら頑張り次第な気もするし。完全な処理系じゃなくて、SQLファイルを読み込むラッパー的なもの。ありそうな気もするし、探してみようかな。

もう少しドキュメント類を探してみて、なさそうなら諦めるか挑戦するか考えます。

コピペの罠

基本だけど、コピペしたまま動くとは限らない。

PEAR::DBのセットアップ部分を、「めんどくさいから他のコピればいいや」という事をよくやる。今日も、ちょっとしたチェックスクリプトを書くだけだし、「DB周りはちょっとしたSELECTだけだから問題ないだろ」とそのままコピペ。

で、DBに格納したデータと、それを利用して書き出したファイルの内容を(ハッシュしてだけど)完全一致で比較してたら、どうも上手くいかない。色々と調べてたら、どうもファイルの終端がトリミングされてるっぽい事が発覚。

検証対象の、DBからデータを引き出したりファイルを書き出してたりするライブラリとかを遡って調べていっても、トリミングしてる部分は無い。DBをshellで見ても問題ない。BLOBで入れるとトリミングされるのかと疑って、MySQLのドキュメントとにらめっこしてみたり。

どうしようもない感が漂い始めてきたので、気分転換に喫煙。「そういえば、PEAR::DBのセットアップ周りは見てないかも」という事で、席に戻って調査再開。オプションを渡してる部分が臭かったので、何も無しでテスト。ばっちり。

原因は、移植性レベルを設定するportabilityをDB_PORTABILITY_ALLにしてたので、DB_PORTABILITY_TRIMが含まれていた事。オプション設定は頭から抜け落ちてた。

コピペの罠です。というか、「よく分からないなら使うな」という事ですね。実は、終端文字のトリミングは割とよく引っかかってたり。Emacsで書いてると、最後が改行で保存されるのか編集中の見た目だけなのかよく分からなくなったりします。頭がぐちゃぐちゃになってる時にこれになると、shellで表示してプロンプト表示が崩れたら最後の改行がないんだ、と力技。

全体に影響がある挙動を設定1つで賄えるのは便利なんだけど、そこをちゃんと押さえておかないと無駄な労力大爆発という教訓。フレームワークとか触るの怖い。。。

Railsのページキャッシュ

動的生成は最初のリクエスト時か内容が更新したときだけ。後は、生成時に作られた静的なファイル(キャッシュ)にアクセスするようになる仕組みらしい。

相変わらず、負荷分散がよく分かってない状況なんだけど、キャッシュ機能の仕組みの1つとして覚えておかないといけない事だと思ったのでメモ。

今抱えているタスクがちょうど、動的に表示してるコンテンツを静的なファイルを作る事で、サーバの負荷とかサーバダウン時の弊害回避に対応しましょうという感じのやつ。で、「こんなやり方もあるよ」と教えていただいて、『これまでの苦労は。。。』と。

ひとまず、ページキャッシュを実装するのは見送りになって、今のやり方で進み続ける事になった訳だけど、スマートなやり方じゃないのかも。コンテンツリクエストに関して、完全に動的生成を排除すべきか、1回くらいは許してもいいのかというところで線引きがあるかな。

プログラムへの要求に対して、サーバが(プログラムを触らずに)キャッシュを利用するかどうかってのも設定次第でできるんだっけ?サーバいじる必要があるから、フレームワーク側で完結する仕組みの方が使い易いってことかな?

そんな感じで、割と黄色信号な状況です。

PHPのSSH2関数を使ってみた

ちょいと、実行権限に引っ張られて出来ない事があったので、この際SSH使おうかという事で。
PHP: Secure Shell2 関数 - Manual

SSH2関数を使うためには、拡張モジュールのインストールが必要。で、この拡張はまだPECLにあって、安定板の提供はまだらしい。インストールはドキュメントそのままで、特に困った事はなし。手元の環境では、PECLモジュールをpearでインストールできないので、peclコマンドを利用。それ以外では、出来上がったssh2.soをコピーする必要がなかった事かな。必要に応じて、要求される場所にコピーしたらよし。

ログインしてコマンド実行まで、ひとまずドキュメントを見ながらこなせた。戸惑ったのがコマンド実行時の戻りの処理。streamで戻ってくるということで、freadとかで読み取る必要がある。ファイルは触るけど、ソケットとかほとんど使った事がなかったのでいい勉強になった。STDIOとSTDERRを分割出来るようなので、エラー処理もその辺でやればいいらしい。

SCPとかSFTPの関数も用意されてるけど、基本的にログインとコマンド実行が出来れば問題ない気がする。ので、ここに書いてあるクラスを参考にしたらいいと思う。パスワード認証を許可してない場合は、公開鍵とかホスト公開鍵とかでの認証関数を利用する必要があるだろうけど。

今回は必要がなかったので、使ってないんだけど対話式のシェルも扱えるらしい。ターミナルの種類とか幅とか高さとか設定出来るらしい。ブラウザでリモートほげほげとかこの辺を使ってるのかな?(PHPじゃないにしてもね)

SSH2拡張はPECLのβ版ということで、なんでも出来るのかといわれるとどうなのか分からない。とりあえず、必要な処理を手元の環境でこなせればいいのかな、と。

SSH2拡張を触ってみて、ソケット処理(?)を勉強しないといけないなという危機感を覚えた。ソケットとか使えるようになれば、簡単なデーモンとか書けるようになるかな?デーモンはCとかで書くべき?

出来るらしいです。採用目的も兼ねるようです。

ここでは、何も気にせず突っ走ってる訳ですが、『会社の』という事になると筆が進みそうにありません。

最近では勉強会でもろくなネタが思いつかず、担当の日が来てもお茶を濁して終わってしまってます。

全く参加しないというのも寂しいので、何かしらのかたちで参加したいとは思いますが、下手な事書いて『あの記事見たら働く気無くすよ』という事態を招きたくないのでこっそり活動する予定です。当たり障りの無いコメントがベストでしょうか。『それPla』とか。

サービスの開発候補ネタとかで皆様のやる気を煽る記事とか書いたらいいのでしょうか。技術方面じゃなくて、マーケティング方面になりそうな予感がします。競合にすっぱ抜かれる悪夢?

まずは、『サルでも書けるきれいな日本語』とか探して勉強しないと駄目ですね。手書きじゃないのがせめてもの救いです。。。

validなFeedとwell-formed XML

xmlnsを利用して、Feedを拡張した場合、validatorにvalidじゃないと怒られる事がある。

個人的に、「だからどうした、読めればいいだろ」と思ったりもするんだけど、validatorを利用してエラー処理をしてるFeed処理系とかがあるとまずい。メジャーなフィードリーダーはその辺ゆるめだよね?少なくとも、ブログフィードでよく利用されてるFeedburnerをはじくような事があるなら、結構大々的に取り上げられてるはず。なので、きっとvalidかどうかは問題じゃないんだと思う。

以前どこかで、『IE7はwell-formed XMLしか読まない』といったニュースを読んだ気がするんだけど(IE6もそう?)、well-formed(整形式) XMLである事とvalidなFeedである事はイコールじゃないよね?Feedのvalidatorがどうやって実装されてるのか知らないんだけど、あれはFeedの各仕様に沿って判定してるんだよね?

Feedが有効であるかどうかを判断したい場面は結構あって、その時に何を使って判断するかはちょっと考えた方がいいのかも。個人的に、『仕様に沿っているかどうか』よりも、多くの処理系で『必要な情報を正しく読み取る事が出来るか』が問題なんだと思う。なので、well-formed XMLであればいいんじゃないかと思う。(RSS2.0の場合)item内にtitle,description,linkがあるかも知りたいけど、無きゃ無いでデフォルトで埋めても何とかなるし。

この辺の認識ってどんな感じで同意されてたり共有されてたりするのかな?ひょっとして、かなり恥ずかしい事を今更考えてたりするのかな。

『Feedはサマリ情報であって、RSSとかの規格は関係ない』みたいな事は一般的(?)だと思うんだけど、それを考えると『Feedを利用するアプリケーション』を作る場合は『妥当な体裁』を保てていればよしとしていいと思う。勿論、RSSという規格ありきの『厳密性』が大事である場合は、ちゃんと仕様に沿ったvalidatorを通すべきなんだとは思うけど。

けど、『折角仕様を決めたんだから、それは守りなさい』という気持ちもあると言えばある。HTMLみたいに、ブラウザのベンダごとに独自仕様が作られて混乱気味の世界がある訳だしね。

RSS/Atom用に作られたparserライブラリの事も考えないと駄目なのかな。これがvalidであるかどうかを前提に実装されてるなら、validである事にこだわらないといけない。けど、RSSにしろAtomにしろ、parserは受け取るデータをXMLだって解釈するよね?きっと、libxmlだかなんだか辺りを奥底では使ってる気がする。それであれば、結局well-formed XMLであれば問題は無いんだよね?文字コードの問題は別として(well-formed XMLと関係あるのかな?)。

というわけで、会社で『それvalidじゃないよ』ツッコミをいただいて、validじゃない場合の影響がよくわからくなってたので頭を整理してみました。validatorに怒られるのは気持ちいい事じゃないけど、『大概使える』のであれば問題ないというのが結論でいいのかな?


補足ですが、『フィードリーダーで読み込むデータはwell-formed XMLであれば何でもいい』という話ではありません。あくまで、標準化されたデータフォーマットの利用が前提です。ただ、原則として仕様には従うけど、多少余計な(validじゃない)要素が増えてても対応出来る事が現実的だよねという事を確認しましたという話です。

追加で、ちょっと気になったのですが、is_validでなくて、レベルを返すfeed用validator(tester?)ってあるんでしたっけ?

$level = array('valid_xml_feed' => 0, 'well_formed_xml_feed' => 1, ...);
if (xml_feed_test($xml_feed) <= $level['well_formed_xml_feed']) {
    ....
} else {
    
}

適当ですが、上の様な感じで妥当とするレベルで処理を判断したらやり易いかな、と。きっと知らないだけでもっと適切なものがあるんでしょうね。
あまり気にする必要はないと思いますが(アプリケーションが処理出来れば問題ない)、『妥当なRSS/Atom(well-formed Feed?)』という判定が出来合いのサービスやライブラリで出来るなら、名前だけでも知りたいかな、と。

Googleをさまよっていると、どうもRSS parserのエラーメッセージが目につきます。『... not well-formed XML ...』。一般的なRSS parserでは、well-formed XMLであれば処理しますというスタンスという事でしょうか。


Perlでは、XML::LiberalというCPANモジュールを利用すれば、well-formedでないXMLも扱えるらしいです。

マイヘルプ

ブックマークだとかBlogだとかWikiだとか、自分で切り抜いたり書いたりしてきた事を、お気に入りのエディタとかから検索して取り出したい。

Spotlightを使いこなしたら、問題なくなるのかな?

そろそろSafari

Firefoxにも飽きてきたので、Safariに戻ってみる。なんか新鮮。

何も設定しなくても、フォーム内をEmacsライクに操作出来るのが嬉しい。バックスペースとかでいじったかもだけど、まあそれはそれ。CocoaGestures使えばマウスジェスチャーも使えるし(戻る、進む、タブ開く、タブ閉じるについては無意識に手が動くので)、SafariStandとかSIBMLプラグインを使えばちょっとした事は出来る。

ユーザスクリプト(Creammonkey)でどこまでできるかは知らないけど、まあそれっぽい機能も提供されてる訳だ。最近、Safari用にJSのDebugg環境も提供されたとかなんだとか(βだっけ?)。

GMailも問題なくSafariで動くようになってたみたいだし、とりあえずは大丈夫っぽい。まあ、細かいところでは色々ある気がするけど(JS使いすぎアプリ関係ね)。

さて、いつまで続くかな?

会社PCの整理(予定)

さくさく動いて気持ちよくお仕事をしたいので、少しずつ余計なアプリを削っていく予定。

とりあえず、社内SNSのRSSを読むために起動していたGoogle Desktop(Sidebar)を削った。デスクトップ検索はしないし、他のモジュールも今の所不要。RSSについては、日記/コメント/コミュニティをひとまとめにしたRSSを吐くスクリプトをこっそり仕込んでおいたので、それをThunderbirdで購読中。

ブラウザも軽いものに変えようか検討中。開発の検証+デバッグ環境と普段使いとを分けるのが面倒だったのでFirefoxを使い続けてるんだけど、メモリ馬鹿食いが気に食わない。ただ、Greasemonkeyとか拡張とかは捨てがたいので、今のところ代替案無し。まあ、再起動したり最小化したりでメモリは解放出来る訳だから何とかなると言えば何とかなる。ver2.xに期待して使い続けましょう。

常時起動アプリは、Thunderbird+Firefox+Poderosa(Cygwin,coLinux)+Explorer(SVN)+Emacs+coLinux。常駐させているのは、Bluewind+XKeymacs+Multimonitor Taskbar+Norton。これ以上どうやって削ればいいんだろう?余計なサービスを探して止めるかな。

暇を見つけて、ちょっとずつWindows Service当たりについて調べつつ余計なものは消していくのが妥当かな。とりあえず、アプリが動いてウィルスに感染しなければそれでいいし。ネットワーク周りで不具合でなければ問題ない気がする。

あ、PoderosaをPuTTYとかに変えたら軽くなるかな?でも何か不満があってやめた気がするんだよね。なんだっけ?タブ周りだったかな?screenを使いこなせないで挫折したのかも。

Thunderbirdも変えた方がいいかも。Firefoxほどこだわりはないし、これまでのメールを引き継げれば問題ない。軽くて適度に便利なメーラー探してみようかな。

まあ、少しずつ進めます。

切羽詰まってきたので、MySQLの勉強中。

パフォーマンス周りで色々気になりだしたので、PHPのPDOを試してみる事に。ひとまず自宅サーバのDebian環境でテスト。
koshigoe hiki - [PHP]DebianにPDOをインストール

よく分からないけど、aptitudeでのMySQLインストールの影響か、PDO_MYSQLのインストールが上手くいかない。色々Webをあさりながらどうにか解決。

PDOはCベース(++だったかな?)らしいので、PEAR::DBより確実に高速らしい。PHP5.1.4+MySQL5.0.22で動く事が確認出来たので、これから家で書くPHPではPDOを我慢して使ってみる予定。

PHPからRubyに乗り換えようと思ってたんだけど、しばらくはPHPが続きそう。Ruby本読む前にMySQLとか他のもっと必要な部分を身につけないとね。言語は後回し。インフラ(って言うのかな?)を押さえておかないと、どうしようもないわ。

ネタが分からない、、、。どこで笑ったらいいですか?

~$ sudo aptitude help

↑を打ったら最後に出てきました。

OSXのFirefoxでCommand+k(検索フィールドのフォーカス)が邪魔されませんか?

Firefoxの変なとこいじったかな?

枇杷完食!

しました!

そういう場かどうかは別として、フィードリーダーと組み合わせてディスカッションアプリとして使う事を整理してみたり。

はてなブックマーク+LDR+Greasemonkey(Bookmarklet)で考える。

まず、はてなブックマークユーザーで、Livedoor Readerユーザーで、ユーザースクリプトを使える程度の知識はある事が前提。

次に、利用の流れ。

  1. LDRにはてブ登録ボタンを追加する(多分Greasemonkeyであるはず)
  2. LDRにはてブ個別EntryのRSS購読ボタンを追加する(↑Greasemonkeyをいじれば出来るはず)
  3. LDR上でコメントとスレッド追っかけのためのUIが揃った
  4. ついでに、LDR経由じゃない場合も考えて、2つのUIをBookmarkletとかでも用意しておく。
  5. 発言は、はてブ登録で行う
  6. スレッドの追っかけはLDRへの登録で行う
  7. 発言せずにLDRで追っかけだけしてて、発言したくなったらはてブ登録して発言

で、問題点。
まず、ディスカッションとか言いながら、ブックマークの性質上発言は1回だけ。こりゃ盛り上がらないね。読まれてるかも分からないし。オーナーの側に反映されないのも問題かも
あと、LDR登録UIがフォルダ登録まで出来ないと面倒。まあ、未分類を『揮発性』であると考えればそれでもいいんだけど。bookmarkletに書いてある登録URL叩いた場合は、フォルダ登録も出来たね。
発言の場合、『もの申す!』タグとか標準で入力欄に入れておいた方がいいかも。そしたら、そこからまた広げられるかも。
一番の問題は、はてブでのコメントがなんだか嫌われてるっぽい事かも。

というわけで、使えそうも無い小ネタでした。


antipop - livedoor Reader から、ショートカットキー一発ではてなブックマークにぶくまする greasemonkey スクリプト
↑で、LDRからはてブは解決。
あと、↑を参考にショートカットからはてブ個別エントリのRSSをLDRに登録するGreasemonkeyも適当に書いてみて試用中。
ショートカットキーは適当なキーが思いつかなかったので、eを利用。
しばらく使ってみてつまらなければやめる予定。

Atomでのスレッドフィード

今のところ、インターネットドラフトの模様。
元ネタ:IBM dW:XML:Atom 1.0の拡張機能、第2回:著作権ライセンス、リンクの… - Japan

メールヘッダについて勉強した方がいいのかな。スレッドツリーをどう実現するのがスマートなのかよく分かってないので、ちょっと遊びで実装するにしても、変な風になりそう。

気になる記事のURLを入力して、スレッドRSSを発行するサービスってあるかな?とりあえず、はてなブックマークでのコメント(被ブックマーク)状況を追いかけてみたい。LDRに登録して、『観戦中』フォルダに放り込んどく感じ。

、、、よく考えたら、個別エントリのブックマーク状況もRSSで出してるね、はてな。残念なのは、通常ブックマークのRSSとは連携がとれてないところか。まあ、標準化されてない拡張とか下手に使っても、フィードクライアントが対応しづらいかもしれないし、こういう時はGreasemonkeyかな。探したらあるだろうか。

と、1日経ってみると色々勘違いしていた事がぽろぽろと。


はてなブックマークのエントリRSSをLDRに追加するBookmarkletでしばらく試用。
HB-e2LDR ちなみに、LDRで用意されているFirefox用をもじっただけです。


ポストURLもブックマークボタンでいい訳だし、はてブのリーダー上でのスレッドフィードは意外と簡単かもね。需要の有無は別だけど、、、

枇杷食った!

冷蔵庫でヒンヤリしたところを、ガブリと。

食べきれなそう。。。

メールと RSS

くどすぎるけど、前のエントリのフォローの続き。

例えば、私はメールをやめようと言ったんです。
ブログを核にリストラしたライブドアのポータル戦略 - CNET Japan

ドリコムコンテストを眺めつつ上の記事を読んだ印象から、RSS活用方法をもう少し進められるのかなと思って書いてみました。ただ、記事内でのメールからRSSというのは、どこまで本気なのか(サービスインまでの絵があっての発言なのか)よく分からないので、ここで書く事は記事に対する反論とかではないです。記事をきっかけに考えてみたというだけ。

メールは携帯ユーザを考えると、完全になくなるとは思えない。携帯を切り捨てるような形になると、フォローの仕方次第で不満噴出な状況になりそう。まあ、Lのメールユーザがどんな感じかは分からないんだけど。メールやめてもメール送信は出来るのか?

ただ、場面によってはRSSベースにする事は有効だと思う。POPサーバ同様に、RSSサーバ(仮称)が一般的になれば、ウェブアプリ内でのメール機能置き換えは十分考えられる。メッセージのやり取りとスレッドの追跡、アーカイブの取得などなど。RSSで十分可能。スパムはブログコメントでも問題になってるし、メールサーバほど対応策が練られてない分危険かも。あと、RSSは公開が前提なので、下手すると個人情報垂れ流しの危険性もある。上手く実装しないと、RSSの利点を十分に生かせないかもしれない。ユーザーに管理能力を期待しちゃ駄目だろうし。

メールじゃ駄目な理由を分かり易く理解してもらって、同時にRSSを使う事のすばらしさをアピールする事は出来るかな?スパム被害ってだけじゃ、弱いと思う。というか、『スパムをどうにかする技術を考えろ』という人が多いんじゃないかな。新しいよく分からないものを使うよりも、今使ってるアドレスでつながってるネットワークを使い続ける事の方が重要でしょう。そこにスパムが来ても新技術が出来るまではコツコツ削除すればいい。ウィルスは怖いけどね。RSSにしたらウィルス被害が無くなる?添付ファイル機能を用意したら大して変わらないんじゃないかな。

まあ、コスト的に継続する事が見合わないという場合は、考える価値があると思う。けど、インフラとしての置き換えは簡単には出来ないだろうな。携帯電話の会社を変える時の最大の障害は、電話番号が変わるということ。これは、いつだかに実施される新制度で解決されるけど、メールとRSSとの置き換えを考えた場合は、メールアドレスを継続して使う事は難しいよね。中継サービスとか上手く使って解決出来るのかな。

メールをRSSに変えて購読する事が出来るサービスはある事はある。IMAPをRSS変換だったか、RSSをIMAP変換だったかうろ覚えだけど、多分ある。メールをRSSとして受け取るためのラッパーは、結構ありだと思う。

1サービスとして、RSSを基盤にしたメール代替を狙えるメッセージングサービスを提供する事はありだと思う。けど、インフラレベルで置き換えを狙うための戦略は全く思いつかない。この辺も考えてるんだろうな、Lの人は。2、3日頭の中身貸してくれないかな。。。

久しぶりに、色々と考えた1日でした。

スレッドRSS

1つ前のエントリで書いた事をちょっと手直し。くどいですが我慢してください。

特定の話題の流れを追いかける場合、コメントを含むアイテムからなるフィードよりも、1つの話題が1つのフィード(1書き込み1アイテム)で表現される方がいいかもしれない。1スレッド1RSSという言い方が正しいか分からないけど、多分そんな感じ。

例えば、トピックをまとめたフィードを購読していて、1つのトピックについて流れを購読したい場合を考える。この場合、トピックアイテムの中にスレッドRSSのURLが含まれていて、購読アプリ側で流れを切らずにそのスレッドを購読出来るとよろしい。トピックアイテムにはスレッドIDを含めておいて、購読アプリ側でスレッドエンドポイントと組み合わせてスレッドRSSのURLを組み立てる方法もあるけど、購読アプリに余計な知識/労働が必要になるのは微妙。

コメントアイテムを見た時に、そのコメントが属するスレッドRSSのこれまでのコメントログを引っ張れると嬉しい。コメントアイテムにもスレッドRSSのURLを含めておいて、それをキーにコメント群を抽出する。ログはクライアントにキャッシュされているかもしれないし、サーバに問い合わせる必要があるかもしれない。キャッシュデータベースの仕組みが必要かも

ただ眺めているだけでも面白くない。ログを眺めていれば発現したい場合もあると思う。その場合、購読アプリが書き込みUIを備えていれば、その場で発現可能。ただ、フィードが最新でないと変な流れになるかもしれないので、購読の際にはフィードをチェックアウト。APIを公開する形になるので、スパム対策も必要。認証APIかな。

フィード配信側

  • スレッドRSSの発行
  • 書き込み用APIの提供
  • 認証APIサポート
  • スレッド問い合わせAPIの提供
    • 特定スレッドの取得
    • スレッド検索
    • コメント検索
    • 検索結果をまとめてフィードを作る
    • 書き込み履歴からレコメンドフィード
    • ...

クライアント側

  • スレッドRSS取得機能
    • トピックアイテムから抽出
    • コメントアイテムから抽出
  • ログ取得機能(スレッド問い合わせAPI)
    • スレッドRSSのURLから取得
    • 条件指定によるスレッド/コメントの取得
    • ...
  • 書き込み機能(書き込みAPI)
  • 認証APIサポート
  • 購読切り替え機能(追いかける/放置する)

具体的に

はてなブックマークでコメントがつく様子を眺めたい場合があったりするので、フィードを購読する流れと連動して欲しい。で、コメントが落ち着いてきても『購読を解除』するのはちょっと違う気がするので、『放置する』ステータスを作って流れを止めたい。ただし、裏ではデータは保持されていて、いつでも引き出せる仕組みも欲しい。はてなを名指ししてるけど、類似のソーシャルなコメント付きサービス全般の話。

Web APIとAjax UIを上手く連携させれば、既存の共有フィードリーダーに組み込めると思う。スパム対策とか認証サポートがネックかな。

MT+TypeKey+Plagger+LDRでなんとかならないものかな?書き込みUIが問題になりそうだし、クライアントはGoogle WidgetとかのWidgetが妥当かも。IMっぽいUIで。ログをデスクトップでたれ流したい場合はWidgetがベストかもね。

書いてみたけどもうあるよね?

自分のコメントが含まれるエントリを登録して、その流れを追いかけるサービスはあった気がする。ドリコムコンテストにもそんな感じのがあったし。でも、コメントをしなくても追いかけられた方が楽しいよね?それも可能なのかな?ただ、一連の作業を1つのアプリケーションで完結したいし、それはフィードリーダーであるべきだと思う。『リーダー』という呼び方が正しいのか分からないけど、まあ今そう呼ばれているアプリケーションという事。

しつこいですが

こんな感じのサービスをご存知の方、ぜひ教えてください。フィードパスだかなんだかでこういう事もサポートしてるんだっけ?

とりあえず一覧を眺めただけです。18作品というのが、多いのか少ないのか妥当なのか、判断出来ません。

で、今ちょっとネタを思いついたので、メモ。作りません。きっと、もうあるだろうし。目新しいものでもない。

最近、社内でSNSを利用中というのは前から書いている事なんですが、SNSのフィードでコメントも対象にしています。この『原則、書き込み全てをフィードで出す』というのが、結構当たりかな、と。

スパム被害を受ける場合、管理コストがネックなんですが、閉じたコミュニティで、議論ベースの運営を行う場合、議論のログをフィードで出す事は有効なのではと思ったり思わなかったり

さらに、XML-RPCとかを上手く使って、フィードリーダーを入り口にコメント(反応)出来ると楽しいかも。チャットとかIMほどの即時性は必要ないけど、気がついた時に反応出来て、購読者全員でログを共有出来る。

技術的には今すぐ作れるものだし、ネタ的にもだいぶ枯れてる(?)とは思うんだけど、これを社内コミュニケーションツールとして導入する事はあまり考えられてないかも?OpenPNEのAPIにXML-RPCがあった気がするんだけど、あれってダミー?使えるなら、RSSのアイテムに上手くURL埋め込んで、それに対応してくれるクライアントを作ってもらえばいいのかな?いや、作りませんよ?

こんな事を考えたのは、Google Sidebarでフィードを表示してる時の、更新の仕方がちょっとチャットっぽいな、と思ったからです。チャットとかIMは上司に怒られたとしても、RSSリーダーなら怒られないよ!多分。

RSSの仕様としてコメント機能を用意する必要はありません。必要なのは、書き込みを受け付けるAPI(XML-RPCとか)と、その入力UIとポスト処理に対応したRSSリーダー。吐き出すRSSでは、APIを叩くためのURLだけ書いておけばいい。そのURLを書くために、RSSの拡張仕様を使う必要はあるかもだけど、新しいAPIとかを作る必要は無いはずです。きっと、Atomでやると素直に出来る。

と、思いつきかつ未調査でメモ。こんな感じのオープンソースなツール知ってたら教えてください。こっそり社内サーバに仕込んでみます。

枇杷来た!

先日、実家より送ったとの連絡あり。本日21:00頃、無事届きました。

特産品がある地元両親サマサマ。

小箱でこんもり送られて食べきれるか心配です。

ただいま冷蔵庫で待機中。

QuicksilverのSubversion Plugin

QuicksilverのSubversion Pluginを使って、svnを使おうと思ったんだけど、なんだかpython周りで失敗してる模様。
quicksilver:plug-ins:subversion [docs]

~/Library/Application Support/Quicksilver/PlugIns/Subversion Module.qsplugin/Contents/Resources/pipeSVN.python
まず、pythonが入っていなかったようなので、Darwinportsでpythonを入れてみて、1行目の"#!/usr/bin/env python"を"#!/opt/local/bin/python"にしてみたけど駄目。

Finder用のプラグインも活用出来てないし、OSXではTerminalで使えばいいかな。Quicksilverをアップデートしてちょこっといじってたら見つけたんだけど、使いこなしてる人いますか?

なんとなく、HTTPS+Basic認証で落ち着きそうな気配があるけど、ケースバイケースではあるのでちょっとメモ。


予測困難なURL

ランダムな文字列をフィードのURLにする事で、そのフィードの存在をある程度隠す事が出来る。URL自体が認証情報となるので、このURLが漏れた段階でアウト。
適当なタイミングでURLを変更し、古いURLを無効にする事で安全性の向上が図れる。
クライアント側で特別な実装を必要とせず、またサーバ側でも実装の負担は小さい。
フィードURLの管理次第で簡単に情報漏洩してしまうため、ごく軽微な被害(心理的にちょっと困る)で済むケースでのみ利用可能。

HTTPS+Basic認証

Webのアクセス制限として一般的な方法。
広く利用されているため、サーバとクライアント両者にとって実装の負担が小さい。
メリット/デメリットについては、一般のWebアクセス同様。
購読者(アクセス許可ユーザ)の数だけフィードへのアクセスのための認証情報が必要になるため、管理コストは高め。全ての購読者に対して同じ内容のフィードを配信する場合は、多少コストは下がる。
場合によって、ユーザ情報ごとに処理が必要な場合は難しい場面が登場するかも。

HTTPS+WSSE

AtomPPで利用されている認証方法。
一般的ではないため、クライアントとサーバ両者にとっての負担は小さくない。
これからフィードを配信するサービスがすでにユーザ認証機能を備えている場合、その認証情報と連携がとれるため、認証後に処理何かしらの処理を行いたい場合には有効かもしれない。
ただし、サービスを利用するための認証情報を外部サービス(アプリケーション)に教える必要がある事に注意。

HTTPS+認証API

認証のための外部サービスを利用する。
認証処理を実装する必要は無いが、クライアント側での認証の要求処理とサーバ側での認証結果に基づく応答処理は必要であるため、両者の負担は小さくない。
認証APIの実装次第で、クライアントが上手く実装出来るか決まる。
フィード配信側でのユーザ識別が難しいため、購読者ごとに内容を変えたフィードなどを配信する事は難しいかもしれない。

フィード自体の暗号化

PDFの様に文書暗号化技術を利用する。
"鍵"を持っていなければ複合出来ない。
サーバ側では安全な暗号化処理の実装が必要となり、クライアント側でもその複合化処理を実装しなければならない。
現実的に考えれば、個人環境での利用に限定される。Webアプリとして提供されているアグリゲータサービスでは、鍵の管理や暗号化/複合化処理の問題を解決する事は難しいかもしれない。
また、アイテムURLを暗号化文書(PDF)のURLとし、その暗号化/複合化は既存サービスを利用する。


どの方法を選ぶかは、ケースバイケース。購読者を制限したいだけであれば、何も考えず上2つを選べばいい。有名なフィードリーダーであれば、きっとBasic認証をサポートしている。ただし、ユーザ視点として共有型のリーダーサービスを利用している場合は注意が必要。登録したURLは原則として他のユーザーに漏れていると考えた方がいい。また、サーバに認証情報を教えているという事も考慮する必要がある。

課金フィードを提供したい場合、『フィード購読者の多くは共有型のリーダーサービスを利用している』事を頭に入れておく必要がある。このケースで考えると、情報が漏れて困るのは提供側。全ての購読者がセキュリティについて慎重だとは限らない。独自の認証処理とリーダーをセットにして提供する事が望ましいかもしれない。もしくは、フィードのアイテムURLを暗号化文書のURLにする事を考える。

SNSの更新情報など、利用者によって内容が異なる種類のデータをフィードで提供する場合は、認証処理後のユーザ別処理を簡単にする事も見据えて考える必要がある。既存の認証方法と情報を使い回す方が管理コストが低くなる可能性がある。ただし、独自の認証方式を導入すれば、クライアントが対応していない可能性が高くなる。Widgetなど独自のクライアントアプリケーションを提供出来ないのであれば、一般的なクライアントでの実装方法に合わせた選択をせざるを得ない。


と、意味が分からないメモを続けた訳だけど、勤め先でこの辺を導入しようとした場合はどれが妥当だろう。(フィード発行サービス)

まあ、フィードごとに1つの認証情報を用意するしか無いだろうね。Basic認証で。ああ、強制HTTPS通信も。配信処理の中で認証処理をサポートするのはサービスの形態的に現実的でない気がする。

仮に、複雑な処理が必要になってBasic認証では捌ききれない場合、それは『課金フィード』みたいな別サービスとして用意した方がすっきりしそう。フィード管理周りは今のサービスで統合出来る仕組みを作って、細かいところはそれぞれの別サービス側で実現した方が現実的かもしれない。

今のところこんな感じで理解してます。セキュアフィード。

カテゴリ整理

タグが使えるようになったので、カテゴリを縮小するのが目的。

エントリとカテゴリ、タグが一致してないかもしれないけど、それは一括処理したりして対応したので、その辺は気にしない方向で。

めんどくさ。。。

プロフィール

このアーカイブについて

このページには、2006年7月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2006年6月です。

次のアーカイブは2006年8月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。