TDD Boot Camp Tokyo 2013-07/KPT
Keep
- 「不安をマネジメントする」という視点で適度にテストを書く
- TAできた
- 充実したTA陣
- 自発的だったのであまりTAの出番なかった
- 用語集
- 他言語のテストコード見るの楽しかった
- 他の言語のことも知れて楽しかった。
- 他の言語のコード見るの楽しい
- アイスはよかった。(すぐに食べないと溶けるので、強制的に休憩を促せる)美味しかった！
- プログラミングしやすい環境
- STEP0から書き始めるとたびたび「それこの先考えるとやばそう」ってなるのでひと通り見た方が良い
- サプライズゲスト、スペシャルゲスト
- Steveさんのお話が聞けた！
- Steveさんにまた来てほしい。
- Steve Freeman氏とペアプロしたった
- Steveのコード見れた
- コードあげました
- ペアプロによって普段意識してなかった設計部分まで気づけた。
- ペアプロで手を動かせたのがよかった。
- ペアプロ is GOOD!! 特に設計に関して
- ペアプロ初めてだったけど楽しかった
- ペアプロで他の意見を聞く
- 和田さんの講演で、導入事例の数字が出ていたので、啓蒙に使いたいと思った。
- ペアプロで他の人は考え方が全然違うと知った。交互に行うことによって、どちらが強くなることが無くて良い。
- 楽しい。
- いろんなテストを見れてよかった。
- Perl忘れてたのでドライバー出来なかった
- Wikiの言葉が曖昧なおかげで設計の議論ができてよかった(値段はジュースの「初期状態」なのか？ →違う。とか)。
- いつもより女性が多かった
- 一日コードを書く時間を持てると楽しい。
- 実装(ペアプロ)タイムとレビュータイムのバランスがちょうどよかった。
- 楽天タワー近い
- 遅刻しない
- テストの自動実行させたこと。
- それぞれの環境で開発できた。
- 1000円でこの内容が受けられるのは夢のようです。
- guardは量が少ない時は便利
- 設計に踏み込んでペアプロ
- 課題に色々考える余地が残されているので、取り組み甲斐がありました。
- スケルトンよい(setupでハマらない)
- パラメタライズドテスト便利！
- クラス設計を見直せたこと
- rubyの勉強に続ける
- Quick JUnitを使ってみた
- OOP的な責務のモデリング
- リファクタリング、ガンガンするの良い
- 初心者は先生と組んだ方が無難。
- SteveのサインをGOOS本にもらった
- Steveに質問できた
- たくさんの本の課題とセットでの紹介
- テストが通った時の喜び GooD!!
- TDDのメリットは心理的なもの
- ペアプロの目的(教育なのかドライブなのか)について考えることができた。
- オブジェクト指向っぽいコードから関数型っぽいコードに大幅に変更したが、直す際に既存のテストが役立った。
- こまめな交代ができた。
- コードとテストコードのリファクタがよくできた。
- ペアプロ最高！
- TDDについての勉強
- TDDする
- 黄金の回転ッ！
- 今やっているのはどの矢印で、その一つのことに集中するのが重要ということを実感することができた。
- Githubの利用。
Problem
- 「開発環境は事前に用意」とあったのですがどこまで準備するか悩んだので、GtiHubのテンプレをご連絡いただければ嬉しかったと思います。
- イベント告知のときに、開発環境の案内しとけば当日楽なのでは。
- 時間が短い
- 人数に対してTAが少なかった
- 初心者だとJava(デモ)がごちゃごちゃして見えるかもしれない。
- ペアプロデモにはピンマイクがあった方がいいかも（マイク持つの大変そうでした）
- ペアプロデモ、driver,navigatorの他に説明者がいたほうが良さそう。説明しながらペアプロは大変そう
- ペアプロデモの時にもっと説明があった方がいい。
- ペアプロでも どのくらい役立ってるかわからない
- 最初に全体像を共有しておくほうがよかった
- 設計不足
- 設計をどこまで考えるかあいまいだった
- モデリングむずかしいぉ....
- 設計を考えるのと小さく始めるバランスが難しい
- 実装を進めていって、途中で設計を見直すタイミングが難しい。
- 設計を見直すタイミングがわからなかった
- 設計に2つの選択があったときに、中途ハンパになっちゃった
- プログラム以外（ToDo?、設計、モデリング）をもっと大事にした方がよかった
- TODOリストの書き方、問題をどこまで細かくすればいいかわからなかった。
- TODOを分割する時間をちゃんと取るべきだった
- ペアごとのメモ用紙、ホワイトボードが何か所か欲しい
- ペアプロの交代をもっとひんぱんにやればよかった（少なかった）
- ペアプロ力不足
- エディタによって慣れ・不慣れがある。合わないと申し訳ない。。。
- ペア間でキーボードが違う問題
- レビューで見せる用の設定変更が面倒
- TDDのサイクルの内、REFACTORがあまりできていなかった。
- テストコードのリファクタの意識が弱かった。きたないtestコードのまま次のstepにいっていた
- REDの確認忘れ
- 単体テストでリファクタリングなんてできるわけないよね
- テストの粒度やカバレッジをどこまでやるか、感覚値が難しい。
- メソッド名・クラス名意識しているつもりでも変。主語が違ったり。
- 個人的に勉強不足
- 技術不足を感じた
- rubyの知識が少し足りなかった
- RSpecに対する習熟不足
- 動的型付言語
- PowerShellの人がいない
- Groovyistが少ない
- 静的型付け関数型言語が少ない
- 英語をちゃんとやっとくべきだった
- 英語が聞きとれない。
- つれーわー 実質2時間しかねてないからつれーわー
- 前日はちゃんと寝る
- レッドブル忘れた
- なごやこわい
- なごやこわい
- こわいといわれた
- マサカリ忘れた
- アイスとけてた
- 本もらえなかった
- プレゼントじゃんけん、最後に負けた
- トイレはカバーしてもらえていたけどやはり不便
- 楽天タワー遠い
- Id:t-wadaのブログが更新されてない
Try
- 設計をどの時点で固めていくのか。
- 仕様変更しやすいようにミニマムなハッシュを作る(最初は)
- とりあえずIntelliJ IDEA使っているとデキる人に見えそうなので使う
- 岡山のペアプロデモではやさしいScalaにする
- (Steveに限らず)タレントのコードも紹介する
- 次回までにマルチリンガルのTA
- キャンセル待ちだと思ったら最終チェックを怠らない。
- 遅刻しない。
- 色んなペアでやってみたい！
- ペアプロでTDDをUSTで流しても面白いかも
- TDDBCの次の実践TDD！
- 静的型付け関数型言語でTDD
- 証明駆動開発
- 「不安がないからテストしません」と自信を持って言い、注力すべきことに取り組む。
- TDDする(続ける)
- JUnit本完読して実践したい
- 紹介された本を読む
- 実践テスト駆動開発精読
- リファクタリングに時間をかける
- リファクタリングの本を読んで極めたい！
- 朝がツライのでがんばる
- テストコード書かない人には、ペアプロで張り付きます
- 会社でもペアプロ/TDD取り入れる
- TAでも久しぶりにペアプロしたい
- あとでFreemanさんとのペアプロの話をあげます
- テンション上がったのでコード書く量増やします
- Guard使ってみる
- 自分が知っているフレームワークや言語以外のテスト・フレームワークについても勉強したい
- Groovyやってみようかなー
- Haskellでやってみる
- ExcelVBAでTDD
- JSは各フレームワーク毎に比較してみたい
- JavaScriptのUnitTestからは逃げ続けてきたので、この機会にチャレンジしたい
- 家で続きをやる。
- 残りの課題やり終える
- Designをきちんとする、テスト可能か、Boundaryはどこか
- モデリングにもっと時間をかける
- Type Driven Design
Keyword(s):
References: