Questions and feedbacks

284km
284km commented 4 months

質問ありがとうございます。

  1. Data Abstraction Layer を用意したことにより、サポートしているデータ構造 (現在のところ Daru::DataFrame, Numo::NArray, NMatrix, ActiveRecord) であればどれでも同じように扱えること。

  2. Plotting Abstraction Layer を用意したことにより、サポートしている plotting library (現在のところ maplotlib, gruff, rubyplot) であればどれで統一されたひとつのインターフェースで扱えること。

  3. 1, 2 により、ユーザが使いたいデータ構造、Plotting library の組み合わせで自由に plot できること。

  4. Charty の用意している設定により、render メソッドを呼ぶだけで、"そこそこ良い感じ" の設定でグラフを描画できること (それぞれの plotting library で、きれいなレイアウトでグラフを出力したいとすると、細かなオプション指定を自分でする必要が生じます。その手間を省き、data plot のために時間を使うよりも、本来目的とするデータ解析に集中することができる状態になること) が、Charty を使うメリットです。 なので、手間をかけて詳細に plotting library のオプションを設定してでも、自分好みのきれいなグラフを出力したい。といった用途では、Charty を使わずに、直接自分の使いたい plotting library を使わなければ、やりたいことを表現できないことがあります。

この様な特徴を理解して Charty を使うとよいと思います。 また上記とは別に、 Charty がより多くのケースで便利に使える様に、引き続き改善を続けていきます。

Like(1)

okuramasafumi
okuramasafumi commented 4 months

現在のBasecampでの「サイエンスプロジェクト」で話せることがあったら教えてください。

Like(0)

kirikak2
kirikak2 commented 4 months

ActionTextはActionViewを使っていなくてSPA主体のアプリケーションでも何か恩恵をうけることは出来ますか?

Like(0)

aeroastro
aeroastro commented 4 months

モックのAPIやAPIドキュメントを作る作業はフロントエンドチームとバックエンドチームが共同で作る体制でしょうか?

はい。案件ごとの差はありますが、共同で作る体制が多いです。 例えば、満たすべき要件に対して両者で話し合いながら概念設計を進め、その結果をスキーマに反映し、モックのAPIやAPIドキュメントを作っていきます。バックエンドチーム、フロントエンドチームが、それぞれの得意な領域から、設計に対してフィードバックしていきます。設計の為のたたき台を作ったりする部分や、設計結果をスキーマに落とし込み、APIとして利用できるようにする部分はバックエンドチームが担当する場合が多いです。

APIの規模や難易度が大きくなるほど、よりスキーマ確定前の設計時の共同作業に比重が置かれる傾向があります。

Like(0)

aeroastro
aeroastro commented 4 months

gRPCの利用は検討されたのでしょうか?

はい。検討しました。 しかし、プロジェクト当初は、RESTfulを選択することによる恩恵が大きいということで、開発者の意向として RESTful が選択されました。

これらの背景をより詳しく見ていくと以下のようになります。

  • RPC or RESTful という文脈においては、特に Rails においては、 RESTful を利用することによる生産性向上が大きかった。
  • そもそも、検討時における gRPC は、エコシステムも含め、今のように成熟したものではなかった。

また、SDK において開発者に使いやすい I/F を提供したいという都合上、カスタムのコードジェネレータを設計・実装する必要があるという部分は 、当時、仮にgRPCを導入していた世界線であっても、あまり楽にはならなかったのではないかと推測されます。

Like(0)

aeroastro
aeroastro commented 4 months

命名変更以外の非互換 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)

itkrt2y
itkrt2y commented 4 months

ライブラリの乱立が落ち着いたとはいえ、JSはパラダイムが広くやはり情報収集は難しいと感じています 板倉さんがどのように情報収集をされているか教えてください

「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)

amatsuda
amatsuda commented 4 months

名前に関していくつかコメントをいただいていて、回答の切り口はいろいろあるかとは思うんですが、まあこういうのもアリかな、と思って、今回発表したgemをプレイリストにしてみました。 https://open.spotify.com/playlist/0rBaJpNYZWwyWBzzoufNPE

つまり、名前には対象の指示でも振る舞いの説明でもなく、単にイメージを想起させる作用というかそんな感じの役割もあるということですよ、藤村さん。 この中では特に hocus_pocus はまさにこんな感じだよなぁ、という感じで、懇親会でマニアの方から「hocus_pocus はもともと違う名前で作ってたと記憶してるんですが、わざわざ改名したのは何故ですか?」とご質問いただいたんですが、これに関してはこの曲の存在がそれなりに大きかったように思います。要は、「名前」としての "Hocus Pocus" というフレーズにこういうイメージを与えてくれたもの、という意味で。

Like(1)

banyan
banyan commented 4 months

@anonymous

  • cookie 系のライブラリで RFC6265 に準拠していると plus sign を encode しないですが、Rails はするために、converter などの処理があるライブラリを使っています。
  • 不便とは違いますが、preflight のリクエストが発生しないように同じドメインで受けて nginx 等で api サーバが assets に流すかなどをしています。

結構昔から SPA として切り分けているため、あんまり不便な点が思いつきませんね... すみません 😅

Like(0)

banyan
banyan commented 4 months

@yaboojp

簡単な back-office などのちょっと JS を使いたい要件であれば普通に使うと思います。

Like(0)

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