ひと月くらい前の話だと思うが。

内浦漁港の朝一で干物なんかを買って、隣のミトシーへ。

ペンギンはなかなか可愛かった。

るるぶ静岡伊豆浜名湖富士山麓11 (国内シリーズ)

ジェイティビィパブリッシング / 840円 ( 2010-10-08 )

お疲れ様でした。今回はまさかの二人ぼっちだが色々はかどった。自由気ままに作りたいものをつくる他に、簡単なテーマを決めて作るようなトラックを用意すればいいんだろうか？と思ったけど、そうすると誰か面倒見るヒトが必要になるからなぁ。それよりも、終了前30分くらいとって成果の発表をする時間を用意したほうがいいのかなぁ。

お昼はコミュニティfの近所のプレアーテで。

@ringtaroがBackbone.js触っていて、僕がSpineのコールドリーディングしてたので、二大クライアントMVCフレームワークを極める感じの勢いだったということで。

さて、今までコードリーディングする時はSphinxを使ってたんだけど、doccoっていうツールを知ったので、今回はこっちを使ってみた。

doccoはソースコードに直接コメントを挿入すれば左にコメント、右にソースコードを表示するhtmlを出力してくれるし、コードはハイライトしてくれるし、コメントはmarkdownが使えるので便利だ。一方index.htmlを出力してくれないので、モジュール間の依存関係なんかを綺麗に出力できればいいなぁと。それから更新を自動検出してドキュメントを作りなおす機能と、ローカルサーバーが欲しいかも。

コードリーディングの流れは

1. githubのコードをフォークする
2. ローカルにcloneしてソースコードに注釈を入れてく
3. doccoをはしらせるとdocsというディレクトリが出来てそこにhtmlが出力される
4. コミットしてプッシュ

って感じで調子良く進む。例えばspine.coffeeだとこのようにコンバートされる。

今日のつくる会ではSpineを読んだ。

昨日はhemを読んだ。

お絵描きの好きな娘と一緒に読んだ。よくわからんが、娘はなんかインスパイアされたようだった。

食いつきはよかった。

5日間で学ぶ！お絵描きPhotoshop教室
しぐれ
ワークスコーポレーション / 2100円 ( 2011-08-31 )

僕が参考になったのはこのあたり。

• 顔の比率
• 境界線の追加
• オリジナルパターンの追加の仕方
• クリッピングマスク

「バイト・パートがワクワク動きだす！ 」と副題がついているように、経営者目線で従業員を如何に動かすかっていう話。

経営の立場で見れば参考になることが書いてあるけど、バイトの立場でみた場合「それで得られるものはなんなの？」っていう非対称さは残る。

バイト・パートがワクワク動きだす！ 繁盛店のしかけ48 (DO BOOKS)
山口 しのぶ
同文館出版 / 1470円 ( 2012-02-07 )

料理に「金をかけるか、手間をかけるか」っていう言葉ばあるんだけど、それのバイト版かな。もちろん手間をかけるほうだけど。

幸せそうなキャラクターデザインするようなひとの思考はどうなっているのかな？と思って読んでみた。

キャラクターデザインの仕事―ハッピークリエーター★たかいよしかず
たかい よしかず
大日本図書 / 1470円 ( 2012-02 )

基本的にポジティブ。

ここらへんのシリーズを薦めていたが、面白いんだろうか？

ハチミツとクローバー 1 (クイーンズコミックス―ヤングユー)
羽海野 チカ
集英社 / 420円 ( 2002-08-19 )

今度ブックオフにでも探索に行ってみるか。

3月のライオン (1) (ジェッツコミックス)
羽海野 チカ
白泉社 / 490円 ( 2008-02-22 )

娘の本のチョイスをするのに参考にしている。

なかなかよさそうな機能の割に、いまいち使われてないのが残念。

本を「人生のスパイスに」。そんな、本を紹介したい人が集まるコミュニティです。 作成されたレシピは、全国のカーリルユーザーだけでなく、インターネットを通じていろんなひとに届けることができます。

• カーリル｜レシピ

最近（というかここ2,3年くらい）今の職場で、新しい挑戦はセクションの壁を超えてトピックブランチ的にワーキンググループを作って自主的に議論して上に提案するというスタイルが普通になった。

これはやる気がある人が積極的に議論に加わるので、調子がいいし議論も生産的で楽しい。

が、あるワーキンググループの議論の中で「自分はその（別の）WGに参加してないからコンテクストが理解出来ない」みたいなことを言われたのでちょっと考えてしまった。

トピックブランチは他に影響を与えないで新しいことを試すので、WGも参加者以外には基本的に見えない。だからそういう発言になってしかるべきだし、それはあり方として正しい。一方で全然ワーキンググループに参加しないヒトは振る舞いや思想がメンテナンスブランチのそれに近くなってきているのではないかと。そもそも保守的な考えのヒトが多いからほっといたら保守化するわな、そりゃ。

昔はセクションのトップがそういうヒトにもある程度成長のためのチャレンジを促していたような気がするけど、プロジェクト色が強くなるとどうしても自主的に動けるかどうかが重要視されるよなぁと。

まぁサイエンティストだったら当たり前の感覚だろうけど、企業研究者の8割は単なる労働者でしょ？そういう状況で、こういうやり方が組織論的に正解なのかはよくわからん。

なかなか、面白かった。

大手メーカーが作らない「B級」iPhoneゲームが売れる50の理由
RucKyGAMES
秀和システム / 1470円 ( 2011-12 )

真面目な内容を期待すると裏切られた感が得られるが、行間とか内容の本質を考えながら読めばそれなりに得られるものがあると思う。

僕の場合は参考になることが多かった。

4/8(sun)にいつものコミュニティfで。

• 静岡デベロッパーズつくる会#5

久しぶりにGAEでなんか作ろうかなと思っている。とかいいつつjQuery Mobileにはしるかも。

最近モナド、継続に続く第三の悟りを体験した。それが「モックとスタブの違い」

自分の言葉で表すとすれば、

テスト関心空間の内側にあるのがモックで外側がスタブ

といったところか。

発端はPython Testing: Beginnerでmockerを使っていたのだけど、verifyメソッドの存在意義がよく分からなかった(モックとスタブの違いを理解した今なら、verify必要に決まってんじゃんと言えるわけだが)。

Python Testing: Beginner's Guide
Daniel Arbuckle
Packt Publishing / 3220円 ( 2010-01-31 )

悟りに至るまでにいくつかのサイトを読んだ。

スタブに関しては割りと容易に理解できる。モックとスタブの違いなんかに書いてあるように要するにスタブアウトですね。外界とのインタラクションを絶ち切って(debouple)状態にテストの関心を集中するわけだ。

で、問題はモック。Mock と Stub についてによると

Mock と Stub の違いはテストの観点の違いです。相互作用（振る舞い）中心のテストに利用するのがMockで、状態中心のテストに利用するのがStubです。

これだけだとわからないが、次のパラグラフを読むと

相互作用中心のテストとはテスト対象のシステムと外部のコンポーネントとの間で正しいやり取りがされるかのテスト、いわばプロトコルのテストです。外部のコンポーネントは Mock により置き換えられ、システムから正しい呼び出しがなされているかを監視します。

この文章でモックが何をデカップリングしようとするのかがおぼろげながら見えてきます。

したがって、例えばWebアプリの Controller の単体テストにおいて相互作用中心のテストが正しく行われてパスしているならば、Model が正しく実装された時に Controller が正しく動作するということが、Model が実装されなくても保障されます。

つまり、モックオブジェクトが期待されたとおり過不足なく呼び出されているかを調べるverifyはモックのテストにおいては重要な機能なわけだ。

実際にモックのテストを見ていると、内部の動作知ってないとテストかけないじゃんと思うんだけど、それはモックが必要な場面、モックが有効な場面に書いてあった。

でも、話を聞く限りだとモックというのはテスト対象の実装の中の処理の流れを追う物のようなので、それじゃブラックボックステストにならないじゃないかと思った。それをそのまま言ったら、確かにテストはできるだけブラックボックステストになってた方がいいけど、機能テストやインテグレーションテストのような粒度の大きな単位のテストでは、処理の中で起こる様々な出来事や副作用を色々モニタリングして、すべての処理が期待通りに動いているかどうかを検証しないといけないから、必然的にホワイトボックステストにならざるを得ないと言われた。

僕の場合はここまで読んだら、あーモックとスタブの違いってそういうことなのか！となったので参考になればと思い、メモっておく。