_ 師走

もうだめぽ。

_ trac 0.9

多言語化的には退化している…。 いままでテンプレートに出てた部分がコードに埋め込みになったために、 日本語化するにはコードの部分をたくさん変更しないといけなくなってしまっている。 テンプレートだけでは多くは日本語化できなくなってしまい、 こんな感じ だ。

さて、パッケージの方はどうしたらいいだろう。 一応上の URL のページは テンプレートと wiki-default だけを入れたパッケージで日本語化 してあるんだけども…。

_ ガンバ優勝

終了直前に追加点を決めたガンバと終了直前に同点に追いつかれたセレッソ． その差はどこにあったんだろう．

この劇的な優勝シーンが，家から徒歩数分のところで行われたということに 軽いショック．仕事が大変でなければきっと（思い出して）行ってただろう になぁ．2003 年の横浜の劇的な優勝シーンは目の前で見たわけで…．

日本でも優勝したのは 3 トップのチーム

去年あるいは一昨年あたりから世界的に「ウインガーの復権」という 感じで3トップが注目されているけど，時代は3トップ での攻撃サッカーということになってきた感じ．来年のワールドカップ が楽しみ．3トップのチームと2トップのチームのどちらが強い・ 面白いサッカーをするのか．

_ Ruby の empty? メソッド

ふと思い立って実験。

irb(main):001:0> ''.empty?
=> true
irb(main):002:0> [].empty?
=> true
irb(main):003:0> {}.empty?
=> true
irb(main):004:0> 0.empty?
NoMethodError: undefined method `empty?' for 0:Fixnum
        from (irb):4
        from :0

ふむ。文字列、配列、ハッシュは empty? メソッドで空である ことがわかるけど、数値は無い。まぁ「0」が empty といえるか どうかは微妙なのかもしれない。

perl のような条件判定（0、空の文字列、配列、hash が偽） というときに empty? が使えるかなと思ったけれど、使えないようだ。 残念。だれかすでに提案しているかな？

追記：Integer (Numeric) は zero? メソッドがありますね。 これの alias で empty? を追加しても良さそう。

追記2：nil のこと忘れてた。 Rubyではnilはコンテナではないのでempty?は定義しません ということなんで、perl のような使い方はできないですねぇ。 Numeric#nonzero? にならって という話はありますが、Numeric#empty? の話は見つけられませんでした。

_ binary 2.0 conference

行ってきた。昨日（書いてる時点では一昨日）のことなんだけど。 詳細は satoru 先生のエントリ を参照してもらうとして、なかなかよかったですな。 自分は低レベルなところは興味が薄いんだけども、こういった hack は 楽しそうで良い感じ。

はやりの「なんとか 2.0」

なんか 2.0 とつけるのが流行ってるようなんで、自分も 2.0 をつけて みたいな、なんかあるかなー、と思ったら、あった。 「アレゲ 2.0」。いやむしろアレゲは 1.0 であることに意味が あるのかもしれないけど、そもそもアレゲってなんだということが 言ってる本人がわかってないんでよしとする（意味不明）。

しかし、2.0 にして何が変わるんだ…？ > アレゲ

アレゲ 2.0 に言いたいことがあるみんなはコメント・トラックバック キボンヌ。

_ tDiary TracWiki スタイル作りました

普段仕事と private 両方でTracを使っててそのWiki 文法が結構気に入ったので、tDiary もこれで書きたいと思ってびびっと書いてみた。Wiki スタイル（古い方、hikidoc になってないやつ）のソースをいじって、Trac のWiki のスタイルでレンダリングできるようにしただけ。まだ完全ではない（いろんな制限がある）けれど、基本的なところはなんとかなる。あとは Trac のソースの方を読んで、リファクタリングをしないといけない。

とりあえずこれで今後は書いていくことにする。

ちなみにソースは http://tach.arege.net/trac/browser/tdiary/style にあります。ドキュメントをあとで書こう。

ちなみに

まだ全然だめだめなので、私以外は使おうとしない方が良いでしょう。（使う人いないと思うけど…）

_ tDiary trac theme

アホな私はさらにモゲって、tDiary trac theme もでっちあげてみた。まだ theme として公開できるほどのできじゃない（いろいろとおかしい）けど、思い切って設定してみた。

trac 見てるのか tDiary 見てるのかわからなくなってくるな…（わら

_ レアル・マドリード 1 - 0 ヘタフェ

レアルがまた窮地に陥るのを見ようと思ったんだけど，前節の奇跡的な同点劇の影響か，まずまずのできだった．ロナウドのゴールはその前のプレーがハンドだったけれどもあの力強い突破力はすごいねぇ．

_ 偏頭痛

昼から。結局日曜に行こうと思っていたところ、しようと思っていたことができなかった。まぁこればかりは仕方ないんだけども。

しかし、思うにここ一年くらいでまたぶり返してきた感じ。大学の頃はひどかった（一月に一度くらい）けど、就職してから比較的落ち着いていて（一年に数度くらい）、良くなってきたのかなと思ってたら最近は一月に一度かそれ以上のペース。

気の持ちようなんだろうか。大学にいたころはいろいろ将来に不安をかかえていて、就職してからはがんばってて不安もあまりなくなって、就職して数年たっておちついてくるとまた不安になってくる、みたいな。たしかにいまはいろんな意味で不安はたくさんあるねぇ。

ともあれ、じぶんの偏頭痛でいやなのは、

1. 異常な吐き気
2. 目が見えなくなる
3. 頭痛

の順番だなぁ。吐き気だけはがまんのしようがなく悲惨だ。

_ ビジャレアル 0 - 2 FCバルセロナ

今シーズン前半のヤマ．昨シーズンやられたビジャレアル戦．今のバルサを止められるとしたらこのチームだろうという相手．

シャビが大きなけがをして今期絶望というニュース．バルセロナイレブンは，「シャビがんばれ」という（カタルーニャ語で書かれた）T シャツを着て登場．いまのバルセロナらしいチーム全員で支えていくという姿．すばらしい．しかし，調子が良かったシャビがいなくなったのはとても痛い．ファンボメルといいシャビといい，調子がとても良い選手が離脱しているのはせつないなぁ．今日はライカールト監督もいないそうで（インフルエンザらしい），厳しいかも…．

結局バルサ完勝

強い。審判に助けられた面があったかもしれない（統計的にホームアドバンテージの少ない審判だそうだ）けど、強い。中盤でかなりいいプレスをされていたのに、パス回しとテクニックでほとんどボールを奪われることがなかった。ただ、シャビがいなくなると展開でのアクションが減る感じ。代わりに出たモッタも良い選手なんだけど、シャビとはちょっと違う。

ただ、次はメンバー的に厳しそう。モッタ（怪我）、デコ（カード累積）、マルケス（退場）で一気にメンバーが減る。ベレッチが戻ってくるそうなんで、ちょっとはマシかな。おそらくセンターにオレゲールが入って右にベレッチ。中盤底にはエジミウソンでその前にイニエスタかな。中盤もう一人は誰になるだろう（ファンボメルが復帰できる？）。

_ ノートの電池がすごいんです

減る速度も充電速度も．3秒で 1% くらい増減していきますね．なんか面白い．

…，そろそろ替えないとダメかな．

_ Web アプリの textarea はなぜ小さいのが多いのか

trac は他の Web アプリに比べて入力しやすいなぁ，と漠然と思っていたのだけど，これはどうやら textarea（入力フォーム）の大きさによるところも多いのではないかと感じた．trac のtextarea はブラウザの横幅いっぱい（に近い）広さがあり，行数も調整できるようになっている（20 行以上あると書きやすい）．

数ヶ月前に同僚に紹介されてResizable Textareaという Extension を使っている．たしかにコレをつかえば，大きくしたりできるけど，「プレビュー」とかで submit してしまうとまたもとの大きさに逆戻り．ふたたび resize する手間がかかる．

blog のコメント欄とかならいいんだけど，blog の本文や wiki の入力では，幅広で大きい方が見通しがきいて編集しやすい．Wiki では外部リンクを

[http://www.example.com/example/url/index.html example ですよ]

みたいに書くことが多いが，幅が狭いとこれが途中で折り返されることが多く，非常に見にくくなってしまう．hiki では，表示と編集で同じスタイルを使っているため，サイドバーが表示されないにもかかわらず左側 20% をあけてしまっているので，残り 80% の幅で編集しないといけない（さらに，テーマによってはそのなかで margin とか padding が指定してあってさらに狭くなる）．

ということで，（自分も含めて）Web アプリを作る人には，textareaのサイズを可能な限り大きくすることを検討して欲しいなぁと思う次第であります．さて，sf.jp やslashdot.jp やjapan.linux.comも修正していく必要があるねぇ．> 自分

textarea が大きいと

2げっとコメントみたいなのが減るという効果はないだろうか．こんな広い入力フォームにちょびっと書いて submit は気が引けるとか…．

ないな．

_ bounce が From: に来るのは流行？

いくつかのメールサーバは Recipient From（Return-Path:，SMTP の MAIL FROM: で指定するアドレス）ではなくて，ヘッダのFrom: のアドレスに bounce を返すようだ．RFC2821の 6.1 には

If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line).

と書かれている．つまり「Return-Path: のアドレスに送らなければならない」のだ．

せっかく Return-Path をいじってエラーを自動処理させてるのに，まったく意味がないよ…．

_ アレゲ 2.0 とはこういうのをいうのか!?

以前のエントリでアレゲ 2.0 とか言ったんだけど、これはまさしくアレゲの名にふさわしいかも。だって自宅に加速器ですよあなた。大学の時に加速器を使って何度か実験したけど、起動前にはピーピー言っておいてある部屋から出ないといけなかったなぁ、と思い出した。べつに管理さえしっかりしてれば（そこが不安なんだろうけど）ものすごく危険というわけではない（だって、東山動物園のすぐ裏にある加速器で実験してたもん）。

まぁ、自分のうちには置きたくないねぇ…。 ← アレゲじゃない

_ Ｗ杯のシード国決定！日本は第４ポット

いよいよ近づいてきたと実感するときだね。

_ たこ焼き

この間安売り 1,000 円で電気たこ焼き器を買ったので、今日作ってみた。なんか前飲み屋で作ったときよりもきちんとできたような雰囲気。味はさすがにお店の方が良かったけど。ポイントはしばらく待つことかな。じっくり待ってまわりを焼いてそろそろかなと思ってももうちょっと待って、そしておもむろにくるっと。

ただ、作り方はへたくそなので、汁の入れ具合が足らなくて最終的に穴みたいになってしまったりして。まだまだ修行が足らないようだ。

ともあれ、たこ焼きはおもしろいので近いうちにまたやろう。というか、たこ焼きパーティしたいねぇ。

_ Web 複数セッションを使ってテストしたい

アカウントによって権限や見えるページが変わる Web アプリをテストするときに、それぞれの複数アカウントでテストしたいんだけど、通常の Webブラウザだと 1 セッションしか使えない。cookie changer extensionみたいなのがたしかあるはずなので、それを使えば良いんだけど、他になんか方法ってないかなぁ。タブごとに cookie を切り替えられると一番楽なんだけど…。

_ 誤解されているのでは？？

技術屋のエートスを読んで，書かれていることはもっともだと思うんだけど，技術ニッポンの黄昏の文章を誤解しているような感じ．

ほんらい、技術屋と事務屋の対立関係というのは、技術屋が採算を度外視してできるだけ 質の高いものを作ろうとし、それに対して、事務屋が「それではコストが合わない」と 言って質の切り下げを画策するというかたちで展開するのが「常道」である。 それが逆転している。

もし、技術屋が事務屋の御意にかなうように、すすんで法的規制「以下」のことをする 傾向があるというのがほんとうなら（耐震強度偽装事件を見ると、どうもほんとうらしい）、 それは戦後日本の繁栄を支えてきた「技術者のエートス」というものが死滅しつつあると いうことである。

（引用太字は筆者による）

つまり，「それが達成できないのは『技術者の怠慢』であるかのような話」ではなくて，すすんで自ら積極的にこういったことをやるのは「技術者のエートス」の欠如ではないのか？という話だと読みましたがいかがでしょう…．

まぁ私も技術者のはしくれなので，安かろう悪かろう（とりあえず動けばいい，みたいな）といった感じのものを作ろうとする方向性ははっきりいって嫌いだけど，でも市場がそういうところを求めているなら仕方のない部分もあるな，とは思う．でも，自らすすんで安かろう悪かろうものを作るということはしない（といっても悪いモノができちゃうことは多いんだけど… orz）．

ということで，なるべくよいものを作ろうという気概のない技術者は技術者（アーキテクト，エンジニア）と呼んではいけないという思いもある．

_ ワールドカップ組み合わせ

縁があるなぁ、ブラジルとは。しかし、微妙なグループ。

ドイツは比較的楽な展開になりそうだね。

_ ドイツ行きの身支度開始

ともあれとりあえず。6/7,8 あたりにドイツに渡って、6/24 に帰ってくるというあたりで調整できるといいな（希望）。とりあえずの目的地はミュンヘン・カイザースラウテルン・ニュルンベルク・ドルトムント。

_ LeafのゲームタイトルにGPL違反の可能性

これは，やり方次第だけども「災い転じて福となす」に出来そうな予感．実際にどういう形式なのかは良くわからないけれど，ソースの公開がエンジン部だけだとしたら．

どのようなゲームなのかは良くわからないが，サウンドノベル系のゲームであれば，データがあってこそのゲームの質だと思う．だとすると，エンジンのソース公開はそれほど大きな痛手にはならないのではないかと考える．たしかに，同業他社にこのエンジンを使われて同じようなゲームを作られてしまうかもしれないが，消費者はエンジンで商品を選んでいるわけではなく，ストーリーやエロ絵などの質で選んでいると思われるからだ．

で，「福となす」方法．聞いたところによると，こういったゲームのエンジンは，解析されて(?)クローンを作って公開している人がいるそうだ．たとえば，これを使えばデータを持ってくれば Linux 上でもゲームを楽しめる（データのライセンスの問題が生じる可能性がないとはいえないけど）．で，正規版のソースがGPL で公開されるわけだから，今後はほぼ正規版のエンジンを作ることができるわけだ．とすれば，今後このゲームはマルチプラットフォームで動作させることができるようになるだろう（このようなゲームのファンには Linux など他の OS に精通した技術者が多いと推測できるから）．つまり，他の OS のユーザにも門戸を広げられることとなり，結果的に売り上げが伸びる可能性がある（伸びないかもしれないけど）．

また，こういったユーザはさらにおもしろくなるようエンジンの改造を企てるかもしれないし，気になるバグがあれば直して使うかもしれない．一般のゲームユーザよりは技術力も意欲も高い人が多そうなので，よりおもしろいエンジンができそうだ．そうなったとき，企業はその成果を利用することができる．つまり，（製作する）コストをかけずに，新機能を手に入れることができる（しかもそれはおそらく（消費者自身が実装するんだから）消費者が望んでいる機能であろう）．これにより，商品の価値をより高めることができる可能性がある（ただし，同業他社も同様のモノを利用できる）．

これは，オープンソースのソフトウエアを利用し，そこで利用するデータを販売するオープンソースビジネスのやり方の一つだと思う．まぁ実際にこういう形にするかどうかはわからないけれども，可能性としてはおもしろいんじゃないかな．

オープンソースではないけど，Adobe はPDF Viewer (Acrobat Reader) を無償配布し，この分野での標準フォーマットとして PDF（と標準フォーマットを策定する Adobe）を確立させ，PDF 製作ソフトを販売するというビジネススタイルをとっている．フォーマットは公開されているから，同業他社も同様のビュワー・クリエイターを作成することが可能だが，これまでの経験の蓄積をベースにしたフォーマットの拡張とそれに合わせた新バージョンのリリースで業界をリードしている．Adobe の場合はソフトを売っているが，データを売るという形に変えて，Adobe のようにうまくやっていけるかもしれない．

かの企業は，ソースコードを単に公開するだけでなく，sf.jp や sf.netなどで，オープンソースのスタイルで開発を進めていくということにするとおもしろくなるのではないだろうか．日本の大企業も sf.jp で開発を進めているプロジェクトがあるし．

_ tDiary referer spam 対策の最終形?

だれかが既に考えて作っている気がするんだけど，現実逃避に作ってみた．

• pagecheckreferer.rb

これを tdiary/filter 以下に置けば自動的に動作…にしたいんだけど，いまは自動では何もしない．データファイルのパスを指定する必要がある（設定の詳細は後半）．

何をするかというと，open-uri で referer URL にアクセスし，その中にHost: ヘッダのホスト名が入っているかどうかをチェックする．リンクかどうかはチェックしていない．これを PStore に保存しておき，二度目以降はアクセスしに行かない．パーミッションさえそろえておけば，（信用できる）他のユーザともファイルを共有できる．

この PStore の中には，URL を key にして，アクセス回数が入っている．正当な referer の場合は正の数が，referer URL にホスト名が入って居なかった場合は負の数が入る．二度目以降のアクセスの場合は，負の数が入っている場合に限りデクリメントされる．

回数を入れている理由は二つある．統計に使えるということがまず一点で，もうひとつは数を利用した制御をするためだ．referer spam は大量に送り続けるので，放っておくとどんどんインクリメントされる．このときにはtDiary のスクリプトが動くので，サーバに負荷がかかってしまう．それを低減させるために，tDiary に入る前，apache で制御してしまうのだ．mod_ruby で URL rewriteのように，mod_ruby を利用してこのデータを読み込み，一定数以上の場合は403 を返すようにする．こうすると，tDiary が動く前に処理でき，サーバにあまり負荷がかからない．

気をつけないといけないのは，たとえば一時的なネットワークの不具合によって referer URL にアクセスできなかったときや，見るのに cookie が必要な一部のサイトのときは，referer spam と判定されてしまうことだ．だが，referer filter はあくまで referer を保存するか否かの判定に使われるため，referer が保存されなくなるだけでアクセスには影響がない．よって，これくらい厳しいフィルタでもあまり問題ないと考えている．

むしろ問題となりそうなのは，PStore を使うことによる負荷だ．ちょっとしたテストスクリプトで PStore のアクセス速度を調べてみた．

      user     system      total        real
  0.140000   0.030000   0.170000 (  0.170299)
  0.060000   0.030000   0.090000 (  0.095428)
  0.420000   0.100000   0.520000 (  0.526370)
  5.340000   0.610000   5.950000 (  6.147076)
 81.250000   5.760000  87.010000 ( 93.595241)

上の表は，PStore の root を 100 回（うち 50 回はヒットしない文字列）取得したときの結果だ．このフィルタが行うアクセスと同様のアクセスを行うようにしている．表は上からroot が 10 個，100 個，1000 個，10000 個，100000 個である．上記を見ると，10000 個のときは一回 0.06 秒程度だが，100000 個になると一回 0.93 秒となり，目に見えて遅くなるはずだ．そのため，ときどきcleanup する（ファイルを消せばよい）か，はじめから登録しないようにする必要がある．そこで，登録しない URL の正規表現を指定できるように設定項目を作ってある．

設定項目

以下の二つ．

@options［'pagecheckrefererfilter.autolist'］

上記 referer データを保存するパス

@options［'pagecheckrefererfilter.userlist'］

上記 referer データをチェックする前に手動で判断する正規表現の hash

userlist の方は以下のように書く．

{ %r!^http://tach\.arege\.net/! => 1,
  %r!^http://example\.jp/! => -1 }

1 の場合は無条件に許可，-1 の場合は無条件に不許可．

デフォルトで有効でないわけ

このデータファイルはいわばただのキャッシュなので，tDiary のキャッシュディレクトリに作成してしまえばよいと考えた．しかし，Filter objectに渡されているのは @cgi と @conf だけで，このなかには cache_path が存在しない（たとえばプラグインには @cache_path として渡されている）．よって，デフォルトでは動かない（かならず true を返す）のでありました．

有効性

いまのところすばらしく有効．仕組みに穴はないんじゃないかなぁ…．考えつかないだけかもしれないけど．

_ ユーロ高

もうちょっと安いときにいくらか買ってるんだけど，citibank ではユーロのままおろして使えないのかな…．ドイツ行くときに使えるといいかなと一瞬思ったんだけども．半年後さらにユーロ上がっていたらやだな…．ユーロの MMF でも買っておいて（為替手数料が安いやつ），さらに高くなってたらこれを売って現金に換金，安くなってたらそのまま保持という形にするのがいいかな…．ちょっと考えてみよう．

いまのうちに現金にかえておくとかユーロのまま使える口座をどこかに作るという手もあるけどね．

そいえば，ドイツ国内で ATM から現金がおろせるんだろうか．citibankのカードなら大丈夫かな…？

_ FC バルセロナ 2 - 1 セビリア

なんというか、バルサ強い。守りが堅い相手に一点を先行されて厳しくなるところをしぶとく逆転勝ち。中盤のレギュラー（ローテーションだからレギュラーといえるかは微妙だけど）が怪我や出場停止で 3 人とも欠けていてもこの強さ。

（イギリスでの）チャンピオンズリーグのオッズでは第一位がバルセロナで二位がチェルシーだそうで、もはやこのチームを止められるのは国内にはいないのではないだろうか。

でも、レアルマドリーも復調のきざしが見えてきてるので、カンプノウでのクラシコでは、昨シーズンとおなじように負けちゃうかもしれないけど…。そうはなってほしくないけどね。

_ クリスマス!

今年もこのシーズンがやってきました。まつもとさんとこみたいにテーマ変えたりはしないけれども、これは紹介しておかねば。ぜひぜひ聴いてください。おすすめ。

はんばあぐさんあたりが書くかなーと思ったけども。

_ 多忙状態から復活しました

まだタスク山積みなわけですが，自分の時間はとれそう．

_ 教員採用は女性優先＝「業績同じなら」−名古屋大

また変なことをしてるなぁ…．

たしかに，物質環境構造学講座教員公募とか専任教員の公募についてあたりを見ると，

業績（研究、教育）の評価において同等と認められた場合には、女性を積極的に採用します。

と書かれている．

でも，本当にそれでいいの?

たしかに，大学の先生方は男性が圧倒的に多く，これだけ見るとなんか良い方向にみえなくもない．けれど，これって逆に見ると男性差別なんじゃないの? と思えてしまう．まぁ業績が同等ということがあまり無いから良いのかもしれないけど，これで「あなたは男性だから不採用」となったらそうなった応募者はどう思うだろう．

そもそも採用判定に性別を用いる方がおかしいと思う．性別が重要な要素をもつ仕事（更衣室の掃除とか）ならともかく，そうでない仕事であれば男女は関係ないはずだ．より研究や指導の助けになってくれそうな，業績をあげそうな人を採用すればいい（面接だってするんだし）．「女性だから採用」とか「男性だから採用」ってなんかおかしいよ．

男女同等もいきすぎるとおかしくなるけど，これはもっと方向がおかしい気がする．自分が採用されたのは「女性が少ないから」という理由では，当の女性も喜ばないのでは?

_ 舛岡富士夫教授「日本発の三次元半導体で歴史を創る」

帰宅してつけたテレビの NHK スペシャル再放送から．かなり古い話題（最初は 1989 年!）なんだけど，初めてこの技術を知った．たしかに難しいけども，できればすごいね．すごい．すごい．

_ iTunesに挑むオープンソースソフトウェア「Songbird」

こういうのが出てくるのはうれしい。iTunes に挑むというのは大きく出てるけど、iPod を使うユーザは iTunes を使うだろうから（でも、Apple はiTunes で商売している訳ではないので、Songbird が iTMS に対応してiPod ユーザ以外、Windows/MacOS ユーザ以外でも便利に使えるのであればおもしろいかもしれない）iPod を使わないユーザ向けだね。

ぼくは、 iRiver フラッシュメモリープレーヤー T10 1GB オレンジイエロー [T10 1GB-OY] ユーザで、メインは OGG Vorbis でエンコードされた曲を聴いてるから、この二つに対応していればいちばんうれしいかな。Linux 対応は当然としても。

日本語カタログがまだ無いみたいだけど、きっと誰かがやってくれると思うのでとりあえず待とう。誰もやらなかったらいずれ手をつけざるを得ないと思うけど、いまは他のことで忙しいので…（ぉぃ）。

_ GPLに基づくソース配布の方法として、郵送させていただく事となりました。

以前のの結果。なんで Web からダウンロードではなく面倒な方法をとるようにしたんだろう…。

• 要求があった場合にだけソースを出せばいいので一般流出を避けられる（と誤解している）
  • GPL なので、受け取った人はそのソースを不特定多数に配布できるから意味無し
• ソースを持っている人を特定できる（という誤解）
  • 上記と同じ理由で意味無し
• ソースを渡した人にサポートする義務がある（という誤解）
  • NO WARRANTY なのでその義務はない

ほかになんか理由があるかなぁ…。

ともあれ、手に入れた誰か（ぉぃ）は、sf.jp/sf.net あたりにアップロードしてですな、マターリと改良すると良いかもしれない。いや自分で手に入れてもいいんだけどね…。このへんのゲーム持ってないからちょっと躊躇ぎみ。もってなくてもくれるみたいだけど。

_ Amazon ギフト券

Amazon でプレゼント買って友達に贈ったんだけど、ギフト券還元セールとかでギフト券がきた。で、ちょうど靴がぼろっとしてきたんで Amazonのスポーツショップでお気に入りの靴を買おうとしたら…。ほしいサイズは売り切れですかそうですか…。というか、ほとんど売り切れじゃん…。仕入れている数がすくないんかねぇ。いろいろ Web 探ってると、他のメーカでもよさげなウオーキングシューズがあるねぇ（当然）。最新版を一度はき比べてみた方がいいな。彼女の人も買う物があるので、年末年始に一緒にスポーツ用品店にでもいこう。

別の何かを買うのが良いかな。コンフェデレーションズカップ 2005 の DVD（その2）（その3）（その4）でも買うかな。

_ UEFA チャンピオンズリーグ バルセロナ vs チェルシー

事実上の決勝戦（だと勝手に思っている）なわけですが、日程を確認してびっくり。来月の 1st legはロンドンなんだけど、カンプノウでの 2nd leg は 3 月 7 日ですよ!?誕生日プレゼントに最適（ぉぃ

_ ドイツいくにはドイツ語が必須か…

やっぱドイツは（フランスも同じかな）ドイツ語でいろいろ済む国だけあって，英語での情報が少ない感じ．たとえばドイツ鉄道のページを見ても，ドイツ語の情報がほとんどで，International Guests のページは基本的な情報だけしか載ってない感じ（ワールドカップ特設ページも無い）．とりあえず，路線図を（世界地図からコピった）ドイツの地図に書き込んで，鉄道路線と都市の位置関係などを確認．

どの都市がどの辺にあって（主要都市がどのあたりにあるかというのはわかる，地理好きだし）どれくらいの時間で移動できるか，その経路はどんなのが考えられるか，などということがすぐに出てくる程度にはしておきたい．旅行プランを考えるときは，これらの情報が頭の中に入ってて，楽にいけそうか厳しいかなど感覚的に把握していることが重要．そうじゃないとひとつのプランをたてるのにえらく時間がかかる．ただ，日本の場合はよく移動しているので，新幹線の感覚とかよくわかるんだけど，他国はさっぱりだね…．

とりあえず，上のこともあるのでドイツとスペインに関する情報収集のため，今日のタスクは

• 旅行代理店（JTB）に行ってパンフレットを拝借してくる
• 本屋（三省堂）に行ってよさげな本・雑誌を買ってくる

というところかな．年末年始で勉強しよう．

_ Tracwiki スタイルでのカテゴリの扱いをどうするか

未来日記になるけど、書いてしまおう。

TracWiki の文法では、 はリンクを表現するのに使う。なので、tDiary での一般的なカテゴリの使い方（サブタイトルに カテゴリ名 を入れる）がこのままではできない。どうするのが良いんだろうと小一時間考えてみた。

1. サブタイトルの先頭だけ をカテゴリとして扱う
   • ○ - 標準のものそのままなので扱いやすい
   • × - いきなりリンクから始めるサブタイトルを書けない
     • http:// ではじまるもの（カテゴリに使えない文字（そんなのある？）が含まれているもの）がきたらカテゴリではない、というのでもいいのかな
2. TracLinks のスタイルを使って表現（category:CategoryName みたいな）
   • ○ - TracWiki のスタイルには合ってるかも
   • × - 標準と違うので扱いにくい
   • × - 長いからカテゴリを書きにくい

前者のでいいかなぁと思うんだけども、知恵をください…。

この問題が解決すれば…

あとは細かいバグフィクスをして、ML に投稿できる。この時点で取り込んでもらえるとうれしいけど、これはとりあえず安定版として終了させて、リファクタリングを行う。今のコードは動くけどちょっとださいから。

_ 今年の垢は今年中に落とす

というわけで，残しているタスクを今夜と明日でがんばって作業します．バグレポートも受け取ってるし…．

_ drk7.jp ダウン

していて、amazon_search プラグインで動作がブロックされてた。まぁ、エラー処理なにもしてなかったので、とりあえず rescue で例外処理をするように追加。

で、ここで二つハマったのでメモ（一つめは知ってたけど）。

open-uri はタイムアウトを指定できない

指定するインターフェースがないので、timeout.rb を使ってタイムアウトを指定する必要がある。

Timeout::Error は StandardError のサブクラスでない

つまり、rescue にきちんと指定しないと捕まえられない。rescue はなにも指定しないと StandardError のサブクラスを捕まえる。通常はすべての例外を捕まえるときはなにもしなくて良いんだけど、StandardError のサブクラスでないものが発生する場合は、それを書いておく必要がある。

ということで、修正点を commit。

自分が焦ってるときは正しい見方ができないね

他人の力を借りると、客観的に見てくれるのでポイントがわかる。ありがとう＞すぎし

_ 垢落とし

• backports.org エラってた → done.
• 投票（12/31 まで） → done.
• キーサイン（JDMC2005 の分、遅…） → done.
  • サインしてもらった鍵を import して revuid して send-keys
• amazon_search の原作者にメール → done.
• referer spam filter について tdiary-devel に投げ → done.

_ 「やめること」を先に考えよう

なるほど。たしかに「あれもやろう（やりたい）、これもやろう（やりたい）」とかで結局すべてができない or 中途半端になってしまうという自分がいる。来年の抱負もだいたい決まってて、それはすべて「やること」なんだなー。人間って持ってる時間や能力は決まってて、いくら睡眠時間を削っていろいろやろうとしても無理なことは多い。

物を処分するということは（判断が楽なので）よくやっているけど、やりたいことを処分するのは難しい。でもそれをやっていかないと、きっとやりたいことの中に埋まってしまって、本当にやりたいこと・必要なことを見つけるのが困難になってしまうんだろうな…。

ということで来年の抱負に一つ追加しよう。「『やめること』を考える」←またすることが一つ増えただけ。

だめすぎ（わら

from ただのにっき

_ 処分しようと思っている本

何を読んだかとか忘れてしまいそうなので、メモ的に。役に立ちそうな話題とかは trac のほうにメモったりしてるので、ここで紹介するのは趣味系というか楽しむための本。

• 東京の地理がわかる事典
  • 地理好きには良い本。ここはなぜこうなってるのかとかいう感じで話題ごとに Q & A みたいに答えてくれる。「江戸の範囲はどこまで」とか「秋葉原はどうして電気街になった」という感じ。読むとおもしろい。
• 道と路がわかる事典
  • 道路好きにはまたまたたまらない本。これもひとつひとつ話題ごとに解説してある。「渋滞はなぜ起こる」というみんなが思っていることから「トンネルの定義と種類」といったマニアにうけるような話までいろいろ。一通り知識を仕入れる（入門）には良いかな。
• 儲けの仕組み 欲望産業の原価がわかる本
  • どうやって風俗店が運営されているかざっくりとわかる。店代は？女の子の取り分は？とかちょっとした歴史まで。といっても風俗を運営しようなんて思ってないけども。ただ、ここに書かれている以上に大変だと思うなぁ。
• 大人力検定
  • R25 で連載してたコラムの書籍版、かな。設問があって 4 択で回答して、どんな回答をすればオトナか、というものが 100 問くらいあるかな。まじめなのではなくてまぁネタなんだけど、要は当たり障り無く相手に気持ちいい思いをさせてあげるようなのがオトナということかな。