3月25日に開催されたRails Developer Meetup（2日目）に参加しました。
私が拝聴したセッションの内容の一部を簡単に紹介します。
1日目の記事はこちら
2日目の会場は株式会社ドリコム様のオフィスの一角をお借りして行われました。
イベントの詳細は下記よりご確認ください。
http://techplay.jp/event/655769
また、資料につきましては下記のサイト様がまとめてくださっています。
https://qiita.com/dyoshimitsu/items/20a41ab656d2da80e4d9
それでは、当日の内容を振り返ります。
株式会社スタディスト様のランチセッションでの発表です。
内容としては５年ほど前に開発したBtoB向けサービスのRailsのバージョンをおよそ半年かけて上げる際に行ったリファクタリングに関しての発表です。
Railsのバージョンを上げる際様々な箇所でエラーが発生します（e.g. 引数が変わった）
リファクタリングを行うことで対応箇所を減らすことができます。
リファクタリングでは下記の3つの要点があります。
それぞれについて説明します。
3種類とは、「必要かつ使用が明確な処理」、「不要な処理」、「（必要なのか）わからない処理」です。
「必要かつ使用が明確な処理」に関してはあるべき流れに沿って書き直しました。
「不要な処理」に関しては勿論削除しました。
ただし、メソッドは呼ばれているけれど実は呼び出し元も不要な場合があるので、本当に不要なのか確認するのが大変だったそうです。
「わからない処理」に関しては、本流とは別の場所にまとめて、不要だとわかったときに削除しました。
モデルに寄せることでテストがしやすくなります（コントローラのテストは時間がかかる）
また、今後サービス層などを導入する際に処理を分離しやすくなります。
コントローラ感はconcernに、APIとWeb間はcommonに、モデル間はmoduleに共通の処理を記述していきます。
コードの品質を上げるためにRubocopを導入し、プルリク時にSideCIで自動チェックするようにしました。
また、プルリクに関しては最低2人がOKを出すまでマージしないなど、ルール面を整備しました。
コードの行数が約44,000行から約28,000行に削減され、テストコードの行数が6行から約3000行に増加しました。
本発表は新人教育を行う方（メンター）の養成講座のような内容です。
新人教育では仕事のやり方などを教えますが、新人に本当に必要なのはいかにして学んでいくかという方法ではないかという考えから、知性とは何かということに関して考察します。
また、発表では最初に新人教育に当たっての参考書籍が紹介されていますので、初学者の方は一読をおすすめします。
知性に関しては発表資料から引用します。
知性は「型」と「実践」に分解することができます。
「型」と「知識」を野球に例えると、「型」はボールの投げ方やバットの振り方などの知識で「実践」は実際にボールを撃ってみる行為です。
日々の観察からわかるのは結果であり、他にどんな「型」があって、なぜその「型」を使ったのかという理由まではわかりません。
「型」については座学で学ぶことができますが、「実践」はメンターがいる方がより理解が深まります。
株式会社お金のデザインのサービス（THEO）を例に、マイクロサービスの良さとgRPCのメリット・デメリットについての発表です。
全体的に駆け足の発表となりました。
個人的には一番おもしろいセッションだったので、資料の一読をお薦めします。
入出金や口座管理など高い可用性とセキュリティが求められる箇所はJava、UI/UXの部分はRailsやVue.js、市場で証券を売買する部分はC++などそれぞれ得意な分野を担当する。
ここで登場するのがgRPCです。
APIの設計方針としてREST、RPCが、データの表現形式としてJSON、Protocol Buffersなどがあります。
登壇者曰く、RESTとRPCの違いの一つとして「APIの設計時にどこに着目するか」が挙げられます。
RESTではリソースに着目し、RPCではアクションに着目します。
RESTの方が向いているケースとしてCRUD、RPCの方が向いているケースとしてSlackのようなチャットサービスのAPIが挙げられていました。
ユーザがあるチャンネルから退出するアクションをleave、あるユーザをチャンネルから追放するアクションをkickとすると、leaveとkickを綺麗なRESTで表現するのは難しいです。
これらをRPCで表現すると下記のようになります。
URL: https://example.com/api/leaveFromChannel
body: { "channel_id": 123, "user_id": 456 }
URL: https://example.com/api/kickFromChannel
body: { "channel_id": 123, "user_id": 456 }
デフォルトではProtocol Buffer（Protobuf）が採用されています。
Protobuf大きなのメリットしては下記が挙げられます。
反面デメリットとしは下記が挙げられます。
導入に関しましては発表資料を御覧ください。
一番興味を持ったのはgRPCでした。
gRPCに関してはなかなか使う機会が無いのですが、ぜひ使ってみたいと思います。