こぶろぐ。

Engineer / AWS / CYDAS

【イベントレポート】 JAWS-UG 横浜支部 #15 に参加してきました!

3/20(水)に行われた JAWS-UG 横浜支部 #15 のイベントレポートです!

今回はMedia-JAWSとのコラボ企画!

その名も・・「Media-JAWS #0 〜メディア✕AWSスペシャル〜
ということで、会場も放送局のようなセッティングに!
f:id:aym413:20190321175651j:plain:w500  

Media-JAWSというだけあって本格的なライブ配信も行われましたよ〜
f:id:aym413:20190321175854j:plain:w500

そもそもMedia-JAWSって??

Media-JAWSは、メディアの世界でAWSをどのようにして活用しているか情報を共有していくためのコミュニティとして設立予定です。
今回は設立前のプレイベントとして、メディア✕AWSの内容で勉強会が開催されました!

AWSを利用したライブ配信構成まとめ:アイレット 土田さん

社会人4年目+インフラエンジニア=土田さんからは事例を交えながらライブ配信の構成についてお話してもらいました。

  • ライブ配信を行う際の構成としては3つ
  • AWSベーシック構成(EC2, CloudFront, S3など)→ そこまで要件に厳しくないお客さん向け
  • AWS+有償製品(Wowzaなど)→ いろんなデバイスで配信したいなどの要件があるお客さん向け
  • AWS Media Services フルマネージドサービス → 未実装の機能はある(自動フェイルオーバーの機能がない)が案件の引き合いは増えている

さっぽろ雪まつり配信におけるMediaLive失敗談:北海道テレビ 三浦さん

なんと今日のために北海道から駆けつけてくれた三浦さん。
さっぽろ雪まつりを5G 4Kでライブ配信したときの失敗談についてお話してくださいました。

  • MediaLiveでは4K配信できず。。jstreamを使って実現した。
  • jstreamを使って配信をすることに決まったあと、MediaLiveのチャンネルを削除するのを忘れてとんでもなき請求が来てしまった・・
  • ライブ配信を行うのに雪をショベルカーで掘って、パイプの中に配線を通している映像には驚きました!

Media ServicesとAIを利用した字幕付きライブ配信テレビ東京 段野さん

今回のMedia/JAWSの発起人である段野さんから字幕付き配信のお話をしてもらいました。

  • リアルタイム字幕には「Closed Caption」と「リアルタイム変換」の2種類がある
  • Closed Caption:特定のインターバルごとにまとめて字幕を表示する
  • リアルタイム変換:字幕生成したタイミングで随時表示する
  • 目指すカタチは、Closed Captionで表示し、クラウドで処理を完結させ、字幕変換はAIで!
  • 字幕付き配信のデモでは、少し誤訳があるものの、ほぼしゃべってる内容に差がありませんでした!日産のゴーン社長が「5分」と訳されるなど、誤訳も面白く、会場は笑いに包まれていました。

www.slideshare.net

あなたの知らない怖い話 ~メディアコンテンツに迫る魔の手~:IMAGICA Lab. 蜂須賀さん

身の毛もよだつお話をしてくださったのは蜂須賀さん。
メディアコンテンツのセキュリティに関するお話をしてくださいました。

  • S3に置くファイル名はファイルの中身が特定されないものにする
  • 配信を行う際は、CloudFrontで署名付きURLで
  • 画面録画に対する対策としては透かしを入れるなどして漏えいしたユーザーを特定できるようにする
  • メディア限定のセキュリティというわけではなく、IT・AWSに関わっている人ならやってしまいがちなことが多く耳の痛い話ばかりでした、、

www.slideshare.net

 

DXGWは海外映像配信で使えるのか?MediaConnectの事例を交えながら:NTT東日本 里見さん

里見さんからは通信キャリアの方ならではの海外にコンテンツ配信するときのお話をしてくださいました。

  • ダイレクトコネクトGW(直接海外へ配信する)よりも、VPC Peeringで海外に配信したほうが安定している
  • MediaConnectの検証がまだ未完了とのことで次回のMedia-JAWSでの発表に期待!
  • ダイレクトコネクトを使った検証は通信キャリアの方ならではのお話で大変貴重でした

もっと詳しく聞きたい!という方はこちら

www.youtube.com

Togetterはこちら

togetter.com


参加していただいた方も半分くらいはメディア業界で働いているというJAWS-UGでも珍しい顔ぶれとなりました。
次回のMedia-JAWSは4月下旬を予定しているそうなので、興味のあるかたは是非ご参加ください!

【Google Apps Script】 資格試験の練習問題をSlackに投稿するBotを作ってみた!

弊社の技術部でAWSのソリューションアーキテクト-アソシエイト全員合格を目指そう!ということで、毎日試験の練習問題をSlackに投稿するBotを作ってみました!

完成イメージはこんな感じです↓ f:id:aym413:20190317222212p:plain

今回、試験問題はGoogleスプレッドシートに記載して、Slackに試験問題を投稿するスクリプトGoogle Apps Scriptで書いてみました。

Google Apps Script(GAS)とは?

Googleが提供しているスクリプト作成・実行ができるサービスです。
言語のベースはJavaScriptです。

試験問題の作成

試験問題は下記のような形でスプレッドシートに記載していきます。
f:id:aym413:20190320125357p:plain

A列 B列 C列〜
日付 問題 選択肢

GAS上でスクリプト作成

「ツール」>「スクリプトエディタ」を開きます。

f:id:aym413:20190317232351p:plain:w300

エディタに下記のコードを貼り付けて保存します。
任意の値の箇所は環境に合わせて変更してください!

いざ、実行!

メニューから関数を選択して「実行」をクリックします。

f:id:aym413:20190318233846p:plain:w300

実行するとSlackに投稿されました!

問題文にリアクションをつけてしまうと、自分で解答を考える前にみんながどれを選んでいるのかわかってしまう・・ということで、問題文を投稿したスレッドで解答を選べるようにしました!
f:id:aym413:20190317222836p:plain:w300

日次でSlackへ自動投稿

最後にSlackへ自動投稿するためのトリガーを作成していきます。
トリガー作成もブラウザから設定できるので難しくありません!

メニューから「現在のプロジェクトのトリガー」をクリックします。
f:id:aym413:20190318234030p:plain

別画面が開くので、画面右下の「トリガーを追加」をクリックします。
f:id:aym413:20190320121344p:plain

トリガーの設定をしていきます。
今回は毎日Slackへ投稿したいので下記のような設定をしました。
f:id:aym413:20190320121540p:plain:w350

「保存」をクリックすると、一覧画面に表示されます。
f:id:aym413:20190320122102p:plain

これで設定は完了しました!
とっても簡単ですね!!

ハマったところ

スプレッドシートから値を取得してSlackに投稿すると文字化けする

スプレッドシートから取得した値を表示しようとするとこんな表示になることがあります。
f:id:aym413:20190320113414p:plain:w300

そんな時は、下記のようにやるとちゃんと文字列として表示されるようになります。

<変数名>.toString().replace(/,/g , "\n");

また今回は、上記のようにやらなくても文字列と変数を結合することで文字化けせずに表示できました。

57行目   var message = '*問題*' + '\n\n' + questions + '\n\n' + '*選択肢*' + '\n\n';


Slackの数字絵文字は英語表記でないと文字列になる

通常、Slackの絵文字で :1: と入力するとf:id:aym413:20190320125247p:plain:w20と出ますが、スクリプト内で「:1:」を生成しても、絵文字にしてくれません・・。

f:id:aym413:20190320130516p:plain:w300

仕方がないので今回は数字の英語配列を作成することで対応しました。

2行目   // 選択肢のリアクション
3行目   var reaction = ['one', 'two', 'three', 'four', 'five', 'six'];

何かいい方法があれば是非コメントください!!


GASを今回初めて使ってみましたが、簡単に作成することができました。
これを応用してWeb APIで取得した値をスプレッドシートに書き込んで、集計するなんてことも簡単にできそうですね!

【Laravel5.8】macOSにローカル環境を構築する

仕事でPHPフレームワークであるLaravelを使うことになったので、勉強がてら色々と作ってみようと思い、まずはローカル環境を構築してみました!

今回はローカルにLaravelをインストールする手順をまとめておきます。

今回インストールした環境

名前 バージョン
macOS Mojave 10.14.3
PHP 7.1.23

今回インストールするバージョン

名前 バージョン
Homebrew 2.0.4
Composer 1.8.4
Laravel 5.8.4

Homebrewのインストール

こちらにあるHomebrewのインストールコマンドを実行します。 https://brew.sh/index_ja.html

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

途中「Press RETURN to continue or any other key to abort」といわれるので Enter キーを押下します。
その後、パスワードの入力を求められるので入力してください。

Homebrewがインストール出来たことを確認します。

$ brew --version
Homebrew 2.0.4

Composerのインストール

パッケージ依存管理ツールであるComposerをインストールします。

$ brew install homebrew/core/composer

Composerがインストール出来たことを確認します。

$ composer --version
Composer version 1.8.4

Laravelのインストール

composerでLaravelをインストールします。

$ composer global require "laravel/installer"

パスを通して・・

$ vim ~/.bashrc
export PATH="$PATH:$HOME/.composer/vendor/bin"

ファイルを再度読み込みます。

$ source ~/.bashrc

プロジェクトの作成

プロジェクトを作成します。

$ cd <任意のディレクトリ>
$ composer create-project --prefer-dist laravel/laravel <プロジェクト名>

コマンドが実行し終わるまでに1分ほどかかります・・
 

ローカル環境の起動

いよいよサーバーを起動して、初期ページを表示してみましょう!

$ cd <プロジェクト名>
$ php artisan serve
Laravel development server started: <http://127.0.0.1:8000>


ブラウザで「http://127.0.0.1:8000」へアクセスします。 f:id:aym413:20190311212833p:plain Laravelの初期画面が表示されればOKです!

ローカル環境の停止したい場合は、「Control + C」で停止できます。


簡単にLaravelのインストールができました!
Laravelでアプリができたらまたご紹介したいと思います!!

モブプロを3ヶ月ほどやってみた話

2019年1月からチーム(3名)でモブプロをやっているのですが、
最初からうまくいっていたかというとそうでもなくて・・
今回はモブプロを約3ヶ月間やってみての振り返りを書いてみます。

私のスキルレベル

本格的にコードを書き始めたのは、ここ6ヶ月くらいです。
それまではAWSインフラの構築を行ってました。

全くコードを書いたことがないかというとそうではなくて、Lambdaを使ってコードを書いたり、運用でシェルスクリプトを触ってたりしました。
でも、コードをレビューしてくれる人もおらず自分なりの書き方でコードを書いてました。
なので開発のお作法も知らず、functionに切り分けることもしてませんでした(恥

モブプロをやってみることになった経緯

元々スクラムという開発手法を使って開発を進めていたのですが、昨年末チームの振り返りで出た意見としては・・

  • 1つのプロダクトバックログ(PBL)を1人が担当していてタスクが属人化してしまっている
  • スプリントごとのふりかえりで KPT をやっていたが、個人の感想を話すくらいになってしまっていた
  • スクラムの良さを活かしきれていない などなど

これらの反省点とチームメンバーの中でアプリ開発有識者が1人しかいなかったということもあり、チームでレベルを上げていこう!ということで基本モブプロで開発を進めていくことになりました。

モブプロをやってみてよかったこと

  • プルリクの確認がいらない!

以前は、正直プルリク内容を見ても何をやっている処理なのかを短時間で理解することが難しく、変数のミスなど簡単な間違いにしか気づくことができませんでした。
モブプロにしたことでメンバー全員が仕様やコードを理解しながら進めていけるのでプルリクの確認がいらなくなりました。

  • 手戻りが少ない!

以前は、プルリクを出すまで自分のミスに気づかないため、手戻りが発生してしまいました。
モブプロにしたことで間違いがあればナビゲーターがすぐに指摘してくれるので手戻りがなくなりました。

  • 知識をチームで共有できる!

以前は、自分なりのコードの書き方でやっていたのでアプリ開発者がどうやってコードを書いているのかがわかりませんでした。
経験者とモブプロを行うことで、コードの追い方やどうやって無駄なく処理を書けるかなど、近くで色々な知識を教えてもらえます!

  • チームでやってる感!

先ほども書いていたように去年まではタスクが属人化してしまっていて、困ったら誰かに聞くというスタイルでした。
モブプロにしたことでわからないことに対しては指摘してくれるし、出来たことはみんなが褒めてくれます。小さいことでも達成感を得ることが増えました。

  • No残業も夢じゃない!

25分を1ポモドーロとして、午前3ポモドーロ・午後8ポモドーロを目安にやっています。基本開発全てをモブプロでやっているのため、集中している時間がかなり増えました。なので、定時になるとメンバーみんなヘトヘト状態ですw
おかげで定時間内に集中してタスクを進められ、ほぼ残業ゼロ!になっています。

モブプロをやってみて気になること

上記を見て、モブプロいいことしかないじゃない!やるしかないじゃない!と思った方も多いかもしれませんが、最初はモヤモヤすることも多かったです。。

  • 自分でモクモクできない

私は自分の知らない知識は自分で調べて、解決するということに大きな達成感を感じる方でした。
なので、ドライバーをやっていてナビゲーターからああやるんだよ、こうやるといいよとアドバイスばかりをもらっていて、自分自身で何も出来ないことに対してとても悔しいという気持ちがありました。
今は全くないというわけではありませんが、「早く間違いに気づける」「早く知識を付けられる」という意識で悔しい気持ちも前向きに捉えるようにしています。

  • メンバーのモチベーションがチームの空気に影響する

チーム全体でつまづいてしまい、ちょっとどんよりした空気になってしまうこともしばしば・・。ひとりでタスクをやるときよりもチームメンバーのモチベーションがチームの空気を大きく影響するんだなあと感じました。
そこで私たちは、チーム全体がつまづいた時は一旦それぞれで調査を行う時間を作り、気分を変えるようにしています。

  • チームビルディングが大事!

お互いにコードのアドバイスを行ったりするので、相手を信頼し、尊敬し合っている関係でないと言い方がきつくなってしまったりすることもあるかと思います。幸い、私たちのチームは3ヶ月間チームビルディングを行っていたので、お互いに気になったことを言える関係だったのでよかったです。これから新しい人が入ってきた時には気をつけたいです。

まとめ

全員モブプロ初心者ということでまだまだ改善するべき点はありますが、チーム全体としてはモブプロをやってよかったと感じています!
まだモブプロをやったことがないという方は是非一度やってみてください〜

AWS CLIでUnicodeWarningが出たときの対処法

WindowsAWS CLIを実行して以下のような"UnicodeWarning"が出たとき

↓エラー内容

PS C:\Users\Administrator> aws ec2 describe-regions --region ap-northeast-1
C:\Program Files\Amazon\AWSCLI\.\dateutil\parser.py:601: UnicodeWarning: Unicode equal comparison failed to convert both
arguments to Unicode - interpreting them as being unequal

対策 − PowerShell

> Set-Item env:tz -Value jst

対策 − コマンドプロンプト

> set tz=jst

 

LambdaからS3へファイルアップロード(ウェブサイトホスティング)

メンテナンス画面を作成するときにメンテナンス時間を表示してあげた方が親切だよね!ということでメンテナンス日に合わせてHTMLファイルを更新してS3にファイルをアップロードするLambdaを生成しました!

★重要なのがContentTypeを「text/html」にするところです。

何も指定せずにアップロードしようとすると、「application/octet-stream」になってしまうのです。

その状態でホスティングしてもHTMLファイルをダウンロードするようになってしまいますのでご注意を!!

LambdaからS3へHTMLファイルアップロード

華麗なるワンライナー

【第15回 クラウド女子会 〜美:Cap 雲をもつかむ美しさに最新技術を添えて〜】でご紹介した華麗なるワンライナーのまとめです。

VPC作成&タグ付け

REGION="ap-northeast-1” && \
VPC_CIDR="XXXXXX/X" && \
VPC_NAME="AAAA" && \
VPC_ID=`aws ec2 create-vpc --region ${REGION} \
  --cidr-block ${VPC_CIDR} --query 'Vpc.[VpcId]' \
  --output text` && \
aws ec2 wait vpc-exists --region ${REGION} --vpc-ids ${VPC_ID} && \
aws ec2 create-tags --region ${REGION} --resources ${VPC_ID} \
  --tags Key=Name,Value=${VPC_NAME} && \
aws ec2 describe-vpcs --region ${REGION} --vpc-ids ${VPC_ID} \
  --query "Vpcs[].Tags[].Value" --output text

CloudWatchLogsのロググループ作成&ログ保持期間の変更

REGION="ap-northeast-1" && \
CWL_GRP="CWL_GRP.txt" && \
LOG_PERIOD=7 && \
for LOGGROUPNAME in $(cat ${CWL_GRP}); \
do aws logs create-log-group --region ${REGION} \
  --log-group-name ${LOGGROUPNAME} && \
aws logs put-retention-policy --region ${REGION} \
  --log-group-name ${LOGGROUPNAME} \
  --retention-in-days ${LOG_PERIOD};done

AMI削除&Snapshot削除

REGION="ap-northeast-1" && \
AMI_ALL=`aws ec2 describe-images --region ${REGION} \
  --filters "Name=name,Values=*$(hostname)*" \
  --query 'Images[].ImageId' --output text` && \
for AMI_ID in ${AMI_ALL} ;do \
  SNAPSHOT_ALL=`aws ec2 describe-snapshots --region ${REGION} \
  --filters "Name=description,Values=*${AMI_ID}*" \
  --query 'Snapshots[].SnapshotId' \
  --output text` &&\
  aws ec2 deregister-image --region ${REGION} \
  --image-id ${AMI_ID} && \
  for SNAPSHOT_ID in ${SNAPSHOT_ALL};do \
    aws ec2 delete-snapshot --region ${REGION} \
    --snapshot-id ${SNAPSHOT_ID} \
  ;done \
;done

不要なKeyPairの洗いだし

REGION="ap-northeast-1" && \
aws ec2 describe-key-pairs --region ${REGION} \
  --query 'KeyPairs[].KeyName[]' --output text \
  | sed 's/\t/\n/g' > $(date '+%Y%m%d-%H')_key.txt && \
aws ec2 describe-instances --region ${REGION} \
  --query 'Reservations[].Instances[].KeyName' \
  --output text | sed 's/\t/\n/g' | awk '!abc[$0]++{print $1}' \
  > $(date '+%Y%m%d-%H')_ec2.txt && \
for EC2_KEY_PAIR in $(cat $(date '+%Y%m%d-%H')_key.txt); \
  do CNT=$(grep -x ${EC2_KEY_PAIR} ./$(date '+%Y%m%d-%H')_ec2.txt | wc -l); \
  if [ ${CNT} = 0 ];then echo ${EC2_KEY_PAIR} \
  >> $(date '+%Y%m%d-%H')_delete_key.txt;fi;done

WindowsAWS CLIを実行して"UnicodeWarning"が出たとき エラー内容

PS C:\Users\Administrator> aws ec2 describe-regions --region ap-northeast-1
C:\Program Files\Amazon\AWSCLI\.\dateutil\parser.py:601: UnicodeWarning: Unicode equal comparison failed to convert both
 arguments to Unicode - interpreting them as being unequal

対策 − PowerShell

> Set-Item env:tz -Value jst

対策 − コマンドプロンプト

> set tz=jst