投稿短歌カレンダー

短歌、いま流行ってるそうです。電源もWi-Fiも歳時記もいらない、趣味としては最高にポータブルな部類でしょう。

現代ではウェブで短歌の投稿を受けつけているメディアもたくさんあって、はがきを送るようなことをしなくてもよいのはデジタルネイティブにもうけますね。また、投稿から掲載までのレイテンシが一ヶ月単位で生じるため、SNS などでインスタントな反応を求めがちな心を調律することもできます。

こういったフォームのそれぞれに題と〆切とがあるわけですが、これらを管理するのが面倒なので、ical 形式でカレンダーにインポートできるものを作りました。

投稿短歌カレンダー

https://tanka-form-calendar.motemen.workers.dev/calendar.ics という URL で配ってるので、これをカレンダーアプリなどから登録するとよいです。

現在対応しているのは以下のメディア。

• 短歌ください
• うたらば
• NHK短歌

ほかに対応すべきものがあれば教えてください。

技術的な話

デプロイは Cloudflare Workers。Node で VCR 的なことをする定番が分からなかったんだけど、今回は Polly.JS を使ってみた。Jest での利用も非常に簡単だったけど、あまり日本語の情報を見かけない気がする。別のものが流行ってるのかな？

定期的な更新には Cloudflare の Cron Triggers を使うわけだけど、エラーが起きた場合の通知やログがないので、モニタリングが難しいなー。ここは現状答えを持ってない。

GitHub - motemen/tanka-form-calendar

ぼくの短歌ノート (講談社文庫)

天才による凡人のための短歌教室

ISUCON12予選敗戦記（からあげネイティブ、3899点）

今回のISUCON12は惨敗だったのであまり記憶も残ってない……。

songmu、toricls、motemen のメンバーでの挑戦も3度目となり、いよいよ優勝したい、そのために当然予選突破はしたい、という年だった。

今回も自分が構築、他の2人が作戦と実装、という役割分担。これはまあ、一年に一度の頻度でしかやってないなりに経験値がたまってきた。予選前にはきちんと予習をした年でもあって、そのおかげで初期構築はかなりスムーズにいったはず。1時間もせずにデプロイと計測ができる状態になったのは進歩だった。あとここ2回まともにやってなかった pprof に出番があったのもよかった。

今回の鬼門はやはり SQLite で、これをどうするか……というところで方針を強く決められなかったな～。

慣れてるし取り扱いやすい MySQL に移行するか、SQLite のまま進めてみるか、というところで複線で進めてしまって、MySQL 移行にチームの全力を注ぐことができなかったのがまずかった。たぶんどちらの方法でも予選突破は可能なのだと思うけど、SQLite のデータがかなりでかい、となったときに MySQL 運用の知識でサポートするみたいな動きが能力的にも思考的にも取れなかったのが根本的には敗因。

あとプロファイルを取るのは当然として、データの性質をちゃんと読み取ることができていないと打つ施策に意味がなくなってしまう。これ毎回思うんだけど、なかなか決まった時間のなかでやりきることができない。SQLite を MySQL 化するときに flock を愚直に消してしまって整合性が取れなくなり、そりゃそうかとなる、みたいな経験がしばしばある。

あとはやったことを羅列しておくぜ！

• alp, pt-query-digest, pprof を順に取って、取ってる間にソースを見てうーんこれ SQLite どうしようかってなったところからスタート。
• docker-compose は剥がさなかった。
• テナントの頭文字でアプリケーションサーバ分けたりするかな～と思ってnginxの設定書いてみたがとくに使わず。
• visit_history を Redis 化。
• ランキングの N+1 除去。

手元構築可能になったら復習して、来年も優勝狙うぞ～。一年間この不完全燃焼で暮らすの嫌なので、社内 ISUCON や野良 ISUCON があったら招待してください。

GitHub - motemen/isucon12-qualifier

Chrome 拡張のポップアップが表示されるタイミングは onload っぽい

Chrome 拡張のポップアップがどのタイミングで表示されるのか、ちょっとググった限りでは分からなかったので調べた。 掲題の通りで、結論としてはまあそりゃそうだ、とはなるが、ポップアップ内で img や iframe により外部リソースを読み込んでるようなときは、すべてがロードし終わるまでユーザへの反応が何もなくなるので注意が必要そう。

ポイントになりそうなのは ExtensionPopup::DocumentOnLoadCompletedInPrimaryMainFrame で、これはコールバックとして呼ばれるっぽい。

// This method is invoked once the onload handler of the primary main frame's current document (i.e., |render_frame_host|) has completed. This happens when the primary main document has finished running onload events after loading all content (images, scripts, etc).

結果はシンプルだけど、ここに至るまでにいくらか読んで回った。Chromium のソースコードを読んだのは初めてだったけど、Chromium Code Search がよくできてて助かった。さすがにこれだけコードベースがでかいと、こういうツールも普通に必要になるわけだ。

---

検証用のリポジトリも一応作った。https://httpbin.org/delay/{delay} という遅れてレスポンスを返す便利エンドポイントがあるので、これを iframe で埋め込んでみている。await chrome.tabs.query や setTimeout を挟むと

GitHub - motemen/experiment-webext-popup-timing

20分でつくるChrome拡張 に刺激されて Chrome 拡張を爆速で作る方法を求めている。今回は Chrome だけじゃなくて webextension として対応したいなーと思って @samrum/vite-plugin-web-extension を使ってみたけど、Manifest Version 3 をターゲットにしたら結局 Firefox では見られなかった。Chrome による MV3 移行圧力とその他のブラウザのサポート具合がぜんぜん違って戸惑うな～。