2008年になってみて、ITの地殻変動がどこに起こっているのか？を考えてみる。 ※以下は殴り書き。後でロジカルにまとめる。 【1】XPからPF(プロジェクトファシリテーション)へ ウォーターフォール型開発はメインフレーム＋Cobolの時代の開発プロセス。今となっては古い。 RUPは、業務向けオブジェクト指向開発を基盤とした開発プロセス。 馬鹿でかい。皆こなしきれない。 ウォータフォール型開発に、各フェーズでインクリメンタル型を取り入れただけ。 XPは、Webシステムを基盤とした開発プロセス。 XPは、ここ10年の経験に裏打ちされた開発プロセスの革命。 ソフトウェア工学にも新しい知見を生み出した。 XPでは、プログラマは、コーディングするパンチャーではなく、システムの品質に対する最終責任者。 ドキュメントよりも動くプログラム重視。 プロトタイプ重視。 ソース共有、コーディング規約、常時ビルド

Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 ＃以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記

「コードコンプリート」第2版下巻を輪読した。 品質、テスト、デバッグの章を読んで、非常に参考になることばかりだった。 「コードコンプリート」を読むまで「プロセスで品質を作りこむ」という格言の意味が分からなかった。 整理するために感想を書いてみる。 【1】テスト自体はソフトウェア自体の品質を改善しない 「コードコンプリート」によると、テスト(単体・結合・システムテスト)をいくらやっても、一般に存在するエラーの高々50%しか検出されない。 テストの結果は品質の指標になるだけだ。 ソフトウェアの品質を上げたいなら、テストを増やすのではなく、開発プロセスを改善しなければならない、と。 その実例や測定結果も載せていた。 この指摘には衝撃を受けた。 どのプロジェクトでも、テストケースを増やしたら、ソフトウェア品質が上がっているように思えないだろうか？ それは、痩せるために体重計にのる回数を増やしている

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

第16回 Ruby関西に行ってきた。 Ruby会議2007の話もあり、牛尾さんも来られて、いつもの如く盛り上がった。 楽しかったことをメモ。 【1】Continuation(継続)ライブラリは恐ろしい～yharaさんの話 Continuation(継続)は、C 言語の setjmp()/longjmp() に相当するRubyのライブラリのこと。 定義は下記に書かれている。 組み込み関数 callcc 何故こんなライブラリが必要なのか？ 理由は、込み入ったループ処理でジャンプしたい時、イベント処理で複雑にwaitしている時にジャンプしたい時があるから。 普通は、使わなくても書けるし、多分書かない方がいい。 yharaさんが機能を解説してくれたが、callccが入ると、セーブポイントへジャンプするため、同じようなステートメントを何度も通過するので、机上デバッグできない。 でも、こんな問題でca

Eclipseの使い方を一覧で分かりやすく説明しているＨＰがあったので、メモ。 特にリファクタリングの手順が分かりやすい。 Eclipseリファクタリング Eclipseのリファクタリングは非常に使いやすいのに、何故か皆、使ってない。 ファウラーのリファクタリング本を読んでないのだろうか？ Javaプログラマにとって、綺麗なプログラムを書くための技術が全て詰まっている良書なのに。 【リファクタリングの目的】 最近、ソースインスペクションをする立場になってみて、仕様を理解せずに長々と書いている下品なプログラムを見ると、すぐにカチンと来てしまう(-_-;) Fatなメソッド、Fatなクラスは、不吉な匂いがする。 女性と(だけじゃなくて男性も)同じく、太ったクラスはダイエットすべき。 リファクタリングする真の目的は、誰でも理解できるプログラムにして保守性を高めることにある。 特に、プログラマは派

朝会をチームでやることになり、下記のＨＰを参考にした。 ・朝会のパターン：立ってるだけじゃないよ ・プロジェクトファシリテーション実践編：朝会ガイド そこで自分なりにアレンジしてみて、下記のルールで朝会をやってみた。 １・話す内容は、昨日やったタスク、今日やるタスク、最後に一言(抱負、連絡事項)の３つだけ。 ２・一人が話す持ち時間は3分以内。 ３・全員で立ったまま話す。 そして1ヶ月間、朝会をチームで実践してみて、新しい発見が結構あった。 その体験から「朝会の目的はそもそも何だろう？」という思いが上がってきた。 そこで、朝会について再考察してみる。 【１】自らの役割を自覚する～コミットメントの共有 過去の経験からして、失敗プロジェクトでは各メンバーの役割が曖昧で、誰が何をしているか、今の自分の仕事がプロジェクトのどのプロセスに相当しているか、を開発者だけでなく、リーダー自身も知らないことが

1/20に開かれた第6回RubyOnRails関西へ行ってきた。 場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。 このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。 講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。 【1】RDBのテーブル設計におけるアンチパターン Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。 １・無限ＦＫ地獄や列破綻 テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。 西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。 ２・フラグステータスとバタフライ効果 「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小

デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。 Ruby勉強会＠関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。 僕はRubyOnRails初心者なので、聞きやすかった。 聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。 「何故、RubyにDOAの第一人者の渡辺さんがいるの？」みたいな。 【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない！？ 渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。 懇親会で業務に携わっていると言うエンジニアの女性が、 「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」