SE奮闘記

Mermaid（マーメイド）記法を調査しているときの覚書。 Gemini 3 Flash Previewと対話。 １． Mermaid記法の概要 Mermaidは、テキストベースで図を描画するためのJavaScriptライブラリおよびその記法。 Diagrams as Code (DaC) 「図をコードとして扱う」という思想に基づいている。 専用の描画ソフトを使わず、使い慣れたエディタでテキストを書くだけで、フローチャート、シーケンス図、ER図、クラス図などを生成できる。 エンジニアへのメリット Git管理: テキストデータであるため図の変更履歴をGitで管理し、プルリクエストで差分（diff）を確認できる。 自動レイアウト: 線の接続や配置はMermaidが自動で行うため、ユーザーは「構造」の記述に集中できる。 高いポータビリティ: 多くのドキュメントツールやIDEで標準サポートされている。 ２． 歴史およびMarddown（マークダウン）記法との関わり Mermaidは、Markdownエコシステムの中で「図解を担当する標準パーツ」としての地位を確立してきた。 歴史  2014年にKnut Sveidqvist氏によって公開された。 2019年にJS Open Source Awardsを受賞し、エンジニアの間で「PlantUMLよりも手軽な選択肢」として急速に普及した。 Markdownとの関係 シームレスな統合: Markdownのコードブロック記法（ ```mermaid ）の中に直接記述できるのが最大の特徴。 プラットフォームの採用: 2022年にGitHubがネイティブサポートを開始したことが決定打となり、GitLab、Notion、Obsidian、Azure DevOpsなど、主要な開発プラットフォームで標準的にレンダリングされるようになった。 Docs as Codeの実現  「文書（Markdown）」と「図（Mermaid）」を同じテキストファイル内で管理できるようになったことで、ドキュメントのメンテナンス性が飛躍的に向上した。 ３． 生成AIとの親和性 Mermaidは、現代の生成AI（ChatGPT, Claude, Gemini等）と極めて相性が良い記法。 AIが得意な構造化出力: 生成AIにとって、ピクセル単位の「画...

BigQuery StudioとGitLabリポジトリを連携させれば分析作業が捗ると思って試したときの覚書。 Gemini 3 Flash Previewと対話。 参考：  リポジトリの概要  |  BigQuery  |  Google Cloud Documentation １． SSH鍵の生成 GCPのCloud Shellを開き、鍵ペアを作成。 パスフレーズなしで生成する。 $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_bigquery_gitlab -N "" 生成された公開鍵を表示。 $ cat ~/.ssh/id_rsa_bigquery_gitlab.pub ２． Gitリポジトリを作成 新規にBigQuery用リポジトリをGitLab上で作成。 アカウント全体ではなく、特定のリポジトリにのみBigQueryからのアクセスを許可する。 そのリポジトリへアクセスするための鍵を登録。 Settings -> Repository -> Deploy keysで「Add new key」。 Title: BigQuery Studio Key Key: 先ほどコピーした公開鍵の文字列 Grant write permissions to this key: チェックを入れる （SQLをBigQueryからGitLabへ保存するために必要） ３． 秘密鍵をSecret Managerに登録 Secret ManagerはGCPの機密情報を管理するためのツール。 Cloud Shell経由でSecret Managerに秘密鍵を登録する。 まずは現在の設定（選択しているプロジェクト）を確認。 $ gcloud config list Secret Manager APIを有効化。 $ gcloud services enable secretmanager.googleapis.com シークレット（入れ物）を作成。 $ gcloud secrets create gitlab-ssh-key --replication-policy="automatic" 秘密鍵の内容を登録。 $ gcloud ...

MariDBのパフォーマンス改善の資料を読んで、AIと会話しているときに「ZFSのrecordsizeをInnoDBと合わせるといい」という提案を受けたときの覚書。 Gemini 3 Flash Previewと会話。 参考サイト： Optimization and Tuning | Server | MariaDB Documentation 環境： FreeBSD 14.3-RELEASE-p10, MariaDB Server 11.8.6 １． ZFSとInnoDBの書き込み単位 InnoDB Page Size（MariaDB側）:InnoDBがデータを管理・ディスクへ読み書きする最小単位。デフォルトは 16KB。 データベースはこの16KBの「ページ」という箱の中に、実際のレコード（行）を詰め込んで管理する。 ZFS recordsize（ファイルシステム側）:ZFSがディスクに書き込む際の最大ブロックサイズ。デフォルトは 128KB 。 不一致が起きると 128KBの枠（ZFS）の中に、16KBのデータ（InnoDB）を書き込もうとすると、ZFSは 「隙間を埋めるために残りの112KBを一旦読み込み、16KBを混ぜて、再度128KBとして書き直す」 というRead-Modify-Write (RMW) という無駄な動作を強制される。 ZFSのrecordsizeを確認。 # zfs get recordsize,atime,compression /var/db/mysql NAME                PROPERTY     VALUE           SOURCE zroot/ROOT/default  recordsize   128K            default zroot/ROOT/default  atime        off        ...

AIに作ってもらったPowerShellスクリプトをどこでも実行できるようにしたときの覚書。 Gemini 3 Flash Previewと対話。 環境： Windows 11 Pro １． PowerShell プロファイルに登録 PowerShellが起動する時に自動で読み込まれる設定ファイルに、関数として登録する。 メモ帳でプロファイルを開く。 PS > notepad $PROFILE 関数を追記。 function wp-update-plugins {     & "D:\Projects\GitLab\windows-utility\wordpress\wp-update-plugins.ps1" } 保存して設定を反映させる。 PS > . $PROFILE PHPStormのターミナルで関数名を実行する。 PS > wp-update-plugins 関連記事 PowerShellでファイル名を一括で変更（連番で桁埋め） Windows11をクリーンインストール（2022年12月）

久しぶりにsvgからwoff2へ変換したときの覚書。 Gemini 3 Flash Previewと対話。 環境： FreeBSD 14.3-RELEASE-p9, Node.js v24.13.0 1. Fantasticonとは？ Gemini先生に聞いたらFantasticonをお勧めされたので調査。 GitHub - tancredi/fantasticon: Icon font generation tool · GitHub Fantasticon は、単なるコンバーターではなく、アイコンフォント構築のためのオーケストレーター（まとめ役）。 処理のステップと使用ツール SVG → SVG Font (svgicons2svgfont) 複数の SVG ファイルを読み込み、1つの巨大な XML ベースのフォントファイル（SVG Font）にまとめる。 この段階で、パスデータ（d属性）がフォントのグリフ座標系にスケーリング。 SVG Font → TTF (svg2ttf) XML形式の SVG Font を、バイナリ形式の TrueType Font (TTF) に変換。 TTF → WOFF (ttf2woff) TTF を zlib で圧縮し、WOFF 形式のヘッダを付与。 TTF → WOFF2 (wawoff2)  WebAssembly 版のコンバーターを使用して WOFF2 を生成。 なぜ FontForgeなしで変換できるのか？ かつてはSVG からフォントを作るには、FontForge のような C/C++ で書かれたデスクトップアプリを OS にインストールし、Python スクリプト経由で操作するのが一般的。 WOFF2 形式は、Google が開発した Brotli という非常に強力な圧縮アルゴリズムを使用する。 この圧縮ロジックは非常に複雑で、かつては C++ の公式リファレンス実装（google/woff2）を使うしかなかった。 Fantasticon が内部で使っているttf2woff2は、そのGoogle製の C++ コードをWebAssembly （プラットフォーム非依存のバイナリ形式）にコンパイルしたもの。 Node.jsはWebAssemblyを実行できる。 fantasticonをインストー...

WordPress標準のWP-Cron（疑似Cron）からOSのCronに切り替えようとしているときの覚書。 Gemini 3 Flash Previewと対話。 環境： FreeBSD 14.3-RELEASE-p8, WordPress 6.9.4 参考記事 WP-Cron（wp-cron.php）を無効にしてパフォーマンスを改善する方法｜ Kinsta Optimization – Advanced Administration Handbook | Developer.WordPress.org WordPress 擬似Cron（WP-Cron）が実装された背景 WordPressが擬似Cronを採用した最大の理由は、サーバー環境に依存せず、PHPだけで完結させるため。 ホスティング環境の制約 : 世界中の多種多様な共有サーバー（安価なレンタルサーバーなど）では、ユーザーがOSレベルの crontab を設定できないケースが多々ある。 ゼロ構成での動作 : インストールした瞬間に、予約投稿やアップデート確認などのバックグラウンドタスクが動作し始める必要。 ポータビリティ : サーバーの仕様を知らなくても、WordPressというアプリケーションのレイヤーだけで完結するスケジュール機構が求められた。 WordPress 擬似Cron（WP-Cron）の仕組み WP-Cronは、バHTTPリクエストをトリガーとしたイベント駆動型で動作。 擬似Cronの処理手順 リクエストの受信 : ユーザーがサイトのいずれかのページにアクセス。 実行判定 : WordPressの初期化プロセス（initフック等）の中で、前回の実行時刻を確認し、「実行すべきタスクがあるか」をDB（wp_optionsテーブル）に問い合わせる。 非同期実行（ループバック） : 実行すべきタスクがある場合、WordPressは自分自身に対してループバックHTTPリクエスト（wp-cron.phpへのPOST）を発行。 タスク処理 : wp-cron.php が独立したPHPプロセスとして起動し、予約されたタスクを順次実行。 WordPress 擬似Cron（WP-Cron）の構造的な問題点 技術的負債 オーバーヘッドとDB負荷: あらゆるページビュー（PV）のたびに、DBへの「タスク確認用S...

 PPDFの1ページ目をJPEG画像で一括出力したときの覚書。 Gemini 3 Flash Previewと対話 環境： FreeBSD 14.3-RELEASE-p8 avifencのバージョン確認。 # avifenc --version Version: 1.3.0 (dav1d [dec]:1.5.3, aom [enc/dec]:3.13.1) libyuv : available (1903) １． AVIF変換が失敗する PDFを開いて画像出力してAVIF変換してみたら下記エラー。 # find . -name "*.jpg" -print0 | xargs -0 -I {} sh -c 'f="{}"; avifenc -q 40 -s 4 -y 420 "$f" ${f%.*}.avif"' Unsupported color conversion request Cannot read input file: ./202307.jpg ImageMagfick(7.1.2-16)をインストールしてAVIF変換してみたら、その画像がWindows 11の画像アプリでは見れるけど、Chromeブラウザで閲覧できない謎現象。 ２． PDFから一括で画像出力 問題はJPEG画像にありそうなので、ツールでPDFから画像出力してみる。 pdftoppmコマンドで出来るそうなのでインストール。 # pkg install poppler-utils 試しに変換。 「-f 1」: 開始ページ 「-l 1」: 終了ページ # pdftoppm -f 1 -l 1 -jpeg "202307.pdf" "202307" avifencでavif画像変換。 # avifenc -q 40 -s 4 -y 420 202307.jpg 202307.avif Chromeブラウザでも表示できたので一括変換。 PDFから1ページ目だけJPEG画像出力。 # find . -name "*.pdf" -print0 | xargs -0 -I {} sh -c 'f="{}"; pdftoppm -f...

ウェブサイトをリニューアル前に旧サイトを保存しておく方法を調査。 Gemini 3.1 Pro Previewと対話。 環境： Windows 11, GNU Wget2 2.2.1 wgetで保存 Scoop経由でインストールしたwget2をまず試す。 PS:> cd D:\Downloads PS:> wget2 --mirror --convert-links --adjust-extension --page-requisites --no-parent --output-file="download_log.txt" "https://www.hoge.com/" Cyotek WebCopy wget2でレイアウトが崩れる場合は、「Cyotek WebCopy」を試す。 参考：  Cyotek WebCopy - Copy websites locally for offline browsing • Cyotek スクリーンショットを手動で取得 ブラウザの標準機能を使う。 Chrome: DevToolsで「Capture full size screenshot」。 Firefox: 右クリックで「スクリーンショットを撮影」。 もう少ししたら自律型AIエージェントで出来るようになる気がする。

WordPressのcronジョブに関して調査しているときの覚書。 Gemini 3.1 Flash Liteと対話。 環境： PHP 8.3.29, WordPress 6.9.1 wp cronコマンド一覧 現在予約されているタスク（cronイベント）を表示。 $ wp cron event list 即時実行（詰まっているタスクの消化）。 $ wp cron event run --due-now 特定のフックだけを指定して実行（実行予定時刻が過ぎている場合のみ）。 $ wp cron event run (フック名) 特定のフックだけを指定して実行（実行予定時刻に関係なく今すぐ実行）。 $ wp cron hook run (フック名) 実行スケジュールの削除。 $ wp cron event delete (フック名) ▼ 関連記事 WP-CLIのwp core updateがobject-cache.phpを置くと出来なくなる WP-CLIをInstallしてWordPressのVersion管理

WordPressのWP-CLIを使ってwp core updateをしても更新しなくなったので調査したときの覚書。 Gemini 3.1 Pro Previewと対話。 環境： FreeBSD 14.3-RELEASE-p8, php 8.3.29 wp-cliのバージョン確認。 # wp cli version WP-CLI 2.12.0 １． object-cache.phpがあると失敗する理由 WP-CLI環境ではAPCuキャッシュが使えないため、せっかく取得した最新のアップデート情報がなってしまう。 wp core updateしたときの挙動 WP-CLIが起動すると、object-cache.php が存在するため、WordPressは「アップデート情報をデータベースではなく、APCu(APC User Cache)に保存するモード」に切り替わる。 WP-CLIが WordPress.org のAPIに問い合わせて「新バージョンがある」という情報を取得。 取得した情報をAPCuに保存しようとするが、CLI環境のAPCuは無効化されているため、コマンド終了と同時にメモリごと消滅。 結果として、「新バージョンがある」という情報がDBにも保存されず、メモリ上からも消え去るため、何度 wp core update を実行しても「アップデート情報がない＝すでに最新版である」と誤認し続けてしまう。 ２．開発環境ではCLI環境でもAPCuは有効化 object-cache.phpが存在すれば、WordPressはAPCuモードになるため、設定で対応する。 iniファイル確認。 # php --ini Configuration File (php.ini) Path: /usr/local/etc Loaded Configuration File:         /usr/local/etc/php.ini Scan for additional .ini files in: /usr/local/etc/php Additional .ini files parsed:      /usr/local/etc/php/ext-10-opcache...