xguru 2026-01-18 | ความคิดเห็นหลัก | ใน: Dell UltraSharp 52 Thunderbolt Hub Monitor (dell.com) ตอนนี้ผมใช้ขนาด 40 นิ้วอยู่ แต่ 52 น่าจะใหญ่เกินไปหน่อย แม้แต่ในคอมเมนต์บน Hacker News ก็ยังเถียงกันเลยว่าควรใช้หลายจอหรือจอเดียวแบบนี้ แต่สำหรับผม ตอนนี้จอเดียวแบบนี้กลับสะดวกกว่าครับ twinstae 2026-01-18 | ความคิดเห็นหลัก | ใน: GraphQLite - ส่วนขยาย SQLite ที่รองรับภาษาเคียวรี Cypher และอัลกอริทึมกราฟในตัว (github.com/colliery-io) https://github.com/twinstae/graphqlite-ts ลองทำ bun sqlite + ffi binding แบบชิล ๆ ไปกับ LLM ดู แล้วมันก็ใช้งานได้จริงนะครับ (โลกนี้ช่างดีจริง ๆ) yangeok 2026-01-18 | ความคิดเห็นหลัก | ใน: GraphQLite - ส่วนขยาย SQLite ที่รองรับภาษาเคียวรี Cypher และอัลกอริทึมกราฟในตัว (github.com/colliery-io) น่าจะเหมาะเอามาทำ PoC ดีเลยครับ ฮ่าๆ softer 2026-01-18 | ความคิดเห็นหลัก | ใน: Open Responses - มาตรฐานเปิดเพื่อการทำงานร่วมกันระหว่าง LLM (openresponses.org) โอ้... ผมก็มีอะไรที่กำลังทำอยู่เหมือนกัน แบบนี้คงต้องเอาสิ่งนี้มาเป็นกรอบแล้วล่ะ anyflow 2026-01-18 | ความคิดเห็นหลัก | ใน: ฉันเกลียด GitHub Actions มากจริง ๆ (xlii.space) ดูเหมือนว่านี่จะเป็นปัญหาที่หลีกเลี่ยงไม่ได้ เพราะโครงสร้างบังคับให้ต้องใส่ logic ลงไปใน yaml ดูเหมือนว่าบทความข้างบนจะเสนอคำตอบไว้คร่าว ๆ แบบด้านล่าง แต่ถ้าแทนส่วนของสคริปต์ด้วย Dagger ก็ชวนให้คิดว่านี่อาจเป็นคำตอบที่ถูกต้องก็ได้ "อย่าปล่อยให้ GitHub Actions จัดการ logic แต่ให้ควบคุมสคริปต์เองโดยตรง และให้ Actions มีหน้าที่แค่เรียกใช้สคริปต์นั้น" xguru 2026-01-18 | ความคิดเห็นหลัก | ใน: Astro เข้าร่วมกับ Cloudflare (astro.build) Astro คือการหวนคืนสู่พื้นฐานของเว็บ Astro 3.0 เปิดตัว Astro: ดีพลอย JavaScript ให้น้อยที่สุด tsboard 2026-01-17 | ความคิดเห็นหลัก | ใน: Astro เข้าร่วมกับ Cloudflare (astro.build) ต่อจากข่าวดีเรื่องที่ Claude เข้าซื้อ Bun ก็ยังมีข่าวดีเข้ามาเรื่อย ๆ เลยนะครับ แบบนี้ก็น่าจะทุ่มเทกับโปรเจกต์ได้อย่างมั่นคงมากขึ้น slowandsnow 2026-01-17 | ความคิดเห็นหลัก | ใน: Astro เข้าร่วมกับ Cloudflare (astro.build) เป็นเรื่องที่ดีนะ kaydash 2026-01-17 | ความคิดเห็นหลัก | ใน: claude-mem - ระบบบีบอัดหน่วยความจำสำหรับคงบริบทข้ามเซสชันของ Claude Code (github.com/thedotmack) ดีนะ จัดการประวัติการสนทนาทั้งด้วย FTS และด้วยเวกเตอร์เลย kaydash 2026-01-17 | ความคิดเห็นหลัก | ใน: เหตุผลที่ย้ายออกจาก Redis ไปใช้ SolidQueue (simplethread.com) Redis ก็ดีนะ laeyoung 2026-01-17 | ความคิดเห็นหลัก | ใน: การทดลอง ‘เบราว์เซอร์’ ล่าสุดของ Cursor สื่อถึงความสำเร็จโดยไม่มีหลักฐาน (embedding-shapes.github.io) บทความที่เกี่ยวข้อง - 장시간 실행되는 자율 코딩의 확장 bungker 2026-01-17 | ความคิดเห็นหลัก | ใน: อีก 2 ปีข้างหน้าของวิศวกรรมซอฟต์แวร์ (addyosmani.com) เป็นบทความที่ให้มุมมองอย่างลึกซึ้งจริง ๆ ผมยังคงอ่านซ้ำแล้วซ้ำอีก ywc0008 2026-01-17 | ความคิดเห็นหลัก | ใน: Vercel เปิดเผยคลังแนวปฏิบัติที่เป็นเลิศสำหรับ React (vercel.com) https://ywc.life/posts/vercel-react-best-practice ลองแปลฉบับเต็มแล้วครับ tsboard 2026-01-17 | ความคิดเห็นหลัก | ใน: ไอเดียราคาถูก การลงมือทำยิ่งถูกกว่า (davekiss.com) ดูเหมือนว่าความเปลี่ยนแปลงของยุคสมัยมันจะเร็วเกินไปจริง ๆ เศร้าจัง xguru 2026-01-16 | ความคิดเห็นหลัก | ใน: Pocket TTS: TTS คุณภาพสูงที่มอบเสียงให้กับ CPU (kyutai.org) ดูเหมือนว่าจะยังไม่ค่อยเห็นโมเดล TTS แบบโอเพนที่รองรับภาษาเกาหลีเท่าไรนะครับ ก่อนหน้านี้มี Kokoro-82M ที่บอกว่ารองรับภาษาเกาหลี แต่ก็เคยได้ยินมาว่าคุณภาพน่าจะยังไม่ค่อยดีเท่าไร ลองหาดูคร่าว ๆ ก็เห็นว่าถ้าทำและใช้งานด้วย GPT-Sovits หรือใช้พวก Edge-TTS ก็ดูเหมือนว่าจะออกมาใช้ได้โอเคพอสมควรเหมือนกันครับ ช่วงนี้ถ้าเอาไปประกบกับ Whisper ตอน vibe coding ก็น่าจะมีอะไรสนุก ๆ ออกมาได้อยู่ แต่ยังนึกไอเดียไม่ออกเลย ฮ่า jokerized 2026-01-16 | ความคิดเห็นหลัก | ใน: Rust เร็วกว่า C หรือไม่? (steveklabnik.com) ในงาน embedded เราเขียนโค้ดโดยคำนึงถึงขนาด cache line ของฮาร์ดแวร์ด้วยอยู่แล้ว ประเด็นคงอยู่ที่ว่านักพัฒนาจะทำ optimization ขั้นสุดบนระดับภาษาได้ไกลแค่ไหน รวมถึงเรื่องประสิทธิภาพของ standard library และ compiler แต่ยังไงทั้งคู่ก็รองรับงาน low-level เหมือนกัน ดังนั้นความต่างของ overhead เล็กน้อยก็น่าจะอยู่ในระดับที่แทบไม่มีนัยสำคัญ เพราะงั้นเลยดูไม่ใช่ประเด็นถกเถียงที่มีความหมายเท่าไรนัก.. ถ้าต้องการ optimization แบบสุดทาง สุดท้ายก็ต้องอาศัยการแทรกแซงของมนุษย์อยู่ดี เพราะ compiler ไม่ได้สมบูรณ์แบบอย่างที่คิด tensun 2026-01-16 | ความคิดเห็นหลัก | ใน: Ask HN: คุณกำลังทำ RAG บนเครื่องโลคัลกันอย่างไร? (news.ycombinator.com) สงสัยว่าใช้ภาษาเกาหลีได้ดีไหม aer0700 2026-01-16 | ความคิดเห็นหลัก | ใน: Rust เร็วกว่า C หรือไม่? (steveklabnik.com) โดยเฉลี่ยแล้วผมไม่แน่ใจว่าภาษาไหนเร็วที่สุด แต่คิดว่าความกระจายของผลลัพธ์น่าจะมากที่สุดสำหรับ C++ xguru 2026-01-16 | ความคิดเห็นหลัก | ใน: ภาพถ่ายที่ถ่ายทอดสเกลอันน่าทึ่งของการขยายพลังงานลมและพลังงานแสงอาทิตย์ในจีน (e360.yale.edu) และรูปแรกนี่เหมือนฉากหนึ่งจากหนังแนวหลังหายนะจริง ๆ เลยนะ onestone 2026-01-16 | ความคิดเห็นหลัก | ใน: ไอเดียราคาถูก การลงมือทำยิ่งถูกกว่า (davekiss.com) (ทักษะการเขียนโค้ด = ระดับโต๊ะเดิมพันขั้นต่ำ) ฮือๆ โหลดความคิดเห็นเพิ่มเติม
ตอนนี้ผมใช้ขนาด 40 นิ้วอยู่ แต่ 52 น่าจะใหญ่เกินไปหน่อย
แม้แต่ในคอมเมนต์บน Hacker News ก็ยังเถียงกันเลยว่าควรใช้หลายจอหรือจอเดียวแบบนี้ แต่สำหรับผม ตอนนี้จอเดียวแบบนี้กลับสะดวกกว่าครับ
https://github.com/twinstae/graphqlite-ts
ลองทำ bun sqlite + ffi binding แบบชิล ๆ ไปกับ LLM ดู แล้วมันก็ใช้งานได้จริงนะครับ (โลกนี้ช่างดีจริง ๆ)
น่าจะเหมาะเอามาทำ PoC ดีเลยครับ ฮ่าๆ
โอ้... ผมก็มีอะไรที่กำลังทำอยู่เหมือนกัน แบบนี้คงต้องเอาสิ่งนี้มาเป็นกรอบแล้วล่ะ
ดูเหมือนว่านี่จะเป็นปัญหาที่หลีกเลี่ยงไม่ได้ เพราะโครงสร้างบังคับให้ต้องใส่ logic ลงไปใน yaml
ดูเหมือนว่าบทความข้างบนจะเสนอคำตอบไว้คร่าว ๆ แบบด้านล่าง แต่ถ้าแทนส่วนของสคริปต์ด้วย Dagger ก็ชวนให้คิดว่านี่อาจเป็นคำตอบที่ถูกต้องก็ได้
"อย่าปล่อยให้ GitHub Actions จัดการ logic แต่ให้ควบคุมสคริปต์เองโดยตรง และให้ Actions มีหน้าที่แค่เรียกใช้สคริปต์นั้น"
Astro คือการหวนคืนสู่พื้นฐานของเว็บ
Astro 3.0 เปิดตัว
Astro: ดีพลอย JavaScript ให้น้อยที่สุด
ต่อจากข่าวดีเรื่องที่ Claude เข้าซื้อ Bun ก็ยังมีข่าวดีเข้ามาเรื่อย ๆ เลยนะครับ แบบนี้ก็น่าจะทุ่มเทกับโปรเจกต์ได้อย่างมั่นคงมากขึ้น
เป็นเรื่องที่ดีนะ
ดีนะ จัดการประวัติการสนทนาทั้งด้วย FTS และด้วยเวกเตอร์เลย
Redis ก็ดีนะ
บทความที่เกี่ยวข้อง - 장시간 실행되는 자율 코딩의 확장
เป็นบทความที่ให้มุมมองอย่างลึกซึ้งจริง ๆ ผมยังคงอ่านซ้ำแล้วซ้ำอีก
https://ywc.life/posts/vercel-react-best-practice
ลองแปลฉบับเต็มแล้วครับ
ดูเหมือนว่าความเปลี่ยนแปลงของยุคสมัยมันจะเร็วเกินไปจริง ๆ เศร้าจัง
ดูเหมือนว่าจะยังไม่ค่อยเห็นโมเดล TTS แบบโอเพนที่รองรับภาษาเกาหลีเท่าไรนะครับ
ก่อนหน้านี้มี Kokoro-82M ที่บอกว่ารองรับภาษาเกาหลี แต่ก็เคยได้ยินมาว่าคุณภาพน่าจะยังไม่ค่อยดีเท่าไร
ลองหาดูคร่าว ๆ ก็เห็นว่าถ้าทำและใช้งานด้วย GPT-Sovits หรือใช้พวก Edge-TTS ก็ดูเหมือนว่าจะออกมาใช้ได้โอเคพอสมควรเหมือนกันครับ
ช่วงนี้ถ้าเอาไปประกบกับ Whisper ตอน vibe coding ก็น่าจะมีอะไรสนุก ๆ ออกมาได้อยู่ แต่ยังนึกไอเดียไม่ออกเลย ฮ่า
ในงาน embedded เราเขียนโค้ดโดยคำนึงถึงขนาด cache line ของฮาร์ดแวร์ด้วยอยู่แล้ว ประเด็นคงอยู่ที่ว่านักพัฒนาจะทำ optimization ขั้นสุดบนระดับภาษาได้ไกลแค่ไหน รวมถึงเรื่องประสิทธิภาพของ standard library และ compiler แต่ยังไงทั้งคู่ก็รองรับงาน low-level เหมือนกัน ดังนั้นความต่างของ overhead เล็กน้อยก็น่าจะอยู่ในระดับที่แทบไม่มีนัยสำคัญ เพราะงั้นเลยดูไม่ใช่ประเด็นถกเถียงที่มีความหมายเท่าไรนัก.. ถ้าต้องการ optimization แบบสุดทาง สุดท้ายก็ต้องอาศัยการแทรกแซงของมนุษย์อยู่ดี เพราะ compiler ไม่ได้สมบูรณ์แบบอย่างที่คิด
สงสัยว่าใช้ภาษาเกาหลีได้ดีไหม
โดยเฉลี่ยแล้วผมไม่แน่ใจว่าภาษาไหนเร็วที่สุด แต่คิดว่าความกระจายของผลลัพธ์น่าจะมากที่สุดสำหรับ C++
และรูปแรกนี่เหมือนฉากหนึ่งจากหนังแนวหลังหายนะจริง ๆ เลยนะ
(ทักษะการเขียนโค้ด = ระดับโต๊ะเดิมพันขั้นต่ำ) ฮือๆ