ผู้คนไม่ค่อยเข้าใจถึงความสำคัญของเสรีภาพอย่างแท้จริง ไม่ว่าจะอายุมากหรือไม่ก็ตาม

แม้แต่คนรุ่นที่เคยต่อสู้เพื่อประชาธิปไตย ก็น่าแปลกที่กลับยินดีรับการเซ็นเซอร์

พวกเขายังไม่เข้าใจด้วยซ้ำว่าข้อเสียของการเซ็นเซอร์นั้นมากกว่าประโยชน์ในการป้องกันอาชญากรรม
ทุกการเซ็นเซอร์ล้วนเอาเรื่องการป้องกันอาชญากรรมมาเป็นข้ออ้างเดียว และนี่ก็เป็นยุคที่ข้ออ้างนั้นยังใช้ได้ผล

อีกไม่กี่ปีต่อจากนี้ แม้จะมีการติดตั้ง CCTV ในทุกครัวเรือนเหมือนในนิยายอย่าง 1984 ผู้คนก็อาจไม่แม้แต่จะเข้าใจถึงอันตรายนั้นเลยก็ได้

คนที่กดแนะนำอะไรแบบนี้ควรสำนึกผิด

สำหรับผู้คนที่อาศัยอยู่ในสังคมแห่งการเซ็นเซอร์ที่เป็นดิสโทเปียอยู่แล้ว นี่ก็เป็นวาทกรรมที่มาช้าไปมาก

อืม ใน golang
เท่าที่รู้ เหมือนว่า sarama จะเป็นตัวที่คนชอบใช้มากกว่านะ..
ไคลเอนต์ Kafka นี่.. ซับซ้อนกว่าที่คิดมากเวลาเจอบรोकเกอร์ล่มหรือมีข้อยกเว้น
จะครอบคลุมทุกเคสได้ไหม ..

ผมเคยเขียนไว้ก่อนหน้านี้เกี่ยวกับช่วงต้นของคดีนี้อย่างละเอียดกว่านี้:

จุดเริ่มต้นของคดีคือในปี 1999 เมื่อรัฐบาลอังกฤษตัดสินใจไม่ยกเลิกและนำระบบจ่ายเงินบำนาญและสวัสดิการที่ไปรษณีย์เคยสงสัยในความน่าเชื่อถือและยกเลิกไปแล้ว มาใช้ในการอัปเกรดระบบเดิมของไปรษณีย์ที่บันทึกธุรกรรมลงบนกระดาษ

ระบบเครื่องขายหน้าร้านอิเล็กทรอนิกส์ (electronic point-of-sale system) ที่ถูกเรียกว่า Horizon นี้มีปัญหามากมาตั้งแต่แรก โดยมีการพบความคลาดเคลื่อนระหว่างเงินสดที่บันทึกไว้ใน Horizon กับจำนวนเงินสดที่ถืออยู่จริง และว่ากันว่าบรรดานายไปรษณีย์ที่ตกใจก็เริ่มโทรไปยังศูนย์บริการลูกค้าของ Horizon

ข้อผิดพลาด "Dalmellington" ทำให้หน้าจอค้างเมื่อผู้ใช้พยายามยืนยัน (confirm) ว่าได้รับเงินสดหรือไม่ และในสถานการณ์นี้ทุกครั้งที่กด Enter ระบบจะบันทึกว่าได้รับเงินสดแล้วโดยไม่แสดงอะไรเลย

ข้อผิดพลาด "Calendar Square" ทำให้เกิดธุรกรรมซ้ำ เนื่องจากข้อผิดพลาดของฐานข้อมูลที่เป็นรากฐานของระบบ...

สาเหตุคืออะไร? คงมีอยู่หลายอย่าง แต่ที่เห็นเด่นชัดคือ 1) บุคลากรไม่เพียงพอ 2) ความเชื่ออย่างงมงายในความไร้ข้อผิดพลาดของซอฟต์แวร์ 3) ระบบราชการ

1. บุคลากรไม่เพียงพอ

ตามคำบอกเล่าของเดวิด แมคโดเนลล์ ผู้มีส่วนร่วมในการพัฒนา "ในทีมพัฒนามีอยู่ 8 คน สองคนเก่งมาก สองคนอยู่ระดับปกติแต่ยังทำงานร่วมกันได้ ส่วนที่เหลืออีก 3~4 คนไม่มีความสามารถในการเขียนโค้ดระดับมืออาชีพ จึงทำงานได้ไม่เหมาะสม"

https://x.com/KayKiwoongKim/status/1825209040575873330

แก่นของปัญหาก็คือการพยายามฝืนสร้างเว็บให้มีลักษณะเหมือนแอปภายในโปรโตคอล HTTP ที่มีพื้นฐานอยู่บน "เอกสาร" ของเว็บ
และจึงมีความเห็นว่าถ้าต้องการความสามารถระดับแอปเพื่อแก้ปัญหานี้ ก็น่าจะสร้างโปรโตคอลและเฟรมเวิร์กใหม่สำหรับแอปไปเลยจะดีกว่า
เหมือนกับที่บนสมาร์ตโฟนไม่ได้รันโปรแกรมเนทีฟล้วน ๆ โดยตรง แต่รันแอปที่ถูกแซนด์บ็อกซ์ไว้รูปแบบหนึ่ง ซึ่งในกรณีนี้ก็คือโครงสร้างที่ทำงานอยู่ในระดับเบราว์เซอร์
แน่นอนว่าเพื่อไม่ให้จบลงแบบ ActiveX ก็ต้องมีความเปิดกว้างและการทำให้เป็นมาตรฐานนำหน้าก่อน

ความเห็นเกี่ยวกับคำว่า "น่าเบื่อ" น่าสนใจดีนะครับ 555 ถ้าจะเปลี่ยนเป็นคำอื่น คำไหนจะดีกว่ากัน? แบบเดิม ๆ, ธรรมดา ๆ?

มันเป็นคนละประเด็นกับที่คุณกำลังพูดถึงโดยสิ้นเชิงไม่ใช่หรือ?

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

สุดท้ายแล้วก็เป็นเรื่องยุคที่ต้องดาวน์โหลดโปรแกรมเนทีฟมาใช้ แล้วใช้ ActiveX บนนั้นนั่นเองครับ

การแปล boring ว่า "น่าเบื่อ" ทำให้ความหมายดั้งเดิมหายไปมากเกินไปหน่อย boringness เป็นหนึ่งในปรัชญาการออกแบบของ Go ครับ

โดนหลอกอีกแล้ว~

ดูเหมือนจะไม่ได้ใช้งานง่ายแบบคลิกเดียวจบ

ตอนนี้ Grok 4 เป็นโมเดล AI ชั้นนำแล้ว
รีวิว Grok 4 โดย Simon Willison
Grok ค้นหาว่า Elon Musk พูดอะไรบน X เกี่ยวกับประเด็นอิสราเอล-ปาเลสไตน์

ทุกอย่างดีหมด แต่ถ้าใช้ตัวนี้จะไม่สามารถควบคุม Wireguard จากในระบบได้ ถ้าอยากใช้แยกจาก Tunnel ก็ต้องแยกไปใช้บน VM ครับ

แม้จะเป็นเว็บที่มีลักษณะเหมือนแอป ผมก็คิดว่าควรมุ่งไปในทิศทางที่ใกล้เคียงกับข้อสรุปที่บทความกล่าวไว้ การใช้ JavaScript มาก ๆ จะทำให้ฝั่งไคลเอนต์หนักขึ้น

จริง ๆ ก็ไม่ใช่ว่าจะไม่มีเฟรมเวิร์กที่ทำแบบนั้นได้ อย่าง Next.js เอง ถ้าลดการใช้ client component ให้เหลือเฉพาะตอนที่จำเป็น ก็พอทำได้ประมาณหนึ่ง และอย่างฝั่ง Rails ที่อีกท่านพูดถึงก็มี Hotwire(https://hotwired.dev/) ซึ่งเป็นชุดเฟรมเวิร์กที่รองรับเว็บแบบแอป (เช่น Turbo, Stimulus เป็นต้น) ให้เข้าใกล้ข้อสรุปที่ผู้เขียนพูดถึงได้มากทีเดียว

เพราะดีลเข้าซื้อกิจการของ OpenAI ทำให้ Claude หยุดให้ไลเซนส์เวอร์ชันล่าสุด ดังนั้นถ้าจะใช้โมเดล Claude 4.x บน Windsurf ก็ต้องซื้อ API ตรงในราคาแพง ไม่ทราบว่า Claude จะกลับมาไหม?

ต่างจากวัฒนธรรมการพัฒนาในเกาหลีที่งานไหลลงมาตามสายจากผู้บริหาร -> นักวางแผน -> นักพัฒนา ในโลกตะวันตกไม่มีแนวคิดเรื่องนักวางแผนแบบเกาหลี และนักพัฒนามักมีส่วนร่วมอย่างจริงจังกับการวางแผนผลิตภัณฑ์ด้วย บทบาทอย่าง PM ในตะวันตกเองก็ไม่ได้ตรงกับนักวางแผนของเกาหลีแบบสมบูรณ์ เช่นเดียวกับที่ cover letter กับจดหมายแนะนำตัวไม่ได้เป็นแนวคิดเดียวกันทั้งหมด แน่นอนว่าในกรณีของเกมซึ่งมีลักษณะเป็นโปรเจกต์เชิงสร้างสรรค์สูง และความสนุกกับเกมเพลย์เป็นสิ่งสำคัญ แม้ในตะวันตกจะมีโครงสร้างแนวราบมากกว่าเอเชีย แต่ก็ยังเป็นการไหลลงมาจากผู้กำกับไปสู่นักพัฒนาอยู่ดี

เพราะปรัชญาการพัฒนาที่แต่ละคนยึดถือนั้นแตกต่างกันอย่างมากนี่แหละครับ.........

สมกับเป็น AI ที่ไม่เป็นธรรมเหมือนกันนะ

น่ากลัวมาก
เพราะอาจเกิดเหตุการณ์ที่บันทึกซึ่งถูกสร้างขึ้นอย่างมุ่งร้าย
เอาชนะความทรงจำและประสบการณ์ กลายเป็นหลักฐาน
และย้อนกลับมาคุกคามพวกเราได้