小さなアーカイブのための静的ウェブサイト活用
(alexwlchan.net)- ローカルに蓄積した文書・スクリーンショット・ブックマーク・メディアを後で見つけ直すため、小さなコレクションごとに静的ウェブサイトを付けて閲覧する
- 各コレクションはディスク上のフォルダとして残し、ルートのHTMLファイルをブラウザで開くことで、Finderより豊富なメタデータと整理方法を提供する
- Webサーバー・ビルドシステム・依存関係・JavaScriptフレームワークなしで手書きし、各サイトは多くても数百行のコード程度なので小さなプロジェクトに向いている
- 既存のフォルダ階層、Finderタグ、「everything bucket」アプリ、自作ツールには、それぞれ階層の強制・実装上の限界・アプリの考え方への適応・保守負担があった
- 手作業の整理には時間がかかるが、保存する価値のあるファイルだけを選ぶようになり、HTMLの単純さは長期保存に有利である
ローカルアーカイブをミニウェブサイトとして見る
- コレクションごとに静的ウェブサイトを作り、ローカルアーカイブを閲覧する
- スキャンした書類
- 自分で作成した文書
- 撮っておいたスクリーンショット
- 保存したWebページのブックマーク
- 保存した動画・音声ファイル
- ファイルの性質に合わせて、コレクションごとに異なる画面を用意する
- スクリーンショットのコレクションは画像グリッドで表示する
- ブックマークはテキストリンクの一覧として見せる
- 動画はサムネイルとテキストが混在した一覧として整理する
- 目的は複雑なシステムではなく、macOS Finderより少し優れたファイル閲覧インターフェースを作ること
- ページにより多くのメタデータを入れられる
- 自作の検索・整理方法を使える
構成方法と技術選択
- 各コレクションはローカルディスク上の1つのフォルダで、ウェブサイトはそのフォルダのルートにある1つ以上のHTMLファイルである
- 使うときはHTMLファイルをWebブラウザで直接開く
- 意図的に小規模かつ低い技術レベルを保つ
- Webサーバーなし
- ビルドシステムなし
- 依存関係なし
- JavaScriptフレームワークなし
- すべて手作業で書くが、小さなプロジェクトでは管理可能である
- 各ウェブサイトは多くても数百行のコード程度である
- ディスク上のファイルとHTMLだけで構成されており、長く続く可能性が高いと考えている
- フォルダファイル構造の単純さと移植性を保つ
- その上に必要な機能だけを少し追加する
以前の方法が長続きしなかった理由
- 普通のファイル・フォルダ方式は階層構造を強制し、すべてのファイルが正確に1か所に置かれていなければならない
- コードのような一部のデータにはよく合う
- メディアファイルでは満足のいく階層を設計するのが難しかった
- どのフォルダに入れるか迷っているうちに、デスクトップが整理されない状態になった
- キーワードタグ付けは、1つのファイルに複数のラベルを付け、複数の方法で見つけ直せるため、より好ましい
- macOS Finderもタグをサポートしているが、実装が十分ではなく、重要な用途には使いたくなかった
- DEVONThink、Evernote、Yojimboのような「everything bucket」アプリも合わなかった
- アプリのやり方に合わせて考え方を変えなければならないように感じた
- 自作のファイル整理ツールも少なくとも12回ほど試し、最後の試みの1つがdocstoreだった
- 自分の思考にはより合っていたが、保守負担が生じた
- PythonのアップグレードやmacOSアップデートのたびに何かが壊れ、コードを直す必要があった
フォルダをミニウェブサイトに変える方法
- 最上位フォルダにインデックス役のHTMLファイルを置けば、すべてのファイルを望むメタデータとタグで表示できる
- この方法はフォルダ構造を単純化し、完璧な階層を探さなければならない負担を減らす
- ファイルは通常、年別またはファイル名の先頭文字別にだけまとめる
- フォルダは新しいファイルを追加するときだけ見て、閲覧には使わない
- ファイルを探すときは常にウェブサイトを使う
- ウェブサイトはキーワードタグによってファイルを複数の方法で見つけられるようにし、実際のフォルダ構造の詳細を隠す
- HTMLは保守が少なく柔軟で、消える可能性が低い技術として選ばれている
- Webの基盤技術である
- ほぼすべての現代的なコンピュータにはHTMLページをレンダリングできるブラウザがある
- 2006年に作った学校の授業用の最初のウェブサイトも、現代のブラウザで問題なくレンダリングされる
「小さな」アーカイブに向いている理由
- ファイル整理、メタデータ作成、ビューア制作のかなりの部分を手作業で行うため、大きなコレクションにはうまくスケールしない
- 数百個の項目を保存するだけでも少なからず時間がかかるが、この摩擦が保存対象を選ぶ助けになる
- きちんと整理する価値があるか判断するようになる
- 1分すらかけて保存したくないファイルを、再び見る可能性があるのかと問うようになる
- 保存すると決めたファイルには、後で見つけやすいようメタデータをより丁寧に書くようになる
- 以前は数千個のファイルが大きく曖昧なフォルダに溜まり、きちんと整理されていなかったため見返さなくなっていた
- 今は数百個の項目を含む小さなウェブサイトが複数あり、項目はより慎重に選ばれ、有用に説明されている
- 自動化が好きであっても、より手作業寄りのプロセスがもたらす制約を前向きに受け入れている
保存ツールとしての静的ウェブサイト
- この方法の着想はTwitterアカウントのエクスポートから来ている
- Twitterアカウントのエクスポートは、ローカルで閲覧できるミニウェブサイトを提供する
- 複数のソーシャルメディアプラットフォームも、データを人間が見やすく閲覧できるウェブサイト形式で提供している
- 静的ウェブサイトは、born-digitalアーカイブを扱うデジタル保存の方法としても有用になり得る
- 単純さ、長期性、低い保守性は、数十年あるいは数百年の保存を目標とする記憶機関においてさらに価値がある
- 基本的なメモ帳やテキストエディタだけでも、基本的なHTMLウェブサイトを作れる
- Data Lifeboat projectでは、Flickrのアーカイブの一部をパッケージ化する方法として、より大きな静的ウェブサイトを作っている
- ローカルアーカイブは通常リストビューに近いが、Data Lifeboat内のウェブサイトはより多くのページと機能を持つ
- Ed SummersによるHistorypin保存のための静的サイトに関する投稿も同じ方向性の事例である
段階的な移行とHTMLの個人的な用途
- すでにディスク全体に散らばっているファイルが多いため、すべてを一度に移すのは作業量が大きい
- 新しいファイルは静的ウェブサイトに保存し、古いファイルは見つけるたびに既存の保存場所から取り出して、適切な静的サイトのフォルダへ移す
- 初期のサイト構造を作った後は、動作を維持するための保守負担はほとんどなかった
- 初めてウェブサイトを作ってみたい人には、Blake WatsonのHTML for Peopleがおすすめされている
- 「望むなら誰でもHTMLでウェブサイトを作れるべきだ」という哲学を含んでいる
- HTMLは長い間、他人が見るウェブサイトを公開するための道具だと考えていたが、ローカルの個人アーカイブにも使える
- 2025年2月19日の更新で、コードの詳細を説明する続編記事How I create static websites for tiny archivesが追加された
1件のコメント
Hacker Newsのコメント
クリップボードの画像をコピーして HTMLファイルに保存し、単一ファイルのギャラリーとして使う
https://gist.github.com/egeozcan/b27e11a7e776972d18603222fa5...
ライブ例: https://gistpreview.github.io/?b27e11a7e776972d18603222fa523...
ファイルピッカーで選ぶのも動作するが、ドラッグはたいていうまくいかない。正しく動作すれば、画像はblobとしてドキュメント内にインライン挿入される
画像を追加したあとページをそのまま保存、つまりfile->saveを押すと、blobも一緒に保存される。保存前に一部を外したい場合、たとえば画像を削除したい場合は、要素の検証を開いて削除してからページを保存すればよい
このファイルはサーバーにアップロードしてもよいし、PCやモバイルでダブルクリックして開いてもよい
https://github.com/cadars/john-doeも似た雰囲気がある
手早いプロトタイプ: https://gistpreview.github.io/?14a2c3ef508839f26377707dbf5dd... - コード: https://gist.github.com/simonw/14a2c3ef508839f26377707dbf5dd...
コメントではMarkdownの話が多いが、自分もそれに一票。プレーンテキストが最高だ。自分のデータ収集と保管についてよく考えるが、プレーンテキストはその中核で、将来互換性が非常に高い
WordPerfect以降は、より決定的で軽く書式を入れられ、書式文字を直接見られる文書を好んできた。Markdownは素晴らしく、実質的にHTMLのためのドメイン固有言語に近い
プレーンテキストの要点はツールだ。HNに出たことはあるが、ここではまだ見かけていないMarkdownツールがいくつかある
https://addons.mozilla.org/en-US/firefox/addon/markdown-view... - ブラウザでMarkdownを見やすくレンダリングする
https://casual-effects.com/markdeep/ - 機能豊富なスタンドアロンのWeb向けMarkdownフォーマッタ
こうしたローカルWebサイトで使えば、普通のMarkdownを書くだけの手軽さが得られる
=> https://www.tducret.com/pure-markdown/
ソースコード: https://github.com/tducret/pure-markdown
技術的でないユーザーにも使えるようにしたいが、まだそこまでは至っていない
https://joeldare.com/using-neat-css-on-github-pages
Google/Searchから、プレーンテキストでノートを取る方法を探す人がかなり来ていて、そのシンプルな記事が役に立ったようだ
コンテンツをMarkdownと関連画像に変換したあと、Obsidian vault に保存している。同期はSyncthingで自分で処理している。ノートPCと携帯電話で、かなり効果的なツェッテルカステン式の記憶補助装置になりつつある
Google/Facebook Takeoutも取り込んで結果を再フォーマットし、人間に見えるすべての通信をそこに保存してインデックス化している。テキストは安いので、画像はほとんど避けている。それでもまだ200MB未満で、良いUIですぐ検索でき、Markdownファイルの束なので簡単に移動できる
個人的には、似たような方法で Obsidian に依存している。あとで共有するかもしれないFacebook投稿のように、保存しておきたいものがあれば元リンクと一緒に保存する。外部サービスはいつ消えてもおかしくないので、ローカルデータには自分たちが所有できることと検索しやすいことの2つの利点がある。
KindleのハイライトをMarkdownファイルに変換するスクリプトも作った。興味がある人がいれば、少し整えて共有できる。
公開用コンテンツについては、静的サイトジェネレーターのエコシステムがどんどん良くなっている。GitHubのデフォルトだったのでJekyllから始め、Gridsomeを経て最終的にNuxt 3 Contentに落ち着いたが、今のところ自分にはそれが最適点のように感じる。今から始めるならAstroを選んでいたかもしれない。
いずれにせよ、参入障壁はかつてないほど低い。GitHubで無料でサイトをホストできるし、カスタムスタイルが必要ならAIモデルがCSS作業で非常に役に立つ。
Markdownはテキスト整形のためのJavaScriptのようなものだ。変なところがあっても、結局ちゃんと動く。
[1] https://github.com/IAmStoxe/obsidian-markdownr
[2] https://addons.mozilla.org/en-US/firefox/addon/markdownload/ - Chrome拡張もある
15年前から似たようなことをしてきた。画像を埋め込んだポータブルHTMLやmp3などを作り、閲覧に別ソフトが必要ないようにしている。最近はクラウドやスマートフォンに入れて持ち歩けば、どんなデバイスやOSでもブラウザさえあればよい。
HTMLにmp3を埋め込むとサイズは大きくなり得るが、別の音楽プレーヤーやアプリなしでブラウザだけで済む。
最近はHTMLと一緒に手動で埋め込む代わりに、MHTML形式で保存しようとしている。
簡単なHTTPサーバーを立ててアーカイブを見て回ればよい。
画像ではこうしている：すべての画像をフォルダに保存 → localhostサーバーを開く → ブラウザでフォルダを開く → JavaScriptでリンクをsrc=linkのタグに変換 → ブラウザがすべての画像を取得して表示したら「名前を付けて保存」して、埋め込み済みのMHTMLアーカイブを得る。
あるいは簡単なBashスクリプトでimgタグとフォルダリンクのあるHTMLを作ることもできるし、MHTMLを手動テンプレートで作ることもできる。
だが、面倒な作業はブラウザにやらせればよく、わざわざ手動でする必要はない。
また、Base64埋め込みよりも MHTMLにバイナリ画像を直接埋め込む ほうがはるかに効率的で、メモリ消費も少ない。たとえば画像15枚の場合、MHTMLのバイナリエンコーディングは4MB、MHTMLのBase64エンコーディングは5MBだった。
もう一つの方法として、任意のフォルダで
python -m http.serverを実行するか、Linuxではtree -Hhttp://localhost:8000 で再帰の深さを設定する。その後、サーバーのフォルダリンクやtreeが生成したHTMLをブラウザで開き、コマンドラインで
wget -rkpN -e robots=offhttp://localhost:8000 を実行すると、閲覧可能なindex.htmlを含むフォルダを再生成してくれる。以後は閲覧のためにサーバーは不要になる。Google、Twitter、YouTubeのエクスポートと同じ方式だ。
似たようなことを考えていて、小さなフレームワークを自分で作った：https://www.smallweb.run
既存の自前構成と比べて追加される核心的な機能は、サブフォルダをサブドメインにマッピングすることだ。動的Webサイトも可能だが、そちらには関心がなさそうだ。
例：
~/smallweb/example=> https://example.localhost興味があれば小さなDiscordコミュニティもある：https://discord.smallweb.run
個人的には、仕事中のノート取りには VimWiki を好んでいる。アイデア、短い文書、Webで見つけたコード片を混ぜて置いておく場所として使っている。
主に記事、チュートリアル、有用なTipsを保存したいので、Webサイト全体を保存することが多い。この作業にはSingleFile[1]が一番気に入っている。
SingleFileでは画像を埋め込んだWebサイトを保存でき、注釈を追加したり、邪魔な広告などを切り取ったりもできる。気が散る要素のないWebサイトのコピーにも対応している。ぜひ見てみることをおすすめする。
[1]https://github.com/gildas-lormeau/SingleFile
こういう記事はいつも興味深い。ローテクで保守しやすい方向性は良いが、昔の作業を探し返すことに意味のある時間を使ったことは一度もない。
写真は例外だが、日付順に並んだ個人写真のタイムラインをただスクロールするだけで十分だった。子どもの頃はこういうことにもっと時間を使っていたが、ある時点で実際にはまったく見返していないことに気づいた。
人々が何年も前の作業を頻繁に見返す理由が何なのか気になる。
少なくとも自分の場合、コレクションに項目を追加するたびに HTML ファイルを手で編集しなければならないなら、どれほど速くて単純でも長期的には絶対に維持できないと思う
ごく単純な DIY 静的サイトジェネレーターを使うのに理想的なケースに見える。Bash や Perl で書けば、永遠に将来互換でいられるはず
静的 Web サイトをこのように使うのは新しいことではない。着想は Twitter アカウントのエクスポートから来ていて、ローカルで閲覧できる小さな Web サイトを提供してくれる。他の複数のソーシャルメディアプラットフォームでも、人が読みやすい形でデータを閲覧できる Web サイトを提供しているのを見た
どこかで Telegram のエクスポートもこの方式だと読んだ。元のファイル群がディレクトリである程度整理されていて、それ自体でも辿れるし、より楽に見て回れる小さなローカルの静的 Web サイトも付いてくるらしい
最後に使った大規模エクスポートである Google Takeout とはあまりに違う。Google Takeout は、ユーザーから見て意味のない命名体系の元ファイルと、よく分からない XML を雑にダンプしてくる
今でも、クラウド側で削除する前に要求したデータをすべて受け取れたのか確信がない