mt.el with 日本語

今度こそ、日本語で post できて、 category も日本語で表示されるかな。

ということで簡単なテストもめでたく終わりました。 欲しい人はGitHub あたりから取っていってください。

xml-rpc.el もいるので、持っていってください。

Carbon Emacs 22.3.1 で試しました。ちなみにここ Cocologに対して しか試してないので、ほかのところで動くかはよく分かりません。 多分動くでしょう。ためしてみてくださるとうれしいっす。

でもなぜか新規ポストは動いても、既存のポストの編集は動きませんでした。でももう酒も回ってきたので寝ます。おやすみなさい

K-9 mailは標準 Emailよりいいけど、日本語の扱いが..

まずは k-9 Mailという Android用 mailer applicationの話から。

会社のメール環境はIMAP over SSLに SMTP AUTH with STARTTLSってのに なってます。これは、Gmailとほとんど似たような設定なので、G1標準搭載の Emailでサクッとつなげるだろうと試してみました。

でも失敗でした。

Cannot safely connect to server
(Not trusted server certificate)

なんてことを言われます。要は SSLの証明書が怪しいって言うんでしょうか? Outlook Web Applicationに https でつなげた時にはサクッとつなげるくせに! Applicationごとに証明書の検証ルーチンが違うのか?

で、エラーメッセージでググってみたら、 やはり同じことで困っている人もいる みたい。

で、その threadで発見したのが、最初に出した k-9 Mail。 なぜか forumの postでは k7になってるけど、あまり気にしない!

Downloadして設定してみたらサクッと使えました。えらい! こうやって、標準 Appの代替品がでてくるのもいいとこだねえ。 Appleだったら却下してるんじゃないか。

ちなみに K-9 mailでは本文表示中に "Next/prev message" buttonが あります。これは Gmail appになくて iPhoneにあって、欲しかった物なんだよね。 こういうところもえらい。

で、概ねめでたいんですが、日本語の扱いがいまいちのようです。

本文に (simejiとかで) 日本語を入力した場合、 UTF-8 charsetのまま、base64 encodeingされて出て行きます。 まあ、これは標準 Gmail clientでも同じだし、 MIME仕様上許容範囲でしょうが。

Subjectに日本語を指定した場合、UTF-8で plain (8bitのまま) で メールが来ます。うわ。こりゃ、 RFC2822的にいかんだろ。 標準 GMailでもちゃんと B-encodingはしてくるぞ。

でも最近は本文 UTF-8でもいいんですかね。 ISO2022JPにしろとか言うのは junet的脅迫観念でしょうか。 そんな国ごとに特化された encodingに対応するなんて 島国的作業いやだもんねえ。

とりあえず、Subjectあたりはソースを見てみようかなあ、と思いつつ、 最近の電子メールの現状を知りたくなった日でした。

Flickrのアカウントを持っていない人にそこそここっそり写真を見せる

Flikcrに写真を貯めてるんだけど、 写真に写った人だけに写真を公開したい、 でもその人たちはアカウントを持ってない。 そんなときには Guest passって 機能が使えるらしい。 日本語の解説も ちょっとあるけど、少し変わったみたいなんでさらに解説する。嫁。

Guestpassとは

特定の setに対して、ひっそり公開するための URL。 表にはでないので、そのURLを知っている人だけが見られる。

知られたくない人に知られちゃった場合にはGuestpassの管理画面から取り消すことも可能。

使い方

1. 見せたい写真を集めたSetを作る:
   Orgnizerでも 使って作ってください。
2. 公開したい Setを表示
3. 右上の "Share This"を click:
4. (メールで送られるのは嫌なので) "Grab the link"を選ぶ。
5. "Add a Guest Pass"の三つのチェックボックス(Friends, Family, Private) を全部 on
6. "GET THE NEW LINK"ボタンを押す
7. "Here's a link" ってところの URLが変わる (http://flickr.com/gp/で始まるものになる) ので、それが Guest Pass。
8. コピーしてメールで送るなりどうぞ。

要は画面の右上に集中してるので、そこら辺を注目してください。よろしく。

iZisyo更新中

好評をごくごく一部の方にいただいている iZisyoですが、 いろいろと改造 (および bugfix) してたりします。

• 表示をまともにした (単語の意味ごとに改行し、 用例はちゃんと italicにした)
• 一部の単語の発音を聞けるようにした。 単語を覚えるときは 発音も一緒に覚えないともったいないので。 WordVoxと同じフリーの音源を使っています。 たまに単語にスピーカーアイコンが出てくるのでそれをタップしてください。
• 品詞を %n とかの手抜き表示じゃなくて、 italicで表示するようにした。 これをバグだと思ってた人が何人かいたので。

そんな所です。

あとの改造予定は:

• 本文中の単語を tapしてさらに意味を引ける。
• "-" とか記号が入った単語をまともに引ける。 記号を無視して alphabetを入力するようにしたいけど、 たまにある数字入りの単語はどうしよう。 流石にこれを無視するのは usability的にどうかねえ..

てなところです。

ちなみに ソース も公開して見たので、よろしければどうぞ。

今更 iPhoneで辞書を引けるよう iZisyoを作った

iZisyoなるものを 作りました。 iPhoneむけ英英辞典のなりそこねみたいな物です。 iPhone SDKもある時代にいまさら Web Applicationですかって感も ありますが、 NDAが嫌いなんだからしょうがないって言い訳しときます。

デザインがダサいのは仕様です。 使い方とかはまあわかると思いますが、 分からなかったらコメントかメールでもください。

データはWordNet 3.0 を使ってます。 英語辞典としては力不足だけど、類義語とかがすぐでてくる (というか overviewから外す方法が分からない) ので、 英語を学習する意欲のある人にはいいんじゃないんでしょうか。

WordNetは他にも反意語とか頻度とかいろいろデータがあるので、 そういうのも表示できるとうれしい気もします。 ここら辺は反響があったりしたらやります。 なくても自己満足でやるかもしれません。

では。

Twitterで開催中のエクトリーム聖火リレーをヲチする

オリンピックの新種目、 エクストリーム聖火リレーが San Franciscoにやってくるらしい。 今日 4/9 (Wed), PDT 13:00 に始まるとか。せっかくなので見てみたいのだが、さすがに仕事でいけない。

で、twitterで sftorchさんを follow して見ています。

sftorchさんは twitterの aggregaterというか。 いろんなスネーク実況担当者が sftorchさんに messageを送るとそれをみんなに届けてくれる.. という仕組みではないみたい。 sftorchさんが followしてるひとの statusを broadcastする しくみなのか? まあ、よく分かりませんが、 San Franciscoの現状が 伝わってきて楽しいです。

PDT 11時現在だと:

rockbandit: plane overhead with message: Tibet will always be a part of China (チベットは中国の一部でありつづける、というメッセージつき飛行機が飛んでる)
joshwolf: Trains are all fucked (電車はもうだめだ)
rockbandit: police on jetskis, lots of noise: whistles, drums, horns, chanting (ポリがジェットスキーにていて、街は騒音だらけ。笛、ドラム、警笛、シュプレヒコール。)

実況写真みたいなあ、とつぶやいたら 親切にも Flickrに あげたよ と。 おれのつぶやき見えてるはずないんだけどなあ。ちなみにhttp://flickr.com/photos/rockbanditにあります。

ustreamとかでもやってるのかもしれないけど、仕事中に眺めるには logをたどれる文字情報の方がいいです。 写真も同時に組み合わせて見られるといいけど、それはむずかしいかな。

いずれにしても仕事中も色々楽しめそうです。 っていうか仕事しろ >> 俺

たしかに Amazon MP3のすごさを知らせるべき

たしかに、iTunes Storeなんか使う気がなくなります。 Amazon MP3は いいサービスだと思います。 感動して叫びたくなったんだけど、宮川さんが書いてたので、 便乗させてもらいます。

DRM Freeなのは、まだそんなに利益を享受してませんが、 かなり気もちいいものです。 それがいやでいままで iTunes Storeは避けてたし。

あと実は値段もやややすい。

例えば Nirvanaの In Uteroなんか、$6で買えるのです。 対して、iTunes Storeだと $10です。DRMつきでおまけに高い。 Jobsなんかに $4もお布施を払う気にはなれません

これで久々におれも音楽を買うようになりました。 宮川さんのように月に3、4枚も買ったりはしませんが。

あとは日本でサービスできるようになればいいですが.. iTunes Storeみたいに Gift Card買えば何とかなったりしないんですかね。

Polipoが覗く HTTP/1.1の深淵(?)を UMLGraphで解説してみる

Dolipoや Polipoが 話題になっているようで。 でもその原理になっている HTTP/1.1の仕組みとかはそれほど理解されてなさそう。 この記事 でも Poor Man's Multiplexingは飛ばしちゃってるし。

ということで、自分の思い出すのと UMLGraphの練習を兼ねて 解説したいと思います。 Sequence図の UMLGraph sourceももれなく公開という大盤振る舞いです (って、だれが喜ぶんだろう)。

HTTP 0.9

まず、HTTPの基本形とは以下のようなかんじです。

Requestがあって Responseがあるという単純なもの。 そして重要なのが transactionごとに TCPを張り直すということ。 これは、HTTP/0.9時代は responseの終わりを TCP Disconnectionで 示すという荒っぽい仕様だったためしかたないっす。

つまり、三つの tranasctionがあったら以下のようになります。

TCPの SYNや FINの時間がもったいないっすね。

HTTP/1.1 の工夫

ということで出てくるのが persistent connectionです。 これは HTTP/1.0では Content-length headerでコンテントの 終わりを明示できるのでできる技です。 HTTP/1.1ではこれが標準になってます:

絵の上からでも短くなったのが分かるでしょう。

さらに、全体の応答時間 (latency) を短くするための 工夫が pipeliningです。

絵ではちとズルをして縦幅を短くしてありますが、 Responseを待ってから次の Requestを 投げるより、Requestを立て続けに投げた方が 全体として時間を無駄にしてないのはイメージできますよね?

あともう一つ、Range Requestの話もしときます。 これは、コンテンツを頭から読み出すんじゃなくて 指定したバイトから指定した長さだけ呼び出すってもの。

たとえば PDF Pluginとかで使われてます。 Web最適された文書の場合、読みたいページに飛んだらそこの 内容だけを読み出すようにして、いらない途中のページの転送時間をかけない。 だから、PDFは Downloadして Helper applicationで読むより、 Pluginで読む方が早いはず。

でも、個人的には昔の Pluginが不安定だったり、 Pluginだと画面が狭くなるので、Helper applicationで呼んでますが。

polipoはこういう技術をバリバリ慎重に使ってる

で、こういう風な工夫がされているのが HTTP/1.1なんだけど、 実のところ積極的には使用されてないような気がします。 調べたわけじゃないので断言できないけど。 少なくとも某社のブラウザとかでは。

なぜかといえばいろいろ実運用上問題があるから。

たとえば典型的な問題に pipeline stallというのがあります。 上の sequece chartでいえば、 Response1 がすごく重い CGIで生成される画像で、 Response2 がちっちゃい静的な画像だったりします。 そうすると、Response1の生成に時間がかかってるせいで、 Response2の画像も画面に表示することができない。 複数 connectionを張っていれば、Response2はサクッと 素早く取り出せたのに。

まあ、そういうしがらみがあって、みんな保守的にやってるのかもしれません。 そこを、polipoは果敢に使える機能は使っちゃってるので いい感じに早くなってるのかも。 そして、そういう問題を回避する know howとかも入ってるんじゃ ないかなあ、って documentも読まずに想像してます。

「polipoのパイプラインについて」(わかつも) によると

polipoはサーバーがパイプラインをサポートしているか慎重に調べ(carefully probes)てからパイプラインを使うぜ

だそうです。ここら辺が肝なんでしょうねえ。

最後に Poor Man's Multiplexing

で、最後に問題の Poor Man's Multiplexingについて説明します。

でもドキュメント見ると polipoの PMMって既定値では offなんですよね。 やっぱり "an intrinsically unreliable technique" (本質的に信頼できない技巧) だからねえ。 ということで PMMは polipoの高速性にはあんまり貢献してないと思うんですが、 乗りかかった船ということで。

最初に、Multiplexingとは何かと言うと、 複数の transactionを順番じゃなくて同時に送っちゃうことです。

本来 Persistent connectionや pipelineを使っても、objectは順番にしか 取り出せないわけです。 で、 pipeline stallとかの問題が起こるわけです。

ちょっと前の (今でも?) お行儀の悪い web browserとかでは、 そこらへんは 複数 connecitionで回避してたわけです。 Operaの connectionの張り方なんてすごかった気がします。 最近はおとなしくなったんでしょうか。

HTTP/1.1 では client ごとに 2本だけの connectionにしとけよ! って 仕様にかかれていて、やっぱりこれを守りつつ multiplexしたい! というと PMMになっちゃったんでしょう。 っていういみでは、Poor Manじゃなくて、規約を守る Nice Man's Multiplexingって気もしますが。

どうやってやるかというと、Pipelining と Range requestを 駆使するんだと思います。多分。実験しないでかいて申し訳ありませんが。

Content{0, 1, 2} を擬似的に同時に取りたい場合、

1. Content0 を先頭から 1KiB だけ
2. Content1 を先頭から 1KiB だけ
3. Content2 を先頭から 1KiB だけ
4. つぎに Content0 を 1KiB目から 1KiB
5. 以下続く

って感じに Pipeliningを使ってやるんだと思います。 試してませんが。

まあ、でもこれも Content2が重い CGIだったりすると stallする 可能性は大なので、労多くして益少なし、ってことで offになってるんでしょう。

まとめ

UMLGraphは便利だけど、いまどき PSを吐くので Pngにするのが面倒です。 ここら辺、自動的にやってくれないかなあ。