Fukuoka.rbでエクストリームフィッシュボールをして、エクストリームな体験をした #fukuokarb

成果です。

github.com

ひょんなことから @udzuraさんとペアプロをする機会を得たのですが、成果は出るわ勉強になるわで最高体験でした。教えてもらうことが久しぶりで新鮮過ぎて

とりあえず豪華だった…あとメタプロRuby読めって感じだった。 @udzura さんありがとうございました！ #fukuokarb
— k1LoW (@k1LoW) 2015, 12月 10

うずら無双な時間だった #fukuokarb
— k1LoW (@k1LoW) 2015, 12月 10

興奮冷めない #fukuokarb
— k1LoW (@k1LoW) 2015, 12月 10

な感じでした。

awspecに追加された強力な実装についてはまたいつか紹介するとして、とりあえずいろいろメモを記録。

あ、

「メタプロRuby早く読んだほうがいい」と10回以上言われました。

まずは実装の方針について検討・共有

いきなりソースコードに向かうと思ったらそうではなかったです。

2時間のうち、1時間くらいは設計の話だったような気がします。SDKのドキュメントと、awspecのソースを表示しつつ、方針を決めました。

で、決まった今回の実装方針はこちら。

f:id:k1LoW:20151211185231p:plain

とてもわかりやすい！

特に緑でウニョウニョしている部分( ResponceReader )が今回の実装のポイントです！（本人たちは議論しながらなのでばっちり）

「`respond_to` がわからないなんてちょっと。。。」

respond_to がぱっとでてきませんでした。これがレベル低いのかどうかすらわからないレベル。ちょっと能力差がありすぎました。（ちなみに使っていました。。。）

Rubyに馴染んでいないのがまるわかり。

「メモ化してください」「え？」

def resource
  @resource ||= Awspec::ResourceReader.new(Aws::S3::Bucket.new(@id))
end

||= の部分ですね。まず「メモ化」の言葉の意味が出てこなかった（そういう言葉があるのは知っていた）です。

その後、説明をしてもらうとすんなり理解。シングルトンとの違いもすっきり。

テストは実装方針にしたがって順番に

今回は最終的に

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq 'my-bucket-owner' }
end

のテストが通れば完成なので、自分はついつい上のテストが通ることを急ぎがちなのですが、 @udzuraさんはしっかりと、「順を追って」「まずは」といいながら

describe s3_bucket('my-bucket') do
  its(:real_resource) { should be_an_instance_of(Awspec::ResourceReader) } # まずは直接アクセスしてインスタンスを確認
  its('real_resource.name') { should eq 'my-bucket' } # アトリビュートがStringの場合
  its('real_resource.acl') { should be_an_instance_of(Awspec::ResourceReader) } # アトリビュートがAws::Resources::Resourceの場合
  it 'should be a Exception when black list method is called' do # ブラックリストなメソッドを呼んだ場合
    expect { subject.delete }.to raise_error(
      Awspec::BlackListForwardable::CalledMethodInBlackList,
      'Method call :delete is black-listed'
    )
  end
  its(:acl) { should be_an_kind_of(Awspec::ResourceReader) } # 最終形態でのアクセス方法でインスタンスを確認
end

と、実装を進めながら順にテストを追加していきました。

今回は特に基盤となる部分の機能追加でもあるので、「あーね！あーね！」と言いながら関心していたら「博多..」と言われました。

正しい値を知るために、テストREDの結果を利用する

自分はstubの値を知っているので、

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq 'my-bucket-owner' }
end

とすぐ書いてしまうのですが、そこをあえて

describe s3_bucket('my-bucket') do
  its('acl.owner.display_name') { should eq '' }
end

と書いて、一旦テスト結果をREDにし、さらにテスト結果から my-bucket-owner というstubの値を知るということをしていました。

というかテストを書くとき、必ず結果をREDにするところからスタートしているのが、慣れているなーと思いました。（ちょっとだけTDD？）

bin/console bin/setup と exe/ ディレクトリとpry

@udzura さんに「あれ？」と言われて知った事実。

github.com

ちなみに bundle gem で生成されたのは覚えているのですが「なんだこれ、知らんわ」と消していました。。。

あと「pryがないなんて耐えられないんで。。。」とpryが追加されました。

対話インターフェースで確認する習慣がないです。。。どうやったらそういう習慣になるんだろう。

（こちら修正しました）

感想

教えてもらうのがめちゃくちゃ楽しい。最高体験。
Ruby力足りない。でもそれが楽しい。最高体験。
他の人のコーディングを見るだけで勉強になる。最高体験。
Emacs。最高。

また、是非やりたいです！

そんな豪華な体験ができる勉強会がFukuoka.rbです。みんなも来たほうが良いと思いました。

以上成果報告でした！

あ、