_ モヒカン族の一員になりました (22:48)

_ 久しぶりにメールサーバーを設定したら (13:33)

いろいろ手間取ったのでポイントだけメモ。

• vpopmailではドメインまでアカウントに含めなきゃ認証とおんねーんだよ！（それに気づかずに、authdaemondの設定を何度やり直したことか）
• qmail-scannerでspamassassinとclamavを使う場合は、spamdとclamdの権限に気をつけないと、チェック用のテンポラリ領域に書き込めなかったりして、何が原因かわかりにくいことになるぞ！　spamdとclamdを同じユーザーにして、setuidgidしたら通ったけど、単にsetuidgidし忘れていただけのような気もする。っつーか、qmail-scannerのパーミッション絡みではまるのってこれで何度目だろう。
• RedHat系で、extern errnoを#include <errno.h>するのは覚えていたけど、#include <sys/time.h>を#include <time.h>にするのは忘れていた。
• そういやcourier-imapって、認証系がcourier-authlibに分離していた。最新版の手順をまとめ直しておかないと。
• clamavって結局ソースからインストールした方が良さそうな感じ。
• courierとspamassassinの綴りが面倒くさすぎ！　何回打ち間違えたことか。

_ 一時しのぎの対策 (15:15)

オープンソースBlogとWikiに影響する脆弱性、各社が修正リリース関連で、

相変わらずpear upgrade XML_RPCするとpingサーバーが動かなくなるんで、手作業でXML/RPC.phpの中でシングルクォーテーションを使ってパース結果（のPHP コード）を生成しているところをダブルクォーテーションを使うように修正した。

http://1470.net/mm/mylist.html/1?date=2005-07-06#m62804

と書いたけど、これはあくまでも一時しのぎ（少なくとも既知の攻撃は受けなくなるというだけで、これだけで十分な安全性が確保できたかは未検証）なので、「なるほどこうすればいいのね」とは思わないでくださいね。と一応追記。を文字数制限の関連でMM/Memoにはできなかったから、こっちに書いておく。

_ sbライセンス問題 - いかんともしがたいの人編 : highbiscus -北国tv (16:57)

まだその路線で続けるのかー。感情的自己主張（プロレス的エンターテインメント）に文章の大半を費やすんじゃなく、もっと具体的なポイントに絞って（相手が回答可能な）質問をすれば、まだ建設的な結果が得られそうなのに。

たとえば、sb作者id:simpleboxesさんおよびpaperboy&co.（以降p&cと略す）に対して、

配付前に配付条件(非営利利用に限り無償で利用可能)を提示した上で、配付許可をもらっています。

とのことですが、

• 上記の通りの文言で許諾を得たのですか
• 具体的に「営利目的においては有償販売する」旨をp&cに伝えたのですか（まあ俺には、「非営利利用に限り無償で利用可能」だけで、十分「営利利用は有償とするつもりである」と読めるけどね）

を確認したりとか。

でも、俺がp&cの中の人で、sbの存在はトータルでメリットがある（あるいはデメリットは特にない）と感じているんだとしたら、「その辺の態度を具体的に表明しろ」と第三者から言われるのはとても迷惑だけどね（もしも具体的な問題が出たら、その時点で対処すればそれで十分なのに、なぜ今態度を明確にしなければならないのか）。

あと「highbiscusさんがsbをいつから使っていたか」という問題に関しては、「もちろん2005年2月19日に取り上げる以前にも試用したことはあります」だけで十分。もしも存在するならば、客観的な証拠となりうる情報も付記すればなおよい。現状はどっちにしろ「言ってるだけ」だ。

何にしろ、JUGEMに関する権利をどう行使するかはその権利を持つp&cが決めることであって、第三者が決めるべきことではないし、sbを一例とした「ソフトウェアのぱくり問題」という一般論に訴えたいのだとしたら、あちこちでツッコミがあったその他の事例一般（互換OSの存在とか）に関して論を立てた方がいい。

現状はプロレスにしてもあまりにもつまらん。

_ sb話 - 著作権の話もしてみようか？ : highbiscus -北国tv (09:27)

以下、引用元を明示していない文章は、「sb話 - 著作権の話もしてみようか？ : highbiscus -北国tv」からの引用となる。まずは、

終盤の裁判所判断のところを見ますと、「デッドコピーないしそれに準ずるようなもの」である必要性があります。

について。この部分は、きちんと関連する文章を判決文から引用すると、

これを要するに，原告ソフトの表示画面については，仮にこれを著作物と解することができるとしても，その創作的表現を直接感得することができるような他者の表示画面は，原告ソフトの表示画面の創作的要素のほとんどすべてを共通に有し，新たな要素も付加されていないようなものに限られる。すなわち，仮に原告ソフトの表示画面を著作物と解することができるとしても，その複製ないし翻案として著作権侵害を認め得る他者の表示画面は，いわゆるデッドコピーないしそれに準ずるようなものに限られるというべきである。

サイボウズ事件−画面表示の著作物性と侵害の有無（東京地裁判決） 3争点 <解説>3より

となる（強調は引用者による）。きちんと「デッドコピーないしそれに準ずるようなもの」である条件として「新たな要素も付加されていないようなものに限られる」と書かれているのだから、この判例を取り上げるならばこの部分を明記しておくべきだろう。それによって、

JUGEMにしかない機能もありますし、逆にsbにしかない機能もあります。

Re: sbのライセンス問題　その２より

というsbに関しては、「デッドコピーないしそれに準ずるようなもの」ではないと言えるだろう（参考：JUGEM管理画面、sb管理画面）。また、

極力JUGEMユーザーが違和感なく使えるようにインターフェースをクローン設計で作ってるわけですから、当然ユーザーに触れる部分はとても似ています。

この部分に関しても、根拠が不明だ。作者の説明によれば、

JUGEMのテンプレートと互換性のあるウェブログツールです。

Re: sbのライセンス問題　その２より

と、JUGEMに似せてあるのはあくまでもテンプレートの互換性部分であるとし、さらに

逆に言えば、そこ（テンプレートのこと※筆者註）以外は別にまねようとは思っていません。

Re: sbのライセンス料問題 - パクリはなぜいけないのか？より

と、それ以外の点に関しては、JUGEMのクローンとして作ったことを明確に否定している。だから、

「合わせ技一本」というのが妥当に思います。

というのは、全然妥当ではない。

「インターフェースをクローン設計で作ってる」という言葉の根拠が、今回書かれた文章中には提示されていなかったが、もしも「俺にはインターフェースがクローンに見える」以上の根拠があるのならば、それを提示して欲しい。もちろん「クローン」というからには、「一般的なブログツールとして参考にした」以上の特別な類似性を示す必要がある。

また、結論では、

俺はJUGEMというソフトウェアに創作性はあると思います。

ここを「無い」としちゃうのは、Blogツール全ていっしょで全部いっしょのもので創造性は認められない、っつーのに等しいですよ。

などと「創造性を認めるかどうか」という論点に話がずれているが、それはリスペクトの類の話であって、法的にはどうでもいい。創造性を根拠にした著作権の話ならば、もちろんJUGEMもsbもその他ブログツールも、それぞれの著作権を持っているだろう。

ただ、その表面上に現れたアイディアや設計の類に関しては、他の人がそれを（デッドコピーではない程度に）参考にすることを禁止するような、独占的な権利は付随しないというだけだ。独占的な権利が欲しければ、それなりの手続きを取ってその権利を法的に認めてもらう（特許権、意匠権など）など、特別な主張する必要があるだろう。

_ 著作権と特許権とsb : highbiscus -北国tv (11:16)

ソフトウェアの著作権について、「知的財産権（特許・商標・著作権）の基礎講座 1.5ソフトウエアの特許について」を参考資料として用います。まずは最初の3段落。

ソフトウエアは、著作権による保護とともに特許権によっても保護されています。著作権はプログラムの表現を保護し、特許権はプログラムのアルゴリズムを保護するといわれています。

では、著作権によって保護されるプログラムの「表現」とは、何でしょうか？プログラムは、プログラムリストという形でプリントアウトもしくは表示できます。著作権法は、これを「表現」としてとらえ、プログラムを著作権によって保護しているのです。換言すると、著作権によって保護されるのは、プログラムそのものであるといえます。

これに対し、特許権によって保護されるのは、プログラムの背後にある技術的「アイディア」です。たとえば、「アイコンの上にマウスカーソルが来たら、そのアイコンの機能を吹き出しのようにして表示する」というアイディアを、最初に考えたのであれば、このアイディアにつき特許を取得することができます。

わかりやすい文章なので、追加説明はなくてもいいくらいですね。

基本的に、著作権で守られるのはソースコード自体であり、設計等のアイディアに属する部分は特許権で守る必要があります。ソフトウェア作者にはそのソフトウェアに関する著作権が発生するけれども、そのアイディアや設計に関しては、特別に著作権以外の手法で守らない限りは、独占的な権利としては認められない、という話です。

ただしソフトウェアの画面等は、グラフィカルデザインやインターフェースデザインといった要素も絡んでくるので、著作権の影響もある程度受けます。この部分に関しては、先に例示したサイボウズ−ネオジャパン裁判の一件が判断基準となるでしょう（この判例はsbに適用できないと主張するのならば、sbがJUGEMのデッドコピーレベルのクローンであるという客観的な証拠を示す必要があります）。

また、

(6)データの構造は特許の対象となるか

上の説明によって、たとえば、新しいデータ圧縮アルゴリズムを考えた場合、「データ圧縮装置」「データ圧縮方法」「データ圧縮プログラム」として特許取得可能であることは理解いただけたと思います。さらに、圧縮後のデータ構造が、圧縮処理に対応して特殊な構造となっている場合、このデータ構造についても特許を取得することができます。つまり、「・・・・の構造を有するデータ」として特許取得可能です。

といったあたりも注目に値します。テンプレート仕様というデータ構造に関しても、特許を取ることによってその独占的な権利を得ることができるわけですね。逆に言うと、特許で守られていないデータの構造に関しては、通常独占的な権利は発生しない（そのデータ形式を扱う他のソフトウェアを作成することが許される）ということになります。もちろんデータ自体（JUGEMが作成したテンプレート）には著作権が発生します。

最後に、著作権と特許権とsb : highbiscus -北国tvより、

モヒカン族の一部はここの切り分けがハンパに思えます。

創作性って凄く繊細はなしで、ちょっとしたことだってほんとは創作者が居るのだ。

勝手にこれをパブリックなんだとか言っちゃうのは失礼な話に思いますよ。

という話ですが、基本的にアイディア（知識）ってものはパブリックなものです。そのごくごく一部だけが、特許権等によって特別に独占的な権利を与えられているのです。創作性に関しては、すべての創作物に著作権が与えられており、著作権者に無許可でのデッドコピーの利用は許されていません。その二つの権利の違いをきちんと切り分けていますか？

_ DB_DataObjectのNULLの扱い (22:46)

DB_DataObjectでinsertやupdateを行う時って、nullという文字列をNULLとして扱うのね。PHPのnullがDBでもNULLになると期待していたんで、しばらくはまってしまった。

これはちょっとすごい仕様だな。not nullじゃなくい文字列フィールドに'null'という値を入れようとしてもNULLになっちゃうのか。この仕様では、厳密にNULLを管理しようとするのは無理だなー。not nullにして扱った方がまだましっぽい。

_ オレオレ著作権 (16:21)

という言葉がなんとなく思い浮かんだ。

「俺だよ、俺」

「ん？　誰？　もしかして著作権？」

「そうそう、俺、著作権だけど」

といった感じで、相手に著作権の話だと思いこませて話を進める。しかし、よくよく聞いてみると、どうもそれは著作権本人ではない。

「お前、本当は著作権じゃないだろ！」

「何言ってんだよ、俺だよ、著作権だよ」

「じゃー、著作権だって証拠をみせてみろよ」

「え、どこから見ても俺ってば著作権じゃん」

「だって、さっき言ったこれとかこれとか、全然著作権じゃないじゃん」

「だって、俺ってば創造性があるじゃん。作った人間には権利があるじゃん」

「それは著作権じゃなくて、著作者の権利でしょ」

「著作者の権利、略して著作権じゃん。やっぱ俺、著作権じゃん」

法律に基づく著作権の話をしたいのならば、「俺はこう解釈する」「俺にはそう見える」だけじゃなく、具体的な事例やら判例やらを根拠として持ち出さないとね。著作者には権利がある（主張はできる）けれども、その実効範囲は著作権法によって制限されているわけだし。

別に事例や判例が絶対的な根拠ではない（後々覆ることがあり得る）けれども、単なる「オレオレ解釈」をどれだけ書き連ねたところで、法的な権利が有効かどうかを判断するための根拠としては、まったく意味を持たない。それとも法的な権利の話ではなく、情緒とか道義とかの話をしたいの？＞highbiscusさん

_ dev.ishinao.net: PEAR XML-RPCの脆弱性について (20:05)

質問があったらしいんで、一応回答を載せておきます。書籍のサンプルや配布アーカイブでは特に影響ありません。ただ、サンプルを参考にXML-RPCライブラリを使ったアプリケーションを実装している場合は、pear upgrade XML-RPCしておいた方がいいでしょう。とかいいつつ、うちではアップデートで問題が出てごまかしているわけだけど。

_ 人によってパーマリンクが異なるシステム (21:40)

すげーくだらないことを思いついたんで、書いておこう。パーマリンクが人によって違うシステムならば、ディープリンクによる言及ができなくなる。

具体的には、エントリーID + '_' + md5(エントリーID + ランダムCookie)なんてものが、その人（ブラウザ環境）向けのパーマリンクになる。ランダムCookieは初回アクセス時に長期間Cookieとして発効したランダムなID（要はRURIコードね）。

そのURLにアクセスがあったら、最初の_でsplitして取り出したエントリーIDと、Cookieから取り出したIDを使ってmd5チェックして、マッチしないと内容を表示しない。

でもふつうに、記事インデックスとかにアクセスすれば、その環境向けの正しいURLが表示され、リンクをたどると中身が表示される。ランダムCookieが維持されている間は、そのURLはその人にとっては有効なパーマリンクとして働く。

ランダムCookieの代わりに、HTTP_USER_AGENTとかREMOTE_ADDRとか使ってもそれなりにいけるけど、人ごとの重複しにくさと、同一条件を維持できる期間の長さを考えると、Cookieが一番妥当なやり方だろうな。

公開はしたいけれども、あまりリンクや言及はされたくない、といったコンテンツを管理するようなサービスで使ってみたらどうでしょう。いやがらせレベルの対策だけど、運用してみたら実用レベルではそこそこいけるかもよ。

実際問題として、パーマリンクがないコンテンツは、内容が良くても言及されにくい、という現状があるわけだし。

_ オレオレ著作権 (2) (14:34)

コメントだとトラックバックが送れないんで、こっちにコピーして送っておく。基本的な論点は、この元コメントと一緒だよね。

で、ソフトウェアのインターフェースデザイン面においても、その「思想または感情を創作的に表現したもの」 であると結論づけたのがサイボウズ裁判。

違います。ソフトウェアの画面に著作物性は認めるとしても、デッドコピーレベル*1でない限りは侵害とは見なさない、というのがサイボウズ−ネオジャパン裁判の結論です。

で、デッドコピーですが、ここでの議論は完全に別のものが結果的に似た場合、デッドコピーレベルでなければ著作権侵害と認定するわけにはいかないという話です。

違います。判決文には、

これに依拠して作成された他社等のソフトウェア（以下「他社ソフト」という。）の表示画面がその複製ないし翻案に当たるかどうかを判断するに当たって

と、偶然似た場合ではなく、「依拠して」作成された場合についてきちんと考慮されています。

まずいしなおさんは、ソフトウェアの外面のデザインも著作物であるというとこからして著作権認識おかしいです。

すみません、意味が分かりません（「著作物である」は「著作物でない」の間違いですか？　その前提で話を進めます）。私は、

ただしソフトウェアの画面等は、グラフィカルデザインやインターフェースデザインといった要素も絡んでくるので、著作権の影響もある程度受けます

と書いています。ただ、「見た目が似ている程度では侵害と見なされない」というサイボウズ−ネオジャパンの判例を元に判断するべきだ、としているのです。

あと、

デッドコピー証明をするまでもなく、部分部分においては確実にJUGEMの著作物を使用していることは前提なのですから

その前提を私は共有していませんので、その点についても証拠を見せてください。

あと「デッドコピー」という言葉の意味を辞書で引いてみてください。 ソースと表示と著作権 - ishinaoさん編 : highbiscus -北国tvを読む限りでは、デッドコピーという言葉の意味が共有されていない気がします。「完全なコピー」だけがデッドコピーですよ？

といいつつも、ちょっと主に日本語の使い方と論理操作における断絶があまりにも大きすぎて、これ以上やっても進展がない気がしてきたな。結局「見解のすりあわせはできませんでした」ってことで終わりにしてもいい？

_ ishinaoさんにいやいややってそう気配を感じたり : highbiscus -北国tv (15:00)

話がかみ合わなすぎて、つまんないだけだよ！

言葉の定義レベルでぐだぐだになる展開が（俺的には）一番つまらん。戦略を誤った。

_ 逃げんなよ笑 - ishinaoさん編２ : highbiscus -北国tv (16:14)

「ソースのみ著作権で保護される」とか頓珍漢なこと言ってる

私は「基本的には、ソースがプログラムの著作権の対象」だが「ソフトウェアの画面についても著作権が認められる可能性がある」（しかし、判例によってsbの場合は当てはまらないだろう）と書いてるんですよ。highbiscusさんの論理解釈では、

ソースのみ著作権で保護される

と私が主張していると、解釈されるんですか？

あと、「依拠する」という言葉の意味も辞書で引いてみてください。「依拠して作成された」と「由来する」とは違うという解釈ですか？　判決文では「依拠して作成された他社等のソフトウェア」という前提の上で、あの判断を下しているんですよ。

あと、

sbの場合、明確な模倣があるわけですから

と主張するのならば、テンプレート仕様というデータフォーマット以外の点に関して、明確に模倣しているという証拠を提示してください。highbiscusさんは客観的な証拠を示さずに「クローンだ」「パクリだ」と言っているだけですよ。

俺は大きいとは思えないけどね。サイボウズ裁判の判決の読解に関しては、単にishinaoさんが強引な読み方してるだけでしょう。

これだけの断絶を断絶と認識してもらえないあたり、やはり、断絶はとても大きいようです。私には、highbiscusさんの論理操作と互換性のあるプロトコルは実装されていません。データのやりとりはできるみたいですけど、validatorを通らないんでロジックがきちんとデータを処理できません。converterを通して処理するのもそろそろ限界のようです。

_ 人によってパーマリンクが異なるシステム 実装例 (17:55)

『[Web技術][リンク] 人によってパーマリンクが異なるシステム』は一発くだらなネタのつもりだったんだけど、思いのほか反響があったんで、実際に動くサンプルを作ってみた。やっつけだけど、実際に動いた方が雰囲気が出るよね。

最初にアクセスするとCookieに発効し、それ以降はふつうにアクセスができる。各記事にもふつうにアクセスできる。けど、各記事のURLに他のブラウザとかを使ってアクセスしようとすると、目次が表示されてしまう。そこから各記事をたどる分にはふつうに表示されるけど、さっきのURLと各記事のURLは異なっている。

ソースは以下な感じ。md5値を丸ごとURLにくっつけるとうざいんで、最初の3文字だけに削った。それでも4096通りあるんでパーマリンクがパーマリンクとして働かないという用途では十分だよね。

<?php

mb_internal_encoding('euc-jp');
header('content-type: text/html; charset=euc-jp');

main();

function main()
{
   $uid = getUserId();
   if (!$uid) {
      publishUserId();
      die;
   }
   if (isset($_GET['entry'])) {
      $entry = $_GET['entry'];
      if ($entry = checkEntryLink($entry)) {
         showEntry($entry);
         die;
      }
   }
   showEntryList();
}

function showEntry($entry)
{
   $item = getEntry($entry);
   echo '<h1><a href="' . makeEntryLink($entry) . '">' . htmlspecialchars($item['title']) . '</a></h1>';
   echo '<p>' . nl2br(htmlspecialchars($item['body'])) . '</p>';
}

function getUserId()
{
   if (isset($_COOKIE['uid'])) {
      return $_COOKIE['uid'];
   }
}

function publishUserId()
{
   setcookie('uid', md5(uniqid(rand(),1)), time() + 60 * 60 * 24 * 30);
   echo 'Cookieを発効しました。';
   echo '<a href="?">記事一覧へ</a>';
}

function checkEntryLink($link)
{
   list($entry, $check) = explode('_', $link);
   $uid = getUserId();
   if ($check == makeCheckSum($entry, $uid)) {return intval($entry);}
   return FALSE;
}


function makeEntryLink($entry)
{
   $uid = getUserId();
   $link = '?entry=' . $entry . '_' . makeCheckSum($entry, $uid);
   return $link;
}

function makeCheckSum($entry, $uid)
{
   return substr(md5($entry . $uid), 0, 3);
}

function showEntryList()
{
   $list = getEntry();
   echo '<ul>';
   foreach ($list as $entry => $item) {
      echo '<li><a href="' . htmlspecialchars(makeEntryLink($entry)) . '">' . htmlspecialchars($item['title']) . '</a></li>';
   }
   echo '</ul>';
}

function getEntry($entry = NULL)
{
   $entrylist = array(
      '1' => array(
         'title' => 'うへ',
         'body' => 'まあそんなこともあるさ。',
      ),
      '2' => array(
         'title' => 'うほ',
         'body' => 'えー、マジっすかー。',
      ),
      '3' => array(
         'title' => 'うげ',
         'body' => 'そうなんですよ。',
      ),
   );
   if (!isset($entry)) {
      return $entrylist;
   }
   if (isset($entrylist[$entry])) {
      return $entrylist[$entry];
   }
}

?>

_ アーキテクチャーの違い (21:07)

ソースと表示と著作権 - ishinaoさん編 : highbiscus -北国tvで、私が、

「新たな要素も付加されていないようなものに限られる」と書かれているのだから

を引用したのに対して、

原告ソフトの表示画面の創作的要素のほとんどすべてを共通に有し、新たな要素も付加されていないようなものに限られる

を引用した上で、

「原告ソフトの表示画面の創作的要素のほとんどすべてを共通に有し」にsbは当たるもんじゃないですか？つー話ですよ。

として、反論にしているのは、もしかしてand条件を理解できていない？

原告ソフトの表示画面の創作的要素のほとんどすべてを共通に有し、新たな要素も付加されていないようなものに限られる

ってのはand条件ですよ。and条件は、並べられたすべての条件が真の時だけ真になるんですよ。たとえ「原告ソフトの表示画面の創作的要素のほとんどすべてを共通に有し」が真だとしても（その条件が成立している証拠も見せてもらってないけど）、「新たな要素も付加されていないようなもの」が偽ならば、全体としては偽なんですよ。

ってあたりの論理操作すら、互換性がないみたいなんだよな。多分CPUのアーキテクチャーが違っている。

_ Subversion 1.0.9から1.2.0への移行 (17:00)

サーバーを移行しようとしたら、Subversionのバージョン（DBフォーマット）違いで、単純にレポジトリをコピーしたのでは動かなかったので。古いサーバーで、

svnadmin dump [repos] > repos.dmp

してDBダンプを作り、新しいサーバーで、

svnadmin create [repos]
svnadmin load [repos] < repos.dmp

して内容を移行。

_ モヒカンチェック！ (20:21)

あなたのタイプは[タイプ９：ムラ社会的平和主義]です。

だったよ！　どゆこと！

_ WindowsでDNSキャッシュをクリアする (13:08)

Windows でクライアント側の DNS キャッシュを無効にする方法より、

ipconfig /flushdns

_ .svnディレクトリへのアクセスを禁止する (13:11)

<DirectoryMatch "\.svn/">
    Order allow,deny
    Deny from all
</DirectoryMatch>

_ 疲れている (13:18)

「ただのにっき」にディスプレイの埃が重なって「だだのにっき」に見えて以来、タイトルを見かけるたびに映像が思い浮かぶ。いっそのこと、ユーザースタイルシートでタイトル周りの画像を差し替えてしまおうか。

_ 最近逆援助系SPAMが非常に多い (14:53)

んだけど、これって効果があるから流行っているのかなー。

ちなみに逆援助系SPAMってのは、「欲求不満の女性会員（年収1000万円以上と書かれている例が非常に多い）が、あなたを求めています。30万円（って例が非常に多い）出します。連絡ください」みたいなやつね。この系統は文面のパターンも多いし、「どういう狙いでどういう表現を使っている」とかを考えるのが楽しいんで、結構チェックしている。

最近来た中で比較的新しめなのが「株式会社ウーマンフリー」と名乗るやつ。「このメールでURLを記載してしまうと、未承諾広告等の法律に違反してしまいますので、貴方の承諾を頂きたくメール致しました次第でございます。」という文言の効果が知りたいな。こういう表現を使うことによって、従来の形式よりも返信レートが高くなったりするんだろうか？

_ 一番古いサーバーの解約申し込み (16:15)

20日締めの翌月末実効らしいんで、来月末までは使える。解約するサーバーは、一番古いサーバーなぶん、一番機能が詰め込まれていたやつなんで、移行漏れがないようにしないと。ひとまずDNS周りの危険が危ない。主要な機能はだいたい移行しているんで、大して作業は残っていないはずだけど。

_ テンプレート互換が著作権法に触れる可能性 (14:36)

ソフトウェアの画面表示も著作物という話。を読んでいて思ったのだが、「画面」と「設計」と「デザイン」という言葉を、恣意的にその適用範囲を変えながら使うのは勘弁して欲しいなー。

• 「画面表示には著作物性がある」
• →「画面表示のデザインには著作物性がある」
• →「画面表示の設計には著作物性がある」

って、なんで「画面表示」が「画面表示の設計」にすり替わっているんだろう？　多分「画面表示」＝「画面の設計」だと思っているんだろうけど、それは「絵画」＝「絵画の構図」とか「小説」＝「小説のあらすじ」みたいなもんで、本来一緒くたにしてはいけないものだよ。

相変わらず、highbiscusさんの「プログラムの著作権」に関する解釈には同意しないんだけど、その件についてはこれ以上すりあわせることはできないだろう。ひとまず対論は十分提示したと思うし、「プログラムの著作権」でググれば関連する情報は見つかるし、まあそれぞれ自分の解釈を堅持するということで。

で、基本的な「プログラムの著作権」の解釈に関しては、全然同意しないんだけど、ソフトウェアの画面表示も著作物という話。で書かれた、「テンプレート互換は著作権法に触れる」という主張には、それなりに理があるとは思う。Webアプリケーション、特にHTMLやらCSSやらを使ったデータおよびそれによって生じる表現に関しては、今のところ判例がほとんどなくグレーゾーンが大きいんで、その辺をつつくと判断が非常に難しくなるからだ。

テンプレート互換というのは、基本的にはデータフォーマットの領域なんで、著作権をたてにデータ互換のツールを排除しようしても、現状のプログラムの著作権に関する主流の解釈からすれば、勝ち目はない。たとえばMicrosoftのOffice文書を読み書きできるツールを作っても著作権法に抵触することはない。もちろんWordで作ったデータファイルは、Word互換のツールで読み込んでも、同じような表示結果が得られる。テンプレート互換で表示結果が似ているから、画面表示の著作権に抵触しているというのならば、上記の例に対して有効な反論をする必要がある。

ただ、HTMLやCSSに関しては、その実用的な表現方法のバリエーションがものすごく少ない。特に洗練された表現をしようとしたときには、その表現は似通ったものになりがちだ。sbとJUGEMの件に目を向けてみると、テンプレート互換にすることによって、HTMLやCSSの表現が類似している部分や、部分的に同一の表現が出てくるだろう。HTMLやCSSの表現の類似は、どこまで著作権法に抵触すると考えるべきだろうか。というのは、おそらく今のところ具体的な判断が行われた事例はないと思う。

HTMLやCSSも、実際に表現として記述されたものには、著作権が発生する。しかし、基本的にHTMLやCSSによる表現というものは、オリジナルに書き下すものというよりは、仕様に準拠した表現や、既存のTIPSを組み合わせた表現となりがちで、そうなってくるとそこに生ずる著作物性というものも、非常に限定されたものになってくるはずだ。

もちろん、デッドコピーおよびそれに類するもの（要は、まるまるコピーしたり、あるいコピーしたものをちょっとだけ書き換えたり）は、サイボウズ−ネオジャパンの判例から考えても、著作権法に抵触すると考えるべきだろう。しかしそのソースを参考に、一般的なTIPSレベルの要素を部分的に借用しながら、新しくHTMLやCSSを作成した場合、それは著作権法に抵触すると考えるべきだろうか？

それが、「著作物の流用」なのか「著作物性を持たない一般的な表現を利用」なのかは、非常に判断が微妙な問題となる。sbとJUGEMに関して言えば、それぞれが出力するHTMLやCSSのレベルでの類似性を取り上げ、それがデッドコピーなのか、それとも仕様に準拠した結果同じような表現になっただけのかを争う、といった形になるだろう。

プログラムの著作権における判例として、「誰が作成してもほぼ同一になるものは、著作権法上の保護の対象から外す」という判断があることや、データ形式という著作権法に抵触しない部分での互換性を求め、その仕様に対応することによって似通ったHTMLおよびCSSが使われることとなった、という状況から、仕様を遵守した結果の（いわゆる創作性のない）表現と見なすことができ、著作権法に触れないという判断が下される可能性が高い*1とは思うが。

というわけで、「テンプレート互換は著作権法に触れる可能性」の問題は、使われているHTMLやCSSに同一の部分が多いような場合においては、判断が難しくなってくる。そのうちそれが問題となる事例も出てくるかもしれない。

そういえば

デフォルトのテンプレートファイル自体に、JUGEMと同一のものを使っていた場合、そのファイル自体はJUGEMの著作物なんで、著作権で保護される対象となるな。その利用については、その著作権者に利用許諾をもらう必要があるだろう。

sb開発者の方がJUGEM開発者の方に利用許諾をもらったってのは、その点についてかもしれない。

でもそれはあくまでも、sbのプログラム全体ではなく、該当のテンプレートファイルのみに関する問題ね。厳密に言えば、テンプレートファイルが著作物性を認められるような内容である必要があるけど、よほど非創作的な内容でない限りは、ふつう認められる。

_ テンプレート仕様という表現に、複数の意味が混ざっているな (17:56)

一つは「{$EntryUrl}は、エントリーのパーマリンクURLを差す」みたいなテンプレートのデータ形式の仕様。

もう一つは、「<span class="EntryUrl">で定義されたHTML要素はspan.EntryUrl {font-size: 90%; color: gray;}というCSSで修飾されて表示される」みたいな、表示に使われるHTMLやCSS定義に関する仕様。

前者は、純粋にデータ形式の問題であって、その利用が著作権法に触れるということはない。一方後者に関しては「HTMLやCSSの表現自体」という要素が絡んでくるので、その部分に関しては著作権法に触れる可能性がある。

判断の分かれ目は、<span class="EntryUrl">やspan.EntryUrl {font-size: 90%; color: gray;}などの定義は、「仕様」の領域にあるのか「表現」の領域にあるのか、なんだろう。

これがデスクトップアプリケーションで、「x:0, y:0, color:blackというデータを受信したら、座標0, 0に黒い色で（文字を）出力する」なんて話ならば、純粋にデータ形式とそれを解釈して実行するプログラムの問題なんだけどな。

通常のデスクトップアプリケーションならば、データの解釈から出力処理までをいろんな書き方ができるけど、WebアプリケーションがHTMLやCSSを使って出力する場合は、HTMLやCSSにする段階で表現方法が限定されてしまうところがあるから、それがプログラム設計・仕様の問題なのか表現の問題なのかが不明確になる。

これは実際に裁判にでもならない限り、きちんとした結論は出しようがない問題だろうな。

ちなみに

ここでいう「HTMLやCSSの表現」というのは、「あるHTMLやCSSをブラウザが解釈した結果表示される画面」ではなくて、「あるHTMLやCSSを記述したコード自体」のことね。プログラムの著作権で守られるのは基本的には*2その記述したソースコード自体であり、結果として出力された内容ではないので。ただWebアプリケーションは、HTMLやCSSという中間コード的なデータを出力しなければならないし、そのHTMLやCSS自体も表現として著作権による保護の対象となりうるところが、ややこしい。あと画面の表現としての著作権に関しても、（サイボウズ−ネオジャパン判例に基づいて）限定的には認められることになるだろうし。

_ MySQL 4.1.7＋DB_DataObjectでgetがおかしい (11:19)

DB_DataObjectでprimary keyを使って行を取得するときに、

$obj->get([primary key value]);

なんて感じでいけるはずなんだけど、MySQL 3.23.58で動いているコードを、MySQL 4.1.7環境に持ってきたら、なぜか動かない（正しいprimary key valueを与えても行がgetできない）。

またMySQL 4.1以降の文字コードの問題にはまっているのかなーと、文字コード絡みの設定をいろいろ変えて試してみたんだけど、ふと、

$obj->get([primary key name], [primary key value]);

に変えてみたら動くようになった。DB_DataObjectがprimary key情報の取得に失敗している？　DB_DataObjectってまだMySQL 4.1系には対応していないんだろうか？

_ blog @ psychedesire: FLASHでブログ間のやりとりをわかりやすくできないものか？ (12:13)

あの、sbていうブログ構築ツールとJUGEMが似ててアーダコーダという、いしなお!ていう人とhighbiscus -北国tvていう人のやり取りを見てて思った。スゲー見づらいっつか、見づらいまで行かないにしても、もっとなんか見易くすれば、こういう論議っつーの？そういうのもわかりやすくなって、いろんな人がハッピーになれるんじゃねーの

トラックバックに完全対応したblogツール同士のやりとりならば、 trackback trace: いしなお! - 一時しのぎの対策 (15:15) , sbライセンス問題 - いかんともしがたいの人編 : highbiscus -北国tv (16:57) - blogmapを使えば、やりとりをツリー構造に展開することができるんですが、あいにくhighbiscusさんが使っているチャンネル北国tv（blosxom）がトラックバックの送受信にしか対応していない（__mode=rssに非対応）ので、こういうツールが使えません。

ちなみにトラックバックにフル対応したツール同士の場合ならば、 trackback trace: [ビジネス] ［R30］環境が無敵のポジショニング軸になる日 - blogmapみたいな感じになります（※[+]マークをクリックすると、トラックバックのやりとりをツリーに展開していきます）。

というわけで、そういうツールはすでに作っているのですが、現状ではインフラが整っていないので、いまいち実用性が低いという状況です。

とコメントに書こうと思ったら、MTでエラーが出たんで、トラックバックにして送ってみる。

あれ、コメントが表示されてる

コメントを投稿したら、sprintfがどうとかいうエラーメッセージが出ていたんだけど。

_ 第三者トラックバック (21:10)

昔、第三者によるトラックバックというネタを考えたことがあった（今は亡きintersite MLとかに流した気がする）。あるエントリーに関連する、他サイトのエントリーのURL情報を、第三者からでもトラックバックで送れるようにしたらどうだろう、という話だ。

通常第三者が（トラックバックが送られていない）関連エントリーを見つけた場合、コメント欄あたりを使って筆者（や他の読者）に伝えることになる。

その情報を人間が理解するだけならば、コメントだろうがトラックバックだろうがどちらでもかまわないのだが、トラックバックという規格を使うことによって、関連エントリーの情報をメタ情報的に扱いやすくなる（__mode=rssとかを使って機械的に取得できたり）というメリットがある。

ただし、第三者が（他人の記事に関する）トラックバックを送信することには、心理的な抵抗が大きいらしいんで、それが第三者によるトラックバック送信だということが明示できるような仕組みや、第三者がトラックバックを送りやすくする仕掛け（投稿フォームとか）があった方がいい。

というネタをこの記事に関連して今更ながらに思い出した。やっぱりこういう仕組みはあると便利だと思う。トラックバックという規格を関連エントリーを機械的に取り扱う枠組みと考えた上で、トラックバックの__mode=rssによるRSS取得機能をもっと活用していってもいいんじゃないだろうか。

簡単な実装方法としては、

• トラックバックの手動送信フォームをエントリーごとに用意し、トラックバックの標準項目以外に「トラックバックを送信するエントリーはあなたが書いたものですか？」というチェックボックスを用意する
• トラックバックデータを保存する際に「第三者による送信」というフラグを追加し、上記チェックボックスがオンの場合は、そのフラグを立てる
• トラックバック情報を出力する場合、それが第三者による送信であることを明示する（HTMLの場合はそのまま注釈をつければいいけど、RSSの場合はどう表現するのが妥当だろう？）

なんて感じだろうか。

_ IMAPを使ってGTDを管理できないか (01:29)

IMAPを使ってGTDを管理できないかと、ちょっと試してみたんだけど、Becky!のインターフェースだといまいち操作に自由度が高くなくて難しいな。でも、IMAPでGTDを管理するというアプローチ自体は悪くなさそう。

そのうち、IMAPベースのグループウェアとか作ろうかと思っていたんだけど、その前段階として、IMAPベースのGTDクライアントでも作ってみればいいのかな。IMAPベースにしておけば、外出先でもmobileimapで各種情報が閲覧できるところが便利だよね。

_ IMAPでGTD (2) (14:18)

ちなみにGTDについては、ここを斜め読みした知識しかないし、ひとまずあまりGTDそのものを追求する気はない。単にIMAPをGTD（というか仕事管理）に使う実験。

ひとまず専用のIMAPアカウントを作る。IMAPフォルダとして、

• 今日やる
  • 家で
  • 会社で
  • 外出時
• 暇なときにやる
• いつかやる
• やった
• ごみ
• 資料
• 050721
• 050722
• 050723
• 050724
• ……
• 0508
• 0509
• 0510
• ……

なんて作ってみる。IMAPフォルダの並べ替えは（Becky!では）できないんで、基本的に後から作ったものが後ろに足されていく。必要になったら新しい日付とか月のフォルダも作っていく。GTDの基本に準じるならば、日付は一ヶ月分、月は1年分用意しておくのが妥当か。並べ替えが効かない点をフォローするために、年月日あるいは年月でフォルダを作っている。不要になったら今日以前の日付のフォルダは消していく。FIFO。

続いてアイディアの登録。思いついたアイディアは草稿として作るか（これだと再編集が効く）、もしくは上記アカウント宛のメールとして適当に送っておく。タイトルは、大括弧で大まかなカテゴリーを表現し、それ以降に内容の概略を書く。「[blog]IMAPでGTDの概要を書く」とか。詳しい情報があれば本文に書く。必要な資料があれば添付ファイルとしておく。

通常のメールアカウントのメールをチェックして、何らかのアクションを伴いそうなメールがあったら、適当にタイトルだけ差し替えて、上記アカウントに転送しておく。その段階で具体的なアクションに分割できそうならば、アクション単位でメールを書き、資料として元メールを添付する。

続いてアクションの分類。受信箱や草稿箱、今日の日付に溜まったメールを、内容に応じて、

• 今日やる - 今日やれそうなもの。場所依存のものは場所ごとのサブディレクトリに入れる
• 日付のフォルダ - 特定の日付にやるもの。
• 月のフォルダ - 日付が明確ではないが、だいたいの時期が見えているもの。
• いつかやる - 緊急性がないが、いつかはやった方が良さそうなもの。
• 暇なときやる - 「いつかやる」と似ているけど、気分転換に良さそうなスキマ作業ネタ。
• 資料 - やることじゃないけど、今後やることに関係しそうな資料。
• ごみ - いらない。あるいはいらなくなった資料。そのうち捨てる。

に分類していく。

続いてアクションの消化。まず「今日やる」の中の（現在の）場所依存のものをチェック。すぐにやれるものはやる。すぐにやれないものは、適切なフォルダに移動するか、あるいは次の消化タイミング用に残しておく。すぐやれないもののうち、アクションがおおざっぱすぎるものは、細かいアクションに分解してみる。

続いて場所依存ではないものをチェック。すぐにやれるものを片付け、すぐにやれないものはフォルダ移動もしくは残す。すぐにやれないもののうち、アクションがおおざっぱすぎるものは、細かいアクションに分解してみる。

仕事に飽きてきたら、「暇なときやる」とか「いつかやる」とかを眺めて気分転換をする。また、（今いる場所以外の）場所依存のアクションをやるべきかどうかを考える。必要ならば、その場所に出かける。

一通りのチェックが終わったら、再びメールチェックしたり、新しい仕事を考えたりして、必要ならばアクションを追加するってところに戻り、適当にループする。

外出中なんかはmobileimapを使って、「今日やる」とか「暇なときにやる」をチェックする。やれることがあればやる。また、何かアクションが思いついたら、適当にメールで送っておく。

というやりかたをさっきからやり始めているんだけど、ひとまず数時間やり始めて思ったことは、

• 通常のメールアカウントとは別に、仕事管理用のメールアカウントを用意しておくと、やらなければならないことはそちらに（アクション単位で添付ファイルなどを使って）吐き出してしまえるんで、通常のメールアカウントに中途半端なメールが溜まることがない
• メールは表現力があるし、扱いが手軽だし、データ置き場にも使えるし、なかなか便利。重要度とかメール標準で用意されている機能も、もっと活用できそうだ。
• ただし、メールはというかBecky!は、再編集とかに制限があるんで、ちょっと編集したいときとかも、新しいメールとして書き直したりする必要がある。特に、ある程度大きなアクションをプロジェクトとして扱い、複数のアクションに分割して云々、みたいなことがやりにくい。専用クライアントを作る以外でいい方法はないかな。
• mobileimapで外出先から手軽に閲覧できたり、携帯メール等で手軽にアクションを登録できるのは便利。
• というか、GTDってこんなんでどのくらい再現されているんだろう？　GTD自体をもうちょっと追求してみるべきなのか、それともGTDからネタを借りた独自の仕組みとして洗練させていった方がいいのか、どっちだろう。

なんて感じですよ。

_ 何回やっても (19:32)

qmail、ezmlm-idx、vpopmail、qmailadmin、clamav、spamassassin、tcpserver、qmail-scanner-queueあたりを全部入れる手順がきれいにならない。どこかのバージョンに固定してしまえばいいんだろうけど、一通り新しいバージョンに追随しようと思うと、たいていどこかで前のやり方のままではうまく動かない部分があったりして、手順が錯綜してはまる。疲れる。

_ テンプレート互換とソフトウェア設計互換は別 : highbiscus -北国tv (00:17)

このような一定の画面から他の画面への転換が，特定の思想に基づいて秩序付けられている場合において，当該表示画面の選択と配列，すなわち牽連関係の対象となる表示画面の選択と当該表示画面相互間における牽連関係に創作性が存在する場合には，そのような表示画面の選択と組合せ（配列）自体も，著作物として著作権法による保護の対象となり得るものと解される

この場合，個々の表示画面自体に著作物性が認められるかどうかにかかわらず，表示画面の選択又は組合せ（配列）に創作性が認められれば，著作物性を認めることができるというべきである。

サイボウズ差止請求事件本訴第一審判決

申し訳ない。確かにこの文章は、「プログラムの画面の設計（画面遷移や画面内の部品の配置）」について（それに創作性が認められれば）著作物性を認めうるという裁判所側の判断だ。前回の「プログラムの画面の設計」に話を広げるのが強引だという主張は撤回する。

ただし、あくまでもサイボウズ−ネオジャパンの判例が「画面の設計（画面遷移や画面内の部品の配置）」に関する判例でもある（「画面の設計」に無条件で著作権を認めている判例ではないことに注意）という点を認めるだけであって、それが「プログラムの設計（ソフトウェアデザイン）」一般に関する判例だとは認められない。

前回は自分で書いた「画面」「デザイン」「設計」という言葉に釣られて誤った主張を展開してしまった。前回の主張で、俺が間違った部分を修正して書き直すと、

• 「画面表示には著作物性がある」
• →「デザインには著作物性がある」
• →「ソフトウェアデザイン（設計）には著作物性がある」

というような、「画面」「デザイン」「設計」という言葉の恣意的な使い方はとても許容できない、ということだ。

あと、俺が今まで話をすり替えてきたという主張については、こちらでは違う認識があるのだが、おそらくそこには大きな断絶がありすぎると思われるので、いちいち争わない。highbiscusさんは、基本条件（基本的には○○だ）の後に例外条件（しかし、××の場合は△△になる）を述べた場合、その意味を適切に理解できていないように思う。

で、いつまでたっても証拠を提示してくれない（まさか、管理画面を比べてみたら、さすがのhighbiscusさんも著作権侵害だと言えなかった、というのが証拠じゃないよね？）んで、JUGEMとsbの画面をこちらで提示しておく。

標準状態のsbとJUGEMとMTの画面（sbのホスト名はさっき設定したばかりなんで、DNS情報が伝搬するまで見れない環境もあるかもしれない。ダメならこっちから見て）。画面キャプチャーするよりも、直接HTMLやCSSも比べられる本物を見てもらった方がいいよね。sbはこの標準テンプレートしか同梱していないから、この標準テンプレートを使った画面表示について、highbiscusさんはほとんど同一（デッドコピーレベル？）だから著作権侵害だと主張しているんだよね。それとも、ユーザーが独自に作ったりどこかから持ってきた（sbと一緒に配布しているわけではない）テンプレートを使って表示させたときに、同じ画面表示になるという点を問題にしているの？

と書いていたら、なんだか「テンプレと画面表示 : highbiscus -北国tv」ではトーンが下がっているな。ひとまず実物のどのあたりが具体的に「デッドコピー」レベルなのか指摘して欲しいな。それともやっぱり「画面表示の著作権」ではなく、「ソフトウェアデザイン」の著作権の話なの？　それとも不正競争行為の話だったの？

_ tDiary.org - tDiaryの脆弱性に関する報告(2005-07-20) (15:58)

CSRFに対する脆弱性（フォームの送信元がどこであれ、送信先（action）とパラメータが正当ならばそのリクエストは正当と扱う、という標準的な仕様）は、おそらくほとんどのWebアプリケーションが抱えていると思うんだけど、どの辺から脆弱性扱いされる範囲になってくるのかな。「少なくとも認証によって保護された機能については、CSRFによって呼び出しが可能であってはいけない」ってあたりかな。

おわ

さらに、tDiaryが動作するWebサーバ上で任意のスクリプトやコマンドがtDiaryの実行権限にて実行される可能性があります。

ってところを読み飛ばしていたよ。そういやtDiaryはプラグインが強力だから、そこ経由で自由なコマンドを実行される可能性が（設定いかんでは）あるのか。なんかうちのtDiaryっていろいろいじってある気がするけど、ひとまず何も考えずに（バックアップだけ取って）アップデートしておくか。

tDiary 2.1.2にアップデート

Refererチェックはオフにして、CSRFキーチェックを有効にしてみた。さて、どこか動作がおかしくなったところはあるかな？

_ IMAP関数のインストールとテスト (17:24)

先を越される前に、IMAP周りをプログラムから使う準備をしておこう。というわけで、まずはPHPにIMAP関数をインストール。

の前にc-clientをインストールしなければならないらしい。ftp://ftp.cac.washington.edu/imap/からc-client.tar.Zをダウンロード。ただ、Fedora Core 2では単純にmake slxではインストールできなかった。PHPで、IMAP,POP3,NNTP関数を使うを参考に、SSLDIRとSSLINCLUDEを書き換えてからmakeして必要なファイルをコピー。PHPに--with-imapを追加してコンパイル。

ひとまずIMAPフォルダの一覧を取るところまで動かしておこうと思って、

$mbox = imap_open('{' . $imapserver . ':143}INBOX', $user, $pwd);
$folders = imap_listmailbox($mbox, '{' . $imapserver . ':143}', '*');
foreach ($folders as $folder) {
   echo $folder . "\n";
}

なんてシンプルなコードを動かしてみたら、$folderはなにやら変なエンコードがかかっている。IMAP4の概要とモバイルコンピューティングあたりをながめたところ、

IMAP4rev1(RFC2060)ではサーバ上にフォルダを作成する場合はプロトコル上ではUnicodeをRFC2060で規定されているModifed UTF-7を使用してBASE64でエンコードして作成します

ということらしい。よく見たら、PHPがmb関数でサポートする文字エンコーディングにUTF7-IMAPというそのものずばりっぽい代物がいる。で、

  $folder = mb_convert_encoding($folder, 'euc-jp', 'utf7-imap');

とかやってみたら、ちゃんと日本語フォルダ名も取れるようになった。というところまでで今日の調査終了。

_ スポクラ入会 (00:38)

そろそろ秋の野球大会に向けて、腐った体力を復活させておこうと、スポクラに入会してみた。けど、まだ入会手続きをしただけ。来週あたりからぼちぼちやり始めたいなー。最低限1試合キャッチャーをやってもゲロ吐きそうにならない程度になっておかないと。ピッチングはどうしようかなー。ストレートだけならまだ投げれるだろうけど。

_ 小さい電池 (12:33)

最近車のセキュリティ（兼ふつうの鍵）のリモコンの反応が鈍くなってきたんで、電池が切れかけているのかなーと思いリモコンを開けてみたら、なにやら見たことがないサイズの電池が入っていた。てっきりボタン電池が入っていると思っていたのに。

これって見たことないけど単5ってやつかなー。でも、23A 12Vとか書いてあるんだが、単5ってそんなスペックなのか？　ひとまず電気屋に持っていって同じものがあるかチェックしてくるか。

単5ではなかったらしい

ビックカメラで電池を見せたら、同じものを持ってきてくれた。けど、単5ではなかった模様。単5の電池もやっぱりふつうの電池と同じ1.5Vだね。これはなんて規格の電池なのかよくわからん。A23ってのが規格名？　それとも商品名？

_ 画像アップロードが動かない (12:38)

CSRFチェックエラーが出て絵日記プラグインからアップロードできないな。俺がちゃんとアップロードをしていないのか、絵日記プラグインがまだCSRF対策に対応していないのか、調べないと。多分アップロードフォームにCSRFキーをhiddenで追加してやればいいんだと思うんだが。

プラグインが全然アップデートされていなかった

この間目をつぶってアップデートしたのは、本体だけだった模様。ということで、プラグインもアップデートしたら、ちゃんとアップロードできるようになりました。

_ is_subclass_ofが動かない (14:20)

HTML_QuickFormでhiddenなエレメントがなぜか消え失せるという不具合が出て原因を追及してみたら、is_subclass_ofでHTML_QuickForm_HiddenがHTML_QuickForm_Elementのサブクラスだと認識できなくて、addElementで弾かれていた。で、試しに入れていたAPCをオフにしてみたら、ちゃんと動くようになった。PHP 4.3.11＋現時点での最新stableのAPC＋HTML_QuickForm。is_subclass_ofが全部動かないわけではない（HTML_QuickForm_Textとかはちゃんと判別できる）というのがいやらしい挙動だ。ひとまずアクセラレータをTurck_MMCacheに変えたら同じ問題は出なかったんで、そっちでごまかしておこう。

_ 初スポクラ (14:23)

台風が来ているっつーのに、午前中に初スポクラに行ってきた。

しばらくの間、基本メニューは

• ウォーキング 10分
• ストレッチ
• マシン適当（背筋と肩を中心）
• バイクかジョギング 20分

といった感じでいこう。できれば1時間以内で一通り終わらせたいところだけど、1時間半くらいかかっちゃいそうだな。

初めてなんでマシンをいろいろ試していたら、思ったよりも筋肉が疲れてしまった。午前中から疲れ切っても困るから、マシンの負荷は軽めにすることにしよう。

あと、週2くらいのペースで行こうかと思っていたんだけど、思ったよりも疲れずに済みそうだから、これだったらできるだけ毎日行った方が良さそうな感じ。

_ 肉が痛い (09:25)

思いのほか筋肉痛が来てるなー。でも今日も軽めにやってこよう。

やってきた

軽めのつもりが、結構ハードになってしまった。

_ 有望なライブラリはどれ？ (14:15)

現時点でPHP＋Ajaxなライブラリで一番有望なのはどれなんだろう？　なんかいろいろ見かけたけど、結局どれ一つとしてまともに使っていないんで、今から自分で判断するのは辛いなー。ひとまず、

• MMでPHP+Ajaxを検索
• PEARのHTML::AjaxとServices::JSON

あたりをながめてみるか。

_ 連想配列かどうかを判別する (06:43)

うわー、知らなかったよ。PHPであるarray型が連想配列かどうかを調べるのに、

return array_keys($array) === range(0, count($array) - 1);

なんてことができるのか。っつーか、arrayって===で比較できたのか。

うが

tDiary Wikiスタイルで===を書こうとしたら、打ち消しになっちゃうよ。ひとまずプラグイン記法でエスケープしておこう。

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

だいぶ疲れが出てきているけど、まだ体に無理が利くならば、ここで続けてやっておいた方が体が慣れるのが早いはず。というわけで今日も軽めに。

• ウォーキング 5分
• ストレッチ 5分
• マシン 10分
• ジョギング or バイク 15分

なんて感じだと1時間以内に終わっていい感じだな。

_ 曖昧なつながりと実行時解決によって、コンピュータ＋ネットワークを実用的な道具にする (18:10)

というのが、現在起こっていることなのではないか、と思った。

従来のコンピュータアプリケーションは、かっちりとした枠組み（仕様）の中で、自前で持っているきちんと意味づけされたデータ群を使って、あらかじめ決められた機能（サービス）を実現しようとしていた。それはそれで有用だったけど、規模が大きくなるとシステムを構築することや仕様（現実）の流動的な変動に追随することがとても大変だった。

それに対して最近流行っているアプリケーション（というかサービス）は、もっといい加減な（人間が扱いやすい）データを、いろんな形式であちこちに分散して持ちつつ（というかネットワーク上に存在することを前提に）、自前で持っていないデータはネットワーク経由でかき集め、必要に応じて必要なデータを必要な解釈（フォーマット）で取り込みつつ、それらを使って機能（サービス）を実現しているものが多い。

そういうやり方では、各要素レベルでの信頼性というものは高いとは言えないんだけど、人間が普段使う道具としては、それでも十分使い物になっている。というのは、もともと人間の普段の生活では、従来のコンピュータアプリケーションが担保していたほどの正確さは求められていないから。

というアプローチで考えていくと、何か新しい便利な仕組みが思いつくかもしれない。

一応書いておくと

もちろんそういうアプローチによって、従来型のかっちりとしたシステムを否定しているわけではない。というか、そういうものは今まで通り必要な場所で使われていくだろうし、そういうものがなくなったら困る。

ただ、今まではかっちりとした仕様に落としきることができず、システムとして構築できなかった雑多な案件について、今回挙げたようなアプローチを使えば、それなりに実用的な道具（コンピュータアプリケーション）を作ることができるし、しかもそれは従来よりも手軽に実装できる。

みたいな趣旨ですよ。コンピュータ＋ネットワークのコモディティ化は、こういうアプローチによって実現されていくのではないか、とか。

_ Rast＋php_rast試し中 (21:09)

プチはまりその1。

• icuを有効にしないとUTF-8が使えない
• というのを忘れて、Rast、php_rastをコンパイルした。
• 後からicuをインストールして、Rastをicu有効でコンパイルし直した。
• php_rastもコンパイルし直さないと、php_rastからUTF-8が使えなかった

プチはまりその2。

• 検索インデックスを保存するディレクトリを作成し、書き込み可能にしておく
• そのディレクトリに対して、rast_db_createを実行。しかし失敗する（FALSEが返る）
• 特にエラーメッセージやエラーログも出ないので、理由が分からず悩む
• インデックスを作成するディレクトリを削除して実行したらOKだった。ディレクトリもrast_db_createが作成するってことだった

で、ひとまずインデックスに登録したり、削除したり、検索したりを一通り動かしてみた。

ちなみに、一度登録した文書が更新されたときに再登録するためには、前回登録した文書をdoc_idを使って削除しなければならず、そのためには何らかのユニークなキー（doc_id以外）を付与しておいて（Web系の検索ならばURLとか）、それを使って検索して既存文書を削除しなければならないんだね（登録時にdoc_idの方をドキュメントにひもづけておいてもいいけど）。最初ユニークキーを持たせずにインデックスを作成・登録していって、登録済みのドキュメントのインデックスを更新しようとして困った。更新される可能性があるドキュメントを登録するときにはインデックス作成時に注意。

次はある程度の分量のドキュメントを登録して、一般的な検索機能を試してみて、それでよさげだったら大量ドキュメントの登録・検索を試してみようかな。

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

今日も軽めに。最後のバイクで100kcal/15分を目指してみたんだけど、結構きつい。アベレージで100W以上の負荷を維持しなければならないとなると、足にかかる負担もそれなりに大きいし、ちょっと一生懸命やるとすぐ脈拍の警告範囲（170回/分以上）に達してしまう。ジョギングで100kcal/15分ならばそんなに辛くなかったんだけどな。よほど体力がつくまでは、バイクで100kcal/15分はあきらめるか。

_ 久しぶりに仕様書の原文を見たら (15:06)

__mode=rssに関する記述が消えていた。すでにobsoleteだったのね（ver.2で同様の機能を復活させる予定らしいけど）。あと、昔見た仕様書と違って、ちゃんとした仕様書文章になってるじゃん。文字コードはcontent-typeヘッダで指定したcharsetを使うのが正式な仕様になってたんだね。

PHPでやるなら、

$charset = 'auto';
foreach (getallheaders() as $header) {
  if (preg_match('|content-type.*charset=(.*)|i', $header, $matches)) {
    $charset = $matches[1];
    break;
  }
}
// $charsetからinternal_encodingに変換

なんて感じかなー（動作確認してない）。

_ テーマ増量＋カレンダー折りたたみ (17:35)

MM/Memoのユーザーページで選択できるtDiaryテーマを増やしました。

ついでに、ユーザーページのヘッダ部に表示しているカレンダー（日付単位）を、年単位で折りたたむようにしました（過去・未来メモを書いている人以外にはあまり関係ない機能だけど）。

って久しぶりにMM/Memoをいじったな。

カレンダーは月まで折りたたむようにしました

まだちょっと改行処理が完全じゃないけど。