X11

概要

https://nana-music.com から, リニューアル版 https://beta.nana-music.com/ の Web フロントエンドの技術選定, 設計から実装, 保守・運用をすべて一人で担当 (現在も, 機能追加, パフォーマンス改善, バグ修正など進行中).

既存コードとリニューアルデザインカンプから仕様を把握して技術選定・設計まで

これまでに経験したことのない最も大変なことであり, 前任者などが誰一人いなく, ドキュメントもなく, コードも断片的につぎはぎされたような状態 (リリースプロセスなどもなく, ほぼ放置状態) から, 仕様を把握して, 技術選定・設計をおこなうことでした. そのためには, 既存のコードをリーディングするには限界があり, リニューアルにあたっての MVP (Minimum Viable Product) を以下のように整理して (また, ビジネス的な理由上, 2023 年 10 月にローンチして, 2023 年 12 月末までにリニューアル版としてリリースする必要がありました), それを補完するために既存のコードや挙動をかいつまんで進めました.

• アカウント作成ができる
• ログインができる
• アカウント情報が編集できる
• ユーザーページが閲覧できる
• 検索やフィードなどコンテンツ回遊の導線ができる
• 動画・オーディオの視聴ができる
• オーディオファイルがアップロードできる

また, MVP を意識して, UX 的なことは削ぎ落としたり (例えば, 検索では当初の予定では, さらにフィルタリングができる想定), デザインに時間を要するところはデザイナーと相談して簡素な UI に変更してもらう (例えば, カルーセルは横スクロールにしてもらうなど) などしてこれ以上削ぎ落とせば, nana の Web アプリケーションとして成立しないぐらいの実装コストを減らして, 実質 2 ヶ月の実装時間 (残り 1 ヶ月は QA 項目の作成, QA プロセスの主導) で MVP を実装し, リリースすることができました.

技術選定

企業規模, また, 経営的にも人的リソースを確保できる状況ではないので,

• フレームワークやライブラリは充分に枯れているのを選定する
• 開発に関わる人が複数にならないと決められないようなこと (チームメンバーのスキルや経験) に依存しやすいことは避ける

上記の 2 点を意識しました. 具体的には, 既存の Web アプリケーションは Vue.js + Nuxt で実装されていましたが, 現状の Web フロントエンドの技術動向から React + Next.js の方がより枯れていると判断して, 既存資産は使うことをせずゼロベースで実装したり, API スキーマからの型生成もあくまで型定義のみを生成する薄いツール (openapi-typescript) を選定したり (クライアントコードまで生成すると生産性は向上するが, 将来ジョインするメンバーのスキルや経験によっては逆効果になりうるので), ツールで制約できないコーディング規約は作らないといったことです.

そのほか

技術的理想に対して, 教条的になりすぎず, 後回しでよいことやあればよいぐらいのことはやらないようにしました.

• Storybook は導入し, コンポーネントの Story ファイルは担保しても, VRT まではしない
  • そもそもセルフレビューの状態なので VRT の意味がそこまでない. Story ファイルさえあれば, Chromatic などを導入すればいつでもできる
• pre commit フックは使わず, CI でフォーマットや型検査を担保する
  • commit 待ちの時間がもったいない
• API スキーマファイルの更新は手動 (Swagger から定義ファイルのみコピーして openapi-typescript で生成する)
  • 将来的にはパッケージ化するなどして自動化したいが, 現状, バックエンドも人的リソースが少なく, 頻繁に API の更新があるわけではない. また, アプリで使われている API がほとんどのため, 新規に追加されるスキーマもほとんどないので.

概要

GMO PGマルチペイメントサービスを利用した, 各保険会社ごとの (マルチテナントごとの), Web でのクレジットカード登録・決済システムを実装

実装上の大変だった点と属人化の防止

まず, クレジットカード決済に対する基本知識の習得を元に, GMO PGマルチペイメントサービスの決済フロー (例えば, 3Dセキュア2.0 対応と未対応での決済フロー (API リクエストのフローの違い) であったり, GMO が提供する SDK (クラインアント側での POST 処理の詳細の理解, 例えば, SDK では Fetch API などによる Ajax で Content-Type: application/json による POST リクエストではなく, HTMLFormElement による Content-Type: application/x-www-form-urlencoded が決済フローとして実行されていることをトレースしたり, またそれに合わせて, 自社側の API 側のコードをリーディングして, レスポンスの Content-Type を修正したり, 決済終了後の iframe へのレスポンスから, 親フレームへの postMessage で, 決済のウィンドウを閉じるなど, 非常に複雑な仕様を読み解きリリースまで問題なく遂行したこと, また, 一人での実装であったので, Web フロントエンドメンバーへの仕様・実装の共有をして, メンバーの誰もが, 最低限, 何を知っていればいいか, どこが実装において重要な点かを共有し, 属人化させずその後の追加対応などを他のメンバーに担当できるようにしました.

概要

TIPSTAR のリニューアル (主に, デスクトップ版対応) にあたって, Web アクセシビリティを Lighthouse の計測で 40 から 98 まで向上させました

意識したアクセシビリティのポイント

リニューアルに関わったメンバーは Web アクセシビリティにあかるいわけではなく, また, リニューアルも人数に対して工数がかなり多かったことから, できればこうありたい Web アクセシビリティの指摘よりは, マストな Web アクセシビリティを意識してコーディングしてもらえるように, レビューをとおして, 以下のポイントを主に重視しました.

• 適切なマークアップ (例えば, クリックしてダイアログが開くなら, button を使うなど)
• 画像の alt 属性 (説明が必要ならつける, 隣接する場所にテキストがあったり, 装飾的な画像であれば不要)
• WAI-ARIA 属性 (特に, 装飾的なテキストでは aria-label, 装飾的な要素には role="presentation" をつけるなど)

主な成果

ブラウザの Autoplay Policy (ユーザーアクションがない場合, ミュート状態でないと自動再生不可) に対する対応

下記のような挙動の特徴を発見しそれに対応する実装をした結果, Autoplay Policy のあるブラウザでもベストエフェオートな自動再生を可能にすることができました.

• Safari のみボリューム・ミュートともに 0・オフにしないとミュート状態とみなされない
• 1 度自動再生に失敗しても何度か再生を試みると自動再生できることもある
• SPA の場合, ページ遷移のためのユーザーアクションが動画プレイヤーへのアクションとみなされて, 事実上, ミュートしなくても自動再生可能 (ただし, 動画プレイヤーのページでリロードした場合は, ミュートが必要)

Storybook を利用した動画プレイヤー UI コンポーネントの管理

個別顧客用に新規動画プレイヤーを実装することになった案件で, 既存のプレイヤーは技術負債のかたまり (テストコードもなし) だったのでそれをそのまま使うことはせず, Storybook を利用しながら 1 つ 1 つの Vue Component の動作を確認しつつ, Atomic Design にそってリファクタリングしました. その結果, 既存のコードでは video.js にべったり依存していたのが, 容易に他のストリーミングライブラリ (hls.js など) に差し替え可能になりました.

hls.js へのコントリビュート

• v0.12.4 の hotfix
• webpack 4.x + TypeScript コンパイラへの移行

概要

Flux フレームワークである Flummox が開発停止になってしまい, そのままでは, React のバージョンアップに対応できないなどのリスクが生じたので, 別の Flux フレームワークを使い, アーキテクチャ刷新をすることになりました.

Redux 選定の理由

もっとも大きな理由は, Flummox から (Store が複数, or 1 つという違いなどはあれ) 移行しやすいということでした. 移行のしやすさを最大の理由にしたのは, ビジネス制約上, リソースを大きく割くことはできなかったことがあげられます (実際, このアーキテクチャ刷新と同時並行して, 新機能の実装も進んでいました). 他の候補としては, MobX がありましたが, すでにあるプロダクトを刷新する (新規プロダクト実装ではない) ということから, メンテナンス性が高いという点でも Redux に分がありました (記述は MobX より冗長になりますが, その分自由度が少なく, 誰が実装しても同じようなコードになる). 実際, このメリットは大きく, リリース時期が迫るにつれ, より多くのエンジニアが参入しましたが, コストをほとんど要さずに, スムーズなジョインを可能にしました.

調整力と評価

リリースが迫るにつれ, ディレクターやテスター (実機確認者), インフラ担当者, また, プロダクトのリブランドが最重要で動いていたこともあり, 様々な人と協調する調整力が要求されました. 結果としては, 最重要のリブランドのリリースに支障をきたすことなく, また, 既存のバグ以外は, 一切のバグなしという無事故リリースを実現することができました. また, 既存コードには, テストコードが存在しませんでしたが, Action / redux-saga (Web API との通信処理) / Reduer のテストコードも追加し, 以前よりいっそうメンテナンスの高い Web アプリケーションにすることができました.

概要

生放送サービスに関わっていたときに, デスクトップでもリアルタイムで番組開始通知を受信できることで番組視聴数を向上させることを目的に実装. ちなみに, わたしが社会人エンジニアになってから, 1 人でまとまった機能を実装したはじめての実績となります.

Service Worker

Web Push に先立って, Service Worker の Cache を導入し, パフォーマンス改善, また, サービスの PWA 化などを実現しました. 特に工夫したこととしては, CircleCI でビルドされたタイムスタンプをキャッシュ対象のアセットのパスに使うことで, リリースしたときには必ず Service Worker の Cache が更新されるように自動化しました.

最も大変だった実装

実装した当時は, Web Push 自体は普及初期ともいえ, ブラウザ自体にバグがあり (特に, Web Push 通知許可を求めるダイアログの表示や, 通知許可・通知拒否をしたときの挙動が必ずしも仕様に沿っていなかった. 例えば, 通知はブロックされるが, Notification.permission の値が 'default' (通知を許可している状態でも, 拒否している状態でもない) になるなど, 結果として, 通知状態と UI が整合しないということが最大の問題でした), それらの挙動を調べあげ, ユーザーが使用する上で問題のない, つまり, 通知状態と UI の整合が保たれた状態でリリースすることができました (FRESH! における Web プッシュ通知機能 〜実装編〜).

概要

オーディオ技術のないエンジニアにも, ブラウザでオーディオを扱えるというコンセプトで実装し始めた Web Audio API ライブラリ. 現状, Web Audio API はある程度オーディオ処理を抽象化した JavaScript API ではありますが, (例えば, BiquadFilterNode のようにデジタルフィルタの詳細を知らなくても 8 種類のデジタルフィルタが利用可能となっています. ところが, 本格的なオーディオ処理をするためには, 結局のところ, オーディオ技術が必要になります (例えば, フェイザーというオーディオ処理を実装するには, 基礎的なオーディオ技術をもとに, BiquadFilterNode を組み合わせる必要があります) . XSound は, Web Audio API をさらに抽象化し,

• 直感的な記述で実装できる
• オーディオ技術がなくてもある程度の機能が実装できる

以上 2 つを実現したライブラリとなっています. また, 将来に渡って, 破壊的な変更を最小限にできるように, ライブラリ・フレームワークに依存しない実装となっています.

機能リスト

• サウンドの生成
• ワンショットオーディオ (ピアノの音など) の再生
• 楽曲データの再生
• WebRTC からの音声取得と加工
• MML (Music Macro Language) による自動演奏機能
• サウンドエフェクト処理
• 波形描画
• WAV ファイルの動的生成による録音機能
• WebSocket によるバイナリメッセージング機能
• Audio Sprite (オーディオの部分切り取り)

XSound.app はライブラリの機能をほとんど網羅した Web アプリケーションです.

プロダクトの内容と設計

• オーディオ信号処理の理解や Web Audio API のやや奇怪な API を抽象化し, 簡単に Web オーディオプログラミングを可能にする
  • ネイティブアプリケーションの移植ではない, Web Music アプリケーションの創造をサポートしたい
    • これまで, 多くの Web Audio API を利用した Web アプリケーションがネイティブアプリの移植に過ぎない
    • Web をオーディオプラットフォームにする理由として弱い (インストール不要, クロスプラットフォーム対応などは技術的優位性とは言えない. 特に, 音楽用途の場合, 0.025 msec ~ 0.05 msec 程度の精度が求められる. それよりレイテンシーが長くなると, 音楽として成立しなくなる)
    • Web をオーディオプラットフォームにする最大のモチベーションは, ネイティブアプリにとらわれないアイデアだと考えている (例えば, どんなに WebAssembly でネイティブに近いパフォーマンスを実現しても, Web であるが故の制限 (例えば, SharedArrayBuffer の複雑な制限) や, I/O 関連の最適化は難しい. 例えば, Web MIDI API などは Working Draft のまま長い間仕様すら更新されていない). そのアイデアの試行錯誤を形にするきっかけやヒントを与えることが目的
  • したがって, 特定の目的があるプロダクト, 例えば, Web DAW などを作成する場合には向かない. それ専用のライブラリを使うことを推奨している (howler.js, Tone.js, Tuna.js など. たまに質問を受けることがあるが, そのように回答している)
  • しかしながら, 理由としてはあとづけで, もともとは XSound.app の制作において, UI とオーディオ信号処理の分離, すなわち, ビューとロジックの分離を進めているうちに, いつしか (2013 年半ばぐらいから ?) ライブラリとして再利用可能なプロダクトになっていた (ちなみに, git でバージョン管理もできていない頃の最初期のバージョンは公開している. ソースを見るとあきらかに, UI とオーディオロジックの分離ができていない)
• 音源の抽象クラスである, SoundModule に必要なオーディオ処理を集約して, サブクラス (個別の音源, 例えば, オシレーターやノイズ, 楽曲データ, WebRTC からの音声など) において, 必要な処理を override, また, 個別に必要なオーディオ処理を実装 (例えば, ノイズサプレッサーなどは StreamModule (WebRTC からの入力音をソースとするモジュール) でしか使わないので, SoundModule では実装していない). これが基本設計であり, 結果として, テンプレートメソッドパターンになっている. 端的には,
  • 抽象クラス SoundModule のオーディオ信号処理をもたせる
  • サウンドソースに応じたサブクラスで必要に応じてメソッド定義
• MML (Music Macro Language) は例外的で, MML のパースと, 委譲された (DI された), SoundModule のサブクラスをパース結果の音楽演奏情報にしたがって, 自動演奏を実行する (また, SoundModule を継承しない).

どういう考えでコードを書いたか、なにに注意したか

• 音源は異なっても (X 関数で取得する SoundModule のサブクラス), 可能な限り同一の API (メソッド) を提供する
  • setup (アプリケーション起動時に必要な初期化処理)
  • ready (再生前に必要な処理. スケジューリングなど)
  • start (再生)
  • stop (一時停止)
  • param (パラメータの取得・設定)
  • module (モジュールを取得して, アクティブ状態にしたり, パラメータを設定したりする)
    • Web Audio API における AudioNode の複雑な connect (モジュラールーティング) を抽象化する重要なメソッド
• これらは, サブクラスごとにシグネチャが異なるので, 抽象メソッドにして実装を強制できていないのは課題
  • 実装もれを人力チェックするのは少々しんどい
• SoundModule に共通するオーディオ処理を集約して継承する
  • 一般的には, 継承より委譲のほうが結合度が低くなり, モジュールの独立性としては高くなるが, アプリケーションコードが簡易になるように継承 (テンプレートメソッドパターン) を採用している (version 1.0 から, 現在のバージョンまで変わらない)
    • 委譲にすると, アプリケーションコード側で必要なモジュールを委譲 (DI) する必要があり, アプリケーション側で必要な実装が多くなる. また, 少なからず, オーディオ信号処理の理解が必要になる可能性が高くなる.
    • 開発開始当時 (2012 年), 一般的に使われていた jQuery のような記述で使えるようにしたいという漠然とした理由もある
  • ただし, 代償として, ライブラリ側では SoundModule が肥大化してしまっているので, サブクラスでボイラーテンプレートのようなコードや, ボイラーテンプレートのような単体テストがたくさんあるのは問題点としてある

工夫した点、苦労した点など

アーキテクチャレベル

• 継承関係を検討する
  • 例えば, AudioModule と MediaModule は同じような機能をもっているので, MediaModule を AudioModule のサブクラスにすることも考えたが, 継承の継承はさらに結合度が高くなる (モジュールの独立性が低くなる), また, 実装が増えても, アプリケーションコードには影響がない.
  • 委譲で問題ないモジュールは継承させない (例 MML クラス)

Recorder

• 録音データでメモリを不要に使わない (number[] ではなく, Float32Array[] に格納する)
• ミキシング処理
  • 各録音ラインの, 左右チャンネルで Float32Array[] のトラックを, Float32Array にフラット化
  • 各録音ラインの, チャンネルごとの合成・平均化 (オーディオ信号処理におけるインターリーブ処理)
• 量子化ビット 16 bit の場合の WAVE ファイル生成 (リトルエンディアンでデータを格納する必要がある)
  • ビット演算で, 下位 8 bit を先に配列に格納
  • シフト演算して, 上位 8 bit を次の要素に格納

MML (DSL)

• 大量のパラメータをアプリケーションから与えるのではなく, 言語を与えて目的を達成する
  • 正規表現の問題解決のアプローチと同じ
• 自身が初めて実装した言語処理型 (正規言語, 有限オートマントで受理可能な文字列)
  • 初期の実装では, トークナイズや抽象構文木の生成はせず, 正規表現で音楽情報に変換していた
• 抽象構文木の設計
  • 左部分木は常に数値
  • 右部分木に進むほど, 音楽的な時間も進む (木のレベルが大きくなる)
    • 一般的に, 探索に不利な木構造 (クイックソートが最悪計算量になるような木構造) であるが, 目的は (実行前の) 音楽情報への変換なので問題ではない
    • むしろ, 右部分木が深くなるほど, 音楽的な時間も進んでいるという情報を表現しているので適している
  • ABC 記譜法へのトランスパイル
    • abc.js によって SVG による楽譜が出力できる
    • ただし, このトランスパイルは正規表現による変換なので, こちらも抽象構文木を生成して変換できるようにしたい (ABC 記譜法のほうが, より多くの音楽表現ができるので, 言語仕様の拡張が十分にありうる)
  • ハイライト処理. 実装自体は難しくないが, HTML としてあつかう必要があるので, パフォーマンスを考慮して, ハイライト処理を OFF にできるようにしている (マシンスペックが低い場合などを考慮).
    • 同様の考えは, ビジュアライザーにもあり, Canvas や SVG への描画のアニメーションは, 少なからずパフォーマンスを落とすので, スペックの低いマシンでの利用を想定して, OFF にできるようにしている

ScriptProcessorNode から AudioWorklet への移行

• ライブラリなので (CDN としても使えるようにしているので), 1 ファイルにまとめるためにハッキーな実装を試行錯誤 (バンドラーで /^.+Processor$/ で終わるクラスを識別し圧縮しないようにする).
  • AudioWorkletProcessor のサブクラスを定義して, toString で文字列にして, Data URL で addModule する.
  • そのまま, バンドルすると, メインスレッドのコードとしてまとめられてしまうので, 上記のようなバンドラーの設定で解決 (できればしたくはなかったが).

オーディオ信号処理の理解

TypeScript など Web フロントエンド関連の技術と Web Audio API を理解しているだけではここまでの実装はできないと思う. 少なからず, オーディオ信号処理を大学院での専攻としていたことが活きている

2012 年 10 月から現在まで

モチベーションはその時々で変わってきたが, 12 年近く, 機能追加やバグフィックス, リファクタリングを続けて, また, Web フロントエンド技術のエコシステム (npm によるパッケージ管理, TypeScript による型システム・型検査, ドキュメントの自動生成や, ESLint による潜在的なバグの autofix など) をあわせてバージョンアップを続けてきたこと.

技術スタックの刷新

Release note

• TypeScript 100%
  • Enable to use ATA (Automatic Type Acquisition)
• Improve code quality
  • Type check
  • Use Jest instead of Jasmine & Karma

実績・評価

v1.x.x のリポジトリ のスター数と合算すると 200 を超えており, これはニッチな Web Audio API ライブラリというドメインにおいて, メジャーな部類に入ると言えます. 実際,
9 libraries to kickstart your Web Audio stuff で, 9 つの有用なライブラリの 1 つ取り上げられており,

XSound is a batteries-included library for everything audio. From basic management and loading through streaming, effects, ending with visualizations and recording, this libraries provides almost everything! It also has nice, semi-chainable API with solid documentation.

• オーディオ処理のほとんどすべてを実装している
• 堅実な API ドキュメントがある

上記 2 点が評価されています.

また, 国内を代表するエンジニアの方からも評価を受けています.