簡易的なAlexaアプリを作ってみた

1.はじめに

こんにちわ、こんばんわ。

そして明けましておめでとうございます。

新年になって2週間経ってからようやく新年初ブログ更新できました。

皆さんはいかがお過ごしでしょうか。

さて、今回私は表題の通りアレクサアプリを作成してみました。

というのも昨年海外でスマートスピーカーが大流行し、日本にもその波がいずれ来るだろうということで勉強しても損はないと思ったからです。

昨年の年末には私もAlexaを購入し、私生活で使っていたのですがこれが中々に便利。

確かに売れるのも納得。

それじゃあ自分もアプリを作りますか、ということで今回に至ります。

と言っても実際にアプリを作ってみるとこれがかなりお手軽にできる。

ネット上には既にいくつか私の記事と同じようにアレクサアプリを作ってみたという感じで丁寧な説明がありますので、過去の私にこんなにお手軽に作れるんだよ！ってオススメするという体でいきます。

2.アレクサとは

そもそもアレクサとはなんぞやという方に向けて簡単に説明を。

先ほどチラッと出てきましたが、所謂スマートスピーカーと呼ばれるものでappleユーザの方ならSiriをイメージしてもらうとわかりやすいかもしれません。

Wikiには対話型のAI機能を搭載した音声スピーカーと記述がありました。端的に表していますね。

用途は電気をつけてもらったり、曲をかけたり、ニュースを流したりと使い方は千差万別。

さすがにスマートフォンの次と称されるだけはある程の便利さです。

その中で私がアレクサを購入した理由はズバリ、シェアです。

昨年の市場シェアでは68%がAmazonでGoogleが26.2%。

(Amazonが開発しているのがAlexa、Googleが開発しているのがGoogle Home)

2倍以上の差が付いていたので情報量にも差があるだろうということで、Alexaにしました。

まあ使い比べている訳ではないのでどちらが優れているとは言い切れないんですけどね。単純に今回は勉強・開発も兼ねていたからというだけです。

実際にGoogleもシェアを伸ばしてきいるとのことですし。

3.実際にアプリ作成

それでは簡単な説明もしたところで、アプリ作成へと移ります。

手順としては以下の通り。

・Amazon Developerのアカウント取得

→呼び出し名、インテント、スロットの設定

→ビルド

・AWSのアカウント取得

→Lambda関数の作成

→ロールの作成

→コードの記述

→Amazon Developerの作成したアプリのエンドポイントの設定をする

凄いざっくりと書いたけどコードの記述量もほとんどないし本当にあっという間に出来上がります。

(もちろん今回作成したものが簡易的なものだからっていうのもありますが。。。)

今回私が作成したのはAlexaに将棋の守りを聞くと教えてくれるというアプリです。

では順番に見ていきましょう。

Alexaはウェイクワード+呼び出し名+インテントと対応する言葉で言葉を返します。

ウェイクワードというのはAlexa自体を起動するワードです。

SiriであればHey,Siri!ですし、GoogleであればOK,Google!。Alexaの場合はそのまんまAlexaになります。

呼び出し名はAlexaアプリを起動するときに発する言葉です。

この名前は唯一無二なので登録したもの勝ちだったりします。

そういう意味でもキャッチーな名前は大事ですね。

まあ自分の場合はそういうネーミングセンスはないので、今回はシンプルに将棋の守りでいきます。こんな感じ。

インテントはAlexaアプリに行ってもらう動作です。

今回であれば「教えて」であったり「守りかた」であったりといった具合ですね。

まずはインテントの名称を作成しましょう。いわゆる関数名ですね。

インテントを作成したら今度は呼び出しに使われると考えられる言葉を追加していきます。

今回は雑学、豆知識、何か教えて、教えての4つで行うことにしました。

アプリを呼び出すには今回の例で言えば「Alexa、将棋の守り方、何か教えて」といった感じになります。簡単ですね。

ここまで進んだらビルドしましょう。

ビルドをしたら次はLambda関数の作成です。

AWSにログインして、AWSサービスでLambda関数を作成します。

Lambdaとはサーバレスでコードを実行するものだそうです。

なんか凄い便利そう(コナミ

関数を作成したら設計図からalexa-skill-kit-sdk-factskillを見つける。

このとき自分が詰まったのは、右上部にある場所をアジアパシフィック(東京)を選択していなかったこと。

ここで場所の選択をしていないと後の作り方が変わってくるので注意。

選択後は関数名を入力し、作成。

関数の作成ができたら作成した関数のページでトリガーの追加からAlexa Skill Kitを選択。 

選択をしたら、Amazon開発者コンソールに戻ってスキル一覧からSkill IDをコピーしてLambdaのスキルIDにペーストして保存。

保存ができたらいよいよコードの記述。

初期で記述されているコード内にあるAPP_IDはスキルIDのことなので、先ほどコピーしてきたスキルIDをここにもペースト。

記述した内容はこんな感じ。

画像のXXXXのところにスキルIDを貼り付ける。

 1枚目の画像が変数の定義で2枚目がメイン処理とハンドラ。

流れとしてはメイン処理でSDKの利用宣言をして、アプリケーションIDの設定後ハンドラの記述内の処理を行う。

speechOutputやrepromptなどはAlexaの応答設定であったり聞き直す設定。

あとはここに想定される処理を記述していく。

記述ができたら右上部の保存をし、その上にあるARNコードをメモしておく。

再度Amazon開発者コンソールへ戻ってスキル一覧から編集でエンドポイントのデフォルトの地域に先ほどメモしたコードを貼り付けることで完成！

完成したらあとはスキル名等が書いてあるタブからテストを選択しenabledにすればデバッグができる。

4.まとめ・総評

さらっとではありますが、Alexaスキルの作成について一通り触れてみました。

いかがでしたでしょうか。

もちろん今回はさしてコードの記述量がないものではあったが簡単にアプリを作ることができるということがわかっていただけたのではないかと思います。

アレクサ本体がなくてもアプリ自体は作ることができるので、もし興味があったらぜひ作ってみてはどうでしょうか。

自分もこれから対話ゲーム式のアプリを作成してみようかなぁと考えています。

それでは今回はこんなところで。ここまで読んでいただきありがとうございました！

参考文献

qiita.com

ログイン機能を持ったアプリを作成したときにswaggerにアクセスしたら404が返ってきた話

こんにちわ、こんばんわ。

今月初めに発売した某アクションゲームでまだメインキャラが決まっておりません。

別キャラ使いはじめるハードルが高いんですよね〜〜

さて雑談はこれぐらいにしておき、今回は自分が作成しているアプリについてです。

導入

GitHubと連携ができ、未ログイン時に他のページにアクセスした際にはUNAUTHORIZEDを返すWebアプリを作成しているときに、swaggerにアクセスするとNot Foundが返ってきてしまいました。

使用言語：Java

フレームワーク：spring boot 2.0.1

対処

最初はswaggerの依存ライブラリの問題かなーと思って一回削除して再度入れ直して見たが変わらずNot Foundが返ってくる...

ということでアクセス時のログを見てみると、

No mapping found for HTTP request with URI [/swagger-ui.html] in DispatcherServlet with name 'dispatcherServlet'

とのこと。

マッピングされてないよ！っていやいや今までできてたじゃんと思ったけど、ちゃんと見てみるとDispatcherServletにないよーって書いてあった。

どうやら作成したWebMvcConfigureの子クラスが問題らしい。

静的なコンテンツはデフォルトサーブレットじゃないとダメなのにDispatcherServletをルートパスにマッピングするとデフォルトサーブレットが呼び出されないんだとか。

ということでswaggerを表示するために必要なことは、

・ swaggerをマッピングしてしまう

・ DispatcherServletをルートパスにマッピングしつつ、デフォルトサーブレット経由でドキュメントルート上の静的リソースにアクセスできるようにする

のどちらか

具体的な記述としては以下の通り。

・swaggerのUrlをマッピングしてしまう

import org.springframework.context.annotation.*;
import org.springframework.web.servlet.config.annotation.*;

@Configuration
@EnableWebMvc
public class WebMvcConfig implements WebMvcConfigurer {

 @Override
 public void addResourceHandlers(ResourceHandlerRegistry registry) {
 registry.addResourceHandler("swagger-ui.html")
 .addResourceLocations("classpath:/META-INF/resources/");

 registry.addResourceHandler("/webjars/**")
 .addResourceLocations("classpath:/META-INF/resources/webjars/");
 }
}

※こちらの記述の場合マッピングされているUrlが起動時のログに表示されている。

・DispatcherServletをルートパスにマッピングしつつ、デフォルトサーブレット経由でドキュメントルート上の静的リソースにアクセスできるようにする

import org.springframework.context.annotation.*;
import org.springframework.web.servlet.config.annotation.*;

@Configuration
@EnableWebMvc
public class WebMvcConfig implements WebMvcConfigurer {

 @Override
 public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
 configurer.enable();
 }
}

所感

アプリ作成がひと段落したところでswaggerにアクセスしようとしたらできなかったので原因を特定しようとしたのだが、swagger関連で弄ったところがなかったため特定に時間がかかってしまった。

ログもうちょっとしっかり見るようにしないとなぁ。。。

そして結構記事がある内容らしい。調べる力も必要ですね。

それはさておき、1回1回マッピングするよりデフォルトサーブレットを経由できた方が後にもいい気がするんですけどネット上の記事ではswaggerのUrlをマッピングしちゃう書き方が多かったんですよね。

何か理由あるんでしょうか。マサカリお待ちしております(言ってみたかっただけ

ブログに関しては何か書こう書こうとしていたら2週間も空いてしまったw

難しく考えすぎなのかもしれない、自分のレベルは高くないのだから地道に分からないことを記すようにします。。

参考

Spring MVC(+Spring Boot)上での静的リソースへのアクセスを理解する - Qiita

Webエンジニア駆け出しの私のこれからの進み方

これまでの記事では自分の今までをお話ししてきましたので今回はちょっと未来のことというかこれからどうするかについてを語れたらなと思います。

いい加減技術的なことを書こうかとも思いましたが、折角の機会なので一度落ち着いて見つめ直す機会をもうけることにしました。

目標

目標といっても大雑把な書き方でした。

具体的にこうしたいということを語るにはまだ浅いので、将来的にどうなりたいかってところを焦点にしてお話しします。

生活をするためにお仕事をしているのですからお金は大事でしょう。

金銭的猶予があるということは精神的余裕にも繋がります。

親には本当にお世話になっているので、楽をさせたいという思いもあります。

次は承認欲求が強い人間だと自覚しておりますので、誰かに認められたいということでしょうか。

誰かを引っ張って行く存在でも、何かを教える人間でも頼られる存在になりたいです。

最後はどうなりたいかというのとはちょっと違いますが、やっていて楽しいことをやりたいですね。

こんなところでしょうか。

ではもっと具体的な話に入っていきます。

これらを達成するためには

さて目標を目標で終わらせないためには、そのための手段が必要となります。

1つ目、2つ目に関しては技術職なので当然スキル。これに尽きるでしょう。

スキルのない人間はそれ相応の対価ですし、スキルの無い人間に教えられたい人なんてよっぽどいません。

じゃあスキルを身につけるにはどうする、という話で現段階での自分のイメージは

• 業務で学んだことの吸収
• 参考書を読む
• 他人のコードを読む
• 自作アプリを作る
• 勉強会の参加

といった感じでインプットをし、これらから得たことブログなりgithubなり目に見える形でアウトプットすること。

なんだ普通じゃんって思われる方もいらっしゃるかもしれませんが自分はあくまで業務未経験でweb業界に飛び込みまだたったの2ヶ月しか現場にいません。

そんなペーペーの自分が奇を衒ったことをしていきなり技術が身につくほど世の中甘くありませんしね。

まずは基礎。基礎を身につけた上で自分なりのやり方を考える。

なのでとりあえず今はこれかなーと。

3つ目に関しては参考書を読むだとか自作アプリを作るだとかと関わる部分ではありますが、勉強をするにも自分がやってて楽しい分野をやっていきます。

好きこそものの上手なれと格言があるように上に行くには本当にこれに尽きると思います。

まとめ

大まかなイメージですけどこうやって言葉にすると自分にとってもわかりやすくていいですね。

あとはこの一連のことを行うにも近しい実力の人がいるといいと思いました。

幸い自分はそういった点でも恵まれています。

勉強会もあって、毎月数人入社してくる環境。これを使わない手は無い。

積極的に交流の場を作って行くようにしていきます。

量的には少ないですけれど今回はこの辺で。

読んでいただきありがとうございました。

それでは、また。

Webエンジニアになった理由、どのようになったか

はじめに

また転職ネタになってしまいましたが、今回は私がどのようにWebエンジニアになったかを記すことにしました。

Web系を目指したきっかけ

プログラマーと言っても色々な仕事があるでしょう。

それこそ私の前職であるゲームプログラマーから、組み込み、汎用、アプリケーション、etc

その中でも私がWebエンジニアを目指した理由は、楽しいかつ仕事している自分をイメージをしやすかったこと、あとは将来性の2つになります。

・楽しい

仕事なのでプロ意識は当然必要なのですが、その中でもやっぱりやってて楽しいことが一番だと思います。

モノづくりが好きだと気づいたのは社会人になってからではありましたが、気づけてよかった。

学生時代は社会人になってやりたいことを実現するための期間だったんだなぁ。。。と(今更

まあ学生時代に言われても実感できないんでしょうけどねw

・将来性

ありきたりな言葉ではありますが、今や私たちの生活にインターネットは切り離せないものとなっていますからね。

その中でも発展が著しく、成長できそうだと判断したためWebに決めました。

しっかりと技術を身につければ食いっぱぐれることもありません。

勿論他にも理由はあるんですけど、一番強い理由がここです。

どのようにWebエンジニアになったか

エンジニアになろうと思い立ったは良いものの実際にどうして良いのか分からない人(過去の自分)に向けて。一番最初ってスタート切りづらいですよね。

自分は学習系Webサイト→プログラミングスクール→ポートフォリオ作成、といった流れでエンジニアになりました。

この手順で行ったのには理由があるのですが後述します。

・学習系Webサイト

空いている時間にブラウザでプログラミングを勉強できるサイトです。

多くのサイトがあるのですが、自分はProgateを利用させていただきました。

prog-8.com

Progateを使った理由はいくつかあって、

・環境構築をしなくて良い

・説明がわかりやすく、スラスラと解ける

・いろんな言語を学べる

・レベルアップ性がモチベーションに繋がる

といった感じです。

最初の環境構築をしなくて良い、は本当に大きくてつまらない部分を省略できます。

勉強したいのに準備で訳がわからなくて、投げ出すのってもったいないですからね。

純粋にモノづくりの楽しさを経験できるところがおすすめの理由。

・プログラミングスクール

仕事をしながらではありますが、プログラミングスクールに通いました。

(仕事しながらはきつくない？って思うかもしませんが意外と時間取れるものですよ)

これはProgateで避けて来た環境構築をサポートありで行え、プログラミングでも分からないことがあればメンターにすぐ聴くことができるからですね。

また、スクールにまで行ってプログラミングを学びたいという境遇にいる人は高いお金を払っていることもあって真剣度が違います。

本当に学びたい人が来ているのでそういった環境に身を置き、視野を広げるという意味もありました。

思い返せばスクールで学んだことは本当に多く、非常に濃密な時間でした。

値段が高いのがネックではありますが、業界でやっていきたいという人には是非おすすめです。

ちなみに私が通っていたスクールはWebCampです。

メンターさん、バディの方が親身になってくれるので一人でやるのが辛い、何して良いか分からないという方はのぞいてみて下さい。

web-camp.io

・ポートフォリオ

Progate、プログラミングスクールを経て一人でポートフォリオの作成をしました。

あくまで自分の目標は転職であったため手ぶらで面接行くよりもこういったモノを作成しました！と言える方が真剣度もモノづくりが好きということも伝わるからですね。

何を作ったかというとアイデアを形にするideeというサイトです。

公開はしていないのですが非常に良い経験をしました。

というのも今までは習いながら作成をしていたのが自分一人で新しいものを作成するので、何が分からないのかというのが浮き彫りになるんですよね。

どこの技術が足りていないか、理解できていないのかを知ることができます。

弱点を知ることは成長への近道ですからね。

知らないを知らないで終わらせない、そういった意味でもスクールはメンターさんにすぐ聞けるのでおすすめです。

まとめ

長々と語って来ましたが、これが私がエンジニアになるために通った道のりです。

後述するといっていたこの手順で行った理由に関しては、何度も言ってきた楽しみ方を知るためです。

Progateで学んだ後のスクールの問題はすらすらと解けるから理解できている、という実感も得られますしね。

期間めちゃくちゃかかるんじゃないの。。。？って思う方もいるかもしれませんが私の場合はたったの1ヶ月半でした。

(勿論個人差はあると思うので1ヶ月半で終わらなくても怒らないでね……)

1ヶ月半でプロになる一歩を踏み出せるなら安いもんだと思いませんか？

今日はここまでにします。

なんか終始宣伝ぽい感じになっちゃいましたが私の記事を読んで楽しそう、やってみようかなと思える人がいたらとても嬉しいです。

それではまた。

転職をして学んだこと、戸惑ったこと

1.初めに

今回記述しようと思った内容は表題の通り転職をした際に学んだこと、戸惑ったことになります。

ここでいう内容は転職活動という意味ではなく、ゲームプログラマーからWebエンジニアになった際の仕事内容の変化という意味なので悪しからず。。。

 

2.ゲームプログラマーとWebエンジニアの違い

実際に転職をする前は結局プログラマーだし、大きく作業変わらないでしょと楽観的に考えていましたがそんなことはありませんでした。

そもそもジャンルが違うので、当たり前といえば当たり前なのですが。

ということで今回はここに焦点を当ててお話しさせていただきます。

3.作業内容

ではどういう形で違うのか、ざっくりと。

社会人歴2年にも満たないので的外れなことがあっても許してください。。。

・ゲームプログラマー

プランナーの方が作成した仕様書に基づいてコーディング

面白くない場合は仕様変更する場合も

描画とかサウンド関連も必要に応じて

・Webエンジニア

実装する内容の設計書作成→実装→単体テスト

本当にざっくりとしか書けていないけれど、自分が体験したものだとこんな感じ。

Web開発の方がお堅い印象(現行のプロジェクトだけかもしれないけれど。 

ゲーム開発ではテストというものは無く、動作確認と完成後のデバッグぐらいだったのでWeb開発に移行した時ここまで厳密にテストしてレビューして、ってやるのかと驚きました。

今考えるとバグ無くすためには当たり前だよね、とは思うんですがw

じゃあ何でゲーム開発でそんな厳密なチェックがないのか、というのは憶測だけど仕様の変更が多いのとテストケースが膨大になってしまうからではないでしょうか。実際ゲーム開発ってかなりの期間かかりますからね

だからそこに工数を割くよりは完成させてデバッグ期間でどうにかしようぜ、ってことだと思います。あとテストってつまらないしね(暴論

4.設計書

ゲーム開発だと仕様書も自分で作成しませんでした。

プランナーからいただいた指示に則って実装を進めて、リードエンジニアに確認してもらうみたいな工程だったので本当にかっちりしていなかったんですよね。

単一では複雑なものにならないからでしょうか。

それに対しWeb開発はフローチャート書いて、内部レビューして確認してもらったら外部レビューして、と厳重にやっています。

ここまでやるのは上司曰く実装に移る前に仕様をしっかりと理解するため、とのことです。

何のどこにアクセスして何が必要だから何を返すといった様々な要因が絡み合うので理解をしていないと実装できませんからね。

5.テスト

 作業内容で触れた内容にはなるのですが、もう少しだけ詳しく。

ゲーム開発では所謂正道一ケースしか検証していなかったです。動作が正常に動くことを確認し、問題がなければレビュー・実装で最終的にはα版、β版でデバッグを行う。

バグレポートが来た時には修正対応を行う、といった流れ。

デバッグは基本デバッグ会社に外注で行います。

デバッグの幅は広く特定の条件の時に何か起きないかみたいなことまで細かく見るみたいです。おもむろにボタン連打してみたりマップを何度もいったり来たりしてみるなど。

考えるだけで頭が痛くなりますね。。。

Web開発では実装者の方が仕様をよく理解しているということで、実装者が基本テストを行います。

単一のもの複数組み合わせのものを洗い出し、テストケース作成後レビュー依頼、試験実施といった流れ。

もちろん膨大な物になり得るのでUnitテストというコードで試験を実施します。

……今自分はUnitテストではなく、一つ一つ確認していますけどね。

そのためテストコードは書いたことありませんので、ここに関してはいずれ学ぶその時に取っておきます。

6. まとめ

なんかゲーム開発はゆるいみたいな書き方になってしまったけれど、そういう訳ではなく良いところもあると思います。

言うなれば自由。面白いゲームを作りたいっていうのは開発者全員思っていることだしね。

だからこそかっちりとしたWeb開発に移行して本当に驚きが多い。

視野が狭かったのを実感しました、ということで今回はここまで。

上手く纏まらなかったけどまあ。。。

また、次回お会いしましょう。

最後まで読んでいただきありがとうございました！

自己紹介

経歴

2016年某大学電子情報工学科を卒業。兼ねてからゲームを作成していたということもあり、都内のゲーム会社に就職。

しかし自分で作成するギャップと自分の視野の狭さ、将来に対し焦燥感を覚えて仕事をしながらプログラミングスクールに通い2018年9月チームラボに転職をし現在に至る。

趣味

ゲーム会社に勤めていただけあってゲーム好き。ジャンルはアクション、SRPG。その他はドラム。一時期はバンドを組んでいたけれども今は気まぐれぐらい

仕事内容

Webエンジニアをやっています。言語はJava。ゲーム会社にいた時はC#を使っていました。

ブログにかける意気込み

意気込みと言えるほどの熱いものじゃないかもしれないけれど、

社内外でインプットしたことのアウトプット。なるべく過去の自分に向けて。

まだまだひよっ子で、小さな実と呼ぶにも烏滸がましい状態だからこそできることを探した結果、やっぱりというか地道に積み重ねていくしかないことを思い知りました。

本当なら社会に出た段階や転職した段階で行うべきだったんだけど、そこはこれから挽回します。

技術に関する内容でもそんなこと知ってるよ、っていう内容が多くあるかと思いますが温かい目でで見守っていただけると幸いです。よろしくお願いします。