ユメのチカラ: なぜメリークリスマスが禁句なのか？
1989年年末、わたしは米国ニューハンプシャー州にいた。米国DECのRdb開発チームに出向になっていて、せっせとアジア版Rdbのコードを本体へマージしていた。 日本人で米国ニューハンプシャー州ってどこにあるのか知っている人は少ない。初対面の人となんかでニューハンプシャー州に居たんですよという話になって、ああ私も実はなんてことになると、一気に盛り上がってしまう。マサチューセッツ州の北にある、縦長の州で、米国独立時の13州のうちの一つである。ニューイングランド地方の一つである。紅葉が綺麗だ。 80年代は、日本の産業が実力以上に元気で、米国とは経済摩擦を引き起こしていた。半導体は日本のメーカーがトップ10のうち多くを占めていたし、銀行もぶりぶり言わせていた時期である。日本企業が米国の資産を買いあさっていたバブルのころである。 ニューハンプシャー州のナシュアという田舎町で働いていたころ、会社の帰り
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
ユメのチカラ: 人月の神話
Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳 わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。 原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。 第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐
ユメのチカラ: OSS時代の人材育成
Unisys BITSでパネルディスカッションをした。メンバーは旧知のテックスタイルCEO、岡田さん、日本HP、宇佐美さん、IPA、OSSセンター長、田代さん、主催者側からはユニアデックスの松隈さん、そしてわたし。 ユニアデックスはユニシスグループの中ではサポート部隊という位置付けでメインフレームビジネスが主なビジネスモデルである。そのような会社がLinuxやOSSをどのように位置付けるかと言うのがパネルの裏のテーマである。 パネルの中で人材育成というのが議論になった。 従来のメインフレームベンダは、ハードウェア、OS、ミドルウェア、アプリケーション、SIなどすべて自社で請け負う。典型的な垂直統合型ビジネスである。 それがオープンシステムの時代になって、プロセッサはインテル、OSはマイクロソフト、RDBMSはオラクルなど、それぞれのコンポーネントがそれぞれの分野のトップシェアのベンダが担う
みたのブログ: Ext3 ファイルシステムで削除したファイルを復元について
うっかりファイルを消してしまったりすることは、よくあると思います。 いろいろ事情があって、ext3 ファイルシステムで削除したファイルの復元について、半日ぐらい調べていました。 恥ずかしながら ext2 の場合も同じだろうと ext2 の場合の復元方法を一生懸命テストしたり、古い文書やメーリングリストの議論に惑わされたりしながら、やっと Linux ext3 FAQ のなかの ext3 の開発者のひとりの引用を読んで調査が終了しました。Q: How can I recover (undelete) deleted files from my ext3 partition?つまり ext2 の場合は、ファイルを削除するとき inode を "deleted" としるしをつけるだけなので、 debugfs コマンドの lsdel で削除された inode の一覧を得ることができるし、その削除さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
