« 2008年1月 | トップページ | 2008年3月 »

2008年2月

2008/02/29

関西ライフハック研究会でファシグラ体験

関西ライフハック研究会Vol.5「ファシグラ体験講座」 に行ってきた。
一番の目的は、すだち師匠やなおまるさんが書いたファシグラ本の解説。
楽しかった~。

その時の感想をメモしてみる。

関西ライフハック研究会は初参加ですが、座長opakenさんがウケを取ったり、腰ビールのCMもやったり、リラックスした雰囲気。

今回のテーマであるファシグラことファシリテーショングラフィックは、会議で、議論を見える化し、問題vs私たちという構造に持ち込むひとつのテクニック。
実際に書いてみましょう、とプロッキー片手に講師のすだち師匠さん。

さっそく、30人ほどでプロッキーを持って、4人単位に座って、グループワークでファシグラ体験。

プログラマは字が汚い人が多いですが、丁寧に大きく書くとそれほど気になりません。
プロッキーは寝かせながら書くこと、縦は太く横は細くを意識すると、読みやすくなる。

プロッキーを使いながら、議論を見える化する手法についても、すだち師匠から聞く。
議論しながら、ゴールや問題点を書く時、下記をイメージすると分かりやすくなる。

・見出しを使う
・アイコンや絵を入れる
・マインドマップ、マトリックス、フローチャートなどの基本図形フレームワークを使う

さっそく、ワークショップでは、各グループで、好きな商品企画をテーマにワイワイ書いてみる。
僕のチームは、ノートPCをテーマにした。

皆さん色んな個性がある。
マインドマップで議論を発散させる時に、見出しに●をつけたり、黄色の下線を入れると分かりやすくなる。

アイコンは、携帯の絵文字を使うと分かりやすい。
例えば、「アイデア!」「大好き!」「注意!」など。

絵を描くのがうまい人もいる。特にWebデザイナーの人たち。
他チームでは「金太郎飴のようなポッキー」という絵をかなりリアルに描いていて、これならいきなり営業できるのでは?と思わせるぐらい。

プログラマは基本的に絵が下手。
でも、プロジェクトリーダーは、「絵を使って説明してくれ」という場面が結構多い。
例えば、開発者に、こういうアーキテクチャでクラス設計してくれ、とか、お客様へ、売上データはこういうフローで最後はバッチで送信されます、などのように説明する。

僕の場合、作業手順はアクティビティ図、Web画面遷移はステートチャート図、データの流れはロバストネス図やDFDを使う時が多い。

また、ビジネスモデリングでも、WBS、プロセス図やBSC、因果ループ図などを使って、実際の組織の作業フローを色んな角度から解明しようとする。

だから、ファシグラのような技術を意識して使えば、UMLやDFD、ビジネスモデリングツールをより強力に使えるようになる。

いつもながら、関西ライフハック研究会はお笑いを取るのがうまくて楽しめました。
スタッフの皆さん、ありがとうございました♪

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

2008/02/27

【再考】XPプラクティスの相関関係

SEA関西プロセス分科会「エンピリカルソフトウェア工学の実践 」を聞いてきた。

さかばさんの講演でした。
最も興味があったのは「効果的なXPの導入を目的としたプラクティス間の相互作用の分析」。
内容は、XPのプラクティスの相関関係を調査したもの。

2004年当時、2個のプロジェクトでヒヤリング形式で調査したとのことだが、下記の結果が得られている。

【1】生産性や向上に役立つプラクティス
 ペアプロ
 リファクタリング
 テスト駆動
 シンプルデザイン

 更に、保守性に役立つプロセスは、上記+アルファとして、
 コードの共同所有
 コーディング規約

【2】要求品質に役立つプラクティス
 短期リリース
 常時結合
 ユーザテスト
 計画ゲーム

【3】コミュニケーションに役立つプラクティス
 全員同席
 計画ゲーム
 ユーザテスト

XPは第2版になって複雑化してきているが、現在のシステム開発をパワーアップさせるプラクティスがまだまだたくさんある。

プログラマの観点から見ると、生産性や保守性の向上は、仕事の効率性そのもの。

今となっては、テスト駆動やリファクタリングは、かなり流通した技術になっている。
今時、テストファーストでないプログラミングスタイルは、逆に怖い。
テストされていないプログラムは、ガラクタと同じ。

ペアプロは現状普及してないけれど、少なくともその効果は皆知っている。
二人の目による作業は、プログラミングでなくとも、本番リリース作業や本番DBメンテナンス作業など、失敗が許されない作業はペアでするのが普通。


プロジェクトリーダーの観点から見ると、ソース管理や即検証できるビルド環境は、必須だ。

と言っても、CVSやSubversionすらない開発チームも今だあるようだが、考えられない。
ソース管理は、達人プログラマーによれば、プログラミングのUndoそのもの。

更に、ソース管理はコードの共同所有につながる。
プログラムは人に見られた方が綺麗になる。
他人のソースを見てアイデアを盗む。
それは、丁度、女の子が人に見られて綺麗になっていくように。

すぐにビルドできない開発チームもあるようだが、今となっては考えられない。
組み込み系は1日1回程度しかビルドできないようだが、Web開発ならば、リリース直前に1日10回ビルドすることも稀ではないだろう。

即ビルドできるならば、すぐに検証できる。
バグが見つかれば、すぐにバグを再現させることができる。
開発者が修正したら、すぐにビルドして、稼動確認できる。
インクリメンタルな開発のためには、常時結合できるビルド環境が必須だ。

だが、チームビルディングと言う観点では、やや力点が劣る。
しかし、今の日本では、チームビルディングに焦点を当てたプロジェクトファシリテーションという技術がある。

毎朝の朝会。
会議術として、ファシリテーショングラフィックなど。
進捗管理にタスクかんばんなど。
週末にふりかえりやKPT。

昨今の開発は、3ヶ月単位にプロジェクトが立ち上がり、初対面同士のメンバーをかき集めて、3ヵ月後にアウトプットを出すというスタイルが多い。
人が集まれば、すぐにチームは機能するものではない。
メンバーのスキルと、チームが必要とする役割が初めて合致して、チームの一体感が生まれる。

XPで最も刺激を受けた概念は「ドライブ」と「ナビゲーション」。

XPは最近は熱気が冷めたように見えるが、それは、XPのプラクティスの一部が実践されてきているからだろう。
やっぱりXPは面白い。

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

2008/02/25

Kanasan.JS JavaScript第5版読書会#3 行ってきた

Kanasan.JS JavaScript第5版読書会#3 があったので行ってきた。
前夜は大阪でも雪が積もり、この日も晴れたものの寒い(;_;

この寒い中、30人も集まりましたよ。
自己紹介を聞いていたら、東京から来た人3名、名古屋や三重県から来た人3名もいたよ!

今日も通称サイ本の輪読。
当日の勉強会の内容を書いてみる。

【1】applyとcallをどう覚えればいい?

applyもcallも、関数呼び出しをあるオブジェクトのメソッドのように扱うこと。

f.call(o, 1, 2) は下記と同じ。

o.m = f;
o.m(1, 2);
delete o.m;

applyとcallの違いは、Ujihisa君がLispで書いた説明が分かりやすかった。

(apply f a b c '(d))
(call f '(a b c d))

つまり、applyは引数が配列、callは引数の羅列。

yharaさんのAnswerが端的ズバリ。

 Schemeを知っていればapplyは簡単.Rubyを知っていればcallは簡単.

applyもcallも、関数をオブジェクトと見なせる点がJavaと異なる。
また、カリー化の話もあった。

他にcalleeの話題もあった。


【2】関数の引数に関数をセットできること~スクリプト言語の最大の特徴

Array.sort()の話。
引数に、ソートしたいロジックを無名関数にして入れたら、ソートできる。

これは、元々Perlから派生した手法だと思う。
ブロックをうまく利用したやり方。
JavaScriptの場合、変数も関数もオブジェクトみたいなものだから、関数をプロパティへセットすることも可能。

Javaならば、無名関数ではなく、メソッドだけのクラスを作り、そのクラスを引数にセットするやり方しかない。
Javaの方が冗長。
RubyはPerlJavaScriptと同じ。

あと驚いたのが、JavaScriptはオーバーロードできない。
たしかに、JavaScriptは、引数の型がないし、引数の数も見ないから、やりようがないのだが。


次回は、本命のプロトタイプベースのオブジェクト指向のお話。
面白くなってきた(^o^)丿

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

2008/02/24

Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ

Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。
古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。

#以下、セキュリティ関係などを除く。

Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。
古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。
なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。

しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。

Webアプリを作る時はいつも、下記の問題をどのように解決するか、を潜り抜けなければならない。

・戻るボタン
・注文ボタンの2度押し
・F5(更新ボタン)連打
・マルチウィンドウで操作

しかし、ここでは、Webアプリ特有の技術に焦点を当ててみる。

1・リダイレクト
2・ポストバック
3・可変個数のパラメータをPOSTで送信する

※以下は殴り書き。後でロジカルにまとめる。

【1】リダイレクト

リダイレクトとは、フォワードを2回以上実行すること。
つまり、クライアントは次の画面に遷移しているように見えるが、サーバーサイドでは、2個以上の画面を経由して、最後にクライアントに画面表示する仕組み。

@ITの記事が分かりやすい。

リダイレクトとフォワードの違いを知る

リダイレクトを使う場面としては、ログインチェックが多いだろう。
つまり、ログイン完了した画面ではなく、注文画面だったり、会員修正画面のように、ログインチェック後、元の画面に戻るようにする。

あるいは、会員情報修正の画面フローで、住所登録や修正ができるとする。
普通は、住所修正が終わったら、会員情報修正完了画面に遷移するだろう。

しかし、注文の画面フローの途中で、「配送先住所を変えたい」「メールアドレスが間違ってた」などの理由で、途中で会員除法修正画面へ移るとする。
修正できたら、会員情報修正完了画面ではなく、元の注文の画面に戻らなくてはいけない。
このとき、画面遷移の分岐処理をフォワード処理でするか、あるいは、ViewにResponseからリダイレクトする処理を入れる。

他にも、他サブシステムへ画面遷移する時にも使う時が多い。

この手法は、JSP+ServletだけでなくASP.NETでも良く使われる枯れた技術。

【2】PostBack(ポストバック)

ASP.NETで出てくる。
@ITの記事が分かりやすい。

ポストバック処理

 従来型のプログラム開発の基本的な考え方は、ブラウザからの入力データの送信先を「次の画面を表示するプログラム」にするというもの。
例えば、Sturts。
ASP.NETでのポストバック処理とは、ユーザがクライアントブラウザ上で入力したデータを、次の別プログラムではなく同一プログラムに再送する処理のことを指す。

つまり、ポストバック機能とは、ViewStateを利用してブラウザ上で行われた操作をサーバ側で「再現」し、対応するメソッド(イベントハンドラ)を自動的に呼び出す機能である。
 ポストバックの仕組みにより、ASP.NETではポストしたデータを処理するのは、常にそのページ自身となる。そのため、ASP.NETのページには基本的に入力フォーム部分と処理結果の表示部分が同居することになる。
これによって、入力チェックエラーで元の画面を復元する場合、JSP+Servletのように難しく考える必要はない。

更に、ASP.NETフレームワークは、スケーラビリティを確保するためにページインスタンスを毎回破棄する。
つまり、初回リクエスト時とポストバック時に使われるインスタンスは別物になる。
このため、ページインスタンス上にデータ変数を用いてデータを残しておくことはできない。
だから、隣り合う画面ではない他画面を復元するには、ViewStateかセッションにデータを保持する必要がある。

【3】可変個数のパラメータをPOSTで送信する

この状況は、カート画面で、商品を複数の配送先にコピー又は分割したい場合が多いだろう。
良くある業務は、ギフト注文のように、1個の商品を複数の配送先に分けたい場合に相当する。

この操作は、以前は逐一サーバーに問い合わせてセッションを分割する手法が多かったが、Ajaxが登場して以来、DOMを生成する手法でクライアント上で簡単に実装できるようになった。

この問題は、POSTする商品リストの個数がSubumitされるまで可変なため、POSTする商品リストを動的に作る機構が必要なことだ。
業務アプリケーションでは入力項目数が可変であることが多いにも関わらず、WebアプリではPOSTする配列をダイナミックに生成する機構が最近まで存在しなかった。

以前は、Submitする時に、POSTする商品リストのサイズも合わせてPOSTするという原始的なやり方が主流だっただろう。

最近は、Javaの場合、Appche commons-collectionsのListUtils.lazyList()を使うと、遅延評価のように、リストをダイナミックに生成できる。
肝心のRailsの場合は知らない。

しかし、この問題はAjaxによって更に複雑化する。

フォワードした

カート画面を表示

クライアント上でDOM操作で商品リストを追加ないし削除して、商品リストの個数をフォワード時と変える

POSTする

Servletが処理して次画面を表示
でもやっぱり、一つ前に戻るとしよう

戻る場合は、DOM操作して個数が変わった後の画面を再表示する。
一つ前のアクションを呼ぶのではない。
セッションに放り込んだデータを再表示する。

入力エラーの場合も同じ。
 Strutsでは、Servletに渡る前にActionFormでValidatorが動いてしまうと、一つ前のActionが呼ばれてしまう。
 DOM操作して個数が変わった後の画面が表示されない。
 普通は、ActionFormのValidatorはコメントアウトし、ServletでValidatorを実行するようにする
 しかし、余計なロジックが入り、複雑化する。

【4】クッキーログイン
半ログインとも言われる。
クッキーにログイン情報が残っていれば、ログインした状態で商品検索できる。
注文する時、カード情報を入力する時、半ログイン状態ならログイン画面で入力させる。
Amazonなどのように、半ログインであたかもログインしているかのようにクライアントに思わせる。
Webアプリがクライアントに優しくなるための一つの手法。

つまり、Webアプリでは、会員の状態は下記3つがある。

・ログオフ
・半ログイン
・ログイン(実ログイン)

以上の技術を見ても、Webアプリで何度もぶち当たる問題は、詰まる所、セッション管理に行き着く。
デブサミでyoshioriさんは「セッション管理の問題は昔辿ったプログラミングの歴史と同じ。詰まる所メモリ管理と同じでしょ?」と言っていた。

思い出して見よう。
書いてるWebプログラムはステートレスが多い。
つまり、手続き型プログラミング。
 全然オブジェクト指向じゃない。
 画面の状態を保持するオブジェクトがプログラムで存在しない。
  画面の状態は、セッションに保持するのが普通。
  Viewに残すのはセキュリティ上やばい。
   クレジットカード番号だけでなく、会員IDすらViewに残すのは危険。
  セッションへ保存するのは、ハッシュに詰めるのと同じ
  タイプセーフでない。
  何故、オブジェクトでセッションに保存できない?

  セッションに入れるデータの一覧表をExcelで管理していた。
  DRY原則に反する。
   何故ソースで管理しない?

【RailsとAjax】
【1】Railsがもたらしたもの

デブサミでyosihoriさんは「Ruby on Railsは究極のWebフレームワークだ」と言った。
Strutsの究極の進化系がRails。

Webアプリのアーキテクチャは、MVC2モデルで既に確立されている。
業務システムの殆どは、RDB→SQL→Controller→View というアーキテクチャ。
もっと簡単なシステムであるWikiなどは、テキストor XML→正規表現→Controller→View というアーキテクチャ。

Railsが最も生かしやすいターゲット。
しかし、Wicketは別方向に進もうとしている。

画面の状態をどこで保持し破棄するか?
画面の状態をどのようなライフサイクルで管理するか?

つまり、それはデスクトップアプリ開発で悩んでいたメモリ管理と同じ。
Webフレームワークは、それをどのように解決しようとしているか?

Railsは、クッキーへ画面情報を持たせようとしている。
更に、URLで指し示すHTMLかXMLに情報を持たせる。
いわゆるREST思想。

Wicketは、セッションへ画面情報を持たせようとしている。

継続フレームワークは、画面操作の手続きをスタックで保持する。

おそらく今後数年で、上記の問題を解決するフレームワークが出るだろう。

【2】Ajaxがもたらしたもの

Ajaxによって、Webアプリはクライアントに優しいUIを持てるようになった。
つまり、サーバーと非同期通信することによって、クライアント操作の待ち時間が減る。

 その仕組みは、Viewを生成するロジックはサーバーではなくクライアントに置く。
 サーバーからView生成用データを送ってもらい、クライアント上ではJavaScriptでDOM生成によってViewを生成する。

 RESTの概念とは、リソースに全てのデータがある。そのリソースはサーバーにある。
 View表示ロジックはサーバーにない。

 サーバーからデータをもらえば、View生成のために逐一サーバーに問い合わせる必要はない。
 ステートレスWebアプリを作る現在の主流の方法にすごくマッチしている。

 Railsが持つRJS、GWT(Google Web Toolkit)は、サーバーからViewを返す時に、Ajaxを埋め込んで、クライアント上で自由自在にDOMを生成できるように自動生成する機構を持つ。
 この手法ならば、クライアントのUIもサーバーサイドから制御できる。


Webアプリプログラミングは、デスクトップアプリに比べると開発途上と言える。
「画面の状態をどこで持つか?」。
セッション管理のように、未だにメモリ管理の機構をプログラマが逐一考えないといけない。

車輪の再発明を未だに繰り返すWebアプリ開発。
そろそろキラーアプリが出ても良い予感。

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

2008/02/20

リーダーシップよりもメンバーシップ

小飼弾さんのBlogから下記の本を立ち読みしてみた。
結構面白い!

 こんな目次になっている。

  • はじめに
  • 序章 チームはすべて「共有」から始まる
  • 第1章 ビジョンを共有するチームを作る
  • 第2章 「質問」でメンバーの力を巧みに引き出す
  • 第3章 コミュニケションの「困難」を克服する
  • 第4章 チームを活性化させるメンバーへの「気配り」
  • 第5章 メンバーからの「プレッシャー」を追い風にする
  • 第6章 「共有」に役立つツールの実践事例
  • 終章 「メンバーシップ」が人を動かす

 今の時代、基本的にプロジェクト単位の仕事が多いから、チームのメンバーはコロコロ入れ替わる。
 上下関係がはっきりした関係で長期間仕事することはおそらくあまりない。
 軍隊ですら、海兵隊のように、少数精鋭のチームで誰もが司令塔として活躍することを求められている。

 そんな環境でチームでアウトプットを出そうとする時、メンバーと共有することが最重要。
 特にゴール、ビジョン。

 そして、メンバーとの信頼関係も大切になる。
 ファシリテーションでは、素早い信頼関係構築も一つの使い道だった。

 リーダーは、その信頼関係を元に、メンバーへ影響させて、プロセスを連鎖させる。
 オブジェクトの集まりのようなチームでは、リーダーは指示よりも委任するタイプの方が似合う。

 ジョハリの窓、ホーカーソンの法則など心理学、社会学の知識も載せてあって、色々考えさせられる。

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

2008/02/12

次世代Webフレームワークの設計思想~RESTful Webサービス

「RESTful Webサービス」本を買ってみた。
まだ読んでないけれど、この本を買った動機を振り返ってみる。

【1】Webフレームワークの歴史とその限界

Webアプリは最初はオモチャみたいなものだった。
普通は、掲示板のようなアプリをPerlでCGIを書いて作っていただろう。

そして次第に、ViewからControllerを分離する設計をするようになった。
Javaの場合、JSP+Servletという仕組み。

だが、システムが巨大化していくうちに、Webフレームワークが必要とされるようになってきた。
そのWebフレームワークの基本思想として、MVC2モデルが叫ばれるようになった。
MVC2モデルは、GUIアプリのMVCモデルのWeb版といっていい。

この思想によって、大概のWebフレームワークは、MVC2モデルを標榜するようになった。
そして、Javaはこの思想を突き詰めて、Model部分にEJBを作り出した。

EJBは、永続化装置とネットワーク分散型装置の2つを実装した巨大なビジネスオブジェクト。
EJBはステートフルなBeanとステートレスなBeanの2種類があるが、皆、ステートレスセッションBeanばかり使う。
理由は、ステートフルな方が本当は使いやすいが、ネットワーク越しにステートフルな状態を持つのは遅いから。
確かに最新技術をふんだんに取り入れて魅惑的だが、何しろ重くて実用的にならない。

更に、その頃は、SOAPという概念も出てきた。
SOAPは、Webというネットワーク上でメソッドコールできるようにすること。
つまり、ネットワーク越しのRPC。
でもすごく遅い。
2000年当時は、ネットワーク越しにメソッドコールで1分以上もかかる。
とても使い物にならなかった。

そして、今でもSOAPやEJBは、Webアプリ開発の主流となりえていない。

【2】プログラマにとってステートフル、ユーザにとってステートレスなWebフレームワークとはどんなものか?

Webフレームワークとは大まかに下記の流れと言えるだろう。

HTTPリクエストからデータをもらう

プログラムはそのデータを使ってゴニョゴニョ処理する。
RDBへ放り込んだり、ファイルをアップロードしたり。

プログラムが作ったデータをHTTPレスポンスに渡す

Viewを表示する

画面の状態を保存するには、セッションやクッキーを使うしかない。
クレジットカード番号や個人情報はViewでHiddenで保持するのは危険。

でもセッションの状態管理は難しい。
画面遷移が複雑になるほど、セッションはどんどん汚れていく。

Webアプリの鬼門はいつも「戻るボタン」と「注文ボタンの2度押し」。

例えば、戻るためには、どの画面から飛んできたかを知らないといけない。
前の画面に戻るパターンは、実は、その2個前の画面の状態に依存する例もある。
あるいは、会員登録フローならば、新規会員登録なのか会員情報修正なのかで、戻る場所は違う。
画面遷移を制御するためのフラグをリクエスト変数に追加していくうちに、スパゲティコードになる。

他に、最終注文画面の注文ボタンを2回誤って押したら、同じ商品が2度注文されてしまう。
普通はそんな誤動作を防止するために、注文処理後すぐにセッションをクリアしたり、注文ボタンを押した時刻をHiddenで保持したり、あるいはトランザクション・トークンキーを使ったりする。
どの方法にせよ、たかが2度押し防止のために、かなり面倒な実装をしなければならない。

「境界を越える: 継続とWeb開発、そしてJavaプログラミング」では、そんな疑問に一つの回答を示している。
合言葉は「プログラマーにとってはステートフル、ユーザーにとってはステートレス」。

つまり、画面の状態を保持する機構がプログラマにとって必要。
だが、スケーラビリティやユーザビリティを考えると、ユーザにとってステートレスの方が圧倒的に使いやすい。
この矛盾した設計を最初に実現したのは、実はLispのWebフレームワークだと言う。

Paul Grahamが「ハッカーと画家」の中で、既に1995年のViaWebにおいて、この基礎となっている手法を使ったらしい。
この手法は、『継続(continuation)』というプログラミング制御構造を使うことに意義がある。

この基本的な考え方は、「プログラミング・フレームワークが、アプリケーションの状態をリクエストの前にロードし、また各リクエストの後に保存するようにする」ということ。

GausheというSchemeで作られたKauhaというWebフレームワークでもこの考え方が使われているらしい。

Rubyにも、『継続(continuation)』というライブラリがある。
基本は同じ。
でも、デバッグするとどのステートメントをたどるか分からないのが普通で使いづらいのが普通。
Ruby関西では、yharaさんが講演してくれたのが分かりやすかった。

そこで問題。
『継続(continuation)』を使った場合、画面の状態はどこに保存されるのか?

それは実は、URLに隠れている。HTTPメッセージへ全ての情報(リソース)を渡すのだ。
ここからRESTの話に移る。

【3】RESTの定義とは?そしてRESTを実現したRuby on Rails

WikipediaのRESTの解説が非常に分かりやすい。
HTTPプロトコルについてもう一度おさらいしてみよう。

似たようなプロトコルにFTPがある。
こちらの方がHTTPよりも原始的だが。

FTPでファイルをアップする時、WindowsユーザならFFTPアプリを使うだろうが、ftpコマンドを使って、コマンドラインでもアップできる。
同様に、HTTPプロトコルでも、GETやPOSTコマンドを使って、直接HTTPサーバーに問い合わせることができる。
大まかには、RESTとは、このコマンドを拡張して制限したアイデアを指す。

RESTとは、下記の設計原則を持つと言われている。

◆ステートレスなクライアント/サーバープロトコル
 HTTPメッセージの一つ一つが、そのリクエスト (メッセージ) を理解するために必要な全ての情報を含む。

◆すべての情報 (リソース) に適用できる「よく定義された操作」のセット
 HTTP では操作 (メソッド) の小さな集合で定義されている。
 つまり、"GET"、"POST"、"PUT"、"DELETE"。
 これらはデータ永続化に要求される CRUD の概念に似ている。

◆リソースを一意に識別する「汎用的な構文」
 すべてのリソースは URI (Uniform Resource Identifier) で表される一意的な (ユニークな) アドレスを持つ。
 それは大概、訳の分からないトークンキーかセッションキーのような形式になる。

◆アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
 多くの場合、HTMLかXMLに情報およびその他のリソースへのリンクを含める。
 これによって、リンクを辿るだけで、必要な情報を参照できる。
 状態を逐一保持する必要はない。

これらの設計思想は、SOAPやEJBなどの思想と明らかに異なる。
むしろ、よりシンプルに考えたものだ。

そして、この設計思想を最初に実現したのが、Ruby on Railsだと思う。
少なくともRubyKaigi2006のDHHの講演を読むと、彼がREST実装を強く意識しているのが読み取れる。
更に、最新のRails2.0では、RESTサポートが強化され、セキュリティも改善されていると言う。


Ruby on Railsの凄さは、下記4点に集約されると思う。

・フルスタックなWebフレームワーク
・CoCというシンプルな設計思想
・RJBを使うと、Ajaxと親和性が高い
・RestfulなWebフレームワーク

最後のRestfulという概念は、Ruby on Railsを離れて、もっと抽象化できるはず。
そんな内容が書かれていると思うので「RESTful Webサービス」を読んでみようと思う。

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

2008/02/07

Appleケア店員は優しかったヨ!

3ヶ月前に購入したお気に入りのiPodに、液晶に白いノイズが混じるようになってしまった。
先日、Apple心斎橋店に行く時があり、何とかしてもらえないか頼んでみた。

すると、購入1年以内だったということで、交換してもらえたヨ。
ラッキー♪

それ以上に驚いたのは、お気に入りのiPodに張ってある薄い透明のシールカバーをわざわざ外して、交換したiPodに張り替えてくれたこと。
セロハンテープを使って、やや手間取りながらも、丁寧に張り替えてくれた。

iPodは単なる音楽プレーヤーだけでなく携帯フォトストレージと化していたから、すごく大切にしていたからね。
Appleさん、ありがとう♪

お金ができたら、MacBookを買うかもしれないヽ(^o^)丿

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

2008/02/06

システムのリプレース案件が最も危険な理由

Joel on Software」を立ち読みして興味深く思えたことを書く。

「あなたが絶対すべきでないこと PART I」という章がある。
Netscapeがブラウザの90%を占めていた頃、何を思ったか、彼らはNetscapeのソースコードを一から書き直すことを決心した。

Netscpapeのアプリをアップデートしていくには、そのソースコードを書き直さねばならない。
文字列を分解してゴニョゴニョした処理をして返すだけの関数が2ページもある!
タコなソースだよ!と。

でも待ってくれ。
このIF文は、IEの古いバージョンのバグに対応するために、ナンシーが書いたものだ。
この処理は、Windows95で動かすために手を入れたもので、ボブが書いたものだ。
つまり、このソースコードは見た目は奇怪でも、きちんと動いているし、過去のバグフィックスも積み重ねられているんだよ。

もし一から書き直したとしよう。
すると、また、これらのバグフィックスを一からやり直す羽目になるんだよ。
何故、IE5.0で動かない?
何故、Windows95で動かない?
何故、MacOS8で動かない?
要らないって? でもお客から苦情が来てるんだよ。

それから3年余り、Ver4.0のまま止まったまま。
ITの世界で3年は途方もない時間だ。
そしてVer5.0をすっ飛ばして、Ver6.0をようやく出した時、Netscapeはシェアを獲得できなかったばかりか、会社そのものも消えた、と。

この逸話には、工業製品レベルのプログラムの品質について、いくつかの示唆を与えている。
一つは、システムやアプリのリプレース案件は非常にリスキーなことだ。

IT業界の業務システム開発は、システムのリプレース案件が非常に多い。
以前はメインフレームでCobolで作っていたシステムを、オブジェクト指向言語でオープン系のシステムで作り変えたい。
VBやAccessで作っていたクラサバのシステムを、Webベースのシステムに作り変えたい、とか。

これらの案件は非常にリスキー。
確かにそれらの技術は古すぎて、スケーラビリティもユーザビリティも耐えられないだろう。
しかし、数年もかけて運用してきたと言う事実はある。
つまり、色んな業務フローに対するバグフィックスや機能追加を重ねて、安定稼動したシステムになったのだ。

それらを捨ててスクラッチで作り直す時、過去のノウハウも全て捨ててしまうことと同じ。
お客さんから見れば、既に動いているシステムがあるのだから、仕様ははっきりしているでしょう、と思うだろうが、肝心のシステムは中身が全く違う。
運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。
同じソースコードの断片は一つもないはず。

リプレースする最新の技術力をコントロールできるか、そして、仕様を完全に設計しきれるか、が問われる。
普通は、どのプロジェクトもデスマーチになると思う。

もう一つは、プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。

言語が違えば、そのライブラリを再利用するのは難しい。

とはいえ、最近は、JavaからCのソースをコールしたり、RubyからJavaやC#のソースをコールすることもできるようだが。

特に再利用性は、そのライブラリの粒度に大きく依存する。
再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。

IT業界で仕事してきて、同じような失敗を何度も繰り返しているような気がするのは、上記の現象が解決されないからだろう。
システムのリプレース案件ほどリスキーな仕事はない。

追伸

この本の著者Joelさんは、来週のデブサミに来日されるとのこと。
ちょっと楽しみですヽ(^o^)丿

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

« 2008年1月 | トップページ | 2008年3月 »