oharu tech blog

記事

  • チェックが全部緑のプルリクエスト2つでmainが壊れた — GitHubのRequire branches to be up to date before mergingで防ぐ

    私はプルリクエストのチェックがすべて緑になったらマージしています。なので、自分のプルリクエストが触ってもいないテストファイルで CI が落ちたときは驚きました。 原因は私の変更ではありませんでした。別のプルリクエストがチェックをすべて通してマージされた直後に、main そのものが赤くなっていたのです。そのせいで、開いているプルリクエストはすべて自分とは関係のない理由で赤くなっていました。壊れた main の裏には、まだどのテストも実行されていない本物のバグも隠れていました。 マージされたプルリクエストのチェックは間違っていたわけではなく、古かっただけです。チェックが走ったのは、別のプルリクエストが先にマージされるより前でした。あとからマージされた側の変更が、先にマージされたプルリクエストの追加したコードを壊していました。GitHub の _Require branches to be up to date before merging_ を有効にすると、こうしたマージは新しい CI の実行を待つようになります。 本記事では、緑のプルリクエスト 2 つがどうやって赤い main…

    続きを読む

  • Vercel のデプロイメントストレージを 13.96 GB から 20.27 MB に減らす — プレビュー停止と保持期間の短縮

    Vercel の使用状況ページで、Deployment Storage に赤いリングが付いていました。無料枠 10 GB に対して 13.96 GBが使われています。他の項目はどれも上限の 20% に届いていません。 最初に気になったのは、公開中のサイトに影響が出るかどうかでした。影響はありませんでしたが、超過したままにすると代償はあります。Vercel は 30 日の保持期間を適用しなくなり、対象のデプロイを即座に削除しますし、上限を下回るまで新しいデプロイを拒否することもあります。 まず疑ったのはリポジトリでした。この記事も含めて、どの記事にも図やスクリーンショットが入っています。しかしリポジトリはパック後で 9.79 MiB、画像と動画を全部足しても 9.4 MB です。このサイトのビルド1回分は 147 MB で、それが 30 日間に 189 回作られていました。 プレビュービルドを止め、保持期間を1日に縮め、リリースフローの先頭に整理を1手入れたところ、同じグラフが 20.27 MB になりました。

    続きを読む

  • iPhone の WebKit がブログを 100% 未満まで縮小していた — overflow-wrap と表のスクロールボックスで解決

    スマートフォンで自分の記事をピンチインしたところ、本来のサイズより小さく縮んでしまいました。違和感があったので調べることにしました。 トップページではそうなりません。ピンチインしてもページはその場に留まります。どちらも同じ <meta name="viewport"> で配信しているので、原因はタグではないだろうと考えました。 WebKit は縮小方向の最小スケールをドキュメントの実際のコンテンツ幅から決めますし、iOS 10 以降は minimum-scale を無視します。つまり下限を指定する手段はありません。本当の問題は ページがスマートフォンの画面からはみ出していること でした。 解決したのは CSS のルール 2 つです。インラインコードへの overflow-wrap: anywhere と、本文の幅より広い表を囲むスクロールボックスです。あわせて、全記事をスマートフォン幅で測定するチェックも追加しました。画面からはみ出したページは公開前に落ちます。

    続きを読む

  • Trend Microがこのブログを「Disease Vector」と誤判定 — URLを特定して再分類したら解決した

    普段からTrend Microを使っているのですが、あるとき自分のブログが検索結果でグレー 表示になっているのに気づきました。いつもの安全バッジではなく、そっけない「？」 マークが付いていたのです。 緑のチェックマークが欲しかったので、Trend MicroのSite Safety Centerにドメインの再分類を申請しました。ところが返ってきた 結果は、以前よりも悪くなっていました。評価は「Dangerous」、コンテンツタイプは 「Disease Vector」です。 本記事では、その後に行った調査と、評価を最終的に「Safe」に変えた一つの変更について解説 します。

    続きを読む

  • CommonMark のフランキング規則が日本語と中国語のページに ** を出力する

    3 言語で公開した記事の日本語ページを読もうとしたところ、太字になるはずだった一文の両端にアスタリスクが並んでいました。 原因は CommonMark 側にあります。 のランが強調を閉じられるのは right-flanking のときだけです**。句点と文字に挟まれたランは left-flanking でも right-flanking でもありません。英語がこの条件に引っかからないのは、文末の句点のあとに必ず空白が入るからです。CJK にはその空白がありません。

    続きを読む

  • chrome-devtools MCP にプロジェクトごとの Chrome プロファイルを持たせる — gitignore した .mcp.json を 1 つずつ

    私のプロジェクトのうち 2 つが chrome-devtools-mcp 経由で Chrome を操作しています。このブログと、サッカーのデータを扱うアプリです。ブログ用のブラウザを開いたままもう一方のリポジトリに移り、ページを取得させたところ、返ってきたのはスクリーンショットではありませんでした。 Chrome はプロファイルディレクトリ 1 つにつきブラウザプロセスを 1 つしか許しません。そして公式プラグインは、マシン上のすべてのプロジェクトに同じディレクトリを渡します。解決策は 各リポジトリに .mcp.json を置き、それぞれ自分の --userDataDir を渡すことです。そのパスは 1 台のマシンでしか通用しない絶対パスなので、このファイルは gitignore します。 いまは 2 つのプロジェクトが同時に Chrome を操作でき、それぞれのログイン状態も保たれます。

    続きを読む

  • Markdownを出所にGitで仕様書を管理する — PDFはWeasyPrintで都度生成

    どの版の仕様書に対して実装しているのか、たびたび分からなくなっていました。文書はGoogle Driveにあってgitには写しがなく、誰かの編集が入っても手元の作業ツリーは何も変わりません。1日おいた2つのエクスポートを差分で比べたところ、見たこともない編集がコードのふるまいを変えていました。 エクスポートをコミットしても解決しません。PDFはgitが毎回まるごと保存するバイナリで、HTMLのエクスポートは行の折り返しが毎回変わります。どちらも1語の修正が文書全体の書き換えとして現れます。 そこで仕様書はMarkdownとしてリポジトリに移し、PDFはWeasyPrintで都度作るものにしました。

    続きを読む

  • Expressive Codeでコマンド出力にラベルを付ける — Gutter APIとコピーボタンの書き換え

    Claude Codeは自分のトランスクリプトで、コマンドをIN、その結果をOUTとラベル付けします。同じものをこのブログのコードブロックでも使いたくなりました。ここではBashの出力を、同じブロックの中に#コメントとして書いていました。読む分には問題ありませんが、2つの問題があります。 読者には指示と出力の区別がつきません。 どちらも#で書かれています。 コピーボタンにも区別がつきません。 貼り付けるコマンドの中に、出力の行がそのまま入っていました。 解決策は、フェンスにout={…}オプションを追加するExpressive Codeプラグインです。 使っている拡張ポイントは3つです。 ガター要素がIN/OUTのラベルを載せます。 レンダリング後の書き換えが、コピーボタンから出力を取り除きます。 詳細度の上書きが、出力行からShikiの色付けを外します。 本記事ではこの3つと、マーカーが受け付けないもの、そして私が直面した2つの障害を扱います。

    続きを読む
もっと見る