SE奮闘記

秘密分散を調査しているときの覚書。 Gemini 3 Flash Previewと対話。 １．秘密分散とは？ 秘密分散は機密情報を複数の断片に分割して管理する技術。 各断片だけでは情報が足りないため、数学的に復元不能。 閾値を超えれば復元可能。つまり一部を失くしても復元可能。 量子コンピュータであっても閾値を超えない限り復元不能（ 計算能力に関係なく安全 ）なため、近年注目されている。 参考：  秘密分散 - Wikipedia ２． 秘密分散 vs 公開鍵暗号方式 公開鍵暗号は「 通信や署名 」のための技術であり、秘密分散は「 権限の分散と保存 」のための技術。 比較項目 公開鍵暗号方式 (RSA, ECDSA 等 ) 秘密分散 (SSS 等 ) 主な目的 安全な通信、身元証明（署名） データの安全な保管、単一障害点の排除 セキュリティの根拠 計算量的安全性 （数学的問題を解くのに膨大な時間がかかること） 情報論的安全性 （数学的に「情報が足りない」ため解読不能） 鍵の管理 秘密鍵を 1 箇所で厳重に 守る必要がある 秘密をバラバラにして 複数箇所で 守る 単一障害点 (SPOF) 秘密鍵を盗まれたら終わり、失くしたら復旧不能 一部の断片が盗まれても安全、一部を失くしても復元可能 計算負荷 比較的高い （特に大きなデータの暗号化） 低い （多項式計算のみ） ※ ただしデータ量による 量子耐性 既存の方式は量子コンピュータに弱い 量子耐性がある （計算能力に関係なく安全） 公開鍵暗号と秘密分散は組み合わせて使われる。 分かりやすい例え。 公開鍵暗号： 「ドアに鍵をかける」技術。 秘密分散： 「鍵そのものをバラバラにして信頼できる人たちに預ける」技術。 公開鍵暗号方式の簡単なおさらい 公開鍵暗号の凄いところは、Aさんの公開鍵...

開発環境でNginxを再ビルドしたときの覚書。 Gemini 3 Flash Previewと対話。 環境： FreeBSD 14.4-RELEASE-p3 下記エラー。 # cd /usr/ports/ # git pull # cd /usr/ports/www/nginx/ # make rmconfig-recursive make: "/usr/ports/Mk/Uses/ssl.mk" line 98: You are using an unsupported SSL provider openssl-quictls make: stopped in /usr/ports/www/nginx Gemini先生が教えてくれたコマンドで確認してみる。 #  make -d v rmconfig-recursive 2>&1 | grep -B 10 "SSL_DEFAULT = openssl-quictls" Result of ${.MAKE.EXPORTED:O} is "LANG LC_ALL META_MODE" Evaluating modifier ${.MAKE.EXPORTED:u} on value "LANG LC_ALL META_MODE" Result of ${.MAKE.EXPORTED:u} is "LANG LC_ALL META_MODE" Global: OPENSSL_INSTALLED = security/openssl-quictls Var_Parse: y(OPENSSL_INSTALLED) (eval) Global: SSL_DEFAULT = # (empty) Var_Parse: ${OPENSSL_INSTALLED:T} (eval-keep-dollar-and-undefined) Evaluating modifier ${OPENSSL_INSTALLED:T} on value "security/openssl-quictls" (eval-keep-dollar-and-undefined, regular) ModifyWords: split...

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        ...