Mavenはビルドに適したツールか？

http://www.infoq.com/jp/news/2008/02/maven-debate

僕はまだ、ビルドにMavenを使っていない。
多くの人が、Mavenに対する賛美と批判の声を送っている。
それを使うかどうかは、君次第だ。

とりあえずメモ。
jaxenのサロゲート判定にバグがある。
今回見たのは、最新版の1.1.1。

org.jaxen.function.StringLengthFunction
を見ると、140行目あたりに
　　　　if (c >= 0xD800) {
とある。これは上位サロゲートを判定するものなのだが
正確には以下のようにしなければならない。
　　　　if (c >= 0xD800 && c <= 0xDBFF) {
これでうまくいく。

ちなみに今回これが発覚したのは、jaxanを使ってるPMDで
バグ報告を受けたから。
日本語名の変数を使ってるときに、パーサが日本語を
違法サロゲートだと誤判定してエラーになってしまう。

例えば「Ｄ」の文字はUnicodeで0xff24なので
　　　　if (c >= 0xD800) {
に引っかかってしまい次の文字が下位サロゲート(DC00?DFFF)じゃないと
「サロゲート違反だよ」ということでエラーになる。
にしても、下位サロゲートの処理は正しいのに
なんで上位サロゲートの処理だけ間違っているのか。

http://www.limy.org/program/articles/

ここに修正版の jaxen-1-1-1.jar を置いといた。
いずれjaxenにバグ報告しとかなきゃならないが
どうやらしばらく開発が止まってる様子。
再開してからにしよう。

久しぶりに家でプログラムに苦戦中。
今悩んでるのは、Apache - Tomcat 経由でURLを書き換える方法。
要するに…

http://www.limy.org/context/XXX/YYY

みたいなアドレスを

http://www.limy.org/context/id=XXX&value=YYY

のように置き換える。
Apacheだけだったら mod_rewrite 使えば一発。

ただ Tomcat 経由だと話が厄介になる。
もともと

http://www.limy.org/context/id=XXX&value=YYY

というApacheへのアクセスを

http://www.limy.org:8080/context/id=XXX&value=YYY

っていうTomcatのポートに繋いでいる(正確にはajpというコネクタを使用)
ので、mod_rewrite による書き換えはうまくいかない。
mod_proxy_jsp と mod_proxy_balancer を使ってやる方法がどっかのサイトに載ってたので
試してみたらうまくいって喜んでいたんだけど、
なぜかFirefox以外のブラウザから見ると失敗する。
全然糸口が見当たらないので別の方法を探すことにした。

Url Rewrite Filter っていうTomcat上で動くフィルタを発見。
これならうまくいくはずなのだが、今苦戦中。
とりあえず時間がないので今日はここまで。
残りは明日…あぁ、もっと先だな。また今度にしよう。

今日はTopCoderのCompetitionに初チャレンジ。
お題が3問出題されて、なるべく速い時間で解いた方が得点が高くなる。
が、回答が間違えていると得点は0。
だから確実に正解してることを確認してからSubmit(投稿)しなくちゃならない。

過去問題を何問か見てたけど、今回のはそれよりちょっと難し目だった。
1問目はすんなり解けたものの、2問目で苦戦。
ようやく解けたんだけ、うっかりミスがあって結局得点は0。
3問目にいたっては回答すらできなかった…
やっぱアルゴリズム問題っていうのは難しいね。

まぁ何はともあれ、これは面白い。
時間に追われながらコード書くのは精神的にちょっと辛いけど
それを上回る楽しさがある。
Competitionは毎週開催されるらしいから、これらも続けようっと。

僕がコードを書くときに、常に意識しているルールがある。
それが、30秒ルール。
確かJavaの偉い人(名前忘れた)が言っていた言葉で、
Javaのメソッド(処理の最小単位)はそれを見て30秒で何をしているのかが
わからなければ駄目だという理論だ(10秒だったかも…)。

わかりやすく書くなんてのは、現場でコードを書くときには基本的な考え方。
これに反して、1時間読んでもそれが何をしているのかが
全く掴めないコードもある。
こういったコードは本来すぐにでもゴミ箱に捨ててこの世から葬ってあげたいところだが
そうはいかないのが現実だったりする。

--- 読めないドキュメント ---
同じように、ドキュメントにも僕は30秒ルールを適用することにしている。
何が言いたいんだかわからないドキュメントに、僕は何度も遭遇して困っているからだ。
これは僕の理解力が足りないんじゃない。
コードに関してもそうだけど、僕は読解力は割とある方だと思っている。

ということは、そのドキュメントがただ読みにくいというだけだ。
多分、こういう文章を書く人というのは作文能力が不足しているんだと思う。
しかし、どこかの記事にもあったようにプログラマの中で
きちんとした文章を書ける人というのは世界的に見ても割合が少ないそうだ。

これは困った。そんな人達が書いたドキュメントを読んで
僕らは作業しなきゃいけないのか。
SE、コンサル、目指す前にまず、わかりやすい日本語で文章を書く練習をした方がいい。
あと、物事をまとめられる力ね。
毎日日記を書くだけでも大分上達するはずだ。

そろそろ家のサーバも新しくしようと思い、
以前「Linuxクライアント化計画」の為に買ったPCを使うことにした。
LinuxのGUIは正直まだまだWindowsの足元にも及ばないというのが今の結論。
サーバはLinux、クライアントはWindowsでいくのが
一番妥当な選択だと思う。

とりあえずOSはLFSにしてみた。最新の6.2。
FTP、SSH、Sambaはただ入れるだけ。
Apache、Tomcatも何なく移行に成功。

--- Courier-Imap ---
つまづいたのがメールサーバ。
今回はImapサーバを導入しようと思い、qmailとの連携が良さそうなCourierに決定。
qmailのインストールは何度もやってるので簡単に終わるが、
予想通り(？)Courier-Imapの認証でハマる。
インストール直後はshadowからのパスワード認証に成功してたのに
その後色々やってたらこれが失敗するようになってしまった。

仕方無いので、別ファイルで認証ファイルを作ることにする。
まずはshadowファイルから設定ファイルを作成。

% /usr/local/sbin/pw2userdb | grep -e "^mailuser" > /usr/local/etc/authlib/userdb

mailuser ってのは、Linuxのユーザ名ね。
こうすると、shadowファイルからパスワードを引っ張ってきて
authlib用の設定ファイルを作ってくれる。
結果はこんな感じになる。

mailuser uid=1007|gid=1008|home=/home/mailuser|systempw=$...

あとはこの設定ファイルからバイナリデータを作成…
とその前に、なぜかうちの環境ではユーザ名にドメインを付けなければ動かなかったので
こんな感じで修正。

mailuser@limy.org uid=1007|gid=1008|home=/home/mailuser|systempw=$...

そしたらコマンドを実行。

% /usr/local/sbin/makeuserdb

これで、/usr/local/etc/authlib/userdb.dat というファイルが作成される。
これが認証時に使われ、無事認証が確実に成功するようになりました。

--- コンテンツにしない理由 ---
こういう情報はコンテンツとして起こしておけって話もあるんだけど
なかなかそれが難しい。
いつも試行錯誤しながら正解にたどり付くから、
それをコンテンツとしてまとめるのは大変なのだ。

だからこうやって日記の形でずらずら書くことにしている。
とりあえずこれでも検索エンジンには引っ掛かるからね。

--- IMap ---
やっぱりIMapサーバは便利だ。
僕はいつも複数の環境でメールを使うから
メールがサーバに保持されるIMapサーバは役に立つ。

これで今後、半永久的にメールを保管しておくことが出来るし
環境を変えたときにも以前のメールを破棄することなく
簡単に取り込むことが可能になった。
Courierの動作についてはまだまだよくわからない事も多いので
ある程度わかってきたらコンテンツとして公開しよう…かな。

最近はまぁまぁ仕事がある。
今やってるのは、うちで開発してるiアプリをWebで焼き直そうというもの。
とりあえず仕様はざっとしか決まってないんで
プロトタイプ的なものを作ればいいという気楽なお題。
僕一人の作業なんでさらに気が楽だ。

で、今日一通り形になったのでリーダーに見せてみた。
「おぉ?」って感心してくれてるのは喜ばしいことだけど、
厳しい言い方をすればその程度で喜んでるようだからまだまだなんだ。

--- 作るのは初歩 ---
物をただ作るなんてのは、言ってみれば初歩の初歩。
誰でも出来るとまでは言わないまでも、とりあえず最低限のレベル。
問題はここからなのだ。

バグの出ないようなシステムにしなきゃいけないし、
ユーザの突拍子も無い行動や不正アクセス、
そして雨あられと降り続いてくる仕様変更。
こういうものをスパッと片付けられる作りになっていて
初めて褒められたシステムと言えるんじゃないだろうか。
もちろん、出来る限り短期間でね。

--- 外側と内側 ---
よく言われるのが、外側の小さな修正は
内側の小さな修正に留めなければいけないという事。
システム内部を何も知らない人間が「これ簡単でしょ」と言えるような変更で
内部を大幅に修正しなければならない事態は避けなければいけない。

これが出来てないシステムは、世の中に山のようにある。
根本の原因は、変更に対応できる作りにしていない事。
例えば、消費税の5％をハードコードしてるような人達は
世の中の仕組みを全くわかってないって事だ。
システムの大部分は、変えられる事を想定して作らなければならない。

--- 今後 ---
これが出来るようになるとどうなるか。
世の中にはもっと便利で使いやすいシステムやWebサイトが増えていく。

現状、便利なシステムにはおそらく相当の額をつぎ込んで作り上げている。
でもこれからはそうじゃいけない。
少ない投資で、もっと便利なものが作り出せたら
もっと多くの人達がITに目を向けるようになる。

僕は敢えて、その答えを最近流行りのフレームワークだとは言わない。
どんなに便利なフレームワークが出てきても
それを使う側のスキルが向上しない限り、彼らの意識が変わらない限り
システムの質は向上しない。

答えは簡単だと思う。
物を作る。それに全力で取り組んでみろって事だ。
中途半端な人達が多い。
物は作りたい。サービスは提供したい。
コンサルタントはしたい。金は稼ぎたい。

結局、どれも身に付かずに10年後には路頭に迷うことになるよ。
誰にも負けない自分の得意な事を見付けた方が、最後には得すると思うけどね。

新しくシステムを作る場合、まず何の言語で作るかという事は大きなテーマです。
それは客の要望であったり、作る側の希望であったりと
色々あるわけですが、どんな基準で選択すればいいのかって事をちょっと考えてみます…暇なので(笑)。

まずいきなりテーマをぶち壊しそうで何なんですが、
「言語を一つに決める」という事自体が、そもそもの失敗であるという事があります。
言語には、適材適所というものがあるのです。
一つのシステムを、全て一つの言語で統一してやる必要はありません。
昔とは違い、今は言語同士の連携がしやすいようになってるんですから。

まぁそれは置いといて。
例えば、Webアプリを作りたいとしましょう。
現在で主な選択肢と言えば、Java / PHP / Rails / Flash のような感じでしょうか。
まぁこの中のどれかが一般的でしょう。

--- 選択方法 ---
よく、生産性がどうのとかいう理由で言語を選びたがる人がいますが
実際にはそれは全くのナンセンスです。
生産性は、言語で決まるのではなく「開発者がどれだけその言語での経験があるか」
で決まるのです。

確かに Rails の生産性はかなり高いとは思いますが(記事などを読んだ印象では)、
それが全ての技術者に当てはまるわけではありません。
まだ何の言語も知らない人を集め、一から学んでもらうことを考えたら
おそらく Rails が一番早くWebアプリを完成させられるでしょう。

しかし、実際にはそうではないはずです。
既に開発者はいくつかの言語を使った経験があるでしょうから
「プロジェクトに関わるメンバーが最も得意な言語」というのが
最良の選択肢となるのです。
それ故、まだメンバーが決まっていないような場合
経験者の数が多い言語(例えばPHP)が必然的に選ばれることになります。

--- マルチリンガルの必要性 ---
僕は最近ほとんどJavaの現場でばかり働いていますが
それしかやってない訳ではありません。
例えば前の現場ではASPも使っていたし、今の現場では
PerlやPL/SQLも書いています。
そして、どの現場でも共通して使う言語に Ruby があります。

言語が変わったからって、別に大したことはありません。
色んな言語を学んでいけば、「プログラムの書き方」というものが身に付いていきます。
これはどの言語でも通用する普遍的なスキルです。
一つの言語しか使えないという人は、一度他の言語も学んでみることをお勧めします。
そうすることで、あなたのスキルはぐっと上がるはずです。
そこから新たなヒントが発見できるかもしれません。

さて、この日記をしょっちゅう読んでいる方ならご存知かとは思いますが
これは言わずと知れたOracleの事です。
「あぁまたかよ」と思った方、そう言わずにつき合って下さいな(笑)。

Oracle はDBサーバの枠を超え、ありとあらゆる機能を提供しようとしています。
いずれこの会社が Oracle OS を発売したとしても何の不思議も無いのです。

なぜ、Oracle がこのような多機能アプリケーションになったのか。
向こうの言い分としては「全てが統合されていることでシステム開発がより効率的になる」
というような感じでしょうか。
しかし、これはちょっと信じ難い言葉です。全てが統合されたからといって
必ずしも開発の効率は上がらないのです。
逆にほとんど100％の確率で開発効率を落としている事に皆、気付いていないだけなのです。

ではなぜ気付かないのでしょうか？
それは、他のものを使ったことが無いからです。
比べる対象が無ければ、非効率だと気付く余地がありません。
または、データベースというものが本質的に何なのかを理解していません。
「おそらくこんなもんなんだろう」という程度の意識しか無いのでしょう。

「別にそんな事言われても、Oracleを使ってうちは幸せな開発をしているよ」
という人には、僕は何も言うことはありません。
でも、もしそうじゃない考えを持った人がいるならば
あなたにはまだOracleを捨てる選択肢があるのです。

現在、ほとんどの企業ではデータベースに Oracle を採用しています。
しかし、その理由を彼／彼女たちに尋ねたら一体どんな答えが返ってくるでしょうか。

「いや、特に理由は…」
「客がOracleじゃないと駄目だって言うから…」
「他に使ったこと無いから…」

そう、別に誰も Oracle に固執しようとは思っていないのです。
僕はまだ、Oracleのメリットを適切に説明できるような人に会ったことがありません。

--- 全てを提供する事 ---
先程も話したように、Oracleはこの製品でシステムの全てを提供しようとしています。
例えば Oracle10g にはWindowsのタスク、UnixのCronと同じような機能を持つ
「スケジューラ」という機能があります。
これを使えば、毎日決まった時間に特定のSQLを実行させる事などが可能になります。

これを知ったITアーキテクト達はこう思うのです。
「よし、次のプロジェクトではOracle10でスケジューラを使おう」
そして開発は始まり、スケジューラも無事動きました。

ある時、「スケジューラの実行が失敗したときに、管理者充てにメールを送信したい」
という要望が客から出てきました。

さて、どうしましょう。スケジューラにはそんな機能はありません。
結局開発者が取った行動は、Cronを使った従来の方式で作り直すというものでした。
こうなるんだったら、最初からスケジューラを使わなければ良かったのに。
もっと言えば、このプロジェクトで Oracle を採用したメリットがあったでしょうか？
他のDBを使っていれば、かなりの予算を節約できた上に
開発効率もずっと上がったはずです。

確かにOracleは様々な機能を実装していて魅力的かもしれませんが
それは決して客の全ての要望を満たすまでには至っていません。
そしてそれは当たり前の事なのです。
人間の要望は、一つのシステムでは到底達成できないほどに膨れ上がってくるのですから。

だとしたら、僕達の取る行動は何でしょう？
そんなものに任せず、自分達で機能を実現することです。
その為に僕達がいるのです。
Oracleが全てを実現できるようなら、プログラマの存在価値なんてあるでしょうか？

もう一つの方法は、特定の機能に特化した製品を組み合わせて使うことです。
これが、ほとんどの場合において最適な選択肢となります。
製品に達成できない機能が出てきたら、自分達で作ればいいのです。
その為には、多機能アプリケーションを切り捨てる必要があります。
これらは外部システムとの協調など、何一つ考えていないのですから。

--- 柔軟な対応 ---
ちょっと話を変えて。
上の例で、こうなってしまった原因を考えてみます。

「ITアーキテクトの決断が誤っていた」と誰かが言うでしょう。
しかし彼はこう言うのです。
「メールを送信するなんて、設計の段階では一言も言ってなかったじゃないか」
確かにそれも一理あります。

一番大事なのは「システムの変更には柔軟に対応できなければならない」という事です。
今回の例は、客の我侭でも何でもありません。
こういった事は、よくある事であり避けられない事なのです。

「実際にシステムを構築しない限り、そのシステムを理解する事は絶対に出来ない」

システムを作りもしないで、設計の段階で全てを決定する事など
人間にはもはや不可能なのです。それが、システム開発の現実だと知っておきましょう。
ですから開発者には、システム製作中に発生する様々な要求を随時受け止め
実装していくための力が必要なのです。

もちろん、「設計の段階である程度を決めておかなければ発注もできない」
という立場の人もいるでしょう。
そのやり方を否定するつもりはありません。
しかし、その最初の決定を全てにおいて正だとする考え方はやめてほしいのです。
家とソフトウェアは、同じ方法では作れないのです。

ソフトウェアの初期設計はあくまで初期設計であり、それで完成ではありません。
システムを構築していく段階で様々な要因によって
設計は常に変化していきます。

それを認められないような古い体質の企業は、
おそらくシステム開発で多大な額の損失が出ています。
それを続けていたら、何年後かには大勢をリストラする羽目になるでしょう。
あなたの会社は、大丈夫ですか？

ちょっと今回はプログラム寄りの話。
開発の仕事に携わったことのある人なら、XMLという言葉くらいは聞いたことあると思う。
XMLっていうのは簡単に言えばツリー構造のテキストフォーマットの事。

  <root>
    <child>
      ...
    </child>
  </root>

まぁこんな感じの。
HTMLも似たようなもんです(正確に言えばHTMLはXMLではない)。

たかが一種のテキストフォーマットが何故そんなに流行っているかよくわからないけど
彼らに言わせれば、XMLは「魔法の箱」なんだそうだ。
SOAのWebサービスなんかもそう。

今やXMLはありとあらゆる場面で使われている。
しかし、それが本当に最良の選択肢だとは到底言い難い場所でも使われているのだ。
例えばJSP。これはHTMLを動的に作成するための技術で
多くの場所で使われている。
JSPも正確に言えばXMLでは無いんだけど、とりあえず今回は例という事で紹介する。

  <html>
    <body>
      <div>Title</div>
      <c:out value="${subject}" />
    </body>
  </html>

こんな感じで、HTMLの中に独自タグを埋め込んでいく。
c:out という見慣れないタグがあるが、これがその独自タグ。
これがJSP内にあると、JSPコンパイラはそこからJavaコードを実行して
動的なHTML生成を可能にするという訳だ。

では次に、JSPの中にif文を埋め込んでみよう。

  <c:if test="$count % 5 == 0">
    count は5で割り切れます。
  </c:if>

count という変数を参照して、それが5で割り切れるかを判定して文言を表示させるという
簡単なロジック。
さて、ここからが問題。同じようにして今度はif?else文を埋め込んでみる。

  <c:if test="$count % 5 == 0">
    count は5で割り切れます。
  </c:if>
  <c:if test="$count % 5 != 0">
    count は5で割り切れません。
  </c:if>

elseは使わず、ifブロックを二つ並べている。
そう、XMLではif?elseという極めて単純なブロックさえも表現できないのだ。
XMLでロジックを表現することがいかに無謀かという事は、他にも山ほど実感できる。

XMLが持てる状態は、
・ルート要素
・属性
・その子要素
たったこれだけだ。
ツリー構造を持ったデータ格納先として使う程度で充分だろう。
XMLにデータを扱う以上のことはさせるべきでは無い。

XMLでロジックを記述するなんて、割り箸を組み合せて棚を作るようなもんだ。
そんな苦労をしなくても、棚を作る方法はいくらでもある。
物事を実現するために最適なものを選択して使うスキルが、今の技術者には欠けている。
「流行ってるから使おう」とか「これしか知らないから仕方無くこれ使おう」じゃダメなのだ。
自分で良いものを見極める力を身に付けることが大事だね。