haruki256.com

ローカルのHTMLをfile://で開くのをやめ、127.0.0.1で配信することにした

Thu, 30 Jul 2026 09:00:00 +0900

手元のHTMLをまとめて閲覧する仕組みを作り始めたとき、僕は「ダブルクリックで開ければ十分」と考えていました。ブラウザさえあれば使えて、サーバを起動する手間もありません。

長文記事と短い投稿を1つのHugoサイトに同居させた

Wed, 29 Jul 2026 09:00:00 +0900

作業中に気づいたことを、その場で短く書き残したいときがあります。1つの判断や、小さな修正だけなら、長文記事の構成には合いません。

別の投稿サービスへ分けるのではなく、自分のブログに「ショート」という短い投稿欄を作りました。同じサイトなら、デザインとタグを記事と共有しながら、見せ方だけを分けられます。

デザイン確認用のダミーコンテンツを、本番のビルドに混ざらない場所へ隔離した

Tue, 28 Jul 2026 09:00:00 +0900

WordPressからHugoへ移したあと、デザインを詰める段になって手が止まりました。表示するデータが入っていないと確認できない画面があるからです。

記事とショートの公開状態を、フラグではなくフォルダの場所で決めた

Mon, 27 Jul 2026 20:49:00 +0900

記事とショートの公開と未公開を、front matter（ファイルの冒頭に書く設定の並び）のフラグではなく、フォルダの場所で決めることにしました。

Flutterの入力ダイアログでは、ControllerをダイアログのStateに持たせる

Sun, 26 Jul 2026 17:00:00 +0900

結論

Flutterで TextEditingController を使う入力ダイアログを作るなら、Controllerはダイアログの State で生成し、State.dispose で破棄します。showDialog の完了後も終了アニメーション中は入力欄が残るため、呼び出し側ですぐ破棄すると、表示中の入力欄から参照されるおそれがあります。

ファイル差分だけでSQLiteキャッシュを更新すると、削除したフォルダの警告が残る

Sun, 26 Jul 2026 13:00:00 +0900

結論

JSONファイルの読み込み結果をSQLiteへキャッシュするアプリで差分更新を実装するなら、ファイルの追加・変更だけをテストして終えてはいけません。フォルダ削除は差分として検出されず、古い警告が残ることがあるため、更新対象が0件になる削除ケースもテストに含めます。

Hugoをやめる日に備えて、依存を本文・表示・ビルドの3層に分けた

Sun, 26 Jul 2026 09:00:00 +0900

WordPressからHugoへ移したとき、僕は次の移行で記事本文まで直す作業を避けたいと考えました。

記事本文は公開するたびに増えます。一方、テンプレートと設定は範囲が限られています。そこで、Hugoに依存している箇所を一覧にし、ブログを本文・表示・ビルドの3層に分けました。

フォルダ再編で、ローカルHTMLの相対リンクが切れた

Sat, 25 Jul 2026 21:00:00 +0900

手元のHTMLを分野ごとのフォルダへ整理したら、ページ間のリンクがまとめて切れました。../別分野/index.html のように、今いるファイルからの位置でリンクを書いていたためです。

ショートを、一覧の流れを残したまま共有できるURLにした

Sat, 25 Jul 2026 20:50:00 +0900

僕のブログでは、ショートを1件共有するときも、共有先は個別ページではなくショート一覧にしました。URLには一覧内の特定位置を指すアンカーが付き、該当するカードを示します。

Hugoからの乗り換えに備えて、専用処理をテンプレートと設定にまとめた

Sat, 25 Jul 2026 20:00:00 +0900

Hugoを選びましたが、将来も使い続けるとは決めていません。僕は別のツールへ移るとき、記事本文とデザインまで作り直すのは避けたいと考えました。

WordPressからHugoへ安全に切り替えた手順

Wed, 22 Jul 2026 09:00:00 +0900

haruki256.comをWordPressからHugoへ切り替えるとき、僕が重視したのは、問題が起きた場合にWordPressへ戻せることでした。

WordPressを残したままHugoへ切り替えた

Tue, 21 Jul 2026 15:40:00 +0900

haruki256.comの本番を、WordPressからHugoへ切り替えました。切り替え前にデータベースとファイル一式をバックアップし、Hugoの生成物は公開先とは別のフォルダへ展開しています。

WordPressからHugoへ移すときのURL設計

Tue, 21 Jul 2026 10:15:00 +0900

WordPressからHugoへ移すとき、最初は旧記事のURLをすべて再現できるようにしました。ただし、再現できることと、今後も公開することは別の判断です。

WordPressの旧記事13本はHugoで公開しないことにした

Mon, 20 Jul 2026 20:00:00 +0900

WordPressから取り出した旧記事は、Hugoへ移したからといって、すべて公開し直す必要はありません。

このブログでは、公開されていた7本と旧下書き6本をMarkdownで手元に残し、13本すべてを非公開にしました。以前の公開URLは記録用の legacy_url に残しますが、Hugoの公開先には使いません。

静的HTML教材の誤答結果をClaude Codeへ貼り、前提を1段ずつたどる

Tue, 14 Jul 2026 09:00:00 +0900

静的HTML教材の問題ページで正誤を出せても、誤答した項目のどの前提から確認し直すべきかまでは分かりません。僕は、採点結果に固定の学習項目IDを残し、その結果を、教材ファイルを参照できるClaude Codeの会話へ手動で貼り付ける運用にしました。

HTML教材で復習先を探すため、学習項目の前提関係をJSONで持つ

Sun, 12 Jul 2026 13:00:00 +0900

結論

HTML教材で誤答した学習項目から復習先を探すなら、学習項目同士の「先に理解する項目から、後で学ぶ項目へ」という関係をJSONで持ちます。誤答した項目のIDだけでは、その項目より先に理解しておくべき項目のどれでつまずいたかまでは分からないため、関係を逆向きにたどって復習候補を出します。

HTML教材の採点結果は、問題文ではなく学習項目IDに結び付ける

Sat, 11 Jul 2026 13:00:00 +0900

結論

ブラウザで問題を解くHTML教材を作るなら、採点結果には正誤だけでなく、問題が扱う学習項目の固定IDも残します。問題文を後から直しても同じ項目の誤答として追えるため、復習対象を文章の比較に頼らず選べます。

HTML教材の必須構成を、目視チェックリストからスクリプト検査へ移した

Sat, 11 Jul 2026 09:00:00 +0900

僕は、ソフトウェアアーキテクチャなどを学ぶための教材を、1章につき1つのHTMLページとして作っています。各章は、見出しで学ぶ内容を分け、図で関係を示し、問題で理解を確かめ、復習リンクから前の項目へ戻れる構成です。

WordPressからHugoへ移すことにした理由

Tue, 07 Jul 2026 09:00:00 +0900

haruki256.comを、WordPressからHugoへ移すことにしました。

WordPressに障害が起きたわけでも、記事を書けなくなったわけでもありません。ブログの運用方法を見直した結果、動的なCMSを維持するより、Markdownを正本にして静的ファイルを公開する形のほうが、これからの使い方に合うと判断しました。

WordPressからHugoへの移行を始めた

Mon, 06 Jul 2026 20:00:00 +0900

haruki256.comを、WordPressからHugoへ移す作業を始めました。

WordPressに大きな不具合が起きたわけではありません。記事をMarkdownで手元に置き、gitで変更を追い、公開環境では静的ファイルだけを配信する形が、これからの運用に合うと判断しました。

増えたObsidianノートを探すため、全文検索・意味検索・RAGを1つのアプリにつないだ

Wed, 01 Jul 2026 09:00:00 +0900

ObsidianへMarkdownノートをためていくと、内容は覚えていても、どの言葉で書いたかを思い出せないことがあります。検索に使う語が分かる場合と、内容しか思い出せない場合では、必要な探し方も違います。

RAGへ渡したノートが分かるよう、回答に参照ソースを表示した

Tue, 30 Jun 2026 22:35:00 +0900

僕は、検索結果を生成AIへ渡して回答を作るRAGを実装しました。質問に関連するノートの一部を、回答用の情報としてチャットモデルへ渡します。回答だけを表示すると、どのノートが候補に入ったのか分かりません。

Obsidianノートを、キーワードと内容の近さの両方で探すことにした

Tue, 30 Jun 2026 22:30:00 +0900

僕は、Obsidianに蓄積したMarkdownノートを探すデスクトップアプリを作っています。名前や用語の一致だけでなく、内容の近さからも候補を出せるように、検索方式を一つに絞りませんでした。

Obsidianで親ノートのIDを移すとき、保存前の検査と途中失敗を分ける

Thu, 14 May 2026 09:00:00 +0900

僕は、Obsidianで一つの焦点に絞った考えをZettelとして残し、ノート先頭のメタデータ（front matter）に 1、1.a、1.a.1 のようなIDを付けています。この階層型のZettel IDは、どの考えから派生したかを親子関係として表すものです。

ObsidianのZettelノートを、自分や子孫の下へ移動できないようにした

Wed, 13 May 2026 09:00:00 +0900

結論

Obsidianで一つの焦点に絞った考えをZettelとして残し、親子関係を階層IDで管理するなら、IDの移動機能では自分自身・子孫への移動を拒否します。利用者が指定した新IDが別のノートですでに使われている場合も、書き込み前に止めます。循環やIDの重複ができると、親子ツリーを一意にたどれなくなるためです。

Obsidianの階層Zettel IDを移すときは、子孫IDの対応表を先に作る

Tue, 12 May 2026 09:00:00 +0900

結論

Obsidianで階層Zettel IDを移すなら、親ノートのIDだけを書き換えず、先に子孫までの新旧ID対応表を作ります。親のIDだけを 1 から 3 に変えると、子と孫のIDが古いまま残り、親子関係がずれるためです。

Obsidianの親子ノートIDを自動採番し、子作成とツリー表示まで行うプラグイン

Mon, 11 May 2026 09:00:00 +0900

僕はObsidianのVault（ノートの保管場所）で、自分の考えを一つの焦点へ絞ったノートをZettelとして残しています。どの考えから派生したかを表すため、1、1.a、1.a.1のような階層IDを使います。

Obsidianの親子ノートIDを手作業で管理しにくくなり、自動採番プラグインを作った

Sun, 10 May 2026 09:00:00 +0900

結論

Obsidianで1、1.aのようなIDを使ってZettelの親子関係を表すなら、次の子IDを選ぶ処理と重複確認は自動化できます。人は「どの考えから派生させるか」を決め、連番の管理をプラグインに任せれば、IDを考えの親子関係だけに使えるようになります。

Obsidianで情報の役割・主題・Zettelの派生を別軸にする

Sat, 09 May 2026 09:00:00 +0900

僕はObsidianのVault（ノートの保管場所）を、自分の情報をためて整理する個人ナレッジベースとして使っています。外部資料、参照する知識、自分の考え、アイデア、計画などが一つのVaultへ増えるにつれ、役割の違うノートを管理しにくくなりました。

NDCは主題、Zettel IDは考えの派生に使う

Fri, 08 May 2026 09:00:00 +0900

結論

Obsidianで1ノート1焦点のZettelを整理するなら、僕はNDC（日本十進分類法）を参考にした分類番号を、ノートの主題に使います。1から1.aのようなZettel IDは、どの考えから派生したかという親子関係に使います。主題と考えのつながりを、一つの番号で表さないためです。

外部資料から自分の考えまでを、3つのレイヤに分ける

Thu, 07 May 2026 09:00:00 +0900

書籍や記事から得た情報をObsidianへ残すとき、要約、自分の考え、そこから作った手順を一つの読書メモへ書き足すと、そのノートが何を表しているのか判断しにくくなります。

読書の要約と、そこから生まれた自分の考えを分ける

Wed, 06 May 2026 09:00:00 +0900

結論

Obsidianで本や記事を読みながらメモするなら、要約・引用は外部資料のノートに残し、そこから生まれた自分の考えはZettel（1ノート1焦点で残す自分の考えのノート）へ分けます。出典と自分の解釈の境界を、あとからたどれるようにするためです。

ObsidianのVaultを、情報の役割ごとに構成する

Tue, 05 May 2026 09:00:00 +0900

Obsidianへ記録を増やすうちに、同じテーマの資料、事実、自分の考え、手順が同じ場所へ集まると、ノートを何に使うのか判断しにくくなりました。

ObsidianのVault直下は、情報の役割ごとに分ける

Mon, 04 May 2026 09:00:00 +0900

結論

Obsidianで複数種類の情報を同じVault（ノートの保管場所）に置くなら、Vault直下は情報の役割ごとに分けます。主題だけで分けると、同じ分野の資料と自分の考えが混ざるためです。Zettel（1ノート1焦点で残す自分の考え）は、その中の一つの役割として置きます。

お問い合わせ

Mon, 01 Jan 0001 00:00:00 +0000

記事の内容についてのご質問や、誤りのご連絡は、Xのダイレクトメッセージからお願いします。

Xで @haruki256com に連絡する

内容によっては回答までに時間がかかる場合や、回答できない場合があります。

このブログについて

Mon, 01 Jan 0001 00:00:00 +0000

haruki256.comを書いている、はるきです。

普段はソフトウェア開発に取り組みながら、個人開発や技術調査を続けています。興味を持った技術は、まず自分で試して確かめます。

プライバシーポリシー

Mon, 01 Jan 0001 00:00:00 +0000

当サイト「haruki256.com」（以下「当サイト」）における、利用者に関する情報の取り扱いについて説明します。

運営者

運営者：はるき
連絡先：お問い合わせページ

当サイトで取り扱う情報

アクセスログ

当サイトが利用するサーバーでは、IPアドレス、ブラウザーや端末に関する情報、アクセス日時、閲覧したURLなどが、アクセスログとして記録される場合があります。