Questions and feedbacks
- cookie 系のライブラリで RFC6265 に準拠していると plus sign を encode しないですが、Rails はするために、converter などの処理があるライブラリを使っています。
- 不便とは違いますが、preflight のリクエストが発生しないように同じドメインで受けて nginx 等で api サーバが assets に流すかなどをしています。
結構昔から SPA として切り分けているため、あんまり不便な点が思いつきませんね... すみません 😅
Like(0)
名前に関していくつかコメントをいただいていて、回答の切り口はいろいろあるかとは思うんですが、まあこういうのもアリかな、と思って、今回発表したgemをプレイリストにしてみました。 https://open.spotify.com/playlist/0rBaJpNYZWwyWBzzoufNPE
つまり、名前には対象の指示でも振る舞いの説明でもなく、単にイメージを想起させる作用というかそんな感じの役割もあるということですよ、藤村さん。 この中では特に hocus_pocus はまさにこんな感じだよなぁ、という感じで、懇親会でマニアの方から「hocus_pocus はもともと違う名前で作ってたと記憶してるんですが、わざわざ改名したのは何故ですか？」とご質問いただいたんですが、これに関してはこの曲の存在がそれなりに大きかったように思います。要は、「名前」としての "Hocus Pocus" というフレーズにこういうイメージを与えてくれたもの、という意味で。
Like(1)
ライブラリの乱立が落ち着いたとはいえ、JSはパラダイムが広くやはり情報収集は難しいと感じています 板倉さんがどのように情報収集をされているか教えてください
- ライブラリのバージョンが上がったら、変更内容を確認する
- Frontend Focus https://frontendfoc.us/
- YouTube
- https://www.youtube.com/channel/UCnUYZLuoy1rq1aVMwx4aTzw
- https://www.youtube.com/channel/UCWf2ZlNsCGDS89VBF_awNvA
- https://www.youtube.com/channel/UCsBjURrPoezykLs9EqgamOA
- https://www.youtube.com/channel/UC_x5XG1OV2P6uZZ5FSM9Ttw
- あと、レコメンドされた動画。気にいったチャンネルをフォローしておけば、割といい感じのレコメンドをしてくれます
- ブログ
- web.dev https://web.dev/
「Webpackerは使うな」とちっちゃく書いてありましたが、よろしければ軽くお話いただけるとうれしいです。
いろいろ理由はありますが...
- 不要なnpm package入れすぎ
- 覚えること多すぎ。しかも、ほとんど不要
- 個人的には、webpackを覚えるよりwebpackerを覚える方がはるかに難しいです
- webpackの設定変更がwebpackerでラップされていることによって二度手間になる
- 素のwebpackを理解することを遠ざけることにより、Railsエンジニアと他言語のエンジニアたちとのフロントエンド知識格差がどんどん広がっていく
webpackerのいいところって javascript_pack_tag を書くといい感じにscriptタグ書いてくれて再ビルドもdev serverを起動しないでも勝手にやってくれる、ってところだと思うのですが、それくらいなら自分で書いても大したことないので自分で書くといいです（参考: https://medium.com/takeyuweb-tech/rails-typescript-webpack%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89-21c4402bbb01 ）
トークの紹介にあった
「今、なぜフロントエンドを学ばなければならないか」 「何を理解すれば、これからのフロントエンドを理解できるようになるか」 この辺りのお話をもう少しききたいです！
スライド最後のページを参照ということで
一瞬Elmの名前が映りましたが、来ると思いますか？
来ないと思います。ですが、Haskellなんかと同じで一部では重宝されるだろうし、来ないけど死ぬこともないライブラリな気がします。
Like(0)
命名変更以外の非互換 schema 変更を伴う場合の対応はどのように行っていますか？(versioning?)
まず、APIの出力に対して、新しい field を追加するという場合は、スキーマとしての互換性は失われますが、SDKを利用するコードに修正は必要無いため、そのまま追加を行います。
次に、APIの入力に対して、新しい field を増やすという場合は、スキーマとしての互換性は失われますが、バックエンド側で初期値を与えてあげることで、旧スキーマを参照する SDK からのアクセスも同一エンドポイントでハンドリング可能であるため、そのまま追加を行う場合が多いです。
fieldの削除等、 schema だけでなく、 SDK I/F としても互換性が失われるものについては、開発フェーズや、利用度合い等、様々な事情を考えた上で、様々な策が取られます。（詳しく説明すると非常に長くなってしまうので、すみませんが、今回は割愛させてください。）
これらが不適切となる運用段階での大幅な変更（大幅なschema変更や内部ロジック変更等）がある場合には、エンドポイントベースでの versioning を行 う場合があります。schemaから生成されるコードと、SDKの外部I/Fの間に層が存在することによって、SDK I/F としては同一のままになる場合もあります。また、APIの特性によっては、ロジックやデータのバージョンを示す field をスキーマ内に持つことで、新・旧の互換性を保持しているものもあります。
Like(0)
gRPCの利用は検討されたのでしょうか？
はい。検討しました。 しかし、プロジェクト当初は、RESTfulを選択することによる恩恵が大きいということで、開発者の意向として RESTful が選択されました。
これらの背景をより詳しく見ていくと以下のようになります。
- RPC or RESTful という文脈においては、特に Rails においては、 RESTful を利用することによる生産性向上が大きかった。
- そもそも、検討時における gRPC は、エコシステムも含め、今のように成熟したものではなかった。
また、SDK において開発者に使いやすい I/F を提供したいという都合上、カスタムのコードジェネレータを設計・実装する必要があるという部分は 、当時、仮にgRPCを導入していた世界線であっても、あまり楽にはならなかったのではないかと推測されます。
Like(0)
モックのAPIやAPIドキュメントを作る作業はフロントエンドチームとバックエンドチームが共同で作る体制でしょうか?
はい。案件ごとの差はありますが、共同で作る体制が多いです。 例えば、満たすべき要件に対して両者で話し合いながら概念設計を進め、その結果をスキーマに反映し、モックのAPIやAPIドキュメントを作っていきます。バックエンドチーム、フロントエンドチームが、それぞれの得意な領域から、設計に対してフィードバックしていきます。設計の為のたたき台を作ったりする部分や、設計結果をスキーマに落とし込み、APIとして利用できるようにする部分はバックエンドチームが担当する場合が多いです。
APIの規模や難易度が大きくなるほど、よりスキーマ確定前の設計時の共同作業に比重が置かれる傾向があります。
Like(0)
ActionTextはActionViewを使っていなくてSPA主体のアプリケーションでも何か恩恵をうけることは出来ますか？
Like(0)
現在のBasecampでの「サイエンスプロジェクト」で話せることがあったら教えてください。
Like(0)
質問ありがとうございます。
Data Abstraction Layer を用意したことにより、サポートしているデータ構造 (現在のところ Daru::DataFrame, Numo::NArray, NMatrix, ActiveRecord) であればどれでも同じように扱えること。
Plotting Abstraction Layer を用意したことにより、サポートしている plotting library (現在のところ maplotlib, gruff, rubyplot) であればどれで統一されたひとつのインターフェースで扱えること。
1, 2 により、ユーザが使いたいデータ構造、Plotting library の組み合わせで自由に plot できること。
Charty の用意している設定により、render メソッドを呼ぶだけで、"そこそこ良い感じ" の設定でグラフを描画できること (それぞれの plotting library で、きれいなレイアウトでグラフを出力したいとすると、細かなオプション指定を自分でする必要が生じます。その手間を省き、data plot のために時間を使うよりも、本来目的とするデータ解析に集中することができる状態になること) が、Charty を使うメリットです。 なので、手間をかけて詳細に plotting library のオプションを設定してでも、自分好みのきれいなグラフを出力したい。といった用途では、Charty を使わずに、直接自分の使いたい plotting library を使わなければ、やりたいことを表現できないことがあります。
この様な特徴を理解して Charty を使うとよいと思います。 また上記とは別に、 Charty がより多くのケースで便利に使える様に、引き続き改善を続けていきます。
Like(1)
暗黙な依存が存在するfactoryに関して、これを良い感じにリファクタする方法やアプローチがあれば教えていただきたいです。
factorybotの定義を確認し、暗黙な依存があればそれを剥がした状態でテストを実行、コケたところを一つづつ修正していく、という地道な作業をしていくしか方法はなさそうです…。大変だと思いますが頑張ってください！
Like(0)
Basecampでは、複数モデルに渡る処理をどのように書いていますか？
Like(0)
今回の可読性を現場で実践していく上で、重要だと考えているもの（方法論）があれば教えていただきたいです。 特に、既存のテストコードを、可読性が高い状態へと改善していく際のヒントを頂けると助かります。
チームメンバーに可読性の高いテストコードの書き方を布教する、というのが一番大事かつ一番大変なことだと思います。チームのうち一人だけ意識が高くても全体のコードの品質はなかなかあがりません。
知見を布教する、というのは結構難しいことです。仮に今回のスライドを共有しても、全員が読むとは限りません。読んでも読んだ内容を実践して身につけるまでいける人はあまり多くないのでは、と思います。
個人的にはペアプロやモブプロで既存のテストのリファクタリングを進めるのがオススメです。みんなで試行錯誤するのを続けていくと、きっと自然と知見を獲得していけるはず。
Like(1)
grpcはhttp2が必要だと思うのですが、railsでgrpcをやり取りする場合の実装はどうされているのでしょう？ 内製のgrpc gemでカバーしているんでしょうか？ （本題でないのでということであれば懇親会で聞きます）
はい、そのあたりは以下のgemで実装されています。 https://github.com/cookpad/grpc_kit
http2の部分でいうと、上記gemが依存している以下のgemですね。 https://github.com/tenderlove/ds9
Like(0)
Webのフロントエンドはマイクロ化できますが、iOS/Androidアプリの場合はどのように解決されているのでしょうか
こちらはまた別アプローチで、内部のモジュール単位ごとに分割していくという戦略です。詳しくはこちらをごらんください。 https://speakerdeck.com/giginet/cookpad-techconf-2019-xia-gaguan-kutukupatudoiosapurifalse-po-huai-tochuang-zao-sositewei-lai
Like(0)
Q
「ドキュメントを読む能力が育ってしまう環境はよくなさそう」とのことですが、1次情報にアクセスして入手できるようになったほうが良さそうに思ったんですが、どうでしょう？🤔
A
懇親会で @hanachin さんに確認しました。
エディタでマウスオーバーしたら表示されるなど、1次情報にアクセスすることすらしなくて良い仕組みがあった方が良いとのことでした。
< 発表後の質疑応答で説明していただいていた
Like(0)
ガラケー版は基本的にメンテナンスしてない、とのことですが、アクティブに開発されているアプリケーションに起因する変更によってガラケー版が壊れたりすることはないのでしょうか？また、壊れたときは直すと思うのですが、そのメンテナンスコストは払えているのでしょうか？
します！その場合はもちろん直しますし、そのメンテナンスコストが払えないのでサービスを分離したいと思っています。
Like(0)
Aggrigation LayerとしてのGraphQLという話が出ましたが、grpcやREST APIとの使い分けはどういう視点で考えられてるんでしょう？
バックエンドのマイクロサービスは gRPC や REST などで機能単位で実装し、BFFやモバイルアプリなどは、裏にどういうサービスがいくつかるのかを意識せずに GraphQL だけにクエリする、ということができればいいのかなと考えています。もしからしたら GraphQL は必要なくて、フロントのほうも各サービスのgRPCを呼び出すのでも済むかもしれませんし、まだ構想中なのでたしかなことは言えないです。すいません。
Like(0)
デザインの統一やボタン配置といった、複数のチーム間で揃えないといけないユーザ体験はどのようにコントロールしているのでしょうか
sara という UI フレームワークがあります。内製の Bootstrap のようなものです。昔の資料ですがこちらを参照ください。 http://cssnite.jp/lp/lp26/CSSNiteLP26-s9-ikeda.pdf
Like(0)
S3のバケット名やDNS名のようにアカウント単位ではなくAWS全体でユニークな場合はstgとprodで同一のコードを適用できないと思うのですが、そこはどのように解決してるのでしょうか？
Like(0)
Cookpad社ではEnvoyを使っている話が昨日あがりましたが、nginxとの組み合わせはどのようにやっているのでしょうか？
gRPCのフロントや service mesh の data plane には envoy、gRPC以外の reverse proxy には nginx という感じです。nginx のレイヤーが envoy に置き換わっていく可能性もあるかもせんが、今のところは未定です。詳しくはこちらを。 https://techlife.cookpad.com/entry/2018/05/08/080000
Like(0)
スクラム導入前の「成果が出せてなかった」というのは、なぜそう感じられたのでしょうか？もしくは、具体的にどういう状態だったのでしょうか？
一番はわかりやすく機能・改善が出せてなかったことでした。 あとは副次的にKPT(のちにプレ期では廃止したのですが)keepよりproblemの数が圧倒的に出がちというのは一つ基準としてあったかもしれません。 とにかくドタバタだったため、これは健全じゃないと直感的に思ってたところもまた大きいと思います。
Like(0)
チームの中でスクラムの理解を深めるためにやったことなどはありますか？勉強会などされたりしたんでしょうか？
さきほどお答えをさせていただきましたが、勉強会は特にしてなかったんですが 一人チームに経験がある人がいたのと本をおすすめしていました。 本を読んでなかった人に関しては、というか普段の業務のいろんなところで 「こ～できるといい感じになりそうだよねー！」っていいながらスクラムの感覚を喋り続けてたので もしかしたらそれは効いたかもしれないです！
Like(1)
Charty は gruff や Rubyplot のラッパーライブラリという認識でよいですか？ 直接それらを利用するのではなく、Charty を使うメリットはなんでしょうか？
Like(1)
公式のgrpcジェネレータでは達成できなかった内容(主な内製理由)はどのようなものがありますか？
マルチプロセスの問題、Graceful Shutdown などの問題です。詳しくはこちらによくまとまっています。 https://speakerdeck.com/ganmacs/grpc-in-cookpad
Like(0)
Copyright © 2018 Yoshiyuki Hirano
@yaboojp
簡単な back-office などのちょっと JS を使いたい要件であれば普通に使うと思います。
Like(0)