お題「エンジニア立ち居振舞い」 流行に乗りたかったんです...！情報の扱いについて。 大学時代に日本史学をやっていて、よく教授に一次史料を確認しなさいと言われました。ソフトウェアエンジニアになっても同じことを言われます。 いくつかのパターンを見ていきます！ ドンピシャの記事を探す よくやりがちなのは何かわからないことがあったとき、ググってヒットした記事を見て満足するケース。これはわかった気になってるけど見になってないので、応用が効かないしそもそも間違っていることがあるのでいまいちです。とくにIT系の技術はアウトプットが盛んなので、これで済むケースも多いですが、いざgoogle先生が解決できない問題に出くわすと非常に脆い状態になります。 ググっていくつかの記事を比較する 次に複数の記事を見るケース。これは良し悪しだと思っていて、時間がないケースとかなら仕方ないかもしれない。ただ、それでもその

About 私が担当しているインフラ環境で先日インスタンス障害がありましたが、pull型デプロイにしていたからか自動でインスタンスが復旧できたので嬉しさのあまり記事にしてみます。 About 技術スタック AutoScalingにした際のゴールデンイメージ問題 pull型デプロイについて インスタンス起動の流れ この前起きた障害時の流れ この構成のデメリット まとめ 参考 技術スタック consul + stretcher Autoscaling AutoScalingにした際のゴールデンイメージ問題 AutoScallingをさせるにはアプリが全部入りのAMIが必要です（AMIを起動させた時点でサービスインできる状態）。ただ、更新が多いアプリだと更新の度にAMIを作るの時間かかりますよね…。1日10回デプロイするなんてことになったら、CIでやるにしろそれなりの時間がかかるのでかなり面倒く

大したことをしたわけではないですが、とあるプロダクトに対しPRを出し、それがマージされてcontributorになりましたというお話です。ポエム成分多めです。 やったこと awspecのec2 typeにTermination Protectionの属性のテストができるmatcherを追加しました。 github.com やるなかで学んだこと・感じたこと 意外に動くものができる これまでインフラ周りの担当として業務を行って来ていて、chefだとかServerspecだとか各種ミドルウェアの設定だとかはよく書くのですが、実際にコードを書く機会がほとんどありませんでした。（コードの定義が難しいのですが、何かのサービスやプロダクト自体のコードというイメージ）ただ、業務中に何か問題が起きた際には実際にコードを見たほうが解決が早いと思ってコードを見るようにしていたし(これとか)、それが前職でお世話に