AlexaChampion岡本さんが、AlexaのQuick Linkを簡単に作るWeb Componentを作ってました。
似たようなことなんかできないかなーと思って、ブックマークレット作ってみました。
スキルIDをコピーしてブックマークレットをクリックすると、クリップボード内のスキルIDをQuick Link用URLに変換します。単純にURL生成するだけなので汎用向け。
はてなブログ使ってる自分用。使い方は同じで、はてなブログ用の埋め込みリンクにしてくれます。
たまたまドキュメントを見てて気づいたのですが、どうやらQuick Links for Alexaが日本語、というか、ほぼ全ロケールで使えるようになってるみたいです。
公式のドキュメントはここです。
Quick Linkの利用可能状況と要件
AlexaのQuick Linkは、以下のデバイスをサポートしており、以下のロケールで利用できます。
デバイス： ユーザーがQuick Linkを使用してスキルを起動できるデバイスは、 Echo（すべてのバージョン）、Echo Tap、Echo Dot（すべてのバージョン）、Echo Show（すべてのバージョン）、Echo Spot、Fire TVです。
ロケール：en_AU, en_CA, en_IN, en_GB, en_US, fr_CA, fr_FR, de_DE, hi_IN, it_IT, ja_JP, pt_BR, es_ES, es_MX, es_USに向けて作成されたカスタムスキルで利用できます。
ちゃんと「ja-JP」が含まれてますね・・・。前からドキュメントの記載がこうなっていたか？はちょっと覚えてないし、Feature Updatesのページでもen-US/es-USしか載ってないので、どうなんだろう？と思いつつ試してみました。
Quick Links for Alexaがどういうものかは、Alexa Championあおくささんのページをご覧いただくのがよいでしょう。わかりやすくまとまっています。
実際に私の公開しているスキル「神戸あるある」で試してみましょう。
日本語スキルのQuick Linksのリンクは以下のようになります。ドメインが"amazon.co.jp" になっていますね。以下のURLの「スキルID」の部分を自分のスキルのIDに書き換えるだけです。 一旦テキストエディタか何かにペーストしておきます。
https://alexa-skills.amazon.co.jp/apis/custom/skills/スキルID/launch
上記URLに含めるスキルIDを確認します。開発者コンソールを開いて、スキル一覧画面を表示、「公開中」のスキル名の下に表示されている「カスタムスキルIDをコピー」をクリックします。
すると、画面にスキルIDが表示されるとともに、クリップボードにコピーされます。
これを先程のURLのスキルIDの部分にペーストして上書きします。こういう感じになります。
https://alexa-skills.amazon.co.jp/apis/custom/skills/amzn1.ask.skill.dcd0fbc4-6015-408c-9ac2-5d993cb79b4e/launch
あとはこのURLへのリンクをブラウザなりSNSなりに貼り付ければOKです。リンクをクリックすると、こういう感じで表示されます。
「今すぐ試す」のところにユーザが持っているEchoデバイスが表示されます。これをクリックすると実際のEchoデバイスでスキルが起動するというわけですね！
Quick Links for Alexaを使うと、スキルの実行がこれまでよりもかんたんに試せるので、SNSなどでの周知から直接スキル起動という動線が期待できるかもしれません。もちろんVoiceflowで作成したスキルでも使えますので積極的に使っていきたいところですね！
ただし、現時点では、
という点についてはご注意ください。
PackerでVyOSのvagrant boxを作ったので、調子に乗ってGitLabのAMIも作ってみました。構成はこんな感じ。
$ tree . ├── files │ ├── setup_base.sh │ ├── setup_docker.sh │ └── setup_gitlab.sh └── packer.json
packer.jsonはこういう感じです。
{ "variables": { "instance_type": "t2.medium", "source_ami": "ami-0cc75a8978fbbc969", "gitlab_url": "http://gitlab.example.com" }, "builders": [ { "name": "amazon-ebs", "type": "amazon-ebs", "region": "ap-northeast-1", "source_ami": "{{user `source_ami`}}", "instance_type": "{{user `instance_type`}}", "ssh_username": "ec2-user", "ssh_timeout": "5m", "ami_name": "ami-gitlab-ee-{{isotime | clean_resource_name}}", "tags": { "Name": "ami-gitlab-ee-{{isotime | clean_resource_name}}", "Base_AMI_ID": "{{ .SourceAMI }}", "Base_AMI_NAME": "{{ .SourceAMIName }}" } } ], "provisioners": [ { "type": "shell", "scripts": [ "files/setup_base.sh", "files/setup_docker.sh", "files/setup_gitlab.sh" ], "environment_vars": [ "GITLAB_URL={{user `gitlab_url`}}" ] } ] }
環境や用途などによって変更する事が多いだろうと思われる、インスタンスタイプやGitLabのURLはvariablesで指定できるようにしてます。ベースとなるAMIは、ビルド時の最新を取るでもいいんだけど、管理上は固定しておいたほうがいいかなという、ここは好みの問題ですね。
前回VyOSのvagrant boxの場合は、buildersにvirtualbox向けの項目を設定していましたが、今回はAMI用ということでEC2な項目が並んでますね。タグでベースAMI入れておいたりするのは以下を参考にしましたが、いいアイデアだと思いました。
Provisionersではシンプルにシェルスクリプトを並べました。setup_base.shで基本パッケージ等のインストール、setup_docker.shでDockerのインストール、setup_gitlab.shでgitlabのインストールみたいな感じです。ansibleとか使ってIaCで管理していつでも再作成OK！みたいにしてもいいんだけど、auto scalingさせるようなものでもないので、それならシンプルにシェルスクリプトでいいかなと。その代わり、死んだらバックアップから戻す必要があります。逆にauto scalingさせるのであれば、何かしらIaCなツールは使ったほうがいい気がします。
で、サンプルでsetup_gitlab.shはこんな感じです。
#!/bin/bash
set -xeuo pipefail
# install gitlab
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
sudo EXTERNAL_URL="${GITLAB_URL}" yum install -y gitlab-ee
# install gitlab-runner
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E yum install -y gitlab-runner
ただのコマンドの羅列ですね。GitLabのインストールはGitLab公式の手順に従ってるんですが、yum install叩くときにGitLabのURLを環境変数で指定する必要があります。この部分はenvironment_varsで環境変数設定して、スクリプトからそれを参照して実行、みたいな感じです。sudoのしかたによっては引き継がれない場合もあるのでちょっと注意が必要かも。ただ、可変な部分は変数として切り出しておくことで、変更する場合もpacker.jsonのvariablesだけ書き換えればいいし、実行時に-varで上書きもできるのは、とてもいい感じです。
（今更ながら）Packerにも慣れてきたので色々作ってみようと思います。
