まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:nodered

このブログは Node-RED Advent Calendar 2019 に参加しています。12/22 ぶんとしてエントリーしています。


今年 2019 年に新たな試みとして挑戦したことの1つに「ボランティアで IT 勉強会を開催する」がありました。それまでにも社内外の技術者向けコミュニティで講演したり、参加した先のイベント内でゲリラ的に活動するなどは行っていました。ただ前提として IT 技術者を対象としていたり、そういった知識を持った人を対象とすることがほとんどでした。一方で IT や AI 、プログラミングが少しずつ世の中で広まっている実感もあって、そんな乖離について疑問とまでは言いませんが、より多くの人に広める活動はできないだろうか、と考えることはありました。そんな中で女性向けコミュニティや、以下で紹介する子供向け勉強会を開催させていただく機会がありました。その活動についての報告を兼ねてブログにまとめてみました。


【IT勉強会について】
この手の IT 勉強会を開催する上で会場の確保は1つの壁になります。加えてパソコンそのものは持ってきてもらうとして、その電源やプロジェクターの確保、無線 LAN の有無、机や椅子の用意、そして会場を借りる上でのコスト、加えて集客方法や会場を利用する上での制約事項等を総合的に考慮する必要があります。以下で紹介する勉強会では 2016 年に千葉県市川市にできたシェアスペース「にわにわ」をお借りして開催しました:
2019121001


簡単に説明すると無線 LAN や電源の利用可能なレンタルスペースです。トップページを見ていただくとわかるのですが、普段から地域コミュニケーションを中心とした(IT に限らない)活動をされていて、親子向けワークショップも多く開催されています(画像はトップページより)。価格も非常にリーズナブル!:
800


この会場をお借りし、今年は5月に開催したのを皮切りに計5回のIT勉強会を行いました。「IT勉強会」と銘打ってますが、基本的には IBM Cloud を使った勉強会という位置づけで、IBM Cloud コミュニティのメンバーにお手伝いをいただいています。なお(*)印がついているものは Node-RED を使ったハンズオンです:
日付タイトル内容
5/19【子連れも】BMXUG市川IT勉強会「LINEでお絵描きメッセージを送ってみよう♪」【学生も歓迎】LINE LIFF を使ったお絵描きスタンプを作る
7/13【こどもも】BMXUG市川IT勉強会「テトリスを作ってスマホで振って遊ぼう!」【おとなも】(*)IBM Watson IoT サービスを使ってゲームをリモートコントロール
8/24【こどもも】BMXUG市川IT勉強会 AI先生と外国語で会話しよう!【おとなも】IBM Watson Translator, Speech to Text, Text to Speech を使って外国語会話レッスンアプリを作る
10/19BMXUG市川IT勉強会「レースゲームを作って、鈴鹿サーキットを走ってみよう!」(*)OpenStreetMap と IBM Watson IoT サービスを使った地図ゲーム、二人協力プレイ可
12/7BMXUG 市川IT勉強会番外編 【おとなも】『スクラッチ』でゲームを作ろう!【こどもも】スクラッチを使ったおにごっこゲーム開発(コピペ一切なし)


つまり今年は5回の勉強会を開催して、そのうち2回で Node-RED を使いました。また全てのタイトルに【おとなも】【こどもも】と含まれているように、対象者の前提は設けていません。もともとこの会場で行われるイベントは両親がお子さんと一緒に参加されたり、お年寄りの方が参加されたりすることが多かったこともあって、その一環で参加していただけたら・・という思いもありました。結果的に「普段キーボード入力を使う機会が少ない(コピペして、すらそのままでは通じない)」ようなお子さんや大人の方に多く参加いただけたと思っています。この点では当初の目的がある程度達成できたと感じています。


なお勉強会ではないのですが、7/13 開催の内容については 7/18 に開催された Node-RED Con Tokyo 2019 の中でもレポートする形で紹介しています:
IBM Watson IoT を用いた遠隔ゲームコントローラーと Node-RED による簡易カスタマイズによる実現(*)


※個人的にはこれら以外でも IT 関連のボランティア活動は行っていましたが、このブログでは上記イベントに限ったレポートとさせていただきます。


【勉強会で大変だったこと】
大変だったこと、というか大変なこと。結論を最初に言うと「時間との戦い」です。

参加者は「お子さんと、その親」が大半でした。ここでの「お子さん」とは、下は小学校低学年から、上は高校生がいたかなあ・・・中学生はいました、といった感じ。おそらくスマホは僕以上に使いこなせるのでしょうが、PC を普段から使っているわけではありません。ブラインドタッチなど以ての外、「コピペ」が「Ctrl+C して Ctrl+V」と理解できるわけでもありません。「選んで、右クリックして、コピーして、・・・」と教える必要があるレベルです。PC 操作には普段の勉強会やハンズオンとは比較にならないほどの時間を要します。

加えて、全ての勉強会がハンズオン形式となっていて最終的にアプリを1つ作りあげる(!)のですが、だいたい2時間弱で作れるものを用意する必要があります。時間をかければ細かい説明もできるし、作ったものを自分の好みに合わせて改良できたりもするんですが、一方で時間が長くなって「途中で飽きられちゃう」と勉強会としては致命傷です。もうPCの前に戻ってきてくれなくなります(苦笑)。コツとしては最初にアプリのデモを見せて(つまり完成形を見せて)、ある程度興味を持ってもらって、「頑張ればあのゲームができる!」と思わせて(笑)、なんとか集中力を2時間キープしてもらう、加えて神様に祈るw! そして目的のアプリを最短コースで作り上げる!! という持久走のような2時間になります(あ、でも苦痛ではなく楽しいですw)。

勉強会で扱うハンズオンのコンテンツはベースとなるものがあったりなかったりですが、ベースがあってもこの勉強会向けの改良を行っています。理由は「そのままでは理解できない」と思われる内容があったり、キーボード入力が多すぎて着いてこれないと思われたからです。基本プログラミングなので、プログラミングの入力は必要なのですが、その内容が多すぎると集中力が途切れてしまう懸念があります。かと言ってコピペのオンパレードだと「いま自分は何をコピペしてるのか」「そもそもこれはどの部分を作っているのか」がわからず惰性の作業になってしまう(要するに勉強会にならない)恐れもあります。一方で「ある程度プログラミングっぽいことが体験できるようにしたい」とか「苦労するから完成すると嬉しい」というユーザー体験的な観点からはやっぱりプログラミングが体験できるようにもしたくて・・・ このあたりのバランスが非常に難しいのでした。実際、今も改良を続けながらコンテンツを準備しています。

コンテンツのアイデア出しやコンテンツ作りにも時間は必要だし、2時間で一通りの解説と動作確認ができるように仕上げないといけないし、毎回が色んな意味で時間との戦いになっています。


【Node-RED を使った感想】
上述のように、5回の勉強会のうち2回で Node-RED を使ったハンズオン開発を行いました。ちなみに他の2回は Node.js (のコードを github からコピーして使用)、1回は Scratch を使いました。また Node-RED を使う場合も HTML ページを記述するテンプレートノードの内容についてだけは(時間の都合もあって)コピー&ペーストで逃げました。今にして思えば Node.js の2回は Node-RED で作れるようにしておけばよかったと感じています。

プログラミング教育のハンズオンで Node-RED を使う場合のメリットは、なんといっても「少しずつ作りながら&動かしながら進めていける」ことだと思っています。ノードの説明をして、それらを組み合わせて1つのフローを作っては、作ったフローを実際に動かして動作を確認する、これを繰り返すことで機能単位で少しずつ動作を確認しながら作ろうとしているものが完成体に近づいていく様子を体験できるようになります。この「少しずつ完成に近づいていく」のがプログラミングの醍醐味であり、楽しい部分でもあると思っています。

また Node.js を使う場合と比較すると、「コマンドプロンプトやターミナルからコマンドを実行する」に相当する作業がなく、開発作業に集中できるという点も大きなメリットであると感じています。プログラミングといいつつ、最終的にサーバー上で動かすため各種 Linux コマンドを使わずに進めていくのは困難なのですが、Node-RED だとそのあたりはよく作られていて Node-RED の画面内だけでアプリを開発し、サーバー上にデプロイすることまでができます。Windows / Mac の環境依存になる部分も少ないため、教える側としては非常に楽になる、といった、副作用的な効果もありました。特に今回のように教わる側の知識があまり高くない場合では大きなメリットのあるハンズオン環境といえると思います。

似たような GUI プログラミング環境として Scratch もあります。こちらははじめからウェブサービスとして提供されている点と、画面を確認しながら作れるという点で視覚的に非常にわかりやすい環境といえます。一方で外部とのデータやりとりについてはどうしても弱い点があるようにも思えます(逆にそういうやりとりが必要なければ気にすることもないと思ってます)。この外部とのデータのやりとりについては Node-RED が得意としている分野でもあるので、このあたりが今後の使い分けの基準にもなっていくんだろうなあ、と感じています。


【今後の話】
今年の5回の勉強会を経て、比較的 IT 知識のない人(普段、ワードやエクセルさえ使う機会のないレベルの人)向けの学習環境としての Node-RED の優位性を改めて感じることができました。一応、この活動は来年以降も続けるつもりでいて、2月初旬に予定している年明け一回目のコンテンツでも使う想定をしています。

ただし、来年は「Node-RED を使う前提でコンテンツを考える」のではなく、「参加者が興味を持ちそうな(エンターテイメント性のある)コンテンツを作って」&「それを Node-RED で実現できるように改良する」という準備をしていこうと思っています。ぶっちゃけ手間がかかるといえばかかるのですが、この準備自体が自分の勉強にもなるし、そういうことが実現できる Node-RED のポテンシャルの高さを証明することにもなるのではないか、と思っています。



1つの Node-RED 環境に普通に複数人がアクセスすると同じ環境を使うことになります。これを複数人で、それぞれ個人ごとの環境で(個人ごとにフローを保存したりして)使う方法です。

Node-RED をインストールした後、通常だと以下のような node-red コマンドで Node-RED を起動します(青字は起動メッセージ)。この例だと 1880 番ポートで待ち受け状態になっています:
$ node-red

13 Feb 08:55:02 - [info]

Welcome to Node-RED
===================

13 Feb 08:55:02 - [info] Node-RED バージョン: v0.19.5
13 Feb 08:55:02 - [info] Node.js  バージョン: v6.11.2
13 Feb 08:55:02 - [info] Linux 4.4.0-121-generic x64 LE
13 Feb 08:55:03 - [info] パレットノードのロード
    :
    :
13 Feb 08:55:03 - [info] フローを開始します
13 Feb 08:55:03 - [info] フローを開始しました
13 Feb 08:55:03 - [info] サーバは http://127.0.0.1:1880/ で実行中です

この node-red コマンドにパラメータを渡して実行環境をカスタマイズすることができます。例えば以下のような settings1.js ファイルを用意します(実行ポート番号を 1881 に指定しています):
module.exports = {
  uiPort: 1881
}

更に自分のフローを保存するためのフォルダ(~/tmp/userDir1)を作っておきます:
$ mkdir -p ~/tmp/userDir1

この状態から以下のようにパラメータを指定して node-red を実行します(青字は起動メッセージ):
$ node-red -s settings1.js -u ~/tmp/userDir1

13 Feb 09:04:35 - [info]

Welcome to Node-RED
===================

13 Feb 09:04:35 - [info] Node-RED バージョン: v0.19.5
13 Feb 09:04:35 - [info] Node.js  バージョン: v6.11.2
13 Feb 09:04:35 - [info] Linux 4.4.0-121-generic x64 LE
13 Feb 09:04:35 - [info] パレットノードのロード
    :
    :
13 Feb 09:04:36 - [info] サーバは http://127.0.0.1:1881/ で実行中です
13 Feb 09:04:36 - [info] フローを開始します
13 Feb 09:04:36 - [info] フローを開始しました

今回は 1881 番ポートで Node-RED が起動しています。またここで記録したフローは ~/tmp/userDir1 内に保存されます:
2019021301


同様にして settings2.js ファイルと ~/tmp/userDir2 フォルダを作り、これらをパラメータ指定して起動すると、異なるポートで異なる記録フォルダを持つ Node-RED が(もう1つ)起動できます:
$ cat settings2.js
module.exports = {
  uiPort: 1882
}

$ mkdir -p ~/tmp/userDir2

$ node-red -s settings2.js -u userDir2
13 Feb 09:11:15 - [info]

Welcome to Node-RED
===================

13 Feb 09:11:15 - [info] Node-RED バージョン: v0.19.5
13 Feb 09:11:15 - [info] Node.js  バージョン: v6.11.2
13 Feb 09:11:15 - [info] Linux 4.4.0-121-generic x64 LE
13 Feb 09:11:15 - [info] パレットノードのロード
    :
    :
13 Feb 09:11:16 - [info] フローを開始します
13 Feb 09:11:16 - [info] フローを開始しました
13 Feb 09:11:16 - [info] サーバは http://127.0.0.1:1882/ で実行中です


フローの記録フォルダも別々に指定しているので、一方でフローを作成済みであっても他方には影響しません:
2019021302


同様にして3人以上で利用する場合もそれぞれの settingsXX.js とフロー用フォルダを作成し、それらを指定して起動することで複数人が別環境の Node-RED を使うような感じで1サーバー内の Node-RED を使うことができるようになります。まあ充分なディスクとメモリ、CPU があれば、という前提ですけど。


Node-RED の設定ファイルでカスタマイズできる内容と指定方法についてはこちらを参照ください:
https://nodered.jp/docs/configuration

なお、今回のように起動ポートとフロー保存フォルダを指定するだけであれば、settingsXX.js ファイルを用意する必要はなく、Node-RED 起動時のコマンドラインから以下のように(-p で起動ポートも)指定することができます。ただカスタマイズの範囲をどこまでにするかによっては設定ファイルを用意した方が便利だとは思っています:
$ node-red -p 1881 -u ~/tmp/userDir1






Node-RED は GUI で便利にデータの流れを定義することができるビジュアルデータフローエディタです。HTTP(S) や MQTT など多くのプロトコルにも対応しており、これまでプログラミングを記述しないと実現できなかったようなデータの流れを、個別の機能を持ったノードを組み合わせることで、ほぼコーディングレスで実現できるという点が画期的なツールです。このブログでも何度か紹介してきました。

(このエントリで紹介した時のデータフロー。これだけでデータベース入出力を行うウェブアプリケーションを作ってます)
2018031301


さてそんな簡単で便利な Node-RED ですが、「Node-RED だと(一般的なプログラミングと比較して)処理が複雑になるケース」もあります。こういう視点で語られているドキュメントを目にすること-がなかったこともありますが、Node-RED がより多くの現場で使われていく上での適材適所を考える上では必要になってくると思っていることもあり、そんな例を紹介しようと思いました。

今回、Node-RED と比較するプログラミング環境はサーバーサイド JavaScript である Node.js とします。もともと Node-RED 自体が Node.js 上で動くアプリケーションであり、Node-RED の function ノード内では JavaScript を直接記述することもできるという点で、比較対象としては相応しいのではないかと思っています。

で、この「Node-RED での処理が複雑になるケース」の典型例の1つが if 分岐処理だと自分の拙い経験上で思っています。if 分岐はプログラミング言語を学ぶ中でのかなり早い段階で遭遇することになる基本的な処理ですが、Node-RED では必ずしも基本的とは言えない内容だと感じています。

例を挙げて説明します。例えばこんな処理を行うケース:
・気温(temp)と湿度(humid)という2つの変数値から「不快」か「不快ではない」かを判断する。
・気温が 30 以上で、かつ humid が 50 以上だと不快
・気温が 30 未満で、かつ humid が 80 以上だと不快
・それ以外は不快ではない

よくあるレベルのシンプルな分岐処理ですよね(湿度は%単位で与えられるものとします)。この処理を Node.js (や他の一般的なプログラミング言語)の if 分岐で行おうとすると、こんなシンプルな感じになると思います:
if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

では同じ処理を Node-RED で実現しようとするとどうなるでしょうか?仮に msg.payload.temp と msg.payload.humid にそれぞれ温度と湿度の値が入っているという前提で作ることを考えてみます。

Node-RED で条件分岐を行うノードは "switch" ノードです。機能カテゴリ内にある switch ノードをキャンバスにドラッグ&ドロップします:
2018031302


ドロップした switch ノードをダブルクリックして、処理内容を設定する画面に切り替えます:
2018031303


このノードでは温度(msg.payload.temp)に関する条件分岐を行うことにします。今回は30度以上か、30度未満かで処理を分岐する必要があります。というわけで、プロパティの値を (msg.)payload.temp にして、その条件を指定する部分では「30以上の数値」となるように指定します。またノードの表示用の名前を「温度」と設定します:
2018031304


今回の処理では温度が「30 以上の場合」と「30 未満の場合」の2つの条件に分岐する必要があります。前者は上記で指定したので後者を追加します。この画面内の「追加」ボタンをクリックします:
2018031305


すると条件部分が1行追加され、もう1つの条件を指定できるようになりました。ここでは「 30 未満の数値」となるような条件を指定します(下図のようにするか、または後述のように"otherwise"(その他)という選択肢でも同じ結果になります)。 これで msg.payload.temp の値が 30 以上であれば1へ、30 未満であれば 2 へ行く、という分岐処理が定義できたことになります。ここまでできていることを確認して「完了」ボタンをクリック:
2018031306


すると switch ノードに指定した名前が表示されるのと同時に、ノード右側の出口が2つに増えていることが分かります。上側の接続子が1、下側の接続子が2を意味しており、ここから条件を分岐して処理できるようになりました:
2018031307



続けて湿度の条件を追加します。温度 switch ノードの①に別の switch ノードを追加して接続します:
2018031308


追加した switch ノードをダブルクリックして編集ダイアログを出し、以下のように設定します。 名前は「湿度」、プロパティは湿度の値である (msg.)payload.humid 、ここは温度が 30 度以上の場合に処理されるノードなので、分岐の条件は「 50 以上の数値」か「otherwise(それ以外)」として、最後に「完了」をクリックします:
2018031309


この時点でキャンバス上は以下のような2つのノードが設定されているはずです。③は温度が30度以上で、湿度は50以上なので「不快」、④は温度は30度以上ですが、湿度は50未満なので「不快ではない」という分岐がされたことになります:
2018031310


では続けて②のノードの続きの処理を追加します。更にもう1つの switch ノードをキャンバスに追加し、温度 switch ノードの②と接続します。そしてノードの設定内容を以下のようにします。先程の湿度ノードに近い内容ですが、このノードは温度が 30 度未満の場合に処理されるので、湿度が 80 以上だった場合に不快、それ以外であれば不快ではないと分岐するノードにしています:
2018031301


ここまでの作業でキャンバスには以下のように3つの switch ノードが用意されているはずです。そして③と⑤が不快、④と⑥が不快ではない場合の処理を行う流れになります:
2018031302


後はこの分岐した条件にあわせて処理を繋げていけばよいので、例えばこんなフローになっていくんでしょうかね:
2018031303


というわけで、目的の条件分岐を Node-RED で実現することはできました。 ただ Node.js では以下のような超シンプルな分岐処理だった割にはフローが複雑になってしまっている面は否めません。これが更に複雑な分岐処理だった場合、Node-RED ではどれだけ switch ノードを並べないと行けなくなるのか・・・:
if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

原因というわけではないのですが、Node-RED の switch ノードは単一のプロパティに対する条件分岐しか行えないため、複数の値を元に条件を分岐するようなケースではどうしてもノードを多用する必要が出てきてしまいます。この部分だけを切り取って結論にはできないと思いますが、Node-RED では if 文による分岐処理は必ずしも簡単ではないということだと思います。



タイトル通りですが、「『じゃじゃじゃじゃーん』をリズムに変換する Node-RED 用ノード」を作ってみました。


ほとんどの人はこの時点でどんな処理をするノードか理解ができてないと思うので、その補足です。このノードを作るきっかけになったのはこちらのまとめサイトでした:
【超能力者】知恵袋「何の曲か分かりますか?てんてててん てんてんてて」→「戦場のメリークリスマスですね」「なんで分かるんだ!?」


要するに「じゃじゃじゃじゃーん」という日本語テキスト(音階なし、正確なリズムもわからない)だけを頼りに「交響曲第5番、『運命』」のように曲を探し出すという(超)能力を持った人がいて、こりゃすげー!と。

なるほど、面白そうだ。最終的にはこれと同じことをシステム化できないかなあ、と考えているわけですが、その開発の途中で「とりあえずは日本語テキストからリズムを取り出す」仕組みを作り、そこから少々脱線して「その仕組を Node-RED のノードにしてみた」のが今回紹介するノード: node-red-contrib-dotnsf-jajajajan です:
https://www.npmjs.com/package/node-red-contrib-dotnsf-jajajajan

2017092300


利用するにはまず Node-RED 環境を(ローカルでも IBM Bluemix でも)用意し、そこからこのノードを導入します。ローカルであれば以下のコマンドでインストールできます:
$ npm install node-red-contrib-dotnsf-jajajajan

IBM Bluemix の Node-RED の場合はメニューからパレット管理機能を使ってインストールします:
2017101401


パレットの管理画面において「ノードを追加」タブを選び、検索文字列に "jajaja" などと入力すると見つかります(私のミスで複数バージョンが登録されてしまいました。最新バージョンのものを指定して「ノードを追加」してください):
2017101402


この状態で Node-RED を起動すると機能カテゴリ内に音符アイコンの "jajajajan" というノードが追加されて、キャンバス上で使えるようになります:
2017092301


このノードの挙動を確認するために以下のようなシンプルなフローを作ってみます。入力カテゴリの inject ノードと、出力カテゴリの debug ノード、そしてこの jajajajan ノードを配置し、以下のように配線します:
2017092302


inject ノードをダブルクリックして、Payload の種類をデフォルトの timestamp から string に変更し、その値を上記で示したような日本語のリズムテキストにします。以下の例ではまさに『運命』の有名な部分である「じゃじゃじゃじゃーん、ララララーン」としています(「じゃ」でも「ラ」でも同じように処理することができることを確認するため、わざと別の表現にしています)。ここで指定したテキストが msg.payload として jajajajan ノードに渡されて処理されます。入力し終わったら「終了」ボタン:
2017092303


これでフローの準備はできました。動作を確認するため「デプロイ」します:
2017092304


デプロイできたら、画面右ペインを "debug" タブに切り替えたことを確認してから、inject ノードの左にあるボタン部分をクリックします。クリックしたタイミングで指定したテキスト(今回の例では「じゃじゃじゃじゃーん、ララララーン」)が msg.payload として jajajajan ノードに渡されます。
2017092305


クリックすると、不定のタイミングで debug タブに文字が表示されてゆくことが確認できます。このタイミングに関してはネットワーク依存があることと、Node.js 上で動く Node-RED が非同期処理を行うことから必ずしも厳密なタイミングではないのですが、なんとなく「じゃ」「じゃ」「じゃ」「じゃーん」「ラ」「ラ」「ラ」「ラーン」のリズムで1行ずつ表示されている(はず)です:
2017092306


出力されている内容を詳しく見てみると、"8" とか "2" とか数字が表示されています。実はこれは音符の長さを表していて、"8" は「8分音符」、"2" は「半音符(2分音符)」を意味して、その長さに合わせて debug 出力も制御されています。現在の仕様では "8" では 0.5 秒後、"2" では 2 秒後に次の音符が表示されるようにしています(なので "8" の次はすぐに表示されますが、"2" の次が表示されるまでには少し時間がかかります)。結果的になんとなく「じゃ」「じゃ」「じゃ」「じゃーん」「ラ」「ラ」「ラ」「ラーン」というリズムに合わせて1行ずつ表示されているように見える・・・のではないかと思っています(苦笑):
2017092307


試しに『メヌエット』の出だし部分である「タンタタタタタンタンタン」で試すとこんな感じです。最初の「タン」が4分音符で、そこから8分音符が4回続いて・・・というリズムで解釈されていることがわかります:
2017092308


と、またこんなくっだらないノードを作ってしまった。。どうしても使ってみたいという変わった人がいたら使ってください。ちなみにソースコードはこちらです(日本語処理の部分はかなりハードコードに依存しているので、他の言語用に移植するのが難しいかも・・):
https://github.com/dotnsf/node-red-contrib-dotnsf-jajajajan


脱線した話を元に戻すと、このノードで実現している仕組みを使ってテキストをリズムに変えて、取り出したリズムの情報をあらかじめ楽譜を元にリズムだけを取り出した楽曲のデータベースから曖昧検索して近いものを探す、という方法で冒頭で紹介したような超能力者みたいな仕組みをシステム化できないか、と考えています。こちらも諦めているわけではなく、ある程度は動くようになっている(楽譜そのものと、楽譜から主旋律を探す仕組みに苦戦している)ので、人前に出せるようになったら公開するかもしれません。まあ、そうそう簡単なものではないと分かっている上に自分が音楽や楽器が得意ではないので、まだ躓いてすらいない落とし穴が待っているかもしれませんが・・・

複数の楽器向けに書かれている楽譜から主旋律(というのかな?人間がよく知ってるパート)を探す方法を知っている人がいたら教えていただけるとうれしいです。

以前に CentOS 環境に StrongLoop LoopBack を導入する手順を紹介しました:

上記の手順ではまず Node.js を導入し、その Node.js 上に StrongLoop LoopBack を導入して OpenAPI 環境を構築していました。リンク先でも紹介されているように、この方法では LoopBack(Node.js) の起動をコマンドラインで行う必要がありました。つまりシステムが起動した後に明示的に LoopBack(Node.js) サーバーをアプリケーションとして起動する、という方法でした:
# cd myapp
# node .

今回の目的はこれをデーモン化することです。

LoopBack に限った話ではないのですが、Node.js アプリケーションをデーモン化する場合には forever というツールを使うことが多いです。forever は Node.js スクリプトの死活監視ツールで、 npm を使ってインストールします:
# npm install forever -g

forever で Node.js アプリをデーモン化して起動する場合は、forever コマンドの start オプションとして実行する JavaScript ファイルを指定します。LoopBack の場合はアプリケーションディレクトリ(上記例の場合は myapp)に package.json というファイルがあり、その中に以下のような記述があります:
{
  "name": "myapp",
  "version": "1.0.0",
  "main": "server/server.js",
  "scripts": {
    "start": "node .",
      :
      :

つまり LoopBack の場合は server/server.js が起動時に実行されていることがわかります。したがって forever を使って LoopBack アプリケーションを起動する場合はアプリケーションディレクトリからこのように server/server.js ファイルを指定すればよい、ということになります:
# cd myapp
# forever start server/server.js

これで LoopBack が実行されます。ウェブブラウザで http://(LoopBack アプリサーバー):3000/explorer にアクセスすると、Open API の API Reference にアクセスできることが確認できます:
2016061601


なお forever は start 以外にも以下の様なコマンドが用意されています:
コマンド目的
forever start (Node.js JavaScript ファイル)指定したアプリケーションの起動
forever list実行中のスクリプトの表示
forever stop (Node.js JavaScript ファイル)指定したアプリケーションの停止
forever stopall起動中の全アプリケーションの停止
forever restart (Node.js JavaScript ファイル)指定したアプリケーションの再起動
forever restartall起動中の全アプリケーションの再起動







 

このページのトップヘ