SmartTraining V8テスター募集してみます


コメント

コメントを投稿

このブログの人気の投稿

Execノードを使う

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はExecノードです。Execノードを使うと外部のコマンドを実行することができます。コマンドが出力した、標準出力や標準エラー出力などをノードから出力できます。 標準出力の内容を出力する 最初に確認するサンプルは「 flows > node-red > function > exec > 01 - Get standard output from external command 」です。 Execノードのプロパティを見ると以下の通りになっています。 実行コマンドは「 echo 」 msg.payload で受け取った値を引数として利用 出力モードは「 コマンド終了時 - execモード 」 コマンド終了時に結果を出力します Execノードには出力ポートが3つあります。 標準出力 標準エラー出力 返却コード 実行すると、標準出力には「 Hello World! 」、返却コードには「 {code : 0} 」が出力されます。この挙動は特に説明することはないかと思います。 標準エラー出力の内容を出力する 次に確認するサンプルは「 flows > node-red > function > exec > 02 - Get error output from external command 」です。外部コマンドのエラーをポートに出力します。中身は先程のサンプルフローとほぼ同じですが、Execノードで存在しないコマンドを実行しています。 実行すると、以下のログが出力されます。これも説明不要かと思います。 実行中に出力する 最後に確認するサンプルは「 flows > node-red > function > exec > 03 - Run external command in spawn mode 」です。出力がコマンド実行中に行われるのがこれまでのサンプルと違う点です。 コマンドはwhieループ内で2秒おきに「 Hello 」を標準出力に出力し続けます。Spawnモードで実行するとループ内でechoコマンドが実行されるたびにログが出力されます。サービスっぽい...
続きを読む

Joinノードを使う（その4）

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はJoinノードの4回目です。終わらねぇ。 確認するサンプルは、 前回 に引き続き「 読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode 」です。 メッセージを結合してkey/valueオブジェクトにする 5段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。 DataノードでCSVデータを送信する CsvノードでCSVデータをJSONオブジェクトに変換する msg.payloadには以下のような値が指定されたメッセージ4つに分解される { name: "Apple", price: 100 } Changeノードでmsg.payload内の値を以下のプロパティに設定する msg.topic = "Apple"（msg.payload.nameの値） msg.payload = 100（msg.payload.priceの値） Joinノードで、2個の受信メッセージごとにmsg.topicの値をキーとしてkey/valueオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadにJSONオブジェクトが指定されていることを確認できます。 メッセージを結合して結合オブジェクトにする 先ほどは結合した値がkey/valueオブジェクトでしたが、6段目のフローでは単純にオブジェクト結合します。ざっくりとした流れは以下のとおりです。 DataノードでJSON配列を送信する nameをキーに持つオブジェクトとpriceをキーに持つオブジェクトを交互に含んでいます（実際、こんなに都合の良いデータが生成されることはあるんだろうか） Splitノードで配列データを個別のメッセージに分割します Joinノードで、2個の受信メッセージごとにオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadに2個ずつのオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。ちなみに、Joinノード...
続きを読む

Travis-CIで環境変数を使う

前回 紹介したSendGrid-Reversiで Travis-CI を使った際に気になった箇所のメモを残します。 Travis-CIを使うためにはプロジェクト内に .travis.yml という名前のファイルが必要です。とりあえず、リポジトリトップ下に置いてポチポチ設定すればいいみたいです。 今回はこんな感じにしてみました。 language: ruby rvm: - "2.0.0" # - "2.1.0" env: - RACK_ENV=test services: - mongodb before_script: - bundle install script: - bundle exec rspec それぞれの詳細はTravis-CIの ドキュメント を見ればよいのでポイントだけ。 実行環境のバージョン指定は一つだけにしてみる 実行環境としてRubyを使っており、通常複数バージョン指定できるのですが、今回はバージョンを一つだけ（上の例だと"2.0.0"だけ）に限定してみました。 これは、テストケースでSendGrid APIを使っている関係上、複数環境でテストをするとテストが並列実行されてしまい、SendGridがテストケースの想定していない状態になってしまい失敗（テンプレート削除のテスト中にテンプレート作っちゃったり）するためです。実行環境毎のテストをシーケンシャルに走らせるためのオプションを見つけられなかったのですが、そんなのあるんですかね？ SendGrid環境も分けるようにしないといけないんでしょうか。それはちょっとキツイなー、と。 晒したくない情報は.travis.ymlではなくSettingsを使う 環境変数は「env:」配下に書いておけばよいのですが、パブリックなリポジトリにアップされた .travis.ymlファイルは公開されてしまうため、晒したくない情報（サービスへのログイン情報など）は書けません。 今回、SendGridへのアクセスを行なうテストケースがあったので、そういった情報をどこに置くかが問題となりました。調べてみるとそういう情報は「Settings」に書けってTravis-CIのヘルプに 書いてありました 。Settin...
続きを読む