議事録 / 第45回

議事録

第45回 Java EE勉強会 †

• 日時: 2008年8月23日(土) 13:00〜18:00

ポジペ: 「私と英語」 †

• プレゼンを英語でチャレンジ
• Writingはアルク頼り
• 仕事でたまに使う(出張年一回)
• インドの人の発音は難しい
• iPhoneで英語をESL, Lern Business English, Java Posse
• ドキュメント等で忘れないようにしている
• 中学までは得意、高校から苦手
• 職場の英会話教室、原著を読む会
• 英語の勉強はしている
• PodCast?はビデオで、ABCニュース
• iKnowを毎朝
• 辞書を片手にドキュメント
• 特に何も勉強してない
• 私に英語は聞かないで
• だんだん下降中
• チャットで英語
• 悪口から学ぶ
• ECC英会話
• 嫌い
• TOEICでいい点を獲る方法→リスニングで「かさかさ」と音がなった時が答え
• 大学で輪読で論文読み
• 幼稚園がカトリック系で、英語教育
• Object Designを音読
• 漫画の英訳版の立ち読み
• Evansが日本語勉強すべき
• 受験の時は得意だった→語彙は多い
• 大学で英語を諦めた
• PofEAA輪読
• 中学で挫折
• インタネットで、英語の重要性
• 残りの人生を英語力向上で無駄にしたくない

DDD読書会 (Chapter Two.) †

• モデルが「頭の中に」は、現実のプロジェクトでは難しいのではないか
• モデルは頭の中、ドキュメントによってモデルの意味を表現、ドキュメントがコードを説明
• whyに関してはドキュメント→本当にwhyだけでいいのかは疑問
• ドメインモデルをあまり扱ってない。コードがモデルを反映してない
• agileの人達なので、「ドキュメントは少なくていい」ではなく、「ドキュメントは不要→必要」と読み取るべき。
• SIerのドキュメントは、情報を伝達するもの
• ドキュメントで詳細まで起こしたとしても、結局コードを見る。
• アセンブラでPCが一人一台なかった時代では、ドキュメントは役に立った
  • 現状では、IDEが発達してコードの方が価値がある
• 言語がわからないと、ドキュメントでロジックがわかる
  • クロージャとかポリモフィズムとか仕様に起こせないでしょう
  • こういうドキュメントを作る人は、20年前の機能でロジックを書いてる→継承禁止とかインスタンスメソッド禁止とかありえない
  • 変数名も長く使えるようになった。言語の生産性を生かせない
• クラス間の関係が大事
• ロジックが書いてあるドキュメントにバグがある → 仕様変更要求
  • 実現できることをドキュメント上で確かめたい → コードでやればいい → そこまでやれば、実装した方が速い
• オフショアでは細かい指定が必要？
  • 外国の人は仕様に書かれない部分を実装しないかもしれない
  • それでは工数を下げれない
  • ナレッジクランチングにプログラマが入るのは重用
• オフショアは、いかにコミュニケーションを疎にするかという考え
  • この本は、いかにコミュニケーションを密にするか
  • 最近では、オフショアも密にしている
• 上流-下流で担当が違えば、仕様書が契約書になってる
  • 仕様にあれば実装だし、なければ別料金
  • 一緒のチームとして作るべきだが、壁は厚い
• RFP(Request For Proposal)をしっかりしないと、裁判沙汰になる
  • XPは、ベストエフォートな契約になる → 人月は保証、結果は未保証
  • RFPでプラスマイナスな契約はできないのか
  • 最初は人月で、後半請負的な契約が多い
• ベストエフォート的な契約は、お客さんにもメリットがある
  • お客さんはやりたいことが決まってない。人月の範囲で要件変更ができる。
  • お客さんの事業計画とあわない → 予算がうまくとれない
• プロトタイピングの作成時に、ドメインモデルを作る？？
  • フェーズが別れてる時点でだめ
    • 上流でドメインモデルは完成 → 洗練できない
• EvansやFowlerは、マジョリティなのか？？
  • アメリカでは国防総省が大きい仕事
  • 客を巻き込むってよりは、お客さんのところに入って行ってる
  • Agileはスーパー派遣。乗り込んで作ってくる。
    • 日本でも常駐だと一緒では？？
    • 主導権を、乗り込む側がとる
  • アメリカは日本のようなSIerは少ない
• ドメインエキスパートとデベロッパ
  • インタラクションデザイン → 振る舞いのような部分は、おざなりにされる
    • 「インタラクションデザイナー」って呼ばれる人は居ない
  • ドメインエキスパートに関しても、専任者がいない → 3章で
  • プロトタイピングにかかる時間が7割 → なにか作るとこに時間がかかる
    • 試行錯誤に時間がかかることを受け入れる
• お客さんには、「いくらで何ができる」と言った方がいい
• XPに必要なのは勇気
  • 失敗しても、同じことをしたい
  • 前と違うことをして失敗するのは嫌。前と同じことをして同じ失敗をするのはOK。
• 「声に出す」ってことは、コミュニケーションしましょう
  • モデルを洗練させて行くのは、難しい → ルーチンワークで洗練させるのは難しい
  • 「XXXとYYYとZZZを決める」から、用語を作り出す
  • 会話する時に、同じことが頭にあるようにするのは難しい
• 結局ドキュメントは書くの？？
  • この本では、書くべきドキュメントは出て来ない
  • ソースの補足、小さく維持。
  • 新しく入った人は、ドキュメントを手がかりにコードを読んで頭にドメインモデルを作る
• コードに、すべてドメインモデルはあるのか？？
  • あるはず
  • システム化しない部分は？？
  • スコープの問題
  • システム化されない部分も、議論には入ってくるのでは？ ドメインモデルとは呼ばない？
  • ドメインモデルの対象と、システム化の範囲は違う？
  • システム化しないモデルもあるだろう
• 納品物と言う観点では、ドキュメントは必要ではないか
  • 厚さが、やってると言う主張になる
  • 金額とドキュメントの量は比例する
  • 監督庁の監査が入ると、ドキュメントが少ないのはまずい可能性がある
  • XPの人達とSIerの差は、契約に関して大きく違う部分もある
  • まずは理想を求めるしかないのでは・・・
  • agile modeling (書籍)
  • ベンダーのドキュメントの標準化は？ → お客様から、身を守るためのもの。agile的な助けにはならない。
  • 別業界だと思った方がいい
• P42の図が理解できない
  • 部分的な図なので、これだけでは理解できないのでは
• モデルは一つ？
  • モデルは一つで、ビューは複数あってもいい
  • 4+1ビューと同じ
  • 「モデル」に、共有する一つのモデルと別のビューと言う意味合いがありそう
    • 言葉の使いかけはあいまい？

スイーツタイム †

ポジペ: 「私と英語」(その2) †

• 外資系だけどイマイチ
• iKnow
• 海外旅行未経験、行きたい
• 輸入ゲームで覚えた
• ネットゲームで海外の人と
• フランスの人には foo,bar,buzz など、通じない
• 高校で漫画の英語→読まず
• 洋書はマイケルジャクソンの本が最初
• 技術書の洋書はよく買う → 訳本の方が安いのが残念
• 文学に挑戦中

Appendixのパターンの見方の部分 †

• パターン本なのに、普通の文章として読んでしまう可能性がある
• 次回以降は、パターンの部分がパターンとわかるようにした方がいい

DDD読書会 (Chapter Three.) †

• 分析モデルは捨てられるし、対応が複雑だとメンテしきれない
  • UBIQUITOUS LANGUAGEによってモデルと実装を結びつける
• モデルを実装するために、オブジェクト指向がよい(オブジェクト指向をどうモデリングに生かすかではない)
  • 手続き型で実装可能？
    • 複雑では？
    • 仕様書が手続き型になっている
    • すでに手順が決まっているような仕事をシステム化すると、手続き型になる
• モデルと実装の結びつけが正しいのかはどう判断？
  • 会話に出てくる言葉がクラス名になっているか
  • 二人の頭の中のモデルがどうやって同じかはどう確認するの？
  • ホワイトボードで会話すればわかる → 会話しない部分はわからない
  • プロトタイプを作って見せあう → ペアプロだと、共有
  • ズレがある場合は、ドキュメントが必要。
  • 前回の話より、ドメイン専門家と技術者で矛盾があることもある
  • モデルとコードの紐付けが崩れないためのパターン集が欲しい
  • モデルと実装が完全に一致するタイミングはないのかもしれない → 進化的
  • コードを直した場合 → コード直していない人のモデルの認識と、ズレる
• DDDの人はアクセサにgetをつけないのか？
  • モデル的にはgetはノイズ。(機械的には必要)
    • C#のパーシャルクラスでシステム上のメソッドをモデル上のメソッドを分離とか
  • Rubyでは、アクセサもメソッドも同じに見えるようにしている
  • getとsetはJavaBeans?だけの概念。
  • フィールドについて、実装上は命名にgetとかsetをつける可能性はある
  • パーシャルクラスで分けるよりも、アノテーションで指定の方がいい？(分け過ぎるのもよくない)
  • Smalltalk のカテゴリ (プロトコル) など
    • StCategory for Eclipse
  • 喋りたい時に、必要な要素が見えるといい。IDEにやらせるなら、もっと頑張って欲しい
  • ドメインと他のレイヤを分離し、ドメインレイヤは極力シンプルにする
  • 永続層では、lazy loading などで、モデル上と現実とのギャップと戦う
• オブジェクトDBとDDDの相性はよい？？
  • なんの関係もなさそう
  • なくなってもいいと思う
• モデラーとプログラマーがペアプロやっとけばいい
  • モデルを理解しないプログラマが問題ではないか(ただし、モデル=ドキュメントだと思っていた)
  • パターン名(HANDS-ON MODELERS)的には、モデラー側に歩み寄りを求めている
• モデラーって誰？？ モデルは頭の中・・・
  • 専任の人は居ない。居場所がない。リストラ。
  • アーキテクト？？
  • ジェネラリスト
• 技術が複雑になって来て、DB、アーキテクト、コーディング、に特化したスペシャリストが必要？
  • XP的には、専門家？ 均一化？
  • ペアプロの結果としては均質化される。リスクマネージメントにもなる。
• ビジネスな側面とテクニカルな側面があるが、ビジネスな側面を見ているのでは
  • ビジネスの複雑さへ対処するパターン
• DDDとしては、ジェネラリストではなくDDDのエキスパートになる
  • ものは言い様(笑
• アジャイル的には、システム全体で技術を回す
  • 幅広い知識が必要ではないか
  • 知識量が増えたら間に合わないのでは？ となるとスペシャリスト？？
  • 原子力発電はアジャイルではやらない
  • 非機能要件に関しては、スペシャリストに。
• 小さい仕事もSIer的にするのはおかしい。DDD的にできる。
  • 小さいプロジェクトの方が色々できる
  • SOAとかは大きいプロジェクトしかありえない
  • 大きいプロジェクトではそのような単語はbuzz word
  • 小さ過ぎたら、DDDじゃなくてphpで十分

次回 †

• 2008年9月27日(土)
• ポジペ「ドキュメントの書き方」
• 次回も、「先に読んで、後から議論」を維持
• 要約の分量の目安
  • 1段落1行
  • 太字は細かく
  • Exampleは大分省略
  • パターンはきちんと整形する (参考)