初めまして。こんにちは。
メディアディベロップメント事業本部(MDH) 動画開発局の塩島と申します。
普段は、動画広告プロダクト(AVA Style for cosmetic, AVA Style for recipe, ライブ動画や360度動画等)をチームで開発しています。
さて、先日 LT Thursday Vol.21 が開催されましたので、その様子をレポート致します。
1. Introduction to QC (MDH 小坂)
まず最初に、MDH ADテクノロジー局の小坂が ”Introduction to QC” というテーマで発表しました。
“QC” というとQuality Control(品質管理)を思い浮かべますが、今回は”Quartz Composer”に関しての紹介となります。
Quartz Composerとは、ノードベースのビジュアルプログラミング言語で、Xcode development environmentの中の製品の一つです。グラフィックデータ処理のためにMac OS Xの開発環境の一部として提供されています。
身近なところでは、Macのスクリーンセーバーやメディアアートの分野などで利用されています。
発表では、音に合わせて円や四角形を生成する映像や実際に作成した時計を表示するプログラムの実行結果の紹介がありました。具体的には、System TimeというモジュールからDate Formatterというモジュールを通し、Image With Stringにより文字列を画像にすることで時計が表示されるようになります。
また、SyphonというオープンソースのMac OS Xテクノロジーの紹介がありました。
このプラグインを使うと、あるアプリケーションから出力されたビデオのストリーミングを他のアプリケーションで入力として使うことができます。
Syphonは、QCだけでなく、プロジェクションマッピング制作に良く使われるMadMapperやModul8、unityなど様々なソフトウェアやアプリケーションに適用されています。
発表の中でもありましたが、業務の中のどんな場面で利用するかを考えるとなかなか難しい部分がありますが、視覚的効果のある興味を惹かれるような映像が作成可能なので、単に見せるだけで人を楽しませたり、喜ばせたりできるのではないかと思いました。
2. Prepack VS Closure Compiler (MDH 泉)
続きまして、同じくMDH ADテクノロジー局の泉が1ヶ月ほど前(ゴールデンウィーク頃)にリリースされたPrepackについて発表しました。
Prepackとは、JavaScriptのソースコードを最適化するツールでFacebook社が開発しました。これは、「演算可能なことはコンパイル時にしてしまう」というコンセプトで開発されました。
公式サイトに “Prepack is still in an early development stage and not ready for production use just yet. Please try it out, give feedback, and help fix bugs.（Prepackはまだ初期開発段階なので、プロダクションで使う状態にはなっていない。試してみて、フィードバックをください。そして不具合を修正するのに役立たせてください。）”と書かれているように、まだお試し期間なのでプロジェクトへ導入ができる段階にはなっていません。
今回は、類似機能を持つ、Google社が開発しているJavaScript最適化ツール、Closure Compilerと比較をする発表内容となっています。
公式サイトに掲載されているサンプルコードを実際に試し、オプティマイズされる様子を確認していきました。
最初に簡単なサンプルを試してみました。
Closure Compiler の場合、1行で演算済みのものが出てきます。文字列の結合や数値計算などは事前に行われるので、この場合、Prepackも同様に1行となります。
しかし、ビルドの速度とファイルサイズを比較すると、Prepackの特徴の通り、Prepackの方がビルドが速く、ファイルサイズも小さい結果となりました。
次に、もう少し難しいサンプルについて、Closure Compilerでオプティマイズすると、関数名が短くなるくらいで、あまり変わらなかったのですが、Prepackでは演算したものが表示され、短くすっきりしたソースコードとなりました。
そのため、Prepackの方がファイルサイズも圧倒的に小さく、ビルド速度も速い結果となりました。
続いて、フィボナッチ数を計算するプログラムについてです。両者ともロジックはあまり変わらないですが、Prepackはコンパイル時に演算してしまうので、計算結果のみといったアウトプットになりました。
しかし、手元で計算できるコードが多ければ多いほど、ビルド速度は遅くなるようでした。ファイルサイズは、やはりPrepackの方が小さい結果となりました。
また最後に、実務で使っているJSファイルを使って実験した様子が紹介されました。その過程で「Image APIを使うとビルドが通らない」という不具合に遭遇したようです。
所感として、「Closure Compilerに比べて容易に導入できる」、「ビルド速度が速い」といったことが挙げられました。
上記で述べられている通り、初期開発段階のツールの場合、リファレンスも少なく、どんな場面で活躍するのかも不明確な場合が多いですが、Prepackを使った世界中の開発者がフィードバックをし、改善を重ね、より良いツールになっていくことを期待しています。
3. 循環的複雑度を測定しよう！ (AJA 森)
最後に、株式会社AJAの森が循環的複雑度に関しての発表を行いました。
循環的複雑度(Cyclomatic complexity)とは、関数やメソッドの複雑度がどの程度なのかを数値化したものであり、数値が大きいほど複雑なコードということになります。
グラフの終点ノードと始点ノードを結んだとき、循環的複雑度 M は、
M = E − N + P
E ： グラフのエッジ数
N ： グラフのノード数
P ： 連結成分
と定義されます。
概念としては、循環的複雑度はソースコード内の線形独立な経路の数となります。
ifやforのような分岐点の無いソースコードの場合はそのコードには経路は1つしか無いので、その複雑度は1となり、コードに1つのif文が含まれていれば、コードには経路が2つ含まれることになるので、その場合の複雑度は2となります。
発表の中では、実際にgocycloというgolang用の循環複雑度を測定できるライブラリを利用し、測定してみた結果の共有やGoogle社が採用している「バグ予測アルゴリズム」の紹介などがありました。
このバグ予測アルゴリズムは、「バグ修正が頻繁に行われているファイルは危ない」という考えのもと、gitのコミットログから該当ファイルへのバグ修正コミットが何回行われたかというデータをもとにスコアをランキングします。
“fixes” や “closed” といったキーワードを含むコミットログがあるかどうかが、バグかどうかの判断基準となります。
このアルゴリズムを実装したオープンソースのツールである bugspots を導入してみた結果と循環的複雑度を比較したところ、考察として、両者には相関関係がありそうということが挙げられました。
まとめとしても述べられていましたが、このように数値化されると曖昧だった部分が明確化され、リファクタリングの優先度決めや工数を見積もる際に役立つと思います。
また、個人やチームの主観的な考えだけで確認や判断をするのではなく、このようなツールなども使うことにより、多角的なアプローチで品質向上を目指していければと思いました。
以上、LT Thursday Vol.21のレポートでした。
MDHの最新情報はAmeba Ownd, Facebook, Twitterに随時更新されますので、ぜひフォローいただければと思います。
最後までお読みいただき、ありがとうございました。
それでは、次回もお楽しみに！
Profile:
株式会社サイバーエージェント
Ameba統括本部 広告部門 動画開発局
塩島佐代子
▼メディア広告部門(MDH)
Ameba Ownd：https://ameba-ad-pr.amebaownd.com/
Facebook：https://www.facebook.com/AmebaAds.CyberAgent/
Twitter：https://twitter.com/amebaads_pr