« 2008年2月 | トップページ | 2008年4月 »

2008年3月

2008/03/22

【感想】Kanasan.JS prototype.js CodeReading#4

Kanasan.JS prototype.js CodeReading#4へ行ってきた。
今日はわずか13人だけ。
歩く仕様書のnanto_vi先生もおらず、正直物足りない面もあったけれど、ソース解読そのものは結構面白かった。

今日コードリーディングしたprototype.jsのL1652~L2472 は、ブラウザ依存やCSS依存の部分を汎用的に使えるように苦労している所。

IEはバグそのものが多いのか、ラップしたり、苦労している部分が多い。
FireFoxもVer1.8.0のみ特別な処理がある。
Safariは、バグFixしたプログラマが丁寧なのか、コメントしてくれて親切。

それらのソースは、正直綺麗じゃない。
たくさんの人の手が入ったのだろう、コーディングルールが徹底されておらず、インデントや変数名に統一性がない。

okkezさん曰く「バグレポート駆動」なのでしょう、と。
つまり、 バグレポートが上がるたびに、各人が勝手にバグFixして積み重ねたソースなのだ、と。

この状態は、システム開発の結合テスト以降のフェーズに似ている。
仕様書に従ってプログラミングしても、結合テストやシステムテストで、たくさんのバグ修正や仕様変更に伴って、プログラムは本来のあるべき綺麗な構造から少しずつズレていく。
一度、バグ修正したソースへ再び手を入れるのは、誰もが嫌がる。

今日コードリーディングしたprototype.jsも同じように思える。
実際のソースはそんなに綺麗じゃない。
でも、ブラウザやCSSにも依存しないように汎用的なライブラリにしてくれているので、AjaxのようなリッチUIを実装できる。

以前、lapis25さんが、フレームワークの内部のプログラムは、どう書いてもやっぱり汚い部分が残るんですよ、と言っていたのを思い出す。

汎用的で使いやすいライブラリを作るための泥臭いプログラミング。
それも、プログラミングの一側面。

| | コメント (0) | トラックバック (0)

2008/03/18

三項演算子?:の正しい書き方

三項演算子の書き方について、分かりやすい記事があったのでリンクしておく。

三項演算子?:の正しい書き方

Ruby、JavaScriptは、三項演算子を使いまくるソースが多い。
それは、Lispのような関数型言語の発想に似ている。
短絡評価も似たような発想。

条件分岐やループ処理も、DRY原則を徹底して、1行で書き切るやり方。

| | コメント (0) | トラックバック (0)

2008/03/15

【感想】第24回Ruby/Rails勉強会@関西

第24回Ruby/Rails勉強会@関西へ行ってきた感想を書く。

【1】REST思想が解決しようとするもの

moriqさんの講演。
REST思想をアーキテクチャの観点から非常に丁寧に深く解説してくれて、かなり概念が整理された。

Webシステムの特徴のひとつは、デプロイが独立していること。
つまり、クライアントのVerUpは、サーバーは無関係であること。

Railsの弱点は、デプロイにあると思う。
おそらく、JRubyがそれを解決してくれるはず。

REST思想のモチベーションは、セッションを汚さないこと。
できるだけ、画面の状態は、URLが指し示すリソースで持つ。
GET、POSTだけでなく、HTTPメソッドにあるPUT、DELETEを使って、セッションで保持しなくてもいいようにする。

少なくとも、注文ボタンの2度押し問題は、POSTメソッドでなく、PUTメソッドを使えば解決できる。
PUTメソッドは冪等の性質を持つので、1回以上の操作後の結果は全て同じだから。

しかし、ストヤンが指摘したように、RESTで全ての問題が解決するわけではない。
戻るボタン対応は、RESTでは、戻る遷移専用のURLを作る必要がある。
それは面倒で根本的な解決ではない。

戻るボタン対応は、結局、Continuationつまり、継続サーバーを使わないと解決できないと思う。
継続の概念があれば、画面操作がログインチェックで中断されても、スタックに保持した操作で画面を復元できる。
正常処理ならいつでも操作の途中から開始できる。

REST思想と継続サーバーの概念は全く別だ、と帰路の電車でストヤンが力説してくれた。
ストヤンが言うには、TCP/IPプロトコルそのものが限界にあり、SCTPみたいなプロトコルが必要じゃないかと指摘した。

僕はその意見が絶対正しいと思っていない。
REST思想はまだ不十分だけれども、無駄なセッション管理をなくす方向でWebアプリを単純化しようとしている。
Webアプリがステートレスである限り、その方向性は性能も考えると正しいと思っている。

【2】Railsとアジャイル開発

かわばたさんの講演。
Railsで構築したSNSと、現場でのアジャイル開発のお話。

Tagawaさんが、Railsのテスト駆動開発では、フェイクしたモックオブジェクトを使って開発することはないのか?という質問をしていた。

Railsに限らず、最近のシステム開発は、モジュール単位にプログラマをアサインして分業化するやり方ではなく、機能単位でプログラマが担当する。
つまり、1機能に必要なモジュールをプログラマが全て作る。セル生産のイメージに近い。
その意味では、プログラマの責任が大きくなっている。

プログラマはアーキテクトでもある。

【3】FlexとRubyの意外と親しい関係

FlexUG大阪のhirossyさんの講演。
Ruby関西の人は殆ど、Flexを知らなかったらしい。

デモでは、Webカメラで写した画面を触るとポッと反応するアプリをする予定だった。

興味深かったのは、RubyAMF の話。
動画などの情報をAMF3(Action Message Format 3 )という直列化されたバイナリ形式でサーバーとクライアントをやり取りする。
この時、クライアントはFlex、サーバーはRubyで、そのインターフェイスをAMF3であるアーキテクチャ。
この形式ならば、Flexクライアントは、サーバーのAPIをコールするだけで欲しい情報を取得できる。

ストヤンが話すには、FlexはAjaxよりも良い。
理由は、Flexの方がはるかにリッチなUIを作りやすく、更に、動画などのストリーム情報も加工や表示がやりやすいから。

更に帰路の電車でストヤンから、Flexは元々Flashから来たからデザイナーがプログラミングできる。
リッチなクライアントUIはデザイナーに任した方が、いいものが作れるよ、と。

確かに、Ajaxを使った場合、Viewをデザイナーもプログラマも触ることが多い。
だから、デザインをマージする時など、ソース管理がどうしても面倒になる時がある。

個人的には、ユーザ向けWebアプリはAjax、バックエンドの業務アプリはFlexかAirが現在はベストなWebシステムじゃないかと思う。

今回は色んな発表が聞けて楽しかった。


| | コメント (2) | トラックバック (1)

2008/03/12

配置図から非機能用件を類推する

配置図は必須」の記事を読んで同感。

UMLのうち、コンポーネント図や配置図を使うケースがない。
でも、物理的なサーバーと動作するモジュールの配置場所を意識する時に、非常に重要。

Webシステムでは、ロードバランサーやディスパッチャーで、複数台のWebサーバーへ負荷分散させるのが普通。
更に、DBサーバーも参照系と更新系、あるいはトランザクション系と分析系のように2台分ける時も多い。
Webシステムはスケールアップがやりやすいのが最大の特徴。

そんなケースでは、複数のサーバーへPGMが接続して処理するというロジックが漏れていることがよくある。
その理由は、開発環境と本番環境が違っているのに、設計時に漏れていたのが殆どだろう。

だからこそ、最初から非機能用件を固める時に配置図を上手く使う。

インフラチームは物理的なサーバーしか念頭になく、実際に動くモジュールに無関心な場合が多い。
だから、配置図を使って、インフラチームと認識共有する。

でも実際は配置図はイマイチ使いにくい。
ExcelやVisioで、DFDっぽく書く時の方が多い。
PCクライアントはパソコンのようなアイコン、DBはドラム缶でやっぱり表現したい。
なのに、UMLの配置図にはそんなアイコンがない。

UMLに詳しくない人でも理解できるように、配置図を改良してくれないかな?

| | コメント (2) | トラックバック (0)

2008/03/11

REST思想とHTTPメソッドの関係

RESTの基本的な発想は、HTTPメソッドでリソースをCRUDできるはずだ、というアイデア。
では、HTTPメソッドは、そもそもどんなものなのか?

安全なメソッドと冪等{idempotent} なメソッド」でいくつか語られている。

「RESTful Webサービス」で「べき等」という概念が出てくる。
「べき等」とは、同じ操作を何度行っても同じ結果であること。つまり副作用がなく安全であることを意味する。

少なくとも、GETはべき等に使うならば、安全であると言える。
しかし、GETで、リソースの削除や更新を行う時も、実はよくある。

REST思想に従うならば、GETは副作用を起こしてはいけない。
POST、PUT、DELETEがリソースの更新で副作用を起こすように使うべき。

RailsはREST思想を忠実に反映している。
また、Strutsも「http://~/***.do」というURLを見ると、RESTの発想を実現しようとしているニュアンスが感じられる。

更に、WebDAVとHTTPメソッドは親近な関係にある。
WebDAV メソッド」ではこんな風に説明している。

WebDAV とは "Web-based Distributed Authoring and Versioning" の略で、Web サーバ上でファイルの編集や管理等の共同作業を行えるようにする事を目的に開発されました。
(snip)
その後、1992 年に書かれた HTTP/1.0 の初期バージョンでは、PUT や DELETE といった HTTP/1.1 で盛り込まれるメソッドに混ざって、CHECKOUT や CHECKIN, SEARCH といった WebDAV で提案されているメソッドも見られます。
これらは明らかに、WWW を「サーバからクライアントへの単なるリソース配布するためのもの」から、「WWW 上でリソース編集を行うためのもの」にする狙いが読み取れます。
この「リソース編集のための仕組みを HTTP に組み込む」という考え方は、PUT や DELETE という形で HTTP/1.1 に盛り込まれ、更に現在の WebDAV へと着実に受け継がれています。

この発想を突き詰めると、「WWW上でリソース編集したいというモチベーションがREST思想なのだ」と言えるのではなかろうか?

| | コメント (2) | トラックバック (1)

2008/03/10

XPの計画ゲームとは?

OOエンジニアの輪! 第 40 回 関 将俊 さんの巻」で、関さんが興味深い発言をしている。

(引用始まり)
--- XP やアジャイルを試みてからずっと継続的にやってるんですか?

7 年くらい。でも、多分やってる人は XP でやってると思ってないと思います。そういう話はしてないです。はじめに入った時からそれしか知らないから、他と違うことを知らない人が多いのかもしれないです。

--- エリートですね(笑) 。どのようなプラクティスを重視してますか?

うちが一番注意しているのは計画ゲームとか、ストーリーカード・・・他のやつは、普通のプログラミングテクニックですよね? 計画ゲームが無いと XP としての意味がないというか・・・

(snip)

--- XP、アジャイルとの出会いはいつくらいですか? Kent Beck の白い本が出始めた頃ですか?

多分 2001 年ぐらいだと思う。出る前くらいかなんかだと思います。なんか当時、流行ってましたよね? ほかでも。なんか絵が描いてあるヤツ。絵を指している絵を使って。平鍋さんの所かな*25。プラクティス同士がこうつながるような絵のやつ。計画ゲームとかは共感できて。

--- 計画ゲームに関さんのツボがある感じがしますね。

計画ゲームは、何かある山を越えないとできない何かが結構あるんですよ。他のプラクティスに限って言えば、導入しても普通のプログラミングテクニックとかわらない。うまくやっている所はやってた事で、みんな知ってたよねっていう気がするんです。例えばうまい人はみんなテスト入ってからやってるのが普通。

--- 計画ゲームをやっていないと XP をやってるとは言えないですか。

うん。XP は名前に反しててプログラミングのための仕掛けじゃなくて、どうやって製品作ればいいんだろうっていう仕掛けなんですよね。その中でも、計画ゲームは作る製品を企画するような作業に一番向いていて。
(引用終わり)


XPのプラクティスの殆どは、今やかなり流通している。
Webシステム開発のように、ビジネスの速さにシステム開発を付いていくようにしたら、自然にXPらしくなってくる。

ソース共有、コーディング規約、常時ビルドは、今や当たり前の開発環境。
テスト駆動、リファクタリングも、今や当たり前のプログラミング技術。
スタンドアップミーティングで朝会をやり、全員同席でお互いのタスクと、チームのゴールを確認する。

ペアプロも、初めてのフレームワークや技術検証では、結局2人で作業していることが多い。
特に、本番リリース作業やデータセンターで本番DBをメンテナンスする時、ペアで作業している。
そうでないと、逆に怖い。

顧客を巻き込むことも自然にやっている。
本番リリースする前に、顧客に必ずデザインやUIを確認してもらうのが当たり前。
だから、リリース前には、WebデザインやUIの細かい部分の修正とテストを頻繁に繰り返すのが普通。
特に小売系は見た目にうるさい。
FireFoxで動作しても、IEでほんの少しレイアウトが崩れただけでも、やり直しになる。

だが、計画ゲームだけは、よく分からなかった。
関さんによると、計画ゲームとは、企画なのだと。
システムのデザイン、製品のデザインを顧客を巻き込んで行うこと。
技術志向ではなく、製品を一から作り上げていくためのボトムアップ的な手法。


オブジェクト倶楽部にある下記の話が秀逸。
「ドライブ」こそがXPの真髄。

(引用始まり)
Kent は,はじめて自動車を運転する練習をした日のことを例にしています.

母を横に乗せ,ハンドルを握り... 最初はうまく行きました.でも,ちょっと油断した瞬間,車は車道を外れて砂利に突っ込んでしまいました.母は車を道に戻すと,初めて運転とは何かを教えてくれました.
「運転で大切なのは,車を正しい方向に進めることじゃないのよ.大切なのは,常に注意を払って細かく左右に方向修正していくことなの.」

(引用終わり)

| | コメント (2) | トラックバック (0)

2008/03/09

【告知】第 24 回 Ruby/Rails 勉強会@関西

参加申し込みが近年になく芳しくないので再告知。

詳しくは
http://jp.rubyist.net/?KansaiWorkshop24をご覧ください。

【告知】第 24 回 Ruby/Rails 勉強会@関西

日時:2008 年 03 月 15 日 (土) 13:00~17:30

場所:神戸大学
会場:学術情報基盤センター分館
アクセス:http://www.kobe-u.ac.jp/info/access/index.htm
費用:実費(講師の交通費、配布物の印刷代等)の人数割をご負担ください。前回(同じ会場)は500円でした。
定員:45名(注意!!)(今回は会場の都合で定員が設定されています)

セッション概要は随時Wikiの方で更新致しますので
宜しくお願い致します。

○ロガー
前回に引き続き、各セッションのロガーも募集しています。
ロガー志望の方は「このセッションのロガーやりま~す!」と書いてください。重複も歓迎。

○懇親会の参加・キャンセル
懇親会の受け付けは金曜17:00までです。

参加およびキャンセルは、
http://jp.rubyist.net/sns/?m=pc&a=page_c_event_detail&target_c_commu_topic_id=139
からお願いします。

○内容
◆NetBeans Ruby Pack / Rails 2.0 by moriqさん
概要 :

最近 NetBeans 6.0 を触り始めたのですが Ruby support が素晴らしすぎるので NetBeans を触りつつ Rails 2.0 の話題を提供したいと思います。

ディレクターから推薦:
Rubyの統合開発環境を提供するNetBeansは、Rubyをコード補完できるだけでなく、リファクタリングもできる優れモノです。
Ruby初心者にとって、NetBeansは最も開発しやすい環境だと思います。
更に、Railsの中核思想であるRESTful Webサービスについても語って頂く予定です。
REST思想は、今後のWebフレームワークの設計において、MVC2モデルに次いで重要な概念になると思います。

◆Ruby1.9 の新しい仕様(Array の逆襲) by こなみさん
概要 :
前回不手際であまり紹介できなかった部分,特にHashとの絡みなどを含めて紹介します。

◆Ruby/Railsプロジェクトにおけるアジャイル開発(仮) by かわばたさん(XPJUG関西)

◆Flex3 / AIR デモ by やまもと(hirossy)さん(Flexユーザーグループ関西)
概要 :
デモを含むFlex3/AIRのご紹介、RubyとAIR連携。

ディレクターから推薦:
今年初めにAdobeAirがついに正式リリースされました。
AdobeAirは今最も注目されるWebリッチクライアントです。
(MSもAirに刺激されて、.NETで動作するWebリッチクライアントSilverlightをベータリリースしています)
今回は、関西で活発に活動されているFlexユーザーグループの方に、AdobeAirとFlexを紹介して頂く予定です。

◆Ruby初級者向けレッスン第18回 by okkezさん

| | コメント (0) | トラックバック (0)

2008/03/08

業界から見たIT技術の変遷

IT技術の変遷について考えてみると、業界の変遷と照合すると分かりやすくなる。
最新のIT技術が必要とされる業界が、流れとして、鉱工業や金融から、小売などの商業やマーケティング系へ移りつつある。

昔は、工場や銀行のようなミッションクリティカルな業務システムに、メインフレーム+Cobolで構築していた。
昨今は、メインフレーム+Cobolを、Java/.NET+オープン系システムへリプレースする案件が非常に多い。
それらの案件は大抵、大規模案件で、いつもデスマーチになる。
技術者としても、部品ばかり作って、システムの全体像が見えず、楽しくない。

昨今の小売などのネット注文Webシステム、SNSなどは、Java/PHP/Perl/Ruby+Unixで構築することが多い。
例えば、Amazon、楽天、mixiなど。
それらの案件は中小規模だが、いつも最新のWeb技術を試すし、技術革新のスピードが猛烈に速い。
技術者としては、いつも新しい技術を使うので、しんどいけれども、ワクワクする。

小売系のWebシステムの特徴は、Webシステムの特徴を生かしきっていること。
Webシステムの最大の特徴は、2つある。
一つは、クライアントはPCブラウズ又は携帯なので、Webサーバーへモジュールをデプロイすれば簡単にリリースできる。
もう一つは、スケールアップがやりやすいこと。Webサーバーを増設すれば、簡単に処理性能をUpできる。
昨今は、サーバーのコストも安くなっている。サーバーのメモリを64G積もうとしても、そんなにお金はかからない。
メインフレームよりも安く、更にカスタマイズしやすい。

小売系の業務は実はかなり複雑。
大まかな流れは下記の通り。

1・バックエンド:オペレータが商品マスタを投入する

2・PCブラウザ/携帯:ユーザが会員登録+商品検索+商品を注文する。更に、注文履歴や配送履歴を閲覧する。

3・バックエンド:オペレータが、ユーザーの連絡を受けて、ユーザーの注文データを修正したり、クレジットカード会社へ注文を取り消したりする。

4・バッチ:オペレータが売上計上する。更に会計システムや配送会社へ注文データを送る。

つまり、アクターが変わるたびに、システムが4つも変わる。
Webシステムだけで閉じているなら、テストも簡単だが、Web→バックエンド→バッチまできちんとデータが流れるか、その業務のインターフェイスを設計して品質を保つのが難しい。

業務的には、はぶさんやT字形ERによると、商品マスタというリソースが多い会社ほど、ビジネスを展開しやすい。
つまり、リソースを組み合わせることで、トランザクションを増やすことができる。
例えば、商品と顧客というリソースの関係から、注文だけでなく、購入履歴、お勧め商品、お気に入りリスト、優先会員へ割引注文、などのトランザクションを生成できる。

決済処理は、小売系で最も重要な機能。
小売系の会社は、自社のクレジットカードで決済させたがる。
理由は簡単。注文者の購入履歴を把握できるから。クレジットカード決済データがたまるほど、そこからマーケティング調査できる。
また、コンビニ注文は5日以内にお金を払わないと注文キャンセルらしい。
最近は、代引き決済なんてできるらしい。

また、小売系は、季節商品が多い。
冬はおせち・お歳暮・クリスマスケーキ・福袋、春はバレンタインデー・お花(母の日が年間で一番売れる)、夏はお中元など、やたらとイベント単位に大量に売りさばく業務が多い。

そのたびに、カスタマイズした機能を作り、商品データを流し込む作業が発生して、年中忙しいけれど、それらの商品でテストするのは楽しい。
少なくとも、女の子SEは、クリスマスケーキや女性用化粧品、女性用婦人服の商品を使ったテストが楽しいらしい。
僕もテストしたおかげで、女性用化粧品のブランドをかなり覚えたよヽ(^。^)ノ
クリニーク社の製品は実は、男性用もあるらしい、とか。

技術的には、EJBサーバーを使うとか、携帯ならFelicaや3G対応などハード面も技術調査が必要。
特に携帯は、画像の表示サイズが小さいとか、絵文字を使ったり、ハード面の制限も多い。
PCなら、ユーザが使う場面では、AjaxでUIを使いやすくするのが最近の流行。
バックエンドのシステムは、FlashやFlexなどで、昔のクラサバのシステムに近いUIにするのが普通だろう。
今年以後は、バックエンドは、AdobeAirやMSのSileverlightを使って、デスクトップアプリのようなUIを使うようになるだろう。

プログラミング的には、ミッションクリティカルな業務システムでは、Java技術がかなり枯れて安定している。
Javaはオープンソースのフレームワークやライブラリが多く、ノウハウも多い。
しかし、開発のスピードがJavaで遅いと感じる時が多い。

だから、PHP/Perl/Rubyを使うシチュエーションが多くなりつつあると思う。
Amazon、楽天、Mixi、はてなはいずれもPerlを使っている。
これからは、Ruby on Railsかな。

Webシステムの開発スタイルはアジャイル開発。
XPが最もマッチする。
特にUIやデザインは、顧客がリリース前に一度確認したがる。小売系は見た目重視だから。
だから、結局、開発チームに顧客も巻き込んだ形になる。

更に、ソース管理とビルドツールを統一的に組み合わせて、常時ビルドできる環境が普通だろう。
だからこそ、毎日リリースする開発体制を組むことも可能。
以前のメインフレーム上の開発では考えられないだろうが。

このように、ハード面も技術面もプログラミング面も開発プロセスでも、工場や銀行のシステム開発は、時代にマッチしなくなってきた。

昨今のように、3ヶ月先の景気すら見えない時代では、素早く変化できるビジネス、そして変化に対応できるシステム開発が最重要な技術。

Webシステムの最大の特徴は、リリースとスケールアップが簡単なこと。
Webシステムは、今の時代に一番マッチしている。

| | コメント (0) | トラックバック (0)

2008/03/07

SEが死ぬほど忙しいのは彼女もわかってくれるよね?

こんなマンガ見つけた。

SEが死ぬほど忙しいのは彼女もわかってくれるよね?

理解できる自分が悲しい。。
「SEの仕事は脳みそで鉄筋を組み立てているようなもんなんですよ」というどこかのフレーズを何故か理解できてしまう。。

IT土方を感じるこの頃。

| | コメント (0) | トラックバック (0)

2008/03/05

DBはグローバル変数

システムコントロールテーブルに、システムの設定情報、業務の固定情報を載せる。
システムの固有情報を動的に変更したい時があるから。

DBをグローバル変数として持たせる。
Singletonに近い発想。

渡辺さんの本でも似たような話があった。

利点は、プロパティファイルの場合とは違って、アプリケーションサーバーを再起動する必要がないから。
プロパティファイルを変更した場合、アプリケーションサーバーを再起動しなくてはいけない場合がある。

DBがグローバル変数みたいなものなら、システムは関数。

丁度昔のCのプログラムのように、ヘッダファイルにプログラムの状態の値をグローバル変数として持たせた状況に似ている。

| | コメント (0) | トラックバック (0)

2008/03/03

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF

2008年になってみて、ITの地殻変動がどこに起こっているのか?を考えてみる。
※以下は殴り書き。後でロジカルにまとめる。

【1】XPからPF(プロジェクトファシリテーション)へ

ウォーターフォール型開発はメインフレーム+Cobolの時代の開発プロセス。今となっては古い。

RUPは、業務向けオブジェクト指向開発を基盤とした開発プロセス。
馬鹿でかい。皆こなしきれない。
ウォータフォール型開発に、各フェーズでインクリメンタル型を取り入れただけ。

XPは、Webシステムを基盤とした開発プロセス。
XPは、ここ10年の経験に裏打ちされた開発プロセスの革命。
ソフトウェア工学にも新しい知見を生み出した。

XPでは、プログラマは、コーディングするパンチャーではなく、システムの品質に対する最終責任者。
ドキュメントよりも動くプログラム重視。
プロトタイプ重視。

ソース共有、コーディング規約、常時ビルド、そしてインクリメンタルな開発。
いずれも、Webシステム開発にすごくマッチする。

Webシステムの場合、Webサーバーでデプロイしてリリースすれば、いつでも誰でも稼動確認できる。
常時ビルドしているから、常時リリースできる。

顧客も設計者も開発者も巻き込む。
昨今の時代、要求の一つであるリリーススケジュールが最も大きな意味を持つ。
リリースするタイミングが遅れるほど、マーケットシェアを失う。

機能単位に細かくリリースして、システムをバージョンアップしていく。
バージョンアップしないシステムは、時代にマッチした新規機能が追加されないので、死んでいるのも同然。
常時リリースできる開発スタイルだからこそ、取れる戦略。

XPは技術重視、プログラマのための開発プロセス。
平鍋さんが提唱するPF(プロジェクトファシリテーション)は、XPの弱い部分であるチームビルディングにフォーカスを当てる。

昨今では、3~6ヶ月単位のプロジェクトで、新規メンバーをかき集めて、システム開発するパターンが多い。
この時に、すぐにチームビルディングできるかどうかは、プロジェクトの成功を大きく左右する。

プロジェクトが求める役割に各メンバーがマッピングできるか?
プロジェクトが進行中、ぶち当たる課題、そして突然のトラブルに、チームとして解決できるか?

ニコニコカレンダー、バーンダーンチャート、タスクかんばんという進捗管理。
朝会、KPTという場。

技術だけでなく、チームそしてプロジェクトをコントロールできるか?

【2】Webフレームワークに関数型言語の特徴を取り入れてみる

IT技術は、Reach(使用人数のスケール)とRich(UIの使いやすさ)の2軸を拡張する方向で発展してきた。

メインフレーム
→デスクトップ
→Webアプリ
→Webリッチクライアント

Webフレームワークでは、まずSeasarがDependencyInjection、Aspectという観点を実現した。
そして、RubyOnRailsが、REST思想を実現した。

REST思想は、EJBやSOAPの反対に位置するもの。
すごくシンプルな発想。
誰でもプログラムで実装できる。

Webシステムの最大の特徴は、ステートレスであること。
ステートレスだからこそ、スケールアップがすごく簡単。
Webサーバーを増設すればいい。

REST思想は、Webアプリがステートレスである特徴をよく生かしている。

だとしたら、ステートレスである関数型言語の方がオブジェクト指向言語よりもWebフレームワークに向いていないか?
オブジェクト指向はデスクトップアプリ開発から生まれた。
デザインパターンはオブジェクト指向のカタログ。

RubyがJavaと違うコーディングスタイルは2つあると思う。
一つはクロージャ。
もう一つは、短絡評価(short-circuit evaluation)。

最近のコーディングスタイルとして、メソッドチェーンや3項演算子を使いまくるソースをよく見かける。
JavaScriptでは、Prototype.jsを見ると、3項演算子を3個以上も繋げているソースもある。
メソッドチェーンの利点は、英文を読んでいるかのように1行で済むこと。
Javaならば、メソッドでチェーンするたびに、オブジェクトのNULLチェックが必要になる。
後者は、ダックタイピングの特徴もあり、オブジェクトに定義されていないメソッドがあれば無視される。

クロージャは、まだ理解し切れていない。
普通は、ループ処理の代わり。

クロージャが本当の威力を発揮するのは、継続(Continuation)を使うこと。
継続(Continuation)は、本質的にGOTO文と同値。
return, break, continueは全て継続(Continuation)で書き直せる。

継続(Continuation)をWebフレームワークに取り入れると、Webシステム開発がすごく楽になる。
その発想は、下記を参照せよ。

部分継続の使用法

閲覧は自由だが書き込みはログインが必要なサイトを作る場合の例が書いてある。
クライアントから見ると次のような画面遷移になるだろう。

1.投稿記事入力フォーム(ここで入力してポストする)
2.ログイン認証画面 (ここでログインチェック)
3.記事閲覧画面(投稿記事もしくは記事一覧などを表示する)

すると下記のようなロジックが必要になる。

2-1.入力フォームから記事がポストされた時にログインしてなければ、ポストデータを退避しておき、ログイン認証させるためのページを返す。

2-2.ログイン認証を行い、認証が成功したら、退避していた情報から記事投稿の処理を再開して記事投稿後のページを生成して返す。

つまり、Webアプリはステートレスなので、ポストデータは一度セッションに退避して保持しなければならない。
また、退避していたセッション情報から記事投稿の処理を再開する部分などは決して楽なプログラミングではないだろう。

継続(Continuation)を使えば、途中まで実行した手続きをクロージャで保持し、しかも途中から処理を再開するルーチンをコールできる!
つまり、投稿した後の処理を継続(Continuation)を使って、ログイン認証成功後に呼び出すように表現できるのが、継続Webフレームワークの最大の特徴なのだ。

継続サーバーの概念は、「ハッカーと画家」「JavaからRubyへ ―マネージャのための実践移行ガイド 」でも取り上げれている。
今後数年で出てくるはず。

【3】日本のIT技術の希望~SeasarとRuby、そしてPF

日本のIT開発は、舶来品の部品で開発しているようなもの。
だが、2000年以後、日本独自の技術や概念が出てきた。

JavaのフレームワークSeasar。
Railsを生み出したオブジェクト指向言語Ruby。
そして、XPを補完するPF。

それらは日本のIT技術の希望。

| | コメント (2) | トラックバック (0)

« 2008年2月 | トップページ | 2008年4月 »