無料ブログはココログ

標準は諸刃の剣

標準と聞くと仕事を楽にするもの、組織に必要なもの、 あるいは、 面倒臭いもの、 厳しいもの、と考える方がおられるかも知れません。これはどちらも真っ当な意見で、標準には良い面があるものの、悪い面もあります。

標準の効果

ここで参考になるのはプロセスモデリングのゴールでしょう([#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。標準を理解し、共通の行動を前提に改善し、必要な作業が行われているか管理し、ツールによる自動化やガイドできます。

つまり開発者を支援して、一定のレベルへの底上げや組織的な改善が可能になります。

思考停止の罠

組織活動に便利な標準ですが、思考停止に陥りがちです。厳しく管理することで標準に従うことに集中してしまい、より良いものを追求しなくなってしまいます。また、柔軟な開発ができなくなるので、 開発の負担になって生産性が低下してしまうこともあるでしょう。

より難しい問題は、技術者の成長を止めてしまうことです。実際に大規模開発でうまくやっていた人が、小規模で比較的自由な開発でプロジェクトをうまく管理できないこともあります。なぜその標準が必要なのかをキチンと理解していなかったのでしょう。

良い標準

このような問題が生じにくい標準を考えてみます。標準で全てを縛るのではなく、その重要度によって規則、推奨、参考情報に分けると良いでしょう。単純な共通化ではなく、判断条件と共に複数の選択肢を示します。

良い標準は学びになります。その標準がなぜ良いか、どのような条件で有効か、その理由が説明されているなら、標準に振り回されること無く、自ら判断して実施できるでしょう。

標準を活かすには

どんなに良い標準でも、言われるままに実施しているのでは仕事をこなしているだけです。確認が可能なら、きちんと原本を読んでください。思わぬ発見があるかも知れません。

標準はそれぞれの組織や業務に応じて決められたものですので、定められた制約を守らないといけません。反面、制約を守っていればそこに工夫の余地があります。ソフトウェア開発と同じです。

(参考)詳細設計書を後回しにした話:Win-Winプロセス(ウォータフォール編)

このエントリーをはてなブックマークに追加

Visual IoT 開発ツール Node-RED が盛り上がってきた - 新刊2冊 -

IoTって言うけれど、ハードウェアの情報を収集したり、サーバーを構築するのは結構面倒でした。そこに現れたのが  Visual IoT 開発ツール Node-RED です。

Node-RED は以下のような特徴を持ちます。

  • Node.jsの非同期処理をVisualに、しかも簡単に扱える
  • ハードウェア接続や通信など標準モジュール(ノード)が豊富
  • 多くのソフトウェアがcontribute されている。中でもdashboardを利用すれば、テスト用のUIが簡単に作れる

そんな、Node-REDの書籍が2017年夏以降に2冊出版されました。しかも良く書けていてお勧めです。

【1】つないで つないで プログラミング Node-REDでつくる初めてのアプリ

基本的な操作だけで半分のページが使われ、ユーザーズマニュアルの様に丁寧に書かれていています。

このブログでもNode-REDを紹介してますが、ここまでは詳しく書けません。まわりにユーザがいない方には頼りになる存在でしょう。

【2】はじめてのNode‐RED

はじめてのと書かれていますが、バランス良く書けた入門書です。初めての方でも、Node-REDらしいプログラムを楽しみながら読めると思います。

Node-REDの日本語情報を提供しているNode-REDユーザグループジャパンhttps://nodered.jp/執筆とあって、興味を惹く内容が色々と乗っています。

一見、おもちゃの様に見えるNode-REDですが、実際に使ってみると、高機能なソフトウェアを簡単に書くことができて驚きます。良い本が2冊も発売されて、いよいよ本格普及が始まりそうです。

このエントリーをはてなブックマークに追加

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発(以下アジャイル)がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」(リーンを考える - 無駄と必要なアソビ -) の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法(ウォーターフォールと呼ぶとリリースが1回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法)とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです(「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ:An Agile Way:オルタナティブ・ブログ)。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル(リンク先はWikipedia)を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時(最終責任時点)まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります(現場で役立つシステム設計の原則)。

この5ページの「すべてのカラムが Not Null は非現実的?」に対して「実際にやっている、特に困っていない、SQL のスキル+ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました(アジャイルとデータモデル、DB進化設計のこと)。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -

2017/9/14追記
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション(スプリント)をうまく回せるか不安だった方や、ベロシティ(開発速度)が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか?では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの5つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません(私には書けませんが)。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

このエントリーをはてなブックマークに追加


立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -

高級食材をリーズナブルに提供する立食タイプのレストランがはやっている。景気が少しは上向いたものの本格的な好景気と言いがたい中、たまには良いものを食べたいというニーズに応えるべく、立食で回転率を上げることで原価率の高いリーズナブルな商品を提供しているのだ。

これに対して本格的なコース料理を出すレストランの方々は、苦々しく思われているだろう。食事というのは文化であり、美味しく食べるには順番があり、ふさわしいサービスと共に提供することで至福の時間を楽しんでいただける。それなのに、メインディッシュ中心で、イスすら無い。そもそもイスが無ければ落ち着かないじゃないか、と。

もちろん、単なるアイデア勝負では勝てないので、立食サービスを提供する側も顧客の特性を見据えて方針を変更する。たとえば大阪と京都だけはイスを設置するなどして、ニーズに応えようとする。

オブジェクト指向

前置きが長くなったが、増田さんの本と杉本さんの批判を読んで頭に浮かんだことである。

杉本さんの「現場で役立つシステム設計の原則」批判 (1) ~何のために、「データとロジックを一体に」するのか?~「現場で役立つシステム設計の原則」批判 (2) ~ポリモーフィズムは何のために?~ を読んでいると「なるほど」と思うものの「現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法」の増田さんはなぜそのような本を書かれたが気になった。

そこで話題の本を読んでみると、私の知っているオブジェクト指向をベースに戦略的な内容が書かれていた。ベースとなるオブジェクト指向は、デザインパターンが話題になるまでのオブジェクト指向に近いものだ。

オブジェクト指向の主張や流派には色々あるが、Smalltalkで学ぶオブジェクト指向プログラミングでは、アラン・ケイさんが「生物がどのように複雑な構造を作るかを考えました」という言葉を引用し「オブジェクトは細胞のアナロジー」としている。

そこには、小さなものを作り、確認しながら、方向性を見極めながら、徐々に大きなものを作るアジャイル開発やリーンスタートアップにつながる戦略が垣間見える。

アジャイル開発とリーンスタートアップの戦略に求められるもの

アジャイル開発も最近ではモダンアジャイルと言って、定期的なタイムボックス管理にこだわらず、ビジネスの成長に直結するソフトウェアを、よりコアな部分から段階的に、しかも安全に開発する方法として実践されつつある。

そのような開発では、従来型開発で重視された、業務全体を見渡して最適化すること、技法本来の使い方を熟知すること、将来的に必要と思われる機能をシステム一式を開発するよりも、ローコストで、シンプルで、業務に役立つ最低限のシステム、の開発が求められる。

もちろん、アジャイル開発に向いた開発法には欠点もあり、初期の開発では業務全体に最適化されておらず、技法としても不十分で、将来的に継続的な改修が必要となる。

しかし、収益を出すことが難しいスタートアップ企業のに求められるのは

  • ビジネス(業務活動)が実施できること
  • 理解が容易な程度に単純なこと
  • リファクタリングが容易なこと

といった点である。これらはビジネスの存続・発展のためには重視されるだろう。

立食 vs コース

さて、機能の抜けが無く良い設計のソフトウェア開発と、リファクタリングを前提に最低限の機能から実装する方法は、本格的なコース料理を提供するレストランと、メインの料理を中心に立食で提供するレストランの様に戦略が異なる。

今後も発展するだろうが、ブームは過ぎるかもしれないし、立食で無くなるかも知れないが、回転率を重視する店は今後も存在するだろう。逆に、コースを提供するレストランは淘汰が進むかもしれないが、こちらも全てが無くなることは無いだろう。

それぞれに特長があり、調理師に求められるスキルも異なる点があるだろう。互いに相手のやっていることは、自分のやりたいことではないと言うかもしれない。

しかし、相手の立場に立ってその戦略を見たとき、自分の技術に書けている点や自身の強みが見えてきて、技術を磨くための肥やしになるだろう。

おわりに

今回の議論はとても興味深く、とても参考になる。その背景には感情的な対立でなく、若い人にわかって欲しいとか、偏った考えを持って欲しくないという前向きなものだ。

すでに若いとは言えない年だが、色々と学ばせていただいた。今後もぜひ前向きに議論を続けていただき、技術の発展に貢献していただきたい。

このエントリーをはてなブックマークに追加


[#Node-RED] 7〜8分でわかるファンクションノード

Photo

Visual IoTツール Node-REDには、データセットや基本的な制御構造がありますので、簡単なプログラムならコーディングなし(設定だけ)でプログラムを書くことができます。

しかし、少し複雑な処理になるとファンクションノードが便利です。ファンクションノードはjavascriptでコーディングできますので、複雑な処理をフローにまとめることができ、シンプルなわかり易いフローが書けます。

1.基本

まずは基本的な内容から。

1.1 名前をつけよう

ノードには日本語で名前を付けることができます。処理内容を表す名前を付けておくとフローが読み易くなります。「XXに変換する」「msg.cnt++」などわかり易い名前を付けてください。

1.2 入力は最大一つ、出力は複数可能

ファンクションノードの入り口は一つだけです。デフォルトの出力は一つですが、下部にある出力数を変更して増やすことができます。出力が複数場合は戻り値を配列で返します。出力しない出口にはnullをセットします。条件によってどれか一つに値を出力するだけなら、スイッチノードに渡した方が、修正が楽な場合もあるでしょう。
(追記:バージョン0.17以降では端子に名前をつけるとマウスオーバーで表示できますので、入出力などをわかり易く書いておくと良いでしょう。)

1.3 javascriptでコーディング

内蔵エディタはjavascript構文を理解してエラーやワーニングを表示してくれます。Node-REDが動作するNode.jsのバージョンの文法で記述します。msgオブジェクトを受け取って処理し、リターンバリューがmsgオブジェクトになります。

2.あらかじめ定義されたオブジェクト

msgオブジェクト以外のあらかじめ定義されたオブジェクトを説明します。

2.1 グローバルオブジェクト

プログラム全体で利用可能なグローバル変数が使えます。
global.get(‘オブジェクト名’)で取得し、 global.set(‘オブジェクト名’,値)で値を設定します。現在は永続化されないので、再起動で初期化されます。

2.2 フローオブジェクト

タブ内で有効なフロー変数もあります。
flow.get(‘オブジェクト名’)で取得し、flow.set(‘オブジェクト名’)で値を設定します。
永続化されないので、再起動で初期化されます。

2.3 node.send()

一つの出口に複数返す場合や、無名関数内で終了する場合は、returnでなく、 node.send(msgオブジェクト)を用います。returnは最後の一度死活変えませんし、無名関数内のreturnは全体の戻りではないからです。

2.4 require は setting.js で

ファンクションノード内で requireできません。requireが必要な場合は、ユーザーディレクトリ( ホームディレクトリ/.node-red)のsetting.jsのfunctionGlobalContextにrequireを追加します。Node-REDを再起動すると、設定したオブジェクトを global.get(‘オブジェクト名’) で取得できます。もちろん、必要に応じてユーザーディレクトリで、モジュールをnpmインストールする必要があります。

3.オブジェクトの管理

簡単に見えるNode-REDプログラミングですが、意外とハマるのがオブジェクトの管理です。

3.1 msg.payloadは基本

標準的な出力はmsg.payloadですが、破壊されることも多いです。payload以外のプロパティを使えば多くの場合は大丈夫です。しかし、新しいmsgオブジェクトが生成される場合は、フロー変数やグローバル変数を使います。

3.2 新しいmsgオブジェクトで返す

受け取ったmsgオブジェクトを渡したくない場合は、「return {payload: 値};」とすると新しいオブジェクトのmsg.payloadとして値を返すことができます。ただし、後続の処理で、受け取ったmsgオブジェクトの値を渡せないので注意してください。特にhttp inが出力するmsgオブジェクトには、http responseに必要な情報が含まれますので注意してください。

3.3 コピーされるオブジェクト

「return [msg, msg];」のようにmsgオブジェクトを複数同時に返すと、オブジェクトッがコピーされ、異なるオブジェクトが渡されます。また、一つの出口から複数のノードに繋いだ場合もコピーされます。大量データを扱う場合には注意してください。新しいmsgオブジェクトを生成するか、node.send()で出力すると参照が渡されます(参照を渡すと想定外に内容が破壊されてしまうことがありますので注意してください)。

4.おわりに

簡単に始められるNode-REDプログラミングですが、ドキュメントをきちんと読んだり、色々試さないとわからないことがあります。ここに挙げた内容がわかっていれば、少し複雑な処理もスラスラと書けると思います。

詳しくは、公式ドキュメント(英語)の確認や、実際に動かすなどしてください。それでも困った時は、ユーザー会slackやメーリングリストなど(英語)で聞いてみると良いと思います。

このエントリーをはてなブックマークに追加

Node-REDで品質の高いソフトウェアを開発する

開発者へのアンケートによると、Node-REDを用いると高品質なソフトウェアが開発できることがわかりましたが、そこには注意点がありました(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。

Node-REDで開発する際にはNode-REDに合わせた設計やテストが必要です。順に説明しましょう。

データ設計

Node-REDのノードは関数ではなく、msgオブジェクトを加工しながら処理を進めますので、msgオブジェクトのデータ構造をきちんと決めておかないと、混乱してバグの原因になります。

msgオブジェクトと同じ様に処理館の共通データであるフロー変数やグローバル変数、データベースも同様にデータ構造をきちんと決めておきます。

構造設計

フローをどのように構成するか、非同期並行処理(コールバック地獄よさようなら。Node-REDで非同期処理を使いこなせ! )か順次処理かを検討します。非同期処理は処理が速く効率的です。一方の順次処理はメモリーをあまり消費しないので、大量データを扱う際に有利です。メモリー消費が多いとシステムやDBノードが止まることもありますので、注意深く検討してください。

システム間連携

前回(Node-REDでより大規模な開発を - モジュール化とフロー・システム間連携 - )に書いた様に様々な連携方法があります。それぞれの長所短所を検討して方式を決めてください。

いずれの場合もなるべく早い時期から結合すれば、信頼性を高めることができます。

モジュール設計

いわゆるモジュール強度(凝集度)や結合度を考慮してモジュール化します。なるべく単機能のノードやサブフローになる様に、インタフェースのデータ構造が単純になる様に設計します。

また、ノードの出力するオブジェクトがが参照なのか、データのコピーなのか、あるいは新しいオブジェクトにするのかを検討します。新しいオブジェクトにすると、渡していないデータは破壊されます。特にhttpレスポンスには多くのデータが必要ですので注意してください。

逐次開発・テスト

いわゆるxunitはカスタムノードでないと利用できません。改造する際はデグレが生じ易いので気をつけてください。良いモジュール構造にして、逐次開発とテストを並行して行います。

少しずつ開発しながら随時テストすることで、信頼性の高いソフトウェアを増やしていきます。常に追加した部分を動作確認すれば、まとめてテストした場合よりも抜けが少ない様です(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。

機能テスト

機能テストを行う際は、機能の観点だけでなく、データの網羅性に注意すると良いでしょう。いわゆる界値に注目してテストデータを決めます。

Node-REDはスタブやモック、ドライバなど、いわゆるテストダブルの開発にも向いています。実機の利用が難しい場合に検討すると良いでしょう。特にDashboardを利用すると、使い易いテスト環境が実現できるでしょう。

非機能テスト

デバッグノードなどを不用意に繋ぐと、フローの二股に分かれたところでデータがコピーされ、メモリー負荷や、処理速度の低下に繋がるので注意してください。

Node-REDはNode.js上で非同期に動作しますので、スレッドによる実装よりも線形に性能が出ますが、残念ながら上限性能は存在します。小規模なテストで安心しないで、想定される負荷を実際に与えてテストしてください。

おわりに

Node-REDを使うと簡単に動くプログラムができます。しかし、ある程度規模が大きくなると、設計やテストの戦略が必要になります。

ここに挙げた方法は一例に過ぎません。開発対象や環境に合わせて実施してください。

このエントリーをはてなブックマークに追加

Node-REDでより大規模な開発を - モジュール化とフロー・システム間連携 -

Node-REDはマルチユーザ対応に向けてバージョンアップが進んでいますが、現在のエディタは基本的に一人でしか使えません。しかし、モジュール化やフロー・システム間連携を使えば、複数人で連携してより大規模な開発ができます。

1.  機能モジュールの作成方法

(1-1) エクスポート/インポート

エディタ上の任意のフロー/現在のタブ/全てのタブをJSONでエクスポートして人に渡したり、エクスポートしたJSONを受け取ってインポートすることができます(もちろんバックアップや複製にも使えます)。

エクスポートはフローを選択した後に、
 右上のハンバーガー(3本線)メニュー ⇒ 書き出し ⇒ クリップボード
を選択すると、 エクスポートのダイアログが表示されますので、選択したフロー/現在のタブ/全てのタブ、 それをコピーします。インデントのないJSONフォーマット/インデントのあるFOMAとを選択し、クリップボードに書き出します。

インポートは、
 右上のハンバーガーメニュー ⇒ 読み込み ⇒ クリップボード
を選択すると、 インポートのダイアログが表示されますので、現在のタブか新規のタブを選択して、エディタにコピーします。

(1-2) サブフロー

フローが大規模になると、同じフローが何度も出てくるなど見通しが悪くなりがちです。フローの一部をサブフローと呼ばれるモジュールを定義して扱うことができます。

右上のハンバーガーメニュー ⇒ サブフロー ⇒ サブフローを作成を選択すると、左ペインにサブフローが追加されサブフローのタブが開かれます。プロパティを編集するとサブフロー名や情報タブに表示される詳細情報を編集できます。入力(最大1つ)や出力(0以上)を設定すると、inputやoutputが表示されます。

またはサブフローにしたいフローの部分を選択しておいて、ハンバーガーメニュー ⇒ サブフロー ⇒ 選択部分をサブフロー化を選択するとその部分がサブフローになり、左ペインにサブフローが追加されます。左ペインのサブフローをダブルクリックするか、エディタ上のサブフローをダブルクリックして「フローのテンプレートを編集」をクリックすると、サブフローのタブが開かれます。

サブフローのタブを閉じてもサブフローは消えませんので、サブフローのタブを開いて削除します。

(1-3) カスタムノード

ユーザが独自のノードをJavascriptとHTMLで書くことができます。requireもできますので、様々なノードを 作ることもできます。 詳しくはCreating Nodesを見てください。

2. フロー・システム間連携

機能モジュール毎に担当者を分けて開発し、それらを以下のような方法でつなぎ合わせれば、より大きなシステムを作ったり、外部のシステムと連携することができます。

(2-1) デバッグノードの出力をインジェクトノードで送信

別の担当者のモジュールと接続する部分にデバッグノードをつないで、その出力のJSONをコピー(取り出)して担当者に渡します。担当者は受け取ったJSONをインジェクトノードに設定すると、異なるNode-RED間を直接つながないで、JSONデータを介してフローの続きを開発することができます。

(2-2) 異なるタブをリンクノードでつなぐ

機能ごとにタブを分けて、それぞれに担当者を決めておくとマージが容易になります。各タブのフローを繋いで大きなフローとするには、出力と入力のリンクノードを使います。

リンクノードは複数への出力や、複数からの入力の設定が可能です。リンクノードにわかりやすい名前をつけておくと良いでしょう。

(2-3) グローバル/フロー変数結合

取得したデータをメモリーやストレージに保存し、それを一定のタイミングで取得することも可能です。インジェクトノードで繰り返しを設定すると、一定間隔や指定日時、あるいはその組合せで処理を実行して、いわゆるポーリング処理やタスク処理を実現できます。

最も簡単な方法はグローバル変数やフロー変数を用いる方法です。グローバル変数は全てのノードから参照・更新が可能で、(いまのところ)Node-RED起動時に初期化されます。フロー変数は同じタブ(フロー)内のノードから参照・更新が可能で、デプロイ時に初期化されます。

(2-4) 処理間連携

httpノードやwebsocketノードを使えば、他のシステムと連携することができます。http inノードで要求を受けたら、同じ処理のフローにhttp responseノードを入れないと呼び出しが終了しないので気をつけてください。また、http requestノードは出力形式を文字列、バイナリバッファ、JSONを選ぶことができます。

他システムのデータをタスク処理やポーリング処理をするなら、ファイルやデータベースを使うと良いでしょう。ファイルは入出力のほかwatchノードで更新を検出することができます。また、カスタムノードをインストールすればPostgreSQLやSQLiteなどのデータベースを利用することができます。

3. おわりに

Node-REDで開発する際のモジュール化とフロー・システム間連携についてまとめました。

ここに挙げた方法を用いれば、複数人でNode-REDを用いてより大規模なシステムを開発することができます。みなさんも色々と工夫してください。

開発者へのアンケートによれば、大きなシステムを開発する場合はここにあげた方法だけでなく、設計やテストを工夫することで高品質なソフトウェアを短期間で開発することができます(Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -)。設計やテストの工夫もいつかまとめたいと思います(Node-REDで品質の高いソフトウェアを開発する)。

このエントリーをはてなブックマークに追加

[#TiDD] プロジェクトを成功させるチケット管理

QuaSTom高品質ソフトウェア技術交流会 2017年度第2回例会で講演させていただきました。

Redmineの勉強会ではないので初心者の方が多いかと思いきや、9割の方がチケットシステムを使われていて、そのうちTracが24%、Mantisが8%、残りがRedmineを使われていました。

幹事の松谷さんに用意していただいたグループディスカッションも、みなさんのお悩みや経験で盛り上がりました。やはり、メンバーにきちんと理解してもらえないとうまくいかないようです。

同じような議論は、90年代後半以降のプロセス改善ブームの頃にもありました。みなさんの意見をうかがっていると、やはり「ツールの導入はプロセス改善である」という思いが強くなりました。

ディスカッションへのコメントで「ゴールはプロジェクトの成功」とお話ししたことや、講演のおまけでお話しした「サーバントリーダーシップ」もリーダーシップの議論をされているとのことで喜んでいただけました。

久しぶりに大いに刺激を受けることができました。ありがとうございました。

おまけ

講演の仲であまり詳しく説明しなかったチケット駆動開発のレフトウィングとライトウィングのお話は、以下の発表が元になっています。

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

(今回はお話ししませんでしたが、改善にはフィードバックやタイミングも重要だと思っています)

この発表の際にも使わせていただいた乗松さんの資料(PDF)の23ページ「SPIモードの遷移」は認証の罠を標準化の罠に読み替えるとツール導入にも同じような問題が起きると思いますので、参考にしてください。

このエントリーをはてなブックマークに追加


アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

このエントリーをはてなブックマークに追加

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

このエントリーをはてなブックマークに追加

«Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -