AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

カテゴリー: AWS

「DeepLens」セットアップしてみました!


こんにちは、百木田です。

現在開催中のre:Inventに参加のためラスベガスに来ております!
今朝のキーノートにて「DeepLens」という新サービスが発表されました!!
DeepLensはAWSオリジナルのカメラ付きデバイスを使うことで、エッジでの映像の撮影からリアルタイムな解析までの実装をより簡単にしてくれるサービスです。

サンプルプロジェクトが用意されているのでこれらを使って試すことができます。

  • OBJECT DETECTION
  • HOT DOG NOT HOT DOG
  • CAT AND DOG
  • ARTISTIC STYLE TRANSFER
  • ACTIVITY RECOGNITION
  • FACE DETECTION

DeepLensのwork shopに参加した人にはデバイスを配布されるということで行ってきました!
このデバイス、Amazon.comで$249.00で予約受付がされています。

DeepLens販売ページ

先ほど開封の儀を済ませ、セットアップまでをやってみましたので手順を共有します。

1. DeepLensのコンソールにアクセス

https://aws.amazon.com/jp/deeplens/

スクリーンショット 2017-11-29 22.54.05.png (2.3 MB)
「Get started with your DeepLens」を選択します。

2. デバイスを登録

左上のハンバーガーアイコンをクリック

  • 「Resources」の「Devices」を選択
  • 「Register device」を選択

デバイス名

スクリーンショット 2017-11-29 22.55.02.png (158.3 kB)

必要なIAMロールたちを作成

それぞれのサービスを実行するためにIAMロールが必要なので、「Create a role in IAM」からすべてのロールを作成します。右上の「Refresh IAM roles」を押すと、作成したIAMロールが選択できるようになります。

スクリーンショット 2017-11-29 22.58.19.png (373.2 kB)

証明書をダウンロード

後ほどDeepLensにアップロードします。

スクリーンショット 2017-11-29 22.58.30-2.png (177.0 kB)

3. DeepLens本体を準備・接続

SDカードを挿入

32GBのSDカードが同梱されているのでそれを後ろに挿します

電源に接続

電源アダプタも同梱されています。

電源ボタンを押して電源を入れる

DeepLensのネットワークに接続

電源を入れてから少しすると「AMDC-xxxx」のようなネットワークが出てくるのでそれに接続します。

ブラウザから http://192.168.0.1 にアクセス

DeepLensの設定ページが表示されます。

4. DeepLensをネットワークに接続

ここからはDeepLensがホストする設定ページ( http://192.168.0.1 )での作業になります。
DeepLensをつなぐネットワークをプルダウンメニューから選択し、Wi-Fiパスワードを入力して「Save」します。
スクリーンショット 2017-11-29 23.15.03.png (134.8 kB)

5. アップデートプログラムをインストール・再起動

右下の「Install and reboot」を選択します。
今回の場合は5分くらいかかりました。
スクリーンショット 2017-11-29 23.15.24-2.png (252.9 kB)

アップデート中はランプが点灯します。アップデート、再起動が終了すると点滅に変わるので再度DeepLensのネットワークに接続して http://192.168.0.1 にブラウザからアクセスします。

6. 証明書をアップロード

手順1の際にダウンロードした証明書をアップロードします。
スクリーンショット 2017-11-30 0.35.38.png (133.2 kB)

7. デバイスの設定

デバイスの設定をします。今回は以下のような設定にしてみました。
スクリーンショット 2017-11-30 0.36.29.png (228.5 kB)

8. 設定の確認

スクリーンショット 2017-11-30 0.38.46.png (140.0 kB)

完了!

正しく設定が完了するとこのような画面が表示されます。
スクリーンショット 2017-11-30 0.38.51.png (77.9 kB)

まとめ

現場からは以上です。
サンプルプロジェクトも試してみたいです。


3つのセルフマインドコントロールを駆使してAWS認定資格5冠を達成した話


こんにちは、POSチームの人見です。

この度、AWSの資格を5つ取得したことをご報告いたします。

  1. AWS Certified Solutions Architect – Associate (SAA) 取得日:2017-04-17
  2. AWS Certified Developer – Associate (DVA) 取得日:2017-04-24
  3. AWS Certified SysOps Administrator – Associate (SOA) 取得日:2017-04-27
  4. AWS Certified Solutions Architect – Professional (SAP) 取得日:2017-05-29
  5. AWS Certified DevOps Engineer – Professional (DOP) 取得日:2017-11-20

 

以上!

 

 

 

 

 

ということなのですが、

 

 

ということだけではブログにならないので、

どうやって勉強したかの話をしたいと思います。

 

 

私はストイックではないですし、どちらかといえば飽きっぽい方です。

今回もSAP取得までは着々と進めていたのですが、途中で飽きてDevOps取得までは時間が空いてしまいました。

3日坊主という言葉もあるように、本来人間は飽きてしまう生き物です。

そこで使った方法が、セルフマインドコントロール

決して怪しくはないのでご安心ください。。

 

 

 

今回は、これさえ実践すれば合格間違いなしのセルフマインドコントロールを3つ紹介します。

 

 

 

・セルフマインドコントロールその1

「合格できるかできないかギリギリだと思う日程で試験を予約してしまう」

AWSの資格試験の良いところは自分で試験日を決められることです。

試験日を決めないとだらだらと時間が過ぎてしまうため、私は勉強を始めるまえに試験を予約してしまいました。

期間が長いとダレるので、短ければ短いほど良いと思います。

少ない時間で高いパフォーマンスを得るために、パーキンソンの法則を利用するのです。

 

 

 

・セルフマインドコントロールその2

「意識しやすいタイミングで、いつまでに取るかを決める」

私はソリューションアーキテクトプロフェッショナルをAWS Summit前までに取ることに決めて、

DevOpsはAWS re:Invent前までに取ろうと決めました。

理由はともかく、「いつまでに」と目標にできる明確なタイミングがあるとそれに向けて意識しやすくなります。

 

 

 

・セルフマインドコントロールその3

「危機感を与えてくれるものを利用する」

勉強が進んでいない状態で早めに模擬試験を受けて、早めに危機感を持ちました。

勉強途中で飽きてきても、模試の結果を思い返すことで危機感が保てます。

適度な危機感を持つことで、集中して勉強できたと思います。

 

 

 

今度こそ以上です!

いかがでしたか?

セルフマインドコントロールは資格に限らず、仕事でもなんでも使えるので、

2017年やり残したことを達成しましょう!

 

 

 

ちなみにですが、ハンズラボでは資格取得や、勉強会参加など、エンジニアの成長を手厚くサポートしてくれるので、貪欲に上を目指すエンジニアにはものすごく良い環境です。

私が5冠を達成できたのも会社のサポートがあったことが大きいです。本当に感謝しています。

ハンズラボに興味をお持ちの方は、どうぞお気軽にお問い合わせください〜

 

 

さてさて、来週からre:Inventですね。

re:Inventにいく方はぜひぜひ現地でお話ししましょう!

そしてカジノ!!ルーレット当たりますように。。

 

 


Amazon Alexa日本上陸に合わせてAlexaスキルを開発しました!


AWSチームの鹿倉です。

2017年10月2日にアマゾンが「Alexa」、「Amazon Echo」を年内に日本で展開のすることを発表しました。そして、我々ハンズラボも日本上陸に合わせて東急ハンズのAlexaスキルの開発に早期に取り組みました。このブログでは今回初めてAlexaスキルの開発をどのように行ったか、またその時出てきた課題などについて共有したいと思います。

Alexaスキル開発の流れ

 

まず、開発〜ローンチまでの主な流れは以下の通りです。

  1. Amazonの開発者コンソールからAlexaスキルを新規追加する。
  2. デバイス(Amazon Echo)をセットアップする。(開発者コンソールにシュミレーターが用意されているので、ひとまずデバイスは無くても開発は進められます)
  3. プログラムを開発する(AWS LambdaもしくはHTTPSベースのAPI)。
  4. テスト(実機でテスト&開発者コンソールのシュミレーターでテスト)
  5. Amazonに申請

 

また、今回はローンチまでの期間が短かったので、以下の機能に絞りました。

  • 各店舗のイベント情報の紹介
  • おすすめ商品の紹介
  • 店舗では売っていないネット限定商品の紹介

 

まずはプロトタイプを作成し、ブラッシュアップしていくスタイルで開発を進めました。プロトタイプはエンジニア1人で2〜3週間ほどで完成させたのですが、実際に試してみると色々問題が浮かび上がってきました。弊社でも引き続き改善を行っているところではありますが、いくつか分かっている問題、改善ポイントについてご紹介いたします。

ユーザーの発話パターンは多種多様であること

 

当たり前の話ですが、ユーザがなんと発話するのかにはいろいろなパターンがあります。例えば、イベント情報を聞く時、「渋谷のイベントを教えて」、「今週のイベントは何?」など場所を知りたいケースや時期を知りたいケースなど、まだ単純に「イベント」とだけ言うユーザーもいます。

Alexaではあらかじめユーザが発話しそうな発話例(サンプル発話)を用意しておく必要があります。「○○のイベントを教えて」と言われたらイベント情報を伝える処理をするというような登録が必要になるのです。社内メンバーにもいろいろ試してもらいながら、できるだけ様々なパターンでも応答できるようにサンプル発話を考えました。また、開発時のサンプルは社内メンバーに限られていたので今後運用フェーズで実際にユーザはどのようにAlexaと会話しているのかデータを収集して改善していくポイントだと考えています。

今あるコンテンツが音声発話した時に聞きづらい

 

今回、イベント情報やおすすめ商品を紹介する機能を作成しましたが、機能としては単純にWebで掲載している情報(文章)をAlexaに読ませているだけです。

これがなんとも、、、音声ではかなり聞きづらいし、長い・・・開発する前からなんとなく想定していたのですが、Alexaが勝手に学習してめちゃくちゃいい感じに発話してくれるのではないかと淡い期待をして開発を進めました。たしかにAlexaはすごくて開発中もどんどん発話がいい感じになっていきます。が、さすがに商品名や商品説明とかは聞きづらいです。(特にハンズはマニアックな商品なども含まれるからかもしれませんが)

今後、この機能を充実させるならコンテンツもWebとは別で音声用のコンテンツを用意すべきだと感じました。また、アメリカではディスプレイ付きのデバイスなどもあるらしいので、デバイスが充実してきたら、ディスプレイ&音声で紹介するような機能を提供できれば便利かもしれません。

Webで検索するよりも、会話形式であった方が便利な機能をユーザに提供した方が良い

 

上記で述べた通り、商品紹介など一方的に会話を進める機能は音声インターフェースよりも、今のところWebの方が良いと感じています。

なので、まずは、音声会話で便利な機能を充実させるべきという方向で改善を進めようと考えています。例えば、ハンズであれば、営業時間や在庫確認、お店までの行き方などのお問い合わせをお電話で受けることがあります。このようなお問い合わせ業務をAlexaで提供することで、よりスピーディにお客様の要求に答えれるようにすること。また従業員の方々の負担を軽減することで、トータルでお客様により良いサービスと提供できるのではないかと考えています。

最後に

ハンズラボでは東急ハンズのAlexaスキルを開発しておりますが、合わせて他の事業社様のAlexaスキル開発についても今後承ります。ご興味のある方は是非弊社にお問い合わせください。

弊社へのお問い合わせはコチラ


CodePipelineの進行状況をSlackに通知する


こんにちは。百木田です。
CI、回してますか?

CodePipelineで実行するステージの進行状況を手軽に見たいと思い、Slackに流れるようにしたので共有します。

ポイントとしては、CodePipelineからLambda functionを呼ぶのではなく、CloudWatchイベントでCodePipelineステージのステータスの変化を検知してLambda functionを呼び出します

今回はできるだけシンプルにするために、すでにCodePipelineは作成済みの想定で、すべてのステージにおけるSUCCEEDEDFAILEDのステータスを通知します。なのでCodePipelineに変更は必要ありません。
また、Slack Botを作成しトークンを発行して使っていますがIncomming Webhookでも同じようなことはできるかと思います。

Serverless Frameworkを使ってCloudWatchイベントの設定と、slackに通知するためのLambda functionをデプロイします。

環境

ディレクトリ構成

デプロイ

コードは記事の下の方に書いときます。上記のディレクトリ構成のように配置したらデプロイします。

デプロイできたらCodePipelineを動かしてみます。そうするとslackにこのような通知が来るかと思います。

いつの実行結果なのかをトレースできるようにCodePipelineの実行IDの前半7桁を表示しています。この辺はお好きにカスタマイズしてみてください。

まとめ

CloudWatchイベントの検知がリアルタイムじゃないので、CodePipelineの進行と通知にラグがあったり、前のステージの実行完了と次のステージの実行開始の通知が前後することなどもありますが、実行結果がわかればいいかなくらいの感じなので気にしないことにしてます。

ありがとうございました。

以下、コードたち

status_notification.py

serverless.env.yml

serverless.yml

※ detailのセクションを消すと、すべてのステータスが検知対象になります。


AWS SAA合格までのサクセスストーリー


iOSエンジニアとしてひーこら言いながらも、現場にも慣れて心に余裕が生まれてきた9月上旬。
7月に新卒研修を終えてPOSチームに配属されてから、HandsPOSの業務をしっちゃかめっちゃかしつつもなんとかこなしていた。
いきなり業務に携わり、大きな不安を抱えながらもそれなりに頑張ってきた。

しかし、配属から2ヶ月経ったその時、それは突然にやってきたのだ。

OJT。

業務をこなしつつ、それに追加して少しずつ課題を解いていく。
基礎的な技術力や知識量の向上が主な目的だ。

そしてトレーナーは言った。
「渡邉さん、来月中にAWSのSAAとってね。」

SAAとは、AWS初心者がまず取得を目指す資格である。

「大したことない課題じゃん」そう思われる方もいるだろう。
確かに、この資格は難しすぎるわけではなく、ほどほどの難易度だ(と個人的には思っている)。

しかし、わたしは目の前が暗くなっていくのを感じた。
これから始まる勉強は、恐ろしく辛く苦しいものになると、わかったからである。

ここで、私渡邉の略歴を書いておく。
普通科の高校を卒業後、情報系の専門学校でiOSとAndroidでのモバイルアプリ開発を専門に2年間学んだ。
2017年4月にハンズラボに入社。現在社内最年少の21歳である。

専門学校で習ったとはいえ、クライアント側以外の知識は皆無である。
具体的に言うなら、HTTPってなんかの規格でしょ?ポートってなんか穴空いてるんでしょ?くらいのものだ。

正直に言おう。わたしはサーバーサイドやインフラを食わず嫌いしていた。
学生時代も学ぶ機会はあったが、なんとなく避けてきていた。
ついに逃げられなくなった。だから絶望したのである。

しかし、ここで逃げては問題を先延ばしにするだけだとわかっていた。進展はない。
絶望すると同時に、絶対に成し遂げてみせる、そう思っていたのもまた事実なのである。

こうして、私とSAAの戦いは幕を開けた。

chapter1. vs 参考書1周目

AWS SAAの参考書といえば、これが有名だろう。

例にもれず、私もこれをまずは購入した。
持ち運びしやすいサイズ、適度に薄く書き込みしやすい紙、軽さ、全てにおいて最高の参考書だ。

意を決して開いてみる。
リージョンとAZの概念はすんなり理解できた。IAMというものがあるのか。ふーん。
IDフェデレーション。フェデレーションってなんだ。
ほう、そんな認証方法があるのか。ふーん。

1周目なんて、わからない言葉を都度調べて書き込んで、
書かれている日本語を私が理解できる言語に噛み砕くだけだ。作業ゲー以外のなにものでもない。
眠くなる。寝たい。やめたい。しかし、やらなければならない。
今辛いのは、今まで奴らから逃げてきたツケだ。

自分に鞭を打ちつつ、まずは1周、読破した。

chapter2. vs 模擬試験

ところで、私のOJTトレーナーはAWS Solutions Architect Professionalを取得している。
10日でAWSのアソシエイト資格3つ制覇した話」の人見だ。

今読んでも10日間で全部取ったのは尊敬する。尊敬しすぎてちょっと引く。

それはさておき、その人見が「模擬は早めに受けろ」と繰り返し言ってきた。
なぜかと聞くと、「その方がいいから」というなんとも微妙な答え。
しかしプロを取得した人見がいうのだから間違いはないだろう、と、参考書を1周終えてすぐに模擬試験を受けた。

この問題は本で読んだからわかる。これは書いてあった気がするが自信がない。なんだこれは。初めて見る言葉だ。
結果は、50%。不合格ラインだった。当たり前だ。

しかし、早めに受けたこの模擬試験には2つの大きな利点があった。
一つは、実際の試験の形式がわかったこと。もう一つはどこまで理解を深めれば合格できそうかのイメージがつかめたことだ。
早めに目標ラインが定まったのは、その後の勉強の効率を高めることにつながった。

chapter3. vs 参考書2周目

模擬試験を終え、参考書に戻った。
参考書に書いてあるどの部分を頭に叩き込めばいいのかがわかった今、
インフラやサーバーを食わず嫌いしていた私はいなくなっていた。

インフラやサーバーに興味がでたわけではない。
好きになったわけでもない。
AWS SAAという壁を打ち破りたい。ただの意地だった。

この部分は本番で出題されそうだ。
これに関してはすっかり抜けているな。しっかり抑えよう。
参考書の文だとわかりにくいから、自分がわかりやすい文章に変えてしまおう。

参考書の余白への書き込みはどんどん増えていった。
汚れていく参考書。消えていく余白。蛍光ペンのインクがなくなる。
買いに行く時間が惜しい。ボールペンで勉強を続行する。
結局、最後まで蛍光ペンを買い足すことはなかった。

参考書には各章の最後に確認問題があるのだが、
その解答を覚えてしまうほどやりこんだ時、一抹の不安がよぎった。
試験3日前のことである。

chapter4. vs WEB問題集で学習しよう

試験3日前。参考書はほぼ暗記してしまっていた。参考書の問題集の正答率は100%だった。
これなら合格できそうだ、と一息ついたときに、一つの記憶が蘇った。

模擬試験に、参考書ではみたことがなかった言葉が使われていたのを思い出したのである。

つまり、参考書で出題範囲を全てカバーしているわけではないということだ。
当たり前の話なのだが、AWS SAAを倒すと息巻いている私にとって、
この「カバーしきれない範囲」は恐怖対象へと変わったのだ。

手元にある問題は暗記してしまっている。勉強にはならない。
どこかに初めて見る問題はないのか。本に載っていないような問題はないのか。

そこでたどりついたのがこのサイトだった。

フリープランに登録して、まずは解いてみる。
ボロボロだ。今までなんども解いたから問題と答えを暗記していただけであって、
根本の理解をしているわけではない。

まずい。

試験前は3連休だったのだが、ある意味本気の勉強はここからはじまった、とも言えるのかもしれない。

chapter5. vs 参考書3周目

2周目の参考書は、確認問題を重視していた。
一発で正解すれば理解している、という指標としてわかりやすいからだ。
確かに、それはわかりやすい。しかし、なんども繰り返し解くのには向かない。

そこで私は、今一度各章の解説部分を読み直すという行動に出た。
想像以上に時間がかかる。しかし、根本を理解するにはもうこれしかないのである。

読み終えたあと、確認問題(今更だが選択形式だ)の正答と誤答それぞれの理由をつぶやきながら確認問題を解いた。
ここまでやっても詰まる問題はある。
正答がわかっても、理由が説明できないのなら、そこからの応用はない。

解説に詰まったら、戻る。これを繰り返す。作業ゲー以外のなにものでもない。
しかし、辞めたいとは思わなかった。意地が勝った瞬間である。意地の塊と化していた。
元来、わたしは両親がお手上げするほど意地っ張りなのだ。

chapter6. vs BlackBelt

AWS試験の教材として、BlackBeltを参考にしている人は多いのではないだろうか。
実際に使われている様子や、細かい仕様などの解説が動画で見られるのは大変ありがたい。

しかし、私はBlackBeltはほぼ視聴しなかった。
具体的には、最後の最後まで不安だったAuto Scailingのオンデマンドセミナーのみを視聴した。

理由はとてもシンプルだ。時間的制約。

勉強期間は1ヶ月。その間SAAの勉強のみをしていたわけではなく、
仕事や家事、やることは盛りだくさんだ。参考書を開く時間すらない日も少なくなかった。

BlackBeltはわかりやすいが、どうしても時間が取られる。
対時間コストというのだろうか。時間的コスパが低い。
そう判断し、参考書や模擬の復習を優先した。

chapter7. 試験本番

会場は池袋。目の前のカフェに10:00に入店。試験は13:00からだ。
時間が近づくにつれ、緊張感が高まっていく。

高校受験の時、緊張しなかったことを思い出した。
あの時は「これ以上やれることはない、これで落ちたら仕方がない」と思っていたからだろう。
後悔というのは、やり残したことへの執着だ。
やり残したことがなければ後悔もない。

しかし、緊張していた。
当日のわたしは、自分の勉強方法を悔いていた。
なぜ参考書にこだわり続けたのか。なぜ、もっと他の問題をこなさなかったのか。
今考えても仕方がない。しかし、過去の自分を悔いていた。

やれるだけのことをやろうと心を決めて、試験会場に入った。
その頃には、穏やかな心境になっていた。

勉強方法への後悔はあるが、受験とは違って再度受け直すこともできる。
受かったら万々歳。落ちても勉強方法への反省点という収穫がある。
なにも怖いことはないと、それまでの1ヶ月をぶつけてきた。

合格

結果は、合格だった。
カメラで監視されていることも忘れて、渾身のガッツポーズをした。

頰がゆるみ、凝り固まっていた肩がフッと軽くなる。
飛んでいきそうな足を抑えて会場を後にする。
いつもは人の多さにげんなりする池袋の街が輝いて見える。

会社に戻る電車の中で、結果通知のメールをなんども読み返す。
思いついて、頰をつねってみる。痛い。夢じゃない。
ここまで嬉しかったことはいつ以来だろう。

資格は、成功したときの形がわかりやすい。合否があるからだ。
白か黒か、0か1か、はっきりと結果がでてしまう。諸刃の剣にもなるのだ。

だからこそ面白い。そう思えた。
努力が実るのは気持ちがいい。
実るかわからない努力がつらいなら、何が何でも実らせてやるという意地と根性を持てばいいのかもしれない。

勉強方法に後悔がある状態での合格は、ラッキーだったと思っている。
次の試験勉強は、後悔がない状態まで持っていくのが課題だ。

(サクセスストーリー風にお届けしました。いつもはもっと適当に生きています。)