プロポーザル

僕はTC39で提案されているCall-this operatorを熱望しています。これによってTypeScriptの開発体験が大きく変わると信じています。

その考えを確かなものにするために、TypeScriptやVSCodeに勝手にCall-this operatorを実装して、個人開発で実際に利用することで、その開発体験を手触りしています。

何故そこまでしてCall-this operatorが欲しいのか、TypeScriptにどうやって実装するのか、といった、仕事に1ミリも役にたたないであろう話をします。

• Web標準(TC39)とTypeScriptの関係性をおさらい
• Call-this operatorと僕が思い描く未来について
• TypeScript Compiler (tsc) の内部構成
• 実際に構文変更を含む機能追加をする方法

ポータブルで安全に埋め込み可能な実行フォーマットとしてWebAssembly (Wasm)が近年注目されています。エディタやネットワークプロキシなどのミドルウェアの拡張プラグインでの採用、またはマネージド環境でWasmを直接実行するサービスが増加しています。

そのようにWasmを採用したCDN上でのコンピューティングサービスの一つとしてfastly computeがあります。本セッションではfastly computeを商用サービスに用いた経験を元に、以下の内容について話します。

• WasmおよびWASIの基本的な知識
• fastly computeの実行モデルと制約の公開情報に基づく説明
• JS/TS主体のチームでRustを選択した場合のWasmターゲットなアプリケーション開発
• Wasmは本当に「業界の未来」で便利なのか？ 利用者観点での所感と提言

最近Webサービスを作るとなると、フロントエンドとバックエンドで分業します。開発が進むと疎通というタスクが発生しますが、大体ここで色々なトラブルが起きます。経験上、疎通が１発で成功したことはないです。このトークでは、これまで自分が経験したことを話したいと思います。自分も正解は知らないので、自分がよくやる方法論を話すという感じのトークになります。そのため感想戦会場などで議論をお待ちしております。

• 開発をローカル環境で完結させるための工夫（コンテナ、テスト、UIカタログ）
• CORS関連の諸対応、その意味（fetchのinit, preflight, SameOrigin)
• 認証認可、特にSameSite Cookieとlocalhost
• CDN（shared cache事業者）の直感に反する動き
• キャリア回線・イントラネットなどの環境起因トラブル
• 人間関係

私たちのチームは、この3年間、大規模なOMS（Order Management System）の開発に取り組んできました。
3年間の長期的な開発の中で、技術面・組織面の両方で多くの改善を行なってきました。
本セッションでは、そのサービスの構成について解説し、技術選定や開発体制の改善のために取り組んだ内容について振り返りたいと思います。

具体的には下記の内容を話す予定です。

• 大規模OMSの特性と開発における課題
• サービスの構成の紹介 (GCP,Go,Next.js,GraphQL)
• BtoBサービスにおけるHasuraとGraphQLの採用
• OpenAPIからのGoのAPIクライアントの自動生成
• Next.jsでのSPA構築
• 複数の外部サービスと連携する上での開発環境の整備
• スクラム開発の良かった点・悪かった点
• レトロスペクティブでの振り返り手法の変遷

JavaScriptを書いたことはありますか？Web開発者なら、一度はあると思います。じゃあ、JavaScriptがどのように作られているか知っていますか？そう、TC39が仕様を策定して、JavaScriptエンジン開発者がそれを実装します。

じゃあ、JavaScriptエンジンに仕様を実装、あるいは修正したことはありますか？

私は最近、SafariのブラウザエンジンであるWebKitのJavaScriptエンジンの開発に参加し仕様に準拠していない動作の修正に取り組んでいます。
この作業で重要になるのがtest262です。test262はJavaScriptエンジンが仕様を満たしているか確認するためのテストスイートです。これにより、開発者は実装が仕様に準拠していることを確認できます。

このセッションでは、test262について、そしてWebKitでの運用についてお話します。

多くの企業がデザイン・システム用に独自のコンポーネント・ライブラリをゼロから実装しています。
これはスタイルが適用可能な組み込みのブラウザコントロールがほとんどないため、同じコンポーネントの多くをゼロから再実装する必要があるからです。
React Aria は、アクセシビリティ、国際化、キーボード、マウス、タッチインタラクションなどのサポートを提供し、これらの課題を解決するためのライブラリです。

本セッションでは、React Aria の特徴である、アクセシビリティ、国際化対応、スタイリングの容易さ、およびカスタマイズに優れた拡張性を駆使して実現する優れたユーザー体験ついて、実装例や内部実装に踏み込んで解説します。
また、実際の業務での運用知見についても共有し、React Aria を使用することで得られる成果と直面する課題について話します。

ReduxはReactアプリケーションの状態管理ライブラリとして長年愛されていますが、多くのボイラープレートが必要なため、現在ではRedux Toolkitの使用が推奨されています。
しかし、古くから存在するプロダクトでは、かつてReduxを導入し、そのまま直接使い続けている現場も多いのではないでしょうか？
このトークでは、Reduxを直接使っている状態からRedux Toolkitを導入し、徐々にモダン化していく方法について紹介します。
また、Reduxと他のライブラリとの使用感を比較し、移行したくなった場合に移行しやすくするための工夫についてもお伝えします。

なぜ、 俺たちは四半期ごとに別のトレンドの話をしてるんだろうか？
なぜ、「技術的にこれが正しいはずだ」と信じて疑わなかったものは、数年後負債になるのだろうか？
なぜ、水平思考したいのに、枯れる前に廃れてしまうんだろうか？
なぜ、気づいたらまた Node.js を使ってるんだろうか？
なぜ、同じようなものを作ってるのに、何度も新しいフレームワークの使い方を学び直さないといけないのだろうか？
なぜ、自分が推してたあの技術より、こっちの技術が流行ったんだろうか？

技術的に「正しいもの」があり、それが全てを解決すると思うも、その割には「正しさ」が移ろいでいく。
CS の博士を取ろうと、学会の論文を漁ろうと、答えがみつからない。むしろ大して研究すらされてない。
そもそも俺たちは、「Web 開発」の実態を本当に正しく捉えて、説明できているんだろうか？

について、普段考えていることを話してみたい。

MPAではbf cacheやブラウザ独自の復元処理によって、ブラウザバック時には可能な限り以前の状態が復元されるように工夫されています。しかし、Reactなどを使った昨今のモダンフレームワークでは画面遷移時のComponentのunmountで状態を破棄してしまうので、ブラウザバックした時にはアコーディオンやformは初期状態に戻ってしまいます。これは「あやまってブラウザバックしてしまったので戻ったらformが空になってた」「ブラウザバックしたらアコーディオンが全部閉じててスクロール位置が変なところにいた」といったユーザーの不満につながります。
このSessionでは、この問題に対応するために作ったlocation stateというライブラリについて紹介します。
https://github.com/recruit-tech/location-state

日本最大級のトレーディングカード通販サイト「カーナベル」のMicroservices認証認可基盤の裏側をご紹介します。

• 地方の小規模チームが30人日で認証認可基盤を作った話
• gRPC extensionを自作してメソッド単位のRBACを宣言的に定義している話
• Contourを導入してKubernetesの認証Gatewayとして利用している話
• Multi User Poolsが固有で持つユーザー情報をSTS(Security Token Service)でMicroservicesから隠蔽している話
• EnvoyのExternal Authorizationを利用して3rd partyの認証トークンを内部トークンにローテートしている話
• Web標準に寄り添った「メンテの不要なAuth Guard」をNest.js向けに開発した話

などなど、てんこ盛りな内容です

Webフレームワークの自作の方法を紹介します。フレームワークはCloudflare、Deno、BunなどのJavaScriptランタイムで動き、ファーストクラスでTypeScriptをサポートします。Web標準を使ってスクラッチから初めて、URLPatternによるルーティング、Express/Honoライクなインターフェース、コンテキスト・ミドルウェア機構を作ります。最終的には、Reactによるサーバーサイドレンダリング、ファイルベースルーティングまでやりたいです。また、早めにテストを書いていき、ベンチマークの取り方、パフォーマンス・チューニングのポイントも解説します。車輪の再開発かもしれませんが、自作は楽しいし、経験しておくと役に立つかもしれない。

Rust では web backend server の開発は大変だと言われてましたが、最近徐々にスタンダードなども固まってきてweb開発が楽になってきました。
近年徐々に人気の出てきてる Sveltekit を利用して Rust + Sveltekit (Svelte 5) で 簡単な Web アプリを作成する話をします。
実際に業務で使用しているいる組み合わせなので実務での知識も入れて話せたら良いなと思ってます。

株式会社 enechain ではデザインシステムを運用しています。 当初、スタートアップにおける内製プロダクトの開発効率、事業への価値を最大限引き出すための取り組みとして、有志でデザインシステムの運用を始めました。現在では社内ほぼ全てのプロダクトで使用されています。

本セッションでは、デザインシステム自体の開発体験を向上させ、社内のどのエンジニアからでもコントリビュートできる環境まで育て上げたアプローチを、プロダクトオーナーを務める自分のエンジニア視点から見る、「使われる」デザインシステムにするための具体的な取り組みを話します。

昨今の様々な会社で取り組まれているデザインシステム運用のための施策に関わらず、Web 開発をするにあたって、の観点から紹介します。

0 -> 1の開発は仕様策定から始まり、技術選定や設計、テストやリリースまでとてつもなくやることが多いです。
しかもリリースした後も、よく分からんバグに遭遇したり、セキュリティの問題が発生したり、最適化をしたりと、色々大変なのは周知の事実でしょう。
それを、たった一人でやることになってしまった、もしくはなりそうな、あなた、大丈夫です。このトークを聞きにくれば、その不安は（多少は）解消されることでしょう。

さあ、みんなで 0 ->1 やろうぜ！

AWS や Google Cloud, Microsoft Azure などのクラウドサービスには Web コンソールが存在します。
これらを使う際に、「なぜ CLI があるのに、同じ操作が可能な Web コンソールがあるのだろうか」「なぜインフラ向けのサービスで GUI を提供するのだろうか」と思ったことはありませんか？

本セッションでは、Cycloud(サイバーエージェントのプライベートクラウドサービス) と、これをベースとしたマネージドサービス向けの Web コンソールをなぜ・どのように開発しているのか紹介します。
具体的には、Web コンソールによる操作の効率化や CLI を普段使わないユーザー層をカバーしている事例から、クラウドサービスにおける Web コンソールの重要性や提供する意義を考察します。