はてなブックマーク

はじめに kubernetes の ConfigMap/Secret を Pod に Volume としてマウントしている場合、ConfigMap/Secret を修正すると Pod の Volume に自動的に反映される事は良く知られている。 しかし、その反映に 1 分以上かかる事はあまり知られていないのではないだろうか？[1] すみません、ちょっとだけ（？）盛りました。必ず 1 分以上かかるわけでは無く、運が良ければ 1 分切る事もある。が、運が悪いと 1 分半かかることもある。 と言うわけで、まずは実際反映に 1 分以上かかったりすることを確認するちょっとした実験を行い、その後遅い理由を解説する。また、併せて簡単な対処方法も紹介したいと思う。 ホントにそんなに遅いの？ 遅いことを確認するために以下のようなマニフェストを用意する。 apiVersion: v1 kind: Config

はじめに 今やあらゆるアプリケーションは Go で書かれていると言っても過言ではない（過言）。そして、今やあらゆるデータは json であると言っても過言ではない（過言）。 となると、Go で json を扱う頻度も必然的に多くなる。そして初めて Go で json をデコードするコードを書こうとした人は、必ずこの問題にぶち当たる。 「json.Unmarshal と json.Decoder は何が違うのか？そしてどちらを使えばいいのか？」 そしてググると大抵以下のような答えにたどり着く。 入力が文字列（string）やバイト列（[]byte）の場合は json.Unmarshal() を使う 入力がストリーム（io.Reader）の場合は json.Decoder を使う なるほど、確かにパッと見はそれでいいように思える。思えるんだが、よく見ると実は他にもいくつか考慮すべき点がある。

概要 タイトルのまんま。以上。 ちょっと説明 とは言え、それだけではあんまりなので軽く説明をば。 JavaScript に fetch と言うメソッドがあるのは皆さんご存知の通りだが（Web ブラウザ環境の場合だが）、コイツは任意のリクエストボディを送ることが出来る。 で、任意と言うからには multipart/form-data 形式のリクエストボディも送ることが出来るのだが、その場合には⇓のようにリクエストボディとして FormData のインスタンスを渡す必要がある。 # 例 1 : 正しいやり方 const body = new FormData() body.append('data1', 'value1') body.append('data2', 'value2') const response = fetch('/path', { method: 'POST', body,

概要 AWS とかで踏み台ホスト経由（ここでは AWS っぽく bastion と呼ぶ）で ssh する必要があるなら ~/.ssh/config は↓みたいにしとくのが良いんじゃないかな？ Host bastion Hostname bastionのIPアドレス User bastionのユーザ名 # ↓は規定のファイルだったり ssh-agent 使ってれば不要 IdentityFile bastion接続用の秘密鍵ファイル名 # ↓の3つはWindowsでは使えないので諦めて ControlMaster auto ControlPath ~/.ssh/cp-%r@%h:%p ControlPersist 10m Host 好きな接続先名 Hostname 接続先のIPアドレス User 接続先のユーザ名 # ↓は規定のファイルだったり ssh-agent 使ってれば不要 Identi

なお、よく「ダイグラフ」と呼ばれたりもするが、見ての通りキーワード型の物も結構あるし、キーワード型を除いたとしても必ずしも「ダイ」（2文字）ではない（%:%:）。 ちゃんと「代替トークン」（あるいは「オルタナティブトークン」）と呼んであげよう。 ちなみにこれらの名前も予約語なので、例えば and や or と言った関数名や変数名は使えない。 and って言う関数書こうとしたら何故かエラーが出た的な話を稀に聞くが、まさにコイツらの仕業である。 なお、「トークン」と名前がついている通り、コンパイラがソースをトークン化する際に処理されるので、文字列中や他の識別子中では代替トークンとはみなされない。 まぁ当たり前っちゃあ当たり前なんだが… 使用例（その１） さっそく使用例を見ていこうと思う。 使用前 #include <iostream> int main() { int a[] = { 114,

何だと！？ タイトルのまんま。 恥ずかしながらこれ今まで知らなかった。 もしかして常識だったりする？ ちなみに確認したのは Linux だけど、glibc の posix サブディレクトリ配下の execl*execvpe の挙動なので glibc 使ってればみんな一緒じゃないかな？知らんけど… 環境変数 PATH が設定されていない時 unset PATH とした状態。 この場合、PATH=/bin:/usr/bin と設定されているのと同じ意味になる（追記も参照のこと）。 当然カレントディレクトリは含まれていない。 環境変数 PATH が空の時 PATH= とした状態。 「PATH 環境変数が設定されていない時」とは異なる事に注意。 この場合、PATH=. と設定されているのと同じ意味になる。 つまり、カレントディレクトリが含まれている。 環境変数 PATH の最後が : で終わってい