2007年9月アーカイブ

なんとなく道筋は見えているっぽい。

cybozu -> cybozu2ical -> icalendar file -> ? -> google calendar <-(Spanning Sync)-> ical

「っぽい」情報を見つけただけで、実践していないので何とも言えない状況ですが、何となく上記のような流れになるような気がしています。iCalはおまけです。

カレンダーアプリは全く使っていないので大して興味はないのですが、何となく知っておいて損はない気がしているので調査だけはしています。

  • Cybozuはイントラ限定
  • Googleカレンダーでも非公開(限定公開?)
  • Cybozuで更新された情報をGoogleカレンダーにも反映
  • CybozuからGoogleカレンダーへは自動更新

上記の要求を満たす事が出来るのでしょうか。何はともあれ、会社のCybozuのバージョンを調べて、cybozu2icalが使えるようなら試してみます。

さて、そんな暇はあったでしょうかね?


あ、Fの人、おめっとさんでした。

Firefox2.0(lzyc)でuser.jsが効かないと思っていたら、先頭行に「@charset "utf-8";」が。

結果を言えば、@charsetの行を消して解決しました。いつの間にかuser.jsが存在していたので、何かのきっかけで@charsetが書き込まれたのだと思いますが、さっぱり思い当たりません。

問題は解決しましたが、@charsetってJavaScriptに書くとどんな意味があるのか分かりません。まあ、そのうち答えが見つかるでしょう。

多分、既知の問題とかだと思いつつ放置し続けてはや幾月。

OSXのFirefox2.0で、[表示]→[ツールバー]→[カスタマイズ...]とすると、ダイアログを閉じたときにおかしな事になって設定が反映されない、というやつ。

All-in-One Sidebarを無効にしたら問題なくなりました。

回避策が分かればあとは運用で逃げるので、とりあえずはこれでスッキリしました。

楽しい残業

iMacが届いたので、サービス残業としてセットアップ作業をしてました。

とりあえず、楽しさは周囲に十二分に伝えられたと思うので、ここでは割愛。

宣言通り、Win&Macの併用です。という訳で、早速Synergyを入れてみました。

SynergyはOSXをサーバにして、旧マシンのWin機をOSXにつないだキーボード&マウスから操作できるようにしています。設定などはウェブをみたらわかるので省略(説明できるほどまとまってません)。注意する点としては、自分の環境では"Cmd+@"でのIMEきりかえができなかったので、Win機にCmdSpaceを入れてCmd+SpaceでIMEを切り替えるようにした事。
後は、Win機のSynergyはPC起動時に実行される風なオプションがあったのでそれを有効にして、OSX側では起動処理をAppleScriptに書いてログイン項目に登録しておきました。

まだまだ道半ばですが、併用しつつ徐々にmac側ですべての作業ができるようにする予定です。

ひょっとして、知らなかったのは私だけ?

"Enhanced Feed Preview"の方は、設定で"正確なURL"と言われたので使ってません。そこで、"Feed with Stylesheet"を試してみたところ、スタイルの適用を見極めてフィードプレビューのOn/Offをしてくれる事を確認しました。

気になるのは、ヘッダのようなものが表示されている点。テストに影響があるようなら、結局はFirefox1.5を使わないといけませんが、ひとまず会社でテストしてみます。

テストが通ったらいいな。。。


まあ、きっと、会社の誰かが試して駄目だったとかなんでしょうがね。聞いいた事があるようなないような。

諸事情から、きっと必要になるはず。

Mozilla Firefox - Firefox - Firefox 1.5 のダウンロードが見つかったのですが、どうもダウンロードできないようです。

FTPミラーを見てみても2.0系しかありません。サポート終了となっているので仕方がないのですが、どうにか手に入れる方法はないものでしょうか。

CVSから古いソースを手に入れて、それをビルドしたらいいのでしょうか。CVSにアクセスした事がないので、古いソースが手に入るのか分かりませんが、手に入るならきっとビルドできるのでしょう。

Windowsであれば、多分インストーラが残っていた気がしますが、OSXのはありません。

そのうちWindows消してLinux入れようと企んでいましたが、これでは無理です。

ん。テスト項目消すか。。。

さて、どうしたものか。

sbmとSPAMとnofollow

考えた事がなかったので知らなかったけど、rel="nofollow"がスタンダードらしい。

まあ、他所様に見過ごせない悪影響を与えてしまっているなら、問題だわね。結局、SPAM行為を管理できないなら、メタデータ云々を諦めて、rel="nofollow"とするしかない。大変でしょう、SPAM対策ってさ。まあ、対費用対効果ってやつで考えるしかないですわね。

基本的に阿呆なので、"口コミ効果がGoogleに反映されるんだ!スゴイワ!"とか考えてしまうわけですが、まあ、Googleは十分すごいしね。いいんじゃない。ブレークスルー待ちでさ。

他所様への悪影響もそうだけど、その過程で自分とこも荒れてしまっちゃあどうしようもないですわな。人気エントリのRSSをリーダーに登録してるわけですが、たまにエロスがまぎれてきて困るわけですよ。SPAMなのか、みんながエロスなのか知りませんがね。お昼とかにリーダー眺めてるとね、会社だし。男ばっかですがね。まあ、気になるわけです(体裁ですよ?エロスぢゃないですよ?)。

なんといいますか、del.icio.usが買われた頃か、その前あたりか、とにかくその辺りでsbmについて考えるのがめんどくさくなったので放棄です放棄。いいんじゃないのぉ、nofollowでさぁ。

一カ所でまとめてサーチできればそれでいいですわ。それがGoogleであろうがなかろうがさ。ソーシャルだ何だと意識せずに、ウェブからまとめてぶっこ抜ければそれでいいよ。

ひとまず、被ブックマークのデータを今とは別の方法で吸い上げてもらえばメタデータ云々は解消?ああ、結局はsbmにまぎれるSPAMをうまい事排除できなきゃ意味ないのか。ある程度はまぎれてもいいだろうし、ほぼほぼで引っ掛けられるフィルタがあればいいね。

まあ、やる気ないので、nofollowでふぁいなるしーさー。


タグで引っ掛けるのは微妙でない?spamってSPAM行為に対してつけているのか、SPAM行為に関する記事につけているのか、微妙でない?共通認識できあがってたの?まあ、後からどうにでもなるのか。

Debian(etch)ではwodimを使う風な情報を発見。

そもそも、『CD-Rを焼く』という行為自体を、おそらく片手(多くても両手)で足りるくらいしか経験した事がありません。しかも、GUIだけなので、実際に『CD-Rを焼く』という作業の詳細をまったくもって理解していません。

そんな訳で、CUIでCD-Rを焼いてみようと思います。

さて、以降、無駄に長い文章になるのでここで区切ります。結果を先に言うと、焼けませんでした。お先真っ暗。

8/29に炎上してた?

久しぶりにレンタルサーバのログ解析を見てみました。

まったく自然にスルーしてましたが、8/29に501,063[Hits/day]ほどアクセスがあったようです。

追いかけてみると、/archives/2007/05/に特定のホストの特定のUAから連続してリクエストがあったようです。午前5時から午前8時までの間に487,819[Hits]ほど。(UA偽装でなければ)WinXPのFirefox2.0.0.6という事なので、何でしょう。暴走?

気になるのは、39,518,468[KB]ほどの転送量が発生したという事。同一クライアントから秒間Nリクエスト以上はbangするとかしないと駄目ですかね。専用サーバではないですけど、この辺は利用者側が責任を持つべきでしょうか。トラフィックに関する条項とか記憶にないです。

ひとまず、レンタルサーバの運営会社から苦情のたぐいはいっさい来ていないのでスルーの方向で。

普段まったくもって凪なので、こういうのは心臓に悪いです(自前サーバじゃないにしろ)。


50万リクエスト/3時間で秒間46リクエストくらい。コンテンツサイズは150KBくらい。ログを見ると実際に転送しているサイズはばらつきがあるので、75GBには至らず。

何か、誰かの気に障るような事したっけかな?


ちなみに、普段はせいぜい10,000[Hits/day]程度。

アナウンサーがテンパッてるのかと思ったら、リングネームだったんだね。

最近、ついていけてないなぁ。

「`cap -S _hoge=foo <task>`したら、<task>の中で_hogeという変数が使える」という事実を知らなかった事についさっき気がつきました。

さらに、ヘルプをちゃんと読んだ事がなかった事にも気がつきました。レシピを書く為に多少はドキュメント(web)を読んだりしていますが、コマンドのヘルプを読んだ記憶はさっぱりありません。

そんなもんで、ちゃんと調べないままに`HOGE=foo cap <task>`とかしてたのは内緒です。

会社のマシンで触るIEの十倍くらい速い(気がする)。

多分、OSXのFx2よりもVMのIEの方が速いです。これは異常。ここまで速いIE6は見た事ありません。

インストールしたばかりで、余計なモノをいっさい動かしていないWindowsだからでしょうか。

まあ、理由はどうあれ、良い事です。

深く考えずに、2.4GHzくらい欲しいな、と。

前提

  • 開発用サーバが必須(Linux)
  • IE6による動作テスト(selenium)が必須
  • できればOSXで作業したい

プラン1:全てOSXでまかなう

  • Parallels Desktopを購入
  • WinXPを購入
  • WinXPとLinuxの仮想マシンを作成
  • VM上のIEからVM上のアプリを叩く

Seleniumでは、多いときで600MBくらいメモリを消費するので、不経済な気がします。アプリ側でもそれなりに負荷がかかるので、OSX側にどれだけリソースが残るか不安です。

プラン2:現行マシンを使い続ける(A)

  • 現行マシン(WinXP)には開発用サーバ(coLinux)とIE6がある
  • テストは現行マシンで完結する(テスト対象とテストツールが動作)
  • OSX側は純粋に開発作業だけに使える

このプランなら、Macのスペックが低くても十二分にやっていけるはずです。Synergyを使う機会を得る事もできます。ただ、自分で低く見積もったスペックに、いずれ不満を持つようになる可能性はあります(ワガママすぎ)。

プラン3:現行マシンを使い続ける(B)

  • 現行マシンを純粋なLinuxサーバとする
  • Parallels Desktopを購入
  • WinXPを購入
  • IEでのテスト用にWinXPの仮想マシンを作成
  • VM上のIEからLinuxサーバ上のアプリを叩く

サーバアプリは速く動くだろうけど、VM上のSeleniumというのはやはり怖い。どうしても、Macのスペックを高めに見積もってしまいます。仮想マシンとOSを購入する必要もあるので、これは富豪プラン。

ネックはIE

どうしても、IEがネック。プラン3は、実は安くすませる事ができます。CI用のクライアントマシンを使わせてもらえば、IEの心配をしなくてもすみます。IEが不要なら、仮想マシンもいりません。となれば、Macのスペックも低く見積もれるはずです。

CI用クライアントは席が離れていますが、リモートデスクトップなりVNCなりを使う方法も考えられます。が、CI用のクライアントマシンはスペックが低めなので、その辺がうまく動いてくれるか不明。

やはり、VM上でSeleniumを実行するのは、今のテストスイートの出来を考えると自殺行為です。となれば、諦めてWindowsマシンを買うか、プラン2を選ぶかとなります。多分、Windowsマシンを選ぶと個人的な気持ちの問題で公開すると思っています。なので、どうしようもない事態に陥らない限りは、Macを選びます。

さて、結局スペックはどうしたらいいでしょうか。開発用サーバに無駄にスペックを求めても仕方がないので、プラン3を消して、プラン2が妥当な気がしています。つまり、スペック低めで問題ない、と。プラン1は、VMだらけで気持ちが悪いので無視します。Seleniumで無茶をしなければ問題ないんですけどね。

一番左のiMacが妥当かな

どうやら、iMacの2.0GHzのモデルが妥当な気がしています。Mac miniまで下げられなくもありませんが、それもどうかなという気がします(HDD:5400rpmなんですよね?)。(ノート持ちより勉強会は楽しそうですが)特別、ノートにする意味もないので、MacBookも却下。そもそも、熱いでしょうし。

iMacの2.0GHzモデル(メモリ2GB)なら、18くらい。DVI-VGAの変換アダプタをつけても18くらい。決まりかな。


あ、現行のWindowsマシンをWindows入れたまま使い続けると、ノートンが2つ必要になるのか。よくないなぁ。ん、OSXで使わなければいいのかな?それも、体裁悪いよなぁ。

IE問題さえ解決すれば、Windows消して、Linux入れるのに。まあ、言い換えれば、Macにこだわるのが悪いんですけどね。

お?IEでテストしなきゃいけないような場合は、誰かと無理矢理ペアプロして、ペアの人のマシンで作業すればよかったり?無理だな。

!。しばらくBootCampでごまかし、、、WinXP買わなきゃいけないのか。駄目だ。?。Win2000なら、、、あれ?およ?いや、めんどくさすぎる。

CI用クライアントマシンが手元にくればいいんだっ!どうせ、CIの結果をチェックしてるのは自分だし。普段は暇してるマシンだし。1台都合が付けば、いまの位置に置けるし。えぇ、わがまますぎる。でも、本当に1台都合が付くなら、島の空いた席にでも動かしたい気持ちはある。

んー、Mac購入にこんなに障害があるとは思わなかった。あぁ、もう、どうしていいのか分からん。いっそ、買わなきゃいいんだよ、おニューなんてさっ。


という、盛大な愚痴がどうやら1000エントリー目のようです。

macかPCか

会社で、「おニューのマシンを買っていいよ」というありがたいお言葉をちょうだいしました。

「以前からmacで仕事したい」とぼやいていましたが、いざ踏み出そうとすると躊躇するものです。というのも、諸事情から、Windows上でのテストが必須だからです。

ただでさえ、macは高い(ほどよい価格帯のモデルがなかったりする)のに、WinXPと仮想マシンアプリとが必要となると、間違いなくWindowsマシンを買うよりも高くつきます。

WinXPと仮想マシンアプリを買わずにすませる回避策として、現状のマシンを引き続きテストマシンとして使い続けるという方法があります。

現マシンのテストマシン化は実はすごく惹かれるアイデアです。ですが、みんなが1台で開発している中で、一人2台というのも「なんだかなぁ」と。2台分の生産性をあげられるかといわれると、果てしなく自信がありません。そもそも、macにふさわしい生産性があげられるかすら危ういです。

でも、やっぱ、OSネイティブ(?)でUnixライク(互換?)なシェル環境が触れるというのは魅力です。魅力です。

macを買うとすると、どうしても最軽量モデル(?)のひとつは上を使いたくなるので、腰が引ける値段になります。自腹なら躊躇しませんが、そうでないとどうも駄目です。Windowsマシンを上手にやりくりすれば、大きめのディスプレイをつけておつりがくる位の値段です、きっと。

あと、ペアプロとか考えると、ペアの人がmacを触れないとどうしようもない。まあ、エディタとシェルは共通だから何とかなるとは思うんですが、「馬鹿やろう!macなんか触れるか!うちは曾爺さんの代からPCだ!」とか言われると、もう何も言えません。泣き寝入りです。

などと考えつつも、ほぼ9割方macを選ぼうと思っています。だって、この機会にSynergyが使えるかもしれないんですよっ!!3面ディスプレイな環境が手に入るかもしれないんですよっ!!

んー、自分が自信を持った技術者なら、きっとこんな心配しないんだろうなぁ。


狙っているのは、iMac[20インチ,2.4GHz]+Mem:2G。追加でmini DVI-VGAアダプタ。で、現マシンにディスプレイ1台使って、残り1台をiMacにつなぐ。iMacがデュアルディスプレイになって、Synergyで現マシンにつながったら、仮想でトリプル。サン、レン、チャンッ!!!

22か。。。

まずい。

オライリーの詳説正規表現の第三章(導入部分)まで読んだだけですが、かなり分かっていない事がはっきりしました。

第四章以降をちゃんと理解できるか恐ろしい。。。


Unicodeの¥p{...}とか知らんです。後方参照をパターン内で使った事ないです。¥wとエンコーディングをちゃんと意識してなかったです。¥Xと合わせ文字とか知らんです。略記法は意外と最適化されてなかったりするんですか。アトミックですか。

読み終わったら、現在の状況を把握しないとだめですかね。そこは、必要に応じてチェックリストで叩けばいいのかな。きっと、「何を意識すべきか」がはっきり分かっているはずだ。多分。だといいなぁ。


結構、(個人的に)タイムリーな話なので、真面目にやらないと痛い目を見そうです。

けど、正規表現の本を読まないとだめなので、まだ読めません。ちぇっ。

こんなのがあったとは知りませんでした。

シェアウェアであったり、X使ってたりとかは見た記憶がありますが、Porticusは知りませんでした。

使い慣れた訳ではないので、評価も何もありませんが、パッケージ情報が見やすい気がするので好印象です(他と比べた訳じゃないんですけどね)。

コマンドラインで使うと、キャッシュできてないのか、"port installed"を何回叩いても遅かったりした気がします。そういう意味でも、よいかもしれません。

portコマンドでどこまでできるのかを知っておかないと、よくわからない度が増しそうなので、一応基本はコマンドラインで作業します。が、情報を見たり、ちょこざいな作業はGUIベースになる気がします。

しばらく使ってみます(多分)。


そろそろ、archiveと"-b"のあたりを調べないと。明らかにコンパイルしてるんだよなぁ。yumとかみたくリポジトリ(?)のURLを指定したらいいのかな?

あれ?初回は必ずコンパイルするというのがMacPortsの決まりなのかな。yumとかみたくできるモードがあるのかと勘違いしてたみたい。

フィードに詳しくない身ですが、ちょいと愚痴って考えてみます。

とりあえず、フィードなんか盛り上がんなくていいよ。フィードなんか裏側でちょこまかしてればいいんだ。

表現の裏とか、音楽・映像配信リストの裏とか、検索の裏とか、さ。データを正規化(?)するのにフィードっていうフォーマットが使えるようにしとくと、いろんな露出先から引っ張りだこで、トラフィック増とかSEO効果とかが期待できるかもよ的な事は裏の人がおさえてればいいんだ。

よくわかんないけどさ、普通の人がたくさん騒がなけりゃ盛り上がったりしないんじゃないの。開発者とか企業の広報担当(web)とかが騒いでも、それが普通のツールとかになっちゃえばそりゃ静かになるでしょうよ。こっから盛り上げようと思ったら、普通の人が対象じゃないの。でも、普通の人がフィードで盛り上がるってなによ。

フィードなんてよくわからないもんを、普通の人が楽しめますかっての。みんながみんな時間を節約したかったり、大量の情報を効率よく収集したいとか考えるもんか。フィードリーダー使ってフィードを使うなんて、変態ばっかだよ。

受け手としてそんなんなんだから、出し手になったときだって、フィードなんか意識するもんか。ブログが勝手に用意してくれるから、推奨されるままにフィードを提供してるだけだよ。だから、「まずフィードを作る」なんて意味分かんない。やりたいのは、ブログを書いたり、音楽・映像コンテンツを発表したりって事でしょ。フィードは流通をサポートするだろうけど、やりたい事をかなえる為の第一のツールなんかにゃならん。

まあさ、あれこれ書いたけどさ、結局何かいてるか分からなくなってきたよ、もう。何ていうか、あれだね。媒体というか見えるものとか使えるものが大事であって、それを作る為の何かなんて、ないがしろにされてオッケーだってことだよ。分かる人に分かってもらえればいいんだ。ポンッて肩を優しく叩いてくれれて、ウンウンってさ。

はぁ。盛り上がんねぇかなぁ、フィード。


とりあえず、エンドユーザに意味があるのは、フィードのいっこ(以上)上の層だと思ってます。なので、エンドユーザに提供できる価値とかは、その層の創意工夫の成果物になるのかな、と。で、創意工夫の土台にフィードがいてほしいという気持ちはありますが、フィード自体を無理矢理エンドユーザに届けたいとか使ってほしいという気持ちはありません。

あー、無理矢理書いたせいで、落としどころを完全に見失いました。「週休4日マジック」のせいかな?

なんというか、未だに彼のサービスが「フィード押し」でグイグイ行こうとしている意味が理解できないので、ちょっとでも分かる事ができたらなぁと思ってこんな事を書いた訳です。でも、結局分かりませんでした。だって、あれブログでしょ?


そんなこんなで、待ち続けている宅急便の人がやってきません。

と書いたとたんにやってきました。恐るべし、「週休4日マジック」!

見出しをうまくまとめられませんでしたが、特に方法はないのですかね?

PHPのpreg_match関数に第3引数を指定すると、その変数にキャプチャ結果が代入されます。そのため、私はよく以下のような書き方をします。

if (preg_match($pattern, $subject, $matches)) {
    var_dump($matches);
}

一方で、Pythonのreを使う場合にはこう書いています。

match = re.match(pattern, subject)
if match:
  print match.groups()[0]
 

何をしたいのかというと、ようは、Pythonで書いたコードの最初の代入を省略したいという事です。これは、Pythonの分かりやすいコードという事に反する欲求なのでしょうか。知らないだけで、方法はあるのかな。

どこかにグローバルな魔法的変数とかがあるのかしら?まあ、なきゃないで困りはしないけどさ。

ブックマーク経由で知ったRFC(STD 1)。
[RFC 5005] Feed Paging and Archiving

仕様中には"complete", "paged", "archive"という状態(?)を表す用語(?)が定義されています。それぞれ、「ある条件に従ったエントリー群全てを含むフィード」、「一時的な集まりであるエントリー群を分割してまとめたフィードの集まり」、「永続的な集まりであるエントリー群を分割してまとめたフィードの集まり」を意味します(きっと)。

また、それらの状態ををフィード中で明示する為に、"fh:complete", "fh:paged", "fh:archived"という空要素をヘッダに埋め込むようです。

分割したフィードへのアクセスは、link要素に従って行えるようにします。これは、OpenSearchか何かで使われている方法と同じはず。リンク先が「どこ」をさすのか知る事ができなくてはいけないので、当然それを明示する為のrel属性が定義されています。

ページが「一時的なエントリー集合」で、アーカイブは「永続的なエントリー集合」であるという考えにプチへぇ〜。あまり意識した事がありませんでした。まあ、基本的にはページを使えばいい気がしますが。

フィードに疎いのでよくわかりませんが、共通の語彙が決まるのはよい事です(よね?)。

PHPのpreg関数で、日本語を含む文字列に対してのマッチングに失敗。(PHP5.2.3; OSX[intel]; UTF-8)

var_dump(preg_replace('|([^\w\-\.\~\!\$\&\'\(\)\*\+\,\;\=\:\%\@\/\?]+)|e',
                      '"<\1>"',
                      'あいうえお_09'));
var_dump(preg_replace('|([^\a-zA-Z0-9\_\-\.\~\!\$\&\'\(\)\*\+\,\;\=\:\%\@\/\?]+)|e',
                      '"<\1>"',
                      'あいうえお_09'));
string(15) "<あいうえ⚤最琀㬀ꨀ_09"
string(15) "<あいうえお>_09"

しばらく悩み続けましたが、どうやら文字クラス内で英数字(単語構成文字)の略記法を使っていた事が原因のようです。正規表現を「とりあえず使える」程度のままだましだまし使っている事が露呈しました。

略記法は文字クラス内で使ってはいけないんでしたっけ?[\w]=[a-zA-Z0-9_]という理解でここまでやっていたように思います。それで、過去に[\w]でうまくいかなかった経験があって、[a-zA-Z0-9_]を使い続けてきた気がします。調子に乗って\wなんか使おうとしたのがまずかった。

「文字クラス内に文字クラス(略記法)を書いた場合にどうなるか」を理解できていなかったようです。そもそも、単語構成文字(\w)の意味すらよくわかっていない事に気がつきました。ロケール情報で内容が変わるんですね。

とにかく、急ぎめで正規表現について調べておこうと思います。


本だけはあるんだよなぁ。

今までのエラー出力とひと味違う。

先ほどインストールしたPHPUnit3で表示されたエラーメッセージが、これまでと違いはっきりと差分が分かるような出力にかわっていました。

PHPUnit 3.1.8 by Sebastian Bergmann.

...FF

Time: 0 seconds

There were 2 failures:

1) testParseUri(kTest)
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ -4,8 +4,9 @@
     [authority] => user@host.example.com:80
     [userinfo] => user
     [host] => host.example.com
-    [port] => 80
+    [port] => 
     [path] => /path/to/
     [query] => query=foo
     [fragment] => frag
+    [ort] => 80
 )

/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:97
/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:27
/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:109

2) testEscapeUrl(kTest)
Failed asserting that two strings are equal.
expected string <http://user:pass@host.example.com:80/path/to/%A4%A2?q%5B%5D=%A4%B5#%A4%D5%A4%E9%A4%B0>
difference      <                                 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
got string      <http://user:pass@host.example.com/path/to/�%81%82?q%5B%5D=�%81%95#�%81��%82%89�%81%90>
/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:102
/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:27
/Users/koshigoe/c/src/snippets/php/koshigoe/test/kTest.php:109

FAILURES!
Tests: 5, Failures: 2.

アップデートに気づかずに、ずっと3.0.?を使っていた(はず)ので、よくわからないエラーとにらめっこしていました。困ったら、アサートメソッドのメッセージ引数(?)頼み。

今のところ、好印象。


何のテストかは内緒です。

無理だ。探せない。

Operaでは、"Transfer-Encoding: gzip"をつけたレスポンスを伸張して表示してくれます。ひとまず、「そういう実装がある」という事は確認できました(かなり古い話らしい)。
後は、Apacheが"Te: gzip"をつけたリクエストを受け取ったときに、"Transfer-Encoding: gzip"をつけてメッセージボディをgzip圧縮してくれるようにする方法を知りたい訳です。

探し方が悪いのか、"Te: gzip"を受けて"Transfer-Encoding: gzip"となるモジュールなりを見つける事ができずに数日が過ぎました。という訳で、諦めモード。大半は、Accept-Encodingを使ってくれているので、ある程度は帯域も節約できているように思います。

すっきりしない。できないのかなぁ?


なんで、"Te: deflate,gzip;q=0.3"をつけてリクエストしてるんだろう?

とりあえず、gzip圧縮したAtomを"Transfer-Encoding: gzip"つきでLDRとはてなRSSに登録てみたらちゃんと表示されたので、目的は"Accept-Encoding: gzip"と同じだと推測。

あと、少なくともmod_deflateではTransfer-Encodingで返す事は考えてないっぽい。なので、Apacheに関しては、"Te: gzip"とか無視のまま通り過ぎる事にしました。

完。

恥ずかしながら、HTTP/1.1でリクエストする際にPEARのHTTP_Requestが"Transfer-Encoding: chunked"を暗黙的に処理してくれているのか確認していませんでした。

サーバは、TE フィールドによって与えられた転送コーディングが受け入れ可能かを試すために、以下の規則を使う事ができる。

1."chunked" 転送コーディングは常に受け入れ可能である。"trailers" というキーワードが列挙されていれば、クライアントは、自身やダウンストリームのクライアントがチャンク形式のレスポンス中の trailer フィールドを受け入れ可能である、という事を示す。このフィールドが与えられた場合、クライアントは、すべてのダウンストリームクライアントは転送されるレスポンス中の trailer フィールドを受け入れ可能であるか、あるいはダウンストリームの受信者のためにレスポンスをバッファしようとしているか、のどちらかを示している事を意味する。

注: HTTP/1.1 は、クライアントがレスポンス全体のバッファリングを保証できるようなチャンク形式レスポンスのサイズの制限するための手段を定義しない。

2.現在試している転送コーディングが TE フィールド内に列挙されている転送コーディングの一つで、その qvalue が 0 でなければ、受け入れ可能である。(section 3.9 にて定義されるように、qvalue が 0 であるという事は、"受け入れ不可能" を意味する。)

3.複数の転送コーディングが受け入れ可能である時は、qvalue が 0 以上で最も大きい値を持つ転送コーディングが優先される。"chunked" 転送コーディングの qvalue は常に 1 である。

TE フィールド値が空か、あるいは TE フィールドが与えられていなければ、使用できる転送コーディングは "chunked" のみとなる。転送コーディングがなされていないメッセージは、常に受け入れ可能である。

TE :: ハイパーテキスト転送プロトコル -- HTTP/1.1

多分、chunkedは常に受け入れなければいけないような気がしています。qvalueを0にしたら受け入れ不可能となるのでしょうか?

とりあえず、HTTP_RequestではTransfer-Encodingが存在するレスポンスに対して特別な処理をしており、 その値がchunkedであればchunkedなデータの読み取りをしているようです。まあ、deflate問題の様に値を"==chunked"で比較しているので、複数の値が指定された場合にどうなるかは不明ですがね。

ひとまず、(大半の)予期しないchunked(?)については勝手に処理してくれるものだと考えておきます。

最近、日付関数で使える定数の存在を知りました。

以下の定数は PHP 5.1.1 以降で定義されており、標準的な日付の書式を表します。 日付フォーマット関数(date() など)で使用します。

DATE_ATOM (string)
Atom (例: 2005-08-15T15:52:01+00:00)
DATE_COOKIE (string)
HTTP クッキー (例: Monday, 15-Aug-05 15:52:01 UTC)
DATE_ISO8601 (string)
ISO-8601 (例: 2005-08-15T15:52:01+0000)
DATE_RFC822 (string)
RFC 822 (例: Mon, 15 Aug 05 15:52:01 +0000)
DATE_RFC850 (string)
RFC 850 (例: Monday, 15-Aug-05 15:52:01 UTC)
DATE_RFC1036 (string)
RFC 1036 (例: Mon, 15 Aug 05 15:52:01 +0000)
DATE_RFC1123 (string)
RFC 1123 (例: Mon, 15 Aug 2005 15:52:01 +0000)
DATE_RFC2822 (string)
RFC 2822 (Mon, 15 Aug 2005 15:52:01 +0000)
DATE_RFC3339 (string)
DATE_ATOM と同じ (PHP 5.1.3 以降)
DATE_RSS (string)
RSS (Mon, 15 Aug 2005 15:52:01 +0000)
DATE_W3C (string)
World Wide Web コンソーシアム (例: 2005-08-15T15:52:01+00:00)
PHP: 日付・時刻関数 - Manual

AtomとかRSSとか、結構流行(?)にそったフォーマットが用意されている事に少し驚きつつ、Last-Modifiedとかに使えるのか悩んでいます。

If-Modified-Since = "If-Modified-Since" ":" HTTP-date
...
Last-Modified = "Last-Modified" ":" HTTP-date
...
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616)

少なくとも、HTTP/1.1で定義されているHTTP-dateのうち、rfc1123-dateとrfc850-dateでは末尾のタイムゾーンが"GMT"で決めうちのようです。asctime-dateはタイムゾーンを使わない模様。あまりRFCと実際の実装について詳しくないので、あれですが、少なくともHTTPヘッダにおいては自分でフォーマットを書き続けた方がよろしそう。

以下は、自分の環境で先述の定数を書き出した結果です。

<?php
 
$date_const_list = array(
                         'DATE_ATOM',
                         'DATE_COOKIE',
                         'DATE_ISO8601',
                         'DATE_RFC822',
                         'DATE_RFC850',
                         'DATE_RFC1036',
                         'DATE_RFC1123',
                         'DATE_RFC2822',
                         'DATE_RFC3339',
                         'DATE_RSS',
                         'DATE_W3C',
                         );
 
foreach ($date_const_list as $date_const) {
    echo sprintf("%16s: %-16s\t%s\n",
                 $date_const,
                 constant($date_const),
                 date(constant($date_const)));
}
 
/** 結果
 *       DATE_ATOM: Y-m-d\TH:i:sP         2007-09-03T17:02:31+09:00
 *     DATE_COOKIE: l, d-M-y H:i:s T      Monday, 03-Sep-07 17:02:31 JST
 *    DATE_ISO8601: Y-m-d\TH:i:sO         2007-09-03T17:02:31+0900
 *     DATE_RFC822: D, d M y H:i:s O      Mon, 03 Sep 07 17:02:31 +0900
 *     DATE_RFC850: l, d-M-y H:i:s T      Monday, 03-Sep-07 17:02:31 JST
 *    DATE_RFC1036: D, d M y H:i:s O      Mon, 03 Sep 07 17:02:31 +0900
 *    DATE_RFC1123: D, d M Y H:i:s O      Mon, 03 Sep 2007 17:02:31 +0900
 *    DATE_RFC2822: D, d M Y H:i:s O      Mon, 03 Sep 2007 17:02:31 +0900
 *    DATE_RFC3339: Y-m-d\TH:i:sP         2007-09-03T17:02:31+09:00
 *        DATE_RSS: D, d M Y H:i:s O      Mon, 03 Sep 2007 17:02:31 +0900
 *        DATE_W3C: Y-m-d\TH:i:sP         2007-09-03T17:02:31+09:00
 */
 
?>

いつも、Last-Modifiedなどを書き出す際にフォーマットを忘れていて悩むので、楽ができればうれしかったのですが、タイムゾーンなどのあたりで結局悩むような気がします。
という訳で、存在だけは覚えておく事にします。


HTTP周りの処理(?)はフレームワークなりライブラリなりに面倒を見させるのがよい気がしますが、ちょっとした実験用スクリプトの場合はついつい都度書き(?)になってしまっています。。。

というか、そろそろHTTPリクエストを受けつける必要があるスクリプトもPythonで書くようにしないとなぁ。ついつい、楽をしてPHPで書いてしまいます(悪い事ではないのですが)。
やっぱ、PHPは慣れと配備の楽さがあります。

観察用のフィードはプログラム(PHP)なので、Last-Modifiedを返していなかった事に気がつきました。

それで、Last-Modifiedと304応答(If-Modified-Sinceだけ)を返すようにしてみましたが、まだ効果が現れません。まあ、2回のリクエストのうち、最初のリクエストが変更前か後か曖昧なので、次回のリクエストではっきりするのでしょうが。

気になっている事は、例えばBloglinesの場合、"A-Im: feed"をつけてリクエストしてきます。一方で、If-Modified-SinceやIf-None-Matchは確認できていません。"A-Im: feed"は「If-Modified-Sinceが必要ではなかったのか」という疑問もありますが、それ以前に、"A-Im: feed"を理解しないサーバやAtom以外のフィードに対する配慮はどこに行ったのか、という事が気になります。

Feedpathの"A-Im: channel"も、何をしたら望ましいレスポンスを返せるのか分かりません。

んー、分かりやすい条件付きGETを受け付けてくれるとうれしいんだけどなぁ。それは甘えですかね。

どこで何を調べたら、"A-Im: feed"とIf-Modified-Sinceなどによる枯れた(?)条件付きGETとの関係を探る事ができるのでしょうか?


Last-Modifiedと304応答に対応したためか、BloglinesとFeedpathからIf-Modified-Since付きでリクエストされるようになりました。ついでにNewsGatorからも。
という訳で、ひとまず無問題です。

mod_deflateでフィルタを有効にしただけでは、TEヘッダフィールドは使えないのでしょうか?

以下の場合は、圧縮されたものがかえってきます。

% telnet debian.local 80

GET /test.html HTTP/1.1
Host: debian.local
Accept-Encoding: gzip
Connection: close

一方、以下は圧縮されずにかえってきます。

% telnet debian.local 80

GET /test.html HTTP/1.1
Host: debian.local
TE: gzip
Connection: TE, close

Apacheの設定が不足しているのか、リクエストに不足(不備)があるのか。よくわかりません。

転送コーディング関連のディレクティブとかがあって、それをいじらないとだめとかなのかな。というか、そもそも、ApacheでTEヘッダフィールドのgzipを理解してくれているのだろうか。RFCだとchunkedしか定義されてないんですよね?他は拡張?(transfer-extension)だかなんだか。多分、gzipとかの圧縮まわりは(Apacheでは)サポートされているんじゃないかと期待しているのですが、どうなんだろうか。

とりあえず、もう1回Apacheのドキュメントを眺めるしかないですね。


んー、"Te: gzip"の意味をはき違えてるのかな?というか、"Te: gzip"が"Accept-Encoding: gzip"と同じ動作を期待するものだとして、大多数のHTTPクライアントが対応できるものなんだろうか?
はてなRSSやLDRからのリクエストにgzip圧縮したRSS/Atomを返すにはどうすべきだろうか。はてなRSSとかLDRのドキュメント類を見たら書いてあるのかな?

ボス退職

| コメント(1)

ボスが8月いっぱいで退職なされました。本来は、こんな場所に書く事ではないような気もしますが、折角なので書いてしまいます。

改めて、お疲れさまでした。
2年半くらいご一緒させて頂きましたが、本当にお世話になりました。

自分にとって最初の"技術者としての上司"だったので、感慨深いものがあります。入社したての頃の"獅子は我が子を千尋の谷にぶっ込む"かの様な愛の鞭は今でも忘れられません(注: 社外の方に誤解を招くかもしれませんが、不可抗力の出来事なので深刻に受け取らないでくださいね)。あのおかげで、心構えができた様にも思えます。

ボスには特に、"技術者が働きやすい環境づくり"に多大なご尽力を頂きました。今の社風があるのも、多くはボスの影響のように思います(勿論、ドンや幹部(?)あっての事ですよ)。チームを組んだ開発について、今の開発プロセス(スタイル)しか知りません(経験していません)が、2年以上の業務の中で息苦しさを感じた事がないという事は恵まれた環境だと思っています。

技術面においても、やたらと聞きたがりな自分を抜群のスルー力を発揮する事なく、ご指導いただけた事に感謝しています。"虎の威を借る狐"の如くある自分ですが、これを"ちゃんす?"と考えより一層の成長をしていきたいと思っています。

心細く寂しい思いはありますが、やりたい事があっての前向きな退職という事で、心より応援させて頂きます。どうぞお体にお気をつけて、これからのご活躍をお祈りします。

追伸:エアージャケット(?)はお忘れなく。


なんだか、変な事を書いている気がしますが、切り替えのきっかけのような意味を込めて、ここに書かせてもらいました。

んー、こういうのは表に書く事じゃないのかな。一般常識がよくわかりません。しゃっちょこばりすぎてる気がしないでもないし。けど、知らんぷりしておきます。
自分がしてもらった事しか書いていないように思いますが、会社への貢献度などは語るまでもなく。まさに獅子奮迅のご活躍!いやぁ、足を引っ張ってばかりでした。

さあ、第二部の始まりだ。究極生物なんてこわくないっ!そのうち考える事をやめるんだものっ!、、、ん?

「ゆー、ふぁいやー」なんて言われないように気をつけないとね。

これまで確認した事がなかったという事実に思い至ったので、少し観察中です。

対象は有名どころのアグリゲータ(Webのフィードリーダーとかブログサーチ(ping)とか、とりあえずRSS/Atomを目的にしているボット)です。

Perlっぽい所はTEをよく使っているようですね。A-Imを使っているところもありますが、これは少数派。持続接続かそうでないかはまちまちのようです。

恥ずかしながら、TEとA-Imは何の事かよくわかっていなかったので勉強になりました(まだ理解しきれていませんが、なんなのかは覚えました)。まだまだ理解しきれてはいないので、おいおい調べていくつもりです。

TEを使うのは、keep-aliveでchunkedでdeflate(gzip)なあたりでほげほげという事でしょうか。"Connection: close"と"Accept-Encoding: deflate, gzip"であれば、安全?帯域について考えたときに足を踏み入れる領域でしょうか。

A-ImをつけてリクエストするUAは、どうもIf-Modified-Sinceなどはつけないようです。"delta encoding"だから不要という事でしょうか。BloglinesがA-Imをつけているので少々気になるところです。

TE

内容コーディングは内容を圧縮する事が念頭に置かれていますが、転送コーディングは、内容をあるエンコード方式に従って転送するという事を意味します。
転送コーディング :: [Studying HTTP] Message Body
転送コーディング値は、ネットワークを通して "安全な転送" を保証するために、エンティティボディに適用されている、する事のできる、する必要のあるエンコーディング変換を示すために使われる。
転送コーディングは、元のエンティティではなくメッセージの特性である、という点で内容コーディングとは異なる。
3.6 転送コーディング :: ハイパーテキスト転送プロトコル -- HTTP/1.1

A-Im

A-IM リクエストヘッダフィールドは Accept に似ているが、レスポンス中に受け入れ可能な instance-manipulation (section 10.1) を制限する。
section 10.5.2 にて明示されるように、レスポンスは複数の instance-manipulation を適用した結果であるかもしれない。
10.5.3 A-IM :: HTTPにおける差分エンコーティング
ステータスコード 226 は、Delta encoding in HTTPで定義されています。
サーバは、現在のインスタンス (現時点でのエンティティ) に差分コーディングを行い、その差分を返しました。実際に、どのようなインスタンス操作が行われたかは A-IM ヘッダフィールドに記述されています。
226 IM Used :: [Studyng HTTP] HTTP Status Code

久しぶりにFeedpathを触りましたが、feedpath.comでfeedpath.jpの証明書が使われているというアラートが出ました。どうしたのでしょう?


A-Imについて追記。"A-Im: feed"の場合は、以下のように動作するようです。

Atom フィードのダウンロード速度を上昇させる Apache モジュール。仕組みはフィルタモジュールとして動作し、Content Type が application/atom+xml の場合、クライアントから送られてくる If-Modified-Since ヘッダを調べて、新しい記事のフィードのみを配信するという仕組み。
mod_speedyfeed : NDO::Weblog

なるほど、観察中のものはRSS2.0なので、いくらクロールしてもIf-Modified-Sinceをつけてこないという訳ですかね。

一方、"A-Im: channel"はよくわかりません。RSS用の独自モジュール?

プロフィール

このアーカイブについて

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

前のアーカイブは2007年8月です。

次のアーカイブは2007年10月です。

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