議事録/第43回 - Java EE勉強会

JTwitter(しゃべる)
社内コード
ベンダー系
jQuery
Hadoop (MapReduce? + HDFS)
ZendFramework?
symfony
Akelos
Ruby(transcode.c), MacRuby?(string.c)
Kilim(アクターモデルっぽいの, ASMでCPSに変換)
Tomcatの "リムーブアダンタント"？
CruiseControl?
URI Template
Apache shinding(PHP)
Apache POI
Hibrenate(の使い方)
SICP(書籍,LISP)
S2JDBC
Eclipse3.4 プラグイン
cursys??
Haskell - Prelude(ライブラリ)
JBoss jBPM
S2Buri
Nautica(ワークフローエンジン)
Googleのcollection系
java.util.ArrayList?
Transate API(URLだけしかないらしい)
Spring MVC, Batch
RoR
JUnit(読みやすい)
CakePHP
Prototype.js
Clickフレームワーク？
tangonist？？
screenフレームワーク？
SAStruts
Spring内のAspectJ関連
jbehave？？
jdave？？
S2JUnit

【DDD読書会の進め方について】

[意見]

要約の資料を作ると、
- 負担が大きい
- みんな読まない
- →全員で少しずつ読む。
- wiki等に、翻訳を書き込む
- 参加表明 = サインアップ
- ☆Google group
- ☆pukiwiki
パート1は読む。パート2～4は序文を読んで、拾い読みは可能
- パート2までで、基本的なとこまではわかる
部分だけだと、全体像がとらえにくい
infomation retrievalは、id:naoyaさんが復習(まとめ)をしてる
読みたいのか、読んだこと前提で議論をしたいのか → 両方でしょう
2週間前にwikiに超訳、1週間前に議題をピックアップ
読むことを主体にする。まとめの会として、議論する
wikiに超訳＋感想＋突っ込みを分けて書く
1ヶ月で50ページくらいやると、1年で終わる
- 2ページずつで30人

[結論]

目次ベースで、1～5P
サインナップ方式
- 要約・つぶやき・突っ込み・まとめ(後ほど)
当日はwiki見ながら発表する
1週間前に〆切
- わからなければwarning

【Java de Haskell/GLAD!!さん】

Haskellっぽく組めるJavaライブラリ
Preludeを実装
Bool、Ordering、Char、()、関数 a->b、Eq、Ord、Showを実装済
Int、リスト、String、タプル、Enum、Num、Maybe、IO を作成中
関数合成: _dot_ メソッドを利用
部分適用: apply
遅延評価: 基本型もクラスでカプセル化する
Streamの遅延評価: IO.getContents
モナドって？？ → 次回へ続く

【Webアプリケーション論/ひがさん】どうすれば保守性があがるか、ディスカッション。

MVC
- コントローラにロジックを全て書くのが、シンプル
Magic Button / ボタンにロジック書く
古代 / php + JS + SQL + HTML
Smart UI / プレゼン層に色々入れる
- そんなに悪くない。1000行以下ならメンテナンスできる
2005年くらい → アクションに書きすぎない
- ビジネスロジックの分離。サービス(ファザード)クラス
DAO(テーブルと1-1) | サービス層(ユースケース) | クライアント
- Transaction script / ユースケースに応じたロジック
- 複数のユースケースに対し、同じロジックが分散
ドメインモデル
- 本当に重複を避けれるのか？細かくしても問題は同じ気がする
- 重複は要件定義レベルで出てくるのではないか
- 責務は特定のドメインに属するから、重複を防ぎやすい？
  - 複数のドメインにまたがると意味がない
処理を探す時、どのエンティティにあるかどのユースケースにあるかを探す難易度の違い
ドメインには、エンティティだけではなく業務プロセスも存在する
- 永続化されないものもあるでしょう
- DDD的には、制約、プロセス、仕様、もドメインに入る
こり過ぎると、現実に適用不能。単純過ぎると用が足りない
サービスパターン：エンティティと"サービス"(ドメイン中の振る舞いを扱うもの)
- 何をサービスとして抽出する？
  - ユースケースごとのロジックをサービスとできる
  - ユースケースはアプリケーションレイヤ？ドメイン内のサービス？
  - ユースケースの一文一文はサービス、その順番はアプリケーションロジック
サービスレイヤー / PoEAAとDDDで定義が違う
Daoを拡大して、ロジックを入れるといいのではないか
- エンティティごとにサービスを用意する
- 足りない部分に、サービスにサービスをDIする
なんでエンティティとサービスを分けるのか
- エンティティは単なる記録(ログ)。振る舞いは分ける
- ドメインモデルによっては、"アクティブなエンティティ"は自然にはまる
- デリバティブの世界と伝票の世界の違い
Employにsalaryを計算するロジックを積んではいけない
- そもそも、salaryを持ってるべきではない
- ドメイン逢いで、"給与支払いルール"が従業員にあるのは理解できない
おそらく、本を読んでも答えは出ていない。プロジェクトごとの正解を決める価値基準を持てるといい(ひがさん)
ドメイン≠エンティティ言葉の使い分け
ロジックとデータの改修頻度が同じであれば、分けなくても良い？
Rubyでは、モデル(DB)とアクション

次回は、2008年7月26日(土)。

ポジションペーパー: 私にとっての「大規模」の定義。

議事録 / 第43回

Menu

最新の20件

Menu

最新の20件