ผมลองดาวน์โหลด Hacker News ทั้งหมดดู

 (jasonthorsness.com)
5 คะแนน โดย GN⁺ 2025-05-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างสร้าง hn.unlurker.com ได้เขียน HN API client และเพิ่มฟีเจอร์ scan สำหรับดึง item ทั้งหมดตามลำดับ จากนั้นดาวน์โหลดข้อมูล Hacker News ทั้งหมดมาไว้ในเครื่อง
  • ระหว่างรัน hn scan --no-cache --asc -c- -o full.json การดาวน์โหลดหยุดไปหลายครั้ง แต่ด้วย scan ที่สามารถทำต่อจากเดิมได้ จึงได้ไฟล์ JSON ขนาด 20 GiB หลังผ่านไปไม่กี่ชั่วโมง
  • ใช้ read_json_auto ของ DuckDB แปลง JSON เป็นตาราง แล้วใช้ SQL ที่มี text ILIKE และ ค่าเฉลี่ยเคลื่อนที่ 12 สัปดาห์ เพื่อสรุปสัดส่วนการกล่าวถึง Python, JavaScript, Java, Ruby, Rust
  • แค่ใช้ grep ธรรมดาก็พบว่าวลี “correct horse battery staple” ปรากฏใน Hacker News 231 ครั้ง และ DuckDB ดูเหมาะมากสำหรับการวิเคราะห์แบบครั้งเดียวกับข้อมูลขนาดนี้
  • เมื่อมีข้อมูลทั้งหมดในเครื่อง ก็สามารถวิเคราะห์คอนเทนต์เก่า ๆ ของ Hacker News ได้หลายรูปแบบ แต่โปรเจกต์นี้จบลงเพียงเท่านี้ และขั้นถัดไปคงเหลือไว้ให้คนอื่นมาสานต่อ

ดาวน์โหลด item ทั้งหมดของ Hacker News

  • เพื่อสร้าง hn.unlurker.com จึงเขียน HN API client
    • มี client หลายตัวอยู่แล้ว แต่ในโปรเจกต์ใหม่อยากลองใช้ ฟีเจอร์ Go รุ่นใหม่ ๆ และ linter
    • ใน HN API คอมเมนต์และสตอรี่ถูกเรียกว่า item
  • client สามารถดึง item ที่ active และรายการ item ต่าง ๆ ได้
    • ในโปรเจกต์จริงต้องใช้แค่ item ล่าสุด แต่เพื่อให้สมบูรณ์ยิ่งขึ้นจึงเพิ่มฟีเจอร์ scan
    • scan จะดาวน์โหลด item เรียงลำดับตั้งแต่ 0 ถึงล่าสุด หรือในทิศทางกลับกัน
  • คาดว่าการดาวน์โหลดทั้งหมดไม่น่าจะใหญ่ระดับหลายหมื่น GiB แต่เป็นประมาณ JSON หลายสิบ GiB จึงลองทำดู
hn scan --no-cache --asc -c- -o full.json
  • การดาวน์โหลดหยุดไปหลายครั้งจนต้องกด CTRL-C เพื่อหยุด แต่ scan สามารถทำต่อจากเดิมได้ จึงเสร็จหลังผ่านไปไม่กี่ชั่วโมง
  • ผลลัพธ์คือ ไฟล์ JSON ขนาด 20 GiB ที่บรรจุทุกอย่างที่เกิดขึ้นบน Hacker News
  • หากรันคำสั่งเดิมอีกครั้ง ก็สามารถเติมข้อมูลล่าสุดเข้าไปใหม่ได้

วิเคราะห์ข้อมูลในเครื่องด้วย DuckDB

  • ตอนแรกค้นหาด้วย grep แบบง่าย ๆ
    • วลี “correct horse battery staple” ปรากฏใน Hacker News 231 ครั้ง
    • กรณีล่าสุดที่ปรากฏคือ item ที่ถูกโพสต์ “วันนี้” ณ เวลาที่เขียน
  • จากนั้นลองวิเคราะห์ด้วย DuckDB
    • DuckDB เป็น เอนจินรันวิเคราะห์ ที่รวดเร็วและฝังในแอปได้ และยังมีให้ใช้เป็นเครื่องมือ command line
    • UI ใหม่ทำให้มือใหม่ใช้งานง่าย และ LLM ก็ช่วยเขียน SQL query ได้
  • นำข้อมูล JSON เข้า DuckDB ด้วยวิธีต่อไปนี้
CREATE TABLE items AS
SELECT *
FROM read_json_auto('/home/jason/full.json', format='nd', sample_size=-1);
  • query ตัวอย่างจะจัดกลุ่ม item รายสัปดาห์ และคำนวณสัดส่วนของ item ทั้งหมดที่มีคำเฉพาะอยู่
    • ค้นหา python, javascript, java, ruby, rust ด้วย text ILIKE
    • คำนวณ ค่าเฉลี่ยเคลื่อนที่ 12 สัปดาห์ สำหรับแต่ละสัดส่วน
  • ใช้วิธีเดียวกันนี้ทำ visualization สำหรับคำที่เกี่ยวกับฐานข้อมูลด้วย
    • กราฟตัวอย่างมีสัดส่วนการกล่าวถึงแบบค่าเฉลี่ยเคลื่อนที่ 12 สัปดาห์ของ mysql, postgres, mongo, redis, sqlite
  • DuckDB ดูดีมากสำหรับการวิเคราะห์ dataset ขนาดประมาณนี้
  • แม้จะได้สำเนาคอนเทนต์ Hacker News ทั้งหมดไว้ในเครื่องแล้ว แต่ตัดสินใจจบโปรเจกต์ไว้เพียงเท่านี้

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

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

 
GN⁺ 2025-05-02
ความคิดเห็นบน Hacker News

  • รู้จักฐานข้อมูลอยู่สองตัวที่มีตาราง Hacker News ที่อัปเดตแล้ว ซึ่งสามารถนำไปรันการวิเคราะห์ได้โดยไม่ต้องดาวน์โหลดมาก่อน
    BigQuery ต้องมีบัญชี Google Cloud และคิวรีน่าจะทำได้ในระดับฟรี โดยใช้ bigquery-public-data.hacker_news.full
    ClickHouse ไม่ต้องสมัคร และสามารถรันคิวรีจากเบราว์เซอร์ได้ทันที: https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...

    • ถึงขั้นหา clickhouse ในคอมเมนต์นี้เจอด้วย: https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
    • ทรัพยากรของ ClickHouse ยอดเยี่ยมจริง ๆ มีประวัติย้อนหลังด้วย
      ก่อนจะรู้จักฐานข้อมูล HN ของ ClickHouse ก็เคยลองลงมือดาวน์โหลด JSON ทั้งหมดเองมาแล้ว

  • เคยทำอะไรคล้าย ๆ กันกับบัญชี Twitter/Bluesky @fesshole มาก่อน ดาวน์โหลดคลังทั้งหมดมาแล้ว fine-tune โมเดลให้สร้างคำสารภาพที่บ้าหนักกว่าเดิม
    ตอนนั้นค่อนข้างภูมิใจ แต่สุดท้ายก็ตระหนักได้ว่าสิ่งที่ทำไปก็แค่สอน การสำเร็จความใคร่ด้วยตัวเองและการหย่าร้าง ให้เครื่องจักรผู้ไร้เดียงสาเท่านั้น
    เหมือนฉากในหนังไซไฟที่เอเลียนหรือ AI อัจฉริยะเหนือมนุษย์ดูประวัติศาสตร์มนุษยชาติแบบเร่งความเร็ว แล้วตัดสินว่าเราไม่คุ้มค่าที่จะช่วย

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

  • คิวรี Java จะรวมกรณีทั้งหมดของ JavaScript เข้าไปด้วย ดังนั้น Java จึงถูกนับเกินจริง

    • เช่นเดียวกัน คิวรี Rust ก็จะรวมคำอย่าง trust, antitrust, frustration เข้าไปเป็นจำนวนมากด้วย
    • ใช่… ถ้าอย่างนั้นการที่เห็นแนวโน้มลดลงอาจยิ่งเหนือความคาดหมายกว่าเดิมก็ได้

  • การที่มี ไฟล์ JSON ขนาด 20GiB ซึ่งบรรจุทุกอย่างที่เกิดขึ้นบน Hacker News นั้น ถือว่าใหญ่กว่าที่คิดเมื่อคำนึงว่าเป็นไซต์ที่มีแต่ข้อความ
    หมายความว่าตลอด 18 ปีที่ HN มีอยู่ ผู้คนโพสต์ข้อความรวมกันเกิน 20,000 ล้านไบต์เลยหรือ? เฉลี่ยมากกว่า 2MB ต่อวัน หรือประมาณ 7.5KB ต่อวินาที

    • วันละ 2MB ดูไม่เยอะนัก โดยเฉพาะหลังเหตุการณ์ Reddit และ “กันยายนที่ไม่มีวันจบ” ครั้งล่าสุดซึ่งเป็นครั้งใหญ่ที่สุด จำนวนโพสต์อาจเพิ่มขึ้นแบบทวีคูณตลอดหลายปีที่ผ่านมา
      แถมปริมาณจำนวนมากในนั้นคงไม่ได้มาจากมนุษย์ด้วย /newest เต็มไปด้วยสแปมจากบอต
    • 7.5KB/s หรือ 7,500 ตัวอักษรต่อวินาที ฟังดูไม่ค่อยสมจริง เลยลองคำนวณดู[0] แล้วจริง ๆ ใกล้เคียงกับประมาณ 34 ไบต์ต่อวินาที หรือ 0.03KB/s มากกว่า
      และเพราะรวมเมทาดาทากับไวยากรณ์ของ JSON ไว้ด้วย ปริมาณข้อความจริง ๆ น่าจะต่ำกว่านั้นอีก ส่วนการคำนวณว่า “มากกว่า 2MB ต่อวัน” นั้นถูกแล้ว
      [0] จริง ๆ แล้ว ChatGPT เป็นคนคำนวณ แต่ก็ดูถูกต้อง: https://chatgpt.com/share/68124afc-c914-800b-8647-74e7dc4f21...
    • อาร์ไคฟ์ทั้งหมดของ Reddit ก่อนที่ API จะถูกเอาออกไม่นาน มีขนาด ประมาณ 4TB ในรูปแบบบีบอัด เมื่อก่อนโฮสต์อยู่บน the-eye และถ้าต้องการก็ยังมีที่ที่สามารถโหลดไฟล์ผ่านทอร์เรนต์ได้
      ส่วนใหญ่ในนั้นเป็นขยะก็จริง แต่ข้อมูลช่วงต้น ๆ โดยเฉพาะก่อนปี 2018~2019 ก่อนที่บอตที่ฉลาดขึ้นมากจะปรากฏ น่าจะยังคุ้มค่าที่จะสำรวจ
    • เรื่อง JSON 20GB นี่น่าทึ่ง ผมมีไฟล์ SQLite ที่เก็บข้อมูล HN ทั้งหมดอยู่ ซึ่งมันก็ 20GB แล้ว ดังนั้นถ้าเป็น JSON น่าจะต้องใหญ่กว่านี้มาก
    • ขนาดรวมกลับรู้สึกเล็กด้วยซ้ำ นี่เป็นผลลัพธ์จากสมาชิกที่แอ็กทีฟหลายแสนคนและผู้มีส่วนร่วมรวมหลายล้านคนตลอดเกือบ 20 ปี
      ตามมาตรฐานก่อนยุค Facebook แล้ว HN น่าจะเป็นเครือข่ายสังคมที่ค่อนข้างใหญ่ และเพราะมีขนาดกำลังดีแถมมีการดูแลอย่างแข็งขัน คุณค่าของมันก็ถือว่าสูงด้วย
      ในปี 2019 ตอนที่ Google+ ปิดตัว ผมเคยลองทำโมเดลว่าข้อมูลข้อความที่มีคนร่วมสร้างบนไซต์นั้นมีมากแค่ไหน
      ในที่นี้ ข้อมูลข้อความ หมายถึงไม่รวมสื่ออย่างรูปภาพ เสียง วิดีโอ รวมถึงองค์ประกอบหน้าเว็บเสริมอย่างโครง HTML, CSS, JS
      เมื่อพิจารณาว่าอัตราการมีส่วนร่วมต่ำมาก และความยาวโพสต์เฉลี่ยอยู่ที่ราว 120 ตัวอักษร ประวัติ 7 ปีของบัญชีที่แอ็กทีฟหลายสิบล้านบัญชีก็มีขนาดเพียงไม่กี่ GiB เท่านั้น แม้โปรไฟล์ที่ลงทะเบียนจะมีมากกว่า 4,000 ล้านบัญชี แต่กิจกรรมจริงมีน้อยกว่านั้นมาก
      Archive Team ทำงานร่วมกับ Internet Archive แต่ก็เป็นคนละกลุ่มกัน ในการอนุรักษ์ Google+ และผลลัพธ์ก็ปะปนกันไป มีคอนเทนต์จำนวนมากถูกเก็บไว้ แต่ที่หายไปมีมากกว่านั้นอีกมาก คอมเมนต์แทบไม่เหลือ เธรดถูกตัดเหลือประมาณ 10 รายการล่าสุด และไม่มีการค้นหา ทำให้โดยรวมใช้งานได้ไม่ค่อยมาก “vanity accounts” ที่ใช้ชื่อบัญชีที่เลือกเองแทนแฮชแบบสุ่มก็เข้าถึงได้แย่กว่าเดิม
      ยิ่งไปกว่านั้น การพยายามสแครปทั้งหน้าเพื่อจำลองรูปแบบที่เห็นออนไลน์กลับเพิ่มความต้องการพื้นที่จัดเก็บอย่างมาก ขณะที่พลาดองค์ประกอบจำนวนมากที่ทำให้ไซต์นั้นน่าสนใจจริง ๆ
      แม้ในกรณีที่ต้องการเก็บการมีส่วนร่วมเป็นข้อความของประชากรกลุ่มใหญ่ ความต้องการพื้นที่จัดเก็บก็ยังค่อนข้าง modest ตัวอย่างเช่น แม้สมมติว่าเวลาออนไลน์เฉลี่ยต่อวันคือ 45 นาที ความเร็วพิมพ์ 45wpm และครึ่งหนึ่งของเวลาออนไลน์นั้นเป็นการเขียนไม่ใช่การอ่าน ก็จะได้ประมาณ 1,000 คำต่อคนต่อวัน หรือราว 6KiB เท่านั้น เท่ากับ 6MiB ต่อ 1,000 คน, 6GiB ต่อ 1 ล้านคน และประมาณ 6PiB ต่อ 1 พันล้านคน
      ค่าจริงแทบจะแน่นอนว่าต่ำกว่านั้นมาก เพราะเวลาที่ใช้เขียนถูกประเมินสูงเกินไป และจริง ๆ น่าจะใกล้ 10% มากกว่า อีกทั้งความเร็วการป้อนข้อมูลบนมือถือก็น่าจะอยู่ราว 20~30wpm เช่น Facebook มี “ชิ้นส่วนคอนเทนต์” ประมาณ 2.45 พันล้านชิ้นต่อวัน และครึ่งหนึ่งเป็นวิดีโอ หากคิดว่าโพสต์ละ 120 ตัวอักษร ข้อมูลข้อความต่อวันก็มีน้อยกว่า 300GiB มาก ซึ่งเป็นปริมาณที่เล็กอย่างน่าประหลาดใจ
      ปัจจุบัน ระบบเก็บข้อมูลและ ทุนนิยมสอดส่อง ส่วนใหญ่ประกอบด้วยข้อมูลที่มนุษย์ไม่ได้ป้อนเข้าโดยตรง เช่น ตำแหน่ง วิดีโอ ปฏิสัมพันธ์ออนไลน์ และพาณิชย์

  • มารยาทบนเน็ต ตอนดาวน์โหลด HN ควรเป็นอย่างไร? ควรถาม dang ก่อนหรือเปล่าก่อนจะสร้างภาระให้เซิร์ฟเวอร์?
    หรือจะถือว่า บริษัทเทคโนโลยีระดับหลายพันล้านดอลลาร์คงทำกันไปหลายรอบแล้ว จนเราแทบไม่เป็นที่สังเกต?

    • ตามที่บทความบอก HN มี API และถึงขั้นไม่มีการจำกัดอัตราเรียกใช้ด้วย ข้อมูลทั้งหมดโฮสต์อยู่บน Firebase ซึ่งเป็นบริษัทของ YC ก็น่าจะไม่เป็นไร
    • มีฐานข้อมูลสาธารณะอยู่จริง ๆ
      https://console.cloud.google.com/marketplace/product/y-combi...
    • จะตัดความเป็นไปได้ที่หน่วยงานสามตัวอักษรกำลังผูกนามแฝงบน HN เข้ากับชื่อจริงออกไปก็ไม่ได้
    • ชื่อมันคือ Hacker News ดังนั้นอย่างน้อยการแฮ็กในความหมายดี ๆ ก็น่าจะเป็นเกมที่ยุติธรรม
    • ถ้าอยู่บนเว็บสาธารณะ ก็มีบอตหลายพันตัวสแครปอยู่แล้ว

  • เคยทำอะไรคล้าย ๆ กัน ใช้ทริกกับ ชุดข้อมูล BigQuery ซึ่งไม่รู้ทำไมถึงยังอัปเดตอยู่เรื่อย ๆ แล้วส่งออกข้อมูลเป็น Parquet จากนั้นดาวน์โหลดมาคิวรีด้วย DuckDB

    • นั่นไม่ใช่ทริกหรอก แค่เป็นทางเลือกที่ใช้งานได้จริง

  • “ตอนนี้เราได้ดาวน์โหลดเนื้อหาทั้งหมดของ Hacker News มาไว้ในเครื่องแล้ว เราก็สามารถฝึกบอตที่ขับเคลื่อนด้วย LLM หลายร้อยตัวให้ทำหน้าที่เป็นผู้ร่วมเขียน แล้วค่อย ๆ และอย่างหลีกเลี่ยงไม่ได้แทนที่ข้อความของมนุษย์ทั้งหมดด้วยเอาต์พุตจากตัวสั่นในห้องภาษาจีนที่สะท้อนและรีไซเคิลอดีตไปชั่วนิรันดร์” นี่เป็นมุกตลก แต่ก็กลัวว่าสักวันจะมีใครสักคนลองทำจริง ๆ
    หวังว่าจะไม่เกิดเรื่องแบบนั้น แต่ถ้าเกิดขึ้นแล้วเราจะหยุดมันได้ไหม?

    • ผมเริ่มเชื่อมากขึ้นเรื่อย ๆ ในแนวคิดเก่าอย่างหนึ่งที่ยิ่งเวลาผ่านไปก็ยิ่งสำคัญขึ้น นั่นคือการสร้าง เครือข่ายความไว้วางใจ ระหว่างมนุษย์ เพื่อให้บัญชีหนึ่งถูกตรวจสอบได้ผ่านเส้นทาง เช่น คนที่ผมไม่รู้จักไว้วางใจบัญชีนั้น คนคนนั้นถูกคนที่ผมรู้จักไว้วางใจ และคนที่ผมรู้จักคนนั้นก็เป็นคนที่ผมไว้วางใจ
      มีปัญหามากมายที่ต้องแก้ และความเป็นส่วนตัวก็เป็นหนึ่งในนั้น ไม่จำเป็นต้องเปิดเผยความสัมพันธ์เชื่อมโยงให้ผู้ใช้เห็น แต่ในการทำแบบตรงไปตรงมา ข้อมูลเหล่านั้นก็ยังจะอยู่บนเซิร์ฟเวอร์
      อาจเพิ่มเส้นทางความไม่ไว้วางใจเป็นค่าน้ำหนักลบได้ด้วย ถ้าไม่ไว้วางใจใครสักคนโดยตรงหรือโดยอ้อม ค่าของห่วงโซ่ความไว้วางใจที่เชื่อมระหว่างผมกับคนนั้นก็จะลดลง
      เพราะมันเป็นเครือข่าย ระบบจึงอาจปรับตัวเองต่อความพยายามบิดเบือนระบบได้ แต่จะทนทานได้แค่ไหนก็ยังเป็นคำถามอยู่
    • เราจะรู้ได้อย่างไรว่ามันไม่ได้เกิดขึ้นอยู่แล้ว?
      คอมเมนต์ยาว ๆ ที่มีเนื้อหามักจะแยกออกได้ แต่ยากขึ้นกว่าหนึ่งหรือสองปีก่อนมาก ถ้าเป็นคอมเมนต์สั้น ๆ หนึ่งสองประโยค ผมคิดว่า LLM ตอนนี้ดีพอจะผ่านเหมือนมนุษย์แล้ว
    • LLM ของเราให้ได้เฉพาะผลลัพธ์ที่ได้รับการยืนยันจากหลายแหล่ง ดังนั้นจึงปล่อยออกมาได้แค่คำตอบแบบเฉลี่ย ๆ ของมนุษย์
      ในทางกลับกัน คอมเมนต์จำนวนมากบน HN เป็นข้อคิดที่ค่อนข้างเฉพาะตัวและสวนทางกับความคิดยอดนิยมโดยเฉลี่ย ถ้า LLM พยายามเลียนแบบสิ่งนี้ ก็จะมีแต่พูดเหลวไหลออกมา
      ถ้าเอาตัวกรองที่ให้ผ่านเฉพาะคำตอบที่สมเหตุสมผลและเข้าท่าไปครอบความเหลวไหลนั้น คำตอบก็จะน่าเบื่อและยังคงใกล้เคียงกับความเหลวไหลอยู่ดี
      ถ้าจะให้คำตอบถูกต้อง แม่นยำ และมีเอกลักษณ์ ต้องใช้ บางอย่างที่ไม่ใช่ LLM
    • HN มี ระบบภูมิคุ้มกัน ที่ค่อนข้างดีต่อเรื่องประเภทนี้อยู่แล้ว คอมเมนต์ที่ใช้ความพยายามต่ำและซ้ำ ๆ จะถูก downvote, flag และจำกัดอัตราอย่างรวดเร็ว
      ฮิวริสติกเรื่อง karma และความเร็วของไซต์อาจดูหยาบเมื่อเทียบกับแมชชีนเลิร์นนิงหรู ๆ แต่ก็ใช้ได้เพราะชุมชนเล็กกว่า Reddit หรือ Twitter และทีมดูแลเข้าแทรกแซงโดยตรง
      ถ้ากองทัพบัญชีปลอม LLM จะ “แทนที่” ข้อความมนุษย์ได้ ก็ต้องโพสต์สิ่งที่ผู้คนรู้สึกว่าน่าสนใจจริง ๆ อย่างต่อเนื่อง ไม่เช่นนั้นก็จะถูกจำกัดหรือถูกลบแบบเงียบ ๆ ไปก่อนหน้านั้นมาก
      ต่อให้ปล่อยให้บัญชี AI บางบัญชีอยู่รอด ต้นทุนส่วนเพิ่มก็สูง การรัน inference กับกระทู้ใหม่หลายสิบกระทู้ตลอด 24 ชั่วโมงไม่ใช่ของฟรี และการทำให้เอาต์พุตไม่ไถลไปเป็นขยะ SEO ดาด ๆ ก็ยากอย่างน่าประหลาด
      ผลตอบแทนก็แทบไม่มีอยู่จริง เอาทราฟฟิก HN ไปทำเงินไม่ได้ และ karma ก็เป็นสกุลเงินที่แย่มากสำหรับผู้ควบคุมบอต
      ถ้าถามว่าจะหยุดผู้ไม่หวังดีที่มีทรัพยากรและดื้อดึงได้ไหม ก็คงเป็นไปได้ แต่แนวทางรับมือก็คงเหมือนตอนนี้ คือจำกัดอัตราอย่างเข้มงวด เพิ่มเพดานจำกัดสำหรับบัญชีใหม่ การตรวจสอบโดยผู้ดูแลที่เป็นคน และอาจมีการวิเคราะห์สไตล์การเขียนบ้าง
      สำหรับผู้ใช้ใหม่ที่ถูกต้องตามกฎหมาย มันจะน่ารำคาญแต่ไม่ถึงตาย ท้ายที่สุด HN อยู่รอดได้เพราะมนุษย์ที่นี่อยากอ่านงานเขียนของมนุษย์คนอื่น ถ้าคอมเมนต์เริ่มฟังดูเหมือนนกแก้วเชิงความน่าจะเป็น ผู้อ่านก็จะเมินหรือรายงาน และบอตก็จะคุยกันเอง
      เขียนโดย GPT-3o
    • มีหลายอย่างที่คาดการณ์กระแสแบบนี้ไว้แล้ว เช่น แฟรนไชส์ Metal Gear[0] และทฤษฎีอินเทอร์เน็ตตายแล้ว[1]
      “บทภาพยนตร์อันทะเยอทะยานของ Hideo Kojima ใน Metal Gear Solid 2 เคยถูกมองว่าเป็นหนึ่งในตัวอย่างแรก ๆ ของวิดีโอเกมแบบโพสต์โมเดิร์น และยังถูกประเมินว่าคาดการณ์แนวคิดอย่างการเมืองยุคหลังความจริง ข่าวปลอม ห้องเสียงสะท้อน และข้อเท็จจริงทางเลือกไว้ล่วงหน้า”
      [0] https://en.wikipedia.org/wiki/Metal_Gear
      [1] https://en.wikipedia.org/wiki/Dead_Internet_theory

  • ผมคิดว่าในอีกไม่กี่ปีข้างหน้า API จำนวนมากจะเริ่มมีตัวเลือกให้ส่งคืนเป็น ไฟล์ DuckDB ได้เลย
    ในเมื่อสุดท้ายก็จะเอา JSON โหลดเข้า database อยู่แล้ว ก็ไม่มีเหตุผลอะไรที่จะไม่รับ database กลับมาเป็น response

    • zstd Parquet ที่ export จากไฟล์ DuckDB 1.2 บีบอัดได้ดีกว่า 2–3 เท่า

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

    • ผมก็คิดแบบนั้นเป็นอย่างแรกเหมือนกัน ผู้เขียน uPlot มีเดโมที่แสดงกับดักนี้ได้ดี: https://leeoniya.github.io/uPlot/demos/stacked-series.html
    • จริง :( แต่ถ้า plot ข้อมูลเดียวกันเป็น กราฟเส้น มันซ้อนทับกันเยอะเกินไปจนดูอะไรแทบไม่ออก
      ครั้งหน้ากำลังคิดว่าจะจัดเรียงกราฟเส้นหลาย ๆ อันซ้อนกัน โดยแต่ละอันมีเพียงหนึ่ง series ต่อภูมิภาค
    • แนวทาง 3D คือจุดที่แก้ปัญหานี้ได้ ซ้อนกันแต่ให้ offset เล็กน้อย แล้วใช้เทคโนโลยี game engine กับ business intelligence จริง ๆ เพื่อทำความเข้าใจข้อมูลขนาดใหญ่ในครั้งเดียว ไม่มีอะไรดีกว่านี้แล้ว
      ดูงานของ https://flowimmersive.com/ ได้
    • คิดอย่างไรกับกราฟสะสมที่ใช้ แกน y แบบลอการิทึม? การทดลองฟิสิกส์บางอย่างทำแบบนี้เสมอ[1] แต่ผมรู้สึกว่ามันไม่ค่อยเป็นธรรมชาติเท่าไร
      [1]: https://atlas.web.cern.ch/Atlas/GROUPS/PHYSICS/PUBNOTES/ATL-...

  • เคยทำไว้ตัวหนึ่งมาก่อน และ https://github.com/ashish01/hn-data-dumps ก็ค่อนข้างสนุกดี
    ฟีเจอร์ที่น่าจะเจ๋งถ้าทำได้ คือการสะท้อนข้อเท็จจริงที่ว่า รายการยิ่งใหม่ก็ยิ่งถูกอัปเดตบ่อยขึ้นเมื่อเวลาผ่านไป ดังนั้นรายการที่เพิ่งดาวน์โหลดมาจึงกลายเป็น แคชที่เก่า เร็วกว่ารายการเก่า

    • ดีมากที่ HN มี API แบบนี้ให้ใช้ ไม่ได้ล็อกไว้เหมือนเว็บไซต์อื่น ๆ จำนวนมาก
      ผมใช้ฟังก์ชันที่อิงตามอายุเพื่อตัดสินว่ามันเก่าหรือยัง ตอนแรกจะถือว่าเก่าหลังจากสร้างไปแล้ว 1–2 นาที จากนั้นรีเฟรชบ่อย ๆ อยู่สองสามวัน แล้วลดลงอย่างรวดเร็วหลังสัปดาห์แรก จนเมื่อผ่านไปประมาณ 2 สัปดาห์ก็ถือว่าไม่เปลี่ยนแปลงแล้ว
      // DefaultStaleIf marks stale at 60 seconds after creation, then frequently for the first few days after an item is
      // created, then quickly tapers after the first week to never again mark stale items more than a few weeks old.
      const DefaultStaleIf = "(:now-refreshed)>" +
      "(60.0*(log2(max(0.0,((:now-Time)/60.0))+1.0)+pow(((:now-Time)/(24.0*60.0*60.0)),3)))"
      https://github.com/jasonthorsness/unlurker/blob/main/hn/core...