朝から小雨...とあいにくの天気でしたが、そこそこ人は来ていたんじゃないかなぁー？
去年もそうだったけど、他のイベントに比べて若い人が多い！ よいよねー。
まぁ女性比率はやっぱり低いですがww
13:00-13:45 Wicketとシステム開発の現場
さて一発目はWicketを見てきました。
Cubbyのセッションともかぶっていたのですが、相方が行くということだったので...お任せして..行かなくてスイマセン..
前半部はWicket概要説明でした。
"見慣れない技法" (新しいフレームワーク) を始めるには確かにリスクもあるけど、自分の知っている技法に留まることもリスク。
"技術的に難しい" と "やった事がない" を混同してない？という事を話されていたのは、心に残りましたー。
後半はDwangoの案件でWicket開発をしている話でした。
案件の内容としては、社内システムで請求／支払をするようなものらしいです。
組み合わせは Wicket + Guice.
HTML先行で開発し、画面部分の仕様を始めに決めたらしい。
詳しい内容は分からなかったんですが、始めはHTMLで全て書いておき、実装時にWicketコンポーネントへ置き換えて行く作業って事なのかな..
プロジェクト用にカスタマイズ/自動化した部分は聞きごたえがありました。
マスタ登録部分はscaffoldのようにパパっと作るためにVelocityでコード生成。
リクエストパラメータの処理は
@Param("username")
protected String username
な感じ。
受け取る方がEntityの場合は、パラメータがIDのKeyにしてEntity情報を設定までしてくれる形になる。
@ObjectContextName("name")
で複数のPageで同じエンティティを共有する仕組み。
これは 検索-入力-確認-完了 という一連のアプリケーショントランザクションの間で共有するもの。名前で単純に一致して判断するようにしていたらしい。
バリデーションは、なんと！Excel記述されている内容を読み込みしてバリデータを自動追加。
なぜExcel?というのは、結局Excelで資料の提出が必要だったからということ。
Excelとコードと同じものを2回書くなんて...ってヤツですね。
確認画面は、入力画面と同じ項目でTextをLabelにしただけ...ってパターンは結構あるのですが、これも別に作るのは面倒！ ということで、確認画面は、前画面(入力画面)のコンポーネントを走査してラベルとして貼付け で作ったとの事。
これに限らず...ですが、その案件にとってめっちゃ生産性が上がる事って、案件独自のルールに基づいたカスタマイズですよね。それをぱぱっと作れてストレスフリーな開発できたら、カッチョ良いです！
んでー 最後に、WicketTester.
結構Wicketの良さってこのTestでないの？と思ってしまうくらい良さそうーって思ってしまうんですがww
画面でのテストって、絶対必要な所なんだけど結構面倒だったり、作るのに時間かかったりしません？
でも最近出て来たものは テストをする という前提でちゃんと作られてるんちゃぅ？とも思うし、GUIのテストの観点から見て、WicketはHTMLとSwingの間のいい所の路線いってんちゃぅ？とか思うんですけどー。
14:00-14:45 最新のDI&AOP
・コンポーネントの依存が減ると、分担しやすい ... といわれていたが、"結構一人でやった方が効率が良かったりする
・DIで依存部分のコードが減る...が、減った部分は結局設定ファイルへ。しかもコンパイルエラーにならなくなっちゃってイマイチ。
・実装部分をDIで入替できる...が、入れ替えしたいものって結局すくない。殆どのクラスの実装が一つだったりする。
・依存が減ってテストしやすい...けど、単体テストの時でなくて結合テストの時にはそこまでメリットがない。
んでー、結局ここらへんは生産性向上には思ったよりも貢献してない。それよりもHotDeployの方が貢献してるよね...でSlim3!
というお話でした。
話聞いての感想ですが、DIってそもそもどんなタイミングでどう使えば利点が生きるんだろ？..って思ってしまいました。私自身、業務で始めてDIContainer(S2)を使っている所なんですが、小さいプロジェクトというのもあり...イマイチあんまり利点がまだ理解できてないです。
確かに、DIは後で実装を入れ替えたり出来るのは便利だとは思うんですが、入れ替えたい！ってタイミングって、テスト時のモックとかなので運用に乗ってしまったらそぅ変えないですよね。
それだったら、入替したいクラスはFactory作るなりしてちょっとカスタマイズできるようにすればいいよーな気もする。入替するのがテストのタイミングだけなのであれば、それらの処理はmainのコードでなくてtestのコードで書きたい気がする。(テストの為だけに使いたい仕組みならば、その仕組みを本番環境に持って行きたくないという意味で)
まぁ、良くわかってないのだろうと思うのでナンですがww
15:00-15:45 T2でつなごう!-つなぐつながる Web フレームワーク
T2のキャラクタがキュート！ テツとイーダ。あぅいぅキャラクタが出てくるだけでなんだか優しい感じになっていいですねー。キャラクタ偉大です。カネウチカズコさん偉大です。
T2はステートレスなシンプルなフレームワーク。
@Page("/hello")
@ActionPath("/world")
@ActionPath("/world/{id}")
@Var("id") String id
@RequestParam("name") String name
...のようなアノテーションでの指定をして行く感じ。Cubbyと結構カブっている?
でもユーザが独自で拡張しやすいように...って前提で作られているようです。
DIコンテナ非依存ということで、Guice,Spring,Lucy,Seasar2などで動作可能！
インスタンスの生成はDIコンテナに任せて、T2はそれ以降の処理についての制御って感じ。
こういうのっていいですね。
使い慣れているS2と組み合わせて使ってみるのもよし、Guice使ってみたいから...というのもよし。しかも拡張前提で作られている(=拡張できる窓口が大きい)のであれば、あー！ってなった時もゴリゴリ組み込んだらなんとかなるんじゃ？って安心感もちょっとある。
あと、Ajax, Flex, AMF の対応ということでしたが...イメージがちょっと掴めなかったけど
HTTP, XMLHttpRequest, AMF などの各リクエスト/レスポンス をT2が切り分けて、対象の型が指定されているものにマッピングしてくれる..みたいな？
そういう部分は確かにフレームワークでやって欲しー感じww
16:00-16:45 差のつく勉強法200-35歳定年説を乗り越えるために何をすればいいのか
きしださんワールド満載で凄く面白かったです。
なんで定年になっちゃぅか？というと、「ついていけない」というのもあるけど「全部やっちゃった感」というのも出てくる。
んでも、全部やった...なんて事はないはずで、「知らない事がまだまだいっぱいある」 ということを勉強して知るのだ！ という内容でした。
勉強の内容として出て来た言葉を羅列してみると、
離散数学/ 集合 / グラフ理論 / 論理学 / 不完全定理 / 組合せ理論
プログラムを作るというのは、多くの言語やテクノロジを知っているだけだといいものは作れない。当然ながら、頭の中でどんな風に作るかなぁーって考える必要がある。
実はその「どんな風に」ってのが難しい/面白い所で、人との差が出てくる所だと思います。
実現できないと思った事も、実は発想次第で出来ちゃう事ってありません？
数百行のコードが、発想次第で数十行になっちゃう事ってありません？
オープンソースのコードを読め！と良くいわれる中の一つにこぅいぅ技術以外の所を学ぶよい機会だって事なんだろぅって思います。
昔からある ○○理論 ってのも、そんな力を身につける一つだと思う。
難しいだろーなーって思うけど、基本だけでも知っておくだけで随分違うのかも。
プログラムの事を中心に考えつつ読むと、結構面白いのかも。
おすすめされていた「論理学」っていう本を読んで、きしださんは日本語が良くなったそうです。私もこの本は読んでみます！ ニホンゴムズカシイノデ...
17:00-17:45 ライトニングトークス
これは観客いっぱいでしたねー。という事で内容は省略ww
最後に。
あんなに人がいっぱいいたのに、知っている人に偶然に会う機会が多くて嬉しかった。
カンファレンスのパンフレットで手を3回切りました。次回は切れない紙でお願いします...