同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で
GoでSQLにトレーシングコメントを埋め込んで実行する | おそらくはそれさえも平凡な日々
アプリケーションが発行するSQLにコメントが埋め込めると便利です。例えば、 /* path/to/logic.go:334 */ SELECT ... のようにSQLに発行元の情報をコメントとして埋め込んでからExecすれば、DB側のログ(general log等)にも記録されるため、SREやDREサイドからも、負荷の高いSQLがアプリケーションのどこから発行されているかが分かりやすくなります。 Goには github.com/shogo82148/go-sql-proxy という、SQL実行をトレースし、フック処理を差し込める便利なライブラリがありますが、今回それにpull requestを送って、SQL実行前にクエリの書き換えができるようにしました。 https://github.com/shogo82148/go-sql-proxy/pull/61 https://github.co
Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
smartcache ~ プリフェッチするインメモリキャッシュ | おそらくはそれさえも平凡な日々
https://github.com/Songmu/smartcache smartcacheというGoのインメモリキャッシュライブラリを書いた。 一般的に、キャッシュを実装する場合以下のような問題が起こりがちです。 キャッシュ更新時にリクエストが殺到してしまう(いわゆるThundering Herd問題) キャッシュ生成に時間がかかる場合、キャッシュ更新時に処理がブロックしてしまう smartcacheは上記の問題を以下のアプローチで解決しています。 キャッシュ更新処理を一本化する Goの場合 golang.org/x/sync/singleflight を使えば簡単! キャッシュ期限切れ前に内部的に更新処理をおこなう いわゆるプリフェッチ的な処理 使い方 コンストラクタにキャッシュの実際の有効期限、softな有効期限、そしてキャッシュ生成関数を渡します。 // コンストラクタ ca :
Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々
近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp も本質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
