これまで数ヵ月、理由をみつけては先伸ばしにしてきた卒業試験の申請をさきほど済まして、主専攻の教授3人から試験日程もゲットした。内容は主専攻の情報学が30分の口頭試験x3と副専攻も口頭試験30分x1。主専攻は合計で42 Semesterwochenstunden (週3時間で一学期続く講義で3 SWS)分のネタだ。自分の組み合わせだと講義数にして12講義を復習しなければいけない。(もっとも面白かった)高度な講義は時間数が少なく、内容も難しいので口頭試験には含めないのがミソ。この口頭試験が終った後は6-9ヵ月かけて卒論を書く。年末までには卒業したいなー。なにはともあれ、これで否応がなく、卒業にむけて歩きはじめたわけだ。もはや先伸ばしはできない。

試験日程と内容：

• 2月5日14:00 副専攻変更(Biologie->Japanologie)に伴う追加試験：Prof. Dr. Evelyn Schulz (完了、結果良好)
  • 部落問題：歴史的背景、明治維新以降の解放運動、現在の課題
  • 2001年夏の教科書論争：戦後日本の教科書、検定制度、2001年の第三次教科書論争にみる政治的思惑と歴史教育の関係
• 3月12日18:30、PG (プログラミングと理論)：Prof. Dr. Francois Bry
  • Markup-Sprachen und semistrukturierte Daten (5SWS)
  • Description Logics (4SWS)
  • Hoehere Programmiersprachen (3SWS)
• 4月13日10:00 ST (システム/テクノロジー)：Prof. Dr. Christian Boehm
  • Datenbanksysteme I (5SWS)
  • Datenbanksysteme II (5SWS)
  • Workflow-Management-Systeme und E-Servics (2SWS)
  • Rechnernetze (3SWS)
  • Komponenten zum Aufbau von Rechnernetzen (3SWS)
• 4月14日11:00 A (実践的情報学)：Prof Dr. Claudia Linhoff-Popien
  • Objektorientierte Software-Entwicklung (3SWS)
  • Verteilte Systeme (5SWS)
  • Telekommunikationssysteme (3SWS)
  • IT-Securiy (2SWS)
• 4月26日17:00、副専攻(Japanologie)：Prof. Dr. Franz Waldenberger
  以下の4テーマから2個を2週間以内に自分で選定、詳細な出題が送られてくるので、勉強し、論点をまとめること。当日は論点を紹介した後、教授と議論。
  • 日本企業的マネージメント
  • 日本の雇用形態、雇用市場
  • 日本の金融システム
  • 日本の経済政策

試験勉強中はリラックスと現実逃避するために、いろいろハックしそうな予感。できればやりたいこと：RELAX NG Validator for Rubyの作成、Slashcode 2.3イヂり。もし発売されたら、Half-Life 2を遊び倒す。四六時中勉強しても良い結果にはならない。

バグを修正すればするほど、バグレポートが増える

アクティブなのをユーザが察知して、これまで「どうせ修正されないだろう」と思っていたバグも報告してくれるようになるので、いいことなんだけど...「やっと50切った！」と思った数時間後に新しいのが来てると、そらゲンナリもしてしまうさ。:-) でもバグ狩りは楽しくもある。

ということで、バグレポートよろしく。

Google Japanが悪徳商法？マニアックスを検索結果から除外。数日前から「Google八分」などのタイトルでタレコミがいくつか来ていたが、いずれも速効で却下した。Googleが日本でも検索結果にフィルタをかけている、という事実が発覚しただけもネタ的には十分なのだが、いずれも文章があまりにもダメダメダメダメだった。「広告費欲しさ(邪推です)に安易に検索結果を改変しては」とか「Googleが恣意的に検索結果をコントロールしている」とか、あまりにも一方的すぎ。最終的に掲載したタレコミも激しく不満足だったが、そろそろネタの鮮度が気になるので採用した。まるで全員がこの事件について詳しく知ってるかのような言葉や名誉毀損で適示される情報が事実な場合に公共性が考慮されることなどについて詳しくしらないからだと思われる見当違いの論説など、バッサリとタレコミ文の2/3ほどを切捨て、文章の枝葉を修正しまくった。もちろん原形は十分にとどめているが、内容的に匿名である必要が感じられない匿名のタレコミは実質的にタレコミニストに配慮はほとんどしなくていいと思っているので、思い切った編集にたいする抵抗ずっと少ない。
たまに削除要請を受けると身としてはGoogleの立場も十分に理解できる。違法情報と判断したのなら、削除義務があるのは過去の判例やプロバイダー責任制限法の存在を見れば、明白だ。ただし、 判断が間違っていても、故意や重過失じゃない限りは責任を問われないようにしてくれるのがプロバイダー責任制限法だ。利用者が不特定多数を相手に情報発信できるサービスではないので、Googleがプロバイダー責任制限法で守られるかどうかは微妙かもしれないが、違法情報という指摘にたいして判断を放棄して「なんも削除しない」というのは十分に重過失になりうると考えられる。
Googleの場合はページの作者ではなく、Google自体が発信者なので、作者に配慮する義務はGoogleにはないが、公共性がとても高いサービスなので、リスク排除の為だけの安易な削除はせずに慎重に判断して、違法でないと考えるなら断固拒否して欲しいという、利用者に対する道義的な責任／モラルの話だ。個人的には(判断の余地なく削除しなければいけない)DMCAの時の様に検索結果から除外されているページある事を告知する文を検索結果に含めることを望む。

1AC/30min制限について、なぜこのタイミングなのか疑問に思っている人も多いみたいなので、説明しよう。(告知に細々かくことじゃないよな)

9月中旬の告知の数日後にスイッチオンしたつもりになっていた対策が「動いてねぇぢゃん」と気がついたのはその数週間後。プラシーボ効果(?)か、まるで対策が効いたみたいに問題行動がパタリと止んでいたので、気がつかなかったのだ。偽装工作がすっぱ抜かれたので、そういう手段で世論操作していた数人がやめたから、というのが考えられる。でもまあ、告知だけで結果オーライだったので、その時には対策が動かない原因を特に調べなかった。

あれから半年弱、連続投稿がまた増えてきた雰囲気だったので、調べてみたところ、2-300コメント級のストーリではコメントの10%以上が同一IPIDから、ということが珍しくなかった。

最終的に決定打となったことはふたつ。ひとつは殿堂入りもしたセキュリティ問題を指摘するはずが個人情報を漏らしてしまった話。50以上のコメントが単一のIPIDから来ていた。率としては他より少なめだが、この数は執念といわざるをえない。すべてコメントが30分以内に行われたのではないが、3-4個づつ、クラスタ爆弾よろしく数時間おきに投下されていた。対策によって大量投稿の「勢い」をそげることに期待したい。(さっき松文舘事件の投稿数も調べてみたら、最大でも10個程度で、問題と思うほどではなかった)

そしてもうひとつは、Slashcode 2.3化の下準備として今つかっているコードを検査していたら、なぜ対策が有効になっていなかったか分かったから。最初の告知の前に書かれ、テストもされてたコードが本番環境に入ってなかった..... (- -#

そのうちデバッグしようと思っていたものが、ふと見付かったので、テストサイトで再テスト後、即日実行した、ということだ。

また、再告知のストーリについたコメントで管理者がユーザを監視しているのは気持悪いともいわれた。SELECT count(ipid) AS c FROM comments WHERE sid = xxxxxx AND uid = 1 GROUP BY ipid ORDER BY c DESC LIMIT 5;で監視と言われちゃなぁ。たしかに管理者は必然的にユーザよりも多くの情報をもっている。それでも管理者が安易に生IPを求められないようになってるのがSlashcodeのエライところだ。区別さえできればいいのだから、IPに含まれる識別子以上の情報をすべて捨てたのがIPIDだ。必要最低限の情報以上を保存しなければ、目的外に使ってしまおう、という誘惑もない。オマケとして、[0-9a-f] 32文字なMD5の出力で、ぱっと見ただけでは区別しにくく、覚えにくいものなので、明確な意志をもって調べない限り、「このIPID見覚えあるぞ。またこいつか」なんてこともなく、余計なストレスがたまらないので、管理者にも優しいシステムだ。

「アニメ」トピックを改名して欲しいという要望はかなり前からちょくちょくあった。「アニメ・マンガ」が妥当ではないか、という提案もsf.jpに要望として登録されている。もとの「アニメ」は本家からもってきた時にそのまま訳したもので、改名した場合のシステム的な影響が不明だったため、改名すべきか棚上げしてきた。

最近、コードを追うようになって調べてみたところ、"anime"というトピックIDさえ変えなければ、いくら正式名称を変えても、作成済みの.shtmlが変わらない以外は影響なさそうだとわかった。トピックアイコンにtitle属性もつけるようにしたし、そろそろ真剣に改名を考えてもよいと思う。

「アニメ・マンガ」じゃあつまらないと思う反面、おもいきって「萌え」なんてしてしまったら、必ず「俺は萌えない」なんて言い出すやつがいそうだ。どうしよう？

追記(23:18 CET/07:18 JST)：ぽちっと。「萌え」を真に受けた人がいなくてよかった... というか、ここ1年以上、まともに萌えてない気がする。かなり気にいったマリみては萌えとはなんか違うし、そういや物欲も久しく燃えあがってない。食費と家賃以外の出費がほとんどないような。専門書以外の趣好品はなにも買ってないや。お金で買えるもので、どうしても絶対に欲しい、というものがないのは幸せなのだろうか。次に帰国した時にいい指輪でもプレゼントするかな。エルフ語を刻印してもらったやつを (やめれ

Tech総研というサイトの電網Tech人というコーナでインタビューされた。このサイト、/.-Jに広告を出しているので見てみたことある人も多いと思うが、いろいろスゴイ人がインタビューされている。なにがどう転んで自分がその末席に加わることになったのかはよく分からないが、嬉し恥しい気分。

インタビュー自体は12月に国際電話で1時間以上かけて行われた。質疑応答というよりは、むこうが知りたかった/.-Jみたいなサイトを運営するようになった経緯や利用者の層がどうサイトの性格にあらわれているのか、はたまた本家との差とかを中心にいろいろ考え方を自分がべらべらしゃべった感じだった。その結果、中身の大半は消化され、ライターの文章と化し、自分の言葉で直接引用されてるものは、かなり少ない。草稿でもらったテキストがこういう風にマークアップされると、すごく量が減ったように思えてしまう。実際にはそのままなのだが。

ちなみに、使われてる写真は2年ぐらい前のもので、消されてる背景は たん清 の壁だったりする。/.なオフ会のもので、もっと下にはビールジョッキが... あまり写真に撮られるのが好きじゃないのは、こういう時に不便だ。あと、このプロフィールだけ見ると完全なドイツ人に見えるが、実際にはハーフで、「帰るべき場所」は東京だったりする。

後編は28日の水曜日掲載なので、そちらもよろしく。

リンクの色指定を<body>のlink, vlink, alink属性からHTMLヘッダ内の<style>内でのCSSへ移動した。セクションカラーがあるので、外部CSSファイルには追い出さず。

Pocket IE 3.xが<a><font color="white">foo</font></a>みたくリンクの色を変えるのに対応してなく、無条件に<body>の?linkで指定した色になってしまうので、タイトルバーなど、背景色のあるところのリンクが保護色になってしまう、というバグレポートをもらっていたからだ。CSSで指定してしまえば、CSS未対応ブラウザはデフォルトカラーになる。青や赤はあまりよろしくないが、すくなくとも完全保護色ではない。NN 4.xですら、これぐらいのCSSは大丈夫なので、副作用はほとんどなし、ということで決行。

とりあえずは、a:linkがセクションカラー、a:visitedとa:activeを文字色(黒)に設定した。linkのセクションカラーはゆずれないとして、activeとvisitedをもっと別の色にして欲しいという要望を数個下の日記でもらった。なに色がいいものか？特にvisited。これもセクションカラーにして、未訪問と同じにすべきか、はたまた別の色にすべきか。どう思います？

あと、リンクの下線の有無に対する意見も聞きたいところ。

追記：おもいきって決行して、ユーザの意見を聞くストーリをたてた。変更に気がついた瞬間こそ、慣れがないので、良いのか悪いのか、違和感を感じたのか、素直な意見が聞けることに期待。今後はこの日記へのコメントではなく、ストーリへのコメントをお願いしたい。

追記2：結局、元の黒にもどした。試しに(!)設定してみた色がえらく不評で「これだ！」という案がなかったからだ。自分も不満があったからこそ、ストーリを立てたのだが、なんかもっといい案が出ると思っていた。提案されていたのは、いずれもテストサイトで試してみたが、しっくりこなかった。デフォルト色の青＋赤／紫は.../.の色だと目がチカチカする。リンク色指定をCSSに変えたときに古いままの.shtmlで嫌というほど目にした色の組合せだ。7000記事以上もの.shtmlを再作成するのはえらく時間がかかった。でも、流れていくfreshenup.plのログに懐かしいストーリ名をみたりもした。時が経つの、はやすぎっ。

IBMのLinuxデスクトップ採用計画。「IBMがWindowsを放棄」みたいな感じだったタイトルを書き換え。Windowsが捨てられるのが嬉しいんじゃない、Linuxが採用されることが嬉しいのだ。PR効果はもとより、推進計画のなか、IBMから良いフィードバックと良いコードに期待できそうだ。ついでに、肝心のメモを全文公開したThe Inquirerの記事へのリンクを混入。文脈を外している、なんて言ってるからには原文が大事。なんたって、全社の幹部相手に送られたメモで紹介されてる「IBMのビジョン実現にとって中核となるふたつのキープロジェクト」の片方だ。

ちなみに、原文を変えずに一次情報へのリンクを混入させるのはよくやっていること。でも、タレコミはなるべく一次情報を含んでいて欲しい。一次情報が日本語のプレスリリースや紹介ページなどで、タレコミニストが最初に情報を知った二次情報源がプレスリリースをそのまま書き直しただけみたいな記事なら、そっちへのリンクは価値なしなのでなくしてしまったほうが良い。

ここんところ、勢いに乗って、/.-Jにいろいろ細かい変更を加えている。すぐに目に見るものもあれば、目立たないものもある。ものによっては、ここやsf.jp内のバグトラッカーに変更したものの説明やパッチが残るが、できればどこかに、集中して漏れのない変更履歴をきれいに残したい。ついでに、変更案などについて議論もできればいい。

考えられる案：

• Slashセクションローカルに記事として掲載。=>パッチとかdefault;misc;fooテンプレートを変更したのだの載せる場所じゃない。(ボツ)
• この日記に全部かいてく => いまの粒度だといいけど、さらに細かい事まで載せると多すぎる (ボツ)
• 専用の新しい日記を作る
• sf.jpプロジェクトページにフォーラムを作る
• MLを作る。sf.jpを使えば簡単に作れる上、アーカイブも公開

未読管理や時系列の並び、使いやすさに柔軟さを考えるとMLか？参加すれば今後の変更のネタバレになるかもしれないけど、みてみたい、という人はどう思いますか？

追記：ということでslashdotjp-dev ML作ってみた。最後まで開発日誌的な日記も考えたが、全参加者がひとしくポストできる、というのとファイルが添付できる、というのでMLに決定。

新しい日記テーマに使われているCSSを外部のCSSファイルに追い出した。これでデータ量の削減だけでなく柔軟性も確保できたはずだ。また、ユーザスタイルシートや自動処理用のデータ抽出も共通のルールでできるようにクラス名を統一して、場合によってはspanを追加して範囲を狭くしたりした。例えばタイトルのclassはjournaltextだとか、日付はjournaldateだとか。

元から(特にliquidで)蚊帳の外だったCSS未対応ブラウザや新しいブラウザにとっちゃ、レイアウト的な見た目的の変化はないはず。たぶん。きっと。たのむから。この外部化で影響を受けるのは、4.x世代ブラウザのユーザだ。NN 4.xは@importの使用で疎外される。ナビゲーションメニューの時と同様、変なCSSを踏むとクラッシュすらするブラウザの運命だと思ってください。m(_ _)m。 IE 4.xはclass="journal liquid"みたく複数のクラスを指定するのに対応しいないため、仲間外れとなる。でも、その利用者はNN 4.xユーザの更に数分の一しかいなかったりする。どちらの場合にしても、スタイルシート未適用でも、日記がちゃんと読めるレベルでのCSSはstyle属性で直接指定してあるので、大丈夫なはず。

ついでに、slashdotjpテーマで友達認定している人の各エントリについてた「縁を切る」をあまりにも不評だったのでカット。軽々しく絶交するものではないのでキツめの言葉を選んだのがウケなかった? 絶交はこれまでとおりに「友達」メニューからどうぞ。

最後にどうしても「縞々うぜぇ」という人は、ユーザスタイルシートで.liquid .journalentry { background: #e6e6e6;}とでも指定しちゃってくださいな。もしくはquery stringにてtheme=slashdotjpなどをつけることにより、読み手がテーマを強制指定できる裏技を使うか。新日記テーマのデバッグ用に追加した小技なので、light=1と同様の裏技扱いということで、よろしく。

新日記テーマ、これで完成だと望みたい。明日から休み明けでこの年末年始ほどの時間はとれなくなるので。