Ruby Weekly #360: 日本語サマリー
職場の Slack の #ruby 窓で Ruby Weekly メルマガが毎週配信されます。その中から面白そうなものをピックアップして、日本語で簡単なサマリーを書くようにしています。そのサマリーをここでまとまさせていただきます。くだけた日本語で失礼いたします。
Highlights
schneems さんは昔 jekyll ブログをうっかり WEBrick でデプロイしちゃった。意外とパフォーマンスが良かった。平均 7ms。Perc95 33ms。スループットは 25 requests/min。
今年もっとも人気な記事は 375 requests/min まで上がったが、WEBrick は 1 dyno で 8751 requests/min まで対応可能。余裕。
NGINX に移行することになったが、パフォーマンスのためではなく、SSL を強制させたかったから。一見大変そうだが static buildpack のおかげで static.json ファイル 1 個置くだけで済んだ。
- 平均 7ms → 3ms
- Perc95 33ms → 10ms
- メモリ使用率もグンと下がった
結論：（jekyll みたいに）静的ファイルをサーブするだけなら WEBrick で十分。
おまけ：WEBrick は意外とマルチスレッド対応。1 リクエスト = 1 スレッド。
RubyVM::InstructionSequence で YARV インストラクションを覗いてみる話
Eventide: A Microservices and Event Sourcing Toolkit for Ruby
イベントソーシング用フレームワーク
先週の Clojure の interpose の話に興味を持った Avdi Grimm 先生が yield 式 Enumerable でリファクターしてみた話。テスト、ベンチマーク付き。
config 系 DSL の作り方。
- PORO 作る
- mixin に移植。再利用できるように
config.hoge = 123がhoge 123になるようにリファクター
注意： メタプロ多め
Apache Thrift シリアライゼーションプロトコールの Ruby バインディングを再実装した Airbnb。
Apache が出しているバインディングはパフォーマンスが JSON 以下。Airbnb の Sparsam は MessagePack と肩を並べる。
Tutorial
kmeans-clusterer gem の k 平均法で教師なし学習を実現させた話。例としてカリフォルニア州 100 大都市を位置でクラスタリングっして、流通センターを設ける場所と数を計算した。
テスト高速化。
build_stubbed使えbefore(:all)使え- 不要な
let!捨てろ - 並列実行しろ
- ファクトリーの不要なアソシエーション捨てろ
- ログレベル変えろ
__dir__ が __FILE__ に勝る理由。コードが短くなるから。
Lint Your Ruby Code with Overcommit and Static Analysis Tools
Linter まとめ
- overcommit （コミットのメッセージやメタデータ）
- rubocop （コード規約）
- fasterer （パフォーマンス）
- bundler-audit （依存 gem の脆弱性）
- reek （コードスメル）
- rails_best_practices
- brakeman （セキュリティ脆弱性）
- foodcritic （Chef cookbooks）
- fukuzatsu （コード複雑さ）
- rubycritic （linter 結果の美しきウェブ UI 報告）
- pronto （linter 対象を指定コミット・ブランチに絞るツール）
Asynchronous Elasticsearch Reindexing with Rails, Searchkick, and Sidekiq
Searchkick + Sidekiq で ActiveRecord データを ElasticSearch にインポートした話。
Ruby 2.3 以前の Integer#dup は TypeError でエラってた。プリミティブのようなものなので複製するのがおかしいから。
2.4 以降はエラー投げずに何もしない。
Story
Why We Broke Our Philosophical Vows to Bring You CircleCI 2.0
CircleCI を一から作り直した理由。
一から作り直しちゃダメだと Joel (on Software) も言った。CI/CD 業社なのに一から作り直すなんて全然 CD になってない。それでも 15 ヶ月かけた作り直した。
弊社インフラが効率のピークに迫った。次のピークまでには、根本アーキテクチャーへの変更が必要だったが、段階的には実装できないものだった。
スコープをなるべく小さく絞った。スパイク、タイムボックス、そして失敗を繰り返した。1.0 と 2.0 を並行でビルドできるようにツーリング改善した。closed alpha、closed beta、open beta で発覚した設計ミスを直した。そして数週間前にリリースした。
1.0 は順番通りに build、test、deploy フェーズで固く縛られてた。途中でテストが失敗した場合は、頭からやりなおすしかなかった。
2.0 はフェーズを疎結合したジョブに分割したことで、ワークフローを作れるようになった。テストが失敗したとしても、一から再コンパイルせずに、失敗したジョブから再実行すれば良し。しかもジョブ毎にそれぞれのブランチ、リソース、並行レベルを当てることができる。
Opinion
Hanami が絶対に Rails を追い越さない理由。
現状：Rails は Ruby 界隈を圧倒的に支配してる。しかし嫌いになった人も少なくない。
- 初めて Rails に触れた時は、フレームワークや gem のロジックがどこに隠されてるのか分からなくて不安。特に .NET など NIH 主義言語の出身者。
- コツ掴んで開発スピードに惚れる。
- モノリスの保守に苦しみ恨む。PORO が恋しくなり、ActiveRecord の複雑さを憎む。
そこで Hanami 登場。Sinatra より機能が充実。Grape ほど特化してない。何よりも Rails よりキレイ。
しかし Hanami は魔術がないわけではない。例えばコントローラの Action#call が Rack 標準の HTTP ステータス + ヘッダー + body の配列なのに、実装する側の戻り値は違う。配列を返すロジックはフレームワークによって prepend されてる。
魔術を使ってるのは、Rails に対抗するのが Hanami の目的ではないから。作成者曰く実用主義がメイン。実用主義では Rails からの大移動が起こらない。Rails には作成者のビジョンがあるから人がついていく。Hanami にはビジョンがない。
Tools
Gemfile の gem を ABC 順にソートするコマンド
Code
docker-compose.yml 系オーケストレーション用 Ruby DSL
