Diary?::2008-01

2008-01-01
Tue

(03:10)

何かいろいろ論文読んだり実装してみたりしているうちに年が明けてた。くそぅ、バイナリ差分なんて考えるんじゃなかった。

まずはとりあえず大バカな実装だとどのぐらいの惨劇になるのか、 2M バイトぐらいの一文字だけ違うデータの OpenOffice ファイルの比較を次のようにやってみた。

  1. 二つのファイルを一定サイズずつ読み出す
  2. 読み出したブロックのリリスト同士の Longest Common Prefix を取る (os.path.commonprefix で一発)

それでどうなったかっていうと、 bsdiff で 355 バイト程度の差分になるデータに対して 90K バイトオーバーとなりました。しかもこれ、生のバイト列でのデータなので実際にはずっと大きなデータになるわけで、使いものになるか、こんなもの。第一、実際にはもっとデータの差異は大きいわけだからお話にならんよな。ってか bsdiff は何やってんだよ。

ちょっと調べてみた限り、 bsdiff は suffix array の応用で差分を作ってるようだ。それで今は IBM Hash Suffix Array Delta Compression を読んでるんだけど、これはちょっと目的に合わないかなあ。差分ファイルのデータフォーマットまで込みってのがネックだ。基本的な考え方は応用できるかもしれないけど。

(17:04)

ロッテリアで絶品チーズバーガーを食べてきた。

感想: やはりモスバーガーの壁は厚かった。

2008-01-03
Thu

(12:46)

うーむ、正月休みだからといってだらだら過ごしていたら、昨日はとうとう日記を書くことさえすっぽかしちまった。

とりあえず部屋の掃除とかをやんないといけないのだが、どうにも気力がわいてこない。流石に今の状態はかなりまずいとは思うのだが。

(22:28)

「賭博堕天録カイジ (タイトルこれであってたっけ? もう覚える気力もねえや)」の 12 巻を読んで呆れた。いや、その、なんというか、なんでこんな小物との勝負をここまで引っ張るわけ? これさあ、例えて言うなら「ドラゴンボール」でサイバイマン戦が 10 巻続いてるようなものじゃん。福本先生はこのシリーズを終わらせる気があるのか最近は本格的に不安だ。

もっとも「カイジ」シリーズに関しては、利根川先生が焼き土下座をした所で終わってるってのが正直な感想だけどな。

2008-01-04
Fri

(03:11)

「どうせ正月休みはみんな実家とか帰ったりしていて誰も連絡よこさないだろう」とか思って携帯電話を充電せずに放置していたら、そういうときに限ってお呼びがかかっていて相変わらず自分の数え役満っぷりに乾杯。

えーと、ここ読んでる知人連中に私信。前々から言ってる通り、携帯電話は割と無視できない確率で電池切れ or 家に忘れてしまうので、当日即の呼び出しは博打だと思ってください。特に連休の真っ最中は超危険。あとプログラミングとかでえらいこと集中してるときは電話が鳴ろうが来訪者があろうがガン無視の危険性があるので、そういうときは諦めてください。いや、これについては取り立て先を間違えた借金取りがやってきてヤバくなりかけたので、なんとかしようとは思ってるんだが (はっと気がついたら高橋名人レベルの速さで呼び鈴が鳴らされてんの。どうも前にも来たらしく、そんときも俺がガン無視してたっぽい)。

(21:35)

新年早々またやらかしてしまった。

音量は多分普通の音量になってると思う (normalize にかけた)。音量控えめでマスタリングして normalize にかけるのが一番なのかなあ。いや、マジでマスタリングのきちんとしたやり方がわからん。

またしてもどこから謝っていいのかさっぱりワカラン出来になってしまったのだが、とりあえず言えることはオリジナルにツーバスで疾走なんてパートねぇよ。

まあ俺の演奏力ではこれが限界でしたというわけで、一人反省会開始。

相変わらずリズムが破綻気味でダメ子ちゃんなのだけど、前よかマシになった気がしないでもない。というかベースラインはこれであってるのか自信がない。俺は耳コピが超苦手で (というかギターについては他の人の採譜したタブ譜をよく見る)、特に埋もれやすいベースは何となくあってそうな音を弾いてるだけ。本職のベーシストが聴いたら噴飯物だろう。いや、全パート噴飯物と言えばそうなんだけどさ。

ドラムは弄ってる部分が案外多いのだけどその理由は割とマヌケで、原曲がドラムの展開にやや乏しいせいでしょっちゅうリズムと展開を見失うという大問題が発生し、しょうがねえからドラムパターンを弄くって展開を持たせたってわけ。この辺に俺の根本的な欠陥が現れている気がする。

そしてギター。リズムギターはまだしも、リードギターが弾ききれていないというかオリジナルのフレーズと違う。ってか思ったよりも難しいぞこの曲。ポジション移動が案外激しい上に裏拍が入ってたりと思ってたよりもずっと譜割が複雑な部分がある。テンポチェンジもかなり激しくて、イントロが多分 150 bpm あたりでヴァース〜ブリッジで 172 bpm ぐらい、コーラスは 60 bpm ぐらいでソロで 120 bpm。おかげでよく突っ込んだりもたったりして録り直しになったというか、未だにコーラスのあたりでリズムが乱れてる。

ギターソロは酷いに決まってるのだが、今回最大のアクシデントはタッピングが出てきたこと。そもそもレガート系の練習量が絶対的に足りてないのに、よりによってタッピング (フルピッキングでイケる人もいるかもしれないけど俺には 16F/18F/23F なんてストレッチは無理)。当然、まるで弾けてない。ソロ後半の速弾きのつもりの部分のノイズの部分はタッピングしてるつもり。そもそもこのギターソロ、リバーブを深くかけて誤魔化してるのが丸わかり。ちなみに原曲のソロと違う所は、普通にミスってるかどうやって弾けばいいのかさっぱり不明だったんで適当にフレーズを考えたかのどっちか。つまり断じてアレンジなどではない。

そして今回最大の笑いどころ、それはヴォーカル。もしもここの読者に「デスヴォイスってがなってるだけじゃん」と思ってる人がいたら、即刻考えを改めていただきたい。やってみりゃわかるが、マジできついぞコレ。ヴォーカルが音程もリズムもよれまくっているけど、これは 4 回ほど録り直した結果一番良かったテイクで、さらにはイコライザーとエフェクターで誤魔化して、ミックスする時にヴォーカルを下げて、それでもこれ。ちなみに体力の限界に達したので 5 回めはなかった。それにしても曲の後半になるにつれて段々ヘタれていく様が自分で言うのもなんだけど笑える。俺の声質はデスヴォイスに致命的に不向きな気がしないでもないが、今回はそれ以前の問題だった。何を歌っているか自分でもさっぱりわからないが、まあ仕方がない。

ところで今回はヴォーカル録りと練習を兼ねて楽器店備え付けの練習スタジオを借りたんだけど、こっちの方がカラオケいくよりもコストパフォーマンスが良い。なにより、一人でカラオケに行っていきなり MTR をおっ広げるという不審人物にならなくていい。今思えば、前回はクリスマスのかき入れ時に押し掛けちゃって悪いことしたなあ。

2008-01-05
Sat

(23:55)

やはり Flash でも使って Web ページでそのまま音楽が聴けるようになってた方がいいよなあってことで、ちょっと Flash で簡易プレイヤーを作り始めたのだけど、これが非常に難儀した。というかムカついた。何がムカつくって、

  • どうも Flash 作成は専用のオーサリングツールがほぼ前提
    • コードをガリガリかいてコマンドラインでコンパイルなんてのは全然主流じゃないらしい
    • 俺が知りたいのは Flex じゃねえ
      • 本題からは離れるけど、既に同名の超有名ツールがあるんだからバッティングするような名前付けるんじゃねえ
  • Adobe のサポートページが酷い
    • 何でリファレンスに404 Not Found なページがあるんじゃ
      • リンク先の間違ってる奴もあるし
        • そもそも使いにくいし
    • 別のリファレンスマニュアルはまともなので、こっちを読むように。サポートページの方は地雷だ
  • JavaScript との連携が面倒臭い
    • これは仕方のない部分も多いのだけど、でもこの互換性の怪しさとわかりにくさは酷い
  • 使えるサウンドフォーマットは MP3 のみ。これは前から知ってたけど、ふざけてるとしか言いようがないな
  • そもそも俺は ECMA Script の系統が嫌い

というわけで非常に面倒な思いをしたのだけど、後はプレイヤーに使う画像さえ用意すればどうにかなるかなってところには来ている。そして問題はその画像であり、俺の一番の苦手分野だ。どうすっかな。

とりあえず、 Audacious のスキンから適当な奴をぶっこ抜いてきた。昨日アップした耳の腐りそうな音楽が流れるので、うっかり精神に悪影響を受けても俺は知らんぞ。

追記: 役に立つかわからんけど、以下は一応現時点でできてるソース。 SWFTools の SWFC 用のコードね。

.flash bbox=100x24 version=6 fps=50 filename="sample.swf" compress
  .box bg width=100 height=24 color=grey fill=#002436
  
  .png play "play.png"
  .png pause "pause.png"
  .png stop "stop.png"
  
  .button play_button
    .show play as=idle
    .show play as=hover
    .show play as=press
  .end
  
  .button pause_button
    .show pause as=idle
    .show pause as=hover
    .show pause as=press
  .end
  
  .button stop_button
    .show stop as=idle
    .show stop as=hover
    .show stop as=press
  .end
  
  .action:
    audio = new Sound();
    playing = false;
    resume = 0;
    loaded = false;
    filename = "";
    this.getUrl('javascript: setFileName()');
    
    play_button.onPress = function() {
      if (!loaded) {
        audio.loadSound(filename, true);
      }
      if (!playing) {
        audio.start(resume / 1000);
        playing = true;
      } 
    };
    
    pause_button.onPress = function() {
      if (playing) {
        resume = audio.position;
        audio.stop();
        playing = false;
        play_button.setLabel("play");
      }
    };
    
    stop_button.onPress = function() {
      audio.stop();
      loaded = false;
      playing = false;
      resume = 0;
    };
    
    audio.onSoundComplete = function() {
      resume = 0;
      loaded = false;
      audio = new Sound();
    };
    
    audio.onLoad = function() {
      loaded = true;
    };
  .end
  .put bg x=0 y=0
  .put play_button x=10 y=4 below=bg
  .put pause_button x=30 y=4 below=bg
  .put stop_button x=50 y=4 below=bg
.end

2008-01-06
Sun

(13:18)

それにしても JavaScript とか ActionScript を使った開発はバカげている。何がバカげているかというと、要するにこれらを使った開発では全く違った言語同士が密結合していて、その部分がさらに文脈上では明示的になっていないというのがふざけている。

昨日書いたコードを例に出してみるけど、例えば JavaScript から ActionScript を制御するには次の用なやり方がある。

<object id="sample" width=128 height=64>
	<param name="movie" value="sample.swf">
	<embed play="false" swliveconnect="true" name="sample" src="sample.swf" quality="high" width=128 height=64 type="application/x-shockwave-flash"></embed>
</object>
<script language="JavaScript">
function setFoo() {
  if(window.sample) window.document["sample"].SetVariable("foo", "bar");
	if(document.sample) document.sample.SetVariable("foo", "bar");
}
</script>

人によっては既に俺が何にムカついているのかわかってしまっていると思う。一応解説しておくと、このコードは "sample" という識別子の SWF オブジェクトの "foo" という変数に "bar" を代入するコードなのだけど、何で別の言語のプロパティを直接書き換えられるんだよ! SWF オブジェクトの取得方法が極めて格好悪いのは JavaScript だから不問にするとしても、これは非常にいただけない。こういうのは signal/slot 方式っぽく次のようにした方がはるかにマシだ。

<script language="JavaScript">
function setFoo() {
  document.sample.send("foo", "bar");
}
</script>

一応、 SWF オブジェクトに "foo" というシグナルなりメッセージなりを引数 "bar" で渡しているつもり。たとえやっていることが実質変わらない (ActionScript 側に単なる setter のコードが書かれているとか) としても、こっちの方がより疎結合な感じになっている。

ちなみに ActionScript 側では次のようなコードが最初の例に対応してる。

filename = "";
this.getUrl('javascript: setFileName()');

これは javascript スキームがもろに出てきているのが嫌だ。実は fscommand という関数もあって、それだと次のように書く事が出来る。

fscommand("JSFunctionName", "Argument");

ところがこれだと JavaScript 側では次のようなコードを書く羽目になる。

<script language="JavaScript">
function sample_DoFSCommand(name, arg) {
  if (name == "...") { ... }
}
</script>

俺はこのコードを見た瞬間アホだと思ったし、何よりこのコードは VBScript まで一緒に起動され、思わぬ事故を起こしかねない。それをいったらまあ getUrl の例もそうなんだけど、危険性は少なければ少ない方が良い。

これらは ActionScript 3.0 以降では ExternalInterface という仕組みがあって、見た感じこれはかなりの改善といえる。が、 SWFC が ActionScript の仕様すべてを実装しているわけではないので使えずにいるのが現状である (あ、これは Adobe のせいじゃねえな)。もっともブラウザの実装の非互換性による混乱は相変わらずで、俺が Web 開発で一番ムカついている部分は全然改善されていないのだが。

本題とはずれるけど、こういう事をやっていると静的型システムの方が安全という意見をやっぱり疑いたくなる。確かにコンパイル時に型チェックが出来た方がエラーが発見しやすくはなるだろうが、こうやって全く別の言語同士を繋ぐケースではそこまで役に立つとは思えない。実際かなりのアプリケーションは全然別の言語と通信したり DSL を活用してるので、結局一番重要な部分の整合性は人間がとらにゃならんのだよ。それに RPC の類をつかうと、同じ言語間でも型の不整合がありえるしな。確か Joel Spolski は JavaScript と ASP なんかにコンパイル可能な独自言語を開発して、この言語間のギャップを可能な限り軽減している。これはまったくもって正しいとしか言いようがない。

(16:50)

明日からまた仕事だと思うと大変憂鬱。この連休でだいぶ回復はしているけど、この一ヶ月間テンションを保てるかどうかは微妙。

(23:14)

いくらなんでも弦がヘタれすぎだと思えて来たので張替え。俺は Elixir の弦を愛用していて、その理由は弦の寿命が長いから。弦の張替えがたるくて仕方のない俺にとっては本当にありがたい。

ところでいままでは 0.10 〜 0.52 のいわゆるヘヴィボトムを使っていたのだけど、試しに 0.11 〜 0.49 のレギュラーゲージに変えてみた。トレモロユニットの調整しないといけないんであんまり弦のゲージは変えたくないんだけど、もうちょっと弦にコシがあった方がプレイしやすいんじゃないかと思って。で、流石にヘヴィゲージは俺の指にはキツいだろうと思ってレギュラーゲージにしたわけだ。当然高音弦でのベンドに力がいるようになって、もうちょっと指と手首を鍛えないと 1.5 音ベンド (最近練習してる曲に出てくる) は難しそうだ。

まあ最大の問題は、今月からまたろくすっぽ練習時間のとれそうもない日々が続きそうだってことなんだが。

2008-01-07
Mon

(20:54)

さーて新年早々俺のチームは爆発寸前、俺の堪忍袋も爆発寸前、まさか初日からこんなことになるとは。とにかく仕事していて困ることの一つは、「何でこんなことをやらかしたんじゃ」と聞いたときにフリーズされること。別にさあ、「何も考えずにフィーリングでやりました」でもいいんだよ、実際にそうやっちゃったんなら。正直に言ってくれればこっちも何か言えるんだけど、黙られるとこっちも打つ手が無いっての。後はアレだ、適当に取り繕って適当なこと言うのもナシな。それやられると俺はキレるよ。マウントとってパウンドかますよ。

2008-01-08
Tue

(01:13)

もう少し完成度を高めてから公開しようと思っているといつまで経っても公開できないので、もういいやと思って deltatools を公開。まだバージョン 0.0.0 なんで期待すんなよ。

そして今になって日本語のドキュメントを用意するのを忘れたことに気がついたが、眠いのでもう寝る。ってか英語のドキュメントはドキュメンテーション文字列を元に自動生成してるからいいんだけど、日本語の方はなあ。どうせ Synopsis 読めば大体理解できるだろうから、もうこのままでいいや。

あ、英文の方は相変わらずさっぱり自信ナシ。ま、何にもしねーでコードをポンと放っておくよかマシだろう。なので、最後の最後でゴメンナサイをしておいた。

(07:32)

俺はあんまり暖房の温度を上げすぎるのは好きじゃないんだが、こうも寒いとそうもいってられない。

2008-01-09
Wed

(19:44)

20 分ほど考えて 2 分ほど手を動かして 20 秒でテストを通してその変更のリリース依頼に数時間かかると死にたくなる。意味不明なインタフェースのツールを使ってリリース依頼書とかその他もろもろの書類を作って、それを提出するまでだけでも恐ろしいほど時間がかかる。そしてその変更が反映されるのは翌日以降。何故だ、何故こんなに面倒なことになっているのだ。

(20:52)

ふーん、オープンソース系のソフトウェアはインタフェースが不統一で使い難いんですか。じゃ、あんたの大好きな Windows のソフトウェアはどーなの? IE も Office もダメダメなインタフェースには違いないし、どっちかっつーとこっちの方がマズいだろ。特に Office の異なるバージョン間のデータフォーマットの互換性の無さやインタフェースの変わりっぷりは凄いよな。

それに Windows のソフトウェアも、かなりの部分がアプリケーション間で違うじゃん。メニューバーとかの見てくれが統一されてたところで、結局中のコンテキストの不統一のせいでアプリケーションごとに相当に異なる操作方法を覚えないといけないしな。もっともこれは非常に当たり前の事で、俺はそれ自体は批判しないけどね。本当の問題はユーザが迷子になるようなインタフェースになっているってところで、これはかなり改善できるところでもあるんだけどな (まあ、 Opera みたいに改善の兆しすらみられないのも多いけど)。

そもそも俺は今のアプリケーションもデスクトップもインタフェースが終わっていると思っていて、どうにかして改善できないものかと考えている。とりあえず以下はパッと思いついた、明らかに間違っていてかなりメジャーなインタフェース。

  • タスクバー。最終的に混沌界になることが定められている。ちなみに Xfce はタスクバーなしのインタフェースを選べて、 Xfce を使ってた頃は愛用していた
  • ウィンドウ切り替え (大抵 Alt-Tab だよな) の挙動。これを「最近使った順番でサイクル」に決定した奴には地獄に落ちる権利がある
  • タブ機能。ウィンドウマネージャの仕事だろこれは。アプリケーションごとにタブの切り替えなどのインタフェースが違うのはおかしいだろ。わざわざブラウザの設定をいじってタブ切り替えのショートカットをカスタマイズしてると、なんだか非常に虚しくなってくる
  • アプリケーション間の通信。これがショボいから、 IDE とかタブブラウザとかタブ機能付きエディタが出てくるわけだ

ちなみにアプリケーション間のインタフェースが全然統一されていないことが真の問題でないことは、 Web アプリケーションがこれほどまでに流行っているという事実が証明しているだろう。さらに言ってしまえば、多くのユーザは複雑な GUI というかイベントモデルのインタフェースを必要としていないんじゃないのか?

(21:11)

うげげ、 deltatools が Python 2.5 以降じゃないとダメだってのを書き忘れてた。いや、別に 2.4 でも動かそうと思えば動かせるんだけど (functools 使ってるだけだし)。

(21:50)

久しぶりに自転車に乗っていてすっ転んだ。それもかなりド派手に。何が原因かはわからんが、多分タイヤが磨り減っていてグリップが弱くなっていたのが理由だろう。週末にタイヤ交換しよう。

それにしても冬場でよかった。夏場だったら当然薄着なわけで、もっと酷い怪我をしていただろうな。

2008-01-10
Thu

(20:39)

どうも昨日は思ってたよりもずっと派手にすっ転んでいたようだ。あと怪我した部分を庇って不自然な筋肉の使い方をしていたら、別に怪我してなかったところも痛み出した気がする。

それにしてもアレだ、打ち身の他に風邪気味な上に歯も痛んで、体の中のまともな部分を探す方が難しい。

2008-01-12
Sat

(01:02)

昨日の仕事は実に酷い内容だった。何をやっていたのかというと、 form に対して動的に input 要素を追加する JavaScript を書いていたのだが、よりによってそれをJSP タグライブラリの中で書くというよくわからんことになっていた。しかもそんなことをしなければならなかった理由が、セッション情報に持たせるためのキーがないので毎回リクエストに入れ込んで持ち回すしかなかったというのだから呆れてしまう。どう考えても設計ミスだろ (前のプロジェクトの設計を何も考えずにコピペしてるからそうなる)。業務処理には無関係で単にユーザビリティというか画面の見栄えに関わるだけなので全体に修正をかけるわけにもいかず、だったらプロジェクトチーム随一の黒魔術師に泥を食ってもらおうということになったわけだ。ふざけんな。

それで久しぶりに JavaScript を書いたのだけど、俺はやっぱこの言語嫌いだ。とりあえず以下のソースコードを見てくれ。

function fun1() {
  for (i = 0; i < 10; i++) {
    print(i);
  }
}
 
function fun2() {
  for (i = 0; i < 10; i++) {
    fun1();
  }
}
 
fun2();

実行結果がどうなるかわかる? 「0 ..9 が 10 回画面に出力される」と答えた人は大変な常識人だと思うが、残念ながら JavaScript の世界では間違いのようだ。こいつを実行すると、単に 0 .. 9 が 1 回だけ出力される。え? 言ってることがわからない? じゃあとりあえず、先に書いたとおりの動作をするコードを書いてみよう。

function fun1() {
  for (var i = 0; i < 10; i++) {
    print(i);
  }
}
 
function fun2() {
  for (var i = 0; i < 10; i++) {
    fun1();
  }
}
 
fun2();

何が変わったかわかるか? そう、 var を付けただけだ。このあたりの話は檜山さんの「プログラマのためのJavaScript (12):不思議な宣言と奇妙なスコープ」が参考になるのだけど、どうも JavaScript にはブロックスコープが存在しないのだという。いや、それだけなら別にいい。例えば Python だって、変数のスコープはブロックではなく関数、クラス、ファイルといった単位になっている。だからブロックスコープでないというだけなら俺は何も文句は言わない (いや、本当は Python の変数のスコープにも文句はあるけど、まだ目を瞑ってもいいというレベルってこと)。問題は、 var を付けないと大域変数になってしまうということだ。つまり、最初に出したコードは次のコードのようなものだ (完全に同じじゃない。最初のコードだと i というシンボルが未定義)。

var i;
function fun1() {
  for (i = 0; i < 10; i++) {
    print(i);
  }
}
 
function fun2() {
  for (i = 0; i < 10; i++) {
    fun1();
  }
}
 
fun2();

俺が何にむかついているかというと、デフォルトで大域変数になるという仕様だ。しかも JavaScript にはパッケージだのモジュールだのといった概念がなく (俺はこれが最高に嫌いだ)、大域変数のやらかす悪さは輪をかけて大変なものとなる。確かに毎度毎度 var を付けていれば問題は起こらないだろうけど、じゃあそれって誰が保証すんの? 出来ないでしょ、そんなの。プログラミング言語の良し悪しを客観的に判断するまともなやり方の一つに、デフォルトがクソかどうかというのがある。クソなデフォルトはポカをしたときに事態をややこしくする (use strict していない Perl を考えてみよう)。そして、 JavaScript は現状では明らかにクソだ。

ところで JavaScript 2.0 ではこういった問題が修正されるらしく (どうやらパッケージ機能も追加されるらしい。というか、かなり Python ライクな部分もある)、これでようやくまともな言語になるなと思ってはいるのだけど、互換性とかの運用面を考えると相当な期間は現状のふざけた仕様に付き合う他なさそうだ。主要な Web ブラウザ全てが対応して、そういったブラウザのシェアが大多数を占めるようになって、それでようやく大手を振って使えるようになるわけだ。気が遠くなるね。

何せ Fierfox は 3.0 以降の対応で (一時期はすると言ってたけど未定に戻ったんだよな?)、 IE については……。少し調べた限りでは IE って JavaScript 1.3 までしか対応してないんだよな。どうも JavaScript 1.7 以降のリストの内包とかジェネレータとかの機能の話をあんまり聞かないなと思ったら、そういうことか。とにかく Web 開発はまず間違いなくクロス開発になるわけで、そうなると一番後進的な奴に全体を合わせる必要がある。つまり、 IE が対応するか IE のシェアが全体から見れば誤差程度に落ち込むまでは、 JavaScript 1.3 以降の機能は単なる技術マニアがお遊びで弄ってニヤニヤする程度のものにしかならんのだよ。だから俺は Microsoft も Web 開発も嫌いなんだよ。

追記: IE が対応してんのは JavaScript 1.5 (互換の JScript 5.6) だった。

2008-01-13
Sun

(20:11)

昨日書いたことに少しだけ関連。俺が Microsoft に対してムカついている決定的な理由というのは、別に Microsoft が独占的な立場にいるからというわけでもオープンソース陣営と対立するケースがあるからでもない。最大の理由は Microsoft のソフトウェアがダメだからなのだが、ただダメなだけなら別に嫌ったりはしない。じゃあ連中のダメさ加減のどこにむかつくのかというと、

  • 大変優秀な人間を雇い
  • 話を聞く限りでは世界有数の快適な労働環境を備え
  • これまた聞く限りではなかなか良さげな開発体制をとり

それで出来たソフトウェアがアレということだ。これはムカついているというよりも呆れているというのが近いか。

2008-01-14
Mon

(13:04)

今さっきコンビニ行ってきたんですよ、昼飯買いに。で、ドライカレー買ったんですよ。そんとき店員の野郎、「温めますか」って聞いてこなかったんですよ。まあそれは別にいいんだけど (温めすぎとかが嫌で拒否することが多い)、あろうことかスプーンじゃなくて箸を入れられてんの。あのなあ、どこの世界にドライカレーを箸で食べる奴がいるよ (もしもいたら変態認定)。

(13:49)

リメイク版の FF4 の難易度が大変な鬼畜と聞いてマゾゲーマーの血が騒ぐのだけど、流石にこれ以上リメイク商法に乗るのはなあとも思うのでやめとこう。

ところでこれはどんなゲームにもいえることだけど、如何にも金をかけましたな CG ムービーの後に素朴なポリゴンを見せられると大変微妙というか残念な気持ちになるので、もうそういうのはやめていただきたい。ってかむしろ三頭身程度のポリゴンキャラ (出来ればイベントシーンでボイス無し) の方が俺は好きだ。下手にリアルな CG は不気味の谷へまっしぐらなのでどうにもこうにもアレだけど、デフォルメされたキャラの場合は人形とかぬいぐるみだと思えるからな。

(14:59)

Tanabe さんとこで ZSFF ってのが紹介されてたけど、これはないかなあ。出てくるのが数年遅かったという感じだ。もしもこれが RSS その他の配信フォーマット黎明期に出ていたら、多分支持していたとは思う。

ところが現状ではこの手のフィードフォーマットは、サイトの更新情報というよりはサイトのコンテンツ本体の配信に使われている。確かに RSS Site Summary という意味でとらえれば間違った使われ方なのだけど、既に最後の S は Summary じゃなくて Syndicate に変わっている。

そして多くのサイトにおいては HTML の構造がまともではないので、ちょちょいと記事のタイトルとサマリを取ってくるという処理を行う汎用的なクライアントを作ることが出来なくなっている。そのため、 RSS などのフィードフォーマットには明らかに HTML 本体と重複した情報を入れなければならない。もっとも仮に全てのサイトの HTML が標準化とかされて自動処理が簡単になっても、ネットワーク負荷を考えるといちいち全部の記事にアクセスしていく必要のある ZSFF はあんまりいいアイディアじゃないかもしれないな。

2008-01-15
Tue

(20:04)

親知らず抜いてきた。俺の歯並びの悪さが完全に事態を悪化させていたようで、変な生え方のおかげで歯がボロボロになるまで自覚症状がなかったのが痛い。おかげで抜いてる最中に歯の一部が崩壊し始めて、担当の姉ちゃんがすげえ焦ってた。さらには根っこの部分がヒン曲がって生えていて、終わった後に「久しぶりのハマりでした」と言われるぐらいの強敵だった模様。実際、抜いた歯を見た瞬間思わず「うぉっ」っと叫んで脊髄反射で「マジお疲れ様でした」という言葉が出てくるぐらい酷い状態だった。

さらには歯石をとったらその下から虫歯が出てきて、またしばらく歯医者に通うことになりそうだ。やっぱ歯医者で定期的に検診受けないとダメだな。

(20:33)

俺は小学校の頃、とある先生から「何でもやるというのは何もやらないのと一緒。みんながやるというのは誰もやらないのと一緒」という事を言われた。

当時は先生が何を言っているのかさっぱりわからなかったが、今になってみたら至極当たり前のことを言っていたんだなと思う。

2008-01-16
Wed

(19:57)

あのさあ、何でコードに修正入れたら修正前のコードをコメントアウトしておかないといけないんだ? 何のためにバージョン管理ツール使ってんだよ。そんなことしてたらコードが読み難くなる一方だろ。どうしてそういうルールを平気で作れるわけ? さてはお前らバカだろ。まあ、あっちの業界人にはもう期待しないことにしてるんだけどな。

ところで最近は俺の仕事が激減していて (ってかもうすぐ離任するし) 仕事中空き時間が出来るようになったので、職場にて「達人プログラマー」を読了。この本はソフトウェア開発におけるベストプラクティスのようなもの全般を広く浅く概観しているような構成で、まあ大体知っていることとか当たり前の事が多く書かれていたんだけど、そういうことを「こういう風にやるのがいいんですよ」と改めてきちんと書いてくれることには価値があるな。それで当然今の現場はまったく出来ていないわけで、何ていうか読んでいて苦笑いしっぱなしだった。

2008-01-17
Thu

(19:02)

今朝出勤しようとしたら、自転車のサドルに雪が積もっていてびっくり。どーりで寒かったわけだ。

それはともかく、最近プレイするゲームがないなーと思って、何となく久しぶりに世界樹の迷宮を立ち上げたら、「ダークハンター」「パラディン」「バード」「メディック」「アルケミスト」という面子でフォレスト・セルに挑む前の段階でセーブされてた。そういや、最初に組んだパーティ編成 & 医術防御無しでのフォレスト・セル撃破をやろうとして、面倒になっちゃったんで放置してたんだ。というわけで、今更ながら最後の積み残しをやってみた。

結果からいうと、数回試行錯誤したのち 27 ターンほどで割とあっさり撃破。途中二回ほどあったランダム行動を山勘の三色ガードで凌げたのが最大の勝因だったかなあ。もちろん戦略は例の王の威厳誘発パターンで、序盤の数ターンで少しだけダメージレースをしかけるというもので、要するに前にやったのと同じパターン。流石に一度ネタが割れているから勝てて当然か。

(20:21)

deltatools にバグがあったのでバグフィックスリリース。境界条件を一個見逃していた。一つ前のバージョンでは末尾の数個の要素が一致していて、かつそれまでにいくつかの要素が異なっているデータへの差分が上手く生成されなかった。これはちょっとアレなポカだなあ (コードを比較すれば大体どこでヘマってたかわかるよ)。

で、それとは関係ないんだけど、今の deltatools の仕様はイケてないかなと思ってる。実は Python 標準ライブラリの difflib に多少は使用感を合わせようとして今のデザインにしたんだけど、でもこれだと unified_diff の戻り値の型が文字列のイテレータになってしまって、これはわかりにくいかもしれない。本来ならチャンク/行に対する外部イテレータを返すことのできるオブジェクトを返すべきなんじゃないか?

こんなことを考えるようになったのはマージ関数の部分に手を付けたのが切っ掛けで、果たしてマージ関数に渡すのはどんなデータが適切かという問題が出てきた。最初は差分データの文字列と元の文字列を渡してもらおうと思ったんだけど、何となく差分のフォーマット判断のロジックを書いていておかしいんじゃないかと思えてきて、それじゃあ何か別の型のデータを受け取ればどうだということになったわけ。

というわけで次のリリースでは早速その方向性でいこうかと思っているんだけど、それで迷惑する人はいないかなあ。今んところ三人ぐらいしかダウンロードしていってないんだけど、実際に使ってんのかな。もしもマジに使われてたら、互換性のために今の関数を残しといてもいいんだけど。まあ、ドカッと変えて文句が付いたら復活でもいいか。

追記: よくよく考えりゃ、 Diff オブジェクトに __iter__ メソッド持たせてそれ自身が差分情報の行単位のイテレータになるようにすれば今の仕様と互換性を保てるな。なによりこれなら今のテストコードを生かせる。

(20:58)

バグで一個思い出した。今のプロジェクトで最近、俺の書いた JavaScript にバグが見つかった。その内容はうっかり変数を大域変数にしてしまっていて (var 付け忘れ)、それが画面内のとある要素の name 属性と名前がバッティングしていて、そして IE の多分独自仕様である「name 属性を持つ要素はその属性名の変数としてアクセス可能」によって、まったくもって予期せぬ動作をしていたというわけだ。

もうね、こういうのがある度に JavaScript というか ECMAScript の言語仕様を最初にひり出した奴を叩っ殺したくなるね。もっとも ECMAScript は JavaScript と JScript (Microsoft が世界を分断するために作った言語。多分) の共通部分を抜き出して標準化しようとして作られたはずなので、実際のところ本当の火種はそこからさらに遡って調べないといけないわけだが。

そういや前に IE は JavaScript 1.3 までとか書いてたけど、ありゃ間違いだ。正しくは JavaScript 1.5 互換の実装である JScript 5.6 (IE 7 は 5.7) まで対応だ。まあ、誰も突っ込んでこなかったということは、そこまで致命的な差異が JavaScript 1.3 と 1.5 ではないのかなあ。面倒なんであんまり調べてないけどさ。

(21:44)

寒すぎ。暖房付けてるのに手がかじかむよ。いや、これは今の部屋の構造に欠陥があるとみなすべきか。やっぱロフト付きの部屋だと冷暖房の効率的には嬉しくないよなあ。引っ越すか。次は風呂とトイレが別で、ロフト無しで今と同程度の広さのところがいいんだけど、そうなると家賃がなあ。快速電車を諦めれば、別にあんつこたぁねえんだけどよ。

2008-01-18
Fri

(23:26)

親知らずを抜いたせいでここ数日はヨーグルトとか菓子パンとかインスタントの春雨スープとかで凌いでいたのだけど、いい加減白いご飯が食べたいよ。

2008-01-19
Sat

(17:29)

バカみたいに寒いので暖房を付けっ放しで寝ることがここ一ヶ月は多かったのだけど、おかげで電気代がちょっと大変なことになってしまった。前にも書いたけど部屋の構造に問題があるし、今使ってる掛け布団もあんましよくない。これはどうにかしないとなあ。

(18:31)

今月の Young Guitar で強烈なパフォーマンスを見せた Jeff Waters 率いる Annihilator の "Metal" を聴いた。タイトルに違わぬ誤解・曲解の余地の全くないヘヴィメタルとしか言いようのないアルバムで、全編にわたって参加しているゲストプレイヤーもいい仕事をしている。特に気に入ったのは Young Guitar でデモ演奏された "Clown Parade"。コーラスの歌メロはアルバムの中でも飛び抜けているし、ギターソロも素晴らしい (この曲には先月の Young Guitar でバカテクを披露してくれた Jeff Loomis がゲスト参加)。別の意味でインパクトが絶大だったのは "Detonation" で、ライナーノーツにあるとおりメインリフとヴァースの歌メロが Black Sabbath の "Children Of The Grave"。これ、わざとやってるでしょ。ちなみにこの "Children Of The Grave" という曲は本当にいろんなバンドがリフの元ネタに使っていて、事実上メタル界の共有文化財になっている。

2008-01-20
Sun

(23:56)

大体 21:00 頃に少し横になって、気がついたらこんな時間。久しぶりに中途半端に寝ちまった。こういうのが一番生活リズムを崩すんだよなー。

2008-01-21
Mon

(23:57)

まぁ、何というか朝起きられない人は確かに起きられないし、生活リズムが崩れるときは本当に崩れるよな。

でも午後 4 時から来るのってどうよ。

2008-01-22
Tue

(23:54)

またこんな時間に帰宅かよ。俺はもう離任するんだけどな。本来なら引き継ぎとか後片付けの時期なんだけど、俺いなくなって大丈夫なのか?

2008-01-23
Wed

(01:03)

改めてプロプライエタリなソフトウェアはダメだと痛感。お前ら高い金取ってバイナリだけ配布して、それでこれかよ。俺はオープンとプロプライエタリのどちらかしかない世界を選べといわれたら何の迷いもなくオープンな世界を選ぶのだが、これはプロプライエタリなソフトウェアはどうあがいても保守・運用・政治とあらゆる面で危険だからだ。

もしも今使っているソフトウェアの開発元が倒産したり、主力開発者に逃げられたり、買収されてそのソフトウェアの部門が縮小したり、自社もしくはパートナー企業がビジネス上の競合になったり、とにかくそういう事態になって今まで通りには使えなくなって、そこで簡単に解決が出来るとでも思っているのか。出来ねえだろというか、それが出来れば苦労しねえよ。

(01:50)

相変わらず darcs のソースコードを読んでも何のことやらさっぱりわからんのだけど (まあこれは真面目に Haskell を勉強しない俺が悪いが、 Haskell の文法も悪いと思うぞ)、でも darcs の差分形式はなかなか良さげだ。 uniffied diff の各 chunk を独立した hunk として扱う感じ。この形式のおかげで差分の部分適用が行えるわけだ。どうも darcs のマージアルゴリズムって、この hunk の文脈情報を適用済みのパッチの二重適用の阻止に使ってるっぽいな。

(22:02)

雪が降っていたせいで、今朝はこの冬屈指のタルい朝だった。

ところで今日は「誰かをぶっ殺したくなるぐらいムカつくことリスト」に一件追加があった。それは「盛り上がってきたところで乱丁・落丁」。これは最悪だ。というわけで出版社の Web サイトのフォームからクレームを投げてきたのだけど、そのフォームがポップアップウィンドウで出てくる上に意味不明な JavaScript の使い方をしていてブチ切れですよ。で、今はあちらからの返信待ち。

そのせいで空いた時間とかに読む本が無くなったので、「ピープルウェア 第2版」と「オペレーティングシステム 設計と実装 第3版」を買ってきた。そういや「オペレーティングシステム」はきちんと通して読んで実装までしたことはなかったんだよなあ。

2008-01-25
Fri

(01:00)

くっそー、俺はあと一週間で離任だってのに、何で未だに引き継ぎする暇すらないんだ? 絶対に間違ってる。

ところで今のプロジェクトからは 3人ほど (メンタルな理由で) 休職者が出てしまったのだけど、そうなる前にどうにか出来なかったのかなあ。確かにその時期は俺も結構大変で、というか完全に開き直ってどうにか凌いでいたような状態だったからな。そりゃあ、他の人のメンタルケアまでは出来んよ。もっとも俺にメンタルケアをさせるというのはエド・ゲインに産婦人科医をやらせるようなもんだと思うが。

2008-01-26
Sat

(01:33)

別にまだ家探しを始めたわけじゃないのだけど、 4 月までには引っ越したいと思っているのでちょっとずつ準備を始めてる。

とりあえず仕事が忙しくなってきた去年の 3 月以来ろくすっぽ使ってなかった食器の整理や調味料の処分を始めたのだけど、流石に未使用の中濃ソースとかほぼ未使用のゴマ油とか 80% 入ってるサラダ油とかを見るとちょっと鬱。本当はもっと自分で料理したかったんだけどなあ。残業の害悪はこういうところに出るんだよ (残業代は外食が多くなるのでかなり帳消しだし)。

(12:56)

すげーどーでもいいこと何だけど、思いついちゃったものは仕方がないので書く。

何を思いついたかって言うと芸術と娯楽の違いについてなんだけど、要するにこれって

娯楽
人々が欲しいもの
芸術
人々が思ってもいなかったもの

程度の違いしかないんだよな (そしてこれも程度問題で、娯楽性と芸術性が完全に切り離されることはないだろう)。だから一旦広まった芸術は陳腐化して娯楽になるし、一旦廃れた娯楽が将来に発掘されれば芸術扱いされることもあるだろう。ていうか浮世絵とかマジでそうだよな。日本じゃ単なるちょっと洒落た包み紙程度だったのが、時が流れて外国に行き着いて、「なんだこの絵は!? クール!」とか思われたんだから。そう考えると、いわゆる鑑定士の人たちは「人々に新しい美的感覚を与える」って意味じゃあまったくもって完全な芸術家だな。

何でこんなことを思いついたかというと、「娯楽 << 越えられない壁 << 芸術」とか思ってるバカチンにすげー腹が立ったのがきっかけで、こういうみっともない奴は考えを改めるか腹を切るかしてほしいものだ。

(16:37)

猫と重金属さん曰く「危険すぎる道を現在最も爆走している」という「聖☆おにいさん」を読んだ。これは確かに面白い。とにかく下界に降りてきたこいつらが「私達働きすぎじゃない?」とか言い出したときはどうしようかと思った。こういう不謹慎なものを楽しむぐらいの心の余裕が欲しいよなあ。もっとも個人的にはもう少し酷いネタが好みなんだけど、まあクレームが来て打ち切りになったら元も子もないよな。

それにしても漫画喫茶で夜を明かしたブッダが手塚治虫の「ブッダ」を読んで「手塚治虫スゲエ」とかいって感動してるコマは何度読んでもシュールだ。

2008-01-27
Sun

(17:13)

前々から書いているが、俺は「人それぞれ」で話を終わらせる奴が嫌いだし、そういう連中は全員死ねばいいと思っている。

例えば、音楽だのファッションだのといった単なる趣味の問題なら「人それぞれ」なのは当たり前で、こんな当たり前のことをしたり顔で言って「わかってる」面をしてる奴は完全にバカと扱ってよい。むしろ、趣味の合わないもの同士が「お前の趣味は悪い」「お前こそなんだよ」といがみ合ってる方がよほど人間らしいだろ。ってか実際のところ、適度にいがみ合ってた方が活力が生まれるんじゃないか (ここでいう適度とは、犯罪とか戦争に発展しない程度という意味)。なので俺は「ヘヴィメタル」を「ヘビメタ」と言う連中はとんでもなくダサいチンカスだと言い続けるつもりだ。

そして明らかにこの世界には「趣味の問題」で片付けたらダメなものがあるのだ。とりあえず次の設問に答えよ。

  • 「ゲーム脳」を信じるのは趣味の問題で良いか?
  • 「アポロ計画はアメリカのでっち上げ論」を信じるのは趣味の問題で良いか?
  • 「創造論」を信じる、あるいは「進化論」を信じないのは趣味の問題で良いか?
  • 「水からの伝言」を信じるのは趣味の問題で良いか?
  • 「キリスト教原理主義」のように聖書を字面の通りに信じるのは趣味の問題で良いか?

答えは全部「んなわけねーだろ」である。これは明らかに正しい、あるいは現時点で正しいと扱ってよいものを認めるかどうかという問題だ (つまり信じる信じないの問題ではないということ)。そして明らかに正しくない方を「信じる」ことが趣味の問題とは到底思えない。これははるかに深刻な問題で、そしてこれらは全て明らかに宗教問題である (宗教の本質の一端は現実逃避だということを覚えておこう)。

そしてこの問題が最悪に厄介なのは、こっちが「正しいものだと認めて良いか」を問題にしているのに、あっちはそんなことは問題にしておらず、むしろとんでもないことを信じることでより強く結束していることだ。多分これまでの歴史における宗教問題は「信仰するものの違い」が主たる要因だったと思うのだが、現代においては「信仰を持つかどうか」という点でも戦いが起こっていて、こちらの方がより深刻だといってもいいだろう。どーでもいいが、「科学もまた信仰」と考えている連中は極めて有害なアホなので今すぐ首を吊っていただきたい。

(19:09)

そういや最近になってようやく今のプロジェクトに BTS らしきものが導入されたんだった。結合テストになってバグレポートがポコポコ上がってきて、それを一つの Excel ファイルで管理するのは物理的に無理ということに流石に運営側も気がついたらしく、誰が作ったかわからんが (いや、当たりはつけてるけどね。三人ぐらいしか作れそうな人いないし) 運用が始まり、それで明らかに作業環境の改善がされてるのだからこんなもんプロジェクト発足当初からいれとけよバカー。

(21:26)

本日の挫折: 「世界樹の迷宮」のとあるバトルの BGM の耳コピ & 演奏。

とりあえずメインテーマ部分だけなのだが、一応出来たものを以下に。 30 秒程度のフレーズなんでお時間はとらせません。え、何でよりによってこの曲かって? そりゃあ、原曲がもろにフィンランド系鬱ゴシックなメロディだったからに決まってんじゃん。

何が難しかったかって、バッキングで延々と続くシンセによるアルペジオの音作り。これが全然納得いかない出来だったんで諦めたんだよ。クリーンサウンドに空間系のエフェクターとかかけて、低域と中域をゴッソリ削って高音部のみにして、リングモジュレータで音質を弄って、試行錯誤の挙句に今の俺の技術力ではこれが限界と判断。フレーズ自体は原曲の面影が残っているとは思うが、やっぱ音がなあ。

それに対してメインメロディは実に楽だった。フレーズはあっさりと出てきたので、後は音作り。これはエクストリームディストーションと MTR のアンプシミュレータのクリーンサウンドの組み合わせで、この音自体は結構気に入っているのでもしかしたら今後使える時が来たら使うかも。

これで殆ど終わりだったのだけど、若干音圧が足りなかった気がしたので、注意して聴かないとわからん程度の音量でディストーションサウンドでパワーコードを加え、ミックスする時にコーラスとリバーブで厚みが出るようにして終了。ベースは単純に録り忘れた。マスタリングの時に気がついたけど、気力が残っていなかった。ちなみに製作時間は大体二日ぐらい (まあ、大半は音作りで煮詰まってたんだけど)。

ちなみに俺が使ってるマルチエフェクターはZOOM G2。何か MTR のアンプシミュレータと全般的に噛み合ってない気がしてるけど、これは完全に俺の腕が悪いな。

2008-01-28
Mon

(18:54)

俺は基本的にバカからリンクを張られた場合何もしない。何故なら、バカの相手を真面目にしてると、はたから見るとどっちがバカだかわからないからだ。それにほら、俺がわざわざ何か書かなくても、バカに感化されるやつってまず殆どいないじゃん? が、今回は少々トサカに来たので例外。

科学は宗教では決して無いが,科学も宗教も元々は同じ物。我々人間は「分からない物」にあれこれ解釈を加えたがるので,科学も宗教も色眼鏡のひとつでしかないことは理解してほしいと思う。

「科学も宗教も元々は同じ物」までは紛れもなく歴史的な事実なんだが、その後は何だ? 「科学も宗教も色眼鏡のひとつでしかない」だって? 正気かよ。だったら何だ、「地震は地殻の変動が原因」というのも「地震は大ナマズが引き起こしている」というのも同じだってことか? それは明らかに違うだろ。まあ、確かに「大ナマズが地震の原因なんだよぅ」と言い出すのは完全に自由だ (その程度の言論の自由はこの国にもあるからな)。だけどよ、まともな学説と同列に扱いたいのなら証拠を持ってこいよ証拠を。いいか、「解釈の違い」までなら「趣味の違い」とまったく同じ話だからな。ていうか俺、「そしてこの問題が最悪に厄介なのは、こっちが『正しいものだと認めて良いか』を問題にしているのに、あっちはそんなことは問題にしておらず、むしろとんでもないことを信じることでより強く結束していることだ」って書いてるよな。お前も引用してるよな。何でそこで宗教と科学を同列視するような言葉が出てくるんだよ。

ちなみにこういうバカがソフトウェア開発の現場にいるとどうなるかっていうと、

  • バグの原因をきちんと探らずに適当な修正をしてみる (原因を探るためにコードを書きかえているわけではない)
  • 計測をろくすっぽせずにボトルネックの位置を決めつけてパフォーマンスチューニングをおっぱじめる
  • 自分にとって都合のいい前提条件のコードにこれまた都合のいいテストを通して終わり
  • 自分のところでコンパイルとテストが通ればよく、他の部分との整合性とか全体のデザインはガン無視
  • 動作確認せずにリリース

その他諸々、とにかく害悪でしかないんだ。上の奴は全部俺が見てきたケースだし、いくつかは俺自身大学時代にやらかしてえらい目にあったことでもある。そして本人は「自分はそれでいいと思った」と言い出すんだ、一つの例外もなくな (いや、まれに黙りこくる奴がいるな)。いいか、確かにとある現象を勝手に解釈するのは当たり前だが自由だ (ブレインストーミングなんかではむしろ普段出てこない電波な意見が貴重だしな) が、それらの中で客観的で妥当な証拠を欠いたものは信用するに足るものではないんだからな。いいか、たとえ自分にとって気にくわなかったり都合が悪かったりしても、それが明らかに正しいと判断できるものなら受け入れる必要があるんだ。俺の後輩には気にくわない、直観に反するという理由だけで量子力学を否定してるアホがいたが、お前はそのアホと同じだ。

いいか、科学は断じて色眼鏡ではないからな。むしろ色眼鏡をパラノイアに陥るまで取っ払う必要のあるものだからな (実際のところこれは本当に難しく、思わぬ見落としが無数にある)。俺が学んだものは確かに「計算機」で修飾されるし、そもそも選んだ道が理論屋ではなく実装屋ではあるのだけど、少なくとも大学で 4 年間科学を学んだものとしてそこは頭から否定させてもらう。

(20:43)

今さっきコンビニでカップスープを買ってきたんだけど、なぜかスプーンじゃなくて割り箸が入ってる。

……勝手にその店員はスープを箸で食べるプログレッシブな習慣の持ち主と断定。

(23:13)

本日のちょっとびっくりコード。

Object[] result = foo.bar(arg);
ClassA a = (ClassA) result[0];
ClassB b = (ClassB) result[1]; // ClassA, ClassB はクラス階層上では無関係

どうも Java で多値っぽいことをやろうしたが、

  • Java は多値をサポートしてない
  • Java は静的型付けなのでヘテロジーニアスコンテナが作れない (型安全性を考えるなら当たり前か)
  • 標準ライブラリに Pair や Tuple がない
  • プロジェクトの規約が厳しい上にアホで、中間データの受け渡しのクラスですら自由に作れない <- どう考えてもこれが一番の原因だけどな

というわけで、 Object の配列にしちゃったんだろうなー。ってこれはねえよ。何のための型付けだよ。俺は可能な限りそのための構造体クラスを作ろうとは思うんだけど、前述のとおりプロジェクトの方針で禁止されている。なので別解を考える必要があって、もしも foo が状態を持っていいのなら、

foo.bar(arg);
ClassA a = foo.getA();
ClassB b = foo.getB();

っていう解法もあるけど、これだと a, b が作られる処理が一連のトランザクションだっていうことが曖昧になる危険性があるので、俺はあんまり使わない。それに、 foo が状態持っちゃいけなかったら終わりだしね。というか俺は本当は次のように書きたい。

a, b = foo.bar(arg);

ただ、これだと a, b の型をどう表現するのかって問題がある。一番何も考えていない案は

ClassA a, ClassB b = foo.bar(arg);

という文法なんだけど、これはどうだろう。ちょっとこれは気にくわないし、型名を先に書く言語になれた人の場合 a と b がともに ClassA という風に錯覚してしまうかも (さらには ClassB を変数だと錯覚するかも)。なのでやっぱこれはダメだ。ある程度名前が長くなってくると相当読みにくいコードになりそうだしな。なので結局は次のようにするしかない。これは全然許容範囲内。

Pair<ClassA, ClassB> result = foo.bar(arg);
ClassA a = result.first;
ClassB b = result.second;

それでも問題は解決してなくて、もしも三要素の戻り値を扱いたかったらどうすんの? これについては檜山さんの「型パラメータと総称:どうしたらわかりやすい構文になるのかな」が参考になる。総称とか Generics の機能のある言語だとこういう問題に直面するんだよな。その点動的言語は悩む余地があんまりないので、気楽っちゃ気楽だ。もっとも仕事で使うのは今のところ十中八九 Java なので、考えないわけにゃいかないんだよな (それに俺は本当は強い静的型付けの方が好きだし)。

2008-01-29
Tue

(22:23)

たいへん! て が かじかんで ぎたー が ひけない!

(22:57)

えーとですね、俺はこの部屋に引っ越してきて二年近く経つのよ。で、初めてエアコンにサーキュレーターが付いてることに気がついたのよ。で、使ってみたわけよ。

……ギター弾けるぐらい暖房が効いてるんですけど。なんつーか、俺はバカか。

2008-01-30
Wed

(19:36)

仕事とは関係のない厄介事を引き受けてしまってちょっと忙しい。まあ、どうにかなると踏んだから引き受けたし、どうにかなる目処は立っているんだけど。

で、全然関係ないけどこの記事はどうよ。

いや、あんたが根拠がないと思っていても、事実には変わりないからな。とりあえず表に載っている新卒採用の課題を一つずつ見ていくと、

業界のイメージが良くない
こんだけ業界の暗部が晒け出されてりゃ、悪くなるのも当たり前。俺はむしろ、事実を隠して新卒を生贄にするよかよっぽどマシだと思うぞ。
人材の量的な確保が難しい
人材確保の努力をしていないからそうなる。俺だってトップの中にウォーターフォールをいい加減脱却してインクリメンタルな開発へシフトしようって運動をしてる人がいなきゃ、とっくに今の会社を見限っているさ。なので、最低あと一回は今の会社にチャンスを与えるつもり。
企業の知名度が低い
営業努力が足りないの間違いじゃないのか? ギリギリの時期まで大学とかに求人出して地道にやってれば、意外な獲物が引っかかるものさ。ちなみに俺は大企業かどうかとか、有名どころかどうかなんてのは一切考えていなかった。
昔と比べて学生の質が下がっている
具体的にはいつと比べてのことだ? あんたらの言う「優秀な学生」の定義は何だ? 昔の採用条件のハードルはどれぐらいだった? 言いたくないなら俺が言ってやろう、あんたらの考える「優秀な学生」は、従順で業界の悪い部分を知らず、徹夜の連続に耐えられる体力と理不尽な体制に文句を言わないマゾ性の持ち主だ。どうだ、当たってるだろう。
学生が仕事の内容をあまり知らない
情報系の学校を出てない限り、知らないのは当たり前。求人の出し方、間違えてないか?
即戦力になる学生が少ない
これもやっぱ求人の出し方が間違っているな。まともな大学の情報科にあたれば、それなりの人材はいくらでも出てきそうなものなんだが。少なくとも、俺よりも優秀な人材程度ならそこら辺に転がってんだろ。
技術力の高い学生が少ない
いいことを教えてやろう、「未経験者歓迎」という詐欺紛いの企業 PR を書くのを止めて、近隣の大学の情報科に出向くといい。
適正のある学生が少ない
で、技術者の適正って何? プログラミングとかソフトウェア開発が好き以外に無いと思うんだけど、他に何かある? まあ、四番目の理由と同じだな。
優秀な学生が少ない
上に同じ。
幹部候補となる学生が少ない
幹部の適正って何? ってか、そんなもん実際に働いてみるまでわからねーと思うんだが。これは技術者の適正以上にいい加減な項目だ。

というかそもそも、新人の育成って奴を考えてない回答が多くないか? まあ、確かにプログラミングを全くしたことがない奴を教育でどうにかできるとはあまり思えないんだけど、でもわかってて雇ってんだろ? きちんと育成しろよ? いいか、そこだけは絶対に放棄すんなよ? たとえ一つのプロジェクトが赤字で終わっても、次の黒字を生み出す人材が育てば最終的に勝てる見込みが出てくるんだからな。

2008-01-31
Thu

(20:48)

RI!・NI!・N! RI!・NI!・N! RI!・NI!・N!

というわけで、一年と八ヶ月ほど関わっていたプロジェクトから離任した。よくよく考えてみると、俺って要件定義以前の段階から関わっていたんだよな。いやー、入社して二週間 (厳密には一ヶ月の時間つぶし的 OJT があったけど) でこんなところに放り投げられるとはなあ。未だに信じられんよ。

それにしても本当にバカらしい開発だった。書きたいことがまとまらないので箇条書きにする。

  • 確かにプロジェクトがおかしくなる原因は技術的というよりも社会学・心理学的な問題だろう。が、それは技術的な側面はどうでもいいという事にはならない
    • もう少し詳しく書くと、技術的な部分と社会的な部分は分離なんてされてなくて、まったくの地続きってこと。だってさあ、 BTS とか自動回帰テストとか、そういう体制が整ってないと不安じゃん
      • ここ重要な。個々の作業者が不安になるような開発体制って時点で、社会学の問題になってるわけだ。というか情報技術も社会の一部なんだからさぁ……
        • ここでジレンマが生まれる。もしも明らかにおかしな開発環境でみんなが作業していて、誰もそれをおかしいと思っていなかったら? そこに乗り込んでメンバーに「こっちのやり方に切り替えたらどうか」と言って、それが受け入れられるのか?
  • 「バカとハサミは使いよう」と言うが、やっぱりバカはバカでしかないし、未熟者がほんの数週間で一人前になるなんてことは有り得ない
    • いや、確かにプロジェクトが火を吹いていて、猫の手も借りたい状況だったのは確かだよ? だからって一年目のペーペーを送られても、現場で教育してる余裕なんてないんだよ
      • これは上層部も反省しているので、今後は俺を中心にプロジェクトの火消部隊をある程度は確保していきたいんだと。ってアレ、俺がかなりワリを食う話じゃないか?
    • もっと酷いのはダメダメしい奴が送り込まれた場合。これはむしろマイナスの戦力だからなあ
      • お願いだからもう少しちゃんと喋ってくれ。プログラマはいつも黙ってコード書いてればいい仕事じゃないんだ
      • お願いだからもう少しちゃんと考えてくれ。俺の書いたサンプルの省略記号まで引き写してコンパイルエラーを出して悩まないでくれ
      • お願いだからもう少しちゃんと勉強してくれ。何で俺が現場でオブジェクト参照の概念について講義をたれなきゃならんのだ
  • いい加減ウォーターフォールはやっぱり止めた方がいいと思う。いや、古典的な開発手法からも (それが反面教師だとしても) 学べる物があるというのは当たり前の話だけど、それを実践してプロジェクトを混乱させるのはどうよ
  • 「プログラマと設計者は別物」という考えは大間違い。もちろん全体のアーキテクチャを考える人は限られた人数の方がいいだろうけど、それでもコードの細かな所、全体のアーキテクチャ・設計思想とは直行した部分は個々のプログラマの設計のセンスが問われるところなんだよ
    • そしてそれがわかってないバカが足を引っ張るわけよ。はっきり言ってコーダーになら誰だってすぐになれるけど、コーダーで満足されちゃ困るんだよ。そして本人が「コーダーで何が悪い」と思ってる以上は、どうあがいてもそいつに重要な仕事をさせるのは無理。ぶっちゃけコーディングの技量なんて、ものすごい最悪の底辺でもない限りはそこまで問題にならないんだよ (実際、業務用 Web アプリを作るのに凄い技術はいらないからな。あった方が当然いいけどさ)。一番の問題は、本人に「プログラムを書くことは規模や性質がどうあれ設計をしていることなんだ」という認識があるかどうか。この認識がきちんとあれば、まず足手まといになんてならないと思うんだけど
      • まあ、そういう認識を心の底から持てるようになるには時間がかかるってのが真相だと思うけどさ。だからこそ、プログラマを雇うときは趣味でいいからプログラミングをしていた奴を雇えといってるんだよ
  • 唯一よかった部分と思えるのは、今の現場に数年単位で出入りしてる人たちはきちんとした「チーム」になっていたこと。なので、一番プロジェクトが迷走していた時期でもそこまで職場の雰囲気は酷くなかったと思う。いや、酷かったには違いないけど、程度の問題

細かい話はいくらでも出てくるけど、とりあえず今日はこの辺で。