SQLアンチパターン読書会 「キーレスエントリー」 に参加してきました #sqlap

SQLアンチパターン読書会 「キーレスエントリー」
http://sqlap.doorkeeper.jp/events/4356

はじめに

今回は、「キーレスエントリー」が対象でした。
これまで外部キーのないプロジェクトばかり参加しており「キーレスエントリー」のデメリットを丸々抱えていたので、どのようにしたら改善できるのかを知るきっかけになればいいなと思い、参加しました。

SQLアンチパターン読書会　4章　キーレスエンエントリ（外部キー嫌い） from makopi 23

今回のアジェンダは@makopi23さんが発表してくださいました。
ありがとうございました。

ディスカッション

外部キー制約を貼らない理由として上げられていた、テストデータについてはDB毎に実装されている機能を用いて制約を遅延することができます。

MySQLの場合

13.5.6.4. FOREIGN KEY 制約
http://dev.mysql.com/doc/refman/5.1/ja/innodb-foreign-key-constraints.html

PostgreSQLの場合

SET CONSTRAINTS
http://www.postgresql.jp/document/9.2/html/sql-set-constraints.html

既に外部キー制約が無い場合は、データクレンジングを行い、外部キー制約を貼るのが望ましいですが、コストとの兼ね合いがあるのでやるべきとは言えないというのが、現状ではないかと感じました。

外部キー制約を外すのは、ハイパフォーマンスを得るために已むを得ない場合や、シャーディングをする場合などで、単一のDBを扱うような場合は、初めから付けておくのが必須であるということでした。

DBのマイグレーションや、DDLの作成方法など、モデリングとDBの周辺のお話もいろいろと聞けて、勉強になりました。

おわりに

次回の「EAV(エンティティ・アトリビュート・バリュー)」では、アジェンダを担当することになりました。
「EAV」は、身近なアンチパターンでもあるので楽しみです。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

アジャイルサムライ読書会 横浜道場 「ユニットテスト:動くことがわかる」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「ユニットテスト:動くことがわかる」
http://yokohama-dojo.doorkeeper.jp/events/3963

ユニットテスト

危なっかしい場所？複雑度や静的解析を参考にする #agilesamurai #横浜道場
— とーます (@grimrose) June 11, 2013

テストコードをメインにレビューする。テストの仕様が合っているか見るため。規約等は静的解析ツールに任せる #agilesamurai #横浜道場
— とーます (@grimrose) June 11, 2013

静的解析ツールがOSSで出るようになったり、Jenkinsで実行できるようになったおかげで、どこに潜在的なバグが潜んでいるのかを継続的に見られるようになったと思います。

また、レビューの対象もプロダクトコードよりテストコードを重視することでテストケースの漏れ等を共有できる様になるということを知りました。
これもユニットテストが全てGreenであることが前提となっているからこそだと思います。

また、ユニットテストを自動実行出来る事によって、手動で行わなければならないテストにコストを費やすことが出来るので、自動化出来るテストは自動化するのが望ましいのではないかと思いました。

ユニットテストを積み上げていくことで、変更の影響範囲を可視化出来るので、今までのような不正確な見積もりよりマシな見積もりが出来ると思いました。

おわりに

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

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

『JUnit実践入門』写経・実践会 in 横浜 #7
http://connpass.com/event/2248/

2013/06/01 『JUnit実践入門』写経・実践会 in 横浜 #7 #junitbook
http://togetter.com/li/511975

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加してきました #junitbook

今回は、「第14章 コードカバレッジ -テスト網羅率の測定-」、「第15章 継続的テスト -すばやいフィードバックを手に入れる -」が対象ということで、主にカバレッジの負の側面とそれに対してどうしたら良いのかのディスカッションと、githubのようなレポジトリとtravis-ciのようなサービスと連携するハンズオンをやりました。

カバレッジについて

「カバレッジ100％」という呪いは、もしかしたら、開発側より品質管理やマネジメント層の方が、なまじダイレクトな数字が見えてしまうが故に重症なのではないかと思います。他の指標と組み合わせて、現在の状況を判断する材料なのに、「100％ = 正義」という目的と手段が摩り替わってしまっているプロジェクトは残念としか言えません。
カバレッジの元になっているテスト自体が間違っていたり、アサーションフリーの様に目的としているアサーションがなかったり、そもそも顧客が欲しいものが出来ていない時点で例えカバレッジ100％だったとしても、なんの意味もありません。
そういった内容が14.4に書かれていたので、このJUnit実践入門を他の人に勧めるのには、この第14章はいい材料になると思います。

travis-ci & Drone.io

@sue445さんによるGithubにあるリポジトリをTravis CI連携する手順 #junitbookのハンズオンを聞いた後、以前#tokyomercurialで教えていただいたdrone.ioを紹介しました。

drone.ioは、github以外にbitbucketが使えますし、設定も
Quickstartの手順に沿って設定するだけで使えるようになります。
特にdrone.ioは、mercurialで連携できるサービスとして数少ない一つなので、ありがたいと思います。