Java EE勉強会 第21回（at 新宿某所）
ポジションペーパー 【こんな】Method【あります】
- かっくん Class#getResource、Logger.global#info
- ひがさん ClassLoader#getResource
- manholeさん Class#cast…Tiger 1行の文字数減らせる
- まこたんさん
- でわさん
- koichikさん
- t-wadaさん Object#use(Class)…Groovy
- 塚田さん（happieさん）
- 鈴木さん getDeclearedMethod
- 米澤さん StringBuilder、IF NOT…VB
- 的場さん（matbatさん） String#split、org.apache.jakarta.commons.lang.StringUtils.join
- shotさん hoge.getClass().cast(obj)←かぶった、StringBuilder…Tiger
- taediumさん Arrays.equals
- 星野さん
- 上田さん javax.imageio.spi.ServiceRegistry
- mopemopeさん function.toString()…JS
- 大橋さん
- ぬまがきさん（marrowのアニヲタな日記） proxyクラス
- くすもとさん
- とみおかさん くすもとさんの元同僚
- せとあずささん 公認審判員 Throuable#Throuable(Throuable)、Boolean#valueOf(boolean)、javax.swing.table.TableColumn#setMinWidth(int)、java.lang.reflect.Array#newInstance(Class, int)
- 吉田さん（EY-Office） ServletのdoPut、doDelete
- hirataraさん stringコンストラクタ、string,intern()
- もなじろうさん GRailsいじってる。MethodInvocation(メソッド名, パラメータ）
- 大田さん（FFC） Arrays、Collectionsのメソッド
- むろきさん（FFC）
How to start up opem source project（ひがさん）
- ネパールの国際ITカンファレンスでの発表
- ネパール
- 標高1000mくらい。超暑い。湿度98％。盆地。突然スコールが降る
- 大きな都市は二つ。首都カトマンズ（300万〜100万人、登録されている人の数？）、ポカラ
- 発展途上国、道が舗装されてない、信号がない、交差点では引いた人が負け
- 排ガス規制ない。空気汚い。世界で一番空気を汚している。現地の人マスクしている
- ポカラ、トレッキングのスタート地点。軽井沢に近い。観光客向け
- 主要なビジネスは観光。次の産業の核を作ろうとしている。一番期待しているのがIT
- ITのレベルは日本の10年前くらい。Webアプリの考え方があまりない。ほとんどクラサバ。VBが多い。一部Delphi。Javaを知らない人が結構多い（半分くらい）。オープンソースは1/3くらいしか知らない
- ようやくLAMPという言葉が入ってきた。でもどうしたらいいか、という段階
- 今はオープンソースといえばLinux。まずはローカライズ、ネパール語化が主な活動
- DBはMySQLは一部では使っている。Oracleとかライセンスの考えがいい加減
- シーサーはスフィンクスの親戚
- S2ができた経緯
- 2003年1月 S1 アプリケーション・サーバー
- 2003年12月終わり頃に事件、S1の開発やめよう。全く違うアーキテクチャのプロダクトにしよう→DIコンテナ（その辺の事情はまこたんが知ってる）
- 2004年3月25日 S2の最初のバージョン、Spring 1.0に合わせた
- DL数
- オープンソースとしての規模はアジアでは一番。世界でも有数。Springのコミッタは30人くらい（昨年、Rod来日時の情報）
- ソースコードを書いている開発者自身が一番メリットを受けている
- 見られるものはきれいに書きたいというモチベーション。ソースがわかりやすくきれいになる。コーディング能力が向上する
- 他のOSSのコミッタにもメリット
- そのまま使う。ソースを読んで参考に。健全な競争
- 誰でも自由にソースコード取得できる
- コストがかからない。気軽に試せる。ユーザー数が増える。数多くのフィードバックを受けられる（使われていてもフィードバック少ないと成長しているわけでない）
- コミッタになることのメリット
- 技術的なスキルが上がる。ソースコードを読んで書く
- JavaDocプロジェクト、メリットある？→せとあずささん「ある」
- コミュニケーション能力
- オープンソースの開発者はとんがったイメージあるが、同じプロジェクト/ほかのプロジェクトの人と議論して仕様考えたり。コミュニケーション重要
- リレーションシップ、知り合い、充実した人間関係
- ひがさん自身知り合った人とお仕事すること多い
- パブリシティ、知名度
- 今の企業はエンジニアを評価する体制が整っていない。上司が評価。技術的なところを知らないラインのマネージャ。作ったものを見て、すごいのかたいしたことないのか判断できない。どうしようもないものでも、同じ時間働いてると同じ評価
→よくない。といって急に上司は評価できるようにはならない
→外から変える。勉強会に参加。OSS開発に参加。パブリックな場に出ていく。きっちりアピール。外の知名度上がっていけば、自然に会社の中の知名度も上がる。営業が他の会社に行ったときに、お客さんから「あなたの会社の誰々さんが…」ということで広まる - 会社の中だけでがんばって評価があがるというのは正直、難しい。Googleとか例外はあるが。いつか評価されるという甘いことはない。会社の中で評価されないとその人自体腐っていく。社会に貢献しつつ知名度を上げるのはいいこと
- 今の企業はエンジニアを評価する体制が整っていない。上司が評価。技術的なところを知らないラインのマネージャ。作ったものを見て、すごいのかたいしたことないのか判断できない。どうしようもないものでも、同じ時間働いてると同じ評価
- 技術的なスキルが上がる。ソースコードを読んで書く
- ファウンダであることのメリット
- マネジメントのスキル
- マーケティングのスキル
- 戦略を立てるスキル
- どういう戦略を立てるかを常に考える
- Seasarでいうと、5月EJB仕様リリース、同時にJPAも。それにどう対応するかという戦略。SeasarはEJBのオルタナティブと思われていた（Rodはwithout EJB 3とか言っている）
- 二つの選択肢が考えられる。(1)EJB 3はダメ。DIのほうがOSSで鍛えられている。(2)標準にできる限り従いますよ
- 未来が左右される重要な選択。Seasarが選んだのは後者。Seasar 2.4。DIコンテナとしての顔。EJB 3のアノテーションを解釈して動くこともできる。EJB 3モードみたいな感じ。
- JSF、EJB 3、JPAは仕様。実装は誰がやってもいい。ただし、誰がつくっても同じになる。同じ仕様に基づく限り。内部は違っても使う側からすれば同じようなものになる。
- 差別化。そうでなければ、最初の人が勝つか、大きな会社が勝つか
- ほっとくとJBossが勝つというのが妥当な見方
- どうすればいいか。仕様はあるけど完璧じゃない。JSRはフィードバックそんなに受けられるわけではない。ある程度は使いやすいがある程度は使いづらい
→より使いやすくしましょう。TeedaだったらレイアウトをHTMLでできる。あと、コンテナのホットデプロイ。リブート不要。LLが備えた特徴をJavaで生かす - というようなことを短期間で調査して決断しなければならない。ファウンダは結構たいへん
- 立ち上げるときに考えるべきこと
- コンセプト
- ユーザーが最初に見るのはコンセプト
- このコンセプトなら使おうか。人の気を引くものでなければそっぽを向かれる。S2では現場の人の作業をできるだけらくにしてあげたい
- 名前
- キャラクタ、マスコット
- リリースプラン
- できる限り短いほうがいい。ユーザーのフィードバック早く反映できるとより早く次のリリースできる。加速できる。報告して次の日に修正。ユーザーにとっては短ければ短いほどいい。リリースはあとにしがちだけど、頻繁なほうがユーザーにメリット
- ユーザーをテスタ扱いするな
- ユーザーをテスタと勘違いしている開発者いる。テスト十分じゃないけどリリースするからテストしてね、とか。テストは開発者が書くのが堅い。お客さんはテスタじゃなくて有意義なフィードバックをくれるひと
- ブログ
- MLがメジャーだけど、敷居が高いというイメージ。参加することの敷居とか、メール出したときにぼろくそに誰かに叩かれないかとか（MLで勝手なこと言っていいという意味ではない）。
- イベント
- コミッタ
- プロダクトの競争力高めるにはいいコミッタ必要。いかに確保するか
- コンセプト
- Open Source 1.0
- 開発者は作りたいものを作る
- ML。クローズドな意見の吸い上げ
- コミッタが参加してくれるのを待ってる
- Open Source 2.0
- ユーザーがほしいものを作る
- ある商品をあるメーカーが作るとする。自分たちが作りたいから作るというメーカーいない。ユーザーが何を求めているかを市場調査して企画を練っている。売るために必要。今のオープンソースはそうした努力をしていない。今後はメーカーと同じような努力が必要
- ブログ。不特定多数の意見。フィードバックが多くなる。より多くの人の意見を採り入れる
- コミッタを募集する。待ってちゃダメ。優秀な人たちを積極的にリクルーティング
- 金は重要（by 獄長）
- ユーザーがほしいものを作る
Pro EJB 3読書会 第1回（by shotさん）
- JavaのPersistence戦略の歴史
- なぜまた別の標準？
- 理想のO/Rマッパー（5ページ）
- インピーダンスミスマッチの話（説明略）
- メリット1
- メリット2
- 以下2章
- Entity
- Entity Manager
- まとめ
- POJOを使って簡単に永続化
- @Entity
- Configuration by Exception
- Entity Managerが各Entityの永続化の仲介役
- 永続コンテキストごとに設定を保持できる
- どのEntityが対象なのか
- 接続先のDB
- POJOを使って簡単に永続化
- mergeでSELECT走る？O/Rマッパーは毎回SELECTするのが基本。バルクアップデートの話、JPQLは貧弱
- 次回は3章は飛ばして4章から。担当はひがさん
- JPAの勉強におすすめ処理系はJBossのEmbeddable EJB 3かS2Hibernate JPA。このメンバーならおすすめは後者（質問：星野さん、回答：ひがさん）
その他
- セレブ、ディスプレイアダプタ、ゲットならず
- 某氏が某社をやめたと聞いてびっくり
- パワポをめくるときに緊張して矢印キーをダブルクリックしてしまうクセは直したい
- 次回は8月26日（土） 追記 LL Ringの日でした。orz
