プログラミング言語の命名ルールと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カスタムスキル「五月雨の音」に適用しました。

https://www.amazon.co.jp/dp/B07DVVJ8KC/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の技術情報をキャッチアップしていなかったので、
このようなイベントは本当にありがたいです!

以上です!

JJUG CCC 2018 Fall 行ってきました!参加レポート

JJUG CCC 2018 Fall http://www.java-users.jp/ccc2018fall/#/www.java-users.jp

↓朝8時半、爽快に晴れ、朝日が差し込む四谷駅から新宿二丁目西新宿に向かう f:id:yasay:20181217130733j:plain

f:id:yasay:20181217124225j:plain:w350

今年の冬もやってきました❗️JJUG CCC 2018 Fall❗️
所用があり午前中だけの参加でしたが、とても有益な情報を得られ、
おかげさまで参加したメリットがとても大きかったと思います❗️😃

レポートしていきます!📝

レポート📝

10:00 - 10:45 Spring BootのWebアプリケーションをDockerに載せてAWS ECSで動かしている話

www.slideshare.net

  • DDDとクリーンアーキテクチャの人(前回の登壇は見てた)
  • システム構成
    • 企業向けWebサービス、取り扱うデータ量は多い(数百GB~数TB)
    • ALB -> WEB UI Container -> in ALB -> other containers
    • in ALB -> independent EC2の流れもある
    • ECR -> ECSの王道を行く
    • CodeDeploy, GitLabを利用してECRに登録
    • 採択経緯
      • 学習コスト懸念、Fargateのランニングコスト懸念
      • (ECSでやっておけばFargateへの切り替えは比較的容易・・)
    • (Web)ALB -> Web Server Container -> UI Container
      • 本当はUI Containerの前にALBを挟みたかった
        • X-Forward-For, X-Forwarded-Proto, X-Forwarded-Portが書き換わる
        • リダイレクトURLのポートが変わっちゃう問題があった
  • 開発環境
    • メモリ16GB, Windows派多数、Macな人も
      • マージリクエストを利用
      • ローカル用プロファイルで動作させるSBが入ったDockerコンテナをビルド・起動
      • 他マイクロサービスのところはモック化
    • GitLab CIで開発環境にデプロイ
      • jarビルド -> Dockerイメージビルド -> ECRに登録 -> ECSのタスク定義 & サービス更新 -> Mattermostに通知
      • すぐにデプロイされない罠
        • ec2数 > タスク数:すぐにデプロイされる(新しいインスタンスに)
        • ec2数 = タスク数:1個止めに行っている間は待たされる
    • 環境毎の切り替え
      • β環境1 -> β環境2 -> β環境3
      • 性能ってのは測ってみるしかない!
      • プロファイルの切り替え
      • Git Flowを採用
      • ECSの環境変数をだけで動作設定を変更できる。
  • ログ出力
    • Kinesys Data Firehorseに連携、S3に保存して分析
  • アクセス監視
    • 未解決事件
      • コンテナ間通信が502エラー
        • ALB <- -> コンテナ
    • ECSはDockerコンテナを間違って落としちゃったとしても瞬時に検知して復旧できる仕組みがあるからそこがすごい。

11:00 - 11:45 Java + コンテナ向けパフォーマンス分析手法の紹介と活用事例

https://jjug-cfp.cfapps.io/submissions/2674d2b0-9b8e-415a-bb3f-75e56333330b

  • 最小の変更点を発見し、速度を改善したい。
    • JMeter & APP DYNAMICS
    • APMでもモニタリング
    • プレリリース環境での継続的な負荷テスト
  • ボトルネックの発見
  • だれでもやること
    • ログをいい感じに仕込む
    • VISUALVMをつなぐ
    • FlightRecorder?
      • system, libc, Native library, GC, JIT?
      • perf-toolでサンプリング
  • 事故は起こってから観測しても遅い
    • perf-scriptは重い
    • perf-recordは比較的軽い
  • Interpreterによる分裂の障害
  • 利用しているツールなど
  • Off-CPUの自動解析は難しい
    • wPerf (Zhou et al)

f:id:yasay:20181217130337p:plain

@nakayama_sanの可愛いメモ

紹介せざるをえない!JJUG CCCでいつも可愛いメモを共有してくださっている、
@nakayama_sanのツイートです!

所感

ECSの環境変数を便利に使えるという話はとても有益でした。

[2018/12/19追記]
本イベントの後にAWSから発表があり、
SSM Parameter Storeの値の参照が Fargate から可能になったようです。

Avalancheについても是非とも実際に動かしてみて、
パフォーマンスを解析したいと思っています。
スター数とかも増えて是非とも盛り上がって欲しいOSSですねぇ。

短い時間での参加でしたが、本当に参考になるセッションばかりで感謝です!
見れなかったセッションは、TwitterGitHubを通して、各セッション情報を参照し、
確認したいと思います!

GitHub - jjug-ccc/slides-articles-2018Fall: JJUG CCC 2018 Fall 登壇資料まとめ

↓写真はおなじみの成子天神社の一コマ。今回も牛さん撫でできました 🐮 f:id:yasay:20181217130623j:plain f:id:yasay:20181217130638j:plain

以上です!

AWS SAMの「AutoPublishAlias」の使い方を誤るとエイリアス消えちゃうよっていう話

AWS Serverless Application Model(SAM)には「AutoPublishAlias」という設定があります。
docs.aws.amazon.com

- AutoPublishAlias: By adding this property and specifying an alias name, AWS SAM:
  - Detects when new code is being deployed, based on changes to the Lambda function's Amazon S3 URI.
  - Creates and publishes an updated version of that function with the latest code.
  - Creates an alias with a name that you provide (unless an alias already exists), and points to the updated version of the Lambda function. Function invocations should use the alias qualifier to take advantage of this. If you aren't familiar with Lambda function versioning and aliases, see AWS Lambda Function Versioning and Aliases .

AutoPublishAliasを有効にした場合、
Lambdaファンクションのソースコードに変更があった場合はリパッケージされた
Lambdaのバージョンが発行され、指定したエイリアス名とバージョンが紐づくように設定されます。

今回、この「AutoPublishAlias」を利用して、
Lambdaのエイリアスを複数管理しようとしてうまくいきませんでした。
何故うまくいかなかったのか、「AutoPublishAlias」の挙動結果を述べつつ下記に記します。

エイリアス名を変更した時は、変更前に指定したエイリアスが消える

下記の画像のように「dev」が指定されているとします。
これを、「prod」に変更してデプロイしてみます。
f:id:yasay:20181213163719p:plain

すると、「dev」エイリアスが消えて、「prod」エイリアスのみが残りました。
「dev」エイリアスが削除されてしまったんです。
f:id:yasay:20181213163807p:plain

「AutoPublishAlias」をコメントアウトすると、変更前に指定したエイリアスが消える

例えば、下記の画像のようにエイリアス指定をコメントアウトすると・・
f:id:yasay:20181203165003p:plain

エイリアスが消えてしまいます。
f:id:yasay:20181213165309p:plain

絶対消しちゃダメなエイリアスをSAMで指定するのは不安かもしれない

私はAlexaカスタムスキルで利用するエンドポイントにLambdaのエイリアスを利用しています。
例えばAuboPublishAliasで「Prod」が指定されている状況から「dev」に切り替えた時に、
想定外の処理がAlexaカスタムスキルで実行されることになります。

つまり・・私のエイリアスの使い方・・間違っている?
f:id:yasay:20181213154441p:plain

一つのLambdaファンクションにおいて、エイリアスを指定して開発や本番を指定したい時はどうするべきか

消えちゃいけないエイリアス(prodなど)は個別にエイリアスを発行。
それ以外は$LATESTを参照すればよいと思います。

つまり・・私の運用では「AutoPublishAlias」の設定は不要ということです。

・・・じゃぁ、そもそもAutoPublishAliasってどこで使うの?

API Gatewayなどで指定されているLambdaエンドポイントに
エイリアスが指定されている状況において、SAMテンプレートの更新と同期する形で、
エイリアスとバージョンの紐づけを付け替えたい状況
ですかね。

今の私のAlexaカスタムスキルのように
一つのLambdaファンクションで環境を分ける用途になりますと、
最新のバージョンが「prod」エイリアスなどの本番環境に適用されちゃいけないんです。
つまり、私の利用ケースには適さないということですね。

もちろん、一つのLambdaファンクションで開発や本番を定義するという私の考え自体が、
ベスト・プラクティスに則ってない可能性は否定できません。

しかしながら、APIゲートウェイにステージという概念があるように、
Lambdaにもステージという概念があってもいいと思うんですよ。

それを実現するためにエイリアスと「AutoPublishAlias」を活用しようとしていました。

今回の調査により、「AutoPublishAlias」も結局のところ適材適所のパラメータなのだと思いました。
いいアウトプットにはなりました!

以上です!