コーディング規約(Choreographe)【提案】

前書き

Choreographeを使った開発を行っている方々が、最近ボクの周りに多いのです。
Choreographe、というかNAO自体が研究目的に作られており、基本的に、自分で開発して自分で確認して成果を出していくスタイルです。
ただ、Pepperが先日1000台を一分で完売したことからわかるように、多くの企業さんがおそらく今後開発していくことに成るでしょう。
そうなってくると、一定のコーディング規約が必要になってくるかと思います。
一対一で開発していたものから、継続して開発していくものに変わるとなると、やはりみんなが読みやすい、見やすいプロジェクトを作るのは重要かと思います。

この記事では、Choreographeコーディング規約の提案をしたいと思います。
なので、こっちのほうがいいんじゃない？それはやめたら？などの話を、コメント欄を用いて進めていければと思っております。

導入

Choreographeを用いて開発を行ったことがある人ならわかるでしょうが、いくつかボックスをつなげていくだけで、すぐにスパゲッティプログラムになってしまいます。
そうなると、どのボックスが、何を行いたいのかを瞬時に把握することができなくなり開発効率を落とすこととなります。

自分で作ったものだけど、すでに見直すのが嫌だ。

最終目標

誰が見てもわかるプロジェクト作り。
今回、提案として、いくつかの極端な例を挙げる予定です。
なので、これとこれを組み合わせてやったら？みたいなものも必ず出てくるのはわかった上で作成していきます。

提案

僕からの提案として以下のものが挙げられます。

Dialogベースで作る

対話アプリケーションを用いた、トリガーセンテンスを使わないアプリケーション作り。
究極は、Dialogボックス一つですべての動作ができること。

Timelineベースで作る

こちらは、モーションを付けるというよりは、レイヤーを複数用意することによってアプリケーションの見通しを良くしようというものです。

イベントベースで作る

riseEventボックスを使って、イベントを発火させることで複雑に線が絡みあうことを防ぎます。

Pythonベースで作る

APIがドキュメントとして提供されてるんだから、全部Pythonボックスにぶち込めばいいんじゃない？といったものです。

Diagramベースで作る

Diagramボックスをつかって特定のボックス群を束ねることによって、スマートなアプリケーション開発が行えるはずです。

提案に対する検証

それぞれの項目に対して、実際に簡単なアプリケーションを作成して、見栄えの良さ、わかりやすさを検証したいと思います。

ベースとなるアプリケーションの想定

initializeを行うこと！

言語の設定や、ボリュームの設定、Pepperであればタブレットの初期化、などのinitializeを行う

終了処理を行うこと！

音量を変更していたら元の音量に戻す、言語を変更するような処理を挟んだら元に戻す、使用したメモリの開放等を行う、無理な姿勢を取らせないで終わらせること、などの終了処理を行う

メインとなる処理があること！

何かしらのアプリケーションを作るのですから、何かしらメインの処理があることが必要。

シンプルなアプリケーションであること！

Choreographeでアプリケーションを作成しているとスパゲッティプログラムとなることはよく有ります。
なので、そのようなプログラムになっていないこと。

サンプルアプリケーションをそれぞれ作る

Dialogベースで作る

BoxLibraryから、Dialogボックスを配置し、Outputをいくつか増やし、組み合わせてみた。
(今回は撮影のため、Boxをコピペしていますが、DialogBoxをコピペするのはやめましょう。Box自体がシングルトンで作成されているのか、あるボックスAから出力されるはずが、あるボックスCから出力されたり、安定した運用ができなくなります。そのランダム性を楽しめるゆとりがあれば良いですが、基本的には新規に作成したボックスを利用しましょう。)

Timelineベースで作る

今回は、Timelineを使いますが、モーションは作りません。
レイヤーベースで作成します。

今回は検証のため、上記のようなレイヤー構造にしました。
また、それぞれの中にLogボックスを置いて、どのように動くか、確認しました。

【initとmainレイヤー】
こちらは最後まで結線していません。

【finishレイヤー】
こちらは、finish,finish2ともに最後まで結線してあります。

この状態で実行するとログは以下のように出力されます。
長い部分は消しました。

[INFO ]  __root__Timeline_1__init__init__Log_1:     init
[INFO ]  __root__Timeline_1__main1__main1__Log_1:   main1
[INFO ]  __root__Timeline_1__main2__main2__Log_1:   main2
[INFO ]  __root__Timeline_1__main3__main3__Log_1:   main3
[INFO ]  __root__Timeline_1__finish__finish__Log_1: finish

finish2までいかなかったでござる。
finishの結線を消しました。
その後の実行結果がこちら。

[INFO ] __root__Timeline_1__init__init__Log_1:      init
[INFO ] __root__Timeline_1__main1__main1__Log_1:    main1
[INFO ] __root__Timeline_1__main2__main2__Log_1:    main2
[INFO ] __root__Timeline_1__main3__main3__Log_1:    main3
[INFO ] __root__Timeline_1__finish__finish__Log_1:  finish
[INFO ] __root__Timeline_1__main3__main33__Log_1:   main33
[INFO ] __root__Timeline_1__main2__main22__Log_1:   main22
[INFO ] __root__Timeline_1__main1__main11__Log_1:   main11
[INFO ] __root__Timeline_1__finish__finish2__Log_1: finish2

これらの結果から、基本的にレイヤーは上から順番に実行され、かつ、時間軸が早い順に実行されていくということがわかります。

レイヤーの中に新規にbehaviorが作成されるのかな？

イベントベースで作る

Raise Eventのボックスを使って、イベントを発火させて、つないでいく方法。

Pythonベースで作る

pythonボックスにpythonでガリガリ書いていくだけです。

サンプルアプリケーションを作るのがめんどくさかっただなんてそんなー
(実際めんどくさい。)

強いてあげるとしたら、結線しないボックスでも、"init"と"onLoad"はアプリケーション起動直後に読み込まれるので、そのあたりに、処理書き込んでもいいんじゃないかな。

Diagramベースで作る

既存のボックス群をDiagramで束ねて見やすさを確保する方法です。

見やすそう？

メリット・デメリット

サンプルアプリケーションを作成してみてのメリット・デメリットの列挙。

Dialogベースで作る

メリット

1. 対話アプリケーションと連携してアプリケーションを作ることができる。
2. コミュニケーションと作成済みモーション、イベントなどを一つのボックスでまとめて行うことができる
3. 一つのボックスで完結させることもできるため、当初の目的であるスパゲッティになりにくい。
4. 文章を書く流れで、モーションを載せたり、イベントを呼び出したりできる。

デメリット

1. 小回りのできるアプリケーションが作成できるようになるには、すこし勉強が必要となる。

Timelineベースで作る

メリット

1. レイヤー分けをしたことで、ひと目でどの順番に動作していくか見ることが出来て見やすい。
2. root直下はTimelineボックス一つだけで済ますことができる

デメリット

1. gotoボックスなどを利用してレイヤーやフレームの移動を行った場合、どこからどこに移動するのかわかりにくくなる可能性がある。

イベントベースで作る

メリット

1. 当初の目的であるスパゲッティプログラムとなりにくい。
2. APIを用いてsubscriptionすることによって、特定の条件下のみでのイベント監視が行えるようになる。

デメリット

1. イベントとして発火させるため、どこからどこに移動するのかわかりにくくなる可能性がある。

Pythonベースで作る

メリット

1. 公開されているAPIを用いて、pythonボックスのみのアプリケーションを作成することができる。
2. pythonのスキルをすべてぶつけることが出来、外部ライブラリなども利用できるため、開発の幅が広がりやすい。

デメリット

1. コーディングスキルがそのまま反映されるため、見やすくなるか、見難くなるかはその人次第。

Diagramベースで作る

メリット

1. 既存のボックスを組み合わせて束ねるだけなので、Choreographe触り始めや、python使ったことない人でも簡単に見やすいプロジェクトの作成が可能。
2. Diagramの命名だけ気をつければ比較的容易に見やすいプロジェクトの作成が可能。

デメリット

1. 多くのDiagramを利用すると階層構造が深くなるため、可読性を損なう可能性がある。

感想

今回、この記事では5つのテーマについて考察をしてきました。
それぞれのテーマごとに利点と欠点があるのでその辺りを注意しながら、活用してみたい。

この記事は【提案】なので、次は実践的に活用するためのことを考え記事を上げたいと思います。