ทวงคืนเว็บด้วยรีดเดอร์ส่วนตัว

 (olano.dev)
4 คะแนน โดย GN⁺ 2023-12-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังจากเหนื่อยล้ากับวงการซอฟต์แวร์และโซเชียลมีเดียแบบเดิม ๆ จนลองใช้ Mastodon ด้วย แต่สิ่งที่ต้องการจริง ๆ ไม่ใช่ไทม์ไลน์ที่ยึดคนเป็นศูนย์กลาง หากเป็น ฟีดรีดเดอร์ส่วนตัว ที่รวบรวมบทความและการแจ้งเตือนจากเว็บมาให้อ่าน
  • เป้าหมายไม่ใช่รายการค้างอ่านแบบกล่องจดหมายของ RSS reader แต่เป็น อินเทอร์เฟซแบบสตรีม ที่เมื่อเปิดขึ้นมาก็มีคอนเทนต์น่าสนใจไหลมาเหมือนโฮมฟีดของ Twitter หรือ Mastodon
  • เกณฑ์การออกแบบคือ ประสบการณ์ผู้ใช้ > ความสะดวกในการดูแลระบบ > ความสะดวกในการพัฒนา และให้ความสำคัญกับตัวเลือกที่ดูแลง่าย เช่น htmx·hyperscript, เว็บแอปแบบโมโนลิธิก, SQLite, Python, gevent และส่วนขยาย Huey
  • ระหว่างการใช้งานจริง ได้เพิ่มฟีเจอร์อย่างการอ่านบทความภายในแอป, การปักหมุดไว้อ่านทีหลัง, bookmark, การจัดเรียงตามความถี่การเผยแพร่ของแหล่งข้อมูล และการทำเครื่องหมาย “เคยเห็นแล้ว” อัตโนมัติเมื่อเลื่อนหน้าจอ
  • หลังจากค่อย ๆ ทำอยู่ราว 3 เดือน ก็สร้าง feedi ขึ้นมาได้ และเมื่อใช้มันเป็น “หน้าแรกของอินเทอร์เน็ต” อยู่หลายเดือน ก็ได้ความรู้สึกว่าตัวเองกลับมาควบคุมข้อมูลที่เสพได้อีกครั้ง

วิธีใช้งานเว็บที่กลับมาค้นพบหลังภาวะหมดไฟ

  • เจอกับ ภาวะหมดไฟในอาชีพ จากโปรเจกต์แย่ ๆ ต่อเนื่องและความผิดหวังต่อวงการซอฟต์แวร์
  • ลดงาน ลาออก และเริ่มการรักษา พร้อมทั้งปรับนิสัยอย่างการกิน การออกกำลังกาย และการนั่งสมาธิ
  • อยู่ห่างจากการเขียนโปรแกรมและการอ่านเรื่องซอฟต์แวร์ไปพักใหญ่ และออกจาก Twitter ซึ่งเป็นโซเชียลมีเดียตัวสุดท้ายที่ยังใช้อยู่
  • ระหว่างอ่าน How to Do Nothing ก็กลับมามอง Mastodon อีกครั้งในฐานะชุมชนออนไลน์ทางเลือก

ข้อจำกัดที่เห็นจาก Mastodon

  • Mastodon ให้ ฟีดตามลำดับเวลา โดยไม่มีตัวกลางแบบอัลกอริทึม ทำให้รู้สึกเหมือนได้กลับมาควบคุมฟีดอีกครั้ง
  • คนที่รู้สึกอึดอัดคล้ายกันกับวงการซอฟต์แวร์และเว็บ ก็กำลังหันกลับไปมององค์ประกอบของเว็บยุคก่อนอย่าง RSS, BBS, digital gardens, webrings หรือจินตนาการถึงเว็บที่เปิดกว้างและเป็นอิสระมากขึ้น
  • เป้าหมายการใช้งานจริงใกล้เคียงกับ ศูนย์รวมข้อมูล มากกว่าไมโครบล็อกกิง
    • เหตุผลที่ติดตามผู้คน เพราะอยากได้รับการแจ้งเตือนเมื่อพวกเขาโพสต์บนเว็บไซต์ของตัวเอง
    • เหตุผลที่ติดตามบอต เพราะอยากรับคอนเทนต์จากตัวรวบรวมลิงก์
  • หลังจากรู้จักแนวคิด social readers ของ IndieWeb ก็สรุปได้ว่า เครื่องมือที่ต้องการไม่ใช่ Mastodon แต่เป็น ฟีดรีดเดอร์ ที่ปรับแต่งได้เอง

เป้าหมายของผู้ใช้สำหรับรีดเดอร์ส่วนตัว

  • ไม่ต้องการรายการค้างอ่านแบบกล่องจดหมายของ RSS reader ทั่วไป แต่ต้องการ สตรีม ที่เมื่อเปิดแอปมาก็มีคอนเทนต์น่าสนใจไหลมา
  • ในฟีดต้องมีหลายแหล่งข้อมูลปะปนกัน
    • บทความจากบล็อก นิตยสาร เว็บไซต์ข่าว และตัวรวบรวมลิงก์
    • การแจ้งเตือนจากบัญชีส่วนตัวอย่าง Mastodon, Goodreads, GitHub
  • แม้รูปแบบข้อมูลของแต่ละแหล่งจะต่างกัน ก็ต้องมี การปรับแต่งการแปลงข้อมูล เพื่อให้หน้าตาและประสบการณ์ใช้งานสอดคล้องกัน
  • ฟีเจอร์โซเชียลของ IndieWeb reader แบบเต็มรูปแบบไม่ใช่สิ่งที่จะทำ
    • การเปิดแท็บอื่นเพื่อไปคอมเมนต์ไม่ใช่ปัญหา
    • ไม่เป็นไรหากคอนเทนต์กระจายอยู่บนเว็บไซต์ของบุคคลที่สาม
  • เป้าหมายระยะสั้นคือทดสอบให้เร็วว่าเครื่องมือนี้จะเป็นแหล่งข้อมูลหลัก หรือแม้แต่แหล่งเดียวบนเว็บได้หรือไม่ ถ้าไม่ได้ก็จะพับโปรเจกต์ทันที

หลักการพัฒนาและขอบเขต

  • หลักการพัฒนาคือ user > ops > dev
    • ในการจัดลำดับงานและการตัดสินใจด้านดีไซน์ จะเลือก ความสะดวกในการดูแลระบบ มากกว่าความสะดวกในการพัฒนา
    • และเหนือสิ่งนั้นคือ ประสบการณ์ผู้ใช้
  • เพราะเป็นแอปส่วนตัว คำว่า “ผู้ใช้มาก่อน” จึงหมายถึงการใช้งานเองจริง ๆ (dogfooding) และตอบโจทย์ความต้องการของตัวเองก่อน
  • มองว่าการสร้างเครื่องมือที่เข้ากับสรีรศาสตร์ของตัวเอง น่าจะมีประโยชน์มากกว่าการสมมติผู้ใช้ในอุดมคติขึ้นมา
  • โปรเจกต์นี้ไม่ควรเป็นโปรเจกต์เพื่อเรียนรู้หรือทำพอร์ตโฟลิโอ
    • เป้าหมายไม่ใช่ประสิทธิภาพการทำงาน แต่คือการกลับไปเชื่อมต่อกับความสนุกของการพัฒนาซอฟต์แวร์
    • และความสนุกนั้นควรมาจาก “การได้ใช้สิ่งที่สร้างเอง” มากกว่าการ “แค่สร้างอะไรสักอย่าง”
  • การสมมติว่ามีผู้ใช้เป้าหมายเพียงคนเดียว ทำให้เลื่อนการตัดสินใจหลายอย่างออกไปได้
    • ระบบยืนยันตัวตนที่ยังไม่จำเป็นสามารถเก็บไว้ทีหลัง
    • ฟีเจอร์เฉพาะทางมากอย่างการส่งเข้า Kindle สามารถทำตั้งแต่ช่วงแรกได้
    • สิ่งอย่างการปรับแต่ง feed parser หรือการล็อกอิน Mastodon สามารถตั้งสมมติฐานได้ว่าผู้ใช้มีความรู้การเขียนโปรแกรม

การเลือก UI และสถาปัตยกรรม

  • เพื่อให้เข้าถึงได้ทั้งบนโน้ตบุ๊กและมือถือ จึงต้องเป็น เว็บแอปพลิเคชัน
    • เป็นวิธีที่คุ้มค่าในการรองรับสองอุปกรณ์ด้วยอินเทอร์เฟซเดียว
    • ใช้ HTML และ CSS ที่คุ้นเคยได้
    • เก็บสถานะไว้ฝั่งเซิร์ฟเวอร์เพื่อแก้ปัญหาการซิงก์ข้ามอุปกรณ์ได้
  • Web UI จำเป็นต้องมีความไดนามิกอยู่บ้าง แต่ไม่ต้องการแอปฟรอนต์เอนด์แยกต่างหาก หรือเรียนรู้เฟรมเวิร์กใหม่
  • ตามคำแนะนำเรื่อง boring tech และ radical simplicity จึงมองหาไลบรารีเรนเดอร์ฝั่งเซิร์ฟเวอร์ และเลือกใช้ htmx ร่วมกับ hyperscript
  • เพื่อให้เป็นมิตรต่อการดูแลระบบ การดีพลอยและการตั้งค่าบนเครื่องควรทำได้ง่าย และไม่อยากตั้งต้นจากโครงสร้างพื้นฐานอย่าง Docker หรือ Nix
  • IndieWeb reader แบบเต็มที่ Aaron Parecki อธิบายไว้ แยกเป็นหลายคอมโพเนนต์ตามโปรโตคอลอย่าง Micropub, Microsub, Webmentions แต่สำหรับการใช้งานส่วนตัวแล้ว มีแต่เพิ่มความซับซ้อนทั้งด้านพัฒนาและปฏิบัติการโดยไม่ได้ประโยชน์มากนัก
  • สุดท้ายจึงเลือก เว็บแอปแบบโมโนลิธิก และใช้ SQLite เป็นฐานข้อมูลเพื่อลดจำนวนคอมโพเนนต์ที่ต้องติดตั้งและตั้งค่า

ภาษาและงานเบื้องหลัง

  • Go ดูเหมาะกับโปรเจกต์นี้ เพราะเรียบง่าย ใช้งานได้กว้าง มี garbage collection เร็วพอ มีโมเดล concurrency ที่ดี และแจกจ่ายเป็นไบนารีได้ง่าย
  • แต่ยังไม่เคยเขียน Go เลยแม้แต่บรรทัดเดียว และไม่อยากให้โปรเจกต์กลายเป็นโปรเจกต์เพื่อการเรียนรู้
  • จึงเลือก Python ซึ่งเป็นภาษาที่คุ้นเคยและสร้างต้นแบบได้เร็วที่สุด
  • จุดอ่อนของ Python คือเรื่อง environment และ dependencies โดยเฉพาะการพึ่งพาไลบรารีของ host OS
  • สำหรับการดึงฟีดตามรอบเวลา ไม่อยากเพิ่มคอมโพเนนต์แยกอีกตัว จึงศึกษาจนมาลงที่ gevent และ ส่วนขยาย mini-huey ของ Huey เพื่อรันงานเบื้องหลังภายใน process ของแอปพลิเคชันเอง
  • ข้อดีคือ Python มีไลบรารีดี ๆ ให้ใช้กับ HTTP, feed parsing และ scraping

เหตุผลที่เลื่อนการเขียนเทสต์

  • ในช่วงแรกตั้งใจว่าจะไม่เขียนเทสต์
  • เพราะวางแผนจะทดลองเพิ่ม ลบ และย้ายฟีเจอร์อยู่เรื่อย ๆ จึงมองว่าต้นทุนการดูแล unit test สูงเกินกว่าคุณค่าที่ได้
  • ยอมรับบั๊กลอจิกเล็ก ๆ ได้ และเพราะเป็นแอปที่ใช้งานเองทุกวัน จึงคาดว่าบั๊กสำคัญจะค่อย ๆ โผล่ออกมาตามเวลา
  • มองว่า integration test มีคุณค่ามากกว่าในแง่การสร้างความเชื่อมั่น แต่บั๊กจำนวนมากของโปรเจกต์นี้มาจากการเชื่อมต่อกับแหล่งข้อมูลภายนอกและจาก UI
  • แม้ integration test อาจช่วยจับบางบั๊กและ regression ได้เร็วกว่านี้ แต่ก็ยังไม่คุ้มกับต้นทุนเริ่มต้นในมุมมองของเขา

การใช้งานจริงที่พาฟีเจอร์ไปข้างหน้า

  • การใช้งานทุกวันในฐานะผู้ใช้ปลายทางเอง เป็นตัวกำหนดไอเดีย การทดลอง และลำดับความสำคัญ
  • หลังจากลองหลายเลย์เอาต์ UI และหลายฟีเจอร์ รูปแบบการใช้งานก็เริ่มนิ่ง
    • เปิดแอป
    • เลื่อนฟีดหลัก
    • ปักหมุดรายการไว้อ่านทีหลัง
    • เปิดรายการที่อยากอ่านตอนนี้
    • bookmark รายการที่อยากอ้างอิงภายหลัง
  • ต้องการฟีเจอร์อ่านบทความโดยไม่ออกจากแอป และเหตุผลหนึ่งคือเพื่อหลีกเลี่ยง paywall กับป๊อปอัปขอความยินยอม
  • ได้ลองใช้ไลบรารี Python หลายตัวเพื่อดึงเนื้อหา HTML ออกมา แต่ไม่มีตัวไหนทำงานได้ดีเท่า readability ที่ Firefox ใช้
  • เพราะ readability เป็นแพ็กเกจ JavaScript จึงต้องเพิ่ม Node.js เป็น dependency แบบเลือกใช้

การจัดเรียงฟีดและการทำเครื่องหมาย “เคยเห็นแล้ว”

  • แม้จะมีฟังก์ชันพื้นฐานครบแล้ว แต่การเรียงตามวันที่เผยแพร่อย่างเดียวก็ยังทำให้หาเนื้อหาน่าสนใจได้ยาก
    • โพสต์บล็อกที่ออกไม่บ่อยมักถูกกลบด้วย toot จาก Mastodon
    • บทความยาวจากนิตยสารมักถูกกลบด้วยข่าวรายวัน
  • เพราะทุกแหล่งที่ติดตามล้วนเป็นแหล่งที่สนใจอยู่แล้ว จึงตั้งสมมติฐานว่าอยากเห็นคอนเทนต์จาก แหล่งที่เผยแพร่ไม่บ่อย ก่อน
  • ถ้าจดหมายข่าวรายเดือนเพิ่งออกมาในช่วงไม่กี่วันที่ผ่านมา ก็ควรอยู่เหนือไมโครบล็อกกิงหรือข่าวรายวัน
  • จัดแหล่งข้อมูลเป็น “frequency buckets” และเรียงฟีดโดยให้ bucket ที่มีความถี่ต่ำกว่าแสดงก่อน
  • เพื่อหลีกเลี่ยงปัญหาที่คอนเทนต์หายากจะค้างอยู่บนสุดทุกครั้งที่เปิดแอป ก็เพิ่มฟีเจอร์ทำเครื่องหมาย “already seen” ให้อัตโนมัติเมื่อเลื่อนหน้าจอ
  • วิธีนี้ทำให้เห็นคอนเทนต์ใหม่อยู่เสมอ โดยไม่พลาดอัปเดตที่ออกไม่บ่อย

จากเครื่องโลคัลไปสู่ VPS

  • ตอนแรก รันแอปไว้ในแท็บเทอร์มินัลบนโน้ตบุ๊ก พร้อมทั้งพัฒนาและใช้งานไปด้วย
  • เมื่อเริ่มชอบคอนเทนต์ที่แสดงในฟีด ก็ย้ายขึ้นไปไว้บนเซิร์ฟเวอร์ Raspberry Pi ในเครือข่ายภายในบ้าน เพื่อให้เข้าถึงได้ตลอดเวลา
  • เมื่อใช้งานบน Raspberry Pi อย่างต่อเนื่อง ก็ปรับปรุง การเรนเดอร์บนมือถือ เพื่อให้เข้าถึงจากโทรศัพท์ได้ดีขึ้น
  • พอถึงจุดที่ออกไปข้างนอกแล้วยังคิดถึงแอปนี้ ก็เลยดีพลอยขึ้น VPS
  • การดีพลอยบน VPS บังคับให้ต้องเพิ่มระบบยืนยันตัวตนและรองรับผู้ใช้หลายคนที่เลื่อนมานาน และทำให้สามารถให้เพื่อนบางคนเข้ามาช่วยเบต้าเทสต์ได้
  • การตั้งค่า VPS ยังกลายเป็นจุดเริ่มต้นให้ซื้อโดเมนและสร้างเว็บไซต์นี้ขึ้นมา และเป็นอีกก้าวหนึ่งที่เข้าใกล้อุดมคติแบบ IndieWeb ซึ่งเป็นแรงบันดาลใจแรกเริ่ม

ผลลัพธ์ของ feedi

  • หลังจากค่อย ๆ ทำอยู่ประมาณ 3 เดือน ก็สร้างฟีดรีดเดอร์ส่วนตัว feedi ขึ้นมาได้
  • feedi ไม่ได้เป็นผลิตภัณฑ์ที่เสร็จสมบูรณ์ แต่คล้ายเครื่องมือที่เหมือนการตั้งค่า Emacs ซึ่งยังพังกึ่ง ๆ อยู่ตลอด แต่ก็ใช้งานจนติดตัว
  • หากมองในแง่ productivity มันอธิบายความคุ้มค่าได้ยาก แต่ก็ให้ความพอใจเพราะเป็นเครื่องมือที่ทำมาให้ตรงกับเงื่อนไขของตัวเอง
  • ใช้ feedi เป็น “front page of the internet” อยู่หลายเดือน
  • การใช้รีดเดอร์ส่วนตัวทำให้กลับมาควบคุมข้อมูลที่เสพได้อีกครั้ง และทำให้ค้นหาบล็อกกับนิตยสารที่น่าสนใจอย่างกระตือรือร้นมากขึ้น พร้อมเปิดรับการค้นพบและความประหลาดใจได้ดีขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-15
ความเห็นจาก Hacker News

  • การตั้งค่า urlwatch(https://urlwatch.readthedocs.io/en/latest/) ไว้ค่อนข้างสนุกทีเดียว โดยเฉพาะเมื่อข้าม Puppeteer boilerplate ไปได้และดึงเว็บไซต์ที่ใช้ JavaScript ผ่าน Chrome instance ได้ มันให้ความรู้สึกเหมือนควบคุมให้เว็บไหลเข้ามาหาเรา แทนที่จะต้องคอยดึงไปดูเอง
    การเฝ้าดูเว็บไซต์แบบไม่ต้องเปลืองแรงแล้วมาไล่ดูตอนเช้ามันทรงพลังมาก ติดตามได้ทั้งประกาศรับสมัครงานของบริษัทที่ชอบ งานเปิดรับ/ปิดรับของบริษัทปัจจุบัน สินค้าที่รอลดราคา·กลับมาสต็อก·รีเฟอร์บิช สถิติน้ำเสียโควิด รายการขายอพาร์ตเมนต์ GitHub release ที่สนใจ ไปจนถึงการเปลี่ยนแปลงเงื่อนไขการใช้งานของเว็บไซต์สำคัญ
    ส่วนตัวผมก็ self-host ทั้ง RSS reader และบอต Telegram และยังทำเว็บ HTTP เล็ก ๆ ไว้ทดลองบ่อย ๆ เลยใช้ DigitalOcean $5 Droplet แต่เพราะไม่จำเป็นต้องรันเวลาเดิมทุกวัน จึงทำบนแล็ปท็อปก็ได้

    • ผมทำ Feed me up, Scotty!(https://feed-me-up-scotty.vincenttunru.com/) ไว้ใช้กับเรื่อง “รายการขายอพาร์ตเมนต์” แทนที่จะส่งแจ้งเตือนทางอีเมล ก็ใช้ GitHub Actions สร้าง RSS feed จาก CSS selector ไม่กี่ตัว
    • คล้ายกัน ผมใช้ Playwright เป็น headless browser เพื่อล็อกอินเข้า Twitter วันละหลายครั้ง แล้วดึงข่าวกับอัปเดตจาก saved search
      เพราะเป็นของใช้ส่วนตัว ผมเลยรับแค่สรุปอัปเดต Twitter ในหัวข้อที่สนใจได้ และหลีกเลี่ยงทั้งตัวเว็บไซต์เอง การถกเถียงรุนแรง และโฆษณาน่ารำคาญ

  • ตอนนี้สภาพ IT ทำให้ผมหงุดหงิดมากจนเรียบเรียงออกมาได้ไม่ดีนัก แต่บางทีก็จินตนาการถึงแนวคิด “เจ้าหน้าที่ IT ประจำตัว” อยู่เหมือนกัน เป็นคนที่ช่วยดูแลชีวิตดิจิทัลบางส่วนของเรา เหมือนช่างตัดผมประจำ แพทย์ประจำตัว ช่างตัดเสื้อ หรือคนทำขนมปังแถวบ้าน
    เขามีโครงสร้างพื้นฐานเล็ก ๆ ในระดับท้องถิ่น ทำฟีดแบบปรับตามบุคคล ดูแลความเป็นส่วนตัวและสุขภาวะดิจิทัล และเชื่อมต่อกับ feed reader ผ่านอินเทอร์เฟซเรียบง่ายหรือโปรโตคอลเปิด จัดการได้ทั้งหนัง บทความ มีม และคลิปสนุก ๆ แต่ประเด็นสำคัญคือมีมนุษย์ที่คุยกันได้ ไม่ใช่ อัลกอริทึมที่ปรับให้เหมาะกับรายได้สูงสุด
    ผมนึกถึงไอเดียอย่างศูนย์ข้อมูลที่ชุมชนท้องถิ่นช่วยกันดูแลแบบห้องสมุด หรือการให้บริการคอนเทนต์ง่าย ๆ ผ่านอินเทอร์เน็ตที่บ้าน เพราะแบบนี้จึงชอบแนวคิดอย่าง Veilid(https://gitlab.com/veilid/veilid)
    และนี่ก็ไม่ใช่ครั้งแรกที่ได้ยินว่าคนย้ายไป Feediverse แล้วสุขภาพจิตดีขึ้น ตอนนี้ผมเองก็กำลังวางสคริปต์และมินิแอปทับบน Puppeteer แล้วให้ local llamacpp ช่วยสรุปและแนะนำ และอยากขัดเกลาให้ดีขึ้นเพื่อเอาไปแนะนำเพื่อนกับครอบครัวในอนาคต
    ผมตั้งชื่อสคริปต์เหล่านี้ว่า “not a browser” เพราะผมอยากได้เว็บที่ไม่ได้เสิร์ฟ HTML/CSS/JS พร้อมข้อมูล แต่เสิร์ฟแค่ข้อมูล แล้วให้ผู้ใช้เป็นคนกำหนดเองว่าจะแสดงผลอย่างไร

    • ผมอินกับความรู้สึกนั้นมาก ช่วงนี้เพิ่งตั้ง โฮมแล็บเซิร์ฟเวอร์ แล้วรันเว็บแอปหลายตัวที่มีฟังก์ชันต่างกัน ถึงจะไม่มีอะไรใหม่ แต่ชอบตรงที่ทุกอย่างยึดผู้ใช้เป็นศูนย์กลาง และอิงโอเพนซอร์ส/ชุมชน
      ไม่มีอัลกอริทึมที่เป็นปฏิปักษ์ต่อผู้ใช้ ไม่มีระบบที่ขับเคลื่อนด้วยโฆษณา และโดยมากเป็นซอฟต์แวร์ที่ให้ความสำคัญกับผู้ใช้ก่อน พร้อมพูดถึงโปรโตคอลเปิด ถ้าคุณทำงานอยู่ในวงการ IT และดูแลเซิร์ฟเวอร์เองได้ก็ทำได้ แต่ปัญหาคือแล้วคนที่ไม่ใช่แบบนั้นจะทำอย่างไร
      ไอเดียเรื่อง “เจ้าหน้าที่ IT ประจำตัว” น่าสนใจมาก ผมสงสัยว่าจะให้บริการแบบนี้กับคนที่อยากหนีจากบริษัทยักษ์ใหญ่ด้านเทคโนโลยีและอัลกอริทึม ไปใช้สิ่งที่เป็นส่วนตัวมากขึ้นแต่ไม่มีความสามารถทางเทคนิคได้หรือเปล่า
      ข้อมูลสุขภาพก็คล้ายกัน ผมไม่ชอบที่เวชระเบียนของผมถูกเก็บอยู่ใน MyChart และระบบปิดแบบ proprietary อีกหลายระบบโดยที่ผมไม่มีอำนาจควบคุม ในกระเป๋าผมมีซูเปอร์คอมพิวเตอร์อยู่เครื่องหนึ่ง แล้วทำไมผมถึงเก็บสำเนาบันทึกของตัวเองไว้ไม่ได้ และเลือกแชร์กับหมอเฉพาะตอนพบแพทย์ไม่ได้ ผมไม่เข้าใจจริง ๆ
      การที่โรงพยาบาลยังต้องส่งแฟกซ์หากันก็ยังดูประหลาด ควรมีปุ่มเดียวให้ผมแชร์ข้อมูลของตัวเองได้ Apple Health ดูจะใกล้เคียงที่สุดในบางด้าน แต่ดูเหมือนในสหรัฐฯ จะยังแทบไม่ถูกนำไปใช้ และถึงอย่างนั้นก็เอื้อประโยชน์กับผู้ใช้ Apple เท่านั้น ข้อมูลสุขภาพ ไม่ควรถูกขังอยู่ในระบบปิด ถึงจะเป็นรูปแบบแบบ Apple Health ที่รันอยู่บนเครื่องก็เถอะ จำเป็นต้องมีโปรโตคอลเปิดและระบบนิเวศของ implementation
    • เห็นด้วย 100% สภาพ IT ตอนนี้ชวนให้หงุดหงิดจริง ๆ
      ก่อนที่การตลาดและความโลภจะยึดครองอินเทอร์เน็ต มันเคยมีช่วงเวลาสั้น ๆ ที่โอเคอยู่เหมือนกัน ถ้ามีรูปแบบอย่างผลิตภัณฑ์ Synology NAS ที่มีแอปซึ่งเป็นประโยชน์กับผู้ใช้ปลายทาง และมี “เจ้าหน้าที่ IT ประจำตัว” คอยช่วยอยู่ด้วย มันอาจเวิร์กได้ดี
      ถ้าไม่ได้ออกแบบมาเพื่อรีดข้อมูลส่วนตัวกับเงินจากผู้ใช้ มันคงเกือบเหมือนยูโทเปียจากมุมมองผู้ใช้ แต่ในเชิงธุรกิจน่าจะเป็นกิจการที่มาร์จินต่ำและความเสี่ยงสูง เช่น เรื่องความรับผิดชอบหากไฟล์สูญหาย
    • แนวคิด “เจ้าหน้าที่ IT ประจำตัว” โดนใจมาก และดูเหมือนว่า ภายใน 5~10 ปีข้างหน้าอาจกลายเป็นจริง ได้ด้วย เพียงแต่ผมสงสัยว่าคงต้องมีคนลองทำไปแล้ว และอะไรคือปัจจัยที่ขัดขวางมันอยู่จนถึงตอนนี้
    • ไอเดียนี้สวยงามและน่าดึงดูดมาก แต่ดูเหมือนว่าเทคโนโลยีนี้โดยเนื้อแท้แล้วเกี่ยวกับ แรงทดและขนาด จึงไม่ได้ไหลไปในทิศทางนั้น
      มันคือโครงสร้างที่เขียนโค้ดครั้งเดียวแล้วรันได้เป็นล้านครั้งโดยแทบไม่มีต้นทุนเพิ่มเลย เหมือนแรงเชิงโครงสร้างทั้งหมดจะทำงานไปในทิศทางตรงกันข้าม บางทีถ้า AI มาแทนงานของเราทั้งหมดแล้ว มันอาจกลับเป็นไปได้มากขึ้นก็ได้

  • How to Do Nothing ของ Jenny Odell เป็นหนังสือที่ยอดเยี่ยมมาก อาจไม่ตรงกับกลุ่มผู้อ่านทั่วไปของ Hacker News นัก แต่ถ้าคุณเริ่มรู้สึกถึงแรงกดดันจาก “ความผลิตภาพ” ปลอม ๆ ที่เศรษฐกิจความสนใจยัดเยียดให้ ขอแนะนำอย่างยิ่ง
    โปรเจกต์อื่น ๆ ของ Jenny Odell ก็น่าดูเช่นกัน เช่น The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)

    • ใช่เลย แต่หนังสือเล่มนี้ไม่ใช่อะไรแนว “digital detox” เพื่อเพิ่ม productivity หากแต่ใกล้เคียงกับ วาทกรรมเชิงปรัชญา มากกว่า
      ในบริบทเดียวกัน ขอแนะนำ Saving Time ของ Jenny Odell ด้วย เป็นหนังสือที่เงียบ ๆ แต่หัวก้าวหน้ามาก และส่วนตัวผมชอบมากกว่าในสองเล่มนั้น เพราะการเล่าเรื่องกระชับมีจุดโฟกัสมากกว่า
    • เห็นด้วย ผมซื้อฉบับกระดาษมาอ่านแล้วส่งต่อให้ครอบครัว และไม่นานมานี้ก็ซื้อเวอร์ชันหนังสือเสียงบน Libro.fm อีกรอบ

  • นอกเหนือจากฟีดส่วนตัวแบบธรรมดาแล้ว อยากได้ ฟีดที่มีการจำกัดเวลาและไม่มีสิ่งรบกวน
    ถ้ารวบรวมคอนเทนต์ที่เป็นบทความทั้งหมดที่ฉันติดตามไว้ แล้วช่วยคัดรายการให้พอดีกับปริมาณอ่านวันละราว 30 นาทีได้ก็คงดี ควรรวมทั้งหมดทั้งบทความบล็อก ข่าว ทวีต ฯลฯ
    ไม่ว่าจะใช้ ChatGPT หรือเครื่องมืออื่น ก็อยากให้ช่วยกรองคอนเทนต์ที่ “มีคุณค่าทางสาระ” มากที่สุด และให้ความสำคัญกับเนื้อหาที่มีคุณค่ามากกว่าการทะเลาะกันด้วยคำพูด หลังจากนั้นก็อยากส่งไปที่ Kindle หรือแท็บเล็ต reMarkable เพื่ออ่านแบบห่างจากสีสัน แสงวิบวับ และอินเทอร์เน็ตความเร็วสูง
    ขั้นถัดไปคืออยากสมัครรับฟีดของเพื่อน แล้วรับคอนเทนต์ “รับเชิญ” จากฟีดนั้นเป็นครั้งคราวด้วย

    • ฉันลองทำ side project แนวนี้มาเล็กน้อยแล้ว อยากรู้ว่าคุณสนใจลองใช้เบต้าไหม
      ฉันชอบไอเดียการเพิ่มสรุปโดย GPT และถ้าคนอื่นสนใจด้วยก็อาจจัดระเบียบแล้วนำมาแชร์ได้ ตอนนี้ยังเป็นแอป JavaScript เรียบง่ายที่ใช้ในเครื่องตัวเอง แต่ไอเดียนี้ดูเจ๋งกว่าที่คิดไว้ตอนแรก
    • นี่เชื่อมโยงกับวิสัยทัศน์บางอย่างเกี่ยวกับอินเทอร์เน็ตยุคแรกและ agent คือแนวคิดที่ให้โปรแกรมท่องอินเทอร์เน็ตแทนผู้ใช้และทำงานที่มีประโยชน์ให้
      น่าจะเป็น Douglas Engelbart แต่ฉันหาข้อมูลเกี่ยวกับ agent ไม่เจอ อาจเป็นผู้เชี่ยวชาญด้านเทคโนโลยีคนอื่นก็ได้

  • ฉันสังเกตเห็นและเห็นด้วยกับการตัดสินใจอย่างตั้งใจที่จะไม่ทำ automated test ในช่วงแรก ใช้เวลาพอสมควรกว่าจะข้ามความรู้สึกไม่สบายใจจากการไม่มี test ได้ แต่ตอนนี้สำหรับโปรเจกต์เล่นๆ ส่วนตัว ฉันก็ใช้วิธีคล้ายกัน
    มีหลายโปรเจกต์มากที่ตายตั้งแต่วันแรกๆ ทั้งที่ควรเป็นช่วงสร้างแรงส่ง เพราะมัวแต่ไปทำ test infrastructure กับ CI pipeline แล้วหมดไฟ
    ตอนนี้ฉันทำโดยยึดหลักว่า ถ้า การไม่มี test กลายเป็นปัญหาจริง ค่อยเพิ่มทีหลัง

    • ลืมกันได้ง่ายว่าแนวปฏิบัติที่ดีในการพัฒนานั้นเป็น ฟังก์ชันของขนาด
      สิ่งที่จำเป็นสำหรับโปรเจกต์ที่โตเต็มที่ มีนักพัฒนาหลายคน และมี codebase ขนาดใหญ่ อาจกลายเป็นภาระเกะกะสำหรับโปรเจกต์เล็กๆ ที่ทำคนเดียว
    • สำหรับโปรเจกต์ส่วนตัว ฉันจะเริ่มเขียน test ก็ต่อเมื่อติดจุดที่ทำให้ถูกต้องได้ยากจริงๆ ก่อนหน้านั้นจะไม่เขียน
      หลังจากนั้นก็จะเน้นเพิ่ม test แบบเฉพาะหน้าเมื่อมีปัญหาเกิดขึ้น
    • โดยรวมเห็นด้วย แต่ก็ขึ้นอยู่กับลักษณะของแอปพลิเคชันด้วย
      เมื่อหลายปีก่อน ฉันทำเครื่องวิเคราะห์ก๊าซหายใจเป็นโปรเจกต์ส่วนตัว และเขียนซอฟต์แวร์ที่เชื่อมต่อผ่าน Bluetooth เพื่อแสดงข้อมูลแบบเรียลไทม์ สำหรับฟังก์ชันที่ต้องคำนวณทางวิทยาศาสตร์ให้แม่นยำ unit test มีประโยชน์มาก แต่พอมาย้อนดูแล้ว การทดสอบส่วนอื่นของอินเทอร์เฟซแทบเสียเวลาเปล่า
      พอมั่นใจว่าฟังก์ชันนั้นจะไม่เปลี่ยนอีกแล้ว ฉันก็ลบ test ออกทั้งหมด ตอนพัฒนาคนเดียว บางครั้งการทดสอบด้วยมืออย่างเดียวก็เพียงพอ

  • ฉันสร้างบัญชีนิรนามใหม่เพื่อจะพูดเรื่องอนาคตอย่างตรงไปตรงมา
    ฉันตกใจที่บทความนี้เหมือนตัวฉันในอนาคตเป็นคนเขียน มันมีจุดร่วมกับผู้เขียนมากเกินกว่าจะเชื่อ
    ฉันเพิ่งตระหนักถึงภาวะหมดไฟและกำลังวางแผนจะลาออกช่วงต้นปีหน้า เหตุผลที่สร้างบัญชีนิรนามก็เพราะเรื่องนี้ คิดว่าน่าจะมีหลายคนที่รู้สึกคล้ายกัน
    ที่น่าทึ่งยิ่งกว่าคือ สิ่งที่ผู้เขียนทำแทบจะตรงกับสิ่งที่ฉันจินตนาการอยากลองทำตอนพักงานพอดี ฉันเคยคิดว่าจะเข้าไปมีส่วนร่วมกับ Open Web/IndieWeb อย่างไร และวางแผนจะทำแอปเพื่อทดลองในพื้นที่นี้
    แม้แต่เรื่องกังวลทางเทคนิค เช่น ปัญหาว่าจะทำอย่างไรไม่ให้โพสต์ที่ออกไม่บ่อยถูกกลบในกระแสข้อมูลท่วมท้น หรือจะใช้ภาษาและเทคโนโลยีอะไร ก็คล้ายกัน เว็บดีเวลอปเมนต์ของฉันล้าหลังไปประมาณ 10 ปีแล้ว แต่ก็เคยคิดว่าจะลองสร้างอะไรบางอย่างด้วยเทคโนโลยีเว็บสมัยใหม่
    ด้านหนึ่งฉันดีใจที่ความคิดและความรู้สึกช่วงหลังเหมือนได้รับการยืนยัน รู้สึกว่าตัวเองกำลังไปถูกทาง แต่อีกด้านหนึ่งก็หงุดหงิดและยังอิจฉาที่ผู้เขียนทำสำเร็จก่อน

    • ไม่รู้ว่าจะช่วยปลอบใจหรือทำให้หงุดหงิดกว่าเดิม แต่ฉันเคยสร้างอะไรคล้ายๆ กันนี้เมื่อ 20 ปีก่อน และยังใช้อยู่ทุกวันจนถึงตอนนี้
      ตอนนั้นฉันอยากได้ RSS reader ของตัวเอง ฉันไม่ชอบตัวอ่านที่มีอยู่ และอยากได้ reader ที่หน้าตาเหมือนบล็อกธรรมดามากกว่ากล่องจดหมาย พร้อมปรับดีไซน์ได้ตามใจ เลยสร้างตัว parser สำหรับ RSS feed แล้วออกแบบให้ดูเหมือนบล็อกปกติของตัวเอง
      หลังจากนั้นฉันก็ปรับให้ถ้า RSS feed มีแค่สรุป ก็ไปดึงข้อความเต็มมา ฉันไม่อยากคลิกออกจาก reader เพื่อไปดูข้อความเต็ม แต่อยากให้ทุกอย่างอยู่ใน feed reader หมด พอมีตัว scraper พื้นฐานแล้ว ก็เอาไปใช้กับเว็บที่ไม่มี RSS ด้วย และมันช่วยได้มากโดยเฉพาะตอนโซเชียลมีเดียเริ่มบูม
      ฉันจึงดูเฉพาะคอนเทนต์ที่อยากดูได้จากในฟีดของตัวเองโดยไม่ต้องเข้าเว็บโซเชียลจริงๆ มันเป็นของอายุ 20 ปีแล้ว ใช้เทคโนโลยีเก่าอย่าง PHP กับ XSLT และจนถึงตอนนี้ก็ยังเหมือนเดิม
      ยังไงก็ตาม ฉันแนะนำอย่างยิ่งให้ลองทำเอง มันเป็นโปรเจกต์ที่สนุก ถึงจะเก่า ดิบ และการ scrape ก็ไม่สมบูรณ์จนบางทีดึงคอนเทนต์ที่ต้องการมาไม่ได้ แต่ก็เป็นของฉันเอง และฉันชอบมันเพราะเป็น reader ที่ใช้ทุกวันมาตลอด 20 ปี
    • ไม่จำเป็นต้องอิจฉาที่ผู้เขียนทำก่อน ประเด็นสำคัญคือการสร้างมันขึ้นมาเพื่อตัวเอง และใช้กระบวนการนั้นทบทวนตัวเอง
      ต่อให้ลองทำสิ่งคล้ายกัน ก็ไม่มีเหตุผลว่ามันจะไร้ผล คุณเองก็ไม่ใช่คนแรกที่สร้าง personal reader
      ที่น่าสนใจคือ พอกลับไปไล่อ่านโพสต์ IndieWeb ที่ฉันเคยลิงก์ไว้อีกครั้ง ก็รู้สึกว่าตัวเองแทบจะพูดซ้ำไอเดียในนั้นตรงๆ เป็นคำแนะนำทำนองว่า “อย่าพยายามสร้างซอฟต์แวร์สำหรับทุกคน แต่จงสร้างเพื่อตัวเอง”
      ถ้าพยายามทำให้มันเป็นแบบทั่วไปและใช้งานง่ายสำหรับคนอื่น คุณอาจต้องประนีประนอมจนบั่นทอนการใช้งานสำหรับตัวเอง หรือไม่ก็เผลอออกแบบเพื่อผู้ใช้ในจินตนาการที่ไม่มีอยู่จริง ความหมายคือให้สร้างอย่างเห็นแก่ตัวเพื่อให้มันมีประโยชน์กับตัวเองมากขึ้น

  • สดใหม่มากจริงๆ ตลอด 1 ปีที่ผ่านมา ฉันผ่านเส้นทาง หมดไฟ/ฟื้นตัว ที่คล้ายกันมาก และการสร้างซอฟต์แวร์ใช้ส่วนตัวที่มีประโยชน์ก็ทำให้ฉันกลับมาสนุกกับงานได้อีกครั้ง
    ข้อดีใหญ่อีกอย่างคือได้ลองใช้เทคโนโลยี “นอกกระแส” ที่ตัวเองอยากใช้ได้เต็มที่ อย่างการทำไฟล์รัน PHP แบบ single binary สมัยใหม่ ใช้ SQLite ใน production หรือ deploy โดยไม่ใช้ Docker ซึ่งล้วนให้ความสนุก
    งานแบบนี้ยังส่งผลต่อเนื่องมาถึงงานประจำด้วย หลายครั้งฉันค้นพบเทคนิคและการปรับแต่งใหม่ๆ จาก repository ส่วนตัว แล้วนำกลับไปใช้ในงานหลัก

    • มีหลายช่วงที่เหมือนกำลังพูดถึงฉันอยู่
      มันน่าสนใจที่คนสายเทคมักชอบไปลองจับนู่นจับนี่เป็น side project แล้วเอาสิ่งที่เรียนรู้จากตรงนั้นกลับมาใช้กับงานในรูปแบบที่เป็นประโยชน์ และบางครั้งก็มีคุณค่าจริง แต่บางทีนายจ้างก็กลับลดคุณค่าความพยายามแบบนั้นหรือขัดขวางความกระตือรือร้น
      อาจเป็นเพราะฉันเคยทำงานอยู่ในองค์กรผิดประเภทก็ได้ ถึงอย่างนั้นก็ดีใจที่คุณได้รับประโยชน์จากผลต่อเนื่องแบบนั้น

  • ชอบแนวคิดแบบฟีดมากกว่าการมีเช็กลิสต์ของสิ่งที่ต้องอ่าน/เสพ ฉันเคยลองใช้ RSS reader มาหลายตัวในช่วงหลายปีที่ผ่านมา แต่ไม่เคยปักหลักใช้นานนัก
    รู้สึกว่าไม่แน่ใจว่าจำเป็นต้องคอยจัดการ inbox เพิ่มมาอีกอันไหม ถึงอย่างนั้นก็คิดว่าจะลองดู feedi(https://github.com/facundoolano/feedi)

    • ฉันตรงกันข้ามเลย ถ้ามี RSS reader ก็สามารถจัดการของ “ใหม่” ได้อย่างรวดเร็ว แล้วค่อยไปหมกตัวแฮ็กอะไรสักพักได้
      ก่อนจะตั้งค่านี้ ฉันมักคลิกไปเรื่อยอย่างไร้จุดหมายว่ามีโพสต์ใหม่ใน HN ไหม ใน Reuters มีไหม ประสบการณ์ของฉันตรงกับ https://news.ycombinator.com/item?id=38642092
    • แทนที่จะมี “inbox เพิ่มมาอีกอัน” ฉันใช้ rss2email ให้ส่งรายการ RSS ที่ subscribe ไว้ทั้งหมดเข้าอีเมล
      ทั้งอีเมลส่วนตัว เมลลิงลิสต์ และ RSS feed จะมารวมอยู่ที่เดียว ถ้ากรองเป็นสปูลแยกกันและใช้ email client ที่ทรงพลังอย่าง mutt ร่วมด้วย ก็จะได้ประสบการณ์แบบรวมศูนย์ที่ค่อนข้างลื่นไหล

  • ดูเหมือนผู้เขียนจะเพิ่มการยืนยันตัวตนเพื่อให้เข้าถึงแอปได้จากทุกที่
    แต่อยากรู้ว่าถ้าเอาไว้หลัง VPN แล้วทำให้เข้าถึง VPN นั้นได้จากทุกที่ จะเป็นไปได้หรือทำได้ง่ายกว่าหรือเปล่า
    ฉันอยากเข้าถึงเว็บแอปส่วนตัวอย่างปลอดภัย และกำลังมองหาวิธีที่ง่ายที่สุด พอเห็นระบบยืนยันตัวตนทีไรก็รู้สึกเหมือนเป็นเขาวงกตของแนวคิด โปรโตคอล และไลบรารี และไม่อยากดูแลรักษามัน

    • วิธีที่ใกล้เคียงมาตรฐานและทำเรื่องนี้ได้ง่ายคือ Tailscale
      ฉันโฮสต์แอปอย่าง Home Assistant ไว้ไม่กี่ตัวบน Raspberry Pi ที่บ้าน และติดตั้ง Tailscale ทั้งบน Pi และโทรศัพท์ ซึ่งทำงานได้ดีมาก สิ่งที่ต้องยืนยันตัวตนมีแค่ “ล็อกอินเข้า Tailscale บนอุปกรณ์แต่ละเครื่อง” เท่านั้น
      ถ้าเป็นเรื่องความง่ายในการสร้างเครือข่ายที่ปลอดภัยระหว่างอุปกรณ์ของตัวเอง ฉันแนะนำ Tailscale แบบแรง ๆ เลย
    • สำหรับการใช้งานส่วนใหญ่ ฉันค่อนข้างพอใจกับ Basic HTTP authentication โชคดีที่ทุกวันนี้ยังรองรับกันแทบทุกที่
      มันเพียงพอสำหรับ “ป้องกัน” แอปของฉันที่ไว้โฮสต์แค่ข้อความบางส่วนที่คลิปมาจากเว็บไซต์อื่น
    • ทำได้แน่นอน แต่ถ้าคุณยังไม่ได้ใช้ VPN อยู่แล้ว ก็ไม่คิดว่าจะง่ายกว่าเท่าไร
      มีหลายวิธี แต่ใจความคือวาง VPN endpoint กับเว็บแอปไว้ที่เดียวกัน เช่น เครื่องเดียวกันหรือเครือข่ายเดียวกัน แล้วจำกัดการเข้าถึงเว็บแอปจากที่อื่นทั้งหมด
    • ฉันตั้งค่า WireGuard และ Caddy บนเซิร์ฟเวอร์ให้ทำงานร่วมกันผ่าน Docker
      Caddy จะ reverse proxy เฉพาะคำขอที่มาจากเครือข่ายภายในหรือจาก VPN เท่านั้น และถ้าไม่ใช่ก็ให้คืนค่า 404 ดังนั้นถ้าไม่ได้อยู่บน VPN หรือเครือข่ายที่บ้าน ก็จะไม่เห็นอะไรเลย
      คุณอาจต้องใช้ VLAN หรือเครือข่าย guest แยกต่างหาก ขึ้นอยู่กับว่าคุณเปิดเครือข่ายให้แขกใช้หรือไม่ และกำลังรันบริการอะไรอยู่ หลายบริการที่ฉันรันในบ้านก็มีการยืนยันด้วยรหัสผ่านของตัวเองอยู่แล้ว และใช้ร่วมกับการจำกัดผ่าน VPN
      การตั้งค่านี้เป็นวิธีที่ฉันนึกออกเป็นอย่างแรก จึงอาจไม่ปลอดภัยด้วยเหตุผลบางอย่างที่อยู่นอกความเชี่ยวชาญของฉัน ข้อดีคือฉันรัน Pi-hole ใน compose ไฟล์เดียวกันได้ด้วย เลยได้ตัวบล็อกโฆษณาระยะไกล “ฟรี” ไปด้วยเมื่อโทรศัพท์ต่อ VPN
      Tailscale ตั้งค่าง่ายกว่าและ UI ก็ดีกว่า แต่ฉันเลิกใช้เพราะมันกินแบตบน iOS มาก ประเด็นที่ต้อง “เชื่อใจเซิร์ฟเวอร์ของคนอื่น” ก็เป็นปัญหาเหมือนกัน แต่ถ้าไม่ติดเรื่องแบต ฉันก็คงยอมรับความเสี่ยงเพิ่มเพื่อแลกกับความสะดวก
      แอป WireGuard ก็มีฟีเจอร์สะดวก ๆ ด้วย เช่น ตั้งได้ว่าไม่ต้องทำงานบนบางเครือข่าย อย่างตอนอยู่บ้าน ทำให้ออกจากบ้านแล้วมันเปิดเองอัตโนมัติ และพอกลับบ้านก็ปิดเองได้

  • สิ่งนี้ใกล้เคียงอย่างน่าประหลาดกับสิ่งที่ฉันคิดว่าน่าจะต้องมีบนเรือยอชต์สำหรับล่องทะเล โดยเฉพาะนอกชายฝั่งที่การเชื่อมต่อมา ๆ หาย ๆ ถ้ามีเพิ่มอีกสองอย่างก็น่าจะใช่เลย
    ควรมีปุ่ม sync now สำหรับช่วงที่เชื่อมต่อได้ชั่วคราว เช่น ตอนแล่นผ่านเกาะที่มีสัญญาณ LTE และอีกอย่างคือตามค่าเริ่มต้นควรทำ Readability processing และ local cache เพื่อให้อ่านคอนเทนต์ทั้งหมดแบบออฟไลน์ได้ รวมถึงรูปภาพด้วย