makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DDD本 読書会(羊) #8+α」に参加しました

2014/2/23(日) 「DDD本 読書会(羊) #8+α」に参加してきました。

告知サイト
http://connpass.com/event/5072/

以下の書籍をターゲットとした読書会なのです。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
(2011/04/09)
エリック・エヴァンス

商品詳細を見る


場所はいつもの矢向、横浜地区センターです。
参加者は11人です。初参加は1~2名かな。
今回はじゅんいち☆かとうさんによるDDDの解説があるということで、申し込み開始後、すぐ満席になりました~

事の発端は以下のツイート参照。


この後、二つ返事で引き受けてくださったじゅんいち☆かとうさん!
イヤッッホォォォオオォオウ!
主催の@naopiさんもグッジョブ!

この日は前日の京浜東北線の脱線事故の影響で、蒲田~川崎間がまさかの終日運休・・・
んでも私は京急線の最寄駅が徒歩8分くらいのトコにあるので、京急線を使って無事辿り着くことができました。


■じゅんいち☆かとうさんによるDDD解説
Scala with DDD from じゅんいち かとう


今日のスペシャルコンテンツ!
以下、個人メモをダラダラ書き起こしてみる。
---

■自己紹介
・DDDの出会いは4年前くらい。原著を辞書引きながら読んでいた。
・@t_wada さんに訳者の和智さんを紹介してもらい、DDD本の第二部のレビューを担当した。
・書籍の翻訳者謝辞に「じゅんいち☆かとう」の名前が出ている。
・50人規模のプロジェクトで、XPとDDDで1チーム4名、ペアプロでユビキタス言語を使いドメインモデルを作ってやっていた。
・み○ほ証券のホームトレードシステムの開発でDDDをやり始めた。
・ドワンゴに転職して、スマホ向けシステムでScalaとDDDを使い、基盤周りを開発した。


■DDDについて
・複雑な業務系のドメインはDDDと相性がいい。でもアジャイルじゃないとできない。
・ウォーターフォールは向いていない。
・DDDを始めるには前提となる知識が必要で、事前に読むべき書籍がたくさんある。
・ただ、DDDは設計論の頂点にあるからといって、下から階段を登って学んでいくと一生が終わってしまうw
・なので、今から初歩的な学習をやるのではなく、本質的な所から入って、必要なものを上から下がって知識をインストールしていく方が、今からDDDを実践するには向いている。
・難しいものと向き合うときに役に立つのがDDD本。
・DDDは設計の本なので、実装についてはあんまり書いてない。
・発刊して10年以上経っているが、陳腐化していない。未だに設計の議論は行われている。


■Webアプリの設計時に何を重視するか?(P.7/65)
・設計には色々なアプローチとコンテキストがある。
・開発してすぐ捨てるようなシステムには、DDDは向かない。
・何を重視するかを考えるとき、「テーブル重視型」と「UI重視型」の2種類がある。
・UI重視型が悪かというと、そうではない。
・プロトタイプを作ってみないと分からない、といった場合は、Smart UIアンチパターン(※1)が使われることが多い。
 (※1) 第4章のP.74 "利口なUI「アンチパターン」"を参照。
・でも、それを続けると死人が出る(笑 ので、使い続けるならDDDを前提にしたほうがいい。
・DDDはモデルを前提にしている。それは、複雑な問題をオブジェクト指向で解決したいから。
・DDDの基盤はオブジェクト指向。


■The Hexagonal Architecture (P.16/65)
・真ん中にはドメインモデルがあり、問題の領域の知識を定義している。
・例えばモンハンだとプレイヤーとかアイテムが該当する。
・ERPだと商品とか売上とかが該当する。
・問題の領域の言葉を定義して、実装しているのが真ん中の部分。
・左上に、他のシステムからの入力インタフェースがある。
・コアにはドメインモデルがあり、ここを解決しないとソフトウェアの価値はない。
・実装コード上にコアは見出しづらい。
・ドメインモデルは、現実のモデルとかサービスで使っている言葉と合わせましょう。


■モンハンの例(P.19/65)
・ドメインオブジェクトとして、MonsterとかHunterとかがある。
・それをちゃんとモデル化しましょう。振る舞いを持つオブジェクトとして定義しましょう。
・モデルはただのデータじゃない。役に立つシナリオというものがある。
・モデル自体の振る舞いがそこで行われる。
・例えば、プレイヤーがMonsterを倒してItemを拾うシーンを考える。
・その際、Webアプリケーションだと落し物テーブルを作りたがる。
・Hunterが落し物(LOST_MATTER)を拾ったから、関連が必要だよね、ということで、間を繋ぐテーブルを作りたがる。
・この設計はドメインの知識を表していない。この関連ってドメインにどう紐づくのかわからない。
・Hunterが落し物(LostMatter)を拾っているので、HUNTERとLOST_MATTERという関係でしかないはず。
・割とこれは、ゲームをする人のメンタルモデルと紐付ける考え方である。
・関連テーブルの考え方で話すと通じない。


■ドメインの語彙=ユビキタス言語(P.25/65)
・Hunterとかのユビキタス言語を決めたら、ドメインモデルを定義し、すべての人が意思疎通しやすくなるようにしましょう。
ユビキタス言語は「シナリオ」⇒「モデル」⇒「実装」のサイクル。
・このサイクルの話は書籍に書いていないが、著者のエリックさんがそう話している。
・まず、モデルをどういうふうに使うかの「シナリオ」がある。
・例えば、プレイヤーがパーティーを組んでモンスターと戦うようなシナリオとか。
・シナリオは、ユーザーストーリから引っぺがしてくる。
・最初は「ユーザーストーリー = シナリオ」として広げていく。
・次に、ホワイトボードの前に丸を書いて、線を引っ張って、1:1なのか1:nなのかを考えながら「モデル」を作る。
・どういう属性や振る舞いがあるのかはまだ考えず、まず枠だけ書いて、それで「実装」に落としちゃう。
・そこから属性や振る舞いをチームで議論して、また「実装」に落とす。
・大きいシステムだとUMLを書いたほうがいいかもしれないが、小さいシステムだと、ホワイトボードで書いて写真とって共有するくらいでもいい。
・アジャイルが向いているのは、そういう「シナリオ」⇒「モデル」⇒「実装」のサイクルがあるから。
・イテレーションの最初のフェーズでは、このサイクルを回す。
・それでユニットテストを書いていく。DBはモックとしている。
・リポジトリもモックとかオンメモリリポジトリを使っている。そうやってモデルが通用するのかを固めていく。
・そのあとに、ドメイン層にも手を入れていく。


■DDDによるレイヤー化(P.28/65)
・スプリントを何回か回して形ができてきたら、UI層とインフラストラクチャ層から挟み込む。
・StrutsやSpringといったフレームワークからは完全に切り離して考える。そうしないとF/Wと喧嘩しちゃう。
・ドメイン駆動は別のモジュールとして切り出しているので、Webでもバッチでも呼べるようにアプリとして依存しないように分離させて書く。
・新しいフレームワークが出てきてもドメイン層は中立している。
・ActiveRecordとドメイン層は分離していたほうが良いが、トレードオフがあるのでできない場合があるので、ケースバイケースで対応が必要。ただ、分けたほうが安全。
・JPAはJDBCに依存しているので、いきなりJPAを前提にしてエンティティにアノテーションを付けちゃうと、Memcacheを使う時にに問題になったりすることがある。
・DDDをサポートしている既存のフレームワークは無いので、分けて考えたほうが安全である。
・モデルはなるべくドメイン層だけにしたい。テーブルとドメインモデルは違う、ということを理解する必要がある。
・今までのMVCの考えだと、Mは「UI層、ドメイン層、インフラストラクチャ層」の3つに分かれる。
・今はは3つがごちゃ混ぜになっているが、DDDの視点でみると、3つのパートは分離すべき。
・上の層が下の層を知っている必要はあるが、逆はダメ。
・依存関係の話が第2部の最初に出てくるが、相互依存をシビアに管理しないといけないので、依存は一方向とすべき。


■モデルと実装(P.29/65)
・書籍の5章に登場するエンティティ、値オブジェクト、サービスなどは全部理解している必要がある。
・エンティティは特殊なオブジェクトで、ideniityを持ってないとけない。
・オブジェクトを比較した時に、idenitityの値が同じかどうかで同一性を判定しないといけない。
・例えば人の名前は変わるけど、identityは変更してはいけない。
・なのでidentityはfinalで不変にし、一生変えちゃいけない。再利用も基本的には許さない。永久欠番とかにする。
・equalsメソッドは、デフォルトだとハッシュコードの値で比較しちゃうが、DDDではidentityで比較するようにしなくちゃいけない。
・Userクラスのインスタンスであるyamashiroとkatoさんがいて、インスタンスが持つ3つの属性の値が一緒だったらイコールと判定するのは、エンティティじゃないモノの考え方である。
・P.34のコードは、リストの各要素がアンダースコアに順次入って、existsで存在を評価するコード。
・ここで後ろの名前をYamashiroからHogeshiroに変更してしまうと、今度はexistsで不一致と判定して、戻り値がfalseになる。この操作は危険。
・ちゃんとしたエンティティの実装は、identityで同一性を判定し、他の属性はぜんぶ無視する。
・エンティティには属性がないと表現は乏しいが、idだけを保持してidentityを証明したい、という考え方が大事。
・Userクラスの属性であるfirstNameとlastNameも、文字列ではなくオブジェクトにしてしまった方が本当は良い。
・Userのidは変えられないようにしないといけない。
・人の名前は流転していくもの。年齢とか住所とか、その時々で変わるものをあてにしてはいけない。
・HunterIDをInt型にすると、他の整数を代入されることがあるので、Int型ではなくクラスにした方が良い


■値オブジェクト(P.39/65)
・識別はしない。
・書籍ではクレヨンの例がでてきた。
・モンハンではアイテムとかが値オブジェクトになりやすい。
・DDDだと、値そのものも振る舞いを持つ、という考え方がある。
・値オブジェクトに振る舞いがあるなら、持たせた方がいい。
・例えば回復アイテムは、指定したハンターを回復させる、といった振る舞いを持たせる。
・アイテムはハンターに使われるので、メソッド名は受動態にしている。


■ドメインモデルはユビキタス言語と対応づくこと(P.42/65)
・設計に躓くと、「ここにフラグが必要だよね」といった設計になるが、そうじゃない。
・ドメインモデルはユビキタス言語と対応づけること。
・「なんとかフラグ」という言葉が出てくるのが一番ヤバい。
・本当に「フラグ」のような概念があるんですか?と問わねばならない。
・ユビキタス言語が変わると、凄いリファクタリングが発生する。概念が変わると実装が変わる。
・なのでリリース直後とかには実施できないので、バックログに積むなり工夫する必要がある。


■ライフサイクルの管理(P.44/65)
・よく誤解するが、ライフサイクル管理はドメインの知識と関係していない。
・集約はよく理解しておかないといけない。
・リポジトリはドメインの知識ではなく、I/Oだけを担当する。


■よくある勘違い(P.47/65)
・User#saveというコードは、Userというエンティティにsaveというユビキタス言語があるんですか?と問わねばならない。
・無いはず。それはリポジトリの責務のはず。
・ActiveRecordはドメインモデルとせず、インフラストラクチャ層にすべき。


■Repository ≠ DAO (P.48/65)
・リポジトリはDAOじゃない。もう一段高い抽象化されたもの。DAOはリポジトリの内部で使われる実装のこと。
・グローバルな識別子を持っているのが集約のルートになる。
・集約の単位がDBだとトランザクション境界になる。一般に、トランザクションの境界は集約。
・DDDをやるとなると、既存のフレームワークの便利なものをリポジトリの中で使わないといけない大変さがある。
・自分たちでリポジトリのフレームワークは作った方がいい。


■DDDではフルスタックF/Wは使いにくい(P.62/65)
・RailsでDDDをやろうとすると、レールから外れないとできないことがある。そのため難しい。。。
・手間をなるべくかけないなら、DDDのフレームワークを自分たちで作った方がいい。
・一番面倒なのはリポジトリ。


■Q&A
Q1.
・DDDで使いやすいF/Wはあるか?

A1.
・無いと思っている。
・フルスタックF/WがDDDを前提にしていないと難しい。F/Wはそれぞれの世界観を持っているので。
・極論すればフルスタックF/Wはいらない。ドメインやORMは切り離さないといけない。


Q2.
・DDDはORMとの相性が悪いとのことだが、JPAはDDDと相性が良さそうに感じる。実際どうなのか?

A2.
・エンティティは基本的に永続化層と紐付かない。
・永続化の手段に応じて別々の手段を定義してはいけない。
・DDDでは、JPAはDBならいいかもしれないが、オンメモリとかでは制約になるかもしれない。
・JPAはカラム情報が属性に全部存在しないといけない。
・でもDDDだと、Hunterクラスの属性であるfirstNameとlastNameは、Nameクラスとして別のオブジェクトにしたりする。
・その場合はHunterクラスの構造が階層化されるので、単純にマッピングできない。
・JPAを使うと決めたら、属性を羅列する必要があり、構造が1次元になるのでプログラマの理解度が落ちる。
・概念的な集合にしたほうがフィールドの数を減らせるが、DDDでは表現できなかったりする。
・なのでDDDでモデリングして、JPAを吸収する仕組みをインフラストラクチャ層に作ったりしないといけない。


Q3.
Webアプリとかのトランザクション制御はどう考えればいいか?

A3.
・トランザクション境界は集約ルートになる。集約単位でI/Oしなさい。
・画面の1ボタンクリックを1トランザクションにしたい場合は、トランザクションを入れ子にして、論理的なトランザクションを貼らないといけないかもしれない。
・アプリケーション側でトランザクションを定義しないと現実的ではない。
・トランザクション制御のイメージはP.70の図4.1が参考になる。
・アプリケーション層がbeginTransaction()を呼び出し、インフラストラクチャ層の作業ユニットマネージャに委譲する。


Q4.
・飛行機と宿を両方予約するようなシステムを設計する必要がある場合は、トランザクションをどう設計すればいいか?

A4.
・飛行機と宿を両方とも、1つの集約モデルに含める。
・どちらかが失敗したら片方もロールバックされるようにできるし、設計の意図も伝わりやすくなる。


■7章「言語を使用する:応用例」

じゅんいち☆かとうさんの講演が終わったら、いつもどおり書籍に沿って黙読&ディスカッションタイムです。
この日は7章「言語を使用する:応用例」が範囲でした。

以下、ちょびっとメモ。

■エンティティとテーブル
・「荷役イベント」はエンティティの一種で、ドメインイベントと言う。
・「配送記録」はテーブルにならない。
・「荷役イベント」は貨物ID、完了時刻、タイプの3つのキーの組み合わせを主キーとするか、サロゲートキーを用意するかの2パターンある。主キーとは別に、ientityは存在させる。

■腐敗防止層
・P.184の「配分チェックサービス」はの腐敗防止層としての役割を果たす。
・販売管理システムは予約アプリケーションとは別のドメインにある。
・レガシーシステムのドメインは、予約アプリケーションのドメインに影響を与えたくない。
・販売管理システムがレガシーシステムだったとしても、腐敗防止層として配分チェックサービスを置くことで分離できる。
・ただし腐敗防止層は使い過ぎないようにすべき。
・腐敗防止層を一度でも作っちゃうと、リファクタリングするタイミングを設けないといけない。
・変換コンバータを作って、DDDの層とレガシーの層を分ける。ただし変換ロジックを実装するのはすごく大変。。。

■リポジトリ
・リポジトリを使うのはアプリケーション層である。
・ドメインモデルが永続化とかライフサイクル管理を担っちゃいけない。リポジトリはアプリケーション層が使う。
・なんか値を取ってきたいからとりあえずリポジトリ使えばいいじゃん、とい考えはダメ。

---
あと、説明の過程で「Scala Pet Store API」なるものの紹介もありました。



読書会の終了後は、じゅんいち☆かとうさん+8名でいつもの中華屋さんにご飯を食べに行きました。
DDDの話も熱かったが、糖質制限ダイエットのトークも同じくらい熱かった!w


★感想:
じゅんいち☆かとうさんに感謝!
実務でDDDを使ってるエンジニアのお話をじかに聴けて、とても勉強になりました。
本を読んでるだけだと、ふーん、へー、とかでなんとなく素通りしてしまうんですが、経験に基づく説明を聞いてると、あーそういうことだったのか!となる事しきり。
これは本だけでは得られない部分ですね。

こーゆうイベント、今後の読書会でもやれるといいですね~

じゅんいち☆かとうさん、主催の @naopi さん、参加者のみなさんありがとうございました~
スポンサーサイト

「Developers Summit 2014 (Day2)」に参加しました -其の壱-

2014/2/14(金) 「Developers Summit 2014 (Day2)」に参加してきました。

公式サイト
http://event.shoeisha.jp/devsumi/20140213


去年も参加しましたが、今年もなんとか2日目だけ、丸1日参加できた~
こーゆうイベントに参加すると、「俺も頑張らなきゃっ!」ってスゲー刺激になります。コレ大事!
ちなみに弊社もスポンサーに名前が挙がっていました。ぜひ、今後も続けてほしいです。

雪が舞う中、朝9時40分くらいに到着。この日は大雪だったのです・・・
そのためか、スタッフさんが道中、Amazon経由のエスカレーターコースへ誘導してくれていました。
おかげさまで雪が積もる中、あの坂道を避けることができたのは、マジ感謝!

デブサミ会場の目黒雅叙園は相変わらず豪華です。
さっそく、受付付近には書籍ブースが。
20140214_devsumi2.jpg

他にも、今年もいろんなブースがありましたねー
こーゆう活気あるイベントはワクワクします。
休憩時間の通路も、こんなカンジ!
20140214_devsumi1.jpg
ハハハ!見ろぉ~、人がゴミのよう(ry

というわけで、makopi23が参加したセッションをいくつか、メモと共にご紹介。
とりあえず、今日は一番最初に聴講した角さんのセッションのメモを書く。



■【14-D-1】Team GeekによるFearless Chang
20140214 teamgeek-fearlesschange from Masanori Kado



以前、すくすくスクラムで角さんの「Team Geek」のお話を聞きました。そんときのブログはこちら。


この時はすごい勉強になった。HRTの印象が強烈すぎてワロタw

■そんなのやらなくていいと思うよ(P.5)
・「組織改革」なんて、現場のエンジニアはやらなくていいよ。
・プログラマは、コードによって価値を生み出すべき。社内政治に力を向けるべきではない。
・でも誰かがやらなきゃいけない


■機械論的自然観(P.13)
・チームリーダーとかが組織改革をやろうとするが、頑張っても報われないことが多い。
・なぜうまく行かないんだろう?それは「機械論的自然観」があるから。
・相手を機械みたいに考えちゃう。
・良いアイデア「なのに」無視される、といった表現の「なのに」という語彙などが該当する。


■有機体論的自然観(P.17)
・簡単に言うと、出来事の連続で考えるべきだ、という発想の転換。
・スティーブ・ジョブズも「点と点をつなげること」の重要性を説いている。
・過去にこーゆうイベントがあって、その連続で今があるんだ、と考えないといけない。


■ここまでのまとめ(P.27)
・機械論的ではうまくいかない
・出来事の連続で考える
・それは点と点をつなげること
・それがパターンでありパターンランゲージである


■パターンの構造(P.23)
・結城浩さんの定義が一番しっくりくる。
・"ある「文脈」で繰り返し起きる「問題」を「解決」する方法。
 その方法にはいくつかの「制約」が課せられているかもしれない。"
・制約を避けつつ、なんらかの解決策を探していくこと。それに名前を付けて使いやすくしたのがパターン。


■Fealess Change - アイデアを広めるパターン -(P.32)
・各パターン名の数字は導入順を表していて、日本語版の書籍にしか付いていない。
・訳者の川口さんのアイデアで、素晴らしい。
・あるイベントが終わったら、次のイベントに繋がっていく。


■そんな場当たり的な対応でいいの?(P.55)
・出来事の連続が大切
・変化は少しづつ起こるので定量化は難しい
・人間の反応は予測できない。なので計画できない。
・一度に1つのパターンに全力投球することで全体の品質が上がっていく。
・だけど難しいので、「スターターパック」を用意している。(P.56)


■パターン(9)「なにか食べながら」(P.58)
・食べ物重要!何かを食べることで人は反応が変わる。人は機械じゃない。
・リンダ・ライジングも推奨している。
・チョコチップクッキーをあげるチームとあげないチームがあって、あげたチームの方がアイデアが賛同された。
・つまり、成功を決めるのはアイデアの良し悪しではない。


■フード三原則(P.61)
・ご飯の出るシーンは重要。
 1.善人は食べ物をおいしそうに食べる
 2.正体不明者は食べ物を食べない
 3.悪者は食べ物を粗末に扱う
・組織でなにかをやりたい、チーム作りをしたい、という時は食べ物重要。
・おいしそうにご飯を食べて善人づらしましょうw


■良いアイデアなのに無視される!(P.65)
・誰でも考える時間が必要。関数のようにすぐ返ってこない。
・キャズムを超えないとアイデアは広まらない。
・いきなりレイトマジョリティ以降の人に伝えてもうまくいかない。
・著名人を招き(パターン27)、と経営者を合わせてアイデアを広めていく=謁見(パターン38)
・強く言えるほどの権限がないなら、すぐ「協力を求める(パターン6)」べき。


■協力してくれる人たち(P.71)
・達人、経営者、支援者、メンター、同志、どれを使ってもいいので、状況に適した人に協力を求めましょう。
・そうすると、グループができて、結束力を高めなければいけなくなる。
・「定期的な連絡(パターン24)」も大事。
・経営者も「いいね!」と言ってくれるけど、すぐ忘れちゃうので、情熱を消さないようにきちんと連絡し続けること。


■面倒くさい人が多すぎて萎える(P.76)
・ほんとうに「面倒くさい」の?
・それらの人を尊重して、ヒヤリングして、活用できるなら活用すべき。
・「恐れは無用(パターン46)」
 ⇒ これを本のタイトルにしているってことは「そんなに恐れることはないんだよ」ってことを著者は伝えたかったはず。

■試しに作ってみた(P.84)
・自分が使えるものを選んでイベントにして連続にしてプロセスにしましょう。この本を辞書的に使いましょう。
・足りないパターンは、自分でパターンを作ろう。例:「○○は佐藤さんに聞け」パターンとかw
・試しに作ってみたw

(1) 「愛されキャラ」パターン
 ・失敗しても許される人と許されない人がいる。この違いはなにか。それは愛されキャラ。
 ・愛されキャラを目指していくことで、組織改革は思っているほど上手く行く。
 ・これからはいいキャラになるべき。

(2) 「でもやるんだよ」パターン
 ・情熱は擦り減っていく。最後は、なんでやっててるかわからなくなる。
 ・でもやるんです!そこに理由はない。
 ・最初の情熱とか実感は本物なので、後になって論理的にその気持ちを考えるのは意味がない。
 ・なので、一度情熱を持ったからには、それで頑張っていく。

(3) 「現実歪曲空間を演出する」パターン
 ・スティーブ・ジョブズのように、プレゼンする時にいつもとは違うような非現実的空間を演出することによって、いつもとちがうぞ、と思われること。


■ここまでのまとめ(P.87)
・パターンの構造は「文脈」、「問題」、「制約」、「解決」の4つ。
・パターンの連続がパターンランゲージ。点と点を繋ぐこと。
・自分のパターンを作りましょう


■「パターン」と「フレームワーク」(P.93)
・でも、パターンだけでは不安。「パターン」と「フレームワーク」の両輪があるんじゃないかな、と最近思っている。
・例えば「XP」と「スクラム」。XPはパターン、スクラムはフレームワーク。
・XPだけの時代はうまくいかなくて、微妙な扱いをうけていたが、スクラムが出てきてアジャイルが広まった。
・XPはパターンにすぎないのでイベントにすぎない。スクラムが必要だった。
・他にも「プラクティスと原則」、「レシピとマニュアル」のように、パターンとフレームワークがセットになって、始めてうまくいく。
・パターンが「Fealess Change」なら、フレームワークとしてて「Team Geek」!


■三本柱(P.108)
(1) 謙虚(Humility) ・・・ 自分が間違ってるかおしれないと考えよう
(2) 尊敬(Respect) ・・・ 一緒に働く人のことを大切に扱おう
(3) 信頼(Trust) ・・・ 自分以外に仕事を任せよう

・これが「たいしたことない」と思った人は、機械論的自然観に侵されている。
・これはハッカーが言っているんだ。アイデアの整理ではない。実際にやっている人が言っている点に意義がある。


■1.信頼(P.111)
・弱点のある人は信頼できる。
・弱点がないのは危険。「あいつに全部まかせちゃえばいい」となってしまう。
・自ら弱点を公開するのが重要。
・自分が失敗したときには「~が悪かった」というが、他の人が失敗するとその人の「人間の内面」に原因を求めがち。
・「根本の帰属の誤り」を前提にすべき。
・見せた弱点を克服する必要はない。
・なぜか怪我の話は盛り上がる。チームを作るときに最初にすることは、「弱点を公開する」こと。


■2.尊敬(P.120)
・チーム文化を育てるときは価値観を共有する。
・技術的なスキルよりも文化の適合
 - 技術的スキルは学習できる。
 - 文化が合ってないと生産性がマイナスになる。
・事例として「リコーUCS」がある。
・そこではプロジェクト原則を作った。価値観をづらづらと載せている。
・これをチームメンバーに配布して、こーゆう価値観で今から仕事をしていくんだよ、とやったら上手く言った。
・この原則にはスキルとかは載せてない。原則と文化を載せてうまくいった良い事例。


■3.謙虚(P.130)
・目指すべきは「サーヴァントリーダーシップ」
・謙虚と犠牲の境界線は曖昧だ。自分の意見は意見として主張すべきだ。
・衝突はあってしかるべき。衝突がないチームは不気味。
・「悪魔の代弁者」となって衝突を作り出すべき。
・衝突後に後腐れがないように、HRTはT,R,Hの順で導入すべき。


■有害な人に対処する(P.139)
・これは本にはない。
・何をやってもダメなら追放する!
・HRTを使って丁寧に追放する。


■まとめ(P.147)
・パターンで考えてみる
・パターンを連続させてみる
・食べ物は超大切!(フード理論)
・ハッカー文化を参考にする
・本当にダメなやつはダメ


★感想:
角さんのセッションはいつも面白いと同時にスゲー勉強になる。
Fealess Changeは横浜道場の方とか同じ会社だった方とかが執筆してることもあって、大変興味があります。
ただ積読が多いので購入を見合わせているんですが、読んでみたいなぁ。
あと、「組織パターン」という本も少し前に出ているが、パターンって流行りなのかな?違いとかも気になりますね。

あと「フード理論」!これは前のすくすくスクラムで聞いた時もそうでしたが、強烈ですね。
すごく納得できる理論です。
こんなん聞いたら、毎日おいしいご飯をおなかいっぱい食べちゃうしかない!

DDDでもパターンが出てきますし、先日のリーンカンファレンスでも「型」が大きなテーマにもなってたし、これからは「パターン」とか「型」にも注意を向けて勉強してみようと思うmakopi23なのでした。

他のセッションのメモも、復習のために後日書こうと思います。

SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました

2014/2/6(木) SQLアンチパターン読書会 「アンビギュアスグループ」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/8807

以下の書籍をターゲットとした読書会なのです。
SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は10人かな。
今回は14章「アンビギュアスグループ(曖昧なグループ)」が対象範囲でした。


■14章「アンビギュアスグループ」の説明

今回は @grimrose さんがスライドを作成して紹介してくださいました。



14.5.6節の値連結について、書籍には無いPostgreSQLのARRAY_AGG関数が紹介されています。
あと、GroovyとGradleとPostgreSQL9.xを使ったデモもありました。


こーゆう試みは素晴らしいですね~



■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140206_sqlap1.jpg

あと、私が14章を写経した時に使ったInsert文を一応貼っておきます~。写経したい方はどうぞ。
sqlap_Chapter14_InsertData.txt


DDLとDMLはO'Reillyの書籍サイトに公開されているサンプルコードを使ってくださいな。
http://www.oreilly.co.jp/books/9784873115894/#files

以下、ディスカッション時の個人メモ。
---

■SQL補完をサポートするIDE
・IntelliJ IDEAとかPhpStormは、プログラムの中でもSQLを書くと補完してくれる。型まで付いてくる。
・構文解析しやすい言語はIntelliJ IDEAとかPhpStormとかはお奨め。


■相関サブクエリと導出テーブル
・一般的に、導出テーブルの方が相関サブクエリより実行速度が速い。
・導出テーブルはクエリ実行が1回で済むが、仮想テーブルを作成するためメモリ消費量が大きくなる。


■14.5.4節 JOINを使用する
・サブクエリの中にエイリアス b2 を定義しているが、b2はサブクエリ外でも使用できる。
 → サブクエリの括弧の中にスコープがあるように誤解しやすい。
・このSQLは、集合をズラしてnullを狙い撃ちするイメージ。
・JOINをモリモリ使うとスパゲッティクエリ(17章)に繋がる恐れがあるので注意が必要。


■14.5.6節 グループごとにすべての値を連結する
・PostgreSQLは8.4から、値連結の集約関数としてARRAY_AGGが使用できる。
 http://www.postgresql.jp/document/8.4/html/functions-aggregate.html#FUNCTIONS-AGGREGATE-TABLE
・カンマによる値の連結は、カラムのデータ自体にカンマが入っていると使えない。1章のジェイウォークになる。
・GRUOP_CONCAT関数もARRAY_AGG関数もSQL標準でサポートされていない。
・MySQLでGRUOP_CONCAT関数を使って連結した際に、途中の1024文字目で打ち切られたことがあったので注意が必要。
・値連結は、テーブルの縦方向の関係を横方向に繋げ直すイメージ。


■解決策の選択指針
・基本アプローチは、まず14.5.3節の「導出テーブル」で出来ないかを考える。
・導出テーブルでパフォーマンスや容量で問題になったら、14.5.4節の「JOINを使用する」で頑張る。
・14.5.4節のLEFT OUTER JOINは慣れると応用テクニックになる。
 → ただし、集合をズラしてデータを取るのはSQLならではで、覚えると強くなるが、人に説明するのが大変・・・
・なので、コストパフォーマンスは14.5.4節の「JOINを使用する」よりは14.5.3節の「導出テーブル」の方が勝る。


■SQLの複雑度
・副問い合わせ(サブクエリ)はWITH句で代替できることがあり、複雑なSQLを分かりやすく見せられる。
・SQLの複雑度、性能、集合論は分けて考える。
・長いSQLは途中の過程をトレースできない。
 → 複雑なSQLを複数に分割すると、個別のSQL結果をトレースできるようになる。
・長いSQLにはコメントを付けましょう。


■AS句によるエイリアス
・カラムへのエイリアスにはASを付け、テーブルのエイリアスにはASを付けない、という派が多い。
・カラムへはASを付けないとエラーになる。
・テーブルへはASを付けても付けなくても良い。
・テーブルへはASを付けないことが多いが、カラムとテーブルの両方にASを付ける派もある。


■Window関数
・結果セットを部分的に切り出した領域に集約関数を適用できる、拡張されたSELECTステートメントのことらしい。
・特定の切り口ごとに集計ができる。
・Windows関数はSQL標準のものと、SQL標準ではないものがある。
・Oracle Database 12cからLimitとOffsetが標準サポートとなった。


■おすすめ書籍
・関係代数や集合演算に関する勉強には以下の書籍がお奨め! by @t_wada さん
達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
(2008/02/07)
ミック

商品詳細を見る



★感想:
14.5節の解決策ですが、副問い合わせが登場して急にSQLが長く複雑になって、ちょっと面喰いますよね・・・
この日の話にも出ましたが、SQLを長くするとスパゲッティクエリに繋がる恐れもあるので、バランスが重要!
SQLの処理をアプリ側に逃がすと、DBインデックスの恩恵を受けられなくこともあるので、その辺は難しいところです。
このくらいのSQLがスラスラ書けて理解できるようになりたいなぁ~

あと、誤植を1つ発見して @t_wada さんにご報告!
これからも見つけられるよう頑張る・・・w

参加者の皆様、ありがとうございました~



■おまけ:過去の「SQLアンチパターン読書会」ブログ

1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-65.html

2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-70.html

3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-73.html

3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-77.html

4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-84.html

5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-90.html

6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-94.html

7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-97.html

8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-105.html

9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-109.html

10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-115.html

11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-118.html

12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-121.html

13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-128.html

FC2Ad