2008-09-01 [長年日記]
_ emobile生活始めました
つってもいつもパソコン持ち歩いて移動しまくってるわけではないので、普段と違う環境に行ったとき用なんだけど。
モノは D11LC ブラックで、もうすぐ 7.2Mbps 版が出るんだけど、すぐ欲しかったのでしょうがない。（端末代もべらぼうに安かったし。）
気になるスピードは、金沢市の街中（長町）では 1.2Mbps 出たんだけど、鞍月のビーンズでは 240kbps 止まり。時間帯はよく似たもんで、いわゆるプライムタイム？ エリア的にはどちらも余裕なはずなので、スピードにバラツキが出たのはちょうどいい具合に基地局との距離にバラツキが出たからなのかな。ADSL じゃないんだから距離は関係ない？ どういう条件でスピード変わるんだっけ。
1.2Mbps で使ってると「おぉ、結構はぇーなぁ」という感じなんだけど、さすがに 240kbps になってくると最近のWebサイトの読み込みにはつらいかもしんない。使えなくはないけど、次々クリックして読んでいくにはちょっとつらい。prefetch の機能があるならそれを有効にしておくとまだなんとかなるかな？って感じ。個人的にはそこまで試してないのであくまで予想だけど。
ところで最近 Twitter ばかりで落ち着いて日記を書けない。もっとも、irc とか Twitter はやってるので絶対的な時間不足ではないはずなんだけど、やっぱまとめて書く時間て結構貴重なのだなぁと思っているところ *1。だから最近は irc や Twitter のログをひっくり返してあとで整理し直すことがよくある。結構便利。
ほんとはネタを書くだけでなくライフログとしてもっと使っていきたいんだけど、いったんペースが落ちると「忘れたくない優先度」が日常生活よりも技術ネタの方に偏っちゃうんだよな。
あ。
もしかして日常は忘れたくなって来ちゃってるのかねぇ。そりゃいかんなぁ。
*1 逆か。Twitter とかやってるから集中する時間を長く持続できないのか。
2008-09-02 [長年日記]
_ Yapra で吐いた feed を実際に購読する前に
前回からまたずいぶんと空いてしまったけど、気になっていたことをひとつ。それは
吐いた feed のタイムスタンプは必ず更新されてしまう
というごく当たり前の事実。
これの何が問題かっていうと、できた feed をそのまま Web に公開すると、必ず Etag が変化してキャッシュが効かず、結果、feed を生成するたびに更新扱いになってしまうという点である。
要するに feed reader 上で更新されたものしか表示しないようになっていても、内容に変化がないのに必ず更新されましたよ、と顔を出してくるということである。
これが邪魔だ。
解決方法を考えたけど、アプローチは二つほどありそうな感じ。
- feed を吐く際に既存の feed をキャッシュとして活用して内容に変化がなければ生成し直さないようにする
- 吐いた feed を直接公開しないで、公開用の場所にダイジェストで確認しながらコピーを行う
1 は要するに Yapra を直すという話で、これが可能ならスマートだなぁと思ってはいる。特にキャッシュとして使う辺りは生成した feed のタイムスタンプが変わるか変わらないかよりも大きな話で、これが実現可能なら例えば EFT でも無駄に同じエントリを再取得しなくてよくなるかもしれないと思っている。
2 はそのままの話で、例えば rsync なら --checksum だし、sitecopy なら state checksum というパラメータを追加してやればよい。
当面は 2 かなーと思っている。思いついたのは数日前で、ここの FreeNAS の feed の転送の設定を変えたのは今日のことなので、明日の昼に更新通知がこなければオッケー。
というかこの辺、Plagger の人たちはどう対処してるの？ feed 生成って実はあんまり需要がなくて、feed を食わせて mail なり irc に転送する方が主流なの？
2008-09-03 [長年日記]
_ きむらさんの雑記帖feed化計画
※ 無駄に面倒なこと考えてました。コメントにあるように Yahoo! Pipes の
がいいと思います。
あと、それPlaな人たちはやはり自分で解決しちゃうのが常識っぽい。
考えると作ったらその場で feed の公開（＆ホスティング）までできちゃう Yahoo! Pipes はやっぱいいよなぁ。もうちょっと多様なページやfeedの読み込みに対応できたり、エンコーディングの変換ができたりなんかするとすごく嬉しいんだが。
今どき feed がなくて不便でしゃーないことで有名なきむらさんのときどきの雑記帖ですが、こんな感じで scrape できるんじゃないかな。
- index の <h2>過去の雑記帖</h2>
- の次の一個目のol
- の最後の要素
- に最新の permalink 確定ページの URL がある
- そのページを fetch して
- //div[@class="entry"] を引っこ抜きまくる
- 細かいゴニョゴニョは未確認
- 日付への link はいいかな？
- okotoba も無視の方向で
誰か作って。
ちなみに今、自分は myrss.jp にツッコんで feed を生成させて、更新通知代わりにして、結局 zakkicho に直接アクセスしてます。ページが長いし、非常にブラウザに優しくないです！
以前と違って permalink 確定が早い（もしや index の更新と同時？）なので、上の方法で scrape して十分使いものになりそうな感じ。
というか、とっとと容量制限で rimnet 追い出されてくれりゃまともなツールを使うようになるんじゃなかろうかw
2008-09-07 [長年日記]
_ 『Googleを支える技術』読了
実はこの本はスルーするつもりだったんだけど、最近、やっぱこの本は読んどいた方がいいんだろうなと思い直して手にしてみた。
よかった。
何がよかったか。書き手と編集の仕事が素晴らしい。
正直、内容的にはあちこちのサイト、ブログなどで散見できていて、新しい情報は多くない。だけど断片が離散している状態よりも一冊の本になっている方が当然見やすい。それが優れた作り手の手によるものならなおさらだ。
まず図が豊富で、それほど技術に強くない人間でもある程度までは理解した気になれる。もちろん、技術の分かる人間にとってもこの図は非常に有用である。
次に文章が読みやすい。正直、技術系の本に読みやすさは求めない気持ちで挑むことが多いのだが、この本は久しぶりによくできた縦書きの本を読んだような錯覚に陥った。それくらいに書く行為の基本がよくできていると思う。節、章のまとめもいい具合。いいタイミングでくり返し説明されるのでしっかり内容が頭に残る。
しかし見ると著者はライター歴が長いわけでもなさげ。なおかつ「スーパークリエイター」。天は二物を与えるんだねぇと、少し恨めしい気持ちになった。
良書です。
もちろん編集もグッジョブ。というかここ数年の WEB+DB PRESS の仕事ってほんと感心する。以前は「あー Java の雑誌ね」と見向きもしなかったんだけど、LL 全般を扱い出した辺りから急に幅も奥行きも広がって来ていて、構造化プログラミングを特集されたときには正直「やられた」と思ったものだ。ここにきてこれか、と。
次は「サーバ/インフラ」か？ いやー「集合知」勉強したいんだよな。
2008-09-08 [長年日記]
_ うん、これは自習にいいかも
週末必死に未読feedを消化しているうちに出会った本。
cf. 2008-09-03 - 思っているよりもずっとずっと人生は短い。
以前取り上げた本は、内容的にはいいんだけど、ちょっと硬派で人によっては拒絶反応が出てしまいかねないのと、学習の過程の設計がそれほど上手ではなく、学習曲線がいびつな感じがしていた。最終的にちゃんと全部目を通せば結構な量を網羅できるが、完全なわけでもないし、実際に手を動かす部分が弱かった。
つまり、これ渡して「はい、これで勉強して」と言えないわけではないんだけど、練習問題不足。こちらで「補助輪」として練習問題を用意した方がいいな、という印象。あと取っ掛かりとしてはちょっと情報量が多すぎる。取り上げておいてなんだけど、どっちかというと教材作りのための資料的な使い方やチョコチョコと断片的に知識を仕入れていた人がブラッシュアップするのに向いてそうな感じだった。
そこにこの これからはじめる HTML&スタイルシートの本 (自分で選べるパソコン到達点)(中邨 登美枝) を持ってくるとちょうどギャップが埋まりそうな気配。なんと言っても一冊丸ごと練習問題。
編集はスクリーンショット貼りまくりで個人的には目がチカチカしてきらいなタイプなんだけど、まぁこの方がキャッチーだし、自分がこれで勉強するわけではないので(笑。
何より、本の大きさ、情報の詰め込み具合、一通りのことを順に経験できる内容、といった辺りは非常にこなれていていい感じ。安心して渡せる。まず問題なく一人で最初から最後までやり遂げられて、かつ達成感を味わってもらえると信じられる。もちろん不足分は先日の本や自分で用意した資料などで補ってやる必要はあるけど、最後までやり遂げて成果が出そうっていう辺りが自習教材としてとてもよさげ。
やり始め用の資料を自分で整理とかしてたんだけど、とりあえず初期段階はこれに丸投げしてしまおう。
2008-09-09 [長年日記]
_ 自宅サーバが音信不通……でした。
昨日（2008-09-09）夜、22:00 くらいに気づいたのですが、少なくとも 20:00 まで元気に動いていたサーバが何も言ってこない。というか DNS をやらせていたのでそのままでは外に出れない。
おやおやおや？
もうその日は疲れていて寝る気まんまんだったので放置して*1翌10日、モニタとキーボードを繋いでみる。何も出ない。強制リセット。あ、きたきた。普通に動いてるじゃないか。と思ったら login してしばらくすると画面が乱れて無反応。
あっれー。
これはどっかディスクが壊れたかな。強制リセットしても fsck はバックグラウンドで動くようになっているので login はできるのだ。でもこの状態じゃ何が悪いのか全然分からないな。
ということで今日は予備のディスク買って久しぶりにサラからインストールの予定。たぶんデータはバックアップしてあるので救えるはず。今が FreeBSD 6.3R なので次は 7.0R かしら。
夕飯を食べて。ダラダラ。ダラダラ。やる気が出ない。
意を決して作業開始。実はこのサーバ、光学ドライブをつけていなかった。でも年末 lenovo を買った際に光学ドライブが空いたのでまずはこれを外したり繋いだりの作業。
だりぃ。
オレほんと機械いじり好きじゃないんだなー。それが始める前のダラダラに繋がっていたのだ。
開腹。埃がパネェ。2年分だ、無理もない。掃除機掃除機。
……。
あれ？ さっきまで立ち上がっていたのに「ぴーーーーーっ」て言うだけで立ち上がらない。
ここで知り合いに泣きつく。「メモリじゃね？」というお達し。
うっそーーん。だって2年間普通に動いてて開けて掃除機掛けただけよ？と思いつつ、言われるがままに完全に抜いて刺し直し。
BIOSキタ。よしよし。では Frenzy で起動。軽くディスクの様子を見る。なんか……。なんともない？ バックアップはあるし、予備のディスクもあるので、強制終了してしまったカルマを払うべく普通に起動してそのまま fsck になだれこんでみる。
……。
完了した。
おや？ ということはつまり、原因はメモリが緩かったってか。2年も無事に動いていたのに？ でもまぁ実際、抜き差ししただけで普通に動くようになってしまった。こういうこともあるんだな。
*1 DNSはルータに振り直せば外に出れたし。
2008-09-10 [長年日記]
_ github は git 1.4.x では使えないみたい
イントラで yapra を使いたくて git clone しようと思ったんだけど、404 で止まる。使ったのは Debian etch の git 1.4.4. 探すと同じようにハマった人が居て、やはり backports から入れて解決したようだ。
でもこういう情報はちゃんと表に出さないとダメだろうとカッとなってあちこち調べまくった。1.5 以上でしか github は使えませんというならそれはサイト上に書かれているべきだろうと思って探したがそもそも github には help がない。
Twitter / Keiji Yoshimi: @wtnabe guide? http://githu...
で
Guides というページを教えてもらったけどなんでこれトップページとかヘッダのメニューにリンクないの。そしてやはり欲しい情報はないっぽい。
さらにカッとなって git の release note を漁ると、こんな記述を発見。
The above two new features are not enabled by default and you have to explicitly ask for them, because they make repositories unreadable by older versions of git, and in v1.5.0 we still do not enable them by default for the same reason. We will change this default probably 1 year after 1.4.2's release, when it is reasonable to expect everybody to have new enough version of git.
from http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5.0.txt
1.5.0 ならではの新しい機能を有効にすると古いバージョンからそのリポジトリは使えなくなります、と。1.4.2 が出て 1年経ったらそのオプションをデフォルトにしますよ。
で、ログを漁ると
Public Git Hosting - git.git/log
1.4.2 のタグが打たれてすでに 2年。つまり 1.5 以降を使っているリポジトリには 1.4.x ではアクセスできなくて当然の状況だと。こういうことですな。
残念ながら github がどういう環境で動いているかまでは調べる気力がなかったので分かってないですけど、せめてそういう大事な情報はトップページかせめて 1 hop の位置に書いといてくれよと思った。
その後スッキリして backports から git 1.5.6 入れたよ :-( できるだけ stable のままで行きたい人だっているんだよ。
2008-09-11 [長年日記]
_ Yahoo! Pipes 始めました
Yapra Yapra 言ってたかと思えば今度は Yahoo! Pipes を動かし始めました。
Yahoo! Pipes のメリット
- 作った Pipe もそれを利用したできた feed も Yahoo! がホスティングしてくれる
なんと言っても Pipes を利用する最大のメリットはコレ。Yahoo! だし、さすがにそうそう落ちないでしょ
Yahoo! Pipes のデメリット／苦手なこと
- 編集しにくい
いきなり最大のウリの一つ、ビジュアルプログラミングを真っ向から否定してしまいますが^^;
Yahoo! Pipes は pipe の概念をビジュアルによく表現できていると思うけれど、pipe ってのは基本的に何段にも重なるもので、filter 一つ一つが全部ビジュアルになってしまうとどうしても編集に利用する画面にそれなりの大きさを要求してくるようになる。
簡単に言うと、やってる仕事はたいしたことないのにやたらでかい画面が必要になってしまう。
- グローバル企業 Yahoo! 様とは思えない仕打ち
feed の charset が HTTP response header にない場合は化ける。まぁこれは分からんではない。日本の Web 屋的にはそんなもんある程度は許容しろよと思わなくもないが。そんなことより pubDate から timezone を捨てている！
あほか。
何が起きるかというと、feed を pipe で編集して吐き直すといきなり9時間ずれるのだ。どうするかっていうと地味に 9時間分引いてやるのが今のところの解法のようだ。
cf. 2008-04-18 - Never ending cycle
- サーバもネットワークもクライアントも余裕がないといけない
やっぱちょっと厳しいですな、これ。基本的に JavaScript で画面いっぱいにいろんなオブジェクトを広げてるわ、その指示に基づいてサーバは始終あちこちのサイトにアクセスして feed を取得、各種フィルタを適用してあれこれ値を返してきまくってくる。どこに対しても優しさがない。
まとめ
ビジュアルプログラミングってのはあんまり縁がないんだけど、やっぱ苦手意識は消えない感じ。基本的にはエディタと CLI が最強だと思ってる人間なもんで。*1でもその場でできた feed のホスティングまでできてしまうところがやはり嬉しい。
しかし、文字化けの問題は厳しい。検索エンジンを自分でこさえている会社とは思えない放置ぶり。なんとかしてください！ やってみると分かるけど、案外扱えない feed がたくさんあるよ！
また、地味なところでは twitter の feed を取得することがほとんどできない。これは twitter の API 制限に引っかかってるってことなんだろうけど、この問題は認識してるけど1ヶ月以上経った今も解決してる気配はない。
cf. Pipes Blog � Blog Archive � Twitter and Pipes
※ これは推奨しない方がいいのかもしれない（たぶん重たい）けど、実は search.twitter.com からならほぼ問題なく取得できる。
微妙な点の方を多く書いちゃったけど、文字化けが起きなくて単純な処理だったら Pipes はとても楽しいし便利。もちろん単純じゃない処理だってある程度辛抱強ければ可能。ちなみにこの前、CNET Networks の吐いてる feed をひとまとめにして uniq 掛けるものを作ってみました。便利便利。
Pipes: Combined CNET Networks(Japan) Feed
*1 Squeak が気になりながらどうしても手が出ない、というか手を出しても自分がフリーズしてしまうのもその辺が理由なんだなぁ。
2008-09-12 [長年日記]
_ netbook U100 げと
本当は netbook は全然買う気なかった。昔このサイズの機械を触っていたし、バッテリの保ちも当時とたいして変わらない。もちろん基本性能は当時より高いが、あの小さい画面でできることなどたかが知れていると思っていた。（実際、知れている。）
しかしあるきっかけで欲しくなってしまってからは1週間ほどで機種の選定から実際の購入まで全部やってしまった。うーん、熱は完全に消えたわけではなかったか。
というわけでざっとおさらい。
候補は以下の5機種。あれこれ比較して以下のように順位を付けた。
- MSI netbook U100
- Acer Aspire One
- AsusTek EeePC
以下次点。
- DELL Inspiron Mini 9
- HP 2133 Mini-Note PC
ずばり基準は
画面とキーボードがどれくらい人間に優しいか
である。この基準は PC がでかいとか小さいとか関係ない。PC として使う以上は譲れない基準だ。というかこのサイズの PC のスペックは今ほとんど差がないんだから、あとはデザインかブランドかインターフェイスくらいしか比較しようがない。まぁバッテリの保ちは気になるが、インターフェイスが腐っていたらどんなに長時間バッテリが保とうがそんな機械を使い続けることはできないので無意味だ。
HP のやつのキーボードは大きめで使いやすそうだったんだけど、Atom じゃないし、あっちっちだっていう噂。DELL の変態配列はあり得ない。残りの3機種は実際に触った結果、調査段階とまったく変わらないオレランキングが出た。EeePC はキーボードもよくないが画面が暗い。Aspire One もいいかなと思ったが、最終的には 9" と 10" の差がでかかった。画面もキーボードも余裕のある netbook U100 最強。HDD が 80GB しかなくたって、他のものより多少高くたってそんなことは気にしない。使って気持ちいいか、触って気持ちいいかが問題なのだ。
さて。というわけで emobile もあるし、ずいぶん外に出やすい環境が出来上がってしまった。どうしようかな。
2008-09-14 [長年日記]
_ 北陸セキュリティサミットに行ってきた
※ サミットとは大きく出たよねぇ
いいとこ悪いとこ、感想、提案、その他織り交ぜて。
当日にまとめ書くヒマねーっ。
告知＆サイト
個人的には IT 勉強会カレンダーのフィルタ
を利用して北陸地域の勉強会の情報を feed で取得していたので気づいたけど、他の人はどうやってこの開催を知ったのだろう？というぐらい告知が不足していたような気がする。
というのと日程が。連休のなかびって。自分は何も予定なかったからいいけど、結構困った人多いんじゃないかな。
あと登録フォームが生 http だったような。「おい、セキュリティ。」と思った記憶がある。（今はもう登録フォームのページないけど。）
あ、そうそう会費無料の意味がちょっと分かりにくかったです。講演＆パネルディスカッションと懇親会はベツモノと思った人の方が多かったんじゃないかな。懇親会も無料ってちょっと嬉しい誤算でしたが、事前にそこまで理解できなかったという意味では不安が残りました。
会場
案内はしてあったんだけど看板が小さかったなぁ。あと建物の入り口の扉のところにも看板が欲しいし、部屋の入り口にも欲しかった。うるさいくらいに案内があった方がいいです。何せキャンパスでかいから。（たぶんそれを補うために学生さんがいっぱい立ってたんだろうけど。）
そうそう、野々市は emobile 圏外でした(T_T) Wi-Fi が入ったけど、WiFi が入るとか、そういう情報もあればちょっと嬉しかった。電源は忘れてったのでどっちみち取れなかったんだけど、ネットワークの様子は教えてほしかったかも。
※ 当日、パネルディスカッションの中で proxy が 2ch 弾いてるんじゃないかという話があったけど、バッチリ専ブラでは見えてました。前の席の方で ok サイン出してたんだけど、気づかなかった？
内容
園田さんはさすが先生、という感じでソツがなかった。でも wakatono さんは内容のレベルもペースも設計がむちゃくちゃでしたぞ。まぁ学生も社会人もっていう席で、かつ園田さんと違って特定技術についての内容だとそりゃ難しいとは思いますが。
個人的には wakatono さんの Xen 情報は Web も書籍も含めてかなり目にしているし、自分で手を動かしてアレコレやっているのでなんとかなったけど、会場でついていけていた人間が果たして何人いたのやら。
それより気になったのはパネルディスカッション。テーマでかいなーとは思っていたけど、案の定パネラーとの擦り合わせを全然やってない感出まくり。コーディネータがコーディネータの仕事してないっす。
懇親会
個人的にはちょっと懇親会が（職場の人と一緒に行った都合もあり） wakatono モードになりすぎたのが反省点なのですが、例えば学生と社会人の交流、みたいなことを意識しているのであれば、もう少し強制的に学生側と社会人側が挨拶を交わさざるを得ないような持って行き方とかあったのではないかなぁと思いました。特に社会人は少なかったので、自己紹介くらいさせてもよかったかも。とは言え次回以降、人数が変動すればこのアイディアは全然使えないかもしれない。
スケジュール
質問やらアンケートを書かせるには合間の時間がなさすぎます。まぁ会場の都合とかいろいろあったんでしょうけど。
まとめ
何かの契機になればいいなーと思います。もごもごもご。（いろいろ飲み込んでいるところ。）
2008-09-15 [長年日記]
_ AVCHD の取り回しに苦労する
ビデオカメラありますね。まぁご家庭用のちっこいやつ。最近のやつはあんな小さいのにハイビジョン撮影ができるそうな。マジすか。そんな機能要るの？だいたい、レンズあれ（すげー小さい）だよ？
と思いながら、できることには興味あるのでハイビジョンで撮影してみた。しかしうちにはハイビジョン対応テレビはないし、当然のように blu-ray の作成環境も再生環境もない。つまり、撮っても活かしようがないのは分かっていたけど、どんなもんか味わってみたいと。
しかしこのハイビジョン録画の機能がなかなかくせ者で、どういう風に録画するかが最近まで安定していなかったらしい。blu-ray と HD DVD の戦いの影響がこの辺にまで出ていたのかどうか、あまり詳しくないけど、ここ1年くらいでようやく AVCHD 一本の方向に固まってきたみたい。ちょっと古いモデルを探すと HD 対応でも記録方式の違うカメラがちらほら見つかるので、ビデオカメラ買おうとしてる人は気をつけた方がいいよ。下手に中古とか手を出さない方が無難。
で、その AVCHD、ビデオの圧縮が H.264 で音声が AC-3 で、多重化に MPEG2-TS を使っている、らしい？？？ あーこの辺全然追いかけてねぇ。とりあえず iMovie で取り込めるよ、という情報を頼りに「おぉ、それなら大丈夫」と安易に判断してやってみた。*1
これが間違いのもと。
実は現状、Mac で動く AVCHD を取り込める動画編集ソフトは基本的に AVCHD（というかH.264 ?）をそのまま編集できない。ということで実際には Apple Intermediate Codec というものに変換しながら取り込みを行ってくれる。まぁ昔は MPEG を直接編集するなんて考えられなかったもんね。そういうことだ。
気づけば Mac のディスク容量が全然ない。おや？
そうです、H.264 の圧縮が解かれた動画ファイルは結構でかい！ 1時間で40GBという大きさに達するとな！
cf. Final Cut Pro 5: HDV および Apple Intermediate Codec について
ちょうどハイビジョン撮影で1時間撮影できるものだったんだけど、自分の Mac はこれを 2回分取り込むことはできないくらいの容量しか空いてなかった。調子に乗って撮影した動画を取り込もうとしてハタと気づく。
ディスクないっす。
そこから今度はビデオの書き出しについて調べる。撮る前に調べておけよ。
手元にあるのは iMovie '08 のみ。これで H.264 のムービーを吐き出すことはできる。やってみよう。
……。あれ？
960x540 までしかサイズがない。こちとらフル HD で撮影してんだぞ？
と思ったら QuickTime を使って書き出すとフル HD のままイケるらしい。よーし実験実験。
……。2時間半？ たかが8分のプロジェクトを書き出すのに2時間半？
無理っすよ。これは常用できねぇ。フル HD なめてた。
ということで現在は以下のように書き出してる最中。
フル HD で撮影してしまったものに関しては QuickTime を使わずに書き出せる最大サイズ 960x540 で書き出し。これをデータとして DVD に焼くことに。元のフル HD のまま書き出してもディスク容量的にはたかが 8GB なんだけど、いかんせんエンコードに時間が掛かりすぎて現実的じゃない。でもフル HD から 960x540 のサイズへのエンコードであれば、手元の環境*2で実時間の2〜3倍くらいの時間でなんとかなる。
新規に撮るものはもう SD で撮る。これだって昔のビデオよりはきれいな訳だし、DVD にそのまま焼ける。それに AIC を経由したりとか面倒がない。大幅な時間短縮。どうせあのレンズ、あの内蔵マイクで撮っているのだ。欲張るな。欲張っちゃいかん。何より、
オレはそういう作業に時間を掛けるのは好きじゃない。
cf.
[2008-09-21 追記]
iMovie '08 は AVCHD のカメラからの取り込みではなく、H.264 のムービーファイルの取り込みに関しては AIC に変換など一切行わずにサムネイルとキャッシュの作成だけを行うことができる。どうにかして H.264 のムービーをファイルで取り出せれば問題は解決するような気がするけど、いかんせん AVCHD からファイルをそのまま取り出す方法は今のところ Mac 上ではなさげ。うーん、惜しい。
2008-09-16 [長年日記]
_ ForceType 初めて使った
かっこつけてぇ、API API ってやかましい男がいたんですよぉ〜。なぁにぃ!? やっちまったなぁ!!
つーことで API づいている昨今、古くさい Web のしがらみを捨てて、まずは美しい URI から、と思ったのですが、よく考えたら普段使わないもんだから拡張子付けずにサーバサイドのプログラムを動かす方法が分からない*1。ありゃー困ったなと思ってググったら
ForceType
なんてものを見つけた。例えば
<Files *> ForceType application/x-httpd-php </Files>
とすると何もかも PHP でパースするという漢な仕様の出来上がり。
やるときは気をつけて使ってね。興味ある人は TAKESAKO @ Yet another Cybozu Labs: LL魂お疲れ様でした[LLSpirit] ら辺参照のこと。
*1 最初フロントコントローラ方式で全部 rewrite か？とか思ってた。
_ OpenSSH の ControlMaster を使い始めた
ブックマークだけしてあった
をやってみた。あーこれはすごくいい。
ssh-agent って使ってなかったんですよ。なんとなく気持ち悪くて。でもこれならログインは自分の手でしなきゃいけないし、でも一度ログインしたらその session を使い回してくれる。
これはいい。
OpenSSH 3.9 からある機能なのに、どーして今まで使っていなかったのか。
2008-09-17 [長年日記]
_ リソース指向の URI 設計に悩む
『RESTful Webサービス』読んでんですよ。まぁあらかた読んだんです。いちばん気になっているのはリソースの設計の部分なんですが、これを URI にマップするときにどうにもうまくいかないものが出てきて、しかもまだ解消していないので、それを書こうと思います。（実際のコードのレベルでは「えいや」でルールを決めてしまいましたが。）
何が問題かというと、
- 順番も有無も任意に決められ、かつお互いに階層関係にないパラメータで決定されるリソースの URI へのマップ
です。
例えば書籍の中では、2値によって決まるリソースとして緯度、経度が出てきますが、このときはカンマで区切ることで一つの位置という情報を表現していました。（typo で ; になっているところが何カ所もありますが、カンマになっていないと意味が通じません。）
/Earth/43.9,-103.46/...
このパターンは
- 「緯度経度」の順番
- 緯度、経度ともに欠けることがない
であり、比較的単純にルールを決定し、URI にマップすることができます。
しかし自分の作っていたリソースが
- A, B, C の3つのパラメータを持ち、それぞれ意味が異なる
- 3つはそれぞれあってもなくてもよいが、全部ないとさすがに困る
- 個々のパラメータに階層関係はない
というもので、簡単に言うと従来の Web では
?a=VAL1&b=VAL2&c=VAL3
という query string で表現されるものです。無理矢理階層を割り当てて
/VAL1/VAL2/VAL3
としても、VAL2 は別に VAL1 に属しているわけではありませんし、順番が関係ないからと言って
VAL1;VAL2;VAL3
にすると、今度はこの順番が入れ替わると意味が分かりません。では順番を保持させるべく
VAL1,VAL2,VAL3
なのかというと、……何度も書いてますがこの順番には特に意味はありません。ただどれが何のパラメータなのかを判別するために順番を守ってくれないと困る、というだけのことです。
これは…そもそもリソースがなんだか分かっていないってことなんですかねぇ？
イメージとしては以下のように三次元の座標軸上で考えられるのかなと思っています。
- パラメータが1つの場合はその軸とそれを回転させた立体のデータ
- パラメータが2つの場合はその2軸で作られる平面のデータ
- パラメータが3つの場合は3次元上の1点
という感じで徐々にリソースが限定されていくような感じ。もちろんパラメータが本当に3次元を表現していて、それぞれ x, y, z なのであれば順番は自明ですが、実際にはこの順番が自動的に決定しないというものです。
これは、どう考えるのがよいのでしょうか？ やっぱリソースがなんだか分かってないのかなぁ？ 適当に順番決めてカンマで区切るのが無難なのかなぁ？ さすがにパスがないのはダメだけど、カンマ区切りのパラメータの一部がないのは問題ないからなぁ。デキのよくない、引数の多い関数を作るみたいな感じでちょっとイヤだけど。
2008-09-18 [長年日記]
_ JSONの仕様にちょっと悩む
て、RFC に
RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)
なってるし、YAML と違って結構いろんな言語でちゃんとサポートされてるので、シリアライズ形式として優れているなと思っています。*1
ただなんかちょっと腑に落ちないところがあって、上の RFC に以下のように書かれてるんですよね。
Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A though F can be upper or lowercase. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C".
2.5. Strings より。
で、
may ってどないやねん
と*2。
ただまぁ現実的には生で書くわけじゃないので、ライブラリの挙動が合ってればそれでよく、実際、
- PHP
- Ruby
- JavaScript
で
- PHP -> JavaScript
- Ruby -> PHP
- PHP -> Ruby
の3つではすべて日本語は \u 形式で表現され、それで問題なく解釈できるという動きになってます。
まぁ、そういうことなんでしょうねぇ。
2008-09-24 [長年日記]
_ ETag って特に書式ないの？
RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
3.11 Entity Tags
Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the ETag (section 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and If-Range (section 14.27) header fields. The definition of how they are used and compared as cache validators is in section 13.3.3. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
weakness indicator と quote 以外はなんにも言ってない気がする。
実際例に挙がっている文字と例えば Apache の返す ETag 文字列とはまったく異なる。要は
リソースの変化が検出できる仕様になっていて " で囲まれていれば何を基準にどんな文字列を生成するのも自由
ってことかな？
あーなるほど。この解釈で合ってるみたい。
- Apache はデフォルトでは inode, mtime, size を - で結んだ文字列を返す
- core - Apache HTTP サーバ
- inode が絡むとスケールアウトさせられないので大規模なサービスでは inode は使わない設定にするらしい。
- Rails は response body の md5 を返す
単純なファイルを返す場合以外は Rails 方式を採用するのがいい感じだ。
2008-09-27 [長年日記]
_ rest-client が便利
さてすでに書きましたが最近 API づいております。できるだけ RESTful な API を作りたいなぁと思っているわけですが、そこで問題になったのがテスト環境。
まず、ブラウザは使いものになりません。
- 通常の方法では GET, POST 以外のリクエストを投げられない
- 通常の方法では html, xml, plain text な response body 以外は表示できない
からです。
まぁ今回テストしたかったのは read only な API なのでリクエストメソッドとしては GET, POST だけでも問題はないのですが、response が application/json だったので
毎回毎回「ダウンロードダイアログが出る -> ダウンロード -> ファイルを開く」
作業が必要になり、さすがにこれはやっとれんと思いました。
そこでまず目をつけたのは以前インストールだけしてあった Firefox extension RESTTest. 結構初期のバージョンだったけど普通に使えます。ただ、フォーカスの当たっているデフォルトのボタンが [ OK ] になっていて、何も考えずにエンターを押すとウィンドウを閉じてしまうのがものすごくイライラ。要するに連続してテストしようにも毎回マウスでちくちく [ Send ] を押さないといけない。これはダサイ。
それでもなんとかサーバ側のコードを書く方が優先なのでちくちくやってました。とりあえず基本形ができたところでマシなテストツールを探します。
まずは RESTTest の最新バージョン。なんか addons.mozilla.org にログインが必要とかぬかし始めている。もうその段階で却下。できれば自動化したいので Ruby で書かれたものがいいなと思い、rubyforge を rest で検索して探します。で、なんとなく目をつけたのは以下。
- RubyForge: open-uri for REST clients: Project Info (RESTful本に載っているもの)
- RubyForge: Ruby-On-Rest: Project Info
- RubyForge: Rest Client: Project Info
それぞれ適当に試したのですが、
rest-client は irb を利用したテストが可能というところに強く惹かれました。
使い方は以下のような感じ。（今回試したのは 0.7）
$ restclient irb> RestClient.get( 'URI' )
これで response body が画面上に現れます。例えば body が JSON の場合は*1
require 'json' $KCODE='u'
しておいて、
irb> JSON.parse( RestClient.get( 'URI' ) )
すると目視チェックが可能になります。さらに
require 'pp'
しておいて
irb> pp JSON.parse( RestClient.get( 'URI' ) )
すればインデントもバッチリ、とても確認しやすいです。これはブラウザをそのまま使っていたときよりも RESTTest を使っていたときよりもずっといい。
XML の場合は require 'hpricot' して
irb> doc = Hpricot( RestClient.get( 'URI' ) ); puts doc.search( '//item' )[0]
なんて風に使えます。
もちろん irb なので Readline が効いていれば履歴をたどって何回も同じテストを実行しやすいです。
ヘッダが見たければログを設定
rest-client はデフォルトではヘッダの情報は取れません。ヘッダの情報がほしい場合は
irb> RestClient.log=DEST
としてログを取得する設定をします。DEST は
- ファイル名
- stdout
- stderr
が指定でき、stdout にした場合はそのまま irb 上に表示されます。
しかしここまでやっても実は取れる情報は
- status code
- Content-Type
- Content-Length
くらいのもので、例えば Last-Modified などは取れません。つまり、現状では cache が絡むような凝った client は rest-client では書けないということです。
また status 200, 201, 202, 301, 302, 303 以外は例外が上がるので、例えば
RSpec などと組み合わせてテストコードを書こう
とする場合はその辺をうまく拾ってあげる必要があります。
認証の必要なリソースのテスト
RestClient::Resource を利用します。
irb> r = RestClient::Resource.new( uri, user, password )
でリソースを作って、
irb> r.get
やら
irb> r.post
なんて風に使います。
ヒストリで右往左往
上で irb なので履歴を利用して同じテストを何回でも試せると書いたばかりですが、実は irb は標準では history をログに落としてくれないので、起動するたびに履歴は忘れてしまいます。しばらくこのことを Twitter 上でブータレていたのですが、現在のところ以下の動作を確認しています。
- irb/ext/save-history を使う方法はリファレンスに 1.9 feature と書かれているが 1.8.4, 1.8.5 で問題なく動いている
- restclint 実行ファイルを呼び出した場合は 1 の方法も rlwrap*2 をかます方法も使えない
ということで、結論としては
restclint 実行ファイルは利用せず、irb のプロンプトから require 'rest_client' してテストを行う
という形がベストのようです。いろいろ直接、間接に教えてくれた walf443 さん、eban さん、ありがとう！
なお、現在の自分の .irbrc は以下の通りです。
require 'irb/completion' require 'pp' require 'time' require 'date' require 'irb/ext/save-history' IRB.conf[:SAVE_HISTORY] = 1000 $KCODE='u'
シンプルなもんです。これで require 'rest_client' を打てばすぐいけます。
まとめ
rest-client は API の開発に実に便利に使えそうです。今のところ自分の使っている範囲では cache 周りを除いては特に不満はありません。
またこれを利用すれば response body を Ruby の文字列として自由に加工可能なので、これまでブラウザ上で print デバッグしていたようなケースでも便利に使えることが分かってきました。例えば長過ぎる文字列をぶった切るとか HTML の一部を抜き出して確認するなんてことが比較的簡単に行えるので効率がいいのです。泥臭い print デバッグでも目印さえつけておけば rest-client + Hpricot 辺りでかなり楽できます。*3そしてそれが Terminal だけで、つまりほぼキーボードだけでテスト可能なんてステキな話じゃないですか。
実は 「rest test」で探していたときは全然見つからなかったのですが、「rest client」で探すと Java のものとか Python のものとかいろいろ見つかりました。もしかするともっといいツールがあるのかもしれません。探すってやっぱ難しいですね。思いつかない言葉の組み合わせでしか見つからない情報は見つけられない -> 自分にとっては存在しないに等しい、って感じになっちゃう。
cf.
RestClient は 0.9 でヘッダが取れるようになってた
*1 restclient 自身が rubygems でインストールされているのでいきなり require 'json' で ok です。
*2 rlwrap は readline が有効になっていないアプリで readline が使えるようになり、さらに history log も作ってくれる超便利なツールです。ただし irb で使うためには irb --noreadline と組み合わせないとたぶんおかしなことになるうえに、irb/completion が効きません。tab の動作が rlwrap 側に奪われてしまうからだと思います。
*3 本格的にブラウザを使ったテストの自動化には Selenium や WWW::Mechanize などを使う方がよりよいと思います。
2008-09-29 [長年日記]
_ 超今さら FeedBurner のお勉強
今や世界一の配信数の座は RSS広告社の各種ブログサービスとの提携とともに奪われてしまった FeedBurner ですが、やはり Feed 配信の実績とそれに関する各種機能と Google のネームバリューでなんとなく世界一的な印象のある FeedBurner をようやく試してみました。
と言っても Feed を配信するだけなら
- アカウント取得
- 配信したい Feed を登録 -> feedburner 上の URL を決定
- 上で設定した URL を feed reader に登録してもらう
だけでおしまいです。
問題は、一時騒がれた
auto-discovery を他ドメインにしてしまうと Yahoo! ブログ検索から外れてしまう
こと。これの対策は
- auto-discovery 自体は自ドメイン上の何らかの URI に振っておいて、実際そこにアクセスされたら FeedBurner の bot 以外は FeedBurner ドメインの feed の方に redirect
- Yahoo! ブログ検索の方にオリジナルの URI を ping で通知
のいずれかを行えばよいらしい。
今回は今後 feedburner に配信させる feed が増えていく前提で 1 の方法を採用し、mod_rewrite ではなくサーバサイドのスクリプトの方で redirect や URI の管理を行える簡単な仕組みを用意しました。
ちなみに、この確認も rest-client で以下のように行いました。
irb> RestClient.get( URI, {'User-Agent' => 'FeedBurner'} )
要は2番目の引数に request header をいろいろ詰め込めるので、そこに適当に書いてやるだけでオーケー。ブラウザでこれをやると extension を入れるだの普段使わない UI でどこから設定したらいいだか分からないだの面倒だけど、rest-client ならそのまま書くだけなので楽勝です。
2008-09-30 [長年日記]
_ Last-Modified と HTTP date と RFC 1123
API だの Feed だので盛り上がっている wtnabe です。
今日は先日の ETag の話に続いて client 側での cache に使える Last-Modified response header のお話。
サーバサイドで各種スクリプトを動かす場合、HTML そのものは cache してほしくない場合が少なくありません。
……。ということにしてください。
実は Last-Modified はほとんど意識したことがありませんでした。ですが API や feed の場合は基本的に生のデータをそのまま提供する形になるし、ブラウザからの自サイトへの直接のアクセス以外にも様々な利用が可能なので、ネットワーク帯域やサーバの負荷を抑えるためにできることはいろいろ細工しておきたいものです。
ということで本題。
cf. [Studying HTTP] HTTP Header Fields
このヘッダの値は HTTP date という名前で定義され、以下のようなルールになっています。
- RFC1123 スタイルの固定長の表記が好まれている（送出はこれにしなければならない(MUST)）
- それ以外も含めて3つの表記をサーバ、クライアントともに受け入れなければならない(MUST)
- すべての HTTP date/time stamp は例外なく GMT で表現されなければならない(MUST)*1
ちなみに RFC1123 の日時表記が RFC822 と違うのは
- 年は4桁の数字で表現すべき(SHOULD)
- timezone の名前ではなく時差を数字で表現すべき(SHOULD)
ということらしいです。
ということは timezone の名前は管理する必要ないですね。よかったよかった。
*1 リンク先は誤訳でしょう。without exception は「例外を除いて」ではなく「例外なく」になるはずです。
_ hi_saito [私は「なんでも RSS」を使ってますが、それなりに拾えています。]
_ wtnabe [なんでもRSSってまだやってたんですか。なんか東工大はblogwatcherやめてるし、長いことサイト自体に繋がった..]
_ m-satyr [http://pipes.yahoo.com/satyr/zakkicho?_render=rss ↑良ければどうぞ..]
_ wtnabe [ktkr !!! 今まさに Pipes にログインしたところでした！ ありがとうございます！]
_ wtnabe [そうか。トップページの方にも permalink が埋まってたんですね。気づいてなかった。なるほど。miscapi...]