未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

リナックス・アカデミー

というところで、1時間半ほどお話をさせていただく。ヨタ話ですまぬ。「世界で活躍するオープンソース技術者になるには」というおおげさなお題であった。前半は会社の宣伝で後半が自分の話したいことを話したいペースで話した。狭い会場に50人くらい集まっていただいた。熱心に聞いている。十代の人も2〜3人いたので早速U-20プログラミングコンテストの宣伝をしておいた。
ソフトウェア技術者と言っても、利用者、開発者の立場があって、オープンソースの利用者というのは、情報がふんだんにあって、書籍とか、インターネットとか、メーリングリストとか、掲示板とか、・・・、どこでも学べるし、無料で利用できる、でも、利用者である限り、商用ソフトもオープンソースも変わらない、でもって、OSS(オープンソースソフトウェア)利用者を極めるというのが大切である、極めるというのは、実装を知ったり、コミュニティに参加したりしていくうちに、極められるのだろうか、ソフトウェアの実装を知ると言うのは、開発者にならない限り不可能なわけだが、商用ソフトの場合、開発者になるには、その会社に就職する以外不可能なわけだが、OSSならば可能だ、で実装を知ると何がうれしいかというと、障害があればその原因がわかるかもしれないし、限界値がわかるかもしれないし、より効率の良い利用方法がわかるかもしれないし、地雷をさけられるかもしれないし、勉強になるかもしれない、そこで「中身をいじれる自由」というのが重要になってきて、日立の偉い人も言っているように、わたしも「中身をいじれる自由」というのは絶対必要だと思うのだけど、中身をいじれる人になるには、昔はメインフレーマーに就職するしか道はなかったし、90年代は米国のベンダーに就職してシリコンバレーに行くしかなかったのだけど、21世紀は、OSS開発者になれば中身をいじれる人になれるではないか、というわけで、OSSの開発者になろう、それは、楽しいから、技術者としてのチャレンジとして、ひょっとしたら給料があがったり、人と知り合えたりするかもしれないけれど、その動機は人それぞれなわけで、イチローや松井は大リーグが活躍の舞台なわけで、OSS開発者はそれが世界が舞台なわけで、そのためには基礎的な訓練が必要なわけで、基礎的な訓練と言うのは、狭い意味での技術力、すなわち、コードを読む力とか、デバッグをする技術とか、あるいは、コミュニケーション技術とかそーゆーものが必要で、ソースがあるので、コア開発者と共通の理解ができて、バグの指摘かなんかもできちゃったりして、誰でも開発者になれたりするように見えるのだけれど、習うよりなれろで、英語のメーリングリストにもがんがん参加して、質問の仕方を学んで、バグデータベースでバグの報告ができるようになればコミュニティへの入場券を手に入れたようなものだ、バグの報告の仕方にもイロハはあって、簡潔な問題点の記述、再現方法、期待する効果なんかは必須なんだけど、ついでに解決方法、いわゆるパッチなんかを提案しちゃった日には、デビュー即ヒットみたいな感じだからがんばってほしい、でもって、なぜソースを読むのかと言う話に続くのだけど、これも人それぞれの動機があって、例えば、そこにソースがあるからとか、トラブルシューティングのため必要にせまられてとか、勉強になるからとか、仕事でとか、楽しいからとか、十人十色の世界である、Lions' Commentary on Unixという古典があるのだけど、OSを勉強する3つのアプローチというのが載っていて、こうあるべきだという一般原理を勉強する方法、プロトタイプを作ってみる方法、いまあるOSをケーススタディする方法などが紹介されているけど、〜でなければならないという規範的な立場をとるのか、〜であるという記述的な立場をとるかで随分ソースに対する読み方接し方が違ってくるように思う、どちらがいいとかわるいとかじゃなくてね、でもって、ソースを読むのは、実装からその実装をしたプログラマの知見を得て、そしていまそこにあるプログラムを虚心に理解する技術だとわたしは思うので、そのテクニックとして、巨視的な視点と微視的な視点とを使いながらぐりぐり読み、ソースコードそのものを静的に理解したり、実行してその振舞から動的に理解したりすることを組み合わせるのが一般的で、静的理解としては、ドキュメント、readmeファイル、リリースノート、changelogなどをよりどころに、ディレクトリ構造、ファイル名、名前付規約などをおさえつつ、CVSなどのバージョンからの履歴とか、差分情報なんかも参考になるし、ソースに潜っていって、データ構造、テーブルとか、アルゴリズムとか、コールグラフ、すなわち呼出関係の図とかも参考になる、一方動的理解つーのは、とりあえづ動かすというスタンスで、実行結果、straceコマンドを使ったトレースとか、oprofileやgprofでの実行プロファイリングなんかも有効だし、gdbを利用したデバッガによる実行での理解とか、最近ではLKSTなんかはわたしのお気に入りである、でもってデバッガを使えという話になるんだけど、準備として、コンパイルするとき、-g(ハイフンg)をつけてデバッグシンボル付でビルドしておく、そしてデバッグというのは、極論すればブレークポイントを設定し、変数の値を調べて、期待する値かどうか調べて再実行するだけの話で、それをいかに効率良くやるかが、素人とエキスパートの分かれ目で、同じバットを握ってもすこんすこんヒットを飛ばすイチローになるか、草野球で三振しているかくらいの違いは簡単にでるので、そのデバッグのテクニックはみがいておいてそんはない、で、ブレークポイントや変数に値が代入されたら止まるウオッチポイントなんかを上手に利用できるようになろう、で、トラブルシューティングというのは期待する結果と実際の実行結果の差を埋める作業なのだから、再現ケースを見付け、再実行し、分析するというのを繰り返すだけのはなしで、期待する結果と実行結果の差を、ブレークポイント、ウオッチポイントを利用して変数値を確認しながら追い詰めて行く作業といえる、ある時点で期待値とことなれば既にどっかで何かがおかしくなったのだから、その時点より「前」にブレークポイントをおいて再実行し、期待値と同じだったらまだおかしいことすなわちバグには到達していないので実行を続けどこに問題があるかを探るわけだ、まあ、デバッグというのはいま言ったような作業を延々と繰り返すだけといっちゃあなんなんなだけどね、コミュニケーションというのは、相手の立場を理解することと、自分の立場を相手に理解してもらう、まあ、それだけっちゃあそれだけだ、難しいけど、で、それはもう、実践の場で経験をつむしかなくて、OSSのコミュニティに参加して経験を積もう、コミュニティでの存在感は単に技術的に優れているだけでは尊敬されるとは限らないので、いろいろ経験をつんで欲しいと思う、OSSとして何にチャレンジするかというのは、いろいろあるので、LAMPとかスクリプト言語とかいろいろあるので、好きなものにチャレンジして欲しい、最後に練習問題もだしてしまう、あなたはなぜソースコードを読むのか、答えてほしい、考えて欲しい、どのように読むのか、OSSを修正する方法、機能拡張の方法、OSSを修正したとして、それをコミュニティに受け入れてもらうにはなにをしないといけないのか、受け入れられやすい方法とは何かを考えて欲しい、でもって、世界で活躍するオープンソース技術者になるには、