今回から始まった読書会、どのようなものかというと（ATNDより）

• 「 実践アジャイルテスト 」をベースにテストに関して学ぶ
• 勉強会の中では書籍の読み合わせ（輪読）は行わない
• あらかじめ該当の章を読み進めて来ることが前提（書籍の購入は必須）
• 担当者が予習して文書(sphinx)にまとめておきそれを元に発表していく形式

大学時代のゼミを思い出します。
1回1回が結構ヘビーになりそうです。
（Head First JavaScript読書会もあるし、アジャイルサムライ読書会もあるし…）
ただ、第1回と第2回は概要についての話になると言う事で「書籍購入不要」。
本を購入せずにどのような勉強会か空気をつかもうと思い参加しました。
まぁ、書籍を持っていなかったの、私だけだったんですけどね…。

アジャイル開発の中でのテスターの重要性

今回の範囲は「1.アジャイルテストとは？」。
大きく分けて以下の3つについて話をしました。

1. アジャイルについて
2. アジャイルな現場のテスターの役割
3. アジャイルなテストについて

アジャイルについて

アジャイル宣言なども読みながら、何に価値をおいているかを理解する。

• アジャイルの価値 “ごく短いリリースサイクルで、ビジネスの価値の小さな塊を提供すること”
• アジャイルの前提 “チームが個々の役割以上の事をする – 職能横断的”
• アジャイルで重要なことは “スピードではなく、高い品質を提供し続ける事”

他の読書会などでも考えていることなので、大きなずれはありませんでした。
スピードではなく高い品質のものを提供し続ける事が大事、と言う部分は絶対に忘れてはいけない。

アジャイルな現場のテスターの役割

チームが個々の役割以上の事をする中で、テスターとはどのような位置づけになるか。

• テスト以上の事をしなければいけない
• バグを見つける事を第一目的とするのではなく、「製品をよくする」為に改善点を探す事を一番大事にする
• テストの中で得られた情報を元に、よりよい方向に “テストを変化させる”
• テスターはお客さんとプログラマの橋渡しができる立場にいる
• テスターの仕事は、顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること

ソースコードのテストはプログラマも行う事が多いですが、それによりテスターのやる事がなくなるわけではなく、もっとさらに高い次元のテストを行える事を喜ぶべき、と書いてありました。
プログラマーであっても、テストをする時はテスターの帽子をしっかり意識しないとな。
アジャイルサムライ読書会では開発者各自がどのようなポジションでどのような事をやるかまでは突っ込んでは書かれていない（心構えやチーム作りの話が多い）ので、具体的な「誰はどのような目的でどんな事をやる」というのを整理できたのがよかった。
顧客チームと開発チームの相互作用のベン図はとてもわかりやすかった。
しかし、「顧客がイテレーション毎に実現したいことは何かを顧客が言えるようにすること」って、難しいですね。とてもハードルが高い。

アジャイルなテストについて

アジャイルテストの4象限のうち、アジャイル開発のテスターが行う事は主に「ビジネスに面したテストや要求機能に対するテスト（右上寄り）」となる。
目的は上記テスターの心構えで書いた通り。そのためのテストタイプはたくさんある。

20の質問

今回はその中でも重要になる「探索的テスト」のアプローチを学ぶと言う事で「20の質問」ゲームをしました。
担当者@shuji_w6eさんが頭に思い浮かべたものを、他の人が「Yes/No」で答えられる質問をしながら何かを当てていく（絞り込んでいく）ゲーム。ゲーム？のようなもの。
2回やったのですが、面白かったです。
ちょっと長いですが質問を全部載せてみます。（取りこぼしがあるかも）

＜1回目＞

現実に存在するか Y
お店に売っているか たぶんN
食べられるか N
自ら動く事ができるか N
さわることができるか N - 触るものじゃない
日本で生まれたものか N
私たちが目にするものか われわれはY 普通の人はN
電気を通す事ができるか N
目に見えるか Y
生き物か N
かべにかかるものか Y かかる時もある
やわらかいものか わからない
光るか N
今日それとかかわったか N
におうか N
カラフルなものか Y カラフルな場合は結構ある
それは絵ですか N 近い
それはホワイトボードか N ホワイトボードに関連する事もある
いろいろなものがまとまっているものか Y
作る事はできるか Y
変化しないものか N 通常は変化する
自分で作った事はあるか Y
アジャイルに関係するか Y する場合もある
それは言語か N
それは工場にあるか Y よくある
それは何かを書くものか わからない
それは何かが書かれるものか Y
それは カンバンですか N 近いけど違う
一般的にあるか 一部の業種の会社にはよくある
一部の業種とは営業か N
一部の業種とは飲食業か N
それは貼る事ができるか Y
それはポスターか N
それがないと使っている人は不便か Y
それは工程表か Y


1回目が終わった時に
「得られた情報を共有しようとする気持ちが足りない、誰が当てるかのゲームではない、チームで当てるために得られた情報から絞り込むというアプローチを考えた方がよい」
と指摘されました。
それをうけてもう一回。

＜2回目＞

さわれるか Y
食べられるか N
目に見えるものか Y
重いものか 通常はY - 感覚的なものは忘れた方が良い
動くか N
売っているか Y
中に何かを入れるものか Y
どの家庭にもあるものか 通常はY ない家庭もある
独身の家庭にはありますか Y ある場合もない場合もある
それは台所にあるか Y ある場合もある
もつ／もたないは所得に関係するか N
子供がいるかどうかに関係するか N
それでインターネットをする事ができるか N
男性が使うものか N 男性だけのものではない
マンションにあるものか だいたいY
高齢の人が使うものか Y
寒冷地の家庭には必ずあるか Y
沖縄にあるか N 基本的にない ある場合もあるかも
火に関連するものか Y
赤いものか Y 赤い場合もある
冬に使う頻度が上がるものですか Y
それは暖房（ストーブ）ですか Y


「どのような家庭にあるか？」という観点で絞り込みをかけていっているのがわかると思います。
また、1回目に比べてゴールまでの質問数も少なくなりました。
このような感覚やアプローチする方法が「探索的テスト」では必要になるそうです。
なるほどなー。
20の質問ゲームはとても楽しかったです。
皆さんならどんな質問をしようと思いますか？
いろんな人とやってみるとアプローチの方向性が見えて面白いかもしれない。

1回目を終えて

本の内容として、とても高い所を目標にしているので、現実で実現しようと思うと困る所や足りない所がたくさん見えてきそうです。心が折れそうになることもあるようです。
また、本自体も厚く、読み進める事自体がかなり難しそう。
しかも予習必須…！ とてもハードな読書会です。
でも、だからこそ、１人でやっても無理なので読書会で学んでいくのが良いのかな、と思いました。
（ということで、読書会中に書籍を購入しました )

次回もがんばってついていきたいです。

前回の記事を書いたあとにこれを読んでたのですが、
Hokkaido.pm#6でやったLTのスライドとかぶる部分が多くて、
LTでは説明したのに、書いてない「キャンセルできる」ことについて、
語ろうと思います。

「キャンセルできる」とは、どういうことなのか？
これは、こないだのスライドで以下のように説明しました。

• 設定内容を適用せずに破棄できる
• 時間の掛かる処理を中断できる
• 元に戻す・やり直しができる

個人的に、なぜこれらを重要視するかというと、
ユーザーが安心してその機能を試せるようにしたいからです。
どんなにすばらしい機能でも、使われなければ評価されません。
それと同時に、これらの実装はどれも簡単ではありません。
本当に「キャンセルできる」必要があるのか、
これがないとどうしても使って貰えないのかを検討する必要があります。

そして、もう一つ大事なことがあります。
それは、「キャンセルできる」ことが一目で分かることです。
例えば、アンドゥ・リドゥのボタンが目立つところにあれば、
ユーザーは安心してその機能を試すことが出来ます。
時間の掛かるバッチ処理も、中断する手段が用意されていれば、
やり直せるという安心感から気軽に利用して貰えます。

今のところ、言いたいことは言い尽くしたと思うので、この辺で。
おやすみなさい。

「Design Rule Index［第２版］― デザイン、新・25＋100の法則」(*1)
BNN　William Lidwell、Kritina Holden、Jill Butler　著

「認知的インタフェース」
新曜社　海保博之・原田悦子・黒須正明　著

今となっては、どの本から学んだのかは覚えてないですが、
たぶん、こんな感じのことを学びました。

1. とっつきやすいこと
見た目は重要で、アイコンやコントロールのレイアウトには気を使ってます。

2. 選択肢は少なく
ユーザーが目的を達成するために迷わない工夫をします。

3. 一般的な仕掛け
一言で言うとアフォーダンスってヤツです。
ボタンのようなものはクリックして貰えるだろうし、
ドラッグ操作で動かせそうとか、右クリックして貰えそうとか。
ショートカットキーの割り当ても市販のアプリを参考にします。

4. シンプルなだけじゃない
ユーザーが成長することを無視すると、痒いアプリができます。
たくさん操作するけど、変化量を小さくしたい場合（拡大表示のこと）や、
矢印ボタン、矢印キーを連打させる場合もあります。
キーボードから数値を入力させた方が良い場合もあります。

5. アプリには寿命がある
ユーザーと共に成長してしまったアプリは、もう後には引けません。
そして、生みの親としてはとても辛い、さよならの日も来るでしょう。
いっそこの手で・・・、という訳でUIを刷新しましょう。
アプリを設計する上で、テストを考慮し、疎結合にしてあるならば、
すべてを捨てる必要はないはずです。
きっと、より良いアプリに生まれ変わります。

6. ユーザーの意見を鵜呑みにしない
これも良く言われてますよね。
客観的に見て、正しい方向を示すことが、良い結果を生むと思います。
自分のためにも、様々な方法を検証するのは大切だと思います。
それらをユーザーに選択させた上で、さらに理想に近づけたら素敵ですよね。

7. 軽快な動作
これは、個人的なこだわりです。
ユーザーにストレスを与えない、その一心で作ってます。

最後に
自分はUIが好きだし、使って楽しいを提供したいし、
使って楽しいから操作方法を覚えてくれるんだと思ってます。
そのために、書籍に載っている内容を試しながら、
ユーザーの反応が良いもの、悪いものを蓄積して、
常に最適解に近づけるように取り組んできました。
最近はUIに関する書籍が増えてきて、
思い込みや勘違いを修正する良い機会なので、
現状の認識を整理するためにも、とりあえず書き残してみました。
この続きは、最近の本を読めば何か気付くと思うので、
その時に何か書こうと思います。

おしまい。

(*1) 自分が持ってるのは第1版

今回の範囲で「グっときた」ところ

全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない

お客さんが隣に座っている

勉強会として

自宅に帰って本を読み返しつつまとめのwikiを書いていて、若干文脈が違うディスカッションがあったかもしれないなと感じました。

「必要な分だけ、必要なときに」分析すること

“そのイテレーションで必要なものだけを分析していたら全体像が見えなくならないかな？”という話題がでました。
ここでいう「分析」がどういうものを示すのかをきちんと考えておくべきだったなあ。
見知らぬ土地に連れて行かれて「君のフィールドはここだ！さあ武器と防具を選んで！」というイメージではなくて、
見知った自分の土地のうち「今回はあの区画を耕そう、そのためには何の準備が必要かな」そんなイメージ。
（あまりに抽象的すぎますが。）
本章Ⅲ部の計画の段階で下地ができていて、それをさらに落とし込むという段階での「分析」だと思うのだけど、この段階では全体像はどこまで共有できていて、どこまで準備できているんだろう。
決して「行き当たりばったり」でも「今までの経験とスキルでなんとかなる」ものでもないと思う。
実際の業務の場合、この段階での「分析、設計」ってどんな事をするのかな。そしてその段階で揃っている情報はどんなものなんだろう。仕様面だけじゃなくて、技術的・アーキテクチャの面はどこまで固まっているんだろう。

この本で文書は不要と言っているかどうか

“会話とちょっとした文章だけで伝わるから文書はそんなに必要ないというのは文書化できない事に対する言い訳じゃないのかな？”という話題がでました。
家に帰って気がついたのだけど、完全に議論の途中で自分が文中から読み落としてしまっていたところがありました。
この本で、同じ机を全員が囲めるような小さなチームに必要はないだろうと言われているのは「形式的な」文書、ですね。
文書そのものが全くなくて良いと言っているのではなく、2,3人のチームでは「基本設計書」「○○仕様書」みたいな形式的な文書を作る必要はないよね、というニュアンスなんじゃないかなと、読み返して感じました。

「形式的な」って原著だとどのような単語になっているのだろう。

重要な事は「全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない」事。

その方法として文書が必要なチームは必要な文書を作ればいいし、膝を突き合わせてじっくり話し合う事でイメージが共有でき、それでプロジェクトを進める事のできるチームは、話し合いの時の絵や図、カードのメモだけでプロジェクトがうまくすすんでいくんじゃないかなあという個人的な結論に今は至っています。

ペアプロの話

今日はペアプロやってどうだった？得たものは何か？という話ができなかったのでここに書いておきます。

何度かペアプロをして、自分が一番変わったなと思った事は「名前を付ける」事に対する意識です。

クラス名とかメソッド名、パッケージ名（Javaなので）、１人で作っている時はそれなりの名前を付けて終わっていたのだけど、ペアプロをしているときは「本当にこの名前でいいのか」考える時間が増えました。
（そういうペアに恵まれた事が多かったと言う事もあるのかな）
新しいクラスやメソッドを作る、ということはペアプロ中の大きなイベント事なので
「さてどうする」とじっくり話し合うきっかけになる時だったのですよね。

それからは１人でコードに向かう時にも「名前大事」を忘れないようにしています。
みんなはどういう風にペアプロしているのかな、どういう時に困るんだろう。
また今度聞かせてください！

運営の立場で

「適切な話題をきちんとテーブルに載せる」「話をぶった切らない、雑にまとめない」「きちんとした言葉を選んで伝わるように話をする」、とっても難しいなあ。
「この本が本当に伝えたいポイントはどこか」をもっとしっかり考えたいなと思いました。
どうやって進めるのが良いか、14回開催しながらまだまだ試行錯誤中です。

あと今回は時間配分をミスりました。
ちょっと長めの休憩時間を取ったのもあって、途中で終わってしまったセクションには進まなければ良かったかなーと思っています。
実際にどうやってペアプロをやっているか、困った事、ペアプロをやって良かったと思った事、変わった事とかみんなの話を聞く時間を持ちたかった X(
反省点が多い回です。

でも、今回も楽しく充実した時間を過ごせました。
バレンタインデーと言う事で、皆さんにコーヒーとチョコレートを差し入れしました
（写真を撮るのを忘れたのでありました。ご想像でお楽しみください）

ディスカッションをまとめたwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120214

最後に、場所を提供してくださっている弊社に感謝。
（今回はコーヒーもいただきましたありがとうございます）
また次回から頑張りたいです！

釧路OSSコミュニティ勉強会を開催いたします。
日時：2月15日19:00-21:00
場所：わっと

ご参加お待ちしています！

知らなかった事いろいろ

へえ！そうなんだ！と思った事色々を箇条書きにしておきます。

外部ファイルとして定義したスクリプトファイルのキャッシュを適切に制御する

<script type="text/javascript" src="hogehoge.js?20120102"></script>

ファイル名の後ろに任意の文字列をつける事ができる。
内容を変更したタイミングで末尾の文字列を変えると別ファイルとして認識されるのでキャッシュクリアされる。
あと、scriptタグは外部ファイル定義するときも /> で閉じてはいけない。

prompt

使った事なかった・・・。

constで定数定義、遅延初期化はできない

const A;
A = 10;
alert(A); // undefined

こんな形で使う事ないけど、しらなかった。
constで定義した定数のスコープってどうなるんだろ。

+演算子のルール

前から評価、前から型を推測。

1 + 2
=> 3
"1" + "2"
=> 12
1 + "2"
=> 12
1 + 2 + "4"
=> 34
"1" + 2 + 4
=> 124
true + 3
=> 4
false + 3
=> 3
true + true + "3"
=> 23
true + "3"
=> "true3"

parseIntとisNaN

isNaNの方が数値の定義が厳しい。

isNaN("200aaa")
=> true
parseInt("200aaa")
=> 200

parseIntとN進数

０が先頭だと8進数、0xが先頭だと16進数に勝手に解釈される。
文字列から適切な進数に変換するためには第二引数を指定する。

parseInt("077")
=> 63
parseInt("077", 10)
=> 77

ルート、ノード、リーフ、エレメント

（この辺はもう頭が沸騰していてアレでした）
親がルート、末端がリーフ、それぞれがノード≒エレメント。
エレメントのidは重複しちゃだめ、絶対。

今日の発見、ここまで。

—–
学ぶ形式の勉強会、仕事終わりだとなかなかハードですね。
アジャイルサムライ読書会や達人プログラマ読書会とは違った部分の脳を使います。
終わり30分前くらいにはぐったりしていました（電池切れ）。
体力つけないと、と感じた勉強会でもありました。

次回、リベンジできるかな。

初めてのRuby読み合わせ

今回は6.3.5 for式からでした。

覚えたこと

6.3.5 for式

for と each のスコープの違いについて。eachはブロック内で定義した変数のスコープはブロック内だけだけど、forの場合はブロックの外側でも変数を参照できる。

for i in [1,2,3] do
  a = "hello"
end
puts a // できる

[1,2,3].each do |i|
  b = "hi!!"
end
puts b // NameError: undefined local variable or method `b' for main:Object

このため、ループ内でlumbdaを定義した時の実行結果も変わる

a = []
for i in [1,2,3] do
  a << lambda{puts i}
end
a.map{|e| e.call}
--
3
3
3

b = []
[1,2,3].each do |i|
  b << lambda{puts i}
end
b.map{|e| e.call}
--
1
2
3

こうして比べてみるとiが定義されている場所が違うんだな。なるほど。
みんなforはほとんど使わないみたいだった。

6.3.6 イテレータ

rubyにはいろいろな繰り返し処理の方法がある

• loop: 無限ループを提供
• n.times: n回繰り返す
• n.upto(m): nからmまでカウントアップ
• n.downto(m): nからmまでカウントダウン
• n.step(m, x): nからmまでxずつ増やす/減らす

カウントアップとカウントダウンは n < m (upto), n > m (downto) となっていないと実行されない。

6.3.7 脱出

break, next, redo.
Javaのbreak + ラベルを使う話がでました。実際ラベルを使った事がほとんどなかったのですっかり忘れていました。
ループを一気に抜けるため、にあるのかな？つかわないけど。
pythonの loop else は何のためにある？という話題もでました。

次回は6.4例外処理からです。

アンドリューさんのお話

[1,2,3].map(&1.method(:+))

という書き方ができるよ、と言う話。
関数の部分適用というらしい。

["9","1","2"].map(&method(:Integer))
=> [9, 1, 2]

class MyClass
  def to_proc
    puts "to_proc called"
    Proc.new{puts "doing something"}
  end
end
m = MyClass.new
1.times(&m)
--
to_proc called
doing something

こんな順番で説明をしてくれました。
1というオブジェクトの+メソッドを[1,2,3]に適用させている。
・・・・ようなのだけど、話を聞いている時はなるほどと思っていたのだが、難しくて説明できません。
誰か教えてください(;_;)

source_loactionの使い方とto_iとmethod(:Integer)の違いは理解した。

"a".to_i
 => 0

Integer("b")
// ArgumentError: invalid value for Integer(): "b"

懇親会

国際交流と日本酒とジンギスカン、最高でした。

また次回もよろしくおねがいします！

WPでは管理しているユーザーにアイコンをセットすることができるようである。
Wordpress3.3になってから（？）ダッシュボードの右上に「こんにちは、iarallyさん！」という表示が出るようになって、デフォルトアイコンなのが気になってきた。

そこで、いつものオムライスに変更…しようと思ったら、アイコン写真をアップロードする場所がない。

プラグイン必要なのかなーなんなのかなーと思っていたら、Gravaterと連携しているのでGravater設定をすればOKであるということを教えてもらいました。

対応としては次のどちらか。

• ユーザープロフィールの「メールアドレス」欄に、Gravaterで登録しているメールアドレスを使う
• WPのメールアドレス欄で使用しているアドレスでGravaterに登録する

あっという間にこのブログでもオムライスを表示できるようになりました。
@webbingstudioさん、@makiesさん、ありがとうございました！

今日が今勤めている会社の最終出社日となりました。

思えば6年前、次期システムをPHPで開発するつもりだと話していた当時のスタッフにPerlを使うよう誑かしたアドバイスしたのが始まりで、まさかここまで付き合いが長くなるとは思ってもいませんでした。

在職中は0からシステム構築をする機会を与えられた上、BTSやCIを始めとする開発ツール・フローの導入、書籍購入の自由化、20%ルールの実践、社内勉強会の開催、社外勉強会への参加の奨励など、エンジニアがやりたいと思ったことをどんどん実践できる権限を与えられ、大変刺激的に過ごすことができました。

お世話になった職場の皆様に、この場を借りて感謝致します。どうもありがとうございました。

当日やったことは次の3つ（実質2つ）です。

はじめる！Rails3を読みながら体系的にRailsを学ぶ

Railsのソースを見たり、機能を追加したり、修正したことはあったのだけど、ゼロから環境を作ってじっくり理解しながら学習したことがなかったので、本を読みながらプロジェクトを作っています。
開発オフでもその続きをやっていました。
自分の環境はRails3.1で開発しているのだけど、本書はRails3.0。そんなに大きな違いはないだろうなと思っていたら、結構違った。
しかし、 『はじめる！Rails3 (1)』をRails 3.1で読み進めるときのポイント というピンポイントで自分が困っていたことをアウトプットしてくれている記事があり、大きく躓かずに進むことが出来ました。

プロジェクトはgitで管理していて、練習問題はGitHubにもおいておくことにしました。
（途中で投げ出さないようにするため）
コミットの頻度や意味のあるまとまりでコミットすることを意識して進めました。その結果

git commit --amend
git reset

などのコマンドを覚えることができました
さらに、git関連のエイリアス設定も充実してきた。

データ投入までできたので、次はデータ表示だー。

マシン起動時にMoinMoinDesktopを起動させるスクリプトを作る

ローカル環境のメモとしてMoinMoinDesktopを使っているのですが、MacBookのPythonのバージョンが上がってしまい、起動エラーが出ていました。
なので、

• Pythonのバージョン指定をしてWikiサーバーを立ち上げる
• ターミナルのログコンソールが立ちっぱなしにならないようにする

スクリプトを作りました。

#!/bin/sh
nohup /usr/bin/Python2.6 /Users/xxxx/Develop/moin-1.9.3/wikiserver.py &

この前覚えたnohup。これでログは外部ファイルに記録されるはず。

この.shファイルを右クリックしデフォルトの起動アプリケーションをターミナルにしたうえで

このアプリケーションで開く → ターミナル

システム環境設定 → ユーザーとグループ → ログイン項目

に追加すればOK。
まだ1回しか再起動していないのだけど、うまく行っている模様。
3ヶ月以上放置していた気になることが1個すっきりしました。

もろもろ

ソースコードをEmacsで書きながら覚えていないショートカットを調べて使うなど。
（プラグインには手を出せていない。）
gitにマシン名（本名漢字）でコミットしてしまったソースをGitHubに上げてしまい、本名でググるとソースが出てくる件の修正は
途中まで調べたのだけど完了せず。

あとはみなさんとのおしゃべりて

• よい技術書の選び方
• XSSについて

とか話せたのは良かったなー。

お昼ごはんはsuage+のスープカレー、ハニーマスタードチキンとアボカドの辛口。

ということで、今回も楽しかったです！次回も楽しみです。