Qiitadon忘年会まとめ
日曜日なのにQiitadonが早い
今日はQiitadonの非公式忘年会だから
ホテルニュー淡路
はやすぎるひとたち（集合は16:00）
駅集合なのに早く着きすぎて、ファミレスで開かれる０次会
痛む、なのやつの古傷
足りないまな板
かろてん宅到着。直後のっとられたアカウント
LTL読み上げライブ開始
買い出し
カーテンがない
ボウルがない
いろいろない
でもオーブンレンジはある
さっき買ってもらった
でもカーテンがない
ウォーターサーバーはある
でもカーテンがない
突然始まる工事
なのやつのかつやく
かりてきたねこ
なべ（おいしい）
全ての話の落とし所に使われるカーテン
https://qiitadon.com/web/statuses/101284899848528333 qiitadon.com
ふかまるなのやつ氏
全部俺アプリ
おわらない忘年会
たのしかったようでなによりです
つづく
後遺症
babelで現在のnodeJsのバージョンに合わせてトランスパイルする
** あとで少し追記する
babelのinstall
yarn init -y yarn add @babel/cli --dev yarn add @babel/core --dev
コンパイルするソース
class Hoge { constructor() { } } const hoge = new Hoge();
コンパイル
何も入れず、そのままコンパイルしてみる
yarn run babel index.js
class Hoge { constructor() { } } const hoge = new Hoge();
そのままでてきた。
@babel/preset-envを入れてみる
今まではbabel-preset-es2015など、 トランスパイルするときに参照する仕様をパッケージに追加する必要があった。
しかし、@babel/preset-envを用いれば、 実行環境に合わせて勝手にパッケージを追加してくれる。
また、ブラウザを指定した変換ができたりする。
今回はnode上で動くようにトランスパイルするので、 .babelrcを以下のように指定。
yarn add @babel/preset-env --dev
{
"presets": [
[
"@babel/preset-env",
{
"useBuiltIns": "entry",
"targets": {
"node": "current"
}
}
]
]
}
dockerのコンテナを削除する〜サブシェルについて〜
いきさつ
とまっているDockerコンテナを全部削除したい。
と思って方法を調べたら「サブシェル」という技術を知った。
方法
$ docker rm $(docker ps -aq)
解説
( )
（ ）でくくった処理はサブシェル内で実行する。
親シェルの環境変数を汚したくないときに使う。
$( )
$( )内の標準出力を値として得ることができる。
$ echo $(ls) Applications Desktop Documents Downloads Dropbox Library Movies Music Pictures Public
これを引数として渡すことができるのか。
releaseブランチを導入するメリットについて考える
背景
masterブランチとdevelopブランチ、
それとfeatureブランチで開発しているケースを考える。
developからfeatureブランチを生やして、featureの開発が終わったらdevelopにマージ。
developにマージしたものをリリースのタイミングでmasterにマージ。
それを本番環境にリリース。
問題
リリースに伴い、コードの細かい修正を行うことがある（リリース作業と呼ぶことにする）。
それらのリリース作業と開発作業が並行して行われるとき困る。
リリース作業内容も開発作業内容もdevelopにマージされるので、
それをmasterにマージしてリリースすると、開発途中のものまでmasterにマージされてしまう。
まだリリースしたくない機能があるのにリリースされてしまったりするよ。
解決策
開発用のブランチとリリース用のブランチを分ける。
リリース作業に入った時、developブランチからreleaseブランチを切って、
それに対してリリース作業のコミットをする。
リリース作業が終了すればmasterにマージする。
（さらにdevelopにもリリース作業の内容を反映させるため、マージする）
メリット
リリース作業中でも、developブランチにプルリク＆マージができるので、
作業が滞らずに進む。
リリース作業中の開発内容が本番環境にリリースされることがなく、安全。
AWSのCloudFrontの設定(OriginPath)を、aws-cliから変更する
いきさつ
デプロイ自動化の一環で、
AWSのCloudFrontの設定をaws-cliから変更したくなった。
（今回変更したのはOriginPath）
前提
出来上がったシェル
# Etagの抽出 RAW_ETAG=$(aws cloudfront get-distribution-config --id "xxxxxxxxx" | jq '.ETag') ETAG=$(echo ${RAW_ETAG} | sed "s/\"//g") # 今の設定をファイルとして抽出 aws cloudfront get-distribution-config --id "xxxxxxxxx" | jq '.["DistributionConfig"]' > old_dist.conf # 抽出した設定ファイルの書き換え cat old_dist.conf | jq '.["Origins"]["Items"][0]["OriginPath"] = "'/dir_name'"' > new_dist.conf # 新しい設定の適用 aws cloudfront update-distribution --id "xxxxxxxxx" --distribution-config file://new_dist.conf --if-match ${ETAG}
解説
全体について
CloudFrontの設定を変えるには、
aws cloudfront update-distribution --id "xxxxxxxxx" --distribution-config file://new_dist.conf --if-match ${ETAG}
というコマンドを叩きます。このとき
- 現在のCloudFront設定のバージョンを表す文字列「Etag」
- 新しい設定ファイルである「new_dist.conf」
が必要になるので、準備が必要です。
Etagの抽出
RAW_ETAG=$(aws cloudfront get-distribution-config --id "xxxxxxxxx" | jq '.ETag') ETAG=$(echo ${RAW_ETAG} | sed "s/\"//g")
普通に抽出するとダブルクォーテーションが着いてしまうので、 除去しておきます。
新しい設定ファイルである「new_dist.conf」を生成
# 今の構成ファイルの抽出 aws cloudfront get-distribution-config --id "xxxxxxxxx" | jq '.["DistributionConfig"]' > old_dist.conf # 抽出した構成ファイルの書き換え cat old_dist.conf | jq '.["Origins"]["Items"][0]["OriginPath"] = "'/dir_name'"' > new_dist.conf
まず今の構成ファイルを抽出し、
そのファイルの一部（今回でいうとOriginPath）を書き換え、
新しい設定ファイルを生成しておきます。
感想
これだけでもだいぶ便利になった。
CUIはやっぱりよい。
Go言語製のmigrationツール、sql-migateを使ってみた（postgresSQL編）
経緯
開発環境と本番環境のDB差異をできる限り無くすためにmigrationツールを導入する。
プロジェクトリポジトリと同じリポジトリでマイグレーションファイルを管理することにより、
ソースコードとDBスキーマのバージョンを同期させることができる。
使用するmigrationツールは「sql-migrate(https://github.com/rubenv/sql-migrate)」
導入
goの実行環境を入れる
$ brew install go
~/.bash_profileに以下を記述して、パスを通す
export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin
~/.bash_profileを読み込む
source ~/.bash_profile
sql-migrateをinstall
$ go get -v github.com/rubenv/sql-migrate/...
$ sql-migrate -v #バージョンが表示されればinstall成功
DB設定をdbconfig.ymlで記述
development: dialect: postgres # 使用するRDBMS datasource: dbname=dbName host=hostName user=userName password=passWord port=5432 sslmode=disable dir: migrations/postgres # マイグレーションファイルのあるディレクトリ table: migrations # マイグレーション履歴を保存するテーブル名
使用方法
マイグレーションファイルの雛形を作成
sql-migrate new add-column-to-user-table # Created migration migrations/postgres/20181206145950-add-column-to-user-table.sql と表示されます。これが雛形です。
マイグレーションファイルの雛形を編集
-- +migrate Up create table users ( id serial PRIMARY KEY, name text NOT NULL, date timestamp NOT NULL); -- +migrate Down drop table users;
以上のようにup（行いたいスキーマ変更SQL）とdown（それを打ち消すSQL）の両方を記述する必要があります。
マイグレーションファイルの実行
sql-migrate up
これでupに記述したSQLが実行されます。 upに書いたSQLが間違っていたなどで、DBスキーマを元に戻したい場合は、
sql-migrate down
で元に戻してください。その後、upに書いたSQLを編集し、マイグレーションファイルを実行し直してください。
補足
どこまでマイグレーションが実行されているのかは、
$ sql-migrate status
で確認できます。 なおこの情報はmigrationsというテーブルでも確認できます。
