混ざらなくて意外と便利だなと思ってるんですけど。喜多そこはオプションで切り替えられるんですけど、CDNで配信するのでクライアントのキャッシュ破棄の目的でタイムスタンプを付けるようにしていますね。するみたいなかんじで一連の流れが出来るので、切り戻しも簡単なんで便利なソフトだと思ってます。正直にいうと、今ってデザインも別の部署なんですよね。一緒のプロジェクトをやっている人たちが韓国にいたりして、物理的に離れている場合もあって「どういう経緯でそういうデザインになったのか」とか「ここはこうしたほうがいいんじゃないですか」とかそういうやり取りがメールベースでやってしまうとやりづらいなというのはありますね。tokuhirom近くにいてもコミュニケーションするのって大変ですもんね。静的なサイトだったらまだいいですけど、動きとかも含まれてくると難しいですよね。喜多こっちで先に作ってみて、動くもの見せて、こんなかんじでどうですか?と聞いてみて、ここはもっとこうしたい、とフィードバックをもらって、直して、を繰り返しますね。動きが結構あるんでデザイナのこだわりも強いですし、実現するためにコミュニケーションはよくとるようにしています。tokuhiromではちょっと毛色の違う質問をしますね。自発的な行動をすごく求められているなという気はしますね。プロジェクトを特定の誰かが強くリードするのではなく、企画担当がもってきたアイデアに対して色んな部署から人がアサインされてお互いにプロジェクト調整したりとか仕様を詰め合ったりして進めていくってカンジが僕は結構好きですね。喜多そうですね、前職でもそういった指摘やフィードバックは返せてたんですけど、大きい会社から転職してきた人とかとお酒を一緒に飲んでると「企画が言ってきたものを一方的に作るだけだった」と聞いたりすることもあって、そういうカンジじゃないのがいいなとは思いますね。tokuhiromうちもそこそこ大きいカンジになってきてはいるものの、意外とフランクにやりとりが出来ますよね。コメント欄とかは配信によって大量のデータがくるので、色々試行錯誤しました。入っていない要素をレンダリングしないようにしたり、そもそも保持するデータを最大数百件にしましょうとか。喜多そこは過去の案件で踏んだ問題の記憶頼みな部分が結構あって「このコードだと、あのブラウザで変なことが起きるんじゃないかな」という予感がしたら、調べています。あとは企画担当から概要を聞いた段階で、そもそもプラットフォームの制約で出来る出来ないみたいな話。「スマートフォンのブラウザだとタップ操作をせずに自動で音の再生は出来ない」などを早めに洗い出してフィードバックを返すようにしています。ようなサイトで調べたり、プロトタイプを作ってみたりというところですね。tokuhirom企画の段階から技術的なアドバイスをどんどんしてるかんじですね。喜多そうですね、手元のPCにインストールされているブラウザや部署で共有の検証用の端末である程度は確認しますが、OS、ブラウザのバージョンの組み合わせ全てをカバーするのは大変なので、そこはQAの方にお任せしています。QAやるかんじですかね。基本的なロジックの確認以外にも、色々なOS、ブラウザ、端末で調べていただいています。どっちかというと、最近は、PCよりはモバイルのほうが問題が出る傾向があります。意外と新しいバージョンのほうが変な挙動をしたりとかありますね。あがってきていました。場合はビジネス的なピボットがけっこうあって、それを意識して、コーディングする時も必要以上に抽象化はしないようにしています。ビューライブラリはコンポーネント単位でファイルを分割するんですが、一見同じだからという理由でコンポーネント化すると後で「ここだけちょっと変えたい」とか言われる場合もあったりして。tokuhirom最近は縦動画がメインになったりしましたしね。喜多そうですね、最近はブラウザにパフォーマンスに関係するAPIやSpecが色々出てきている印象があるので、いくつか試しています。重要でない処理を後回しにして、描画処理を先におこなわせるようにしてみたり。サーバプッシュでSPAの初回表示に必要なデータを送って、初期表示を改善できないかな、と考えたりしています。やめたプロジェクトもあります。tokuhiromフロントエンドを実装していると配信のパフォーマンスをすごく早くしないといけないってこともありますよね。喜多そうですね、ライブラリ選定の時のポイントにもなります。Browserifyのプラグインでバンドルした結果のうち、円グラフで「このライブラリがこれだけ割合を占めてる」というのがわかるんですよ。いう日付操作のライブラリがあるんですが、結構サイズが大きくて。全体に占める割合が大きかったので、別のライブラリに乗り換えてかなりファイルサイズを削減できました。tokuhirom結構、配信サイズは気にしてるんですね。喜多グローバルで展開しているサービスもありますし、例えば、インドネシアやタイは日本に比べると通信環境が良くないと思うので配信サイズは気にしています。tokuhirom海外展開多いですもんね、通信環境がよくないと気にすることって他にも増えますか?ファイルサイズ以外に。基本的にはファイルサイズだけですかね。リポジトリがあって、issueで「こういうTips見つけました」と書いてくれたりしています。外部の勉強会のレポートとかもそこで書いています。tokuhiromフロントエンドはツールの移り変わりが激しいみたいなことがありますよね。一応試してはみますけど、筋の良さや、そのツールを使うメリット、長続きしそうかどうかといったところを意識して、取り入れるかどうか判断しています。tokuhiromじゃあ担当がそれぞれ使ってみるかんじなんですね。ドキュメントを翻訳したりとか、Meetupで発表したりとかしていますね。最近部署内であるのは、ビジネスとかドメインの知識が足りていないのを解消するものでしょうか。LINEのビジネス的なものの関係が結構複雑になってきているので、質問を集めて企画担当に教えてもらおうとしていて、いいなと思います。Developers。