プロポーザル

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と他のライブラリとの使用感を比較し、移行したくなった場合に移行しやすくするための工夫についてもお伝えします。

スタートアップ創業〜拡大の4年間で得たいくつかのトピックを10分ずつぐらいで話します。

• スタートアップ立ち上げ期〜拡大期において、リードとして求められた「ここから3年の技術戦略」とその回答
• 立ち上げ期のシンプルでフレームを守りやすい設計から、複数事業領域展開後の各チームでの自律的な開発を支える設計への変遷
• モノリスな単一Next.jsアプリケーションの構造から、チームごとのデプロイを可能とするために複数Next.jsアプリケーションを組み合わせて単一のアプリケーションを表現する構造への移行の変遷
• フロントエンドの専門性と質を保ち続け、メンバーの強みを引き出すチーム設計

なぜ、 俺たちは四半期ごとに別のトレンドの話をしてるんだろうか？
なぜ、「技術的にこれが正しいはずだ」と信じて疑わなかったものは、数年後負債になるのだろうか？
なぜ、水平思考したいのに、枯れる前に廃れてしまうんだろうか？
なぜ、気づいたらまた 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 コンソールの重要性や提供する意義を考察します。