bundle exec cap staging deploy のつもりが bundle exec cap production deploy を選択して本番環境へデプロイしまったり
docker container start xxx のつもりが docker container stop $(docker container ls -aq) を選択して全てのコンテナをストップさせてしまったり

pecoを経由した「フィルタリングして実行」があまりに便利なので、ついつい「フィルタリング -> 選択」をカジュアルに実施してしまい、結果、コマンド実行間違いが多くなってしまいました。

ちなみに、最近私がやらかしたコマンド実行間違いは、Roadworkerのテストを AWS_PROFILE=my-awstest bundle exec rake で実行するつもりが、AWS_PROFILE=k1low bundle exec rake で実行してしまい、プライベートのRoute53のHostedZone設定を全て消してしまったことです ( これで簡単にテスト環境をつくれるようになったから。。。 )。

いつか、もっと危険なコマンド実行間違いをやらかしそうです。

ExeCopで危険なコマンド実行間違いを防ぐ

というわけで、コマンド実行間違いを防ぐためにExeCopという名前でzsh スクリプトを書いてみました。

github.com

ExeCopは、.execop ファイルを設置しておくことで、そのディレクトリ以下で実行するコマンドを監視してくれます。

そして .execop ファイルに書いてある設定に沿ってコマンドをキャンセルしたり yes/no の確認フェーズをはさんだりします。

demo

インストール

execop.zsh を任意の場所にダウンロードし、 .zshrc に以下のように記述します。

. /path/to/execop.zsh

Bashの場合は、execop.bash を任意の場所にダウンロードし、 .bashrc に以下のように記述します。

. /path/to/execop.bash

`.execop` ファイルの設置

.execop ファイルは例えば以下のように書きます。

deny when command_match destroy
confirm when command_match rm
deny when command_eq rm -rf /
confirm when env_eq AWS_PROFILE=production

上記の設定だと、

コマンドに destroy という文字列が入っていた時、コマンド実行をキャンセルする
コマンドに rm という文字列が入っていた時、yes/no の確認フェーズをはさむ
コマンドが rm -rf / だった時、コマンド実行をキャンセルする
環境環境 AWS_PROFILE が production だった時、yes/no の確認フェーズをはさむ

という監視がはいるようになります。

例えば、TerraformのファイルがあるディレクトリでAWS_PROFILEに制限をかけたり、Capistranoのデプロイディレクトリでデプロイコマンドに確認フェーズを差し込むなどすると良さそうです。

.execop ファイルの監視設定のフォーマットは以下のような感じです。

[action] when [matcher] [command or environment value]

actionは deny か confirm の2つ。

matcherは今のところ command_match command_not_match command_eq command_not_eq env_eq env_not_eq を実装しています。

懸念点

ExeCopを導入するとコマンド実行のたびに監視処理が走ります( preexec )。

若干挙動が遅くなるかもですが、危険なコマンド実行間違いをするよりはマシなのでこのまま運用してみようと思います。

というわけで

危険なコマンド実行間違いにビクビクしている方は、 自己責任で ご利用ください。

ちなみに、皆さんはどのようにしてコマンド実行間違いを防いでいるんでしょうか。

2017-08-21

Webフロントエンドハイパフォーマンスチューニングはサーバサイドエンジニア/デザイナも情報にインデックスをはるために読んでおいたら良さそう

フロントエンドの話を学んでいると思ったらTLSハンドシェイクだったりExpiresとかのキャッシュ系ヘッダだったり「例えばGCを避ける」だったりCPUだったりなんかいろいろ学んでいる。あれ？
— k1LoW (@k1LoW) 2017年8月17日

Webフロントエンドハイパフォーマンスチューニング

作者: 久保田光則
出版社/メーカー: 技術評論社
発売日: 2017/05/26
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

私のフロントエンドスペック

まずは前提です。こういうスペックの人の感想ということでご了承ください。

主にPHPでWebアプリケーションを構築するエンジニア
- jQueryから少し脱しているくらい
  - 数年前まではフロントエンドにもステ振りをしていたが、仕事では最近は大人しくPHPなアプリケーションを構築している
業務でもHTML/CSSでデザインしてくれるWebデザイナとのやり取りが多く、「フロントエンドエンジニア」とお仕事をしたことは数えるくらいしかない
サーバサイドのJavaScriptには最近興味あって触っている（サーバーレスとか）

つまりフロントエンド周辺については趣味プロレベルです。

感想

いやー、濃かった。一言で言うと「濃い」です。正直すべてを理解できたわけではないです。30%理解できていたら上出来です。

でも、読んで良かった！

個人的には

読むと読まないとではゼロイチで違う

そんな書籍でした。残り70%、またどこかで再読しようと思います。

仕組みを根拠としたチューニング

「ハイパフォーマンス」「チューニング」という単語があるように基本的には高速化の本です。

個人的には「ブラウザからサーバへリクエストを投げてからブラウザで次のページに遷移するまで」の仕組みを説明して「だから高速化になりうる」という形でチューニング方法を説明していて、どちらかというと「仕組み」のほうが勉強になりました。

フロントエンドエンジニアの人だったら逆なんでしょう。

むしろ、仕組みについてページをさいていたと思います。フロントエンドの基礎を学んだ感じがしました。

サーバサイドエンジニアにもWebデザイナにもフロントエンドのパフォーマンスのためにできることはある

少々乱暴な分類をします。すみません。

例えば、Webアプリケーションを「サーバサイドエンジニア」「フロントエンドエンジニア」「Webデザイナ」で構築するとします。

HTML/CSSは共通言語です。あとjQueryもいまや共通言語といえるかもしれません。

フロントエンドのパフォーマンス向上はフロントエンドエンジニアが一番得意でしょう。フロントエンドエンジニアに任せるのが一番だと思います。

ただ、だからといってサーバサイドエンジニアやWebデザイナから、何も考えず作られたHTML/CSS/JavaScriptを渡されてもパフォーマンス向上の余地は小さいと思います。

フロントエンドのパフォーマンス向上の余地をできるだけ広くするようにサーバサイドを構築したり、HTML/CSSを組んだりすることはできるはずです。

そういった意味で、サーバサイドエンジニアとして「フロントエンドの領域で○○に注意して構築することでパフォーマンス向上の余地を残しておく」という情報にインデックスを貼ることができる書籍でした。

そういえば思い出したのですが、昔、Webデザイナの方から「CakePHPのctp分離を完全に考慮したHTML/CSS」を渡されて、最高に効率よくデザイン適用と運用できた経験があります。最高にテンションがあがりました。

私もそういったバトンタッチができるようになりたいです。

章別感想

かんたんに章別の感想です。

1〜3章

自分の得意分野でない範囲の技術書、読み進めるのめちゃくちゃ遅い。
— k1LoW (@k1LoW) 2017年8月15日

本書を読むときにいろいろ前提となるので、まず読んでおいたほうが良い章です。3章の「計測」章は今すぐからでも使えますね。

ただ、まさかTCP/IPやTLSハンドシェイクの説明からはじまるとは。。。。

4章

俄然面白くなってきた！得意分野じゃなくてもいつも触っている守備範囲で知らなかったことを知る体験すると進む。技術書がススム君。
— k1LoW (@k1LoW) 2017年8月17日

個人的に俄然面白くなった章です。

理由は明らか。自分の守備範囲だから（しかも知らないことがあった）。defer属性とか使ったことなかったです。

「できることはいろいろある」というのを感じることができた章でした。

逆に言うとあまり気にしていなかったんだなーと。

4章は「あー知ってる、知ってる」となりたかった。。。

5章

JavaScriptの別の世界。

「console.log()はメモリリークする」なんて、フロントエンドの世界では常識なんですか？

この章から著者 id:anatooさんの以下の発表が追加章的につながっています（と思いました）。こちらもどうぞ。

JavaScriptを書くとき、ここまでしっかり考えたことなかったな。。。

6〜8章

ざっくりいうとDOMの世界のチューニング。

CSSをどう組むかについて、私は良くて「メンテナンサビリティ」、大抵は「うまく表示できるか」程度しか考えられていませんが、パフォーマンスという観点でCSSを組む世界。。。

「子孫セレクタ、間接セレクタは他のセレクタよりもオーバヘッドが大きい」というかそもそも間接セレクタを知らなかったりしました。

9章

「認知的チューニング」ということで体感速度についてチューニングの章。一般的な手法について丁寧に解説しています。

こういった処理は実装時からうまく入れられるようにしていきたいです。

フロントエンド領域を知ることができる書籍

例えば「SPA」がもてはやされるようになっているように、フロントエンドと呼ばれる領域はますます重要になってくるんだと思います。

自分はフロントエンドエンジニアには（おそらく）ならないとは思いますが、フロントエンドエンジニアと一緒にうまく開発ができるエンジニアにはなりたいです。

本書「Webフロントエンドハイパフォーマンスチューニング」は、Webアプリケーション開発に関わっているエンジニア/デザイナ「も」フロントエンドの情報にインデックスをはるために読んでおいたら良さそうな本だと思いました。

最後に

本書は Geeks Who Drink にて、著者の id:anatoo さんから頂きました！

ありがとうございました！

さて、計測してみよう。。。

2017-08-16

RoadworkerのテストAWS環境を構築するroadworker.tfを作成した

Ruby AWS Terraform

やっと重い腰をあげて、まずはテスト環境を構築できるようにしました。

RoadworkerのテストにはAWS環境が必要

RoadworkerはRoute53を管理できる構成管理ツールで、Codenize.toolsの1つです。

多くの企業で導入実績があり、また、十分なテストが書かれているので安心して利用ができます。当然のようにTravisCIによるCIも回っています。

では、そのテストはどのように実行されているかというと、作者である id:winebarrel さんのAWS環境で実行されています。

.travis.yml をみてわかるとおり、最低限必要なAWSリソースとして

まっさらな Route53 ( RoadworkerがRoute53のHostedZoneから管理するツールのため )
VPC
ELB
CloudFront

があります。特にELBの月額費用は月額18USDと馬鹿にならない料金です。

それらを用意してもらっているので、PullRequestベースなら自前でテストAWS環境を用意しなくてもテストが可能です。感謝。

それでも自前の環境でテストを実行したい

とはいえ、新しい機能を追加したいときや、ちょっとした修正をPullRequestをしたいとき、事前にテストを実行したいものです。

無駄にPullRequestを出してテストを回しまくるわけにもいかず、TravisCIの順番待ちもちょっと効率が悪いです。

できれば自前の環境でもテストを実行したいです。

RoadworkerのテストAWS環境を構築するTerraformコード

というわけで、RoadworkerのテストAWS環境を構築するTerraformコードを作成しましたので共有します。

Test environment for Roadworker

使い方

必ずRoute53を利用していないAWSアカウントで実行してください

$ ls
roadworker.tf

$ terraform apply # Terraformを実行してAWS環境を構築
$ terraform output # Terraformのoutputを確認
AWS_REGION = ap-northeast-1
TEST_AWS_ACCESS_KEY_ID = XXXXXXXXXXXXXXXXXXX
TEST_AWS_SECRET_ACCESS_KEY = XXXxxxxXXXXxXXXXXXXXXXxxxxxxxXXXXX
TEST_CF = dxxxxxxxxxxxxx.cloudfront.net.
TEST_DELAY = 0.3
TEST_ELB = roadworker-test-000000000000.ap-northeast-1.elb.amazonaws.com.
TEST_INTERVAL = 3
TEST_VPC1 = vpc-x0x0x0xxx
TEST_VPC2 = vpc-00x0x0x0
TEST_VPC_REGION = ap-northeast-1

$ eval $(terraform output | sed 's/ //g' | sed 's/^/export /') # outputの結果を利用して環境変数をセット
$ cd /path/to/roadworker
$ bundle exec rake # Roadworkerのテストを実行

テスト環境が必要なくなったら terraform destroy で作成したAWSリソースを削除できます。

テスト環境を作成した経緯

実は、つい先日まで私が codenize-tools/roadworker に実質放置していたPullRequestがありました。

自分の環境で該当箇所のテストだけ実施して、いざPullRequestを出してみると他のテストでエラーになりました（この時点でマズいPRの出し方でした）。

しかし（プライベートなAWS環境は既にRoute53を使っていたので）テストを回すための環境がなかなか用意できず、エラーの検証もなかなかできず今に至っていました。

github.com

今回、やっとRoudworker用テストAWS環境を用意し、テストを利用して試行錯誤して、やっと「自分の修正の筋が悪そうだ」ということに気づけてCloseしました（すみません）。

やっとテスト環境を手に入れたので

またじっくり検証してみます。

2017-07-25

Serverless Frameworkというかサーバレスアーキテクチャの話をGeeks Who Drinkで発表してきました #GWD_Nulab

Serverless

@agata さんに良い機会をもらってビール片手に発表してきました！ 🍻

nulab.connpass.com

requestIdleCallback() の話

@anatoo さんの発表。ブラウザ上で様々なリッチアプリケーションが動くようになってどんどん要求が増えていっているのだと思います。

requestIdleCallback() はブラウザのアイドル時間に様々な関数を実行できるというものらしく、Web Workerとの対比でわかりやすく説明してもらえました。

その時には用途を思いつきませんでしたが、Webブラウザ上で実装しているIDEなどには良さ気な機能だと思います。

Cacooの没実装の話

@hiramako さんの発表。没実装になった理由や採用された実装の対比など、とてもわかりやすかったです。その分「かなり苦労して開発してそう」という感想。

それだけにCacoo HTML5は楽しみです。

Kibelaを支える技術

@ihara2525 さんの発表。Blog + Wiki + αなKibelaの紹介。Fusicももっと大きくなったら社内共有サービスをこんな風に拡張すればいいんだろうか。

「技術的挑戦は精神衛生上必要」っていうのは最近特に思います。

Shifterの話

@tekapo さんの発表。Shiferの話でした。すごくスッキリわかりやすかったです。

対応できるWordPress（WordPressはいろいろ拡張できるので）の範囲がどんどん広がることを期待しています。

Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見を共有してきました

早口なうえに（おそらく）時間オーバーをしてしまったという詰め込みっぷりでした。

本当はもう少し最後らへんの設計のアイデアの話をじっくり話したかったのですがやはり無理でした。。。

hubedit以外はすべてGitHubでソースコードを公開しているので、アーキテクチャの図と見比べて「あー、こんな感じね」とみてもらえれば。

そして

読ませていただきます！ #GWD_Nulab pic.twitter.com/pYq5Lxu3YQ
— k1LoW (@k1LoW) 2017年7月21日

じゃんけん大会で勝った！！！@anatoo さんありがとうございます！

まだ途中ですがじっくり読みたいと思います！

主催のNulabの皆さん、また発表者、参加者の皆さんありがとうございました！🍻

2017-07-13

GitHubのプライベートリポジトリをストレージとして活用したシンプルなメモサービスhubeditを作っている

Serverless GitHub

個人でGitHub有料プランの人しか使えないサービス作っている
— k1LoW (@k1LoW) 2017年7月5日

スマートフォンのブラウザからでもメモが書けるサービス

自分はいつも簡単なメモ書きにはEmacsか、ブラウザを開いていたら wri.pe を使っていました。

wri.pe を使い始めたのは2013年からで、かれこれ4年使っていることになります。

wri.pe で気に入っているところは

シンプル
スマートフォンのブラウザからもストレスなく使える
バックアップが自分がハンドリングできる場所に取れる（wri.peはDropbox）

というところです。

いつでもどこでもブラウザがあれば雑にメモが取れるのが最高です。

ただ、ちょっと困っていることがあって wri.peは最近

~~ノートの検索機能が動かない~~ （微妙に動いている！？）
ノートの削除機能が動かない

という状況が続いています。

これが地味に効いてきているので、「自分で作ってみようかな」という気持ちになって作りはじめています。

hubedit

hubedit.com

f:id:k1LoW:20170713071007p:plain

hubeditは wri.pe と同じように

シンプル
スマートフォンのブラウザからも使える
バックアップが取れる

を主眼に置いています。（まあ、つまり「自分が便利に使えるように」ということですね。）

特に「バックアップ」が特徴で、バックアップというよりもむしろバックエンドにGitHubのプライベートリポジトリを使います。

OAuth連携したGitHubアカウントで my-hubedit というプライベートリポジトリを作ってそこをメモの保存場所とする、つまり、メモの操作を全部 git commit ベースで実施するというアーキテクチャです。

GitHub リポジトリということは、当然 git pull して手元のEmacsでメモを作成編集することも可能です。

つまりいつものソースコードのように、ローカルでの編集と git push による同期が可能。便利。

また、せっかくバックエンドがリポジトリなのでディレクトリにも対応しました。

アーキテクチャ

f:id:k1LoW:20170712231630p:plain

いわゆるサーバレスアーキテクチャで構築しています。

HTMLや、そのHTML上のJavScriptが叩くAPIから全てを、API Gateway / AWS Lambdaで実装しています。メモファイルの操作は全部GitHub API v3で操作しています。

とりあえず早く使えるようにしたかったので、今のところ画像は皆無で、CSSやFont、JavaScriptなども直書きか cdnjs ベースにしています（そのうち気が向いたらS3の静的Webサイトホスティングなども活用しようかと思います）。

取得したGitHubのOAuthトークンだけはS3バケットに置いていますが、これもS3バケットのライフサイクルポリシーで1日で消えるようにしています。

ストレージは各々のGitHub リポジトリなので、hubeditの利用をやめたいときはGitHubでOAuth連携をはずすだけで完了です。

まだ微妙な点

GitHub API + S3をバックエンドとしているのでレスポンスがもっさりしている
- DynamoDBをつかったら少しは早い？まあ、あきらめている
メモの編集が2コミットに分かれている（削除と追加）
- ちゃんとコミットを作りたい
Vue.jsを初めて使ったので、コードが微妙っぽい。JSファイルの読み込み方法も開発モードのまま
UIが雑。ローディングアクションすらない。
ロゴがない（またか）

というわけで

個人利用としてはまあ満足です。

とりあえずwri.peのメモを変換して git push したので、このまま本格利用してみようと思っています。

PUBLIC BETAとして公開していますので、興味ある方は自己責任でご利用下さい。

（これってもっとがんばって組んだら、GitHub リポジトリをバックエンドにしたチーム情報共有サービスなんて作れたりするんだろうか。）

PHPのカンファレンスでServerless Frameworkについて話すということ

というわけで

サーバーレスアーキテクチャはシステム間の糊的な役割としても使えるがシンプルなサービスを作るだけのポテンシャルはある

感想

懇親会が最高だった

というわけで

コマンド実行間違い

ExeCopで危険なコマンド実行間違いを防ぐ

インストール

.execop ファイルの設置

懸念点

というわけで

私のフロントエンドスペック

感想

仕組みを根拠としたチューニング

サーバサイドエンジニアにもWebデザイナにもフロントエンドのパフォーマンスのためにできることはある

章別感想

1〜3章

4章

5章

6〜8章

9章

フロントエンド領域を知ることができる書籍

最後に

RoadworkerのテストにはAWS環境が必要

それでも自前の環境でテストを実行したい

RoadworkerのテストAWS環境を構築するTerraformコード

使い方

テスト環境を作成した経緯

やっとテスト環境を手に入れたので

requestIdleCallback() の話

Cacooの没実装の話

Kibelaを支える技術

Shifterの話

Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見を共有してきました

そして

スマートフォンのブラウザからでもメモが書けるサービス

hubedit

まだ微妙な点

というわけで

`.execop` ファイルの設置