SeasarCon 2009 Whiteにいってきました。

SeasarCon 2009 Whiteに行ってきました。今回が2回目の参加でした。毎度勉強になりますね。

Wicketとシステム開発の現場

id:t_yanoによるWicketのセッション。ドワンゴでやっている実践的な話が聞けたのが非常に参考になりました。特に役割分担の所の「コンポーネントを作る側」「コンポーネントを使う側」で分けるというところは、なるほどなと思いました。今まで自分のやっていた開発だと、そこそこのスキル者が始めに、AbstractPageみたいなのを作って、あとはページ単位で担当を分担みたいなことをやっていたので、「コンポーネントを作る側」「コンポーネントを使う側」というやりかたも非常に効果的な気がして新しい発見でした。あとDRY=正義ということでExcelのデータ読み込みんでバリデートを作るというのも面白かったです。実際、このへんは設計書とかで入力条件とかまとめる際に、よくある話なんじゃないかと思っていて自分でも試してみたいです。
そしてWicket本でましたよ!

オープンソース徹底活用 WicketによるWebアプリケーション開発

オープンソース徹底活用 WicketによるWebアプリケーション開発

テスト駆動開発のこころ (TDD はじめの一歩)

f:id:yamkazu:20090314140301j:image
id:t-wadaのセッション。実は和田さんのセッションは初めて。非常に丁寧な説明で分かりやすかったです。あと書籍の紹介が所どころにでてくるので、今後の勉強の足がかりとして非常に参考になります。

テスト駆動開発入門

テスト駆動開発入門


リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 76人 クリック: 2,540回
  • この商品を含むブログ (277件) を見る

Java言語で学ぶリファクタリング入門

Java言語で学ぶリファクタリング入門


このあたりから読み始めて見たいなと思いました。

T2でつなごう! -つなぐつながるWebフレームワーク「T2」の紹介 : 米林 正明、片山 暁雄

f:id:yamkazu:20090314150235j:image
T2は前から触ってみたいと思っていたのですが、何か色々勘違いしていたことが色々発見できました。T2は単なるStruts等のView周りのフレームワークの一つだと思っていたのですが、ではなくクライアントとユーザコードの仲介役という所を目指しているという所です。ユーザ自体がT2をコントロールしてほしい等、T2における思想のお話が非常に参考になりました。近いうちに試してみたいです。

Hudsonを用いたOSS開発

id:cactusmanによるHudsonのセッション。Hudsonを利用した実際の運用について話が聞けたのが良かったです。実際に今仕事でHudsonを使っているので、是非参考にしたいと思います。
今後の課題にも挙げられてましたがバックアップについてですが、私個人としてはしたほうが良いかなと思っています。仕事で使っているからなのかもしれませんが、ビルド環境が壊れた時に迅速にリカバリ出来る方法は確保しておいた方がよいと思いますし、Hudsonの魅力であるレポーティング傾向を後から何か有効な情報として活用したい時は、最新のビルド状態だけでなく以前のビルド結果も保存しておく必要があるのかなと思っています。ちなみに今はHome directory(.hudson)のディレクトリをデフォルトから変えて、DRBDでミラーリングして保存しています。

LT

最後のジャンケン大会で見事勝利を収めました!ジャンケン大会のなかでいくつかの書籍ごとにジャンケンをするという形だったので唯一もってない本がこの本だったので普通に「ありがとうございます」。読みます。
サインも頂きました。
f:id:yamkazu:20090315153740j:image
頂いた本はこちら。

Eclipseで学ぶはじめてのJava

Eclipseで学ぶはじめてのJava

懇親会

懇親会でWicket本に矢野さんからサインを頂きました。
f:id:yamkazu:20090315153709j:image


ということで、どうもみなさんお疲れさまでした!


以下メモ

Wicketとシステム開発の現場 : 矢野勉

なぜ新しいフレームワークなのか。
  • ユーザの要望は変化していく。
    • その時のフレームワークというはそのときのユーザの要望によって作られている。
    • Strutsが出来た時はStrutsの機能の要望が強かった。今はJavaScriptAjaxといった所の強い要望がある。時代によって変わる。
Wicketとは?
Wicket採用時の心理的な壁について
  • 今までにない技法をとっている。
    • しかし、今までのところに踏みとどまるのもリスク。
    • ユーザの要望にとも応えられなくなる。むしろ「どこに進むのか」を考えるべき。
  • Wicketが採用している技法はほぼすべて、もともとJavaにあったものばかりで新しい訳ではない。
  • 「技術的に難しい」と「やったことがない」を混同するするな
    • やったことないことはやらない=今まで出来たことしかできない。ユーザーの要望に答えられるのか?
  • 人を集められるか?
    • 経験者はすくない。なにをやってほしいのか、を考える。
  • Wicketオブジェクト指向
    • デザインとオブジェクト作成が分離している。
    • またオブジェクトの作成と、オブジェクトの使用する側はでわけられる。オブジェクトの作成はスキルが要求されるが、オブジェクトの使用側はスキルを要求されない。使用側はコンポーネントの中身について知っている必要はない。結果役割の分担が可能。
  • 教育コストが...
    • 教育コストは払う必要がある
    • 開発開始前意にちゃんと1週間くらい研修をやるべき。これはWicketに限らず、どのようなFWの案件でどれでもいえること。
    • そのときの集める人のスキルとトレードオフ
Wicketの機能
  • 基礎を作る側と使う側の分離が可能。リスナーとコンポーネント
  • パッケージングと再利用。必要なものを全部まとめてjarにすることも可能。
  • ビヘイビア
  • 豊富なリスナー
ドワンゴでやっていること
  • HTMLモックを先に作成。ユーザーレビューである程度固める。モックをそのまま開発に使用し、細かい点は実運用の中で指摘してもらう。
  • 自動化
    • マスタメンテ用アプリはVeleocityを使ってWicetのアプリケーションを自動生成
    • リスナによる機能の自動追加。WicketGoogle Guice統合機能を利用。
      • リクエストパラメータの処理はめんどくさい。だったらリスナで検知して勝手にフィールドに入れてしまおう。リクエストパラメータの注入。
  • アプリケーショントランクザション
    • 検索入力確認環境までがアプリケーショントランザクションの範囲。アノテーションを利用して同じ名前のところは同じDB操作として更新される。
      • IComponentInstantiationListerで実現している
  • バリデーション
    • 結構面倒くさい処理。表をそのままプログラムに読み駒せてバリデーションできたらようない?Excelよみこませてやらせている。DRY=正義。Excel使っているけいど正義!
  • 入力画面と確認画面って二つ作るってうざったくないか
    • 前のページの情報を次のページを渡すということが出来る。ページ内のコンポーねんとを操作することが出来る。その結果で確認画面を作る。
  • 自動テスト
    • Hudson使ってるよ
    • WicketTesterはページの遷移まで確認でる
Wicketはこういう層にむいている
  • 自分たちが実現出来る機能をふやしていきたい、拡張していくたい人。
    • 例えば自社でサービスを提供していて、フレームワークの都合で妥協出来ない。お客さんによりよい機能を提供してあげたい。メンテナンス可能でさらに機能各調整が高い。
  • プログラミングなしなんていう幻想を追いかけない人。よりよいUI、よりよい機能、よりよいサービス。それを目指すなら、プラグラミングなしなんて幻想。
  • Wicketを使ううとアプリケーションの作り自体が変化する。「やれること」のベースラインが底上げされて、発想自体がかわる。古い人はいろいろ追加用件とかに敏感なのはこのへんか。

前に進みたい人は使ってみてください!仕事で使ってる人も多し!

テスト駆動開発のこころ (TDD はじめの一歩) : 和田 卓人

TDDとは
  • 1.テストを書き、2.そのテストを実行して失敗させ、3. 目的のコードを書き、4. 1でかいたテストを成功させ、5.テストが通るまでフィファクタリングを行う。6.1-5を繰り返す。
  • Testとは
    • DeveloperTesting、CustomerTesting、OATesting
  • DeveloperTestingとは
  • 3本柱
    • バージョンニング(絵巻長!)、テスティング(JUnit等)、自動化
  • TDDのサイクル
  • TDDはテスト技法ではない。TDDは設計技法です。
    • 品質保証をする為のものではない。保証が目的ではない。
    • バグ発見とコスト。人力でのテストでのバグ発生率を減らす。
TDDのこころ
  • 一つずつ、少しずつ
    • 複数相手にしない。ひとりずつ対処する。すばやく回す。
  • REPL Rad Eval Print Loop
  • 自分が最初のユーザ
    • eat your own dog food まずお前が使え。綺麗なコードとは、他人が使うこと、よく自分で考えることが大事。
  • 不安をテストにする。
テストは人のためならず
  • TDDの始めの一歩
    • 一人でも始められる
      • 読書、写経、動画、etc
  • 勉強会に行きましょう
    • WORKING EFFECTIVELY WITH LEGACY OCDE
    • xUnit Test Patterns
  • FAQ
    • テストのないコードが沢山あるんだけど
      • WORKING EFFECTIVELY WITH LEGACY OCDEをよめ
    • TESTしにくいところは
      • xUnit Test Patternsよめ
      • ログだすとか目で確認等の所は経験が大事
      • ユーザビリティのテストは今後も出来ないだろう
    • どこをテストすべきですか
      • 達人プログラマー -ソフトウェア開発に不可欠な基礎知識をよめ
    • デバッカーはなぜだめなのか?
      • あとが残らないから
      • 名前がよくない。トレーサーとかにしとけばよかった。
    • テストの単位
      • 1クラスファイルに1テストファイルに?1メソッドに1テスト?
      • ある状況について、このテストという単位で作成した方が良い
    • リファクタリングにおわりないんじゃないか?
      • 今のところ終わりを判断する仕組みははい。
    • カバレッジ100%の悲劇
テストはスキルです
  • 才能ではなく取得可能
  • 写経しよう!

T2でつなごう! -つなぐつながるWebフレームワーク「T2」の紹介 : 米林 正明、片山 暁雄

Webを取り巻く環境
T2とは
  • Webフレームワークである
  • テーマ「つなぐ、つながる」
  • クライアントとユーザコードの仲介役
T2のスタイル
  • アノテーションドリブン
  • 基本的にステートレス
  • 特定のコンテナへ依存しない
  • ユーザーに介入してほしい
    • T2自体を使ってほしい。ユーザ自体がコントロールしてほしい。
      • コアはシンプルにextで拡張を提供
      • できればプロジェクトごとに必要な機能を作ってほしい
T2の目指すところ
T2の機能紹介
  • リクエストとPOJOのマッピング
    • ページアノテーションをくらすにつけるこでPageを判定
      • @GET,@Postでメソッドを特定
      • @ActionPathでメソッドを特定
      • @AjaxAjaxのアクセスの判定
      • @Amf(0.6から)
      • @Ddefault とれも一致しなかった場合
  • アノテーションマッチ
    • 複数のメソッドがマッチした場合
    • 同じ数のアノテーションがマッチした場合
      • 先に使った方を使用
      • 検討中
    • マッチするものがなかったら
      • Defaultをよぶ
      • ない場合はエラー
  • メソッド引数特定方法
    • 引数のアノテーションを見て、引数を解決
      • @RequestParam. @RequestHeader @SessionAttr @Upload @Form @Index @Var
    • 引数の型をみて、引数を解決
      • HttpServletRequst,HttpSerletResponse, ServletContext,Cookiee,WebContext,Request,Response,UploadFile,ErrorInfo
  • レスポンス
    • 戻り値として、Navigationインタフェースを実装したクラスのインスタンスを返す
      • Forward,Redirect,SimpleText,Direct,Json,NoOperation,PassThrough
  • DIコンテナ比依存

Hudsonを用いたOSS開発 : cactusman

  • CIとは
  • CIニのメリット
    • ソースコードの状況が把握しやすい
      • ビルドが通る、通らない
      • テストが通る、通らない
    • ユーザがビルドするときにはまりにくくなる
  • Hudsonとは
    • OSSのCIツール
    • JavaWebStart、javar -jar hudson.war、好きなサーブレットコンテナで起動可能
  • Hudsonの役割
    • チェックアウト、ビルドスケジュール管理、通知、レポーティング、ログの保存
  • Hudsonの機能
    • SCM対応、通知機能、綺麗なレポーティング、cronライクなスケジューリング、jobのチェーン、master/slave方式のクラスタリング、ファイルの正門
  • XFD
  • 実例
    • 地豆で使用しているPlugin
    • Hudsonのアップデートは手作業
    • バックアップ
      • 特にしていない
    • Hudsonで2時間おきにSCMをポーリング
    • job
      • 基点となるものからチェーン
      • jobごとにワークスペースをわける
    • メリット
      • テストが充実
      • ソースコードの状態を把握
      • JIRAヤFisheyeなどの他のツールとの連携
    • デメリット
      • あえて言えば、マシンリソースが必要
    • 苦労した点
      • ロジェクトの途中でHudsonを導入したのでそもそもビルドができない。JUnitが真っ赤。
      • Eclipse PluginとMaven2の相性が悪い。依存ライブラリの2重管理。
      • Maven2がHudsonで実行すると何故か動かない。
    • 今後
      • 自動化出来ることをやっていく
      • 動作しないところを調査、改修
      • データ収集
      • バックアップ(そもそもする必要があるのかな)
  • SesarでのHudson
    • プロジェクトは5つ
    • SCM:Subversion
    • ビルドツール:Maven2
    • ユーザ認証にLDAPを使用
    • 複数のDBでのテスト
      • 独自のPluginを使用
    • 導入後の感想
      • DBテストは充実、S2JDBC
      • 品質が安定した。
  • CodeReposのプロジェクトをHudsonでビルドしている
    • vmの環境でも動きます
    • jhudons_botをfollowしろ!
  • HudsonのPluginの作り方
    • PluginImplクラスで拡張ポイントを実装していく
    • viewはJelly
    • 詳しくはWikiを