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

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

タグ:nodered

このフローは以前に少し違う形で業務やイベントのネタ(の裏側)として使っていたことがあったのですが、埋もれてしまうのはもったいない気がしたので公開しちゃいます。

Node-REDFX (外国為替)情報を取得するフローを作りました。FX というのは例えば USDJPY だと USD と JPY 、つまり米ドルと日本円の関係です。「1ドル=107円23銭」みたいなやつですね。これの EURUSD (ユーロドル)やら EURJPY (ユーロ円)やら AUDJPY (豪ドル円)やら、、主に日本円が絡む通貨ペアを中心に 20 ペアの情報を1分おきにリアルタイムで取得するものです。

フローはこちらで公開しています:
https://flows.nodered.org/flow/9d045f691b6d7c5cb3259c197ad365d0

2020060105



このページ内のフロー定義を "Copy" して、Node-RED 環境に「クリップボードから読み込み」するだけでフローが再現できます。フロー1本だけの、それも標準ノードの組み合わせだけで構成されているシンプルな内容です。動く条件は「Node-RED 環境がインターネットに接続されていること」だけでいけると思います:
2020060101


↓ペースト後、こんなフローのタブが作られていれば成功:
2020060102


あとはこのまま「デプロイ」すれば1分おきに inject ノードが動き出し、取得した FX 情報を debug タブに出力し続けます:
2020060103


1回実行した時の debug タブの様子はこんな感じです。_id に実行時の日付時刻が入り、あとは通貨ペアとその瞬間の価格がまとめて出力されます:
2020060100



公開しているフローではこれだけ(debug タブに出力するだけ)ですが、IBM Cloud 内の Node-RED として動いている環境であれば、バインド済みの Cloudant out ノードをフローの最後に追加して、DB 名を指定するだけで出力される情報を1つのレコードとして DB に格納する所まで簡単に実現できます。他の環境でも各種データベースノードに渡すことで取得データの DB 格納ができます:
2020060104


中身は inject node が一分ごとに発火してオープンな API を使って FX 相場を取得し、(Cloudant DB に格納する前提での)JSON フォーマットに変換して debug ノードに渡す、というものです。FX は24時間相場が動くので、1日に 60 * 24 = 1440 データ集まります。(データ量に気をつけながら)1ヶ月程度動かしっぱなしにしておくとそこそこの為替情報データベースができあがります。シンプルですが API やフォーマットを変えることで応用範囲が広くなりそうだと思っています。

本来は集まったデータをグラフ表示したり、上下動の予測をしたり、、、といった使いみちになると思っています。サンプルではない実データを簡単に集めることができるので、説得力のあるデモアプリに応用しやすいと思っています。興味ある方は使ってみてください。


このブログは 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 の HTTP ノード(HTTP in ノードと HTTP Response ノード)を使うと簡単に REST API を作ることができて便利です。自分もデータベースへの CRUD 操作を作る際などによく使っています。

が、この方法で作った REST API にはクロスオリジン制約(いわゆる CORS)が付きます。例えば https://xxxx.mybluemix.net/ というホストで Node-RED を動かしている場合、作成する REST API のエンドポイント URL は https://xxxx.mybluemix.net/getdata とかになるわけですが、この API を AJAX などのブラウザ上の JavaScript から呼ぼうとすると、同一サーバー上の( https://xxxx.mybluemix.net/**** というアドレスのページの) HTML からでないとエラーになってしまうのでした。サーバーサイドのプログラムから実行することはできるのですが、ブラウザ上の JavaScript から実行するには同一ホストからでないといけない、という制約が付くのでした(ま、この制約自体はある方が一般的ですけど)。

この CORS の制約を外して、外部の(https://xxxx.mybluemix.net/ 以外の)ページやローカルシステム上ページの JavaScript からでもこの API を呼べるようにする、そのための設定方法と手順を紹介します。

まず Node-RED で REST API を作成します。今回は以下のような HTTP in ノードと、Function ノードと、HTTP Response ノードをつなげただけのシンプルな REST API を用意しました:
2018101801


HTTP in ノードの設定は以下のように GET /corstest で呼び出せるような設定にしています:
2018101802


Function ノードは以下のような JavaScript を記述し、実行時のタイムスタンプ値を JSON で返す、という関数にしています:
msg.payload = { timestamp: ( new Date() ).getTime() };
return msg;

2018101803


HTTP Response ノードにはこの段階では特に手を加えません。配置しただけの状態のまま接続してデプロイします。これで REST API 側は準備できました。

次に HTML ファイルを用意します。今回はサーバー上ではなくローカルシステム上に以下のような内容の HTML ファイルを用意しました:
<html>
<head>
<meta charset="utf8"/>
<title>CORS テスト</title>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
<script>
function corstest(){
  $.ajax({
    type: 'GET',
    url: 'http://xxxx.mybluemix.net/corstest',  // 上記で作った REST API のエンドポイントURL
    success: function( result ){
      console.log( result );
    },
    error: function( err ){
      console.log( "error" );
      console.log( err );
    }
  });
}
</script>
</head>
<body>
<input type="button" value="CORS" onClick="corstest()"/>
</body>
</html>

この HTML ファイルをブラウザから(Ctrl+O などでファイルを指定して)開くと、"CORS" と書かれたボタンが1つだけ配置されたページが開きます:
2018101807


HTML を見るとわかるのですが、このボタンをクリックすると GET https://xxxx.mybluemix.net/corstest という API が実行され、成功するとその結果が、失敗すると "error" というメッセージに続いてエラーメッセージが、それぞれ表示される内容になっています。なおこのエンドポイント URL の xxxx 部分が実際に作成した Node-RED 環境のホスト名にあわせて変更してください。


ブラウザのコンソールを開いて(F12)、この CORS ボタンをクリックします。現状は CORS の対策を何もしていないので当然のようにエラーになります。エラーの内容はコンソールに表示され、原因はクロスオリジン制約のようです。これをどうにかしたい、というのが今回のテーマです:
2018101804


では、この REST API の実行が成功するよう API 側をカスタマイズします。Node-RED のフロー画面に戻って、HTTP Response ノードをダブルクリックして編集状態にします。そして「ヘッダ」と書かれた欄の「+追加」という部分をクリックし、HTTP Response ヘッダを追加します。そして左側(ヘッダ名)の欄には Access-Control-Allow-Origin と、そして右側(ヘッダ値)の欄には *(どのドメインからのリクエストでも許可するの意)とそれぞれ入力し、最後に「完了」→「デプロイ」します:
2018101805


この設定によって REST API の実行結果を返す際のヘッダに Access-Control-Allow-Origin: * という一行が追加されて返るようになり、このヘッダによってクロスオリジンが許可されているとブラウザ側からも判断され、期待通りの結果が得られるようになります。再度 CORS ボタンをクリックして REST API を実行するとコンソールにはリクエストが成功した時の結果が表示されるようになりました:
2018101806


CORS の制約を理解した上で外す(あるいは特定のドメイン名やホスト名を指定した上で許可する)、という点に注意してください。





Node-RED を使うことで IoT データの収集や Web API の実装などが非常に簡単に実現できます。このブログでも何度か紹介していますし、公開されている外部モジュールを使って更にカスタム機能を追加することも可能です。

今回紹介するのは HTTP in ノードに認証機能を追加する node-red-contrib-httpauth ノードです。これを使うと Node-RED に標準装備されている HTTP in ノード(HTTP リクエストノード)に Basic 認証や Digest 認証を簡単に追加することができるようになります:
2018082900


実際に使う場合は、Node-RED の画面右上のメニューから「パレットの管理(Manage Pallette)」を選びます:
2018082901


設定ダイアログが表示されたら、"Palette" の "Install" タブで "httpauth" と検索します。すると node-red-contrib-httpauth ノードが見つかるので、"install" ボタンをクリックしてノードを追加します:
2018082902


インストールが成功すると以下のような表示になります。ここから実際にノードが使えるようになります:
2018082903


この時点でパレットにも "http auth" というノードが追加されていることが確認できます:
2018082904


実際に使う場合、http in ノードの直後に http auth ノードを配置します。この例では http in ノードの直後に http auth ノードを配置し、その後ろに(いつも使っているような)template ノードや function ノードを配置して、最後に http response ノードで HTTP リクエスト可能な API を作りました:
2018082905


template ノードの中身はシンプルにしています(認証が成功するとこの文字列が表示される、というテストです):
2018082906


そして http auth ノードに認証内容を設定します。この例では Basic 認証でレルム文字列は MyRealm 、そしてユーザー名 : user1 &パスワード : pass1 を設定しました。この状態でデプロイします:
2018082907


デプロイ後にウェブブラウザでこの API にアクセスすると、先程設定した http auth が機能し、指定した内容の認証が行われます。具体的にはユーザー名とパスワードを問い合わせるダイアログが表示され、先程指定した内容が入力されないと先へ進めません:
2018082908


上記で設定した内容(ユーザー名 : user1、パスワード : pass1)が正しく入力されると HTTP リクエストが正しく実行され、設定していた文字列が表示されます:
2018082909


この http auth ノードを使うことで、Node-RED で作成する API や Web ページに簡単に Basic 認証をかけることができそうです。


 

このページのトップヘ