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

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

2015年05月

今年も(AKB48 選抜)総選挙の季節がやってきました。

「投票権はCDに付いているもの」と思っている人も多そうですが、実際は少し異なります。確かに CD にもついていますが、AKB48 公式ファンクラブ会員になるか(1)、AKB48 公式スマートフォンアプリ会員になるか(1)、AKB48 オフィシャルネット会員になるか(1)、各ユニットのモバイル会員になるか(4)、各ユニットの動画見放題会員になる(4)ことでも、それぞれ1票を入手することができます。ただしユニット毎のモバイル会員および動画見放題会員になるにはいわゆるキャリア決済が必要なので、MVNO ではない主要キャリアの契約が必要です。 つまりCDを買わなくても、キャリア契約の携帯電話を1台持っていれば最大で11票入手することができます(逆を言えば、12票以上入手するにはCDを買うことになります)。キャリア契約を2つ持っている人であれば更に8票入手できる、ということです。

簡単に票を入手するには CD を購入するのが一番簡単です(握手券もついてきます)が、最も手軽に(安く)票を入手するにはユニットのモバイル会員になることです(税込324円)。 その方法を紹介します。


まずキャリア契約のある携帯電話およびスマホでモバイル会員サイトにアクセスします。これは AKB48 公式モバイルサイト(http://www.akb48.co.jp/mobile/)です:
写真 01


「投票はこちら」と書かれたリンクをクリックすると、新規会員登録ページに移動します。ここで契約しているキャリアを選びます。自分の場合は au スマホなので一番下をクリック:
写真 02


ここからは au スマホ/iPhone の場合の例です。他のキャリアの場合はそれなりの方法(苦笑)で進めてください。まず au ID でログイン:
写真 03


で「ご利用上の注意」を読んで「同意」:
写真 04


この先からは課金が開始されます。直後に退会しても月額324円。血の一票と考えれば安いものです、迷わず「購入」:
写真 05


最後に au かんたん決済の規約を確認して「同意する」、と。au 以外の方も同様の方法で決済まで行ってください:
写真 06


はい、これでルビコン川の向こう岸です。もう後戻りできません。そのまま総選挙の「投票受付中」ボタンをクリック:
写真 07


ここからは投票画面です。推しメンを選びましょう。チームから検索してもよし、名前で検索してもよし。ちなみにここは AKB48 のモバイル会員サイトですが、投票はどのユニット所属メンバーであっても(立候補していれば)できます:
写真 08


自分はフレッシュ・レモンに一票!
写真 09


投票完了、簡単でした。物足りない人は(笑) AKB48 以外のモバイル会員サイトに移動して同様の会員登録をすればあと3票投票できます:
写真 10


このまま会員でいてもいいと思いますが、投票のためだけにモバイル会員になった人はここで退会しておくと来月分の課金はされません。退会はトップページの一番下のメニューから「退会方法」を選択:
写真 11


思いとどまるかどうか聞かれるので「退会」:
写真 12


退会理由を書いて「送信」:
写真 13


まだ続きます(苦笑)。ここでキャリア決済の退会も行うのでキャリアを選択:
写真 14


au であれば au 簡単決済からも退会します。「解約する」をクリック:
写真 15


はい、全て終わりました。また来年同じ手順で投票しましょう:
写真 16


投票締め切りは6月5日(金) 15:00 です。投票はお早めに!




 

「ちょっとした MySQL サーバーが使いたい」時に、ClearDB を使うようになりました:
ClearDB - The Ultra Reliable, Geo Distributed Cloud Database For Your MySQL Applications

ClearDB はクラウド上で提供されている MySQL データベースです。いわゆる DBaaS で、バックアップやメンテナンスといった面倒な管理作業は提供側がやってくれます。いわば「契約して使うだけ」の MySQL ホスティングサービスです。用途に応じてサービスレベルや価格が分けられていますが、"ignite" と呼ばれるデータ容量5MBの最小構成であれば無料で使えます。3306番ポートも開放されているので、mysql コマンドから接続して使うこともできちゃいます。

「5MB じゃ何も使えない!?」と思うかもしれませんが、MySQL の動作確認には充分といえます。足りない場合は有料サービスに移行すればいいだけです。

で、この ClearDB を普通に使おうとすると無料サービスでもクレジットカードの登録が必要なんですが、IBM Bluemix 経由で使うと何故か不要です(苦笑)。 
※IBM Bluemix は契約後最大30日は無料で使えますが、その期間中は IBM からも ClearDB からもクレジットカード情報を求められることがない、という意味です。


というわけで、IBM Bluemix を使って ClearDB の ignite プラン(無料サービス)を1つ作成するまでの手順を紹介します。 ・・・と言っても、IBM Bluemix 的には他のサービスとほぼ変わりなく使うことができます。

まず普通に IBM Bluemix にログインします。そして ClearDB サービスを紐付けるためのランタイムを1つ作成します(既存の作成済みランタイムがあればそれを使ってもかまいせん)。下図では "dotnsf-php-20150527" という名前のランタイムを使っていて、この場合を想定して以下を説明します:
2015052701


そのランタイムのダッシュボード画面から「サービスまたは API の追加」をクリックして、「データ管理」カテゴリの "ClearDB MySQL Database" を選択します:
2015052702


サービスの概要が表示されます。アプリとしては選択したランタイム、プランは "Spark DB"(現時点ではこれしか選択できないと思います)が選択されていることを確認します。この場合は「5MB 無料」です。最後に「作成」ボタンをクリックして、このサービスをランタイムに追加します:
2015052703


こんな画面が出たら「再ステージ」をクリックして、ランタイムを再ステージングしてください。この辺りは IBM Bluemix の他のサービス追加作業と何も変わりません:
2015052704


再ステージング完了後の画面です。選択したランタイムに ClearDB サービスが追加できました:
2015052705


では ClearDB の「資格情報」と書かれた所をクリックして、この ClearDB に接続するための情報を調べます:
2015052706


このような情報が表示されます。この JSON 文字列はランタイムの環境変数 VCAP_SERVICES として動的に取得することもできます:
{
  "cleardb": [
    {
      "name": "ClearDB MySQL Database-in",
      "label": "cleardb",
      "plan": "spark",
      "credentials": {
        "jdbcUrl": "jdbc:mysql://UUUUUUUUUUUUUU:PPPPPPPP@us-cdbr-iron-east-02.cleardb.net:3306/ad_DDDDDDDDDDDDDDD",
        "uri": "mysql://UUUUUUUUUUUUUU:PPPPPPPP@us-cdbr-iron-east-02.cleardb.net:3306/ad_DDDDDDDDDDDDDDD?reconnect=true",
        "name": "ad_DDDDDDDDDDDDDDD",
        "hostname": "us-cdbr-iron-east-02.cleardb.net",
        "port": "3306",
        "username": "UUUUUUUUUUUUUU",
        "password": "PPPPPPPP"
      }
    }
  ]
}

この JSON 文字列の "credentials" 内の情報を使うことで ClearDB のデータベースにアクセスすることができます。ホスト名は "hostname" の値(us-cdbr-iron-east-02.cleardb.net)、データベース名は "name" の値(この例では ad_DDDDDDDDDDDDDDD)、ポート番号は "port" の値(3306)、ユーザー名とパスワードはそれぞれ "username" と "password" の値(UUUUUUUUUUUUUU と PPPPPPPP)になります。

このデータベースは(クラウド上の)普通の MySQL として使えるため、IBM Bluemix のランタイム以外からも使えます。実際に mysql クライアントコマンドで接続してみました。当たり前ですがちゃんと使えそうです:
2015052707



上でも書きましたが、このプランではデータ容量が 5MB なので大したことはできません。でも最低限の動作確認や MySQL への接続確認として常に MySQL サーバーがクラウド上にあって使える、という環境は魅力的です。

IBM Bluemix のアカウントがあると、こんな環境も無料で入手できる、ということになります。というわけで、IBM Bluemix のアカウントを作りましょう(笑)。


(特にクラウド環境で)MySQL データベースを使って運用している皆さん、データのバックアップはどうしてますか?

色々な目的や用途、制限の中で使っているので正解は1つではないと思っています。中には「初めからバックアップ込みの DBaaS サービスを使っている」という人もいるでしょう。コスト的に問題なければそれがベストかもしれません。

自分の場合、ある環境では cron で一日一回 mysqldump で取り出した内容を圧縮してそのままオブジェクトストレージに丸投げ、という方法を採用していたりします。オブジェクトストレージにダンプデータが残っていれば、そこからリストアできる、という考え方です。ケースバイケースではあるし、クラウド業者のオプションとかにも依存はしますが、オブジェクトストレージは手軽に使えて、比較的安価な割にデータポータビリティの高いデータストレージなので、コスパ的にもあっていました。これだけだとダンプにないデータやダンプ後に変更があったデータは救えませんが、そこまでシビアなデータ管理を要求されることもないデータベースであれば、手軽なこの方法はオススメでもあります。

一方、データが失われてからリストアするのにあまり長い時間かかることが許されないような場合や、救えないデータがあってはまずい場合はこの方法は向きません。データベースサーバーを多重化するなどして「最悪、1台死んでもいい」環境を構築することになります。


最近、自分の管理している環境下で MySQL データベース(正確には MariaDB だったけど)の Master-Slave レプリケーション環境を構築する機会がありました。その時の作業を記録しておきます。

まず前提条件として、以下のような環境を想定します:
- MySQL 5.x サーバーが1台稼働中。レプリケーション設定はしていない。
- MySQL サーバーを新たにもう1台追加して、Master-Slave の2台構成にする。
- 現在使っているサーバーを Master、新たに追加するサーバーを Slave とする。
- レプリケーションの対象とするデータベースの名前は mydb とする。

以下、順に説明します。現在稼働中の MySQL サーバーを「A」と呼ぶことにします。このサーバーが Master サーバーになります。また、新たに追加する MySQL サーバーを「B」と呼ぶことにして、このサーバーを Slave サーバーとして運用します:


1. Slave 用 MySQL サーバー環境の構築(B)

Slave サーバーとなる新しい MySQL サーバー環境を構築します。この辺りを参照してください:
CentOS に MySQL をインストール/セットアップする

Slave 側にも MySQL 環境が構築できたら、mysql コマンドでレプリケーションを行う先のデータベースを作成しておきます。UTF-8 指定などは環境に合わせて適当に:
mysql > create database mydb character set utf8;

2. レプリケーション用ユーザーの作成(A)

MySQL コマンドを使って Slave が Master のバイナリログを参照する際に接続するユーザーを作成します。
この例ではユーザー名 repl、パスワード password で、192.168.1.XXX/24 環境からの接続のみ許可されたユーザーとしています:
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.0/255.255.255.0' IDENTIFIED BY 'password';

3. Master 用の設定(A)

具体的には Master のバイナリロギングを有効にし、かつサーバーを識別するための ID を /etc/my.cnf 内に追加設定します(MariaDB の場合は /etc/my.cnf.d/server.cnf):
# vi /etc/my.cnf

[mysqld]
log-bin=mysql-bin
server-id=1001
ここまで設定したら MySQL サーバー(A)を再起動します。


4. レプリケーション用ユーザーの作成(B)

MySQL コマンドを使って Slave 内にデータを複製するユーザーを作成します。この例ではユーザー名 repl、パスワード password としています:
mysql > GRANT ALL PRIVILEGES ON *.* TO 'repl'@localhost IDENTIFIED BY 'password';

5. Slave 用の設定(B)

サーバーを識別するための ID を /etc/my.cnf 内に追加設定します(MariaDB の場合は /etc/my.cnf.d/server.cnf)。この ID はシステム全体でユニークにする必要があるため、3. で設定した内容とは異なるものにします:
# vi /etc/my.cnf

[mysqld]
log-bin=mysql-bin
server-id=1002
ここまで設定したら MySQL サーバー(B)を再起動します。


6. バイナリログ位置の確認(A)

Master 側サーバーの MySQL コマンドで以下を実行して、その結果をメモしておきます:
mysql > FLUSH TABLES WITH READ LOCK;

mysql > SHOW MASTER STATUS;

+----------------------+-----------+--------------+------------------+
| File                 | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------------+-----------+--------------+------------------+
| mysql-bin.000031     |       285 |              |                  |
+----------------------+-----------+--------------+------------------+
この結果の File がバイナリログ名、Position が現在位置です。これらの値は後に使います。

なお、"SHOW MASTER STATUS;" の実行結果が "Empty Set" と表示される場合は、File は ""(空文字)、Position は 4 とみなすことができるので、これらの値を後に使うことになります。

7. スナップショットの作成(A)

続いてこの状態のデータベースのスナップショットを取得します。6. で "FLUSH TABLES WITH READ LOCK" を実行しているのでデータベースにはロックがかかっています。この状態で別のコンソールやターミナルを使って以下のコマンドを実行します:
# mysqldump -u root -p mydb --lock-all-tables > mydbdump.db
これで指定した mydb データベースのダンプを mydbdump.db というファイルに取得することができます。取得後は再度もう一つのターミナルに戻って以下のコマンドを実行し、ロックを解除します:
mysql > UNLOCK TABLES;

8. スナップショットのコピー(AまたはB)

7. で取得したスナップショットファイルを(mydbdump.db)、Slave サーバーとなる B に転送します。SFTP などを使って A から B へ送ってもいいし、B から A に取りに行ってもいいし、全く別の方法でも構いません。スナップショットファイルが B のディスク内にあって、9 のコマンドが実行できさえすればいい、ということです。


9. スナップショットの展開(B)

7. で取得した Master のスナップショットを Slave である B の mydb データベースに展開します:
# mysql -u repl -p mydb < mydbdump.db

10. Master 情報登録(B)

続いて MySQL コマンドで Slave に Master の情報を登録します:
mysql > CHANGE MASTER TO
  MASTER_HOST='192.168.1.XXX',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000031',
  MASTER_LOG_POS=285;
なお、ここで指定する値ですが、MASTER_HOST は A のサーバー名(IPアドレス)、MASTER_USER は複製用(Aの)ユーザー、MASTER_PASS はそのパスワード、MASTER_LOG_FILE は 6. で取得した File の値、MASTER_LOG_POS は同 Position の値です。


11. レプリケーションスタート(B)

最後にレプリケーションを開始します:
mysql > START SLAVE;
これでレプリケーションがスタートする、はず。


スレーブを増やして、3台目以降の MySQL サーバーを構築する場合も同様にして行います。


環境によっては「初めから MySQL をクラスター環境で構築する」という選択肢もあります。そういう場合はこちらを参照してください:
CentOS に MySQL クラスター環境を構築する


IBM Bluemix では IoT デバイスからのセンサー情報を使ったデータフローを定義する Node-RED エディタを提供しています。

特にセンサー情報はそのデバイス機器によって内容やデータフォーマットが異なるため、その内容をデータベースに保存しようと考えた場合はいわゆる NoSQL データベースを使ってテーブルを定義することなく JSON 丸ごと保存、なんてことをやったりします。これはこれで便利ですよね。

ただ保存するまではいいのですが、保存したデータを再利用する際には NoSQL だとクエリーが使えないため、その取り出しに不便に感じることもあります。その解決策の1つとしていったん Claudant に格納したデータを dashDB に複製する、という方法もあります:
Claudant => dashDB の単方向レプリケーション

そのような方法もありますが、もうデータフォーマットがわかりきっていて、NoSQL に格納する理由が特になければ最初からセンサーデータを SQL 型のデータベースに格納してしまってもいいわけです。本エントリではそんな方法のサンプルとして、Node-RED 内で SQL Database(DB2) にセンサーデータを格納する方法を紹介します。


まず Node-RED 側の用意をします。今回はすごくシンプルな形にして、IoT デバイスからのデータを一度整形して、そのままデバッグ出力するだけ、というものです:
2015051901


この中の整形部分(上記の "f" と書かれたノード)の中身は以下のようにしています。メッセージID とペイロードの名前、そして温度情報をそれぞれ ID, MYNAME, TEMP という名前で取り出しています。DB2 側で列名は大文字であることを前提とするため、JSON 側でもここを大文字にすることが肝です:
2015051902


この状態で一度デプロイして動かしてみます。ちゃんと動きますね:
2015051903


デバッグタブの出力内容は(期待通り)このようになっています。この内容を SQL Database のテーブルに格納していきます:
2015051904


では次に Bluemix 側の(SQL Database 側の)準備をします。Bluemix 上に作成した Node-RED プロジェクトランタイムで「サービスまたは API の追加」をクリックします:
2015051905


サービスの一覧から "SQL Database" を選んで追加します:
2015051906


追加が成功するとプロジェクトランタイムの中に SQL Database サービスが表示されます。このアイコンをクリックします:
2015051907


SQL Database の説明画面が表示されます。この中の "LAUNCH" ボタンをクリックしてウェブコンソールに移動します:
2015051908


ウェブコンソールが開いたら、Node-RED からのデータを格納するテーブルを定義する必要があります。そこで "Work with Tables" をクリックします:
2015051909


テーブル作業画面の左側にあるプラスマークをクリックしてテーブルを追加します:
2015051910


画面右のテキストエリアにテーブル作成の DDL を記述します:
2015051911


今回はこのような内容にしました。テーブル名は MYTABLE です:
CREATE TABLE MYTABLE
(
  ID VARCHAR(15),
  MYNAME VARCHAR(20),
  TEMP INT
);


最後に画面下部の "Run DDL" をクリックして、MYTABLE テーブルを作成します。成功すると MYTABLE テーブルが作成され、その定義内容を確認することができます:
2015051912


改めて Node-RED 画面で SQL Database の設定を追加します。ノード一覧の中から左側だけに丸のついた "sqldb"(左右に付いているのは更新用、左側だけのが追加用)を探して、キャンバスにドラッグして追加します:
2015051913


追加した "sqldb" ノードをダブルクリックし、そのサービスとテーブル名を定義します。テーブル名は先ほど作成した "MYTABLE" を指定します:
2015051914


最後にこのようにノードをつなぎます。これでデプロイ!:
2015051915


デプロイが成功するとデバッグタブにセンサー情報が表示されます。同時に SQL Database にも同じデータが格納されているはずです:
2015051916


SQL Database のウェブコンソールに戻り、MYTABLE テーブルの "Browse Data" タブを開くと追加(INSERT)されたレコードが表示されます。センサーデータが直接 DB2 に格納できたことが確認できました:
2015051917


あとは SQL を使って適当にご自由に。










 

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
 

このページのトップヘ