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

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

IBM Bluemix を通じて提供されているコグニティブサービス(認識型人工知能)API の1つに Tradeoff Analytics があります:
2015051800


この API を理解するにはデモサイトを参照していただくのがいいと思います:
http://tradeoff-analytics-demo.mybluemix.net/

このデモサイトでは「一覧の中で、自分にあったスマホはどれか?」という命題を、その人が重要視するスペックポイントを明確にした上で候補を上げていく、というものです。

スマホはメモリは多い方がいいし、バッテリーは多い方がいいけど、そうすると重量が重くなります。でも重量は気にする人もいればいない人もいます。また価格は安い方がいいに決まっていますが、メモリやバッテリー、重量などの要素と比べて重要度が高いのか低いのか、は人によって異なってきます。 全てを満たすパーフェクトなスマホはそうそう出てこないでしょうから、結局はどの要素を重要視するかでトレードオフを考えることになると思いますが、どの要素を重要視した場合はどのような結果になるか、を判断してくれる、そんな API です。

例えば上記デモサイトを開くと、デフォルトでは以下の様な表が表示されます:
2015051801


一番上の列がヘッダで、2行目からがスマホの候補リストになっています。表の3列目以降がスペックになっていて、3列目は価格(小さい方がいい)、4列目はRAMメモリ量(多い方がいい)、5列目はスクリーンサイズ(意見が別れるところですが、ここでは大きい方がいい)、6列目はカメラの画素数(多い方がいい)、7列目はメモリ量(多い方がいい)、8列目はバッテリー容量(多い方がいい)、そして9列目は重量(少ない方がいい)となっています。このうちデフォルト状態では価格、スクリーンサイズ、重量の色が緑になっていて、今はこの3点を重要視する人にとってのトレードオフを解析する指定になっています。

もしもこれら以外の点を重要視したい場合は表右下の "View/Edit JSON" と書かれた箇所をクリックして JSON の内容を変更します。例えば「スクリーンサイズは気にしないけど、バッテリー容量は重要!」という場合は以下のように値を変更します。 まずスクリーンサイズは今回意識しなくていいので、JSON 内の columns の中で "key" 値が "screen_size" になっている項目の "is_objective" 値を true から false に変更します。この "is_objective" の値が true のものはトレードオフの考慮に含めて、false のものは含めない、という指定です。なお "goal" 値が "MAX" のものは「(メモリ量など)大きい方がいい」という値、"MIN" のものは「(価格など)小さい方がいい」という値だという指定です:
{
  "key": "screen_size",
  "full_name": "Screen size (inch)",
  "type": "NUMERIC",
  "is_objective": false,
  "goal": "MAX"
},

続いてバッテリー容量はトレードオフに新たに含めたいので、同様にして "key" 値が "battery" になっている項目の "is_objective" 値を false から true に変更します:
{
  "key": "battery",
  "full_name": "Battery (mAh)",
  "type": "NUMERIC",
  "is_objective": true,
  "goal": "MAX"
},

この状態で編集エリア右下の "Back to table" をクリックすると、価格とバッテリー容量と重量の3点が重要視指定された状態の表が表示されるはずです。なお、これら以外でも JSON を変更することで候補スマホの名称や各数値を変更することもできます。全て JSON フォーマットで指定されていることを確認しておいてください:
2015051802


重要視する項目が決まったら、画面右下の "Analyze Sample Data" と書かれたボタンをクリックして、トレードオフを計算します:
2015051803


すると画面下に以下のようなグラフが表示されて、指定した3項目でのトレードオフを考えた結果が表示されます。各スマホアイテムがそれぞれの要素を意識した時にどの位置にあるのか、ということが視覚化されています:
2015051804


例えば、ここでバッテリー項目の下限のスライダーを 1000 から 1500 近くまで移動させると、「バッテリー容量が指定値(1500)以下のものは考慮しない」という指定をしたことになり、画面上部付近にあったいくつかのバッテリー容量の少ないスマホが画面から消えます。これで更に絞込みやすくなります:
2015051805


・・・と、なんとなく「トレードオフ解析」の意味がお分かりいただけたでしょうか? IBM Bluemix で用意されているのは、このような解析を行うための(与えられた条件から、上記の結果グラフを書くための)API が用意されている、という点が特徴です。つまり上記デモサイトのようなことを皆さんの作るアプリケーションの中でも実現できるようになる、ということです。

実際にこの API を利用するには、IBM Bluemix で上記の Tradeoff Analytics サービスをランタイムアプリケーションにバインドして資格情報を確認し、利用のための username と password を取得しておく必要があります
2015051801


ここまで準備できれば API そのものは単純です。取得した username と password を使って Basic 認証を行い、https://gateway.watsonplatform.net/tradeoff-analytics-beta/api/v1/dilemmas に対して、解析させたい JSON(上記の Edit JSON をクリックして編集したもの)をポストするだけです。

成功すると、以下の様な JSON が結果として返ってきます:
{
  "problem": {
    "columns" : [ {
      "key" : "price",
      "format" : "",
        :
        (ポストした JSON の内容)
        :
  },
  "resolution" : {
    "solutions" : [ {
      :
      :
    } ],
    "map" : [ {
      "nodes" : [ {
        "coordinates" : { "x":0.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":1.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":2.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":3.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":4.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":5.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":6.0, "y":0.0 },
        "solution_refs" : [ "5" ]
      }, 
        :
        :
      } ],
      "anchors" : [ {
        "name" : "price",
        "position" : { "x":0.0, "y":0.0 }
      }, {
        "name" : "battery",
        "position" : { "x":4.5, "y":7.8 }
      }, {
        "name" : "weight",
        "position" : { "x":9.0, "y":0.0 }
      } ],
        :
        :
    }
  }
}

結果の JSON の細かい内容は以下のリファレンスを参照していただきたいのですが、大きく3つの箇所を参照することになります。 1つ目は "problem" で、この中にポストした JSON がそのまま記述されているはずです。つまり「この問題に対する実行結果である」ことを示しています。

2つ目は "resolutions" の中の "map" で、ここに散布図を書いた時の各点の座標(x,y)が示されており、またその座標位置に相当するアイテムがあった場合は "solutions_refs" という配列値で示されます。例えば上の例ですと ( 6.0, 0.0 ) の位置に "key" 値が "5" に相当するアイテムがある、ということになります。

最後の3つ目は "resolutions" の中の "anchors" で、これが指定した各トレードオフ要素(この例では価格とバッテリー容量と重量)が散布図上のどの位置にあるかを示しています。


後はこの結果を受け取った側でどのように見せるか、という問題になります。チャート描画の API を使ってもいいし、Canvas を使って自分で記述してもいいと思います。ここから先は開発者やデザイナーの腕の見せ所と言えます。そういう意味ではここのデモサイトはなかなか良くできてますよね。


というわけで、これまでにこのブログで紹介してきたコグニティブサービスとは少し(特に実行方法の面で)毛色が違うサービスと言えます。API 実行時に指定フォーマットの JSON を作る必要があるのが少し面倒ですが、トレードオフを意識する要素と、それらの値は大きい方が嬉しいのか小さい方が嬉しいのかの情報、そしてアイテムの一覧を JSON にしてポストすれば結果が返ってくる、というものです。REST API そのものはシンプルなのでエクセルのような表計算からも実行できると思っています(エクセルだと逆に結果の視覚化が難しいかも・・)。


なお、ここで紹介した Watson Tradeoff Analytics API について、詳しくは API リファレンスを参照してください:
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/apis/#!/tradeoff-analytics
 

(注 この記事の内容は古くなっています。新しい情報はこちらを参照してください)


Bluemix を、特に IoT 関連サービスの開発で Bluemix を使っていると、データを Cloudant に格納するのが便利です。Node-RED スターターボイラープレートに照準装備されていることもあるし、データ形式が機器ごとに異なるセンサーのデータをデータベースに格納しようとすると、テーブル定義の不要な NoSQL データベースの方が楽です。

でも NoSQL に格納されたデータは再利用が難しいです。SQL も使えないのでクエリーでデータを選別することも難しく、データを貯めるまではいいのですが、その後の利用時に手間取りがちになってしまいます。。。

そんな問題を解決する目的で IBM dashDB が提供されています。これは DB2 BLU Acceleration 技術を使った統計用 DB2 の DBaaS です。特筆する機能の1つに Claudant からの単方向レプリケーション機能が装備されていて、Claudant の特定のデータベースに格納された内容を dashDB のテーブルにレプリケーションできる、というものです。レプリケーション後は dashDB のデータとして利用できるので、普通に SQL のクエリーを使うこともできますし、カラムナストアを使った高速な統計機能を使うこともできますし、R 言語を使って解析することもできます。

データが dashDB に格納されてしまえば、こっちのもの、という感じ。 なので大量のデータを Cloudant に格納するだけして、解析が必要なデータは dashDB にレプリケーションする、という使い方がビッグデータ時代ではとてもリーズナブルなわけです。


運良く(?)Cloudant も dashDB も IBM Bluemix のサービスとして提供されています。この単方向レプリケーション機能を実際に試してみました。その時の様子を紹介します。

まず Bluemix 上の Node-RED エディタを使って IoT フローアプリケーションを作ります。このあたりの手順はこちらも参照ください。とりあえずシミュレータを使うなどして機器デバイスから発信される大量のセンサーデータを Cloudant に格納します:
2015051601


この Cloudant に格納されたデータを Bluemix 上から確認してみます。NoSQL なので、データベース内のデータ一覧を見ると中身が少しわかりにくいかもしれません。
2015051602


1つのデータを選択して詳細を見ると、より理解しやすい形で確認できます。この例では time や objectTemp, ambientTemp, accelX, ... などのセンサーデータが JSON 形式で格納されていることが確認できます:
2015051603


ではこのサービスにレプリケーション先となる dashDB サービスを追加します。アプリケーションの画面から「サービスまたは API の追加」をクリックします:
2015051604


ビッグデータカテゴリの中にある dashDB を選択してプロジェクトに追加します:
2015051605


念のため。dashDB は無料枠のある有償サービスなので、そのサービス価格を確認しておきます。デフォルトの Entry プランの場合は 1GB データまでは無料。20GB までは月5250円で使うことができます(最初の30日間はデータ量に関わらず無料)。ちなみにこのサービスで使っているソフトは、ライセンス契約で買うとものすごく高いです(苦笑)。ある意味でこれをクラウドから従量課金で使えるのはお得です。特に無料枠で使うつもりの方はデータ量に気をつけてください:
2015051606


プロジェクトに追加後の画面です。dashDB サービスが追加されたことを確認します:
2015051607


ではこの追加した dashDB に対して、Cloudant のデータを単方向でレプリケーションする設定を行います。まず Claudant 側の接続情報が必要なので、Cloudant サービスの「資格情報の表示」部分をクリックします:
2015051608


以下の様な情報が表示されます。host と username, password, そして Cloudant 内で使っていて、dashDB にレプリケーションしたいデータベースの名前をメモしておきます:
{
  "cloudantNoSQLDB": [
    {
      "name": "dotnsf-nodered-cloudantNoSQLDB",
      "label": "cloudantNoSQLDB",
      "plan": "Shared",
      "credentials": {
        "username": "(ユーザー名)",
        "password": "(パスワード)",
        "host": "(ホスト名)",
        "port": 443,
        "url": "...."
      }
    }
  ]
}

これらの情報が確認できたら dashDB への単方向レプリケーションを設定します。ダッシュボードから dashDB アイコンをクリックします:
2015051609


dashDB の説明画面が表示されるので、"LAUNCH" ボタンをクリックします:
2015051610


初期画面が表示されます。レプリケーションは初期データのロードとして設定するので "Load your data" ボタンをクリックします:
2015051611


次の画面で "Cloudant" を選択し、"load" ボタンをクリックして Cloudant からの単方向レプリケーションで初期データをロードすることを指定します:
2015051612


次の画面で Cloudant の情報と、レプリケーション先となる dashDB のデータベース名を指定します。Cloudant の情報として必要なのは以下の3点です:
 データベースURL : https://(接続情報の host の値)/(目的のデータが格納されているデータベース名)
 ユーザー名: (接続情報の username の値)
 パスワード: (接続情報の password の値)

また dashDB のデータベース名として指定するデータベースはこの段階で存在している必要はありません。存在していない場合は新規に作成します。最後に "Start Sync" ボタンをクリックして同期を実行します:
2015051613


同期の設定が正しければ、この同期が "Running" ステータスで有効に設定されたことが表示で確認できます:
2015051614


改めて "Tables" タブを選択し、テーブルにレプリケーション先に指定したテーブルを選択すると、Cloudant のデータが dashDB のテーブルとして自動的にマッピングが定義されていることが確認できます:
2015051615


ここで "Browse Data" をクリックすると、実際のデータレコードが確認できます。元々は Cloudant に含まれていたデータレコードが dashDB に格納されています。また、これはデータのコピーではなく単方向レプリケーションなので、今後 Cloudant にデータが追加されると自動的にこの dashDB のこのテーブルにデータが複製されてくることになります:
2015051616


これで IoT のセンターデータが SQL の使える dashDB に同期で格納できることが確認できました。センサーデータは書き換えることはあまり考えにくく、統計目的で参照することが多いと思われるので、単方向レプリケーションでもあまり問題にならないと思っています。これでセンサーからのビッグデータを統計目的で使う、というためのシステム基盤が簡単に作れることが分かりました。

 

久しぶりのノーツネタです。


ノーツ9のクライアントでカレンダーを開くと、左下にこのようなセレクターが表示されます:
2015051501

ここで選択した形式でカレンダーが表示されます。自分は1週間単位で見ることが多いので、「1週間(勤務日)」で使っていることが多いです。なお「1週間(勤務日)」は月曜から金曜までの5日間を表示(土日は表示しない)、「1週間」だと月曜から日曜までの7日間が表示されます。

最近、自分の勤務が土日も含まれることが多くなってきました。というわけで、勤務用の5日表示では大事な仕事を忘れてしまいかねません。かといって「1週間(勤務日)」を残したまま「1週間」を選ぶのもわかりにくいというか・・・

こんなときこそカスタマイズです!さっそくドミノデザイナーでメールテンプレートを開いて、共有要素 - アウトライン内の NotesCalendarOutline を選択します:
2015051504


その中の「1週間」を書かれたラベルを選択して、ラベルの値を「1週間」から(例えば)「オレの1週間」に変更して保存します:
2015051502


これでノーツカレンダーを開き直すと、「オレの1週間」が選択できるようになり、選択すると7日間分のカレンダーが表示されます。これで安心して週末にも仕事のスケジュール入れられます(涙)。
2015051503




 

このページのトップヘ