Tận dụng website tĩnh cho các kho lưu trữ nhỏ

 (alexwlchan.net)
4 điểm bởi GN⁺ 2024-10-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Để có thể tìm lại về sau các tài liệu, ảnh chụp màn hình, bookmark và media tích lũy trên máy cục bộ, tác giả gắn website tĩnh cho từng bộ sưu tập nhỏ để duyệt
  • Mỗi bộ sưu tập được giữ nguyên như một thư mục trên ổ đĩa, và mở tệp HTML ở thư mục gốc trong trình duyệt để có metadata phong phú hơn cùng cách sắp xếp tốt hơn Finder
  • Mọi thứ được viết thủ công, không dùng web server, hệ thống build, dependency hay JavaScript framework; mỗi site cùng lắm chỉ ở mức vài trăm dòng mã, phù hợp với dự án nhỏ
  • Các cách trước đây như cấu trúc thư mục truyền thống, thẻ của Finder, ứng dụng “everything bucket”, hay công cụ tự làm đều có nhược điểm như ép buộc phân cấp, giới hạn triển khai, phải thích nghi với cách tư duy của ứng dụng, hoặc gánh nặng bảo trì
  • Việc sắp xếp thủ công tốn thời gian nhưng khiến người dùng chỉ chọn lưu những tệp thực sự đáng giữ, và sự đơn giản của HTML có lợi cho việc lưu trữ lâu dài

Xem kho lưu trữ cục bộ như các mini website

  • Tạo website tĩnh cho từng bộ sưu tập để duyệt kho lưu trữ cục bộ
    • giấy tờ đã scan
    • tài liệu tự tạo
    • ảnh chụp màn hình đã lưu
    • bookmark trang web đã lưu
    • tệp video và âm thanh đã lưu
  • Mỗi bộ sưu tập có giao diện khác nhau tùy theo tính chất của tệp
    • bộ sưu tập ảnh chụp màn hình được hiển thị dưới dạng lưới ảnh
    • bookmark được hiển thị dưới dạng danh sách liên kết văn bản
    • video được sắp xếp dưới dạng danh sách trộn giữa thumbnail và văn bản
  • Mục tiêu không phải là một hệ thống phức tạp mà là tạo ra giao diện duyệt tệp tốt hơn một chút so với macOS Finder
    • có thể đưa nhiều metadata hơn lên trang
    • có thể dùng cách tìm kiếm và sắp xếp do chính mình tạo ra

Cách tổ chức và lựa chọn công nghệ

  • Mỗi bộ sưu tập là một thư mục trên ổ đĩa cục bộ, và website là một hoặc nhiều tệp HTML nằm ở thư mục gốc của thư mục đó
  • Khi dùng thì mở trực tiếp tệp HTML trong trình duyệt web
  • Cố ý giữ quy mô nhỏ và mức độ kỹ thuật thấp
    • không có web server
    • không có hệ thống build
    • không có dependency
    • không có JavaScript framework
  • Mọi thứ đều được viết tay, nhưng với dự án nhỏ thì vẫn quản lý được
    • mỗi website cùng lắm chỉ ở mức vài trăm dòng mã
  • Tác giả cho rằng cấu trúc chỉ gồm tệp trên ổ đĩa và HTML có khả năng tồn tại lâu dài cao
    • giữ được sự đơn giản và tính di động của cấu trúc thư mục tệp
    • chỉ bổ sung thêm một ít chức năng cần thiết ở phía trên

Vì sao những cách trước đây không bền lâu

  • Cách dùng tệp và thư mục thông thường ép buộc cấu trúc phân cấp, và mọi tệp phải nằm đúng ở một chỗ duy nhất
    • điều này hợp với một số loại dữ liệu như mã nguồn
    • nhưng với tệp media thì rất khó thiết kế một hệ phân cấp thỏa đáng
    • việc lưỡng lự không biết nên đặt vào thư mục nào khiến desktop luôn ở trạng thái bừa bộn
  • Tác giả thích gắn từ khóa hơn vì một tệp có thể có nhiều nhãn và được tìm lại theo nhiều cách
    • macOS Finder cũng hỗ trợ tag, nhưng phần triển khai chưa đủ tốt để tác giả muốn dùng cho mục đích quan trọng
  • Các ứng dụng “everything bucket” như DEVONThink, Evernote, Yojimbo cũng không phù hợp
    • có cảm giác phải thay đổi cách suy nghĩ để khớp với cách vận hành của ứng dụng
  • Tác giả cũng đã thử ít nhất khoảng 12 lần làm công cụ sắp xếp tệp riêng, và một trong những lần thử gần đây nhất là docstore
    • nó hợp với cách tư duy của tác giả hơn nhưng lại phát sinh gánh nặng bảo trì
    • mỗi lần nâng cấp Python hoặc cập nhật macOS lại có thứ gì đó hỏng và phải sửa mã

Cách biến thư mục thành mini website

  • Chỉ cần đặt một tệp HTML làm chỉ mục ở thư mục cấp cao nhất là có thể hiển thị mọi tệp với metadata và tag theo ý muốn
  • Cách này giúp đơn giản hóa cấu trúc thư mục và giảm áp lực phải tìm ra hệ phân cấp hoàn hảo
    • các tệp thường chỉ được gom theo năm hoặc theo chữ cái đầu của tên tệp
    • chỉ nhìn vào thư mục khi thêm tệp mới, không dùng nó để duyệt
    • khi tìm tệp thì luôn dùng website
  • Website cho phép tìm tệp theo tag từ khóa theo nhiều cách và che đi chi tiết của cấu trúc thư mục thực tế
  • HTML được chọn vì là công nghệ ít bảo trì, linh hoạt và khó biến mất
    • đó là công nghệ nền tảng của web
    • gần như mọi máy tính hiện đại đều có trình duyệt có thể render trang HTML
    • website đầu tiên tác giả làm cho lớp học ở trường vào năm 2006 vẫn render bình thường trên trình duyệt hiện đại

Vì sao phù hợp với kho lưu trữ “nhỏ”

  • Vì phần lớn việc sắp xếp tệp, viết metadata và tạo viewer đều làm thủ công nên cách này không mở rộng tốt cho các bộ sưu tập lớn
  • Ngay cả việc lưu vài trăm mục cũng tốn không ít thời gian, nhưng chính độ ma sát này lại giúp chọn lọc thứ đáng lưu
    • buộc phải tự hỏi liệu nó có đáng để sắp xếp tử tế hay không
    • tự hỏi liệu một tệp mà còn không muốn bỏ ra 1 phút để lưu có thực sự đáng xem lại sau này không
    • với những tệp quyết định lưu, người dùng sẽ chú ý hơn tới metadata để sau này dễ tìm lại
  • Trước đây, hàng nghìn tệp bị dồn vào những thư mục lớn và mơ hồ, không được sắp xếp tử tế nên rồi cũng không xem lại
  • Giờ đây có những website nhỏ chứa vài trăm mục, và các mục được chọn lọc kỹ hơn cũng như được mô tả hữu ích hơn
  • Dù vốn thích tự động hóa, tác giả vẫn nhìn nhận tích cực ràng buộc mà quy trình thủ công hơn này mang lại

Website tĩnh như một công cụ lưu trữ lâu dài

  • Cảm hứng cho cách làm này đến từ tính năng xuất dữ liệu tài khoản Twitter
    • phần xuất dữ liệu của Twitter cung cấp một mini website có thể duyệt cục bộ
    • nhiều nền tảng mạng xã hội khác cũng cung cấp dữ liệu ở dạng website để con người có thể duyệt dễ dàng
  • Website tĩnh cũng có thể hữu ích như một phương thức bảo tồn số khi xử lý kho lưu trữ born-digital
    • tính đơn giản, tuổi thọ dài và nhu cầu bảo trì thấp còn có giá trị hơn với các tổ chức lưu giữ ký ức hướng tới bảo tồn hàng chục hoặc hàng trăm năm
    • chỉ với Notepad cơ bản hoặc trình soạn thảo văn bản cũng có thể tạo một website HTML đơn giản
  • Data Lifeboat project đang tạo ra các website tĩnh lớn hơn như một cách đóng gói một phần kho lưu trữ của Flickr
    • kho lưu trữ cục bộ thường gần với giao diện dạng danh sách hơn, nhưng website trong Data Lifeboat có nhiều trang và tính năng hơn
  • Bài viết của Ed Summers về site tĩnh để bảo tồn Historypin cũng là một ví dụ theo cùng hướng

Chuyển đổi dần dần và cách dùng HTML cho mục đích cá nhân

  • Vì đã có rất nhiều tệp nằm rải rác khắp ổ đĩa nên chuyển toàn bộ trong một lần là khối lượng công việc quá lớn
  • Tệp mới sẽ được lưu vào website tĩnh, còn tệp cũ thì mỗi khi cần tìm sẽ được lấy từ chỗ lưu cũ và chuyển sang thư mục site tĩnh phù hợp
  • Sau khi tạo cấu trúc site ban đầu, gần như không còn gánh nặng bảo trì nào để giữ cho nó hoạt động
  • Với ai muốn thử tạo website lần đầu, tác giả gợi ý HTML for People của Blake Watson
    • nó mang triết lý rằng “bất kỳ ai muốn đều nên có thể tạo website bằng HTML”
  • Từ lâu HTML thường được xem là công cụ để xuất bản website cho người khác xem, nhưng nó cũng có thể dùng cho kho lưu trữ cá nhân cục bộ
  • Bản cập nhật ngày 19 tháng 2 năm 2025 có bổ sung bài viết tiếp theo giải thích chi tiết phần mã: How I create static websites for tiny archives

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-19
Ý kiến trên Hacker News

  • Sao chép ảnh từ clipboard và lưu vào tệp HTML để dùng như một thư viện ảnh chỉ gồm một tệp
    https://gist.github.com/egeozcan/b27e11a7e776972d18603222fa5...
    Ví dụ chạy trực tiếp: https://gistpreview.github.io/?b27e11a7e776972d18603222fa523...
    Chọn bằng bộ chọn tệp cũng hoạt động, nhưng kéo thả thì thường không chạy tốt. Nếu hoạt động đúng, ảnh sẽ được chèn inline vào tài liệu dưới dạng blob
    Sau khi thêm ảnh, chỉ cần lưu nguyên trang, tức là bấm file->save, thì blob cũng sẽ được lưu cùng. Nếu muốn bỏ bớt trước khi lưu, ví dụ muốn xóa ảnh, thì mở inspect element, xóa đi rồi lưu trang là được
    Tệp này có thể tải lên máy chủ, hoặc chỉ cần nhấp đúp để mở trên máy tính hay điện thoại

    • Thích đấy. Đây là cách rất trung thành với tầm nhìn ban đầu của WWW. Trình duyệt WorldWideWeb của Tim Berners-Lee cũng là một trình biên tập
      https://github.com/cadars/john-doe cũng cho cảm giác tương tự
    • Rất gọn gàng. Có lẽ có thể thêm nút Download this page vào trang để tạo ra một tệp HTML đã nhúng sẵn ảnh rồi cho người dùng tải xuống. Như vậy thì trên di động cũng có thể hoạt động
      Bản mẫu nhanh: https://gistpreview.github.io/?14a2c3ef508839f26377707dbf5dd... - mã: https://gist.github.com/simonw/14a2c3ef508839f26377707dbf5dd...
    • Rất mượt. Đúng nghĩa offline-first
    • Thiết kế rất đẹp. Nếu không chạy, hãy kiểm tra xem khi lưu bạn đã đặt định dạng tệp là webpage, complete chưa

  • Mọi người trong phần bình luận nói nhiều về Markdown, nên tôi cũng góp một phiếu cho nó. Văn bản thuần túy là tốt nhất. Tôi suy nghĩ rất nhiều về việc thu thập và lưu trữ dữ liệu của mình, và văn bản thuần túy là cốt lõi của chuyện đó, với khả năng tương thích tương lai rất cao
    Từ sau WordPerfect, tôi luôn thích những tài liệu có định dạng theo kiểu quyết định rõ ràng hơn và nhẹ hơn, nơi có thể nhìn trực tiếp thấy các ký tự định dạng. Markdown rất tuyệt, và thực tế gần như là một ngôn ngữ đặc thù miền dành cho HTML
    Cốt lõi của văn bản thuần túy là công cụ. Đã từng xuất hiện trên HN nhưng ở đây có vài công cụ Markdown mà tôi chưa thấy ai nhắc tới
    https://addons.mozilla.org/en-US/firefox/addon/markdown-view... - render Markdown đẹp mắt trong trình duyệt
    https://casual-effects.com/markdeep/ - trình định dạng Markdown độc lập, thân thiện với web, có nhiều tính năng

    • Tôi đã làm một JS nhỏ có thể host trực tiếp các tệp Markdown. Nó render sang HTML trong trình duyệt, không cần chuyển đổi trước hay plugin nào
      Dùng trong các website cục bộ kiểu này thì bạn có được sự tiện lợi của việc chỉ viết Markdown thuần
      => https://www.tducret.com/pure-markdown/
      Mã nguồn: https://github.com/tducret/pure-markdown
    • Tôi host các tệp Markdown của mình bằng GitHub. Tôi có viết một bài tổng hợp thêm một chút về chuyện này. Thực ra tôi có khoảng 4~5 bài viết mang ý tưởng tương tự, và đang tìm cách làm nó đơn giản hơn nữa
      Tôi muốn cả người dùng không rành kỹ thuật cũng có thể dùng, nhưng vẫn chưa đến được mức đó
      https://joeldare.com/using-neat-css-on-github-pages
    • Tôi cũng ngày càng dùng Plain Text nhiều hơn. Tôi đã viết suy nghĩ của mình về kho lưu trữ tại https://brajeshwar.com/2022/plain-text/
      Có khá nhiều người tìm cách ghi chú bằng văn bản thuần túy từ Google/Search rồi vào đọc, và có vẻ bài viết đơn giản đó đã giúp được họ

  • Tôi chuyển nội dung sang Markdown cùng các ảnh liên quan rồi lưu trong Obsidian vault. Việc đồng bộ tôi tự xử lý bằng Syncthing. Nó đang dần trở thành một công cụ hỗ trợ ghi nhớ kiểu Zettelkasten khá hiệu quả trên laptop và điện thoại của tôi
    Tôi cũng nhập cả Google/Facebook Takeout, định dạng lại kết quả, rồi lưu và lập chỉ mục mọi thư từ mà con người có thể đọc được vào đó. Văn bản thì rẻ nên tôi tránh ảnh trong hầu hết trường hợp. Dù vậy toàn bộ vẫn chưa tới 200MB, có thể tìm kiếm tức thì bằng UI tốt, và vì chỉ là một bó tệp Markdown nên cũng dễ di chuyển

    • Chỉ thế thôi à, ném ra ba từ “công cụ hỗ trợ ghi nhớ kiểu Zettelkasten” mà không có chút ngữ cảnh nào sao?
    • Bạn dùng gì để đồng bộ Obsidian trên điện thoại? Cũng là Syncthing à?

  • Cá nhân tôi cũng dựa vào Obsidian theo cách tương tự. Nếu có thứ gì muốn lưu lại như một bài đăng FB mà sau này có thể chia sẻ, tôi sẽ lưu cùng với liên kết gốc. Dịch vụ bên ngoài có thể biến mất bất cứ lúc nào, trong khi dữ liệu cục bộ có hai lợi thế: chúng ta sở hữu nó và dễ tìm kiếm
    Tôi cũng đã viết một script chuyển highlight Kindle thành file Markdown. Nếu có người quan tâm, tôi có thể chỉnh chu thêm một chút rồi chia sẻ
    Với nội dung công khai, hệ sinh thái trình tạo trang tĩnh vẫn đang ngày càng tốt hơn. Tôi bắt đầu với Jekyll vì đó là mặc định của GitHub, đi qua Gridsome rồi cuối cùng ổn định ở Nuxt 3 Content, và hiện tại nó có cảm giác như điểm tối ưu nhất với tôi. Nếu bắt đầu bây giờ, có lẽ tôi đã chọn Astro
    Dù sao thì rào cản gia nhập hiện thấp hơn bao giờ hết. Bạn có thể host site miễn phí trên GitHub, và nếu cần style tùy chỉnh thì các mô hình AI cực kỳ hữu ích cho việc làm CSS
    Markdown giống như JavaScript dành cho định dạng văn bản. Dù có vài chỗ kỳ quặc, cuối cùng nó vẫn hoạt động tốt

    • Tôi đã fork ứng dụng Android [1] để khi chia sẻ bài viết sang app thì nó sẽ chuyển sang Markdown rồi gửi vào Obsidian. Tôi cũng dùng một extension Firefox, dùng extension Obsidian là Advanced URI để gửi phiên bản Markdown của bài viết sang Obsidian, kèm cả metadata ở phần đầu[2]
      [1] https://github.com/IAmStoxe/obsidian-markdownr
      [2] https://addons.mozilla.org/en-US/firefox/addon/markdownload/ - cũng có extension cho Chrome
    • Tôi quan tâm đến script Kindle. Khi lưu bài đăng FB, không biết bạn có chỉ đơn giản là copy rồi paste nội dung, chuyển nó sang Markdown rồi đưa vào Obsidian không. Tôi muốn nghe thêm về quy trình thực tế

  • Tôi đã làm tương tự từ 15 năm trước. Tôi tạo HTML di động có nhúng hình ảnh, mp3, v.v. để không cần phần mềm riêng để xem. Giờ chỉ cần mang nó trên cloud hoặc điện thoại là trên bất kỳ thiết bị hay hệ điều hành nào, chỉ cần có trình duyệt là dùng được
    Nếu nhúng mp3 vào HTML thì kích thước có thể lớn hơn, nhưng bạn chỉ cần trình duyệt mà không cần trình phát nhạc hay app riêng
    Gần đây, thay vì nhúng thủ công cùng với HTML, tôi cố gắng lưu ở định dạng MHTML
    Chỉ cần chạy một HTTP server đơn giản rồi duyệt kho lưu trữ
    Với hình ảnh, tôi làm kiểu này: lưu toàn bộ ảnh vào thư mục → mở localhost server → mở thư mục đó trên trình duyệt → dùng JavaScript chuyển các liên kết thành thẻ có src=link → khi trình duyệt tải và hiển thị toàn bộ ảnh thì dùng “Lưu thành” để lấy bản lưu trữ MHTML đã nhúng
    Hoặc cũng có thể dùng một Bash script đơn giản để tạo HTML có thẻ img và liên kết thư mục, hoặc tự tạo MHTML bằng template thủ công
    Nhưng cứ để trình duyệt làm phần việc nặng thì không cần phải làm tay
    Ngoài ra, nhúng trực tiếp ảnh nhị phân trong MHTML hiệu quả hơn nhiều so với nhúng Base64 và cũng tốn ít bộ nhớ hơn. Ví dụ với 15 ảnh, mã hóa nhị phân MHTML là 4MB còn mã hóa Base64 MHTML là 5MB
    Một cách khác là chạy python -m http.server trong bất kỳ thư mục nào, hoặc trên Linux dùng tree -H http://localhost:8000 để đặt độ sâu đệ quy
    Sau đó mở liên kết thư mục của server hoặc HTML do tree tạo trong trình duyệt, rồi chạy wget -rkpN -e robots=off http://localhost:8000 trên dòng lệnh, nó sẽ tạo lại một thư mục có index.html có thể duyệt được. Sau đó không cần server để xem nữa
    Nó giống như xuất dữ liệu từ Google, Twitter, YouTube

  • Khi nghĩ theo hướng tương tự, tôi đã tự làm một framework nhỏ: https://www.smallweb.run
    Tính năng cốt lõi bổ sung so với cách tự cấu hình truyền thống là ánh xạ thư mục con sang subdomain. Nó cũng hỗ trợ website động, nhưng có vẻ bạn không quan tâm phần đó
    Ví dụ: ~/smallweb/example => https://example.localhost
    Nếu quan tâm thì cũng có một cộng đồng Discord nhỏ: https://discord.smallweb.run

    • Trông như bạn chỉ đang làm lại CGI/PHP

  • Cá nhân tôi thích VimWiki để ghi chú trong công việc. Tôi dùng nó như nơi trộn lẫn ý tưởng, tài liệu ngắn và các mẩu code nhặt được trên web
    Tôi thường muốn lưu lại các bài viết, hướng dẫn và mẹo hữu ích, nên có xu hướng lưu cả website. Với việc này, tôi thích SingleFile[1] nhất
    Với SingleFile, bạn có thể lưu website có nhúng hình ảnh, thêm chú thích hoặc cắt bỏ quảng cáo gây khó chịu, v.v. Nó cũng hỗ trợ bản sao website không có yếu tố gây xao nhãng. Rất đáng để thử
    [1]https://github.com/gildas-lormeau/SingleFile

    • SingleFile rất tuyệt. Nó nằm trong danh sách cài đặt trình duyệt tiêu chuẩn của tôi cùng với uBlock và Tree Style Tab

  • Những bài như thế này lúc nào cũng thú vị. Tôi thích hướng đi công nghệ thấp và dễ duy trì, nhưng chưa từng có lần nào tôi dành thời gian đáng kể để xem lại công việc cũ
    Ảnh là ngoại lệ, nhưng chỉ cần cuộn một timeline ảnh cá nhân được sắp theo ngày là đủ. Hồi nhỏ tôi dành nhiều thời gian hơn cho mấy thứ này, nhưng đến một lúc nhận ra mình thực ra chẳng bao giờ xem lại chúng
    Tôi tò mò không biết vì sao mọi người lại thường xuyên xem lại những thứ mình đã làm từ vài năm trước

    • Tôi hiếm khi xem lại ảnh chụp màn hình, nhưng mỗi lần xem lại đều thấy có cảm hứng và đôi khi lại bắt đầu một dự án mới. Có lẽ tôi cần một kho lưu trữ mỗi ngày rút ngẫu nhiên ra một cái để hiển thị
    • Một cuộc đời được nhìn lại là một cuộc đời được sống hai lần

  • Ít nhất là trong trường hợp của tôi, nếu mỗi lần thêm một mục vào bộ sưu tập lại phải tự tay sửa file HTML thì dù có nhanh và đơn giản đến đâu, về lâu dài chắc chắn tôi cũng không thể duy trì nổi.
    Có vẻ đây là trường hợp lý tưởng để dùng một trình tạo trang tĩnh tự làm cực kỳ đơn giản. Nếu viết bằng Bash hoặc Perl thì sẽ tương thích với tương lai mãi mãi.

  • Dùng website tĩnh theo cách này không phải điều mới mẻ. Nguồn cảm hứng đến từ tính năng xuất dữ liệu tài khoản Twitter, thứ cung cấp một website nhỏ có thể duyệt cục bộ. Tôi cũng đã thấy nhiều nền tảng mạng xã hội khác cung cấp website để có thể duyệt dữ liệu theo cách dễ đọc với con người.
    Tôi nhớ đã đọc ở đâu đó rằng xuất dữ liệu từ Telegram cũng theo kiểu này. Các file gốc được sắp xếp phần nào thành các thư mục và bản thân chúng cũng có thể duyệt được, đồng thời đi kèm một website tĩnh cục bộ nhỏ để xem thuận tiện hơn.
    Nó quá khác với Google Takeout, lần xuất dữ liệu hàng loạt gần nhất mà tôi từng dùng. Google Takeout chỉ ngu ngốc đổ ra các file gốc với quy ước đặt tên vô nghĩa đối với người dùng và những file XML không rõ nội dung.
    Đến giờ tôi vẫn không chắc mình đã nhận được toàn bộ dữ liệu đã yêu cầu trước khi xóa dữ liệu phía đám mây hay chưa.

    • Facebook cũng làm như vậy vào vài năm trước khi tôi rời đi. Họ cung cấp một bản dump lớn dữ liệu và ảnh, kèm theo các file HTML để có thể duyệt tốt hơn.