kgrss's blog

プログラムを中心にいろいろなことを記事にしていきます!

文字認識APIを使ってみた!

こんにちは、こがらしです。

今回は、NTTドコモから開発者向けに提供されている文字認識APIの利用申請が完了したので早速試してみました。
試してみたというよりは、もともとこれを利用するつもりでいたのですが笑


この文字認識APIなんですが前は利用期限が5月までみたいになっていて、
自分が知ったときにはすでに期限が過ぎてて残念と思っていたのですが、この前ふと見てみると期限延長しました。
しかも、とりわけ期限がついていないっぽい?ということで申請をしていた次第です。

APIは非常にシンプルでした。
情景解析の場合は時間がかかるからかAPIが複数段になっていますが、非常に扱いやすいです。
基本的には、発行されたAPIキーと画像のURLを投げればOKといった感じです。

当たり前ちゃ当たり前なんですが、画像のサイズによっては時間が大幅にかかります。
早くても10秒とかなんで、そういう想定で使わないと駄目ですね。
また、文字自体のサイズもある程度の大きさでないと認識できなかったです(公式によると12pt以上らしい)

使った限りだと、カタカナは単純だからだと思いますがしっかり認識してくれました。
漢字は傾向がちょっとわからないですねー。とはいえ、文字の認識に辞書データを利用しているようなのでそこらへんが関係あるのかも知れません。
辞書に登録されていない単語は、一単語としては認識してはくれないご様子でした。

一般的でない単語の抽出に使う場合はちょっと難しいかも知れないですねー。
ざっくりとですが、使ってみた感想でした。

ではでは。

昨日のお話続き。(OAuth認証のSignature生成に関して)

どーもー、こがらしです。

TGSへ向かうさなかに書いてます笑

昨日はQueryParametersをkey=value&key=value...でつないでいくところまで書いたかなと思います。
そしたら、そろそろBaseStringを生成していきます!

必要なものとして、三つ必要になります。
1.リクエストメソッド文字列( "GET", "POST", ... )
2.リクエストURL( http://kgrss.hateblo.jp/postとか )
3.リクエストパラメータ( 今準備した、QueryParametersですねー )

まず、2と3についてはエスケープしましょう!これ絶対。

そしたらそれぞれを1,2,3の順番で & で結合します
GET&http://kgrss.hateblo.jp/post&message=hoge&title=var&oauth_.....
こんな感じです。
けど、URLとかQueryParametersとかはしっかりエスケープしてあると思ってください!
エスケープしたのを持ってくるのがかったるいのです。

あっ、一応OAuth系のパラメータをさらっと書いておきます。

oauth_consumer : サービスプロバイダー(Twitter等)からもらったConsumer key
oauth_token : Twitter等で、何かの処理をするための許可申請時にもらえるAccess Token(もらってなくてもパラメータに含める必要がある!重要)
oauth_nonce : リクエストごとに一意になるような適当な値(本当に何でもいい)
oauth_time : 現在の時間(UNIX_TIMESTAMPでだったかな)
oauth_version : これは常に"1.0"で。
oauth_signature_method : だいたいのプロバイダーでこれも固定で"HMAC-SHA1"

今あげた上の6つが、QueryParametersに追加で含まれます!
(さらにsignatureを生成したら、それも含めます)

そしたら、今度はハッシュ生成に使うキーです。
これは簡単ですよ。
Consumer SecretとAccess Secretを & で結合するだけ。

xxxxxxxx&yyyyyyyyyって感じです。
ちなみに、Access Secretが無い場合は、
xxxxxxxx&です。
なんとも寂しいです。

後はハッシュを生成して終わりといった感じですかね。
クライアント側(C#)を実装したときにはまったのが、byte配列にするときにエンコード指定をASCIIとUTF-8で色々迷ったところ・・・
BaseStringはUTF-8で、生成に使うキーの部分はASCIIでバイトコードにしてます。
そして、生成したままのハッシュだと形式が全然違うのでBase64エンコードURIエスケープが必要です。

そうして生成したsignatureをoauth_signatureとしてパラメータに付与すれば大丈夫といった感じのはず・・・!

あと、絶対Authorizationヘッダに足さないといけないとかではなかったと記憶していますよ。
まぁだいたいこんな感じです。
間違っている箇所があればご指摘くださいー。

ではではー。

OAuthのsigunatureってなんだ?全然途中まで

こんばんはー、こがらしです。

最近TGSがはやりみたいですね笑
僕ももちろん行きますよー。

今回は、タイトルの通りにOAuth認証で用いるsigunatureに関してまとめていきますー

まず、sigunatureって何のために使うの?ってところから。
あっ、僕の勝手な考えの元のお話になりますので、もしここおかしいよみたいのがあればご指摘くださいー
sigunatureは、悪意のある第三者の方に勝手にリクエストを改変・捏造されていないことを確認するために用いるものですね。
パラメータ等に改変等があれば、このsigunatureの確認フェーズでエラーがでます。
そのため、このリクエストはおかしいと判定することができるんですねー。

どうやって判定しているかとか、そういうのを話せそうであれば説明していきます。

まずは事前準備として、通信をするクライアントおよびサーバー側の双方でConsumer KeyとかConsumer Secretがあると思います。
TwitterはAccess TokenとAccess Secretもでしたっけ?

まぁうろ覚えながら続けていきます。

たとえば下記のようなリクエストをしたいとします。
http://kgrss.hateblo.jp/post?message=hoge&title=var

なんかに投稿をする際とかにはこんな感じになると思います。
この場合はGETリクエストですが、POSTリクエストでもどこにパラメータがくっついているかしか変わりありません。
REST APIとかに応じて合わせてくださいね。

今回は見ての通りGETメソッドの場合で進めていきます。
上のURLのhttp://grss.hateblo.jp/postまでをRequest URLとします。
?以降のmessage=hoge&title=varがQueryParametersです。
それと、これに加えてOAuthで必要になるパラメータもこのQueryParametersに含めていきます。
つまりはoauth_で始まるパラメータ類ですね。
この段階ではoauth_sigunatureは含めないのでご注意を!

sigunatureの生成時には、QueryParametersの順番が決まっています。
Key名で昇順(?)になるようにソートをする必要があります。
この場合はmessageとtitleですね。それに加えてoauth系のパラメータ。
順番としては、以下の順ですね。
message>oauth_*******>title
このパラメータをkey=value&key=valueみたいにつないでおきます。
この部分はソートを行う部分飯貝は普通ですねー。


あー、続きはまた書きます・・・!

WebSocket-Sharpの問題 他

こんにちは、こがらしです。

最近は遅ばせながらの夏期休暇へ突入したので、いつも以上にアクティブにしてます(つもり)

その中で、昨日は@relzxさんと@enpelさんともくもく会をしました。

お昼ぐらいから夕方まで主にはUnity関連についての話とかをしてました。
自分は、色々いじったりはしてたんですがほとんどプログラミングしてなかったっていう笑
それでも色々と話しをしてて主にヤル気を得たのでいいのかなーと。

ということで昨日からのヤル気を持ち越してWebSocketが動かない問題を調べてたわけですが、
自分がforkをした段階のリビジョンでは.NET subsetで動きました(Androidはですが)

たぶん、更新履歴を見る限りだとWebsocket-Serverとかを追加する関係で動かなくなっている模様・・・
ココらへんで結構コードが増えているので内容までは確認できてないです。

実はforkしたやつだとRFC対応していないっていうのにはちょっとあれですが、
とりあえず自分のサーバーとは通信ができているのでいいかなとか思ってます。

まぁ一応forkしたやつのリンクを。
https://github.com/Kogarasi/websocket-sharp

まだ休暇は始まったばかりなので、もっと楽しんできます><
ではではー

CakePHP筆卸。

どもどもこんばんはー、こがらしです。

そろそろ次の仕事のために色々準備をしておりますー。
その中でもですね、サーバー担当をプロジェクトの始めから担当することになってとっても不安な状態な自分が居ます。

システムの運用経験とかがないので、どのくらいのアクティブユーザー数に対してどの程度の負荷まで耐えることができるのかなどなどが全然わからないんですよねー。

そんな状態でも、プロト版までを結構駆け足になってやらないといけないのかなーということもあって、フレームワークは導入必須かなという考えになりましたー。

じゃあどれにするの?というのが自分の中でありましたけど、
新しもの好きの僕としては本当はFuelPHPとか使ってみたかったんですが、
これに関してはフォローに入れる方というのが居ないのかなと言うことであきらめました。

そういうちょっと現実も見ていかなきゃっていうのもあって、
選んでおいて実際大丈夫なのかなという不安がないではないですが、
今回はCakePHPを利用することにしました。

PHPフレームワークとしては、CakePHPが初めてでやっぱりフレームワークは便利な印象ですね。
とはいえはじめからわかってはいた問題点もあって、DBの負荷分散に関してですね。
CakePHPではSharding等の機能がついていないので自前で実装を行っていかないといけないと言うこともあり、自分が一番不安になっている負荷まわりがCakePHPだと弱いんですよね。

そうは言っても、フレームワークに関しては利用をするのが僕だけじゃないのでやっぱり学習コストが低くできるのは優先なのかなという判断をしました。

今後重要な項目としてはDBデータのKVSによるキャッシュや、先ほどのShadingなどをやっていかないと・・・・

それでもJSONデータとかでもフレームワークの強みであるMVCモデルはやっぱり強いんだなって感じましたね!
バリデーションやセッション管理などについても色々とまだ調べないといけないものはいっぱいあるんですがねー。。

まだまだこれからが不安なこがらしでしたー。