見出し画像
Photo by marikooota

Ruby / Railsとの出会いとこれまでと、そしてこれから

福井 烈

note社でエンジニアの発信強化していくぞ！という機運が高まっており、第一弾としてEMの私が書くことに💪
今回は、私自身のRuby / Railsとの関わりについて、前職のガンホー時代から現職のnoteまでを振り返ります。後半では、私自身がnoteの初期フェーズメンバーでもあるため、noteがRailsとどのように歩んできたのか歴史も合わせて紹介していきます！

1. Rubyとの出会い - ガンホー時代

きっかけはFluentd

遡ること9年前の2013年。当時所属していたガンホーで担当していたパズル&ドラゴンズのデータ基盤を構築することになり、ログ収集の定番ツールとなっていたFluentdを使うことにした。

Fluentdはプラガブルな作りになっていて、プラグインを実装することでストリームの間に任意の処理を挟むことができる。プラグインは基本Rubyで実装する制約があり、プラグインで処理を挟む必要性が出てきたタイミングが私がRubyと出会ったきっかけである。

Rubyのお作法を学ぶ

初学として選んだ書籍はパーフェクトRubyだった。

なぜ選んだのかはうろ覚えだけど、PHPを初学の時に選んだパーフェクトPHPが良かったからの流れだった記憶。
当時会社が有楽町にあり、毎日出勤前に有楽町ビルの地下にあるマックで100円のコーヒーを片手に写経をしながら学習を進めた。
そして初めて作ったプラグインが↓。せっかく作ったのでOSSとして公開をした。


入れ子になったJSONをフラットにするシンプルなプラグインだが、今コード見ると色々ひどい。。。

副次: アウトプットが楽しくなった

なんとなくOSSとして公開した初めてのgemがちょいちょい使われるようになった。IssueやPRももらうようになって、「これがあのOSS活動というやつかー」と著名なエンジニア達に少し近づけた気がした。
Web界隈でログ収集が盛り上がりをみせていたことも相まって、サーバ／インフラエンジニア養成読本という雑誌に逆引きFluentdプラグインの章があり、そこに拙作のプラグインを載せていただいたことが嬉しかったことも鮮明に覚えている。

それからしばらくは何かにつけてプラグインを作ってはOSSとして公開して、Qiitaにリリース記事を書くというのが習慣になっていた。Fluentdに出会ってRubyを触ることになっていなければ、おそらく体外的なアウトプットはしてなかっただろうし、勉強会やカンファレンスへの参加もしてなかっただろう。そう考えると、Rubyとの出会いはエンジニア人生を変えたできごとと言っても大袈裟ではないかもしれない。

参考までに作ったFluentdのプラグインを載せておきます。

■LOAD DATA LOCAL INFILEでMySQLにデータをインポートするアウトプット用プラグイン

■JSONのKeyの並びを入れ替えるフィルター用プラグイン

■想定したJSONになっているか否か検証するフィルター用プラグイン


2. Railsとの出会い - noteに入社

Railsとの出会いはFluentdのプラグイン作りが一通り落ち着いた後だったと思う。
piyopiyo.rbという当時PIXTAさんのエンジニアの方が主宰していたコミュニティに参加していて、参加してる方がRailsを触っている人が多かったからなんとなく「Railsでなにか作ってみるかー」となった記憶。Railsの登竜門となっているRuby on Rails チュートリアルを一周し、勉強会やイベント情報をRSSやスクレイピングで集約するWebアプリを作った。

自分が書いたRailsのコードが世に出る

時を経て2015年に現職のnoteに転職。人生に影響を受けたRubyを業務で使えるなら使ってみたいという気持ちがあり、「フルリモートできるか」「ミッションに共感できるか」に次いで「Ruby / Railsを採用しているか」を3番目の転職軸として考えていた。まさかすべてを満たす会社に転職できるとは思ってもみなかった。

初めて自分が書いたRailsのコードが世に出たのはcakesのキャンペーン機能だった。その後しばらくしてcakesは保守運用フェーズに入り、以降はnoteの開発がほぼ100%となった。


3. Railsとのこれまで

cakesはピュアなRailsアプリケーションだが、noteはSPAとREST API(Rails)で構成されている。noteのAPIはこれまでv1 ~ v3までの歴史があるので、ざっくりと遍歴を紹介したい。

noteのAPI遍歴

■v1
v1はコントローラー層にGrapeを採用し、JSONのレンダリングはJbuilderを採用している。
それぞれ独自のDSLを学習する必要はあるものの、手に馴染んだ後の開発体験は良かった。では、なぜv2が生まれたのかというとGrape、Jbuilderそれぞれに以下のペインがあったためだ。

  • Grape: routerの定義が分散し、URLから対象のファイルを探しづらい

  • Jbuilder: Jbuilder内でエラーが出た際にエラーの詳細がわからずデバッグしづらい

■v2
v1でのペインの解消をメインに、v2はActionControllerを採用し、JSONのレンダリングはJsonWorldを採用している。加えて、コントローラの設計方針はDHH流に乗っかり、デフォルトのCRUDアクションのみで定義することにした。当時参考にした記事は以下。

v1時代のペインは解消したもののエンジニアの数が20人を超えたあたりで新たペインが顕著になり始めた。v2のペインは以下の通り。

  • 実装前にレスポンスを設計レビューするチェック体制がない

  • ドキュメントがなく、既存実装やAPIを実際に見て判断せざる負えない

  • 命名規則、エラー処理、例外処理などが属人化し整合性がない

■v3
v2でのペインの解消をメインに、v3は以下の方針を取ることに。

  • OpenAPI3に準拠。OAS(OpenAPI Speficification)をベースに設計レビュー -> 実装のフローとする。

  • OASからReDoc（ドキュメント）を自動生成する。

  • OASからレスポンスに関するテストケースをcommitteeを利用して自動生成する。

なお、コントローラー層はv2同様ActionControllerを採用し、JSONのレンダリングはRails5から本家に取り込まれたActiveModelSerializersを採用している。


ざっくりとnoteのAPIの歴史を紹介したが、特にv3の話は機会があれば詳しく紹介したい。


4. Ruby / Railsとのこれからの付き合い

noteのRails APIは現状モノリシックアーキテクチャだが、モジュラモノリスへの移行を計画しているという話が最近のトレンド。検証しながら部分的に移行を進めていて、ぼちぼちかっちり方針固めて進められそうだなというフェーズ。近々どこかの勉強会で詳しく発表すると思いますのでお楽しみに！

今後もnoteはRuby / Railsと長くお付き合いしていくことを想定しています。その上で、Ruby / Railsコミュニティに還元・貢献できるように積極的に動いていく所存です。


ということで・・・noteは今年のRubyKaigiに協賛し、ブース出展も予定しております！ご参加予定の方と開催地の三重で握手できることを楽しみにしております🤝ぜひ遊びに来てください‼︎



noteの開発に興味あって今すぐ話しを聞きたいという方は下記よりご応募いただければと思います！よろしくおねがいします🙏


技術書購入や勉強会・セミナー参加の費用にあてたいと思います🙏