Rails Developers Meetup 2018 Day 3 Extreme｜IT勉強会ならTECH PLAY［テックプレイ］ に参加させていただきました。 少し遅くなりましたが、感想書きます。
今回は、自分が聞いたセッションの中から、いくつかピックアップして感想を書かせていただこうと思います。 スライドのURLは Rails Developers Meetup 2018 Day 3 Extreme スライドまとめ - Qiita から見つけさせていただきました。ありがとうございます。
曖昧さを受け入れて開発をしていく方法
マネージドサービスという選択肢
- バックエンドだったら AppSync とか Firebase とか
これは、最近気になっている。何でも Rails で実装するのではなく、Firebase だったり Serverless だったり、という選択肢も考慮に入れたい。
AppSync は、GraphQL のマネージドサービスなのか。恥ずかしながら知らなかった・・・。 【速報】マネージドGraphQLサービス「AWS AppSync」が一般公開（GA）されました！ ｜ Developers.IO
また、インフラも Docker とか k8s とか凝らないで、PaaS で良いのでは？と思ったりする。規模にも寄ると思われるけど。
ここら辺は、個人開発で実験するつもり。
将来どうなるかわからないので、その時の手持ちの情報で必要十分なものを設計する
先のことまで見据えて実装したり、早くから抽象化したりしなくて良いのでは、と思ったりする。
例えば、とりあえずモデルにメソッド生やしておいて、情報が十分に揃ったら別のレイヤーに切り出したりしても良いのではないか、と思ったり。
定期的にリファクタリングしていけたら良いんだろうなー。
自分の設計能力や手札を増やす
これは、最近すごく思う。ひどい設計や実装は罪で、技術的負債になっていく。アーキテクチャや技術選定も。
とはいえ、初めて使う技術で最初から美しいものを作るのは難しいから、適当なタイミングでリファクタリングやリプレースするつもりでいた方が良いのかも。
サービスとしてスピードが大事で、リファクタリングやリプレースの時間がない、というのは、すごくよくわかる。自分もサービス思考のあるエンジニアでいたい。
でも、そうやって突き進んできた結果、身動きが取れなくなってしまったサービスを見たことがある。
ちょうど良いバランスというのは難しいかもしれないが、長期的に価値を提供し続けたいのであれば、技術的負債の返済には、真剣に向き合うべきだと思う。
これは自分の中で仮説の段階でもあるから、どこかで検証したい。
グサッ。上の 自分の設計能力や手札を増やす にも繋がるかもしれないが、選択肢は常に増やしていきたい。
Octocatは技術的負債の夢を見るか?
www.slideshare.net
技術的負債による弊害
この辺りは、ビジネスサイドの人とも共通認識を作っていきたいなーと思ったりする。
技術的負債が生まれる理由
- 事業的に価値があるところに負債は溜まりやすい
実現が難しいからこそ価値が生まれる、ということもありそう。
技術的負債を作らない、ではなく、技術的負債と向き合う
向き合っていきたい。
チームで地図を共有する
レールに乗り続けるという選択
Railsのすごいところ
- レールという名の地図が広い範囲で共有されていること
私もそう思っていたが、Railsエンジニアだからと言ってレールが共有されているとは限らない、と最近は思う。
新卒エンジニアもいるし、他の言語をやっていたエンジニアもいる。
「Railsのレールについて再考する」的な勉強会を社内でやりたい。需要があれば、外部の勉強会でも。
FiNCのサービス開発のすべて
マイクロサービス => 技術チャレンジがしやすい
これは、何となく思っていた。チーム毎に技術選定できるし、リファクタリングやリプレースもやりやすそう。
注力ポイント：データベース設計
これにより、現在のつらみが大幅に軽減されている
自社サービスに関わるようになって、データベース周りって辛いなーと思う。
リプレースしようとしても、データ周りはボトルネックになりがちだよな・・・と思ったり。
ビジネスの動向に応じたリファクタリング / リアーキテクト
普段から、システムのある米状態を考えたり議論する
ビジネスとして力を入れる段階で、システムのリファクタリングを行う
このやり方は、取り入れてみたい。
ユーザに関するデータは各サービスに散在する
これは、マイクロサービスの課題なのかな、と想像してた。
データの読み書きを行う専用のサービスを作って、各サービスからそのAPIを叩くようにする、とかではダメなのかな・・・
Rails + TypeScript + React + Hypernovaで始めるSSRライフ
会社からのサーバー費支給
- 月1万円まで
羨ましすぎる・・・弊社もやってほしい・・・。
技術的な検証の場が欲しかった
やってみたかった
個人開発では、ここら辺大事ですよね・・・。
Wantedlyにおけるプロダクト、技術、組織、7年間の進化
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 は本当にありがたいです。
チャンスがあれば、登壇もしてみたい。アンテナを張り続けて、ネタを収集せねば。
実は、弊社で寿司スポンサーさせていただいていたのですが、何もお手伝いできなかったです・・・。申し訳ないです・・・
次はもう少しお手伝いしたい・・・。
そして、弊社からはスポンサーだけでなく、登壇もして盛り上げていきたい。
