Questions and feedbacks

yhirano55
yhirano55 commented over 1 year

アプリケーションを跨いだ機能を開発するにあたって、これらを全てセットアップする必要があります。また、機能の追加により依存するパッケージやミドルウェアが追加される場合もあり、これらの管理は非常に煩雑です。

とてもよくある状況なので、どうやって解決しているのか非常に知りたいところです。楽しみにしています。

Like(0)

yhirano55
yhirano55 commented over 1 year

@qsona ご回答ありがとうございます。セッションでも触れていただけることありがたく思います(体系的な話が聴けそうで楽しみです)。サービス間での依存関係も発生しそうなので、デプロイもひと工夫必要そうですね。

いまのところほぼ全てRails

ある程度使う道具を統一していた方が、コードレビューする際にコンテキストスイッチが発生しなくてよさそうですね。

セキュリティパッチが当たったgemを全部上げる、みたいなケース

PR作るところまでは自動化できそうですが、急ぎの場合に、それをレビューして取り込むのも大変そうですね

Like(1)

yhirano55
yhirano55 commented over 1 year

Railsのコンポーネント(actioncable, actionmailer, actionpack, actionview, activejob, activemodel, activerecord, activestorage, activesupport, railties)のなかで、最も関心が高いコンポーネントはどれですか? それに加えて、最も関心が薄いコンポーネント(ないし機能)はどれですか? 理由や背景も教えてほしいです。

Like(0)

qsona
qsona commented over 1 year

すいません、長すぎて切れたようなので分割します。

  • 2桁以上のrailsアプリケーションを保守する場合、アップグレードや依存ライブラリの定期アップデートに骨が折れそうな印象ありますがどのような工夫をしていますか?
    • はい、これは絶賛困ってます。Railsのメジャーバージョンアップとかそういうのは、影響範囲が見切れるので逆に楽なんですけど、セキュリティパッチが当たったgemを全部上げる、みたいなケースで面倒を感じますね。エンジニアの頭数とサービス数のバランスが良ければ、そんなに問題ではなさそうなのですが。(いまのところエンジニアの数 < サービス数なので)

追記: 長さではなく < 文字の前にスペースを入れてなかったのが原因でした、失礼しました 🙇

Like(1)

qsona
qsona commented over 1 year

Wantedlyさんは、ネイティブアプリも途中からかなり分割していっている印象があるのですが、バックエンドのマイクロサービス化とネイティブアプリ・フロントアプリの関係についてもできればお聞きしたいです。 (当日は裏で司会をしている予定なので、リアルタイムでは聞けない可能性が高いのですが... >< )

Like(3)

qsona
qsona commented over 1 year

事前質問ありがとうございます。参考にさせていただいて本編でも触れさせていただきますが(ほとんどが自然に取り込めそうです)、先に簡単に返答させていただきます。

  • どのような粒度でサービスを分割していますか?(あるいはどのような粒度で分割するのが良いですか?)
    • 一言でいうと、ビジネスとして独立できる単位、なのですが、分割の単位は非常に重要だと思っているので本編でもメインで触れる予定です。
  • 言語やフレームワークが異なる場合、メンテしにくくなりそうですが、そこはどのように対応していますか?
    • いまのところほぼ全てRailsです。これはRails以外を使うインセンティブがそこまで強いケースがいまのところないからです。ただ、いつでも他の言語を使ったサービスを作れるような状態を維持しています。これも関連する話ができそうです。
  • 現在刊行されているマイクロサービスに関する書籍で、これからマイクロサービスに取り組むチームに薦めたい一冊はありますか?
  • サービスとデータストアは1:1になっているのですか?
    • はい、1:1 (もしくは 1:n) で、サービス間での共有はしていません。「いかなる場合でもデータベースを共有しない」は、マイクロサービスをやるときに最も重要なPrincipleだと思っています。過去1度だけですが共有してしまって、今つらい、という話もあるんですが、時間があれば本編で触れたいです。
  • テストはモックすればなんとかなりそうですが、ローカルで立ち上げるの辛そうに見えますがどのように対応していますか(特に非エンジニア職でローカルでの動作環境を作らないと作業ができない場合はしんどそう)
    • これは難しいですよね・・・本当に難しい。前提としては、全サービスを詰め込んだdocker composeを作るみたいなアプローチは厳しい(ローカルで動かすにはメモリが足りなくなる)ので、作業に必要な単位でのdocker composeを用意する、みたいな感じになると思うんですが、今のところそこまで必要性がなくて私はやっていないです。
  • 1リポジトリに複数サービスを同居させて管理しているのでしょうか(repoとサービスが1:1?)
    • 弊社では1:1です。まずデプロイは分離するべきなので、リポジトリの単位もそれに従って分けるのが自然だと思います。1チームが複数のマイクロサービスを管理する場合はくっつけておいたほうが管理しやすいこともあると思いますが、チームとマイクロサービスのマッピングが変わったりすることもあるので逆に面倒そうな気はします。
  • railsはapiモードで利用していますか?
    • apiしか使わないならapiモードでrails newするが、apiモードにこだわるべきでは決してない、というのが私の意見です。似たような話題を触れる予定だったのですが、apiモードを使う/使わない、というテーマでよりrails的な話にできるので、良い視点をいただきました。
  • 多くのサービスでrailsを利用している場合、rails newすることが多いと思うのですが、そのセットアップの手間を省くための工夫として、何か取り組みはされていますか?(テンプレートなど)
    • application templateを作ってようやく使われるようになってます。これも触れる予定でしたが onkさんの Application Templateのススメ という発表の特に後半の話がすごく好きです。

Like(2)

anonymous
anonymous commented over 1 year

辞書を作ったりしていますか?

Like(0)

anonymous
anonymous commented over 1 year

何かgemを使われていますか?使われているなら、どんな選定理由ですか?

Like(2)

anonymous
anonymous commented over 1 year

データの同期はどうされていますか?

Like(1)

yhirano55
yhirano55 commented over 1 year

まったくテストがないアプリケーション場合、どこのテストから書いていくのが良いのか、気になってます。

Like(2)

mactkg
mactkg commented over 1 year

どんな道具を使ってRailsの開発をしていますか。使っている道具のイチオシポイント、こだわりポイントを教えてください。

Like(5)

yhirano55
yhirano55 commented over 1 year

要件にも依ると思いますが、アプリケーションサーバーは、Rails標準のPumaがおすすめですか? もしPumaではない場合は、何を使うことが多いですか?

Like(1)

yhirano55
yhirano55 commented over 1 year

Rails, Go, Python などを使って開発

@Altech なるほど。Wantedly Visitはモノリシックなんですね。ありがとうございます マイクロサービス・アーキテクチャだと、『事業的な中核価値であるユーザープロフィールデータを既存の Rails アプリケーションから切り出し、より使いやすい形で各事業から活用できるよう』が、どの現場でもキーになりそうな問題っぽいので期待しています。

Like(0)

yhirano55
yhirano55 commented over 1 year

Ruby on Railsの 愛して止まないところ はどこですか?

Like(5)

ttanimichi
ttanimichi commented over 1 year

本当は XX みたいな Pull Request がもっと欲しいんだけど来ないからコミッターが自分でやってる、みたいなのって何かあります?

Like(4)

yhirano55
yhirano55 commented over 1 year

マイクロサービス初学者の視点で、ちょっと気になっていることです。

  • どのような粒度でサービスを分割していますか?(あるいはどのような粒度で分割するのが良いですか?)
  • 言語やフレームワークが異なる場合、メンテしにくくなりそうですが、そこはどのように対応していますか?
  • 現在刊行されているマイクロサービスに関する書籍で、これからマイクロサービスに取り組むチームに薦めたい一冊はありますか?
  • サービスとデータストアは1:1になっているのですか?
  • テストはモックすればなんとかなりそうですが、ローカルで立ち上げるの辛そうに見えますがどのように対応していますか(特に非エンジニア職でローカルでの動作環境を作らないと作業ができない場合はしんどそう)
  • 1リポジトリに複数サービスを同居させて管理しているのでしょうか(repoとサービスが1:1?)
  • railsはapiモードで利用していますか?
  • 多くのサービスでrailsを利用している場合、rails newすることが多いと思うのですが、そのセットアップの手間を省くための工夫として、何か取り組みはされていますか?(テンプレートなど)
  • 2桁以上のrailsアプリケーションを保守する場合、アップグレードや依存ライブラリの定期アップデートに骨が折れそうな印象ありますがどのような工夫をしていますか?

実際に自分が携わることになったとき、参考にしたく、ご意見を聞かせていただけたら幸いです

(実践を通してチームが段階的に得られたことを、失敗の体験を含めて聴かせていただけることを楽しみにしています)

Like(3)

koic
koic commented over 1 year

コミッターのみなさんに質問です。自身の Rails への快心のコミット、あるいは一番印象に残った PR や、PR でのやりとりなどあれば伺ってみたいです。

Like(7)

yhirano55
yhirano55 commented over 1 year

2018年になってから @bogdanvlviv 氏、頑張ってますよね。次に新たなコミッターになりそうな方はいますか?(知らんがなって話ですね、はい)

Like(2)

yuemori
yuemori commented over 1 year

ActionCableってあんまり利用されてない印象なんですが、実際committer的にはどうなんでしょう?

Like(8)

yuemori
yuemori commented over 1 year

複数DB対応新着情報

5.2で入るかどうか検討されていたと思うんですが現状としては6.0で対応する方向なんでしょうか? この辺見ると6.0のマイルストーンに含まれているので。 また対応するとしたら今後の対応方針としては垂直分割までで、水平分割は対応しない方針になりそうでしょうか。

Like(10)

masa-iwasaki
masa-iwasaki commented over 1 year

@amatsuda@y-yagiさんに質問です。自分が作ったものではないRailsプロジェクトに関わることがあると思うのですが、その場合に気になるアンチパターン的なものはあるでしょうか。

Like(12)

masa-iwasaki
masa-iwasaki commented over 1 year

Railsのコードで「これはつらい。というか誰かなんとかできるの?」という部分ってあるでしょうか。

Like(10)

yhirano55
yhirano55 commented over 1 year

@amatsuda さんに質問です。もしも『Rails3レシピブック 190の技』の続編(Rails 6版)を執筆することになったら、差分として、どういうレシピを追加していきたいですか?

Like(2)

yhirano55
yhirano55 commented over 1 year

Railsの基本的なMVC以外に、独自のレイヤーを加えて実装することも多く見かけますが、コミッターのみなさまがよく利用するMVC以外で利用するレイヤー(サービス、プレゼンター、デコレーター、フォームオブジェクト、クエリオブジェクト等)って何でしょうか?(要件次第でケースバイケースだと思いますが、興味があって聞いてみました)

Like(13)

yhirano55
yhirano55 commented over 1 year

コミッター間でのコミュニケーションはどの程度の頻度で、どんな風に行われているものなのでしょうか?

リリーススケジュール、方向性や目標など、何らかの指針は伝えられているのか等...某朝刊読んでいる感じだと、PRベースでいきなり提案きて、それが次バージョンの目玉機能になる、みたいなパターンのように見えますが...。

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano