การใช้เว็บไซต์แบบสแตติกสำหรับคลังข้อมูลขนาดเล็ก
(alexwlchan.net)- เพื่อให้กลับมาค้นหาเอกสาร สกรีนช็อต บุ๊กมาร์ก และสื่อที่สะสมไว้ในเครื่องได้ในภายหลัง จึงเพิ่ม เว็บไซต์แบบสแตติก ให้กับแต่ละคอลเล็กชันขนาดเล็กเพื่อใช้สำรวจ
- แต่ละคอลเล็กชันยังคงเป็นโฟลเดอร์บนดิสก์ และเปิด ไฟล์ HTML ที่รากโฟลเดอร์ในเบราว์เซอร์ เพื่อให้มีเมทาดาทาและรูปแบบการจัดระเบียบที่ดีกว่า Finder
- เขียนด้วยมือล้วนโดยไม่มีเว็บเซิร์ฟเวอร์ ระบบบิลด์ dependency หรือ JavaScript framework และแต่ละเว็บไซต์มีขนาดเพียง โค้ดไม่กี่ร้อยบรรทัด จึงเหมาะกับโปรเจ็กต์เล็ก
- ลำดับชั้นโฟลเดอร์เดิม, แท็กของ Finder, แอปแบบ “everything bucket” และเครื่องมือที่ทำเอง ต่างก็มีปัญหาเรื่องการบังคับลำดับชั้น ข้อจำกัดของการใช้งาน การต้องปรับวิธีคิดให้เข้ากับแอป และภาระในการดูแลรักษา
- แม้การจัดระเบียบด้วยมือจะใช้เวลา แต่ก็ช่วยให้เลือกเก็บเฉพาะไฟล์ที่คุ้มค่า และ ความเรียบง่ายของ HTML ก็เอื้อต่อการเก็บรักษาระยะยาว
ดูคลังข้อมูลในเครื่องเป็นมินิเว็บไซต์
- สร้าง เว็บไซต์แบบสแตติก แยกตามคอลเล็กชันเพื่อสำรวจคลังข้อมูลในเครื่อง
- เอกสารที่สแกนไว้
- เอกสารที่ทำขึ้นเอง
- สกรีนช็อตที่บันทึกไว้
- บุ๊กมาร์กหน้าเว็บที่บันทึกไว้
- ไฟล์วิดีโอและเสียงที่เก็บไว้
- แต่ละคอลเล็กชันมีหน้าตาแตกต่างกันตามลักษณะของไฟล์
- คอลเล็กชันสกรีนช็อตแสดงเป็นกริดรูปภาพ
- บุ๊กมาร์กแสดงเป็นรายการลิงก์ข้อความ
- วิดีโอจัดเป็นรายการที่มีทั้งภาพตัวอย่างและข้อความ
- เป้าหมายไม่ใช่ระบบซับซ้อน แต่เป็นการทำ อินเทอร์เฟซสำหรับสำรวจไฟล์ ที่ดีกว่า macOS Finder เล็กน้อย
- ใส่เมทาดาทาในหน้าได้มากขึ้น
- ใช้วิธีค้นหาและจัดระเบียบที่ออกแบบเองได้
โครงสร้างและการเลือกเทคโนโลยี
- แต่ละคอลเล็กชันคือโฟลเดอร์หนึ่งบนดิสก์ในเครื่อง และเว็บไซต์คือ ไฟล์ HTML หนึ่งไฟล์หรือมากกว่าที่อยู่ในรากของโฟลเดอร์นั้น
- เวลาใช้งานก็เปิดไฟล์ HTML โดยตรงในเว็บเบราว์เซอร์
- ตั้งใจคงขนาดและระดับเทคโนโลยีให้ต่ำ
- ไม่มีเว็บเซิร์ฟเวอร์
- ไม่มีระบบบิลด์
- ไม่มี dependency
- ไม่มี JavaScript framework
- ทุกอย่างเขียนด้วยมือ แต่สำหรับโปรเจ็กต์เล็กก็ยังดูแลได้
- แต่ละเว็บไซต์มีขนาดมากสุดเพียงไม่กี่ร้อยบรรทัดของโค้ด
- มองว่าการมีเพียงไฟล์บนดิสก์กับ HTML ทำให้มีโอกาสอยู่ได้นาน
- ยังคงความเรียบง่ายและการพกพาได้ของโครงสร้างไฟล์แบบโฟลเดอร์
- แล้วเสริมเฉพาะความสามารถที่ต้องการเข้าไปเล็กน้อย
เหตุผลที่วิธีเดิมอยู่ไม่ยั่งยืน
- วิธีไฟล์และโฟลเดอร์ทั่วไปบังคับให้ใช้ โครงสร้างลำดับชั้น และทุกไฟล์ต้องอยู่ในตำแหน่งที่แน่ชัดเพียงแห่งเดียว
- เหมาะกับข้อมูลบางประเภทอย่างโค้ด
- แต่สำหรับไฟล์สื่อ การออกแบบลำดับชั้นที่น่าพอใจทำได้ยาก
- พอลังเลว่าจะใส่โฟลเดอร์ไหนดี เดสก์ท็อปก็ลงเอยด้วยความรก
- จึงชอบการติดแท็กด้วยคีย์เวิร์ดมากกว่า เพราะไฟล์หนึ่งไฟล์มีหลายป้ายกำกับได้และค้นคืนได้หลายแบบ
- macOS Finder รองรับแท็กเช่นกัน แต่การใช้งานยังไม่ดีพอจนไม่อยากใช้กับงานสำคัญ
- แอปแนว “everything bucket” อย่าง DEVONThink, Evernote, Yojimbo ก็ไม่ตอบโจทย์
- ให้ความรู้สึกว่าต้องเปลี่ยนวิธีคิดให้เข้ากับแนวทางของแอป
- เครื่องมือจัดไฟล์ที่ทำเองก็ลองทำมาอย่างน้อยราว 12 ครั้ง และหนึ่งในความพยายามช่วงท้ายคือ docstore
- แม้จะเข้ากับวิธีคิดของตัวเองมากกว่า แต่ก็มี ภาระในการดูแลรักษา
- ทุกครั้งที่อัปเกรด Python หรือ macOS ก็มักมีบางอย่างพังและต้องกลับไปแก้โค้ด
วิธีเปลี่ยนโฟลเดอร์ให้เป็นมินิเว็บไซต์
- ถ้าวางไฟล์ HTML สำหรับทำหน้าดัชนีไว้ที่โฟลเดอร์ระดับบนสุด ก็สามารถแสดงไฟล์ทั้งหมดพร้อมเมทาดาทาและแท็กตามที่ต้องการได้
- วิธีนี้ช่วยทำให้โครงสร้างโฟลเดอร์ง่ายขึ้น และลดภาระในการหาลำดับชั้นที่สมบูรณ์แบบ
- โดยทั่วไปไฟล์จะถูกจัดกลุ่มแค่ตามปี หรือตามอักษรแรกของชื่อไฟล์
- มองโฟลเดอร์เฉพาะตอนเพิ่มไฟล์ใหม่ ไม่ได้ใช้ในการสำรวจ
- เวลาอยากหาไฟล์จะใช้เว็บไซต์เสมอ
- เว็บไซต์ช่วยให้ค้นหาไฟล์ได้หลายแบบผ่านแท็กคีย์เวิร์ด และซ่อนรายละเอียดของโครงสร้างโฟลเดอร์จริงไว้
- HTML ถูกเลือกเพราะเป็นเทคโนโลยีที่ดูแลรักษาน้อย ยืดหยุ่น และมีโอกาสเลือนหายน้อย
- เป็นเทคโนโลยีพื้นฐานของเว็บ
- คอมพิวเตอร์สมัยใหม่แทบทุกเครื่องมีเบราว์เซอร์ที่เรนเดอร์หน้า HTML ได้
- แม้แต่เว็บไซต์แรกสำหรับชั้นเรียนที่ทำไว้ในปี 2006 ก็ยังเรนเดอร์ได้โดยไม่มีปัญหาในเบราว์เซอร์ปัจจุบัน
ทำไมจึงเหมาะกับคลังข้อมูล “ขนาดเล็ก”
- เพราะการจัดไฟล์ เขียนเมทาดาทา และทำตัวดูจำนวนมากยังต้องทำด้วยมือ จึงขยายไปสู่คอลเล็กชันขนาดใหญ่ได้ไม่ดีนัก
- แม้การเก็บเพียงไม่กี่ร้อยรายการก็ยังใช้เวลาไม่น้อย แต่แรงเสียดทานนี้กลับช่วยในการคัดเลือกสิ่งที่จะเก็บ
- ทำให้ต้องคิดว่าคุ้มค่าพอจะจัดระเบียบอย่างจริงจังหรือไม่
- ทำให้ตั้งคำถามว่าไฟล์ที่ไม่อยากเสียเวลาเก็บแม้แต่นาทีนั้น จะมีโอกาสกลับมาดูอีกจริงหรือไม่
- และสำหรับไฟล์ที่ตัดสินใจเก็บ ก็จะใส่ใจเขียนเมทาดาทาให้ค้นหาได้ง่ายขึ้นในภายหลัง
- ก่อนหน้านี้เคยมีไฟล์หลายพันไฟล์กองอยู่ในโฟลเดอร์ใหญ่ที่คลุมเครือ และเพราะไม่ได้จัดอย่างเหมาะสมจึงไม่ค่อยกลับไปดูอีก
- ตอนนี้มีมินิเว็บไซต์เล็ก ๆ หลายชุดที่เก็บรายการเพียงไม่กี่ร้อยรายการ โดยแต่ละรายการถูกคัดเลือกอย่างรอบคอบและอธิบายไว้อย่างเป็นประโยชน์มากกว่าเดิม
- แม้จะเป็นคนชอบระบบอัตโนมัติ แต่ก็ยอมรับ ข้อจำกัด ของกระบวนการที่ทำด้วยมือมากขึ้นในแง่บวก
เว็บไซต์แบบสแตติกในฐานะเครื่องมือเพื่อการเก็บรักษา
- แรงบันดาลใจของวิธีนี้มาจากการส่งออกข้อมูลบัญชี Twitter
- การส่งออกบัญชี Twitter ให้มินิเว็บไซต์ที่สำรวจได้จากในเครื่อง
- แพลตฟอร์มโซเชียลมีเดียหลายแห่งก็ให้ข้อมูลในรูปเว็บไซต์ที่มนุษย์เปิดดูและสำรวจได้สะดวกเช่นกัน
- เว็บไซต์แบบสแตติกอาจมีประโยชน์ในฐานะแนวทางการอนุรักษ์ดิจิทัลสำหรับคลัง born-digital
- ความเรียบง่าย ความยั่งยืนระยะยาว และการดูแลรักษาต่ำ มีคุณค่ามากยิ่งขึ้นสำหรับสถาบันความทรงจำที่ตั้งเป้าเก็บรักษาไว้เป็นสิบปีหรือหลายร้อยปี
- เพียงแค่ Notepad หรือโปรแกรมแก้ไขข้อความพื้นฐาน ก็สามารถสร้างเว็บไซต์ HTML อย่างง่ายได้
- ใน Data Lifeboat project มีการสร้างเว็บไซต์แบบสแตติกที่ใหญ่กว่า เพื่อใช้แพ็กเกจส่วนหนึ่งของคลังข้อมูล Flickr
- คลังข้อมูลในเครื่องมักใกล้เคียงกับมุมมองแบบรายการ แต่เว็บไซต์ภายใน Data Lifeboat มีจำนวนหน้าและความสามารถมากกว่า
- โพสต์ของ Ed Summers เกี่ยวกับ เว็บไซต์แบบสแตติกเพื่อการอนุรักษ์ Historypin ก็เป็นอีกตัวอย่างในแนวทางเดียวกัน
การย้ายแบบค่อยเป็นค่อยไปและการใช้ HTML ในชีวิตส่วนตัว
- เพราะมีไฟล์จำนวนมากกระจายอยู่ทั่วดิสก์อยู่แล้ว การย้ายทั้งหมดในครั้งเดียวจึงเป็นงานที่ใหญ่
- ไฟล์ใหม่จะเก็บไว้ในเว็บไซต์แบบสแตติก ส่วนไฟล์เก่าจะค่อย ๆ ดึงออกจากที่เดิมและย้ายเข้าโฟลเดอร์ของเว็บไซต์แบบสแตติกที่เหมาะสมเมื่อเจอเข้าระหว่างค้นหา
- หลังจากทำโครงสร้างเว็บไซต์ตั้งต้นไว้แล้ว ก็แทบไม่มี ภาระในการดูแลรักษา เพื่อให้มันทำงานต่อ
- สำหรับคนที่อยากลองสร้างเว็บไซต์ครั้งแรก ขอแนะนำ HTML for People ของ Blake Watson
- มีแนวคิดว่า “ถ้าต้องการ ใคร ๆ ก็ควรสามารถสร้างเว็บไซต์ด้วย HTML ได้”
- เป็นเวลานานที่มอง HTML ว่าเป็นเครื่องมือสำหรับเผยแพร่เว็บไซต์ให้คนอื่นดู แต่จริง ๆ แล้วมันก็ใช้กับคลังข้อมูลส่วนตัวในเครื่องได้ด้วย
- อัปเดตเมื่อ 19 กุมภาพันธ์ 2025: เพิ่มบทความต่อเนื่อง 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 ก็จะถูกบันทึกไปด้วย ถ้าต้องการเอาบางส่วนออกก่อนบันทึก เช่นอยากลบรูปภาพ ให้เปิดตรวจสอบองค์ประกอบ ลบออก แล้วค่อยบันทึกหน้าเว็บ
ไฟล์นี้จะอัปโหลดขึ้นเซิร์ฟเวอร์ก็ได้ หรือดับเบิลคลิกเปิดบนคอมพิวเตอร์หรือมือถือก็ได้
https://github.com/cadars/john-doe ก็ให้ความรู้สึกคล้ายกัน
โปรโตไทป์เร็ว ๆ: https://gistpreview.github.io/?14a2c3ef508839f26377707dbf5dd... - โค้ด: https://gist.github.com/simonw/14a2c3ef508839f26377707dbf5dd...
ในคอมเมนต์พูดถึง Markdown กันเยอะ ขอสนับสนุนอีกเสียง ข้อความธรรมดา ดีที่สุด ผมคิดเรื่องการรวบรวมและเก็บรักษาข้อมูลของตัวเองอยู่มาก และข้อความธรรมดาคือแกนหลักของเรื่องนั้น แถมยังเข้ากันได้ดีกับอนาคตมาก
หลังยุค WordPerfect เป็นต้นมา ผมชอบเอกสารที่กำหนดรูปแบบได้ชัดเจนกว่า เบากว่า และมองเห็นอักขระจัดรูปแบบได้โดยตรง Markdown ยอดเยี่ยม และแทบจะเป็นภาษาเฉพาะโดเมนสำหรับ HTML อยู่แล้ว
หัวใจของข้อความธรรมดาคือเครื่องมือ มีเครื่องมือ Markdown บางตัวที่เคยโผล่ใน HN แต่ยังไม่เห็นในที่นี้
https://addons.mozilla.org/en-US/firefox/addon/markdown-view... - เรนเดอร์ Markdown ให้อ่านสวยงามในเบราว์เซอร์
https://casual-effects.com/markdeep/ - ฟอร์แมตเตอร์ Markdown แบบสแตนด์อโลนที่เป็นมิตรกับเว็บและมีฟีเจอร์เยอะ
ถ้าใช้กับเว็บไซต์โลคัลแบบนี้ ก็จะได้ความสะดวกของการเขียน 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 มันค่อย ๆ กลายเป็นอุปกรณ์ช่วยจำแบบเซตเทลคาสเทินที่ค่อนข้างได้ผลบนโน้ตบุ๊กและมือถือ
นำเข้า Google/Facebook Takeout ด้วย จากนั้นจัดรูปแบบผลลัพธ์ใหม่ แล้วเก็บและทำดัชนีจดหมายโต้ตอบทั้งหมดที่มนุษย์อ่านได้ไว้ในนั้น ข้อความมีต้นทุนต่ำ เลยหลีกเลี่ยงรูปภาพเป็นส่วนใหญ่ ถึงอย่างนั้นตอนนี้ก็ยังน้อยกว่า 200MB ค้นหาได้ทันทีด้วย UI ที่ดี และเพราะเป็นชุดไฟล์ Markdown จึงย้ายได้ง่าย
โดยส่วนตัวแล้วพึ่งพา Obsidian ด้วยวิธีคล้าย ๆ กัน ถ้ามีอะไรที่อยากเก็บไว้ เช่น โพสต์ FB ที่อาจนำมาแชร์ทีหลัง ก็จะบันทึกไว้พร้อมลิงก์ต้นฉบับ บริการภายนอกอาจหายไปได้ทุกเมื่อ ดังนั้นข้อมูลในเครื่องจึงมีข้อดีสองอย่างคือเราเป็นเจ้าของเองและค้นหาได้ง่าย
ผมยังทำสคริปต์สำหรับแปลงไฮไลต์ Kindle เป็นไฟล์ Markdown ด้วย ถ้ามีคนสนใจ ผมอาจปรับแต่งให้เรียบร้อยขึ้นแล้วแชร์ได้
สำหรับคอนเทนต์สาธารณะ ระบบนิเวศของ static site generator ก็ดีขึ้นเรื่อย ๆ ผมเริ่มจาก Jekyll เพราะเป็นค่าเริ่มต้นของ GitHub ผ่าน 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 ฯลฯ เพื่อให้ไม่ต้องใช้ซอฟต์แวร์แยกต่างหากในการดู ทุกวันนี้ถ้าเก็บไว้ในคลาวด์หรือในมือถือ ก็ใช้ได้กับอุปกรณ์และระบบปฏิบัติการใด ๆ ขอแค่มีเบราว์เซอร์
ถ้าฝัง mp3 ใน HTML ขนาดอาจใหญ่ขึ้น แต่ก็ต้องการแค่เบราว์เซอร์ ไม่ต้องมีเครื่องเล่นเพลงหรือแอปแยก
ช่วงนี้ผมพยายามเก็บเป็น รูปแบบ MHTML แทนการฝังด้วยมือใน HTML
แค่เปิด HTTP server ง่าย ๆ แล้วเรียกดู archive ก็พอ
สำหรับรูปภาพ ผมทำแบบนี้: เก็บรูปทั้งหมดไว้ในโฟลเดอร์ → เปิดเซิร์ฟเวอร์ localhost → เปิดโฟลเดอร์ในเบราว์เซอร์ → ใช้ JavaScript แปลงลิงก์เป็นแท็กที่มี src=link → เมื่อเบราว์เซอร์ดึงและแสดงรูปทั้งหมดแล้ว ก็ “บันทึกเป็น” เพื่อให้ได้ archive แบบ MHTML ที่ฝังไว้แล้ว
หรือจะใช้ Bash script ง่าย ๆ สร้าง HTML ที่มีแท็ก img และลิงก์โฟลเดอร์ก็ได้ หรือจะสร้าง MHTML จากเทมเพลตด้วยมือก็ได้
แต่ให้เบราว์เซอร์ทำงานหนักแทนก็พอ ไม่จำเป็นต้องทำเองด้วยมือ
อีกอย่าง การ ฝังรูปภาพไบนารีโดยตรงใน MHTML มีประสิทธิภาพกว่าการฝังแบบ Base64 มาก และกินหน่วยความจำน้อยกว่า ตัวอย่างเช่น รูป 15 รูป การเข้ารหัสไบนารีของ MHTML มีขนาด 4MB ส่วนการเข้ารหัส Base64 ของ MHTML มีขนาด 5MB
อีกวิธีหนึ่งคือรัน
python -m http.serverในโฟลเดอร์ใดก็ได้ หรือบน Linux ใช้tree -Hhttp://localhost:8000 พร้อมตั้งค่าความลึกแบบ recursiveจากนั้นเปิดลิงก์โฟลเดอร์ของเซิร์ฟเวอร์หรือ HTML ที่ tree สร้างในเบราว์เซอร์ แล้วรัน
wget -rkpN -e robots=offhttp://localhost:8000 จาก command line มันจะสร้างโฟลเดอร์ขึ้นมาใหม่พร้อม index.html ที่เรียกดูได้ หลังจากนั้นก็ไม่ต้องใช้เซิร์ฟเวอร์เพื่อดูอีกเป็นวิธีเดียวกับการ export จาก Google, Twitter, YouTube
ผมเคยคิดคล้าย ๆ กัน แล้วลงมือทำ framework เล็ก ๆ เอง: https://www.smallweb.run
ฟีเจอร์หลักที่เพิ่มจากการตั้งค่าเองแบบเดิมคือ การแมปโฟลเดอร์ย่อยไปยัง subdomain เว็บไซต์แบบ dynamic ก็ทำได้ แต่ดูเหมือนคุณจะไม่ได้สนใจส่วนนั้น
ตัวอย่าง:
~/smallweb/example=> https://example.localhostถ้าสนใจ ก็มีชุมชน Discord เล็ก ๆ ด้วย: https://discord.smallweb.run
โดยส่วนตัวแล้วสำหรับการจดโน้ตระหว่างทำงาน ผมชอบ VimWiki ใช้เป็นที่ผสมไอเดีย เอกสารสั้น ๆ และโค้ด snippet ที่เจอบนเว็บ
ผมมักจะเก็บเว็บไซต์ทั้งเว็บ เพราะอยากบันทึกบทความ tutorial และเคล็ดลับที่มีประโยชน์ สำหรับงานนี้ผมชอบ SingleFile[1] ที่สุด
SingleFile ช่วยบันทึกเว็บไซต์พร้อมฝังรูปภาพได้ และยังเพิ่มหมายเหตุหรือตัดโฆษณาที่น่ารำคาญออกได้ด้วย รองรับสำเนาเว็บไซต์แบบไร้สิ่งรบกวนด้วย แนะนำให้ลองดูจริง ๆ
[1]https://github.com/gildas-lormeau/SingleFile
บทความแบบนี้น่าสนใจเสมอ แนวทางแบบ เทคโนโลยีต่ำและดูแลรักษาได้ เป็นเรื่องดี แต่ผมไม่เคยใช้เวลาอย่างมีนัยสำคัญไปกับการค้นงานเก่า ๆ เลย
รูปถ่ายเป็นข้อยกเว้น แต่แค่เลื่อนดูไทม์ไลน์รูปส่วนตัวที่เรียงตามวันที่ก็เพียงพอแล้ว ตอนเด็ก ๆ ผมใช้เวลากับเรื่องแบบนี้มากกว่า แต่ถึงจุดหนึ่งก็รู้ตัวว่าจริง ๆ แล้วแทบไม่เคยกลับไปดูเลย
ผมสงสัยว่าทำไมผู้คนถึงกลับไปดูงานเมื่อหลายปีก่อนบ่อย ๆ
อย่างน้อยในกรณีของผม ถ้าทุกครั้งที่เพิ่มรายการเข้าไปในคอลเลกชันต้องแก้ไฟล์ HTML ด้วยมือ ต่อให้เร็วและเรียบง่ายแค่ไหน ในระยะยาวก็คงไม่มีทางดูแลต่อได้แน่
ดูเหมือนเป็นกรณีที่เหมาะมากสำหรับการใช้ ตัวสร้างไซต์สแตติกแบบ DIY ที่เรียบง่ายสุด ๆ ถ้าเขียนด้วย Bash หรือ Perl ก็น่าจะเข้ากันได้กับอนาคตไปตลอด
การใช้เว็บไซต์สแตติกในลักษณะนี้ไม่ใช่เรื่องใหม่ แรงบันดาลใจมาจากการส่งออกบัญชี Twitter ซึ่งให้เว็บไซต์เล็ก ๆ ที่สามารถเปิดสำรวจในเครื่องได้ ผมเคยเห็นแพลตฟอร์มโซเชียลมีเดียอื่น ๆ หลายแห่งก็มีเว็บไซต์ที่ช่วยให้สำรวจข้อมูลในแบบที่คนอ่านได้ง่าย
เคยอ่านเจอที่ไหนสักแห่งว่าการส่งออกของ Telegram ก็เป็นแบบนี้เหมือนกัน ว่ากันว่าไฟล์ต้นฉบับถูกจัดไว้เป็นไดเรกทอรีในระดับหนึ่ง สามารถเปิดดูได้ด้วยตัวมันเอง และยังมีเว็บไซต์สแตติกขนาดเล็กแบบโลคัลแนบมาด้วยเพื่อให้ไล่ดูได้สะดวกขึ้น
ต่างจาก Google Takeout ซึ่งเป็นการส่งออกข้อมูลจำนวนมากครั้งล่าสุดที่ผมได้ลองใช้มาก Google Takeout แค่ dump ไฟล์ต้นฉบับที่มีระบบตั้งชื่อซึ่งไม่มีความหมายสำหรับผู้ใช้ พร้อม XML ที่ไม่รู้ว่าอะไรแบบทื่อ ๆ
ถึงตอนนี้ผมก็ยังไม่มั่นใจว่าได้รับข้อมูลทั้งหมดที่ร้องขอไปแล้วหรือยัง ก่อนจะลบข้อมูลฝั่งคลาวด์