2019-03-14

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

PHP Laravel

仕事で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でアプリができたらまたご紹介したいと思います！！

2019-03-09

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

スクラム

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

私のスキルレベル

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

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

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

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

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

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

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

プルリクの確認がいらない！

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

手戻りが少ない！

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

知識をチームで共有できる！

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

チームでやってる感！

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

No残業も夢じゃない！

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

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

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

自分でモクモクできない

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

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

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

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

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

まとめ

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

2018-06-05

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

備忘録

WindowsでAWS 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

2018-06-03

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

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

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

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

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

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

2017-12-12

華麗なるワンライナー

セミナー

【第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

WindowsでAWS 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

2017-08-16

【Slack】新しいチャンネルが作成されたら通知できるようにしてみた！

技術検証

社内でもSlackを導入しているのですが
新しいチャンネルが作成されても気づくことができず
後にこんなチャンネルがあったのか！？
ということがしばしばあったので
新しいチャンネルが作成されたら通知する仕組みを作ってみました😊

作成した構成

プログラムを書いてそれをサーバに配置しておくというパターンではなく
Slack Appを使用し、さらにサーバレスで実装してみました！

f:id:aym413:20170816152659p:plain

⑴API GatewayとLambdaの設定

API Gateway
* メソッドは「POST」
* 統合リクエストの「統合タイプ」は「Lambda関数」を設定

Lambda
* 言語は「Node.js 6.10」
* Slack Appとの連携確認が必要なため、一旦下記のコードで作成

exports.handler = (event, context, callback) => {
    context.succeed(event["body-json"]);
};

⑵Slack Appを作成

下記URLにアクセスし、「Start Building」をクリック
https://api.slack.com/

「App Name」と「Development Slack Team」を入力し、「Create App」をクリックすると… f:id:aym413:20170816153143j:plain

アプリケーションが作成されました！

⑶Slack Appの設定 −その1− Bot User

続けてアプリケーションの設定をしていきます

メニューから「Bot Users」を選択
f:id:aym413:20170816155022j:plain

「Default username」にBotのユーザ名を入力

Botをリアルタイムに処理させるため
「Always Show My Bot as Online」を「On」にする

f:id:aym413:20170816163111j:plain

最後に「Add Bot User」をクリックして保存します

⑷Slack Appの設定 −その2− Event Subscriptions

メニューから「Event Subscriptions」を選択
f:id:aym413:20170816154958j:plain

「Enable Events」を「On」にして
「Request URL」に⑴API GatewayとLambdaを設定するで作成した
API Gatewayのエンドポイントを入力します
しばらくして「Verified」になればOKです！
f:id:aym413:20170816155417j:plain

ここで「Verified」にならなければLambdaのコードか
API Gatewayの設定にミスがあるかもしれませんーーー😥

少し下にいって「Subscribe to Bot Events」に
「channel_created」のイベントを追加します
f:id:aym413:20170816155636j:plain

最後に「Save Changes」をクリックして保存します

⑸Slack Appの設定 −その3− Install App

メニューから「Install App」を選択
f:id:aym413:20170816160142j:plain

「Install App to Team」をクリック！
f:id:aym413:20170816160139j:plain

アプリケーションインストールの確認画面が表示されるので
問題なければ「Authorize」をクリックします
f:id:aym413:20170816160603j:plain

インストールされるとSlackの画面で
アプリケーションが起動しているのを確認できます
f:id:aym413:20170816160822j:plain

⑹プログラムの作成

作成された新しいチャンネルを通知するコードを書いていきますー

その前に…Botのtokenが必要なのでそれをメモしておきます
メニューから「OAuth & Permissions」を選択して
f:id:aym413:20170816161208j:plain

「Bot User OAuth Access Token」に書かれているtokenをメモメモ。。
f:id:aym413:20170816161202j:plain

いよいよコードの作成！
今回はBotkitを使って作成しました
Botkitのインストール方法はこちらの記事を参考にさせていただきました！
http://blog.duck8823.com/entry/2016/05/20/005734

コードはいたってシンプル↓

# vi index.js
//slack settings
var Botkit = require('botkit');
var controller = Botkit.slackbot({
  debug: true
});

var bot = controller.spawn({
    token: <メモしたBotのtoken>
});

// slack new channnel
exports.handler = (event, context, callback) => {
  var channelName = event["body-json"]["event"]["channel"]["name"]
  bot.say({
    text: 'new channel: #' + channelName,
    link_names: 1,
    channel: 'C2XXXX' //通知するチャンネルID
  });
};

作成したコードをzipにします

# zip -r xxxx.zip index.js node_modules

zipファイルをLambdaにアップロードすれば完了です！

⑺新しいチャンネルを作成すると通知されるか確認

早速動作するか確認しましょう
f:id:aym413:20170816162241j:plain

おっ！無事に新しいチャンネルの通知が来ました〜
f:id:aym413:20170816162238j:plain

感想

今回作成したものはPublicチャンネルのみ通知されます
もともとPrivateチャンネルは通知されないみたいです
Botのアクションをトリガーにして
他にも様々な仕掛けを作ることができそうです🤗

2017-03-19

JAWS DAYS 2017で登壇してきました！

先週3/11(土)JAWS DAYS 2017が開催されました〜

昨年はボランティアスタッフとして参加しましたが

今回はスピーカーとして参加してきました😄

登壇に至った経緯

今回JAWS DAYSのテーマは「Link Up!」

私自身、最初はコミュニティが好きではなくて

社内は外部とのコミュニケーションをとる人も少ない環境でした。

そこから色々なことを経て、多くの人と繋がることができたことは

今の私にとってとても大きな価値になっています。

きっと同じような環境にいる人、悩んでいる人もいるんじゃないかなと。

私の経験談が誰かの役に立てれば、、そんな思いで公募セッションに応募させてもらいました。

応募者は20名ほどいたようです！！

そんな中選んでいただいてありがとうございます！！

登壇してみて

正直、全然聞いてくれる人は少ないかも。。と思っていましたが、なんと満席！！

聞いてくださった方本当にありがとうございました😭😭

緊張しすぎて日本語ハチャメチャ、時間がかなり早く終わってしまったなど

色々反省点はありました。。

それでも終わった後に「良かったです」と話しかけていただいたり、

Twitterでも「若手エンジニアに聞かせたい」などの反応をいただきとても嬉しいです！

みなさんに「一歩踏み出そう！」というメッセージを伝えたので

私も今年は一歩進んでAWS HUBに参加してみようかなと思います！！

セッション資料はこちらです↓

【追記】懇親会の司会もしました！

お誘いいただき、懇親会の司会もやることに〜

司会なんてやったことないし、どうなるかと思っていましたが

みんなお酒が入っていたのでなんとかなりましたw

コスプレしていたので、色んな方と写真も撮って

覚えていただくきっかけになったのではないかなと思います😉

やっぱり色んな人と交流するには、人前に出るのが一番いいですね！

今年のJAWS DAYSは登壇や司会を通じて、

新しい経験と仲間のつながりを増やすことができ

私自身一歩踏み出せたイベントでした😊✨