無料ブログはココログ

« 2017年10月 | トップページ | 2018年3月 »

[#Node-RED]インジェクトノードで定期処理 - ポーリングとバッチのヒント -

SRA Advent Calendar 2017 9日目からの転載です)

今回はインジェクトノードによる定期処理とそのヒントを説明します。

1. インジェクトノード

インジェクトノードというのはNode-REDの最初のサンプルでほぼ間違いなく使われるノードです。左の四角い所を押すと現在時刻や文字列、JSONオブジェクトなど設定したデータがmsg.payloadにセットされて送信されます。

20171209_153945_3

インジェクトノードは多機能で、起動時にメッセージを送信して初期処理を実現できますし、「繰り返し」の設定で定期的にメッセージを送信してポーリング処理やバッチ処理を実現することもできます。「繰り返し」をセットすると、インジェクトノードに丸矢印が表示されます

2.ポーリング処理とバッチ処理

ポーリング処理というのはデータ取得の方法です。センサーや通信装置などからデータが送られ無い場合、プログラムの側からデータを取りに行く必要がありますので、求められる時間間隔でポーリングし(取りにいき)ます。

バッチ処理というのは必ずしも定期処理ではなく、まとめ処理を実行するという意味です。UNIX系のcron処理やジョブスケジューラやタスクスケジューラなどと組み合わせて定期処理を実現されることも多いので、ここではバッチ処理と呼びます。

フロントエンドで受信したデータを蓄積し、バックエンドのバッチ処理で定期的にまとめて処理します。こうすることで同時処理を避けることができ、CPUやメモリなどのリソースを効率よく利用することができます。

3. インジェクトノードによる定期処理

インジェクトノードの「繰り返し」では、以下の3種類(と「なし」)を設定できます。

3.1 指定した時間間隔

サーバやセンサから定期的にデータを取得したり、DBにあるデータを定期的に処理する場合に用います。秒、分、時間で指定できます。

20171209_135528_3

3.2 指定した時間間隔、日時

曜日と時間帯を1時間単位に指定し、分単位で定期的に処理ができます。cronで実行されるので、あまり精度は期待できません。

20171209_135713_3

3.3 指定した日時

曜日と時刻を分単位に指定し、定期的に処理ができます。cronで実行されるので、あまり精度は期待できません。

 

20171209_135747_3

4. ヒント

4.1 より短い間隔で実行する

例えば0.5秒ごとに実行したい場合は、インジェクトノードを1秒間間隔で指定し、出力を二股に分けて一方をディレイノードで500ミリ秒遅延させます。こうすると、メッセージが0.5秒ごとに送られる様になります。

20171209_153616_3

片側に1ms、もう一方に501msのディレイを入れると一旦両方のディレイノードが実行されるので、 より精度が上がるでしょう。ただし、精度はそれなりですので、あまり細かくしたり、後続の処理が重かったりすると、うまく動かないので注意してください。

4.2 重複に注意

繰り返しの時間感覚よりも処理時間がかかると処理が重複しますので、注意してください。処理が重複すると、同じデータを2回処理してしまったり、メモリなどのリソースが不足する可能性があります。

4.3 別の方式も検討する

バッチ処理の場合、ディレイノードでキューイングする方法も検討してください。この場合、実行中のデータは保存されないので気をつけてください(バッチ処理でも蓄積する際に永続化しないなら同じです)。このほかにも、クラウドのサービスなどでもキューイングできるでしょう。

5. まとめ

インジェクトノードによる定期処理とそのヒントを説明しました。IoT開発ツールとして以前から繰り返し実行ができましたが、最近はノードに繰り返しの表示が出る様になって、より使いやすくなりました。

Node-REDの面白いところは、シンプルな機能を組み合わせて色々なことが簡単にできる所だと思います。ぜひ、みなさんもインジェクトノードを使って色々と工夫してください。

# おまけ
標準のインジェクトノードでも工夫次第で様々な処理が可能ですが、bigtimerノードならより直感的な設定ができるようです。

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


暗黙知は帳簿と運用に眠る - 業務理解に向けて - #benkyoenkai

年忘れLT宴会<第60回IT勉強宴会>に参加しました。最も刺激を受けたのは杉本さんのLTでした。

暗黙知

同じお客様の開発を何度かすると「なるほど」と過去のことが理解できることがあります。与えられた仕様(要件)を満たすソフトウェアを開発する中で、その背景にある暗黙知が得られた瞬間です。

もちろん、最初の開発でもある程度は暗黙知を得ることはできます。仕様についてそれはなぜかを質問することです。納得できる詳しい説明や、これまでそうしてきたからなど、色々な回答が得られます。

しかし、暗黙知の全体像に関しては、開発を一通り終えて、実際の運用がうまく回り出して一通りの業務を近いするまで、なかなか得られません。

帳簿は暗黙知の中心

杉本さんのLTで紹介された開発では、帳簿(DB)が業務システムの中心で、運用で対応する部分も含めて業務システム開発します。そのような開発に於いては、業務分析やデータモデリングを追求することで、業務を明確にして暗黙知をシステムに取り込んでいくのでしょう。

それはソフトウェアのプログラミングだけでなく、帳簿(DB)はもちろんのこと、運用を含めた暗黙知を明確にしないと教務システムはうまく開発できないという示唆だと思いました。

おわりに

SRA Advent Calendar 2017に「効率的なモデリングをマネージメントする」(ここにも転載:その1その2その3)という記事を書きました。これに運用はほとんど考慮されていません。

これまで、いわゆる業務系とは異なる開発をしていながらも、IT勉強宴会で色々勉強をさせていただいてきましたが、どこかモヤモヤするものがありました。それが運用であったことに気付くことができたのは、今回の大きな収穫でした。

IoT関係で運用と言うと、UIがらみを除くとクラウドのアーキテクチャ設計とその運用設計がそれに当たります。クラウドでは新しいサービスが続々と出てきますので、それが開発を一通り経験しないとわからない理由だったのかと腑落ちした次第です

LT中のアジャイルウォーターフォールに関しては、主語が大きくて気になりますが、それを上回る刺激を受けました。ありがとうございました。

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

効率的なモデリングをマネージメントする その3 - 開発標準を素直に実施しない -

SRA Advent Calendar 2017 23日目からの転載です)

はじめに

まじめにやっているのにうまくいかない。標準なんだからその通りにやればいいじゃないか。そう思われるかも知れません。

しかし開発標準で守らないといけないことには幅があり、それなりの自由度があります。きちんと理解した上で適切にモデリングすれば、効率的なモデリングが可能になります。

開発標準

開発標準は成功したプロジェクトを参考に、良いプロセスの実施が容易な様に、実施すべき各作業とその確認方法を定めたものです。開発者を支援して、一定のレベルへの底上げや組織的な改善を可能にします(その反面、さまざまな罠もあります。標準は諸刃の剣)。

モデリングをする際にも、ある時はガイドやノウハウ集として使えますが、時には収集したデータの正常範囲を定めるなど、モデリングや実装の作業を制限します。

開発標準を良く読む

大切なのは開発標準を良く読むことです。開発標準には以下のようなことが書かれていると思います。

  • 全体の構成と考え方(ガイド)
  • 守らないといけないルール(制約)
  • 一般的な方法(ガイド)

ガイドに当たる部分はうまくいったプロジェクトで行われた一般的な開発の方法や作業が書かれています。制約に当たる部分は守らないといけないルールで、作業だけでなく何らかのメトリクス(尺度)が定められているでしょう。作業のエビデンス(照査)となるデータの収集が必要です。レビューやテストの項目数や時間など一定の量が必要になり、作業が制約を受けるでしょう。

開発標準には多くの役立つことや勉強になることが書かれていますが、必要なことが全て書かれている訳ではありません。書かれていることに従って、それだけをコツコツ実施しても、必ずしもうまくいくとは限りません。

リスクが工数に見合うだけ低減するなら、下記のようなモデリング作業の変更が必要になります(同程度でも実施します)。

 
増やす
 
      必要なモデリングを追加します。多くの場合、設計作業の追加はあまり禁止されていません。  
 
前倒し
 
     よりリスクが低減するなら後工程の作業を前倒しします。一部詳細化したり、プロトタイピングの実施など、本格的な実装でなければ許容されるでしょう。  
 
分解
 
       モデリング作業を分解し、調査、整理、考えるといった作業を前倒しします。会議内で(モブ)モデリングしても良いでしょう。  

大切なのは、予め計画してステークホルダーと合意を得ておくことです。また、開発中であっても必要が生じたら、面倒がらずに計画を変更することも重要です。
前回の「効率的なモデリングをマネージメントする その2 - モデリングの戦略 -」を参考にしてください。

逆らっても徒労に終わることが多い

若気の至りで開発標準に抗議したこともありますが、逆らっても徒労に終わることが多いです。開発標準は必要な作業の抜けを防ぐ目的で組織として決めたものです。個別のプロジェクトに対してテーラリング以外の変更を要求しても、許容する権限が担当者にありません。

逆に制約だけを守れば、意外と自由度があるものです。ガイドを読んでしっかり活用することで得られることも多いでしょう。

とはいえ、どのような標準も使っていれば時代遅れになるもので、改善案は提案してください。パイロットプロジェクトで確認することも必要ですので、改訂には複数年かかるでしょう。

開発標準のフィールドで走り回れ

多くの競技にはコートのような活動領域が決められていて、競技者はその範囲を有効に使いながら、敵を攻略します。

開発標準は縦にだけ動けるサッカーゲームの様に、典型的ないわば「型」を示したものです。定められたフィールドからはみ出さない程度に、右に左にゴールに向けて戦略的に攻撃ください。

おわりに

効率的なモデリングをマネージメントする方法を3回に分けて説明しました。以前はうまく開発できていた人が、プロジェクトが変わると急にトラブルに巻き込まれる。そんな姿を見たくありません。

開発標準と改善活動はフィットするプロジェクトにはとても効果的です。しかし、それぞれの作業がなぜ必要なのかをきちんと理解しなければ、典型的なプロジェクト以外に応用がききません。

何が制約であり、なぜそのようにするかを理解すれば、開発標準を味方につけられます。そして、自由なフィールドを手に入れて様々な実施方法ととることができます。

釣りは「ぼーっ」としていては釣果が出ないそうです。常に「ああかな」「こうかな」と状況を見極めて必要な行動が必要だそうです。ソフトウェア開発でもいつもリスクを見極めてダイナミックに適切な対応をとることが、リスクと戦う効率的な方法だと思います。


「だから、あなたがたは気をつけていなさい。」マルコによる福音書/ 13章 23節(日本聖書協会 新共同訳)

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

効率的なモデリングをマネージメントする その2 - モデリングの戦略 -

SRA Advent Calendar 2017 15日目からの転載です)

1.はじめに

ソフトウェア開発は危険です。急に暴れることから、ある時は狼男、ある時は熊に例えられます。まじめにコツコツと働いていたのに、突然現れた狼男や熊によって計画が台無しになってしまいます。

混乱に陥ったプロジェクトを見てみると、混乱の原因は意外と明確です。しかも、当事者である若いメンバーから部門のマネージャに至るまで、だいたい答えられることも多いでしょう。しかし時すでに遅し、混乱を押さえるには仕切り直して計画や配員を見直さないとプロジェクトを立て直すことができないでしょう。

2.不確実コーンを細くする

社会の発展や競争の激化、ソフトウェア技術の進歩によってソフトウェア開発期間は短く、より多機能になり、見積もりの振れ幅を時間軸で示した不確実コーンは広く、短くなっています([#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう

Photo

そこで、短い期間に区切って段階的に開発するアジャイル開発が増えてきています。 これば、不確実コーンを小さなコーンに分ける方法です。 アジャイル開発はUXを重視する場合や、まずはビジネスを開始したい場合には、実際の動作を見極めながらの方向性の変更や、必要なものからビジネスの支援が可能なので、とても効果的です。

しかし、必要な機能を分解できない場合や、イテレーション(スプリント)を複数回実施できないほど短期間の開発の場合には、効率的なモデリングでリスクを下げて不確実コーンを小さくする必要があります。

そこで求められるのは、戦略的な考え方です([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)。その時点で最も効果のあるポイントをのモデルを作成する必要があります(大規模開発の場合は、ランチェスターの法則(ランチェスターの法則と売り上げ、利益、利益率)に従って総力戦も可能ですが、重点の見極めは大切です)。

作成するモデルは、ドキュメントとして完成されたものでなくても、考える道具になり、ステークホルダーと共有できるなら、なんでも良いでしょう。以下にパターンに分けて説明しましょう。

2.1 全体が曖昧な場合

何かを作ってしまうと、それに引きずられて全体像が見えにくくなる場合がありますので、全体がぼんやりとしている時にわかる所から作り出すのは賢明ではありません。

全体像を抽象的な方向性でなく、具体的な構造を考えて実現可能性を高めます。具体的には、業務フロー、シーケンス図など全体の流れがわかるモデルを作成します。モデルを書いてみると、そこには業務の用語やデータが見えてくると思います。

2.2 抜けがあるような気がするとき

データをモデリングします。必要なデータを探してまとめます。ER図でも、オブジェクト図やクラス図でも、ただの一覧でも構いません。
次に見つけたデータがどこで作られ、どこで更新され、どこで削除されるかの説明を試みます。説明ができたなら不安が解消していると思いますが、精査したければやり過ぎないレベルでCRUDを書いてみても良いでしょう。

2.3 実装イメージがわかない、自信が無いとき

あまり経験の無い環境などで、自信が無いなら調べましょう。インターネット上の記事は大まかな知識や事例を知るには役立ちますが、最終的には公式ドキュメントで確認しましょう。

それでも不安が残ったり、わからない所がある場合はプロトタイプを作成します。プロトタイプは全ての実装ではなく、課題となっている所を抜き出して単純化したものですので、まさに「モデル」です。

3.モデリングのポイント

ここで示したモデリングの方法は、以下の3点を明確にするものです。

  • 全体のイメージ
  • データと関係
  • 関連ソフトウェアの詳細仕様

これらのモデリングを考える道具道具として使い、リスクを排除します。これによって不確実コーンを細くして、ソフトウェア開発の混乱を少なくします。

ここで注意しないといけないのは、前回(効率的なモデリングをマネージメントする その1 - モデリングの目的 -)に書いた様にモデリングの目的には様々あるものの、ここで挙げた方法は

  • 見つける、理解する
  • 整理する
  • 作り出す

といった目的が中心です。つまり、モデリングの全ての目的ではないのです。モデリングでリスクを低減するには、リスクそのものにポイントを絞ったモデリングが必要で、その他の目的を達成する際の参考になりますが、不十分なものです(プロトタイプと同じです)。しかし、それでも優先してモデリングすることが重要なのです。

4. おわりに

ここであげた効率の良いモデリングとは、義務としてドキュメントを早く仕上げるのではなく、個々のプロジェクトに特有のリスクを低減する方策としてモデリングです。このような視点でプロジェクトを実践すれば、より安定した開発を実現することができるでしょう。

モデリングは工程に関係なく、必要ならいつでも実施すべきです。「しかし、開発標準が、、、」と言われる方のために、次回は「[開発標準を素直に実施しない]()」ことについて説明します。

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

効率的なモデリングをマネージメントする その1 - モデリングの目的 -

SRA Advent Calendar 2017 7日目からの転載です)

「どのようなモデリングをするか?」その答えは人や組織によって異なるでしょう。モデリングの進め方には様々な方法があり、その効果が異なるからです。

そもそもモデリングをなぜするか?を考えてみましょう。

モデリングの目的

プロセスモデリングが、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、 ことを目的とした様に、モデリングを行うと、以下のようなことが可能になります(「ソフトウェアプロセスもソフトウェアである」というメタファからすると先祖帰りです)。

● 伝達の道具
 - どのように実現するかを理解する
 - 現状を理解する

●協調作業の前提
 -  ルール
 - インタフェース

●思考・議論の道具
 - 仕様の理解
 - 実現方法の検討

●組織活動
 - 支援・改良
 - 管理

●実行基盤の実現
 - データベースの構築
 - 制約違反の検出

このようにモデリングには多くの目的があります。実際には、これらの複数の目的を考慮しながら、モデリング、レビュー、打ち合わせ、開発を実施します。その比率や順序はプロジェクトや組織によって異なるでしょう。

同じ目的でモデリングを行うとしても多くの手法がありますので、どのような戦略でモデリングを実施するかによってその効率は大きく変わります。

特に小規模なプロジェクトの場合は、必要と思われる全てのモデリングは不可能ですので、目的や方法の取捨選択やその組み立て方がプロジェクトの成否に大きく影響します。

次回は効率的なモデリングの戦略について述べます(効率的なモデリングをマネージメントする その2 - モデリングの戦略 -)。

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

Node-REDでプロトタイピング - お手軽テストダブルのデモ -

年忘れLT宴会<第60回IT勉強宴会>でLT発表&デモしました。

テストダブルの必要性

ソフトウェア開発をしていると、スタブ、ドライバ、モック、シミュレータといったいわゆるテストダブルが必要な時があります。

単体テストする時だけでなく、通信相手の開発が遅くなる時や、並行開発する際にインタフェースだけプロトタイプで開発してそれをテストダブルとして利用するなど、テストや開発で様々なパターンがあるでしょう。

特に初めての環境であったり、ユーザインタフェースの確認、 性能を確認するなど、確認したい部分をプロトタイピングする時には、テストダブルが必要になります。

テストダブルは様々な場面で活躍してくれますが、その開発に工数がかかっていては効果が半減してしまいます。そこで、Node-REDで簡単に開発しましょう!と言う提案です。

デモ内容

バーコードリーダーをあてると、商品の説明と価格が表示される機械を考えてみます。
今回は商品コードだけを使いましたが、顧客毎に割引された価格が表示されるなら、展示会やショールームなどで使えるかも知れません。

商品の説明と価格はサーバーから得ます。端末からHTTP POSTで送信された商品コードで検索し、商品の説明と価格を返します。

クライアント端末は製造に時間がかかるので、Web画面で商品コードを入力し、送信ボタンを押すとサーバーにPOSTして、レスポンスで得られたテキストを表示します。

プログラムの説明

サーバーはひとまずif分でレスポンスを変更する様にしました。DBの代わりにグローバルオブジェクトを用いるとそれっぽくなるでしょう。本格的に作るときは専用のノードがありますので、DBサーバーを立てるか、SQLiteで良いかも知れません。

クライアントはテキスト入力を同一タブ内で有効なフロー変数に保存しておき、送信ボタンを押すとその内容を送信します。テキスト入力ノードのディレイを0秒にして改行で送信すればボタンを無くせますが、拡張性を考慮しました。

テキスト入力ノードをUSBやシリアルから読み出すノードに変更すればバーコードリーダーをつなげられるでしょう。また、RFタグのリーダーなど、他のハードを繋ぐことも可能でしょう。

デモソース

ソースは以下になります。今回は簡単にGUIが開発できるDashboardを使いましたので、右上のメニューにあるパレットの管理でインストールしてから、Node-REDに読み込んでください。

サーバー

クライアント(テストアプリ)

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


« 2017年10月 | トップページ | 2018年3月 »