#devsumi 2018参加レポ (Developers Summit 2018) 最終日 (2/16)

デブサミ2日目 最終日!

今年も2日行けて良かった。活力注入。

【全員参加型】Botで専属トレーナー・栄養士を雇う世界が来ています。先進の擬人化技術を今日、体験しよう。
中嶋 一樹 [LINE]

LINE BotとGoogle Homeの双方のインタフェースを利用したデモ。
デモの内容は、食べたものの栄養管理とワークアウト(筋トレ)の実績管理。

Node.jsベースのbot-expressというフレームワークが、インタフェースのリクエスト/レスポンスの仕様の差を埋める。（中嶋さん作）

Skillを作成、paramとactionに集中できる。
paramとは、たとえば予約であれば人数と時間が必須になるような、それら情報のこと。

自然言語理解(NLU; Natural Language Understanding)から、翻訳、Flow(文脈; 会話のステート管理)、Webhookも出せる。

www.npmjs.com

エンタープライズアジャイル
川口 恭伸 [楽天]

エンタープライズの中でどうアジャイルするか。

決定が早くないと負ける。
上から下までエンジニアな組織だと決定が早い。(ex. MS)

文化とプロセス(デリバリー含)を顧客価値に最適化した、顧客価値駆動開発。

アンケートにエモいとフィードバックする人が居るそうな。
でもエモくていいと思うし、エモくないと聞く意味が半減すると思ってるのは自分だけでしょうか。

1日目2日目のセッションを通して、今年はVUIが普及する?

今年のトレンドはVUIですね。
多くのデモがVUIであり、そのどれもがスムーズに作動していました。
また、VUIとBotの連携も元々の親和性から、王道になっていくと感じました。

ちょっと前まではPepperに話しかけるのが恥ずかしかったり、筒に話しかけるのが恥ずかしかったりしましたが、ちょうどその転換点に居合わせたような感じがありました。

（ちなみに去年はKubernetesだなと感じていました）

展示(Twilio) をすぐ試してみる

先行してポストしましたが、今回はいくつかのセッションをパスして、展示されていたTwilioを実際に実装してみました。

デブサミ実施中に実装するメリットとして、ブースで実際にQAして、席に戻って実装して、またQAにし戻れる、という点があると感じます。
（流石にブースでPCを広げてしまうと、展示ではなくハンズオンになってしまい、展示員さんをロックしてしまうので、それは遠慮しました）

実装上の質問などなど、その場で聞けるのは良いですね。今回デブサミをこのように使ったのは初めてだったのですが、調べながらやるより全然効率が違いますね！

（自分で自分の文章を引用ｗ）
実装上の質問・仕様の質問もできたので、進みが良かったです。

ryoichi0102.hatenablog.com

当日展示されているサービス郡を連携させて、何か作るってのも面白いかも、とデブサミが終わってから、新たな使い方かなと思いました。

ex. Amazon EchoからRedmineにチケット登録したりTwilioで電話をかけたりSendGridでメールを送ったり。(組み合わせに無理やり感が…)

その後 Hackers Barへ

内容がデブサミから離れていきますが、mohikanで話題のHackers Barへ行ってきました。店員さんがハッカーで、ライブコーディングしてくれるという稀有なバー。

意気揚々と１番乗りだったのですが、ライブコーディングは20:00～とのことで。
（最近18:00～に営業時間を拡張したものの、それは単に営業時間拡張という）
次回は20:00頃に伺おう。

それでもハーヴェストムーンのビールがボトルで置いてあったり、ちゃんと(?)スティンガーがあったり、フルHDモニターが3枚ドーンで、Macが繋がっていたりするわけです。

普通のバーなら世間話、近所の話とかが話題ですが、ここは主に技術の話で、ライブコーディングをしていない時は、みんなでググりながら会話して盛り上がるという体験ができます。
（この日はデブサミとかTwilioとかSpreadsheetsの話をしたのですが、なんと「前にTwilio使ってサービスやってました」なんて話も！）

hackers.bar

そして、Uber使って懇親会へ～。
（懇親会でみんなにTwilioで電話をかけてデモw）

テックな1日でした。

AWS API Gatewayにカスタムオーソライザーを設定してみたら、判りにくい事があった

1. オーソライザーの設定方法

この位置…なんかわかりにくい…

2. Execution failed due to configuration error: Invalid JSON in response

戻りのJSONが良くないのですが、どう良くないかって話ですよね。

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/use-custom-authorizer.html#api-gateway-custom-authorizer-output

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html#api-gateway-calling-api-permissions

とりあえず動かす場合は、

callback(null, {
  "principalId": "ユーザーを特定できる文字列なら何でも良し",
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:*",
        "Effect": "Allow",
        // "Resource": "arn:aws:execute-api:ap-northeast-1:000000000000:yourApiGatewayId:*"
        "Resource": "*"
      }
    ]
  },
  "context": {
    "stringKey": "stringval",
    "numberKey": 123,
    "booleanKey": true
  }
});
}

contextにDynamo.getの戻り値(data)をセットするとうまくいかないです！！

"context": data

これハマりました。
(多分だけどJSON.stringify(data)すればいけるんだろうな…と後で思った)

policyDocumentのstatementにはIAMの指定とかではなく、IAMポリシーを作成してそれを指定するわけでもないんですね。

3. カスタムオーソライザーが呼び出されない

コンソール上のテストでは呼び出されるのに、Postmanやcurlだと呼び出されない。

⇒サイドメニュー"リソース" クリック
⇒カスタムオーソライザーを適用したいメソッドをクリック
⇒認証にて、作成したカスタムオーソライザーを指定

全部に自動的に効くわけじゃないんですね。。。面倒。

4. Invalid authorizer ID specified. Setting the authorization type to CUSTOM or COGNITO_USER_POOLS requires a valid authorizer.

画面リフレッシュしたら設定できることもあるかも知れません。
自分の場合は、オーソライザーを同じ名前で作り直したので、裏でそれが更新されていなかったのかも。

5. "Message": "User is not authorized to access this resource" が返ってくる

policyDocumentはちゃんと返してると思ったんですが、

"Resource": "*"

にしたら通りました。
少しづつ狭めて確認していきましょう。

Twilioを使ってAPIから電話をかけてみた #devsumi 番外編

経緯

APIから電話が発着信ができる時代です。前々からなんとなく知ってはいたのですが、デブサミにブース出展されていたこともあり、ちょっと書いてみました。

一般の携帯電話契約にありがちな事務手数料・プランの2年縛りなどがなく、
1つの050番号が月々108円で、番号を取得していない間はこの料金はかからず、
携帯電話宛なら1分16.2円という所が今回ちょっと試してみようかと思った経緯です。

twilio.kddi-web.com

登録

パスワードは14文字〜です。
用途などまだ決まってない方にも、I'm just exploring / I don't have a project in my mind yet / Not a production App あたりの選択肢があるので大丈夫です。

ここで自分の電話番号を認証させます。
※ ここで入力する番号から発信したりするのではなく、単に本人確認のためです。
電話番号は国番号(日本は+81)から始まるので、080-****-****であれば+8180********となります。

SMSに送られてきた4桁の認証用の数値を入力します。

認証が完了するとProject名の入力を求められます。

これで登録が完了した感がありますね。
APIを呼び出す時はここで表示されているアカウントSIDとAUTH TOKENを使います。

サイドメニューの下部のハンバーガー (○の中に…が書いてあるアイコン)を押すと、サイドメニューに表示する機能が選べます。ピン留めもできますね。

サイドメニューの＃の所が電話番号の一覧です。
ここで、"最初のTwilio電話番号を取得"ボタンをクリック。

すると、電話番号がサジェストされますが、だいたい気に入らない場合が多いと思います。横にある"別の番号を検索する"リンクをクリックします。
表示は国番号からの表示なので、+8150********は、050-****-****と読み替えます。

取得可能な電話番号が検索できます。個人的にこの機能気に入ってます！
国はJapanを選択。
ちなみに、JapanからはVoice(音声電話)とFaxの発信が選択できます。
テキストボックスの"番号"に希望の番号を入力して、
セレクトボックスから、
・Anywhere in number : 指定の番号をどこかに含む
・First part of number : 指定の番号から始まる
・Last part of number : 指定の番号で終わる
を選択します。
SMSを利用する場合は海外の番号を取得します。
(SMSの場合の料金は国際電話の料金になります。今後のアップデートに期待)

はい、検索されました。"この番号を選択"ボタンをクリック。

これで、番号が取得できました！

一覧にも表示されています。
さらに追加する場合は、一覧上部の赤丸＋アイコンをクリックです。
（これちょっとわかりにくい…）

実装

・電話番号
・アカウントSID
・AUTH TOKEN
が揃ったところで、電話をかけてみましょう。

下記に実装例を書いてみました。
当然、上記の3つの情報は環境変数設定です。

github.com

ビルドしてAWS LambdaにデプロイすればcallToに指定した電話番号に電話がかけられます！

デブサミ中に何度もブースに足を運んでQAしてわかったこと

実装上の質問などなど、その場で聞けるのは良いですね。今回デブサミをこのように使ったのは初めてだったのですが、調べながらやるより全然効率が違いますね！

・任意の電話番号に発信するには、Trial account(いわゆる無料枠)から正規アカウントにアップグレードすればよい（Trial状態では、検証済電話番号にしかかけられない）
・Trail accountで使える範囲はだいたい5コールぐらい？
・発信時に相手に繋がった後の挙動や、他の電話からの着信で受けた時の挙動は、TwiMLというxmlを書かなければいけない
https://jp.twilio.com/docs/api/twiml
・TwiML (xml) は基本どこかにアップロードしておかなければならない
・日本の電話番号からだとSMSの発信ができないため、海外の番号を取る必要があり、この場合に通話料金がかさみがち