AWS Summit Tokyo 2日目に参加してきました

こんにちは、たじりん（@ayaka_pespes）です。

AWS Summit Tokyo 2019の2日目に参加してきました。そのレポートになります。

Serverless/AppSync によるモバイル開発の今

AppSyncとは何か、どういうメリットがあるか、というような内容でした。 AppSyncはGraghQLのマネージドサービスで、セッションを通してGraghQL便利そうだなと思いました。

事例としてグノシーの方が登壇されていました。以下のような内容を話されていました。

グノシースポーツというサービスでAppSyncを使用している
リアルタイム更新、スキーマファーストになる、複雑かつnestな構造のデータが取得が可能といった理由から、AppSyncを選択
リアルタイム更新
- Dynamoに更新があるたびにリアルタイム通知する
スキーマファースト
- GraghQLは先にスキーマを定義し、それに合わせてサーバサイドを実装するため、スキーマファーストとならざるを得ない
REST APIだとAPI仕様書が必要だが、API仕様書を記載するコストが高い
REST APIだとUIを変更するたびにAPIも修正する必要があったが、GraghQLではそういったことがない
バックエンドはUIがデータにアクセスする方法を提供
Tips
- GSI(Dynamo)だけでなく、ElasticSearchも使うと良い
- lambdaをdatasourceにするときは慎重に(ホットスタート/コールドスタートの問題など)
- 最適な環境をシュッと作れる

私自身RESTで実装していた時に、API仕様書の記述が面倒・ちょっとした画面の変更でもAPIを直さなければならないことは面倒に感じていました。 GraghQLを使うと、そういった問題が解決できそうです。今後APIを作成するときはGraghQLも候補に入れて行きたいと思いました。

最後にライブでデモをしていました。いくつかのコマンドを実行し、少しコードを修正して、簡単にwebサイトが動いていました。

CEO ジム・ローズ来日：CI/CDが変革する開発現場・ビジネスとしてのCircleCIの未来

CircleCIは日本に注力をしているそうです。日本APAC拡大へのHUBにするといった考えもあり、日本での採用を増やしているそうです。

CD(Continuous Deployment)の話をその後話していていました。結局本番環境にリリースしてみないとわからないという話でした。切り戻しが容易にできる、修正がすぐにリリースできれば本番環境にリリースし、問題があればすぐに切り戻したり、修正してリリースすることができます。

開発環境と本番環境の差異やリリース後に仕様が違うと言われることはあると思います。本番にリリースした後、大丈夫かなとよく不安になります。しかし、修正してすぐにリリースができれば、リリースのハードルが下がります。 CI/CDちゃんとやりたいなと改めて思いました。

Amazon Alexa音声インターフェースへの新しい挑戦。スマートホームを実現するAWS IoT

スマートホームの話です。しかし、スマートホームの話だけでなく、使われるスキルを作るヒントを得ることができました。

赤外線リモコンを発売されているラトックシステム様が事例として登場されていました。以下のようなお話をされていました。

AWS IoTを使った赤外線リモコンを発売している
スマートホームAPI
- APIがサポートするデバイスと機能のみ
- 発話がプリセットされている
- スキルの呼び出し名不要
- アカウントリンク必要
Alexaで赤外線リモコンを操作するとき
- Echo → skill → lambda → AWS IoT Core → 赤外線リモコン
スマホリモコンから赤外線リモコンを操作するとき
- スマホアプリ → AWS IoT Core → 赤外線リモコン
カスタムスキル
- 発話を覚えられない
- 発話が複雑になりがち
- スキル名を言う必要がある
スマートホームスキル
- 発話がシンプル
- 発話が統一されている

alexaに対応している赤外線リモコンが10万ユーザーに登り、大ヒット商品となったそうです。また、作成したスキルは作成したdeveloper以外の人にテストしてもらうのが大事だそうです。シンプルな発話は大事だと言われてはっとしました。ついつい、なんでもできる方がいいと思いがちですが、使いやすいのはシンプルなものだったりします。特に音声で操作するときは一度に提示できる情報が多くないので、いかにシンプルにするかは、かなり重要だなと思いました。