アジャイルサムライ読書会 横浜道場 「テスト駆動開発」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「テスト駆動開発」
http://yokohama-dojo.doorkeeper.jp/events/4834

テスト駆動開発

今回は、テスト駆動開発ということでグリーンバンドを左手にして参加してきました。



アジャイルサムライで語られているテスト駆動開発は、一部分でしか無いので、ここだけでは単にテスト書いてから始めればいいよねくらいの感覚しか無いように思ってしまいました。

テスト駆動開発を始めるためには、まず第12章のユニットテストでユニットテストを書ける様になって、第13章のリファクタリングをプロダクトコード、テストコードで出来るようになる必要があると思います。

テスト駆動開発をプロセスとして始める際に、ユニットテストとしての完了の定義を計画ミーティングで決めることが大切なのではないかと思いました。
完了の定義が明確であれば、ストーリーを満たす条件が明確であるため、それを満たすケースを一つづつテストコードに落としこむことが出来るのではないかと思います。

また、テストコードのレビューを行うことで、足りていなかったケースや他になにか気づいた点を共有できる機会が持てるので導入してみたいと思いました。

ユニットテストを書く経験を積んでいると、どういったプロダクトコードだとユニットテストを書くのにしんどい設計なのか身を持って分かる為、テスト駆動開発を行うことでユニットテストをしやすい設計と実装を身につけることが出来るのではないかと思います。

おわりに

アジャイルサムライも残すところ「継続的インテグレーション」のみとなりました。

また、10月にはTDDBC横浜も開催される予定です。

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

SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」 に参加してきました #sqlap

SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」
http://sqlap.doorkeeper.jp/events/4507

EAV

この回は、私が概要の説明をするお役目を承ったので、いろいろと調べてみてみました。





属性とその値を対象に関連付ける場合、その属性について詳しく調査出来るかがこのアンチパターンを解消する鍵なのではないかと思いました。
解決策もORMでサポートされているものも多く、カタログのように属性がバラバラであったりする場合はRDBMSでは難しいということも知りました。
また、最近ではNoSQLのような解決策も出てきており、どうしてもRDBMSでは難しい場合は選択肢として選べるようになったのは大きいと思いました。

おわりに

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

『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) #junitbook
http://connpass.com/event/2590/

2013/07/06 『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) #junitbook
http://togetter.com/li/529598

はじめに

今回は最終回ということで、書籍全体を通してのディスカッションとTDD/ペアプロ実践が内容でした。

最終回

ディスカッションでは、会社で行なっている新人研修でこの書籍を用いてやっているので、その内容についてと個人的な見解を話すことが出来ました。
主な内容については、Javaの研修が終わった新人に対してこの書籍を利用して、JUnitを利用してどうやってユニットテストを書いていけばよいのかを話しました。
この書籍にはサンプルが公開レポジトリに掲載されていますので、これを解答として行き着く手順をこの会で得られた経験も併せて説明しました。
実際にコードを書いてもらってmavenで動かしてみて確認しながら進めて行き方は、評判も良かったように感じました。

最終回ということで、これまでの参加レポートを列挙してみます。

• 
  『JUnit実践入門』写経・実践会 in 横浜 #1 に参加してきました。 #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #2 に参加してきました #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #3 に参加して来ました。 #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #4 に参加してきました #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #5 に参加してきました #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加してきました #junitbook
  
• 
  『JUnit実践入門』写経・実践会 in 横浜 #7 に参加してきました #junitbook
  

#1には@kyon_mmさんが、#3には@t_wadaさんが、#6には@irofさん、著者の@shuji_w6eさんがゲストとして参加してくださいました。

個人的に印象に残った回を挙げるとすれば、やはり#6の特別編を挙げたいと思います。
cucumberとseleniumを組み合わせることで、ここまで振る舞いをテストが出来るんだよというのが実際に手を動かすことで実感できました。
そのおかげでGebを用いてSpockで似たようなことが出来るようになりました。

おわりに

今回で、この写経・実践会も終わりとなりました。
この本が出た後の半年で自分自身多くのことを学ぶ事ができました。
それもこれもこの会があったおかげだと思います。
書籍は積読では何も身につかないので、こういった会に参加することで他の方が実践している経験や知見を学ぶことが出来る事を実感出来ました。
他にもまだ読んでいない本があるので読書会が開催されていたら、積極的に参加してみたいと思います。

#junitbook 去年末に始めた横浜編も、本日開催の第8回目を持って締めの最終回となりました。数多くの方々にご参加頂き、内容の濃い議論や実践等が行えたのではと思ってます。皆様ありがとうございました！
— しんや (@shinyaa31) July 6, 2013

主催の@shinyaa31さん、参加者の皆さん、会場の横浜タネマキさん、ありがとうございました。

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で連携できるサービスとして数少ない一つなので、ありがたいと思います。

SQLアンチパターン読書会 「続・IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会 「続・IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3968

はじめに

今回は、前回の「IDリクワイアド」が終わらなかったので、その続きを行いました。
始まる前に@osa2さんが下調べをして下さったLTのお陰で後のディスカッションであまりブレずに出来たのではないかと思いました。
ありがとうございます。

ディスカッション

IDリクワイアドのアンチパターンで重要なことは「キー戦略」であることだと感じました。
@osa2さんのスライドで使われていた、達人に学ぶDB設計 徹底指南書の「第8章　論理設計のグレーノウハウ」にて代理キーを使うのはグレーノウハウであるということが紹介されていました。

USINGやJOINの使い方では、自分が普通だと思ってたことが、実はオプティマイザが進化してて別にその書き方じゃなくても大丈夫だということを知りました。
特定のプロジェクトやレガシーコードにしか携わっておらず、新しいことに触れる機会が少なくなるのは、プログラマにとっては損失ではないかと思いました。

日本特有の悪しきウォータフォールが蔓延り、実装段階でテーブルを増やしたり減らしたりすることが出来ず、設計の機会があったとしても論理設計を経ずに物理設計から始めてしまうため、こういった傾向に陥りやすいのかなと感じました。

おわりに

この勉強会は副読本があるとより実践に近いディスカッションが出来るということが実感しました。
次回の、「キーレスエントリー」は、ページ数こそ少ないですが、一般的にありがちなパターンだと思われるので、これまで紹介された本を読んでみたいと思います。

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

SQLアンチパターン読書会 「IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会 「IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3774

はじめに

今回は、SQLアンチパターンでも言及の多かった「IDリクワイアド」でした。
個人的には、考えなしにIDつければいいやとなったことはなかったので、どのような状況になったら、このアンチパターンが発生するのかが知れたらいいなと思っていました。

ディスカッション

RDBMSに関しての様々なキーについてどのようなものがあるのかや、それぞれのキーをどのような場合に適用するのかを教えて頂きました。

また、このアンチパターンでありがちな場合は、某オフィススイートの表計算ソフトの考え方をそのまま適用してしまうためということでした。
個人的には、コードのサンプルなどでIDとしか振っていないテーブルを正しいと思い、テーブルにIDを必ず付けて使ってしまうのではないかと思いました。

画面から始めると、データの設計が蔑ろにされやすい。そのツケを長年支払うはめになる。 #sqlap
— とーますさん (@grimrose) 2013年5月9日

アプリケーションのコードよりDBのデータの方が寿命が長いので、気を配って設計しなければいけないということでした。
特に画面は変わりやすいのでそれを元に設計してしまうと、残念な意味での「継ぎ足された秘伝のソース」になってしまうのだなと学びました。

では、どんなモデリングをしたらよいか良いサンプルはなかということで、教えてもらったのがDatabase Answersです。

例えばTutorial on Beginning Data Modellingを見てみると、どのようにエンティティとリレーションが成り立っているのかが見えてきますし、Industry Data Modelsを見てみるとどこかで見たことがあるようなモデルがあります。
とても参考になるので、設計を始める前に似たようなモデルはないか探してみるのといいと思いました。

あと、IPAのデータベーススペシャリスト試験(DB)の午後2の試験についていろいろと勉強になるという話もあったので調べてみたいと思います。

おわりに

脱線は脱線でいろいろな話が聞けたのはよかったのですが、出来る限り内容に即したディスカッションが出来るといいのかなと思いました。

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

アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「現場の状況を目に見えるようにする」
http://yokohama-dojo.doorkeeper.jp/events/3455

はじめに

今回の通常回は、プロジェクトで使う「貼りもの」についてどのように運用したらよいかといった内容でした。

現在のプロジェクトは独りで行なっていますが、付箋を利用したストーリーボードを実施しています。
こうすることで、今日やるべきことと後どれくらいで終わるのかめどが立ちやすくなりました。

ディスカッション

壁に貼るものについて主にプロジェクトで使う言葉についてと、貼り物の真価についての内容が多かったように思えます。

特にプロジェクトで使う言葉については、間違えやすかったり、文字通りの意味を持たない場合など注意しなければならない言葉をピックアップして貼りだすのが良いのではないかなど、改善内容が多く出て来ました。

貼りものをすると顧客の目に触れる機会があると思うので、その場で分からなかったり新たに追加する内容等がすぐに反映出来るのが良い点ではないかなとも思いました。

おわりに

懇親会では、似た境遇の方に今までやってきたことなどを伝えることが出来たので、とても有意義な時間でした。

次回はの特別編は、新しい試みをするそうなので、楽しみです。

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

SQLアンチパターン読書会 「ナイーブツリー」 に参加してきました #sqlap

SQLアンチパターン読書会 「ナイーブツリー」
http://sqlap.doorkeeper.jp/events/3682

はじめに

前回のレポートはこちら→SQLアンチパターン読書会 「ジェイウォーク」 に参加してきました #sqlap
今回は、「ナイーブツリー」ということで自分自身経験した内容が話せればいいなと思い、参加いたしました。
ツリー構造に馴染み深い掲示板に関する事を自己紹介と併せて話しましたが、ニフティサーブから近年のSNSまで幅広く、世代というものを実感しました。

ディスカッション

アンチパターンを使っても良いとして上げられたCTE(共通テーブル式)が使えるDBであれば、シンプルでテーブルも少なくて済むということでした。
今回の解決策として上げられた3つのパターンについてですが、経路列挙モデルの場合、DBによっては型が用意されていたりして人間にも扱いやすいのですが、デメリットとして前回のジェイウォークに当てはまってしまうので、アプリケーション側で制約を守るようにしなければならないことです。
次に入れ子集合モデルでは、データの変更より参照が多い場合に使われることが多く、ORMによってはプラグイン等でサポートしているものもあるそうです。
デメリットとしては、ツリー構造の欠損等が発生した場合、人間で修正するのがとても難しいということです。
閉包テーブルモデルでは、入れ子集合と同様に変更より参照が多い場合に利用する場合が多く、2つテーブルを利用することがメリットでありデメリットでもあるということでした。
ツリー構造のスケールによってどのモデルを採用するかを検証し、コストに見合ったものを選ぶのが望ましいのではないかと思いました。

私の場合、組織階層を表現する方法として経路列挙モデルを採用しました。対象となる組織の階層も深くなく、横の広がりもそれほど大きいものでは無かったためです。
経路列挙のデメリットとしてはジェイウォークと同様にインデックスが使えないことです。ですが組織の数そのものが少ないため、デメリットがそれほど目立ちません。
もし今後階層がもっと深くなったり、横に広がるような場合は、残りのモデルやCTEを検討する必要が出てくるかもしれません。


今回のツリー構造をRDBMSでどのようにしたらよいのかについて、@t_wadaさんからJOE CELKO氏が書かれた本を紹介して頂きました。
1冊まるごとツリー構造について書かれた本らしいので、もう少し巨大なツリー構造に立ち向かう前に読んでみたいと思いました。

#sqlap プログラマのためのSQL 第4版 ジョー・セルコ amazon.co.jp/dp/4798128023/… @amazonjpさんから
— とーますさん (@grimrose) 2013年4月25日

同じくJOE CELKO氏が書かれた本として上記の本があるそうなので、こちらの本も取り寄せたいと思います。

#sqlap 監訳注SQLアタマアカデミー：第6回　SQLで木構造を扱う～入れ子区間モデル　（1）もしも無限の資源があったなら#gihyojp bit.ly/LI82s0
— とーますさん (@grimrose) 2013年4月25日

入れ子集合の監訳注にあった入れ子区間モデルは、ここが参考になると思います。

おわりに

次回の「IDリクワイアド」は、ORMとの関係でいろいろと物議を醸した章なので、楽しみです。

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

SQLアンチパターン読書会 「ジェイウォーク」 に参加してきました #sqlap

SQLアンチパターン読書会 「ジェイウォーク」
http://sqlap.doorkeeper.jp/events/3416

はじめに

SQLアンチパターンの読書会が開催されるとのことでしたので、申し込みました。
自分が経験していなかった話を聴いたり、逆に自分が経験したパターンについて他の人がどういう対処をしてきたのか知りたいと思ったのがきっかけです。

ジェイウォーク

読書会とは言うものの読んでくる前提でしたので、ディスカッションが主な内容でした。

ジェイウォークに陥る要因として上げられたのが、以下の通りでした。

• そもそも、交差テーブルを作るということを知らない。
• テーブルを追加するには、いろいろと手続きが必要。

一対多から多対多へ変更が生じた場合は、キーとなる属性同士で関連付けるので、ジェイウォークのようにしてしまうと、検索時にインデックスを利用しないため、遅くなりがちです。
なので、そういう匂いを感じたら、交差テーブルを導入するのが正しいということを知りました。

一対多が多対多になる可能性が予見されるのなら、交差テーブルを必ず使うこと。at ジェイウォーク #sqlap
— とーますさん (@grimrose) 2013年4月11日

解決策の交差テーブルを導入するのが望ましいのですが、既にジェイウォークになっていた場合は、どのように解決したら良いかという疑問については、@t_wadaさんがデータベース・リファクタリングの本を用いて解説したくださいました。
トリガーを用いて新しい交差テーブルへデータを同期して、アプリケーション側で経過措置を講じ、最終的に交差テーブルを利用するように変更するといった内容でした。
DB周りについて体系的に学習したことがなかったので、こういった対応が出来るということ自体知りませんでした。
また、交差テーブルについても、関連付けられた日付などキー以外の項目が必要になってきたりして単なる交差テーブルからエンティティへ変化してしまうこともあるので、テーブルを設計するのはやはり難しいと感じました。

おわりに

今以下のジェイウォークは、本の始めの方にあるので容易に感じてしまいそうですが、解決策の先がまだあり奥深いものだと実感しました。
また、@t_wadaさんにSQLに関して参考になる書籍を教えていただいたので、一つづつ取り寄せて見たいと思います。
次回は、ナイーブツリーということで、自分の経験した内容でもあるので、楽しみです。

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

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

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

2013/04/14 『JUnit実践入門』写経・実践会 in 横浜 #5 #junitbook
http://togetter.com/li/465948

はじめに

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

今回は、振舞駆動開発についての回でした。

外からみた振る舞いに着目して開発を進めるというのは、現状のプロジェクトと利用しているフレームワークを鑑みると難しいと感じています。
プロトタイプやモックアップを上手く利用して受け入れ条件に一致するものを作り上げていくのは、チーム、個人のスキルセットに依存していくのかなとも思いました。
受け入れ条件を顧客と話し合って決めていくのも丸投げが多い現状では難しく、開発者の視点が占めてしまって、本当に顧客が欲しかったものとはズレてしまいがちになってしまうのも当然なのかなと思います。

こういったプロセスを取って実際に開発されている方の話しを聞く機会があればいいなと思いました。

Spock! Spock!

実践では、Spockを初めて使われる方々のサポートをしていました。
皆さんIntelliJ IDEAを使っていらっしゃったので、Gradleのインストール、build.gradleのファイル作成からideaプロジェクトの生成までをしてもらって、始めて頂きました。
お題は、以前にも紹介した、@pocketberserkerさんの「TDD 序破Qの世界へようこそ!」です。
個人的には、Javaのプロダクトコードに対してSpockで書いていくには最適な教科書だと思います。

#junitbook TDD 序破Qの世界へようこそ! — tdd_jo_ha_q 2012.02.17 documentation pocketberserker.github.io/tdd_jo_ha_q/
— とーますさん (@grimrose) 2013年4月14日

写経が始まって手伝う機会が減ったので、自分もSpockを触っていました。

#junitbook 今日の成果。 grimrose / tddbc-tokyo-2013-03 — Bitbucket bitbucket.org/grimrose/tddbc…
— とーますさん (@grimrose) 2013年4月14日

今回は途中までやっていたLTSVのお題を2枚目までやってみました。

LTでも、Spockの発表にかこつけてGradleの布教活動してました。

おわりに

Jnarioすごい！ /Jnario写経・実践記録 1.はじめに(Jnarioフィーチャーの紹介) - Shinya’s Daily Report (id:absj31 / @shinyaa31) d.hatena.ne.jp/absj31/2013041…
— とーますさん (@grimrose) 2013年4月14日

今回印象に残ったのは、Jnarioでした。
簡単なシナリオを書いてみて体験してみたいと思います。

次回は、コードカバレッジと継続的テストということで、Gradleでjacocoを使う方法、drone.ioとGitHubまたはBitbucketを連携するのを紹介してみたいと思います。

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

アジャイルサムライ読書会 横浜道場 「アジャイルな意思疎通の作戦」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「アジャイルな意思疎通の作戦」
http://yokohama-dojo.doorkeeper.jp/events/3267

はじめに

今回は、久しぶりの通常回です。
イテレーションの運営に入ってきており、実践している方がチームにいらっしゃらない場合のことも考えていかないといけないのかなと思います。

ディスカッション

イテレーション計画ミーティングとストーリー計画ミーティングの違いについて疑問が始めの方に出て来ました。
それぞれのミーティングでやることが似ている部分があったりして、どのように違いを付けて行なっているのか気になったりしました。
その後の方に、チームの合意が取れれば一緒にやっているという話も出てきていたので、実践している方は分けているとしたらどう区別をつけているのか、一緒にやっている場合でもどのようにしてやっているのか疑問に思いました。
ミニ振り返りもあまり時間をかけずにするということがあったのですが、長くなりがちな振り返りをどのようにしたら短く出来るのかいい方法があれば、実践してみたいなと思います。

朝会の話についても、マンネリ化したり形骸化したりするパターンがあったりして、どのように改善していければいいのかといったこともまとめの発表で出て来ました。
今日一日に対するコミットメントを発表するだけでもその人の一日の目的がはっきりするので、完了したかどうか個人で見直せることが出来ればある程度目的に沿っているのではないかと感じました。
その習慣が良い結果をチームにもたらしているのであれば、続けるか続けないかはチームの合意が取れればいいですし、何も生み出さすただの時間潰しであれば、別のことに時間を割り当てるべきかなと思います。

おわりに

まとめの発表でタイムボックスがキッチリし始めたので、そろそろ古参の人たちが率先してまとめの発表の計画をしっかり立てていく段取りをしなければならないのかなと思いました。
次回はまた特別編ですが既に予約が一杯の模様です。

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

横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」 に参加してきました #agilesamurai #横浜道場

横浜道場　特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」
http://yokohama-dojo.doorkeeper.jp/events/2912

2013/03/19(#agilesamurai)横浜道場　特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」
http://togetter.com/li/474247

はじめに

今回は、告知された際にいろいろな箇所で話題になっていたおかげか、初めて横浜道場に参加された方が多かった気がします。

砲火後ティータイム

Domain-Specific Language、略してDSLは、特定の領域にのみ通じる言語ということで、今回は「まどか☆マギカ」を題材にした内容でした。
全話視聴済みの方がほとんどだったので、ドメインの共通知識は持っているということが確認できました。
私達のグループには全く知らない方がいらっしゃったので、キャラクターの概要やイメージから連想してもらったりしてもらいました。
個人的には、「杏子」派だったのですが、「ほむら」の生き様が開発者によく似ているというお話を聞いて、納得いくようなこともありました。

「build measure learn」すなわち 「ほむほむ」 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年3月19日

特に印象的だったのが、リーンスタートアップで有名な言葉も「ほむほむ」という単語で置き換えが出来るということでした。

同じドメインにいても考え方が違っていたり、見え方が違っていたというのも、興味深かったです。

おわりに

今回の開催のいきさつを聴いたり、懇親会での状況を見て、道場主巻き込み力の凄さを感じました。

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

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

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

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

おわりに

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

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

アジャイルサムライ読書会 横浜道場 「現場で実践する」に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「現場で実践する」
http://yokohama-dojo.doorkeeper.jp/events/2590

アジャイルサムライ読書会 横浜道場 「現場で実践する」 #横浜道場 #agilesamurai
http://togetter.com/li/450974

はじめに

遅くなりましたが、忘れないために書きます。

今回は、現場でいろいろとミスや失敗をしてしまいその為、遅刻して参加しました。

ディスカッション

バーンダウンチャートから見えてくる結果から、どのように計画の変更を行なっていくのかが主な内容でしたが、メンバーの増減でコストがかかる場合にあらかじめそれを見越して、ドキュメントなど後々使うのをまとめておくのは、やりたいけど優先順位下げがちだなと感じました。

自分の隣に壁があるので、ポストイットを使って自分の作業をカンバンで見える化している話をしてみました。
こういった話を出来るようになってきたのが、とりあえず一人でも出来るプラクティスをやってきた結果なのかなと思いました。
自分が実践してみて分からなかったり、疑問に思ったことを話し合える場が、外部にもあるというのは心強いです。

おわりに

togetterで見直しながら書いていますが、あとで振り返るために頑張ってtsudaって見ましたがまだまだ精進が必要だと感じました。

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

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

アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」 に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　特別編「ワールドカフェ再び」
http://yokohama-dojo.doorkeeper.jp/events/2148

2013/01/22 アジャイルサムライ読書会　横浜道場　特別編「ワールドカフェ再び」#agilesamurai #横浜道場
http://togetter.com/li/443871

はじめに

今年はじめてのアジャイルサムライ読書会に参加して来ました。

第一回目もワールドカフェだったのですが、それ以降何度か体験して面白かったので、このメンバーでやるとどうなるのか楽しみでした。

ディスカッション

ディスカッションのテーマはいろいろあったのですが、意見を出しやすいテーマを選んでみました。
選んだテーマは、「アジャイルのプラクティスで外せないものは何か」でした。
その結果は以下のような感じになりました。


それぞれで外せないものは、あるのですがいろいろと関連性が見えてくるのが興味深い内容でした。

次のテーブルでは、型を破るタイミングとどう破るのかについて話し合ってました。


チームのスキルセットによっては、型を形作るまでの過程が険しいのだと感じました。

おわりに

やはり横浜道場はホームなのだなと改めて思った。今年もよろしくお願いします。 #agilesamurai #横浜道場
— とーますさん (@grimrose) 2013年1月22日

今年は、ハッカソンを中心に手を動かすような勉強会に参加して行こうと思います。
聴講形式では、知った気になって何も身につかないのは、この一年で実感したので減らしてみます。

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

今年もよろしくお願いします。