อ๊ะ ฮือ เดี๋ยวฉันจะแก้ไขอันนี้ภายหลังนะครับ/ค่ะ

งั้น <selectlist> ก็จะไม่จำเป็นอีกต่อไปแล้วเหรอ?

Show GN: เว็บเกมจัดอันดับ/แบตเทิลการตั้งค่าตัวละคร

พูดอีกเรื่องหนึ่งคือ ใน Slackbot ดูเหมือนว่า <select> ในชื่อเรื่องจะไม่แสดงนะ 555

เมื่อวานตอนเห็นยังไม่รู้เลยว่าเป็นของ Microsoft โอ้โห ต้องลองใช้ดูแล้ว

ดูท่าบล็อกเกอร์ที่คอยจับตาคอมมิตใหม่ ๆ เพื่อคาดเดาฟีเจอร์ใหม่คงจะเสียดายกันน่าดูนะครับ

เห็นด้วย..!

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

ไม่จำเป็นต้องทำสื่อหรือเอกสารที่ดูดีตั้งแต่แรก สิ่งสำคัญคือการสร้างนิสัยในการจัดระเบียบแล้วเขียนเอกสาร แม้จะเรียบง่ายก็ตาม
ตัวผมเองก็รู้ด้วยหัวว่ามันสำคัญ แต่ก็ยังทำได้ไม่ค่อยดีนัก... เป็นหัวข้อที่ยากจริง ๆ

ผมอาจไม่ได้รู้ลึกถึงขั้นพื้นฐานอย่างแท้จริง แต่ผมเคยเห็นว่าถ้าไม่รู้พื้นฐาน จะสร้างผลลัพธ์ที่ทั้งน่าเหลือเชื่อและคาดไม่ถึงอย่างยิ่งได้จริง ๆ
ยกตัวอย่างเช่น ทำระบบให้ดึงทุกเรคอร์ดใน DB มาใส่ไว้ในหน่วยความจำทั้งหมด แล้วค่อยค้นหาในหน่วยความจำ
ตอนที่มีเรคอร์ดน้อยก็ทำงานได้ดี แต่พอเรคอร์ดมากขึ้น หน่วยความจำก็ระเบิด
ที่เขียนแบบนี้ก็เพราะไม่เข้าใจเลยว่าหน่วยความจำกับ DB ต่างกันอย่างไร
นี่เป็นแค่ตัวอย่างหนึ่ง และทุกครั้งก็มักจะอิมพลีเมนต์ไปในทิศทางที่คาดไม่ถึงจริง ๆ
โปรแกรมเมอร์ทั่วไป(?) คงจินตนาการไม่ออกจริง ๆ

https://th.news.hada.io/topic?id=4138

มีอีกตัวที่ชื่อว่า Coolify อยู่เหมือนกันครับ

ผมก็เห็นด้วยกับบทความนี้เช่นกัน
ผมมองว่าการนิยามปัญหาด้วยค่าสถานะที่ถูกทำให้อยู่ในระดับนามธรรมแล้วมีประโยชน์ต่อการค้นพบปัญหา และกำลังพยายามสร้างเครื่องมือจัดการสถานะที่ชัดเจนแบบมองเห็นได้และระบุได้อย่างชัดแจ้ง เช่น การทำภาพสถานะด้วยไดอะแกรม, Unreal Blueprint หรือ workflow

คงต้องมองที่ภาษาก่อนสินะ

เป็นบทความที่ทำให้นึกถึงวิชาเอกทฤษฎีการคำนวณเลยครับ! แนะนำให้คนที่ทำงานด้านโปรแกรมมิงลองศึกษาเพิ่มเติมดูครับ

ดีมากเลยใช่ไหมล่ะ? นึกไม่ถึงเลยว่าแม้แต่แบบนี้ก็มีเป็นโอเพนซอร์สด้วย ฮ่าๆ

แย่กว่านั่นแหละดีกว่า!

อย่างไรก็ดี งานวิศวกรรมซอฟต์แวร์ในภาคปฏิบัติจะเปลี่ยนไปมากแน่นอน นักปั่นโค้ดจะมีความสามารถในการแข่งขันลดลง แต่ผมเดิมพันว่าวิศวกรที่สามารถสร้างผลิตภัณฑ์ได้จริงแบบ End-to-End จะเป็นคนที่อยู่รอด

ผมเองก็รู้สึกว่า OpenAPI function calling น่าจะดีกว่าไม่ใช่เหรอครับ เพราะการต้องมาทำอันนี้ขึ้นใหม่ด้วยโปรโตคอล MCP ก็เป็นงานเหมือนกัน

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

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

น่าเสียดายนิดหน่อยที่ในยุคที่แม้แต่ Docker Desktop ก็ใช้ Kubernetes แล้ว แต่กลับรองรับแค่ Docker Swarm เท่านั้น

> ERROR: Unsupported distribution 'manjaro'

พอลองทดสอบดูก็พบว่าไม่รองรับ Manjaro น่าเสียดายนิดหน่อยครับ

Anthropic เปิดซอร์ส Model Context Protocol
วิธีพัฒนา Model Context Protocol (MCP)
คำอธิบายเปรียบเทียบ MCP กับ API
Awesome MCP Servers - รายการเซิร์ฟเวอร์ที่รองรับ Model Context Protocol