プロのためのNode-RED再入門

Copyright © Software Research Associates, Inc. All Rights Reserved
株式会社ＳＲＡ
阪井誠
プロのためのNode-RED再入門

Copyright © Software Research Associates, Inc. All Rights Reserved 1
Visual 開発ツールNode-RED
• Node-RED*はVisual IoTツールと呼ばれ，Webブラウザ上の
エディタでプログラミングする
• 長円のプログラムモジュールをノードと呼び、標準ノードのほか、
コントリビュートされた多機能なノードが豊富にある
• ノードを中央の編集領域に配置し，ノード間を接続してフロー
（処理）を作成する
• ノードには名前を付加できるが，単に配置するだけでも設定に
応じた内容が表示される
* JS Foundation，Node-RED is a visual wiring tool for the Internet of Things，https://nodered.org/

Node-REDの長所・短所
長所：
• 非同期処理が簡単に扱える
• アルゴリズムが可視化される
• 多機能なノード（モジュール）
• デプロイが一瞬
• 再利用が容易
短所：
• 単体テストの自動化ができない
• 発展途上
• 方式設計が重要
• ループが特殊
• マージ・保守に工夫が必要

Node-REDを使いこなそう
• Visual IoTツール Node-REDの開発は、簡単に始
められ、だれでもある程度は使いこなせる
• しかし、Node-REDの導入には以下が重要*1
• ツールの知識やノウハウを共有すること
• 特性を活かした設計で品質を作りこむこと
• 実装を繰り返して常に確認すること
• 上流から利用すること
• Node-REDを使いこなすためのノウハウを説明し
ます
＊１：Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点，
http://sea.jp/ss2017/accepted_papers.html#3-9，SS2017 ， 2017．

目次
• 背景：Node-REDを使いこなそう
• 目次
• アンケートとその結果
• Node-REDの特徴と繰り返し開発
• 構造を設計・実装する
• テストの方法
• 上流から動かす
• はまりがちなところ

アンケート
• Node-REDの経験者8人にアンケートを行った．
• 社内サービス
• プロトタイプ
• テストダブル（ドライバ，モック，スタブ）
• 自社パッケージ
• ユーティリティなど
• Node-REDは生産性が高いことから選択された．
• 全てのプロジェクトはいわゆるウォーターフォール
型開発の工程を持っていた
• 程度の差はあるが厳格な工程完了審査は行われていない
• メールでQCDとプロセスの変化をアンケートした
• 品質，コスト，開発期間：4段階の選択式（重複選択可）
の評価と自由記述
• 要件定義，設計，プログラミング，テスト，リリースの変
化：自由記述

アンケート結果
• 評価方法
大分類小分類収集データグラフ化
QCD 品質 4段階＋自由記述 4段階
コスト
開発期間
プロセスの
変化
要件定義自由記述以下を判断して集計
• ネガティブ評価
• ポジティブ評価
• 変化なし
および
どちらともいえない
設計
プログラミング
テスト
リリース

QCDアンケート結果 - 品質 -
• サクサクと実装，実行，確認・修整の作ってのループが良かった
• 内製にこだわるよりも品質が良い
• コード量が減った
• 試作に有効
• 非同期処理が容易
• フローを意識してシンプルな作りになった
• 単体テストができない
• コード検索ができないのでバグが見つけにくい

QCDアンケート結果 – コスト -
• 高機能なコンポーネントが多い
• 設計からテストまでシームレスにでき効率が良い
• 処理部に注力できた
• diffが取れない
• ドキュメントが少ない
• 必要なノードを探すのに時間がかかった
• 繰り返し処理に苦労した

QCDアンケート結果 - 納期 -
• カスタムノード作成で効率化できた
• 開発のスピード感が半端ない
• 他人のフローを簡単にインポート可
• 実装にいきなり入れる
• 効率よく開発できる
• 大きな手戻りがなかった
• 自作部分の作りで効率や保守性が変わる
• ドキュメントが少ない
• 品質の悪いノードがあった
• 必要なノードを探すのに時間がかかった

プロセスの変化 – ポジティブ -
• プロトタイプが早くできると説明も早く，意見を貰いやすい
• 曖昧な要求でもとりあえず作り始めることができる
• 作ったものから要件を確定していくことが可能
• 大まかな処理の流れをすぐにフローとして実装可能
• 設計とプログラミングのイテレーションが容易
• Injectノードとデバッグノードでの確認も容易
• ほんの少数のファイルをリリースするだけでよく，管理しやすい
• ユニットテストはカスタムフローやAPI単位しかできないが，不安は少なかった
• コード管理だけ課題・・・完成した開発環境になればすばらしいものになりそう
• （保守は）基本的に容易だが，開発環境を残さないと詳細を確認し辛かった
設計以降の問題を
指摘しながらも，
好意的な表現

プロセスの変化 – ネガティブ -
• 単体テストをどのように行うのかわかりませんでした
• 複数人数での開発が少し手間取る
• 外部リソースの設定が外だしに出来ず，リリース後にとても煩わしかった
• Node-REDの癖にあわせた設計は必要．設計次第
• 簡単な反面，リリース後の不具合も増える可能性がある
• コード全体の検索が出来ないため，複雑なシステムは保守しにくくなる
上流のプロセスに変
化がないとしていた．
Node-RED流の開発
スタイルをつかみ切
れていない

考察
Node-REDの導入に重要なこと
• ツールの知識やノウハウを共有すること
• 特性を活かした設計で品質を作りこむこと
• 実装を繰り返して常に確認すること
• 上流から利用すること
情報共有や教育が重要であるだけでなく，
既存のプロセスをそのまま適用するのではなく，
積極的に変更することがプロセス改善につながる

アンケートまとめ
• Node-REDの開発経験者8人にアンケートした
• プロセスの変化を調査してその原因を考察した
• 新しいツールを導入してプロセスの改善するには以下が必要
Node-REDの導入に必要なものモダンアジャイルの指導理念
ツールの知識やノウハウを共有
する
人々を尊重する
特性を活かした設計を行う安全な状態を前提とする
実装を繰り返して常に確認する素早い実験と学習
主体的にプロセスを変更し、品質
を上流から作りこむ
価値を継続的に届ける
• 得られた知見は，モダンアジャイル*の基本理念と通じる
• Node-REDの良い導入が開発のアジリティ（機敏さ）を高める
* Smith, Agile 2016 Keynote: Modern Agile, https://www.infoq.com/news/2016/08/agile2016-modern-agile,
笠原，Agile 2016の基調講演: モダンアジャイル, https://www.infoq.com/jp/news/2016/08 /agile2016-modern-agile, 2016.

Node-REDの特徴
• Hello Worldの入出力のノードを置き換えるだけで
Webプログラムになる
一瞬でデプロイ
非同期処理を
可視化簡単デバッグ
多機能なノード群

Dashboard
• msg.payloadが標準なので
Hello Worldの入出力のノー
ドを置き換えるだけで
WebUIになる

繰り返し開発
• データの受け渡しの基本がmsg.payloadであ
ることを利用する
• インジェクトノードとデバッグノードでノードを開
発する
• 動作確認ができれば上流あるいは下流のノードを追
加する
• 確認の工夫
• カバレージを考慮しながらテストする
• 使い方のわからないノードは単独で確認する
• 注意点
• 起動時の処理は要注意
• もしもの時は~/.node-red/flows.jsonを編集する
• type:injectにあるonce
（一世代だけならbackupから戻せます）

インジェクトノード
注目
注目

デバッグノード
• ノード状態：functionノードの「node.status(xxx)」と同じ
• https://nodered.jp/docs/creating-nodes/status
注目

構造を設計・実装する
• 実装前に考えたことは？
• 意識したデータ？
• 機能のまとめ方？
• システム構造の考え方？
• 作業分担の方法？

意識するデータ
• msgオブジェクトの構造
• 重複の少ないデータ構造
• 途中で破壊しない
• グローバルオブジェクト、フローオブジェクト
• 永続化されない
• 初期化も考慮する
• データベース
• RDBかキーバリューか
• 運用も考慮する

機能のまとめ方
• タブ
• リンクやhttpで結合
• サブフロー
• フローを一つのノードにまとめる
• ファンクションノード
• 複雑な処理（Change, Switch, Split, Joinノード）を
まとめて記述できる
• カスタムノード
• 設定などのUIを持ったノードを作成できる
• 設計指針
• 単機能のノードやサブフローになる様に
• インタフェースのデータ構造が単純になる様に

Functionノード(1/2)
• 処理内容を表す名前を付けてフローを読み易く
• 入力は最大一つ、出力は複数可能
• 出力が複数の場合は戻り値を配列で返す
• 出力しない出口にはnullをセットする
• 単一条件出力はスイッチノードの方が修正が楽
• 端子に名前をつけるとマウスオーバーで表示
• バージョン0.17以降
• javascriptでコーディング（構文エディタ）
• msgオブジェクトを受け取って、msgを返す
• 一つの出口に複数返す場合や、無名関数内で終了
する場合は、 node.send(msgオブジェクト)

Functionノード(2/2)
• グローバルオブジェクト
• global.get()/set()
• フローオブジェクト
• flow.get()/set()
• require は setting.js の
functionGlobalContextで
• グローバルオブジェクトで
参照可能
端子名とアイコン

システムの構造を考える
• 処理形態
• 非同期並行処理
• 順次処理（メモリー消費が少ない）
• 処理間連携
• データ結合
• グローバル/フローオブジェクト、RDB、その他
• CRUD（生成、参照、更新、削除）の仕組み
• 通信
• http：戻りがある
• websocket、リンク：入力あるいは出力
• カスタムノード、サブフロー：入力と出力
• msgオブジェクトの初期化は危険
• http responseできなくなる
• メモリ削減にならない

作業分担の単位と方法
• 分担の単位
• システム（Node-RED）
• タブ
• フロー
• サブフロー
• カスタムノード
• 分担の方法
• 呼び出し(通信)
• リンクノード
• import & export
• インストール
• デバッグノードの出力をインジェクトノードで入力

テストの方法
• 単体レベル
• xUnitできるのはカスタムノード
• 少しずつ開発しながら随時テストする
• 信頼性の高いソフトウェアを増やしていく
• 機能テスト
• 機能の網羅性、データの網羅性や境界値に注目する
• Swagger、Postman、curlなどで呼び出す
• Node-REDでテストダブルを用意する
• スタブ、モック、ドライバ
• DashboardをUIに利用する
• 非機能テスト
• 非同期に動作するので線形に性能が出る
• 想定される負荷を実際に与えてテストする
• デバッグノードに注意

上流から動かす
• ドキュメントを軽量化する
• 情報（タブ、カスタムノード）
• コメントノード
• とりあえず動かす
• ユーザインタフェース
• システムインタフェース
• ビジネスロジック
• 単純化する
• 詳細なロジックは後回し
• リスクをつぶして実装のメリットを発揮する

はまりがちなところ
• メモリ不足
• 1対他の接続はコピーになる
• Functionノードでstatus表示すると良い
• デバッグノードは文字列化するので要注意
• 不要な接続は切る
• Node.send()は参照になる(結構危険)
• Javascript
• 非同期あるある
• 非同期処理中はreturnでなくnode.send()
• 適当に動作する（弱い型付け）
• 引数の間違いも動作する
• 進化が速い
• 他人が作業中に上書き
• 競合の通知と差分確認が可能
• 端子を間違える
• 端子に名前を付ける
• 動かなくなる
• ユーザディレクトリの.flows_＊.json.backupを.flows_＊.jsonにコピー

おわり

プロのためのNode-RED再入門

More Related Content

What's hot

Similar to プロのためのNode-RED再入門

More from Makoto SAKAI

プロのためのNode-RED再入門