ユメのチカラ: 技術は会社のものではない。みんなのものだ。社内セミナーをニコニコ動画(RC2)で公開するまで。
先日、野村総合研究所向けに「技術は会社のものではない。みんなのものだ」というタイトルで社内セミナーをした。 オープンソースにまつわるソフトウェア開発方法論みたいな話である。まあ、中身は日頃わたしのブログをご覧の皆様にはおなじみなお話である。 野村総合研究所(NRI)の社員30人程度の皆様への社内セミナー(注)である。今回一つお願いをした。「講演を後に公開していただく事を前提にお請けします」。 セミナーを職業にしている講師にとってはありえない条件である。しかし、わたしは講演を公開することの経済的な損失というのはないし、むしろ自分の日頃の主張と行動に一貫性を持たせるという意味あいの方が強い。 講演内容を公開しろなどという講師は前代未聞である。大きな企業になればなるほど社内調整というやっかいなものが待っている。一度誰かが先例をつければ次の人はその道をフォローできるが、最初の一歩が困難にみえる。越
ユメのチカラ: なぜメリークリスマスが禁句なのか？
1989年年末、わたしは米国ニューハンプシャー州にいた。米国DECのRdb開発チームに出向になっていて、せっせとアジア版Rdbのコードを本体へマージしていた。 日本人で米国ニューハンプシャー州ってどこにあるのか知っている人は少ない。初対面の人となんかでニューハンプシャー州に居たんですよという話になって、ああ私も実はなんてことになると、一気に盛り上がってしまう。マサチューセッツ州の北にある、縦長の州で、米国独立時の13州のうちの一つである。ニューイングランド地方の一つである。紅葉が綺麗だ。 80年代は、日本の産業が実力以上に元気で、米国とは経済摩擦を引き起こしていた。半導体は日本のメーカーがトップ10のうち多くを占めていたし、銀行もぶりぶり言わせていた時期である。日本企業が米国の資産を買いあさっていたバブルのころである。 ニューハンプシャー州のナシュアという田舎町で働いていたころ、会社の帰り
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
ユメのチカラ: 大規模ソフトウェアをgdbを利用して微視的視点から理解をする
たまたま講読している php-dev というPHPの実装を日本語で議論するメーリングリストで「mbstring の新関数」というスレッドがあった。新規にmb_list_encodings_alias_names()という関数を追加したらしいのだが、既存のmb_list_encodings()とどう違うのかどうかという議論がわきおこっている。 ここでは、mb_list_encodings()を題材にどうやってphpの実装を理解していくか、そのプロセスを記述してみたい。もちろんこの方法がベストであるとか、この方法でなければいけないとか、いつでもこの方法が適用可能だなんてことを主張するつもりは一切ないが、一つの例として大規模ソフトウェアの微視的理解方法を理解いただきたい。 1) mb_list_encodingsがどこで利用されているかを知る。 $ cd /usr/src/php-5.1.4 $
ユメのチカラ: 闘うプログラマ
わたしが紹介するまでもなく、「 闘うプログラマー〈上〉」、「 闘うプログラマー〈下〉」はビル・ゲイツの野望を実現すべく雇われた「伝説のプログラマ」デイブ・カトラーのＮＴ開発物語である。 わたしはデイブ・カトラーに会ったことはないがDEC時代にいろいろ伝説は聞いていた。一番、有名な都市伝説は、Windows NT (WNT)というのはVMS (DECのベストセラーマシンVAXのOS)を一文字づつずらした名前にしたというものである。誰かがデイブ・カトラーにその真偽を問うメールをしたところ、今ごろ気がついたのかよ、という返信が来たという。90年代初頭にそのようなメールがでまわっていたような記憶がある。 それはともかく鬼軍曹のような風貌のプロジェクトリーダ率いるＮＴ開発物語はザカリーの筆力もありぐいぐいと人を引きつける。 それは栄光と挫折の物語である。20世紀最後の商用ＯＳ開発物語と言ってもいい。
ユメのチカラ: 価値創造の方法論
技術は会社のものではない。みんなのものだ。なんて事を言うものだから、よしおかさんには「カネの匂いがしない」などと言われてしまう。 企業戦略として知的財産権をトッププラオリティにして経営をするというのは、まことに理にかなっているし、それを否定するものでもない。 他社との差別化戦略で、他社に容易にまねできないものを持つという意味で、知的財産権をそのよりどころにするのは間違ってはいない。 一方で特許をはじめとする知的財産権というのは、新しい価値を創造することに対するインセンティブをあたえる事によって、大げさに言えば、人類の幸福に寄与することを目的としている。 特許法『第一条(目的)この法律は、発明の保護及び利用を図ることにより、発明を奨励し、もつて産業の発達に寄与することを目的とする。』 著作権法『第一条(目的) この法律は、著作物並びに実演、レコード、放送及び有線放送に関し著作者の権利及びこれ
ユメのチカラ: アーキテクチャの設計寿命
「マルチプロセッサ向けソフトウェアパラダイムとは？」で、Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとかしないとか書いてあって、感心したのを覚えている。 http://blog.miraclelinux.com/yume/2007/01/post_ab8c.htmlと書いたのだが、先日たまたま下記の論文を発見した。 いまはなきDEC の技術論文集(digital technical journal)の第４巻第４号がAlpha AXPの特集号である。目次を参照されたい。 Alpha AXP Architecture by Richard L. Sites
ユメのチカラ: コードを読むな、理解しろ
コードを読まないで理解するというと何やら心眼で読めとかテレパシーを使えとか、そーゆー荒唐無稽な方向に走れという事ではなく大局的に理解しましょうという話である。 カーネル読書会のネタで今回はmallocのお話だったのだが、そこでRubyのささださんがいらっしゃっていて、GC(ごみ集め)と記憶域管理の関係について熱い議論が沸騰し、その後いろいろブログなどでフォローされていたりする。 わたしもRubyでmallocやGCがどう実装されているか興味があったのでoprofileで実行プロファイルをとってみたりした。日頃利用しているノートPCでRubyのテストプログラム(test/runner.rb)を実行してoprofileしたのは先日ブログに書いたとおりである。 「それとわたしのノートPCではキャッシュミスを測定できないので、Xeonのマシンでキャッシュミスを測定すると面白いと思った。GCの時ぼろ
みたのブログ: メモリが一部分壊れたときのしのぎかた
256MB のメモリをはずしてもやはりへんな動作をすることがあったので、もう一度 memtest86+ を実行してみたところ、512MB のメモリのほうも一箇所壊れていました。Tst Pass Failing Address Good Bad Err-Bits Count Chan --- ---- --------------------- -------- -------- --------- ----- ---- 4 0 00016caf4f0 - 364.9MB 5611fbfd 5611fb7d 000000080 431一時間ほど流して 364.9MB の辺りの一箇所で 431 回もエラーを検出していました。このまま使いつづけるとファイルシステムまで壊してしまう恐れがあるので、メモリを取り換えるまで起動するのはよくないのですが、つぎ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第三のペンギン: Linux パフォーマンスチューニング (入門書を卒業した管理者が次に読む本) その２