プログラマでありたい

おっさんになっても、プログラマでありつづけたい

嘘のつきかた

 ようやく体調が回復してきたので、当たり障りのない話から再開です。まずは、有名な話を2つほど。

茹でガエル

『2匹のカエルを用意し、一方は熱湯に入れ、もう一方は緩やかに昇温する冷水に入れる。すると、前者は直ちに飛び跳ね脱出・生存するのに対し、後者は水温の上昇を知覚できずに死亡する』

茹でガエル - Wikipedia


ノミのジャンプ

 ノミのジャンプ力は、体長の100倍近くあります。そのノミをガラスのコップに入れて蓋をします。はじめは自由に飛ぶのですが、何度も頭をぶつけていくうちに低くしか飛ばなくなります。その後、天井を外してもノミは以前のように飛ばなくなります。ノミは自分で限界をつくることにより、高く飛ぶ能力を失ってしまうのです。

 どちらも、大嘘です。茹で蛙の実験は、何度も再現実験をしてみたところカエルは熱くなるとサッサと逃げていくそうです。ノミの方も、科学的な実験の話ではなく心理学でよく利用される喩え話です。この2つの話から引き出せる教訓は何でしょうか?
 もっともらしい話であれば、人間は真偽を確かめないという話です。特にこの2つの話は、経営者など社会的地位が高い人が好んで使う傾向にあるようです。そうすると本人の信頼性も相まって、ますます真実味を帯びてきます。(試しにググると、◯◯先生に聞いた話ですとか沢山でてきます。)

嘘の構造



 虚構(物語)を作るプロの職業の1つに小説家があります。誰が言っていたのか忘れましたが、たぶん阿刀田高か筒井康隆だったと思いますが、物語の書き方には次のような鉄則があるそうです。
 
「ありえない話(大きな嘘)をつくには、細部については徹底的に真実を織り交ぜろ」

 つまり沢山の小さな真実で装飾された1つの大きな嘘は、読んでいるうちに真実に思えるという話です。その話を聞いた時に思い出したのが、安部公房の砂の女です。砂に埋もれようとする集落に閉じ込められた男が、脱出しようと悪戦苦闘する話です。しまいには何が現実で、何が虚構か解らなくなる話ですが、この話の前提である砂に埋もれようとする集落というのが大きな嘘です。しかし、そこでの生活を徹底的にリアルに書くことにより、現実感のないその設定が真実味を帯びてきます。

教訓



  1. もっともらしい嘘に人間は騙されやすい
  2. もっともらしい嘘を確かめもせず嬉しそうに話している人は騙されやすい人と思っておく
  3. 小説家は嘘のプロ。嘘の構造は、古今の小説読んでると解ってくる

 嘘の構造はパターンがあるので、覚えておくと騙されにくくなります。しかし、あまり度が過ぎると、嫁さんに「あんたは何で、世の中をそんなに斜めに見るの」と突っ込まれるのでご注意を

99・9%は仮説?思いこみで判断しないための考え方? (光文社新書)

99・9%は仮説?思いこみで判断しないための考え方? (光文社新書)


See Also:
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

SwaggerでAWS API Gatewayを作成する

 前回Swaggerの紹介をしたので、今回はSwaggerを使ってみます。実用例で一番解りやすいのが、Swaggerを使ってAWS API Gatewayを作成する例ではないかなと思います。API Gatewayは素晴らしいサービスですが、UIで作るには面倒くさすぎます。そんな時に登場するのが、Swagger importer toolです。Swagger Specを元にツールを介して、API Gateway一式を作ってくれます。

API Gateway Importerのインストール



 まずは、Macでの環境設定です。JavaとMavenが必要となります。

 $ brew install Caskroom/cask/java
 $ brew install maven

 Swagger Importerツールのインストールです。GitHubからダウンロードして、Mavenでビルドします。

 $ git clone https://github.com/awslabs/aws-apigateway-swagger-importer.git
 $ cd aws-apigateway-swagger-importer/
 $ mvn assembly:assembly

 エラーが出なければ、稼働の確認してみましょう。
aws-api-import.shを叩いて、下記のようなメッセージが出ればO.K.です。

$ ./aws-api-import.sh 
 Usage: aws-api-import [options] Path to API definition file to import
  Options:
    --create, -c
       Create a new API
       Default: false
    --deploy, -d
       Stage used to deploy the API
        --help
       
       Default: false
    --profile, -p
       AWS CLI profile to use
       Default: default
        --raml-config
       Provide a configuration file to load AWS information from
    --test, -t
       Delete the API after import (create only)
       Default: false
    --update, -u
       API ID to import swagger into an existing API

API Gateway Importerの作成



 それではSwagger Importerツールを使って、API Gatewayを作成してみましょう。サンプルのAPI GatewayのSwagger Specが幾つかあるので、それを使ってみましょう。Swagger Importerツールは、AWSの認証については、AWS CLIツールのクレデンシャルを利用しています。設定していないのであれば、~/.aws/以下のcredentialsを用意しましょう。

cat ~/.aws/credentials 
[default]
aws_access_key_id = your_aws_access key
aws_secret_access_key = your_aws_secret_access_key
region = ap-northeast-1

[dev]
aws_access_key_id = your_aws_access key
aws_secret_access_key = your_aws_secret_access_key
region = ap-northeast-1
 $ ls tst/resources/swagger/
 apigateway.json				petstore-with-external-docs.json
 basic.json				petstore.json
 large.json				test.json
 petstore-expanded.json			uber.json
 petstore-minimal.json			uber.yaml
 petstore-simple.json

 今回は、petstore-simple.jsonを使ってみましょう。

 $ ./aws-api-import.sh -c tst/resources/swagger/petstore-simple.json 
2015-11-21 07:42:29,295 INFO - Skip unsupported property name region in profile [default].
2015-11-21 07:42:29,297 INFO - Skip unsupported property name region in profile [dev].
2015-11-21 07:42:32,823 INFO - Attempting to create API from Swagger definition. Swagger file: tst/resources/swagger/petstore-simple.json
reading from tst/resources/swagger/petstore-simple.json
2015-11-21 07:42:32,987 INFO - Parsed Swagger with 2 paths
2015-11-21 07:42:32,993 INFO - Creating API with name Swagger Petstore

作成されたAPI Gatewayの確認



 それでは、AWSのコンソールに行って作成されているか確認してみましょう。API Gatewayのダッシュボードで出来ているか、確認してみてください。

f:id:dkfj:20151210195149p:plain

感想



 SwaggerのSpecを書ければ、AWS API Gatewayが簡単に作れるということが解ったと思います。次の問題は、Swagger Specをどう作って運用するかという話です。その辺りは、今後取り上げたいと思います。

See Also:
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

ブログと字数の関係

 このブログの記事数が1,000近くになってきました。ちょっと振り返りがてらに、どんな感じで書いているのかまとめてみます。

ブログの字数



 私がいつも書くブログのエントリーは、1,000〜2,000字くらいが大半です。昔懐かしの原稿用紙にすると、3〜5枚換算です。小中学校の宿題で原稿用紙3枚だと大作で頭を悩ませましたが、実はこの分量は一般的な技術書のサイズだと図も入れて2ページほどとなります。こらくらいだと、5分くらいで読める分量です。実際にGAをみていると同じくらいになっているので、だいたい想定どおりの結果になっています。
f:id:dkfj:20151209115103p:plain

 個人的な感覚ですが、これくらいの分量だとスマホでもぱっと読めます。また、それほど興味がない内容でも、読み出したら最後まで読もうかと思ってもらえる分量です。ということで、これくらいを目安に考えています。

 たまに、力を入れて4,000〜6,000字くらい書くことがあります。直近だと『有機農業や田舎暮らしは、地球環境に優しいのか?』にあたります。書いているうちに色々言いたくなって字数が増えるのですが、基本的には良いことはありません。滞在時間等は長くなるのですが、総じて反応が芳しくありません。はてなブックマークやTwitter等での拡散が少なめになる傾向にあります。たぶん読みきらないとシェアしようともしないのでしょうね。一方で、長期的にみると検索流入が多いという場合もあるので、一概には言えない部分があります。

ブログを書く時間



 1,000〜2,000字だと大体30分を目安にしています。調査やプログラミングしながらだと、これの数倍かかりますが、最近は別にするようにしています。どっかのタイミングで調査したのを30分以内でサクッとまとめるという感じです。というのは、時間掛けると字数も多くなり、頑張った割に反応がよくないということが多々あるからです。10分で書いたのが2時間で書いたコンテンツより人気で、何となくモヤモヤするといのはブログ書く人あるあるだと思います。

感想



 ということで、ブログは時間を掛けずにライトに書くのがよいのではと思っています。あまり身構えると1文字も掛けなくなるので。ちなみにもう10年以上書き続けているので、振り返ってみると下記のようなメリットがあったと思います。

  • 執筆のキッカケになった
  • 文章を書く際、どれくらいで書けるか8割くらいの精度で解るようになった
  • ブログへの反応をみていると、一般的な考え方とか流行り廃りが何となく解る
  • たまに読み返すと、書いた当時のことを思い返して面白い

 人それぞれなので、自分なりの書き方を見つけると良いのではと思います。Let's Enjoy!!

See Also:
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

API Gateway+Lambda+fabricでGitHubのWebHookと連携

 API Gatewayの登場で、LambdaをWebからのエンドポイントとして利用できるようになりました。一般的なメリットとしては、モバイルアプリやJavaScriptアプリのバックエンドとして利用しやすくなったということです。それ以外にも便利なのが、WebHookとの連携です。WebHookは、何らかの処理をトリガーに、Web上にあるHTTP/Sのサービスをコールして処理を連係するといった機能です。抽象的にいうと解りにくいですが、GitHubにコミットされたタイミングで、ビルド処理を走らせる為にJenkinsやCircleCIのビルドをURL呼び出しで叩くということです。最近では、サービス間の連係によく使われるようになりつつあり、WebHookの機能が実装されているサービスが増えています。

API Gateway+LambdaとWebHook



 WebHookを利用する際に、サービス間の連係だけで完結する場合は特に問題はありません。しかし、フックした後の処理が、サーバ上のOSコマンドやシェルプログラムを叩くものの場合だと少し問題があります。WebHookの呼び元からHTTP(/S)で呼ぶ出せるサーバを用意する必要があります。少々、面倒くさいですね。またWebHookを利用する場合、サービスの実行頻度が低く常時利用する必要もないものが多いです。そのために、24時間動いてるサーバを用意するのは非効率なことが多いです。
 そこで、API Gateway+Lambdaです。Lambdaはご存知の通りイベント駆動のコンピュートエンジンです。課金体系も、プログラム処理が走っている時間だけの従量課金で、しかも課金の単位はミリ秒単位です。そして、API Gatewayと組み合わせると、極めてローコストなWebからのエンドポイントになります。WebHookとの連係にピッタリですね。

API Gateway+LambdaとWebHookのユースケース



 それでは、どんなケースが考えられるでしょうか。WebHookは通知系のサービスと相性は良いですが、通知機能自体はサービス自身にデフォルトで実装されていることが多いです。あとは、SendGridのようなメールサービスで、メール受信後にリプライを返し自動応答や空メール機能といったことが考えられます。
 それ以外に相性がよいのが、コードのリポジトリとの連係です。GitやGitHubには当然のごとくフック機能が付属しています。プッシュした後に自動でデプロイしてくれれば嬉しいですね。そういった用途には一般的にはJenkinsやCircleCIなどのCIツールを使いますが、単なる静的コンテンツ等のビルド不要な場合はもう少し手軽に出来る方法があっても良いのではないでしょうか?そこで、GitHub + APIGateway + Lambda(Python) + Fabricを試してみました。

f:id:dkfj:20151208090754p:plain

Lambdaからgitコマンド



 まず試したのが、Lambdaにgitコマンドを叩けるようにするということです。Git CloneでTrunkもしくはBranchからデプロイ対象のソースを落とすことを想定してです。まず認証の部分ですが、GitHubには設定画面でDeploy keyを作れます。ここで、簡単にリードオンリーのキーを作れるので、これを利用してLambdaのプロジェクト内にキーを配置すればよいかと考えました。次に、gitコマンドです。Lambdaが動いている環境には、gitコマンドは用意されていません。じゃぁ、ビルドして同梱しようと気軽に考えていたのですが茨の道でした。
 Lambda用のモジュールを作る時は、基本的には静的リンクでビルドして依存関係のライブラリを内包させて作ります。私の知識不足で、それが難しかったです。
 まず、下記のコマンドで作ってみました。

$ make configure
$ ./configure CFLAGS="${CFLAGS} -static-libgcc"

 モジュールは出来るもののLambdaから呼び出した次のようなエラーが出ます。理由としては、curlライブラリが無いのが問題のようです。

fatal: Unable to find remote helper for 'https'

 じゃぁ、HttpsではなくSSHで呼ぶ出そうとしたのですが、やっぱりsshコマンドはありません。sshのモジュールはもう一段敷居が高いのでギブアップです。ということで、今のところはzipダウンロードが代替手段かと考えています。ただこのケースでいうと、GitHubを使うよりS3イベントに連動させた方が、100倍楽です。

LambdaでFabric



 こちらの方は、gitコマンドを作るよりかは苦労しません。pip install -tでローカルに必要なモジュールをどんどんインストールしてLambdaに同梱していけばよいです。具体的に依存関係があってどのモジュールをインストールしたのか忘れましたので、また手順を載せます。

pip install pyasn1 -t ./
pip install rsa

 ディレクトリをみると、下記のような感じになっていました。
f:id:dkfj:20151208091217p:plain

 Fabricの呼び出しは、最小限引用すると下記のような感じです。
fabricのシェルを作成し

import commands
import json
import os
from cStringIO import StringIO
import re

print('Loading function')

def _(cmd):
    return commands.getoutput(cmd) 

def lambda_handler(event, context):
    print(_("mkdir /tmp/fabric"))

    #コンテンツの取得処理を実装

    print(_("cp ./private.key /tmp/private.key"))   
    print(_("chmod 600 /tmp/private.key"))   

    #fabricコマンドの呼び出し
    print("./fab home_dir -H hostname -i /tmp/private.key -u fabric-user")

あとは、fabファイルの方で任意の処理を書くイメージです。

感想



 今のところは、CIツールを作る方が楽です。phantom-lambda-templateプロジェクト形式みたいに始めると皆が幸せになれるかもしれませんね。あと、ビルドの知識が根本的に掛けていることに改めて気がついたので、今度誰かに弟子入りしてパワーアップしてきます。
 今回はFabricの例でしたが、WebHookはAPI Gateway+Lambdaを組み合わせることで応用性が10倍広がります。皆さん是非一緒に妄想してみましょう!!

See Also:
SWF ✕ Lambda
Lambda PythonでAWS CLIコマンドを実行する方法
今年もやるよ!AWS Lambda縛り Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Qiita
プログラマになりたい Advent Calendar 2015 - Adventar

SWF ✕ Lambda

AWS Advent Calendarの7日目で、全部オレの7日目です。

 サーバーレス・アーキテクチャの重要な要素の1つが、Lambdaです。Lambdaは、イベント駆動でプログラムを実行するコンピュート基盤です。ユーザは、自分でサーバを管理しなくてもプログラムを実行できるため、ビジネスロジックに集中できるというメリットがあります。また、API Gatewayの登場によりHTTP Requestからの実行が容易になり、モバイルやIoTなどのバックエンジンの中核を担うようになりつつあります。

Lambdaに複雑な処理をさせたい場合



 一方で、Lambdaには幾つか課題があります。複雑な処理をしたい場合、実行時間の制約や処理の責務の分割を考えると幾つかのLambdaに別ける必要が出てきます。その際は、Lambdaの多段(カスケード)実行という形になります。イメージ湧きにくいと思うので、reInventのとあるセッションで出てきたLambdaを使ったシステムのアーキテクチャの例です。様々なイベント(直接コール、S3 Putイベント、SNS通知)からLambdaを呼ばれ、またLambda自身からもLambdaをコールしています。

f:id:dkfj:20151007151925j:plain

 自分で設計した場合、上記の例と同じようになってしまうため、よい設計例がないかreInventでLambdaやサーバレス・アーキテクチャのセッションを受けまくっていました。しかし、どれも同じような内容でした。運用保守を考えると、Lambdaの多段実行はかなり辛いのではと思います。なぜならば、途中で処理が終了した場合の追跡と再実行が困難だからです。
 個人的には、LambdaからSQSのPull型の実行ができれば80%くらいは解決できるのではと思っています。しかし、現時点では、Lambdaの対応リストにSQSはありません。とすると、SWFを使うしかないかという結論です。

SWF



 Simple WorkFlow(SWF)は、AWSのサービスの中で1,2位を争うややこしいサービスです。ややこしいのですが、SQSの上位互換で色々なことができます。例えば、下記のような例です。

  • タスクリストからのポーリング実行
  • 逐次処理/並列処理
  • 並列処理の終了を待って実行
  • 処理結果により分岐して実行

 詳細は、SWFのBlackBeltを参照してください。

www.slideshare.net

 ちなみにAWS界隈でも、SWFを喜々として使っていたのは@c9katayama氏と@tottokug氏しか知りません。reInventでも数多くのセッションを直接見て、その他のセッションの資料を読みましたが、SWFの文字を発見することは叶いませんでした。ということで、人類にSWFは早すぎたのではと少し疑っています。

SWF Flow Framework



 そんなSWFですが、Lambdaと連携可能になっています。ということで、試そうとしたのですが現時点でLambdaを利用可能なのはAPI経由もしくはJava版のFlow Frameworkだけです。Flow Frameworkとは、SWFのAPIをラッパーして使いやすくしたフレームワークで、Java版とRuby版のみ提供されています。正直、SWFはFlow Frameworkを使わないと面倒くさくてやってられません。また、Java版も随分とJavaを使っていない人間にはかなり辛いです。ちなみに過去にSWF Flow FrameworkのJava版を使ってハンズオンが開催されたことがあって、参加者の半分近くが環境のセットアップまででタイムアップしてしまったという話を聞いたことがあります。
 Ruby版のFlow Frameworkの使い方は、こちらをご参照ください。 www.slideshare.net

 

まとめ



 すいません。実装含めて紹介しようと思ったのですが、そこまで至れませんでした。Ruby版のFlow Frameworkを使えばすぐに出来ると油断していました。後日、再度アップします。もしかして、ついにSWFの時代が来るのかもしれません。

プログラマになりたい Advent Calendar 2015 - Adventar
プログラマになりたい Advent Calendar 2015 - Qiita
AWS Advent Calendar 2015 - Qiita

有機農業や田舎暮らしは、地球環境に優しいのか?

f:id:dkfj:20151205235111j:plain

 昔から違和感が拭えないのが、食料自給率の話や、自給自足的な生活を賞賛し地球環境に優しいという風潮です。もっというと現代社会において、田舎暮らしが環境に優しいのかという話です。

食料自給率の話



 TPPの話などで折にふれて繰り返される食料自給率の話。カロリーベースだと39%で、生産額ベースにしても64%とのことです。食料安全保障の観点から、もっと高めないといかねばという議論があります。もっともらしい話ですが、正直どうなのかなと思います。理由としては、肥料と燃料です。
 肥料の三要素としては、窒素・リン酸・カリウムです。空気の中にふんだんにある窒素や、比較的豊富に存在するカリウムについては問題ないですが、リン酸は原料となるリン鉱石の枯渇の懸念がされるほど資源量が少ないです。また日本はリン酸の全量を中国から輸入しています。この時点で、食料の自給率の話をしても仕方がないのではと思います。しかし、自給率の議論の中で肥料を含めて話す人を、少なくともテレビの中では一度も見たことありません。また、自給率の要素に、肥料は含まれていません。
 無機肥料が駄目なら有機肥料があるやんと思うかもしれませんが、有機肥料で全て賄おうとするのは夢物語です。無機肥料のみで衰えた土壌に対して、有機肥料を補助的に利用するのは有効だと思います。一方で、生産性の違いは歴然です。有機農業と慣行農業あたりをキーワードに検索を掛けると、いろいろと論文でてきますが有機農業の方が良くても7割くらいの生産性(3割減)のようです。今は、ほぼ世界中で無機肥料を中心とした農業なので、純粋に3割減したら食料足りなくなりますよね。かつ、有機肥料の肥料を生産する農地が必要になります。鶏ふんや牛ふん、後は堆肥の生産地です。これが農地の何倍にも必要になります。どこに土地があるのかという話ですね。ということで、個人的にはオーガニック礼賛は金持ちの道楽だと思っています。もちろん、化学肥料の問題もいろいろありますが、一方的に悪で有機農業が善とする風潮は好きではないです。
 また、肥料の話です。田舎で農業やってるので、たまに手伝っています。米作などは、ほぼ機械頼みです。田植えから収穫、精米と全部機械化されています。機械を動かすのは当然電気とガソリンです。両方共、元を辿れば輸入頼みですよね。ということで、食料自給率の議論はまやかしなんじゃないかなぁと思っています。

田舎暮らしの話



 田舎から大阪のアパートに帰ってきた時に、ふと気がついた点があります。田舎の家と住んでたアパートは、ほぼ同じ面積だけど住んでいる人が100倍以上違うと。田舎では、近所を村という単位で呼んでいますが1つの村(管理単位的には、町域です。)が200〜300人くらいです。当時住んでいたアパートが、13階建てで各階に7部屋あったファミリー向けだったので、たぶん200〜300人くらい住んでいました。ということで、面積辺りの集約率がここまで違うのかと気が付かされました。
 もちろん田舎の家の方が集合住宅より電気設備はないのですが、その水道・電気ガスを支えるインフラの集約度を考えると都会の方が効率的なのではと思います。気になって日本一人口が多い東京と人口の少ない鳥取で、都道府県ごとの民間部門の電力消費量を人口で割ってみると、東京の方が省エネでした。都会ぐらしというのは、結局効率が良いから集約が進んでるということです。

感想



 自然に触れ合える生活が人間に優しいのは事実だと思います。実際、私も子育ての為に少し郊外に住んでいます。ただ、人間に優しいというのと地球環境に優しいのは別問題だと思います。この辺りが混同されているような気がします。この辺りは、文明の崩壊や繁栄で繰り返し主張されています。色々な方面から考えてみたいので、農業やエネルギー関係の話をもう少し読んでみたいなぁと思っています。
 ちなみにリン鉱石の話、鳥の糞に多量に含まれていて、それが化石化したのがグアノです。グアノのおかげで、一時期は世界一の金持ちだったナウルとかそれに関係する話は興味深いのが多いです。

繁栄――明日を切り拓くための人類10万年史 (ハヤカワ・ノンフィクション文庫)

繁栄――明日を切り拓くための人類10万年史 (ハヤカワ・ノンフィクション文庫)

文明崩壊 上巻

文明崩壊 上巻

See Also:
プログラマになりたい Advent Calendar 2015 - Qiita

プログラマになりたい Advent Calendar 2015 - Adventar

アプリ側からSORACOMのSIMの回線速度の操作

 SORACOM使って色々やりたいと妄想しております。本命はIoTですが、スマホを使って手軽に出来ることから試していきましょう。その中の1つが、スマホアプリのSlow Testです。

何故、スマホアプリのスローテストが必要なのか?



 何故スマホアプリのスローテストが必要になのでしょうか?スマホアプリは様々な環境で利用されます。当然ながら、通信事情が悪くてレスポンスが遅い場合もあります。その辺りを考慮してUXを作りこまないと、利用者からのイライラはつのります。しかし、このレスポンスを遅く返すというのは中々むずかしいです。以前、API Gateway+LambdaでSleepをいれてレスポンスするとかを紹介したことがあります。これでだいぶ簡単にできるようになりましたが、APIのスタブを作らないといけないなど面倒くさいといえば面倒くさいです。ここにSORACOM使えば、実際に回線速度が変えられるので手軽ですよね。ということで試してみましょう。

SORACOMの管理者画面から変更する



 まず管理者画面で変更してみましょう。ログインして、対象のSIMの速度クラスを変更します。
f:id:dkfj:20151205050733p:plain

 一瞬で出来ますが、ネタとしては面白くないです。

APIを使って変更する



 AWSの遺伝子をひくSORACOMは、プログラマブルに操作ができるようにAPIが用意されています。嬉しいですね。それでは、さっそく試してみましょう。最初は、SORACOMのAPIリファレンスから操作してみましょう。APIリファレンスは、Swaggerで作られていて実際のAPIリクエストを簡単に投げられるようになっています。

まずは、ID,Passwordによる認証をします。
API リファレンス | SORACOM Developers
f:id:dkfj:20151205051051p:plain

API KeyとTokenが発行されます。この時点では必要ないですが、後で利用するのでどこかにコピっておきましょう。

 速度クラスの変更は、update_subscriber_speed_classを利用します。引き渡すパラメータとしては、imsi(SIMの一意の識別子)とspeed_classです。imsiは、管理画面の一覧等から取得できます。speed_classは、現在はs1.minimum,s1.slow,s1.standard,s1.fastの4種類です。
f:id:dkfj:20151205051452p:plain

リクエストを投げると簡単に変更できましたね。でも、スマホのテストするのにわざわざブラウザから変更するんかいと思いますよね

APIを呼び出すスマホアプリを作ってみる iOS編



 ということで、スマホアプリからAPIを呼んで回線速度を変更してみましょう。いろいろな所からマサカリが飛んできそうですが、肝の部分は下記のようなコードになっています。JSONファイル作って、NSURLRequestで同期呼び出ししているだけです。imsiとspeedClassを引数にし、認証の為のAPI KeyとTokenはハードコーディングしています。ごめんなさい

※2015/12/05 21:05追記 認証の部分は、メタデータサービスを利用することにより省略できます。SIMの情報により認証をスキップできるとのことです。
SORACOM Air メタデータサービスのご紹介 - SORACOM Blog
Getting Started | SORACOM Developers

- (void)updateSpeedClass:(NSString *)imsi speedClass:(NSString *)speedClass {
    NSString *jsonPostBody = [NSString stringWithFormat:@"{\"speedClass\": \"%@\"}",speedClass];
    NSData *postData = [jsonPostBody dataUsingEncoding:NSUTF8StringEncoding allowLossyConversion:YES];
    NSString* postDataLengthString = [[NSString alloc] initWithFormat:@"%lu", (unsigned long)[postData length]];
    NSMutableURLRequest *request = [[NSMutableURLRequest alloc] init];
    NSString *url = [NSString stringWithFormat:@"https://api.soracom.io/v1/subscribers/%@/update_speed_class",imsi];
    [request setURL:[NSURL URLWithString:url]];
    [request setHTTPMethod:@"POST"];
    [request setHTTPBody:postData];
    [request addValue:@"application/json" forHTTPHeaderField:@"Accept"];
    [request addValue:API_KEY forHTTPHeaderField:@"X-Soracom-API-Key"];
    [request addValue:TOKEN forHTTPHeaderField:@"X-Soracom-Token"];
    [request setValue:@"application/json" forHTTPHeaderField:@"Content-Type"];
    [request setValue:postDataLengthString forHTTPHeaderField:@"Content-Length"];
    NSError *error;
    NSURLResponse *response;
    NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
    NSLog(@"responseText = %@", [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]);
}

 ちなみにismiについては、スマホのSIM情報を取得して自動でセットしようと思ったのですがiOSではできません。Androidだと出来るようです。

 あとは、UISegmentControlとかを使って切り替えればよいと思います。
f:id:dkfj:20151205052047j:plain

 他にも通信量の取得等も簡単に出来たので、利用量のグラフ化とかも作ると面白いですよね。また、前述の通りAndroidはismiの取得が出来るので、SIMを挿した後にスマホの名前を送信して登録とかもできますね。