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

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

IBM Cloud からはオープンソースのブロックチェーン基盤である Hyperledger Fabric をベースとしたマネージドなブロックチェーン環境が提供されています。この 3/21 からは Starter Membership Plan という、名前の通りに小規模向けの比較的安価なプランも提供されるようになりました。2018/03/25 時点ではベータ版で、通常プランと比較していくつかの制約はありますが、無料で利用できます。早速使ってみました。今回のブログエントリではサービスを選択して利用可能にする所までの手順を紹介します。あくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/25 時点での情報であることをご了承ください。


また、以下で紹介する IBM Cloud から提供されているブロックチェーンサービスは、IBM Cloud の無料アカウント版であるライトプランからは利用できません(2018/03/25 時点)。以下で紹介する Starter Membership Plan のベータ版は無料ですが、ライトプランのアカウントからはサービスを選択することはできません。実際に試す場合はクレジットカードを登録するなどしてスタンダードプラン等に移行してからご利用ください。


IBM Cloud にログインしてからカタログを表示し、ブロックチェーンカテゴリーを選択すると、対象サービスが "Blockchain" だけに絞り込まれます。これを選択します:
2018032401


次の画面でリージョンやプランを選択します。今回紹介する Starter Membership Plan は 2018/03/25 時点では米国南部リージョンからのみ提供されています。そのためロケーションを選択する箇所で「米国南部」を選ぶようにしてください:
2018032402


画面を下にスクロールすると利用プランの選択画面になります。上記で米国南部リージョンを選択しているとここが選択肢になっていて、Starter Membership Plan か Enterprise Membership Plan が選べるようになっているはずです(米国南部以外のリージョンだと有料の Enterprise Membership Plan のみ)。ここで Starter Membership Plan を選択して「作成」ボタンをクリックします:
2018032403


なお上図にも書かれているように Starter Membership Plan の場合、以下のような制約事項があります。シングルピア環境なので多数決をとるようなスマートコントラクトを実装することはできませんが、アプリケーションとしての実装はほぼ変わらないものを動かすことが可能になります:
・組織は2つまで
・各組織ごとに1ピアまで


サービスが作成されるとダッシュボード内のサービス一覧内にブロックチェーンサービスが表示されるようになります:
2018032404


作成したブロックチェーンサービスを選択するとブロックチェーンサービスの概要が表示されます(この辺りはプランによる違いはないと思われます)。ここから実際にブロックチェーンを操作したり管理するためのダッシュボードを開いてみます。「管理」タブの「起動」ボタンをクリックします:
2018032405


すると別ウィンドウでブロックチェーン環境のダッシュボードが表示されます。下画面ではトランザクションの順番を決定するオーダラーや、CA(認証局)、そしてピアとなるサーバー環境が動いている様子が確認できます:
2018032406


これまで自分で Hyperledger Fabric 環境を構築しようとすると、サーバー環境を用意した上でこれらの各種サーバーを自分で作って運用する必要がありました。そこまでの構築作業とサーバーとしての運用部分を IBM Cloud に任せて、実際のアプリケーション開発・実行やユーザー登録といった実務に集中できる環境として提供されていることが分かります。ブロックチェーンに興味のある方は是非今のうちに色々使ってみてはいかがでしょうか?

なお、今回は IBM Cloud 上にサービスを作る作業までを紹介しました。次回以降でこのサービスにビジネスネットワークアプリケーションをデプロイして動かせるようになるまでの手順を紹介する予定です。



インスタグラムの API を使うと、インスタグラムの写真を使ったアプリケーションを開発することができます。その開発例を準備段階から説明します。詳しくは後述しますが、今回はインスタグラム API の "SandBox" モードを使ったサンプルを紹介します。


【アプリケーション登録】
まず大大大前提としてインスタグラムのアカウントが必要です。こちらは取得済みとした上で以下を記載します。

インスタグラム API を使うには、インスタグラムデベロッパーであらかじめアプリケーションを登録しておく必要があります。これから API を使って作るアプリケーションを最初に登録しておく必要がある、という意味です。

というわけでまずは PC からインスタグラムデベロッパーにアクセスしてログインし、"Manage Clients" をクリックします:
2018032001


すると現在登録済みのアプリケーションの一覧が表示されます(まだ1つも登録していない場合は何も表示されません)。新たにアプリケーションを登録するにはこの画面で "Register a New Client" をクリック:
2018032002


新規登録画面ではまず最初に "Security" タブを選んで、"Disable implicit OAuth" のチェックを外しておきます:
2018032101


改めて "Details" タブに移動し、必要な項目を入力します。Application Name(アプリケーション名)は任意に指定できますが、"Instagram" や "Insta", "IG" といった文字列は使えない、という規約があるようです。後は Description(説明)を記入して、Company Name(会社名)は個人名でも空でもいいようです。大事なのは Website URL と Valid redirect URIs、ここはこの後の OAuth 認証で使うため、(アプリケーションとして動いていなくてもよいので)実在する URL を指定する必要があります。なおここで指定する値は後から編集することも可能です:
2018032102


すべて指定したら下にスクロールして「私はロボットではありません」の横をチェックします:
2018032103


自動化されたロボットでないことを証明するための質問に答えます。下の例では画像からお店を選べ、とのこと:
2018032104


まあこれとこれとこれ、、かな?? という感じにチェックして確認ボタン:
2018032105


正しい選択ができているとロボットではないことが証明できて、"Register" ボタンがクリックできるようになります:
2018032106


無事にアプリケーションの登録が完了し、CLIENT ID が取得できました。ここに表示されている CLIENT ID の値はこの後に利用するので控えておいてください:
2018032107


【アクセストークン取得】
インスタグラムの API は「アクセストークン」と呼ばれる文字列を使って利用します。このアクセストークンは上記手順で指定した情報を知っている(指定できる)人だけが取得できます。なお今回対象としている SandBox モードの場合、1つの登録アプリケーションにつき、アクセストークンが取得できるユーザーは20人までという上限がありますが、以下で紹介するアプリケーションの場合は本人だけが使う想定なので問題ないと思っています。

ウェブブラウザで以下の URL にアクセスします:
https://instagram.com/oauth/authorize/?client_id=(Client ID)&redirect_uri=(Redirect URI)&response_type=token&scope=public_content

(CLIENT ID) 部分には上記で取得した CLIENT ID の値を、(Redirect URI) 部分には取得時に指定した Valid Redirect URI の値にそれぞれ置き換えて指定します。すると以下のような画面になり、Instagram の画像やプロフィール情報にアクセスすることを許可するか?という確認画面が表示されるので "Authorize" をクリックして許可します:
2018032108


するとブラウザ画面が切り替わり、Rediret URI で指定した URL に転送されます。この時の URL には acess_token=XXXXXX..XXXXXX という形でアクセストークンが付与されています:
2018032109


この値がアクセストークン値で、この文字列を使うことでインスタグラム API を利用することができるようになります。この値を控えておきます:
https://dotnsf-myphotos.us-east.mybluemix.net/#access_token=XXXXXX..XXXXXX


【サンプルアプリケーション実行】
インスタグラム API を使った Node.js のサンプルウェブアプリケーションをこちらに用意しておきました:
https://github.com/dotnsf/myphotos

2018032101


このコードをダウンロード&展開するか、git clone して手元に用意してください。そして settings.js ファイルをテキストエディタで開き、exports.access_token の値を先程確認したアクセストークンの値に編集して保存します:
2018032101


2018032102


この状態のアプリケーションを指定した Redirect URI で動くように転送/コピー/デプロイします。これで準備は完了です。


実際の動作を確認するには(できればスマホで)Redirect URI にアクセスします。すると自分のインスタグラムの最新20件の画像/動画が確認できるアプリケーションが表示されます:
IMG_1999


次/前の画像を見るには左右に(フリックやマウスドラッグで)スライドさせます:
IMG_2001
 (↑伝わりにくいけど、右から左へスライド中の様子)


すると次/前の画像に切り替わります:
IMG_2002


表示されている画像をタップすると、インスタグラム上の同画像ページに移動し、タイトルやタグ、コメントも確認できます:
IMG_2003


インスタグラムの API を使って自分の画像をカルーセル表示する、というサンプルでした。実際に API が正しく動いて画像を取得できていることも確認できました。



【Sandbox モードについて】
Sandbox モードは誰でも気軽にインスタグラム API を使えるように 2016 年6月に用意されたモードです。アカウントと(上記の)アプリケーションの登録をするだけで使えるようになるというメリットがあります。

一方で、その利用には制約があります。使える API やその結果は限られたものだけです。私個人が確認した限りでは、ユーザー名からユーザー ID を検索する API は自分自身の ID については期待通りに動いたのですが、フォローしているユーザーや他のユーザーの検索はできませんでした(実行結果が空だった)。といった制約があり、この制約をなくすには Sandbox モードではなく、正式な API を利用する必要があり、そのためにはアプリケーションの申請が必要になります。個人的に正式な申請をした経験はないのですが、ウェブ上にはそういった情報もあるようです。1つだけ参照リンクを貼っておきます:
Instagram APIの審査を通した人に話を聞いてみた。

また Sandbox モードにおける制約等の(最新の)情報は公式ドキュメントを参照ください:
Sandbox Mode









Node-RED は GUI で便利にデータの流れを定義することができるビジュアルデータフローエディタです。HTTP(S) や MQTT など多くのプロトコルにも対応しており、これまでプログラミングを記述しないと実現できなかったようなデータの流れを、個別の機能を持ったノードを組み合わせることで、ほぼコーディングレスで実現できるという点が画期的なツールです。このブログでも何度か紹介してきました。

このエントリで紹介した時のデータフロー。これだけでデータベース入出力を行うウェブアプリケーションを作ってます)
2018031301


さてそんな簡単で便利な Node-RED ですが、「Node-RED だと(一般的なプログラミングと比較して)処理が複雑になるケース」もあります。こういう視点で語られているドキュメントを目にすること-がなかったこともありますが、Node-RED がより多くの現場で使われていく上での適材適所を考える上では必要になってくると思っていることもあり、そんな例を紹介しようと思いました。

今回、Node-RED と比較するプログラミング環境はサーバーサイド JavaScript である Node.js とします。もともと Node-RED 自体が Node.js 上で動くアプリケーションであり、Node-RED の function ノード内では JavaScript を直接記述することもできるという点で、比較対象としては相応しいのではないかと思っています。

で、この「Node-RED での処理が複雑になるケース」の典型例の1つが if 分岐処理だと自分の拙い経験上で思っています。if 分岐はプログラミング言語を学ぶ中でのかなり早い段階で遭遇することになる基本的な処理ですが、Node-RED では必ずしも基本的とは言えない内容だと感じています。

例を挙げて説明します。例えばこんな処理を行うケース:
・気温(temp)と湿度(humid)という2つの変数値から「不快」か「不快ではない」かを判断する。
・気温が 30 以上で、かつ humid が 50 以上だと不快
・気温が 30 未満で、かつ humid が 80 以上だと不快
・それ以外は不快ではない

よくあるレベルのシンプルな分岐処理ですよね(湿度は%単位で与えられるものとします)。この処理を Node.js (や他の一般的なプログラミング言語)の if 分岐で行おうとすると、こんなシンプルな感じになると思います:
if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

では同じ処理を Node-RED で実現しようとするとどうなるでしょうか?仮に msg.payload.temp と msg.payload.humid にそれぞれ温度と湿度の値が入っているという前提で作ることを考えてみます。

Node-RED で条件分岐を行うノードは "switch" ノードです。機能カテゴリ内にある switch ノードをキャンバスにドラッグ&ドロップします:
2018031302


ドロップした switch ノードをダブルクリックして、処理内容を設定する画面に切り替えます:
2018031303


このノードでは温度(msg.payload.temp)に関する条件分岐を行うことにします。今回は30度以上か、30度未満かで処理を分岐する必要があります。というわけで、プロパティの値を (msg.)payload.temp にして、その条件を指定する部分では「30以上の数値」となるように指定します。またノードの表示用の名前を「温度」と設定します:
2018031304


今回の処理では温度が「30 以上の場合」と「30 未満の場合」の2つの条件に分岐する必要があります。前者は上記で指定したので後者を追加します。この画面内の「追加」ボタンをクリックします:
2018031305


すると条件部分が1行追加され、もう1つの条件を指定できるようになりました。ここでは「 30 未満の数値」となるような条件を指定します(下図のようにするか、または後述のように"otherwise"(その他)という選択肢でも同じ結果になります)。 これで msg.payload.temp の値が 30 以上であれば1へ、30 未満であれば 2 へ行く、という分岐処理が定義できたことになります。ここまでできていることを確認して「完了」ボタンをクリック:
2018031306


すると switch ノードに指定した名前が表示されるのと同時に、ノード右側の出口が2つに増えていることが分かります。上側の接続子が1、下側の接続子が2を意味しており、ここから条件を分岐して処理できるようになりました:
2018031307



続けて湿度の条件を追加します。温度 switch ノードの①に別の switch ノードを追加して接続します:
2018031308


追加した switch ノードをダブルクリックして編集ダイアログを出し、以下のように設定します。 名前は「湿度」、プロパティは湿度の値である (msg.)payload.humid 、ここは温度が 30 度以上の場合に処理されるノードなので、分岐の条件は「 50 以上の数値」か「otherwise(それ以外)」として、最後に「完了」をクリックします:
2018031309


この時点でキャンバス上は以下のような2つのノードが設定されているはずです。③は温度が30度以上で、湿度は50以上なので「不快」、④は温度は30度以上ですが、湿度は50未満なので「不快ではない」という分岐がされたことになります:
2018031310


では続けて②のノードの続きの処理を追加します。更にもう1つの switch ノードをキャンバスに追加し、温度 switch ノードの②と接続します。そしてノードの設定内容を以下のようにします。先程の湿度ノードに近い内容ですが、このノードは温度が 30 度未満の場合に処理されるので、湿度が 80 以上だった場合に不快、それ以外であれば不快ではないと分岐するノードにしています:
2018031301


ここまでの作業でキャンバスには以下のように3つの switch ノードが用意されているはずです。そして③と⑤が不快、④と⑥が不快ではない場合の処理を行う流れになります:
2018031302


後はこの分岐した条件にあわせて処理を繋げていけばよいので、例えばこんなフローになっていくんでしょうかね:
2018031303


というわけで、目的の条件分岐を Node-RED で実現することはできました。 ただ Node.js では以下のような超シンプルな分岐処理だった割にはフローが複雑になってしまっている面は否めません。これが更に複雑な分岐処理だった場合、Node-RED ではどれだけ switch ノードを並べないと行けなくなるのか・・・:
if( ( temp >= 30 && humid >= 50 ) || ( temp < 30 && humid >= 80 ) ){
  //. 不快と判断

}else{
  //. 不快ではないと判断

}

原因というわけではないのですが、Node-RED の switch ノードは単一のプロパティに対する条件分岐しか行えないため、複数の値を元に条件を分岐するようなケースではどうしてもノードを多用する必要が出てきてしまいます。この部分だけを切り取って結論にはできないと思いますが、Node-RED では if 文による分岐処理は必ずしも簡単ではないということだと思います。



このページのトップヘ