Questions and feedbacks

katsumata-ryo
katsumata-ryo commented 5 months

@kymmt90

KPTで出たTryをチームとして実際の行動に移す際になにか工夫していることなどはありますか?

資料にも書いたことですが、数を絞る(1,2個)が一番聞いた気がします。 もし1回でもやるみたいなもの(たとえばモブプロやるみたいなtry)とかであればカレンダーに突っ込んだりしています。 ただ、時々Tryを忘れるみたいなことはあるにはあるので、あーやれなかったねーやりたいねーという気持ちをまた次週に託します。

Like(0)

katsumata-ryo
katsumata-ryo commented 5 months

@issei126

自身のチームのスプリントレビューがただの「今週やった業務報告」になりがちかなと個人的に感じています。 そうならないために、ご紹介していただいたやっていることで一番効果がありそうなものを挙げていただけるとうれしいです ちなみに自身のチームはポイントをタスクにポイントを振っていないです。

あくまで自分のチームだった場合になってしまうんですが、ただ司会が淡々と喋る会になってしまわないように 自分は2つを気をつけました ・緩めの雰囲気をつくる(同期と話すような気軽さ) ・権力勾配を感じさせないようにする( 自分が同じ目線の人だと認識させる ) 話せる空気感でどんなことでもいいから気持ちがあったらみんなに共有してほしいっていう思いを伝えてました!

Like(1)

yuemori
yuemori commented 5 months

railsのmethod traceのflame graphや、CPUのinstructionなどのgraphなどはそれぞれどうやって(何を使って)出しているんでしょう?

Like(0)

shinkufencer
shinkufencer commented 5 months

Cookpad社ではEnvoyを使っている話が昨日あがりましたが、nginxとの組み合わせはどのようにやっているのでしょうか?

Like(1)

8398a7
8398a7 commented 5 months

公式のgrpcジェネレータでは達成できなかった内容(主な内製理由)はどのようなものがありますか?

Like(1)

willnet
willnet commented 5 months

@expajp

let!の多用はDBアクセスが増えてテストにかかる時間が増えてしまうと思うのですが、なにか対策はありますでしょうか?

(先程口頭で回答しましたが)letでも実行されればlet!同様DBアクセスが増えます。DBアクセスが本当に必要なときだけlet!を使うことで、DBアクセスをletを使ったとき同様最小限に防げると思います。

Like(0)

yuemori
yuemori commented 5 months

Aggrigation LayerとしてのGraphQLという話が出ましたが、grpcやREST APIとの使い分けはどういう視点で考えられてるんでしょう?

Like(1)

willnet
willnet commented 5 months

@issei126

逆に shared_examples の使い所っていうのがあれば教えてほしいです。

現実世界でshared_examplesがバッチリハマってる!というケースはまだみたことがありません

さっき話したように、結局はDRYと可読性低下とのトレードオフを考えつつ、DRY側のメリットが上回ると判断した場合にやむをえず使う、というものだという認識です。

現実世界を離れると、RSpec公式のsharedexamplesの例は可読性低下がほぼなく sharedexamplesの使い所感があります。↓に引用しましたがsharedexamplesの定義側が依存しているコードがテストコード本体側に存在しないので、脳内マージが容易にできますよね。こういうコードが現実世界でもしあればsharedexamplesのメリットを活かせて便利だな、と思います。

require "set"

RSpec.shared_examples "a collection" do
  let(:collection) { described_class.new([7, 2, 4]) }

  context "initialized with 3 items" do
    it "says it has three items" do
      expect(collection.size).to eq(3)
    end
  end

  describe "#include?" do
    context "with an item that is in the collection" do
      it "returns true" do
        expect(collection.include?(7)).to be_truthy
      end
    end

    context "with an item that is not in the collection" do
      it "returns false" do
        expect(collection.include?(9)).to be_falsey
      end
    end
  end
end

RSpec.describe Array do
  it_behaves_like "a collection"
end

RSpec.describe Set do
  it_behaves_like "a collection"
end

shared examples - Example groups - RSpec Core - RSpec - Relish

Like(1)

ota42y
ota42y commented 5 months

デザインの統一やボタン配置といった、複数のチーム間で揃えないといけないユーザ体験はどのようにコントロールしているのでしょうか

Like(1)

yaboojp
yaboojp commented 5 months

スクラム導入前の「成果が出せてなかった」というのは、なぜそう感じられたのでしょうか?もしくは、具体的にどういう状態だったのでしょうか?

Like(0)

corselia
corselia commented 5 months

自動化した部分が期待通りではなかった(誤っていたのに通ってしまった)ケースはありましたか? その場合はどういうケースで、どれぐらいの頻度でしたか?

Like(0)

ota42y
ota42y commented 5 months

Webのフロントエンドはマイクロ化できますが、iOS/Androidアプリの場合はどのように解決されているのでしょうか

Like(2)

pokotyamu
pokotyamu commented 5 months

チームの中でスクラムの理解を深めるためにやったことなどはありますか?勉強会などされたりしたんでしょうか?

Like(1)

fkdkent
fkdkent commented 5 months

ドキュメントを読まなくてもコードが書けるというのは具体的にどんな感じですか? APIがよくできているから細かく調べなくてもコードが書ける、みたいな感じでしょうか?

Like(0)

kymmt90
kymmt90 commented 5 months

KPTで出たTryをチームとして実際の行動に移す際になにか工夫していることなどはありますか?

Like(2)

kyanny
kyanny commented 5 months

ガラケー版は基本的にメンテナンスしてない、とのことですが、アクティブに開発されているアプリケーションに起因する変更によってガラケー版が壊れたりすることはないのでしょうか?また、壊れたときは直すと思うのですが、そのメンテナンスコストは払えているのでしょうか?

Like(1)

yuemori
yuemori commented 5 months

grpcはhttp2が必要だと思うのですが、railsでgrpcをやり取りする場合の実装はどうされているのでしょう? 内製のgrpc gemでカバーしているんでしょうか? (本題でないのでということであれば懇親会で聞きます)

Like(2)

issei126
issei126 commented 5 months

自身のチームのスプリントレビューがただの「今週やった業務報告」になりがちかなと個人的に感じています。 そうならないために、ご紹介していただいたやっていることで一番効果がありそうなものを挙げていただけるとうれしいです ちなみに自身のチームはポイントをタスクにポイントを振っていないです。

Like(1)

willnet
willnet commented 5 months

@cobafan

willnetさんの話されている内容だとファイルが大きくなりそうですが、 そのために工夫されていることはありますか? 例えば、ネストは何階層までにしている等あればお聞きしたいです。

例えばユニットテストを書く場合、各クラスを小さく保つ(例えば100行以内にする)ことで、自然と対象となるテストコードの大きさも読める範囲に収まります。クラスが大きくなりそうだったら別のクラスに分割していきます。

E2Eのテストを書く場合は、controllerの各アクションごとに1ファイル、という単位で分割することが多いです。この単位で分割すればそこまで大きくはならないはず…。

ネストの数は特に制限しておらず、気になったら考えるというやり方をしています。ネストが深くてもそれほど読みづらくないテストも存在しているので。例えば↓のテストはcontextが5つもネストしていますが上のスコープについて考える必要が少ないので、それほどは読みづらくないかなと思っています

RSpec.describe '友達にメッセージを送る', js: true do
  let!(:user) do
    create :user,
           :with_condition,
           twitter_uid: login_twitter_uid,
           twitter_name: '@netwillnet'
  end
  let!(:friend) do
    create :user,
           :with_condition,
           github_uid: login_github_uid
  end
  before { Friendship.make!(user, friend) }

  context 'ログインして友達のページへ遷移し、"メッセージを送る"リンクを押したとき' do
    before do
      login_by_twitter(user)
      click_on friend.name
      click_on 'メッセージを送る'
      page.has_content?("#{friend.name} さんとのメッセージ")
    end

    it 'メッセージ用のページが表示されていること' do
      expect(page).to have_content("#{friend.name} さんとのメッセージ")
    end

    context 'かつ、メッセージを書いて"送信する"ボタンを押したとき' do
      before do
        fill_in 'body', with: 'こんにちは!'
        submit = find('[data-target="messages.submitButton"]')
        10.times do
          break unless submit.disabled?

          sleep 0.5
        end
        submit.click
      end

      it 'メッセージが表示されていること' do
        expect(page).to have_content 'こんにちは!'
      end

      context 'さらに友達のユーザがログインしたとき' do
        before do
          logout
          login_by_github(friend)
        end

        it '通知欄が"1"になっていること' do
          within('.navigation__link-to-messages') do
            expect(page).to have_content('1')
          end
        end

        context 'かつメッセージ一覧に遷移したとき' do
          before { find('.navigation__link-to-messages').click }

          it '新着通知の表示が消えていること' do
            expect(page).to have_no_css('.navigation__notification-number')
          end

          it '未読の表示になっていること' do
            expect(page).to have_css('.list-group-item-success')
          end

          context 'かつ、メッセージ詳細を表示してから一覧に戻ってきたとき' do
            before do
              click_link 'こんにちは!'
              page.has_content?("#{user.name} さんとのメッセージ")
              find('.navigation__link-to-messages').click
            end

            it '既読の表示になっていること' do
              expect(page).to have_content 'メッセージ一覧'
              expect(page).to have_no_css '.list-group-item-success'
            end
          end
        end
      end
    end
  end
end

Like(0)

pipopotamasu
pipopotamasu commented 5 months

@hamadata さん

ご質問ありがとうございます。 おかげさまで既存のプロジェクトでトラブったことはまだありません。

Like(0)

pipopotamasu
pipopotamasu commented 5 months

@n-kurasawa さん

ご質問ありがとうございます。 ビルド後のファイル及びmanifest.jsonはgit管理しません。

デプロイスクリプトの中でプロダクションビルドを行い、CDNやS3といったサービスにpushし(もしくは本番サーバに乗せて)配信するのが通常のフローになるかと思います。

Like(0)

pipopotamasu
pipopotamasu commented 5 months

@arsley さん ご質問ありがとうございます。

javascript_include_tagはrails本体のaction_viewで定義されているscriptタグを生成するヘルパーメソッドです。

https://github.com/rails/rails/blob/c1e949e9e618f75dc446ffa584c3b441c48714b1/actionview/lib/action_view/helpers/asset_tag_helper.rb#L87

なので、javascript_include_tag自体はsproketsの構成要素ではありません。

Like(0)

willnet
willnet commented 5 months

@hshimoyama

関連が複雑なモデルのレコード群で trait を使って制御しようとすると、入れ子の子・孫レコードを制御する trait をその親に書く> 必要があるなど、記述が煩雑になる問題があると思うのですが、そういうケースの場合どのように対処していますか?

前提として、traitで関連先を作るのは、下に載せたコードのように適当な関連先を作るときのみかと思います(例: postが0個の状態でuserを作成するとバリデーションエラーになってしまうから、なんでもいいのでpostを作りたい)。テストに必要な値を設定した具体的な関連先が欲しい場合はtraitではなくテストコード本体に書くべきです。

関連が複雑なモデルで「適当な関連先を作りたい」というケースに遭遇したことがないのですが(たいてい具体的に関連先の値を設定したいので、テストコード本体で関連先を作っている)、もしそのようなケースがあったら普通にtraitで定義してしまいそうです。これで回答として合っているかわからないので、はずしていたらもうちょっと具体的なケースを教えてもらえるとありがたいです

FactoryBot.define do
  factory :user do
    sequence(:name) { |i| "username#{i}" }

    trait(:with_posts) do
      after(:create) do |user, evaluator|
        create_list(:post, 2, user: user)
      end
    end
  end
end

Like(0)

arsley
arsley commented 5 months

javascript_bundle_tag にて javascript_include_tag を使っているということはsprockets依存を完全になくしたわけではないということですか? 「sprocketsが遅い」ということだったので少し違和感を覚えて...

Like(1)

KentaYoshitani
KentaYoshitani commented 5 months

このシステムは何時間(何日?)くらいで作成されたのでしょうか?

Like(0)

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