ในโลกของการเขียนโปรแกรม มันจะมีคำว่า imperative กับ declarative มันคืออะไรแล้วมันทำให้การเขียนโปรแกรมของเราเปลี่ยนไปยังไง มาลองถอดบทเรียนกัน เริ่มจากแปลตรงๆ * Imperative (How): ต้องสั่งทีละขั้นตอนว่าต้องทำอย่างไร (เหมือนการบอกทางแบบละเอียด: เลี้ยวซ้าย 100 เมตร, เลี้ยวขวา...) * Declarative (What): บอกแค่ว่าผลลัพธ์
human resource
ในปี 2546 นักศึกษาคณะวิทยาศาสตร์ที่เรียนอยู่ที่ศูนย์รังสิตมาตลอดแบบผม ได้มีโอกาสเข้าเมืองไปเรียนที่ธรรมศาสตร์ ท่าพระจันทร์ เป็นครั้งแรก นอกจากจะตื่นตาตื่นใจกับของอร่อยมากมายรอบมหาวิทยาลัยแล้ว บรรยากาศที่ศูนย์ท่าพระจันทร์มันมีมนต์ขลังแปลก ๆ ตัวผมได้
ในฐานะโปรแกรมเมอร์ เรามักหมกมุ่นอยู่กับการเปลี่ยนแปลง (Mutation) เราสนใจว่า State จะไหลจาก A ไป B อย่างไร แต่เรามักลืมตั้งคำถามที่สำคัญที่สุดคำถามหนึ่ง: “ก่อนที่สิ่งนี้จะกลายเป็นสิ่งนั้น… มัน ‘เป็น’ อะไรมาก่อน?” นี่ไม่ใช่แค่คำถามเชิงตรรกะ แต่มันคื
Specification
บ่อยครั้งที่ผมได้ยินน้อง ๆ ออดส์ทีม (ODT) เล่าว่า งานที่ทำอยู่ไม่ท้าทายเลย เพราะเพียงได้รับ Specification มาจาก System Analyst (SA) หรือ Tech Lead ที่เป็นพนักงาน แล้วน้องก็มีหน้าที่เขียนโค้ดตามนั้นไปอย่างเดียว บ่อยครั้งที่น้องเห็นวิธีการที่ดีกว่าในการแก้ปัญหานี้ แต่พอเสนอไอเดียไปก็ไม่ได้รับการรับฟัง
ในโลกของ Rust “ความอิสระ” เป็นเพียงภาพลวงตา เพราะทุกการขยับเขยื้อนของข้อมูลล้วนมีพันธนาการที่เรียกว่า Ownership กำกับอยู่เสมอ หากเราเปรียบฟังก์ชันทั่วไปเป็นเหมือนคนแปลกหน้าที่เดินผ่านมาแล้วจากไป Closures ก็คงเป็นเหมือน “เงา” ที่ไม่ได้อยู่โดดเดี่ยว แต่มั
QA Knowledge Series 5 นาทีกับบทความนี้ จะเปลี่ยนวิธีเขียน test document ของคุณไปตลอดกาล — เพราะ QA หลายคนเขียน Test Case ได้คล่อง แต่พอถามว่า Test Scenario คืออะไร ก็ตอบว่า "เหมือนกันนั่นแหละ" ถ้าคุณเคยถูกถามว่า "Test Scenario กั
ในโลกของการเขียนซอฟต์แวร์ เรามักจะติดอยู่กับคำถามที่ว่า “วัตถุนี้คืออะไร?” และคำตอบส่วนใหญ่มักจะหนีไม่พ้นการมองหา “สายเลือด” หรือ Hierarchy ของมัน แต่ถ้าเราลองเปลี่ยนมุมมองจากการถามว่ามัน คือใคร มาเป็นการถามว่ามัน ทำอะไรได้ เราอาจจะพบทางออกของระบบที่ยืดหยุ่นและเป็นอิสระมากกว่าเดิ
ในมหานครที่ฉาบด้วยแสงนีออนและความโกลาหลของข้อมูล เหล่าโปรแกรมเมอร์มักจะติดอยู่ในวงจรของการพยายามควบคุมสิ่งที่ควบคุมไม่ได้ เราภาวนาให้ Network ไม่ล่ม เราอ้อนวอนให้ User ใส่ Input ที่ถูกต้อง และเราเจ็บปวดเมื่อระบบ panic! พังทลายลงต่อหน้า แต่นักคิดสโตอิก (Stoic) เมื่อสองพันปีก่อนไม่
ในโลกของการเขียนโปรแกรม เรามักมองว่าภาษาเป็นเพียงเครื่องมือ (Tooling) แต่สำหรับผู้ที่คลุกคลีกับภาษา Rust จะรู้ดีว่าภาษานี้มี “ปรัชญา” บางอย่างที่ฝังรากลึกอยู่ภายใต้ไวยากรณ์ที่เคร่งครัด โดยเฉพาะเรื่องการจัดการหน่วยความจำที่ไม่ได้มองว่าเป็นแค่เรื่องทางเทคนิค แต่
ในระเบียบอันเคร่งครัดของ Rust… การเป็นเจ้าของ (Ownership) คือพันธนาการ ข้อมูลทุกชุดต้องมีนายทาสที่คอยควบคุม และเมื่อสิ้นสุดอำนาจ ทุกอย่างจะถูกทำลายทิ้งอย่างไร้ความเมตตา แต่นี่คือความจริงที่โปรแกรมเมอร์ส่วนใหญ่หวาดกลัว: การครอบครองคือภาระ และยิ่งคุณถือครองมากเท่าไหร่
ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้
ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะถูกสอนให้เป็นคนรอบคอบ ให้คิดถึงความเป็นไปได้ให้ครบทุกด้าน แต่บ่อยครั้งที่ “ความรอบคอบ” นั้นกลับกลายเป็นกับดักที่สร้างความซับซ้อนจนเราเองก็รับมือไม่ไหว วันนี้ผมอยากจะหยิบยกปรัชญาหนึ่งที่ผมพบจากการเขียนโปรแกรม โดยเฉพาะในภาษาอย่าง Rust ซึ่งมันไม่