RailsガイドでOSS貢献するのはどうだろうか

日本語版のRuby on Rails ガイド、日本人Railsエンジニアなら一度はお世話になったことがあると思うのだけど。読んでいるとtypoだったり、てにをはがちょっとおかしいところだったり、古いバージョンの記述のままだったりするところがあります。

ぼくは技術顧問業の一環でよくRailsガイドを読む機会があるので、そういうのを見つけたらなるべくPull Requestを送るようにしていたらコミット権をいただきました。

yasslab/railsguides.jp: Ruby on Rails Guides in Japanese (Railsガイド)

↑に普通に日本語でPull Requestを出せば大抵すぐにマージされるので、読んでいてここちょっとおかしいのでは？と思ったら気軽にPull Requestを投げるようにするとみんな幸せになるはず。日本語でPull Requet投げられるので、OSSに貢献というのをやってみたいけどどうしたらいいのかよくわからないみたいな人にオススメ。

例: Fix typo by willnet · Pull Request #491 · yasslab/railsguides.jp

あとは日本語版の間違いかな？と思ったら、原著が間違えていたという例もあります。その場合は、rails/railsにPRを投げることになります。Railsガイドの原著は本体のソースコードと一緒に管理されているのでした。

例: [ci skip] Add a missing space before closing curly braces by willnet · Pull Request #31312 · rails/rails

こういうしょぼいコミットでもRails Contributorsに反映されるので、積極的に見つけてコントリビューターの順位を上げていくと楽しいと思います。

もうちょっとちゃんと貢献したい人は、新規の章や節を探して追加してみるのが良いかと。例えば最近原著でActive Strorageの章ができたので、こういうの訳してPRくれたりするとみんなとても嬉しいはず。

というわけで、みなさんからのPull Requestお待ちしています。

Rails Developers Meetup 2017でレールの伸ばし方について話した

Rails Developers Meetup の年末拡大版である、Rails Developers Meetup 2017で発表させていただきました。

Railsアプリケーションの可読性を保ちつつ開発をすすめるにはどうしたらよいか、みたいな話です。資料はこちら

所感

この辺の情報は、英語圏だとちらほら情報あるのですが、まだまだまとまった統一見解みたいなものはなくそれぞれ思い思いのやり方でやっているような状況です。日本の現場だと、可読性を保つための方法はほとんど共有されておらず、共有されているとしてもチーム内で口伝に近いやり方*1で行われており、みんなの形式知になっているとは言い難いです。

楽に可読性の高いコードを書くための形式知(もしくはツール)があるとみんな幸せになれると思うので、ブログ書きやYubaの開発の進捗を頑張りたいと思います＞＜。

*1:コードレビューのときなどで指摘する

RejectKaigi2017でファイルアップロードについて発表した

先日行われたRejectKaigi 2017でファイルアップロードについて発表しました。資料はこちら。

内容的には、WEB+DB PRESS Vol.95で書いたファイルアップロード話を最新にしたものになります。Rails5.2で新しく追加されるActive Storageというファイルアップロード機能を紹介しつつ、ファイルアップロード全般の話題について触れています。

ファイルアップロードをただしく実装するにはそれにまつわる様々な要素についての知見が必要で、webエンジニア的には腕の見せ所ではないかと思います。Active Storageの登場でファイルアップロードについての知見が広まって、ただしく実装できる人が増えるといいなと思います(( ⁰⊖⁰)/)

あわせて読みたい

WEB+DB PRESS Vol.95

posted with amazlet at 17.08.20

小出 淳子 黒澤 剛志 牧 大輔 横江 亮佑 山口 貴也 尾藤 正人 佐藤 琢哉 中橋 研太郎 田中 慎司 小西 裕介 伊藤 直也 稲富 駿 前島 真一 長野 雅広 山際 康貴 のざき ひろふみ うらがみ 岡林 大 遠藤 雅伸 ひげぽん 海野 弘成 はまちや2 竹原 大場 寧子 大場 光一郎 野々下 裕子
技術評論社
売り上げランキング: 281,045

Amazon.co.jpで詳細を見る

「Rails5.1時代のアプリケーション開発」というテーマで発表した

昨日「Rails5.1時代のアプリケーション開発」というテーマで発表しました。

MedBeer -Rails 5.1での開発について- - connpass

スライドはこちら。内容的には、web開発難しいので頑張って勉強していきましょうというメッセージになっています。若干エモ寄り。

web開発における知の高速道路みたいなものがあるとよいのですが、学ばなければいけない要素技術は日に日に増えていくので頑張って道路を作ってもすぐ陳腐化していきます。なのでレベルを上げて物理で殴るのが現状の最適解かなと。みんなでレベル上げ頑張っていきましょう💪

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

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

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

Capybara.serverをpumaにする

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

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

Capybara.server = :puma

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

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

(追記)最近のcapybara(2.15.1以上?)を使っている場合、config/puma.rbの設定に関わらずワーカ数は1に設定されるようになったみたいです。

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

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

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

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

(追記)コード見た感じ、同一プロセス内の別スレッドでサーバ起動しているように見える&&実際にpumaで問題なく動くようだったのでこの節は読み飛ばしてください＞＜

capybara/server.rb at master · teamcapybara/capybara · GitHub

前提として、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会議です。

公式サイトにも気合が入っています。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日締め切り予定です