#tddbc 大阪2.0の企画・運営をしてきました

6月3日 TDD Boot Camp 大阪 2.0 #tddbc(大阪府)を企画・運営、およびTDDBC大阪1.0のお手伝いしてきました。私としては福岡,東京1.6,福岡2に続く4回目のTDDBC企画担当となります。
今回も色々なことがあったので、一つずつ振り返ってみます。

サブイベントからTDDBC大阪2.0へ

まずはじめに、TDDBC大阪*1のスタッフ募集時に手を挙げた際、「どうせ遠征するなら2日目もやりたいなー」という軽い気持ちでtddbc MLに「サブイベントを勝手にやりたい」的なことを書いた記憶があります。

その後サブイベントの会場手配や構成決めを行っていたのですが、時が流れていくうちにひとつの懸念事項を思い出します。参加希望者が殺到するという、TDDBC東京のような事態が発生するのではないかということ。初開催の大阪なら十分にありえることです。

サブイベントのままにするか、2.0にするかは本当に悩みました。GW前後に多くの方と相談しそれでも決められず、結局最終的には参加希望者の人数しだいで機械的に決めるという判断におちつきました。

スタッフ

今回も多くの方にスタッフとして参加していただきました。

本イベントは楽天株式会社様のカフェテリアをお借りしました。そして、@さんをはじめとする会場スタッフの方々に多くのことを手伝って頂きました。素晴らしい会場を提供していただき、また、イベントに関する様々なことに配慮していただきありがとうございました。

講演していただいた@さん、@さん、@さん。前日のTDDBC大阪1.0で話した内容をもう一度話してほしいという、割と無茶な注文を承諾してくださいました。また、運営に関するアドバイスもたくさんいただきました。ありがとうございました。

@さん、@さん、@さん、@さん、@さん、@さん、@さん、@さん、@さん、@さん、@さん、@さんには、ワークショップでのTAと運営のお手伝いをしていただきました。ありがとうございました。

今までと異なる部分

TDDBCが同じ内容で2日間連続開催されるのは、実はこれが初めてです。そこで、1.0ででた問題点の中から2.0では解決できそうなものは解決しようという話になりました。
ちょっと申し訳なく思ってしまったのが、スタッフの方々には食事や懇親会もそこそこにミーティングに参加してもらったことです。1時間弱ミーティングしていたらしいので、追加されたピザは少しくらい残しておいてもらうべきでした。

この改善案などはわりと手ごたえありだったので、今後のTDDBCに活かせると思います。

また、今回は演習中のタイムキープを私が担当し、ドライバーとナビゲーターの交代を10分ごとに呼びかけるという形式をとりました。ですがこれ、かなり時間を気にしないといけないので演習風景を見る余裕がなくなります。つまり、全体を見て周りたいという主催者が担当するには不向きな役割です*2。また、TAも手が空いていないことを考えると、タイムキーパー要員が別に必要になりそうです。まぁ、問題はタイムキーパーはイベントに参加できなくなることなのですが・・・何かいい案ないですかねぇ。

なお、大変参考になるイベント運営のアドバイスをいただいたのでペタリ。

イベント運営ノウハウまとめ - Togetterまとめ

やれなかったこと

やりたくてできなかったことがいくつかあったので、記録として残しておきます。

TAの方々に「パートナー入れ替えは各言語で任意に」と連絡しておきましたが、おそらく入れ替わったペアはいないかと思われます。まぁ、イベント時間の問題もあるのでこれは仕方がないかなと思わなくもないです。

  • 言語を混ぜて机上レビュー

これはやろうと思っていたのですが、席をどう入れ替えるかシミュレートできていなかったため採用されませんでした、残念。ただ、いくつかの言語はペア数が少ないためこの形式でレビューを行い、わりと満足できたらしいので可能性はまだ残されているようです。

なお、サブイベントとしていくつか(ソフトウェアテスト、VOTDD、DVCSとか)やりたいことがあったことを一応メモしておきます。

t-wada賞

なぜあの書籍を選んだのか、という話。
今回はTwitter上で募集してみた中から選んでみました。

  • テスト駆動JavaScript・・・@さんおすすめ
  • Clean Code・・・kyon_mmさんおすすめ

あとdRuby Bookはm_sekiさんがいらっしゃるからで、Ultimate Agile Storiesはyasuohosotaniさんのご厚意です。

少しだけ思うことがあるとしたら

ソフトウェアテストも学ぶといいと思います。

宣伝

TDD in Actionという、TDDペアプロライブコーディング(仮)イベントを7/22に東京で開催します。6月中に募集を開始するので皆さん参加してね!

あとTDDBC for FPという話がチラッとでたので、誰か10月以降に東京で一緒にやりませんか?

おわりに

参加者、スタッフ、講演者の皆様、お疲れ様でした。そしてありがとうございました。
またどこかでお会いしましょう!

*1:当時は1.0のナンバリングもなかった

*2:私は別にいいやと割り切っていたので無問題

「実用期を迎えた関数プログラミング」懇親会での会話忘却録

実用期を迎えた関数プログラミング : ATND

「実用期を迎えた関数プログラミング」というイベントが福岡で開催されたので参加してきたのですが、その懇親会で山本さんと小笠原さんとお話することができたので会話したことをメモしておきます。
かなりうろ覚えでの記述なので、間違っていたら指摘お願いします。

テストの話

  • Q. Haskell Day 2012の資料拝見したのですが、Haskellって実際どの程度テスト書かれているのか?
    • (名前失念)に登録されているもの23個のうち8個くらい
    • カバレッジは調べてないからわからないけど若干低めではあるかも?
    • 動的型付けでのテストの何割かはHaskellではいらない
      • 「hogehogeにタグが含まれていることのテストとか書いてあるけどHaskellだったら型で検査できるじゃん」
    • Haskell後方互換性のないライブラリが多い
      • 型チェックでエラーがでるのでどこを修正すればいいのかはわかる
      • テストは重い(表現失念)から書かれないのかも
  • 純粋な関数と副作用を含む関数を合成することでプログラムを組み立てる
    • 純粋な関数の性質はわかる(訓練すればわかるようになる)
    • 性質がわかっているならQuickCheckで性質書いてランダムテストできるよね
  • 副作用を含む関数は性質というよりシナリオ
    • シナリオにはランダム性は含まれない
    • こういうのはHSpecとかでテスト書こう
  • 型に関する間違いはなくても値に関する間違いはある可能性があるのでQuickCheckでチェック
  • (MVVMの)VMは独立にテストできる(だったかな?)
    • RxとFRP
      • データを差し替えることでイベント駆動型のテストもやりやすくなるのでは
  • exampleとpropertyを使い分ければいいと思うよ
    • 具体値でテストをどんどん書き、性質がわかった時点でpropertyに差し替える
    • 性質がわかっているものはpropertyでいきなり書く
  • QuickCHeckのようなものが浸透するかどうかは各言語コミュミティの雰囲気次第?
  • SmallCheckというのもある

先に書くか、後から書くか

  • Q. シグネチャを先に書く場合と後に書く場合とあると思いますが…
    • 基本は後から書くほうが多い
    • Type Driven Designする場合は先に書く
    • 型はモデル図
  • 割と複雑な関数は先に型を書いておく
    • 道をはずれかけたとき、型が間違いを教えてくれる
    • 型が実装を導いてくれる
  • 公開しない関数はシグネチャ書かずに型推論に任せる
  • OCamlシグネチャファイル分離しないといけないよね
  • シグネチャを先に書いたときはTDDしづらい
    • 駆動できていない感?
    • アルゴリズム系のテストも似たような感じがする
    • シグネチャを先に書いた場合はREPLを使いながら実装していくといいよ
      • REPLは履歴残らないが、でもその場で確認したのだから安心感は得られる
  • 関数型言語での開発はREPLよく使う
    • REPLでの実行結果を利用例としてdocに張り付けたりとかも

OCamlぽい話とか

  • フロントエンドとは切り離されていたりするバックエンド部分などはOcamlでいい場合も多い
    • そんな言うほど導入ハードル高いかなぁ(プロダクト的な意味で)
    • Ocamlは知名度の問題もあるかも
  • Q. チーム開発する際、どの程度の習熟度なら関数型言語を導入できると思う?
    • 値を示せるわけではないから難しい質問
    • 高階関数やOptionを使いこなせる必要はあるかも
    • でも実践だと、Optionだけではエラーでの情報量が足りないので、例えばOCamlの場合だとError型も必要になってくることも
  • Q. Windowsプラットフォーム対象のときにOCamlは?
    • OCaml標準で収まる範囲ならまぁありなのでは。テキスト処理とか。
  • oasisの話
  • Ocaml 4.0:replのcwoロードの依存関係の解消、GADTS
  • Js_of_OCaml
    • OCamljsは開発が止まっている(でもオブジェクトはこちらのほうがよかった)
  • TaPLの話とか
  • λ計算 → η-変換
  • Relaxed value restriction
  • OCamlerはみんな何かしら自作ライブラリをもっている
  • 他の言語を使っているときに(言語によっては使えない場合)Continuous Monadが使いたくて心が痛むときがある
  • Lazy.t.list
  • F#のType Provider
  • Haskell,OCaml,Scala,F#…独自の進化を始めている機能もある。だけど根底にあるものは似ているので、1つの言語を使えるようになれば、後は慣れの問題(文法学んで3日ほど書き続ければ慣れる)。

本編の感想は後日改めて書きますが、懇親会で聞いたお話もかなり勉強になりました。ありがとうございました。

なごやの #CDStudy と #scmbc に参加した、ような…

4/21〜4/22にかけて、なごや遠征に行ってきました。

4月21日 継続的デリバリー読書会(愛知県)
4月22日 SCMBootCamp in Nagoya 1 #scmbc(愛知県)

行く前の予習編

うさみみさんに「読書会前に対象書籍と関連書籍を読み終わっていないとか(ry」と言われそうだなーと妄想したので、遠征前に下記書籍を1回は読んだような。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

あと関係ないけど少し目は通してみたやつとか。

Jenkins

Jenkins

継続的デリバリー読書会当日

継続的デリバリー読書会に参加してきました #CDstudy - secretbase.log

同じテーブルの@さんのエントリに全部書いてあったので割愛。

CDStudy & TaPLnagoya合同懇親会

なごやかな方々と合流して懇親会。
私はご飯食べたりなんとかろふさんと空中戦を眺めたりぐるぐるさんにPCを貸してF#布教を手伝ったりしてました。
あと、ぐるぐるさんにProgramming F# 3.0 early release版いいよーと宣伝されたので翌日購入しました。迷ってたのですが、実物を見ると欲に負けますね。

SCMBootCamp Nagoya当日

一時カエルに身体を乗っ取られていたため本編の記憶が…なので、詳しい中身は参考として他の方の記事を張り付けておきます。

SCMBootCamp in Nagoya 1 に参加してきた #scmbc - Shinya’s Daily Report

ああ、意識が戻った時にはPCにDarcsがインストールされていました。あとPatch Theoryのページが開かれていましたね、なぜか。

scmbc懇親会

ピザまでのつなぎとして闇LT「なごやは人生をかえるか」をやってきました。多くは語りませんが、少なくとも私自信は人生変わった気がするし良い変わり方だった、と言っておきます。
懇親会は途中までしかいられなかったのですが、Darcsの話やSML#の話が聞けたりしてとても勉強になりました。色々な方ともおしゃべりもできて楽しかったです。

反省点

  • たぶん「誰こいつ」って思われていた
  • たぶん「なんでここにいるの」って思われていた
  • ちょーしにのってました
  • ぺんぎんよ、たまには中身で勝負しようや…

なにはともあれ

お疲れ様でした。楽しかったです。ありがとうございました。

後日談

読書会やブートキャンプ中に話題にあがったSML#をPCにインストールしました。
多相性の話などはわりと興味あるのでぼちぼち勉強します。

XP一日体験ワークショップに参加+α

XP1日体験ワークショップなるものに参加してきました。
で、どういうことがあったかとかそのあたりの感想はきっと誰かが書いてくれるはずなので、簡単に感想を書いておきます。

  • devstは2回目だが、この勉強会はいつも面白い試みをしているなと感じる
  • 決まった運営というものがないので仕方がないのかもしれないが、も少しテンポよくできればいいかも?
  • お絵描きがかなり苦手な私としましては、ペアドローはかなりきついですね…
  • 直接は関係ないが、この手の勉強会で言語を"Javaに"固定するのは厳しいのかなと再認識
  • コミットしたらWebページでテスト結果が見られるのは面白かった
  • XPの内容をいくつかまとめてやろうとするには、今回はちょっと時間がたりなかった感がある(CIははずしたほうがよかったのでは)
  • ペアの方にEclipseのQuick JUnit Plugin、git-nowあたりをおすすめしてみた
  • この手のイベントはサポーターいりますね、と再認識
  • Mavenェ…Eclipseェ…
続きを読む

Nagoya.Testingに参加 #NagoyaTesting

行きたいけど時期的に無理かなと思っていたのですが、諸事情により時間に余裕ができたので参加することにしました。
今の自分に足りないものが見つかると思ったのも理由の一つです。

前夜祭?

「誰か晩御飯ご一緒しませんか?」とつぶやいたところ、TEF東海のKENさんときょんさんとご一緒できることに。
Nagoya.Testingスタッフと会話できるこの喜び…でもきょんさん、準備大丈夫かなとも思った夜でした。

始まるまで

最近増殖中の@irofさん、TEF東海のまさおさん、きょんさんと合流して会場へ。ちなみに、irofさんに「遠いところからわざわざ…」と言ったら反論された。それもそうか。


会場入りしてからは「名札作るの手伝って(シールを貼る)」と頼まれたので、シールを貼りながら受付のお手伝い(?)をしていました。某"雪"ウサギさんに「あれ?なんでいるの?」みたいなことを聞かれましたが、ぺんぎんが色々な地域に出没するのはきっとよくあることですよ?

午前

TDDや形式手法の話ばかりでした。
私もLTをさせていただきましたが、あれの要点は「最終的に実践あるのみ」「とりあえず皆TDDはやれるようになっておこうぜ」「って色んな人が言ってるよ」ということです。


「座席表誰かお願いします!」とつぶやいたら@orange_cloverさんが作ってくださいました。ありがとうございます!

お昼

初めて味噌煮込みうどんを食べました、うどんかためなのね。
食事中の@mzpさんと@kumagiさんによるpersistentなお話が面白かったです。

BlackBox、WhiteBox、網羅的、ピンポイントの4象限

午後最初のハンズオン。
知っている(やったことのある)テストは4象限のどこに位置するか、を書き出すハンズオン。
なんというか、なかなか思いつきませんね。特に技法以外のネタをなかなか書き出せなかったです。
普段使うものって三角測量、同値分割、境界値分析、デシジョンテーブル、状態遷移、原因結果グラフ、ランラムテスト、CFDかなぁ。TODOリストはこの分類にいれていいのかわからないとか、カバレッジは…まぁいいや。
平行系に関するテストの話が聞けたのは個人的に収穫でした。とても勉強になります。


一個疑問に思ったのは、これを次のハンズオンにどうつなげればいいのかな、ということでした。まぁ、私がハンズオンの目的を聞き逃していただけかもしれませんが…。

戦略、分析、設計、実装

テスト戦略、テスト分析、テスト設計、テスト実装を実際にやってみようというハンズオン。
状況は以下のような形が想定されていました。

  • デプロイされたHerokuアプリのテスト
  • 18:00までにリリースしたい

渡されたもの

function list

状態

なんともいえない状況ですね。

テスト戦略

私のいたグループの方向性としては

  • 少しでも早く深刻な順にバグを発見したい
  • 簡単かつ重大なバグを見つけられるテストを優先してスケジュール
  • テストデータ作成など、同時に作業しても問題ない部分はメンバーが並行して作業する

という形でいきましょう、ということに。

テスト分析、テスト設計

どういった事柄に着目しましょうか、という話を相談しながら以下の順に決めました。

  1. ページが開けるか
  2. 機能系
  3. セキュリティ
  4. 平行テスト(同時に登録・削除などした時の挙動)
  5. 時間があれば他のテスト
テスト実装

きょんさんに指摘されて気づいたのが、正常系異常系の同値や境界値の具体的データを仕様書に残していなかったことです。脳内完結させてしまっていたのはまずかったですね、反省。
あと、事前条件に書かれている項目が一部依存条件だったという指摘もありました。このあたりは素直に遷移図に切り替えたほうがよかったかなーとこちらも反省。

依存 テスト 期待する結果
トップページでステータス200が返ってくる wgetでクローリング エンドポイントのすべてのURLが200で返る
ブラウザにページが表示される キーデザイン操作 ブラウザで各キー操作に応じた結果が表示される
各ページが正常に表示される 入力データの検証 正常値は登録、異常値はエラー
データ登録が可能 10000件のランダムなデータを突っ込む 正常に登録される or 異常値ではじかれる
アプリからデータベースにアクセス可 SQLインジェクションの確認 エスケープされること
POSTがとおる CSRF エラーページ
入力系操作が単体で正常に動作する 削除→完了と編集→完了を同時実行 指定の挙動を満たす
入力系操作が単体で正常に動作する 削除→完了と削除→完了を同時実行 指定の挙動を満たす

確かに、改めて見ると具体値を書かなさすぎでテスト仕様書とはとてもいえないですね。時間的制約に焦った影響もあるかもですが、練習だと割り切ってゆっくり作るべきでした…。あと、上の表は思い出しつつなので少し間違っているかも。

実際にテスト

kumagiさんにかなり頼ってしまいました。
"WireSharkでパケット覗いて、Rubycurlで1万件突っ込む/削除するスクリプト作成"をサクッとやってしまうあたりがすごい。


私はこのあたりから体力の限界でほとんど動けていませんでした…orz

振り返りとか

少しはグループのお役に立てたのかな、など少し不安が残りましたが、不安があるってことは次回までに改善せよってことですよね。改善していく所存です。

懇親会でこんな話をした(された)、ような

  • 「組み込み系で同じようなハンズオンやりたいよね」という話になったときに、なぜか「KINECTを使ったテストのハンズオンとか面白そうだなー」とか思っていたら、いつの間にか口走っていた。
  • AlloyやろうAlloy
  • OCamlやろうOCaml
  • TDDBC大阪を侵r…おっと誰かきたようだ

個人KPT

Keep

  • テストに関する勉強

Problem

  • 実践不足
  • 体力切れ

Try

テストの勉強会にいったの?みたいなTryになっているけど気にしない。

感想?

  • この手のグループワークで学生が多目のメンバー構成だとつらい(普段一人で作って一人でテストな状況の学生が多いと特に)
  • 誰かの手が止まるとつらい(私も人のこと言えないけど…)
  • 何をすればいいのかわからない人もいた?(特に普段Excel触っていて今回初勉強会とかだったらそうなるかも?)要検証
  • 模範解答がほしかったという意見を聞いた気がする
  • うさみみさん、いのちをだいじに(体力的な意味で)
  • 時間、足りませんでしたね
  • Developer Testの話、結果的にはいらなかったですね
  • ペアプロできなかったのは少し残念
  • でも楽しかった
  • 自分に足りないものがわかった(気がする)

余談

  • 懇親会後に@irofさん、@hakuraiさんと手羽先を食べに行きました。2日連続手羽先!
  • 翌日、目が覚めたらチェックアウト20分前とか…

さいご

主催者の@kyon_mmさん、TEF東海のKENさんとまさおさん、エイチームさん、勉強会スタッフの皆様、勉強会に参加された皆様、ありがとうございました。
次またどこかでお会いしましょう!


あ、4月22日のSCMBC in Nagoyaがあるらしいのでよろしくです!

Developer's Test勉強会 SCMBCコラボ企画編に参加

今年最初の勉強会参加記事です。

1月14日 Developer's Test勉強会 特別編 - 学べ、Git! - SCMBootCampコラボ企画(大阪府)

Git初心者なので参加しました…と書くとどこかから突っ込みが入るかもしれませんが、少なくとも私は「SCMBCの演習スタッフ」レベルではないことと、複数人でのバージョン管理をほとんどやったことがないため体験したいということもあり参加しました。
Developer's Test勉強会については下記ブログにも目的が書かれていますね。

Developer's Test 勉強会 第3回 のメモ #devst - 日々常々

なお、会場ではなぜか「今日は名古屋からですか?」と聞かれることが多かったですが、九州の人です。"こわくない"分類ですよ。

演習1

ポジションペーパーを書いてコミットし、pull requestを送るというものでした。
GitやGitHubが使えるかどうかという環境確認の意味合いもあったようです。
ちなみに私はネットにつながらなくて時間がかかってしまいました、早めに会場入りしていたのに確認してなくてすみません。。。

講演

@bleisさんによる講演です。
SCMBC第2回のGit資料がベースにGitの考え方についての説明と、CIツール連携についてお話がありました。

お昼

グループ単位で食事することをお勧めされていたのですが、何も考えずに歩いていたらはぐれました。ごめんなさい。
そういうわけで、@kami_teruさんや@irofさんのところに混ざってお話していました。Developer's Test勉強会の目的などが聞けて面白かったです。

演習2

恒例の課題、Gitのチートシート作成です。
おそらくここからグループごとの特色がでたのではないかと思います。ので、本記事では私のグループについて書いておきます。


チートシートをどういう形式にするか決めていく中で、「チートシートの完成度は気にせず、一連の作業をしっかり行えるようになる」を目的とする形になりました。
途中で他人が作業しているファイルのファイル名を変えてpushするという事態が偶然発生し、面白い状況になりました。でもこれ、おそらくソフトウェア開発ではめったに発生しない事態ですよね。
なお、演習2ではmergeやpull主体で行われていたのでコミットグラフがグネグネしています。

演習3

トピックブランチやrebaseを主体とした演習です。


グループとしてはトピックブランチとrebaseをメインとした使い方、補助としてresetの使い方を中心に説明を入れながら練習。午前講演にあったcommitオブジェクトなどの話もからめた気がします。
トピックブランチをきちんと使えたかは…ちょっとわからないです。意図は伝えられたかな、とは思います。
どういうときにrebaseではなくmergeを使うかという話もでてきました。で、bugfixブランチと次バージョン開発ブランチを統合する時などは、"統合した"という情報を残したいからmergeのほうがいいのではないかということじゃないですかね。

振り返り

全員で各グループのコミットグラフを見ながら振り返り。チームによってコミットグラフが違っていて面白いですね。
ここで、演習2のときに私がフライングrebaseしたことがばれてしまいました…だが私はあやまらない!

感想

私はrebaseとresetばかり使っていてmergeを使ったことがないので、今回の演習でmergeだとどのような形になるのかを実際に見られてよかったです。
あと、グループの方にrebaseやresetは使い方を間違えなければ怖くないコマンドだよ、ということを少しでも伝えられたかな、と思いました。


SCMBC系のイベントに思わぬ形で参加できたのでとてもうれしかったです。ちなみにあの入門Gitはお昼に買いに行きました。
講師、スタッフ、参加された方々、ありがとうございました。今回の気づきを本家SCMBCにも反映したいなと思っています。

後日談

つぶやきによる後日談

動き出すF#er。

荒ぶるF#er。

串カツシュークリームは面白い味でした。
irofさん、bleisさん、お付き合いいただきありがとうございました。

TDD Boot Camp 福岡 2を開催しました

TDDBootCamp福岡2を開催しました。
当日の様子などはtogetterなどを見てください。

TDD Boot Camp 福岡 2 #tddbc - Togetterまとめ

まずはじめに謝辞を。
登壇を快諾してくださった@さん、@さん、@先生、イベントを支えてくださった@さん、場の盛り上げやTAなどしてくださった@さん、懇親会の手配をしてくださった@さん、グリーンバンドを手配してくださった@さん、そして様々な地域から参加くださった参加者の皆様に感謝いたします。

続きを読む