おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

ActionCableでフィーチャスペックを書く

最近自分の作っているサービスにActionCableを導入しました。そこでフィーチャスペックを書いていくつかハマったので内容を共有します。

使っているのはcapybara & poltergeistです。

Capybara.serverをpumaにする

Capybaraのデフォルトのサーバは、ざっと見た感じRailsアプリを別スレッドで動かしているだけのようです。これではActionCableを動かすことはできません。ActionCableを利用するにはpumaを使う必要があります。

次のようにすれば Capybara はpumaをサーバとして使ってくれます。

Capybara.server = :puma

これでオーケー…と言いたいところですが、まだ落とし穴が2つほどあります*1

puma のデフォルトワーカ数(プロセス数)を1にする

pumaはconfig/puma.rb があると、テスト時でもそれを設定に利用します。developmentやtestの環境ではActionCableのアダプタはasyncが設定されているため、pumaのプロセス数が2以上だとうまく動かないケースがあります。

次のように環境変数が設定されていない場合は1になるようにしておきましょう。

workers ENV.fetch("WEB_CONCURRENCY") { 1 }

ActiveJobのテストと環境を分ける

前提として、ActiveJobのテスト用のアダプタはデフォルトの:testです。

Capybaraデフォルトのサーバを利用する場合は同一プロセス内でサーバが動くので、サーバ内でキューにジョブを詰めたとき、テストコード内でassert_enqueued_jobsなどのメソッドで実際にキューにジョブが入ったかを確認することができます。しかし、サーバをpumaにした場合は別プロセスになり、サーバ内でキューにジョブを詰めても、テストコード内では確認することができません。

ではActionCableを利用した場合だけサーバをpumaに変えればいいのでは?と思い次のようにしたのですが、フィーチャスペックが不安定になったのでやめました。どうやらserverはdriverのように頻繁に変更するようにはできていないようです(深掘りはしていません)。

config.around(:example, websocket: true) do |example|
  default_server = Capybara.server
  Capybara.server = :puma
  example.run
  Capybara.server = default_server
end

とりあえず次のように、通常のテストはActionCable以外をテストし、ActionCableを使ったテストだけを実行したい場合は環境変数をつけるようにしました。

if ENV['WEBSOCKET'].present?
  config.filter_run_including :websocket
else
  config.filter_run_excluding :websocket
end

これでテストが通るようになりました🍏

*1:僕はきっちりハマりました><

rspec-style-guideの英語版ができた

先日のRails Developer Meetupで発表したrspec-style-guideですが、ありがたいことにPull Requestをいただき英語版ができました。

rspec-style-guide/README_EN.md at master · willnet/rspec-style-guide

Pull Requestしてくれた@gazayasさんありがとうございます!

内容に関する意見などは今のところまだ来ていないのですが、英語版ができたことで広く目にとまる可能性が出てきましたね。

関連情報

Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記

ぎんざRuby会議を開催します

毎月第三火曜日に開催しているginza.rb、開催を始めてからかれこれ4年になります。このままいくと8月にはなんと第50回のミートアップをむかえることに。というわけで拡大版を開催することにしました。

ぎんざRuby会議です。

f:id:willnet:20170524230229p:plain

公式サイトにも気合が入っています。ginza.rbに参加したことのある人はおなじみ@ken1flan画伯の「ざぎんねこ」を使って@ken_c_loさんにうまく誂えてもらいました。

日付は8月5日(土)、テーマはRailsです。このテーマにした理由は、Railsの話がメインの日本のカンファレンスが需要の割に少ない気がしたことと、あとはもちろん*1Railsが好きだからです。

招待講演には@amatsudaさんと@kamipoさんというビッグネームに登壇いただけることになりました。

残りの発表枠は公募としています。通常発表枠(25分)とLT枠(5分)です。Railsの話をしてくれる方、いま絶賛大募集をしています*2。あなたが温めている秘伝の知見を教えてください。ぜひぜひよろしくお待ちしています。

ぎんざRuby会議01 CFP - Ginza.rb

話を聞きに来たいという方は予定を空けてお待ち下さい。6月頃に募集を開始します。

*1:言うまでもないですね

*2:6月9日締め切り予定です

Rails Developers Meetup で綺麗なテストコードの書き方について発表した

昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。

Rails Developers Meetup #1(東京会場) - connpass

資料はこちら

余談

もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。

昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。

willnet/rspec-style-guide

お願い

今回まとめた内容はあくまで僕が考えるテストコードの書き方なので、異論反論あると思います。意見ある方はIssueなりPull Requestなり、ブログエントリにまとめるなりしていただけるととても嬉しいです!

メドピア開発者ブログに寄稿した

お手伝いしているメドピアさんのブログに、Railsのコード可読性を保つための知見の一つであるform objectについて寄稿させていただきました。

form objectを使ってみよう - メドピア開発者ブログ

最近は技術顧問として複数社のエンジニアに対して、主にRailsアプリケーションを可読性を保ちつつ作るための知見を伝えるような仕事をやっています。具体的な仕事内容については別エントリで書くかもしれません。

寄稿した内容の補足

エントリ後半の、「Active Recordモデル中のvalidationやメソッドをform objectに移してモデルをスリムにする」話はジョーカーさんのツイートのように、チーム全体で徹底できていないとダメなので取り入れるには若干のハードルがあります。

ただ、エントリ前半のActive Recordを使わないケースでform objectを使うのはデメリットがほぼないはずなので全国的に広まってほしいなという気持ちです :pray:

寄稿先のエントリでも書きましたが、複数の会社で同じことを何度も説明するのは大変です><。説明回数を減らすために、他の知見もこのブログやお手伝い先のブログなどで積極的にまとめていくつもりなのでご期待ください*1。もし、うちにも寄稿してほしい!という会社さんありましたらご連絡ください*2

*1:忙しいので時間かかるかもしれません><

*2:予め断っておくと有料です><

株式会社ウィルネットを設立した

いわゆる法人成りです。

かっこいい会社の名前が全然思いつかず*1、結局ハンドルネームを採用しました。このブログのタイトル(おもしろwebサービス開発日記)もだいぶアレな感じで、自分の命名センスの無さに震えますね><

単に名義が変わっただけで、特に何があるわけではないのですがこれからも引き続き頑張っていこうと思います。よろしくお願いします。

一応例のリスト置いておきますね (( ⁰⊖⁰)/)

*1:あまりに思いつかなかったので株式会社ベホマズンなどが候補に入っていた

ソフトウェア開発者採用ガイドを読んだ

読みました。自分はフリーランスなので直接誰かを採用することはないですが、お手伝いしている会社の方に「どうやったらいいwebエンジニア採用できますかねー?」と聞かれることがよくあるので、そのヒントになるかなと思い。

ソフトウェア開発者採用ガイド
Joel Spolsky
翔泳社
売り上げランキング: 406,688

感想

基本的に自分の考えているやり方で間違ってなさそうだという気持ちになれました。

  • エンジニアにとって良い環境を整える
  • いいエンジニアはまず応募してこないので基本こちらから出向いて探す
    • コミュニティやインターンシップなどを利用する
  • 面接の時は、その人が問題に対してどのようにアプローチするのか見る
  • 迷うくらいの人であれば採用しない

よくweb上で見かけるエンジニア採用関係の文章は、この本が元になっていることが多いので違和感なく読めて当然なのかもしれません。

しかし「どうやったらいいwebエンジニア採用できますかねー?」にはやっぱり「頑張るしかないですね」としか答えようがないですね。難しい。