java-ja.ddd に参加してきました #java_ja

java-ja.ddd DDD！！DDD！！
http://connpass.com/event/1934/

2013/03/22 java-ja.ddd #java_ja #java_ja_ddd
http://togetter.com/li/463570

java-ja.ddd の資料、ブログ記事などのまとめ
https://gist.github.com/yamashiro/5230921

はじめに

今回のjava-jaの告知から100人埋まるのがめっさ早かったのを昼休みの時に知りました。なので、150人まで拡張された時に急いで申し込みました。

開催までの期間の間に、エリック・エヴァンスのドメイン駆動設計を購入して読み始めてみました。
個人的に気になっていた箇所であるエンティティとレポジトリの部分を重点的に読んでみましたが、一旦コードにしないと身につかないのかなとも感じました。

第一部 ざっくり DDD 入門！！

ざっくり DDD 入門！！ from Yukei Wachi

今、自分が担当している業務が勤怠に関することなので、お客様の勤怠と共通な部分が多いのですが、やはり労使協定に関する部分は違ってくるのと、会社独自の文化によるコンテキストがあるので理解するまでにいろいろとお伺いしなければならない箇所があります。

自分の知識が足りないときに書いたコードがまさにファットなトランザクションスクリプトなので、制度が変わったり、仕様変更が生じた際にバグが発生しやすい状況でした。

ドメインエキスパートの話を自分に当てはめてみると、確かにある程度の範囲までは自分でカバーできるけど、全体のシステムを見渡して判断できるような人物がいるのかと云われると厳しい側面があります。お客様の担当も部署が変わったり配置転換があったりするので精通している人が居続けるのはやはり難しいと思います。そういう場合はやはり開発側がもっと知識を得てドメインエキスパートにならなければならないのかなと思いました。

http://domainlanguage.com/ddd/whirlpool/
Whirlpoolは全く知らなかったので、取り入れてみたいと思いました。
モデルに対する理解もまだ足りないので、本とコードを見比べながらループを回したいと思います。

プログラミングは名前探し

リッチなドメインモデル　名前探し from 増田 亨

オブジェクト設計エクササイズ に参加してきましたの内容の中でも出てきた「良い名前をつける」ということにおいて公演されてました。
講演中の参加者の反応が大きかったのが印象的でした。
専用部品を作っていくことでその部品が導いてくれるというのは、現在でも実感してる最中です。

もう少し進めてテストのコードを業務の言葉で書ける様に出来ていければ、テスト自体が業務のシナリオとして使えるのではないかなと感じました。

おわりに

LT(=Long Talk)のお二人のお話も興味深いもので、特に腐敗防止層については本にも載っていたので、読み進めてみようと思います。
Magic Beansパターンは、RailsのActiveRecord特有だと思っていましたが、今のプロジェクトにも似たような状況の箇所があったと思うので、腐敗防止層と合わせて対応して見たいと思います。

今回のjava-jaも前回LOG.debug("nice catch!") に参加してきました #java_jaに引けをとらないくらい非常に楽しいかつ勉強になった回でした。

次回のjava-jaはJOJO回らしいので、楽しみです。
java-jaの皆様、講師の和智さん、増田さん、会場を提供してくださったGREE様ありがとうございました。

GREE パネェっす

TDD Boot Camp Tokyo 2013-03 に参加してきました #tddbc

TDD Boot Camp Tokyo 2013-03
http://tddbc.doorkeeper.jp/events/2904

2013/03/16 TDD Boot Camp Tokyo 2013-03 #tddbc
http://togetter.com/li/473108

はじめに

今回は、JavaかGroovyのTAが出来ればと思っていたのですが、Groovyの希望者がいなかったためJavaのTAとして参加しました。
始まる前に開催予定である長岡の@masaru_b_clさんと福岡の@Spring_MTさんを囲んだランチミーティングにて、TDDBC横浜での経験を伝えました。
いちスタッフとして参加した程度の経験なので、主催者にとって役に立つのかは分かりませんが、スタッフがこういう風に動いてましたよといったような内容であれば参考にしてもらえるのではないかと思い、話しました。

@t_wadaさんのTDDでの講演は、初回での横浜以来なのでTDDをこれから始める自分を振り返ってみて、「今の状態はどうなのか？」「最初に感じたあの感動を忘れていないか」と自問自答しながら聴いていました。

TDD・ペアプロのデモ

ペアプロワークショップ from yattom

TDDのデモということで、@yattomさんとFizzBuzzをお題にペアプロをやりました。
打ち合わせでは最低限程度の共有しか出来てなかったので、ほぼぶっつけ本番かつペアプロ自体TDD in Action以来久しぶりだったのですが、プロトコルがあったおかげでなんとか出来ました。
個人的にペアプロのいいところは、自分が考えていること相手に説明することで、考えを整理出来たり、相手がどういう思考でそういう考えに至ったのかを知ることが出来るところだと思っています。

TODOリストについてですが、紙でも電子媒体でもペアが合意すればどちらでもいいと思います。
ただし、どちらともどこまで進んだのか、やらないこと、未確定なことなど、その都度メモを残すことを忘れないことが大切だと思います。
あと、運営側の振り返りでも出て来ましたが、全て書きだしてから始めるのは、完璧な設計に陥る兆候だと思います。
個人的にはアジャイルのプラクティスを参考に、タスクの優先順位づけをして最も重要なものが終わった時に、改めてやるべきことや見落としてることなどを洗い出して、また優先順位を付けて続けるのがいいのではないかなと思います。

Boot Camp

JavaのTAでしたが、ペアの振り分けの結果、Mac、JISキーボード、IntelliJ IDEAでペアを組めるのが私しかいなかったため、急遽ペアを組むことになりました。

私達のペアは、話し合った結果dumpの実装から始めました。
dumpを選んだ理由は、他のgetとsetは、中身の確認を行う必要があるので、確認する手段としてdumpを先に実装してから確認しながら行えばいいのではないかと考えたからでした。

個人的には、TDDBCではお題をこなすことに意識してしまいがちで、リファクタリングをどのタイミングで行うのがいいのか掴む機会が少ないと感じていました。
今回のような文字列をフォーマットして出力するという処理には必ずリファクタリングができるタイミングがあるので、あえてdumpを選びました。

dumpから進むためには、内部で値を保持する状態を「setup」で作る必要があるので、コンストラクタに「setup」で生成した値をセットできるようにして、完了後に塞ぐという手段を取りました。こうすることで、リフレクションで内部アクセスしたり、アクロバティックな方法でテストする必要がなくなります。
また、テストを補助するためのメソッドも予めテストを書いてからパッケージプライベートで実装する手段も取りました。
ただしライブラリを作ったりする際はこういったアプローチが出来るのですが、レガシーコードなどを扱う場合はまた別のアプローチが必要になります。

TDDBCでは、参加者層によってはGitHubやBitbucketにアクセスしたことがないメンバーもいらっしゃるので共有される成果物が少ないです。
また、アクセス出来る人達もpushする際には歴史改変したり、最終成果のみpushするので途中経過を見ることが出来ないことが多いです。
今回のお題に似た内容で途中経過が分かるのが、ぺけまにありました。

TDD Live 番外編(TDD序破Q)
TDD 序破Qの世界へようこそ!

Groovy + Spockで書かれていますが、説明が補足されているので分かりやすいと思います。

DVCSに関しては、TDDBCで扱うには時間が足りないので扱われませんが、そちらはSCMBCや各DVCSのコミュニティでの勉強会がおすすめだと思いますので、ぜひTDDBCに参加された方でDVCSに興味を持たれたら探してみてはいかがでしょうか。

今回のTDDBCで印象に残ったのは２つです。
まずは、Javaのテーブルでは「JUnit実践入門 http://gihyo.jp/book/2012/978-4-7741-5377-3?ard=1363786051」があったことです。
事前に打ち合わせなくペアに一つは必ずある状態だったことは、TAとしてもありがたい状況でした。このおかげでコンテキストの共有が出来て、より深い内容の質問されたことでTAをやってて良かったと実感できました。
TDDBCに参加してみたいと思ったけど不安がある方は、「JUnit実践入門」を手にとってみてください。@irofさんがJUnitの依存性で章のカテゴライズをしてくださっているので、参考になると思います。

JUnit実践入門の感想とJUnit依存具合と読書会と #junitbook
http://d.hatena.ne.jp/irof/20121123/p1

次に、Scalaのペアの発表に出てきたSpecs2のhtml reportでした。
それに触発されて野良LTでGradle + Spockのアピールを即席でやりました。
話の内容としては、Javaの実装に対してGroovyやSpockでテスト書くといいよ的な話と、Gradle使えばレポートも綺麗ですよという感じです。

おわりに

今回のレポートもこちらにまとめられているので、TDDBCに参加したいけど東京は遠い、でも長岡や福岡なら近いと思われた方や次回参加してみたいと思われた方は、参考にしてみてはいかがでしょうか。

TDDBC Tokyo 2013-03 の参加レポートたち　#tddbc
http://matome.naver.jp/odai/2136365798061279801

主催してくださった@katzchangさん、講師の@t_wadaさん、TDDBCのスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社VOYAGE GROUP様ありがとうございました。

オブジェクト設計エクササイズ に参加してきました #lcfactory

オブジェクト設計エクササイズ
http://lcfactory.doorkeeper.jp/events/2719

2013/02/23 オブジェクト設計エクササイズ #lcfactory
http://togetter.com/li/467691

はじめに

以前に、「学び方を学ぶ 〜オブジェクト指向の設計と実装を学ぶ〜に参加してきました。 #devlove」で講師をされた増田さん(@masuda220)がオブジェクト指向設計についての勉強会をされるということでしたので、申し込みました。

エクササイズ

今回は、オブジェクト設計エクササイズということで、以下のルールについての説明がありました。

1. インデントは１つまで
2. else句は使わない
3. プリミティブとStringはラップする
4. 一行にドットはひとつ
5. 名前は省略しない
6. クラスは50行、パッケージは10個以内
7. インスタンス変数は２つまで
8. ファーストクラスコレクション
9. getter/setterを使わない

オブジェクトを小さくバラバラにする理由は、隣同士の繋がりだけに落としこむことで全体を知らなくてもうまく動かせるようにするためということです。
こうすることでテストを行う際もモックで置き換えることが出来るので対象範囲を狭くすることが出来るのではないかなと感じました。

小さくするということで重要になってくるのは、オブジェクトにどのように名前をつければ、バラバラになっても分かりやすくなるのかということだと思います。
そのためには、省略せず対象分野の言葉を使うのが一番です。
英語で名前をつけるのが殆どなのですが、辞書を引いたままの言葉よりも同じ分野のオンラインマニュアルを探してそれに見合った単語をつけるのがいいというのは、知らなかったので自分の対象分野のオンラインマニュアルを探してみたいと思います。

オブジェクトに名前をつけることで、そのオブジェクトがどういう振る舞いをするのかが見えてきます。
「契約による設計」という言葉が出てきたのですが、これは以前参加した「LOG.debug("nice catch!") に参加してきました #java_ja」の@t_wadaさんの資料にも出て来ました。

例外設計における大罪 from Takuto Wada

オブジェクト指向設計を適用させることでif文のネストを減らすことが出来るようになります。そうすることで、仕様変更にも対応する場合でもネストを深くするのではなく、オブジェクトだけに注力出来るので、既存のテストへの影響範囲も視覚的にわかるのではないかと思います。

クラスをラップしておくことの利点は、オブジェクトをimmutableであることを明示できることだと思います。
コレクションクラスは、java.util.Collectionsでunmodifiableにすることもできますが、例外を使うよりラップしてput、add出来ないようにするほうが分かりやすいと思います。
その他にもMapのようなクラスを使う場合では、予めオブジェクトにNullObjectパターンを適用させておくことで、nullチェックを減らすことが出来ます。
例えば、java.util.Mapをそのまま使ってしまうと、自由に値を操作されてしまう可能性を残しているので、それに対する防御的プログラミングをしなければなりません。また、キーを元に値を取得する際に、NullチェックをそのMapを利用している箇所全てで行わなければなりません。
それは、変更があった場合全ての箇所で適用させなければならないので、必ず漏れ、ミスタイプ等が発生します。
こういったミスを予め減らすことが出来るのであれば、ぜひやるべきでは無いかなと感じました。

カプセル化でよく言われるgetter/setterについても、フレームワークなら使ってもいいけど、人間が使うのを避けるために@Deprecatedにするといった、使わないところをきちんと明確にすることで減らすことが出来るというのを知りました。

最後に、行数を制限することでコードの不吉な匂いを嗅ぎ分ける訓練が出来るようになると感じました。
ネストが深くなったり、setterをひたすら書いていたりなど、行数を稼ぐ何かしらのコードが出てくることは、何か間違っている傾向が見られるということです。

これらをいきなり現在のプロジェクトに適応させていくのは、かなり困難な道を歩んでいくと思われます。
ですが、まずこのエクササイズを行えるようなプロジェクトでまず試して、チーム全員が慣れてから挑むのがいいのではないかなと思います。

おわりに

電脳書房さんで、ThoughtWorksアンソロジーが出品されていたので、早速購入してみました。

電脳書房さんでポチッたThoughtWorksアンソロジー届いた。初版とは思えないくらいきれい。 instagr.am/p/W8NvGVP8p8/
— とーますさん (@grimrose) 2013年3月17日

今のところおすすめされた本を一つづつ消化しています。
全てを読んで振り返った時にまた新しい気づきが生まれるのではないかと思うと、楽しみです。

今後のことを考えた時にふと感じたのは、以下のようなことです。

Java8から導入されるlambdaだとメソッドチェーンでcollection操作出来るんだけど、ドット一つの制限だとキツイような気がする。 #lcfactory
— とーますさん (@grimrose) 2013年2月23日

Java8を現場レベルで使えるのはいつになるか分かりませんが、オブジェクト設計エクササイズも変わっていくのかなと思いました。

増田さん、主催のLearning Community Factoryの方々、会場を提供してくださった楽天様ありがとうございました。
次回が開催されることを楽しみにしております。

アジャイルサムライ読書会 横浜道場 「イテレーションの運営：実現させる」に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「イテレーションの運営：実現させる」
http://yokohama-dojo.doorkeeper.jp/events/2911

アジャイルサムライ読書会　横浜道場「イテレーションの運営」
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinyokohama20130305

はじめに

今回から「第IV部 アジャイルなプロジェクト運営」に入りました。
これまで建てていた計画を実際に運営してくためには、どうすればよいのかを学んでいきます。
通常回の「第9章 イテレーションの運営：実現させる」でした。
特別編や番外編のおかげか、通常回にも新しい人がいらっしゃいました。

ディスカッション

今回のディスカッションで一番印象に残っていたのは、「技術的な検証や調査を行う際にポイントを割り振って行う」ということでした。
新しい技術を調査する際に、例えば3ポイント割り振って実施して振り返りを行うことで、次のイテレーションにつなげるのか、それとも採用せず既存のものを流用するのかなどチームで検証が出来るということでした。
期限を区切らずに一人に割り当てて専任にしてしまうと、終わらなかったり、共有できなかったりしてしまうので良くないということが、あると思います。

また、設計のために必要な分だけ分析するというのが一番話されていました。
どこまでやればいいのかというのが分からず、やり過ぎると後々のイテレーションに影響が出てしまうという弊害も起こるので、さじ加減を習得するのは難しいのではないかと感じました。

おわりに

今回の章は、実際に運営した経験がある人でないと気付けないような箇所も見受けられたので、雲をつかむような感触がありました。
次回以降も運営に関することがあるので、疑問に思ったことはいろいろ聞いてみたいと思います。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。

次回もまたよろしくお願いします。

アジャイルサムライ 横浜道場 番外編「自分の価値観を見える化してみよう」 に参加してきました #agilesamurai #横浜道場

横浜道場　番外編「自分の価値観を見える化してみよう」
http://yokohama-dojo.doorkeeper.jp/events/2591

2013/02/22 横浜道場　番外編「自分の価値観を見える化してみよう」 #agilesamurai #横浜道場
http://togetter.com/li/460726

はじめに

今回は、特別編ではなく「番外編」らしいです。
内容は@haradakiroさんが講師となって行うワークショップでした。

ワークショップ

始まる前の注意書きとしてR指定が出てきたので、血で血を洗う名状しがたい何かだと思ってましたが、そんな物騒なことはありませんでした。

まず、自分が4つの相対するカテゴリに分別されるとしたらどんなカテゴリになるのかというのを、アンケートの結果を元に導き出されました。
4つのカテゴリには、それぞれ色が決められており、それぞれ特徴となる考え方、思考があるそうです。
私のカテゴリは、緑色の「創造・想像」でした。
特徴としては、常に新しいものに取り組むのを好んだりするらしいです。
反対側のカテゴリは、赤色の「改善・管理」で官僚的で管理するのを好んだりするらしいです。

1回目のワークショップでは、同じ緑色の人たちをペアプロについて話し合いました。
2回目のワークショップでは、シャッフルして自分の正反対の色のロールを演じながら1回目と同じペアプロについて話し合いました。

正反対のロールを演じるのは、結構しんどい #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年2月22日

印象深かったのは、正反対のロールを演じるのは、ものすごいエネルギーが必要だということを実感したことでした。

正反対のロールの人達は、ムカツクけど、あなたがやりたくない仕事が得意な人たちです。 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年2月22日

ハンロンの剃刀という言葉があるそうで、反対側のカテゴリに属する人たちが言うことが気に食わない事もありますが、それは悪意を持っている場合は殆どなく、悪意があるように捉えてしまいがちだそうです。

あなたの目には色眼鏡がついています。それを認識して見ていることに気づくことが大事。 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年2月22日

予めそういうこともあるという認識を持つことでチームの多様性を維持することが出来るのではないかなと感じました。

おわりに

自分がどのような思考をしやすいのか、また反対側のカテゴリの人たちがどういう考え方を知ることで、お互いに上手くやっていく方法を見つけることが出来るのではないかなと思いました。

講師の@haradakiroさん、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまたよろしくお願いします。

『JUnit実践入門』写経・実践会 in 横浜 #4 に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #4 - DBTest Boot&Boost Camp? -
http://connpass.com/event/1694/

2013/03/03 『JUnit実践入門』写経・実践会 in 横浜 #4 #junitbook
http://togetter.com/li/463129

はじめに

前回の写経・実践会のレポートはこちら→ 『JUnit実践入門』写経・実践会 in 横浜 #3 に参加して来ました。 #junitbook

今回は、「第12章 データベースのテスト」が範囲でした。
主にH2Database + DBUnitの使い方を知る内容でした。

データベースのテスト

個人的には、DBUnitを使うのもいいのですが、Groovyでテストを書くとあまりDBUnitに依存しなくても出来てしまうので、Groovyをおすすめします。
DBと連携したテストを行う際に一番のネックとなるのはテストデータの準備だと思われます。
RDBMSであれば、xls、csvあたりが一般的だと思いますが、ORMを使うのがほとんどだと思われますのでそうなってくるとオブジェクトの構造を用意できるようなフォーマットのファイルが必要になってくると思います。
今回は、YAML形式のファイルを読み込んでDBUnitと似たようなことが出来ることをテーマとして取り組んでみました。

テストクラスはこのような感じ→こちら

SnakeYamlとGroovyは、相性がいいため記述量が少なく、さらにGroovyが用意するSQL周りのクラスと組み合わせることで、データの登録も簡単です。

この他にもDBのマイグレーションはどのようなツールを使ったら良いかや、Rails、RSpecのコードを見たりして学ぶことが出来たので、とても勉強になりました。

おわりに

JUnit実践入門に載っていることは、本当に入門なので、この先に待ち受けているDBとの連携周りのテストのような現実とどう向き合っていけばいいのかは、「レガシーコード改善ガイド」や「データベース・リファクタリング」といった本を片手に勉強していくことになると思います。

主催の@shinyaa31さん、参加者の皆様、横浜タネマキさんありがとうございました。
次回もよろしくお願いします。

アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　特別編「マシュマロ・チャレンジ」
http://yokohama-dojo.doorkeeper.jp/events/2592

アジャイルサムライ読書会　横浜道場　特別編「マシュマロ・チャレンジ」 #agilesamurai #横浜道場
http://togetter.com/li/459092

はじめに

今回の特別編は、「マシュマロ・チャレンジ」でした。
当日まで何の予備知識もなく臨んでみたいと思ったので、検索もせず楽しみにしていました。

マシュマロ・チャレンジ

実は、今回のチームは偶然にも前回のチームとほぼ同じメンバーでした。
1回目は作戦として設計とプロトタイプを作るのに専念した結果、下の写真のように土台を作るので手一杯でした。


他のチームの状況を見ると、無事マシュマロが乗っていたところもありました。
2回目に移る前には振り返りをしてどの部分を改善したら上手く乗せられるのか意見を出し合いました。
2回目が始まってから土台の作成効率が上がったのと、マシュマロを乗せるタイミングをギリギリまで粘った結果、無事立ちました。


マシュマロ・チャレンジの解説動画はこちら

CEOのチームにファシリテーターが居ることで、成績が良くなったというのが興味深かったと感じました。

同じようなプロジェクトが次回もあるのは、滅多に無い。 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年2月19日

本来、マシュマロ・チャレンジは一発勝負なので、私達が取った作戦は本来の主旨から外れたものでした。

チームビルディングとプロトタイプの重要性を知るいいワークショップだと思います。
材料も手に入りやすいものですし。
準備で重要なのは上に乗せるマシュマロは日本の小さいタイプではなく、バーベキューで焼くような大きいタイプを用意することだそうです。

おわりに

こういったワークショップも楽しめるので、横浜道場は面白いところだと思います。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまたよろしくお願いいたします。

SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 - に参加してきました #sqlap #devlove

SQLアンチパターン・レトロスペクティブ　- データベース危篤患者の救出 -
http://devlove.doorkeeper.jp/events/2775

SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 - #sqlap #devlove
http://togetter.com/li/462950

はじめに

先月に発売された「SQLアンチパターン」の監訳者お二人による勉強会が開かれるということで、参加してきました。

参加するまでの経緯としては以下の様な感じです。

まず、本自体は出た当初に購入してました。
その後にJUnit実践入門の読書会があり、急遽和田さんが参加されてその時にサインを頂くことが出来ました。

ラゾーナでラス1のSQLアンチパターン購入done. #sqlap
— とーますさん (@grimrose) 2013年1月27日

デブサミ2013でも講演をされていたのですが、その時は短いセッションだったので物足りない感じがしてました。

2013/02/15 デブサミ2013【15-B-5】SQLアンチパターン - 開発者を待ち受ける25の落とし穴 #devsumiB
http://togetter.com/li/451569

2/21には、監訳者お二人の刊行記念トークセッションがありましたが、都合がつかず参加することが出来ませんでした。

書籍『SQLアンチパターン』に関するつぶやきまとめ #sqlap
http://togetter.com/li/459889

アンチパターン

私個人が経験したアンチパターンは、以下の項目です。

• ジェイウォーク（信号無視）
• キーレスエントリ（外部キー嫌い）
• EAV（エンティティ・アトリビュート・バリュー）
• ポリモーフィック関連
• ファントムファイル
• フィア・オブ・ジ・アンノウン
• アンビギュアスグループ

この本では、よかれと思って裏目に出てしまうもの、それをアンチパターンとして呼ぶ #devsumiB #sqlap
— とーますさん (@grimrose) 2013年2月15日

遭遇した当時はベストだと思っていても、後からその代償を払うことになってしまい、いろいろと大変でした。

SQLやDBは言語によらず利用している人が多いためか、SQLアンチパターンに挙げられている事例を経験された方が多かったみたいです。

個人的に26番目のアンチパターンとして挙げるとしたら、コンソールからテストされていないDDL・DMLを実行してしまう行為です。
いい名前が思いつかなかったので、仮に「グレネード・キッカー」とでもしておきます。

おわりに

この本は、過去に行った罪を懺悔し、悔い改めることで現実と折り合いをつける方法を学ぶことが出来るという点で、救いがあるのではないかと思います。
よく聞く「若いうちの苦労は買ってでもしろ」は、先人の失敗や経験はこういった本を買うことで学ぶことが出来るのだから、同じ苦労をなぞるのではなく、その先の未知の領域で苦労をしたほうが良いということでは無いかなと思いました。

終了後、監訳者のもう一人である和田省二さんからサインを頂くことが出来ました。

エンティティを設計したり、仕様変更がテーブルに及ぶときに、この本を片手にどのように対処すればよいのか考えて、バランスのとれた最善の対処が出来るようになりたいと思います。

主催者であるDevLOVEのスタッフの皆様、監訳者お二方、参加者の皆様、会場を提供して下さった株式会社インターネットイニシアティブ様、ありがとうございました。