Diary?::2008-02

(23:37)

現場が変わって早速初日からとんでもない仕事になったというか、あのさあ、一ヶ月間のみ有効な制限ライセンスで 10 万円って、それ詐欺じゃねえのか。そして俺の現時点でもっともプライオリティの高い仕事というのは、

• そのソフトウェアの性能の評価
• Java API から呼び出してのプログラミング技法の調査
• 実際にアプリケーションにしてみての評価

これらを一ヶ月でキチンとやらないといけないわけだ。他の仕事の割り込みがなければ目処は立ってるんだが、俺にはフレームワークの拡張の仕事も割り振られていて、そっちがどんだけ優先度が高いのかにもよるなあ。一番辛いのはとにかく相談できる相手がまたしてもいないことで、どうにも会社の連中は俺を黒魔術師とでも思ってるんじゃないか、やっぱり。

それにしても、こういう仕事が俺にばっかり降ってくるのは不健全としか言いようがないな。これじゃあ後進がまったく育たんよ。頃合いを図って、共同作業者を付けてもらう用に頼んでみるかな。実際今回はほぼ完全新規開発で、恐らく上層部としても様々な部分でのブレイクスルーを期待してるはずだからな。ここらで他のメンバーのレベルも底上げしておかないと、会社全体がジリ貧になるだろうし。

(00:23)

俺はほぼ完全な技術屋というか職人の地位らしく、クライアントと業務要件を詰めたりという仕事は降ってこないのだけど、それでも何も知らないのはまずかろうということで、今回の案件の業界についての基礎というか入門書を渡された。どんな業界かはちと書けないのだけど、何であれ開発者が対象の業務について何も知らないのはたとえ直接業務部分を書かないとしてもやっぱりまずいので、こういう判断は完全に正しい。

ただその一方で、クライアント側は依然として俺たちソフトウェア業界のことを知らないのだ。これはどう考えてもアンフェアだ。これは俺たちに有利過ぎる状況で、こういった情報格差は不正利益を合法的に生み出すといっていい。俺は不正利益を掠め取られるのは死ぬほど嫌だが、不正利益に手を出すぐらいなら本当に死んだ方がマシだと思っている。

そして今回の案件では今までとは違う人が上司になって、その人はかなり熱心な XP やアジャイルの推進者で、つまりこのアンフェアな状況をどうにか出来るかという問題に取り組むための役者は揃っているわけだ。技術者には自身の思想の科学的な正しさと社会的な正当性をソフトウェア開発を通して証明する義務がある以上、俺にはもはや「逃げ」の選択肢は残されていないということだ。

もっとも、後退のネジなんざとっくの昔に捨てちまったがな。

(11:40)

>>> chikara = KuwataChikara()
>>> chikara.add_age()
<type 'exceptions.NotImplementedError'>: 現実を受け入れるつもりがないようです
>>> chikara._age += 1
<type 'exceptions.AttributeError'>: 'KuwataChikara' object has no attribute '_age' 
>>> chikara._KuwataChikara__age += 1
>>> print chikara.get_age()
<type 'exceptions.NotImplementedError'>: 現実を受け入れるつもりがないようです
>>> print chikara._KuwataChikara__age
24

友人からのメールで、昨日が自分の誕生日だということに気がついた。いや、マジで忘れてた。しかし俺も 24 か。何か去年一年間をドブに捨てたような気がするので、年を取ったという実感がないというか、ただでさえ年なんざ取りたくないってのに、これはちょっとなあ。

(03:12)

ここ一週間程、前の現場の引き継ぎだとか友人の修論手伝ったりとかで忙しくて、ろくすっぽギターに触っていなくてこりゃあヤベエと思ってこんな時間に練習開始。……流石に一週間もサボると衰えるなあ。これだから中々上達せんのだよ、俺は。

(20:03)

今朝は起きたら大変なことになってた。何だよこの雪は。あまりの寒さに生きる気力が失われていくようだ。

それはともかく、すげえ今更なんだけど PHP はダメ言語かどうかについて。ダメかダメじゃないかの二択で答えろって言われたら即座に「ダメ」と答えるんだが、多分そんなことよりももっと重要というか一番ダメなのは「PHP で簡単に Web アプリ」とかいってる連中で、まあこれは PHP に限った話じゃないか。実際のところ、初心者が適当に作った Web アプリでも被害が出ることはあるんだからな。

すげぇ適当な事例を書くと、次の cgi スクリプト (の一部) は spam 送信に悪用可能である。公平性のため、俺にとって第二の母国語である Python で書いておく (PHP で書いたら電波がよってきそうだからな!)。

from cgi import FieldStorage
from email.mime.text import MIMEText
f = FieldStorage()
subj = f['subject'].value
from = f['from'].value
msg = f['msg'].value
m = MIMEText(msg)
m['Subject'] = subj
m['From'] = from
m['To'] = 'admin@example.com'

さて、ここで送信されたデータのうちの "from" でも "subject" でもいいから、次のようなデータが入っていたらどうする?

foo@example.net\nBcc: bar@example.org

これを受け取った状態で MIMEText の as_string を呼び出すと、次の様な結果になる。

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Subject
From: hoge@example.net
Bcc: foo@example.org <- 見事に Bcc が追加されてる
To: admin@example.com
-- 以下、メール本文 --

これはヘッダインジェクションという奴だ。一見すると単に入力データに改行が含まれていないかどうかだけのチェックをすれば良さそうだけど、実は長すぎるヘッダには折り返しを行うようにと RFC には書かれていて、そこで折り返し処理の書き方次第では、この部分でヘッダインジェクションを行うという事が出来てしまう (実際には今の MTA は大抵長いヘッダを問題なく処理できるはずだけど)。なので、ヘッダインジェクションのチェックというのは思っているよか面倒くさいわけだ。ところで今はどうだか知らないけど、 PHP のメール関連の関数には先に出した折り返し処理に関連する脆弱性があったはずだ。 Python は email.Header がこの折り返し処理とかには対応している。他の言語は知らない。

追記: Python の email.Header はあくまでも長いヘッダの折り返しだけなんで、それ以外のことはやっぱり個々のプログラマがやんないとダメ。ところでこの折り返し処理って、 Django の email 系の処理ともろに競合していて、 email.Header で折り返しの付けられたヘッダを Django 側が削除しちゃうって話を聞いたことがある。その後どうなったのかは知らない (この手のフレームワークを使う事にあんま興味ないんで)。

ちなみにこれはメールフォーム CGI で起こりうることで、ちょっと見栄張って自分で作ったメールフォームを設置したら spam 送信に使われちゃいましたなんて笑えない事態もありうるわけだ。なので、あんまり「簡単に作れます」と吹聴するのはなあ。事実、これと同じかどうかは知らないけど XOOPS とかのメジャーなアプリケーションでも spam の踏み台にされるような問題があったり、共用サーバとかだとさらに DB や Web サーバの権限とか、いろんな問題があるわけだ。なので俺は「初心者はPHPで脆弱なウェブアプリをどんどん量産すべし」なんてことは口が裂けても言えない。

とりあえず俺に言えることは、

• ネットワークアプリケーションは「簡単にできる」という謳い文句とは程遠い代物だ
• その性質上、他人に迷惑をかけないようにネットワークアプリケーション開発を学ぶのは大変だ
• あまりに「簡単に出来ます」と言ってる連中は詐欺師か恥知らずかその両方かだ
• PHP は今のところバージョンに限らず最初に覚えるべき言語ではない (将来大幅にレベルアップする可能性はゼロじゃないけど)

程度だ。

(21:58)

うーむ。確かに技術的には面白いところで、割とチャレンジ精神を感じるんだけど。これ、俺一人で独占しちゃっていいの?

まあそれは明日考えよう。それよか会社帰りに「魔人探偵脳噛ネウロ」の 15 巻が出てるのを発見 & 購入。相変わらずギャグパートも上手くて納得の出来で、特に獄中のディビッドのネタが相変わらず不謹慎というか怖いもの知らずで最高だった。電車の中で読んでて笑いをこらえるのに必死だった。

(22:36)

コンビニで買ってきたホットケーキが変だ。何が変って、匂いが変。もずく酢っぽい匂いがする。まあ、シロップとホイップクリームかけたら気にならなくなったけどな。

(21:50)

• 普及してるのはプロプライエタリなものばかり
• フリーなものは普及率で遅れを取ってる

だから俺はマルチメディアフォーマットの世界には足を突っ込みたくなかったんだよ。

(00:32)

初心者用プログラミング言語について。身も蓋もない結論から書いてしまうと、そんなもんあるわけねーだろ、ヴォケ。どんなプログラミング言語にも得手不得手はあって、最初に持った目的を容易に達成できそうな言語を選んだら、他の部分でどん詰まりになるなんてのはいかにもありそうな話だ。

それじゃあどんな言語でもいいかというとそれは全然違う話で、最初に覚えるべき言語が備えているべき特性はいくつかあげられると思う。パッと思いついたのは次のような感じ。

• 導入が簡単。世の中にはどのパッケージを落とせばいいのかすら初見じゃさっぱりわからん言語もあるが、そういうのはまず最初に学ぶに値しない
• 開発環境が端末とエディタだけでもやっていける。 IDE は初学者にとっては邪魔なだけだ。そういう言語を勧める奴は、単に頭が悪いか自分が初学者だった頃のことをすっかり忘れているのだろう
• 複数のパラダイムを扱える。関数プログラミング (クロージャと高階関数があれば関数プログラミングをサポートしてるといっていい) とオブジェクト指向プログラミング (これは多くの言語でサポートされてるか) があれば、とりあえずどうにかなる (マクロやテンプレートといったメタプログラミングはどうしたものか。一度やっといて損はないと思うけど)
• オフィシャルサイトのチュートリアルやリファレンスがしっかりしている
• その言語で書かれた実用的なソフトウェアのソースが容易に手に入る。他人のソースはいつの時代もいい教材だ
• フリーソフトウェアである。言語に限らず、プロプライエタリなものにどっぷり浸かるのは危険極まりない

ところでもっと身も蓋もない事を書いてしまうと、プログラミングに打ち込むんならガタガタ言ってねえでとっとと Unix 系 OS に乗り換えろなんだけどな。 Windows と違って、プログラマのためのお膳立ては充分過ぎるほど揃っている。

追記: 「まともな文法」を入れるのを忘れていた。ちなみにまともな文法の定義は「一貫性がある」「シンタックスシュガーが無意味に多くない」の二つ。あとはあれだ、モジュール性。これは真面目に書くと長くなりそうなのでまたいつか。

(21:36)

結局、 Ogg に助けられる形になった。まだまだ課題は山積みだけど、特許とロイヤリティの問題はクリアできる見込みが出来た。本当、こういうフォーマットの存在は有難いよ。後出しジャンケンで金をせびり出した Fraunhofer とか Unisys の連中は xiph の人たちを見習えってんだ。特に後者は GIF を扱うフリーソフトウェアを駆逐したからな、相当罪は重い。

(23:05)

流石に俺以外の人間がさっぱり手出しできない今の状態は非常にマズいので戦力を増やしたいのだが、そうなるとネックになるのが人材の育成である。ぶっちゃけ全然育ってないからなあ。そして何より人がいない。ああ、今研修やってる新人を使うという手もあるか。

ところでその人材育成だけど、やる気があって酷く頭が悪いわけではない人なら、別にこっちがあれこれ教えなくても勝手に勉強して勝手にレベルアップしてくれるものだ。なので、俺はプログラマの教育に関する問題は恐らく

• やる気があるのに学ぶ機会を奪われている人をどうするか
• やる気があるがやり方が恐ろしく間違っている、あるいは何をやっていいかわからない人をどうするか
• やる気の無い奴をどうするか

というものだろうと思っている。二番目の奴は相手がよほどの大バカものでもない限り、多分問題にはならない (実際問題になったことは大学の時に一回こっきりである)。三番目の奴はどうしようもないので放置するしかない。となると、早急に解決しないといけないのは最初の奴だ。多分。そしてこの学習機会損失が起こる原因は

• 忙しくて勉強する時間が無い
• 仕事から得られるものが無い

の二つの合わせ技だろうと思っている。忙しくても仕事から得られるものがあればスキルアップになるし、仕事が簡単でも余裕があれば一歩上を目指す余力が生まれる。そして先月までいた現場はこの複合技でやられていた。そしてこの考えが正しいと仮定するなら、本当に解決するべき問題は真に無駄な作業時間をどうやって減らすかになって、そしてこれは

• 本当に必要な作業かどうか管理する側と管理される側で合意が取れていない

というのが真相な気がする。そして前の現場では成果物の運用とか成果物の作成方法とかそもそもの成果物の定義が全然一貫していなくて、振り返って見ると結局は単なる無駄骨だったというのがとても多かった。そしてそういった無駄骨で相当な労力を消費していて、心身ともに疲弊してやる気デストラクションというのが日常的な光景だった。

じゃあ解決策は何かと言うと、えーとね、ぶっちゃけ一般解は無いと思ってる。お互いに何が問題なのかという認識を正しく共有するのは難しいことだし、そもそも本当に何が問題か誰もわかっていない。なので、俺が上に書いたことが凄まじい的外れという可能性は多いにある。

人材育成の話から逸れた気がするが、いつものことだからまあいいや。

(23:04)

どうにも俺は無駄に潰しが効くせいか、独立愚連隊のような形で仕事をすることが多いんだが。でもこれ、俺がいなくなったらどうすんだろ。頓挫するよな、明らかに。一応作業メモとかはこまめに取ってはいるつもりだし、時間をちょっともらえればそれなりにドキュメントをまとめることが出来るけど、でも問題はそんなことじゃないんだよ。

俺が今の職場で一番問題にしているのは、とにかくみんな問題解決のための引き出しが少ないことだ。ぶっちゃけてしまえば、殆どの社員はフレームワーク上で決まりきったコードを書くということに慣れきってしまって、さらに突っ込めばそういった連中は Web アプリ、それも DB フロントエンドもどきの業務アプリしか書いた経験が無いように見える。なので他のアプリケーションをどうやって書いたらいいかとか、ライブラリやフレームワークをどうやってデザイン・実装するかということを考えもしないのだ。これは技術者としては相当マズイ。今振られている作業は明日にはおおよその目処を付けられるので、ここから先をどうするかについてもう少し長いスパンでの話をしておかないとな。

話は変わるしどーでもいいけど、雨後のなんとかのようにフレームワークとかが出てくる理由は単純で、

1. アプリを作る上での面倒ごとを解消しようとする
2. たまたま上手く行ったのでそれを公開してみる
3. 同じような問題を抱えていた人たちが意外に多く、そういった人たちの間で評判になる
4. 何が問題なのかさっぱりわかってない連中が飛びつく
5. 本来なら適用外のところにまで使われ、デザイン上の限界にぶち当たる
6. 何これ使えねー
7. 最初に戻る

ということなんだろうと思う。なので俺はフレームワークの類に関してはあまり熱をあげないようにしている。まあプログラミング言語とかその他の事にも言えることだけど、フレームワークはオブジェクト指向プログラミングに続いての、というか取って代わっての桃源郷なんだろう、多分。

(22:23)

今日は一日 Visual Studio で開発していたのだけど、相変わらず酷いソフトウェアで呆れたというか逆にその相変わらずっぷりに笑ってしまったというか。俺は普段 Eclipse に対して文句を書いているが、 VS に比べりゃ Eclipse は遥かにマシだ。大学時代に VC++ 6.0 を使っていて「何このバカちんこ」とか思ったものだけど、今使ってる Visual Studio 2005 もまったく同じバカちんこ丸出し。とりあえずヘッダファイルやソースファイルのファイルシステム上のディレクトリ構造とプロジェクトビューでの見え方が全然同期してないというデザインは早急に止めてほしいなあ。いちいち手動でフィルターを追加してそこにヘッダファイルを追加してとかやってるとミスのもとだよ。

あと無闇にマクロ定義とか条件コンパイルで型名のエイリアス付けるののどうかと思う。いや、そうせざるを得ないケースがあるのは承知してるけど、 LPCTSTR が場合によってはワイド文字列として定義されていて、ファイル系の関数に LPCTSTR として宣言した変数を渡すとパスを見つけられずにエラーとか言うのは勘弁して欲しい (そこは明示的に LPSTR にキャストしたりする必要あり)。

あと今回は様々な理由でこれまで動的ライブラリだったものを静的ライブラリにする必要があったんだけど、ここで酷い罠が待ち受けていた。 Visual Studio で動的ライブラリを作ると一緒にインポートライブラリとかいうものが作られるようなのだけど、これが静的ライブラリと同じ拡張子の別物なのである。そして静的ライブラリのようにリンカに渡しても問題なくリンクがとおり、そして実行時に dll が無くて落ちる。えーと、この仕様を考えた人って大脳新皮質を欠損してないか。

それから MSDN に載ってる HTTP まわりのライブラリ関数を使おうと思ったらプラットフォーム SDK のバージョンアップが必要で、でもそれってどう考えても VS 2005 が出るずっと前に出ていたバージョンだったような。まあ動くには動いたから別にいいけど、こういうふざけた環境で開発するのはあんまり精神衛生にはよくないな。

それにしても Microsoft のバージョン番号の振り方はまったく意味がわからん。何しろ Visual Studio 6.0 のようなバージョンで付けたと思ったら今度は .NET とか言い出して、かと思ったら 2005 とかの名前になって (正しい順番は不明。調べる気力無し)、しかも Visual Studio 2005 は実際には Visual Studio 8 という名前のフォルダにインストールされているのだ。一体何を考えているんだ。

(20:33)

スゲーどうでも良い話だけど、俺は子供の頃に聞かされた「北風と太陽」の話が嫌いだ。もう少し正確には、あれが道徳のお話とされていて、太陽が善玉というのが嫌いだ。考えてもみてくれ、北風と太陽がバカなことをやり始めなければ旅人は寒い思いをすることも暑い思いをすることもなかったわけだ。これは詐欺とか宗教とかマスコミとか、そっち方面の洗脳手法の話として紹介するべきだろう。

(23:50)

仕事していて始めて知ったんだけど、 Ogg のフォーマットの中に Speex ってのがあるんだね。これは低いサンプリング周波数、例えば人間の声のデータの圧縮に有効なフォーマットで、今回の仕事には結果的にピッタリだったわけだ。実際のところ半分ぐらいは俺の我侭でフリーなフォーマットを探していたわけだけど (もちろん会社にも利益があるので調査対象になったんだけど)、多分他のフォーマット使うよかいい結果になったんじゃないかなあ。まあ、実際には他のものと比較して検討しないといけないわけだけど、フリーなものを最初にゴーサインの出せる状態に持っていけたので一安心だ。

しかしもうすぐ入社して二年目が終わろうって時期になって、ようやく張り合いのある仕事にありつけた感じだ。先月までの仕事は本当に技術屋として得るものが無かったからな。やってることの難易度は今までに比べると倍率ドンでさらに上乗せってところだけど、それでもやりがいのカケラもないことをダラダラやってるよか遥にマシだ。

いやまあ、「技術的にレベルが低い=やりがいがない」ってのは単純化しすぎなんだけど、どうにもそういう仕事って、研修もそこそこのペーペーを拉致ってきてガチガチで身動き取れない環境でプレッシャーをかけつづけて作業させるとか、プログラマは SE の書いた「変数 a の値を 1 カウントアップする」とかのレベルで書かれたドキュメントに従ってコーディングするとか、まあ全部今までの職場の事なんだけどそういう印象があるからな。

(01:13)

今まで三回ほどロフトから降りるときに転げ落ちそうになって、既に一回は怪我してるのだけど、今回は今までで一番ヤバかった。どういう風にヤバかったというと、

というわけで、もうなんていうかいつ大怪我してもおかしくないなあ。

(11:36)

最近「ダンジョンエクスプローラー 邪神の領域」を遊んでるんだけど、これはなかなかの良ゲー。何がいいって、敵が殺る気満々なのがいい。装備とかスキルとかをちゃんと考えて使っていかないと、後半は雑魚相手でも取り囲まれてフルボッコというケースも出てくる。使っているのはタラッタ族の魔術師で流派は狂流。一番見てくれのビッとしてる奴を選んだ。

今のところ第四章まで進んでいて、これでストーリーモードは終わりかなあ。敵の攻撃もえげつないし、ボスも火力と固さが相応のものになってるし。

(12:17)

大雑把に分けると、バカというものは三つに分類できる。無知と低能と電波である。簡単に書くと、

無知

単に物事を知らないか、間違って覚えている

低能

知識はあるが思考の深さや広さに問題がある

電波

知識もあるし思考力もあるが、シナプスのつながり方が壊滅的に間違っている

という感じ。ちなみにここに「無根拠な自信」を付け加えると狂人が出来上がる。

(17:25)

就職して以来ずっと職場で Windows を使わされているのだが、なぜにこんなポンコツで開発せにゃあならんのか。とにかく Windows は開発環境としては紙屑以下で、なぜなら紙屑はメモ帳に使えるが Windows のメモ帳は完全に終わっているからだ。最低限、 Unix の標準的なコマンドやツールを移植した奴を「でべろっぱー・えでぃしょん」とでも称して売り出せよ。そうすりゃ会社側に購入するよう交渉してやる。まあ、それでも俺個人で買うことは未来永劫無いと断言してもいいが。

(18:27)

去年はさっぱりプログラミング言語の習得に時間を費やせなかったので、実に久しぶりに Haskell の勉強を再開。やはりこういうときには入門書があると便利なので、「ふつうの Haskell プログラミング」を購入。まだ第一部までしか終わってないけど、非常にわかりやすく書かれていて今のところはかなりの好印象。

もっとも本および著者への印象と反比例して Haskell に対する「何故じゃ」という感覚は残りっぱなしなんだけど。例えば俺は Python でプログラムを書くときに次のようなコードをよく書く。

__all__ = ['foo', 'Bar']
def foo(...):
  # 関数本体
  
class Bar(object):
  # クラス本体
 
    :
    :
  
def main(...):
  # メイン関数
  
if __name__ == '__main__':
  import sys
  sys.exit(main(sys.argv[1:]))

つまりそのままスクリプトとしてもモジュールを使えるようにしてるんだけど、これが Haskell だと出来ないようだ。というのも、 Haskell では main 関数は Main モジュールで定義するようになっていて、もしも main 関数を他の名前の付けられたモジュールで定義しようとするとエラーになる。多分こういう場合にはライブラリ部分と実行ファイルは別に作ったりとか、 Prelude でインポートしてテストするんだろうけど、どうにも俺の好みではないなあ。特に俺はテストコードを (ある程度の規模までなら) 本体のソースコードに含めてしまって、それで Makefile に

test:
  python foo.py
  python hoge.py
       :
       :
       :

という感じで追加して make test とかをやっている。まあ、全然違う言語なんだからスタイルまで込みで頭を切り替えるのはむしろ当たり前なんだろうけどさ。

(22:05)

相も変わらず VC++ での作業であり、そして俺はきっと未来永劫このソフトウェアを好きになることはないだろう。というかだな、何で ATL 系のコントロールを作ろうとするとあんなバカみたいな量のコードが自動生成されて、しかもそのバカなコードで実装してるインタフェース (もどき。 C++ にはインタフェースはないからな) の量がこれまたイカれてるんだ? 一体どの部分が何を抽象化してるのかさっぱりわからん。

実際のところ無駄にクラス階層を増やすことがいいことだと思っている知恵遅れというのは一定数いるもので、多分 Microsoft のコンポーネントを考えたチームにはそういうのが多かったんだろう。あるいは、あまりにも規模がデカすぎてワケワカメになって、つぎはぎ部分を隠蔽していったらああなったとか。

その割には Windows API は C++ の分際で全然オブジェクト指向の技法を使っていなくて (MFC とか ATL なら別だけど)、一体連中は何がしたいのかさっぱりわからない。それとも実はそこら辺は C で書かれてるのか? よくわからん。とにかく Windows はカーネル部分とそれ以外の境界線が曖昧で (これは意図的なものかもしれないが、そうする理由がわからない)、何が何やらわからねえんだよ。そういや Windows も NT カーネルは POSIX 準拠だという話を聞いたことがあるけど、にわかには信じがたいよな。

(23:27)

そして未だに院生の友人の修論の手伝いをしてるのだけど、お前これぐらい自力でどうにかしろよというのが正直なところ。乗りかかった船だから付き合ってやるけど、何ていうかヘルプを求めるんならもうちっと余裕もって出せと。こっちは社会人なんだぞと。ってか結構忙しいんだぞと。

そういや最近また新人が入ってきた。何でも前の業種は製造業で、そこの上司が制御系のプログラムを書いていて、自分でもやってみようとおもったけど会社にそういうポストがなくて、それで転職してきたんだそうだ。これでプログラミングの経験もあれば何も文句はないんだが。でもじっさいには wanna be の一種っぽいんだよな。まあでも、割とはっきりした目標というかイメージがあるっぽいからそれは本当に大きいとは思う。

問題は教育だよなあ。適切なアドバイスだけあればあとはある程度まではポーンといっちゃいそうなんだけど、じゃあ誰がアドバイスすんのよって話で、多分俺にはそういうのは求められてないだろうな。何故なら、恐らく俺と会社が完全に決裂してる部分が採用及び教育の方針だからだ。当然俺は引き下がるつもりはないんだけど、向こうも引き下がらないだろうし、結局俺が教育係になるのは有り得ないだろう。そしてこれは俺が完全に敗北を認めている所なんだが、俺は教育者にはまったくもって不向きだ。まずは 10 分に一回のペースで口をついて出てくる「地獄に落ちろ」「このインポ野郎」「死ね」をどうにかせにゃあならん (でも Windows も Microsoft もいい加減くたばってほしいよな? いや、もうとっくにくたばっていて、惰性で転がってるだけか)。それと脱線癖をどうにかしないとな。流石に新人の前であんまりディープな方向に脱線してビビらせるのはよくない。

(22:51)

やっぱり今の職場 (=本社) の方が明らかに仕事がはかどるな。理由は単純で、本社は非常に静かなのである。ってか前の現場がクソ過ぎたんだろうけど、この落差はどうよ。何より電話は事務のお姉さんがとってくれるし (まあ、そもそも俺はむしろ電話に出るなって感じなんだが)、限られたメンバーしか居ないから自分の仕事と無関係な話し合いとか怒鳴り声はないし、破滅の源のメッセンジャーも俺は独立愚連隊なので全然使ってない (今後はわからない)。

それでもまだまだ改善するべき所は山ほどあるけど、まあ表沙汰にならないようなレベルでやらせてもらうか。そもそも俺は音頭をとってドカンとトップダウンでやるのは性に合わないんでね。

ところですげーどーでもいいけど、「インタフェースはインターフェースの間違いでは?」とか言われたんだが、本来はこっちの方が正しい書き方なんだよ。まあ、外来語をカタカナで書いてる時点で正しいもクソもあるかって感じなんだけどな。なので俺はあんまりどっちで書いてるかそこまで気にしてなくて、たまたま長音記号をノリで書いちゃった場合はそのままにしてることもある。ていうか、意味がわかんなくなるような誤字とかならともかく、こういうどーでもいいことに目を光らせる奴は特にソフトウェア開発では足手まといにしかならないのでなるたけ関わり合いになりたくない。前の現場でも本当にどうでもいいような体裁のチェックでみんな死ぬほど疲弊してたしな。あんなのは二度とゴメンだ。

(21:49)

研修中の新人から「どうやったらプログラミングを効率よく覚えることが出来るか」と聞かれたので、「様々なソフトウェアを書き、様々な言語を試すこと」と答えておいた。が、そこで他のプログラミング言語について「じゃあ C# とかもやった方がいいんですか?」「メジャーなところで C++ ですかねえ」とか返って来たんだけど、まあそんなもんか。とりあえず「どうせやるんなら全然毛色の違う言語の方がいい」とは言っといたけど。

でも真面目な話、特に書きたいソフトウェアがあるわけでもないのにプログラミング言語を覚えるってのは特に初学者にとっては非常に厳しいことだ。そもそも目的のはっきりしないまま歩みを進めるというのは万人にとって難しいといってもいい (ソフトウェア開発自体、何が目的なのかはっきりしにくいんだが)。特に課題を与えられてそれを解くだけでで実際にはあまり身につかないと思う。というかそういう「与えられた課題を解く」ってのは言ってみればパズルみたいなもんで、実際にはある程度プログラムが書ける人が道楽でやるもんだろうと思う。

(22:12)

ていうか今日って木曜日だったのか。てっきり水曜日だとばかり思ってた。月曜が休みだとこういう錯覚をしがちだなあ。

(00:25)

別に毎号書くことにしてるわけじゃないけど、今月の Young Guitar の感想。相変わらず Gus G 超絶技巧と裏腹に全然垢抜けないなあとか、「ギターの形状って女のボディラインに似てなくね?」「Leo Fender の削りはエロい」とかバカ話をおっぱじめる Winger の二人は本当に楽しそうだなあとか思いつつも、あくまでもおまけ程度の扱いの Rodrigo Y Gabriela のライブ映像と Rodrigo の方のエクササイズがいろんな意味で別次元で参った。

この人たち、元スラッシュメタルで今はラテン・スパニッシュ系アコースティックデュオというまったくもって意味不明な経歴の持ち主で、さらにその演奏もメタル耳で聴いてもイッチャってる。こりゃあ CD を入手せねば。

(02:02)

とりあえず今回の新人二人は流石に元異業種とはいえ社会人で、そこら辺の心配はしなくて良さそう。というかまあ、そういう方面の心配を一番されてるのは俺だけどな。

それはともかく、前に書いた製造業からやってきた方の奴は

• 他人のソースを読もうという姿勢がある
• ちゃんと自腹で本を買って読んでる
• 自分で設計する気満々
• 一人前の職人になるには 10 年を要することがわかってる (ここらは製品開発部門にいた経験が大きいのかも)

という大変なレアキャラで、ぶっちゃけこれだけで高く評価していいぐらいだ。なんでかっていうとだな、みんな本は読まない、せっかく目の前にフレームワークのソースがあるのに手付けず、そしてプログラミングとは設計であるということを認識してない、カスみたいなコードを書いて一人前気取りという有様だからだ。っていうか、あんたらの尻拭いしてる俺だってマスタークラスからは程遠いんだがなあ。

今の会社で俺のポジションは言ってしまえば黒魔術師で、これはつまり「Kuwata に頼めば作ってくれるよきっと」みたいな雰囲気が社内にあって、俺はこれが気にくわない (まあ、他に人がいないから作るけどさ。他に誰も C++ なんてわかんねーし)。まず俺ごときがエースという時点で完全に狂っているのだが、何より一部の人間に便りっきりというのは不健全過ぎる。これはプロジェクト管理の方でも一緒で、今の上司がぶっ倒れたら一巻の終わりだからな。

(22:36)

アパートの契約更新の期限が来月の 12 日だということに今日配達された書類で気がついた。えーとだな、次の部屋探しはぶっちゃけあんまし進んでない。仕事と友人の手伝いで忙しかったからな、今まで。先月も暇になったのはラスト数日程度だったし、こりゃあ諦めてもうしばらくここに住むしかないかなあ。

多分急げば今月中にでも引っ越せるとは思うけど、急いで決めた部屋が今のこれだからな。流石に同じヘマをやるわけにはいかんよ。それに間違いなくネットの開通は間に合わないだろうし、そもそも引越し前に処分したい物がいろいろあるし。

というわけで引越しは多分相当先にずれ込みそう。次に降ってくる仕事が落ち着いたらだな、行動に移すのは。

(11:51)

DS 版「ダンジョンエクスプローラー」をストーリーモードとピラミッドと両方クリアした。ストーリーモードでは詰みはしなかったけど、ピラミッドの方は途中で詰みかけたよ。いやー、結構歯ごたえのあるゲームだった。

その詰みそうになった部分は第四階層で出てくるワンダーパーソンというボスで、こっちはこいつの攻撃二発で死ぬ上にその攻撃パターンに

• ターゲッティング不能に近い距離からの毒霧
• ベアハッグ。チャージ攻撃で剥がせるが、チャージ完了するまでにアイテムを消耗しすぎる

という鬼畜技が入っているもんだから思わず投げそうになった。飛び道具系のフォームで射程外から削ろうともしたが、火力が低すぎて断念。じゃあどうやって倒したのかというと、今まで全然役に立ってなかったお供のロボの防御力を思いっきり上げて (500 ぐらいあれば安心)、ロボの方にベアハッグをさせるとほぼ完全なハメになることが判明。あとはチャージ攻撃にならないように通常攻撃を当てればよい。偶発的にこっちに攻撃が飛ぶこともあるが、単発で時々くるだけなのでリカバリは可能。

ワンダーパーソンの鬼畜っぷりとは裏腹に弱かったのが第四階層のラストに出てくるデュラハンという奴で、こいつは弱点属性のアーツを打ってるだけで死にくさった。お前、ボスなんだからもうちょい頑張れ。

第五階層は初見でクリアできたというか、この階層では

• ワンダーパーソン×3
• デュラハン×3
• フェバーン
• メタブリード
• ブリード

というボスラッシュがあるわけだが、

• ワンダーパーソンは三体全部ベアハッグでハメれば負ける要素は無い
• デュラハンは雑魚を最初に一掃してから落ち着いて戦えば負ける要素は無い
• フェバーンはここまでくる腕があれば負ける要素は無い
• メタブリードは攻撃すると偽者を召喚する最低最悪の面倒くささを誇るが、まあいつかは勝てる
• ブリードは仕掛けがわかれば後は難しくない (ヒント: ステージ中央のブロック)

とまあ、ワンダーパーソン初見のときよか大分楽だった。もっともタラッタ族魔術師でヒールを使えたのが大きかったとは思うけどな。このヒールというアーツは最高レベルまで上げて打つとかなりの長時間回復フィールドを張ることが出来るので、そのフィールドの付近をうろつきながら戦うという戦略が可能になる。

とりあえずゲームの総評としては、ある程度の歯ごたえを求めている人にはオススメ。一件無茶な攻撃をしてくるボスでも大抵は攻略方法を見つけ出せるので (力押しもあるが)、なかなか攻略のしがいがある。残念ながらマルチプレイはまだやってないというか、周囲に DS を持ってる人が……。

さて、「世界樹の迷宮2」まであと数日だ。

(17:19)

ここ最近買った CD の感想でも。

• Ari Koivunen - Fuel For The Fire
  • 「友達にそそのかされてアイドルのオーディション番組に出たらあれよあれよという間に勝ち上がり、ついにはデビュー」というどこの少女漫画なんだそりゃというメタルシンガーのデビューアルバム。これがポップソングを歌う女の子じゃなくて男性メタルシンガーというのがフィンランドの凄いところ。何でも審査員からは「何だこのメタルバカ」と思われていたらしいが、本人は「知るかよ、俺はメタルが好きなんだ」って感じで突っ走り、それが視聴者には受けたようだ。
  • 音楽性は大変真っ当な北欧メタル/ハードロックで、そりゃあ楽曲提供者に Tonny Kakko とか Timo Tolki とかそうそうたる顔ぶれがそろってるもんな。まあ、特に好きな "Don't Try To Break Me" と "Hear My Call" は全然知らない人の作曲なんだが。あとこの人は現在 23 才らしいけど、みてくれも声も 23 の男とは思えんな。特に声は時々「君、ちゃんと声変わりしてるよね?」と言いたくなるようなショタ声になる。
• Biomechanical - Cannibalised
  • 英国を中心に活動する超絶エクストリームバンド。 Rob Halford 系金切りハイトーン + Slayer 風スラッシュサウンド + 映画音楽風オーケストレーションといったあんばい。ていうか中心人物であるヴォーカルの John K は映画音楽の仕事もしてるそうで。
  • すさまじく格好いいが、一回聴いただけでは曲構成がさっぱりわからないほど複雑で壮大。
• Norther - N
  • 前作が微妙な出来だったので心配していたけど、今回はアタリ。相変わらず Kristian Ranta のクリーンヴォーカルがいい仕事をしてる。 Petri Lindroos のデスヴォイスが高音絶叫系なので、中〜低音でアダルティックに歌う Kristian といい対比が出来ている。
• Rodrigo y Gabriela - Rodrigo y Gabriela
  • スラッシュメタル出身のアコースティックデュオなんだが、これは素晴らしい。アコギだけでここまでのものが出来るのか。本来は指弾きのスパニッシュギターを鍛え抜かれたフラットピッキングでとんでもない勢いで弾き倒す Rodrigo に、超絶技巧と特殊奏法を駆使してどう聴いてもパーカッションにしか聴こえないバッキングを叩き出す Gabriela と二人とも神業を連発。
  • もちろん曲もいいんだけど、特に "Stairway To Heaven" と "Orion" のアコースティックアレンジには意表を付かれた。前者は元からアコースティックパートがあるからまだしも、後者はここまでアコースティックな世界で表現出来るとは。アコギしか使って無いのにどう聴いてもヘヴィメタルにしか聴こえない。そこらのメタルバンドなんかよりもはるかに過激でテンションが高いよ。
  • というわけでメタラーにも全力でオススメしたい一枚。ドラマティックなメロディとスリリング極まりないリードとバッキングの絡みはメタル的にも 100 点満点。いや、本当に参りました。俺が買った奴にはおまけの DVD が付いてきて、それにはライブ動画と教則ビデオを収録。ライブ動画は必見といってよく、何せアコースティックライブなのにオーディエンスが拳を振り上げて頭振って叫んでる。演奏はタイト極まりなく、 Rodrigo のピッキングの精度と Gabriela のミュート・パーカッション奏法が大変な事になってる。

Rodrigo y Gabriela は久々の大ヒットだなあ。何しろメタルファン以外にも自信を持って薦められるんだからな。というか、これ聴いた後に手持ちのスケールブックからスパニッシュ系の奴を引っ張り出して練習始めるぐらい気に入った。

(21:54)

仕事で使うことになった事もあって、本当に久しぶりに C++ の勉強をしてる。まあ、仕事で使うと言ってもアプリのうち本当に限られた部分で、俺の腕でもどうにかなる所だけなんだけど、それでも今後に備えて腕を上げとくに越したことはないからな。

そして大学時代には何を言ってるのかさっぱりわからんかった部分も流石に今なら理解できたりするんだが、しかしそれも結局のところは範馬勇次郎相手に「今ならおぬしの技が見えるぞ」といった本部以蔵のようなもので、とてもじゃないが歯が立たないのも事実なんだが。俺程度の腕ではこいつとの戦いはライフワークにならざるを得ないだろうな。

(23:23)

俺は Python を「母国語」だと言ってはいるものの、実際には何度か書いているように静的な強い型付けの方が好きだ。が、その理由は書いた覚えがないのでとりあえずその一つを書く。

まずはプログラミングにおける型エラーについてだが、俺はこれにも実装エラーと仕様エラーの二つがあると考える。実装エラーの型エラーというのは、要するに適切にキャストしてないとか、適切な抽象クラスとして変数の型を宣言してないとか、うっかり別のメンバを参照してたとか、引数の順番を間違えて書いてたとか、そういう類のものだ。これは実行時に見つかってもコンパイル時に見つかっても修正コストはたいして変わらないと思う (が、コンパイル時に見つかった方が一気に修正出来るのでこっちの方が好み)。

問題は仕様エラーの方で、これはそもそもそのデザインに問題があるというケースだ。例えば Python の socket オブジェクトはデータの読み書きに recv/send を使うのだけど、 ssl を噛ませるとなぜか read/write になる (まあ、標準モジュールの ssl なんざ誰も使わんだろうが、あくまでも例な)。ここについて何かしら勘違いして

• socket と同じインタフェースが要求されるところに ssl オブジェクトを投げる
• ファイルなどの read/write を使うオブジェクトが要求されるところに socket オブジェクトを投げる

というケースを書いてしまい、それが条件次第で起こるかどうかわからないケースの場合 (オプションで ssl モードにするとかな)、テスト漏れした場合に酷い目にあう。そしてテストというのは漏れるものなので、やっぱり酷い目にあう。そしてこれは単純なケースだけど、もっと複雑なケースじゃどうなることかわかったもんじゃない。もちろんその場合でも動的言語に特有の書き直し易さでで対応できるっちゃそうかもしれないけど、出来ればこういうどう考えても明らかにおかしな部分は実行するまでもなく検出して欲しい。

そしてそれでも俺が動的言語を支持する理由はあって、それは

• C 言語はシステムプログラミング言語。今の時代にアプリケーションプログラミングに使いたくない
• C++? これを本気で使うのは「真の実力者」「どうしても仕事で必要になった被害者」「死んだ方がいいバカ」のどれかだ
• Haskell はあまりにも変態的過ぎる
• Java は仕事言語としてみたら悪くはないものの、ライブラリ、実行環境ともにその使いにくさに’は凄まじい物がある
• Ada は実は少し勉強したことがあるが、二度と触りたくないなアレは。文法が面倒臭すぎる
• Pascal は俺が師匠の元を離れる切っ掛けの一つになった
• C# は詰め込み過ぎで何をしたいのかさっぱりわからない

とまあ俺が使ったり多少勉強したことのある言語はどれもこれも気にくわなくて、これが静的型付けの宿命なのかどうかは知らない。俺が欲しいのは「Python + 型推論」な言語なのだけど、そういうニーズがあるのかどうかはわからない。ただ、 Guido van Rossum は型推論に対して興味を持ってはいるようではある。あと契約プログラミングにも興味をもってるはずだったな。

(21:54)

諸事情により今日から SOAP を使っての Web サービスについて調査 & 実装を始めることになったのだが、まあこれについては「S はシンプルの S」を読めば一体何なのかわかるよ、多分。

追記: ちなみに俺はリモートオブジェクト自体にかなり懐疑的。リモートオブジェクトを使うと本来分断されているべき領域が密結合になってしまう (Java の RMI とか酷いもんだろ)。俺はリモートオブジェクトが必要になるケースには、根本的なデザイン上の誤りがあるんじゃないかと常に疑っている。まあ、主に政治的な力関係とかしがらみとかでそういう技術を使わざるを得ないんだけどね。

(07:31)

昨日は日記を書けなかったわけだが、それは仕事が終わった後に会社の人たちに飲みに誘われて、そこで話し込んでしまって帰って来たのが 23:00 とかだったから。

まあそんなことはどうでもいいとして、ちょっと契約プログラミングの話。例えば Javadoc とかに次のような記述があるとする。

/**
 * 何かするメソッド。
 *
 * @param s null でない文字列
 */
public hoge(String s) {
  if (s.equals(...)) {
    :
    :
  }
}

もしもこのメソッドに null を渡してエラーになったら、それはまあ基本的に渡した奴が悪いんだけど、俺はこういうのは「null を入れてはいけない」というルール・契約としてコードで表現したいのだ。多分 AspectJ とかのツールを使えばいいんだろうけど、俺はそういうバイトコード操作をするのは嫌いだ。あと契約を AspectJ のアスペクトで表現すると、実際のコードには反映されないってのが気に入らない。

というわけでいつも通り Python でならどうやるかという方向になるわけだが、これは関数デコレータを使うのがいいだろう。簡単に書くと次のような感じ。

def not_none_contract(f):
  def _not_none(*args):
    if None in args:
      raise ContractError('None を入れるな')
    r = f(*args)
    # 事後条件のチェックをしたい場合はここで
    return r
  return _not_none
 
@not_none_contract
def foo(a, b):
  :
  :
 
@not_none_contract
def bar(a, b):
  :
  :

関数ならこれでいけるんだけど、じゃあスーパークラスのメソッドの契約をサブクラスでオーバーライドした場合もデフォルトで引き継がせるとなるとどうなるのかなあ。何となくそれは無理なんじゃないかという気がする。いや、 __getattribute__ に書いちゃうって手もあるけど、それはとても嫌だ。もっとも、オーバーライドしたメソッドが自動的に契約を引き継ぐのは契約の存在が明瞭じゃないので気持ち悪いといえばそうだ。

そして同じ事を Java でやろうとすると、えーとアノテーション使うのかな? あんまり使ったことないんでわからん。

(00:22)

相変わらず SOAP と格闘してたのだが、とりあえず受け渡しに使うオブジェクトがシリアライズ/デシリアライズ可能なのでどうにかなった感じ。最悪、自分で WSDL 書かないといけなかったかもしれないからな。それが回避できそうだってだけもでめっけもんだ。

ちなみにフレームワークの改造も始まってるのだが、 Struts が元ネタとかそういうのをさておいてもかったるい。なぜかって言うと、ドキュメントが全然整備されてないのだ。導入資料の類はない、 Javadoc に至ってはろくすっぽ書かれていなかったり記述が古かったりするし、ゴミファイルも残ってる。インクリメンタルな開発ってのはそういうところをいい加減にする手法じゃねえんだが、まあいい、多分俺にはそこら辺をまとめ上げる能力も求められているんだろ。

しかしあまりに理解しがたいというか情報が足りないので、俺の独断と偏見により勝手にイントラネット内部で Wiki をおっ立ててそこでドキュメントをまとめることにした。どうせ機能は最低限でいいので、昼休みを潰して (俺が管理権限を持ってる) サーバにゲリラ的に構築。他の Wiki クローンは機能的にオーバー過ぎたり文法が気にくわなかったり、そもそもサーバに入ってる環境じゃ動かせなかったりしたんで結局自分で書いちまった。まあ、俺は機能的には不足を感じてないのでいいや。これが一定の効果を上げたら次の展開が考えられるんだが、まずはどの連中を巻き込むかなあ。とりあえず現状のフレームワークに悪戦苦闘してる新人には見せておいた。

しかし組織が小さいといろいろ楽だ。特に俺は独立愚連隊として扱われているので相当無茶が効く。まあ、その半面チームメイトゼロの慢性的なトラックナンバー 1 で仕事をすることが決定していて、いざというときにリカバリが効かないってのがあるんだが。

(19:49)

「世界樹の迷宮2」買ってきた。更新が途絶えたらそういうことだと思ってくれて結構。

っていうか、何で木曜日に発売するかなあ。明日の仕事に差し支えるじゃないか!

(20:36)

極めてどーでもいいことだけど、 10日の日記に妙なコメントが付いてた。

その定義だと“すべての人間が馬鹿”にならないか ? 誰だって何かに対しては無知だし間違って覚えたりするだろう .

え、違うの? 人間ってみんな何かしらのことについてはバカなんじゃないの? 人類が全員ある意味でバカだったとして、それで問題があるの? あるからこういうコメントを付けたんだろうけど、何が問題なの?

まあ、実際のところこういう反応の人ってのはいるにはいて、俺はそういう連中が大嫌いなんだけど、それは何故かというと今までの経験上、そういう連中は大体自分がバカのカテゴリに入ることに抵抗するからこういう反応を示すわけだ。この人がそうなのかは知らないし知る術はないんだけど、俺はそういう風に考えている。

何でこういうことを書いたかというと、これは俺の実践している学習方法に関わる話だからだ。俺は大学の頃から「定期的にレベルをリセットする」という修行をしていて、それはつまり

• 静的型付けの言語でしかプログラミングしたことがないので動的言語にチャレンジしてみる
• 手続き型の言語しか知らなかったので関数型言語に手を出してみる
• それなりにメジャーな言語しか使ってなかったので情報量がほぼゼロのマイナー言語を使ってみる
• フレームワークを使う立場だったので逆に自分で書いてみる
• 三流私大の情報数学で知識が止まっているので圏論のようなレベルの違いが倍率ドンな方面を調べてみる
• C++ が STL で止まっているので Boost を使ってみる
• Python 2.4 以降に慣れすぎてしまったので 2.1 程度の機能の Jython でプログラムを書いてみる (ていうか仕事の関係上そうなった)
• Linux の世界に浸かりすぎてしまったので Windows で ActiveX を書いてみる (これも仕事だったけどな)

というようなもので、これは前述の「どこまでいっても人間は何かしらの意味でバカ」という前提の元にやってることだ。何で修行なんざするかというと自分はまだまだだと思っているからで、それまでとは別分野に首を突っ込むのは自分のバカさ加減を知るためにはうってつけだし、挫折を味わってみるのはいいことだ。そしてまた元の場所に戻ってきたとき、実は自分はそこのことすら何一つ本質的な事はわかっていなかったということに気がつく。

実際俺は大学三年の冬頃に C++ を封印して、それからいろいろあって Python に鞍替えして、それで一年ぶりに諸事情により C++ を書いたら信じられないぐらい C++ の腕が上がっていたという経験がある。そもそも同じ事を繰り返したって成長曲線には限界があるわけで、「ピープルウェア」で出てきた「10 年選手と 2 〜 3 年程度の経験のプログラマにレベル差があまりない」という調査結果は実は当たり前だと言える。

そして悲しいことにソフトウェアの世界には自分のバカさ加減を知ろうとしないキチガイが山のようにいる。これは別の現場の業務系の人から聞いたことだけど、業務用 Web アプリの世界じゃオブジェクト指向をわかってる人はまれで、それどころか共通処理をまとめて別メソッドにしようという考えすらなくて、そういった本来なら当たり前のことをやろうとすると「そんなことしたら設計書が書き直しになるじゃないか」「そんなことして何が嬉しいんだ」という反応が返ってくるそうだ。

そして俺はそういう悪い意味でのキチガイには決してなるまいと思っているので、今日もまた自分のレベルをリセットする。

(01:40)

• 世界樹の迷宮2 ロールプレイ & 攻略記録

というわけで世界樹の迷宮の話は基本的にリプレイ & 攻略記録の方で。更新用のスクリプト書いてギルドとメンバーの名前を考えて、三文芝居のネタを考えてたらこんな時間だ。結局今日は樹海に辿り着けなかったが、仕事に差し支えるのでもう寝る。

(20:27)

俺は Wiki 記法の標準化は殆ど無理だと考えているが、それでも自分の日記と会社の Wiki で記法が違うと混乱する。っていうか、世界樹リプレイへのリンクが間違ってたし。

この日記とかで採用してる記法は俺が完全に自分の好みで作った記法だけど、会社の Wiki の奴は既存の文法を参考に多分一般的なんじゃないかなあって記法になるようにデザインしたんで、かなり形式が異なる。こんだけ違ってればよもや混乱するまいと思っていたけど、やはりダメだったようだ。プログラミング言語なら話は別なんだけどなあ。

あーでもプログラミング言語の場合、そもそも文法以前にプログラミングスタイルというかデザインする時の精神性に大きな違いがあるので、きっとそこが影響して文法を取り違える事がないんだろう。だってさあ、別に C と Python を平行して使ってても、 C で elif とか滅多にやらないだろう? それとプログラミング言語の場合文法エラーが即座に処理系に怒られるから気がつくけど、 Wiki 記法とかの場合は文法エラーじゃなくて単なる文字列として処理されてしまうんだよな。

なのでこういった記法はやっぱり複数使うのは良くないことなので、標準化しようっていう人たちの気持ちはわからなくもない。でもさあ、やっぱりこれは無理だって。だって Wiki 記法のパーザって書くのにそんなに手間かからないし、自分でいくらでも作れるんだよ。だから確実にオレオレ記法が存在するわけで、真に必要な事はそういった文法を変換した結果 (XHTML あたりだな) を標準フォーマットに直すというライブラリとかだろう。そしてここでの問題はその標準フォーマットはバカみたいに強力な表現力を持っていないといけない事で、なぜならそのフォーマットは未来に出てくるものを含めてあらゆる Wiki 記法のスーパーセットでないといけないから。そしておそらくそのフォーマットはクソだ。

ちなみに俺はその標準フォーマットとして開発された Creole という記法は大嫌い。何が嫌いかというと、まずリストの書式が嫌い。 Creole だとリストは次のようになる。

 * 順序なしリスト
 ** ネストしたリスト
 * ネストレベルが戻る
 この部分はパラグラフになる。

それに対して俺が考えた記法は reST (Python の世界のデファクト見たいな記法) にどっちかというと近い。

 - リスト
  - ネストしたリスト
 この部分は一行上のアイテムと同じ要素
 - ネストレベルが戻る
   インデントしても同じ
 
 空行をはさむとパラグラフ。

見出しの記法もバカらしくて、俺はこいつに付き合うつもりは全くない。結局これはどう考えても帯に短し襷に長しなものしか出来ないんだから、みんなオレオレ記法のコンバータとか書けよって話にならざるを得ない。

(19:24)

世界樹のアレを更新。相変わらず進みが遅いが、こうやってゲームやりつつネタを作ってると結構大変なんだよ。

(16:05)

世界樹2ロールプレイを更新。本当はこっちも RSS 対応にした方がいいかなとか思ったけど、ネタバレ系のコンテンツに RSS があったってまず使われないか。ちなみに俺は攻略サイトとか他のファンサイトの情報を完全に遮断してプレイしてるので、ものすごい勘違いとかをやらかしてるかも。

あと流石に平日はそんなに更新できなさそうというか、仕事がそれなりに忙しいので無理。進められるのは休日のみかもしれない。通勤途中にプレイするにはちとボリュームが多いというか、本社勤務になって通勤時間が短くなって、それで電車内でゲームをするのが難しくなっちまった。なので、基本的に世界樹のページは休日にしか更新しなさそうだ。

(20:13)

Web アプリケーション用フレームワークの要件は、簡単に抜き出してみると以下のようになる。

• HTTP リクエスト/レスポンスの抽象化機構 (必須)
• 入出力データのチェック (必須)
• 開発者の書く処理へのディスパッチ (必須)
• 画面遷移 (必須)
• データソースなどのコネクションまわり (オプション)
• O/R マッパーなどの永続化機構 (オプション)
• JSP タグライブラリや PDF 出力などのプレゼンテーション (オプション)

こうして見てみると、別に俺はどの要素も嫌いではない。 O/R マッパーあたりは単純に信用してないけど、でも「O/R マッパー死ね」なんてことは全然思ってない。プレゼンテーション部分も別に自前で HTML テンプレートぐらい書けるけど、でもあまりこだわりのある部分ではないんで提供されるならそれでいい。

実は俺は嘘を書いた。というか、情報を隠した。実際にはフレームワークの要件には以下の二つが追加となる。

• 制御の反転 (必須)
• そびえ立つ設定ファイルの山 (オプション)

そして実際にはこの二つは強く関係しているケースがあって、例えば今弄らされているフレームワークではある特殊なテーブルで ID とバックエンドロジックの対応が定義されていて、フロントからバックを呼び出すための機構はそれを使うものと単体テストなどで使うためのモックしかない。そして両者の切り替えなどは設定ファイルで制御している。

そしてただでさえ制御の流れを規定されて嫌なところで、設定ファイルの山がその制御の節目節目で顔を出してくるのは実にムカつく。まあ設定ファイル地獄はある程度どうにかできるんだろうとは思うのだが、それでもやはりアプリケーションの流れを決める権限はプログラマにはなくて、それゆえ俺はフレームワークを使うのが嫌いだ (自分で作って使う分には全然いい)。

(23:28)

ちょっとアクセスログを見たら世界樹の迷宮のページにやたらアクセスがあったんだけど、ネタバレしてるのに見にくるって事はみんなもうとっくに先に進んでるってことか。実際には俺ももっと先へ進めてはいるんだけど、文章書くのに手間取っているというか、実際にプレイしながらキャラの性格付けとか脳内ストーリーを作っていくのはやっぱ大変。特に脳内ストーリーはゲームの方の進行次第でいくらでも書き換わるからな。後で思いっきり加筆修正が入るかも。

(21:47)

俺が野良社内 Wiki & BTS を動かしているマシンが SELinux 有効で構築されているのだけど、どうやらセットアップした人は RedHat が SELinux をデフォルトで有効にしていることに気がつかなかったらしい。まあ、 CVS しか動かしてなかったんだから仕方ないよな。かく言う俺もおかしな権限エラーが出るから気がついただけなんだけど。

そしてやっぱり SELinux はディストリビューションのサポートが無いと使うのが大変で、俺はあれの設定をスクラッチからやるつもりは無いぞ。やるなら多分、設定支援ツールでざっくりとアウトラインを決めて、細かいところは手動ってことになるだろうな。そしてそれでもやっぱり出来ればやりたくない。

(19:49)

ちょっとお金が入ったからって気が大きくなって、バブリーなことを夢見たり、当初の予定を土壇場でブッチして方針変えたり、そんなことやって従業員から見放されたら終わりだろうなんて経営の事がさっぱりな俺にも予想がつくわけで、そしてきちんとそれまで経営できていたはずの人がそういう紐付けないでバンジーしてる様を立て続けに見ると虚しくなるね。

諸事情により残業禁止令が出たので、これからしばらくは早い時間に帰宅することになりそう。しかし俺がいわゆる「ジョーカー」として投入されると俺の遥か頭上で場が荒れ出すのだが、あれか、そういうのが予想されるところに俺は投入されるのか。

(21:54)

世界樹2 のページを更新。今回は一度に二回分。そして第一階層突破まで書いた時点で、街の人たちを誰一人として出していないことに気がつく。何やってんだ俺。というわけで次回の更新でそこら辺をカバー……するかも。電波を受信するままにキーボードを叩いているせいか、既に当初の思惑からは相当外れているというか、ゲームをプレイしながら書いてるとはいえギルドの行く末はまったくわからん。

しかし DS の画面をデジカメで撮ってリサイズしてトリミングしてとやっていると面倒くさい。 DS の機能で「画面のスクリーンショットを撮る」みたいな機能があったら最高なんだが、そんなの使う奴は少数派かな。でもニコニコ動画とか YouTube でゲームプレイ動画をアップするのが結構出て来てるしなあ。もしもそういったスクリーンショットや動画の記録機能のついた DS が出たら買い換えてしまうかもしれない。

(19:58)

未だに時々サンボマスタージェネレータが PIL のサンプルとして紹介されるのだけど、作者としてはもっとマシなサンプルはないのかと言いたい。もの凄く言いたい。というかあの程度の処理は PIL のドキュメント読みながらやれば書けるだろ、普通。

(20:28)

Java を例にとると、以下のような文字列比較は好ましくない、もしくはバグだとされる。

void foo(String s) {
  if (s.equals("abc")) {
    :
    :
  }
}

これは s の値が null だった時に例外で落ちるからで、こういった場合 "abc".equals(s) と書くのがよいとされる。が、そんなもの俺に言わせればクソ喰らえだ。

理由の一つは明らかに自然言語の文としてみて不自然な印象を受けるというのがあるが、一番大きな理由は引数が null か否か、正しくは引数として null を認めるか否かという問題から逃げているということだ。これは明らかに悪い意味での Defensive Programming に思える。 null と文字列はまったく別のものなんだから、それに対して目を瞑るのは常に認められるわけでは無いだろう。もしかしたら、渡されてきた null は呼び出し元のバグのせいかもしれないだろう (何せ null だからな)。もっともそうして null を別扱いにすると「条件にマッチしなかった時と null とでエラー処理コードが重複する」という問題が起こらなくもない。なので結局はケースバイケースなのだろうが、それでも俺は上記のコードからは嫌な匂いを感じる。

もっとも俺が一番気にくわないのは文字列の比較が常に == で行えないことで、こういう時に「何で文字列がインターンされてないんだ」「何で演算子がオーバーロードできないんだ」という不満が出てくる。

(20:07)

「書き方が悪かった == そもそもわかってなかった」