トップ «前の日(06-01) 最新 次の日(06-03)» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2003-06-02

_ 2003F1モナコGP (13:49)

予選2日目

すっかり忘れていて、また予選1日目を見逃した。予選1日目にバトンが3番手だ、すげーと思いきや、午前中のセッションで事故って、予選2日目はキャンセルかよ。で、酒を飲みながら斜め見していたらあっさり終わってしまった。なにやらフェラーリがダメな模様。でもあくまでも予選2日目のコンディションにおいてダメだったってだけだよな。決勝で復活して、いろいろありながらも結局勝っちゃうパターンだったりして。

決勝

いまいち盛り上がりに欠けたけれども、地味に面白いレースだったなー。バトンは結局出られなかったのが残念だった。やつも絡むとさらに上位の動きが面白くなっただろうに。ラルフは予選でせっかく上げた株を、本戦でさげてしまったなー。特にモントーヤの対比で見るときつい。ライコネンの株は地味に上がり続けている。あとアロンソも。ヴィルヌーヴの株はもう底値かな。本人だけが悪いんじゃないだろうけど、これだけ結果が出ないともう本格的にダメって印象になってくる。クルサードも内容は悪くないのに、結果が比例していない感じ。バリチェロはクルサード以上にぱっとしなかった。

チャンピオンシップの動きを見ていると、なんかかんかいって今年のレギュレーション変更で展開は面白くなっているな。一気にフェラーリが巻き返すかと思いきや、ここで足踏みしてくれたおかげで上位5、6人、3、4チームくらいまではまだ可能性がもてる感じになっている。どのくらいまでこういう展開で引っ張れるかな。

_ アナログ、デジタル、プログラムまで500ステップの電子回路学習キット発売 from MYCOM PC WEB (13:49)

むむむ、ちょっと欲しいかも。でも自分で遊んでいる暇はなさそうだから、ムスコのおもちゃとして。って、ムスコ(現在2.9歳)がこんなので遊べるようになるのはいつだ?

_ ソニー、2003年度経営方針説明会で新プラットホーム「PSX」を公開 from GAME Watch (13:49)

いくらくらいで出せるのかな? 10万円以下だったら結構現実的だし、まかり間違って5万円程度(量産効果が出た後の値下げ価格)だったりしたら爆発的に売れるだろうな。東芝のRD-X2の腐ったUIにうんざりしている(でもHDD+DVDレコーダーというコンセプトは素晴らしい)人間にとって、PS2プログラマがUIを作れるHDD+DVDレコーダーってのは結構魅力があるしな。できればSDKを有料で一般公開してくれたりしないかな。

_ Eclipseグループ、開発効率の向上のためにツールの機能を拡張へ from ZDNet (13:49)

>Eclipseのオープンソフトウェアを、開発ツール以外のソフトウェアでも利用できるように変更することなどが盛り込まれている

おお、俺が昔「誕生から10年、ブラウザはまだまだ進化する? from ZDNet」で書いたEclipseのインターネット統合クライアント化が現実的になってきたかも。現時点だとプログラム以外のテキストを入力するのがつらいんで、まずは日本語の普通の文章を入力しやすいエディタのサポートが欲しいな。っつーか、ものすごく優先順位が低いToDoリストには載っているんだけど、多分そんなことをやる余裕はないだろうからなー。でもナチュラルにテキストをCVS管理できるEclipseはかなり便利なんだよなー。


2005-06-02

_ Re: 純粋後ろめたさ批判 (11:04)

純粋後ろめたさ批判で書かれている話は気持ちはよくわかるけど、この手の公憤・思想に属する行動原理は、なかなか実際(直接的)には取りにくい。というか、俺の中での優先順位的には、「結果を出すこと」が優先で、「理想を追うこと」は二の次だ。

この手の活動をしていて一番コスト(特に精神的な)がかかるのは、今回のような人間関係・感情的なものに対応する部分であり、モチベーションを維持するためには、そこにかけるコストを最小にするアプローチが、戦略的に有効だと考えている。もちろん商売でやっているなら話は違ってくるけど(あらかじめ十分な準備を行うべきだし、何か起きたときの対策のコストを惜しんではいけない。逆に言うと、商売じゃないからこそ、その手の部分に手を抜いてもある程度は許されると思っている)。

ちなみに、アフィリエイト系サイトからのクレームってのは今までも何件か(メール等の非公開窓口経由で)来ているんで、BigBangさんが初めてというわけではない。ただ、今までのクレームは「要件のみ」といった感じで、具体的に何をどう考えているのかさっぱりわからなかったんで、その点BigBangさんのように公開で何をどう考えているのか表明してくれると、問題点が明確化するし、情報の共有・公知もできるんでありがたい。

で、自分にとって「結果を出す」ための一番いい方法が現状の対応(一番クレームの原因となると思われるポイントを、機能性を損なわずにつぶしておく)であり、「インターネットにおける意識改革・環境整備のために戦う」という選択肢は、割に合わなすぎて取る気になれない。まあ現時点ではそっち方向のモチベーションも余力もないってだけなんで、そのうちそういうのがやりたくなったらやるかもしれないけど(ただ俺は、議論(バトル)ならやってもいいけど、政治は趣味じゃない。政治的な議論ならばまあ範疇か)。

自分の(基本的な立ち位置としての)思想は主に行動で示しているつもりなんで、そういう間接的な表現+今回のhankakueisuuさんの発言とか関連するいろんな人の発言によって、世の中(インターネット)が(俺にとって)過ごしやすい方向になるといいなー、程度には思っている。現在俺がその手の活動にかけられるモチベーションは、せいぜいその程度のもの。

とか書くと、せっかくのhankakueisuuさんの政治的な発言の効果が薄れちゃうかもしれないけど、ああいう表現で書かれちゃうと、それを放置しておくよりはつつき返した方が俺的には気が楽なんで、できるだけ穏当な表現を使って書いてみた。

_ changes.xmlのパース (18:55)

はてなダイアリーの更新時刻情報としてchanges.xmlが用意されたんで、従来のRSSからこっちに切り替えるべきだろうなー。はてなダイアリーの規模だと更新が激しすぎてRSSだといろいろ問題があったし。

でもchanges.xmlのパース処理って用意してないんで書かないと。XMLとして処理せず、単にパターンマッチで処理した方が効率が良さそうだな。

<?php
mb_internal_encoding('sjis');

$srcUrl = 'http://d.hatena.ne.jp/changes.xml';
$xml = mb_convert_encoding(file_get_contents($srcUrl), mb_internal_encoding(), 'utf-8');
if (!preg_match('|updated="(.*?)"\s+count="(.*?)"|i', $xml, $matches)) {die;}
$baseTime = strtotime($matches[1]);
$count = intval($matches[2]);

if (!preg_match_all('|<weblog\s+name="(.*?)"\s+url="(.*?)"\s+when="(.*?)"\s*/>|', $xml, $matches, PREG_SET_ORDER)) {die;}
foreach ($matches as $item) {
	$title = $item[1];
	$url = $item[2];
	$lastmodified = $baseTime - intval($item[3]);
	echo $title . ' ' . $url . ' ' . date('Y-m-d H:i:s', $lastmodified) . "\n";
}

?>

とか。

Tags: PHP XML

2006-06-02

_ Zend_Search_HyperEstraier設計中 その3

だいたい以下のような形で固まりつつある。

  • Zend_Search_HyperEstraier - ユーティリティクラス
  • Zend_Search_HyperEstraier_Document_Abstract - ドキュメント基底
  • Zend_Search_HyperEstraier_Document - 通常のドキュメント
  • Zend_Search_HyperEstraier_Document_ListItem - ドキュメントリストのアイテムとしてのドキュメント
  • Zend_Search_HyperEstraier_Document_SearchResult - 検索結果のアイテムのとしてのドキュメント
  • Zend_Search_HyperEstraier_SearchCondition - 検索条件
  • Zend_Search_HyperEstraier_SearchResult - 検索結果
  • Zend_Search_HyperEstraier_Node_Client - クライアントAPI
  • Zend_Search_HyperEstraier_Node_Document - クライアントAPIと連携するドキュメント
  • Zend_Search_HyperEstraier_Node_NodeInformation - ノード情報
  • Zend_Search_HyperEstraier_Node_UserInformation - ユーザー情報
  • Zend_Search_HyperEstraier_Node_Api_Abstract - コアAPI基底
  • Zend_Search_HyperEstraier_Node_Api_Client - コアAPIクライアント用
  • Zend_Search_HyperEstraier_Node_Api_Master - コアAPIマスター用

分散クライアントは、URIとノードの対応をどこで管理するのが妥当か思いつかない(っつーか、毎回URI検索して既登録だったらそのノードを使い、未登録だったら空いているところに登録、とかしかない気がするんだけど、それじゃあ分散させる意味が薄くてやる気がなくなった)んでいったんキャンセル。

あと結局ほぼノードAPIそのままのコアAPI層と、アプリケーションから使うクライアントAPIを別にした。ノードAPIを直で使う場合は、

$clientApi = new Zend_Search_HyperEstraier_Node_Api_Client($url, $username, $password);
$nodeInfo = $clientApi->getInformation();
$documentDraft = $clientApi->getDocument($uriOrId);
$document = new Zend_HyperEstraier_Document(documentDraft);
$document->text .= 'added text';
$document->modified = time();
if (!$clientApi->putDocument($document)) {
  die('cannot save');
}

なんて感じ。クライアントAPIを使うと、

$client = new Zend_Search_HyperEstraier_Node_Client($url, $username, $password);
$document = $client->getDocument($documentUri);
if (!$document) {
  $document = $client->createDocument($documentUri);
}
$document->title = 'title';
$document->created = time();
$document->modified = time();
$document->keywords[$keyword1] = $score1;
$document->text = 'text';
$document->hiddenText = 'hidden text';
$document->foo = 'foo'; // 非システム属性
$document->setAttribute('foo', 'foo'); // 上と同じ
if (!$document->save()) {
  die('cannot save');
}
$document->updateAttributes(); //属性だけ更新する場合
$document->delete(); // 削除

なんて感じ。

肝心の検索は、

$searchResult = $client->search('phrase'); // フレーズ検索

// 複雑な検索条件
$condition = $client->getSearchCondition();
$condition->phrase = 'phrase';
$condition->attributes[] = 'attribute STRINC str';
$condition->skip = 5;
$condition->max = 10;
$searchResult = $condition->search();

foreach ($searchResult->hints as $word => $count) {
  // 検索ワード出現回数
}
foreach ($searchResult->links as $nodeUrl => $nodeInfo) {
  // ノード情報
}
foreach ($searchResult as $document) {
  $uri = $document->uri;
  $title = $document->title;
  $created = $document->created; // @cdateをYYYY-mm-dd HH:ii:ss形式で
  $snippet = $document->snippet;
}

なんて感じ。API周りのテストまで書き終わったんだけど、検索条件周りがまだいまいちすっきりしないんで、その辺をもうちょっと練ってみよう。