2013/5/28(火) 横浜道場 特別編 「システム設計の謎(ひみつ) ～ べ、別にあんたのために設計してるんじゃないんだからね/// ～」 に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/3959以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者は30名、定員MAXだったようで、かなりの盛況！
今回は特別編ということで、スタッフの @terahide27 氏が講師となり、「設計」をテーマにワークショップをやりました。
■導入＆ワークショップby @terahide27 氏
ちなみに表紙の絵は @s_kic 氏が書いてくださったとのコト。
参加者が協力して創りあげた、という過程が素晴らしいですねー。
しかし、ツンデレなタイトルである。
以下、個人メモ。
■@terahide27 氏の自己紹介：「深夜アニメのカバレッジが90%」 (P.7)・むむ、今期は豊作だと聞いているが、90%はスゲーな。。。
・ちなみに@makopi23、先週、映画館へ行ってきました。助手が可愛すぎて生きるのが辛い。
・あと「宇宙兄弟」もずっと見てて、よく泣かされてます。エンジニア向けのアニメだと思うんだ。
■「折鶴」の設計書を書け、とのお題（P.11）を参加者全員でやってみるワークショップ・やべー、設計書を書くどころか、折鶴の作り方ぜんぜん覚えてなかった。
→ @makopi23、折鶴は諦め、紙ヒコーキにチェンジ。実際に折り紙で作ってみてから、設計書を書いてみる。
・いざ折り紙の設計書を書く段階になって、あれ？何をどう書けばいいんだ？と悩みこむ。
・自分が作れないものは設計書も書けない、という事実を再認識した。
■どうだった？（P.12）・@terahide27 氏曰く、
①「How（どう作るか）に注力しすぎ。What（何を作るか）をもっと考える必要がある。
②いきなりゴールが決まっているものを書かせると、whatを書かずにhowを書いちゃう
■設計ってなに？（P.13）・自分が思っているる設計と、回りが思っている設計は違う
・ウチの班のディスカッションでは「最初に完成図を書くべき」という意見が出た。
■設計の定義（P.22）・設計は「どんなものを作るかを考える作業」とここでは定義する。
■共通の枠組みがあったほうが話がしやすい・工程
・構成要素
・粒度
・アーキテクチャ
■みんな詳しすぎるので視野が狭くなる。→ 抽象化が大事
■「共通の性質」の例・P.46は「ツンデレ」という共通の性質がある
・抽象化すると「嫁」になる。（・・・！？）
■共通の枠組みがあったほうが話しやすい
■ドキュメントの役割①忘れない
記録として残しておく
②分かりやすい
ソース読むより図とか表とかのほうが全体像を掴みやすい
③時空を超える
時間を超える
■相手に合わせたものであることが大事■設計書を書くのが「設計」作業ではない
■「Coolな折り紙」をチームで作るワークショップP.70のスライドのあたり。
制限時間内で、チーム毎にクールな折り紙を作ることになった。
■要件・複雑
・モチーフが現実のもの
・目新しい
・曲線が混じっている
あと、他のチームが再現できるよう、設計書も作らねばならない。
■ウチのチームで作ったものお花！
・・・やべぇ、カッコ良すぎる orz
■工夫したこと①設計書として、作っているところをiPadで動画撮影した。
②雛形を用意した。（途中まで折っておき、ポイントとなる折り目や切れ目にマジックで指示を入れておいた）
おかげで、他のチームに折り紙を再現してもらった際の完成度は高かった！
■反省点・他のチームの人に再現してもらう際に、完成済みの折り紙を最初に見せなかったのがダメだった。
（全体像を知ってもらうために、最初に完成物を見せるべき）
■他のチームから出た、ワークショップの感想・折り紙で「蛙」を表現しようと思った。
→ 情報を言語化できないから蛙を表現できなかった（設計書を書けなかった）
・「飴」を折り紙で表現しようとしたが、全員が「飴」に対し暗黙の共通認識があった。
→ そのおかげで、折り紙で作ることができた
・折り紙で「くらげ」を作ることにしたが、職人技が必要だった・・・orz
→ 作った職人さん本人が他のチームの折り紙を作る役として出て行ってしまったので、
よそのチームから来た人に作り方を示そうにも、誰も再現できなかった
・折り紙で「半分に折る」といったような「パターン」が無かった。
→ パターンが無いと、同じものはできないな、と思った。
■まとめ■アジャイルサムライの13章「リファクタリング」で、「大変なのはきれいな設計を保ち続けること」と言っている。
■まとめ・段取り重要
・考えること重要
・伝えること重要
・効率よくしたいね
・記録を残そう
ちなみにウチのチームの机と模造紙はこんなカンジ。
■ビアバッシュでのワンシーン「ツンデレ」スライド(P.46)の周りに参加者が集まり、品評会をするワンシーン。
みなさま、お気に入りのツンデレキャラについて熱く語るッ！
ちなみに私、この中からだと、右上から2番目の助手が良いでございます。STEINS;GATEは神ゲー。
■参考図書今回の特別編の参考書です。
出版元であるソフトバンククリエイティブさんからも、この日の特別編に１名参加されていました。
んで、この書籍について裏話とかいろいろ紹介してくださいました。
あと、参加者へ数冊のプレゼントも！ありがとうございます～
まだ新しい書籍ですが、かなり人気は高いそうです。
エンジニアにとって避けて通ることのできない「設計」、改めて学ぶには良い書籍だと思います。
6-2節にはアジャイルの話もあるとのこと。
あと、@terahide27 氏がレビュアーとして、書籍の中にも名前があるそうです。（ココ、重要らしい！）
★感想：ワークショップで折り紙を作り、その設計書を書く、ということをやったわけなんですが、やっぱ自分が作れないと設計書なんて書けないことを実感。
ソフトウェア開発の世界では、コーディングの経験がないようなSEが書いた設計書を元に実装する、なーんてことが往々にしてあるわけなんですが、上手くいくはずがない。
あと、プログラミング能力が高いからといって、素晴らしい全体アーキテクチャを設計できるかといったら、そうとは限らないわけでもある。
そんな私も、良い設計ができるよう日々修行しているわけであるが、いろいろ考えさせられる１日になりました。
最後に講師の @terahide27 さんはじめ、参加者のみなさんありがとうございました。
2013/5/23(木) SQLアンチパターン読書会 「続・IDリクワイアド」 に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/3968以下の書籍をターゲットとした読書会なのです。
会場は湯島（御徒町）のアルティネットさんです。
主催者の @natsu_nanana さん、会場提供の @heroween さん、いつもありがとうございます。
参加者は全員で9人かな。今回も訳者の @t_wada さん参加です。頼もしい！
今回は前回に引き続き、3章「IDリクワイアド」がターゲットです。
というのも、この章はみなさん思い入れが強く、前回だけではディスカッションが尽きなかったのです。
前回のブログはこちら。
■3章「IDリクワイアド」の発表by @osa2 氏
（クリックするとDropboxにある資料に飛びます）
2度目の発表です。いつもありがとうございます。
ちなみに背景の画像は、以下のサイトにあるER図から取ってきたそうです。
http://laurel.datsi.fi.upm.es/~ssoo/DAW/Trabajos/2008-2009/022/このER図、良く見ると・・・
「あ、これ 進研ゼミ SQLアンチパターンでやったやつと同じだ！」
■各テーブルにカラム「ID」が！？ こ、これはまさか「IDリクワイアド」・・・！
■Categoryテーブルのカラムに「Parent」が！？ こ、これはまさか「ナイーブツリー」・・・！
ってな感じで感心しつつ、ワラタｗ
つーか、こんな題材よく見つけてきましたね～
あと、スライドP.8以降で「達人に学ぶDB設計徹底指南書」というミックさんの書籍から抜粋があります。
この書籍から代理キーをテーマに抜粋し紹介しているスライドが素晴らしいです。
このスライドにある市町村名の変更例を題材に、代理キーに関するディスカッションがとても活発になりました。
以下、そのディスカッションからメモ。
■「自然キー」と「代理キー」・ミックさんは、主キーは「自然キー」が良いと主張している。
・書籍「DBりファクタリング」では、主キーは「代理キー」でも良いと紹介されている。（P.159 「キー戦略の整理」参照）
・「自然キー」と「代理キー」、どちらの方が良い、ということは無い。これは宗教戦争。
・良い悪いではなく、好き嫌いの世界と捉えるべき。
・「論理設計」モードと「実装」モードでは、また別に考えないといけない。
・まず代理キーを使わずに頑張ってみるのはいいかも。
・代理キーは、現実世界には無いものなので、自然キーを探そうとするのは自然なこと。
■市町村の合併吸収の例 （スライドP.10以降）・B市がQ市に変更になっても、市町村コードはB市のコードをQ市でも使いまわす必要がある。
→ じゃあキー設計をどうするか？
→ 「年度」という概念をカラムとして追加して複合キーとし、履歴管理すれば区別できるのでは？
→ 「西暦4桁」だと同年にもう一度合併吸収があったときに対応できないので、年月日の8桁で持つべき。
・「あるときに何が起こって、何が発生する」というのを表現する場合、時間をキーに追加することが多い。
・市町村の合併と分離を考慮したモデルを最初に作っておかないといけない。
・これは、１個のテーブルで表そうとしている時点で無理。（上記の設計は完全ではない）
・３つの市が無くなって新たに「さいたま市」ができたような対等合併も考慮したりする必要がある。
・市区町村マスタがあればいい、という話ではない。
■表示順の制御・表示順を主キーで制御したい、という場合に、主キーを変えたいという要件があるのでは？
→ いや、それは主キーにすべきではない。
・表示順ってのは実装のレイヤーなので、アプリ側で保証すべき仕組みの世界の話。
・自然キーだとキーの振り直しが発生することはある。例えば最近だと以下の例とか。
【例】年金機構から基礎年金番号の付番機能を剥奪せよ：
http://takagi-hiromitsu.jp/diary/20130507.html日本年金機構が、性同一性障害で性別変更した人を判別するため、基礎年金番号10桁のうち前半4桁に共通する固定番号として8500を割り当てた。
→ 世間にバレて炎上
→ 8500から5000に変更
→ さらに炎上
・表示順を制御するためのカラムをDBに持たせないといけないのは、そうしないとできない場合のみに限る。
例えば、ある部署の平社員がとある別の部署の部長より権限が高く、表示上は上部に表示させたい、といった場合とか。
■1級と2級という表現（by @t_wada 氏)・１級： 自然界にあって、人間が指を指せるもの。
・２級： システム都合上、無いといけないもの。（論理削除フラグとか）
→ 自然界に改編の理由があるなら、それは１級として扱う。
■複合キーと代理キー・複合キーが面倒なのは、手を動かす段階（実装する段階）。
・論理設計の段階では、複合キーの方が良い。
・ORマッパーを使ってるので実装段階になると複合キーを避けたい、というのは実装都合である。
・モデルを読む側は複合キーの方がわかりやすい。でも実装になると複合キーはめんどくさい。
■前回のディスカッションの続き前回、みなさんで付箋に書き出したもののタイムオーバーとなって扱えなかったネタを中心にディスカッションしました。
■[3.2.4節] INNER JOINとUSING・INNER JOINはWHERE句でも書けるが、そうすると等値結合と条件絞込みが混在してしまう。
・混在を避けるため、以下のように使い分けるべき。
- WHERE句：条件の絞込み
- INNER JOIN：等値結合
・USINGも同様、等値結合であることを明示するために使う。(WHEREでも書けるがUSINGの方が意図がハッキリする）
・INNER JOINの「INNER」は省略できる。
・ただし、LEFT OUTER JOINとかとの違いを明示するため、INNERを明記したほうが良い。
■[3.4節の最終行] 長い文字列の列にインデックスを付けるのは非効率な理由・インデックスのデータ構造はKey&Valueではない。（線形構造ではない。木構造とか、何種類かある）
・B-Treeインデックスの場合、インデックスが一意に確定するまでノードのチェックに時間がかかる。
・対象データが大きいほど、B-Treeインデックスが大きくなるので、非効率となる。
・MySQLだと、先頭から桁数を指定してインデックス貼ることができるらしい。
■論理設計と物理設計の違い・サイズの見積りやデータ型、桁数、文字コード、領域割り当ては論理設計でななく物理設計で行う。
・論理削除カラムや最終更新者カラムを検討するのも物理設計。
・TreeのNested Setとかを考え始めるのも物理設計。
・論理設計と物理設計とでテーブル構造とか関係性が変わることがある。
・スーパータイプとかサブタイプとかの設計は論理設計で実施するが、物理設計でなくしたりする。
→ その際にSTSとかでなくすらしい。（この話は5章のEAVで出てくるらしい）
★感想：今回も大変有意義なお時間を過ごさせていただきました。
INNER JOINとWHEREの使い分けとか、私、今まで意識したことありませんでした。
んでもこの日の説明を聞いて「おぉ、なるほどなぁ」と感心しきり。今後意識してみようと思います。
あとB-Treeインデックスの話とか興味深かったですね。
インデックスの内部の仕組みまではほとんど理解できてないので、一度調べてみようと思います。
次回の4章「キーレスエントリー」、私がアジェンダのスライドを作ることになったので、早めに予習しよう。
皆様ありがとうございました～
2013/5/11(土) 「JJUG CCC 2013 Spring」に参加してきました。
JJUG CCC 2013 Spring
http://www.java-users.jp/?page_id=330togetter
http://togetter.com/li/500961Javaをテーマにした大きなイベントですね。参加者は300名弱くらい？でしょか。
私、仕事はほとんどJavaです。んで、Javaが好きです。なので参加することにした！
ちなみにCCCとは「クロスコミュニティカンファレンス」の略らしいです。
つーか、ウチの会社がシルバースポンサーになっていた件。
うむむ、弊社もCosminexusとゆーJavaのアプリケーションサーバを開発/販売してるし、JVMも作ったりしてるし。
そのへんでJavaイベントのスポンサーになったものと推測。
■総会（9:30-10:00）総会から参加しちまった・・・！
なんか採決とか会計報告とかやってて、正直、場違いなトコから参加してしまった。。。と、チョト後悔。
んで総会が終わったあと、となりの席にイケメンが座り、爽やかに語りかけてくる。
んむ？どっかで見たイケメンやなぁー、と思いながら会話してたんですが、その後、ノートPCで発表スライドを作り始めます。
こ、これは・・・！？
午後に「失敗から学ぶAPI設計」という題目で講演される @yusuke 氏であった。
そんなこんなで午前の部が始まりました。
以下、各セッションでスライドに無い口頭説明部分を中心に、書き殴りの個人メモ。
■基調講演-1 Javaのこれからを考える鈴木雄介氏 (日本Javaユーザーグループ 会長)
togetter:
http://togetter.com/li/501597 ■「オムニチャネル」という用語が出てきた。知らなかったのでググってみた。
→ 「2013年のWebマーケティング注目キーワード」第10回・オムニチャネル
http://www.webdbm.jp/column/3279/■今までは個別システムを担当している人がいて、どう連携するかを考えていた。
→ 今は、連携という概念すらない。最初から連携しているのが当たり前。
■変化にどう対応するかではなく、どう変化を感知するかが重要。
■世の中の流れがサービス型に変わってきている。
■基調講演-2 What’s New for JavaFX in JDK 8Jim Weaver氏 (オラクルコーポレーション)
■Java FX： Swingを引き継ぐインタフェースを作るもの
■ H-1 Java EE 6 から Java EE 7 に向かって寺田 佳央氏 (日本オラクル)
■Java EE 7
・新しい機能が4個くらい追加される。
・既存の技術も簡単になっている。
・物足りなかったところが改善されている。
・Java EE 6との差分を押させていただければ、Java EE 7には比較的簡単に移行できる。
■2009/12/9 にJava EE 6がリリースされた。 (P.5)
・J2EE1.4で「使いづらい」という意見をたくさん受けた。
→ J2EE1.4以降で、OSSの良いところを取り入れていこう、とマインドが大きく変わった。
・世の中の意見を聞いてできたのがJava EE 5。
→ そのやり方ではじめて作ったバージョンだったのでいまいちだった。
・それを改善したのがJava EE 6。
■Java EE 6に含まれる技術 (P.6)
・P.6のスライドで、緑色がJava EE 6で新しく入ったところ。
・P.6のスライドで、オレンジ色が以前か大きく変わったところ。
■2010/1/27にSunがOracleに買収された。 (P.7)
→ 仕事が減った。その余暇でBlogでJava EE 6の良さを伝えようと思った。
→ その当時、まわりのJava EE 6に対する視線は冷たかった。ぜんぜん注目されてなかった。
→ ３年たって、Java EE 6がようやく注目されるようになった。
■Java EE 6のテーマ (P.9)
・拡張性が上がった
・過去の資産をどうしても組み込みたい場合に、以前に比べて設定がめんどくさくなくなった。
・web.xmlに複数のフレームワークの設定を書いたら保守性が悪くなる。
→ それがEE6になると、web-fragmentでフレームワークごとに設定をかけるようになった。
■Java EE 6のテーマの１つ「プロファイル」 (P.11)
・将来的にはJava SEにも入る。Java EE 5までは、P.11の薄い青色の部分。
・濃い青色がWeb Profile。
・すべての機能は必要ない、余分なものを取り除いたサブセットがプロファイル。
■Java EE 6のテーマの１つ「Pruning」 (P.12)
・古くなって使われなくなったAPIを整理した。
・JAX-RPCのSOAPは、JAX-WSに移行した。
・いきなり無くすのではなく、２段階プロセスでPruninngする。
・Java EE 6で「無くしますよ」とチェックがついた。Java EE 7で仕様的に使えなくなる。
・個々のアプリケーションサーバによっては、残すAPIがあるかもしれない。
・ただしJava EE 7の仕様的には無くす。なので、今のうちに移行してほしい。
■Java EEは開発生産性が悪いと言われていたが、以前のバージョンに比べ圧倒的に開発生産性や開発用意性、テストのしやすさが上がっている。 (P.14)
■EJB (P.21)
・Java EE 6からEJBコンテナをJava SEのアプリから立ち上げられるようになった。標準機能として提供される。
■Java EE 5まではフル・スペックを提供 (P.24)
・Java EE 5まではフル・スペックを提供しており、重すぎた。Tomcatで十分、と思われていた。
■Java EE 6からWeb Profileに対応したアプリケーションサーバを使えば、速くなる。 (P.25)
・Web Profileは、これさえあればWeb開発は十分というものを残している。
■パッケージング (P.27)
・パッケージングはこれまではめんどくさかった。
例：Webアプリはwarにまとめて、ライブラリはjarにかためて、EJBはEarにまとめてとか。。。
→ １つのwarのなかにejbとかも組み込めるようになった。
■XML設定地獄 (P.30)
・Java EE 5以降から、デフォルト値がすでに設定されている。
→ デフォルト値でいい人にとっては設定がすごく楽。
■Java EE 7のテーマ (P.37)
・シンプル化
・HTML5対応
■Java EE 7
・Java EE 7は6がベースになっている。
・なので、6から7の差分だけ押さえれば楽に移行できる。
・Java EE 7からBatch Applicationが追加される。
■JSON (P.40)
・JSON用のAPIは２種類の方法を提供している。
①Streaming API
②Object Model API
■Expression Language 3.0 (P.61)
・JSPの$とか#の書式が、Java EE 7から書式が大幅にアップデートされる。
・EL式のなかにラムダ式が書ける。
■H-2 Project Lambda Essential櫻庭 祐一氏 (Java in the Box)
■Project Lambdaの目的
・closureのかわりではない。クロージャを導入するためではない
・parallel computingを簡単にするため。
■lambda Exp.とAPI
・どちらが重要かというと、API
・パラレル処理をするための基盤になる。
・lambda Exp. << API
■タスクをちっちゃくしてスケジューリングを簡単にしましょう。
■JAVA SE 7でFork/Join Frameworkが入ってきた。・・・使えないです。非常に使いづらい。
・lambdaと一緒に出る予定だったが、これだけEE7で単品で出てしまって使いづらい状況にある。
■lambdaは無名クラスを簡単に書くためのもの。
・シンタックスシュガーでしかない。
・なんでもlambdaで書けるわけではない。
■mapメソッドの処理は遅延される。
→ これは遅延評価の仕組みが取り込まれたのかな？と個人的な疑問。
■Steam APIは関数型の考え方を取り入れている。
・そのため、上司がわからないから使うな、といわれる可能性もある。。。
■lambdaでパラレルコンピューティングも非常に簡単になる
■R5-3 Type Annotation って何? それを使うとプログラムはどう変わる?木村英一氏
■Java8には82個のアノテーションが定義されている。Java 7は78。
■宣言に対して属性を与えるのがアノテーション。
・アノテーション型と型アノテーションは違う
■アノテーション型には２種類ある。
・これまでJava5～7にあったのは、宣言アノテーション。型利用に対するアノテーションはできない。
・今回Java8で増えるのは、型アノテーション。
・Java SE 8では型に対してもアノテーションが記述できる。
■Java SE 8からインスタンスメソッドにthisが書けるようになった。
・さらに型アノテーションをつけれるようになっている。
■型アノテーションの「意味」は規定しない (P.24)
・型アノテーションを書けるようになるけど、それには意味がない
・規定する側のJSRがサスペンド状態になっている。
■JSR308の型アノテーションを利用したチェッカがある (P.28)
→ Checker Framework
■Nullness checker (P.31～)
・NonNullチェック
・NonNullのアノテーションを付けておくと、コンパイルの段階でNonNullのチェックができるようになる。
■InterningChecker (P.37～)
・Internedがついているものとついていないものの比較はコンパイル時にチェックされる
・またs1とs2をeqaulsで比較すると、==で比較せよ、と警告がでる。
・開発者はinternedとなっていることを保証しないといけない。
・型アノテーションは実行時の属性まで保証してくれない。保証するのは開発者。
■型アノテーションをコメントアウトして書くと、JDK7でも通せる。
■H-4 失敗から学ぶAPI設計山本 裕介氏 (サムライズム / Twitter4J)
■Twitter4Jというライブラリを開発している。あんまり失敗してない（笑
■なるべく敷居をさげてたくさんつかってもらえるようにしている
■利点
・Javaなので、型安全に呼び出せる
■Twitter4Jの開発指針
・YAGNI
・JavaのインタフェースはJavaプログラマで理解していない人もいるので、なるべく使ってない。シンプルに。
■拡張
・拡張が出来過ぎると、簡単に使いたい人にとって邪魔になる。
・へたに拡張させることを想定すると設計がすごく難しくなる。
・finalなクラスにしている。継承させない。
・モックテストをしたい箇所はわざとfinalにしていない。そこにはコメントで、拡張しないでね、と書いている。
■デザインパターン
・デザインパターンをわからないエンジニアがいるので、デザインパターンは使わない。
■IDE補完
・importされていないクラスを呼ぶのはIDEでも大変。なのでなるべく同一パッケージに。
・一般的過ぎるクラス名にしない。一般的にしすぎるとIDE補完で衝突する。
・IDEで補完が活きすぎないように。使われたくないクラス名の先頭にZをつけるのは、最後に表示されるようにするため。
■互換性
・互換性のため、基本的でないクラスさえも、クラス名はバージョンアップ時に変えないようにしている。
・直列化形式の互換性を保つ
・シリアライズされてバイト列に変換されたものの互換性まで保つ。
・フィールドがなくなったりするとシリアライズされた状態が変わってしまったりするので、そういうことをしない。
・どういう変更が直列か形式に影響するのか調べる。
・deprecatedをアノテーションでつけておくと、コンパイル時に非推奨と表示がでる。
・パッケージを分けるのではなく、ソースディレクトリをわける。
■javadocで足りない場合は、テストに気を付ける。テストを読めば使い方がわかるようにする。
あと、ログに気をつかっている。
■R5-5 [BOF] Java読書会ライブ高橋 徹氏 (Java読書会BOF代表)
Java読書会
http://www.javareading.com/bof/この日は実際にコアメンバー＋参加者飛び入りでJava読書会の実演が実施されました。
・平均60ページくらい進む。
・事前に読んでこなくてもよい
・不明点はその場で調べたり宿題にしたりする
・本を選ぶプロセスは、参加者のweb投票。
・英語の書籍の場合は、事前に訳さないと辛かった。
・読書会に入門本は向かない。ある程度、自分で読むと読み飛ばすような本が読書会向き。
・積ん読になりそうな本がよい。
・その場でコードを実行することもあるが、しないこともある。
・朗読することで深い議論できたりする。
■R2-6 [BOF] 地方における勉強会事情togetter:
http://togetter.com/li/501590 ■地方だとコネクションの拡散が弱い。どこの勉強会へいっても同じ人がいる。
■エヴァンジェリストとか、Twitterでなんかつぶやいている時は暇だな、と思ってそのチャンスに講演を依頼する。
■パネルディスカッション
■勉強会の参加具合とかキャンセル率とか
・参加登録のタイミングが都市だと２、３日で埋まるがキャンセルも多い。
・地方は参加がなかなかこない。告知しても参加者がなかなか集まらない。
・地方だと、開催の前の週あたりから急に申し込みが増え出す。キャンセルは７０人で２、３人くらい。
・ドタキャンすると、大体誰がしたかわかる。
・大阪も即埋まらない。参加希望なのに、様子見しちゃう。
・沖縄もぎりぎりまで登録しない人が大半。勉強会に来る人は同じ。定員に入るのは当たり前なので登録すらせずにその日に来るみたい。
・広島も当日いきなり来る人が多い。なので懇親会もお金を集めるとき困る。お金が関わる勉強会は開催しにくい。
・沖縄はスポンサー集めるの大変。
・札幌は、集まらずに赤字になったら主催者の自分が出す。
・大阪は、Jenkins勉強会とかはたくさん人がくる。でも懇親会はドタキャン多い。
■勉強会ネタはどう決めているか。
・jjugは公募。
・沖縄は、本土から沖縄へくる講師駆動で勉強会を開催する。
→ 沖縄から勉強会講師に呼ばれたから沖縄いきます、と会社に旅費を出してもらうように仕向ける。
・中国は、来たいといってくれる講師がいない。こっちからアプローチするしかないので、コンテンツ決めが中心。若い人に話してもらう場を設ける。
・札幌だと、主催者が興味があることをやる。あとは年に２、３回に東京に出て勉強会の講師をやって、札幌にも来てもらうように仕向ける。
・勉強会の感想blogを読んでくる人もいる。blogとかツイートで勉強会は楽しいものと露出度をあげるのが有効かも。
・ワークショップ系が食い付きがよい。ただハンズオンは準備が大変。
・ハンズオンだと参加者が多くてもサポートできない。
・ハンズオンだとＰＣが必要になるのもネックになったりする。
■海外の勉強会
・海外だとコミュニティが転職の場になる。
・国として意識が高い
・コミュニティで自分のバリューを上げようとする。
■勉強会の参加者
・「勉強会」という言葉がカタイかも。
・参加者は30代の人が多い。奥さんをフォローする仕組みがいるかも。
・javaはメインが30代で成熟してきたので、どうしていくかを考えないといけない。
・中国地方はrubyが強い。中高生もくる。学校でも教えているので。
・javaだとandroidに興味がある人がかろうじてくる。
・RDBとかカーネルとかになると、２０代はほとんどこない。
・rubyとかjavascriptだと２０代がおおい。
・javaだと３０～３５歳くらいが多い。
・有料セミナーは若い子こない。
・無料セミナーとしてきっかけ作りとか刺激をあたえるJavaの勉強会にする。
・作ったものが動いていると楽しい。
→ JavaFXのハンズオンとかは参加者を巻き込めるのではと思っている。
・参加費に５００円とると、もう若い子がこない状況。
・女性の参加率は、oracleとかrubyとかだと比較的多い。
・女性のスピーカーが出ると、勉強会の女性の認知度もあがるのでは。
・意図的に多様性を取り込むのも策かも。２５才以下でＬＴ枠を設けるとか。まさかり禁止で。
★感想：Javaの最新状況を知ることができて有意義な時間でした。楽しかったし、刺激をもらいました。
あと、jjugの講演とかをこの日いろいろ聞いた限りだと、今の世の中の「Javaのイメージ」として以下のようなものが大勢を占めているような印象を強く受けました。
・他の言語に遅れをとっている
・古臭い
私がJavaを学び始めたときは、「Javaってすげぇ斬新や！」ってな時代だったので、この日はそのギャップを感じて少々戸惑いました。
いやぁ、月日が経つのは早い。でも私はJavaがやっぱ好きです。
あと最後の勉強会事情のセッションでも講演者がおっしゃってましたが、勉強会に参加する理由は「楽しい！」からなんですよね。私も。
勉強会で学んだことを実践しないといけない、とか、何かを習得しないとけいない、とか堅苦しく考える必要は全然ないと思ってて、単純に「楽しい」から参加する。
その気持ちがまずあって、あとは自分の興味に合わせて学習のキッカケにしたりしてます。
もちろん、自分が興味がある勉強会を選んで参加してるわけだから、予習もするし、お話も注意深く聞くし、ディスカッションにも自然と熱が入るし、頑張ってハンズオンやろうとしたりするし、それで収穫も自然と多くなる。
あと、やっぱ刺激を受けるのが大きいかなぁ。
やべぇ、こんな凄いエンジニアが世の中にはいるのか、俺も頑張ろう！みたいな。
この日も、みんなJavaをネタに楽しそうに話している姿が印象的で、それだけで楽しい気分になれました。
こーゆうイベント、やっぱいいですねー
2013/5/14(火) アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/3455以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者は15人くらいでしょか。
今日は通常会ということで、11章「現場の状況を目に見えるようにする」がターゲットでした。
ウチの班は4名で、ホワイトボードはこんなカンジ。
11.1節に「リリースボード」というのが出てきたのですが、私、このプラクティス初めてでした。
ストーリーボードでもタスクボードでもなく、リリースボード。
どうやらマスターストーリーリストをボード化したものらしいです。
ココを最初に読んだとき、「あれ？ユーザーシナリオをマスターストーリーリストで一覧化して、リリースボードにもまたシナリオを貼るの？それって二重管理じゃね？」と疑問に思いました。
その辺のモヤモヤもあって、シナリオとタスクの管理方法について結構ディスカッションしました。
あと、 班の御一人の事例を紹介してもらいました。興味深かったのでメモ。
■ユーザーストーリー（上図の左側）・横浜道場の付箋を２つ合体させたような、横長で少し大きめの付箋を使うそうです。
・付箋には以下の情報を書くとのコト。けっこー盛りだくさんですね。
①識別ID
②ストーリーポイント
③What
④Whom
⑤Why
⑥やること
⑦やらないこと
■タスク（上図の右側）・ユーザーストーリーをタスクに分解する。
・タスクも付箋に書き出すが、ユーザーストーリーより小さい付箋に書く。
・タスクの付箋には、見積時間（理想時間。単位h）と実作業時間の２つを書く。
→ 両者を一目で比較することができ、見積時間と実作業時間が乖離しているタスクがすぐわかる。
■ユーザーストーリーとタスクの付箋運用で工夫していること・あるユーザーストーリーの付箋と、そのストーリーを分解したタスクの付箋を同じ1枚のA4用紙に貼ることで、ユーザーストーリー毎に用紙で分けているとのこと。
・各開発者の名前シールを貼った磁石を用意し、今誰がどのタスクをやっているかがわかるよう、磁石をタスクの付箋に上からくっつける。
・ユーザーストーリーはチケット管理システムのような電子でも管理しているとのこと。
■バーンダウンチャート
・バーンダウンチャートを１イテレーション毎に書く。
・横軸は１イテレーションの経過日付を書く。
・縦軸の左側にチームのベロシティ、右側にそのイテレーションで開発するタスクの総見積時間を書く。
・バーンダウンで開発完了の線を、バーンアップで実作業時間の線を書く。
こーゆう事例を紹介してもらえるのは大変ありがたいですね。
■ウチの班でディスカッションしたネタのメモ■タスクボードとかインセプションデッキとかを壁に貼ったが、チーム外の他の人に見向きもされなかった。
→ 見える化したからといって、上司とか同僚とかが興味を持ってくれるとは限らない。
→ 逆に、見える化することで、興味を持ってくれる人とそうでない人が一目でわかるようになる。
■タスクの粒度は8h前後の作業。二日くらいで仕上げられる程度がいいのかも。
■派生開発やXDDPにも繋がるが、ユーザーストーリーは「理由」が大事。
・理由はブレにくい。
・理由を明確にしておくことで、そのストーリーが実現困難になった時とかに代案を探しやすい。
・派生開発では、ユースケースだけでは足りない、と主張している。理由が大事と言っている。
・この話の関連で「ICONIX（アイコニクス）」という開発方法論がある、というお話を聞いた。
・ICONIX（アイコニクス） は、ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論である。
RUPと同様にICONIXプロセスはUMLのユースケース駆動であるが、RUPより軽量である。
by wikipedia
http://ja.wikipedia.org/wiki/ICONIX■11.4節のディスカッション
・ドメイン用語とかはWikiに書き残す運用にしている、という話が出た。
・参照で関連付けたり、リンクを押すと定義が見れたりできる。
・手軽に編集できる。
・人の入れ替わりが多かったり新人が入ってきたときに共有しやすい。
■11.5節のディスカッション
・組み込み開発でハードウェアのテストをする際に、バグ監視の指標にMTBFを使っている、という話が出た。
→ テストを継続して行い、バグが検出されるまでの時間（≒MTBF）で品質の安定性を見るらしい。
・バグ対応作業も、チケットや付箋として起票し、見える化して管理すべき。
■各班の発表で出たお話のメモ■用語集は量が膨大だが、勘違いしそうな用語は貼り出すようにしている。
・これまで間違えたことがあるものを張り出す。
・これまで痛い目を見た用語を張り出す。
→
この工夫は個人的には、良いなぁ、と思いました。なんか、思いやりを感じました。
「用語一覧表に書いてあるだろ、ちゃんと見とけやボケ！」みたいな、見た見てない問題のような風景でなく、これは注意が必要だから見ておいてね、という心遣いが見えてなんか良かった。
■貼紙の進化、という概念が紹介されてた。
・貼り出すと、重要なものに集中する、という効果が得られる。
・壁は狭いので、必然的に重要なものを絞らざるを得なくなる。
・自分が報告しなくても、貼り出したものを上司が見てくれれば、報告の手間が省ける。
・陳腐化しない効果もある
■用語集ってそもそもなんで必要なの？
→ お客さんと会話するため、概念を共有するためでは？
→ ユビキタス言語の一種では。
■プレゼン能力が重要、という話が出たが、プレゼン能力って必要？
→ そもそもプラクティスとかがうまく説明ができないのは、理解が足りてないだけでは？
■瑕疵担保期間を過ぎているかどうかで、バグ対応するか否かを変える、という紹介があった。
★感想：予習というか、対象範囲を軽く読んでから参加したのですが、実際にディスカッションしてみると新たな気付きとかが多くてマジ驚き。
あと今回もいつもどおり15分のスプリントを4回回したのですが、11章は2回で読めちゃいました。
なので残りの2回分、30分間はまるまるディスカッションしてました。
これが案外いいと思った。直前に読んだ内容に引っ張られすぎず、11章全体について結構な深さで議論できました。
今後も4回のスプリントのうち、最後の1回は全体ディスカッション用に取れるといいのでは、と思ったり。
懇親会のビールとピザも、おいしかったです。
道場主様、スタッフ様、参加者の皆様ありがとうございました。
2013/5/12(日) 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加してきました。
connpass
http://connpass.com/event/2270/togetter
http://togetter.com/li/490112以下の書籍をターゲットとした写経会なのです。
場所はいつもの横浜、タネマキさんです。参加者は20名くらいかな。
今回は特別編ということで、著者の @shuji_w6e 氏が参加！
しかもお題はSelenium！期待せずにはいられない！というのも私、前回のJUnit写経会の事前アンケートの、「触ってみたいツール」的な回答項目に、ちょうど「Selenium」と回答したばっかりなのです。
一応お仕事でもJenkinsで自動テストは仕掛けているのですが、仕掛けているのはロジック部分の単体テストのみ。
んで常々、Webアプリの自動テストをなんとかできないものかなぁ、Seleniumというものがあるらしいんだけど試してみたいなぁ、とか思っていたところなのでした。
そんな私にとって、今回のテーマはストライクすぎる！
今回の写経会は、事前に開発環境を構築をするための準備までされてます。この充実ぶりは素晴らしい！
■本日のご案内by 主催者 @shinyaa31 氏
毎度、アジェンダの作成とか司会進行アリガトウございます。
今回は更にお弁当の手配とか、至れり尽くせりです。感謝！
以下、スライドに無いトコ中心に、個人的にとったメモ。
■講演『テスト駆動開発を継続する』by @irof 氏 (“TDDBC Osaka 2013 1月 外伝”再演)
@irof 氏による講演です。
発表スライドはまだ公開されてないようなので、1月のものを貼ってます。
■P.36 ついで症候群
・最初の２つのassertはいらない。他のユニットテストでやってるはずなので。
・ついでに書けるからといって余分なテストを書くと、プロダクトコードを1箇所変更するだけで、あちこちのテストでコケる。
（テストケースに重複があるので）
■テスト大変だからテスト失敗しないようにしよう、となるとダメ。
■開発が進むにつれドメインが明らかになってくる。
・適切な名前もわかってくる。なのに変更/リファクタリングできない、というジレンマの事象が出てくる。
・変えたい、と思ったときに変えられるようにする必要がある。
■失敗が特別行事になると、変更やリファクタリングができなくなる。
・なので、失敗は特別行事じゃなくて、あたりまえのことにする。
■場当たり的な対処は、新たなミスを生む。
■テストを書く、ということは、想定できることしか書けない。
・でも、プロダクトコードを修正すると、想定できないバグが起こる。
・なので、プロダクトコードを変更してもバグは起きない、ということが定量的に言えない。
・そこを保証しようと思ったら、網羅性を考慮するしかない。
・どういうテストを自動化するか、を考えることが重要。
・予測不可能なことが起こるなら、設計が間違っているのでは。
・環境がおかしくてテストがコケることを検知するテストはまた別にある。
■受け入れテストの自動化とユースケース駆動開発by @shuji_w6e 氏
(↑はTDDBC 大阪の資料。これと当日資料はほぼ同じとのこと）
■状況によってはJUnitのテストが無くてもアリだと思っている。
・Railsはほとんど設定でおわり。コードあんまり書かない。
・ユニットテストをすると、Railsのサクサク感がなくなる。
・Railsだとテストで○か×かはない。設定されているかされていないかだけ。
・ユニットテストやるよりは、いっそのこと受け入れテストやっちゃった方が良い場合がある。
・受入テストを厚く書いて、ユニットテストは不安なとこだけ書く。
・そのようにやってみたら、Railsならこっちのほうが良いと思った。
・ユニットテストは、不安なところをやるのが結論だと思う。
■テスト駆動開発かユニットテストかの違いは、テストファーストを実践しているかどうか。
・テスト駆動開発はプログラマを救ったか？
→ Yes。確かに救った。
■重要なのは、要件からテストケースを導くこと。
・何を作るのかを考えなきゃいけない。それを要件から導かないといけない。
・外部設計が一番重要だったりする。
・TDDは要件とテストリストの橋渡しはしてくれない。
■外部設計の手法で、ユースケースを使うのが一番いいと個人的に考えている。
・アジャイルで言うとユーザーストーリー
■ユーザーストーリーからプログラムがいきなり作られるわけではない
・しっかりユースケースシナリオに落とし込むことが重要。
・見た目も重要。ユーザが実際に触るシステムは、中のプログラムでなく、外部インタフェースなので。
■「基本設計」という名前よりも「外部設計」という名前が好き。
→ 「外部」という単語から、システムの利用者視点、というニュアンスが出ているから。
■神崎さんの外部設計の書籍がおすすめ。
■ユースケース駆動開発実践ガイドという書籍が参考になる。
・まず前半半分を読めばよい。後半はユースケースで設計したものをSpringで実装する話。
・前半が重要。
■ユースケースは、システムの使用例。
・ユースケースシナリオは必ず箇条書き。１行で１アクション。
・お客さんにモックアップを見せながらユースケースシナリオを組み上げていくのが外部設計。
・ユースケースシナリオは実装チームじゃないと書けない。実装を意識しないと書けない。
・なのでSIerのマネージャ的な人がユースケースシナリオを作って開発チームに渡そうとすると、死ぬ。
■ユースケース図はただの目次。
・ユースケース図をいくら書いたって外部設計にはならない。それは要件定義でしかない。
■ユースケースには二つの流派がある。「システムユースケース」と「本質ユースケース」。
・本質ユースケースを要件定義でやるのは問題ない。
・ただし実装の際はシステムユースケースに落とし込む必要がある。
・両者は別物。
■ユースケースシナリオは、お客さんの合意が取れてないといけない。
・合意を取るためには、日本語でお客さんが理解できる言葉で書かれていることが重要。
■ロバストネス分析
・3要素がある。
①バウンダリ ： 境界。ユーザが操作するところ。
②エンティティ： DBに永続化するようなデータ。
③コントローラ： 操作。
・頭の中で分析を済ませて先に進めることもある。ガチガチにロバストネス分析すればいいわけじゃない。
・ユースケースシナリオに「管理者」という単語が何箇所か出てくるが、それってそれぞれ別じゃね？
・・・といったような分析とかをやる。「管理者」を更に細分化したりして、日本語の曖昧さを無くす。
■現実としては、ロバストネス分析をやる前提でユースケースシナリオを書くので、分析をしなくてもあまり乖離しない。
■ユースケースシナリオ
・コントローラがユースケースシナリオの動詞で、publicメソッドになる。
・ユースケースシナリオからクラス数とかメソッド数とかテストケース数とかがざっくり見積もれる。
■みなさん大好き「確認画面」を追加すると、ユースケースシナリオが3行ほど増える。
→ 「このくらいコスト増えますよ」とユースケースシナリオを見せてお客さんに言えるようになる。
→ 折衝の材料にできる。説明の際の武器になる。
→ そうやって説明をきちんとして、いらないものは作らない方が良い。
■ユースケースシナリオの量が多くなると、「レビューが辛い」とお客さんがなる。
・それで「じゃあ、いらないもの削りますか？」と持っていける。（折衝の材料になる）
■ユースケースシナリオの1行がユニットテストに対応する。
・受入テストは、ユースケースシナリオの全行が対応する。
■受入テストだけやってユニットテストをやらない、というのはアリ。
・不安なとこだけユニットテストをやる、というのが結論。
■ユースケースシナリオを作る段階は、受入テストを作っていることとほぼ同義。
・テストデータがないことだけが違う。
■「実践アジャイルテストという書籍に、アジャイルテストの4象限が紹介されている。
」
・ユニットテストはプログラマが救われるためのテスト。基本的に自動化が前提。
・ユースケースをテストシナリオにできる。
・ユースケースを序盤できっちり作れば、テストシナリオを書いたことになる。
・自然言語でテストシナリオを書くことで、Cucumberのテストに繋がる。
■ユースケースシナリオにおける代替シナリオは、お客さんに価値を届けるというより、品質を上げるもの。
・主シナリオに分岐はない。１つの価値のみ書く。
・20ステップを超えるとデカ過ぎ。複数のシナリオに分割したほうがよい。
■アーキテクチャやフレームワークを理解している人なら、ユースケースシナリオは作成できる。
・個々のフレームワークの詳細よりも、抽象化された概念がわかればいける。
以上、午前は @irof 氏と @shuji_w6e 氏による講演でした。素晴らしいクオリティです。
■Cucumber＆Selenium ハンズオン@shuji_w6e 氏が用意してくださった演習題材を使用し、Cucumber＆Selenimuのハンズオンです。
実際にSpring Frameworkを使って構築された書籍管理Webアプリケーションに自動テストを仕掛けます。
しかもテストシナリオは日本語で書きます。
すんげー実践的でハイクオリティなハンズオンです。
私も、なんとか最後までテスト書いて、動作させるところまでできました！
私、初めてSelenium使ったんですが、自動でリンクがクリックされて画面遷移する挙動を見たときはチョト感動した！
このハンズオンの内容は、ちょうど会社のサンプルWebアプリケーションのテストにも使えると思う。
これは復習するに値する内容と題材ですね。
もう一度、課題の材料を使って一からやってみようと思います。
私のスキルと頭では、なかなか目の前の課題を順にこなしていくので精一杯なところもあったので。。。
あと、ちょとメモ。
・MavenのProfile機能は強力。
・GradleなりMavenを覚えたほうが良い。
・テストシナリオをつくるところがイマイチだと、後ろをどんだけ頑張ってもうまくいかない。
・ユースケースシナリオを綺麗に書いているかがキモ。
・結論：ユースケース駆動開発もやろう！
■懇親会ハンズオン終了後は、同じ会場で懇親会です。
@shuji_w6e 氏と @irof 氏と私の3人で、近くのスーパーに買出しに行ってきました。
著名なお二人と会話する機会！光栄な役回り！
@enum 氏も飛び入り参加で、講師のお二人と参加者でソフトウェアテストに関する話で盛り上がりました。
■いろふの部屋＆LT@irof 氏から参加者に質問を投げかける形で、ソフトウェアテストを題材にいろいろお話しました。
またTABOKをテーマとしたLTもありました。
TABOKという単語、私は初めて聞きました。
Test Automation Body of Knowledgeの略称だそうです。（PMBOKとかBABOKとかと同じ類のネーミングですね）
テスト自動化の知識体系だそうな。この辺のサイトが参考になるかも。
テスト自動化研究会https://sites.google.com/site/testautomationresearch/
★感想：素晴らしいクオリティでした！充実な一日です。
今日のハンズオンで学んだ内容は実務にも使えると思うし、講演からも多くの気づきが得られました。
ホント主催者の @shinyaa31 氏、講師の @shuji_w6e 氏と @irof 氏に感謝！
このような特別会、またあるといいなぁ。長野で温泉ハンズオンみたいな話も出てたし、楽しみです。
皆様、ありがとうございました。
2013/5/9(木) SQLアンチパターン読書会 「IDリクワイアド」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/3774以下の書籍をターゲットとした読書会なのです。
会場は御徒町（湯島）の株式会社アルティネットさんです。
参加者は10人かな。ディスカッションには最適な人数です。
今回も @t_wada さん参加！更にOracleの @yokatsuki さんまで参加です。贅沢な勉強会ですねー。
私、この日は体調不良で会社をお休みしました。
んで午後6時くらいまで病床に臥していたのですが、気合で勉強会に参加！
今回も、いつもの如くディスカッションしたいテーマを各自で付箋に書き出しました。
■IDリクワイアド、という原著のタイトルに対し、翻訳者と「とりあえずID」と日本語訳を決めた。
→ どういうニュアンスでタイトルを伝えようか、といろいろ考えた。
■読者からは11章の「ファントムファイル」と今回の「IDリクワイアド」が一番反響があった。
■IDリクワイアドは使うべきではない！という意見アリ。
→ 論理設計の段階では、IDはすべてに付けないはず。IDリクワイアドは飽くまで物理設計。
■ナチュラルキー、主キー、複合キー、擬似キー、ユニークキー、サロゲートキー。。。いろいろなキーがある。
・主キーがないとけいないと思うのは間違い。
・ユニークキーがないといけない、と思いこむのは間違い
・あった方が便利、というのと、なくちゃいけない、というのは別。
■この3章だけで、DOAの方までこの本がリーチしたのが面白いところ。渡辺幸三さんまで！
■自然キーとは？
・社員番号とか健康保険番号とか、実際の世界で使われている識別子。
・ユニークとは限らない。
・どれを自然キーとするかが論理設計そのもの。
■ユニークキーとは？
・ユニークキーは、ユニークであるだけであって、主キーとは別。
・ユニークキーはNULLを許容する。DBMSによって仕様が変わる。
■物理設計とか実装を加味していく段階でIDがほぼすべてのテーブルに出現する、というのはあるが、それは実装に向けた設計の話である。
・その段階までに、キーになりうるものが見つからないのはおかしな話。
・論理設計の段階では「とりあえずID」はないのでは。
■オートインクリメントの主キーだと、テストデータを作成するのが大変。。。
・オートインクリメントのキーが外部キーとして使われていたりする。。。
・開発時点では、各開発者のマシン上に構築したDB上でテストする。
→ そうなると、キー以外のカラムの値は同じなのに、主キーの値だけ各自のDBで異なるカオスな状況に。。。
■「とりあえずID」のような設計をやる人は、表計算ソフトに慣れすぎ。
・Excelのような単調増加の行番号がないと不安。
・集合論でモノを見てない。
・カラムの並び順が思ったようにが並んでくれない、とか言う。
・トランザクションで歯抜けになった番号が気持ち悪い、とか言い出す。
・ビューと構造が合っていないのを嫌がる。
・とりあえずID、の人は、テーブルを表計算ソフトとしか見ていない。
■データベースを2次元と思ってしまうのがだめ。DBは多次元集合。
■データベース設計者（DBA）がきちんとDBを設計するような現場では「IDリクワイアド」とかは起こりにくい。
・ただし、その人がDB設計をやってしまうので、人が育たない弊害はある。
■データ移行で何が辛いかというと、シリアルのキーを移行するのがすごく辛い。
・移行の際に、番号は振替ないといけない場合がある。
・なので、IDリクワイアドは移行が大変。再構築したほうがいいことが多い。
■アプリケーションコードよりDBの寿命の方が長い。
・データは移行しながらずっと使うので。
・データベースよりデータの寿命の方が長い。
■日本年金機構が、性同一性障害で性別変更した人を判別するため、基礎年金番号10桁のうち前半4桁に共通する固定番号として8500を割り当てた事例
年金機構から基礎年金番号の付番機能を剥奪せよhttp://takagi-hiromitsu.jp/diary/20130507.html→ 炎上後、番号を変えて新たに附番しなおすとした。（さらに炎上）
→ 外部の要因で自然キーを付け替える良い例。
■画面中心設計だと、データの設計から始まらない。
→ それで継ぎ足しでやっていっていろいろおかしくなる。
■デザインの変更とDBの変更は、本来は全く関係がない。
・RDBMSは、デザインの変更に柔軟についていくためにある。
・RDBMSとSQLがあるからデザイン変更についていける。
・結論が逆。デザイン変更が止まらないとDB変更が止まらない。のではなく、デザイン変更を止めたくないからDB設計をする。
・画面は一番寿命が短い。それよりアプリケーションコードの寿命の方がやや長い。
・DBMSの寿命の方ががさらに長い。更に、データの寿命の方が更に長い。
→ デザイン変更の際に、寿命が長い方が影響をうけるのはおかしい。
■画面にデータ項目が追加になった場合に、DBにカラムを単純に足せばいいのか、そうじゃないのかを判断できることが重要。
・変更に対して敏感になることが大事。
・画面の項目数＝テーブルのカラム数、のように画面とテーブル構造を直結して考えちゃうのがそもそもの間違い。
・本来はビューとテーブル設計は別。
■本書で設計の議論が一番出たのがIDリクワイアド。
・フレームワークがIDを振ることがある。その場合は従うべき。
・名言「俺はIDを振ってない！RailsがIDを振ってるんだ！」By 角谷さん
・RailsにとってはIDはポインタの一種。ポインタは意識しないけど存在している。物理設計の際に存在しているのは当たり前。
■プログラムの延長線上で考えるのではなく、データの構造は別として考え切り替える。
・経営から落としていく。経営としてどういう情報が必要か、を考えるのがいいのでは。
■DB設計のサンプルはいっぱいある。英語さえ読めれば。一番有名なのは以下らしい。
database Answershttp://www.databaseanswers.org/data_models/index.htm→ サンプルが600くらいある。
■IPA情報処理技術者試験のデータベーススペシャリストの午後Ⅱ試験はDB設計の良い題材かも。
・DB周りは、資格が唯一機能を果たしている分野かも。
・モデリングなんで、抽象的に考えられる素質が必要かも。
■プログラムを書く事とDBの設計は切り離して、データをどう扱うか、というコマを1つ用意すべきでは。
・プログラミングの延長としてDB設計を考えると惨状が生まれる。
・データをどう設計するか、というのだけをきちんと教えるのを教育に盛り込むことが必要。
■書籍「データベースリファクタリング」の6章に「自然キーによる代理キーの置き換え」という節がある。
→ 参考になる。
★感想：話が沸騰して、2時間でIDリクワイアドを語りきれないほど盛り上がりました。
みなさん、IDリクワイアドとかDB設計について、溜まりに溜まった思いがあるようでしたね。
ということで、次回もIDリクワイアドについて引き続きディスカッションします。
体調不良ながら参加した甲斐がありました。でも、帰りの電車、間違えた。。。
最後に、参加者の皆様ありがとうございましたー。
-->
