2008年8月27日水曜日

プログラマとして生きるということ

はてなを眺めるようになってから、「IT土方(どかた)」という言葉を知りました。IT土方とは、

システムエンジニアプログラマーなどにおける過酷な労働条件を自嘲的に表現したもの。「土方」は差別用語及び放送禁止用語として扱われているため、使用の際には留意すること。

という意味だそうです。僕は研究者だけれど、プログラマでもあるので、プログラマが世間でこう呼ばれているのは非常に悲しいことです。プログラマというのは、本当はとても魅力的な仕事です。土方で甘んじているのは、きっと「プログラマ」として生きていないのだとも思います。(例えば、矢野勉さんのエントリにも挙げられているような状況の人達です)


プログラムをデザインする、ということ プログラムの場合、通常の土木工事と比べて顕著に違うのが、一度作ったコードを「一から作り直さないようにデザインできる」ということ。たとえば、コマンドライン引数を処理するプログラムを一度作ると、それをクラスの形に整理して(OptionParserクラスなどと名づけて)ライブラ リにしておきます。ライブラリを作る作業は、Windowsならdllを作る、JavaならJARファイルにまとめることに相当します。

書いたプログラムが自動的に再利用可能になるわけではなく、そうなるように「デザインできる」ということで、この間は結構違いがあります。二度目からは、ライブラリにリンクして使うので必要な仕事の量は格段に減りますし、使い道にあわせてライブラリの修正をしなくてはいけないことも多いですが、機能を改善し、使い勝手を向上できるというメリットがあります。修正に費やす時間は、今直すか、後で必要になってから取り掛かるか、という違い。Ruby on Railsのフレームワークも、Webアプリケーションで頻繁に書くようなコードをうまくライブラリ、モジュールにしていると思います。

プログラミングが肉体労働になりやすいのは、おそらく、このライブラリにまとめるという経験が不足している場合。Visual Studioでdllを作っておくだけで、ビルド時間や開発時間は短縮できるし、Javaならmavenを使えば、細かな修正を施したjarを頻繁にreleaseする作業が苦ではなくなります。PerlだったらCPAN用のモジュールを作るとか、RubyならRuby gems用モジュールを作るというところでしょうか。

他に考えられるのは、プログラマ自身が今書いているコードが二度目のコード(重複がある)と思っていない可能性。オブジェクト指向の考え方や、デザインパターン(クラスの組み方の過去の知見)を知らなくて、コードを再利用可能な形でまとめることに考えが及ばない、ということがありえます。Subversionやgitなどのソースコード管理ツールの存在を知らないと、再利用といっても、常にコピー&ペーストするという最悪な方法を採っている人も多いかと思います。これでは単純労働となっても仕方がない。


ハッカーと画家 ここで紹介したいのが、「ハッカーと画家」という話です。ソースコードを書くのは、絵画を描くのと非常に似ています。僕自身もそうですが、新しいものを創ることだけでなく、良いコード、簡潔でわかりやすいコードをデザインすることに魅力を感じます。本文中には以下のように書かれています:
ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。
コードをデザインする能力が、画家の画力と同じように、良いプログラマたる条件でしょう。良いデザインを考えることはかなり高度な知的活動になります。ただ、ビジネスモデルの中で、プログラマが良いデザインをすることと売れることが直接結びつくケースは少なく、プログラマが労働過多になるのは、以下のような事情によるものかと推察します:
Yahooに入ってみたら、彼らにとってハックするということはソフトウェアを実装するということで、デザインするということではないということがわかった。プログラマは、プロダクトマネージャのビジョンとかいったものをコードへと翻訳する技師とみなされていたのだ。

究極のプログラミング - コンパイラを作る- コードをデザインする時間・許可が与えられない場合、たとえば、コンパイラを作る、なんてことは到底認められないでしょう。けれど、コードを書くというのは、人が考えていることを機械が実行できるようにすること。この意味から考えると、究極のプログラミングはコンパイラを作ることにあります(お絵かきソフトなど人の入力を画像データにするのも、ある意味コンパイラですね)。簡単な記述で、素敵な仕事をしてくれるのがコンパイラです。コンパイラを作る時間、そのために必要な技術を習得するコストが大きいので、通常は、他人が作った言語やフレームワークを使ってコードを書いているだけです。

Webアプリケーションのように、どのOS、どのブラウザでも動くコードを書くのは大変です(主にIEが他とケンカしてしまう悪い子なので…)。だから、その作業を軽減するために、Google Web ToolkitではJava言語からJavascriptコードを生成するコンパイラを作るという、とても良い仕事をしてくれました。けれど、コンパイラを作るのだって、そんなに大変なわけじゃないですよ?以下は、Joel on Softwareより引用
Most people don't realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn't have to be a general-purpose compiler. It doesn't have a math library, for example. (多くの人が、コンパイラを書くのはドラゴンブックを読んだ優秀な人が2ヶ月くらいでやる仕事だってことをわかってない。コンパイラには、コンパイルするコードしかないので書くのは簡単だし、一般的なコンパイラなんて書く必要はないんだ。数学ライブラリなんてものもいらない。)
ドラゴンブックはコンパイラの教科書としてとても有名ですが、隅から隅まで読む必要はなくて、字句解析、構文解析の概要を知って、Lex/Yacc/Bison, ANTLR、JavaCCなどどれか1つのツールの使い方を学べば、コンパイラはすぐにでも作り始めることができます。

開発するプログラムが同程度のものなら、フレームワークなり、コンパイラがあるだけで相当仕事が短縮されるはずです。ここで負荷が減らないなら、コンパイラで仕事が簡単になったから、あれこれ追加機能を実装しようと欲張るなど、開発すべき仕事が単純に増えているのでしょう。逆に、コンパイルコマンド1つで製品ができても、それを1分、1秒の時間単価や人月で見積もられてはいけないのだと思います。

プログラミング+αの時代  インターフェースのデザインなどは、上記の「ハッカーと画家」の例のような比較とは違って、本当に「画家」とか「デザイナー」の能力を要する分野に踏み込んでいるので、プログラマの仕事としては過負荷になっているのだと思います。

僕は、デザインすることは昔から好きだし、コミック、油絵とかも良く描いていたので、ウェブデザインをするのは時間はかかって大変なことだけれど、楽しい部分として受け入れることができます。まだまだ未熟だけれど、デザイン+コーディングの両方できるというのは僕自身の専売特許だと思います。データベースが専門でシステムを作れるというのも、プログラマとして持っている僕の付加価値です。プログラマは、コードをデザインするだけでなく、+α(アルファ)の部分で、自身のブランドを作れる存在だと僕は思っています。売れないブランドだって当然でてくるわけで、オープンソースのApacheブランドだって、よくよく見てみるといいコードばかりではありません。

プログラムをデザインする能力を習得した上で表現すべき「+α」の部分が、まだまだ未開拓のように感じています。コンピュータ専攻の人だけでなく、もっといろいろな人にプログラムを学んで欲しいと思うのです。自分の魅力である「+α」をアピールするためにプログラムを作ってみる、知識が足りなければプログラミングを学ぶ、この繰り返しをするのがレベルアップへの近道でしょう。

プログラムやコンパイラを作るというのは大変なことですが、「魅力的なものを創る」ためには欠かせないことです。コンピュータ、インターネット内だけの話ではなくて、コンピューターでデザインして、現実の作品を作るなんてこともできます。せっかくプログラミングという応用分野が広く、すばらしい技術を学んだのに、人に言われたものだけ黙々と作るというのでは、面白くないのは当然。

プログラマが「+α」を作るという意味で、作ったものが売れないことがあるのも、飛ぶように売れる(有名になる)ことがあるのも、作家や画家と似たものを感じます。それはプログラマという職そのものの性質ではなくて、ビジネスとしてブランドの宣伝であったり、市場があるかどうかなど問題だと感じます。プログラマも、作りたいものだけを作る、と小説家や芸術家くらいわがままであってもいいと思います(これは偏見ですが)。わがままを通して「食える」ようになるというのは、プログラマに限らずまたどこか別の次元の話です。

プログラマとして生きるということ プログラマとして生きていくというのは、ビジネスを含めて、自身のブランドとして独立する覚悟が必要ですし、そうしない道を選ぶなら、他で生活の糧を得る必要があります。これは、プログラマとして能力が劣ることを意味するわけでも、恥ずかしいことでもありません。Googleだって広告収入が安定しているからこそ、Google Web Toolkitなどの開発に注力できているのです。

開発をしていて労働過多で見合った収入が得られていないと感じたときに、「プログラマだから」と結びつけるのは、誤った思い込みであるように思います。「プログラマ」とはそんなひとくくりにできるような言葉ではありません。「プログラマ」は好きなものを思いのままに作れる夢のような職業である一方、製造・出版業のような既存のレールがない分、ものをつくる職業として確立できていない難しさもあるでしょう。

けれど、そんな時代の荒波を生きていくのが「プログラマ」です。数年で技術が変わり、新しいツールも次々に出てくる。そんな中、目指すものを創るために、自ら学ぶことを止めず、成長し続ける人が、真の「プログラマ」と呼ばれるべきです。3年前にも同様のことを書きましたが、プログラマやハッカーという言葉に対するこの思いは今でも変わっていません。

2008年8月26日火曜日

JARファイルの中にJARを埋め込む

以前、「Leo's Chronicle: Fat Jar: Jarファイルの中にJarを埋め込む」で、JavaでFatJar plug-inを使って、Jarファイルの中にJarを埋め込む使う方法を紹介したのですが、最近は事情が変わってきています。

たとえば、Eclipse3.4からは、Runnable Jarの作成がサポートされ、依存関係にあるすべてのJARファイルの中身を展開して、1つのJARにまとめてくれる機能が標準装備だったり、Mavenユーザーなら、assembly pluginを使って、jar-with-dependenciesを指定する方法もあります。

ぱっと試したいなら、Runnable Jarを作成するのが速くて楽。このようなJARを頻繁に作成するなら、Mavenのassemblyで書いてしまうのが良いです。

関連記事:JARファイルの作成方法

[本郷でお散歩] UT Cafe

(長かったので前エントリを分割しました)

久々に本郷をお散歩してきました。東大の本郷キャンパス周辺のアカデミックな雰囲気がとても好きなんです。カフェに入ってもなにやら難しそうな英語の文献を読んでいる人が多かったりと。今日は、新しくできたUT Cafe(赤門入ってすぐ)に行ってきました。


最近の東大はとってもおしゃれですね。店内も赤をアクセントに使ったりと、表参道の通りのカフェみたいな雰囲気。お茶をしながら、研究のことを考えノートに マインドマップを描いていました。何もない静かな部屋に一人でいるよりも、人の動きのある中で自分の場所が持てるカフェのような環境の方が、かえって集中 できるので好きです。

博士課程のころは、部屋に一人ぼっちで寂しいことが多かったので、その孤独を乗り越えるためにカフェの存在は必須で した。最近はカフェで作業することもほとんどなくなったので、昔を懐かしみつつ、ノートひとつで、0から研究の全体像を描きなおしてストーリーを練り、今 後何をつくるとよいのかを自分の中で整理していました。

普段と仕事中としていることとほとんど変わらないのだけれど、休日だからと欲張ら ず、少し環境を変えて、普段+αくらいのことをするのが、お休みの有意義な楽しみ方だなと思います。本当は、休みになったからDBMSをじっくり作れる! とか思っていたりしたのですが、大きなことは「一日にして成らず」です。大規模なシステムは少しずつ進めていかないと、作りきれません。

2008年8月20日水曜日

[本郷でお散歩] PFIに行きました

今週休みをとっていたので、この機会に、はてなの関連エントリー機能を実装するなど、いまを時めくPreferred Infrastructure(PFI) さんに遊びに行ってきました。忙しいところ快く応じてくれた社長の西川君太田君に感謝。


以前、二人が会社を立ち上げたばかりのころに、データベースの話で盛り上がったことがあります。東大全体を見回しても、データベースシステムとその実装にまで興味がある人って意外と少なくて、Jim GrayのTransaction Processingを読んでいるなど、データベース屋さんの僕にとっては、貴重な話相手です。

ACM主催のプログラミングコンテストICPCの東大内予選(と僕が勝手に呼んでいます。本当は国内予選。ただ、各大学から3チームまでしか先に進めない)を勝ち抜けて、世界大会にまで出場するだけでもすごい人達なのですが。

今日は分散トランザクションについて話をしてきました。トランザクション処理は、スループットを上げるための実装はそうとう複雑なのですが、さらにマシンが複数台になると考慮すべき障害が増えてとたんに難しくなります。運用を考えたときのコストとか、商用DBといえど落ちることがある、などの話を聞けてためになりました。僕は研究者の立場なので常に新しいものを開発すればいいのですが、24時間常時動かすというのはやはり相当大変なことなのだと再認識。もしかすると、僕はこういった運用の大変さから逃れるために、研究の道に入ったのかも。

今回は短時間の訪問だったので紹介しきれませんでしたが、本当は最先端の話題でもっといっぱい話したいことがありました。主にMITのStonebraker教授(PostgreSQLを作った先生)のお弟子さんたちの話なのですが、C-Store (列ごとにテーブルを分割して圧縮。性能抜群), H-Store (トランザクションの意味を考えて、仕事の単位を分割、sequentialに処理して速度を稼ぐもの)など。One-size doesn't fit all (DBMSも用途に応じたものが必要)という時代の流れがあるんですね。現在主流のrow-oriented storage(テーブル行単位でディスクに配置していくもの)で、ロックマネージャーを外し、ログを外し、、、とやっても、トランザクションで100倍の性能を上げるのは難しいんです (OLTP Through the Looking Glass, And What We Found There. SIGMOD2008を参照)。

まだ教科書には載ってないけれど、トランザクションを高速に実現するための現在の主流であるsnapshot isolationを、性能をほとんど落とさずserializableにする話 (Serializable Isolation for Snapshot Databases。著者に実際に会ったときにソースコードくださいと話したらBerkeleyDB上での実装を公開してくれました)など。

XMLのような階層構造のデータもrelational databaseと同じ枠組みで扱える、という僕の研究の話もいつか紹介したいですね。こんな要素をもろもろ含んだ日本発の最先端DBMSを、彼らのように物を作ることに貪欲で、「わくわく」する感覚を持ち続けている人たちと一緒に作れたらいいなぁと夢見ていたりします。

PFIのオフィスは、自宅から徒歩圏内なので、本当はもっと遊びに行きたいのですが、職場まで遠距離通勤+子育て中なので、もうちょっと落ち着いてからかな。


License

Creative Commons LicenseLeo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License.