_ Re:NaverのBOTさらに悪質化 from ただのにっき (13:50)

• NaverのBOTさらに悪質化 - http://sho.tdiary.net/20030820.html#p01

>>ついに「GoogleBot」を詐称するようになったもよう。

うわー、これは最悪だ。これはもう、Naverの所有するすべてのIPアドレスに対してdenyするしか、拒否する方法はないかな。どこかにNaverの所有するIPアドレス一覧はないだろうか。ちなみにうちのアクセスログに残っていたNaverBotのIPアドレスは、

61.78.61.163
61.78.61.162
61.78.61.170
61.78.61.193
220.73.165.81
218.145.25.77
218.145.25.81
218.145.25.113 

ただ、NaverBotと名乗っているすべてが本物のNaverBotとは限らないけど。

もうちょっと調べてみた。これらのIPアドレスに関するアクセスログは、

dloader(NaverRobot)/1.5
minibot(NaverRobot)/1.0
GoogleBot
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/3.01 (compatible;)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

なんてのが残っていた。普通のブラウザっぽいUserAgentも結構残っている。これらのIPアドレスはBot以外でも使っているのかな？　あるいはもしかしたら、ランダムにUserAgent文字列を適当に付け替えるブラウザ（って確かあったよね）とかを使ったアクセスだったりして。

ちなみにうちも、robots.txtへのアクセスだけはGoogleBotだった。

_ DropCash (10:57)

ウェブロについて考える。６ 295（←infoseek CGIはリファラーチェックで外部からのリンクを弾くので、URLをアドレス欄に貼り付けて飛ぶべし）で紹介されていたTypeKey＋PayPalな投げ銭システムに試しに登録してみた。

TypeKeyのアカウントは試しに取ってあったんで、それを使ってDropCashにログイン。登録にPayPalのアカウントも必要なんで、それを取ってきたら登録完了。個人情報はTypeKeyとPayPalに登録し、DropCashはその必要最低限だけを利用する形。

アカウントを取ると、「Create a new campaign」から「どういう意味で」「いくらを目標に」お金を集めるかの登録を行う。ってあたりからは、何となく「金くれ」というよりは、「○○するために○○ドル集めています」という目的ありの募金を行ったりすることを中心に考えているのかな？

でも別に俺には目的はないんで、何となくなcampaignを試しに作ってみた。

• 「DropCash:くれくれたこら」

ASCII以外は全部実体参照化して登録されるんで、一応日本語も何となくは通るっぽい（けど、ブラウザ依存かも）。あと、登録したら速攻でcontactのところに書かれているgmailアカウントから「タイトルとURLの表現にバグがあったから直しておいたね」というメールが来たんだけど、これって開発者からかなー？　さすがベータ版＆リアルタイムで見ているのかな？

募金はPayPalのアカウントさえあればできるっぽい。ただ、コメントを残すためにはDropCash（というかTypeKeyのメール通知付き）のアカウントが必要な模様。

海外のblogger（って単語初めて書いたよ）は、元々PayPalは使っているだろうし、TypeKeyの導入さえ進めば結構流行るかもね。OpenSourceプロジェクトの寄付募集なんかも、何となくなPayPalアカウントを使うのではなくて、DropCashを使って目的別に目標金額を決めてやるのもいいかもしれない。あと、何かイベントを開催するにあたっての費用徴収にこれを使って「いくら集まったらやりますよ」と非均等前払い制にするのもいいかもね。

開発者のblogがあった

もう1個作ってみた

• 「DropCash:世界征服資金」

って、こんなふざけたのばっか作ってていいのか。まあ現時点では、どんな利用法でも（違法でない限りは）いろいろ試してみた方がいいよねってことで。

_ メールニュース死んでた (12:08)

PHP再インストールの影響で、blogmapメールニュースが死んでいた＆復活させるときに間違って2通同じものを送っちゃったかも。ごめんなさい。

_ いやー、今日もいい天気だねー (12:20)

今度は風景モードで撮ってみた。ちゃんと明るく撮れたかな？

全然だめじゃん

と思ったら、ホワイトバランスの方の設定で変えるのかな？　今度はホワイトバランスを晴天にして撮ってみよう。

_ trackbackによる関係図(13:26)

ついでに、ウェブロについて考える。６ 290（infoseek CGIにつきURLをアドレス欄にコピペの上移動。っつーか、ime.nu経由とかで書いた方がいいのかな？）の、

ishinaoさんが実験的に見せで作ってたTrackbackをツリー表示にして追えるってツールだけどあのへんって進化止まったままだなあ。残念だ

に関連したネタ。

結局あの当時はまだtrackbackがさほど使われていなかったってこともあって、ある特定の記事に対するtrackbackを追ってみたところで全然面白い情報が得られなかったから（ふつうにWebブラウザでtrackbackを追っていくのと大して変わらん）、やる気がなくなったけれども、ずいぶんtrackbackも普及してきた今ならば、結構遊べるかもしれない。

ただ、現在はtrackback数自体はずいぶん増えたけれども、trackbackの情報の質は低下している（お返しtrackbackとか、うなづきtrackbackとか）ように思うんで、ある特定の記事に対するtrackbackを追うことの面白みのなさは、大して変わっていないんじゃないかと思う。だけど、一つ一つのtrackbackを追跡すること自体は面白くなくても、trackbackによってつながるサイト（記事）間の連携状態を観察するのはそれなりに面白そう。

だから、もし今からその手のものを作るとしたら、いくつかのサイトをseedにして、そのサイトへ送られるtrackbackを監視しつつ連鎖的にたどっていくクローラーを作って、はてな地図みたいな関係図として表示するツールとかかな。ある程度の期間、データを集めて、trackback数を重みとして評価すると、単なるツリー表示とは違った関係図が描けそう。

まあblogmapで収集しているリンク・被リンク情報を解析しても似たようなものは作れるだろうけど、blogmapのデータ収集対象は単なる個人Webサイトってだけなんで、そこから得られるメタデータ量が少なくて解析しにくいんだよな。trackbackベースで監視すると、そのターゲットは狭義のblog系サイトのみに絞られるだろうから、メタデータを使った解析がやりやすそうだ。

自分で作る気はあまりないんで、誰かが作ってくれるとうれしい。

_ キーワードリンクの検索対象 (14:06)

キーワードリンクの検索対象を、tdiary.ishinao.net内Estraier検索から、ishinao.net内にあるさまざまなEstraier検索をestmerge.cgiを使って串刺し検索するように変更した。blogmapのblog検索とnews検索が含まれるんで、かなり使える検索結果が出ると思う。

Estraierを使うと、こうやって異なるシステムに対して作成した複数のインデックスを、まるで一つの検索インデックスに対して検索するかのように使うことが標準でできるんですよ。この機能ってかなり使えると思って前から話題にしているんだけど、あんまり使っている例が見あたらないのがもったいない。

ひとまず試しに、このセクションではやたらとキーワードリンクを張りまくってみたんで、試しにクリックしてみてください。リンク文字色とかデコレーションをオフにしてあるんで、通常のブラウザではどこがキーワードリンクかわかりにくいでしょうけど、適当にマウスカーソルを移動してみて、クリックできそうなところを押してみるといいです。

あとついでに、結構な負荷をかけて生成しているにも関わらず、大して利用者のいないblogmapのblog検索とnews検索の宣伝も兼ねておこう。

_ これか？ (15:02)

最近全然テレビ見ないんで、「（検閲：創造力のない奴→発想が豊かな人）ほど、（検閲：他人の創造力にケチをつける→他人に対する要求が高い）」を読んでも何がなんだかさっぱりわからなかったんだけど、たぶん「仲間由紀恵は悪くないともっぱらの“月９”ドラマのデタラメ」のことを言っていたんだね。

_ uconvインストール (16:16)

tDiaryのGoogle検索キーワード表示が文字化けしているんで、uconvをインストールしてみたら、ちゃんと表示されるようになった。なんとなくruby 1.8系は標準でUTF-8対応しているもんだと思いこんでいたよ。

ところで、rubyの文字コード変換処理って、この関数を使っちゃうのが標準なんですか？　estrelate.rb（ここで使っているEstraierを使った「似た話題の日」プラグイン）をrubyで書き直そうと思ったんだけど、rubyのリファレンスマニュアルをみてもよくわからなかった。

↑わからなかったのは

uconvライブラリの使い方じゃなくて、uconvライブラリを使って文字コード変換処理を書くことが、一般的（可搬性がある書き方）なのかってことね。

ruby 1.8はiconvか

ruby 1.8が、標準でUTF-8対応したってうろ覚えの記憶は間違っていなかったけれども、ライブラリが違ったのか。従来は独自ライブラリのuconvだったけど、ruby 1.8からはiconvのラッパーライブラリを標準搭載したってことかな。ってことは現状は、

• uconvとiconvの間で互換性はない（uconv用に書いたコードが、自動的にiconvでも動いたりはしない）
• ruby 1.8より前に書かれたコードでは（UTF-8対応は）uconvが標準的に使われていた
• ruby 1.8以降はUTF-8対応はiconvが標準的に使われるであろう（※それとも過去互換性のためにuconvを使う方が主流だったり、あるいはどちらでも使えるようなラッパをかますのが主流だったりするのかな？）

って感じなんでしょうか？　ruby uconv iconvでググってみてもいまいちその辺に関する情報が見つからない。

_ 今日のスポクラ (11:19)

いつものメニューだったんだけど、1人マシンを占有している人がいて、マシンが一つできなかった。いやまあ本格的に（何セットも）やっている人だったから正しい使い方なんだろうし、インターバルの時にちょっと割り込ませてもらうこともできただろうけど、そこまでしてやらなくてもいいしなー。そういや今日もバイクは90W20分やったんだけど、今日は1度も脈拍数の警告範囲に（というか170回/分すら）入らなかった。もう体が慣れたのか？　人間の体の順応性はすごいなー。

_ 今まで何度かやったのに (15:42)

またやって、しかもしばらく気がつかなかったから、ここに書いておこう。

メール関連をインストールする前に、PHPをインストールしてしまうと、メール関連の関数は使えなくなりますよーーー。

メール周りは面倒くさいから、後回しにしがちなんだよなー。

_ PHPカンファレンス2006

フレームワークのパネルでZendの回し者になってきました。ネタはいろいろ用意してあったけど、話の流れでほとんど言う暇なかったな。

最後のZeev氏のプレゼンが終わるまでいたんだけど、懇親会までの待ち時間の間に、眠くて吐き気がしてきたんで、懇親会には出ずに帰ってきてしまいました。挨拶できなかった方々すみません。

そういやZeev氏がプレゼンの最後の方で出していた、ZActiveRecord（今はZend_Db_Table）とかZMail（今はZend_Mail）とかZSearch（今はZend_Search_Lucene）とかは、Zend Framework 0.1.1が発表される以前のちょー古い仕様で、そこで使われていたサンプルコードは現状のZend Frameworkのコンポーネントとは全然違っているんで、あれは信用しないように。っつーか、いったいZeev氏はいつのプレゼン資料を使い回しているんだ？　あれを見てちょっとげんなりした。

一応事前に準備しておいたネタ帳は以下のような感じ。

• [各フレームワーク] 現状
  • Preview 0.1.5が7/10に出た。
  • 高機能な（RoRやSymfonyのような）フレームワークとしてはまだ足りないが、基本的なコンポーネントは一通りそろっている。
  • Zend Studioとかと連携しての開発支援系は考えているらしい（昨日のセミナーネタ）。Widgetとか言っていたけど、詳細不明。
  • 完成度は、コア部分は実用レベル。流行りもの系（フィードとかWebサービスとか）はまだビミョー。実際に使う人が増えないと、この辺の品質は上がらないんじゃないかな。たぶん開発者もテストケースとかは書いているけど、アプリケーション風の使い方はしていないように思う（結構基本的なところでダメだったりするし）。
• [各フレームワーク] 今後
  • 一応今年中には正式版1.0.0が出るらしい。今年9、10月あたりという説もある。まだコンポーネントが足りてない気がするけど……。
  • 開発の様子は、SubversionレポジトリやMLを見ている限りでは、ちょっと停滞気味かも。がんがん新しいコードが追加されている感じはない。
  • proposalはいろいろ出ている。
  • バグ管理とかドキュメント管理とかの仕組みも、ようやく安定してきた（それまではいろんなツールをとっかえひっかえ状態だった）。
  • PEARが5〜6対応を推し進める方向に向かっているようなので、そちらとのバランスを取らないとリソースの無駄遣いになりそう。と思ったんだけど、PEARとZend Frameworkは全然別物だし、品質とか知財の関係とかで、PEARのような既存のライブラリをZend Frameworkが取り込むことはないそうだ（昨日のセミナー）。
• [meta] PHPフレームワークは普及するのか？そもそもフレームワークを使う価値はあるか？
  • 基本的に、フレームワークの考え方自体はあらゆるシーンで使える。フレームワークは先人の知恵がコード化されたもの。
  • 実際の制作物にフレームワークを使うかどうかは、ケースバイケース。ただし、環境さえうまく整えることができるならば、かなり小規模なケースでもフレームワークを採用するメリットが得られる。逆に環境が用意できない場合は、フレームワーク的な考え方だけを利用するか、あるいは小規模な自作フレームワークもどきを使うなどもあり。
• [meta] フレームワークの選択基準
  • フレームワークを知らない人は、何でもいいからWebアプリケーションフレームワークの考え方を身につけた方がいい。ある程度メジャーならばなんでもいい。
  • 実用レベルでの採用を考えると、コードの品質、採用実績、将来性、環境、パフォーマンスあたりが検討材料となる。
  • うちの場合は、PHP5への完全移行を決め、それに伴い環境的にPHP5にフル対応しているものを選択し、その中で将来性、コードの品質を重視してZend Frameworkを選んだ。
  • コードの品質というのは、PHPのライブラリでは、バグの少なさよりも、いざというときにソースを読んで自分で対応（修正）しやすいかどうかが重要。もちろんバギーすぎるのは困るが、ドキュメントも実績も十分ではないPHPのライブラリでは、自分のコードと同程度にライブラリのコードを追う必要がある。
  • そういう意味では、コード規模がまだ小さく、きちんとした規約に基づいて書かれ、異常系処理が例外ベースで統一されたZend Frameworkが、相対的にベストだった。
  • 現時点だけで言うと、他のフレームワークの方が便利なことが多いとは思う。
• [各フレームワーク] バージョンアップ...どう？
  • まったく不明。まだそのあたり（運用後のフレームワークのバージョンアップ対応）まで考えるレベルまで来ていない。
  • ただ、設計的に各コンポーネントの結合度が比較的低く、インターフェースもきれいな設計のものが多いので、比較的未来は明るいんじゃなかろうか。
• [各フレームワーク] アプリにどこまで食い込むか？(コアonly or CMS方面へ...)
  • 現状では、アプリケーションレイヤーよりのフレームワークというよりは、独立したライブラリレイヤーのフレームワークといった位置づけ。というか、疎結合で部分的に他のライブラリと差し替えて使えるように設計してある（昨日のセミナー）そうだ。
  • ただし、ZAppのようなアプリケーションフレームワーク的な方向のものもproposalとしては出てきているし、Zend自体もZend Studioと組み合わせての開発支援は考えているみたいなんで、Rails的なアプローチではなく、たぶんマイクロソフトがVisualStudioでやっているようなアプローチに近い支援機能がくるんじゃないかなー。
  • ちなみにうちで作っているWEBXPというフレームワークも、Zend Frameworkのコンポーネントを組み合わせてアプリケーションレイヤーよりの作業を効率化するための仕組み。Zend Frameworkは、フレームワーク on フレームワーク的なものを作るのに向いている。

他にも現地でパネルが始まるまでの間にいろいろ追記したんだけど、W-ZERO3[es]が熱暴走して追記した分が失われてしまった。Zend Frameworkを選択した理由とか、他のフレームワークと比較しての特徴とか、いろいろ書いていたんだけど。

_ そういや

Zend FrameworkがOracleにいつ対応するのか質問していた人がいたけど、現時点でもZend_DbにはZend_Db_Adapter_Oracleとか入っているけど、これがちゃんと動かないってことなのかな？　PDO OracleドライバーもすでにPHP 5.1.4とかには入っているはずだけど、Zend_Db_Adapter_Oracleがあるから、わざわざZend_Db_Adapter_Pdo_Oracleの方は作られないんじゃないかなー。

_ PHP 6のUnicodeサポート

昼飯の時に「たぶんバイナリ文字列とUTF文字列という二つの文字列型が追加されて、文字列処理関数は型を見て処理を振り分けるんじゃない？」と100％想像で言ってしまったんで、気になってPHP6-devのソースを見てみた。

zend_variables.cの

   switch (Z_TYPE_P(zvalue) & ~IS_CONSTANT_INDEX) {
       case IS_CONSTANT: {
           TSRMLS_FETCH();

           if (UG(unicode)) goto dtor_unicode;
       }
       case IS_STRING:
           CHECK_ZVAL_STRING_REL(zvalue);
           free(Z_STRVAL_P(zvalue));
           break;
       case IS_UNICODE:
dtor_unicode:
           CHECK_ZVAL_UNICODE_REL(zvalue);
           free(Z_USTRVAL_P(zvalue));
           break;
       case IS_ARRAY:
       case IS_CONSTANT_ARRAY:
       case IS_OBJECT:
       case IS_RESOURCE:
           zend_error(E_CORE_ERROR, "Internal zval's can't be arrays, objects or resources");
           break;
       case IS_LONG:
       case IS_DOUBLE:
       case IS_BOOL:
       case IS_NULL:
       default:
           break;
   }

あたりを見ると、やっぱり従来型のバイナリ文字列とUNICODE文字列の二つの文字列型になるみたいだね。で、各文字列処理関数ではzend_builtin_functions.cから適当に抜き出した、

ZEND_NAMED_FUNCTION(zend_if_strlen)
{
   zval **str;

   if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) {
       ZEND_WRONG_PARAM_COUNT();
   }

   switch (Z_TYPE_PP(str)) {
       case IS_UNICODE:
           RETVAL_LONG(u_countChar32(Z_USTRVAL_PP(str), Z_USTRLEN_PP(str)));
           break;

       case IS_STRING:
           RETVAL_LONG(Z_STRLEN_PP(str));
           break;

       default:
           convert_to_text_ex(str);
           RETVAL_LONG(Z_UNILEN_PP(str));
           break;
   }
}

みたいな感じで、やっぱりUNICODE文字列かどうかで単純に処理を振り分けているみたい。UNICODE文字列とバイナリ文字列が入り交じった状態の比較とか、文字列結合とかがどうなるかまでは追ってない。