Go において、いわゆる SSRF (Server Side Request Forgery) を防ぐような目的で、内部 IP アドレスにアクセスしない HTTP クライアントを作るには hakobe/paranoidhttp が便利だった。ただ、近年ではこれが作られて以降の Go 側のアップデートとして、net.Dialer.Control の登場がある（Go 1.11 より）。 type Dialer struct { ... // If Control is not nil, it is called after creating the network // connection but before actually dialing. // // Network and address parameters passed to Control method are not //

この記事は、はてなエンジニア Advent Calendar 2020の21日目です。昨日は id:tarao による Scalaの依存ライブラリ更新はRenovateでもけっこうイケる でした。明日は id:Krouton です。 みなさん在宅勤務してますか？ 私もしています。 仕事も雑談も、とにかくオンラインで話すことが多いので在宅勤務中は AfterShokz という骨伝導ヘッドホンを使っている。ずっと装着してても疲れにくいので、大変いい買い物です。 いちいち外すのも面倒なのでほとんど一日中付けっぱなしにしているんだけど、これが事故を呼ぶこともある。マイクをオフにすることを忘れて離席してしまうと、オフのときの会話が筒抜けになってしまうので、同僚の前ではおとなしいのに家族の前では豹変するとか……。あとおしっこしてる音が聞こえちゃってないとか。気になりますよね。油断できない。 そういうわ

前回のエントリで作った Docker イメージ motemen/datastore-emulator は、google/cloud-sdk をベースにしているが、このベースイメージがけっこうな頻度で更新される。とうぜん自分はその追従に手を煩わせる気はなくて、全部自動でやってほしい。 やりたかったこと google/cloud-sdk:x.y.z がリリースされたら、 リポジトリ中の ./Dockerfile と ./alpine/Dockerfile の FROM を google/cloud-sdk:x.y.z(-alpine) に更新し、 x.y.z タグを打って git push することで、 Docker Hub に x.y.z(-alpine) タグとしてリリースする これを自動かつ無料で実現したい。 採用しなかった案: 自分でなんか作る はじめは適当な GitHub Actio

複数のサーバが関わっている環境では、ホストに人間が分かる名前を関連付けなければ運用がスケールしなくなるものです。その名前はホスト名だったり、ロールやタグのようなものだったりすると思いますが、仮にホスト名を利用するなら、DNS を用いて名前とホスト（の IP アドレス）の対応をつけるようなこともできるでしょう。DNS が利用できない場合は、/etc/hosts に書くというようなのもありですね。 しかしホスト名を直接利用した運用というのは意外と難儀なところがあって、とくに自分のように普段サーバを扱った作業をあまりしないアプリケーションエンジニアなどは、「前に接続したことあるあのホストは何だっけ……」といううろ覚え状態に弱い。名前の一部は覚えているわけなので、シェルの履歴を検索すればなんとかなるのですが、一度も接続したことがなければ目当てのホストを探し出すことはできません（この、接続したことが

最近は仕事でも新しくGoのプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール（golint とか gobump とか）であったりのインストールをどうするかという話。 npm であれば devDepende

おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基本的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを Mackerel や Slack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も

いろいろあって、本戦からだいぶ時間が経ってしまいました。チーム全体としての流れはSongmuさんが書いてくれているので、自分の視点でどうだったかな〜というのを時系列を無視して思い出しつつ書きます。 チームは、会社（はてな）の同僚で組んだ Songmu, masayoshi, motemen の3人。全員の名前からとって「ソン（ムー）・モテメン・マサヨシ」です。おしゃれ。リポジトリはここ。 本戦の問題は Cookie Clicker をモデルにしたもの。競技の開始まですこし時間の余裕があったので、その間にオリジナルをプレイして、アプリケーションの仕様を学習した。話題になったときに遊んでなかったので、このとき初めてやったんだけど、たしかに中毒性がありそう……。 Cookie Clicker のほうは放置しつつ方針の相談。まあルームごとにサーバを割り当てて、オンメモリでやってく感じだよね、という