コンピュータやソフトウェアのあれこれ＠道民（＆元道民）
Archive for 2月, 2012
Sapporo.elに参加した
2月 27th
2012/2/25にSapporo.elが開催されたので参加してきた。横にはSapporo.vimも開催されていた。 自己紹介 最初はSapporo.elとSapporo.vimで合同で自己紹介。おすすめプラグインなどを発表しつつ進められた。気になったプラグインがいくつか。 org-mode artist-mode 便利なelispを使う 前半は実際にプラグインを使ってみるコーナー。今回はEmacs上でTwitterができる「twittering-mode」。プラグインを導入する際には「auto-install.el」を使ってプラグインをインストールするらしい。自分はauto-installをインストールしていないのでその導入から説明していただいた。 auto-installのインストールは無事できた。続いてtwittering-modeのインストール ブラウザでGithubの
Ruby Sapporo Night vol.14 に行ってきました
2月 25th
2月23日（木）に開催されたRuby Sapporo Night vol. 14 『Ruby札幌 × Sapporo.js』に行ってきました。
このイベントはRuby札幌がApple Store Sapporoで行っているイベントです。
Ruby札幌の方達の今やっている、気になっている技術のお話を聞けたり、他コミュニティとのコラボ企画で色々な分野のお話を聞く事ができます。
不定期開催、事前登録不要のイベントです。
開催はRuby札幌のサイトやAppleStoreのイベントカレンダーで知る事ができます。
リッチクライアントを中心とするセッションのリンク
前半は、Ruby札幌の島田さんによるセッション
「リッチクライアント時代のWebアプリケーションアーキテクチャパターンについて考える」
”MVC” をキーワードに、従来のMVCとは、そして現代のリッチクライアントに必要なMVCモデルの形についてとお話が発展していきました。
後半はSapporo.jsの佐藤竜之介さんのお話
「Testable JavaScript」
”テストしやすいJavascript” にするためにどのように設計をし、コードを書いていくのが良いか。
Testableにしていくために、MVCモデル(KATA)を考えていく事が大事になると言う話でした。
参加していてとても面白いなあと思った事は、全く違うアプローチから入っていっている両者のお話が、絶妙にリンクしていってたんですよね。
核となる部分に同じ思想があって、それにそれぞれの形で向かっている。
うまく言えないのだけど、すごく気持ちのよいイベントの流れがありました。
あと、お二人のスライドはどちらもお二人の話以外のたくさんの情報が詰まっている。
とってもためになる資料です。公開されている事に感謝です。
リッチクライアントのためのMVC
ちょうど数ヶ月前に「Javascriptのテスト、すごく難しい」と思う事があり、どういう形でテストしていくのがいいのかなーと考えていたので、りゅうのすけ氏のアプローチはとても興味深かったです。
テストツールやテスト用のライブラリの紹介も最後にあったのですが、それよりも「KATA」。
手を加える度に、進歩して行ける開発を！
デスクトップアプリケーションを作った時に学んだ考えも生かしつつ、「良い設計」について考える機会・・・もとい
「良い設計」を意識する気持ちを持つ事ができました。
Javascriptだから、時間ないから無理、と諦めないこと大事。
良い時間を過ごす事ができました。ありがとうございました！
Ruby Sapporo Night vol.14
2月 23rd
Ruby Sapporo Night vol.14
アップルストア札幌さんをお借りしてものすごく久々に Ruby Sapporo Night vol.14 を行いました(約2年ぶり!!)。参加いただいた皆さま(mrknがいた!)、ありがとうございました。
発表のスライドは以下から。今回は Sapporo.js さんとのコラボ企画ということで、僕からは最近気にしているクライアントMVCというワードに関する話をさせていただきました。さらなる旅を続けます。
MacBook(Lion)にRabbitが入った
2月 23rd
昨年の11月頃、Rabbitをインストールしようとしていたのですが、エラーがたくさん出て
うまくインストール出来ませんでした。 前半の格闘はこちら。
このあと大きく躓いて、心が挫けてしまったのでした。
そのまま諦めかかっていたのですが、最近試しにやってみたところ、
すんなりインストールすることが出来ました(・∀・)！
OSがアップデートされたからかな。
トライ途中まで書いた状態のものが下書きフォルダに残っていたので
ログの記録として残しておくことにする。
———-
- cairoのインストールでエラーが出る
$ brew install pango ==> Installing pango dependency: pixman /usr/local/Cellar/pixman/0.22.2: 9 files, 1.0M, built in 56 seconds ==> Installing pango dependency: cairo ==> Exit Status: 2 http://github.com/mxcl/homebrew/blob/master/Library/Formula/cairo.rb#L20 Error: Failed executing: make install These existing issues may help you: https://github.com/mxcl/homebrew/issues/7658 https://github.com/mxcl/homebrew/issues/8144 https://github.com/mxcl/homebrew/issues/8491
OSのバージョンが同じだったissueshttps://github.com/mxcl/homebrew/issues/8144 のオプションをつけてみる
$ brew install cairo --use-clang /usr/local/Cellar/cairo/1.10.2: 95 files, 6.6M, built in 110 seconds
キタワー
$ brew install pango /usr/local/Cellar/pango/1.28.4: 129 files, 3.9M, built in 2.3 minutes
すんなり！
- n度めの正直なるか？
$ gem install rabbit checking for gdk-pixbuf-2.0... no
世の中そう甘くはない
$ brew install gdk-pixbuf ==> Installing gtk+ dependency: jpeg /usr/local/Cellar/jpeg/8c: 17 files, 1.4M, built in 37 seconds ==> Installing gtk+ dependency: libtiff /usr/local/Cellar/libtiff/3.9.5: 235 files, 3.5M, built in 44 seconds ==> Installing gtk+ dependency: jasper /usr/local/Cellar/jasper/1.900.1: 33 files, 1.0M, built in 49 seconds ==> Installing gtk+ dependency: ping ==> Exit Status: 1 http://github.com/mxcl/homebrew/blob/master/Library/Formula/gdk-pixbuf.rb#L21 These existing issues may help you: https://github.com/mxcl/homebrew/issues/4970 https://github.com/mxcl/homebrew/issues/7400 https://github.com/mxcl/homebrew/issues/7654
エラーメッセージをよく読むと、
configure: WARNING: *** TIFF loader will not be built (TIFF library not found) *** configure: error: *** Checks for TIFF loader failed. You can build without it by passing *** --without-libtiff to configure but some programs using GTK+ may *** not work properly
ライブラリが認識されていない。dependencyでインストールされたライブラリのlinkがうまく貼られていなかったみたい。
その後、以下のlinkをsudo権限で設定してから実行したら無事にインストールできた。$ sudo brew link libtiff $ sudo brew link jpeg $ sudo brew link jaspar
インストール後に忘れずに
$ sudo brew link gdk-pixbuf
そもそも、brew install時のユーザー権限がよくない？
sudo brew install ができないのをここを見て解決。 - ひたすらライブラリを入れ続けるしかない
$ gem install rabbit checking for gtk+-2.0... no
$ brew install gtk+
成功。
$ gem install rabbit checking for librsvg-2.0... no
はい、次。
$ sudo brew install librsvg ==> Installing librsvg dependency: intltool /usr/local/Cellar/intltool/0.41.1: 15 files, 200K, built in 7 seconds ==> Installing librsvg dependency: libcroco /usr/local/Cellar/libcroco/0.6.2: 37 files, 972K, built in 44 seconds ==> Installing librsvg /usr/local/Cellar/librsvg/2.34.1: 50 files, 1.6M, built in 47 seconds
inittoolをいれる際に以下のWarinigが出ていた。
Warning: m4 macros were installed to "share/aclocal". Homebrew does not append "/usr/local/share/aclocal" to "/usr/share/aclocal/dirlist". If an autoconf script you use requires these m4 macros, you'll need to add this path manually.
よし、次。
$ gem install rabbit checking for poppler-glib... no
$ sudo brew install poppler --with-glib /usr/local/Cellar/poppler/0.18.1: 447 files, 21M, built in 2.9 minutes
残っているログはここまで。
このあとまた躓いています。
————
ということで、Rabbitを触ってみようと思います。
1回社内の発表で、うさぎとカメを使ってみたいなー。
mavenで依存ライブラリが同包されている実行可能なjarファイルを作成する
2月 23rd
実行可能なjarと依存ライブラリが梱包されたzipアーカイブを作る、という方法で実行可能モジュールを作成していたのだけど、かなり無駄な構成になっているなと感じていた。
一つのjarファイルに全てのライブラリが同包されて、そのjarが実行できたほうがずっといい。
ということで今回の目標
- コマンドから java -jar で実行可能なエントリーポイントを含むjarを作る
- 上記jarで必要なライブラリ類はjarに同包されていること
外部に依存することなく1つのjarファイルだけでエントリーポイントからの処理が実行できるようにする。
使用するプラグインは maven-assembly-plugin。
maven-assembly-plugin
デフォルトアーカイブ jar-with-dependencies を使用し、エントリーポイントとなるmainClassを定義しておくだけで、目的のjarファイルが作成される。
＜pom.xml＞
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>sample.Main</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-sample-jar</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
これだけ。前と比べてpom.xml自体もとても簡潔になった。
最初にこの設定が出来なかったのは、親モジュールに[descriptors]が定義されていたため。
親モジュールにこれが定義されていると、アセンブリファイルの位置の上書きはできるけど、アセンブリファイルを”使わない”という設定ができない。
[descriptorRefs]を使用してもアセンブリファイルがないとビルドエラーとなる。
今回はプロジェクトの構成をもう一回見なおして、[descriptors]を親モジュールで定義する必要がないとわかったので、それぞれのモジュールで[descriptors]か[descriptorRefs]を定義させるようにして解決。
mavenは使い方になれるまで難しい。
実践アジャイルテスト読書会 01に参加しました
2月 23rd
2月20日（月）に開催された、実践アジャイルテスト読書会 01に参加しました。
今回から始まった読書会、どのようなものかというと（ATNDより）
- 「 実践アジャイルテスト 」をベースにテストに関して学ぶ
- 勉強会の中では書籍の読み合わせ（輪読）は行わない
- あらかじめ該当の章を読み進めて来ることが前提（書籍の購入は必須）
- 担当者が予習して文書(sphinx)にまとめておきそれを元に発表していく形式
大学時代のゼミを思い出します。
1回1回が結構ヘビーになりそうです。
（Head First JavaScript読書会もあるし、アジャイルサムライ読書会もあるし…）
ただ、第1回と第2回は概要についての話になると言う事で「書籍購入不要」。
本を購入せずにどのような勉強会か空気をつかもうと思い参加しました。
まぁ、書籍を持っていなかったの、私だけだったんですけどね…。
アジャイル開発の中でのテスターの重要性
今回の範囲は「1.アジャイルテストとは？」。
大きく分けて以下の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回目を終えて
本の内容として、とても高い所を目標にしているので、現実で実現しようと思うと困る所や足りない所がたくさん見えてきそうです。心が折れそうになることもあるようです。
また、本自体も厚く、読み進める事自体がかなり難しそう。
しかも予習必須…！ とてもハードな読書会です。
でも、だからこそ、１人でやっても無理なので読書会で学んでいくのが良いのかな、と思いました。
（ということで、読書会中に書籍を購入しました 
)
次回もがんばってついていきたいです。
UIについて語りたいの続き
2月 21st
前回、書きそびれた分を追記しようと思います。
「キャンセルできる」ということについて。
「グラフィックデザイナーのためのユニバーサルデザイン実践テクニック51」
ワークスコーポレーション 中川 聰 (著), トライポッド・デザイン (その他)
前回の記事を書いたあとにこれを読んでたのですが、
Hokkaido.pm#6でやったLTのスライドとかぶる部分が多くて、
LTでは説明したのに、書いてない「キャンセルできる」ことについて、
語ろうと思います。
「キャンセルできる」とは、どういうことなのか？
これは、こないだのスライドで以下のように説明しました。
- 設定内容を適用せずに破棄できる
- 時間の掛かる処理を中断できる
- 元に戻す・やり直しができる
個人的に、なぜこれらを重要視するかというと、
ユーザーが安心してその機能を試せるようにしたいからです。
どんなにすばらしい機能でも、使われなければ評価されません。
それと同時に、これらの実装はどれも簡単ではありません。
本当に「キャンセルできる」必要があるのか、
これがないとどうしても使って貰えないのかを検討する必要があります。
そして、もう一つ大事なことがあります。
それは、「キャンセルできる」ことが一目で分かることです。
例えば、アンドゥ・リドゥのボタンが目立つところにあれば、
ユーザーは安心してその機能を試すことが出来ます。
時間の掛かるバッチ処理も、中断する手段が用意されていれば、
やり直せるという安心感から気軽に利用して貰えます。
今のところ、言いたいことは言い尽くしたと思うので、この辺で。
おやすみなさい。
UIについて語りたい
2月 21st
そろそろそういうタイミングが来たと思うので、
カジュアルに書き残そうと思います。
まずは、書籍の紹介。
というのも、この業界に入ってGUIソフトに携わっていた頃、
誰に教わる訳でもなく、これらの本を実践することで学んだので。
「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版
第14回アジャイルサムライ読書会 @札幌道場 開催
2月 15th
第14回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は9名。いろんな方向の話をまとめるのは難しいなあーと感じた回でした。
今回の範囲で「グっときた」ところ
全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない
お客さんが隣に座っている
勉強会として
自宅に帰って本を読み返しつつまとめのwikiを書いていて、若干文脈が違うディスカッションがあったかもしれないなと感じました。
「必要な分だけ、必要なときに」分析すること
“そのイテレーションで必要なものだけを分析していたら全体像が見えなくならないかな？”という話題がでました。
ここでいう「分析」がどういうものを示すのかをきちんと考えておくべきだったなあ。
見知らぬ土地に連れて行かれて「君のフィールドはここだ！さあ武器と防具を選んで！」というイメージではなくて、
見知った自分の土地のうち「今回はあの区画を耕そう、そのためには何の準備が必要かな」そんなイメージ。
（あまりに抽象的すぎますが。）
本章Ⅲ部の計画の段階で下地ができていて、それをさらに落とし込むという段階での「分析」だと思うのだけど、この段階では全体像はどこまで共有できていて、どこまで準備できているんだろう。
決して「行き当たりばったり」でも「今までの経験とスキルでなんとかなる」ものでもないと思う。
実際の業務の場合、この段階での「分析、設計」ってどんな事をするのかな。そしてその段階で揃っている情報はどんなものなんだろう。仕様面だけじゃなくて、技術的・アーキテクチャの面はどこまで固まっているんだろう。
この本で文書は不要と言っているかどうか
“会話とちょっとした文章だけで伝わるから文書はそんなに必要ないというのは文書化できない事に対する言い訳じゃないのかな？”という話題がでました。
家に帰って気がついたのだけど、完全に議論の途中で自分が文中から読み落としてしまっていたところがありました。
この本で、同じ机を全員が囲めるような小さなチームに必要はないだろうと言われているのは「形式的な」文書、ですね。
文書そのものが全くなくて良いと言っているのではなく、2,3人のチームでは「基本設計書」「○○仕様書」みたいな形式的な文書を作る必要はないよね、というニュアンスなんじゃないかなと、読み返して感じました。
「形式的な」って原著だとどのような単語になっているのだろう。
重要な事は「全員が正しい方向へ向かっているかを絶えず確認できるようにしなければならない」事。
その方法として文書が必要なチームは必要な文書を作ればいいし、膝を突き合わせてじっくり話し合う事でイメージが共有でき、それでプロジェクトを進める事のできるチームは、話し合いの時の絵や図、カードのメモだけでプロジェクトがうまくすすんでいくんじゃないかなあという個人的な結論に今は至っています。
ペアプロの話
今日はペアプロやってどうだった？得たものは何か？という話ができなかったのでここに書いておきます。
何度かペアプロをして、自分が一番変わったなと思った事は「名前を付ける」事に対する意識です。
クラス名とかメソッド名、パッケージ名（Javaなので）、１人で作っている時はそれなりの名前を付けて終わっていたのだけど、ペアプロをしているときは「本当にこの名前でいいのか」考える時間が増えました。
（そういうペアに恵まれた事が多かったと言う事もあるのかな）
新しいクラスやメソッドを作る、ということはペアプロ中の大きなイベント事なので
「さてどうする」とじっくり話し合うきっかけになる時だったのですよね。
それからは１人でコードに向かう時にも「名前大事」を忘れないようにしています。
みんなはどういう風にペアプロしているのかな、どういう時に困るんだろう。
また今度聞かせてください！
運営の立場で
「適切な話題をきちんとテーブルに載せる」「話をぶった切らない、雑にまとめない」「きちんとした言葉を選んで伝わるように話をする」、とっても難しいなあ。
「この本が本当に伝えたいポイントはどこか」をもっとしっかり考えたいなと思いました。
どうやって進めるのが良いか、14回開催しながらまだまだ試行錯誤中です。
あと今回は時間配分をミスりました。
ちょっと長めの休憩時間を取ったのもあって、途中で終わってしまったセクションには進まなければ良かったかなーと思っています。
実際にどうやってペアプロをやっているか、困った事、ペアプロをやって良かったと思った事、変わった事とかみんなの話を聞く時間を持ちたかった X(
反省点が多い回です。
でも、今回も楽しく充実した時間を過ごせました。
バレンタインデーと言う事で、皆さんにコーヒーとチョコレートを差し入れしました 
（写真を撮るのを忘れたのでありました。ご想像でお楽しみください）
ディスカッションをまとめたwikiはこちらになります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120214
最後に、場所を提供してくださっている弊社に感謝。
（今回はコーヒーもいただきましたありがとうございます）
また次回から頑張りたいです！