tai2

## 概要 プロジェクトの立ち上げからベータリリースまで関わりました。 最初はクライアント(プロダクトオーナー)と、ディレクター１人、開発者であるわたしの3人で始まったプロジェクトのため、技術選定から設計・実装まで、序盤はすべて１人で行いました。開発の中盤あたりから、知り合いのフリーランスエンジニアやクラウドーシングから募集したデザイナー・エンジニアに参加してもらいチームとしての開発を進めました。 ## インフラと技術の選定 インフラは、少ない人数で成果を出すために、アプリ実装に集中できるHerokuを選択しました。 言語とフレームワークは、初期の速度と後々の人員の集めやすさを考慮して、 (自分の好みからは離れますが)Ruby on Railsを選択しました。 わたし自身、Railsはこのプロジェクトではじめて使いました。 初期は、ふつうにRailsのbuildpackを使ってはじまりましたが、中盤以降Dockerベースで環境を構築し、プロダクション環境、CI、開発環境すべて同一のDockerイメージで行うようになりました。なお、CIはcircle ciを使い、そこでプロダクション用のDockerイメージをビルドして、HerokuのDockerレジストリにpushするというデプロイプロセスにしました。 開発環境をDockerベースにしたことで、技術者ではないプロダクトオーナーや、はじめてプロジェクトに参加したメンバーも、環境構築に苦労することなく、ローカルでサービスを動かして最新のコードを確認できる環境を作りました。余分なミドルウェアのセットアップや煩雑な環境変数の設定などに煩わされず、docker-compose up一発で、だれでも環境が立ち上がるようにこだわりました。 (ただ、全員Mac環境のためDockerだと速度面などの問題もあり、Dockerを使わずに環境起動するための手順もオプションで用意しておくほうがベター、というのが現時点での考えになります。) ## Railsのコード 人員を集めやすいようにというのがRailsを選択した理由のひとつだったため、なるべく素直でふつうのRailsコードになることを心掛けました。 自分自身RailsやRubyに関する知見がほとんどなかったため、rubocopをほとんどデフォルト設定のまま使い、それを基準として進めました。 アプリ自体クライアントサイドがメインで、サーバー側はそれほど複雑なものではなかったため、サービスクラスなども導入せず、モデルが多少大きくなっても構わないという方針でいました。モデルが多少太っても、後からリファクタリングすることは難しくないという考えです。逆に、余分な抽象化や、あまり一般的でないプラクティスの適用は、後々の負債になると考え、避けるようにしました。 ただ、Railsの思想自体、自分の思想(Explicit is better than implicit)とは合わない部分も多々あり、葛藤もありました。とくに、concernやcallbackは、使いかたを誤ると非常にコードを追ったりデバッグするのが難しくなるため、あまり使いたくないという気持ちが強かったのですが、Railsの標準的なプラクティスで自然なRailsコードにしようとすると、どうしても使う必要があり避けられないという感触がありました。 concernについては、https://medium.com/@carlescliment/about-rails-concerns-a6b2f1776d7d この記事を参考にして、基本的に委譲を使う方針としましたが、結果的にややRailsらしくないコードになっており、今でも正しかったのか迷いがあります(次やるときは逆に思いきりRailsらしい方にふってconcern使いまくりでやってみようかと考えています)。 ## フロントエンド HTMLの知識がまったくないユーザーでもランディングページが作成できるというのがコンセプトだったため、GUIのドラッグ&ドロップのみでサクサク編集できる必要がありました。Reactでドラッグ&ドロップをかなりヘビーに使うアプリを実装するというのが、このプロジェクトのチャレンジングな点のひとつです。 基盤として選択したのはreact-dndですが、これは(react-beautiful-dndなどに比べれば)かなり低レベルなライブラリのため、生DOMにアクセスしての座標計算などもゴリゴリ行う必要があります。アプリの性質上、どうしても生DOMを使ったコードは増えましたが、それでも全体としては、ReactとFluxアーキテクチャによってアプリの複雑性を押さえ込めたという感触があり、Reactの実力を実感したプロジェクトでした。 ## テンプレートシステム このプロジェクトでもっとも苦労した部分のひとつが、テンプレートシステムです。 ランディングページのデザインを、ユーザーの好みにあったものから自由に選択できるようにするシステムです。 テンプレートのデザインは、クラウドーシングなどで募集をかけた上で、デザイナーに大量発注する想定だったため、HTML/CSSの知識がある人ならばだれでも作成できて、かつ、デザイン上の表現力も十分に確保できる形式である必要がありました。SASSの知識やそれを使うためのツール環境の知識さえも前提とはしたくないため、素のHTML/CSSのみで構成できることが要求されました。 それを実現するための解法として取ったのは、一定のフォーマット(命名規則など)にそった一枚のHTML/CSSをデザイナーには入力してもらい、そのHTMLで一枚のページとしてデザインを入稿してもらいます。 入稿されたHTML/CSSをこちらで作成したツールにかけると、システムで実際に利用可能なテンプレート形式に変換されるという仕組みです。デザイナーが作成するのは、たんなる標準的なHTML/CSSであるため、こちらのテンプレートフォーマットの込み入った知識はほとんど要求されません。 ただ、それでも変換のために最低限のレギュレーションは必要なため、バリデーションツールも作成し、実行した上で、HTML/CSSが正しい形式になっているかどうかのチェックを行うようにしました。このバリデータとコンバータは、Node.jsで作成しました。 ## CSS もう一点チャレンジングだったのは、CSSの設計です。 このシステムで作成したランディングページは、最終的にはたんなる静的なHTML/CSSとして出力されます。つまり、編集中のUIなどが乗ったページと、最終的にレンダリングされたページの二種類があるのですが、編集中の見た目と、最終的な見た目が基本的には同一である必要があります。 これを実現するためには、DOM構造とCSSの設計において、いくつかの基本的な選択肢が考えられます。 それらの選択肢には、実装難易度と、UIがコンテンツ自体に与える影響(侵襲性)との間でトレードオフがあります。結果的に選択したのは、実装はそこそこ素朴に行えるが、コンテンツのDOM構造にも若干の影響が出る形の設計です。DOMの構造が、編集中と最終的なページで多少変わるため、見た目の違いが出てしまう可能性が若干高まります。ですが、開発中にしっかりと検証を行えば、そこまで問題にはならないだろうと判断しました。実際そこまで致命的な影響は出ませんでした(なお開発を進めている最中に、より影響が出なく開発難易度もそこまで上がらない設計も思い付きましたが、その設計を試す機会は残念ながらありませんでした)。 この選択は、類似サービスなどの実現方法も参考にしつつ、手探りで行いました。利用しているreact-dndの制約などさまざまな要因が絡みあっています。 ## 開発プロセス 序盤からプロダクトオーナーと共に、アジャイルやスクラムに関する本を何冊か読み、最終的には1週間に1度のイテレーションでリリースを行う形で進めました。序盤はPivotal Trackerを使いましたが、途中からはGitHub上のZenHubに移行しました。プロダクトの最終的な形を定めず、毎週動かしてプロダクトオーナーが得た感触から、ときには大胆に既存実装を削除したり、コンセプトを大幅に変更し、クライアントであるプロダクトオーナーの理想を実現できるシステムを追求しました(その分、試行錯誤の連続となるため、開発期間はどうしても伸びました)。

## 概要 自社用の新規ビジネスとして、RTMPストリーミングサーバー、およびそのGUIフロントエンドや周辺ツールをC++を使ってフルスクラッチで開発しました。Linux,Mac,Windowsのマルチプラットフォーム対応。 ## 背景 当時は、まだ動画のライブストリーミングサービスの黎明期で、存在自体が、いまほどには認知されていませんでした。Flash技術を通じてブラウザで簡単にライブ配信できる環境には可能性がありました。 RTMPの仕様自体が公開されていなかった(後程公開)ため、コミュニティーで行われていたプロトコルの解析結果や、その結果として実装されたOSSを参考にして実装しました。主要なOSSとしてはJavaで実装されたRed5などがありましたが、C++で実装することでより軽量かつハイパフォーマンスで、機能を限定するかわりにシンプルな設計とし、複雑な設定が不要な製品を目指しました。 ## 技術的なチャレンジ 仕様非公開のプロトコルであり、対向のクライアントであるFlashプレイヤー自体も、スクリプティング可能な環境とは言え、内部的な動作はブラックボックスであったため、まず接続して最初に動画が再生されるまでが苦労しました。接続に成功している既存のOSSにログなどを仕込みつつ動作の流れを追ったり、Wiresharkを使って、接続時や再生時に実際にどのようなパケットが流れているのかを確認、あるいはメーリングリストでのコミュニティーの議論などを追いながら、ひとつひとつ問題を潰していきました。 Flashプレイヤーの更新によって、新しい動画フォーマット(H264)に対応するために、専用のハンドシェイク方法への対応が必要になるなど、プレイヤーの仕様変更への追随なども必要になりました。自分でプロトコルをしたわけではありませんが、これもやはり仕様が明示されているわけではないので試行錯誤が必要でした。 また、このエンジンを利用して、当時としてはめずらしい、Peer to Peer(配信者と視聴者の直接接続)での動画配信プロダクトの開発も行いました。Peer to Peerで配信する再にネックになるのはNATで、どうNAG越えを実現するかが課題でした。STUNTというTCPでNAT越えをする技術に着目しましたが、多くのルーター(全部ではない)が持っている明示されていない特性を利用する技術で、実装難易度が高そうなわりには、カバーできる範囲が100%になるわけでもないため、これは一端あきらめました。多くの家庭用ルーターが対応しているUPnP(UDPでルーター設定の変更などをできるプロトコル)を利用して、ルーター設定をアプリから変更することで対応しました。 エンジン自体はC++で実装していましたが、アプリ向けに柔軟な機能拡張ができるようにPythonインタプリタをエンジンに組込みました。上記のUPnP対応などもPythonスクリプトで実現しました。 サーバーは、メモリ消費を抑えたままでの同時接続性を実現するために、libevent(libevの前身)を使用して、非ブロッキングソケットを用いたイベントモデルを採用しました。ただし、イベントモデル(=単一スレッド)だとCPUコアを十分に活用できないため、マルチスレッド+イベントモデルという形でより高いパフォーマンスを発揮できるサーバーを目指しました。マルチスレッドにしたときに、スレッド間の通信手段が必要になりますが、こにはパイプを使うことにより、非ブロッキングイベントモデルのレースコンディションを気にしなくて良いという特性を活かしたままスレッド間通信を実現できました。 ただ、結果的にマルチスレッド化したことによりコードベースは複雑化してしまい、今思うとオーバーエンジニアリングだったように思います。今であれば、よりクリーンな実装が可能な単一スレッドのイベントモデルで実装します。配信サーバーは長寿命のプロセスになるため、数週間起動していると、いつの間にか落ちているということもままあり、安定化にはかなり苦労しました。

## 概要 プロジェクションマッピングで、スクリーンに描画するためのイメージの計算、およびそのイメージを物体に投影した場合のシミュレーションを行うシステムの研究開発を行いました。Windows向けデスクトップアプリ。 ## 技術的なチャレンジ プロジェクションマッピングは、現実世界の物体をスクリーンに見立て、その物体表面にフィットするように計算を行った上で、プロジェクターなどから光を投影する技術です。計算されたイメージが、まるで物体の上に実際に存在しているかのように投影されるため、その場にいる人が臨場感を持って映像を体験できます。本プロジェクトでは、このプロジェクションマッピングを、とある工業的な生産プロセスに応用するための研究開発を行いました。二次元的な映像が、対象の上にゆがむことなく投影される状態を実現する必要がありました。 これを実現するための基本的な手段は、空間上に、人の視界に見たてたスクリーンを配置した上で、反射の計算をするレイキャスティングです。視界の各点の集合である「最終的に人の目に見えて欲しい象」が、物体上のどの点で反射されてディスプレイ(本件ではプロジェクターではなく面を持ったディスプレイをプロジェクタとして使う)のどの面に到達するかがわかれば、それはつまり、ディスプレイをどのように発光させるべきかがわかったということになります。 こうして計算されたピクセルの発光によって、理想的には、物体表面に元の象がそのままの形で復元されるはずです。また、これと逆の計算を行うことによって、物体表面にどのように象ができるのかをシミュレーション(検証)することができます。 最初、これは基本的なレイトレーシングの手法で行えると思ったため、(kdツリーなどの)空間分割のためのツリー構造を事前計算しておいた上で、レイの反射計算を行うことで効率的に上記の計算が行えると考えました。しかしながら、データ構造の構築によってかなりの計算を省略できるとは言え、高々ピクセル数×ポリゴン数(投影対象)×ポリゴン数(ディスプレイ)の計算が必要になるため、軽い計算ではありません。 しかし、本件はシミュレーション結果のレンダリングのために、OpenGLでラスタライズを行うことが決まっていたため、すべてのポリゴンを反射計算の対象とする必要はなく、ラスタライズ結果を「見えて欲しい象」と同一であると見なせば、画面上のピクセルごとに反射計算を一度行えば良いことに気付きました。ラスタライズの過程で、ピクセルと対応する、最前面の物体とその座標が確定しているためです。こうして、投影計算と、その逆計算のシミュレーションまで含めて、リアルタイムでの計算を実現できました。