ctagsメモ

Webで検索すると、ctrl - ] と ctrl - t は紹介されていますが、:ts はあまり出てないですね。

ctrl - ] では、とにかく同名の関数に飛んでくれますが、Javaでオーバー（ロード｜ライド）しまくっていると目的の場所に届かないことがままあります。そんなときに :ts です。

:ts とすると関数の候補が出ます。行きたい関数の数字を打てばOK。

eclipse だと結構探してくれますが、ctags では自分で候補を探す必要があります。（eclipseも完ぺきではないので、候補を自分で探す方が結果的に早いということもあります）

以上

はじめに（プロジェクトの人間学）

※　この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。

はじめに
システム構築プロジェクトに関係するステークホルダーには３つある。
ひとつは顧客である。プロジェクトの品質を要求し、正しいプロジェクト運営を求める。
もうひとつはマネジメントである。技術的なことはほとんど分からないのだが（それゆえにこそ顧客とマネジメントが対等なのであるが）プロジェクトを管理しようとする。
もうひとつは現場である。「マネジメントではない」存在として定義されたメンバーで構成されている。

前者二つは「こうであるべきだ！」「こうでないのはおかしい！」と声高に叫ぶ。そして管理という名の雑用を増やし、プロジェクトの混乱を促進する。現場はコンピュータが産む理不尽なトラブルと、マネジメントならびに顧客からの要求に耐え、絶望的に、だが粛々と作業を進める。「だったらお前がやってみろ」という呪いの言葉を飲み込んで。

筆者は現場の人間である。現場の視点からいくつかプロジェクトに関する本を読み、ほとんどすべてに対して「ウソだろ？」と顔をしかめてきた。デマルコなど一部を除いて。世のプロジェクト本は、それぞれの著者の脳内プロジェクトシミュレーションを扱っているに過ぎなかった。生きたプロジェクトを扱っている本はどこにもないように思えた。

現実のプロジェクトを対象にしたものでも、やたらと数値化を利用してプロジェクトを分析いる。だが大抵の場合は脳内のプロジェクトモデルにデータを寄り添わせるために数値を利用したに過ぎなかった。その計測方法も欲しいデータを得るために恣意的な切り口で計測したものが多かったように思う。つまりは自らのプロジェクト観を補強するために数字をもてあそんでいるに過ぎない。

あるいは中には無用にプロジェクトの悲惨さを訴えるものがある。悲惨さをユーモアとするにしても、戯画化されすぎていて、中途半端である。別の本では著者の方法論があまりに完璧なので、注意して管理すればプロジェクトの失敗などありえない、と述べる。また別の本では訳の分からないプロジェクト進捗（リスク）定量化ソフトウェアを使え、と言ってくる。どれもこれも全く生のプロジェクトを扱っていない。

筆者は現場で働きながらプロジェクトを扱った本を読み「プロジェクトを一度現場の視点で定義しなおす必要があるんじゃないの」とぶつぶつと考えてきた。考えた結果がこの本である。中にはマネジメント層や顧客層からは容認しがたい記述があるに違いない。しかし、これは偽らざる現場感覚である。ソフトウェア工学でプロジェクトを計測し、評価した結果が真実であると主張するのと、同じ権利を持って真実と主張できると筆者は自負している。

マネジメント層や顧客に訴える書籍が多いのはある意味で当然である。何故なら彼らには金があるから。彼らに気に入る理論でなければお金儲けは難しいに違いない。教授たちやコンサルタントがプロジェクトをサンプリングし、数値化、分析する。そして「プロジェクトはこうあるべきなんです」とマネジメントや顧客に訴える。それもよかろう。しかし、筆者は現場の人間である。敢えて現場から見たプロジェクトの真実を書きたい。

この著作がほんの少しでも現場エンジニアの喝采を浴びることができたら、筆者にとってはこれほどうれしいことはない。

では早速だが、まずプロジェクトを二元論的な観点から見てゆこう。

崖の上のポニョ（宮崎駿インタビュー）

昨夜ＮＨＫの番組で宮崎駿インタビューを見ました。

宮崎監督がイメージボードだか絵コンテを書きながら「子供たちにこの映画を通して生きていてもいいんだ、ということを伝えたいんだ」（正確ではない）とブツブツ言っていたシーンが凄みがありました。

言葉にしてしまうとありきたりですが、彼のつぶやきには彼の人生や、トラウマがしっかりと刻み込まれていました。それがこの言葉にただならぬ重さを与えていた気がします。

他には「僕は映画の奴隷だよ」という言葉も印象に残りました。

仕事や会社の奴隷なら普通にいますが、そうではありません。映画が「もっとできる。もっと凄いものが作れる」と彼を駆り立てるのでしょう。

夏目漱石の夢十夜だったか、木から仏像を作るのではない。仏が木に埋まっているのを掘り出すんだ、という話があったかと思います。
その人が頭で作るのではなく、その人にしか見えない何かがあって、その何かが人を動かすのです。芸術には芸術家を超えた何かがあるということなのでしょう。

しかし、宮崎監督の話は面白いですね。ポニョを見るのが楽しみです。

JavaMail は5年遅れている

このブログにしてはなかなかキャッチーなタイトルです。

JavaMailは現在バージョン1.4。1.1のリリースから10年近く経ちますが、本質的な機能は変わっていません。

つまり（かなりアクロバティックな展開ですが）JavaMailの本質は10年ほど変化していないのです。

言い換えると、

１．JavaMail 1.1 のリリースが10年近く前

２．JavaMail 1.4 と 1.1 の機能は本質的には変わっていない

３．ゆえに JavaMail 1.4 の機能は本質的には10年ほど変わっていない

すばらしく乱暴な展開ですが、私は結構確信を持ってこれを書いています。

なぜ確信を持っているか。

それは、JavaMailが依然としてクラサバ型のメールクライアントを意識した仕様だからです。

なぜそう思うか。

Folderがメッセージをキャッシュすべきである、とか、そもそも「フォルダー」という概念がクラサバチックなのです。

Swingで作るメールクライアントならFolderがメールをキャッシュするのもよいでしょう。しかしServletではどうするか。Folderがメールをキャッシュしたところで、じゃあそのFolderをどこにキャッシュするのか。FolderはSerializableではない（javax.mail.Messageすらも！）のでSessionにPUTすることはできません（してもいいけど仕様に反する）。じゃあServletContext？？それは何だかみっともないなあ。

それからgmailやdel.icio.usで採用されているような（「フォルダ」という概念ではなく）「タグ」という概念が、JavaMailでは実装不可能であること。つまり「フォルダ」という概念をそのまま「javax.mail.Folder」に落としてしまったという痛恨のミス。これらがJavaMailが5年以上前のレベルにとどまっている証拠だと私は思うのです。

3層Webアーキテクチャ（というのも古い言葉なのかな）でメールシステムを作るとすれば、JavaMailの仕様は結構無視してしまうしかない、と私は確信するものであります。

かなりマニアックな話題を中途半端に終わらせるのもなんですが、以上です。

GPL・・・

GPLというソフトウェアのライセンスがあります。
このページを見るような方であれば名前くらいはご存知かと思います。私も厳密には理解していないと思うのですが、大体以下のような特徴を持つライセンスです。

（１）著作権は書いた人にある
（２）GPLのソースコードは変更が自由である
（３）GPLは継承されなければならない
（４）GPLのライセンスを含むソースコード・ライブラリを含むアプリケーションのソースコードは無償で公開されなければならない

この（４）の制限が強烈です。

GPLとは言わば「ソースコード公開原理主義」です。GPLはソフトウェアの対価として金銭を受け取ることを認めてはいるものの、商用ソフトウェアでは事実上GPLのライブラリやソースを利用できないことになります。

結構厄介なもので、ちょっと気の効いた、自分では作るのがちょっと難しいようなライブラリがGPLだと、困ったことになります。GPLを含めるわけにはいかないので、既に優れた実装が存在するものをわざわざ0から自分で作る羽目になるのです。これはかなりの「しょうがねーなー」感があります。

LGPLやMITライセンスやApacheライセンスなど、もう少し利用しやすいライセンスが流行るのが当たり前だと思います。

学生の頃は「GPLいいじゃん」などと思っていたのですが、最近では「GPL困ったもんだね」派に傾いています。何につけても原理主義というのはよろしくないと思います。