みなさんさようなら.
3/31をもってクラウドワークスを退職します. 2015/03/16入社だったので,3年くらいいました.
2/27が最終出社だったので,しばらくはスキーに行こうと思います.モーグルの板を手に入れたんだ.
続きを読む📢 #GOLANG WARNING
— Francesc (@francesc) 2018年2月7日
go-bindata creator deleted their @github account and someone else created a new account with the same name.
There's no guarantees that the new user has good intentions, so if you're using the repository make sure you verify it first!https://t.co/bOhPYRnFvV
go-bindata の作者が GitHub アカウントを削除し、他の誰かが同じ名前のアカウントと go-bindata を作成しました。
— mattn (@mattn_jp) 2018年2月8日
現時点では新しいユーザが良い意味でアカウントを作ったという保証はないのでリポジトリを使用している場合は、まず確認する様にしてください。 #golanghttps://t.co/OVtSyI1mWj
最近こういうことがあった. というわけでもしgo-bindataを使っている場合にはgo-assetsあたりに乗り換えたほうがいい.
例えば静的ファイル等を http.FileServer
で配るだけなら,最初からgo-bindataではなくgo-assetsを使っている方が多いのではないだろうか.
そうではなく,わざわざgo-bindataを使っていたのは,ファイルの中身をパースしたかったりするからなのではないだろうか?
というわけでgo-assetsを使って,go-bindataと同じようにファイルの中身をパースしてみる.
続きを読むみなさんさようなら.
仕事でも家でもAWSを使っていて,よくsshログインをしなければならない局面がある. で,高度に自動化されたAWSだと,Autoscaling Groupを使ってEC2インスタンスを自動で生み出したり,また自動で落としたりするよね. ECSを使っていても,裏側にはAutoscaling Groupを用意しておいて,インスタンスが足らなくなったら補充したりする.
で,そういうインスタンスに全てEIPを振ったり,固定のAレコードをつけたりしますか?
俺はめんどくさくてやってません(EIPはインスタンスに割り当てられてないと課金されるしね).
そうなると自然と,sshログインする際に「今どんなインスタンスが生きてるんだろー」って確認して,ターゲットのインスタンスのIPをコピーしてきてターミナルに貼り付けたりする.
めんどくさい.ああめんどくさい,めんどくさい.
この作業だけで,ブラウザを開く
-> AWSのコンソールにログインする
-> EC2インスタンスを探し出す
-> IPをコピーする
-> ターミナルに戻ってsshコマンドを組み上げる
というだけの作業をやらなきゃいけない.AWSアカウントに二段階認証をつけていたりすると,コンソールにログインするだけでめんどくさい.