p5.jsは、Processing言語をベースにした、クリエイティブコーディングのためのJavaScriptライブラリです。簡単にグラフィックやアニメーションを生成し、Web上で動作するインタラクティブな作品を創出できます。Webエディタを利用すれば、環境構築なしに利用することができます。Webカメラやマイク、Web Serial APIなどを通じた外部デバイスとの連携も可能です。さらに、Googleの機械学習ライブラリMediaPipeを使い、物体認識や骨格認識などの機能をWebサイトに簡単に実装できます。
LTでは、p5.jsの基本機能や活用事例を、実際のコード例を交えて紹介します。例えば、外部デバイス(M5Stack、toio)との連携、オーディオスペクトラムアナライザ、骨格情報を使用したゲームなどを取り上げる予定です。LTを通じて、p5.jsの可能性をお伝えできればと思います。
アラカンおじさんのnakayoshix(なかよしX)こと中村良幸です。ヨーガ歴30年のダルシム系エンジニアですが、現在は隠居系フリーランスとしてデータサイエンティスト兼機械学習エンジニア的な仕事をしています。
私はフロントエンド方面に関しては全くの素人ですが、つい最近Twitter(自称X)にてPythonで作られたWebアプリ作成用ライブラリ『Gradio』の存在を知り、これは面白そうだということで早速使ってみたところ、機械学習向けWebアプリが本当に瞬殺で作れることがわかり、この興奮と感動をこの機会に是非皆さんにもお伝えしたいと思いました。
なお、Gradioで作成したWebアプリはHuggingFaceのSpacesでアプリを公開することも可能で、Stable Diffusionで有名なWeb UIの一つstable-diffusion-webuiもGradioを使用しています。
私のフロントエンドエンジニアとしての経験を踏まえて、プロダクションに積極的に導入したいユーティリティライブラリの選定例と実装例をご紹介します。
ここでいうユーティリティライブラリとは、例えばZod(JavaScript、TypeScriptでスキーマバリデーションを表現できる人気のライブラリ)等のコーディングを補助してくれるライブラリです。
各種ユーティリティライブラリの導入はフロントエンドのアーキテクトにおいて、1つの論点となっています。しかしながら、プロジェクト全体でどのようにユーティリティライブラリを活用していくべきなのか・選定するときの観点は何を重視して判断すべきかの知見は、コミュニティには広まっていないと感じています。
このようなユーティリティライブラリの選定の思考を踏まえつつ、zodと共にts-patternというパターンマッチライブラリの導入例を紹介したいと思います。
例えばSHEIN ( https://m.shein.com/jp/?lang=jp )のWebサイト等に実装されているカテゴリ選択するメニューのようなUIを実装したいと思ったことはありませんか?
iOS/Android等でスタックナビゲーションとよばれるこのUIはSP重視のtoC向けのプロダクトではデザイナーからも人気の高いUIです。
しかしながら、スタックナビゲーションのUIの実装例はコミュニティにほとんどなく、SEOやアクセシビリティ、コンポーネントのメンテナビリティなどの要件を満たしながらWebで実装するのはかなり難しいUIになります。
このようなスタックナビゲーションのUIを各種要件を満たしながら実務で実装した経験を踏まえ、実装するに当たっての考慮点と実装例を紹介します。
現代の多くの Web サイトにとって、Core Web Vitatls のような User-centric なメトリクスは非常に重要です。
Lighthouse などのツールは、計測環境を固定して使用すれば、変化の激しい Web サイトに対しての有効な定点観測手法となりますが、一方で実際のユーザー体験とは乖離することもあります。
New Relic などのオブザーバビリティバックエンドにある RUM(Real User Monitoring)機能では、エンドユーザー端末での実測をするため、ユーザー層や固有のコンテンツに依存したより現実的なデータが得られますが、一方で変数が多すぎるため、ある変更がパフォーマンスに与えた影響を把握するのには向いていません。
本トークでは、実際の Web サイトでこれらのラボデータ・フィールドデータをどのように活用して CWV を改善していくべきか話します。
本LTではバックエンドエンジニアから見たフロントエンドとの分割における「つらみ」を「状態管理」の視点から明らかにし、軽減するためのアイディアを紹介します。
バックエンドのAPIとして、Java/Go/Ruby/PHPなどの処理を呼び、フロントエンドはUI/UXに注力するというアーキテクチャは現在よく取られている手法です。
明確な境界があることで責務は分断され、業務ロジックはバックエンドに秘匿され、多くのメリットが享受できます。
一方でステート(状態)はどうでしょうか?
ユーザーの利便性やわかりやすさのためにフロントエンド側で一時的な状態を保持し、画面を組み換え、POSTします。
フロントエンド側で更新された状態を改めてバックエンド側でチェックし、永続化することが多く、状態の保持に関しては複雑性が増してしまいます。
事業上の要請で、Webアプリとして提供しているサービスでプッシュ通知等のネイティブ特有機能が必要になり、モバイルアプリ版を新たに出すことはよくあると思います。その場合、フルスクラッチで開発するとめちゃくちゃ大変です。まずは最小限の工数で通知許可率等を計測し、モバイルアプリのポテンシャルを検証したいですよね。
本セッションでは、Capacitorを用いて既存のNext.jsアプリをそのままモバイルアプリとして動かし、プッシュ通知のようなネイティブの機能を利用するまでをステップ・バイ・ステップで解説します。また、このアプローチで700万MAUのサービスを3年間運用した経験を元に、単一のコードベースでWebフロントエンドとモバイルアプリを運用する上でのTipsも紹介します。
Web開発者が事業を前進させる現実的な選択肢としてモバイルアプリ開発を検討するきっかけになれば幸いです。
昨今Rust製のツールチェインが流行り、ESLintの代わりにBiomeやOxc(oxlint)を採用するケースも増えているのではないでしょうか。
ですが、これらは未だ独自のカスタムルールを利用することはできません。
対するESLintでは、非常に優れた拡張性を持っています。
中でも no-restricted-syntax
というプリセットのルールは、簡単に独自のカスタムルールを作成することが可能です。
本発表では、 no-restricted-syntax
を利用した実用的なカスタムルールを作りながら、ESLintの有用性を再確認します。
フロントエンドで発生したエラーのトラッキングをしたいと思った時、Sentryのようなツールを導入することで解決しようとしている組織は少なくないのではないかと思います。
しかし、エラー監視はどれだけいいツールを使っていたとしても、実際に運用していく体制がずさんではあまり効果を発揮することができないと考えています。
そこで、わたしたちは「cop当番制度」というものを導入することで、エラー監視の負荷が特定のメンバーに集中するといった問題を発生させることなく、レポートされたエラーをしっかりトリアージしきることを実現しています。
本LTではどのようにしてフロントエンドのエラー監視体制を運用しているのか、技術面ではなく運用面にフォーカスしてお話しします。
Redux Toolkitは、ステート管理ライブラリであるReduxをより使いこなし、効率的にアプリ開発をするためのライブラリです。
我々のサービスでは、複雑なフォームを提供する画面にReact、ReduxおよびRedux Toolkitを使用していました。
ある時、Redux Toolkitのマイナーバージョンアップを行うと、フォーム入力時の再レンダリングにかかる時間が約4倍になってしまいました。
もちろん、バージョンアップ以外に実装は何も変わっていません。
普通はマイナーバージョンアップでそんな劇的な変化は起こらないはずです。皆さんは、マイナーバージョンアップで何が起こったのか想像できますか?
最近、テクニカルライターとして Docusaurus と睨めっこしています。
ドキュメントを提供する上で、時にはインターネットにアクセスできないお客様のためにPDF化が必要になります。
Docusaurus には PDF を生成する 3rd party のプラグインもありますが、Docusaurus自体のバージョンアップに追従する難易度や、メンテナビリティを考慮して採用を控えました。
代わりに、E2E テストツールである Playwright を悪用しています。
Playwright にはテストのスナップショットを生成するためにPDFを生成する機能が付いています。
嬉しいことに撮影範囲はセレクタで絞り込めます。
このトークではそのような Playwright の目的外利用をどのように実現したかお話しします。
esbuildやswcの登場を皮切りに、近年のフロントエンドツールはJavaScript(TypeScript)以外の言語で実装されることが増えています。特にRustはゼロコストの抽象化機能を備えており、アルゴリズムの複雑さとメモリ割り当てに気をつけるだけで良く、パーサーやASTを用いた網羅的な実装が頻出するフロントエンドツールの開発に向いていると考えられています。
oxcはハイパフォーマンスなフロントエンドツールのコレクションであり、biomeやrolldown、rspackなどの実装で使用されています。
このセッションでは、oxcがなぜ高性能なのか、その背後にある技術を解説します。また、oxcがフロントエンドツール開発の未来をどのように変えていくか、その可能性についてもestreeなどの既存技術との比較を通して探ります。
storybookをベースにVisual regression testやアクセシビリティーのテストができるらしい!
ぜひやりたいが手元にはSPAではなくtemplate engineベースのMPAしかない!そんな時に役立つテクニックをご紹介します。
近年、フロントエンドにおいて、Rust製のツールが増えてきました
一方で、フロントエンドエンジニアの多くはJavaScriptやTypeScriptが中心で、Rustはあまり馴染みがないのが現状です
私自身、スクリプト言語を中心に使ってきた普通のWebエンジニアですが、フロントエンドツールチェインをより深く理解し、パフォーマンス改善やOSS貢献ができるようになりたいと考え、Rustの学習を始めました
簡単なCLIツールを作成したり、普段Node.jsで書いているような処理をRustで置き換えたりすることで、少しずつ言語に馴染んでいきました
このトークでは、私の入門の過程をご紹介しながら、Rustを学ぶメリットについて考察します
Rustに興味はあるけれどまだ始められていない方にとって、入門のきっかけになれば幸いです
ここ数年、新卒研修でWebプログラミング講師を担当しています。
研修は受講者の経験レベルもバラバラで時間も限られますが、実施するからには次のことを学んで欲しいと思いました。
これらをなるべくWebの仕様そのものに沿って教えるとなった時に、Rubyが適していることに気づきました。
RubyはTCP通信や動的HTML生成を標準ライブラリだけで素直に実装可能で、HTTPはリクエストラインから仕様通りに書き下せて、Macに最初から入っています。
このトークではRubyを使ってWebの基礎を学ぶのにちょうど良いサーバーを作るところをお見せします。
皆さんも日頃からBasic認証を使っていると思います。
しかし実装がどうなっているかはご存知でしょうか。
大体のフレームワークのプラグインを使わずに自前で実装するとすると何が必要になるがご存知でしょうか。
Authorizationヘッダーの構成要素に名前や仕様が存在していることはご存知でしょうか。
Basic認証はHTTP Authenticationの枠組みの一つでしかないことはご存知でしょうか。
ブラウザにUsernameとPasswordの入力画面が表示されるのは、どの仕様のおかげでしょうか。
その仕様に準拠しないとどのようなバグを引き起こし、ユーザーにどのようなワークアラウンドを要するかご存知でしょうか。
このように一見簡単なBasic認証ですが、仕様を理解することで初めて見えてくる世界や、調査や解決できるバグもあります。
このトークでは上記の疑問に対する答えを速習します。
概要:
このセッションでは、MVCフレームワークに慣れたPHPエンジニアが、どのようにしてLaravelのBladeテンプレートエンジンを使用してWordPressサイトを構築したかを紹介します。従来のWordPressの開発環境に馴染めなかったエンジニアが、Bladeを使うことでどのように開発プロセスを効率化し、再利用可能なUIコンポーネントを作成し、コードの冗長性を減らしたかを紹介します。
具体的な学びのポイント:
Bladeの導入: BladeをWordPress環境に統合する際の技術的なステップと必要なツール。
開発効率の向上: 再利用可能なコンポーネントの作成と、維持管理の容易さについての実例。
挑戦と解決策: WordPressのエコシステムに逆らうことで発生した問題点と、それにどのように対応したか。
このセッションではReact RouterやTanStack Routerなど
ReactのSPAアプリで導入可能なルーティングライブラリについて話します。
▼ こんな人が対象者
▼ 内容
私の自社プロダクトではご利用ユーザーの特性上
2024年現在でもガラケー(フィーチャーフォン)やガラホ(ガラパゴス型Androidスマートフォン)をサポートしております。
このセッションでは、これらのレガシーデバイスに対してどのようにサポートを続けてきたかについて話します。
▼ こんな人が対象者
▼ 内容