到着しました。はしかで閉鎖されてます(笑)。案内に従って裏から入場しました。
Seasar2.4
ひがさん・・・真夏だ・・・(格好が)。あれ、しかも今年はAIR-ADGE使えるっぽい。
- Javaは生産性が低くて楽しくない？
- 設定ファイルが多過ぎる
- すぐに動作確認ができない
- これを解消するのがSeasar2.4
- ホットデプロイ
- 設定の自動認識
- デモ
- Project作成
- Tomcat立ち上げ
- DB立ち上げ、DB操作(H2)
- htmlの右クリックからページを開いて確認可能
- classにて、フォームの種類を指定する
- ヘッダ列・ヘッダ行を固定できるテーブルの例
- 視認時と入力時でフォーマットの変わる日付入力フォームの例
- 視認時と入力時でフォーマットの変わる金額入力フォームの例
- Step by Stepのプログラミング
- 1 step 書くごとに確認ができると、ミスが減る
- Seasarを使わない場合は、再起動とデプロイを繰り返さねばならない
- ページ駆動とテーブル駆動を組み合わせる
- ページ駆動
- ページ遷移で内容を引き継ぐデモ
- ボタンのidにgoXXXXとすると、XXXX.htmlに遷移できる。
- 他のカラムはid属性を基準に全て自動で引き継がれる
- モック用のデータは、onClickに対して"location.href=XXX"と書く。ここはidと2重定義か。
- 内容の引き継ぎだけならば、htmlの要素にidを指定するだけでコードは書かなくてよい
- Seasar2.5 について
- ブルーオーシャン戦略
- Without Java EE
- S2Persistence
- SePresentation
- 構成
- S2Framework
- S2Extension
- S2Persistence
- S2Presentation
- S2Tigerも取り込み
- ３つの柱
- 大胆にソースを削る
- 過去の習慣と常識にとらわれない
- 迷いをなくす
- 主な方策
- publicフィールド対応。アクセサ不要。
- DI用フィールドはpublicでいいんじゃない？
- テーブルのカラムと1-1のフィールドはpublicでいいんじゃない？
- インタフェース不要
- インタフェースに1実装なら不要。モックは継承すればいいでしょう。
- 必要最小限の登場人物
- publicフィールド対応。アクセサ不要。
- MLでオープンに仕様を話し合って、実装してドキュメント書いてβする
ずぼらな自分には、この戦略には多いに賛成できます*2。でも、 Java EE を簡単に捨てられないところがJavaコミュニティの弱さ(強さでもある)んじゃないかとも思います。
Seasarとともに歩んできた「Backlog」の開発事例
小さい部屋はやっぱりAIR-EDGEは駄目みたい。メインホールだけOKなのか。
- Backlogとは？
- TracやBugzillaのようなプロジェクト管理ツール
- 易しさと楽しさ
- 顔アイコンがあったり、明るい色を使ったりしている
- 規模 → 1400スペース、1800プロジェクト、4400ユーザ、300ユーザ/月
- Seasar2とは・・・フレームワーク(S2Dao等)のためのフレームワーク。特にAOPが良い。
- Seasar2を利用した理由
- アーキテクチャ
- DI → サービスとライブラリ同士ののりづけ
- 例：メール送信クラスを、DIによって入れ替える
- AOP
- 横断しない関心ごとへのAOP (パッチ的な利用をする。)
- パッチがファイル単位となり、マージしやすい
- キャンペーンによるロジック変更や、社内利用やデモ版に対するインタセプタ
- 本来のコードを汚染せずにパッチを編み込める
- S2Dao最高
- SQLが書ける
- 公開仕様策定
- 社内で標準的に利用している
- オープンソースなので、勝手にパッチを当てられる
- コミュニティが活発なので、ばっちり
- Seasarで困ったこと ・・・ 最近はかなり改善されている
- final や private が多過ぎて何もできない
- エラーメッセージがわかりにくい
- ライブラリ依存関係
- トラブルの解決方法
- ソース嫁！
- コミュニティ活用
- 原材料(ライブラリ)について
- Jcaptcha - Javaでキャプチャ文字を作成するもの
- Lucene 全文検索 → LuceneからIDを得てからin条件でSQLに混ぜ込むことで、全文検索とRDBMSを合体させた
- Sventon (アプリケーション) - WebベースのSVNリポジトリブラウザ
- 企業とOSSの付き合い方
- パッチやバグ報告はフィードバックした方がいい
- S2PagerのOSS化
- 社内のものがデファクトスタンダードになる。新しく覚えなくて良い。
- メンテナンス可能性・・・だれかコミッタがやってくれるかも？
- Seasar2は枯れていて、実績は十分。
- コミッタになって下さい。まずはMLから。
Tuigwaa
インストールCD配ってました。
- escafe → Easy Software Cafeteriaの略。sandboxから卒業。5つのプロジェクト。
- ユーザがアプリケーションを作るためのプロダクト
- 自分の欲しい物を自分自身で作る。「わたしが、つくる。」
- 5つのプロダクトとは？
- 入手、操作、導入、理解*3、応用が手軽
- ハッカー受け、最先端、派手さ、大規模、ミッションクリティカル、は目指さない
- 地道に開発を続ける予定。コミッタ募集。
- とぅいがーとは・・・Webアプリ作成Webアプリ。2005年の未踏。
- WEBアプリの3つのレイヤ = Webアプリ化されている、コストと時間がなくて無理、する気もない
- コスト・時間の壁と、イメージの壁
- コスト、時間の壁はEODで緩和される
- イメージの壁は、ユーザと開発者の壁。ユーザが作れればいい。
- Tuigwaaの機能
- コンテンツ管理 → wikiタイプ
- データ管理機能 → 好きな形で入力し、好きな形で出力できる。コンテンツとDBの連携。
- ロジック管理機能 → イベントと条件に対する分岐
- 内部的には、データをPOJOとして扱う。他のPOJOフレームワークとの連携が簡単
- Tuigwaaによる受託開発 → ポリシーには反する
- 客の目の前で作ってみたかった
- Tuigwaaの弱点を見つけたかった
- 基本機能でできないこと (拡張ポイントにより拡張した)
- 開発例 → 営業システム、会員制アンケート(ネット公開)、院生への指導共有、基幹業務システム(Buriも利用)
- 社内事例 → 秘書の女性が指導まったくなしで作ったWEBシステム、プロジェクト管理システム(グラフ等はJavaScriptで拡張)
- Tuigwaaの得意とするところ → 入れポン出しポン(マスタテーブル管理)
- Tuigwaaの苦手とするところ → 見た目の細かい要求、独自なビジネスロジック → ネットへ公開するシステム
- Tuigwaa は、まず情報システム部門の人に使ってもらいたい
- Tuigwaa 1.1α版
- 今後、複数のTuigwaa同士のデータを関連づけしたい
「えび」と「なでじゃこ」
人数少ない。レアセッションかも(笑)。
- えび → excelベースのルール実行ライブラリ
- なでじゃこ → 日本語スクリプトエンジン (えびとブリで利用)
- プログラムからの依頼で、えびがエクセルを解析し、なでじゃこが日本語解析し、プログラムに返却
- オフショアせんで、『「自動化すれば、よかろうもん」と思った。』『"高度"な"コード"を書く』
- えび (Excel Based Imperative)
- ルールの外出しツール → 仕様書を読んで仕様書を解析して仕様書通りに動く
- Decision Table
- Customizing Decision Table
- Table Pickup
- Check Rule Access Object
- エクセルで書けるのが素晴らしい。加工と変更が楽。
- Decision Tableとは → 業務ルールを条件と動作にわけてマトリクスで表現
- ユーザにヒアリングすると、ルール以外な邪魔な雑談が多い*4
- 結果と条件を、縦軸、横軸にとる。TrueとFalseが書かれていて、全てTrueだった結果が返る
- 別の書き方もある。CONDITION列とACTION列を用意し、CONDITION列のカラムに書かれた条件が全てTrueのものが選ばれる
- Tablepickup。縦軸と横軸に条件を書いて、カラムがreturn値になる
- バリデーション用のルール記述もできる。カラムにprescriptとかvalidateって書く？
- なでじゃこ なでしこベースの日本語スクリプトエンジン
- なでじゃこのプログラム実行の仕組み
- 今後の課題 → リファクタリング、関数を増やす
- "What You See Is What You Get!" を目指す
- Q&A
