「AppSyncのデータソースとしてgolangのLambdaを利用する」というタイトルで
下記のサイトにブログを投稿させて頂きました。✍
よろしければ、ご欄になってください! 🙋♂️
「AppSyncのデータソースとしてgolangのLambdaを利用する」というタイトルで
下記のサイトにブログを投稿させて頂きました。✍
よろしければ、ご欄になってください! 🙋♂️
AWSのセキュリティグループにおいて、
私が直近で利用している適用パターンを紹介します。
(ちなみに、名称は私が勝手に考えました(´・ω・`))
セキュリティグループ(以下SG)のインバウンドルールに、
SGを設定することができることを利用し、
簡易的にインスタンス間のインバウンドを有効にする方法です。
メリットとして、当該SGを設定したインスタンス全てにおいて、
特定ポートの疎通が可能になるので、インスタンス個別に新しい SGを定義する
必要がなくなります。
上記のallow self subnet方式に近いです。
こちらの場合、ELBのリスナとして設定されているEC2インスタンスのSGに
ELBのSGを設定することで、ELB経由のみしかアクセスさせないことを
簡単に実現できます。
こちらは番外的な位置付けではあります。
対抗サーバのグローバルIPアドレスを登録したSGを一つ作り、
インスタンスに適用します。
同じサブネットに配置しているサーバ間連携にも関わらず
パブリックIPで一度外に出てしまっているようなサーバにおいて、
特定のIPのみ許可するSGを適用することで、許可したアクセス元以外を遮断します。
何を言っているんだと思われるかもしれませんが、
パブリックサブネットをNATゲートウェイを利用せずに、
擬似的にプライベートサブネットにする方法だと思っていただければと。
( ※それでも何を言っているのか・・(ry )
プライベートIP間で通信すればいいじゃん的な話ではあるんですが、
パブリックIPがアプリケーション内にハードコーディングされているような
レガシー(;ω;)なサーバアプリケーションにおいて効果を発揮します。
他にもよい適用パターンがあれば、
本エントリーを更新していきたいと思っていますが、
インバウンドルールにSGを設定できるので応用パターンは
もっと存在するのかなぁと思います。
以上です!
プログラマーは命名ルールに敏感です!敏感プログラマー!
命名ルールに則ってない記述を見つけるともにゅっ(´・ω・`)とします。
それも、もちろん経緯があります。
同じプログラミング言語で記述されたファイルにおいて、
下記のような名前があったらどう思いますでしょうか。
CreateFutureIssue.java delete_future_issue.java
・・・どちらかに揃えたいと思いますよね!まずはそこからになります。
命名には様々なルールがありますので、下記に紹介したあと、
golangにおける傾向を見ていきたいと思います。
ラクダの背中のように見えることから Camel case と呼ばれます。
一番最初の単語を大文字にしたケースをアッパーキャメルケースまたは、
パスカルケースと呼ぶようです。
Javaにおいてインスタンス変数にキャメルケース、
クラスファイル名にパスカルケースが使われているのかなという印象です!
地をはう蛇のように見えることから Snake case と呼ばれます。
Javaにおいてもfinal修飾子を加えたグローバルスコープ変数などに利用されます。
しかしながら、Javaのグローバルスコープ変数は大文字で記述する例が多く、
この場合はスクリーミングスネークケースとも呼ばれるようです。
串が刺さったケバブのように見えることから Kebab case と呼びます。
GitHubのリポジトリ名に使われる習慣がありますね。
文字の入力方法にしても「Shiftキー」を使う必要がないということで、
もっとも楽な入力方法ではあると思います。
マークダウンファイルのファイル名や、AWSリソースへの命名など、
個人的にはケバブケースの利用頻度が高まっています。
頭を大文字にしたケバブケースをトレインケースとも呼ぶようです。
golangの有名なOSSとして、「Docker」がありますね。
個人的に注目している「Vuls」も含めて、ソースコードを覗いてみました!
github.com
github.com
github.com
github.com
golangはメンバーの可視性(Public/Private)を
先頭大文字で判定する言語仕様がありますので、
変数やメソッド名の命名規則は基本的にキャメルケースまたは
パスカルケースで統一されていますね。
ASK SDK for Node.js バージョン2を
私が個人で運用しているAlexaカスタムスキル「五月雨の音」に適用しました。
https://www.amazon.co.jp/dp/B07DVVJ8KC/www.amazon.co.jp
実践した事柄を紹介します。
まず、「ASK SDK for Node.js バージョン2」についてです。
Alexaカスタムスキルをコーディングする時に、
様々な言語を利用して直書きすることも可能ではあるのですが、
Alexaの機能にアクセスする命令をラップしたSDKも提供されています。
それが「ASK SDK for Node.js」になります。
ASK SDK for Node.jsは2018年5月にバージョン2がリリースされました。
私のカスタムスキルはバージョン1で動作していました。
今回、バージョン2を適用するようにマイグレーションしました。
ASK SDK for Node.js バージョン2にマイグレーションする時にまず実践したことが、
テストコードの記述です。
テストコードに関するセッションで有名なt.wadaさんに影響を受けて、
Alexaのテストコードによるハッピーパスの確認を行うようにしました。
Testing Frameworkは、Alexa Skill Test Frameworkを利用しました。
下記のようにテストを実行することで、動作確認が行えます。
テストコードを記述したことにより、CIをするための準備が整いました。
CI環境にはCircleCIを利用しました。
CircleCIはパブリックリポジトリであれば4コンテナまで無料で実行可能です。
Alexaカスタムスキル「五月雨の音」はパブリックリポジトリで運用しているため、
その恩恵を充分に受けることが出来ます。
ビルドおよびテストの結果はSlackのWebhookで通知されます。
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
LambdaはAWS SAMによってデプロイしています。
SAM CLIはローカルでAWS Lambdaを実行するためのコンテナが起動します。
つまり、プロダクションにデプロイする前にLambdaのinvokeによる動作確認が出来ます。
# sam localによるLambdaのinvoke sam local invoke "serverlessFunction" --event "./test/event/SoundsOfRainIntent.json"
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
このタイミングを機に、パブリックなS3バケットからのAudioファイルの取得から、
CloudFront経由に乗り換えました。許可したくないアクセス元が存在する場合、
WAFによるセキュリティ対策も可能になりました。
AWSリソースはTerraformを用いて構築しました。
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(); } };
CI環境まで構築できれば、あと少しの手間でCD環境も構築できます。
今後はリリースブランチへのプッシュによるCD環境構築を実践していきたい。
常に自分にとって新しい関心事をインプットとし、
アウトプットも今までにないことをする。
この姿勢を維持し、これからも取り組んでいきたいと思います。
2019年の初投稿ですっ!
私は個人用Slackワークスペースに様々な通知を流しています。
などなどです。
しかしながら、個人用の通知チャンネルの場合、
過去の通知情報を保存しておく必要はありません。
不要な通知情報が溜まりすぎて無料で検索できる1万メッセージの上限を
越えてしまうことのほうが不便だと思います。
ですので、通知チャンネルに投稿された過去のメッセージを
削除するLambdaファンクションを作成しました。
github.com
ポイントをピックアップします↓
今回、レガシートークンは利用せず、Slack Appでトークンを発行しました。
下記の記事がよくまとめられています。
qiita.com
APIを利用したいだけでしたので、今回は「sandbox」という名前で
Slack Appを作成し、必要なPermission Scopeを付与しています。
API実行のために付与したPermission Scopeは下記の通りです
やっていることはシンプルです。
Slackのメッセージを取得する時に、Unixタイムスタンプで指定します。
Python3では、下記のようなコードで、Unixタイムスタンプ(Epoch Time)を取得できます↓
以上です!
2019年も良い年になりますように!🐗㊗️
「Team Geek」という書籍を読了しました。
「Team Geek」はプログラマが実践すべきチームでの
コミュニケーション手法を明確に定義しています。
尚、HRTについては以前から知っていまして、
私はここ数年、なるべくHRTを実践するように取り組んできました。
今回、HRTの出典元となる本書を手に取る機会が訪れました。
あくまで個人的な読書感想になりますので、
結構ずけずけと感想を述べていきますよ↓
そもそもの話、お互いがハート(HRT)の意識を持たないと成立しないと思います。
そういえば「GNUの心あるコミュニケーションのガイドライン」も発表されてましたね。
gigazine.net
例えば、片方が謙虚な姿勢を見せたとしても、
相手の謙虚な姿勢を見て、ここぞとばかりに自分の優位性をアピールする場合がある。
結婚・子育て・介護など、仕事以外にも重要なタスクをこなしながら、
私たちは仕事でのやりがいも見つけていく。
ライフステージによって、HRTで実践できる事柄も
限られる場合があるのではないか。
いや、ない。
私達はいつでもコミュニケーションの混沌にいる。
この本を読んだ日本人なら誰だってそう思うんじゃないかな。
そもそも多重請負構造を構成している日本のSIerの全員が、
HRTを意識しているわけがない。下請けになればなるほど、
職業プログラマがほとんどを占めているだろう。
組織としてHRTを浸透させる取り組みを行なっていないならば、
私たちは今の組織に居続けるべきか考える必要がある。
もっと昔に出版されれば、Teem Geekの考え方も
浸透していたかもしれない。というか、浸透してから就職したかったなぁ。
「いつやるか。今でしょ。」のフレーズが出てくる辺りまさに最近。
常に自分を改善する。
心から相手を思いやる。
相手が正しいことをすると信じる。
そうすれば、私達の行動はぶれないだろう。
プロジェクトのミッションステートメントとして定義されれば、なおよい。
逆に言うと、チームで開発に取り組まず丸投げの会社は非常に好ましくないね。
プログラミングはスキルなので、練習すれば向上する。
自分の性格や人間としての価値が攻撃されたと思わないように、
全員との意識合わせが必要なんだ。
だからこそ、しくじり話として共有することが重要だと認識できる。
パフォーマンスを軽視してはならない。
ユーザーが利用する時のパフォーマンスが改善すれば、
利用頻度が増えるのは必然だ。
ユーザーとの信頼を構築するステップにもなるはず。
心から思いやれる人と一緒に仕事したいです。
本書は何度も何度も読み返すことになると思います。
もっと人間としても成長したいなぁ。
以上ですっ!
alexadevsummittokyo.splashthat.com
行ってきました!ALEXA DEV SUMMIT Tokyo 2018!
Amazon Alexaが主役の開発者向けイベントになります!
レポートしていきます!
面白おかしくre:Inventで発表されたアップデートを紹介してくださるセッションで、
午後一のセッションとしては気楽に聴講できて楽しかったです!
登壇者の方はNY出身ですが漢検3級を取得していたりと、
かなり日本語が得意みたいでとても聞き取りやすい日本語で喋ってくれました!
アップデート内容はすぐにでも試してみたい機能もありました。
しかしながら、Echo Spotの金額が結構高いので、
開発で試すためにどこかのタイミングで購入したい・・。
私が運用しているAlexaカスタムスキルはシンプルなので、
ここまでベスト・プラクティスに則った設計も必要ないのだけれど、
受託開発案件になると必要なノウハウだよなぁと思う。
なので、sandbox環境に対しての設計の実践をやっておきたいと思いました!
先行者利益という言葉は、何も本当の利益に適用されるだけのものじゃなくて、
エンジニアの福利厚生という意味の先行者知識という考え方もありなんじゃないかな。
今日のご飯、明日のご飯という考え方いいね。
個人的には先行知識を増やした時の血が通っていく感じが好き。
(先行ではないかもしれないけどね)
途中から既存スキルの応募も可能になったこともあり、
応募者数が相当少なくて焦ってたんだろうなぁと思っていた。
グラフで見る通り、本当に応募期間の終盤まで応募が少なかったんですねw
いつもAlexa道場を担当している方が登壇しているセッションで、
リアルでお顔を拝見できてよかったです。
自分の時間に余裕があればもう少し
アイディアを練ったスキルを作ってみたいけど・・
LED電球やスマートプラグ、そしてカメラが展示されていました。
カメラはEcho Spotと連携して、Echo Spotに映像を映せるようです。
なんとBOSEのノイズキャンセリング・ヘッドフォンがAlexaに対応していました!
話を聞いた限りですと飛行機の中でも寝れるくらいノイズを軽減できるとのこと。
これは欲しいなぁ 😄
Alexaの最新情報を取得しつつ、
スキルのベスト・プラクティスのノウハウも学べる素晴らしいイベントでした!
ここ最近、Alexaの技術情報をキャッチアップしていなかったので、
このようなイベントは本当にありがたいです!
以上です!