その他

2017年1月26日 (木)

認証プロキシをなんとかするためにツールを作っている話

【要約】認証プロキシをなんとかするためにツールを作ってGitHubで公開した。

経緯

社内ネットワークからhttp/httpsで外部に出る際にはプロキシを通さなければならない、 という環境は多いと思います。 こういうプロキシの中にはユーザー名とパスワードを入れないと通してくれないタイプのものがあります。 認証プロキシというやつですね。 これは本当に頭痛のタネです。

さすがにブラウザとかは認証プロキシに対応しているのですが、 これに対応していないソフトウェアも結構あります。 今時いろんなソフトウェアがhttp/httpsで通信していまして、 特に開発系のツールは必要なコンポーネントをhttp経由で自動的に取ってくるみたいな動作をすることが多いのです。 こういうソフトウェアの多くが素の状態では認証プロキシを通らない。 家で試すと特に問題なく動くツールが、 会社環境だと意味不明なエラーで動かなくなったりします。

ここ二三年、 わけのわからないエラーが出るたびに、 どれが引っかかっているのか調べ、 その設定方法を調べ、 ちまちまと設定しては乗り切っていました。 結果、あちこちの設定ファイルに認証プロキシのパスワードが埋め込まれて、 なにかが間違っているような気がするわけですが、 まあ、仕方ないね。

が、最近Visual Studio 2017 RCのアップデートが認証プロキシ環境内で帰ってこなくなり、 対処方法が皆目わからないという事態が発生するに至って、 我慢の限界を越えました。 こんなもん、やっとれるかーーーーーーーー。

というわけで

ツールを作りました。

これはWindowsのデスクトップ上でローカルプロキシとして動作します。 動かすと、現在のユーザーのプロキシ設定を書き換え、 自分をプロキシとして登録し、 ソフトウェアからの通信を中継します。 で、本来の認証プロキシが認証を要求すると、 通信元のソフトウェアに帰ることなく認証情報をつけてリクエストを再送信します。 結果として、 ソフトウェアが普通のプロキシにふつうに対応していれば、 そのまま通信できます。 中継はタスクトレイのアイコンから簡単にON/OFFできます。

これは認証プロキシを回避するものではありません。 認証プロキシに対応していないソフトウェアのhttp/https通信を中継して、 正しく認証プロキシを通すようにするものです。

効能としては以下の通り。

  • 認証プロキシ環境内で認証プロキシ非対応ソフトウェアを利用することができます。
  • 認証プロキシのパスワードをあちこちに書かなくてすみます。 パスワードは暗号化された状態で設定ファイル一箇所にあれば十分です。 (まあ、元々認証プロキシのパスワードはあんまり安全でないやり方でやりとりされますので、気休めではありますが)
  • 仮想化ソフトウェア(Hyper-Vなど)が定義したマシン内ネットワークに対する(通常)プロキシとして利用できます。 これを利用すると、 「プロキシの設定を埋め込んだままのイメージを公開してしまった!」という事故をやらかしても、 パスワードが埋め込まれないため、多少状況はましになります。

GitHub上で公開しています

設定ウィンドウとかまだ実装できていないけど、 とりあえず役立つ程度には動いているので(Visual Studio 2017 RCのアップデートもできたし)、 tu公開します。 モノはGitHub上にあります。 ツール名は「認証プロキシ爆発しろ!(英語名は MAPE: May Authentication Proxy Explode)」です。

ipponshimeji/MAPE (GitHub)

詳細な説明とかは、 以下のページから。

目次 - 認証プロキシ爆発しろ! (GitHub)

手っ取り早くどういうものか知りたい方は、特に以下のページを。

認証プロキシでお困りの方はお試しくださいまし。

ちなみに

Windows環境で認証プロキシをなんとかするにはFiddlerを使う技とかもありますが、 以下の理由から独立したツールを作りました。

  • Fiddlerを使う場合、Fiddlerのスクリプトをいじる必要(しかもちょっと複雑)があり、 非開発者な人に「これを使えばなんとかできます」とか言いにくい。
  • 自動構成スクリプトでプロキシが設定されている環境では、 Fiddlerのプロキシ設定書き換えは「次で始まるアドレスにはプロキシを使用しない」を設定してくれない。 認証プロキシが設置されているような環境では自動構成スクリプトを利用していることが多いでしょうから、 これは面倒の元になりがちです。

なお、Fiddler自体は便利なデバッグツールとして利用させていただいております。

【2017年4月11日追記】

上にはこう書きましたが、 「次で始まるアドレスにはプロキシを使用しない」に相当する設定がありました。 すいません。

2016年5月12日 (木)

Microsoft Bot Frameworkを使ってSlashのbotを作ってみた(前編)

連休中にMicrosoft Bot FrameworkでBotを作って、 家族内の連絡に使っているSlackのチームに突っ込んでみました。 まずは、特に工夫もない単純なBotだけど。 その話などぼちぼち書いてみます。

Microsoft Bot Frameworkとは

Microsoft Bot FrameworkはBuild 2016において"Conversations as a Platform"の一要素として発表されました。 賢いBotが人間の相手をして、仕事を色々とこなしてくれれば、 GUIとかとはまた違った便利なインターフェイスなるだろう、 そういうBotを作ろうぜ、 という話ですね。

Botを作る話はFacebookも最近発表しました。 Facebookの話がFacebook Messengerを対象にしているのに対し、 Microsoft Bot Frameworkは様々なメッセージングサービスを相手にします。 Botサービスを一つ立ち上げておいて、 それを各種サービス(Email, Slack, Skype, Facebook Messenger, etc.)に繋ぎます。 LINEも対応予定だと言っていたなあ。 現状のメニューには出てなかったけど。

以下の図がよく説明で引用される図です。

Bot Frameworkの説明図

Bot Framework Overviewから

Bot Frameworkは大きく以下の三つの要素からなります。

  • Bot Builder SDKs: Botを簡単に開発できるようにするSDK
  • Bot Connector: 作ったBotをメッセージングサービスに繋ぐサービス(SaaS)
  • Bot Directory: (将来予定)Botを流通させるためのサービス

BotとBot Connectorの関係はこんな感じ。 BotはBot Builder SDKで作らなくても、 インターフェイスを満たせばBot Connectorで繋げることができます。

Bot Frameworkの構成図

Bot Framework Overviewから

メッセージングサービスにBotを送り込む枠組みはこれでよいとして、 「賢い」Botを実装するためには、 賢く状況を認識できるようにしなければなりません。 そのための道具立てが"Conversations as a Platform"のもう一つの要素である"Microsoft Cognitive Services"です。 色々な認識を行うためのサービスが揃っています。 その中のEmotion APIは先月簡単に動かして見ました(前編, 後編)。

さて、ということでSlack上で動くBotを作ってみます。 今編では、まずBot Builder SDKを使ってBot本体を作ります。 次編でBot Connectorを使ってそれをSlackに接続します。

どういうBotを作るか

ファーザーBotを作ります。 以下のセリフをランダムに返します。

  • いいです。
  • わしもですか?
  • みんなもですか?
  • わしがですか?

これは、 「神聖モテモテ王国」のファーザーが発行した紙幣(壱萬ラブ)の四コマ中のセリフです。 これをランダムに返してくれると、 いい感じに壊れた雰囲気になるでしょう。

言語の選択とSDKの準備

まず、言語を選択します。 現状用意されているのはC#またはNode.jsです。 ここではC#を使います。 C#を使う場合は、 Visual Studio 2015 Update 2以降が必要です。 Node.jsを使う場合は、Node.jsとエディタだけでできそう。

C#版SDKは実質的にはテンプレートのみです。 テンプレートのzipファイルをユーザーレベルのテンプレートの置き場所に置くだけです。 具体的には説明の通り。

プロジェクトの作成

ここでVisual Studioを起動し直すと、 「新しいプロジェクト」のC#のプロジェクトテンプレートの中に「Bot Application」テンプレートが現れるようになります。

「新しいプロジェクト」ダイアログ

ここからプロジェクトを新規作成すると、 プロジェクト構成はこんな感じになります。 ASP.NETのWeb APIがベースっぽいですが、 かなりシンプルになっています。

プロジェクト構成

ソースコードの修正

ソースコードの中心部は以下です。 テンプレートの初期実装は入力メッセージの文字数を答えるものですね。

namespace FatherBot {
  [BotAuthentication]
  public class MessagesController: ApiController {
    /// <summary>
    /// POST: api/Messages
    /// Receive a message from a user and reply to it
    /// </summary>
    public async Task<Message> Post([FromBody]Message message) {
      if (message.Type == "Message") {
        // calculate something for us to return
        int length = (message.Text ?? string.Empty).Length;

        // return our reply to the user
        return message.CreateReplyMessage($"You sent {length} characters");
      } else {
        return HandleSystemMessage(message);
      }
    }

これを以下のように変更します。 まあ、まずはシンプルな内容で。

namespace FatherBot {
  [BotAuthentication]
  public class MessagesController: ApiController {
    private static readonly string[] replies = {
      "いいです。",
      "わしもですか?",
      "みんなもですか?",
      "わしがですか?"
    };
    private Random random = new Random();

    /// <summary>
    /// POST: api/Messages
    /// Receive a message from a user and reply to it
    /// </summary>
    public async Task<Message> Post([FromBody]Message message) {
      if (message.Type == "Message") {
        string reply = replies[this.random.Next(replies.Length)];

        // return our reply to the user
        return message.CreateReplyMessage(reply);
      } else {
        return HandleSystemMessage(message);
      }
    }

ビルド

このままプロジェクトをビルドします。 実は、このソースだと「Postメソッドについているasyncの意味が無いぞ」という趣旨の警告をC#コンパイラが出します。 通常、Postメソッドの中では色々仕事をするだろうから、きっと非同期メソッドを呼び出すことだろう、 ということでテンプレートは非同期スタイルでPostメソッドを生成してます。 しかし、現状の内容だと同期的な処理しかしていないので無意味なわけですね。

でもまあ、実害はないので無視しましょう。 asyncを取り除くとそれはそれで同期スタイルに直さなければならなくて手間だし。

デバッグ実行

で、これをデバッグ実行すると、 ブラウザ上にスタートページが表示されます。

スタートページ

このページを開いている間、 Botサービスは動いており、 ページを閉じるとBotサービスのデバッグ実行が終了する、 だったと思うんだけど、 ページ閉じてもデバッグセッションが終了しないな。 ASP.NETのデバッグってそういう動きだったっけ?

まあともかく、 Botサービスを起動している間に、 その動作を試します。 それには、 Bot Framework Emulatorを使うと便利です。

Bot Framework Emulatorは 説明ページのリンクからインストールできます。 なんと、最近ほとんど見ないClickOnceアプリケーションですよ。

Bot Framework Emulatorを使うと、 こんな感じでBotの動きをチェックすることができます。 Bot Framework Emulator側で入力を与えつつ、 Visual Studio側でデバッグを行うことができるわけです。

Bot Framework Emulator

Bot Framework Emulatorを正しくBotに接続させるためには、 Emulatorの上部の帯にある"URL", "App Id", "App Secret"を正しく指定しなければなりません。

"URL"はBotを動かしているアドレスです。 先ほど開いたスタートアドレスのページのアドレスバーを見れば見当が付くでしょう。 注意点としては、BotのAPIのパスは(テンプレートそのままだと)サイトのルートではなく、"/api/messages"になるところですかね。

"App Id", "App Secret"によってBotはクライアントからの接続を認可します。 この値はプロジェクト中のWeb.configで設定されています。

現時点では、 テンプレートから生成された仮の値が入っています。 BotをBot Connectorに登録する際には、 ちゃんとした値を入れることになるでしょう。

スタートページ

次回、BotをBot Connectorに登録し、Slackから利用可能にします。

2016年5月 8日 (日)

ココログの「スマートフォン表示」に無理矢理スタイルを設定してみた

このブログ、 「PC表示」〔ママ〕に対してはスタイルを設定していましたが、 「スマートフォン表示」〔ママ〕に対しては設定していませんでした。 というか、 ココログの追加料金なしのプランでは「スマートフォン表示」にCSSを設定する方法がありません。

携帯版のブログのデザインをカスタマイズすることはできますか? (公式FAQ)

でも、素の「スマートフォン表示」は、 箇条書きが箇条書きにならないし、 表に枠がつかないし、 インデントもうまくできないし、 非常に見づらい。 制限の多かったガラケー時代の名残なのかな?

まあ、 モバイル系がこのままなのもアレなので、 頑張って「スマートフォン表示」に独自CSSを設定する方法を探しました。 結果としては、スマートフォンではなんとかなったんじゃないかな? ガラケーでどう見えているかはわからん。 ガラケーで見ている人はすいません。

別に小綺麗にしたいわけではなく、 単に文章構造を明確にしたいだけなんですけどね。 まあ、ちゃんとカスタマイズできる他のブログサービス使えと言われれば、 そうなんだけどさ。

まず、「カスタムCSS」について確認

ココログのブログ管理ページの「デザイン」の項には「カスタムCSSを編集」というメニューがあり、 独自CSSを設定できます。 しかし、「カスタムCSS」機能は「PC表示」にのみ有効で、 「スマートフォン表示」には反映されないようです。

では、「スマートフォン表示」に有効な独自CSS編集機能は?

前記FAQの通り、追加料金が必要。

なんとか追加課金なしでできないか?

直接的な方法はないし、 可能だったとしても「PC表示」と「スマートフォン表示」で別々のCSS書くのもいやだし、 どうしたものかな、 と考えていたところ、 ファビコンを設定した方法を思い出したわけです。

ファビコン(ブログアイコン、サイトアイコン)を設置してみましょう

これは要するに、 ココログの設定の「ブログのサブタイトル(キャッチフレーズ)」に設定した内容は、 HTML要素も含めてそのままページに埋め込まれるという仕様を利用した方法です。 そんなんでいいのか。

まあともかく、 この方法を流用し、 「ブログのサブタイトル(キャッチフレーズ)」にファビコンを参照するlink要素と並べて、 独自CSSを参照するlink要素を追加したら、 「スマートフォン表示」でもCSSが効くようになりました。

CSSは少し手直しが必要でした。 「PC表示」と「スマートフォン表示」でページの構造が結構異なります。 で、その各構造に割り当てられているクラス名がずいぶんと違う。 が、entry-contentというクラスが記事のコンテナとして共通に存在するので、 それを手がかりにスタイル設定対象を限定できました。 こんな感じ。

.entry-content td, .entry-content th {
  border: solid thin #999999;
  padding: 0.3em;
}
...

後は、 「PC表示」用に従来設定していた「カスタムCSS」は設定が重複するので削除して、 作業完了。 めでたしめでたし。

問題点

「ブログのサブタイトル(キャッチフレーズ)」の内容は、 ブログのページのh2要素の中に埋め込まれます。 ということで、 ページは以下のようになっております。 (このHTMLは説明のためのモノで、指定されているURL等は正しくありません)

<html>
...
 <body>
...
  <h2>サブタイトル
   <link rel="shortcut icon" href="favicon.png">
   <link rel="stylesheet" type="text/css" href="my.css">
  </h2>
...

h2要素中にlink要素を入れてよいのだろうか?

HTML5では大丈夫。 h2要素の内容はフレージングコンテンツであり、 link要素は条件付きでフレージングコンテンツと見なされる。 その条件とは、itemprop属性が存在する場合。 なので、itemprop属性を追加しておきましょう。

厳密には、文法的に許容されるというだけで、 head要素中に記述された場合と同じように機能する保証があるのかはよく分からんが、 まあ主なブラウザで機能しているみたいだし。

なので、 HTML5な「PC表示」ではOK。 ところが、 「スマートフォン表示」はXHTML 1.0なのです。 XHTMLでは、本当はだめだと思うなあ。 XHTMLではh2要素の内容モデルはテキストかインライン要素で、 インライン要素にlink要素は含まれない。 でもまあ、Windows 10 Mobile, iOS, Androidの標準ブラウザで効いているみたいだから、 いいや。

2016年4月 2日 (土)

Microsoft Cognitive ServicesのEmotion APIを使ってみた (使って色々思いを馳せた編)

前回のMicrosoft Cognitive ServicesのEmotion APIを使ってみた (サンプルをビルドする編)の続き。 画像からの感情読み取りに興味をそそられた私が、 様々な画像をEmotion APIにかけて、はるかなるディープラーニングに思いを馳せる回。

まずは、サンプル

まずは、サービス側が用意しているサンプル画像を読み込ませてみます。 サンプルアプリの左のペインで、"Detect emotion using a URL"を選択します。 デフォルトでサンプル画像へのURLが設定されていますので、そのまま"Detect"をクリック。

サンプル画像の解析結果

三人分の顔が認識され、それぞれから検出した感情値(Emotion score)が表示されます。 右のペインには、各人の顔とそこから検出した感情値のうち、上位二つが表示されています。 下のペインには詳細が出ます。この画像で見えている部分は子供の分の結果ですね。 お子さん、NeutralよりSurprise成分の方がありそうな気がするが。

ふむ。

自分の写真

次に、自分の写真を読み込ませてみました。 左のペインで、"Detect emotion using a stream"を選択し、 PC内の自分のドヤ顔写真をアップロードします。

アプリのステータスバーを見ると、 "Microsoft will receive the images you upload and may use them to improve Face API and related services. By submitting an image, you confirm you have consent from everyone in it." とあります。 画像ファイルを直接アップロードする場合は、機能改善に使われる可能性があるということで、 私のドヤ顔が改善上の大論点になる可能性もあるわけですね。 いいけど。

で、結果。 キャプチャ画像は出しませんが、

  • Happiness:0.274908
  • Contempt:0.028495

だそうです。

「表面上おとなしく暮らしているが、心の底では世界を呪っており、押そうとしたバスの降車ブザーを先に押されたことをきっかけに世界を滅ぼそうと決意する確率が83%」 みたいな結果が出たらどうしようかと思いましたが、 そもそも単純な選択肢しかありません。 ニュアンスが正確に一致するか微妙だけど、日本語訳をつけるとこんな感じ?

  • Anger (怒り)
  • Contempt (軽蔑)
  • Disgust (むかつき)
  • Fear (恐れ)
  • Happiness (喜び)
  • Neutral (ふつう)
  • Sadness (悲しみ)
  • Surprise (驚き)

また、 このAPIは画像から表面的に読み取れるものを読み取っているだけですね。 当たり前か。 画像から本心が読めるようになると、大変なことになります。 というか、保護しなければならない機微情報だろう、それ。 スマホで顔をキャプチャされながら、 「冷蔵庫にあったプリンを食べたのはあなたですか?」 とか詰め寄られる未来を考えると、けっこうピンチ。

いや、表面上の感情を読み取るレベルでも、 なにか間違いがあれば危険ですね。 独裁者の前で感極まった表情で拍手している写真を解析してみて、 なにかの間違いで"Anger"と"Contempt"が上位に来ちゃったら、 粛清ものです。 命にかかわる重大インシデントです。

人間側が特性と使いどころを考えて使わないと、 えらいことになりそうですね。 (まあ、技術一般そうだと言えばそうなんだけど)

キハ65

ということで、 この場ではこの先、 技術を平和利用することにして、 実在の人でないものを解析してみます。

機械学習による画像認識といえば、 去年、友利奈緒判定botで友利奈緒な鉄道車両を探してみたという話がありました。 それにたいへん感銘を受けたことを突然思い出したので、 いきなりですがキハ65の画像URLを突っ込ませていただきます。 よろしくお願いいたします。

キハ65画像の解析結果

画像出典: Wikipedia 「国鉄キハ65形気動車」から、 http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/JNR_kiha65_1.jpg/800px-JNR_kiha65_1.jpg

"No emotion is detected. This might be due to: (略) no faces are in the images (略)"

そうですか。

感情値を算出する前に、 人の顔を検出しなければならないので、 まずそこをクリアしなければ先へ進めない訳ですね。

一松さん

次はまあアニメキャラでしょう。 友利奈緒でもいいんだけど、 ここで今絶賛腐り中の次女に聞いてみましょう。

質問: 推し松は?

回答: 一松

なるほど。

一松画像の解析結果

画像出典: Wikipedia 「TVアニメ「おそ松さん」公式サイト」から、 キャラクター紹介の一松

"No emotion is detected."

うーん。

池上遼一絵

単純化されている絵は難しいのかも。 じゃあ、リアルな絵ではどうでしょうか。 Amazonから池上遼一先生の絵の表紙で、 顔が大きく描かれているものをみつくろって解析してみます。

池上遼一絵の解析結果

画像出典: Amazonの「信長1 桶狭間の戦い (MF文庫 10-4)」から、 表紙絵画像

認識されました。すばらしい。 "Anger"と"Sadness"です。渋い。

その他色々やってみて

池上遼一先生の絵は、結構認識されます。白黒の絵でもいけます。 一方、画風を似せているといわれる「魁!!クロマティ高校」とかはあまり認識されません。 「北斗の拳」は認識されたりされなかったり。

そんなに多くのサンプルを調べたわけではありませんが、 感触としては、 立体感が読み取れるかどうかが結構重要であるように思えます。 立体感も、 記号的な表現ではだめで、「影」っぽいものが具体的に読み取れるかどうかが重要なんじゃないかな。

要するに、現状では、記号的な表現にはあまり対応していないようです。 まあ、看板の絵とかにいちいち反応していたらうるさいだけだし、 とか思いつつ、 一方人間は、看板の絵だと理解しつつ、 その絵の表情を読み取ることができるよなあ、 そういえば、 子供が赤ん坊の頃など思い出すと、 けっこう小さいときから記号的な表現を認識できていたような気がするなあ、 とか考え、 わしらの頭の中ではどのような特徴量が構成されているのだろうか、 などと思いを馳せるわけです(とりあえず馳せるだけだけど)。

で、一番知りたいのは、 これらのAPIの奥で、 どのようにディープラーニングが用いられているかです。 どの量に着目してどういうモデルを組んで、 どういう学習をさせ、 どの程度の結果に落とし込んでいるのか。 なんで結果をこの(※)八種の感情にしたのか。 さすがにそういうのはまだ秘密なのかなあ。

※ 数を書き間違えていたのを修正。(2016/04/03 00:04)

Microsoft Cognitive ServicesのEmotion APIを使ってみた (サンプルをビルドする編)(追記あり)

最近、ディープラーニングを勉強し始めていて、画像から感情を検出するという技術(Emotion API)に興味をそそられています。ということで、Emotion APIを簡単に使ってみたという話。まず、APIを準備してサンプルをビルドする編。

Microsoft Cognitive Servicesとは

Microsoftが提供するWebサービスです。 Build 2016(Microsoftの開発者イベント、2016/03/30-04/01にサンフランシスコで開催)で発表されました。どういうものかを一言で説明するのは難しいんだけど(いや、一応それらしい説明はあるんだけど)、以下のビデオのような世界を実現するために必要となるもの、と考えるのが分かりやすいのではないかと思います。これは、Buildの初日キーノートの最後に流されたビデオです。

Microsoft Cognitive Services: Introducing the Seeing AI app (「字幕」を有効にすると字幕を見ることができます。英語だけど)

Webサイトは以下。

Microsoft Cognitive Services

去年、画像から人の顔を特定して年齢を推測するWebサイトが話題になったのを覚えているでしょうか? Project Oxfordというやつですね。それが進化したものです。

Emotion APIとは

Microsoft Cognitive Servicesを構成するAPI群の一つで、画像やビデオから人の顔が写っている部分を特定し、そこから読み取れる感情を推測して返します。

Emotion APIのページに載っている以下のデモを見れば、どういうものか想像できるのではないでしょうか。

Emotion APIページのキャプチャ

Emotion APIのリファレンスを見ると、 4個のAPIが定義されています。今回ここで使ってみるのは、 "Emotion Recognition"です。

Emotion APIを使うには

ちょっと試してみるだけなら、先のページのデモ機能でも十分ですが、せっかくなのでもう少しまじめに使ってみます。

Emotion APIを使うには、以下の手順が必要です。

  • Microsoft Cognitive Servicesを利用するためにアカウントを登録する。
  • Emotion APIを呼び出す。その際には、登録した際に割り当てられるキーを使う。

「Emotion APIを呼び出す」はcurlコマンド一発でもいいのですが、サンプルアプリが用意されているようなので、それを使ってみます。

以下、その手順の説明です。次回のブログでは、そのサンプルアプリを「使ってみた編」を書く予定。

Microsoft Cognitive Servicesを利用するためにアカウントを登録する

Microsoft Cognitive Servicesのページの"Get started for free tody"ボタンから登録できます。その飛び先のページに説明がありますが、

  1. Microsoftアカウントでサインインし、
  2. 使いたいAPIの種類にチェックをつけ、同意事項をチェックして"Subscribe"ボタンを押す

すると、登録処理が行われ、 Cognitive Servicesのサブスクリプション管理ページに飛びます。ここで、"Emotion - Preview"の項目を見てみましょう。

Cognitive Servicesのサブスクリプション管理ページのキャプチャ

こんな感じです。時刻表示はGMTのようですね。現状、無料コースでは「30,000トランザクション/月 かつ 20トランザクション/分」までのようです。

さて、ここで重要なのはキー(Key)です。キーはCognitive Servicesの各API毎に用意される文字列で、この文字列が後でAPIへのアクセスをするための鍵になります。アカウントにはキーが二つ(Key 1, Key2)が割り当てられています。どちらも等しく有効です。

後にサンプルをビルドして実際に動かしてみる段になると、このキーが必要になります。その際には、このページからキーをコピーします。

キーの文字列は、最初"XXXXXXXXXXXXXXXXXXXXXXXXXXX"のように隠されています。、 "Show"をクリックして実際の文字列を表示させ、文字列をコピーし、 "Hide"をクリックして再び文字列を隠します。

言うまでも無いとは思いますが、キーは秘密にしなければなりません。キーがばれてしまうと、他の人がサービスを自分のアカウントで使うことができてしまいます。キーがばれてしまった場合は、 "Regenerate"をクリックしてキーを「取り替え」ます。

Emotion APIのサンプルをビルドする

Emotion APIのサンプルはGitHubにあります。 GitHubのMicrosoft/ProjectOxford-ClientSDKプロジェクト下の、 Emotion/Windows/Sample-WPFにある Windows版サンプルを使います。

単純に、 GitHubからサンプルをとってきて、 Visual Studio 2015で"EmotionAPI-WPF-Samples.sln"開いて、ビルドすればできあがります。

ただ、ビルドの最初にNuGetパッケージの復元が行われますが、私の環境ではNuGet動かず、ビルドエラーになりました。しかし、これはサンプルの問題では無く、 NuGetが全体的に動いていなかったので、私の環境の問題のようです。つい最近までNuGet動いていたと思うんだけどな? Visual Studio 2015の「ツール」-「オプション」の「NuGetパッケージマネージャー」-「パッケージソース」でチェックがオフになっていたv2パッケージソースを有効にしたらビルドできました。

【2016/04/07追記: これはどうやら、NuGetの問題のようでした。「NuGet 3.4 Known Issues」を参照のこと。 4/09あたりに修正が公開されるとあるので、待っていれば直るんじゃないかな。急ぐ人は前記ページに載っているwork-aroundをどうぞ。】

サンプルコードも特にトリッキーなことはありません。 Asyncスタイルで用意されているEmotion APIのクライアントライブラリを非同期呼び出しで呼び出しているだけです。まあ、このAPIの場合、重要なところはすべてサーバー側の方だろうし。

サンプルを起動すると、以下の画面が現れます。

サンプルアプリの画面

この"Subscription Key:"に先ほどのキーを記入し、 "Save Key"を押せば準備完了。

次回、これを使って画像を色々読み取らせてみます。

2015年1月15日 (木)

ブログ始めます

ブログ始めます。

と思ってから10年くらい経ちました。 なんとかせねば、とブログの開設だけしました。 で、1年半が経ちました。このままではいけない、新年から始めよう、と思ってさらに半月が経ちました。 いまここ。

発端は、ソフトウェア開発についての覚え書きを書き溜めようと思ったことです。 歳のせいか、あるいは世の中の進化が年々早くなっていくせいか、色々なことが覚えていられなくなりました。 OneNoteとかにメモを取って、最近ではOneDriveで同期させたりもしていますが、時には共有したいこともあります。 「あの話?メモ公開しているからここ見て」みたいに。 さらに、とにかく何か書いていれば、誰かの役に立つかも知れない。

Facebookだとだらだら書くのに楽かなあ、とも思いましたが、Facebookは完全に日常系になってしまっているし、検索性も悪い。

というわけでブログ始めます。 多くは覚え書きになるでしょうが、気が向けば思うところなど書くかもしれません。

といっても、当面誰も見ないだろうけど。