GDPR の関連で、特に海外のページにアクセスすると「お前のブラウザの cookie 使うけどええか？」というポップアップ来るけど勝手に使ってくれ…という気持ちになる。
同じように考えている人は多いようで、 I don't care about cookies 3.4.5 というブラウザ拡張機能が存在している様子。試しに使ってみたけど、一部のサイトではうまく動かなかった。
実装が気になって見てみると、サイトごとにルールが列挙されていて、このサイトはDOMを隠す、このサイトは Cookie に値をセットする… みたいなことが書かれていた。そしてこのリストに追加したい場合は、リクエストを送ると追加される(可能性がある)世界観のよう。
I-Dont-Care-About-Cookies/rules.js at master · appeasementPolitik/I-Dont-Care-About-Cookies · GitHub
サイトによって実装はバラバラなのでこうするしかないよな〜と思いつつも、なかなかワイルドで面白い。
Qrio Lock を1年半くらい使っていたんだけど、リモート解錠の精度が悪くて機能しなかったり、解錠がシンプルに遅くて最悪10秒くらいかかったりしてイライラしていた。Amazon 見てたら、SwitchBot スマートロック + 指紋認証パッドが Qrio 単体より安いことに気づいてしまったので買ってみた。
逆に Qrio にいい点があるか…というと正直デザインに高級感があるくらいしか思いつかない。あとは電池持ちが悪いという話もあるけどそこはもう少し使ってみないとわからない、という感じ。
複合キーを貼っている以下のようなテーブルで、index が効かなくてクエリがめちゃ重くなる現象が発生してしまった。
CREATE TABLE `example` ( `id` BIGINT UNSIGNED NOT NULL, `column1` BIGINT UNSIGNED NOT NULL, `column2` BIGINT UNSIGNED NOT NULL, `column3` VARCHAR(36) NOT NULL, PRIMARY KEY (`id`), INDEX `index1` (column1, column2), INDEX `index2` (column1, column3) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
実際に発行したクエリは以下のような感じ。
SELECT * FROM example WHERE column1 = 1 AND (column2 = 1 OR column3 = "hoge");
OR 使ってるので index 効かないのはそれはそうという感じなんだけど、explain 結果を見た時possible_keys, key に index 名が入っているので効いてるじゃんと思ってしまった。
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | example | ref | index1,index2 | index1 | 8 | const | 2 | 75 | Using where |
しかし、key_len が 8 になっているので、これははちゃんと複合 index が効いていない状態。ちゃんと効いてるのであれば、key_len は BIGINT の 8byte *2 = 16 または BIGINT + VARCHAR(36) の 146 = 154 *1 になるはず。実際に index が効くようにクエリを発行すると、そのような結果になる。
index1 が効くクエリ
EXPLAIN SELECT * FROM example
WHERE column1 = 1
AND column2 = 1;
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | example | ref | index1,index2 | index1 | 16 | const,const | 2 | 100 |
index2 が効くクエリ
EXPLAIN SELECT * FROM example
WHERE column1 = 1
AND column3 = "hoge";
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | example | ref | index1,index2 | index2 | 154 | const,const | 1 | 100 |
結局上記のようにクエリを2つに分割することで解決した。
key_len がおかしければ複合 index が効いてないことがわかるので、explain するときは key_len をちゃんと見ましょうという教訓。
そしてこれらのクエリを試すために SQL の Playground であるところの DB Fiddle 使ったけど手元に環境を用意する必要がなくて便利。Makdown で出力できる機能もあるので、ブログとかに貼りやすくて助かる。 https://www.db-fiddle.com/f/4yd3igqfkESZBG6dtT85hL/0
*1:VARCHAR の byte 数は最大長。utf8mb4 なので 36 * 4 byte に加えて、さらに varstring だとさらに2バイト常に確保される様子
削除したファイルが 1 つ 2 つだったら使われているかどうかを調べるために素朴に grep すればいいんだけど、大量にあるときつい。ので手軽に調べられるワンライナーを書いてみた。
git log <commit_hash>...<commit_hash> --diff-filter=D --name-only --oneline | grep -Eo '[^/]+$' | xargs -I arg git grep arg
細かく解説すると以下のような動き
git log <commit_hash>...<commit_hash> --diff-filter=D --name-only --oneline でコミット間で削除されたファイルの一覧を出すgrep -Eo '[^/]+$' でファイル名のみを取り出すxargs -I arg git grep arg でファイル名ごとに git grepgit grep しまくるのでファイル数が増えるとかかる時間が指数関数的に増加していくけど、手元で試したかぎりは300ファイルくらいならまぁめちゃくちゃ時間がかかるという感じでもなかった。(コードの規模にもよるけど…)
ポストを開ける習慣が無いので、役所とかから重要な郵便物が届いても放置してしまい困ることがたまにある。開ける習慣をつければいい話ではあるけど怠惰なので技術で解決したい。
SwitchBot 開閉センサーを使うとポストの開け閉めを検知できてよさそうと思って試してみた。ちょうど余ってる SwitchBot Hub もあったのでちょうど良かった。 www.amazon.co.jp
こんな感じにポストの開閉部に貼り付ける。
SwitchBot Hub は最初室内に置いてたけど、bluetooth の電波が届かず通信できなかったので無理やり外に設置した。屋内用なので多分そのうち雨風にさらされてぶっ壊れる気がするが、細かいことは気にしない。
無事通知が来てまた一つ怠惰な人間になれた。
Google Meet だと自分のWebカメラの映像が反転していまっていて困る。 何に困るかっていうと、最近背後に時計を置いてるんだけど、自分の画面だと反転していて何時かパット見わからない。
Zoom とかだと設定で変えられる機能があるみたいだけど、Meet は特になさそう。
開発者ツールで HTML を見てみると、なんと自分の映像を表示している video タグに -webkit-transform: scaleX(-1) が仕込まれていて、css で反転させていることがわかった。
ので Stylish で css を上書きして事なきを得た。 どうやら css で反転しているのは自分の動画だけなので、乱暴に video タグ全部上書きしている。
@-moz-document domain("meet.google.com") {
video {
-webkit-transform: scaleX(1) !important;
}
}
時計がみれて嬉しいけど、どういう意図でわざわざ css で反転しているのかは気になる。
鏡のように反転してるほうが直感的、という話を聞いてなるほどな〜と思った。個人的には相手から見えている画像をそのまま表示してもらったほうが嬉しいが…
Next.js のサーバの前段のCDNに Cache-Control ヘッダーを返したいので設定してみた。
公式ドキュメントでは、getServersideProps 内部で res.setHeader('Cache-Control', 'hogehoge') すればよいと書いてあるが、なぜか反映されなくてハマっていた。
https://nextjs.org/docs/going-to-production#caching
よく見ると
Note: When running your application locally with next dev, your headers are overwritten to prevent caching locally.
と書かれていて, next dev だと設定していてもデフォルトの Cache-Control ヘッダーで上書きされる様子だった。
next start したら普通に出てきた。単純なハマり。