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

プロフィール

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

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

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

ミラクル関連リンク

採用情報

サイト検索

最近のトラックバック

2008年8月

          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
31            

プログラミングキャンプ

この夏、8月13日から17日まで、セキュリティ&プログラミングキャンプ2008というの企画した。わたしも講師の一人として、プログラミングキャンプに参加する。

セキュリティ&プログラミングキャンプ2008 http://www.jipdec.jp/camp/
セキュリティ&プログラミングキャンプ2008/ユメのチカラ http://blog.miraclelinux.com/yume/2008/06/2008-7e81.html

わたしのやりたい事。プログラムの楽しさを少しでも若い世代に伝え、仲間を少しでも増し、プログラマがプログラマとしての専門性をいかし生き生きと豊かにおくれる社会をつくること。

高度ICTリーダー論/shi3mの日記http://d.hatena.ne.jp/shi3z/20080807/1218068383

もっと若い相手、たとえば高校生や大学1,2年生などを対象に、もっと幅広い講師を呼んで講演会を開き、刺激を与えた方が「真のトップノッチ」育成には役立つのではないか。

まさにプログラミングキャンプはそのような明確な意図のもと合宿形式でトップノッチの発掘、養成をめざしている。

それにはどのようなカリキュラム(プログラム)がよいのか、今年は初めてなので文字通り試行錯誤の連続である。

わたしは、デバッグの方法、コードリーディング、プログラミング入門をうけもつが、シラバスを作り、プレゼン資料、実習問題、デモの準備など、正直いってへろへろである。はたしてこのような問題設定でよいのか、はたしてこのような教材でいいのか、そもそも、このカリキュラムでいいのか、そのようなことを自問自答しながら七転八倒し教材を作成した。

まだ実際の講義をしていないので、何とも言えないのだが、講義という学生とのコラボレーションでわたしも多くのことを学ぶだろうし、多くのことを経験するだろう。そしてそのフィードバックは次に生かしていくつもりである。

単にプログラマとしてひいでているだけではなく、コミュニティのリーダとして人々に信頼され、尊敬されるような人材と巡り会いたい。養成とか育成とか、そのような上から目線ではなく、可能性を持つ人々を発掘し、生き生きとその才能を開花させるような環境を作りたい。

そのためにはその中間地点として、彼らがその才能を十二分に発揮できる環境を作るのがわれわれ大人の仕事で、それは具体的には、彼等を雇用できるようなビジネスを創出することが最ももとめられていることである。

Googleに多くの若い才能が結集しているのは、それは我々が十分彼らの才能を生かす仕事場を提供していないからである。日本のタレントを流出させているのは、我々がそのプレイグラウンドを提供していないからである。

その意味で、id:mkusunok の指摘は正しいと思うが、
geek虎の穴をつくろう/雑種路線でいこう http://d.hatena.ne.jp/mkusunok/20080807/ito

恐らく優秀なプログラマーなら日本にも少なからずいる訳で、私塾ではgeekに対してグローバルな視座や搾取されないだけのビジネススキルを獲得できる機会を提供し、geekだけでなく、彼らが活躍できる環境を整えることのできるようなサポーター、具体的には優れたビジネスマネージャやマーケティング、政策立案者も育てる必要がある。手をつけられそうなところから具体的なカタチにしていきたい。

育てるだけではなく、そのような社会環境を作るのが我々の仕事である。今まさに楠さんや清水さんにはそのような役割が求められているのである。

第89回カーネル読書会

第89回カーネル読書会のおしらせ

日時:08月22日、18時半開場、19時ころ開始

お題: Ottawa Linux Symposium 2008出張報告
発表者: 中村(日立ソフトウェアエンジニアリング)さん、須崎(産業技術総合研究所)さん、吉藤(Usagi Project)さん、大和さん(ミラクル・リナックス)、海外(NEC)さん(順不同)飛び入り発表歓迎です。
内容: OLS2008参加の皆様に今年度のOLSについてお土産話をしていただきます。技術的なことから、単なるオタワ旅行記まで、硬軟とりまぜ、ざっくばらんに語っていただきます。

18:30頃、開場、LTないし自己紹介など
19:00頃、お題開始
20:00頃、懇親会開始

場所は楽天タワー
http://www.rakuten.co.jp/info/map/shinagawa.html
●りんかい線「品川シーサイド駅」出口Cより徒歩1分
(1-minute walk from SHINAGAWA SEASIDE Station, RINKAI LINE)

●京浜急行線「青物横丁駅」より徒歩7分
(7-minute walk from AOMONO-YOKOCHO Station, KEIHIN-KYUKO LINE)

会場の都合上、18:30より以前には開場しませんので、ご注意ください。また受付の都合のため、なるべく遅刻のないようにお願いいたします。

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。(予定価格1500円。微妙に値上がり中)懇親会参加希望の方は、懇親会参加と明記してください。
学生さんは無料なのでそれも明記してください。

会場の都合で80名で締切ます。

なおセミナー内容につきましては、にこにこ動画などで配信予定です。ustream.tvでのインターネット中継も可能であれば実施します。チャンネル名は未定

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel080822

YLUG年表
http://www.ylug.jp/modules/pukiwiki/index.php?history

YLUG会合、読書会資料
http://www.ylug.jp/modules/pukiwiki/index.php?reading

初めての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

Emacs勉強会 - tokyo-emacs

Emacs勉強会に参加した。なんやかんやで30人を越える参加登録である。

自分は随分昔からEmacsを利用しているのだが、全然使いこなしている感じがしない。最近、Emacsを勉強しなおそうと思っていたので、早速参加することにした。

http://wiki.livedoor.jp/harg/d/FrontPage

Emacsの基本を勉強しなおそう市民連合(笑)の代表として一言挨拶をした。今回は同市民連合の決起集会(嘘)なので、大いにアジったのであるが、みんなでEmacsの基本を勉強しなおしたいと思った。

早水さんのEmacs Lisp講座は初心者に向けての優しい講座であった。

メモをはりつけておくが、これだけじゃあ、何が何だかわからないなあ。

Emacs Lispは怖くない
括弧は空気
EmacsのことはEmacsに聞け
  ヘルプの使い方
Lispは単純
リストが全て
  ドット対
関数名と変数名の名前空間は別

実践編
.emacsを眺める
  (server-start)
  ansi-term
入門書
  もうひとつのScheme入門
  独習Scheme三週間
  プログラミングGauche
---------------------

files.el

K1LoW
  moz.el
  pabbrev.el
  dabbrev.el

  drill-instructor.el

yuki_neko_nyan
  yasnippet

jj1bdx
  face
  color-theme

IMAKADO
  anything
  補完が凄い

Misho
  Emacs for Latex

naoya_t

.emacs
  IMAKADO

Emacsについて語り合う人が自分のまわりにいない人達にとってtokyo-emacsはとてもいいところだ。大変勉強になった。懇親会で、メモ用紙にマクロの解説をしている早水さんや、それを囲んでわいわいがやがや議論している。楽しかった。またやりたいと思った。

早水さん、参加の皆さんお疲れさまでした。ありがとうございました。

追記:資料を公開した。tokyo-emacs-080628.pdfをダウンロード

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者:西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf


セキュリティ&プログラミングキャンプ2008

ソフトウェアは人が作る。人がすべてだ。

若い人が魅力を感じなければその産業は衰退する。若い人にとってソフトウェア産業が魅力的なものだということを我々はもっと伝えないといけない。ビジョンを示し、その魅力を伝える努力をしないといけない。

一方で少しでも興味を持ってくれた人にソフトウェアを作ることの楽しさおもしろさ難しさを伝えることも必要だ。

人材育成だなんだと大げさにとらえるのではなく一緒にプログラミングの楽しさを経験したい。初心に戻ってプログラムを初めて作ったころの感動を体験したい。

22歳以下の皆さん。

あなたたちのために、そのような合宿を企画した。

セキュリティ&プログラミングキャンプ2008 http://www.jipdec.jp/camp/

『若年層のセキュリティ意識の向上と優秀なセキュリティ人材の早期発掘・育成』という目的で2004年からやっているセキュリティキャンプがきっかけだ。合宿形式で行うセキュリティ人材育成のイベントのプログラミング版だ。

U-20プログラミングコンテストで若い人たち(中学、高校生)のプログラムを読む機会があるが、やはり回りに相談する人がいないのか、プログラムの基礎的なことなどの理解が足りていない。例えばif文を延々と重ねて処理をするとか、いたるところに数字(定数)が書かれていたりとか、そーゆー力ずくのコードを目の当たりにみて、コードを書くにしても基礎的なイロハの伝授が必要であるということを痛感していた。

コードの書き方だけではなく、デバッグの仕方とか、gitをはじめとする分散バージョン管理システムあるいはOSSを前提としたコラボレーションのちょっとしたコツとか、必ずしも明文化されていないがとっても重要なことについて学ぶきっかけを作りたかった。

もちろん、その先にあるプログラムを作ることの楽しさ、達成感、充実感なども共有したい。

わたしのミッションステートメントをここに記す。プログラミングキャンプ宣言だ。

    *  オープンソースソフトウェアを開発する元気のいい若手プログラマを輩出したい。
    * 単にプログラミングテクニックが凄いというだけではなく、コミュニティのリーダとして、人々の話をよく聞き(コミュニケーション能力)、信頼されるようなプログラマを輩出したい。
    * 彼等が今後の核になってさらに新しい人材を発見発掘するというエコシステムを作りたい。
    * 彼等が新しい価値を創造し、世界から尊敬されるような人々になって、日本という地域が、そのような人々が集まるような場所にしたい。

10年で200人。

これが、わたしのユメだ。

そのような若者を雇用するビジネスを作るのが大人の役目である。

多くの若者の応募を待つ。

勉強会のこと

ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。

最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。

まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。

https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com

本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.ne.jp/hanazukin/)が個人で編集されているものなので、おそらくもれや抜けはすくなからずあるだろう。例えば、仲間うちでやっている読書会とか、広く募集していない勉強会などは当然載っていない。

これらの勉強会の特徴を一つだけあげるとしたら有志がボランティアでやっているものだ。商用のセミナーではない。IT系のカレンダーなので、業界の人達が集まるLinux World Expoとかの日程などももちろん掲載されているが、圧倒的多数はボランティアが自主的に開催している勉強会である。

個人が主催しているので、会費も無償か、あってもかかった経費を割り勘というのが多い。

内容も千差万別だが、それにしてもこれだけのコンテンツをほぼ無償でよりどりみどり勉強できる環境がこの地にはある。

勉強会によっては、勉強会のあと懇親会(宴会だよ宴会)がついてくる。これがまた楽しい。カーネル読書会は宴会があってのカーネル読書会のようなものである。

発表者に直に質問する絶好のチャンスである。宴会で隣に座った人が実は業界で知らぬ人はいない神様みたいな人だったりすることもある。あるいは一度も会ったことはなかったけど日記は良く読んでいたという、ああ、あの人かという人だったりすることもある。

確かに初めて勉強会に行くのはちょっとした勇気が必要だ。周りの人は皆初対面だったりするのはなかなか踏ん切りがつかない。行っても打ち解けないかもしれない。常連の人達は楽しそうにやっているかもしれないが部外者が行っても場違いではないか。などなど行かない理屈はいくらでもつけられる。

しかし、別にそんなに大袈裟に考えることはないと思う。ためしに行ってみて、だめだったら、自分にあわなかったら、別の勉強会に行けばいいだけの話だ。経済的なダメージがあるわけではないし、何がしかの知識が得られ、ひょっとしたらもっとすごい何かを得られるかもしれないチャンスなのである。

だめもとである。

いろいろな勉強会に参加してみて本当に思うのだが、このゆるい参加者の繋がりはとてつもない可能性を持っている。

カーネルの技術者もいれば、Web 2.0の開発者もいる。Perlのエラい人もいれば、Rubyの開発者もいる。ユーザーもいればばりばりのハッカーもいる。皆楽しそうにくっちゃべっている。わたしみたいにビールでヘロヘロになりながらキャッシュミスがどーだこーだなどと延々ヨタ話をかましている奴もいれば、大所高所から日本のIT産業の未来について、おまえはこの国の首相かみたいなツッコミを入れたくなるような論調でべきろんをぶっているやつもいる。

若い人もいれば年寄もいる。

オープンソースの技術論についてはとどまる事をしらない。MySQLやPostgreSQLのスケーラビリティについて、それこそ重箱の隅をつつきながら議論している。LAMPなどの定番のオープンソースについては共通の基盤として語彙がそろっている感じである。

そして単なる参加者だけではなくより積極的に発表者になろうというのが、1000人スピーカプロジェクトである。

http://ja.doukaku.org/wiki/index.php/1000speakers

自分を晒そう
恥ずかしがるための プライドなんて捨てちまえ!
それが自分のためにも 人のためにもなる

1000人スピーカ プロジェクトは、発表経験の少ない人に「自分の技術をさらけだす場」を提供することを目的としたプロジェクトです。

カンファレンスで自分のやったことについて発表することはとても重要です。しかし、参加者が100人を超えるようなカンファレンスで発表するのは敷居が高いです。また、そういうカンファレンスではどうしても参加者同士のつながりが薄くなりがちです。そこで、30人程度の規模のカンファレンスを繰り返し行うことで、敷居を低く、間口を広く、密度を濃くしていこうと考えています。

これだよこれ。こーゆープロジェクトがどんどん増えていって、勉強会の幹事もどんどん増えていって、参加者も発表者もどんどん増えていって、知が流通している。そんな実感がある。

日本にはGoogleはない。

だけど嘆くことはない。

われわれは勉強会、読書会という知のネットワークをここに持っている。

そしてプラットフォームとしてのインターネットを使いこなしている人々がいる。

巨大なバーチャルな学びの場をわれわれは持った。梅田望夫が「私塾のすすめ」で語っているような「私塾」があるような気がする。

参考:

カーネル読書会に必要なことは宴会で学んだ/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/08/post_5135.html
勉強会の幹事に向けて書いた。勉強会の運営のイロハである。

ちょっとした勇気と行動力(オフ会編)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/12/post_fbd6.html
こちらは参加者へのメッセージだ。最低限、初対面の人と知り合いになろう。名刺交換をしようという、ちょっとしたコツを伝授(大袈裟だな)している。

勉強会でのエピソードなども早速ブログのネタにしちゃったりする。

Web2.0時代のソフトウェア開発のスピード/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/web20_5b1a.html
勉強会の後の懇親会で教えてもらったエピソードをネタにしちゃっている。金曜日の飲み会で企画会議をするという。

そしてこのエピソードはいろいろなところで使い回しをさせてもらった。
NDD (Nomikai Driven Development)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/ndd_nomikai_dri.html

カーネル読書会のめざすもの/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_d222.html
なぜ、わたしはカーネル読書会なるものを始めたのかについて記した。

カーネル読書会とよしおかの野望/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
ゆるい感じのカーネル読書会の実態を記している。

OSSの技術カンファレンス、縦串横串/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/oss_f5f1.html

日本にはGoogleはないけど、OSの専門家やRDBMSの専門家やWebアプリケーションの専門家がバーチャルにコラボレートして世界にないものを創造していく、そーゆー緩い場ができると面白いなあなどど最近思っているのだ。それを東京と言う地域でやれないかなあと。

1000 Speakers Conference/ユメのチカラ
http://blog.miraclelinux.com/yume/2008/02/1000-speakers-1.html
先に紹介した1000 Speakers Conferenceに参加した時のレポートだ。発表がニコニコ動画にアップされているのも嬉しい。インターネットのおかげで時間も空間も超越できるようになった。

Linux World Expoのパネルディスカッションに参加します

明日(5月29日)、Linux World Expoのパネルディスカッションに参加します。

http://www.idg.co.jp/expo/lw/lw2008/details/index.html#a27

日本SGIの高澤さんの司会で、キヤノン株式会社、志田惠昭さん、横河フィールドエンジニアリングサービス株式会社、丸茂晴晃さんらと人材育成をテーマに議論する予定です。

どんな話になるかは、その場のノリみたいな感じが強いのですが、お時間ありましたら、参加してください。

群衆の叡知(えいち)サミット2008 - (WOCS2008Spring)

群衆の叡知サミット2008に参加した。http://techstyle.jp/wocs/2008spring/

パネリストはわたしも含めて下記の方々。
# 伊藤久美氏(IBMビジネスコンサルティングサービス株式会社)
# 伊藤直也氏(株式会社はてな)
# 伊藤佳美氏(日本ユニシス株式会社)
# 生越昌己氏(WASP株式会社)ブログ
# 楠正憲氏(国際大学グローバル・コミュニケーション・センター)
# 鈴木友峰氏(日立製作所)
# 田代秀一氏(独立行政法人情報処理推進機構)
# 谷川正剛氏(株式会社Prediction)
# 徳力基彦氏(アジャイルメディア・ネットワーク)
# 西田隆一氏(CNET Networks Japan)
# 福岡秀幸氏(日本電気株式会社)
# 山口浩氏(駒澤大学グローバル・メディア・スタディーズ学部)
# 吉岡弘隆(ミラクル・リナックス株式会社)
# チェア:岡田良太郎氏(株式会社テックスタイル)

ustream.tvでの中継(今回はじめての試み)、会場から携帯を利用した集計システムなどインタラクティブな仕掛、休憩時間にはアイスクリーム(美味)やドーナツの配布、ドリンクサービスなどいたれりつくせりのおもてなしでなかなか楽しいイベントであった。

http://www.ustream.tv/channel/wocs2008spring

セッションの内容についてはustream.tvで確認いただくとして、今回参加したなかでいろいろ感じたこと主張したことなどを雑駁ではあるが記してみたい。

オープンソースについて

群衆の叡知あるいは集合知の成功例としてオープンソースソフトウェアという認識のもといろいろ議論をさせていただいた。

オープンソースソフトウェア特にLinuxの成功については鈴木さんのプレゼンが上手にまとまっていると思った。のちに生越さん(おごちゃん)がオープンソースはお花畑かよ、というツッコミがあったが、それはそれとして、成功例の一つとしてLinuxがあることは間違いない。

群衆の叡知が成立する条件として、参加者の多様性、独立性、分散性、集約性などが担保されている必要がある。

Linuxの場合、gitという分散バージョン管理システムで、ソースコードを管理しているが、そのログによれば、2.6.12から最新版までに、約97000のパッチが約4000人の人達によって投稿されている。emailアドレスによる分析では250を越える所属(会社など)。

Top changeset contributors by employer        
(Unknown)        28613     (29.6%)
(None)            9034     (9.3%)
Red Hat           8029     (8.3%)
Novell            7518     (7.8%)
IBM               6683     (6.9%)
Intel             3201     (3.3%)
Linux Foundation  2800     (2.9%)
SGI               1824     (1.9%)
Oracle            1471     (1.5%)
SWsoft            1353     (1.4%)
Others           26300     (27.2%)
Processed 96826 csets from 4032 developers
257 employers found
A total of 14088649 lines added, 4699892 removed (delta 9388757)
as of 5/16/2008

この例からも分るとおりLinuxの開発は参加者の多様性、独立性、分散性、集約性などがある。

特筆すべきは、4割近い人々(所属がUnknownないしNone)が、業務としてパッチを投稿しているのではないという事である。昨今Linuxの開発は大企業によって推進されているという指摘もあるが、確かにその側面もあるにはあるが、Red Hat/Nobel/IBMという御三家それぞれ10%以下のシェアであり、今だに多くの貢献は、個人ないしは小企業に属する人々によってなされているという典型的なロングテールの開発であるという事である。

4000人の開発者はどのような思いで、そのパッチを作ったかは4000通りの回答があると思う。仕事であったり純粋に楽しみであったり人それぞれである。それを集約したのがLinux Kernelという事になるかと思う。

社内ブログと人材流動性

群衆の叡知が成立する条件として、参加者の多様性、独立性、分散性、集約性などが担保されている必要があると先にのべた。

企業内で、SNSや社内ブログで、叡知を結集するためには、上記の条件を意識してクリアしないといけない。そこが社内SNSなどの難しさの一旦である。またイノベーションが発生するためには、何らかの形でも新しい結合(出会い)が必要で、部門間を越えた結合を制度として設計し実装することが必要条件となる。NECの福岡さんの報告にあったようにNECの社内SNSはそれをファシリエータと呼ばれる人々によってドライブしているようである。

福岡さんは、社内SNSなどをEGM (Employee Generated Media)という概念で説明していた。さらに、会社の枠を飛び越えたEGMの可能性を指摘していたが、正直ビジネスの分野では非常に難しいと感じた。

そのような知恵は、会社に所属するのではなく個人個人に属するものだと思う。であるならば、その属人的な知恵は会社内あるいは会社間SNSで閉じ込めるのではなく広く公開したほうが社会にとっても有益である。しかし、暗黙知を形式知にするようなもので、それはそれで難しい。であるならば、人材流動性を前提として、その属人的な価値を、人材とともに流通するような仕組を考えた方が実現可能性が高い気がする。

日本の労働慣行は、長期間な雇用を前提としている。終身雇用と言わないが2年半で会社を変えるというスタイルではないので人とともに重要なノウハウが業界でゆるく共有されるということもない。

一方シリコンバレーのIT産業であれば、例えばRDBMSの実装について、人々の転職によって、業界全体で緩く共有されている。あるいは大規模トランザクション処理のTipsが緩く共有されている。さらに共有基盤としてOracleなどの商用ソフトだけではなくMySQLなどのOSSを利用した運用ノウハウがコミュニティの暗黙知として様々な形で流通している。

そして上記のような状況がシリコンバレーの地域的な競争力を高めているとするのなら、日本という地域でも意識して、人材を流動させることにより、その環境を作ることが可能なのではないか。

事実、大企業ではなくWeb2.0系の会社(はてな、mixi、ドワンゴ(ニコ動)、Gree、ライブドア、Yahoo等々)に所属する若手のエンジニア達は、いろいろな勉強会あるいは読書会などで、自分たちの問題を等身大で語り初めているではないか。隣に座ったPerlのエラい人達と対等に語りあっているではないか。ビジネスとしては競合する会社に勤めている人達が同じ場で自由に情報交換をしている。

そしてOSSの利用技術について暗黙知を形式知に転換したり、バッドノウハウとして情報交換している。

まさに、そこに集う人々は多様性、独立性、分散性、集約性などが担保されている状況が発生しつつある。

東京という地域では、結果として、そのような技術者のルツボがあり、新しい出会いがあり、イノベーションの萌芽が、見られる。

感想など

まだまだ語りたいことはてんこ盛りなのであるが、紙面がつきたので、このくらいにしておきたい。

最後になったが、素晴しい機会をあたえてくれた岡田さん、気持のいいおもてなしをしていただいたスタッフの皆さん、活発な議論をしていただいたパネリストの皆さん、ustream.tvでの参加者、そして会場に参加していただいた皆さん、大変ありがとうございました。皆さんのおかげで大変楽しい時間を過したと共に自分の考えをまとめるキッカケ、気付きのヒントを多数いただいた。お腹いっぱい、すっきりしました。

ありがとうございました(ぺこり)

付録:Linux Kernel Source Codeの分析について

下記にあるgitdmというpythonのスクリプトを利用した。pythonおよびpython-egenix-mxdatetimeなどのパッケージをインストールしておく必要がある。
http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history/

Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか?/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/who_wrote_2620__4b18.html

カーネル読書会/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_da8e.html
GregKHがLinux開発者のプロフィールの分析を発表した。後のOttawa Linux Symposiumでの論文のモトネタとなる。

Greg KHの論文
http://ols.108.redhat.com/2007/Reprints/kroah-hartman-Reprint.pdf

追記:WOCS2008springに言及のあるブログ、日記など。

歌舞伎町で遇ったギークなタクシー運転手の編み出した、群衆の英知を活かした馬券購入法/雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080521/wocs

群衆の叡智サミット2008Spring行って来た/public static void main
http://d.hatena.ne.jp/Kishi/20080522/1211419795

第87回カーネル読書会のおしらせ

毎度おなじみ流浪の番組、カーネル読書会のご案内です。

今回は場所を日本SGIホールにしました。初めての方もそうでない方も奮ってご参加ください。

第87回カーネル読書会のおしらせ
日時:05月23日、18時半開場、19時ころ開始
会場:日本SGIホール、恵比寿ガーデンプレースタワーB1F
http://www.sgi.co.jp/company_info/map1.html
(場所は恵比寿ですのでお間違えのないよう)

お題:Linux Network Stack
 〜UDPメモリ管理の改善とNetwork Subsystemの現状と課題〜
発表者:大島 訓さん(日立製作所システム開発研究所Linux Technology Center)
概要: 
 2.6.25で採用された「UDPのメモリ使用量を計測し、上限を設定する機能」について、開発の動機、netdevでの議論の経過、実装、裏話についてご紹介します。また、Linuxのネットワーク
機能の現状を整理し、今後取り組むべき(と私達が考えている)課題をご紹介します。
 今回の内容は、3月にLinux Foundation Japan Symposiumで講演した内容がベースですが、YLUG向けに”濃い”話をします。

18:30頃、開場
19:00頃、お題開始
20:30頃、懇親会開始

場所は日本SGIホール、恵比寿ガーデンプレイスタワー B1F
http://www.sgi.co.jp/company_info/map1.html

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

懇親会はいつもの銀座ライオンが予約とれなかったので、旬鮮料理 JOE(じょう)其の壱。http://r.gnavi.co.jp/g169302/ 飲み放題コース(予定価格5000円) 、学生さんは1000円ポッキリ予定。(懇親会の会場が変更になっているので注意してください。)
懇親会参加希望の方は、懇親会参加(学割希望者はそれも)と明記してください。

会場の都合で90名で締切ます。

なおセミナー内容につきましては、にこにこ動画などで配信予定です。
ustream.tvでのインターネット中継も可能であれば実施します。
チャンネル名は未定

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel080523

YLUG年表
http://www.ylug.jp/modules/pukiwiki/index.php?history

YLUG会合、読書会資料
http://www.ylug.jp/modules/pukiwiki/index.php?reading

git入門

社内勉強会でgit入門をやった。(参考資料をダウンロード )。

最近の開発でgitを使っているので、そのファーストインプレッションみたいなものである。マニュアルについては、日本語訳もあるので参考にしてほしい。

分散コード管理システムということで従来の集中コード管理システムとその使い勝手が相当違うように感じる。

基本的な使い方は、リモートにあるリポジトリをローカルにコピーして、そのコマンドをgit cloneというのだが、そのレポジトリに対してチェックアウト、チェックインを繰り返し最後にリモートのリポジトリにコミットするという感じである。

基本的には、集中型とそう違わないのであるが、精神的には随分違うという感じがする。

まず、変更はローカルのリポジトリにずんずん行なうという点。ローカルのレポジトリにずんずん行なうので、その時点でリモートにアクセスできなくてもいい。ノートパソコンにレポジトリを用意して、電車の中や街中でちょっとした変更をして、それをノートパソコンのローカルなレポジトリにずんずんコミットする、なんていう使い方ができる。

そこまでモバイルな使い方ではなくても、通常だったら、次のような感じかと思う。まづプロジェクト用リポジトリを準備して、各自は自分の開発マシンにリポジトリを置く。そして、個々の担当は自分のリポジトリにどんどんコミットする。テストが終った変更(コミット)に関しては自分のリポジトリからプロジェクトのリポジトリへpushする。

そんな感じである。

まだ、ありがたみが伝わらない?うーむ、説明が下手ですいません(ぺこり)

基本的には変更はブランチで行なう。ブランチが原則、前提。Linux Kernelの開発のように多数のプログラマによって独立に開発がおこなわれているというプロジェクトの場合、このブランチが原則というのは大変理にかなっているように思う。

また管理の対象もコミット単位(ファイル単位というよりも)というのも理にかなっている。

また各オブジェクトはSHA1のハッシュ値(16進40桁)で管理されているので、同じSHA1値であれば同じオブジェクトであるということがグローバルで担保されている。

ということは、例えばgitの開発ヒストリのログなんかも、本家をコピーしたリポジトリ全てで同一性が保証されている。Linusが最初にコミットしたオブジェクトは、世界中のどんなコピーでもe83c5163316f89bfbde7d9ab23ca2e25604af290という事が保証されている。通常は40桁のハッシュ値の最初の数桁を利用すれば参照できるので、例えば、

$ git-log e83c5163

とすればLinusが開発したgitの最初のコミットのログを見ることができる。すごいすごい。

$ git clone git://git.kernel.org/pub/scm/git/git.git

でソースも読めるのでいろいろ楽しめる。gitを利用したプロジェクトのヒストリの眺め方などという時間軸にそった楽しみ方もあるのではないかと妄想した次第である。

Rebase Early, Rebase Oftenという話をしたかったのであるが、紙面がつきたのでいつの日にか。

カーネルにおけるリグレッションの特定/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_d748.html

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html

勉強をしなおす

いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。

という事で日頃なにげなく使っているEmacsのマニュアルを再読する事にした。会社の机の上にO'reillyの Learning GNU Emacs、Writing GNU Emacs Extensionsそして竹内監訳のGNU Emacsマニュアルがある。竹内監訳のGNU Emacsマニュアルの初版は1988年2月である。20年前である。いくら何でも日進月歩、秒進分歩のIT業界の時間感覚でなくても古すぎるだろうと思わなくもないが、機能がテンコ盛のEmacsにはversion 18ころの古典的な、基本機能をおさらいするには、サイズ的にも丁度いい感じである。

正直に告白すると、Emacsを日々使っているが自分で拡張を書いたりelispで手間仕事をちゃかちゃか片付けるという事はほとんどしていない。何かのきっかけでもないとマニュアルを読みかえすということもほとんどしない。ぐぐればどーにかなる。だけど、一見時間がかかると思えても基本にたちかえってみることは悪い事ではない。

今使っているEmacsは22.1.1だ。Ubuntu 8.04にデフォルトでついてくるやつである。10数年Emacsを使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。

梅田望夫著「ウェブ時代 5つの定理」

シリコンバレーという地域の競争力はどこにあるのだろう。あの底抜けの明るさはいったいなんなんだろう。と思う。

梅田望夫の[ウェブ時代 5つの定理」はシリコンバレーの空気をビジョナリーの言葉によって表現しようと試みている。

梅田にならって、「ウェブ時代 5つの定理」でYahoo!ブログ検索、Googleブログ検索をしてみた。このブログを書いている時点でYahoo!で318件、Googleで約272件とでた。発売されてから1週間たつかたたないかで約300件ほどの記事が執筆されたということになる。それを梅田はすべて読むという。

毎日毎日自著の感想を何時間もかけてへとへとになりながら読む。読み続ける。それはなぜだろうと思う。

素人が書きなぐった感想をひたすら読みまくる。

リトマス試験紙として、「コンピュータによって社会を変える」という言葉を考えよう。あるいは「コンピュータによって社会を変えたい」という願望でもいい。あなたはこの言葉に共感を覚えるか、それともそうではないか。強くそう思う、そう思う、どちらでもない、そうは思わない、強くそうは思わない。

「コンピュータ」という言葉を「プログラム」という言葉に置き換えても、あるいは「技術」に置き換えてもいい。

技術者であるあなたはあなたの技術によって社会を変えたいと思っているのか。いつの日か自分の作った製品が世の中のどこかで使われて、何がしかの利便性を誰かに提供し何がしかの価値を発生させる。その様なイメージをあなたは持つのか。

ハッカーと呼ばれる人は、このプログラムによって何が変わるかをイメージできる人であり、プログラムによって社会を変えたいと思っている人のような気がする。

日本という地域で「コンピュータによって社会を変えたい」などというと、頭おかしいんじゃないの、宗教がかっていて気持ち悪いよと思われなくもない。

しかし、シリコンバレーの地には、そのような技術に対するオプティミズが蔓延しているような気がする。

それが彼の地の競争力の源泉なのだろうか?

もしそうだとしたら、それを日本という地域でコピーできないのだろうか?

ウェブという時代に一人一人が生き生きと幸せに生きるために。

高校時代マイクロプロセッサというものを知って、これで社会が変わると高校生ながら思った。就職してインターネットにふれて、これで社会が変わると新入社員ながら思った。オープンソースとであって、これで社会が変わると思った。

そしてWeb2.0の時代。

PCでもなく、携帯でもない。ワイヤレスブロードバンド時代。次の10年に何が来るのか。

東京の地で若い連中とくっちゃべりながら、この連中によって、いろいろ面白いことが始まっていることを確信する。LL (Lightweight Language)やらLAMPやら軽やかに使いこなす彼らが軽やかにWebサービスを立ち上げ緩やかな連携を会社の壁をいとも簡単に乗り越えて行なっている。

素敵だ。

それを目の当たりにすると、日本始まったな、と強く思うのである。

シリコンバレーの空気を日本語で発信し続け、若い人を励まし、彼がやらない限り世に起こらないことを梅田望夫はやる。

日本ならではの強さとシリコンバレーならではの強さの融合という最終定理に向けてわたしも微力ながら何がしか試行錯誤をしたいと思った次第である。

1000 Speakers Conference

11 1000 Speakers Conference参加した。ミラクル・リナックスで開催した。

わたしの資料もアップしました。ylug_1000speakers.pdfをダウンロード

溝口さん(ドワンゴ)がニコニコ動画にアップしてくれた。ありがとうございます。

わたしは2-13の「カーネル読書会の作り方」でお話をさせていただいた。オフ会的勉強会の実践的開催方法論(おおげさ)について発表したのでぜひ参考にしてほしい。

各、発表はそれぞれ個性豊かで大変面白いものばかりだった。ustream.tvでの中継と、チャットがライブ感をかもし出していた。160人程度インターネット経由で中継を見ていたようである。

その後、懇親会を同会場でピザとビールで行なった後、新橋の居酒屋で二次会をした。