Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

"Rails Developers Meetup 2018 Day 3 Extreme" 感想

DSOC Development Group エンジニアの木田です。

2018/07/14(土) に行われた Rails Developers Meetup 2018 Day 3 Extreme|IT勉強会ならTECH PLAY[テックプレイ] で弊社は寿司スポンサーをさせていただきました。
本記事では、セッションの中から、いくつかピックアップして感想を書かせていただこうと思います。

※ 本記事は、下記ブログの内容を一部修正したものになります。

blog.mokuo.me

スライドのURLは Rails Developers Meetup 2018 Day 3 Extreme スライドまとめ - Qiita から見つけさせていただきました。ありがとうございます。

曖昧さを受け入れて開発をしていく方法

speakerdeck.com

マネージドサービスという選択肢

  • バックエンドだったら AppSync とか Firebase とか

最近気になっているところです。サーバーサイドは何でも Rails で実装するのではなく、Firebase や Serverless などの選択肢も考慮に入れたいです。 (もちろん Ruby ではなく他の言語という選択肢もありますね。)

AppSync は、GraphQL のマネージドサービスなんですね。恥ずかしながら知らなかったです・・・。 【速報】マネージドGraphQLサービス「AWS AppSync」が一般公開(GA)されました! | Developers.IO

また、インフラも Docker や k8s などと凝らず、PaaS で良い時もあるのはないか、と思ったりします。

将来どうなるかわからないので、その時の手持ちの情報で必要十分なものを設計する

先のことまで見据えて実装したり、早くから抽象化したりしなくて良いのでないか、と思うことがあります。
例えば Rails の場合だと、とりあえずモデルにメソッド生やしておいて、情報が十分に揃ったら別のレイヤーに切り出せば十分、などでしょうか。

その上で、定期的にリファクタリングしていけたら良いのでしょうね。

自分の設計能力や手札を増やす

増やしていきたいですね。ひどい設計や実装は、技術的負債に繋がっていくと思います。ひどいアーキテクチャや技術選定もでしょうか。
とはいえ、初めて使う技術で最初から美しいものを作るのは難しいから、適当なタイミングでリファクタリングやリプレイスするつもりでいた方が良いのかもしれません。

サービスとしてスピードが大事で、技術的負債と向き合う余裕がない、というのは、すごく良く分かります。自分もサービス寄りの思考があるエンジニアでいたいと思っています。
でも、そうやって突き進んできた結果、身動きが取れなくなってしまったサービスを見たことがあります。
ちょうど良いバランスというのは難しいかもしれないですが、長期的に価値を提供し続けたいのであれば、技術的負債の返済には真剣に向き合うべきだと思っています。
これは自分の中で仮説の段階でもあるので、どこかで検証したいです。

チームにアーキテクチャを合わせるのではなくて、チームがアーキテクチャに合わせる

グサッと刺さりました。上の 自分の設計能力や手札を増やす にも繋がるかもしれませんが、選択肢は常に増やしていきたいです。

Octocatは技術的負債の夢を見るか?

www.slideshare.net

技術的負債による弊害

この辺りは、ビジネスサイドの人とも共通認識を作っていきたいな、と思ったりします。

技術的負債が生まれる理由

  • 事業的に価値があるところに負債は溜まりやすい

実現が難しいからこそ価値が生まれる、ということもありそうです。

技術的負債を作らない、ではなく、技術的負債と向き合う

向き合っていきたいです。

チームで地図を共有する

  • レールに乗り続けるという選択

    • Railsのすごいところ

      • レールという名の地図が広い範囲で共有されていること

私もそう思っていましたが、Railsエンジニアだからと言ってレールが共有されているとは限らない、と最近は思います。
新卒エンジニアもいますし、他の言語をやっていたエンジニアもいますよね。

Rails に詳しいエンジニアがそうでないエンジニアに伝えていく、ということが大事なのではないでしょうか。

FiNCのサービス開発のすべて

speakerdeck.com

マイクロサービス => 技術チャレンジがしやすい

これは、何となく思っていました。チーム毎に技術選定できるし、リファクタリングやリプレイスもやりやすそうです。

注力ポイント:データベース設計

これにより、現在のつらみが大幅に軽減されている

自社サービスに関わるようになって、データベース周りはボトルネックになりがちだよな、と思っています。

ビジネスの動向に応じたリファクタリング / リアーキテクト

  • 普段から、システムのあるべき状態を考えたり議論する

  • ビジネスとして力を入れる段階で、システムのリファクタリングを行う

このやり方は、取り入れてみたいです。

ユーザに関するデータは各サービスに散在する

これは、マイクロサービスの課題なのかな、と想像していました。
データの読み書きを行う専用のサービスを作って、各サービスからそのAPIを叩くようにする、とかではダメなのでしょうか・・・。

Rails + TypeScript + React + Hypernovaで始めるSSRライフ

blog.hatappi.me

会社からのサーバー費支給

  • 月1万円まで

羨ましすぎます。弊社もやってほしい。

技術的な検証の場が欲しかった

やってみたかった

個人開発では、ここら辺大事ですよね。

Wantedlyにおけるプロダクト、技術、組織、7年間の進化

speakerdeck.com

ElasticSearch, Docker, Firebase, マイクロサービス, k8s, Ruby 以外の言語などを適切なタイミングで取り入れていて、すごいなと思いました。
先見の明がすごい・・・。ここら辺ってどんな役割の人が旗振り役をやられていたのでしょうか・・・。

Attributes API実践

フォームオブジェクトを作る際に Virtus を使ったりしていましたが、 Attributes API で良さそうです。 独自キャストも今のチームで使えそうですが、反対されそうな気もします・・・。

GraphQL on Rails 2018

GraphQL の型設計は、普通の OOP のクラス設計に近い

  • RESTful だと引っ張られる

N+1 問題は RESTful より制御しやすい

GraphQL 試してみたいです。

なぜ E2E テストがたまに落ちるのか

ChromeDriver とは REST API でやり取りしている WebDriver の仕様がある

そんな感じの構造だから、driver 取り替えたりできるのかな、と想像してました。

全体的に、ここまで追っていらっしゃるのはすごいです・・・。
今のチームでもたまに落ちるテストあるので、参考に修正したいです。

終わりに

Rails Developers Meetup は、始まったばかりの頃はここまで大きくなかった気がします。
ここまで育てられて、平野さん本当にすごいです・・・。

RubyKaigi は楽しいですが、サービス寄りの話はあまり聞けないので、 Rails DM は本当にありがたいです。

弊社からはスポンサーだけでなく、登壇なども含めて盛り上げていきたいですね。

© Sansan, Inc.