อ่านไปเจอเรื่อง Path to Production พบว่าน่าสนใจมาก ๆ โดยเป็น workshop หรือ แนวทางในการทำงานร่วมกันที่ทำงานเป็นแบบ cross functional team/peopleนั่นคือ เป็นการทำงานข้ามแผนกหรือส่วนการทำงานมากมาย
design Archive
ว่าด้วยเรื่องของการเก็บรูปลง Database
จากกลุ่มสมาคม programmer นั้น มีคำถามเกี่ยวกับการเก็บข้อมูลรูปว่าทำอย่างไรดี โดยทางเลือกที่แนะนำกันมา ประกอบไปด้วย ทำการ encode ข้อมูลรูปก่อน จากนั้นค่อยเก็บ เก็บเป็น binary ลง database เช่น BLOB (Binary Large OBject) เก็บรูปลง disk แล้วเก็บเฉพาะ path และชื่อรูปลง database ใช้งาน CDN (Content Delivery Network)
สรุปแนวทางการออกแบบ API ของ Slack
จากบทความของ Slack เรื่อง How we design out APIs at Slackทำการสรุปแนวทางในการออกแบบ API ของระบบออกมาว่าเป็นอย่างไรบ้างเพื่อช่วยทำให้ผู้ใช้งานหรือ developer ใช้งานง่ายขึ้นอีกทั้งช่วยให้การดูแลรักษา API ง่ายขึ้นด้วยซึ่งควรต้องคิดตั้งแต่การออกแบบกันเลยทีเดียวมิเช่นนั้นแทนที่จะได้ API ที่ดีมีประโยชน์ กลับได้ของที่แย่ ๆ ออกมาโดยมีแนวทางของการออกแบบดังนี้
สรุปปัญหาจากการออกแบบ API
สัปดาห์ที่ผ่านมา ทำการออกแบบ review และ พัฒนา API ของระบบงานพบว่าสิ่งที่ทำออกมานั้นมีปัญหาหลายอย่างไม่ว่าจะเป็นการพัฒนาที่ยากไม่ว่าจะเป็นการใช้งานที่ยากอีกดังนั้นจึงสรุปต้นเหตุที่ก่อให้เกิดปัญหาขึ้นมา
แนะนำ Cloudcraft สำหรับการสร้าง diagram สวย ๆ
พอดีเห็น Diagram สวย ๆ ซึ่งอยู๋บนพื้นฐานของ AWS diagramจึงลองไปค้นหาว่าทำมาอย่างไร จากที่ไหนก็เลยไปเจอว่า เขาสร้างจาหห Cloudcraft
คำแนะนำในการออกแบบ API ที่ดี
จากการสอนและแนะนำเรื่องการออกแบบ API (Application Programming Interface) ที่ดีไม่ว่าจะเป็น code ไม่ว่าจะเป็น RESTFul API ก็ตามAPI เหล่านั้นควรมีคุณสมบัติต่าง ๆ ดังนี้ ออกแบบในมุมมองของคนใช้งาน ไม่ใช่มุมมองขอคนสร้าง ง่ายต่อการเรียนรู้และใช้งาน โดยเอกสารเป็นสิ่งสุดท้ายที่ควรอ่าน ยากต่อการใช้งานผิด ง่ายต่อการดูแลรักษาในระดับ code ซึ่งทำให้พัฒนาและต่อยอดได้ง่าย ต้องมีความสัมพันธ์กับความต้องการต่าง ๆ
อย่าลืมจัดการกับ Error response ของ API นะ มันสำคัญมาก ๆ
เนื่องจากช่วงนี้ต้องไปร่วมพัฒนาระบบงานที่มี RESTful APIs ให้บริการ พบว่าสิ่งหนึ่งสำหรับนักพัฒนาที่ดีจะต้องคำนึงถึงก็คือ การจัดการกับ error หรือข้อผิดพลาดต่าง ๆ ซึ่งถ้าจัดการได้ดี จะทำให้ API ที่สร้างนั้นมันดูดีมากขึ้น เนื่องจากสิ่งที่สร้างนั้น เพื่อให้คนใช้งานนะ ดังนั้นการออกแบบสำหรับการจัดการข้อมูลพลาดจึงสำคัญมาก ๆ จึงทำการสรุปเรื่องที่ต้องใส่ใจไว้ดังนี้
Developer ควรลดความซับซ้อนของ code ลงบ้างนะ
ช่วงนี้ว่างจากงาน เลยนั่งเขียนระบบงานเอาไว้ใช้เอง ซึ่งเป็นระบบ CRM เล็ก ๆ ง่าย ๆ โดยมี requirement ดังต่อไปนี้ การจัดการข้อมูลบริษัทที่ทำงานด้วย การจัดการชื่อผู้ติดต่อของแต่ละบริษัท การจัดการเรื่องสัญญาการทำงานของแต่ละบริษัท ประกอบไปด้วย การ training, coaching, consuling และ project มาเริ่มพัฒนาในส่วนของ Entity ดีกว่า
ค่าใช้จ่ายที่มากับ source code
ปัจจุบัน developer ต้องทำงานกับ code แบบไหนกันนะ ? ทำงานกับ legacy code, ugly code หรือ beautiful code กันอยู่นะ ? จากที่ทำงานมานั้น มักจะอยู่กับ ugly code มากกว่านะ ซึ่งมันไม่น่าจะใช่เรื่องปกติของการพัฒนา software หรือเปล่านะ ? คำถามที่มักได้ยินมาตลอดคือ แล้วเราควรที่จะ rewrite หรือ refactor มันดีล่ะ
ทำความเข้าใจกับปัญหา N + 1
พี่ @roofimon ส่งบทความเรื่อง Web API and N+1 problem มาให้อ่าน เป็นเรื่องที่น่าสนใจมาก จึงทำการสรุปหน่อยดีกว่า ดังนั้นมาทำความรู้จักและเข้าใจกับ ปัญหา N+1 กัน นั่นใจว่าเป็นปัญหาที่ทุกๆ คนเห็นหรือทำอยู่เป็นประจำ