2005年02月05日

———————————————————————-

顧客からすれば、システムに対して、バグがあるかどうかは満足度にあまり関係がない。
顧客の満足はそういうところにあるわけではない。

少しバグがあっても、業務を円滑に行える使いやすいシステムであれば評価するし、
いくら最先端の技術を使って、再利用性の高いシステムをバグ0で作り上げても
業務的観点で使えないシステムは評価されない。

顧客⇔開発者の関係は、恋愛と同じで、完璧にわかりあえるなんてことは絶対にない。
ただ、顧客満足とはそういうものだ。

顧客の立場からすればこの業界の人間は、
毎回毎回わけのわからない英語3文字の熟語並べ立てる。
それでは、2年前にあなたが言ってたあれはなんだっの？という印象を抱いている。
英語を使わずに全て日本語で説明することができないのならば、
そのSEは完璧に説明内容を理解しているわけではないのでは。

営業的には0か1しかない。受注するか、失注するか。
半分というところはないため、いい加減なことを言ってでも受注しなければならない。
パッケージソフトの営業は売ったもん勝ち。
ITコンサルは偉そうにいい加減な事を言って言いっぱなし。
SIの開発はゼネコンがビル作るのより全然ファジーだ。
そのため後半は献身的な働き方になる･･。

この業界、受注するまではお互いハッピーだ。
お客は信頼してXX億でよろしく頼む!と言う(何を頼むのかよく分かってないまま・・)
受注した側はXX億で任せてください!と言う(何を作るのかよく分かってないまま・・)

開発側からすれば、以下の理由で労働集約的にいくしかない。
・顧客からもらえるお金は上限が決まっている
・利益は出さなければならない⇒少しでも安く
・顧客の言うことは聞かない⇒費用がかさむから

そうしていくと、物事が筋違いの方向に進んでいく。
もともと”コンポーネントの再利用性”は本来生産性を高めるためのものであり、
工数や人月を減らすためのものではない。
UMLを使えば･･･というのも、ただのツールであり、
UMLを使えば良い要件定義ができるわけではない。
ただ単に手段の導入がしたいだけで、それを取り込むのはあまりにも危険だ。

ウォーターフォールの開発もきちんとできないのに
アジャイルな開発をうまくこなせるわけがない。
ウォーターフォールでも、アジャイルでも、
8割は今までの開発と一緒で、残り2割くらいが今までと異なる新しいものになる
くらいのつもりでいい。結局モノ作りは人に依存する。

アジャイルを選択したとたんに何をやれば良いのかわからなくなって手が止まって
しまうようなプロジェクトをいくつか見てきた。
一番顕著な例は、3つのイテレーションをまわし、順次移行していく予定が
結局最終的には3つのイテレーションは並行に流れて、
同時開発状態になってしまったもの。
言うまでもなく、悲惨な状況だった。

業務を知らない人間がいくらUMLを使いこなせたところで、
できあがったモデルは何の使い物にもならない。
また、経営者がUMLなんて読めるわけがない。経営者はUMLを読もうとはしない。
UMLなんて勉強する暇があったら別のことをするはずだ。
メタモデルがメタモデルが、、と追いかけていく、
自称モデラーが作成するのはメチャメチャなモデルだ。
別にUMLでモデルを作ることが仕事ではなく、逆にモデルの絵なんてどうでも良い。
要件をきちんと整理することが仕事であり、
要件の認識を顧客ときちんとつめることが仕事のはず。

日本の業務システムはそんなに甘くはない。
もう少し原点に立って考えてみたらどうか。
店長の経験がない人が、小売店のTO-BEなんて導き出せるわけがない。
技術のノウハウだけでは太刀打ちできない領域である。
デブサミまとめTOPへ

———————————————————————

・講演者のマシンのスペックはわかりませんが、
ノートPCの割には立ち上がるのがものすごく早かった(eclipseと比べて)。
・VBで使ったアプリケーションの配布について機能がある。
Webｻｰﾊﾞに乗っけて各ユーザはそこからダウンロードしたりするような仕掛けを
簡単にウィザードを使用して行えるようになっている
・Webアプリケーションを作成する際に、今まではIISを入れなければならなかったが、
デフォルトでWebｻｰﾊﾞ(Tomcatみたいなもの)がついてくる
・コンフィグファイル等を勝手に自動生成するのではなく、
自動生成する際はダイアログボックスで聞いてくる
・ソースコードのリファクタリング機能もついている
・officeアプリもサポートしていて、エクセルのVBAよりいろんなことができる
(エクセルのセルの位置をベタ書きにしなければいけないところを変数化したり)
・2005からWindowsネイティブもサポートする
(今まではエンデベッドという別パッケージの購入が必要だったらしい)
・SQL Server2005と統合したため、SQL Serverプロジェクトなんていうのも作れる
デブサミまとめTOPへ

講演の概要はTDDとは？という話で以下のような感じでした
・目標が明確に(テストが全部緑になればいい)なって達成感がでる
・何回でも自動でコンポーネントが正しく動作することを保障できる
・ジャストインタイム。
その場その場で必要なものだけ作っていくから余計なコードが出来ない
・テスト駆動でリファクタリングをかけながらやっていけば
(それが手順化されていれば)コーダによって差がでにくい
・修正をかけるときに勇気が生まれる。
(ソースを変えても他もちゃんと動いてることを証明できるから)
・テストコード書くのは仕様を知らなければいけないから仕様をきちんと追うようになる
(仕様をきちんとおさえなくてもそれなりのアプリは作ることはできる･･)
・テストコードが動くドキュメントなので仕様との乖離がない

で、実演です。
ホテルの予約システムを作る。

文章にするのは難しいのですが、本当にテストコードから作ってました。
(そりゃそうか･･･)

そうやってやればいいのはわかってるんだけどなぁと思いました。
個人的になんでやり方はわかっているのに実践できていないのか、と考えてみました。
1.早く画面に出力したい。とりあえず自分のコードが動くところがみたい。
2.とりあえずどっかの機能をコピペしてやった方が早い
3.精査とDBアクセスしか自動テストやってないし、、
業務ロジックがテスト駆動で書けなきゃ･･･
のようなことかなぁと思います。
1.に関しては僕だけかもしれませんが、常に、なんとなくコーディングするときは
焦ってるので、ペアでコーディングレベルが似たような人とやったりすれば
解消されるのかなぁなんて思いました。
デブサミまとめTOPへ

はてなというのは元々は日記のサイトではなくて、
人力検索サイトというところからはじまったんだそうです。
人力検索というのは有料サービスで、知りたいホームページのアドレスを、
その人に代わってホームページ探しの達人が調べてくれるという仕組みだそうです。

現在ははてなダイアリーを中心として、30万人近いユーザがいて、
1日に1.6億ビューくらいあるそうですが、
一番悩まされているのが、名誉毀損であったり、プライバシーの侵害や、
差別的な記述だったりするそうです。
サービスをはじめた当初は全ての記事を会社の人間で読んで、
その都度ミーティングをして対処方法を
決定していたが、だんだんそうも言ってられなくなり、また、
記事を削除する基準等はその事例によってバリエーションが様々であるため、
全て明文化することはできない。そのため判例のような形式で
公開するようにしているそうです。

はてなは人間の豊かさのためのサイトだそうで、
その豊かさは、仕事と睡眠以外の時間でしか実感できないだろう、ということで
“デスクとベッドの間”が重要で、そこにはてなが一役買えれば、
というようなことをおっしゃってました。
ほんとはもっと技術的なところが聞けるのかなぁと思っていたんですが。。

開発の際に、メッセンジャーよりも非同期で、
メールよりも同期的にWikiやBlogを活用していて、
ペアプロに関しては、その場その場でペアにするかしないかを
決めてやるようにしているそうです。
デブサミまとめTOPへ

そもそもSOAとWebサービスがなぜ同じような土俵で語られるのか
よくわかってない上にESB(Enterprise Service Bus)という聞き慣れない単語まで
登場してしまっている講演でしたが、
要はPolarLakeという製品を紹介しながらESBというのはなんぞやという話でした。

・レガシーマイグレーションに関して、EAIとESBで何が違うのか
⇒考え方は全く同じ
●今まではEAIでバックエンドを隠蔽して下記のように実装していた
『フロント』
・EAI⇔J2EE Webサービス
『バック』
・メインフレーム⇔EAI キャラクタベースで
・サーバ⇔EAI APIで
●ESBを使っても上のEAIの部分がESBになるだけ
では何が違うのか？
●ESBの特徴
・SOA-イベントドリブンであり、非同期
・コンテンツベース
・複雑なXML変換に対応
・分散稼動(ここがポイント)

EAIは1度にドン!と導入しなければならないが、
ESBはインクリメンタルにインテグレートできる。
EAIよりも安価で、小さく産んで大きく育てることが可能(ROIを見極めながら)。

正直EAIすらもどういうテクノロジーなのかよくわからない自分には、
後半の話はかなり眠気が･･･。
デブサミまとめTOPへ

最近Webサービスという言葉が1人歩きして、
難しい方向に進んでいることに危惧を覚えている
そもそもWebサービスとは･･･
・異なるチームが異なる場所で異なる環境を使って開発し
・異なるセキュリティポリシー、異なるバージョン管理メカニズム、
異なるデプロイメントシステムにしたがって運用しているシステムを
・できるだけ迅速、柔軟、簡単に接続できるようにするための技術。

ただの技術のはず。

例えば、今まではトムクルーズという人について調べるのに、
・Googleで検索して
・Googleでイメージ検索して
・映画のDBサイトで映画情報を検索して
・amazonでトムクルーズに関する本を検索して
と、いろいろなサイトで調べなければならなかったが、
それぞれ、Googleや映画のDBサイトやamazonがAPIを提供することによって、
(こんなXMLをくれれば、こんなXMLを返すよ、といったようなAPI)
1度検索すれば全ての情報が手に入るようなサイトを作ることができる

例えば吉松氏はBlogで日記をつけるにも、
・Blogを書く
・画像をアップロードする
(Blogの機能に画像アップロード機能がないため別のサービスを利用)
・更新PINGを飛ばす
(Blogの機能に更新PING機能がないため別のサービスを利用)
という3つの手順を踏んでいた。
が、Blogサービス、写真アップロードサービス(よくあるカレンダー機能のようなもの)、
更新PINGサービスのそれぞれがAPIを公開していて、
自分が作ったスクリプトを用いれば1度でそれを全て行えるようになった。

それをライブ形式で行ってこのサイトにアップしてました。(Live from Developers Summit っていうやつです)
実装はJavaScriptで行っていて、ログを見せながらここであーでこーでって説明。
こういうAPIを公開するようなサービスによって、
ハッカーやその周りの人たちが食いついてきて、
写真をアップロードするfrickrというサイトは有名になったそうです。
(やっぱりみんな自分でスクリプト書くの好きなのね)

まさにこういうことがWebサービスなのではないか？
これらのAPIにはWSDLやSOAPという言葉は出てこない。
つまりWSDLやSOAPを使わなければWebサービスでない、なんていうことはない。
世の中に流れているXMLこそが重要で。あまり難しく考える必要はない。

———————————————————————
ちょっと聞きたかった話とは違いましたが･･･
デブサミまとめTOPへ

Seasar2は以下のような構成になっている
コア
・DIContainer+AOP
ファミリー
・S2Dao
・S2JSF
・S2Struts
・その他いろいろ
ツール
・Kijimuna：設定ファイルを自動的に書いてくれるツール(Eclipseプラグイン)

で、設定ファイルも含めたサンプルソースが出てきました。

お酒とそれを飲む人をプログラミングすると･･･

===============================================
《インタフェース》
アルコールインタフェース
public interface Alcohol {
　public String getName();
}

酒飲みインタフェース
public interface Drinker {
　public void drink();
}

《実装クラス》
ワイン
public class Wine implements Alcohol{
　public String getName();
　　　return "ワイン";
　}
}

ハードな酒飲み
private class HardDrinker implements Drinker{
　private Alcohol alcohol;
　public void setAlchol(Alcohol alcohol){
　　　this.alcohol = alcohol;
　}
　public void drink(){
　　　System.out.println(alcohol.getName() + "を飲みます")
　}
}

《XML設定ファイル(diconファイル)》
ワインとハードな酒飲みを結びつける
<components>
　<component name="wine" class="Wine" />
　<component name="drinker" class="HardDrinker" />
　　　<property name="alcohol">wine</property>
　</component>
</components>
============================================

てな具合です。
インタフェースと実装が依存していません、と。

実行する場合は、下記のような感じで、
コンテナによって結びつけられたコンポーネントをゲットするイメージです。
=============================================
public static void main(String[] args){
　S2Container container = S2ContainaerFactory.create("foo.dicon");
　↑上で作ったdionファイル.
　Drinker drinker = (Drinker)container.getComponent("drinker");
　drinker.drink();
}
=============================================

diconファイル(設定XMLファイル)の読み込みですが、
講演の後にひがさんに聞きにいったら、オブジェクトを結びつけるServletがあって、
そのServletがinitされるタイミングで行うそうです。
つまり、TomcatであればTomcatを起動する際に取り込むそうです。

で、こんなことをすると何が良いのか、ということですが、
・それぞれのクラスがPOJOになるので、自動テストがしやすくなる
・利用するコンポーネントの実装が終わっていなくても、
インタフェースさえ定義されていれば、モックオブジェクトを使って開発を進められる
というところだそうです。

——
と、ここまでSeasar2の(DIコンテナの)概要で、以下S2JSFについてです。

●S2JSFについて
S2JSFでターゲットにしている人は以下のような人だそうです。
・JSPをブラウザで直接レイアウト確認ができなくてイライラする人
・HTMLをJSPに変換する作業がイライラする人
(Tomcat画面にスタックトレースがバーンって･･･)
・JSFってStrutsより便利そうだけど乗り換えるほどではないと思っている人

JSFを使うメリットは
・リクエストの内容を受取るオブジェクト(StrutsでいうところのActionForm)と
ロジックを起動するオブジェクト(StrutsのAction)をPOJOにすることができる
⇒WebのAPIに依存せずに自動テストができる!
・ブラウザで入出力する値がサーバサイドのJavaBeansのプロパティの値を連動する
⇒精査エラーの場合はサーバ側のBeanに値を入れずに、
　JSFのコンポーネントが値を保持して入力値復帰する
・ボタンやリンクごとにコンポーネントのメソッド名を指定できる
今までActionでonClickされた値を受取ってどうのこうのってやってたけど、
その手間がなくなる

JSFのデメリット
・標準のJSFではJSPをテンプレートとしているため、
JSPのデメリットをそのまま継承する
⇒ブラウザで直接レイアウトや画面遷移を確認することができない
　デザイナに直接JSPは書いてもらえない

S2JSFの特徴
・テンプレートがHTMLである
⇒ブラウザで直接レイアウト・画面遷移が確認できる
　デザイナにHTMLを直接書いてもらえる
-HTML変換イメージ
　HTML:<input type="text" m:value="#{hoge.aaa}">
　変換後のJSFタグ:<h:inputText value="#{hoge.aaa}">
　⇒m:というのはおまじないで(S2JSFのnamespace)
　　hoge.aaaの部分はBean.Property
HTMLにちょっと手を加えるだけでJSFアプリケーションに変身
・どのAPIにも依存せず完全なPOJOで開発できる
デブサミまとめTOPへ

S2JSFの概念
・HTMLをコンパイルする(このことでブラウザでレイアウトを見ながら実装できる)
HTMLをSAXのイベントに変換(SAXのイベントに変換するのに
NirvanaプロジェクトのNecoHTMLを使用)
SAXのイベントハンドラでHTMLのタグをJSFのタグに変換して、
JSFのタグのツリーを構築する。
最初にアクセスされたときにや変更されたときに
コンパイルが走るようになっていて、
コンパイルされたツリーはキャッシュされる(JSPと同じイメージ)

登場人物
・HTML
・DTO(Data Transfer Object)
画面入力内容を運ぶオブジェクト。POJO。(StrutsのActionFormに該当)
・Action
StrutsのActionと一緒。POJO。ボタンやリンクを押下されたときのメソッド定義、
DTOをバックエンドの処理に渡したり、戻り値を受取ったり。
戻り値は自動的にリクエストやセッションにセット

『実装イメージ』
<html xmlns:m="http://www.seasar.org/maya"> ←名前空間
　 <head>
　　　 <meta http-equiv="Content-Type" content="text/html; charset=Windows-31j">
　　　↑で設定したキャラセットがレスポンスのキャラセットにもなる
　</head>
　<title>Hello</title>
　<body>
　　　こんにちわ<span m:value="#{bean.property}">hoge</span>
　　　↑のhogeの部分はモック(本番で使用されることはない。
　　　　HTMLとしてレイアウト確認の時のみ使う)
　</body>
</html>

他にもセレクトタグやList等のCollectionオブジェクトの取扱い(一覧表出したりとか)
Validationの仕組み等の紹介があり、その場で動かしながらの話でしたが、
ここでは書ききれないので、もし見たい人がいたら僕のところにきてください。
(そのうち今日のプレゼンの資料がアップされると思いますが･･･)
デブサミまとめTOPへ