ヤサイブログ

I'll keep hacking on fun. ~ 学びよ、加速しろ ~

AppSyncのデータソースとしてgolangのLambdaを利用する

AWS AppSyncのデータソースとして、
GO言語のLambdaハンドラーを指定した環境を構築したいと思います。

概要図

今回は、以下の図の通りに構築します。
AppSyncはMutationおよび、Queryメソッドを利用して、
Lambda Function経由でDynamoDBにアクセスし、結果を返却します。
f:id:yasay:20190210125847p:plain

AppSync API

最初にAppSyncのAPIを作成します。
今回はカスタムAPIのため、「Build from scratch」を選択します。
f:id:yasay:20190210125905p:plain

DynamoDB

DynamoDBのテーブルを作成します。
今回はString型のpk, skを定義したシンプルなテーブルとします。

f:id:yasay:20190210125924p:plain

AppSync Schema

AppSync APIのSchemaを記述します。
今回はPostの型にfieldという項目を設け、
Lambdaの処理を分岐させるように実装しました。

type Mutation {
    putPost(
        field: String!,
        pk: String!,
        sk: String!,
        title: String!
    ): Post
}

type Post {
    field: String!
    pk: String!
    sk: String!
    title: String
}

type Query {
    singlePost(field: String!, pk: String!, sk: String!): Post
}

schema {
    query: Query
    mutation: Mutation
}

Lambda Handler

Lambdaハンドラーを実装します。
今回は、Serverless Application Model(SAM)を用いました。
golangのswitch構文によりfieldの値で処理が分岐し、
DynamoDBへのputまたは、getを実行します。

package main

import (
    "fmt"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/dynamodb"
    "github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute"
)

type Post struct {
    Field string `json:"field"`
    Pk    string `json:"pk"`
    Sk    string `json:"sk"`
    Title string `json:"title"`
}

type Response struct {
    Pk    string `json:"pk"`
    Sk    string `json:"sk"`
    Title string `json:"title"`
}

func hander(arg Post) (Response, error) {

    response := Response{}

    fmt.Println("[DEBUG]Start create session.")
    session, err := session.NewSession(
        &aws.Config{Region: aws.String("ap-northeast-1")},
    )
    if err != nil {
        return Response{}, err
    }
    svc := dynamodb.New(session)

    switch arg.Field {
    case "putPost":
        input := &dynamodb.PutItemInput{
            Item: map[string]*dynamodb.AttributeValue{
                "pk": {
                    S: aws.String(arg.Pk),
                },
                "sk": {
                    S: aws.String(arg.Sk),
                },
                "title": {
                    S: aws.String(arg.Title),
                },
            },
            TableName: aws.String("appsync-lambda-go"),
        }

        _, err = svc.PutItem(input)
        if err != nil {
            return Response{}, err
        }

        response.Pk = arg.Pk
        response.Sk = arg.Sk
        response.Title = arg.Title

    case "singlePost":
        input := &dynamodb.GetItemInput{
            Key: map[string]*dynamodb.AttributeValue{
                "pk": {
                    S: aws.String(arg.Pk),
                },
                "sk": {
                    S: aws.String(arg.Sk),
                },
            },
            TableName: aws.String("appsync-lambda-go"),
        }

        result, err := svc.GetItem(input)
        if err != nil {
            return Response{}, err
        }

        resultData := &Response{}
        if err := dynamodbattribute.UnmarshalMap(result.Item, resultData); err != nil {
            return Response{}, err
        }
        response.Pk = resultData.Pk
        response.Sk = resultData.Sk
        response.Title = resultData.Title
    }

    return response, nil
}

func main() {
    lambda.Start(hander)
}

AppSync DataSource

実装済みのLambda FunctionをAppSyncのデータソースに指定します。

f:id:yasay:20190210125948p:plain

AppSync Schema Resolver

Mutationおよび、QueryのResolverを指定します。
今回は下記のリクエスト・レスポンスマッピングテンプレートを設定しました。

request mapping template.

{
    "version" : "2017-02-28",
    "operation": "Invoke",
    "payload": $util.toJson($context.arguments)
}

response mapping template.

$util.toJson($context.result)

動作確認

動作確認をしていきます。

Mutation

AppSyncのQueries画面で下記クエリを記述し、実行します。

mutation PutPost {
  putPost(field: "putPost", pk: "hoge", sk: "huga", title: "Hello! AppSync!!") {
    pk
    sk
    title
  }
}

実行結果

f:id:yasay:20190210130023p:plain
f:id:yasay:20190210130038p:plain
DynamoDBにデータが保存され、レスポンスも期待した値が返却されました!

Query

AppSyncのQueriess画面に下記クエリを記述し、実行します。

query GetPost {
  singlePost(field: "singlePost", pk: "hoge", sk: "huga") {
    pk
    sk
    title
  }
}

実行結果

f:id:yasay:20190210130108p:plain
Mutationで登録したデータが、取得できています!

データソースにLambdaを指定した場合の実装は無限大

Lambdaで処理を記述することで、その実装は無限大です。
例えば、以下の図のようにS3にリクエストパラメータを保存し、
分析用途としても利用することもできるでしょう。
f:id:yasay:20190210130123p:plain

改善点

今回はリクエストパラメータにfieldという項目を用意し、
Lambdaの処理を分岐しました。

しかしながら、AppSyncのためのAppSyncResolverTemplateを利用することが
最適解ではないかと思います。
AppSyncResolverTemplateを利用するよう、改善していければと思います。

AppSyncResolverTemplateによる実装例

package main

import (
    "context"
    "fmt"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

func handler(ctx context.Context, event events.AppSyncResolverTemplate) error {

  fmt.Printf("Version: %s\n", event.Version)
  fmt.Printf("Operation: %s\n", event.Operation)
  fmt.Printf("Payload: %s\n", string(event.Payload))

    return nil
}

AWS セキュリティグループの適用パターン

AWSのセキュリティグループにおいて、
私が直近で利用している適用パターンを紹介します。
(ちなみに、名称は私が勝手に考えました(´・ω・`))

allow self subnet方式

セキュリティグループ(以下SG)のインバウンドルールに、
SGを設定することができることを利用し、
簡易的にインスタンス間のインバウンドを有効にする方法です。

f:id:yasay:20190128223923p:plain

メリットとして、当該SGを設定したインスタンス全てにおいて、
特定ポートの疎通が可能になるので、インスタンス個別に新しい SGを定義する
必要がなくなります。

allow ELB's sg方式

上記のallow self subnet方式に近いです。
こちらの場合、ELBのリスナとして設定されているEC2インスタンスのSGに
ELBのSGを設定することで、ELB経由のみしかアクセスさせないことを
簡単に実現できます。

f:id:yasay:20190128225305p:plain

analog sg方式

こちらは番外的な位置付けではあります。
対抗サーバのグローバルIPアドレスを登録したSGを一つ作り、
インスタンスに適用します。

同じサブネットに配置しているサーバ間連携にも関わらず
パブリックIPで一度外に出てしまっているようなサーバにおいて、
特定のIPのみ許可するSGを適用することで、許可したアクセス元以外を遮断します。

f:id:yasay:20190128230830p:plain

何を言っているんだと思われるかもしれませんが、
パブリックサブネットをNATゲートウェイを利用せずに、
擬似的にプライベートサブネットにする方法だと思っていただければと。
( ※それでも何を言っているのか・・(ry )

プライベートIP間で通信すればいいじゃん的な話ではあるんですが、
パブリックIPがアプリケーション内にハードコーディングされているような
レガシー(;ω;)なサーバアプリケーションにおいて効果を発揮します。

おわりに

他にもよい適用パターンがあれば、
本エントリーを更新していきたいと思っていますが、
インバウンドルールにSGを設定できるので応用パターンは
もっと存在するのかなぁと思います。

以上です!

プログラミング言語の命名ルールとgolangにおける傾向について

プログラマー命名ルールに敏感です!敏感プログラマー
命名ルールに則ってない記述を見つけるともにゅっ(´・ω・`)とします。

それも、もちろん経緯があります。
同じプログラミング言語で記述されたファイルにおいて、
下記のような名前があったらどう思いますでしょうか。

CreateFutureIssue.java
delete_future_issue.java

・・・どちらかに揃えたいと思いますよね!まずはそこからになります。

命名には様々なルールがありますので、下記に紹介したあと、
golangにおける傾向を見ていきたいと思います。

キャメルケース(camelCase)

ラクダの背中のように見えることから Camel case と呼ばれます。

一番最初の単語を大文字にしたケースをアッパーキャメルケースまたは、
パスカルケースと呼ぶようです。

Javaにおいてインスタンス変数にキャメルケース、
クラスファイル名パスカルケースが使われているのかなという印象です!

Javaにおけるキャメルケースによるインスタンス変数の定義例

f:id:yasay:20190128203354p:plain

Javaにおけるパスカルケースによるクラスファイル名の定義例

f:id:yasay:20190128203602p:plain

スネークケース(snake_case)

地をはう蛇のように見えることから Snake case と呼ばれます。

Javaにおいてもfinal修飾子を加えたグローバルスコープ変数などに利用されます。
しかしながら、Javaのグローバルスコープ変数は大文字で記述する例が多く、
この場合はスクリーミングスネークケースとも呼ばれるようです。

Javaにおけるスネークケースによる変数の定義例

f:id:yasay:20190128204532p:plain

ケバブケース(kebab-case)

串が刺さったケバブのように見えることから Kebab case と呼びます。

GitHubリポジトリ名に使われる習慣がありますね。
文字の入力方法にしても「Shiftキー」を使う必要がないということで、
もっとも楽な入力方法ではあると思います。

マークダウンファイルのファイル名や、AWSリソースへの命名など、
個人的にはケバブケースの利用頻度が高まっています。
頭を大文字にしたケバブケースをトレインケースとも呼ぶようです。

マークダウンにおけるケバブケースによるファイル名の定義例

f:id:yasay:20190128204114p:plain

golangにおける命名ルールの傾向

golangの有名なOSSとして、「Docker」がありますね。
個人的に注目している「Vuls」も含めて、ソースコードを覗いてみました!
github.com
github.com
github.com
github.com

可視性

golangはメンバーの可視性(Public/Private)を
先頭大文字で判定する言語仕様がありますので、
変数やメソッド名の命名規則は基本的にキャメルケースまたは
パスカルケースで統一
されていますね。

golangにおけるキャメル・パスカルケースによる変数の定義例

f:id:yasay:20190128212626p:plain

ただし、golangのファイル名については
スネークケースとする習慣があるようです。

golangにおけるスネークケースによるファイル名の定義例

f:id:yasay:20190128212733p:plain

所感

プログラマー界隈では命名ルールは知ってて当たり前的なノリになるので、
新人に対して、変数やクラス名などの命名ルール規則まで詳しくフォローしてくれる人は
稀なのかなと思っています。

「ここ、キャメルケースになっているのでスネークケースに直して~」的なレビューが
飛んできた時、ベテランプログラマーなら問題ないでしょうが、
新人だと「スネークケースってなんだ?」ってなってしまうでしょうね。

各言語を利用する前に、命名ルールを把握しておけば
新規プロジェクトにスムーズに取り組めると思います!

参考サイト

tbpgr.hatenablog.com

以上です!

Alexa Skills Kit(ASK) SDK for Node.js バージョン2を適用した

ASK SDK for Node.js バージョン2を
私が個人で運用しているAlexaカスタムスキル「五月雨の音」に適用しました。

www.amazon.co.jp

実践した事柄を紹介します。

Alexa Skills Kit(ASK) SDK for Node.js バージョン2とは

まず、「ASK SDK for Node.js バージョン2」についてです。
Alexaカスタムスキルをコーディングする時に、
様々な言語を利用して直書きすることも可能ではあるのですが、
Alexaの機能にアクセスする命令をラップしたSDKも提供されています。
それが「ASK SDK for Node.js」になります。

github.com

ASK SDK for Node.jsは2018年5月にバージョン2がリリースされました。
私のカスタムスキルはバージョン1で動作していました。
今回、バージョン2を適用するようにマイグレーションしました。

実践したこと

1. テストコード記述によるハッピーパスの確認

ASK SDK for Node.js バージョン2にマイグレーションする時にまず実践したことが、
テストコードの記述です。

テストコードに関するセッションで有名なt.wadaさんに影響を受けて、
Alexaのテストコードによるハッピーパスの確認を行うようにしました。
Testing Frameworkは、Alexa Skill Test Frameworkを利用しました。

github.com

下記のようにテストを実行することで、動作確認が行えます。

f:id:yasay:20190126030725p:plain

2. CI環境の構築

テストコードを記述したことにより、CIをするための準備が整いました。
CI環境にはCircleCIを利用しました。

circleci.com

CircleCIはパブリックリポジトリであれば4コンテナまで無料で実行可能です。
Alexaカスタムスキル「五月雨の音」はパブリックリポジトリで運用しているため、
その恩恵を充分に受けることが出来ます。

ビルドおよびテストの結果はSlackのWebhookで通知されます。

f:id:yasay:20190126030903p:plain

CircleCIはローカルで動作確認するためのコマンドが用意されています。
ローカルなら、リポジトリへのpushをトリガーとする必要がないため、
円滑にCI環境の構築が行えます。

# ローカル実行のためのCLIをインストール
sudo curl https://raw.githubusercontent.com/CircleCI-Public/circleci-cli/master/install.sh \
--fail --show-error | bash

# アップデートの確認
circleci update check

# アップデートにインストール
circleci update install

# configファイル検証
circleci config validate

# localでの動作確認
circleci local execute

3. SAM CLIによるInvoke処理の確認

LambdaはAWS SAMによってデプロイしています。
SAM CLIはローカルでAWS Lambdaを実行するためのコンテナが起動します。
つまり、プロダクションにデプロイする前にLambdaのinvokeによる動作確認が出来ます。

# sam localによるLambdaのinvoke
sam local invoke "serverlessFunction" --event "./test/event/SoundsOfRainIntent.json"

4. ASK CLIによる動作確認

ASK CLIによるインテント呼び出し観点での動作確認をしました。
Alexaは自然言語処理を介してLambdaのIntentハンドラーが呼び出されるので、
Alexa側の呼び出しをシミュレートするコマンドが用意されています。
それが、「ASK CLI」になります。

# シミュレートの実行(LaunchRequest)
ask simulate --text "さみだれのおとを開いて" --locale ja-JP \
--skill-id ${ALEXA_SOUNDS_OF_RAIN_APP_ID} --profile xblood

5. オーディオファイルにCloudFrontを適用

このタイミングを機に、パブリックなS3バケットからのAudioファイルの取得から、
CloudFront経由に乗り換えました。許可したくないアクセス元が存在する場合、
WAFによるセキュリティ対策も可能になりました。
AWSリソースはTerraformを用いて構築しました。

6. エイリアス定義の見直し

LambdaのエイリアスにAutoPublishAlias属性を使用していたのですが、
Lambda単体でAutoPublishAlias属性を利用するメリットが今回のケースでは無いため、
アライアスはマネージメントコンソールから付与するように変更しました。

課題点

ASK SDK for Node.js バージョン2の適用は成功しましたが、課題も残りました。

コード補完が使えない。

Intentに対応する各種ハンドラーはconstで定義された関数として記述します。
この時、私のvscodeの開発環境ではコード補完が行われなかったため、
テストコードを実行するまでは記述内容が正しいのか不安になることがありました。

これについては私のNode.jsスキルが上昇すれば解決すると思いますが、
TypeScriptによるカスタムスキルの実装も実践していきたい。

// handlerInputにコード補完が利用できない
const LaunchRequestHandler = {
    canHandle(handlerInput) {
        return handlerInput.requestEnvelope.request.type === 'LaunchRequest';
    },
    handle(handlerInput) {
        console.log('Start LaunchRequest');
        return handlerInput.responseBuilder
            .speak(HELP_MESSAGE)
            .reprompt(HELP_MESSAGE)
            .getResponse();
    }
};

CD環境の構築

CI環境まで構築できれば、あと少しの手間でCD環境も構築できます。
今後はリリースブランチへのプッシュによるCD環境構築を実践していきたい。

おわりに

常に自分にとって新しい関心事をインプットとし、
アウトプットも今までにないことをする。
この姿勢を維持し、これからも取り組んでいきたいと思います。

Slackの個人活用テク - 通知チャンネルの古いメッセージを自動的に削除するスクリプトをAWS Lambdaで動かす

2019年の初投稿ですっ!
私は個人用Slackワークスペースに様々な通知を流しています。

  • Googleカレンダーの予定
  • ファイルバックアップ完了の通知
  • 動画エンコード結果の通知
  • CircleCIのビルド結果の通知
  • SharedBoxによるメール転送の通知

などなどです。

しかしながら、個人用の通知チャンネルの場合、
過去の通知情報を保存しておく必要はありません。
不要な通知情報が溜まりすぎて無料で検索できる1万メッセージの上限を
越えてしまうことのほうが不便だと思います。

ですので、通知チャンネルに投稿された過去のメッセージを
削除するLambdaファンクションを作成しました。

github.com

ポイントをピックアップします↓

Slack Appでトークンを発行して、APIを呼び出す

今回、レガシートークンは利用せず、Slack Appでトークンを発行しました。
下記の記事がよくまとめられています。 qiita.com

APIを利用したいだけでしたので、今回は「sandbox」という名前で
Slack Appを作成し、必要なPermission Scopeを付与しています。
f:id:yasay:20181231234358p:plain

API実行のために付与したPermission Scopeは下記の通りです f:id:yasay:20181231235151p:plain

Lambdaの処理内容

やっていることはシンプルです。

  1. LambdaやCloudWatch eventsに設定されている変数を読み込む
  2. "channels.history"APIを利用して削除対象メッセージを取得する
  3. "chat.delete"APIを利用してメッセージを削除する
  4. "chat.postMessage"APIを利用して処理結果を通知する

処理結果の通知イメージ

f:id:yasay:20190101000950p:plain

ソースコード

Epoch Timeの取得処理

Slackのメッセージを取得する時に、Unixタイムスタンプで指定します。
Python3では、下記のようなコードで、Unixタイムスタンプ(Epoch Time)を取得できます↓

コード全貌

以上です!
2019年も良い年になりますように!🐗㊗️

読書感想「Team Geek」

f:id:yasay:20181225183254p:plain:w200
「Team Geek」という書籍を読了しました。

www.oreilly.co.jp

「Team Geek」はプログラマが実践すべきチームでの
コミュニケーション手法を明確に定義しています。

尚、HRTについては以前から知っていまして、
私はここ数年、なるべくHRTを実践するように取り組んできました。
今回、HRTの出典元となる本書を手に取る機会が訪れました。

あくまで個人的な読書感想になりますので、
結構ずけずけと感想を述べていきますよ↓

読書感想

ハート(HRT)はお互いが意識しないと成立しないよね。

そもそもの話、お互いがハート(HRT)の意識を持たないと成立しないと思います。

そういえば「GNUの心あるコミュニケーションのガイドライン」も発表されてましたね。
gigazine.net

例えば、片方が謙虚な姿勢を見せたとしても、
相手の謙虚な姿勢を見て、ここぞとばかりに自分の優位性をアピールする場合がある。

人生にはライフステージがある。

結婚・子育て・介護など、仕事以外にも重要なタスクをこなしながら、
私たちは仕事でのやりがいも見つけていく。
ライフステージによって、HRTで実践できる事柄も
限られる場合があるのではないか。

今だかつでHRTを意識した上司に恵まれたことがあっただろうか?

いや、ない。
私達はいつでもコミュニケーションの混沌にいる。

HRTを意識して仕事している人は稀だということ

この本を読んだ日本人なら誰だってそう思うんじゃないかな。
そもそも多重請負構造を構成している日本のSIerの全員が、
HRTを意識しているわけがない。下請けになればなるほど、
職業プログラマがほとんどを占めているだろう。

だからこそ、私達はHRTを理解したチームを作り上げる必要がある。

組織としてHRTを浸透させる取り組みを行なっていないならば、
私たちは今の組織に居続けるべきか考える必要がある。

意外にも出版されたのは数年前という若い書籍

もっと昔に出版されれば、Teem Geekの考え方も
浸透していたかもしれない。というか、浸透してから就職したかったなぁ。
いつやるか。今でしょ。」のフレーズが出てくる辺りまさに最近。

忘れてはいけないこと

三本柱

1. 謙虚(Humility)

常に自分を改善する。

2. 尊敬(Respect)

心から相手を思いやる。

3. 信頼(Trust)

相手が正しいことをすると信じる。

心の中にいつでもミッションステートメントを持つ

そうすれば、私達の行動はぶれないだろう。
プロジェクトのミッションステートメントとして定義されれば、なおよい。

チームが全て

逆に言うと、チームで開発に取り組まず丸投げの会社は非常に好ましくないね。

私は私の書いたコードではない

プログラミングはスキルなので、練習すれば向上する。
自分の性格や人間としての価値が攻撃されたと思わないように、
全員との意識合わせが必要なんだ。

早い失敗・学習・反復する

だからこそ、しくじり話として共有することが重要だと認識できる。

パフォーマンス重要

パフォーマンスを軽視してはならない。
ユーザーが利用する時のパフォーマンスが改善すれば、
利用頻度が増えるのは必然だ。
ユーザーとの信頼を構築するステップにもなるはず。

総括

心から思いやれる人と一緒に仕事したいです。
本書は何度も何度も読み返すことになると思います。
もっと人間としても成長したいなぁ。

以上ですっ!

ALEXA DEV SUMMIT Tokyo 2018 行ってきました!レポート

f:id:yasay:20181217170513p:plain alexadevsummittokyo.splashthat.com

行ってきました!ALEXA DEV SUMMIT Tokyo 2018!
Amazon Alexaが主役の開発者向けイベントになります!
レポートしていきます!

セッションレポート

13:00 - 13:50 Alexa最新テクノロジーアップデート ~ AWS re:Invent 2018 recap ~

  • 北米ではMyPetRocが人気
    f:id:yasay:20181217223301j:plain:w400
  • re:Inventの紹介
    • セッションの移動にシャトルバスwww
    • セッション数2100www
    • 桁が違いすぎるwww
  • 北米ではゲームが人気
  • TIPS「サウンド効果」
    • 短い時間で効果的にメッセージを伝えることができます。
    • クイズの正解に言葉ではなくサウンドを利用
    • イベントの違いにサウンドを活用
    • SSMLによる会話の間に音声を挟む!
  • 最新アップデートの紹介
    • PollyをAlexa Custom Skillで利用できるようになった
      • Alexa SkillでPollyを使うと無料です!
    • SMAPIを使うためのASK CLI
      • 毎週スロット内容が変わるような場合にCLIを利用すると楽
    • ベータテストツール
      • 対話のパス解析
      • マネタイズ
    • Amazon Pay 1ヶ月前に使えるようになった
    • どこでもAlexa
      • Alexa Built In の端末のこと
    • Echo Button 日本にはまだ来てない
      • Session Extension
      • Mic Control
      • Queue or Interrupt TTS
        f:id:yasay:20181217223501j:plain:w400 f:id:yasay:20181217223509j:plain:w400
  • 音声ファーストUX(ユーザ体験)
    • 状況に応じたデザイン
    • Alexaでなくユーザーが主導
    • フローチャートよりストーリーボード
  • APL
    • Echo ShowやEcho Spotで利用
    • コンポーネント、スタイル、レイアウト、リソース
    • 条件式
    • コマンド
      f:id:yasay:20181217224009j:plain:w400

所感

面白おかしくre:Inventで発表されたアップデートを紹介してくださるセッションで、
午後一のセッションとしては気楽に聴講できて楽しかったです!
登壇者の方はNY出身ですが漢検3級を取得していたりと、
かなり日本語が得意みたいでとても聞き取りやすい日本語で喋ってくれました! アップデート内容はすぐにでも試してみたい機能もありました。
しかしながら、Echo Spotの金額が結構高いので、
開発で試すためにどこかのタイミングで購入したい・・。

14:00 - 14:50 スキルのデザイン・実装のベストプラクティス

  • オトッペの音遊び、ディズニー絵本
  • スキルのデザイン・実装のステップ
    • スキルのデザイン
      • 会話の台本を作る
        • 一番気持ちい形でユーザーが使ったら、どんな体験になるかを思い浮かべる
        • 自然にAlexaと会話するケースをイメージする
          • 人間と人間の会話の片方がAlexaに置き換わるイメージ
            f:id:yasay:20181217224250j:plain:w400
      • 対話のフローを作る
        • 台本の質問に注目
        • 状態を矢印でつないでいく
          f:id:yasay:20181217224531j:plain:w400 f:id:yasay:20181217224606j:plain:w400
      • 対話モデルの準備(インテントスキーマの作成)
    • スキルの開発
      • Lambdaの実装
        f:id:yasay:20181217224939j:plain:w400 f:id:yasay:20181217225014j:plain:w400 f:id:yasay:20181217225108j:plain:w400 f:id:yasay:20181217225144j:plain:w400 f:id:yasay:20181217225231j:plain:w400 f:id:yasay:20181217225258j:plain:w400

所感

私が運用しているAlexaカスタムスキルはシンプルなので、
ここまでベスト・プラクティスに則った設計も必要ないのだけれど、
受託開発案件になると必要なノウハウだよなぁと思う。

なので、sandbox環境に対しての設計の実践をやっておきたいと思いました!

15:00 - 15:50 百官店・外食チェーン事例に見る既存のビジネスにVUIを組み込むためのポイント

  • 会社紹介
    • 先行者事例・先行者利益
      • 誰よりも早く、誰よりも詳しくなる。
      • 他の会社が目をつけたときには、既に先行者利益を獲得。
    • 導入した業種は様々。クラメソ単体でも18スキルある。
    • Alexa TRAININGの技術者講師も担当
    • Alexa Agencyというパートナープログラムがある
  • ビジネスにVUIをどのように活かしていくか
    • CUI -> GUI -> Web -> Mobile -> VUI
      • インターフェースの歴史は10年間毎に入れ替わっている的な話
    • 北米だと2,3割?の人がVUIを利用。買い物などを行なっている
    • VUIで高齢者にリーチできるかも的な話
      f:id:yasay:20181217230226j:plain:w400
    • 問い合わせ対応、受付業務、インフォメーション
      • 人手が足りないという状況において活用できる・・かも
    • スシロー様による注文のカスタムスキル
      f:id:yasay:20181217230433j:plain:w400
    • 美和電気工業様によるコボッタとAlexaの連携ソリューション
      • ピンクの玉を取ってと言ったらコボッタがそういう動きをする
        f:id:yasay:20181217230348j:plain:w400
    • ジャパンネット銀行様による機能ごとの3つのスキル分割
      • ファットなスキルではなく機能ごとにスキルをまとめた方が扱いやすい
      • 4ヶ月単位でリリース
    • パルコ様による事例
      • 運用フロー大事
        • ログを適切に仕込んだ可視化
        • バックエンドには審査が入らない
        • ヒューマンエラーの温床
        • なるべく自動化(CI, CD)
          f:id:yasay:20181217230612j:plain:w400 f:id:yasay:20181217230655j:plain:w400 f:id:yasay:20181217230733j:plain:w400 f:id:yasay:20181217230818p:plain:w400

所感

先行者利益という言葉は、何も本当の利益に適用されるだけのものじゃなくて、
エンジニアの福利厚生という意味の先行者知識という考え方もありなんじゃないかな。
今日のご飯、明日のご飯という考え方いいね。
個人的には先行知識を増やした時の血が通っていく感じが好き。
(先行ではないかもしれないけどね)

16:00 - 16:50 Alexaスキルアワードの振り返りとスキル開発の最新トレンド

  • 振り返り
    • Mashup Award, HackChus
    • 365作品のスキル応募があった
      f:id:yasay:20181217230902j:plain:w400
    • 最優秀賞
      • クイックちゃん
        • 視覚に障害を抱えるヘルスキーパーの方が晴眼者のフォローなしで業務遂行を可能とするためのスキル
          f:id:yasay:20181217230951j:plain:w400
      • みんなのおりがみ
        • 折り紙の折り方を音声と画像で教えてくれるスキル。Echo Spotをいち早く取り入れたスキル
      • GUIの進化は視覚障害者にとって、本当に正しい進化なのか。VUIの意義を忘れないでほしい。
    • スマホの方が便利じゃん!って言われたら負け。音声である理由を考えること。音声の方が圧倒的に便利な体験を提供することが重要
    • 機能を増やせば増やすほどメニューが増える、ユーザーが使いにくくなる。だからもっとVUIのことを考えていこうよ。
    • 来年は"Quality"と"Quantity"のバランス取っていきたい
      f:id:yasay:20181217231030j:plain:w400

所感

途中から既存スキルの応募も可能になったこともあり、
応募者数が相当少なくて焦ってたんだろうなぁと思っていた。
グラフで見る通り、本当に応募期間の終盤まで応募が少なかったんですねw
いつもAlexa道場を担当している方が登壇しているセッションで、
リアルでお顔を拝見できてよかったです。
自分の時間に余裕があればもう少し
アイディアを練ったスキルを作ってみたいけど・・

17:00 - 17:50 Alexa Pay技術入門 ~ Amazon Payを使ったスキル開発にあたって ~

  • Amazon Payとは
    • Alexaスキル向けの技術仕様が一般公開された
    • オーソリ = 信用確認してカード利用枠を押さえること
      1. 事業者はカード会社へオーソリ実行
      2. カード会社はオーソリ結果を返す
    • PCI DSS/クレジットカード情報の非保持化
  • Amazon Payの開発にあたって
    • Amazon Pay導入に必要な技術情報は一般公開
    • 開発効率化のためにSDK・開発補助ツールを提供
    • ワンタイムペイメント
      • 都度決済機能
    • Auto Pay
    • Alexa Amazon Pay 技術仕様
      • Alexaスキル向けAmazon Payの概要
      • Setup API
        • 決済の準備をするAPI
      • Charge API
        • 実際に決済を実施するAPI
      • 支払いDeclineと処理エラー
        • Charge APIでオーソリが実行された場合のエラーハンドリング(決済失敗したことを伝える)が大事
          f:id:yasay:20181217231326j:plain:w400 f:id:yasay:20181217231354j:plain:w400 f:id:yasay:20181217231427j:plain:w400

スマートホーム体験

f:id:yasay:20181217225440j:plain:w400
LED電球やスマートプラグ、そしてカメラが展示されていました。
カメラはEcho Spotと連携して、Echo Spotに映像を映せるようです。

ミュージック体験

f:id:yasay:20181217225616j:plain:w400
なんとBOSEノイズキャンセリング・ヘッドフォンがAlexaに対応していました!
話を聞いた限りですと飛行機の中でも寝れるくらいノイズを軽減できるとのこと。
これは欲しいなぁ 😄

総括

Alexaの最新情報を取得しつつ、
スキルのベスト・プラクティスのノウハウも学べる素晴らしいイベントでした!

ここ最近、Alexaの技術情報をキャッチアップしていなかったので、
このようなイベントは本当にありがたいです!

以上です!