rastam’s blog

東京在住のマレーシア人 Rubyist

Ruby Weekly #360: 日本語サマリー

職場の Slack の #ruby 窓で Ruby Weekly メルマガが毎週配信されます。その中から面白そうなものをピックアップして、日本語で簡単なサマリーを書くようにしています。そのサマリーをここでまとまさせていただきます。くだけた日本語で失礼いたします。

rubyweekly.com

Highlights

Is WEBrick Webscale?

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 スレッド。

A Look At How Ruby Interprets Your Code

RubyVM::InstructionSequenceYARV インストラクションを覗いてみる話

Eventide: A Microservices and Event Sourcing Toolkit for Ruby

イベントソーシング用フレームワーク

Trestle: A Modern, Responsive Admin Framework for Rails

Rails 用管理画面フレームワーク

Riffing on 'interpose' Implementations in Ruby

先週の Clojure の interpose の話に興味を持った Avdi Grimm 先生が yield 式 Enumerable でリファクターしてみた話。テスト、ベンチマーク付き。

Creating a Ruby DSL: A Guide to Metaprogramming

config 系 DSL の作り方。

  1. PORO 作る
  2. mixin に移植。再利用できるように
  3. config.hoge = 123hoge 123 になるようにリファクター

注意: メタプロ多め

Airbnb Open Sources a New, Fast Thrift Binding

Apache Thrift シリアライゼーションプロトコールRuby バインディングを再実装した Airbnb

Apache が出しているバインディングはパフォーマンスが JSON 以下。AirbnbSparsam は MessagePack と肩を並べる。

Tutorial

Unsupervised Learning Using K-means Clustering in Ruby

kmeans-clusterer gem の k 平均法で教師なし学習を実現させた話。例としてカリフォルニア州 100 大都市を位置でクラスタリングっして、流通センターを設ける場所と数を計算した。

A Few Tips to Improve the Speed of Your Test Suite

テスト高速化。

  • build_stubbed 使え
  • before(:all) 使え
  • 不要な let! 捨てろ
  • 並列実行しろ
  • ファクトリーの不要なアソシエーション捨てろ
  • ログレベル変えろ

Cleaning Up Path Definitions with dir

__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 対象を指定コミット・ブランチに絞るツール)

Building Crazy Queries with ActiveRecord and Arel

クレイジーな SQL を Arel で実現させた話。

Asynchronous Elasticsearch Reindexing with Rails, Searchkick, and Sidekiq

Searchkick + Sidekiq で ActiveRecord データを ElasticSearch にインポートした話。

Ruby 2.4 Avoids Exception for Integer#dup

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

Why Hanami Will Never Unseat Rails

Hanami が絶対に Rails を追い越さない理由。

現状RailsRuby 界隈を圧倒的に支配してる。しかし嫌いになった人も少なくない。

Rails アプリ開発者の 3 段階:

  1. 初めて Rails に触れた時は、フレームワークや gem のロジックがどこに隠されてるのか分からなくて不安。特に .NET など NIH 主義言語の出身者。
  2. コツ掴んで開発スピードに惚れる
  3. モノリスの保守に苦しみ恨む。PORO が恋しくなり、ActiveRecord の複雑さを憎む。

そこで Hanami 登場。Sinatra より機能が充実。Grape ほど特化してない。何よりも Rails よりキレイ。

しかし Hanami は魔術がないわけではない。例えばコントローラの Action#call が Rack 標準の HTTP ステータス + ヘッダー + body の配列なのに、実装する側の戻り値は違う。配列を返すロジックはフレームワークによって prepend されてる。

魔術を使ってるのは、Rails に対抗するのが Hanami の目的ではないから。作成者曰く実用主義がメイン。実用主義では Rails からの大移動が起こらない。Rails には作成者のビジョンがあるから人がついていく。Hanami にはビジョンがない。

Tools

Ordinare: Sort Gems in Your Gemfile Alphabetically

Gemfile の gem を ABC 順にソートするコマンド

Code

Orchparty: A DSL for Configuring Orchestration

docker-compose.yml 系オーケストレーションRuby DSL