プロポーザル

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型定義の自動生成
• モノレポによるスキーマの共有
• 得られた知見とメリット・デメリット

ウェブ開発においてJS/TSを利用することが多い中でWasmを組み込もうとするとJS/TS以外の言語(RustやC++など)を利用するのが最初の選択肢になるのではないでしょうか?

JS/TS以外の言語がWasmへのコンパイルをサポートすることでウェブへ進出できるようになるのは喜ばしいものの，JS/TSを中心としたウェブ開発の中で他の言語を導入するコストをどう見るのか?

本セッションではJS/TSと比較した時のWasmのメリットデメリットを踏まえつつ，ウェブ開発の中でWasmを導入する時の最初の選択肢として「AssemblyScript（AS)」を紹介します．
ASはnpmで管理されているためにウェブ開発において手軽に導入でき，かつ書き慣れているTSをWasmにコンパイルできる技術です．
ASを用いたWasmの導入方法や現状できることを中心に話したいと思います．

現在、デザインシステムの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ライブラリを組み合わせる

皆さんは、ユーザーの手元で起きたバグをなかなか再現できずエスパーで直した経験はないでしょうか。あるいは、ユーザーの動きを想像しながら機能の導線改善をした経験はないでしょうか。
そんな仕事を楽にするツールとしてSentryやDatadog、Fullstoryなどが、ユーザーの画面をそのまま見れるセッションリプレイ機能を提供しています。

さて、これはどのように実現されているのでしょうか。Webアプリの画面をmp4動画として録画することはもちろんできません。代わりにMutationObserverをはじめとしたWeb標準技術を駆使して擬似的な録画を実現しています。

本セッションでは、自作のセッションリプレイツールを3年間運用している経験を元に、それを支えるWeb技術と具体的な実装を解説します。実運用するためのプライバシー対応やサーバー側実装についても紹介します。

私は普段、開発物を実際にスクリーンリーダーを使って操作して、アクセシビリティ上の問題がないか確認することを習慣にしています。

その活動の中で、スクリーンリーダーを使って初めて気づいたアクセシビリティ上の課題や、コードレビューやブラウザの開発ツール、キーボード操作では見逃しがちなアクセシビリティ上の課題を紹介します。

アクセシビリティに詳しくない方でも理解しやすい内容で、スクリーンリーダーの利用者目線で検証することの価値に気づいていただけるようなお話をします。

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

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

複数言語をサポートするwebアプリケーション開発において文言の国際化は常に付きまとう問題です。特に日付や数値の表記、文法規則などを考慮した国際化はその処理や管理で悩むことが多いと思います。

webフロントエンドにおいては、このような機能をJSの国際化APIであるIntlが担うようになってきています。一方、日付や数値など個別の国際化機能が充実していく中で、文言全体のフォーマットをどう定義しどう書式化するかと言う課題に対しては未だ答えが出ていません。

このような課題に対し、仕様レベルで文言のフォーマットやパース・書式化をサポートする「Intl.MessageFormat」という野心的な提案が現在Unicodeを巻き込んで協議されています。本セッションではこの提案について、その背景や概要、現在までの流れ、提案されているフォーマットを紹介し、標準化された後の文言国際化を考えたいと思います。

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テスト・画像回帰テストとの付き合い方

フロントエンドカンファレンス北海道2024のLPをWebフロント初心者組で開発しました。

私は北海道在住の大学生です。現在Webエンジニアのインターンとして業務でWebバックエンドを主に触っています。Webフロントエンドも触ることもありますが、まだまだ初心者です。今回フロントエンドカンファレンス北海道2024のコアスタッフとしてLPを制作することになり、3人ほどの開発チームを組んで自分主導でLPの開発を行いました。今回は、メンバー構成や技術選定、実際に開発している中でWebフロント初心者の自分が得た気付きなどについてお話します。

【話すこと】

• メンバー構成
• 技術選定
• 開発の進め方
• 小規模なLP開発を通して感じたこと・困ったこと

ヘッドレスCMS「Storyblok」を使用したプロジェクトにおいて、エンジニア、デザイナー、ライターという三つ巴の天敵となり得るメンバーたちがどのようにコミュニケーションの問題を解決してきたかを解説したいと思います。
Storyblokの特徴であるビジュアルエディターは、デザインの変更がリアルタイムで確認しながら編集が可能で、非技術者でも直感的に操作できます。また、ブロックライブラリにより、再利用可能なコンポーネントを簡単に管理し、プロジェクト全体で一貫性を保ちながら効率を向上させることができます。
これを導入することでフロントエンドとバックエンドを完全に分離し、メンバーが同時進行できる部分が多くなります。導入初期のトラブルを共有します。また機能をどのように活用すれば、チームのリソースを最大限に活用できるか、初心者がつまずき易いポイントも紹介します。

React Nativeは、JavaScript（TypeScript）でiOS・Android対応のクロスプラットフォームアプリを素早く開発できることで知られています。

その一方で、メンテナンス性が悪くなりやすいデメリットがあります。
特に、React Nativeのアップグレードには、iOS・Androidの設定ファイルやコードの変更、さらにはサードパーティのJSライブラリやネイティブモジュールの更新が必要なケースもあり、とても大変です。

しかし、Expoが提唱している、「Continuous Native Generation(CNG)」というコンセプトを取り入れることで、スケーラブルでメンテナンス性に優れたクロスプラットフォームアプリ開発が可能になります。
このトークではCNGの概要、CNGを取り入れたExpoアプリ開発のプロセス、導入事例ついてお話しできればと思います。

コードベースに秩序をもたらすため各種 Linter を利用している方も多いのではないでしょうか？一般的なルールについては Linter 内蔵のものや既存の Plugin ですでにカバーできるでしょうが, 一方で事業ドメイン特化であったり UX/DX を向上させるための技術ドメイン特化なルールまではサポートし切れないケースの方が多いでしょう.

日経電子版においてもコードベースにそうした事業ドメイン, 技術ドメイン特化な制約が存在しています. こうした日経電子版特化な制約について日経電子版開発では属人的なレビューで弾くといったアプローチでなく, できるものは ESLint Plugin を開発してそれにより機械的に弾くアプローチをとっています.

本セッションでは事業, 技術ドメイン特化な ESLint Plugin を開発する利点や How To を具体例とともにご紹介します.