Questions and feedbacks

n-kurasawa
n-kurasawa commented 5 months

ビルド後のファイルとか、manifest.jsonってgitで管理してますか?
プロダクション用のビルドってどこで行ってるんでしょうか?

Like(1)

f440
f440 commented 5 months

@kirikak2

今のところ特にルールなどは決めておらず、エンジニアの個人の判断で検索項目やソートフィールドに応じて適宜追加くらいで済んでいます。

すごくざっくりしたイメージだと「テナント数 x 従業員数 x 履歴」みたいな感じでレコードが増えていくのですが、このうち「テナント」はもともとシャーディングされてて(参考: https://builderscon.io/tokyo/2018/session/5485dc21-810e-4d12-9102-30b2812cd64f ) 、履歴の数もそんなに大量には増えていかないので、今のところは従業員のIDさえインデックスに乗っていれば大きな問題にならないんですよね。あとは要件にあわせてって感じです。 (もちろん削除フラグや有効期間の部分にもインデックスを付けてはいます)

Like(1)

f440
f440 commented 5 months

@cobafan

データ不整合、つらいですよね……アプリ側でどんなに注意して実装してもすり抜ける可能性はあるので、可能な限りデータベースの制約で原則発生できない状況作るしかないと思っています。

Like(0)

hamadata
hamadata commented 5 months

既存のプロジェクトに適用する際、トラブったこととかありますか?

Like(1)

willnet
willnet commented 5 months

@sue445

letのスコープは狭くするという話がありましたが、そうした場合contextの数(例:10個以上)によっては全く同じletを何個もコピペすることになってDRYにならないという問題があると思います。

こういう場合でもletは愚直に各contextに書くべきでしょうか?「○個以上なら外側に切り出す」という基準があるのであれば教えてほしいです。

口頭では「愚直に各contextに書く」と回答しました。僕の中ではDRYよりも脳に負担をかけないことが優先されるので、少しletをコピペするくらいなら問題ないと思っています。

あとで思いついた別案としては、共通部分を新しいcontextとして新設し、他のcontextをその配下に持ってくるとDRYと(ある程度の)読みやすさの両立ができるんじゃないかなと思いました。しかしあんまりネストが深くなりすぎても読みづらくなるのでこれもケースバイケースではあります。

Like(1)

anonymous
anonymous commented 5 months

Railsから切り離しているという話でしたが、SPAとして切り分けているときに不便におもった点などありますか?

Like(0)

yaboojp
yaboojp commented 5 months

自分でこれから新規プロジェクト立ち上げるとしたら、Webpacker使いますか?

Like(0)

urimaro
urimaro commented 5 months

一家言を持つことが重要といったことが資料に書いてあったと思います。 すごく難しそうに感じたのですが、まだ一家言を持っていない人にアドバイスお願いします。

Like(0)

upinetree
upinetree commented 5 months

@euglena1215

CSSの変更を行なったPRをレビューをする上で気をつけていることがあれば教えていただきたいです。

思いつくままにあげてみますね。

  • 実際の画面を見て意図通りに反映されていそうか
  • デザインカンプがあれば、それとの差異がないか、あっても意図的か
  • 他に影響していそうなところはないか、修正漏れはないか
  • CSSがチームのルールに沿っているか
  • クラスの命名は妥当か、BEMならコンポーネントの単位が納得できるか
  • CSSの定義の場所は妥当か
  • 既存クラスの再利用(HTMLからの参照とかextend)や mixin は妥当か
  • マジックナンバーはないか、変数化されているか、適切なコメントがあるか
  • いろんなデータを当てたときに崩れないか(データがないとき、多いときなどなど)
  • 他のデバイスでちゃんと動くか

あんまりCSSの個々の属性については見ずに、実際にあたっているスタイルを見て、その上で設計の妥当性とか、崩れるケースがないかとか、そういう観点でチェックしていることが多い気がしました。

@muryoimpl

使わなくなったviewを削除したときに影響するCSSの定義を削除するのは正直怖さがあるのですが、この恐怖に立ち向かうために何か気をつけている点、利用しているツール、手法はありますか?

個人的には、まずはセレクタの内容を手がかりに、特定できる可能性の高い単語で grep することから始めています。 BEMなどの命名規則を利用していれば簡単に判定できますが、多分そうではない環境でどう立ち向かうかということですよね。

その場合はビジュアルリグレッションテストが書いてあれば安心して削除できるかなと思います。それ以外の方法ではスタイルの変更を機械的に検知するのが難しそうだなあと思っています(結局CSSのシミュレータを作ることになりそう…)。

テストは、セレクタの内容を手がかりに影響範囲を絞れそうならその部分にだけテストを書くとかといった手抜きもできるかと思います。 削除の影響が全く読めないといった場合はページ全域のテストを書くことになってコスト大かもしれません。そういった環境ほどテストが書いてあると後々安心なのですが、まずは広範囲にピックアップしたテストを書くと、意図せぬ変更を検出できる可能性が上がってよいかと思います。

@minakawa-daiki

今後のCSSはどのように進んでいくのか、思っていること感じていること

CSS in JS の世界はとても動きやすくて個人的には大好きなのですが、SPAがそのプロダクトにマッチするかは別の基準があって、そうでない環境でどう立ち回るべきかというのはしばらくは考えていかないといけないかなと思っています。 また、CSS in JS ならではの複雑性の制御はきっと必要になってくるんじゃないかなあとも。

あとは WebComponents とか ShadowDOM 周りには期待しているのですが、まだ触ったことがないのでこれからやってみたいなあという感じです。

CSSフレームワーク(Bootstrapなど)を使用した場合、それに変更や上書きを施す場合、どのようにして設計、付き合っていけば良いのか

カスタマイズは結構難しいですよね…フレームワークが公開している変数とかを上書きする程度なら良いと思うのですが、振る舞い自体を変更し始めると、その部分は自分で別途定義しちゃったほうが面倒がないと思います。 その際はフレームワークのコードを読むと結構参考になりますね。

一部だけ読み込むことができるフレームワークであれば(Bootstrapはそうなっているはず)、使えそうなところだけ利用して、そうでないところは自分で定義するという手もとれるかなあと思います。 立ち上げを早くするという意味では便利に使えるので、役割を追えたときにスッと抜けるように小さく使っていくのがうまい付き合い方なのかもしれません。

Like(0)

joker1007
joker1007 commented 5 months

もしアプリケーションがGCPで動いていたらBigQueryだけで粘っていましたか?

多分、そうはならなかった。 課金スタイルとのミスマッチや構造上、マルチテナントと合わない問題は割と大きい。

Like(0)

joker1007
joker1007 commented 5 months

ガンガン技術力で課題を解決していてすごいなと感じたのですが、新しい技術スタックを導入する際に、特に意識しているポイントがありますか?

動作の理屈とかはしっかり調べて、筋が通ってるかどうかと、その理屈が自分達の課題にマッチするかをある程度先の想定をしつつ考慮している感じです。

Like(1)

joker1007
joker1007 commented 5 months

Bigquery APIが一時間くらい落ちる時があるとのことでしたが、それはビジネス的に問題ないのでしょうか? それともBigquery APIが繋がらない時は別の集計方法を臨時でおこなってたりするのでしょうか?

今現時点では落ちてても大丈夫なところしか使ってないですね。

Like(1)

joker1007
joker1007 commented 5 months

Bigquery -> Presto-EMRに移行する際に、SQLの書き直しはどれくらい発生した感じでしょうか? まるっと書き直しが必要だったレベルなのか、多少書式変えた程度で何とかなったのか。 また、大幅に書き直しが必要になったのであれば、テストはどのようにやったかなど興味があります!

BQのStandardSQLで一回書き直していたので、そこからPrestoについてはそんなに弄らなくて行けました。 テストについては、人間が事前に想定できるケースを越えているので、実際のproductionデータの抽出結果を何パターンも取得して実行結果に差分が無いかを日々確認してます。

Like(1)

joker1007
joker1007 commented 5 months

アーキテクチャ変更の際にアーキテクチャ候補はいくつか出てくると思うのですが 「これで行ける!」感を得るまでの試行錯誤の中で一番重要視しているのは何でしょうか?

一番っていうがどれかは自分でも分からないですが、観点として見ているのは大体以下の要素です。

  • 要求が本当に実現できる
  • 要求を実現するのに過剰な工夫が必要無い
  • コスト感が妥当
  • 運用イメージが持てるかどうか
  • 監視が作れるかどうか

この辺りを総合的に判断してます。

Like(1)

corselia
corselia commented 5 months

ビジネス側からの依頼ではなく、エンジニア側からの気付きによる提案の事例はありますか? そのような場合があれば、具体例が知りたいです。

Like(0)

mpg-izumi-hirayama
mpg-izumi-hirayama commented 5 months

A〜Eがふってあって「できるだけ単純な分析から」というスライドで、現実には「Aのポジションに無用に複雑な分析がはじめから置かれてしまう」というのが問題を生むのかなと思ったりしたんですが、Aのところには具体的にはどういう分析を置いてみる(どこから検討を始める)のがよいのでしょうか?

Like(1)

mpg-minato-nakamura
mpg-minato-nakamura commented 5 months

データ解析を用いた改善の文化は根付かせることが大変かと思いますが、そういった根付かせるためのアクションは池田さんが主導されているのでしょうか?その時のコツや気をつけていることなどあったら教えて欲しいです!

Like(1)

indigolain
indigolain commented 5 months

フィードバックのAsanaのタスクテンプレートのざっくりとした中身について聞きたいです!

Like(0)

asayamakk
asayamakk commented 5 months

セッションでは話さなかったのですが、kaizenさんのデータパイプライン、データ収集環境などが気になります!

Like(0)

geeknees
geeknees commented 5 months

モチベーション管理が課題かと思うのですが、なにか意識していることはありますでしょうか?

Like(1)

geeknees
geeknees commented 5 months

専用アプリケーション(Eラーニングシステム)を作る判断をしたのはなぜでしょうか?

Like(0)

gotchane
gotchane commented 5 months

Ruby で ls コマンドをつくるなど、面白く取り組めそうな課題が多いなと思ったのですが、 課題はどのように考えていらっしゃいますか?また課題は日々アップデートしている感じなのでしょうか?

Like(0)

colorbox
colorbox commented 5 months

アーキテクチャ変更の際にアーキテクチャ候補はいくつか出てくると思うのですが 「これで行ける!」感を得るまでの試行錯誤の中で一番重要視しているのは何でしょうか?

Like(0)

morimorihoge
morimorihoge commented 5 months

Bigquery -> Presto-EMRに移行する際に、SQLの書き直しはどれくらい発生した感じでしょうか?
まるっと書き直しが必要だったレベルなのか、多少書式変えた程度で何とかなったのか。

また、大幅に書き直しが必要になったのであれば、テストはどのようにやったかなど興味があります!

Like(1)

hatappi
hatappi commented 5 months

Bigquery APIが一時間くらい落ちる時があるとのことでしたが、それはビジネス的に問題ないのでしょうか? それともBigquery APIが繋がらない時は別の集計方法を臨時でおこなってたりするのでしょうか?

Like(0)

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