会社の開発部長が、僕が5年ほど前に買ったRubyの本を読んでいます。多分、彼はその本を読まなくても書けるはずなんですが。ちょっと古い本なので、変わっている部分もあるかもしれませんが、僕はもう覚えていないです。

さて、その本の影響というわけではないですが、会社では昔、Rubyのスクリプトが動いていた時期がありました。今は、もうそのスクリプトは使っていない（使っていないはず）ですが。

僕は割といろいろな言語に少しだけ手を出して気に入らなければすぐにやめてしまっていました。Rubyは気に入らなかったわけじゃないんですが・・・。むかーしは、言語おたく的なところもすこしあったのです。最近は、新しい言語に手を出すことはあまりありません。

開発部長は僕と同い年です。彼がRubyの本を読んでいるのをみると、僕も何かやらないといけないかな、と思っていたのですが、よーく考えたら、先週は生まれて始めてPHPのコードを少しだけ書いてみました。PHPは楽しくありませんでした。

今は昔，Cは高級言語と言われ，アセンブラで直接記述するより生産性が高いと言われていました。Javaの登場から10年がたち，メモリー管理はVMの仕事とされ，メモリの割当，解放は大多数のプログラマから意識されることがなくなりました。そして，Cは過去の言語に押しやられ，その地位を落としてしまいました。一部の誤解した人たちは，CもC++もC#でさえ，Cと言う文字を使っていると言うだけで同一視するようになりました。C#はJavaなんだが・・・。地に落ちたCは、Cの登場とともに地に落ちたアセンブラと同じところに落ちてしまいました。ひとたび転落が始まると，とどまるところを知らず，落ち着く先は決まったところだったようです。それは，一部の識者が語るCの本質についての誤解から始まったものかもしれません。そして，Cはアセンブラと肩を並べ，ほとんど同じものになりました。
世の中の常です。

一方のJavaはどんどん進化を遂げ，年をとりました。若かりし頃は，オブジェクト指向の純血種(実は純潔じゃないんだけど)だったものが，理想だけを目指していてはLLにその地位を奪われると感じたのか，スクリプトを取り込み，delegationをとりこもうとし、そしてレガシーな言語になろうとしています。

さて，CとJavaで何が違うのか、というか、開発者の生産性を一番左右する言語要素は何かというのを５年ぐらい前にとある人（現在はSkypeにうつちゃった岩田さん）と話した事があります。人によっては静的な型だとか動的な型だとか言います。そのあたりは僕には分かりません。ソフトウェア（または開発）の規模が大きくなったときに動的型言語でスケールするのか分かりません。Zopeのような巨大なソフトウェアの存在がやり方によってはスケールすると物語っています。一方でZope Interfaceのようなものが存在して，動的型言語に静的型言語のような要素も取り込もうとしています。
僕の結論はメモリー管理です。10年前からの意見です。生粋のCプログラマなら，その管理を自分の制御下におきたいと言うかも知れませんが，オートマ車がひとたび便利だと感じてしまえば，多少燃費がわるくてもマニュアル車には戻れません。それにCのコードは80%がメモリー管理のコードだったり，バグのほとんどがメモリー管理にまつわるものなので（誇張して言っています。実際はそこまでひどくないのでご安心を），その煩わしさから解き放たれロジックに集中できる言語は生産性に開きがあります。
ちなみに，「JavaからRubyへ」と言う本を最近読みましたが，JavaとCの生産性の違いが殆どなくって，LLは生産性がはるかに高いと書いていましたが，LLはともかく，JavaとCでの生産性に開きがあるはずです。もし、開きがない結果が得られるとしたら，Cのプログラマは優秀だから今も生き残っていて，Javaは大量に新しい人をいれたのでサンプルの人たちのレベルが低いからかも知れません。

結局Javaしか知らない人たちはCもアセンブラも、メモリ管理を自分でしないといけない言語は同じなのかも知れません。

気がつけば自分も30代半ばになっていましたが、それとは関係なく今日は20代の人の話です。自分が20代のころは新しいもの(ヘンなもの)を追いかけたり、雑誌や本をそれなりに読んだりしていました。なんとなく、僕の回りにいる20代の人たちは、僕が足元にも及ばない優れたセンスを持ちながらも、それほど新しいものを追い求めたり、本を読んだりしていないように感じます。

さて、会社の恐い人に、「20代の人は基本を学んだ方がいいのか、最新のトレンドを追いかけたほうがいいか」聞いてみました。答えはあっさりしていて、「両方」ということでした。面白くもなんともない答えです。基本ばかりやっていてはおもしろくないし、むやみにトレンドだけ追いかけても基本的なことがわかっていないと上辺だけに流されます。まあ、難しいですが。ちなみに、10年前はJavaは新しかった!
僕が初めてPythonのコードを目にしたのが10年ちょっと前でした。その時は、インデントを言語仕様として強制するなんて、馬鹿げていると思っていました。自分のコードはインデントはちゃんとしてあるし、その時見ていた他人のコードもインデントはちゃんとしています。その後、いろんな人のコードを見ていると、インデントが狂っている人がいる！コーディング規約だけではどうにもならないことがあると気づきました。他人のコードをみて、最初にすることがインデントを直すことだなんて、馬鹿げています。
話はそれましたが、トレンドを追いかけない人がいて、追いかけても自分の興味の範囲内でそれなりにしか追い求めていないように感じます。でも、一見仕事に全く関係のないことも、実は重要だったりして、それはLinuxのカーネルのスケジューラをたまたまよんで、会社のAirOneのいろんなタスクのスケジューリングをするモジュールを書き直したり、何がどうなるかわかりません。

さて、トレンドを追いかけずに基本をみっちりやればいいのですが、それも難しいです。特にJavaからプログラミングに入って、Javaしかやってきていない人は、メモリとかスタックの概念が抜け落ちています。それでもそれなりにコードをかけるのですが、オブジェクトがどのタイミングできて、そのライフサイクルまで考えないので、多少効率が悪かったり、ときには助長なコードを書いたりします。
とっかかりはJavaでもLLでもいいのですが、その後、一度はアセンブラやC(C++じゃないよ)を経験した方がいいのかな?ちなみに僕はC++のコードがどう、Cのコードになるかしりません。なので、C++はよくわかっていません。

そういうことなので、次回は、「Cとアセンブラが同一視される」のお話です。

永遠のテーマなのかもしれません。今の会社では、プロジェクトは無理をしすぎず運用しようとしています。製品が数年をかけて熟成されると想定している(僕が想定しているだけですが)ので、息切れしない程度で実行したいです。それでも、機能要求のリストは山のようにあるので、スーパーエンジニア(僕じゃないよ)の人にはちょっと多すぎるぐらいの仕事量ですが、なぜか彼らはこなしてしまいます。スーパーエンジニアだからでしょうか?それ以外の人たちは、適度な量の仕事量のはずです。でも、工数はスーパーエンジニアが技術的難易度から見積もるので、微妙なところです。本来なら実装するエンジニアが見積ったほうがいいという人もいます。ただ、それには経験とか広い視野とか、見積もるために必要なスキルがたくさんいります。見積りが出るころにプロジェクトが終わっていたというのでは笑い話にしかなりません。結局、どう見積もるかは難しい問題のままですが、スーパーエンジニアの多くは楽観的に見積もりすぎる傾向があるようです。

さて、見積りなので実際に行うと誤差が生じます。1日かかると思っていたものが2分で終わることもあります。2分で終わると思っていたものが数日かかることもあります。それでも、全体としてはバッファーの範囲内で終わります。

でも、ある程度の人数で運用していると、遅れる(実際は遅れると言うよりほとんど進まない)人はいます。今のところ、遅れる人は特定の人です。スーパーエンジニアたちはエンジニアとしてのプライドなのか、プロとしての何かなのか、スケジュールを守って頑張ります。でも、遅れる人はスケジュールは全く意識していないかのように振る舞います。また、彼らが書いているコードについて質問しても、今自分が何のコードを書いているか説明できないでいます（自分が何をやっているかわかっていない）。どうしたものなんでしょう？ちなみにどれくらい遅いかというと、僕がまじめにやった場合は3日ぐらいでできることを、1月かかってもできません。
でも、プロジェクトごとに一人はこういう人がいました。今も、これからもこういう人はいつづけるのかもしれません。もしくはその人のいいところが見えていないだけかもしれません。

以前、「じじい臭い若者」でコードの一行の文字数を偏執狂的に80文字にしている２０代後半の若者N君について書きました。80文字に制限することは古くさく感じますが、今でもプリントアウトしてコードレビューを行ったりするかもしれないので、悪いこととは言いきれません。と言っても、プリントアウトされたコードを見てレビューしたことなんて、ロータスにいたころ１回あっただけですが。

さて、そのN君ですが、質問をされたので彼のモニターを見ながら説明しようとすると80文字以上になぜかすごい違和感を感じます。なんとなくインデントが2文字のような感覚です。でも、確かにスペースで４文字でインデントされています。でも、なんだか、文字の幅がバラバラのような感じをうけます。そうです。彼は、プロポーショナルフォントを使っていたのでした。一行を80文字にそろえるのは、横幅を固定にしたいとか言っていましたが(宗教かもしれません)、プロポーショナルにすると、結局固定されないじゃん!プロポーショナルの方が見やすいということでしたが、印刷物を読むならまだしも、コードを書くときにはどうなんでしょう?ちなみに、プロポーショナルフォントを使っているエンジニアは始めてみました。もっとも、IDEデフォルトのフォントから変更している人を始めてみただけかもしれません。
貴重な体験です。

コードを書くときは等幅フォントの方がいいと思っていますが、それは人それぞれなのかもしれません。まあ、誰も困らないし、なんでもいいのですが。

僕はサーバーのセットアップとか設定とかをよく，自分でやったり，人にやってもらったりします。サーバの中でも僕はDNSとメールサーバは苦手です。正確には怖くてなるべくやりたくないものです。
人にやってもらう場合やカスタマーのサポートで，設定などをいろいろ質問されたりします。でも，大きな仕組みはそれなりに知っているかもしれませんが，個々の設定なんて専門家でもないんだから覚えていません。それなりのドキュメントを読んで，記憶の片隅にそのような設定があったなー、という程度でしかありません。あとは必要に応じて調べるだけです。
つまり，基本的には，質問しにきた人より若干知っているかも知れませんが，そんなに知識レベルが違う訳じゃないです。聞いてこられると，放っておく訳にはいかず，しぶしぶ調べることになりますが，うーん。さて，さらにサーバで問題があると調べることになるのですが，でも、僕が調べても他の人で出発点は同じような気がする。

そう言うときば，ログを沢山読みますが，さっぱり分からなかったのはOracleのログです。なんのことかさっぱり分かりません。プログラムの開発に最低必要なSQLは書けますが，僕はOracleは使えないと言っているのに・・・。

会社のN君は，マルチスレッドで動くとき，メソッドのローカル変数がスレッド間で共有されると思っていたりしたこともありますが，それはさておき，時々，Javaはフレームワークやデザインパターンがちゃんとしているので，マルチスレッドプログラミングは簡単だと聞いたりする事もあります。正確にはマルチスレッドでの排他制御や同期の取り方です。確かにvolatileやsynchronizedなどがあるので，Cに比べて助長な書き方をしなくてもすみます。若干，構文が簡単になるだけで，本質的な難しさは何も変わっていません。
まあ，と言ってもCよりは書きやすくなっているのは事実なので，巨大なロックで効率を無視して安全に書く事は出来ます。ロックの中で排他制御をしなくてもよいようなデータベースのアクセス(例えば数秒かかる処理)を沢山行なっていてもちゃんと動きます。つまり、効率さえ無視すれば，割と気軽に手を出す事が出来ます。素晴らしいですね。他のスレッドは数秒待って，さらに別のスレッドは数十秒待って・・・。でも効率は悪いですが，ちゃんと動きます。でも、教科書的な書き方で素晴らしいです。でも、効率は悪いです。

さて，その効率を改善しようとすると，体に悪い事が置きます。デバッグは難しいし，どこからどこまでが本当に守らないといけない領域か判断しないといけないし，シングルスレッドが恋しいし，それがダメならスレッド間の強調がない世界に戻りたいし，そして夜は更けていく。えーと、どんなにプログラミング言語が進歩しても難しいものは難しいままのこっていくと言う話です。プログラミング言語がどんなに進歩しても難しいものが簡単になる事はあまりなくって、難しさの質が変わっていくだけだったり，より本質的なものが難しいまま残っていくのかな？

会社には若者がそれなりに沢山います。いちばん若いのが18ですが，20代後半のわかものN君のネタです。

彼の各コードは教条主義的なところがあって，それは若者の特権です。そのうち，理想だけではメンテナンスできない事が分かります。もしくは年齢を重ねると，単にめんどくさくなるだけかもしれません。

さて，僕はコードを書くとき，その言語の文化になるべく従うようにしています。その中で，90年代の後半からは特に1行の文字数にあまりこだわっていません。Pythonは例外的に80文字に納めていますが，それはそういう文化だからです。Javaの場合，コードの補完機能があるので，クラス名やら，メソッド名，変数名はどんどん長くなっています。社内で命名するものならコントロールできますが，外部のライブラリはどうしようもないです。なので、Javaで80文字と言う制約は現実的じゃないです。
さて，冒頭の若者は律儀にも1行の文字数を80文字に制限しています。じじ臭いです。じじくさい開発部長よりもじじ臭いです。しかも，80文字の制限のために僕としては気持ち悪いところに改行が入ります。こんな感じです。

Hoge hoge
    = new Hoge()

for (Integer i=0; i<1000; i++) {
    System.out.println(i);
}

ユースケースと言うか、UML的にはシナリオなんですが，最近は仕様書にユースケースを書いてくださいとお願いしています。読んでいるとそれなりに面白いものです。

パターン1：延々と前提条件が説明してあって，前提条件もそれなりに笑える内容であったりするのですが，肝心の部分が書いてなかったりします。で，管理者はそれで何をするの？ユーザは何ができるの？と。より具体的に考えないといけない部分はそのあとだし。

パターン2：ストーリーとしてはそれなりに筋が通っていていいのですが，そのストーリー，僕は普段の生活の中で実行できないよ。あなたは出来るの？しかも，さらに細かな事がそのあとできるような事が書いてあります。うーん，システムに人が支配されいている。というか，システムにとって理想的なユーザを作り出しているし。

パターン３：「こんなログ(CSV)がでますが、いいですか？」でも，僕はそのログで何がしたいのか知らないので，いいもわるいも分からないです。ごめんなさい。なので、「それをExcelで分析した結果を最初に見せてください」とお願いします。うーん，それCSVをExcelで読み込んだだけだし、分析してないし。

シナリオを書いてもらうのは今回が初めてなので，頑張っているとは感じます。でも，もう少しドッグフードを食べたらどんな味がするか想像してもいいかな。

土曜日はPython Workshp the Edge 2007でした。休みの日なのに百数十名も参加して，大盛況でした。いちばん驚いたのは、10時から始まるのですが，みんな１０時からちゃんと出席していた事です。僕は少し遅刻しました。でも，９時には現地につこうと思っていたので，大遅刻です。

さて，IronPythonは何かと面白そうでしたが，どう使っていけばいいのかよくわかりません。やっぱりクライアントサイドで使うのがいいんでしょうか？そのあと，Tracについてです。Tracはお話をしていた落合さんにあとでちょっと質問するのがメインでしたが。mod_pythonよりFastCGIの方がよいらしいと言うことがわかりました。

その次がお昼を挟んで僕のTwistedのハンズオンのセッションです。僕のセッションはいつもご飯のあとにあって眠くなるものですが，これは偶然なんでしょうか？
内容としては，どうだったんでしょうね？まあ，きっかけになってくれれば嬉しいです。Twistedがどこで使われているかと，あとで質問を受けましたが，Appleのサーバで使われています。BitTorrentでも使われています。あとはいろいろ。

気が楽になったところで東京理科大の先生のお話です。とても興味深いもので，プログラマは授業では育たないな、と言うのが率直な感想です。

いろいろありましたが，とても面白かったです。次は秋頃の大お泊まり会でしょうか？