2024/02/16 に公開1818 views
2023/12/11 に開催された『UIT × Bonfire Front-end Meetup #1』について、出演者たちで語りました。
音声書き起こし
1. オープニング
@potato4d
こんにちは。uidアドコーデです。ユーザーインターフェイスとテクノロジーをする開発者のためのポッドキャスト uitインサイド、始めていきたいと思います。今回はですね、昨年の12月え、11日に開催されたuitかけるウォンファイアブロンテンドミートアップへの第1回のアフターショーを行おうと思います。 こちらですね、ご合計4名の相談者と、えーとに、お届けしたイベントとなりまして、かつですねえ、今回uitで、え司会進行を担当させていただいていただいております、わたく
@potato4d
とボンファイヤーの方で、え、進行を務めることが多い、えとは、はるけんさんと一緒にやったので、はるけんさんも交えて、今回は、 2人の司会進行と4名の相談者の計6名でやっていこうと思っています。よろしくお願いいたします。よろし。
kazushisan
それにそも、よろしくお願いします。では
@potato4d
あと、大の、アフタートークに入る前にですね。まず、今回ゲストが4名プラス機会でハルケンさんもいらっしゃることなので、少しずつ自己紹介していただきたいんですが、よろしいでしょうか。はい。同じく、
@halken
統一の司会担当してました、line株式会社デザイナーやってます、はるけんと申しまよろしくお願いします。
@potato4d
よろしくお願いします。では次、
kazushisan
ライヤフー株式会社のコースと申します。普段はアイスマリの開発をやっているフロントエンドエンジニアです。よろしくお願いします。
@potato4d
よろしくお願いします。こちら、
@potato4d
次はたまたさん、お願いできますか。
@spring_raining
はい。 わかりました。ええ、lineyahoo。株式会社の、ただといいます。プランはline公式アカウントの画面を主に開発しています。で、当日は管理画面向けuiponポイントの設計というタイトルで させていただきました。よろしくお願いします。じゃあ、次はまたさん、よろしくお願いします。
@himatani
はい、いの谷です。linf株式会社のソートチームに所属しています。 ま、全社横断で主にフロントへの中心になるんですが、技術支援を行って います。え。今って、ランキングはちょっとまだ非公開なんで、で、何も言えないんですが。はい、以前のやつを話してるので、きゃ、今日よろしくお願いします。はい、じゃあ、続いておさないさんはい、
@sosanai
えーら、linyaho。株式会社のコミュニケーションカンパニーのでま、3年目の、yahoo。メール担当一緒でさなと申しますと、uitではnoで学んだ通説がとない方っていうところで発表させていただきました。 おそよろしくお願いします。
@potato4d
よろしくお願いいたします。はい。所属の担当しているプロダクトの様々な、メンバーでのイベントとなったので、今日はそれぞれの技術であったり、プロダクトに深掘りしていこうと思っております。ではですね、ftに移る前に、簡単にイベント概要の方をおさえさせていただければと思います。 uitかけるボンファイアフロンテンドミートアップはですね、12月11日にyoutubeライブとオフラインの会場で開催されたイベントとなっております。当日のアーカイブについてはですね、ノートの方に、埋め込みで、youtubeライブのアーカイブを
@potato4d
埋め込んでおりますので、もし、よろしければ、合わせて、そちらもご覧になっていただければな、と思っております。 で、今回は、テーマというよりは、プロダクトであったり、技術にあったり、であったり、それぞれの専門領域のところにフォーカスするっていう、な、形になっているので、登談内容も、 多種多様となっております。そんな服があったかっていうのは、今回のポドキャストを気にいただくのはもちろん、この前youtubeliveをご覧いただく、あるいは、タイトルとか、知りたい、タイトル資料の方を知りたいっていうことであれば、ショートの方にですね、
@potato4d
コンパスページでのリンクと、スピーカーテックで購買しているものに関しては、スライドでのリンクを 貼っておこうかなと思いますので、ぜひ合わせてご覧いただければと思っております。 というわけで、もう今、これ、収録がですね、年を越して、1月の収録ってなってるわけですけど、なんかアフターショー
2. Tamadaさんの発表について
@potato4d
ていうところで、当日の内容から変化があったら、ちょっとその辺から話せればなとか思ってるんですけど、12月に話した内容からこんな変化があったよみたいなことあったりする人っていたりしますか。
@spring_raining
そうですね、それで言うと、じゃあ私の方はペンか、言うと
@himatani
ですね、あの内容、
@spring_raining
おお。まず簡単に説明しますと、uiコンポーネントを、ウェブコンポーネントで提供するっていう話をしたんですけれども、 そうですね、話の内容からは、メインの方針は変わってないんですけれども、やっぱり、そうですね、 コンポーネントをどんどん揃えていこうっていう段階になっていて、ダブの話をしたんですけども、それに割と手を言うことが、
@spring_raining
て、手を入れるというか、ザグの行動を読むことが結構多くなったかなっていう感じにはなってますね。で、そうですね、結構あの 話し、その、発表した時点での内容では、あのステートマシーベースの、あのステートカルみたいな話をしてたんですけども、ちょっと、 なんつうすかね、あんまりこう、ケトマシーンみたいな、に、こだこだわるっていうか、そこに囚われすぎる必要はないからって、単純に、そんな便利な、
@spring_raining
おか、状態管理のライブラリーみたいな感じで、 食べるのがいいかなっていう風に、ちょっと始めてますね。そうですね、例えば、例えばというか、リアクトで言うと、1番、結構近いなって思ったのは、リアクタリアっていう、 だいぶ足があるんですけども、あれを、リアクト依存したものみたいなのが、結構、感覚として近い。その、ザグ
@spring_raining
の提供してるそのステップマシンの間には、すごいやと、使わなくても実現できるみたいな、こう、便利ツールみたいな感じで、最近、 これ、直してません。
@potato4d
なんか、こう、思想的な部分とか、こう、捉え方みたいなのを、そのまま、こうすっと、それに準ずる形っていうよりは、どっちかというと、実理にあったというか、
@spring_raining
実際、その、なんていうんすかね、ステートマシーンっていう名前なんですけれども、あんまり実際、ステートってそんなに活用されてないなっていう、本音としてあって、そう、そうなんでしょうね。全然、 なんか、デートって呼ばずに、単に簡単にその、アクセリティの対応ができるような、フレームワークに依存しない uiアンシみたいな感じですかね、ちょっと表現が難しいですけど、それか、止め直してますよね。
@potato4d
なんかあれですかね、ヘッドレスな機能を提供してくれるツールとして、 シンプル、情報できる、共通な感じですね。あんまり私、こういう、出会いライブラリー自体のパターンをこう、色々充実させていくみたいなのってあんまりやったことがないんですけど、 なんか他のプロジェクトでこういうのや経験したことあるよ、みたいな人います。いるのかな。
@spring_raining
あんまり。あれですかね、uiコンポーネントなしに
@potato4d
あまりいない、あれ、そうです、
@spring_raining
充実してますもんね。リアだとほんとにうんうん、いっぱいありますもんね。
@potato4d
契約とかだと、あ、デザインシステムとかもあったかなと思うんですけど、なんかデザインシステムとかで、こういう機能まで含めたui的な、コンポーネントの開発とかってあったりしましたかね。それだと
@halken
あったとは思いますね、多分。ただ、各部で
@potato4d
と合コンポレントか
@halken
にしていくかみたいなのは書そうっすね
kazushisan
ところで試行錯誤してたんじゃないかなと思う。あ、じゃあこ
@potato4d
こう統一的にこういう技術で、なんか何かしらのコンパーメントが提供しているみたいな感じはそんなにない。
@halken
やっぱそこの取捨選択して、自分たちが使いやすいというか、ものをやっぱ選んでるんじゃないかなと思ってます。
@potato4d
なんか、例えばはるなさんの現場とかだったら、そのデザインシステムに合わせた実装みたいなのするときってどういう風に実装されてました。どういう。
@halken
そうっすね。ま、でも基本的にまず ステップとしてはと。昔ですけど、昔、そのバトミックデザインってのが流行ってた時期があって、 その既存のデザインに対してまずコンポーネントを何が必要かっていうのを切り分ける作業から始まっていって、で、そこから、じゃ、このコンポーネントが必要だよねから
@halken
まず作り上げたことからがまずは最初で、そこからこのコンプレットを作る上で何のライブラリーとかが必要とか、なんの機能が必要。
@potato4d
ていうだま、若干後付けっぽい感じで
@halken
作り上げていって、ほんとになんかこう、必要になった時た課題になった時に、えー考えて、どんどん作り上げていった感じでしたかね。僕の場合はそうでしたね。
@potato4d
あーなるほどなるほど。はい。これは今回のたーさんがline公式アカウントで使ってるみたいなやつって、こう、今の実態に沿った形でパーツを定義して、それをこう、プロダクトに当てはめられるようなリードで ご利用していくみたいな形になるかなと思うんですけど、結構あれですかね、その、はるなさんの現場とかであれば、今あるプロダクトのユーザーインターフェイスをデザインシステムの何かま1つと解釈して、そこにちょっとずつ置き換えて適応していくみたいな感じが多かった。
kazushisan
ここからこう入ってい
@halken
で、で、そのコンポーネントが他のサービスで使えるのか、使えるような状態になったら他のサービスに提供していくような形にして
@potato4d
行きつつ、で、
@halken
さらにそこで必要になった追加が、あ、コンポネントが多分必要になってきた時にどんどんまた作り上げていったよ っていう組み合わせでこう作っていったっていう感じだったですね。はい、 ありがとうございます。
@potato4d
結構、やっぱあれですね、ツンドベースの都合によって、この辺の利用技術であったりアプローチってのが変わってくる部分が変わってくる。
@himatani
そう言いますね。はい。
@potato4d
なんかあれですよね、逆に言うと、おたさんのプロジェクトみたいな、1つのサービス、1つのサービスっていうて正しいんですかね。はい、じゃあ、 そうですね。アプリケーション上のコンポイントは1つ、複数ある。はドメインとしては1つのサービスの、専用の uiデザインの、この中限定のデザインシステムみたいなのが、結構どこの現場でも、もしかしたらline、yahoだと珍しいんですかね。なんか全体のデザインシステムを適用するか、サービスごとに
@potato4d
まちまちな祝いを提供してるか、みたいな気がするんで、もしかしたら結構珍しい事例である可能性がありそうですよね。
@halken
で、こう、そういう、なんか管理、その、コンプリート、そして管理したいとい おい作りをしてるのは多いんじゃないかなって思ってます。さ、
@potato4d
いつも。はい。なるほど。であれば、ちょっとなんかあれですよね、こう、なんか、ザグとか使ってるプロジェクトがあったら、ぜひ聞いてみたいところではありますよね。そうですね。多分、
@halken
今、一旦、このリレーとしてはザ、ザが多分1つあって、他のところでどうしてるかって多分
@spring_raining
違うと思うので、この動向は
@halken
もしかしたら聞いてみたいところはある。
@potato4d
いますね。はい。
@spring_raining
あーい こ。そういうわけではないんですかね。その、ここの、その、プロダクトで、アプリもありますよっていう風には書いてるんですけれども、基本的には、ウェブベースと 考えて
@spring_raining
もらえれば、その中で、その、コンポーネントを、さっき言ったように、その、なんか、ドメインとしては1つなんですけれども、こう、サービスが複数あるみたいな状況で、導入するためっていうのが、
@spring_raining
感じでありますね。
@potato4d
確か、あれですよね、line公式アカウントに関しては、管理画面としての機能が膨大すぎるので、結構、1機能のまとまりで、1プロジェクトは、テリポジトリーみたいな形で 管理してるんで、実態としては、別のプロジェクトの集合体みたいになってるんでしたっけ。
@spring_raining
そうですね。私たちの管理してるプロジェクトでは、基本的に、その、バンドルリポジトリは別なんですけれども、 1つのサービスとして、ビルドされますが、それとは、また別に、こう、 なんていうんですかね、別のページとして、提供してるところもあったりしますね。公式アカウントの管理画面の、本体は、そうなんですけども、例えば、その、プロフィールの画面とか、あと、チャット画面ですよね。チャットなんで、その、
@spring_raining
そこらへんは、また別のチームで開発してみたりして、で、ギルススタックも全く別の 主になっていたりっていう感じなので、もっとyahooのサービスでも多いと聞いたんですけれども、スページごとに全然ルスタッフが違うとか、別々で管理してるみたいなのがあると聞いていたので、それに近い 感じですかね。で、その、別々のページのテーマを統一させるためのubコンポーネントみたいなモチベーション
@himatani
やだで、ちなみに、以前のお話だと、ビューの2桁から3ペへの移行も進んでるって話を確かされてたかなと思うんですけど、 それもやっぱページごとに、ここ、このページは今p3dみたいな感じで移行して感じでしょう。
@spring_raining
えーっとですね、移行計画で言うと、今後、状況によってはその一部分からこう移行させていくみたいな可能性もありますよ
@potato4d
というと、あれですよね、こういうののuiコンポーネントがb3のみに対応してるんで、 これに移行するタイミングでb3にしましょうっていうのが1番やな気はするんですけど、それをすると、じゃあ 使いませんっていう選択肢が出てきちゃうんで、ハイブリッド対応せざるを得ないみたいな部分ありますよね。
@spring_raining
そうですね。いや、それが理想なんですけれども、その、なんて言うんすか、ステージ単位で段階的にビースへ移行するっていう話 よりは、むしろ小さな単位からこうビース移行というか、ビス行っていうか、モダナイズモダン化する みたいな計画で進んでいるので、まあ例えば今回で言うと、そのコンポーネント単位でビュースレディのものに移行して、
@spring_raining
で、最終的にこう、ビースリーかみたいな感じの方針ではあるんで、対応するためにも本放ネント側は両方流流両方で使えなくてはいけないっていう 事情はありますね。
kazushisan
このプロジェクトだと、発表の中だと確かビーツとビュースしか出てこなかったと思うんですけど、 他のプロジェクトだとビートリアクトが同じドメインだけどアプリケーションとしては違う みたいなところで、両方栄養されてるみたいなケースもあったりすると思ってて、そういうケースでこのアプローチがどう機能するのかみたいなのはすごい気に
@spring_raining
なりました。そうですね。実際運用されているというわけではないんですけれども、実際のところ、さっき言ったそのチャット画面とか、 あとプロフィール編集画面とか、そういったところはアクと動いていたりする。そういや、ちょっと、すいません、確認するんですけど、 どちらかは少なくともリアクトだった期間
@spring_raining
で、そういった感じで、それぞれのサービスのデザインの統一化を、 あっていうのが、その冒頭で話したそのブートストラップベースのccフリマークだけみたいな感じですね、という感じなんで、 それをこう、壊さずにそのuiコンポーネントに移行したいというのが
@spring_raining
やりたいことですけれども、ちょっと今開発しているのが理由なので、理由のラバーコンポーネントに今注力しているという 状態ではあるので、今後はやっぱり両方、両対応としたい。
kazushisan
なんか冒頭でザグの捉え方を変えたみたいな話があったと思うんですけど、やり方するとなったら 冬の思想とリアクトの思想を両方にマッチするような感じ。なるほあ。それもまた新しい課題になりそうですごい面白そうだな。
@spring_raining
はいはい、確かに。ただ、おたり、難しくは。難しくはないってか、やっぱり思想はそんなに変わってないなとは 思い出せそう。なんて言うんすかね、こう、プロパティがあって、イベントがあって。みたいな、そういう感じのところは。 まあ実際にそのラブのリアクトという量はたりをしているので、その、なんか、それほど、思想的な違いみたいなの
@spring_raining
を、こう、こちらでラップするっていうよりは、忠実に、なんていうんすかね、その、リアクトのコンポーネントとしてのベストプラクティスにあったapiにする、 ていう感じに作業になりそうです。
@potato4d
でも、なんか、薄いライブラリーをこう、使う話を、結構、たまさんがこの本編内で話してたかなと思うんですけど、 なんか似たような軸で、これもuiコンポネントっていうわけじゃないですけど、似たような、またさんが話されていた、同意用のモーダルの sdkの開発。あ、はい、やつけ面白いなと思っていて、この、ライブ、ライブラに完全にいぞ依存しないで、機能だけを提供するみたいなの、面白いなと、この場で詳しく聞きたいなとか
3. Imataniさんの発表について
@potato4d
思ってたんですけど、
@himatani
あ、そうですね。確かに、その、呼び出し元のサービス側が、リアクトで作られてるのか、ビで作られてるのかっていうのは、こちらでは、 コントロールというか、基本的にはそういうことはできないので、というuiフレームワークを使われていたとしても、 ま、正しく動くようにしないといけないっていうところで、ブライバリーは使わないっていう選択をしてましたね、
@potato4d
俺って、発表中に少し気になったんですけど、フェッチが対応してない可能性があるからエア使うみたいな話が、 出てたかなと思うんですけど、この使っていい技術みたいなところの、基準ってどういう風に置いて実装してたんですか。こ、こ
@himatani
こはですね、サポートする加減のバージョンを定めた上で、じゃ、 何だったら使えるのかっていうのを精査していったっていう感じにはなり
@potato4d
なこと。このios、androidwebのま、3プラットフォームの下限の最大公約数みたいなところを対応範囲にして、それで使える範囲の技術で ていったみたいな感じですかね。
@himatani
正確には、えっとー、そうですね。ウェブでの話になりますね。今回、webビューとかではなくて、ios、androidはそれぞれのネイティブのコードで実装されていて。 そうなんですね。はい。で、ウェブはウェブで、という形ですね。はい。なので、完全にウェブの中での話と捉えていただ。なるほどなるほど。
@potato4d
インアップブラウザみたいなところでは古い機能しか使えないみたいなのはそんなに気にしなくて良いと言えば、
@himatani
ていう風だね。はい。これは、検出しなくていいポイントでは。
@potato4d
これってもし話せたらいいんですけど、利用者側から見たインターフェイスみたいなのを、 もしかしたらこう、あんまりモダンじゃないもので、一旦提供しないといけないみたいなことになるかなと思うんですけど、sdkとしてユーザー側はどういう風に呼び出して、どういう 結果が返却されるのを期待する設定にしてたんですか。
@himatani
そうですね。あのスクリプトタグをこう読み込んでもらって、こちらが提供しているメソッドを呼んでもらう。 で、呼ぶときに、あの引数として必要な情報を渡してもらって、それを受け取って処理を行うっていうような感じをみたね。
@potato4d
なんかこの、結構あれっすか、ウィンドオブジェクトを減らして触るみたいな、いわゆる一般的なsdk、あのweb向けsdkと同じようなインターフェイスで提供してみたいな 印象ですかね。
@himatani
そうですね、そうです。まさにそのwidオブジェクトで、そうですね、片手をちょっとこうやって押して、はい、持ってきてっていうことをやってますね、
@spring_raining
最初、その、なんですか、webとiosとandroidを全て対応っていう話だったと思うんですけれども、3つのその環境でインターフェースとか そういったものを、こう、統一感を持たせるために、こう、どういったことをされましたかね。
@himatani
うーと、そうですね、こう、やっぱり、それぞれの記述がやっぱ違うので、厳密にこう、一緒にっていうのは、まあま、難しいと思う。 持っていて、一方で、その、最低限ここは統一化できるなんてところで、こう、なんなんですか。下に揃えたというか。あ、はい。協力、こう、独自の こと、例えば、ウェブ独自の、この、なんか、パラメーターを増やすみたいな、極力避けています。ウインドオブジェクトを介して受け取るのも、極力、こう、
@himatani
ま、データの容量とかを気にしたりとか、個数が大きすぎるので、どれだけ少ない転送量で、スクレンド読み込んでもらって処理を行ってところになりますね。ありがとうございます。
@spring_raining
これ、あのな、なんで聞いたかを言いますとですね、私はがプロジェクトでios向けのコンポーネントを 提供することをを検討していまして、結構、なんていうんすかね、そもそもそのweb開発者がiosの の開発者に向けたライブラリを提供するのどうやればいいんだっていうのが全然見当もつかないみたいな状態になっていって、
@spring_raining
結構、そうですね、そのあたりどうやってたのかなっていうのは気になったりしてます。
@himatani
そうですね、そう、インターフェイスもそうなんですが、結構、その、見た目のデザインとかも揃えなきゃいけないっていう、要件がありましたので、 あ、そう、ど、どういう功績をすれば、各プラットフォームに揃うんだっけっていうのは、結構、難しかった、自分のプライベートの話にはなるんですけど、すと、androidと、それぞれ、sftuiであったりとか、ちょっと、パックコンポスであったりとか、自分で、練習がてら
@himatani
作ってみて、あ、ウェブだとこういうuiは、ネイティブだとこうやって書くんだねっていうのを目でな、じゃ、どういうデザインしたらそれをこう作りやすいんだっけっていうのを 考えていったっていう側面もあります。
@himatani
そうですね、基本的な、考え方というか、先天的なところはだいぶ共通するところが大きいので、はい、なんですかね。傾向とか雰囲気 が分かれば、あ、こういうui、こういうデータ構造であったら表現しやすいんだろうなというのは自ずとわかってくるかなと思います。
@sosanai
いや、でも、いやあ、また
@spring_raining
そのうち質問するかもしれません、
kazushisan
質問したいんですけど、なんか先ほど、ウインドウオブジェクトにあやす形でのインターフェイスになってたみたいなのを伺って、
@spring_raining
なんか、僕
kazushisan
ならlpmパッケージにすることとかも考えられるかなって思ったりしたんですけども、そういう企画とかは、 開発の際、どういう風にこうアプローチを決めたのかな、みたいなのは気になる。
@himatani
そうですね。今回かなりスケジュール限られてる中で、じゃ、どこまでできるんだっけっていうのもちょっと考えていて。うん、 そうですね。ま、まずは最低限ctnで読み込んでもらうような形で、社内の、ストレージから配信するっていうような形にとってって。 で、その上で、え、pmパッケージにするかどうかっていうのは、時間があれば考えましょう
@himatani
感じだったんですよね。で、結局、いや、そこまで求められてないよねっていう結論に至り、見送ったという背景があり、
kazushisan
確かにこう、いろんなサービスとか対応させるとなると、lpmパッケージとかよりもこう、より影響範囲が決定されてるものの方がいいってことなんですかね。
@himatani
そうですね。いろんなサービスと言っても、リストはあって、このサービスとこのサービスっていうのはあったんで、こう、そんなにこう、 無限にあるみたいな感じでもなかったっていうところで、コミュニケーション取りながら、最低限何があればいいんだっていうところのますり合わせをしていったって感じですね。
kazushisan
例えば、どんどんapを使っちゃいけないみたいなのって、結構レビューとかで見落とし、僕なら見落としてしまいそうだなって思ったりしたんですけど、開発のツールだったりとかを使って、このあたりとか 機械的に工夫するみたいなことはあったりしました。なんか言い換えると、どういうこのビルドを使ってたのかな。みたいな、すごい気になり
@himatani
そうですね。そうですね。ま、ですね、機械的にこう落としたっていうのは、あんまり、出来なかったポイントではあるので、そこできたら、もうちょっと良かったのかなとは思い ですね。はい。で、そこは、結構、レビューで担保した部分があって、社内でも、フロントの詳しい人からレビューもらって、これ大丈夫だよねっていうのを確認していたって、
kazushisan
スリートだったりとか、そういうツールとかで、こう分けることができたら、面白そうですよね。
@himatani
そうですね。でも、次やることあれば、まず、そこの整備をしたいなとは思っていて、そこは、心残りというか、1つではありますね。
kazushisan
ちなみに、ビルトはどういうツールチェイだったんです
@himatani
か。どこまで話せるかな。
@himatani
うーん、そうですね。ま、基本的にはそうですね。ウェブパックで、バージョンを定めて、それに合わせて トランプタイルするような形で組んでますが、そんな、なんか複雑なことはやっていないです。
kazushisan
あ、そうなんです。
@himatani
はい、
kazushisan
なことです。いや、めっちゃありがとうございます。すごい気になってました。
@potato4d
おせなか。続けて質問しちゃって申し訳ないんですけど。はい。さっき話 なったか。で、その、webと、ios、androidで、その、それぞれのsdkでインターフェイスを変えることをしたくない、追加のパラメーターを増やしたくないみたいな話があったかなと思うんですけど、 その場合、呼び出し方みたいなのは全部プラットホーム共通で、なんか1つの道みたいなのにsekのドキュメントとしてまとめてたりするんですかね。
@himatani
あ、そうですね。利用者向けにドキュメントは展開していて、そこにこう、それぞれの実装方法みたいな感じのをのせ、
@potato4d
なんか、例えば、スイフトや、javaであったら、なんか、sdkを実装すると、自然と、あ、ドキュメントと、 それぞれのリストをライブラリーとしてインポートすることになるんで、型定義とかもついてくるかなと思うんですけど、ウェブ用で提供する場合って、専用のdtsとかは出さないと、こう、 普通のgsとしてたことになるかなと思うんですけど、その辺までやったりってしてました。
@himatani
ウェブの場合、結論から言うと、できなかった、ほんとは、その、片手まで、こう、整備して渡してあげたかったというところはあるんですが、 これ、なかなかちょっとそこまでできなかった。かなりスケジュールがパリットでできなか。
@potato4d
あ、でもあれですもんね、npパッケージをパッケージとして提供してないのに型定義だけ配信しますってのは、結構ややこしいことにもなります。
@himatani
それはそれで、そうですね、その辺りは、その、なんなんですかね、タイプラインと言いますか、その、まあcicdのフルを整えていくところのコストがやっぱりどうしても大きくなってしまうんですよね。やるならそのnp
@potato4d
パッケージ化と一緒にっていう風な形になりますよね。
@himatani
てときに、じゃあctnで配信してる方はどういう感じで更新するんだっけ。とかの話も出てくるので、そこがなんですかね、
@potato4d
全体の構成のシンプルさみたいなのを優先して。そうです。設計するって形な
@himatani
あれですね。そうですね、はい。
@potato4d
確かにその、どれだけのプロダクトがその方で使うかわからないので、コスパ的に優れるかも正直なんとも言えないところですもんね。そうですね、はい。 あ、ありがとうございます。
@sosanai
自分が気になってる件あるけど、なんか1点1点いた。まじで。1点目は、 その、開発のところで、期間とどれくらいの人数の方いたのかなっていうのは、ちょっと気になってます。 えと、2つ目は、じゃあ、テストの範囲が広いのかなと思ったんです。でも、そこについても、時間、もしくは情報等出してがいいのであれば、
@himatani
教えていただき、あ、そうですね、体制の規模っていうのは、ちょっと際どいかなと思ってます。あ、そうですね、ウェブの方に関しては、と、大部分を私が実装 して、で、プラス1名が、行動のレビューとか、そうですね、テストの拡充とか、 ヘルプをいただいてました。そうですね、はい。で、もうちょっと言うと、今回のノーダル版と、
@himatani
フルスクリーン版と2タイプをこう作ってたんですが、フルスクリーン版の方は別のか、 他にも、ヘルプで入ってもらっていて、トータル3名という 体制でwebはやってました。で、メインの実装は、私がそれぞれいろんな、こう、見た目に合わせて、いい感じになるように実装したっていうような
@himatani
背景です。
@himatani
とはですね、かなりこう、パターンが多くなって、まとめてやってましたね。iesとandroidもそれぞれテスト対象 ですし、ウェブはウェブで、ウェブのandroid、ウェブのios、 もう当然あるので、ほんとにいろんなパターンでテストをしなきゃいけなかったっていうところ
@himatani
ですね。ま、実記の確認も含めてなんて、かなりパターンが多いというか、時間がかかったところですな。ん
kazushisan
ああ、結構色々深掘りしてた
@potato4d
いい時間になってきちゃったんですけど、なんか
4. Konosuさんの発表について
kazushisan
正直そんなにアップデートがないんですけども、こう、atベースでコードを解析して何かをするみたいなのがチーム内にも波及していて、 別のところでもあのatを使って解析しましたみたいなのがチーム内で出てきたので、それはこういうツールを作った福祉的な、 効果として良かったなと思っています。
@potato4d
それってなんかどういう感じのツールの開発があったんですか。
kazushisan
結構アプリケーションの中ってイベントをアナリティクスのためにとってるところがあって、ただそれをイベントって試作だったりとか行動に変更があるたびに変更が発生しての 管理できない、収集がつかない状況になってたんですけども、その、今やってることとしては、この中でイベントを送信している箇所を一通り呼び出してきて、 どういうイベントをアプリケーションから送信してるかみたいなのを分かる形にアウトプットするみたいなものをですね。
@potato4d
なるほど。ここになっていな。初動で管理しなくても、今どういうイベントをプロダクトが送信しているかみたいなのが
kazushisan
可視化されるみたいな。そうです。結構今までは企画の人が管理してる表と 実際に送信されてるものが解離してるみたいな状況があったんですけども、シングルをソーススルーじゃないですけど、それをこう、1つを制御することで 管理のコストを下げようみたいな話です。
@potato4d
やっぱなんかこう、実装で送っているのがたせいになるというか、ドキュメントが正しくて実装が間違ってるってことは基本的にないはずなので、実装に合わせる方が正しい
kazushisan
結果がの方がコスト減られる、減らせるだろう
@sosanai
ていう判断ですね。
@potato4d
だから、その、そういうツール作るときって、結構、今回の、アプローチとかも、tsボンバーアンドみたいなものだったら、お、 個人でメンテしてるものをちょっとチームでも持つみたいな感じで、メンテできるようなものになるかなと思うんですけど、プロダクトにがっつり関わってるものとかだと、結構astを使うアプローチみたいなのって、そんなにこう、普段のアプリケーション開発だと 出てこないので、他のチームメンバーがメンテしづらいみたいなこと出てくるかなと思うんですけど、そういうのってこう、どういう風に対処してます。現場では。
kazushisan
確かになんか結構このatベースのアプローチして、 最初のトプカリみたいなの、すごい難しいなみたいなの課題感としてあって、そこがの理解が進まないと なかなかプロジェクトの中に書いてあるツールがどうなってるかとかも理解が進まないと思うので、割と最初の方はペアプロとかをして、どういう風に
kazushisan
やればいいかみたいなのを、広報活動じゃないですけども進めていったので、なんかそれがあったおかげで、こう、結構やりやすい、チーム内でも浸透したかな。 あー
@potato4d
確かに。なんかa3周りってこうなんでしょう。 とっつきづらいっていうのがすごいこう1番の課題なんで、触ってみればそんなにめちゃくちゃ複雑なことはやってないって特徴があるので、すごい。1人がまずはイーストを行うみたいなのもすごい有効なアプローチに。
kazushisan
そうね。で、結構ペアプロとかをやると、あ、案外簡単じゃんみたいなフィードバックを得られて、ほんとになんかやってみたらすごい簡単なはずなので、 そういう意味でも、その勉強のフェーズの時間をすごい圧縮するって意味でも、エアプロとかは割と、ボイケスはすごい有効なのか。
@potato4d
確かになんか特にこのエステを触るっていうアプローチ に対して刺さりやすいですし、なんか新しい技術で音つきづらくて、実態はそんなにややこしくないものには結構こう広く、 はじめはベアフロディみたいなのは
kazushisan
刺さりそう。あり、
@potato4d
ありがとう感じはしますね。私、
@spring_raining
昨日そのuiコンポーネントライブラリの話にしてた あれも。なので、そのastを解析するっていうのをやってるんですけど、結構やってて思ったのは、なんていうんすかね、解析しやすいastと しにくいnstが、できるだけその解析しやすいようなapiで設計するみたいなのが結構大事。
@sosanai
確かに
kazushisan
それに言うと、結構解析しにくいastみたいなのがやっぱり作業してる中であって、プロジェクトにこう強く紐づいたツールであれば、そのツールの方で頑張ってatを解析するまでもなく、 コードの方のインターフェースを変えてしまうみたいなのができるので、そこは割と柔軟に対応してたと思います。
@spring_raining
そうですよね。1番あの解析しやすいのはjsdocを書な気はしますね。あとあれなんですよね、それ全部そのテキストが 帰ってくるのに、まあ最悪そのジェイスドックにその、例えばジェイソン書くみたいなこともできるよ、みたいな。 めっちゃ使い方としてやってるのかわからないですけど、例えばパラメーターの説明を書くときとか、そういう時はすごい。
@spring_raining
jstokに書いとけば、tcは全部そのjstokのデータとかも、いや、tsmfの機能かもしれないですけれども、あのjstok基本的に入ってくるし、 あとアットのルールとかもなんかうまいことパースしてくれる。そうなんです。そう、そうなんですよ。あのリターンとかもすごい。なんかそこで書いとけば 後でなんとでもなるみたいな感じだったんで、最初jsbackの解析みたいなのはどっかかりとしてはめっちゃ良さそうだなと思いました。
kazushisan
結構めんどくさかったなわ。関数のおインターフェースがオーバーロードされてるところがあって、その、い、 運気が複雑になってたので、とりあえずオーバーロードを消して、あのシンプルなオブジェクトで渡すようにしようみたいなのはやりました。 あと、jsdokとか。確かにそのatの中の情報だけだと、やっぱり王道の情報しか入ってないので、
kazushisan
どういう文脈のコードかとか、多分わからない。そういうコメントに相当するようなものとかは、jsdokとかに書いてあると生成されるもの ですよ。なるほど
@spring_raining
確かに。
kazushisan
なんかjsdok全然使ってなかったですけど、改めてちょっと見てみようっていう気になりました。
@spring_raining
いやひ、結構ちゃんと考慮されてるんで、よかったです。
5. クロージング
@potato4d
だけど、結構、ちょっと深堀りをベースに、相談の文脈の、ちょっとコンテキストなあになってしまったかなと思いますが、突版まえて、と、変化であったり、ちょっと技術的なところの深掘りとかを話していたかなとも ております。もしですね、まだ資料見てないよっていう方でしたら、まだyoutubeのアーカイブ見てませんよって方がいらっしゃいましたら、是非是非、おしもあっておりますので、見てから ですね、再度聞いていただくのもいいかなと思います。また、adサイドには書き起こしの機能もありますので、今日話した内容で、タイムスタンプと合わせて、発話内容が
@potato4d
記録されておりますので、もし、後から振り返って、どういう話してたな。というのを見たいときはですね、そこと合わせて、例えば、資料や動画のライブのアーカイブと合わせて、そのあたり、再度見ていただいてもいいかなと思いますので、 ぜひぜひ、お楽しみいただければなと思います。 というわけで、今回は、uitかけるボンファイアフロンテンドビトップについて話していきました。linerhooのロンデンド組織ではですね、このような形で、この程度に関する議論や情報共有を日々をこな
@potato4d
おります。社内で行われている内容の中にはですね、これまでで、uitサイドで公開させていただいたものも多くありますので、今後、何かパブリックに発表できるような情報がしたいコードキャストっていう形で公開していければと思っております。 また、このコットゲストに関するご意見、ご感想に関しては、ハッシュタグハッシュuitアンダースコアイサイドにてつぶやいていただきますと、スタッフの方でさせていただきますので、ぜひぜひ、気軽に投稿いただければと思います。 というわけで、本日は6名でアフターさの方へ行きました。ありがとうございました。
kazushisan
ありがとうございました。
@spring_raining
ありがとうございました。