GitHub ukstudio
Comment3
Like
Created atJuly 14, 2018 11:08
Updated atJuly 14, 2018 11:08

Questions and feedbacks (3)

ukstudio
ukstudio commented 4 months

もし今Railsを作りなおせるとしたら再びRubyを選びますか? それとも他の言語を選びますか? 後者の場合その理由も知りたいです。

Like(1)

ukstudio
ukstudio commented 4 months

BasecampのコードベースにはあっていつかRails本体にも入れたいけどまだ入れられていないような機能やライブラリなどはなにかありますか?

Like(1)

ukstudio
ukstudio commented about 1 year

質問ありがとうございます。まとめて回答しますね。

曖昧な状況の中で」開発を進めていけるようなエンジニアを採用するにあたって、どのようなことに気をつければいいとお考えですか。

正直、あまり知見はないです…

ただ、今のチームでは、各々が今必要なことを自分たちで考えて動いて、細かい擦り合せを随時やっていくという感じでやっているので、そういう働き方が合わない・指示待ちの姿勢になってしまうというような方は難しいかなぁと思っています。

個人的にはサービス開発自体に興味がある、曖昧な状況自体を楽しめるような人と一緒に働きたいですね。そういう環境・状況で働いた経験があればなお望ましいかなと思います。

(そういう方はどこにいらっしゃるんでしょう… We are hiring…)

「シュッとサーバー立てる方法」詳しく知りたい。(弊社の環境だと多大な労力が必要…)

Hakoというものを使ってAmazon ECSにデプロイしています。必要なものはアプリケーションが動くDockerイメージと、Hakoのサーバー定義の2つです。

もう少し細かくかくと

  • Railsが動くDockerイメージをビルド
    • ビルドはGHEのmasterの変更を検知してJenkinsでビルド
  • DBはSREチームに依頼して用意してもらう
  • サーバーの定義をJsonnetで記述し、PRする
  • マージすると環境ができるので、チャットからデプロイコマンドを叩く

という流れです。

参考文献

クックパッドで、フィードバックをもらうためにhakoを使ってサーバーをたてよう、と思ったときに、サーバーを構築するまでにかかる時間はどのくらいですか?

すでにアプリケーションがDockerで動く状態であれば、小一時間程度でしょうか。入社してから最初の構築のときはドキュメント見ながらやっていたので1日ぐらいかかった気がします。

実際の本番環境のインフラはどのようなものでしょうか?

Railsアプリケーションであれば、AWSのECS上でアプリケーションが動いています。

仕様な曖昧な中、リリース日が決まってるということですがサービスの軸などは決定してるのでしょうか?ある程度利益の見込みなどが見えないと実装も無駄費用になるのではないのかなと思うのですが、曖昧な部分とはっきりしている部分の切り分けを教えていただけると嬉しいですっ。

そうですね、サービスの軸やミッション、ビジョンといったものは比較的ハッキリしていて、それに対するソリューションが曖昧という感じになります。利益については当然一定の目標はありますが、今はそれよりもユーザーに受け入れてもらえるソリューションはなにかというのをひたすら模索しています。

切り分けですが、極端なことを言えば今作っているアプリケーション自体がまだ本リリース前というのもありすべてが曖昧とも言えます。ただ、ミッション、ビジョン自体は今までのユーザーテストやインタビューを通して、少なくともチーム内では大分固まってきています。また、直近のリリースやユーザーテスト時に、「ここはこれで行く」とオーナーが決めることもあるので、会話やコミュニケーションを通して「この辺はある程度固まってそうだな」というのを察したりします(それでも変わることもあります)

AWSを使う企業が多いと思うのですがメリットは何でしょうか? コスト、使いやすさなどなど

古い記事になりますが、 https://aws.amazon.com/jp/solutions/case-studies/cookpad/ が参考になるかもしれません。 サービス立ち上げの文脈でお話すると、サーバーの手配が非常にはやいというのがメリットです。

AWSと他のクラウド(例えばGCP)と比較してのAWSのメリットについては、他のクラウドの経験があまりないのでハッキリとお答えできないです… ただ弊社で言うとGoogleのFirebaseの採用事例などもあるので、状況に応じてAWSに拘らずトレードオフを踏まえた上で選択しています。

テストは仕様書という概念なのでしょうか?

そういう側面もあります。要件が変わっていくなかで、現状のコードが今こうなっているのは何故か、これは仕様なのか、というのがわからなくなることがあります(自分が書いたコードだとしてもです)

そういうときにテストコードがあると、その辺りの把握がラクになります。

モバイル側のクエリを変更するだけ」とのことですが、アプリは審査や提出などがあるのでサーバサイドよりも更新コストが高いと思っていました。(ゲーム系のエンジニア 通常のモバイルアプリ系だとそうでもないのでしょうか?

その認識自体はあっているかと思います。ただ最近はcodepushなどもあるので、GraphQLのクエリの修正程度であれば何とかなるのではないかなと思ってます。

今回お話したのは、本リリース前の曖昧な状況でモバイル側に変更が入ってもサーバーサイドへの影響が少ない、別の言い方をするとアプリのエンジニアはサーバー側の修正を待つことなく開発をすすめることがメリットであるということになります。

本リリースに向けたお話を少しすると、サーバーサイドの方が変更しやすいというのは間違いないので、UI以外のロジックはできる限りサーバーサイドで持つべきだなと思っています。

Like(2)

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