MIRACLE
メールサービス申込 ユーザー登録 パートナー情報
お問い合わせ FAQ サイトマップ
MIRACLE LINUXの特長 製品紹介 サービス案内 購入 サポート 技術フォーラム

プロフィール

吉岡 弘隆 - よしおか ひろたか

日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Board of Directorsを歴任
カーネル読書会主宰

2000年6月、ミラクル・リナックスの創業に参加。
95年~98年、米国OracleにてOracle RDBMSの開発をおこなっていた。
98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。
2008年6月取締役CTOを退任し一プログラマとなった。

ミラクル関連リンク

採用情報

サイト検索

2008年9月

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

« 2008年6月 | メイン | 2008年8月 »

よしおかひろたかの「初めての勉強会」

@ITで『よしおかひろたかの「初めての勉強会」』という連載を開始した。
http://jibun.atmarkit.co.jp/lcom01/index/index_first.html

第一回は下記だ。
http://jibun.atmarkit.co.jp/lcom01/rensai/first/01/01.html

最近、東京界隈で勉強会が熱い。この連載では、勉強会をどのようにして楽しむか、参加するか、あるいは参加するだけではなく、どのように開催するかなどにも踏み込んで紹介したいと思っている。

勉強会をしゃぶりつくすためのガイドになったらいいなあと思う。これをきっかけに勉強会に参加する人が増え、ますます良質な勉強会が多数開催されるようになったら望外の喜びだ。

@IT『よしおかひろたかの「初めての勉強会」』
http://jibun.atmarkit.co.jp/lcom01/index/index_first.html

先行評価(Eager Evaluation)勉強法とトラブルシューティング

新人プログラマのよしおかです。どうぞ、よろしくお願いいたします(ぺこり)。という日々を送っている。日々のトラブルシューティングの話なんかをここに記したい。

そもそもAsianux Mobile Midinux 2.5Jというのは、Intel Moblin(http://www.moblin.org)準拠なのでいろいろお作法が違う。

debianのパッケージング方法なんかも一から勉強である。最近はインターネットのおかげで高速道路が整備されているので、必要なマニュアルは全てオンラインで入手できる。debianのドキュメントの充実度は目をみはるものがある。一見遠回りのようでいても、ドキュメントをひととおりざっと眺めてみることは、重要である。何か問題にぶちあたったときにググって断片的な回答を発見するのではなく、まづマニュアルにあたってじっくり仕組から理解をする。すぐに回答にたどりつかないように見えてもそれは自分に対する投資なのであせらない。習熟曲線というのは最初はなだらかで、ある程度いくとぐぐっと立ち上がる。そのぐぐっと立ち上がるところまでは自分に対する投資である。

まわりにいる、debian使いの人のお世話になって、最初の道案内をおねがいし、読むべきドキュメント、マニュアル類をおさえる。これ非常に重要である。必要になるかならないかわからないけどドキュメントをちゃんと読む。Eager Evaluation(先行評価)勉強法である。で、わたしは、その投資のリターンが非常に高いことを経験則として知っている。ドキュメントを読む時間(投資コスト)は低いので、ローリスク、ハイリターンな投資となる。

日記界隈のハッカーは遅延評価勉強法をとっているようである。何か問題にぶつかったら、それについて調べるというスタイルである。こちらの方が、一見レスポンスタイムが短かくお手軽ですぐれているように思えなくもない。しかし、一つのことを極めようと思ったら初期投資をおそれてはいけない。結局はマニュアルなど原典にあたることになる。

まあ、こーゆースタイルは誰かに強制するつもりもないし、強制できるものでもない。遅延評価で場当たり的にやっていても結局いつの日かマニュアルを読むことになって実はああ何か遠回りをしたなあと気がつく。マニュアルをはじから読むなんていうことは、自分にはなかなかモチベーションをキープするのが難しい。どうしてもつまみぐいになってしまう。という声も聞くが、人それぞれなので、もちろん強制はしない。

わたしなんかは、何度も言っているようにIntel Software Developer's Manualを読むのが趣味という芸風なので特殊例だとは思うが。

で、トラブルシューティングのお話なのであるが、最初はその問題について初心者で動作原理を十分理解していないから、現象を見ただけでは、なんでそのような現象が発生するかチンプンカンプンの状態からはじまる。これが、その問題についてのいろいろ経験して理解がすすんでいけば、現象を見ただけで、ある程度原因がわかっちゃったりするのであるが、そこにいくまでは、いろいろな試行錯誤の連続になる。プログラマはその経験のつみかさねで自分の適応可能領域をどんどん広げていくことになる。

初心者の場合、毎回毎回初めてみる現象に遭遇し、そのたびに、わけがわからなくて、どこからあたりをつけていいかわからないので、試行錯誤をくりかえす。初めての問題なので、そもそも簡単な問題なのか難しい問題なのかすらわからない。ひょっとしたらとんでもない超難問にぶつかってしまったのではないだろうかとか不安になったりもする。解決するには何日も何日もかかるような問題なのではなんて思ったりもする。

第一歩は問題を正しく理解することである。何がおこっているか正しく理解することである。安易な解決策に飛びつこうとしない。先入観をすててありのままに現象を観測する。それが第一歩である。

先日遭遇した問題はこんな問題であった。

ソースコード管理システム(git)からソース一式を持ってきて(git-clone)してビルドする。問題なくビルドできる。いろいろ変更して再度ビルドすると、ビルドできない。Makefile他ビルドシステムそれ自身は一切変更していないので何がなんだかわからない。こーゆー状況に遭遇した。

問題を切りわけるために、原点にもどってみる。git-cloneしてビルドする。問題なくビルドできる。いろいろ変更したのが問題かもしれないので、何も変更しないでビルドしてみる。ここが最初のチェックポイントだ。ビルドが失敗する。ここからトラブルシューティングの旅がはじまるのである。

何がなんだかわからない事は、その通りなのである。解決できるかできないかも、その時点では見通しすらたっていない。どういう戦略でトラブルシューティングをしていくか。

ビルドのログをじっくりながめてみる。エラーがないのか、あるのか。ビルドができないのは結果であって何でビルドができないのかを理解することが必要になる。そうすると、パッチをあてることを失敗している。なぜなんだろうか?debianパッケージの場合オリジナルのソースに独自パッチをあて、その後ビルドをするというプロセスになる。

なぜパッチをあてることを失敗しているのだろうか。

ビルドする前に前回あてたパッチをとりのぞいて真っ新な状態にする。そして、今回ビルドするにあたって再度パッチをあてビルドする。ログを見てみると、前回あてたパッチをとりのぞくことに失敗している。そのために同じファイルに2度目のパッチをあてることをこころみ結果としてそのビルドに失敗している。

なぜパッチをとりのぞくことに失敗しているのだろうか。

問題のパッチのコードを眺めてみることにする。失敗したパッチには.rejというファイルができているので、それもあわせて読む。

パッチのコンフリクトしている部分がrejファイルには記述されているので、それを見た。

そうすると、ある行についてパッチがあたらない。なぜか。

パッチファイルにはTABで書かれていたが、それが空白に変換されて適用されていた。そのためパッチをとりのぞく時に、とりのぞけなかった。

さて原因がわかった。現象を分析し正しく理解すれば原因がわかる。原因がわかれば解決策を作るのは簡単である。パッチファイルのTABを空白にした。再度ビルドしてみてビルドできることを確認した。

理解してみれば他愛のないことである。しかし現象をみた段階で、何がなんだかわからなかったことも事実である。問題を一歩一歩理解していくといくプロセスがトラブルシューティングの王道である。

その道標としてマニュアルをきちんと理解しておくことが重要である。



ハッカーと遅延評価勉強法/Slow Dance
http://d.hatena.ne.jp/LukeSilvia/20080402/1207149044

私の言語遅延学習法 - 三つのルール+1/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50999338.html

遅延評価的勉強法/IT戦記
http://d.hatena.ne.jp/amachang/20080204/1202104260

初めてのRuby

「初めてのRuby」は、他のプログラミング言語の経験があるプログラマ向けのRuby入門書である。プログラミングの入門書ではない。この明確なターゲット読者の設定がこの本の特長であり成功の要因である。

すくなくともわたしにとって、他言語(C言語)でのプログラミング経験があるものにとって、これほどまでにコンパクトかつ明解にRubyの真髄を語っている本書ほど、ありがたいものはない。

わたしはかねてからプログラミング言語の文法書は50ページ以内であるべきだと思っている。プログラミング言語の構文はシンプルであればあるほどいい。道具はシンプルな方が応用が効く。

それはともかく、プログラミング経験者にとって、第二、第三のプログラミング言語を学習するということは、計算機の入門、例えば計算機はどう動くかとか、メインメモリ、CPU、外部記憶の機能はどうだという事を学んだり、プログラミングの入門、アルゴリズムとか、計算量、データ構造、例えば、表、ハッシュ、N分木等々について学ぶのではなくて、そのプログラミング言語の文法や意味論を、そしてそのプログラミング言語の背景にあるプラグマティズムを学ぶことである。

つまり第二第三のプログラミング言語を学ぶということは、その言語が持つ哲学、思想、あるいは開発コミュニティのお作法までも含めた何がしかを学ぶことである。例えば、Perlという奇妙なプログラミング言語を学ぶということは、CPANというPerlハッカー達がよってたかって作ったライブラリのレポジトリについての何がしかを学ぶということで、そのような事を含めて理解してはじめてPerlという言語を学んだということになる。

なぜわざわざそのようなプラグマティズムを貴重な時間コストをかけてまでプログラマが学ぼうとするのか。そこにはそのコミュニティがはぐくんでいるベストプラクティスがあって、それは言語の壁をこえた普遍性があり、それを学ぶことの意義というのは強調されても強調されすぎることはないと考えている。

「初めてのRuby」はRubyを愛してやまないYuguiさんが、Ruby初学者に向けてRubyを学ぶ道標をあたえている。

他言語を使いこなすプログラマに向けて極めてコンパクトかつ明瞭にRubyのプラグマティズムを紹介している。言語の文法書にはでてこないRubyの考えかたを紹介している。

なぜRubyではforで繰り替えしを書かないのか。C言語族に属するわたしにとってYuguiさんの説明は明瞭でかつ説得力がある。なるほどなるほど。

先日、tokyo-emacsというemacs利用者(初心者からハッカーまで)の集りで、いろいろなelispのコードをながめたのだが、そのコードのスタイルが、なにかCを感じさせるものが多く、皆で「これってCだよなあ」というような事を言っていた。関数型と呼ばれる言語(elisp)ですらCの影響を受けたプログラマが書けばCの匂いのするプログラムになってしまうのである。

プログラミング言語がノイマン型コンピュータを抽象化し動作可能なものとしたのなら、そのプログラミングパラダイムはおおかれすくなかれ似たようなものになる。変数という概念があり、メモリはアドレスというもので識別され、そこには状態を保持するので、代入という概念を持つ。手続型としてくくれるものは、ほとんど似たようなものだと言える。このプログラミングパラダイムの中で様々な文法的な選択肢を絶妙なバランスで取捨選択したのがRubyであり、その取捨選択の思想をわかりやすく説明しているのが、本書である。

プログラミング経験者が第二、第三のプログラミング言語を学ぶ意義はなにか。プログラミング言語の瑣末な文法上の差異を学ぶことが重要なわけではない。プログラミング入門的な知識を得るために行なうのではなくて、言語設計の思想、ライブラリや、それを作りあげている開発者の思い、考え、ひいてはそのプログラミング哲学について学ぶというところにある。その言語コミュニティが持つ暗黙の哲学、価値観を学ぶプロセスにある。

しかしながら、そのような暗黙の哲学、価値観は究極にはそのプログラミングコミュニティに属し当事者にならないと容易には獲得できない。

本書は、そのコミュニティの入口まで初学者を連れてきてくれる。

Ruby初心者も中級者もばりばりのRubyハッカーも本書から得られるものは大きい。初心者にとっては、Ruby言語のみならずその思想にふれられるところ、中級者にとっては、そのRubyらしさという必ずしも明確になっていなかったものに対する指針がえられるところ、ばりばりのRubyハッカーにとっては、今まで空気のように感じていたRubyらしさというものを明示的に表現するというのはどのような事かということを整理、理解するつてとして本書の意義は大きい。

Rubyコミュニティの豊かな土壌からRubyKaigi(本当に素晴しい会議だ)があり、本書のような良書が生れ、多くのrubyistを拡大再生産している。持続可能なコミュニティはその文化を明示的に外に示し新人をリクルートする。素晴しいことである。

本書はRubyコミュニティの豊かさの象徴であると言っても過言ではないと思う。皆様にお勧めする。

-------------------------------
読んでいて気がついた誤殖など。
p53
誤:a >> 1  #=> 0b100
正:a >> 1  #=> 0b110
誤:a << -1 #=> 0b100
正:a << -1 #=> 0b110

p71
誤:p story[8, 7]     #=> "Grundy"
正:p story[8, 7]     #=> "Grundy,"
誤:p story[8...15]   #=> "Grundy"
正:p story[8...15]   #=> "Grundy,"

-------------------------------
索引について。

宇宙船演算子(p52)という見出しはあるが、"<=>"での見出しはない。ところがp36で<=>が初出するが何の解説もないので読者はp52を読むまで理解できない。索引で<=>の見出しがあれば、とりあえづそれを引いて疑問は解決する。

後方参照について

後に説明する項目については、多くの場合、明確にどこどこで説明すると明示してあるので安心して読みすすめる。下記は、いくつかの例外。

p112
def some_method(param = nil)
この構文(デフォルト値をあたえる)についていきなり解説なしで登場し、とまどった。

-------------------------------
p124
本章で扱っていないこと
イテレータとでているが、p119 6.3.6 イテレータを解説しているのではと思う。

p130
階乗の定義で、わたしなら再帰で書くなあと思った。
def fact(n); if n==0 then 1 else n*fact(n-1) end end

vi はじめに
File.chmodとFile#chmodの違いというのが結局どこらへんにあるのか良くわからなかった。

-------------------------------
本書を越える範囲のことについて

続編があるとしたら(勝手に期待するところであるが)、以下についてRuby風のお作法をぜひ読みたい。

テストの仕方
デバッグの仕方
性能のチューニング方法

-------------------------------
『初めてのRuby』サポートページ
http://yugui.jp/wiki/hiki.cgi?LearningRuby
『初めてのRuby』正誤表
http://yugui.jp/wiki/LearningRuby-Errata

プログラマ一年生のパッチと大物ハッカーのコード

取締役退任。生涯一プログラマ宣言。」には大変な反響をいただいた。ここに記して御礼の気持ちとさせて頂く。トラックバック、ブックマークコメントなど可能な限り読んだ。過分のおほめ、励ましの言葉にあずかり、大変光栄に思う一方で厳しいお言葉も頂戴し皆様のご期待にそうよう一層精進していきたいと思った。

さて、プログラマ一年生である。最近では、MID (Mobile Internet Device)の開発にいそしんでいる。CPUもIntel Centrino Atomプロセッサだ。

ソフィアシステムズ Peartree用OS Asianux Mobile Midinux 2.5Jである。
http://www.sophia-systems.co.jp/ice/intel/Atom/PEARTREE/

インストーラを作っているのだが、先日ブートローダ(syslinux/extlinux)のバグに遭遇しそれを直すパッチを作成した。メーリングリストに報告したのが、7/2 18:35:14 PDT(米国西海岸夏時間)である。それに対する返事が、同日19:57:02 PDT(米国西海岸夏時間)、一時間ちょっとで、さっそく取り込んでくれた。その返事も素早いが、それだけではなく、リファクタリング(コードの改良)もしてくれた。

So it does (although the *real* problem is the lack of the stat and
device number comparison.)  I just applied a (slightly different) patch
to this and pushed it out as 3.71-pre3; could you try it out?

よしおかの超訳:バグだね(本当の問題はstatと装置番号の比較がなかった事だけど)。この問題に対するパッチ(ちょっと変更したコード)を適用し、それを3.71-pre3にいれておいた。試してみてくれる?

バグのあったコードは下記の部分である。細かい理解は必要ない。単にパターンマッチをして、上のif文と下のif文が対称じゃないことがわかればいい。

  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
    while ( (mnt = getmntent(mtab)) ) {
      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

  if ( !devname ) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
      while ( (mnt = getmntent(mtab)) ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

マウントされているファイルシステムのうち、ext2/ext3ファイルシステムを検索しているのであるが、上の部分は/proc/mountsで検索し、それがみつからなければ/etc/mtabで検索している。コードをじっくり眺めてみれば、下の部分のwhile(){...}で

      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {

という比較がすっぽり抜けおちている。まあ、わかってしまえばトリビアなバグなのであるが現象としては謎であった。

なので、さっそくquick and dirty hackで下記のパッチを先のメーリングリストに投げたのである。

--- extlinux.c.orig    2007-02-10 20:47:08.000000000 +0000
+++ extlinux.c    2008-07-02 15:20:20.000000000 +0000
@@ -708,8 +708,13 @@
     /* Didn't find it in /proc/mounts, try /etc/mtab */
     if ( (mtab = setmntent("/etc/mtab", "r")) ) {
       while ( (mnt = getmntent(mtab)) ) {
-    devname = mnt->mnt_fsname;
-    break;
+        if ( (!strcmp(mnt->mnt_type, "ext2") ||
+              !strcmp(mnt->mnt_type, "ext3")) &&
+             !stat(mnt->mnt_fsname, &dst) &&
+             dst.st_rdev == st.st_dev ) {
+       devname = mnt->mnt_fsname;
+      break;
+    }
       }
     }
   }

7行追加のパッチである。まあ、素人目にはこれで一件落着である。

個人的には、ソフトウェア変更における、修正量最小化の法則、修正個所局所化の法則にのっとっているので、美しくはないかもいれないが、quick and dirty hackとしては合格点かと思った。

メンテナのちょっと変更したパッチというのが下記だ。

diff --git a/extlinux/main.c b/extlinux/main.c
index 0edce5a..819f74b 100644 (file)
--- a/extlinux/main.c
+++ b/extlinux/main.c
@@ -801,6 +801,32 @@ static int validate_device(const char *path, int devfd)
   return (pst.st_dev == dst.st_rdev) ? 0 : -1;
}

+#ifndef __KLIBC__
+static const char *find_device(const char *mtab_file, dev_t dev)
+{
+  struct mntent *mnt;
+  struct stat dst;
+  FILE *mtab;
+  const char *devname = NULL;
+
+  mtab = setmntent(mtab_file, "r");
+  if (!mtab)
+    return NULL;
+
+  while ( (mnt = getmntent(mtab)) ) {
+    if ( (!strcmp(mnt->mnt_type, "ext2") ||
+         !strcmp(mnt->mnt_type, "ext3")) &&
+        !stat(mnt->mnt_fsname, &dst) && dst.st_rdev == dev ) {
+      devname = strdup(mnt->mnt_fsname);
+      break;
+    }
+  }
+  endmntent(mtab);
+
+  return devname;
+}
+#endif
+
int
install_loader(const char *path, int update_only)
{
@@ -808,11 +834,6 @@ install_loader(const char *path, int update_only)
   int devfd, rv;
   const char *devname = NULL;
   struct statfs sfs;
-#ifndef __KLIBC__
-  struct mntent *mnt = NULL;
-  struct stat dst;
-  FILE *mtab;
-#endif

   if ( stat(path, &st) || !S_ISDIR(st.st_mode) ) {
     fprintf(stderr, "%s: Not a directory: %s\n", program, path);
@@ -848,35 +869,17 @@ install_loader(const char *path, int update_only)

#else

-  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
-    while ( (mnt = getmntent(mtab)) ) {
-      if ( (!strcmp(mnt->mnt_type, "ext2") ||
-           !strcmp(mnt->mnt_type, "ext3")) &&
-          !stat(mnt->mnt_fsname, &dst) &&
-          dst.st_rdev == st.st_dev ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
-  }
-
-  if ( !devname ) {
+  devname = find_device("/proc/mounts", st.st_dev);
+  if (!devname) {
     /* Didn't find it in /proc/mounts, try /etc/mtab */
-    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
-      while ( (mnt = getmntent(mtab)) ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
+    devname = find_device("/etc/mtab", st.st_dev);
   }
-
-  if ( !devname ) {
+  if (!devname) {
     fprintf(stderr, "%s: cannot find device for path %s\n", program, path);
     return 1;
   }

   fprintf(stderr, "%s is device %s\n", path, devname);
-
#endif

   if ( (devfd = open(devname, O_RDWR|O_SYNC)) < 0 ) {

ちょっとどころの騒ぎではない。全面改訂。随分コード量が増えている。

元のコードでは、if文でext2/ext3の比較をくりかえしていたのを、ばっさりカットして、find_device()という関数にまとめた。

そのおかげで、下記のように本体はすっきりした。

  devname = find_device("/proc/mounts", st.st_dev);
  if (!devname) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    devname = find_device("/etc/mtab", st.st_dev);
  }

繰り返しをまとめるという基本中の基本である。ext2/ext3への比較などはfind_device()という新規に作った関数に閉じこめている。すっきりリファクタリングである。

syslinux一年生のコードをリファクタリングまでしてとりこんでくれたのである。

わたしは、著者のH. Peter Anvin (超大物カーネルハッカー)に会ったことも話したこともない。彼は、見ず知らずのどこの馬の骨ともわからない人間のパッチを軽やかに咀嚼して取り込んだのである。

ここまで一時間ちょっと。

オープンソースそしてバザールモデルというのはとてつもないソフトウェア開発方法論である。

まだまだ学ぶ機会に満ちている。素晴しいではないか。愉快ではないか。

gitによるコード。http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blobdiff;f=extlinux/main.c;h=819f74b5308bac7540fcdb580f94f93cde28d82e;hp=0edce5a597b65dfeb04764aa84582ce1e18dcfd7;hb=537164d509a4227416f6ac5b44c0030d6c79cb41;hpb=2b7251b3905e58ef5c34bb4b009ae537eb1b9333

メーリングリストでのやりとり。http://syslinux.zytor.com/archives/2008-July/010245.html
http://syslinux.zytor.com/archives/2008-July/010247.html

取締役退任。生涯一プログラマ宣言。

6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。

ここにご報告する。

さて、ここからが本題(?)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。

2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロジェクトの立ち上げ、さらには未踏ソフトウェア創造事業や日本OSS推進フォーラムのサーバ部会での仕事などが思い出深い。取締役として経営に貢献したというよりも技術屋としての立場だったかと思う。正直言えば、経営者としては力不足であった。

8年前にはLinuxをエンタープライズ分野で利用するなどというのはほとんど冗談のように受けとられていた。誰が氏素姓のわからないフリーソフトウェアを企業の基幹システムに利用するのか。サポートはどうするのか。どのようにスケーラビリティを確保するのか等々。それぞれの課題について一つ一つ解決していったのがこの8年だったと思う。

オープンソースソフトウェアという未開の耕地にビジネスの種を植えた8年であった。

今後は一プログラマとして会社やコミュニティへ貢献していきたい。今年でわたしは50歳になる。いい年したおっさんである。とっとと技術屋なんかは引退してマネージメントの仕事でもしていろよという声も聞く。40代はミラクル・リナックスの取締役としての立場(?)もあったわけだが、それも退任したことだし、50代は、わがままを言って現役のプログラマに戻してもらった。はたしてプログラマとして使いものになるのか、ならないのか、不安がなくもない。この年で新しいことにチャレンジすることの難しさも知らないわけではない。

人生、綺麗事ばかりではない。いいこともあれば悪いこともある。上手くいくこともあれば上手くいかないこともある。成功もあれば失敗もある。家族には苦労をかけて申し分けないと思う。給料も役員報酬がなくなったので減ってしまった。子供の教育費も家のローンもある。

それでもと、思う。人生再チャレンジである。いくつになってもチャレンジである。

潔くない生き方かもしれない。ばたばた足掻いている。この歳でまだプログラマに拘るというのも相当見苦しい。でも、それがわたしなんだよなあと思う。

現在のプロジェクトはMID (Mobile Internet Device)向けのOS開発である。Intel Atomプロセッサ用のOS (Asianux Mobile Midinux)の開発を行なっている。20代の若手エンジニアの隣に座って日々ブートがどうだとかドライバが動くとか動かないとかをやっている。新人プログラマの一人として毎日勉強だ。grubのソースを読んだりsyslinuxのソースを読んで、SSD(Solid State Disk)が認識したとかしなかったとか一喜一憂している日々である。

カーネル読書会も続ける。このペースで開催していけば来年には100回になるだろう。第100回はゲストにLinusを呼びたいと思う。こんな事を言うと多くの人は笑う。だけど言葉にして言う。Linusを呼ぶことは簡単ではないけど不可能ではない。

次の10年自分はどのように生きたいのか。経営者ではなく一エンジニアとして生きいくのが自分の長年のユメであった。

ハッカーになりたい。ソフトウェアによって社会をよい方向へ変えたい。

こんなことを言うと頭がおかしいのじゃないかと言われる。暑苦しく、うざいと思われようとも、そのような人生をおくっていきたい。50代でプログラマを続けることは日本という地域では簡単ではない。そのくらいのことは理解している。道は遠く険しい。だけど、それも不可能ではないとも思う。職業としてのプログラマに誇りを持って生きていきたい。

日本に一人くらい、こんなへんなおやじのプログラマがいてもいいと思う。そういう我儘を許してくれるミラクル・リナックスそして家族には大変感謝している。

これがわたしの生涯一プログラマ宣言である。

皆様のご指導ご鞭撻よろしくお願いいたします。

会社情報 採用情報 個人情報保護方針 商標等取り扱い事項 English
Copyright(c)2000-2006 MIRACLE LINUX CORPORATION. All Rights Reserved.