X環境でのキーボード設定に四苦八苦中。
色々いじくった結果、結論はktermを使えば全てうまくという…
日本語環境は後でいいからということで
すっかりktermの存在を忘れていた。
キーボード全般の設定もやってくれるらしいね、ktermは。

ktermも入れたことだし、ターミナル上で日本語入力ができるようにしてみる。
もちろんSKKでね。

skkinput2を使うことにする。
しかし、別途SKKサーバが必要らしい。
しかも最近のSKKにはサーバが付属していない。
Debianにはskkservというパッケージもあるのだが
それよりも高速なdbskkdというサーバがあるらしいので
そちらを使うことにする。

--- dbskkdインストール ---
しかしこのサーバ、かの有名（？）な
D. J. Bernstein氏のアプリケーションを使っているので
多少設定作業に癖がある。
dnscacheやqmail、daemontoolsなどを使ったことがある人なら
わかるだろう。

まず、dbskkdにはcdbが必要とのことで
氏のページからcdb（バージョン0.75）をインストールする。
ちなみにインストールコマンドは
# make setup check
なので注意。ここら辺にも癖がある。

次に、dbskkdの設定ファイルを直接いじくってmake。
詳しくはREADME参照。
# make install
でインストール完了。SKKの辞書が必要。
dbskkdはSKKの辞書をcdb形式にして生成する。
このcdbファイルは後ほど必要。

makeに失敗したら、直接Makefileを修正する必要がある。
こういった設定ファイルを直接編集する作業がしたくない人は
この辺で止めといたほうがいいかも（笑）。
まだまだ面倒な作業は続く。

--- 最高の信頼 ---
彼らがユーザにこういう面倒な作業を要求するのは、
別に嫌がらせでは無いのだ。
「この程度の設定作業が出来ない初心者はこのソフトを使わないでくれ」
という忠告なんだと僕は思う。

qmailが発表されてから今まで、
賞金まで掛かってるセキュリティ問題が発生しないのには
ちゃんとした訳があるのだ。
「存在しない機能にバグは発生しない」

便利な機能を追及するより、信頼できるセキュリティを確保する。
全てを提供するのではなく、そのソフトに必要な機能だけを入れる。
あとの機能は他のソフトに任せればいい。
プログラマは、最良の製品群を選んで使うのだ。

だから、多少の面倒は我慢しても
使いたい人だけこういったソフトを使えばいい。
そこには、最高の信頼性が待っている。

--- skkserv ---
っと、ちょっと横道にそれたので再びインストール再開。
dkskkdをインストールしたら、いよいよ一番厄介な作業である
tcpserverとの連携部分を作成する。
daemontoolsがインストールされている必要がある。
ちなみに今回はログを行わない設定にする。
それやると記述が面倒になるから（笑）。
知りたい人はdjbdnsのdnscache-confなんかを使ってみるといいかも。

以下の作業は全てrootで行う。

# adduser dbskkd
# mkdir /etc/service/dbskkd
# chmod 3755 /etc/service/dbskkd
# mkdir /etc/service/dbskkd/root
# chmod 2755 /etc/service/dbskkd/root

dkskkd/run.example -> /etc/service/dbskkd/run、
dkskkd/SKK-JISYO.L.cdb -> /etc/service/dbskkd/root/SKK-JISYO.L.cdb
にコピー。必要ならばrunを編集する。

# chmod 2755 /etc/service/dbskkd/run

ここまで来たら、/serviceディレクトリ上に
シンボリックリンクを作成する。

# ln -sd /etc/service/dbskkd /service/dbskkd-cdb

これで、skkservが起動する。
確認するには以下を実行すればいい。

# svstat /service/*

サービスを起動してからの経過時間（秒）が表示される。
起動に失敗していると、これは常に0か1になる。
ちなみに、skkservは1178のポート番号を使う。
起動失敗原因を探るにはpsコマンドから行う。

# ps alxwww | grep readproctitle

ここにエラーメッセージが表示されているはず。
ほとんどの場合、原因はパーミッション関係である（体験談）。

--- ktermから使う ---
X環境からskkinputを使うには、いくつかの設定が必要。
set-language-envコマンドを実行すれば
ほとんど全ての日本語環境設定ファイルを作成してくれるので便利。

まずはX環境からskkinputを起動する。
このとき既にskkservが起動している必要がある。

$ skkinput -h localhost &

毎回localhostを指定するのが面倒ならば、
~/.skkinput
を作成して以下を記述。

skk-server-host: "localhost"

kterm上で Shift+Space を押せば、日本語入力モードに入る。
「かな--」と出るのですぐに分るはず。

キーのカスタマイズについてはただ今調べ中。
とりあえず、Shift+Spaceは使いづらいので
~/Xresources
にある「Shift<Key>space」の部分を変えれば
skkを起動するキーはカスタマイズできるようだ。
set-language-envコマンドで作成していれば、
そこら辺がコメントアウトされてるはずなのですぐにわかるはず。
僕は結構昔からShift+Escapeを使っているので
「Shift<Key>Escape」にしている（大小文字に注意）。

そろそろ本格的にWindowsを使わなくなってきたので
Debianでメールを受け取れるようにする。

メーラは、Thunderbirdという手もあるのだが
こいつには最大の欠点がある。
それは、Maildir形式をサポートしていない事だ。

メールの保存形式にはmbox形式とMaildir形式があって
Outlookも含め、ほとんどのWindows用メーラはmbox形式を使っている。
mboxは、たくさんのメールを一つのファイルにまとめて管理する。
それに比べてMaildirは、メール一つがファイル一つとして管理される。

--- 可搬性 ---
一見mbox形式の方が便利そうだが、
色々なデメリットが多い。

まず、メールをまとめて扱っているので管理がしずらい。
つまり、メールソフトを経由しないと
メールを閲覧・整理できない。
環境を移行するときに、これは非常に困る。
大抵の場合、古いmboxファイルは捨てられて
（もしくはバックアップされ）
新しいマシンでは空の状態からメールをスプールしていく。

Maildir形式なら、
過去のメールを（通常のファイルと同じように）圧縮し
新しいマシンのメールディレクトリ内に展開するだけで
メールデータの移行は完了だ。

そして、qmailの作者が言っているように
一つのファイルにまとめて詰め込むというのは
そのファイルが壊れたら全てのメールが台無しになってしまうという点で
非常によろしくない。
データベース並のりかばり機能を持ってるんなら話は別だが。

適切な振り分けをしてメールを管理すれば
一つのフォルダに何千件のメールを入れる事など無いはずなので
メール毎にファイルを分けるというには
それほど効率の悪い処理ではないのだ。

--- mew ---
で、メーラはこれにすることにした。
MUTTという選択肢もあるんだけど
使い慣れたEmacs上で作業できるというメリットを考慮して
とりあえずmewに。

とりあえずDebianマシンではメールサーバは入れない。
今あるRedHatサーバのメールアカウントと、
メインであるniftyのメールアカウントだけあれば充分だから。
ただし、mewでは複数アカウントの扱いが面倒なので
別の手段を考える必要がある。

--- fetchmail＆procmail ---
こんなものがあるらしい。
簡単に言えば、
外部のメールサーバからローカルのメールディレクトリに
メールを随時取得するデーモンのようだ。
これで複数のメールアカウントからまとめて
一つのディレクトリにメールを格納するようにすれば
mew上では単一アカウントの設定でメールを一元管理できる。

procmailと対で使うらしいのでとりあえず使ってみた。
今いちよくわからんが、とりあえず最低限の設定だけで動いた。
本来メールの振り分けとかをやるプログラムらしいんだけど
いくつか見た紹介ページの設定ファイル例があまりに汚いんで
やる気が失せてしまった（失礼）。

まぁこれは彼らの責任じゃないからね。
procmailというプログラム自体の問題だろう。

--- w3mが遅い ---
なんか知らんが、w3mがメチャクチャ重い。
Opening Socket...
とかいうメッセージが異常に長く出たまましばらく固まる。

Webで調べてみたところ、どうやら設定の問題らしい。

http://blog.goo.ne.jp/howtomobile/e/c17319c742cea53fc3887998c67227d8

Option画面で「名前解決の順序（Order of name resolution）」を
inet onlyにすれば速くなるらしいのだが、
どうも家の環境ではあまり速くなった気がしない。
DNSの問題かなぁ。
我が家のDNSキャッシュサーバが原因かもしれない。

昨日もまたバグが出た。
え？またですか？(笑)

本来なら、こんな他人事のように話してる場合じゃないのだが。
正直、このプロジェクトに労力を注ごうって気になれない。
いつの間にか他人が撒いた火種の後片付けしてるだけだからね。

勝手にプロジェクトに放り込まれ、
その後の謝礼も全く無し。
せめて飲みでにも連れてってくれよ。
そうじゃなきゃ、いつまで経ってもバグは出続けるぜ。

うぉぉ、今だにうまくいかん。
ktermからは日本語入力できるのに
Firefoxとかのウィンドウからだと日本語入力が効かないのだ。
GTKの問題と思い再インストールするも駄目。

しょうが無い。今さら元に戻すのも面倒なので
バックアップを取ってまた最初からやり直すことにする。
こんな夜中に俺は何やってんだ（笑）。
とりあえずcfdiskでパーティションを分割して、今のデータは保管しておく。

で、Debianを再起動…起動しねぇ！
Grubが立ち上がらない（メニューすらも）。
仕方無いのでDebianのCDから起動。
続きはまた明日にしよう。もう眠い。

なんかここんとこ仕事が忙しい。
残業ってのは続けると慣れてくるから嫌だよね。
食事の時間帯がずれるから身体にも良くないし。
って、そんなこと寝る前まで酒飲んでる人間が気にする事か(笑)。
でも最近はあまり飲んでないのだ、実は。

今週、来週くらいまではこの状況が続きそうだ。
来週末あたりに最終リリースがあるらしいからね。

とりあえずDebianをデスクトップ環境で再インストール。
当然のように日本語入力も出来るようになって一安心。
まだgtkからコンパイルするのは早いかな。
もう少しXの挙動を理解してからでないと。

サイズを変更してバックアップしておいたパーティションは
一部ファイルが壊れてしまった。
やはり単純にシリンダサイズ変更するだけじゃまずかったか。

最近では多くのLinuxがデフォルトで
HDのパーティションを丸々 / で切るようになってきた。
これは個人で使う分には便利だが
今回みたいにシステムを再構築することを考えると
パーティションは細かく切っておいた方がいい。

またやってきましたよ。MS,Oracleとのあくなき戦いが。
今やっているプロジェクトは IIS & Oracle (&iアプリ) という
最凶の組み合わせ。
こいつらの出すバグには何度となく悩まされてきた。

サポートページで情報公開すれば済むと思ってんじゃねぇ。
プログラム直すのが当然の義務だろうよ。

--- 激闘1 ---
まず最初の問題が発生。
ようやく我が現場に来たサーバマシンにOracleをインストール。
で、IISからOracleに接続しようとするも…出来ねぇ！！

調べたところ、Oracle9.0.2とIISの組合せで起きるバグらしい。
ちっ、ピンポイントかよ。
Oracleのディレクトリをセキュリティ変更すると直った。
現場での作業だったんで、詳しいログは取ってないのだ。すまん。
もし同じ現象で困ってる人いたらBBS or Mailでどうぞ。

--- 激闘2 ---
さて、次はもっと難解な問題だ。
IIS & ODBC。こいつは手強かったぜ。解決まで約4時間掛かってしまった。

現象としては、IISからODBC経由でOracleに接続すると
「たまに」接続エラーを返してくるというもの。
このとき、ODBCはError.Numberプロパティに0を返す。

今までは単純にこれを無視していたのだが
果たしてNumberプロパティが0だからといって無視していいのか
という話が持ち上がり調査する羽目に。
っていうか別にいいじゃねーか。
今までうまく動いてるんだからそんな事調査しなくても。
どうせロクでもない原因に決まってるんだ(実際そうだったけど)。

原因は、DBプーリングにあった。
ODBCはデフォルトでDBプールを使う。
しかし、このプールは一定時間使われていないと破棄されてしまう。

で、問題はその後。
ODBCは接続をプールから取得せずに再生成した場合に
「今回はDB接続を再生成しましたよ」という付加情報を
Errorプロパティに設定してきやがるのだ。
で、それだけだと普通のエラーと区別が付かないから
Numberプロパティに0を設定することで誤魔化そうとしている。

こんな酷い仕様があるか。
付加情報をエラーとして返す必要がどこにあるんだ。
そういうものは、クライアントからのリクエストがあったときにだけ
返してやればいいのに。

--- 完全無視 ---
今回の解決に時間が掛かった一番の原因がある。
ASPの先頭に記述されていたこの一文だ。

On Error Resume Next

この一文が何を意味するかというと、
「エラーが発生しても処理をそこで中断させず、次の処理に移りなさい」
という指示なのだ。

ASPに限らず、ほとんどの言語は
エラーが発生したらその段階でエラーメッセージを出してプログラムが終了する。
もしくは、そのエラーを明示的に捕らえ(catch)て
プログラム内で対処をした上で処理を続ける。

ASPで前述の一文を使うと、
エラーをcatchしなくてもそのエラーは無視されて先に進む。
ただしエラー情報は変数に格納されるから
プログラム側でそのエラー情報を判断して
エラー処理を行うことは可能だ。

しかし、そんな事はどうでもいい。
問題なのは「意図していないエラー全てが無視される」という事だ。
例えば、ASPでは通常のVBと違い変数は予め定義しておかなければならない。
つまり、変数を宣言していないと
その変数を使っている全ての箇所が無視されるのだ。
これによって、思わぬところで別のエラーが発生し問題は複雑化する。

とにかく、こんなオプションは使わない方がいい。
ほとんどの文献で、エラー構文にはこの
On Error Resume Next
をメインに説明しているが
多少なりとも保守を考えているプログラム内で
こんな構文は絶対に使わないことをお勧めする。
近い将来、間違い無く原因不明のバグに悩まされるのだから。

しかし、これに代わる構文もロクなのが無いというのも事実。
On Error GoTo <ラベル名もしくは行番号>
というのが用意されているので、これを使うしかないようだ。

まぁ一番良い選択肢は
「VB(ASP)なんて使うな」って事に尽きるんだけど。

さて、これはiアプリのエラーメッセージである。
iアプリをダウンロードするときに何らかの不具合が見つかると
このメッセージが表示される。

いくつかのWebページによると
このメッセージはjamファイル中のPackageURLに
IPアドレスを指定できないとか
jamのAppSizeとjarのファイルサイズが違うとか書いてあるが
もっと重要なことがある。

それは、「ダウンロードするときのURL指定をIPアドレスで指定してはいけない」
ということ。
開発時なんかはよく陥りがちな罠だ。
っつーか正に俺がハマったから書いてるんだけど(笑)。

それにしても、何故IPアドレスだといけないのか。
DNS名の方がセキュリティ的にはよっぽど危険なんだけどな。

Windowsを使ったことがある人ならば
誰もが経験するであろう、ファイルのロック問題。
Windowsでは基本的に、誰かがファイルを開いていると
そのファイルを他から編集することが出来ない。

「そんなの普通じゃん」と思った人は、生粋のWindowser(？)です。
これがどれほどの不便を招いているか考えたことがあるだろうか。

「ファイルをロックしておかないと、他の人に上書きされちゃうじゃん」
という意見もあるかもしれない。
だが、現実はそれほど単純ではない。
Windowsを使っていてファイルを上書きされた経験が無い人は
果たしてどれ程いるだろうか。

結局、いくらロックシステムを使っていたとしても
不注意で上書きされる可能性はある。
むしろ、ロックがあるからといって
そういった注意を薄れさせてしまう危険性が増えるかもしれない。
これはSubversionが他の(ロックを使う)ソース管理システムと比べる際に
言及している点だ。

ロック機構は、初心者に偽の安心をもたらす疑似工作に過ぎない。
実業務において、ロックは作業の進行を妨げる障害にしかならないのだから。

またOracleのバグだよ。
一体どうなってんだ。

ASP(ADO)経由でSQL文を投げてみる。

SELECT * FROM TESTTABLE;

↑これは成功。

SELECT * FROM TESTTABLE T;
↑しかし、これは失敗。
4つもエラーメッセージが返ってきやがった。

Error #0
[Oracle][ODBC][Ora]ORA-24334: この位置に対する記述子はありません。
(Source: Microsoft OLE DB Provider for ODBC Drivers)
(SQL State: S1000)
(NativeError: 24334)
Error #0
[Oracle][ODBC][Ora]ORA-00904: "TESTTABLE": 無効な識別子です。
(Source: Microsoft OLE DB Provider for ODBC Drivers)
(SQL State: S0022)
(NativeError: 904)
Error #0
[Oracle][ODBC]オプションの値が変更されました。
(Source: Microsoft OLE DB Provider for ODBC Drivers)
(SQL State: 01S02)
(NativeError: 0)
Error #0
[Oracle][ODBC][Ora]ORA-24334: この位置に対する記述子はありません。
(Source: Microsoft OLE DB Provider for ODBC Drivers)
(SQL State: S1000)
(NativeError: 24334)

調べたところ、どうやらパッチを当てないと直らないらしい。
まったく使えねぇ。
以前もそうだったが、Oracleっていうのはパッチを当てないと
まともに動かない酷い製品だ。

--- 立て続けに ---
今度はこんなエラー発生。

[Oracle][ODBC][Ora]ORA-01013: ユーザーによって現行の操作の取消しが要求されました。

ODBC経由で長時間に渡るSQLを発行しているときに起きるらしい。
これによって発行したSQL文は全てRollbackされる。
ホントに使えねぇ。

--- Oracleの精神 ---
とにかく、Oracleを使っていると
こういったバグが山のように発生してくる。
なんでこんな苦労をしてまでOracleを使う必要があるのかが
全くわからない。

良いものが使われるべきだ。
使いずらいものは排除されるべきだ。
Oracleは、決して使いやすいから選ばれている訳じゃない。
製品を購入したユーザへのサポートに重きを置いているだけだ。
しかしそれは単なる建前に過ぎない。

実はOracleはわざとバグを出して
「サポート無しでは使いものにならない製品」に仕立てている。
これが嘘だと思うなら、実際にOracleを様々な場面で使ってみるといい。
これ程バグの多い製品が何くわぬ顔をして販売されている事に驚くだろう。

そんな事も知らずに、高額を払いOracleを使っている人々は
それが自分達の生活を苦しめていることに気が付いているのだろうか。

ずいぶん放ったらかしにしてましたが。

何しろ先週までは珍しく仕事が忙しかったのと
新マシンの設定作業で苦戦してたのが重なって
日記書く暇がなかった。

ようやく家の環境もほぼ完全にWindowsから脱却して
Linuxに移行できつつある。
ここ1週間くらいはWindowsを起動してないけど
何の問題も無く作業できてるし。

--- 次の仕事 ---
落ちついてきたので、そろそろLimywebでも
更新しようかと企んでいる(またかよ)。

そろそろソースも公開しようかなと考えてる。
でもその為にはドキュメントも整備しないとなぁ。
あまり使いたくはなかったけど、Wikiでも使おうか。

ふぃぃ、今日は現場の人達と飲みに行ってきました。
この現場来てからは初めてかな。

何かやたら絡んでくる奴がいて
あしらうのに手間取ったけど
それ以外はまぁまぁ。
やっぱ絡み酒ってのはイカンですよ。

今週末には毎度おなじみ会社の飲み会があるので
今度こそ美味い酒飲むぞ?。
以上、酔っぱらいがお送りしました(笑)。

Oracleの駄目さに嫌気が差した人は、
是非MySQLを使ってみて下さい。
多少プログラマ寄りではあるけれど、
これを知ってしまったらもう他の腐ったDBには戻れない。

開発者の使いやすさを第一に考え、
僕らが欲しいと思う機能はほぼ網羅されている。
今まではおろそかになっていたグラフィカルな管理ツールも
最近では用意されている。ただし、まだ日本語版は無い。
でも日本語対応はしてるのでカラムが文字化けたりすることは無い。

日本語の丁寧なマニュアルも
無料でいつでもWebから参照もしくはダウンロードすることが出来る。
Oracleのマニュアルを読んだことがある人はいるだろうか。
恐しくわかりにくい形式で記述された
「これ読んでみろ」と言わんばかりの自己中心的ドキュメントだ。

--- 真のDBへ ---
今年の11月にはMySQL 5の正式リリースが予定されている。
これには、ビュー・トリガー・ストアドプロシージャ等
今までMySQLに欠けていたものが全て実装される。

尤も、これらの機能は僕のようなプログラマにとっては
絶対必要としていた機能ではない。
MySQLは多くのビジネス上で実際に使われていたのがその証だ。
もちろん機能はあれば便利だが、
それらはある程度プログラム上で補うことが出来る。

--- ビュー ---
例えばビュー。
これは、複数のテーブルを結合させて
一つのテーブルのように見せる仕組みのことだ。

複数のテーブルから一括して情報を取り出したいとき、
ユーザはビューを利用して簡単なSQL文で結果を取得することが出来る。
これは確かに便利だが、DBクライアントにSQL履歴機能が備わっていれば
ビューが無いからといっていちいち毎回複雑なSQL文を打つ必要は無い。
つまり、クライアントの機能によってビューの利便性を実現できるわけだ。

--- トリガー ---
トリガーとは、あるSQL文が実行されたときに
それに応じた別のSQL文を発行する仕組みのことだ。
例えば、履歴テーブルにレコードが挿入される度に
それらのサマリー(累積情報)を別のテーブルに格納する事などが出来る。

これも便利だが、もし元となるSQL文を発行しているのが
自システムだとしたら
そちら側で対応することよって
トリガの役割を果たすことが出来る。

ただし、別のシステムやユーザが独自に発行したSQL文に対しては
それに対応することが出来ない。
そういった意味では、トリガーはDBに必要な機能と言える。
他システムとの連携というのは実業務上重要な要素となるからだ。

--- ストアドプロシージャ ---
ストアドプロシージャ(以下SP)とは、
複数のSQL文を一括に送信する仕組みのこと。
SQL文だけでなく、簡易プログラムを記述することも出来る。
ループさせたり、条件判定をしたり、それなりの機能は揃っている。

それは、SQL文と(SP以外の)プログラムを組み合わせることによって実現できる。
その方が保守し易いし、デバッグも簡単だ。
しかし、もしその処理に高速性が求められているのならば
SPが必要となる。
SPであれば、1回のネットワーク通信だけで
様々な処理を行うことが可能だからだ。

しかし、それによって出てくる弊害は大きいことを
頭の中に入れておいてほしい。
複雑になったSPは、1ヶ月も経てば化石となる。
そのSPを改良・修正しようと思ったら
とてつもない労力が掛かることを知っておくべきだ。
SPの使用は最終手段だと思ってほしい。

--- 導入について ---
MySQLを導入するとき、一つだけ注意する点がある。
それは、導入すべきバージョンについて。
現在よく使われているものとして、4種類ほどその特徴を挙げてみる。

--- MySQL 3.23.xx ---
おそらく現在最も多く使われているのがこのバージョンだろう。
安定しているし、使用には何の問題も無い。
ただし、サブクエリやビューなどの機能は一切使えない。

トランザクション機能を持ったデータベース、InnoDBは
デフォルトでは無効になっているが
起動オプションを設定することで簡単に使用することが出来る。

--- MySQL 4.0系 ---
かなり3.23系に似ている。
サブクエリが一部使えるようになった。
InnoDBはデフォルトで有効になっている。

--- MySQL 4.1系 ---
4系ではあるが、3や4.0系と比べて大幅な変更点がある。

まず、ユーザ認証方式が変わった。
これにより、4.0以前のクライアントから接続できない。

次に、文字コードの扱い方が大幅に変わっている。
具体的な内部仕様はよくわからないが
まず間違い無く一度は文字コードのトラブルに見舞われるだろう。
解決方法さえわかってしまえばその後に支障は全く無い。

サブクエリが完全に使えるようになった。

--- MySQL5系 ---
現在開発中のバージョンがこれ。
もう最終リリースまで1ヶ月程度なので
実用に耐え得る状態まで仕上がっているはずだ。

ビュー、トリガー、ストアドプロシージャが実装された。
文字コードに関しては4.1から若干変更されたようだ。

--- 結論 ---
で、どのバージョンを使えばいいかという事は難しい。
ただ、これから導入するならば4.1か5を選択した方がいいと思う。
4.1はもう充分に安定しているので、まずはこれから始めるのが無難かもしれない。

いつでも5にバージョンアップする事は出来る。
他のDBと違い、移行に手間はそれほど掛からない。
また、レプリケーションを使うことによって
システムを稼働させながらのデータ移行も行える。

--- YMTD ---
これだけMySQLを薦めといて何だが、
最後にこの言葉で締めくくりたいと思う(Velocity日本語ページより引用)。
「どちらを選ぶかは、あなたが判断して下さい。」

さて、前回からの流れで(？)今回はVelocityを紹介する。

Velocityとは簡単に言えば、文書生成テンプレートツールだ。
Jakartaで開発されている。
動的な文書を作成するにはいくつもの方法があるし
その用途も様々だが、今回は一つに絞って紹介しようと思う。
それはずばり、動的HTMLの生成について。

--- 最良の選択肢 ---
JavaでHTMLを生成すると言ったら、誰もが真っ先にJSPを思い浮かべると思う。
僕も以前まではそうだった。

しかし、いつも言っているようにプログラマには常に最良の選択肢を選ぶ権利がある。
JSPの代わりとして今注目しているのが、このVelocityだ。

--- シンプル ---
Velocityの特徴は、そのシンプルさにある。
JSPでは、文書(HTML)とコード(Java)の分離をするのに
結構な手間と技術が要求された。
具体的には、拡張タグライブラリというものを自作しなければならない。
もしくは、Strutsのようなフレームワークを使用する。

JSPファイルがHTMLに変換されるのに、どのような経路を辿っているか
知っている人はいるだろうか。

--- 複雑 ---
JSPファイルは通常のHTMLファイルにタグを埋め込んだ形式になっている。
それをJSPパーサが解析してJavaファイルを自動生成する。
さらに、このJavaファイルをコンパイルして
作成されたclassファイルを「実行」することでようやくHTMLが出力される。

JSPパーサが生成するJavaファイルの内容を見たことがある人は、
そのあまりの汚さに閉口した事だろう。
とはいっても、大抵の人はそれを気にする必要は無い。
JSP→Java→class→HTML
という工程の中で、真ん中の二つは自動的に行われるので
意識する必要が無いからだ。

しかし、開発者はこれを意識する必要がある。
具体的には、デバッグ作業の時だ。
JSPファイル内でエラーが発生した場合、開発者はその汚いJavaコードを
見ながらデバッグしなければならない。

つまり、結局JSPは文書ではなくコードなのだ。
これでは「プログラマとデザイナーを分ける」というMVCモデルを実装できているとは
とても言えないのではないか。
通常のデザイナーではまず間違い無くJSPファイルを修正できない。
ただ単にレイアウトを変更したいだけでも。
ある程度プログラムの事を理解した人でないと、JSPファイルを編集したときに
発生する意味不明なエラー内容に対処できないからだ。

--- ビジネス ---
僕はプログラマだから、今までそういう事をあまり気にする必要は無かった。
コードもデザインも全部一人でやるスタイルだったからね。
でも、このスタイルはビジネスの世界ではおそらく通用しない。
ユーザは見栄えのいいページを望んでいるからだ。

そのためにはデザイナーが必要になる。
今までの開発方式だと、デザイナーがWebツールで作成したHTMLを
プログラマは気が狂う思いをしてJSPに変換しなければならなかった。
もしくは、HTMLタグとJSPタグを理解しているデザイナーが必要だった。
何も知らないデザイナーがこれらを実用的なレベルまで理解するのには
数週間は掛かるだろう。

--- 習得の易しさ ---
それに比べ、Velocityの作者は言う。
「Velocityのテンプレート構文は、2?3時間でマスターできる」
これは大げさな表現ではない。

http://www.jajakarta.org/velocity/velocity-1.3.1/docs-ja/vtl-reference-guide.html

↑このページにある全てが、Velocityのテンプレート構文の全てである。
非常に単純な構文であることが理解できると思う。
単純ではあるが、マクロを使うことで拡張性のある言語にすることが可能だ。
そこら辺は使っていくうちに覚えていくだろうし
マクロを使えないからといってそれほど困ることも無いだろう。
僕の意見からすれば、マクロはプログラマが作成してデザイナーに提供すべきだと思う。
そうすれば、デザイナーはそのマクロの使い方を覚えるだけでいい。

デザイナーには、最初にほんの2?3時間掛けて
テンプレート構文を学んでもらえばいい。
これが2?3週間だったら、おそらく多くのデザイナーはこれを拒否するだろう。

--- 専門化 ---
この業界では、技術の専門化を進めるべきなのだ。
デザイナーがプログラムを覚える必要は無いし
プログラマがデザインを勉強する必要も無い。
そうした方が、より素晴しい物を作り上げる事が出来る。
この二つの能力がどちらも秀でた人など皆無に等しい。
分業なんて、他の分野では当り前のように行われている事なんだから。

だからって、プログラマに「金融」「Web系」などの
ジャンル分けをする必要は無い。そういうのは
企業側が単に即戦力を欲しがる為の言い分に過ぎない。

そこまでジャンルを限定したら、将来他の業務で
使いものにならなくなる恐れがある。
色んな分野に手を出すことは重要だ。
それによって多くの知識が身に付く。
そしてそれは他の分野のプログラムでもきっと役に立つ。

--- 導入のキッカケ ---
僕が今回Velocityに注目したのは、JSPを使っていて
その複雑さに疑問を感じたからだ。

現在公開しているLimywebで、日記のメイン画面を表示させて
その速度を計測していた時のこと。
たかだか30K程度のHTMLを出力するだけなのに
JSPの表示(だけ)に約300msも掛かっている。
これじゃPHPや何かと変わらんレベルだぞ。

おかしいな、と思いJSPから生成されたJavaファイルを見て僕は唖然とした。
そのJavaファイルは何と80K、1500行にも達する巨大ファイルだったのだ。

元のJSPはせいぜい300行程度だ。
しかしその中で多数の拡張JSPタグを使っている。
これが、今回Javaファイルをここまで肥大化させた要因に違いない。

--- 本末転倒 ---
何かの記事で、
「拡張JSPタグをたくさん使うとパフォーマンスが低下する」
と書いてあったが、正にその通りだったのだ。

高速化の為には、JSPタグの使用を控えろともその記事には書いてあった。
何ということでしょう。
これじゃまるで、高速化のために「ポイントを減らし、仮想メソッドは少なく」
という指摘がされている.NETの図式そのままじゃないか。

JSPからJavaコードを排除するために用意された拡張タグを
思うように使えないのでは、結局またJavaコードがJSPファイルに
散りばめられる結果となってしまう。
こんな本末転倒な話があっていいのだろうか。

--- 両立可能 ---
もちろん一般的に、処理速度とコードの綺麗さは
反比例するという事実は否定することが出来ない。

しかし、かつて遅かったJavaが高速化への道を辿ったように
高速化を達成しつつもシンプルなコードというのは
書けるはずなのだ。

それを目指しているのがVelocityだ。
そして素晴らしい事に、Velocityは確かにJSPよりも高速だった。
JSPで300ms掛かっていた処理をVelocity(VTL)で書き直したところ
その表示に掛かった時間は120msにまで短縮された。
もちろん、コード(正確に言えばリソース)は
JSPよりも遥かにシンプルだ。

--- 次回リリース情報 ---
次作のLimywebは全てVTLで書こうと思う。
JSPからVTLへの移行は非常に簡単だ。
ただし、既存のJSPでJavaコードを記述してないという
前提があれば、の話だけど。

簡単なAjaxも導入する予定なので
見た目的にも少し変わって使い勝手も良くするつもり。
完成までもうしばらくお待ちを。
…って、誰も待ってないかもしれないが(笑)。

なんか今週は珍しく外で飲みにいく機会が多かった。
まずはこの前日記に書いた現場ので一つ。

で、金曜は毎月恒例。会社の飲み会。
今月は結構女性参加者が多くて盛り上がってたみたい。
担当に新人の子が就いたんで
ちょっと雰囲気も変わった感じだった。
今までほとんど無かった2次会も10人以上参加してたし。

で、今日(もう日は明けたけど)。
最近mixiに登録して色々コミュニティを探してたら
「1977年前後のエンジニア」なるものがあったので
掲示板見てたら、正に今日飲み会をやるっていうんで
飛び入りで参加してきました。

あんまり濃いメンバーはいなかったので僕としては良かった。
オタク系の人種とはどうも気が合わないのだ。

それにしても、エンジニアっていうのは
あんまりお金持ってない人が多いのかな？
まぁベンチャー始めたばっかりの人とかだったらわかる気もするけど。
そういう人も何人か来ていて、結構大変だな?と思った。

今日なんか2次会までやって合計4100円だもんね。
しかも新宿で。ナイス幹事です(笑)。
みんな同年代なんで話もしやすかったし、
またあれば参加しようなんて思ってる次第であります。
っつーか酒が飲めればいいんだろ、俺は(笑)。

しまった?。
新しい環境にしてから、メールの設定を間違えていた。
受信はできるんだけど送信に失敗していたらしい。

家の場合、メール送信マシンは昔からあるRedhatマシンで
ドメインが「limy.org」。
新しいDebianマシンのドメインは「green.limy.org」に
設定していた。

で、Debianマシンからメールを送信するときは
RedhatマシンのSMTPを通じて行うようにしていた。
Debianではmewを使ってるので、~/.mew.el に

(setq mew-smtp-server <RedhatマシンのIPアドレス>)

と書いておいた。
ここまではOK。
ただし、このままではRedhatマシンがメール送信の依頼を受けたときに
「green.limy.org？そんなドメイン知らんぞ。スパムかも知れないから拒否しよう」
という事になってメールが送信されない。

--- qmail設定 ---
qmailの設定ファイル群は /var/qmail/control 以下にある。

http://man.qmail.jp/jman8/qmail-smtpd.html

↑ここに各設定ファイルの説明があるので参考に。
その中で rcpthosts というファイルが重要で
ここに「メールのFrom句に出現しても良いドメイン」を
登録しておく必要がある。

今回の場合では、ここに「green.limy.org」を登録しておけばいい。
ワイルドカードも使えるので

.limy.org

としておいた。こうすれば「.limy.org」で終わる全てのドメインが許可される。
将来もう一台ネットワークを追加したときにも設定ファイルの変更が必要ない。
で、設定ファイルを更新したらqmailを再起動。
svcコマンドを使う。

# svc -d /service/qmail
# svc -u /service/qmail

前者がDown(停止)コマンド。後者がUp(起動)コマンド。
これでOK。

--- 結局 ---
っつーか、よく考えたらメールのFromアドレスを
「limy.org」にしなければならないことに気づいた。
「green.limy.org」で送信できても
そのメールに返信されたらこっちが受け取れない。
外部に登録してるのは「limy.org」「www.limy.org」だけなのだ。
早くグローバルIPでも取得して
自宅DNSサーバ立てないとね。

今日は法事で実家の方に帰ってました。
なんか疲れる。大勢の親族と一緒にいただけなのに
妙な気苦労バリバリ。
普段は別に気遣う方じゃないんだけどね。

さて、現場の状況でも。
プロジェクトも縮小され、現在のメンバーは
僕とリーダー、それにスロー君の3名。

3人でギリギリ回っていたところで
リーダーが新婚旅行の為離脱。
それにしても随分長いこといないぞ。
先週丸々5日間、今日も休み。
一体いつになったら帰ってくるのかわからない。
それくらいメンバーに言ってから出掛けてほしいよ。

開発が出来るのは実質僕一人なので、
その他外部とのやりとりは全てスロー君が担当している。

--- 無理です ---
そしたら今日、とんでもない事件が起きた。
スロー君がメチャクチャな依頼を引き受けてきてしまったのだ。

データをCSV出力するっていう処理があるんだけど、
180万件、500MB近いCSV出力を30秒以内でやるとか言い出した。
こいつ正気か？
そんなの無理に決まってんじゃねーか。
コンピュータにも限度ってものがあるんだぜ。

「向こうがやれって言うんで…」
ダメだこりゃ。とりあえず最善の手を尽くして高速化に励むしかない。
最速に挑むためにはやはりPL/SQLか。
サンプル作るだけで8時間。デバッガが欲しいよ。

とりあえずサンプル完成。10万件程度で試してみた。
そこから推算したところ180万件で約1時間半は掛かる。
もう少し早くなると思ったけど。やっぱ無理だよ。

--- 大ピンチ？ ---
僕が一生懸命コードを書いている間、スロー君は
何をしてたかというと…何もしてない。
ボーッっとして、何から手を付けていいかわからないといった様子だ。
客と(この無茶な要求を何とかするために)交渉しろって言ったのに
全くやる気配が無い。

その割に、11時過ぎに帰った俺より遅くまで残ってるとは
一体どういう事だろうね。
どうせ残業のし過ぎて思考能力無くなってるんだろうから
さっさと帰りゃいいのに。

今日もスロー君は焦っている。
客との交渉を恐れているらしい。
それを証拠に、ほとんど席にいない。仕事してくれよ。
行動も大ざっぱになってきたし、そろそろ壊れるかもしれない。マジで。

たかが数週間リーダーがいない位でこれじゃねぇ。
彼は一生リーダーにはなれなそうだ。

--- 得意分野 ---
人にはそれぞれ得意分野がある。
リーダーに向いている人もいるし、そうでない人もいる。
リーダーになれない人が仕事出来ない人というわけではないし
リーダーだからって人間的に優れているわけでもない。

そういう事で上下を付けるのって本来おかしいでしょ。
リーダーがいなければ困るし、その下で働く人だっていなければ
もちろん困るわけで。

そういった偏った考えを持った輩が近くにいてね。
ホント、器の小さな人間だよ。概してこういうのに多いんだ。
国民全員が社長になったら経済が成り立たんぜ。

--- No.2 ---
ちなみに僕は、リーダーとか社長は向いてないと思っている。
チームの為とか、会社の為とか、そういう考えが全く無いんだよね。

結構好きなのは、No.2ってポジション。
一番責任を問われるのはトップの人間だし
グループに発言するには充分な権限もあるし。
もともと表に出るのは好きじゃないのだ。

No.1が好きじゃない性格っていうのは
色んな方面で出てくるかも。
携帯はDocomoじゃない。MicrosoftやOracleが嫌い。
他にも…まぁ色々と。

やっぱり、その世界でNo.1になる為には色々と○○な手段が必要なわけよ。
それを選んでまでトップを目指すか、自分の好きな事やってNo.2でいるか。
僕だったら迷わず後者。
No.1になったら人は幸せになれるの？僕はそうは思えない。

--- 久々の笑顔 ---
ようやくスロー君は客との交渉が済んだようだ。
ほっとしたようで、久々に笑い声が聞こえる。
やっぱ人間、笑顔が一番だよ。
その方が周りの皆も幸せになれるしね。

…と思ったら、また訳のわからん依頼を引き受けてしまったようだ。
どうせ向こうは何にもわかってない集団なんだから
やみくもに引き受けてたらキリないぜ。

明日にはリーダーが帰ってくるらしいので
それまで頑張ってくれれば
スロー君も倒れることは無さそうだ。

さて、現場では朝から早速バトル(？)が始まってます。
いつもの事とはいえ、この光景はなかなか見てて面白い。

新婚旅行から帰ってきたリーダーが
スロー君の進捗を確認しているが、
そのあまりの進まなさっぷりに呆れてものが言えないといった様子。
この2日間、ほとんど稼働してなかったからね。

--- 地元近く ---
今日は今僕らが開発しているソフトウェアの現地インストール作業をしに
宮原まで行ってきた。っつーか地元の近くだ。
そのまま実家に帰ろうかとも思ったが、
明日朝早く起きるのもつらいんでパス。
ガラガラの高崎線に乗って帰っていると…

新さいたま市で大量の人が乗り込んできた。
うおっ、襲撃か？
どうやらスーパーアリーナでライブがあったらしいね。
誰かは知らんけど。

僕が今やっているプロジェクトで痛感している事がある。
やはり、使う技術(言語やDBなど)の選択は大事だという事。

今のプロジェクトで使っている主な技術を挙げてみよう。

・ASP
・Oracle
・ODBC (Oracle)
・Java (J2ME)

この中で、間違った選択肢が3つある。最初の3つね。
ちなみに、僕がこのプロジェクトに放り込まれた時は
既に技術の選定はとっくに終わって
プログラムもほぼ完成していた(ただし大量のバグを残して)。

こんな事はしょっちゅうだ。
僕らはこういった状況の中で
苦しみながら開発を続けていかなくちゃいけない。
だから開発初期から関わりたいって言うんだよ。
そうすればこんな苦労せずに便利な技術を選択できるのに。

--- ASP ---
ASPとは、Microsoftが提供するWebサーバ。
ちなみに最近のリリースでは名称をASP.NETに変えて
多少はマシなものに仕上がったらしい(あくまで「多少」だと思うが)。
僕は後者の方を使ったことが無いので
これについてのコメントは差し控える。

で、ASP。
基本的にはVB(Visual Basic)をWeb用に改良したもの。
文法とかはほぼ同じだが、一部使えない構文もある。
そしてこれが、致命的な欠点となることを僕は知っている。

前にもちょっと話したけど、VBのエラー構文は非常におそまつで
・エラーが発生したら特定の行(ラベル)にジャンプする
・エラーが発生したら無視して次の行に進む
という2つの選択肢しか無い。

ちなみに、何の対処もしていないと
スクリプトエラーがWebブラウザに表示される。
ここら辺は他のWebサーバと同じ。

しかしASPではさらに限定され、1つめの選択肢が使えない。
これは、致命的と言え過ぎる位の致命的欠点だ。
※ これを反省して(？)、ASP.NETではTry?Catch構文などもあるらしい

ASPで開発者が取ることのできる選択は、

・スクリプトエラーの内容を直接Webブラウザに表示する
・スクリプトエラーを全て無視する

このどちらかしか無い。
結局、開発時は前者で進め
本番環境では後者に切り換えるというのが最善の策となるだろう。

本番環境でエラーが発生したら、開発者はその詳細を知る術が無い。
さらに恐しい事に、開発時からスクリプトエラーを無視することで
本番でも大量のエラーを無視したまま動いている
アプリケーションが多数存在する。

--- Oracle & ODBC ---
これが何故間違った選択肢だか判らない人もいるかもしれない。
確かにOracleは、単体ではそれほど酷い製品ではない。
しかし、他の製品と組み合わせたときに最悪の結果を出すように作られている。
なぜなら、そうすることによって
全てOracle製品の組み合せを売り付ける事が出来るからだ。

今回、ASPからOracleを使うためにODBCを使う必要があった。
この組み合せによって、一体何件のバグに悩まされた事だろう。
一体どれだけの時間を無駄に費しただろう。
この選択肢がどれほど酷い結果を生むかは、経験した人間にしかわからない。

間違った技術を選択してしまうと
アプリケーションの質の低下、バグ修正の為に必要な工数の増加、
仕様修正に掛かる費用の増加、そして何より
開発者達のモチベーションの低下(笑)。
様々なデメリットがある。

こういう事を考えてこそ、真の設計者と言えるだろう。
僕は今までにそういう人を見たことが無い。

女子フィギュアの村主さんがエイベックスに入ったらしい。
前の会社が色々あって移転先を探してたことは知ってたけど
ここに入ったとはちょっと意外だね。

今後メディアへの露出が増えることになる。
これでちょっとは注目されてくると嬉しいね。

でもなぁ。
この流れは、引退してから芸能活動に移転するって事？
彼女は絶対プロになってもフィギュア続けると思ってたのに。
その想いが急に変わったとも思えないし。
とりあえず、今後の動向には注目。

--- 真面目過ぎ ---
さて、毎回恒例(笑)。スロー君のコーナーです。

今日のスロー君。
何やら悩んでいる。「REAL考える人」と命名しよう(今だけ)。

なぜ彼がこんなに仕事が遅いかというと。
単純に作業が遅いという事もあるんだけど
それ以上に「必要無い事まで丁寧にやり過ぎる」という点がある。

例えば、「この文書チェックしといて」と言われたら
普通の人はまぁサラサラっと目を通して終わりだろう。
それを彼は、一字一句読み砕いて自分の納得いくまでやろうとする。
だから時間が掛かるのだ。

--- 時間との闘い ---
もちろん、それ自体は良い事だけど
プロとしてはそれ以上に重要な事がある。
「期限を守る」ことだ。
仕事で人に物を頼むとき、期限を言わない奴ってのはもはや論外だね。

人間の能力には限界がある。
自分がどの程度の時間でどの程度の作業をこなせるかという事は
知っている必要がある。
自分の下にメンバーがいれば、彼(彼女)らの仕事量も合わせて。
これは実践経験を積んで学んでいく事だ。

それを加味した上で、時間内に終わらせるためには
ある程度やる事を限定しなければならない。

これを手抜きと呼ぶ人もいるかもしれない。
しかし、そういう人はほぼその仕事を達成できない。
どれだけ丁寧にやったって、どれだけ時間を使ったって
完璧なんて事は有り得ないのだから。
少ない時間で、より正確な作業をするというのが
最も現実的な回答なのだ。

--- 僕たちの選択 ---
そして、僕らにはさらに良い回答がある。
「正確な作業をするためにコンピュータを使う」ことだ。

そう、そのためにコンピュータがあるのだ。
「自分の時間を使う代わりに、コンピュータに時間を使わせよう」

Time is money.

より速く。より正確に。
こんなとき、コンピュータの存在は頼もしい。
僕らの手足となって働き、僕らに自由な時間を与えてくれる。

あぁ、また現場の携帯が鳴っている。
が、当の本人はどこかへ行っているため延々と鳴り続ける。
こんな光景はしょっちゅうだ。

こういう奴は一体、何を考えているのか。
もしかしたら、自分がいないときに携帯が鳴り響いている事すら
気にしてないんじゃないか？何たる無神経さ。

席に置きっぱなしにするんだったら
会社の内線使っても同じだろ。
携帯電話なんだから、ちゃんと携帯してほしいもんである。
っつーかしろ。

--- 怒りモード？ ---
なんか今日はそうらしい(笑)。
喫煙室から出てきた奴が近づいてくるだけで
こっちは大迷惑。

それが隣の席でも座ろうもんなら、もう最悪。
喫煙室から出てきたら、こっちに来る前に消臭スプレーでも
掛けといてほしい。

--- 毎度恒例、のはずが… ---
さて、「今日のスロー君」コーナーにでも行こうかな。
と思ったんだけど、今日はあいにくネタが無い。

ただ、今後はリーダーがこの案件に関わる時間が減ってくるらしいので
スロー君の負担が増えるらしい。
まぁおそらくは見かねたリーダーが手を差し延べるんだろうけど。
席も隣同士だし。

--- のんびりモード ---
現場では今後のスケジュールが発表され、
来週末くらいまではのんびりと過ごせそうだ。
致命的なバグ報告でも無い限りね。

たまにはこういうのんびりした時間を過ごすのもいいもんだ。
以前だったら暇なのは嫌だったけど。

なんか周りでやたらと風邪ひいてる人が多い。
流行ってんのかな？

--- 原因不明 ---
なんか今日はうちのサーバ(limy.org)が激重になってる。
外部からじゃ大した原因もわからないからなぁ。
多分ネットワークの問題だとは思うけど。
またルータ再起動する必要ありかな。

このルータ、一定期間が経つとこういう現象が起こるんだよね。
過去にも何回かあったんだけど。
そろそろルータも買い替えようか。

さて、唐突に始まりました。
題して「今日飲んだ酒紹介」。
…完全に飲んだくれ日記ですな、こりゃ(笑)。
ほぼ毎日飲んでるんですが、気が向いたら書くことにします。はい。
日が明けちゃったんで、以下は金曜夜の出来事です。

今日は珍しくサワーを買ってきた。
Takaraの「果実きわだつチューハイ(グレープフルーツ)」。
CMでもやってるやつね。でもやっぱ不味い。
何でグレープフループがこんなに甘いんだよ。

今まで僕が美味いと思った缶チューハイは
メルシャンの「本搾りチューハイ(レモン)」だけ。
あれはさっぱりしてていいね。
焼酎を使わずにウオッカだけで作ってるらしい。
他のは甘すぎて好きじゃない。だから飲まない。

焼酎も買う。
本格焼酎って書いてあるけどホントか？
もしホントだったらフルボトルで1000円切ってるのはおかしいよな。
コンビニの焼酎ってのはどれも同じような味だ。

やっぱ酒屋で買わないと駄目だね。
コンビニにはロクな酒が置いていない。
飲めるのはビールくらいだよ。
セブンイレブンではワインも色々置いてるけど
今いち気に入ったのが無い。
田崎真也セレクションらしいが。

--- 雨の外出 ---
で、土曜は友達と渋谷で飲み。ホント飲んでばっかだな(笑)。
なぜか僕が出掛けるときはいつも雨。
西武デパートの近くで待っていると、何となく知った顔発見。
おそらく一緒の現場の人。
ただ、フロアは一緒だけどチームが全然違うから
「顔は知ってる」程度。
向こうが気付いてなさそうだったので特に声掛けたりはしなかった。

1軒目は韓国料理屋。
「食」メインの場所に行くことはあまり無いんだけど、
たまにはこういうのもいいかな。
牛スジは美味かった。

2軒目はセンター街沿いにあるどこぞのバー。
正直、かなり○○だった。
いや、別に店を紹介してくれた君を攻めてるわけじゃないぜ(笑)。
ジン・リッキーとギムレットを飲む。
あまりにもアレだったんですぐに店を出て次の店を探す。

適当に歩いていると、まぁまぁそうなバーを発見。
ボストン・クーラーとサイドカーを飲む。
まぁ値段相応の味かな。結構安かったからね。

というわけで、久々の渋谷は多少不完全燃焼のまま終了。
再来週はメンバー一人増やしてリベンジだぁ！
あ、でも次は新宿がいいな(笑)。

なんか寒いね?。
暖房でもつけたいくらい。

まぁいいや、とりあえず今日の酒コーナー(笑)。
この前コンビニで買ってきた芋焼酎、その名も「芋ばなし」。
どうやらコンビニ限定商品らしいね。
味は今いち。まぁ安いからこんなもんか。
水割りとロックで適当に飲む。

今日は酒屋でワインと焼酎を買ってみた。
さらに通販で大量に買い込んだので
しばらくはコンビニで酒買う必要も無さそうだ。

まだLinux環境でデジカメの画像が読み込めないので
そろそろ使えるようにしたいなぁ。
やっぱ酒の画像あった方がわかりやすいもんね。
とりあえず、もう少し待っててくれ。

風邪が大流行しているらしい。
現場でもスロー君が休み、ショージ君は午前休。

僕はとりあえず大丈夫、今のところ。
周りからうつされる可能性はあるけど。

なんか今日は朝の電車がメチャクチャに混んでる。
あまりにも混んでたので、一本待って乗ったけど
それでも相当きつい。
たまにこういう日ってあるよね。

--- 蔓延中 ---
やばい。現場では風邪菌が充満してる。
このままじゃうつされそうだ。

スロー君は出勤してきた。
結構元気そうだから、昨日は多分サボリだな。
作りかけの資料が終わりそうにもなかったから
後輩に任せて逃げようとしたんだろうけど
結局資料提出は今日に延期されたから今ごろがっかりしてるんだろう。
案の定、資料のレビューはボロボロだった。

--- 続・考える人 ---
今日もスロー君はひたすら考え事をしている。
しかし、ショージ君は別のプロジェクトに関わ始めたので
もう助けてくれる人がいない。

僕がその役目をしてもいいんだけどね。
それやってばっかだとスロー君のためにもならないから
いざという時まで手は貸さないようにショージ君からも言われてる。

--- もう到着 ---
帰宅後、珍しく料理。
っていっても、インスタントの担々麺茹でて
ニラもやしのパックを炒めて入れただけという…
「自炊」とはとても言えんな。

でもこの担々麺、少々高価だっただけあって美味い。
ちょっとした中華屋のランチで出てくる位のスープの味。
「名古屋錦城 四川担々麺」。最近のお気に入りです。

で、その料理中。我が家に宅配が届いた。
以前注文してた酒である。
結構早いね。一昨日の夕方頼んでたのにもう来るとは。

今回は、以前まで愛用してた店とは別の店にした。
以前までの店はなんか急激に値上げしててね。
今回利用したのは、「ALAK.JP」という洋酒専門業者。
品揃えもまぁまぁで、値段は結構安い。
1万円以上で送料無料だし、1万5千以上で代引手数料無料だし。
前のとこより全然いいぞ。

--- 早速、と思いきや… ---
さて、こうなったらもう飲むしかないな(笑)。
…と思ったけど、まずは先日買ったワインを空けるのが先か。
シャトー・ノエル・サン・ローランという赤ワイン。
結構薄味(？)な感じだね。個人的にはちょっと物足りないなぁ。