トーク

昨今のエッジ進化は、フロントエンドを学ぶ上で避けて通れない存在となってきています。
これまでは単純にCDNに画像を配置していた時代から、エッジを挟むことで画像に対するリクエストにも様々処理（夢）を挟むことも可能となりました。

このトークでは、そんなリソースに対するリクエスト処理で、レスポンス速度はCDN並みに早く、そこに色々な夢（処理）を詰め込むケースをいくつか紹介します。
以下にいくつかサンプルのケースを掲載しておきます。

・画像変換をエッジで行う
・リソースに対するリクエスト数をエッジで計測する
・エッジでHTML,CSS,Javascriptの処理を書き換えてレスポンスする
・署名URL（Cookie）でリソースをエッジで守る
・etc...

参考
https://zenn.dev/oliver/articles/cloudflare-meetup-2023-10-06

概要:
このセッションでは、MVCフレームワークに慣れたPHPエンジニアが、どのようにしてLaravelのBladeテンプレートエンジンを使用してWordPressサイトを構築したかを紹介します。従来のWordPressの開発環境に馴染めなかったエンジニアが、Bladeを使うことでどのように開発プロセスを効率化し、再利用可能なUIコンポーネントを作成し、コードの冗長性を減らしたかを紹介します。

具体的な学びのポイント:
Bladeの導入: BladeをWordPress環境に統合する際の技術的なステップと必要なツール。
開発効率の向上: 再利用可能なコンポーネントの作成と、維持管理の容易さについての実例。
挑戦と解決策: WordPressのエコシステムに逆らうことで発生した問題点と、それにどのように対応したか。

近年、Webフロントエンド上で3DCGモデルを動作させる技術の注目度が上がってきてます。
本セッションではThree.jsのWebGL技術を用いてReact上で3DCGモデルを動作させることについて話します。

▼ こんな人が対象者

• Webブラウザで3DCGモデルを動作させたい人
• Three.jsを利用したことがあるが、Reactとの組み合わせで悩んでる人
• Unityの実装経験はあるが、Three.jsは未経験の人

▼ 内容

• React関数コンポーネントの中で動作させるThree.jsについて
• 3DCGモデル・画像・動画・アニメーションの描画方法について
• Three.jsの周辺機能を提供するカスタムフックの作成について
• 「Webフロントエンド x 3DCG」のこれからについて

このセッションではReact RouterやTanStack Routerなど
ReactのSPAアプリで導入可能なルーティングライブラリについて話します。

▼ こんな人が対象者

• Reactのルーティングライブラリについて知りたい人
• 普段、Next.jsやRemixなどのフレームワークを利用しており、ルーティングライブラリについてよくわからない人

▼ 内容

• React RouterやTanStack Routerなどの主要なルーティングライブラリについて
• 「File Based Routing」 VS 「Directory-Based Routing」の話
• Next.jsやRemixなどのフレームワークとの組み合わせについて

このセッションでは、PHPバックエンドエンジニアがフロントエンドの最新技術のひとつである、NextJSへの入門を試みる過程を紹介します。

特に生成AI技術を活用して英語のドキュメントを理解し、コーディング時の疑問は都度解決するという方法に焦点を当てます。
実際に、GatsbyJSで構築したブログサイトをNextJSへ移行したときのことを取り上げ、バックエンドエンジニアがAI技術と共にどうフロントエンド技術を理解していったかを掘り下げてみようと思います。

昨今フロントエンドにおける自動テスト手法が注目を浴びています。
その中でテストが存在しない既存のプロジェクトはテストとどう向き合うべきでしょうか。

本発表ではテストが書かれていない既存フロントエンドプロジェクトが抱えていた課題と、それに対して「どのように」「どんな」自動テストを導入したかを話したいと思います。

主な内容

• プロジェクトが抱える課題
  • 人的リソース
  • ライブラリバージョンアップなどリスク
  • リリース作業のコスト
• Next.js (Page Router) で書かれたコードに自動テストを導入する
  • 静的解析
  • Jest, React testing library を用いた Component のテスト
  • Playwright による Storybook を再利用した Visual Regression Test

Swift!Swift!ぅうううわぁあああん!!!

んはぁっ!Swiftたんの型安全な世界をWebフロントエンド開発でも体感したいお！
SwiftWasmたんを使えば、フロントエンドでSwiftたんを使うことができる…?きゅんきゅんきゅい!

ぐああ!生成されるWebAssemblyバイナリのサイズが大きいから、Swift ちゃんをWebフロントエンドで使うのは 現実的 じ ゃ な い?にゃああん!うぁあ!

ちきしょー!やめてやる!現実なんかやめ…て…え!?見…てる?SwiftWasmちゃんが僕を見てる?
よかった…世の中まだまだ捨てたモンじゃないんだねっ!
いやっほぉお!!僕にはSwiftWasmちゃんがいる!やったよケティ!ひとりでできるもん!!

本トークでは、現時点のSwiftWasmは どこまで・何ができるのか探究することを試みます。

Swiftといえば、iOSやmacOSアプリを開発する言語だと思い込んでいませんか？

実はLinuxやWindowsでもサポートされている、汎用プログラミング言語です。
意外と知られていない事実ですが、Swiftは、「さまざまな用途で使える最高の言語を作る」という、とても野心的な目標を持って開発されています。

さて、SwiftWasmというプロジェクトがあります。
これは、WebAssemblyでSwiftを使えるようにするというプロジェクトです。
つまり、ブラウザ上でSwiftを走らせることができます！！

本トークでは、サーバーサイドSwiftとSwiftWasmを使って、SwiftメインでWebアプリケーションを作った汗と涙に溢れる体験を共有し、Swiftを中心としたWebアプリケーション開発の可能性を探ります。

DartといえばFlutter専用言語のイメージが強いと思いますが，歴史的経緯によりJSへのトランスパイルをサポートをサポートしています．
しかしながらウェブ開発でDartがメインで使われるといったことはありませんでした．

Dart 3.3からWasmへのコンパイルがサポートされました．
Dart to JSでは実行用JSがアウトプットされていましたが， Dart to Wasmでは実行用のESModuleがアウトプットされるようになったりと，最近のウェブ開発でも利用しやすくなっています．

本セッションではWasmがサポートされたことによりDartをウェブ開発で利用できそうか?という観点での話をしたいと思います．

フロントエンドエンジニアの方は、技術の素振りも兼ねて個人ブログや個人サイトを実装している方も多いと思います。

多くのテンプレートが充実したことによって、思い立った数時間後にはMarkdown製ブログが立ち上がるような時代になりました。便利である一方、一定の品質のものが簡単に出来上がってしまうため、技術の習得という視点では物足りないところです。

新たな知識の習得のためには新しい機能を実装していく必要があります。その際のモチベーションとして、機能をAstroインテグレーションとして実装してみるのはいかがでしょうか。
Astroインテグレーションは、その名の通りAstroに簡単に追加できるプラグイン機構で、通常のnpmに加えて独自のライフサイクルフックを用いることができるのが特徴です。

この発表では記事投稿ヒートマップの実装を例に、Astroインテグレーションの構成と実装方法を紹介します。

社内向け管理機能はサービスのオペレーションを支える重要な機能です。一方で顧客向けサービスと比べ実装にかける労力は抑えられがちで、手軽な管理画面ライブラリが採択されることも多いと思います。

私の現場でも最初はその構成をとっていました。しかしテンプレートエンジンで提供できるユーザー体験に限界を感じ、RefineというFWを用いて別途SPAにリプレイスを採択。これにより2週間でAdminをリプレイスできた点は成功ですが、一方でFWの内部実装を参照しないといけないケースがあるなど、最良の選択肢かは検討の余地があります。

この発表ではリプレイスで得られた知見を元に管理機能フロントエンドに必要な要素を整理し、実装の選択肢とそのトレードオフをお話しします。「フルスクラッチは大変」という粗いADRを書いた私のような経験の浅いエンジニアの方に向けて、技術選定の視点を提供できれば幸いです。

現在、製造現場DXプラットフォーム、「Smart Craft」の開発を進めており、4人のエンジニアがフロントエンドからバックエンドまでを担当しています。
限られた人数で最大限の成果を出すために、私たちはGraphQLを用いたコードファーストアプローチに基づく開発を選択しました。
本セッションでは、2年間でやってきたことを通して、GraphQLを選択した理由やコードファーストアプローチに基づく開発で得た知見とメリット・デメリットについてお話し、GraphQLの活用を検討する方々への助けになれればと考えております。
主に話すこと

• 開発体制とGraphQLの選択理由
• Ruby/Ruby on RailsでのGraphQLのスキーマとドキュメントの自動生成
• Reactでの開発とTypeScript型定義の自動生成
• モノレポによるスキーマの共有
• 得られた知見とメリット・デメリット

現在、デザインシステムのUIコンポーネント実装において、スタイリングライブラリとしてPanda CSSを採用しています。
本発表では、Panda CSSの紹介をした上で、Panda CSSを利用した型安全なコンポーネントのスタイリング方法やデザイントークンとの連携について紹介します。
更に利用する上でのTipsや、Dynamic Stylingに関する注意点についても紹介します。

デザインシステムの普及により、多くのフロントエンド開発者がコンポーネントライブラリを独自で実装するようになりました。
こうした独自でのコンポーネント実装において、様々なデバイスで機能するアクセシブルなUIコンポーネント実装を行うのは難易度が高く、実装コストが高くなります。

本発表では、そうした共通コンポーネントの実装において役立つヘッドレスコンポーネントライブラリであるArk UIとスタイリングライブラリであるPanda CSSを紹介します。
更にこれらのライブラリを用いて実装を行うことでデザインシステムのコンポーネント実装を加速させた事例についても紹介します。

株式会社 enechain では、デザインシステムを運用しています。

元々は社内プロダクトが新たに立ち上げられることが多かったフェーズにおいて、開発効率を良くするために、共通コンポーネントを使い回すためのパッケージとしての運用から開始しました。

そこから、デザイナーのジョインやチーム体制の変更により、正式にデザインシステムとして立ち上げることとなりました。

今や、「日本のエネルギーを担う」というとても大きな目標に向かってプロダクトを作っている我々ですが、その内製されている各プロダクト、ほぼ全てにおいて使用されているデザインシステムを、どのように運用を初め、どのように草の根活動を進めていき、どうやって社内で自分事にされるようになっていったかを、エンジニアの立場として、プロダクトオーナーとしての自分が、立ち上げ期から順を追って赤裸々にお話します。

HonoXはHonoベースで作られたフレームワークです。そしてHonoには、react-rendererというサードパーティーのmiddlewareがあります。
このHonoXとreact-rendererを組み合わせることで、HonoXでReactを使用することが可能になり、Reactベースのuiライブラリを使用しつつ開発を行うことが可能になります。

本セッションの詳細は以下の通りです。

• Hono/HonoXの説明
• HonoXとreact-rendererの組み合わせによる利点
• HonoXとさまざまなuiライブラリを組み合わせる

日本経済新聞社では Hack The Nikkei という技術ブログを運営しています. ここで日経の技術組織における文化や技術的知見を発信しており, また採用導線も兼ねてあり各種エントリー情報なども纏められています.

その技術ブログは特別のメンテナンスチームなどはなく, 有志によって運用されています. また技術記事や採用情報を追加/更新するメンバーには, エンジニアにとどまらず, デザイナーであったり採用担当であったり, プログラミングに不慣れな方も含まれます. そんな中でどのようにして技術組織の発信を支えているのか, 技術ブログ自体の運用をどのようにして効率化して行なっているか, と言った ops や自動化の取り組みについて, 初期の立ち上げ段階の Hack The Nikkei からの遷移とともにご紹介させていただきます.

React Nativeを用いたモバイルアプリの実装は、普段Reactを使っているエンジニアであれば、スムーズに行うことができます。

しかし、Webアプリ開発ではあまり意識する必要のない、モバイルアプリ特有の注意点・相違点が多数存在し、その一つとして、E2Eテストが挙げられます。

単体テストは、Webと同じような感覚で実装することができるのですが、E2Eテストに関しては、端末のOS・機種の考慮が必要であったり、Webアプリで普段利用するE2Eテストツールが利用できないなど、React Nativeでのモバイルアプリ開発特有の知識が必要になるかと思います。

このトークでは、React Nativeで利用できるE2Eテストツールについてや、E2Eテストの運用方法など、「React NativeにおけるE2Eテスト事情」についてお話しできればと思います。

プロダクトにおいて、モバイルアプリとWebアプリのどちらも開発が必要な場合、どのような技術選定を行うかは非常に悩ましいところかと思います。

最近では、Expo Routerが、Next.jsのようなファイルシステムベースのルーティングを実現できるようになるなど、React Native・Expoを利用したモバイルアプリとWebアプリの同時開発が、有力な選択肢として頭角を表しているのではないでしょうか？

このトークでは、React Native・Expoで開発されたモバイルアプリのWeb版を、ReactやNext.jsを用いてイチから作るのではなく、"React Native for Web"や”Expo Router”によるモバイルアプリのコード資産を活用しながら開発することで感じた良かったポイントや苦しかったポイント等を共有できればと思います。

Webフロントエンドの自動テストをチームで無理なく継続するためには「軽やかなテスト」を書くことのできる開発環境と設計が極めて重要です。

本トークでは、開発から8年が経過したプロダクト開発チームでWebフロントエンドの自動テスト文化を醸成した経験をもとに、軽やかなテストを構築するための実践例とそれによって得られる開発体験について紹介します。

詳細は以下の内容を予定しています：

• 結合テストを支えるコンポーネント設計：Container/PresentationパターンとResult型を駆使することでテストのしやすいコンポーネントを構築する
• 単体テストとの付き合い方：ネットワークの入出力に着目した単体テストでカバレッジを広げる
• 開発体験：Storybook駆動で小さく精度の高いPull Requestを実現する
• +α：E2Eテスト・画像回帰テストとの付き合い方