ブルックスの法則 - 未来のいつか/hyoshiokの日記
ムーアの法則（18ヶ月で半導体の能力が２倍になる）というのは有名だが、それに比べてブルックスの法則は知られていない。 http://commons.wikimedia.org/wiki/File%3AFred_Brooks.jpg *1 ブルックスは1960年代、IBM System/360用オペレーティング・システムOS/360の開発責任者で、後にそのときの経験をもとに人月の神話という本を書いた。 大規模ソフトウェア製品開発の難しさを書いた画期的な書物である。IT産業に従事しているなら必読の書である。ソフトウェア開発あるいはプロジェクトマネジメントに関わる人はだまされたと思って読んだ方がいい。わたしの日記でも何度となく紹介している。 それはともかく第二章人月の神話だ。次のような例題がある。12人月かかると見積もられた仕事があるとして、３名で４ヶ月でその作業を完了すると考えた。そして一月毎
コードには力がある。世界を変える力がある。 - 未来のいつか/hyoshiokの日記
先日、思わぬことからGree主催のオープンソーステクノロジー勉強会でお話をさせていただいた。一応テクノロジー系の勉強会なのでお題としてPostgreSQLにおけるスケーラビリティのお話を用意したのだが、本音で言うと高速道路時代を生きる若手プログラマの皆様に向けてのヨタ話の方が主題であった。 当日の様子・ログはGreeのページないし参加者の皆さんのトラックバックなどを読んでいただきたい。多くの方にコメントやら感想をいただいた。参加者の１〜２割の方がなんらかの形でブログで意見表明をするという場に居合わせたことに自分自身うれしく思うし、ブログを書いていただいた皆さんに素直に感謝したい。*1 懇親会で車座になりながらビールを飲みつつさらに皆さんと時間を共有した。その場でもいろいろ参加者の皆さんからコメントをいただいたのだが、技術的な話で言うとRDBMSをはじめとするミドルウェアの性能チューニングの
未来のいつか/hyoshiokの日記 - オープンソーステクノロジー勉強会
第4回 オープンソーステクノロジー勉強会でお話をした。後で書きます。 「PostgreSQLのスケーラビリティ」の話と「エンジニアのキャリア？」の話をしてきた。前半は推進フォーラムの開発基盤WGでやったES7000でのベンチマークのお話で、ユニアデックスの米田さんの持ちネタのhyoshiokバージョンである。後者はまったくもってヨタ話で懇親会への前座的なお話。それぞれ資料はGreeの勉強会のページから公開予定なので楽しみにしておいてほしい。 参加者層は20代、30代半々くらいでわたしから見れば若手である。40代はいなかった。10代がお一人いたので、U-20プログラミングコンテストの宣伝をしておいた。*1 さて、「エンジニアのキャリア？」、副題として「hyoshiokの作り方」。Greeの藤本さん（バリバリのPHPハッカー）から、ぜひお話を伺いたいなどと直お願いされちゃったもんだから、わたし
カーネル読書会 - 未来のいつか/hyoshiokの日記
本日、カーネル読書会だった。お題はalternativeマクロのお話。お題提供者のこさきさんは、薄めの話を持ってきました、などと言っていたが、「薄い話」とわざわざ言う奴ほど濃い話をするという法則のとおり濃いお話であった*1。（すばらしい） なんだかよくわからないのだが、IA32にはNOPと同様な機能をする命令が1バイトから7バイトまであるそうだ。通常のNOP命令は1バイト。0を足すみたいな命令も、使い方によっては、プログラム的には無効な作業なので、NOP的な命令と言えなくもない。そのような命令がいろいろあるらしい。 CISC（一つの命令のバイトの長さが異なる命令を持つコンピュータ）では1命令の長さがことなるのでいろいろなバイト長のNOPがありうる。自己書き換えプログラムである部分を書き換えたときの埋め草としてNバイトが必要だったらNバイト長のNOPを埋めればいいという話になる。例えば7バイ
ブログと名刺 - 未来のいつか/hyoshiokの日記
ブログは名刺みたいなものだとよく言われる。（言われないか？）だけど、名刺はブログではない。 ブログを読めば、その人がどんなことを考えているか俯瞰できる。日々なにをして、何を考えているかがだいたい分かる。分かったような気になれる。共感することも反発することも一切合切含めてその人を理解できる。 名刺には、会社名、所属、役職、名前、住所、電話番号などが書いてある。会社のURLや電子メールのアドレスも最近では書いてあったりする。ビジネスでおつきあいするというのは、名刺という仮面をかぶっておつきあいすることである。双方間合いを詰めながら、この人は一体何を考えているのだろう（それは最終的にはもちろん自社の利益を最大化することなのだけど）ということを推し測っていく。 ブログによって一方的に自分の情報を公開することは日本という地域ではいろいろリスクがあると言われているがそれ以上にメリットがあるのではないか
2006-04-17
パソコンで最もよく利用されているエンコーディングの一つがシフトJISなのだが、その誕生については、なかなかまとまった資料がない。当時の関係者の証言を断片的にまとめたものしかない。 まづ小形さんの以下のBLOGとコメントを読む。当時の当事者が証言をしている。 http://d.hatena.ne.jp/ogwata/20051228/p1 シフトJISを発明したのは誰か？ http://d.hatena.ne.jp/ogwata/20051229/p1 シフトJISを発明したのは誰か？(2) http://d.hatena.ne.jp/ogwata/20051230/p1 「BASIC80を漢字化した経理専用マシン」のこと http://d.hatena.ne.jp/ogwata/20060102/p1 たくさんのコメント、ありがとうございます 安岡さんの日記も参考になる。 http://s
未来のいつか/hyoshiokの日記 - コードを読む力。
カーネル読書会やります。 http://www.ylug.jp/modules/pukiwiki/ 第62回カーネル読書会のおしらせ 日時：4月11日(火)、19時開始 お題：Debian Linux Kernel メンテナンスチームはどうやってカーネルをメンテナンスしているか 内容：Debian GNU/LinuxのLinuxカーネルはdebian-kernelチームによってメンテナンスされています。alioth.debian.org の svn レポジトリ、メーリングリスト、およびIRCなどを利用してどのように共同作業し、どういう問題を解決してきたのか、について語ってもらいます。 発表者:Dann Frazier (Debian kernel team) （通訳はありません） 場所：日本HP市ヶ谷オフィス http://h50146.www5.hp.com/info/company/a
企業とOSS - 未来のいつか/hyoshiokの日記
例えばIPAで支援してもらってOSSを開発するとする。結果をOSSライセンスで公開するのは契約の縛りがあるから当然なのであるが、「OSSで開発しました、コード公開しました、以上」ではバザールモデルにならない。開発企業以外がそのソースをみてパッチを作ったり活発に議論したりということは通常ならない。今年度の予算消化しました。物は契約どおり作りました。次年度以降保守されません。ではあまりにももったいない。 では、どうすればいいのか？ 開発の主体が企業であろうが個人であろうがコミュニティを形成し多くの人および企業に参加してもらう。すなわちバザールを興すというのが成功の鍵だと思う。このコミュニティを形成するというのはコードを書くよりはるかに難しい。パッチを作るよりはるかに難しい。そして、コミュニティをどのように形成するかという知恵というものは各自の成功体験の中にしか存在していない。明文化されてはいな
Pugsを読む。:未来のいつか/hyoshiokの日記
Haskellを勉強するためにPugsのソースを読むというのは、Cの勉強をするためにUnixのカーネルの読むようなものだ。いいねいいね、この主客転倒ぶり。*1 Pugsのホームページから、Downloadをクリックして、http://search.cpan.org/dist/Perl6-Pugs/へ。最新コードは下記の最初に公開されたコードに比べてかなり複雑化している。最初に公開された昔のコードは随分シンプルだ。で、１０ファイルしかない。 抽象構文木あたりから行くのがいいのではないだろうか？特に根拠はないけど。 Haskellの文法書(翻訳）。入門書などを参考にする。 *1:Lionsの本(Lions’ Commentary on UNIX (Ascii books))はCのいい教科書でもある。 Cでどのように表現するかという勉強になるしね。
開発者をどう作るか？ - 未来のいつか/hyoshiokの日記
いろいろ妄想する。OSSの開発者が数人いたらそこそこすごいことができる。そのようなチームが数十あれば定番のOSSのかなりの部分をカバーできる。せいぜい数百人のOSS開発者がいれば世界を変えられる。その数百人をどう育てるか？ 大学教育のソフトウェア演習の一つとしてOSSの開発に参加するというのはどうだ？一クラス数十人としてそのうちの一人でも二人でもOSSに興味を持ってもらうだけでいい。そのようなクラスが全国に数十あれば、年間100人程度のOSS開発者が誕生する。どうだろうか？人数が少なすぎる？ Asia諸国まで場を広げれば年間数千人くらいのOSS開発者をデビューさせることはあながち不可能ではないような気がする。どうだろうか？妄想がすぎるか？ 実現不可能な話ではないように思う。どう実行するかだけのような気がする。 日々是開発:SQS Developmentさん、http://sqs.cmr.s
開発者はどこにいるのか？ - 未来のいつか/hyoshiokの日記
FLOSS-JP オープンソース / フリーソフトウェア開発者 オンライン調査日本版 (http://oss.mri.co.jp/floss-jp/)というのが２００３年ごろに行われている。既に２年以上たっているわけだが日本におけるオープンソース／フリーソフトウェア開発者の実情(？)を知る上での基礎的な資料なので引いてみた。わたしのイメージするOSS開発者と調査した三菱総研の比屋根さんや飯尾さんのイメージするOSS開発者とは微妙に異なる可能性はあるが、日本のOSS開発者の実態を調査した唯一（？）のサーベイなので非常に貴重である。 アンケートは合計547人回答を得ている。開発時間をみてみよう。http://oss.mri.co.jp/floss-jp/report.html#Q6 図(Q6) 週平均OSS/FS開発時間 5時間以下が61.7%と大半をしめる。0時間も8.5%である。むむむ？開
文字化け:未来のいつか/hyoshiokの日記
文字化けと言うのは永遠に解決しない問題なのだろうか？昔々わたしがまだこの業界に入って間もないころ数々のエンコーディングがあってその混沌たる世界は標準化によって解決できるのではないかと夢想していたが、歴史はそれを否定した。（少なくとも今現在は）。数々の標準が（de factoであれde jureであれ）生まれたがどれかに統一されたと言うことはない。 Unixの世界であればEUCというエンコーディングは非常によくできていたし1985年前後の環境を考えれば絶妙な（？）バランス感覚を持っていた。当時は米国生まれのソフトウェアをいかにして簡単に日本語化するかという課題をとくことが一つの使命であった。バイリンガルなソフトウェアがゴールであった。まだソフトウェアの国際化という概念は十分成熟していなかった。 日本語化、韓国語化、中国語化などを繰り返すうちに、ソフトウェアから文字コードに関する数々の暗黙の仮
プログラマ - 未来のいつか/hyoshiokの日記
多分、わたしの使っているプログラマという言葉が意味する職業と多くの人のイメージするプログラマという職業は微妙に異なっているのだろう。 お客さんの業務システムを受注してそれをおさめるという仕事があるが、SIとか言われていたりする、わたしの専門性はその分野にないので、そこでどのような仕事がされているかは実のところよく知らない。なのでSIの人とわたしのイメージするプログラマという職業とではやはり微妙に違うような気がする。 わたしは主にソフトウェア製品を作る人々についての議論になる。SIでお客さんのアプリケーションを開発している人々のことはここではふれない。常々記しているように日本と言う地域には、国際競争力のあるソフトウェア製品というのがほとんどないので、上記の意味での職業的プログラマというのは日本には残念ながらほとんどいない。ソフトウェア製品での勝負は90年代米国の一人勝ちだ。勝負あった。 そこ
未来のいつか/hyoshiokの日記 - 当事者になるということ
時々思う。本当に日本と言う地域は評論家だらけだと。冗談じゃない。あんたはそれをやったことがあるのか？汗をかいたことがあるのか？それだけ言うのなら自分でやってみろ。 なんてことを言うのは大人気ない。大人はそういうことを言わない。ぐっとこらえてミステリアスな笑みを浮かべると言うのが正しい日本人の姿だ。 時々日本に対する違和感を持つことがある。そりゃ違うだろうと思うことがある。それに対してどのような態度をとるのか？どのような態度をとることによってその人なりの生き方が見えてくる。 多分わたしは自分が自覚するかしないかにかかわらづ日本人が暗黙のうちに持っている掟をどこかで踏み外しているというような感じがする。それがいいことか悪いことかは別としてそのような感じを持つ。 90年代日本のIT産業の出口がなくなったとき多くの人は何もしなかったし、そもそもそこに問題があるとは思っていなかった。大丈夫か日本なん
『 プログラマの仕事』
U-20プログラミング・コンテストの審査員を務めたミラクル・リナックス取締役の吉岡弘隆氏は「今年，ついにLinuxカーネル・コミュニティへデビューした」と嬉しそうに話していた。彼の書いたパッチがAndrew Morton氏がメンテナンスするLinuxカーネルに採用されたのだ。Linuxベンダーがカーネル開発に参加するのは当然かもしれないが，吉岡氏は今年47歳。47歳にしてカーネル・ハッカーのスタートラインに立った。その目標は「生涯一プログラマ」だそうだ。 http://itpro.nikkeibp.co.jp/article/OPINION/20051017/222923/ 本当にラッキーだと思う。ひょんなことで「仕事」でカーネルのパッチを書く機会を得てコミュニティにデビューできた。C言語とちょっとした経験さえあればプログラミングは誰でもできる。プログラミングは体力を使わないので年齢を重ね
ソフトウェアの開発で飯を食う - 未来のいつか/hyoshiokの日記
ここでのソフトウェア開発というのはOSとかRDBMSとかソフトウェア製品の開発ということにして、VBやJavaでアプリケーションをばりばり書くというのは取り合えづ置いておく。 でもって、じっと見回してみると日本という地域にはコアなIT産業は携帯とかネットワークとか、そーゆーところにはありそうだけど競争力のあるソフトウェア製品を開発、販売している会社はほとんどない。出口のない産業のような感さえもつ。（寒い）メインフレーマの中には細々とそのような部署がなくはないが、メインストリームという感じでもない。15年位前に日本のソフトウェア産業大丈夫か？というようなことが強く言われたが、だめである。全然だめである。しょぼすぎる。 じゃあ、アプリケーション開発は安泰かというともちろんそんなことはなくて、世界でいちばん高い賃金を正当化できるような事はほとんどないので、中国だ、インドにオフショアだみたいな話を
未来のいつか/hyoshiokの日記 - オープンソースの開発で飯を食う
リナ飯（Linuxで飯を食う）とかオプ飯（オープンソースで飯を食う）とかとオープンソースのボランティア活動はまったく直交している。独立した事象であるとわたしは思う。 生活のためにコードを書く人は昔も今も明日もいるだろうし、趣味でコードを書く人も、（コードを書きたいから書く人も）、昔も今も明日もいるだろう。プロもいればアマチュアもいる。それによって金銭的な報酬を受けている人もいれば受けていない人もいる。金銭的な報酬ではなくコミュニティからの尊敬を受けている人もいれば受けていない人もいる。自己の満足度を金銭的報酬以外のものに求める人もいればそうでない人もいる。 お金だけですべてを語るのは間違いである。もちろんそう思う。しかしオープンソースソフトウェアの開発と言うだけで過度に自己実現のためにコードを書く人が多数だと言うような言説はいかがかと思う。ソフトウェアの多くは趣味で自分のためにだけ書かれた
未来のいつか/hyoshiokの日記 - オープンソースソフトウェアとフリーソフトウェア
ご存知のようにオープンソースソフトウェアというのはNetscapeがソースコードを公開したころにその蛮勇を支援するためにEric RaymondやLarry Augastineらが考え出したフリーソフトウェアに対して与えたマーケティングメッセージみたいなものである。オープンソースソフトウェアをソースコードのライセンスとして捉えるのは誤解とまでは言わないが正しい理解からは遠い。 フリーソフトウェアは、Richard Stallmanがソフトウェアの独占的に利用に対し自分の経験からの信念により、ソフトウェアの自由がなによりも重要だという立場である。そしてその自由を保障するためにGPLというライセンスを発明した。Richard Stallmanは世の中のソフトウェアがすべてGPLになれば世界はよりよくなると信じている。 オープンソースソフトウェアというマーケティングメッセージを作り出した人達はG
2005-09-12
いやはや、たまげた。民主党が守旧派みたいにうつちゃったんだろうなあ？ りんごとオレンジを比べるな。いやはや仰るとおりなんですが、別に比べたっていいではないか？深海の動きはゆっくり。レイヤーが違う。人の芝生を羨ましがっているわけではなくて、そう読めたとしたらわたしの言葉足らずなんだけど、自分は自分、人は人。楽しくやっています。 LLは高速道路があるけど、カーネルハックにはないとしたら、じゃあ、その道を作ってやろうと考えるのが多分わたしのスタイルである。一体全体どのくらい時間と手間と暇がかかるかはわからないけど。ゴールが見えているわけでも、これと言ったビジョンがあるわけでもなくロードマップもなんにもないけど取り合えず一歩踏み出す。 で、そんな事を考えている時、昔の事を思い出した。10年前、シリコンバレーに単身乗り込んで、とりあえづRDBMSの実装部隊にほうりこまれた時の事だ。ソースコードは絶望
2005-09-10
試行錯誤の数で人は学んでゆく。多くの失敗はその人の糧になる。プログラミングを学ぶ過程はまさに失敗の連続である。プログラムを書く。スペルミスをする。コンマとピリオドを間違える。大文字と小文字を間違える。０とOを間違える。コンパイルが通らない。いきなりクラッシュする。起動すらしない。なんてことを延々繰り返すのである。 ソフトウェアプロジェクトも同様である。スケジュール通り物事が進んだ例がない。問題はいたるところから発生する。要求仕様はころころかわる。プロジェクトメンバーがいきなり退職する。問題は山積しているが解決の糸口さえ掴めない。なんてことを延々と繰り返す。しかし、その繰り返しの中で人々は学んで行くのである。一つのプロジェクトが仮に１年かかるとすると３回くらいそれを経験すれば、まあ一人前である。そうすると一人前になるのに３年かかるということになる。大規模ソフトウェアでそれが仮に１バージョンの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
