2012年6月18日月曜日

#scrumbc 大阪に参加してきました


Scrum Boot Camp in 大阪(通称:Scrum BC)
=======================================
http://atnd.org/events/26778


ScrumBC
=======================================
ScrumBCは座学だけじゃなくてワークショップも行うことでスクラムを体感できるイベントです。
スクラムを学びたいと思う方は是非参加した方がよいです!


ScrumBC 大阪
=======================================
ScrumBC関西に去年参加して、その後Certified Scrum Masterを取得してるので
本当だったらScrumBCには参加できないのですが、お手伝い的な役割として参加させていただきました。
お手伝いとは名ばかりで、普通に参加して楽しみました。


伝え方の勉強
=======================================
なおとさんの話を聞きながら。考えてたのは。伝え方。

1. これまでのやり方と、やることは一緒なんだよ。的を射る。
2. でもこれまでのやり方だと、色々問題があるよね。遠い。嵐。変化。
3. だから近くをまず狙って当ててから次の方向を確認するんだ。
4. そうすると負担が増えるよね。だから色んなことを手軽にできるようにする。
5. そのためには透明性と検査と適用が大切。

とか。そういう流れかー。なるほどなー。と違うところで勉強していました。

お昼休みにチームの人と話してたら「やることは一緒なのにやり方が違うんですね」と言ってたので
すごくうまくメッセージが伝わってるんだなーすごいなーと思った。


気づいたこと
=======================================

サンプルストーリー
---------------------------------------
ストーリーの内容は「誰々として、何をする、何のために」と書くといいと説明しつつ
ワークででてきた例が「紙飛行機をつくる」などで要望がぼんやりしてたところ。

紙飛行機をつくることに対する見積もりよりも「このストーリーをどう解釈しようか?」というところに対して
議論が発生してしまっていたので、もっと輪郭をはっきりさせたほうが趣旨にあっていたかも。

それが議論になること自体を体験してもらいたいという意図もあるかなと思うけど。
詳細はテーブル内のPOに聞いてね。くらいあってもよかったのかなーと思った。

ストーリー?タスク?
---------------------------------------
スライド中に出てきた例が、ストーリーなのかタスクなのか、参加してる人は混乱しない?と思った。
ポイントで見積もられてたり、時間で見積もられてたりしてたので。

僕自身タスクを時間見積もりするかどうかは、考え中。今のところしてないです。

スクラム?エッセンス?
---------------------------------------
Q&Aのときに微妙に講師陣と参加者でズレを感じるときがあった。
参加者はスクラムのエッセンスをどう取り入れていったらいいか?と思ってるっぽいところに対して
講師陣はスクラムを取り入れる方法について話をしていたような。感じを受けた。

WFで仕事をしている中でスクラムを勉強し始めた人と
スクラム慣れしている講師陣のコンテキストの差なのかな。


自分がした質問メモ
=======================================

Q. Impediments List の検査と適応はフレームワークとして決められた場所がある?
A. それのためだけというものはない。(川口さんの場合)振り返りで見直す。(西村さんの聞いた話だと)スクラムマスターが分類して見えるところに貼っておく。対応できるときに対応する。

Q. お客さんに分からないストーリーはどうする?
A. (川口さんの場合)タスクボードに貼っといて、何かのストーリやるときに混ぜ込む。

Q. お客さんから見てWF、内部をスクラムでやる場合にスプリントレビューなどで改善点を見つけた場合は?
A. (田口さんの場合)その場に合わせて判断している。


飲み屋ネタ
=======================================
あくまでも、あなたならどうしてる?というのを聞きたいなー。
自分のコンテキストでの答えは自分で見つけなきゃと思っている。というか道場に参加しろオレ。
  • 全体スケジュール引くときの期間見積もりどうしてる?年間計画で予算とりにいくときとか。
  • 約束を守る? vs 持続可能なペース?
    • 残業でカバーすんのかどうか
  • 「役割は自然発生するもの」てところで、1人がファシリテーション始めると、周りが考えなくなりがち
    • 全員に考えてもらうためにどう対応する?
  • 現状に不満を持っていないけど色々改善点が自分からは見えるチームに向き合うときはどうするんだろう?
  • 「見積もりは実際に作業する人が行う」とあったけど、人?チーム?どっちのことだろう。
    • ストーリーならチームで、タスクなら人とか?
  • スプリントバーンダウンはポイント?時間?チケット数?
    • それぞれやってる人にプロコン聞きたい
  • ポイントによる相対見積もりで、結局時間を使って比較してしまいそう

自分を振り返る
=======================================
スクラムやれたら面白そうだなーとは思っているんだけど。出来ていない状況で。
むしろアンチパターンと言われている状況を作ったりしているのだけども。それはそれでいっかなと。

それを「スクラム」とか「これが自分の目指しているところだ」と言っちゃうのはまずいと思うんだけど。
「スクラムに向かい中」とか「スクラムのエッセンスを取り入れ中」とかでいいかなーと思っている。

スクラムするためのストーリーが Not Ready ということか!
というかスクラムやりたいわけじゃないしね。スクラムはよくできた手段かなと。


おもしろかったー
=======================================
色々とおもしろかったー。スタッフのみなさん、主催者のようさんお疲れさまでした!ありがとうございました!
一緒のチームになったみなさんもとても楽しかったです。ありがとうございました!

P.S. SCBCって略さずにScrumBCでいい派。

2012年6月8日金曜日

#tddbc 大阪。ありがとうございました!


感謝
========================
参加者のみなさん、ありがとうございました。スタッフのみなさん、ありがとうございました。
そして講師の和田さん、関さん、吉岡さん、ありがとうございました。
想像以上に、ものすごい熱気に包まれていて、楽しかったです。

惜しかったのは、1日目も2日目もワタワタしていて、
和田さんのセッションをゆっくり聞くことができなかったことです。
むむむ・・・。それが聞きたくて主催したのになぁ。

でも楽しかったです!


参加者のみなさん
========================
主催者として色々と至らない点がありましたが、みなさまが優しくフォローしてくださったおかげで
なんとか無事終えることができました。ありがとうございました。
みなさんが楽しそうに(最後の方はぐったりとしてましたが)ペアプロをしているのを見てとても嬉しかったです。
エンジニアとしてとても良い刺激を受けました。ありがとうございます!


ゴール
========================
今回の主催に置いて、自分としては、1つのゴールを設けていました。
というか色々考えても無理そうなので、1つしかゴールを設けませんでした。
それは「TDDBC大阪を開催すること」です。

とにかく「開催すること」これをゴールに置いていました。

開催前から色々と反省する点があってグルグル悩んでたりしてたのですが
そんなときはこのゴールを思い出して前を向きました。まずは開催しよう・・・と。
その点では無事グリーンバーを拝むことができてよかったです。

参加してくださった皆様と、スタッフ、講師の皆様のおかげです。
また、社内でも多くの方に助けていただきました。ありがとうございました。


カリスマ
========================
講師の3人を見ていて「この人達はカリスマだなぁ」と思いました。

和田さんはMLなどでは、色んな方の意見を引き出してまとめる優しい方という印象だったのですが
実際にお会いすると、どんどん色んなことを決断して先に進めていく男前な方で
TDDBCの個性的なスタッフみんなが、和田さんの一言でまとまるのも、なるほどなぁと思いました。
TDDだけじゃなくて、その姿からもっと色んなことを学ばせていただきました。ありがとうございました。

関さんは、逆に、ついったーなどを見ていて、ちょっとコワイ方かな?と思っていたのですが
全然逆で、今回の開催に当たって色々と自分が気づいていないことを、それとなく教えてくださったりと
とても優しい方でした。この方のところにも人が集まるのは納得だなと思いました。
色々な側面から物事を見ていて「こんな見方もあるよ」とそっと教えてくださいました。ありがとうございました。

吉岡さんは、大好きなので、久しぶりに会えて飲めて嬉しかったです!おーさむ!


スタッフ
========================
全国からスゴイ方々が集まってくださいました。
みなさんとお会いできただけでも感動していました。

いろふさんは、開催にあたって、支えてくれて
何かあるごとに、開催で手をあげてくれてありがとうと言ってくれました、
それだけで頑張ろうと思えました。ありがとうございます。

岡澤さんは、さりげなくアドバイスやフォローをしてくださり
もっとみんなポジティブに話そうと切りだしてくれたりしました。
ありがとうございます。

西川さんは、ギリギリまで参加可能かどうか分からなかったのですが
直前に「いけるわ!」と連絡を下さり、久保さんを紹介してくださったり、
ペアプロをがっつりしてくださったりと、ありがとうございました。

西郡さんは、備品を用意してくださったり
ペアプロで、一人しかいない方のペアを組んでくださったり
さらっと色々やってくださってありがとうございました。

細谷さんは、大阪メンバーとして最初のころから色々とコメントを下さって
会場の準備やアドバイスをしてくださいました。
課題のリバイズなど、とても感謝しています。

太田さんは、MLでも色んなことに反応してくれてフォローしてくださり、
また当日もスタッフの方々のケアをしながら、うまく回るようにご意見を仰ってくださったので心強かったです。
事前のスタッフ打ち合わせなどの取りまとめありがとうございました。

きょんさんは、なんといってもGroovy愛がすごかったです。
あっという間にGroovyが最大勢力になっていました。
そして、服装からうさみみまでとてもかわいかったです。

ぶれいすさんは、すごく優しい雰囲気の方で、とても癒されました。
「Javaのペアの話が勉強になりました」と言っていて、かっこいいなと思いました。
きょんさんもだけど、ぶれいすさんもかわいかったです。

井芹さんは、2日とも写真をずっと撮ってくださいました。
また、いろんなコトをいい声で教えてくださって、かっこよかったです。
写真もすぐにアップしてくださってありがとうございます。

がぶさんは、色んなことを丁寧に手伝ってくれました。
ランチタイムも夜もLTをありがとうございました。
背中を押してくれてありがとう、と言ってくれたので、それだけでもやってよかったなと思いました。

久保さんは、突然のお願いにも関わらず引き受けてくださってありがとうございます。
私の後輩のペアプロも見ていただいて感謝しています。
知り合いのお兄さんということで、ご縁を感じました。

中山さんは、本当は一歩進めたイベントを考えておられたと思いますが
2.0の開催を決断してくださってありがとうございました。
主催者として色々とフォローして下さり感謝しています。

まおさんは、デモペアプロありがとうございました。
また、TAとしてJavaチームをみてくださってありがとうございました。
岡山での主催、がんばってください!

なおきりんさんとせとさんは、2.0のみのご参加で
自分は2.0のときにはぐったりしてたのであまり喋ることができなくてすみませんでした。
またお会いした際にはご挨拶させてください。


Try
========================
ついに大阪で開催することができてほっとしています。
和田さんが何度も、大阪で開催してくれて嬉しいですと言ってくれるたびに、やってよかったと思いました。
最初にスレッドを立ててくださっていた秋猫さんにも感謝です。

今回の参加者のみなさんを中心として
大阪のGroovyコミュ・・・あ、違った、TDDコミュニティが大きくなっていくといいなと思います。
今後ともよろしくおねがいします。

自分自身、今回の主催で沢山の方と出会い、沢山のことを学ばせていただきました。
その学んだことを実践していき、またみなさんにフィードバックしていけたらと思っています。
ありがとうございました!

運営についてのまとめはまた来週。

P.S. 楽天カフェテリア最高ありがとうございます!






2012年5月31日木曜日

TDDBCのJavaの環境準備を自分好みでやってみた(Windows)

Javaの環境を自分好みで用意してみた。
いや、僕はスタッフなのであんまり関係ないんですけど。

Eclipse Classic にしてみた

1. Eclipse Classic 3.7.2 を落とした

http://www.eclipse.org/downloads/packages/eclipse-classic-372/indigosr2

2. 起動


自分好みに設定変更

1. Appearance 設定変更

僕の画面は狭いのです。タブが撫で肩じゃないほうがいいし。パースペクティブのテキストがないほうがいい。
  • Show text on the presentation bar のチェックを外す
  • Show traditional style tabs のチェックを付ける


2. Font 設定変更

  • Appearance > Colors and Fonts > Basic > Text Font をメイリオにした。gdippを使ってるからモワッとするけど。まあよいではないか。


3. Text Editors 設定変更

タブよりスペース派
  • Insert spaces for tabs をチェック
  • Show line numbers をチェック
  • Show whitespace characters は表示が好きじゃないのでチェックせずに後でJStyle入れよう


4. Workspace 設定変更

どうしてデフォルトがMS932なんだろ?
  • Text file encoding を UTF-8 に変更


次はJava関係の設定

5. Formatter の設定変更

タブじゃなくてスペース使って、インデントサイズはスペース2コ派。
  • Tab policy を Spaces Only に設定
  • Indentation size を 2 に設定
  • Tab size を 2 に設定


6. Organize imports の設定変更

JUnit4 使うなら static import 使うので、これしとかなきゃ。
  • Number of static imports... を 0 に設定


7. Content Assist の設定変更

Ctrl + Space で挿入より上書き派。
  • Insertion を Completion overwrites に変更


8. Favorites の設定変更

JUnit4 使うなら設定しなきゃ
  • CoreMatchers, Assert, JUnitMatchersを追加


9. Save Actions の設定変更

フォーマットとかインポートの編成とか気にしたくない派。
  • Perform the selected actions on save をチェック
  • Format source code をチェック


10. Typing の設定変更

どこで打ってもいい具合に入るので重宝するす。
  • Automatically insert at correct position の Semicolons をチェック


11. Installed JREs の設定変更

  • JDKを設定

12. 忘れてた。 Appearance の設定変更その2

僕の画面は狭いのでちょっとでも広くしたいの。
  • Perspective switcher positions を Left に変更


13. Hide Toolbar

僕の画面は狭(ry

14. Package Explorer の Package Presentation を Hierarchical に変更

これも好みね。

15. M2_REPO の設定

  • Maven 使ってるので設定


設定はこんなところか。

プラグインを入れる

1. Quick JUnit を入れる

Ctrl + 9 と Ctrl + (Shift) + 0 でサクサク開発するす!


2. JStyle を入れる

Eclipse デフォルトのやつは表示が好きじゃないのでこっち使う。
  • JStyle( http://mergedoc.sourceforge.jp/#jstyle.html ) からプラグインをダウンロードしてpluginsに突っ込む
  • JStyle は Eclipse の plugin を上書きしないといけないので dropins じゃ動かないです

これでいっかな

3. 動作確認

  • Ctrl + 9 でテストクラスが作られた・・・はっ!TDDなら逆か・・・まいっかε-(´∀`*)

  • Ctrl + Shift + 0 でテスト実行・・・え、ポップアップなんてでるんだねー


プロジェクトの作成

1. mvn でプロジェクトを作成

mvn archetype:create -DgroupId=com.example -DartifactId=tddbc

2. eclipse プロジェクトに変換


  • tddbc プロジェクトのディレクトリに移動してから 

mvn eclipse:eclipse

3. eclipse から import


4. JUnit3 なので JUnit4 に変えよっと

  • pom.xml
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.10</version>
    </dependency>

5. もう一度 mvn eclipse:eclipse


こんなところかな。

















2012年5月23日水曜日

初めてGroovyでコード書いた(∩´∀`)∩ワーイBuzzBuzz

週末に「プログラミングGROOVY」を読んでGROOVYに入門したのだ。
で、
に書いてあるコードが読めるようになったのだ。なので勉強がてら
の「無限の構造」のところをコピペしてきてグニグニしてみた。
こうしたら動くのかな・・・動かない(´・ω・`)
とか遊び倒したコードの残骸。


遅延面白いね。なんか、Blogger使いづらいなぁ・・・。

2012年4月24日火曜日

うにゃったーつくりおわった

うにゃったー

http://unyatter.appspot.com/

なんか、言わなくてもいいんだけど、言ってもしょうがないって分かってるんだけど
それでも言ってしまうんだけど、別に誰かに聞いて欲しいという感じのあれでもなくて
なんかこう・・・ふにっとしたときに(」・ω・)」うー(/・ω・)/にゃーってしたくなるなぁと
思ったので作りました。

ふにっとしたときにうにゃっとするのや。

うにゃったーの使い方

  1. ふにっとしたときにうにゃったーを開きます
  2. ふにっとしたことをうにゃったーに書きなぐります
  3. つぶやく
  4. (」・ω・)」うー(/・ω・)/にゃー
  5. あしたもがんばろう


うにゃったーの生活環境


うにゃったーの作り方

Slim3プラグインでScenicプロジェクトを作ってTwitter4jを追加してFrontPageをごにょごにょしただけかな。
設定はちょこちょこさわったけどね。ロジックはFrontPageだけ。便利だな。

あ、そうそうConsumerKeyとSecretはappengine-web.xmlにシステムプロパティとして書いておきました。
のでそこを消したやつをappengine-web-sample.xmlとしてアップしてます。

あと、ずっと噂に聞いてたTwitter BootstrapのCSSだけ(たぶん)使った。
サクっと作れてよいすなー。


うにやったーの仕組み

  1. テキストエリアは気持ちだけ受け取ります。サーバーには何も送信しません。
  2. サーバーでは過去10ツイートをチェックします。
  3. 過去10ツイートにないものをうにゃります。


うにゃったー作って気づいたこと

テストなしでデプロイして祈るという。久しぶりな楽しい経験をしました。
リファクタリングしようかなーとも思ったのですが。まぁいっかとそのままソースアップロードしました。

最初は(」・ω・)」うー(/・ω・)/にゃーってつぶやくだけにしてたんだけど。
そうするとついったーの「過去10ツイート以内のツイートと同じことはつぶやけません」制約にしっかりはまりました。

そういえばそうか。ということで10こくらいバリエーションを持たせました。
試しにつぶやいて、みんなから「どうしたん?」と心配されました。ごめんなさいごめんなさい。

あと、URLの部分がついったーみてたら普通に表示されてるんだけど短くなったやつなんね。
んでユーザー毎に違うっぽいのね。


うにゃったーのコード


3日間楽しかったです。
なんかまずいところあったら教えてくれると嬉しいです。

2012年4月23日月曜日

うにゃったーをつくった

うにゃったー


http://unyatter.appspot.com/

ふにっとしたときにうにゃっとしてください

使い方

あなたがふにっとしてることを書いてくだしあ。

でつぶやくボタンを押すと。この思いがこうなって発信されます。



まぁ、ふにっとしたときに使ってくだしあ。
書いたことはポストすらされてないので。安心してね。


仕様

- GAE/j : 無料枠
- Slim3 with Scenic
- Twitter4j

です。Slim3プラグインとScenecとTwitter4jすげーなー。
JSPとかもろもろ思い出すのにばっかり時間がかかった。



2012年4月13日金曜日

ふとTDDの良さを体感しはじめた

TDDのことは知ってたんだけど

イマイチそのよさは実感できていませんでした。
言ってることは何となく分かるんだけど・・・ねぇ。って。

けど最近ふと

「ここはTDDでやるとよいかも」と思ってやってみて。
んで実際にピタっとはまって良い感じです。
なんでだろう。なんかが頭の中でつながったのかな。

良さ

一歩ずつ
落ち着いて
足下を固めながら
山に登る

のがいいなと感じました。
いや、言葉にすると既に何度も説明されてることだよね。

相性

TDD と ペアプロ と Git は相性がよいんだなーと思った。
あと、EclipseのQuickJUnit(S2JUnit)は必須すね。

弱点

ただ、この手法。ある程度頭の中で設計を描けないと無理だね。
その点ではウォーターフォールの仕様書ドリブンってのは、入門者にとってはいいもんだなと思った。