ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
ユメのチカラ: 勉強会のこと
ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。 最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。 まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。 https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com 本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.n
ユメのチカラ: さよならNetscape、こんにちはWeb 2.0
Netscapeのサポートがこの2月に終了するというニュースが昨年末に流れた。それを記念(？)して、「さよならNetscape」というイベントが先日開催された。 一時代を築いたブラウザが世を去るというのは感慨深い。 当日、所用があったので参加できないかと思ったが、帰宅途中渋谷で乗換だったので、ふと気が変って、そのままずんずんイベント会場へ行く自分がいた。 なぜ、そこに引き寄せられたのだろう。気がつくとイベント会場にいた。 会場にはお久しぶりの人達がいっぱいいて、神田さんが誰かが作ったブラウザの年表を見ながら90年代のインターネットの事を語っていた。 ビールを飲みながら皆さんのお話を聞く。NetscapeがAOLに買収されて10年後にサポートを終了する。まあ人はいろいろ失敗の理由を言うが、後づけの理屈のような気がする。 次のビールを飲んでいたらマイクがまわってきた。酔いも手伝って、「モジラの
ユメのチカラ: 未踏オフ会
古川享PM(プログラム・マネージャ)の未踏ソフトウェア創造事業(長いな、以下未踏と称す)のオフ会に参加した。 古川さんの事は30年くらい前から、わたしは一方的に名前を存じあげていたのだけど、直接名刺交換をするのは初めてである。それはともかく、1970年代のマイコン世代の懐しいお話満載で、ASCII出版のころとか、マイクロソフト株式会社設立のころのエピソードなど興味がつきなかった。 最初にパワーポイントのちょっとしたTipsを延々話していたのは笑った。YouTubeのCTOは、パワーポイントも上手に使えないとか、どーでもいい(失礼)エピソードが面白い。 古川亨略歴ということで、ASCII時代の話から入った。 79年11月のASCIIにパーソナルコンピュータはメディアになるというコラムを書いてそれが自分のビジネス、生き方の指針になった。その後、ASCIIでInformixの日本語化、BSD U
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: プログラマの仕事はプログラムを読むことである
ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。 古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。 保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。 Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。（プログラマにとってのReduce/R
ユメのチカラ: メモリアクセスは遅い
多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
ユメのチカラ: ウィキノミクス
マスコラボレーションはいかに世界を変えたか。 ピアプロダクションでは、財産権という概念が逆転する、なんていう話は俄かには理解しがたい現象ではないか。成果物を他者が勝手に利用しないように制限をかけるのではなく、無償で他人に利用させむしろそれを奨励するというようなことが理解できるだろうか。 インターネットによってコストゼロでマスコラボレーションが仮に可能になったとして、その事例を見せられたとして、自分のビジネスには関係ないどこか別の世界で起きていることではないかと思うのがほとんどなのではないだろうか。 自分のこととして理解してあらたな行動をこの本から起こすと言うのはほとんど考えられない。既にマスコラボレーションのことを十分理解しそこにビジネスチャンスがあると考えている人は、この本があろうがなかろうが行動しているだろうし、そうでない人は、この本があろうがなかろうが何もしないだろう。 オープンソー
ユメのチカラ: 人月の神話
Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳 わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。 原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。 第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐
ユメのチカラ: 次の10年
梅田望夫「サバイバルという言葉が嫌いなら使わないで話そうか」(My Life Between Silicon Valley and Japan)が、なかなか刺激的な事を言う。「次の十年」、いまの大学生が三十代に入る頃、さらに加速した変化が「仕事をめぐる世界」「職業をめぐる世界」に起きているだろう。いまは「そういう時代なんだ」ということを認識して「緊張感を持って生きる」ってどういうことかを考えてほしいな。わたしは、若い人に向かって、「〜してほしい」とか「〜すべきだ」なんてことは決して言わない。言うつもりもない。ましてや、「その「異常な事態」を誰かのせいにして何もしない言い訳にして今日を明日をのんびり無為に過ごしたら、そしてそれを続けたら、十年たって本当に後悔すると思うよ」なんて事も言わない。 人の人生である。一人一人の人生である。彼らから直に聞かれたら、何がしかを答えるかもしれない。実際約1
ユメのチカラ: Web2.0時代のソフトウェア開発のスピード
最近、あるWeb2.0系の会社の方たちと勉強会をしているのだが、その勉強会もさることながらその後の懇親会でのユルイ会話が面白い。ていうか、勉強会の後の懇親会が好きでやっているのだろうとかいう突っ込み。否定しません。というか、飲み会に大義名分をつけるために、勉強会と称しているのだろう＞自分 それはともかく、いろいろ面白いお話を伺う。 Web2.0系のサービスってのは、やってみないと分からない類のものが多いのでともかく思いつきでも何でもとりあえづやってみる。だめだったら考え直す。そーゆースタイルらしい、極論すると。 古典的なウォータフォールモデルでのソフトウェア開発だと、だめだったら考え直すなんていうアバウトなことを言ってはいけないという前提で物事が進むから、ともかく石橋を叩きつつ確実に確実に事をはかる。それはそれで確立されたスタイルなので、間違いではないが、プロジェクトを開始した時点と終了す
ユメのチカラ: バザールモデルにおける品質
ソフトウェア開発モデルとしてのバザールモデルというのは従来のソフトウェア開発モデルとまるっきり違うので、簡単に対比して考えてみる。 古典的なウォータフォールモデルでは、工程を要求定義、外部設計、詳細設計、実装、単体テスト、統合テスト、運用保守となる。工程による分割可能で、要求定義を上流工程と実装、テストなどを下流工程と言う。それぞれの工程には明確なアウトプットがあり、要求定義のアウトプットは要求定義書で、それが外部設計のインプットになる。 要求の獲得から実装という一連の流れのなかで、利用者の何らかの問題を解決しなければならないのだけど、要求定義が利用者の要求とかけはなれたものであったら、いくら設計から実装が正しくとも、まったく意味のないものができあがってしまう。要求を的確に把握する事が重要なのだけどそれが一番難しい。 仮に要求定義の時点で利用者の要求を把握していたとしてもウォータフォールモ
ユメのチカラ: ハッカーのつくりかた
先日も朝から3人面接し、午後外出の後、夕方1人とじっくり話しこんでしまい、結局ディスカッションは2時間くらいになった。 まあ、ブレストなのか雑談なのかなんなのかよくわからない面接なのであるが、忘れないうちにブログのネタとして書いておく。 彼は弊社一番のカーネルハッカーでバックエンドチームに所属している。カーネルにまつわるどんな問題も魔法のごとく解決する凄腕である。 わたしの下心としては、彼のコピーをどのようにして作るのかというところにある。もちろん人間のコピーなんていうのが簡単にできるわけはない。しかしそれでも彼の1/10くらいのハッカー予備軍ができればおつりがくる。 カーネルの場合、必要とする知識はユーザーランドのアプリケーションより遥かに広範囲である。知識量勝負の部分がある。詳解Linuxカーネル程度の事は常識として理解していないといけない。割り込みの場合、コントローラのレジスタがどう
ユメのチカラ: ウェブ人間論
「ウェブ人間論」はベストセラー「ウェブ進化論」の著者梅田望夫と芥川賞作家平野啓一郎の対談である。「君、平岡の所へ行ってね、せんだっての手紙は御覧になりましたか。御覧になったら、御返事を願いますって、返事を聞いて来てくれたまへ」と頼んだ。 夏目漱石「それから」273頁(角川文庫)「それから」の主人公「代助」は書生の門野に友人平岡に出した手紙の返事を聞くために使いに出す。今から約100年前のコミュニケーションの手段は手紙であったが、それの確認に「書生」を使いに出す。 なるほど、コミュニケーションの手段は変った。人間のいとなみはネットによってどれだけ変化したのか。変化しうるのか。対談はそれに対する回答を試みようと行われた。 例えば文学者（平野）が本能的までに著作権についてナイーブな意見を表明し、コンサルタント（梅田）が近未来では紙の形式の本がなくならないだろうという見解を表明する。技術を過大評価
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
