Questions and feedbacks

morimorihoge
morimorihoge commented 4 months

返信ありがとうございます!

確かにまずは手が早く動かせることでやり直しも含めて考えられることが増えるので、まずは手を動かせるようにしておくというのはRails向きでもあるし大事ですね!

Like(0)

youchan
youchan commented 4 months

スライドツールは何を使っているのでしょうか?

Like(0)

r7kamura
r7kamura commented 4 months

Railsのアップグレードは「上位バージョンでも動くようにする」というのが大事ですが、新しいバージョンで追加された機能を使う(置き換える)みたいなことも発生するかと思います。それは別のフェーズでやるのでしょうか。また、どのように進めていらっしゃいますか。

これは Rails のバージョンをまず先に上げて、それが完了したら新しいバージョンで追加された機能で置き換える、という二段階で進めています。もしどうしても同じ期間に開発作業を進めないといけない場合は、Rails のアップグレードのブランチをつくって、そのブランチを fork して新機能を使うブランチで開発を進めて、適宜前者から後者に変更を rebase しながら進めていく、という感じの進め方になると思います。

Like(1)

taogawa
taogawa commented 4 months

@nard-tech はい、分割しています! あとはアプリ向けAPIエンドポイントもあるので、それでcontroller数が増えている側面もあります。

質疑のときにもお話しましたが、DHH流ルーティングはまともにやるとリソースの階層がめちゃくちゃ深くなりがちなので、そこが気を付けどころです。

Like(0)

nashirox
nashirox commented 4 months

松田さん開発gemを、メンテのモチベーション順に並べたらどうなりますか?また、モチベーションが高まる要因を教えてください

Like(0)

r7kamura
r7kamura commented 4 months

新旧両立できる書き方、という話がありましたが、それができなかったりする事例などあったりしますでしょうか?またそれをどう超えてきたなど教えていただけると幸いです。

軽い問題で言うと、例えば「Rails 4.2 のうちから Rails 5.1 でも動くコードにしたい」という状況において、

  • Rails 4.2 では migration ファイルで ActiveRecord::Migration[4.2] を継承すると動かない
  • Rails 5.1 では migration ファイルで ActiveRecord::Migration[4.2] を継承しないと動かない

という問題がありました。これは Rails のバージョンを見て継承元を条件分岐させるようにして対応しています。大抵の問題はバージョンを見て条件分岐させると解決できます。

重い問題で言うと、resque_mailer という gem があります。これは以下のような問題がありました。

  • Rails 5 にするには resque_mailer のバージョンを 2.2 から 2.4 に上げないといけない
  • resque_mailer 2.2 から 2.4 にすると Redis に格納されるデータの形式が変わる
  • Redis に旧形式のデータが格納されている状態で resque_mailer のバージョンを上げると正しく取り出せなくなる

データを保存するタイプのライブラリでフォーマットの形式が変わると大変で、サービスを動かしたまま変更するのは更に難しい、という問題ですね。これは新旧両対応の形式に変えるパッチを加えて対処できるように対処しようとしたのですが、結局メンテナンスでサービスを止める機会があったので、その機会に Redis の中身を空にしてからバージョンを変更することにしました。

Like(0)

yuriko1211
yuriko1211 commented 4 months

Rails Girls のコーチに求められるもの(スキルのレベル感・マインド)について教えていただきたいです。コーチやってる人=めっちゃすごい人という漠然としてイメージしかないので…。

Like(0)

ikedaosushi
ikedaosushi commented 4 months

heavens_doorhocus_pocus など、amatsudaさんの説明しすぎないネーミングがいつもカッコイイなと思うのですが、何か命名時に意識していることはありますか?

Like(2)

r7kamura
r7kamura commented 4 months

config の更新や rails new 時に生成されているファイルについてなにか気をつけていることはありますか

rails new したときの commit メッセージに、付けたオプションとその理由について書くようにしています。

http://railsdiff.org/ という、rails new したときに生成されるファイルのバージョンごとの差分を見られる Web サイトがあるので、バージョン変更時はこれも参考にしています。

Like(1)

r7kamura
r7kamura commented 4 months

これまでのrailsアップグレードで最もキツかった事象とその原因について可能な範囲でお聞きしたいです。

Rails 3から4にしたらActiveRecordのパフォーマンスが大きく劣化した件が大変でした。対応が難しく、またこの対応が後のRailsアップグレード時に問題となるので更に大変でした。ActiveRecordがオブジェクトを大量に生成するようになってしまったことが原因です。ActiveRecordにの要所要所にmonkey-patchを入れて対応したという感じです。

Like(1)

expajp
expajp commented 4 months

heavens_doorの命名の由来は何なんでしょうか?(moody_bluesじゃないんですか?

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

予約機能はどんどん仕様が増えていく印象があるのですが、どれを実装する・しないの判断はどのようにするのでしょうか?

現在はプロダクトオーナーが存在しているので基本サービスの台帳に関してはその人がある程度優先度を決めて判断しています。

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

飲食店では予約のキャンセルに対する対応(ドタキャン・幹事と連絡が取れないなど)が大きな問題になってくるかと思いますが、そういった問題に対する対策や防止手段などは考えられたりしているのでしょうか? または、トレタ経由の予約は一般の予約システムに比べてキャンセル率が低いなどの話がありましたら興味があります。

プロダクト的な話では http://lp.toretel.toreta.in/ このようなサービスを提供し、お客様に予約確認を促すサービスを提供しています。 また、仕組み的な話では https://corp.toreta.in/news/2017-02-09/ このような仕組みを提供しています。

トレタ経由だからといって他の予約システムと比べてキャンセル率が低いというデータは現状存在しません。

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

設計思想がスマートなのですが、そこに至るまでの要件定義をどのように進めるか教えて欲しいです。すごい泥臭そうで。

弊社代表は元々飲食店を経営していて現場の課題を一番知っている人間でした。代表自ら最所はプロダクトオーナーとしてGitHub上で議論したり、当時CTOの増井さんや一番目のエンジニアとかなり密に議論して初期設計を行ったのがここまで成長できた理由かなと思います。

コアな機能開発に関してはこの機能はどんな課題を解いているか?の部分をprojectチームでなんども議論して認識を合わせてから開発しています。また、会社に飲食店出身者も多いので実際にオペレーションを聞いたりしたり、導入して頂いてる店舗様に直接ヒアリングしたりも日常的に行っています

Like(0)

m-nakamura145
m-nakamura145 commented 4 months

新旧複数の在庫モデルが並行して存在していると思うのですがそこの整合性はどうやってとられているのでしょうか(ダブルブッキングの防止など)

整合性自体はロジックとして正しいかを単体テストをとにかく厚めに書くところと、DBでlockを取って同時に更新しないようにできるだけならないようにコード側で努力しています。

Like(0)

katorie
katorie commented 4 months

@pokotyamu

写真があったほうがわかりやすかったですね。。すみません!

ホワイトボードにマスキングテープでカレンダーを作って、そこに勤怠情報やカンファレンス情報を書き込んでいます。 で、振り返り(レトロスペクティブ)のときに2週間分のタイムラインを確認しようとすると全然覚えてなかったりしてつらいので、日々のデイリースタンドアップの時にタイムライン確認用の出来事付箋を貼り付けておいて、振り返り(レトロスペクティブ)のときにその付箋をひとつずつ見ていって、確認しています。

Like(1)

katorie
katorie commented 4 months

@nard-tech

Tシャツサイズ見積もりは、詳しくはこちらをご覧いただくといいと思います。 https://www.ryuzee.com/contents/blog/7101

この段階では具体的は設計までは話をせず、「だいたいこんな感じで作れそう」というような話をしています。

これは初めは全然よくわからなくて、とりあえず雑にサイズを見積もっておきます。 あとからまた別の見積もりをするときに「我々は以前このPBIにこのサイズを見積もったらしい」と振り返って、それより大きいか小さいかの相対評価するのに利用します。

Like(0)

pupupopo88
pupupopo88 commented 4 months

Railsのアップグレードは「上位バージョンでも動くようにする」というのが大事ですが、新しいバージョンで追加された機能を使う(置き換える)みたいなことも発生するかと思います。それは別のフェーズでやるのでしょうか。また、どのように進めていらっしゃいますか。

Like(0)

anonymous
anonymous commented 4 months

新旧両立できる書き方、という話がありましたが、それができなかったりする事例などあったりしますでしょうか?またそれをどう超えてきたなど教えていただけると幸いです。

Like(0)

katorie
katorie commented 4 months

スプリントに入る入らないをどう判断しているのかが気になりました。 ストーリー毎にポイントで見積っているのか、なにか別の方法でやっているのか教えてください

発表の時に質問の意図を勘違いしていて「POが判断している」という回答をしたのですが、計画づくりのときにスクラムチームがスプリントに入るタスクの量をどう判断しているのか、という質問でしたよね。。すみません。回答としてはストーリーポイントを参考にしたりもしていますが、今のチームは練度があがってきて貼り付けられたタスクの量や内容をみて「これはいけるかどうか」が判断できるようになってきました。それまでは、少なく見積もっておいて、スプリントの途中で「おかわり(もうちょっといけそう、とストーリーを追加する)」したりもしていました。

Like(0)

okuramasafumi
okuramasafumi commented 4 months

メトリックスやメモリ問題などを主に担当するのはチーム内の誰かと決まっているのでしょうか。それとも気付き次第手の空いている人がやる感じでしょうか。

Like(0)

mtsmfm
mtsmfm commented 4 months

config の更新や rails new 時に生成されているファイルについてなにか気をつけていることはありますか

Like(0)

katorie
katorie commented 4 months

@expajp

一例としてドメイン知識の話をしてしまったのですが、それだけではありません!

先日は入社してまだ間もないiOS得意なエンジニア(Rails未経験)たちを対象に、RailsGirlsのチュートリアルをやったりしました。 あとはカンファレンスに行ってきた報告とかもしています。

基本的に発表形式です。

もともと白い壁にプロジェクターで投影していましたが、数ヶ月前に55インチテレビを導入して、そこのまわりで開催しています。

(ちなみにこの55インチテレビでモブプロもします)

読書会は別で小規模開催していたります。

Like(0)

katorie
katorie commented 4 months

@katsumata-ryo

現在ベロシティの管理はしていません!していたこともありましたが、あまり効果が感じられなかったのでやめてしまいました。

Tシャツサイズ、ストーリーポイントは振っていて、見積もりの時の参考にしています。

現在のチームメンバーでの見積もり精度はだいたい間違っていない感じなのですが、人数が増えてきてチームも増えてきたので、これからそこらへんの改善が必要になってくるかもしれません。

Like(0)

colorbox
colorbox commented 4 months

これまでのrailsアップグレードで最もキツかった事象とその原因について可能な範囲でお聞きしたいです。

Like(0)

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