2016-12-21

短時間勉強会のススメ

最近社内で短時間勉強会を行っている。特徴としては、

1時間〜1時間半くらいで終わる
参加者、主催者が特に事前準備をしない

ことがあげられる。

たとえば"他事業部のサービスのソースコードを読む会"をやったときは、

30分間他事業部のサービスのソースコードを各自読み、Wikiページ(ちなみにうちの会社ではConfluenceを使っている)に感想や参考になりそうな点を書き込む。
その後30分〜60分間、各自感想や参考になりそうな点を発表して、意見を交換する

といった流れだ。こういう形式なら参加者も主催者も準備が特に必要なく気軽に開催できる。

ここ最近やった会は以下だ。

StyleGuideを読む会

Ruby, RailsのStyleGuideを読む。読んだ結果の感想や気付き、疑問点等々をWikiページに書き込み、各自みんなで話しあう。
StyleGuideを読んで理解することはコードを書くうえでMUSTなのだが、まだRubyやRailsのコードをあまり書いたことがないメンバーがいたり、また以前StyleGuideを読んだ人も意外と忘れていたりするので、開催してみた。
StyleGuideを読んだことがないメンバーにはいいきっかけになったし、またお互い良いスタイルがなにかの認識合わせができてよかったと思う。

他事業部のサービスのRails ソースコードを読む会

大規模サービスのRails ソースコードを読む機会ってあまりなく、大きなサービスをRailsで作っていると若干不安になることがある。そのため他事業部のサービスのRails ソースコードを読むことで、引き出しを増やしたり、良い設計や実装を自分のサービスに取り込もうという企画。
自分が知らなかった便利なGemを使っていたり、参考にできそうな設計がされていたりして、有益な会になった。

NewRelicをみんなで触ってみる会

NewRelicというパフォーマンス監視ツールがあり、それを導入しようと話がすすんでいた。
ただ、一方的に導入しても他のエンジニアが使わなければ宝の持ち腐れになってしまう。
そのため、導入前にみんなでNewRelicを触ってみる会を設けた。
これも例によって30分間各自NewRelicを触ってみて、その結果の感想だったり、気づいた便利な機能だったり、こういうことが解決できそうといった感想をWikiページに書き込み、そのあとの30分間で各自発表しあう形式にした。
これによって自分も知らなかった便利な機能を知ることができたり、各自がNewRelicを使うことでどんなことが解決できそうか理解することができた。

開発環境共有会

便利なツール1つとっても知っているだけで生産性が上がることってありますよね。そういったお得な情報をみんなで共有して各自の開発速度を上げようという趣旨の共有会
例えば、普段使っている便利なツール、便利な設定、便利なコマンド、使っているキーバインド、使っているシェル、使っているエディタ、使っているキーボード、マウス、取り入れている開発スタイル、タスク管理方法などをWikiページに書きまくって、各自発表する。
エンジニアはツールや環境に凝る人が多いので、会は結構盛り上がる。
知らなかった便利情報が集まって非常に有益な会になった。Wikiページに書いてあるので参加しなかったエンジニアもみることができるのがまたいい。

一部、勉強会というより共有会に近いですね。

あとこのスタイルは読書会でも適用できて、30分間各自指定した本を読みその感想をWikiページに書いて、残り30分間感想を発表しあうみたいな形式が可能です。 (このスタイルは以前同僚がやっていて、今回の一連の勉強会もそのスタイルを拝借した)

短時間で終わって参加者主催者が特に準備がないスタイルは気楽にできるので、ぜひ皆さんもやってみてはいかがでしょうか。

2016-11-03

ネストしたHashからOpenStructを作る

Ruby

HashからOpenStructを作成する場合、

pry(main)> OpenStruct.new({hoge: 1})
=> #<OpenStruct hoge=1>
pry(main)> OpenStruct.new({hoge: 1}).hoge
=> 1

のようにすればよい。しかしネストしたHashだと以下のようになる。

pry(main)> OpenStruct.new({hoge: {fuga: 2}})
=> #<OpenStruct hoge={:fuga=>2}>
pry(main)> OpenStruct.new({hoge: {fuga: 2}}).hoge
=> {:fuga=>2}
pry(main)> OpenStruct.new({hoge: {fuga: 2}}).hoge.fuga
NoMethodError: undefined method `fuga' for {:fuga=>2}:Hash
from (pry):29:in `<main>'

やりたいのは、再帰的にOpenStructを適用して、 xxx.hoge.fugaでアクセスできるようにすること。 https://github.com/aetherknight/recursive-open-struct のようなgemを使えばできるが、以下のようにいったんJSONに変換すると簡単に再帰的にOpenStructに変換してくれる。

pry(main)> h = {hoge: {fuga: 2}}
=> {:hoge=>{:fuga=>2}}
pry(main)> JSON.parse(h.to_json, object_class: OpenStruct)
=> #<OpenStruct hoge=#<OpenStruct fuga=2>>
pry(main)> o = JSON.parse(h.to_json, object_class: OpenStruct)
=> #<OpenStruct hoge=#<OpenStruct fuga=2>>
pry(main)> o.hoge.fuga
=> 2

2016-11-03

FactoryGirlで Hashを定義

FactoryGirl Rails

FactoryGirlでARではなくhashのモックデータを返してほしいときがある。

そういう場合は以下のようにすればよい。

FactoryGirl.define do
  factory :dog, class: Hash  do
    id 1
    name 'john'
    color 'black'

    initialize_with { attributes }
  end
end

initialize_with は初期化処理を定義できるもので、attributesはFactoryGirlのメソッドだけどattributesの戻り値がHashなのでそのまま使っている感じ。

利用するときはいつものようにbuildが使える。

dog = FactoryGirl.build(:dog, name: 'taro')

参考： http://stackoverflow.com/questions/10032760/how-to-define-an-array-hash-in-factory-girl

2016-10-09

Capybaraで非表示要素を対象とする

Rails Capybara

Capybaraで非表示(style="display: none;")になっている要素を検索対象にできないか調べたら、 visibleオプションが使えることが分かった。

例えば、以下のような感じだ

find("#hoeg", visible: false)
have_selector('.hoge', visible: false)
have_css('#hoge', visible: false)

また Capybara.ignore_hidden_elements = falseとすると、visibleオプションを渡さなくても非表示要素が検索対象になる。

なので、以下のようにしてもよい。

before { Capybara.ignore_hidden_elements = false }
after { Capybara.ignore_hidden_elements = true }

参考 http://qiita.com/upinetree/items/4d4022c90ce32b68c38d http://kakakakakku.hatenablog.com/entry/2015/05/14/124653

2016-10-09

Slimのスタイルガイド

Slim Rails

テンプレートエンジンのSlimのスタイルガイドはないものかと探していたら見つけた。

https://github.com/idmean/slim-style-guide

Slimはシンプルなのでそんなにどう書くか決めなくても大丈夫なんだけど、いくつかは迷うときがある。

例えば属性の定義は以下の3種類が考えられる。

a href="http://slim-lang.com" title='Slim のホームページ' Slim のホームページへ
a[href="http://slim-lang.com" title='Slim のホームページ'] Slim のホームページへ
a(href="http://slim-lang.com" title='Slim のホームページ') Slim のホームページへ

そういったときスタイルガイドは役にたつ。

https://github.com/idmean/slim-style-guide は見てもらうと分かるが、とても納得感があるスタイルガイドとなっている。しかしいかんせんstar数が少ないので、見て気に入ったらstarを押そう。

2016-09-22

API BlueprintについてLTをした

エンジニア飲み会があったので、ちょうど調べていたAPI BlueprintについてLTをした。

スライド↓

API Blueprintとその周辺ツール

API Blueprintは読み書きしやすいのが特徴だ。

JSON SchemaはAPIドキュメントとしてはそのままだと読みにくいし、Swaggerはなんか重厚だし…という人におすすめ。

まあでもSwaggerのyamlは読みやすいよね。 Open API Initiativeで標準フォーマットになったから数あるAPIドキュメントツールの中で数年後生き残るとしたらSwaggerが可能性高いと思う。

JSON Schemaはリクエストやテスト時にデータをチェックしてくれるツールが充実している印象だった。でもそこまで必要かなー？例えば社内APIだったらそこまで厳密にチェックしなくてもいい気がする。またAPIドキュメントツールに依存し過ぎたくないのでどうにしてもアプリケーション側でデータのチェックすると思うし。テスト時も値の型や構造だけではなく値の内容までチェックするでしょどうにしても。

RAMLはもっと評価されてもよさそうだけどいかんせん後発すぎたのか人気がない…。残念だ。

2016-08-21

rack-attack gemでユーザごとにアクセス数を数える

Ruby

http://shepherdmaster.hateblo.jp/entry/2016/08/21/000115 でも紹介しましたが、 https://github.com/kickstarter/rack-attack という便利なgemがあります。

n秒間にn回アクセスされたらアクセスを弾くThrottles機能を使う場合、 IP単位でアクセス数を数える場合もありますが、ユーザ単位で数えたい場合もあると思います。

そういう場合は以下のようにsessionに入っている(だろう)ユーザidを返せばよいです。

class Rack::Attack
  throttle('req/ip', :limit => 10, :period => 10.second) do |req|
    req.session[:user_id]
  end
end

StyleGuideを読む会

他事業部のサービスのRailsソースコードを読む会

NewRelicをみんなで触ってみる会

開発環境共有会

他事業部のサービスのRails ソースコードを読む会