・サイト
http://www.java-users.jp/?page_id=330
・まとめサイト
http://togetter.com/li/500961
・参加したもの
・H-1JavaEE6からJavaEE7に向かって
http://www.slideshare.net/OracleMiddleJP/java-ee-6-to-java-ee-7
・H-2ProjectLambdaEssential
・H-4失敗から学ぶAPI設計
http://www.slideshare.net/yusukey/api-ccch4-jjug-jjugccc-jjug-ccc-2013-spring
・R2-5[BOF]Groovy2.Xの新機能
http://www.slideshare.net/uehaj/jjug-ccc-groovy2x20130511
・全体的な感想
Lambdaの話と、Twitter4jのAPI設計の話が特にためになった。
Lambdaは、遅れてもいいからJava8に入って欲しい。
Lambda、Groovy（というか主にGradle）でクロージャ周りを使えるようになってきたけど、やっぱり書きやすさが全然違う。
全容を把握できてる訳ではないけど、うまくJavaのタイプセーフさとも組み合わさればJava8は広まりそう。
ネタでコーディングルールで、Lambda禁止とかあるけど、導入されるなら積極的に使って行きたい。
インターフェイスのdefaultmethod、implmentsした順で実装が優先されるとかいう理解をしてしまっていたけど、Twitterで指摘をいただいて試したところ理解が間違っていた。
別のdefaultmethod同士だと、やっぱりどちらの実装を選択するかを明示しないといけないよう。
https://gist.github.com/hiroisojp/5560120
Twitter4jのAPI設計の話、ライブラリとフレームワークという側面でAPI設計は結構変わると思うけど、
主にライブラリとして作って行く場合の設計意図の話が直接聞けてためになった。
・拡張ポイントはなるべく少なく
・クラス継承はさせない
・デザインパターンを活用しすぎない（初心者は詳しくない）
というところから、ライブラリとしてのスコープ（どの部分までを扱うか、どう提供するか）をブレないように設計するという観点が必要と感じた。
その他、細やかな点として、
・IDEの補完を活かせるようにする
・同一パッケージにして、検索性を上げる
・IDEの補完が効きすぎないようにする
・利用して欲しくないクラスを意図的に検索性を下げる
ex)z_T4JInternal***として、z（補完候補の最後の方にでる）、Internal（内部で利用しているクラス）というように意図を示す
といったのも参考になった。
・メモ
・H-1JavaEE6からJavaEE7に向かって
・JavaEE6の振り返り
・JAX-RPC、EJBEntityBeanは、EE6で廃止予定で、EE7からは「仕様上なくなる」。実際になくすか（下位互換を保つか）はベンダーに次第
・EJBコンテナをJUnitであげれる->サンプルコードはルックアップしてるがDI形式にできないのかな？（その方がスマートだと思う）
・JavaEE7のテーマは、「シンプル化」、「HTML5対応」
・EL3.0で実はLambda式がもう使える（SE7環境下で動作する）
・EL3.0でやり過ぎると、昔のJSPのロジック埋め込みに逆戻りな気がするので、ビューとロジックを分離して欲しい気がする
・H-2ProjectLambdaEssential
・Lambdaは、クロージャ周りが注目されがちだけど、（出自としては）クロージャのためではなくパラレルコンピューティングを導入するため。
・Lambda<<API（のほうが重要）
・functionalinterfaceでインターフェイスを定義すれば、Lambdaで書ける。
・@FunctionalInterfaceは、実装が問題ないかコンパイル時にチェックするためのもの（後で確認した）
・StreamAPIは、Groovyのコレクション処理に似てる気がした
・map、filter（戻り値がStreamになってるようなもの）は遅延される。->最適化されて速い
・H-4失敗から学ぶAPI設計
・「NoGGRKS」（親切に対応）
・シンプルにYAGNI。将来必要になるかもとか拡張性とかを考えすぎない。
・クラス数は極力増やさない。インターフェースは（なるべく）使わない。
・拡張ポイントはなるべく少なく。何でもかんでもやると逆に初心者に難しくなる。
・クラス継承はさせない。finalじゃないと意図しない挙動になることがある。
・一部finalでないものはモック用が主で、コメントで理由をつけている。
・ライブラリ自体を簡単に書くよりは、ユーザが簡単に利用できるようにしている。
・普通のユーザが戸惑うような作りにはしない。
・デザインパターンを適用しない。（やりすぎない）->知らない人が多い。
・IDEの補完を活かせるようにする。
・一般的すぎるクラス名にしない。
・IDEの補完がいきすぎないようにする。使うべきでないクラス名を異様にする。（z_T4JInternal*****）
・至上命題
・互換性の維持
・クラス名を変えない。
・挙動を変えない。
・Twitter側の挙動が変わった場合は判断が迷う、Twitter4jが吸収すべきかどうか。
・直列化形式（シリアライズ）の互換性の維持
・復元ができないケースがたまにある。対応する情報がなくなったとか
・フィールドは残してgetterなど省くなどで対応。
・難しい。が、気をつけるだけでテストはしてない。（ホントはしないといけないけど、コストがかかる）
・互換性情報は、ドキュメントで通知
・非互換はコンパイラに検出させる。どうしても保てない場合など。
・失敗例
・パッケージ構成
・やりすぎるとクラスが見つけられない。blogのコード例をコピペしても見つからない。
・（ただし、通常のプロダクトでは機能別にパッケージわけしたほうがいい）
・ソースディレクトリをわけるのがいいかもしれない。
・R2-5[BOF]Groovy2.Xの新機能
・スピーカー、プログラミングGroovyという書籍の中の人だった。
・Groovyは、動的が中心だったが、動的かつ、静的言語になってきてる
・Gradleは、Androidの公式ビルドシステム
・2.0から、@TypeChecked、@CompileStaticなどの静的チェックを行えるアノテーションが導入されている
・静的Groovyでどう変わる？
・引数は省略できなくなる、動的機能は対応不可。（そのかわり性能向上、IDE補完、型安全、ランタイムではなくコンパイル時に検知。Javaっぽい）
・静的Groovy、大規模なものをあとから書き直すというのはちょっとつらいように感じられる。
・indy対応(invokedynamic)、Groovyのindyはあまり性能がよくないようにみえるよう。
・Groovy2.0
・静的への回帰
・BettarJava
・今使えるJava8(Lambda,TypeAnnotation)
0 件のコメント:
コメントを投稿