ระหว่างนั่งกินข้าวกลางวัน มีคำถามเกี่ยวกับการพัฒนา Spring Bootว่ามีคำแนะนำอะไรบ้าง ที่จำเป็นต่อการพัฒนาก็เลยบอกไปสั้น ๆ ว่าเขียน code ให้ดี ทดสอบให้ได้ที่เหลือก็รับผลกรรม !!
ลองทดสอบกับ Go gin ด้วย test mode
จากกลุ่ม Golang Thailand มีคำถามเกี่ยวกับการทดสอบระบบงานที่พัฒนาด้วยภาษา Goโดยในคำถาม จากที่เข้าใจเป็นดังนี้ ระบบงานพัฒนาด้วย Gin web framework ทำการ post data ด้วย Form data ต้องการทดสอบผ่าน Test mode ของ Gin + HttpTest
การ Refactor code ไม่ควรอยู่ใน backlog ?
เป็นคำถามที่น่าสนใจว่า การ Refactor code ควรหรือไม่ ที่จะอยู่ใน backlogบ่อยครั้งเราจะพบว่า ทำ ๆ ให้มันเสร็จไปก่อน เดี๋ยวไม่ทันส่ง เดี๋ยวเราค่อยกลับมาแก้ไขให้มันดีขึ้นกัน
มาลองเล่น Standalone Component ใน Angular 14 กัน
เพิ่งมีเวลาว่างมาดู Angular 14 ที่ถูกปล่อยออกมาเมื่อต้นเดือนซึ่งมี feature หลายตัวที่น่าสนใจแต่มีตัวหนึ่งที่ติดตามมาเรื่อย ๆ ตั้งแต่เปิด RFCคือ Standalone Component ดังนั้นเรามาทำความรู้จัก และลองใช้งานกันนิดหน่อย
ตรวจสอบ resource limit ใน Kubernetes กันด้วย Kube-capacity
การจัดการ resource ต่าง ๆ ใน Kubernetes นั้นเรื่องของ resource limit และ request ในการใช้งานไม่ว่าจะเป็นแต่ละ pod แต่ละ nodeซึ่งเราสามารถตรวจสอบง่าย ๆ ด้วย Kube-capacity
มาลองสร้าง Golang package server ใช้เอง
เพิ่งเห็นว่าเราสามารถสร้าง Golang package server ได้เองสำหรับการจัดการ package และการเขียนเอกสารต่าง ๆ ได้แบบง่าย ๆโดย source code อยู่ที่ Pkgsite ใน GitHub
เจอปัญหา N+1 อีกแล้ว
ระหว่างการ review code ของระบบงานสิ่งที่พบเจอบ่อยมาก ๆ คือ N+1 problemฟังแล้วอาจจะงง ๆ ว่าคืออะไรมาดูตัวอย่างกัน
สรุปการ generate code จาก sql ด้วย sqlc, DBML และ Taskfile
ใน project ที่ทำอยู่นั้น มีการใช้งาน database ตลอดพบว่าต้องเขียนชุดคำสั่ง sql และ เขียน code ซ้ำ ๆ เยอะจึงเกิดความขี้เกียจ ก็เลยหาแนวทางแก้ไขหน่อยจึงพบแนวทางที่น่าสนใจ และ นำมาใช้งานดังนี้
GitHub Copilot ปล่อยแบบ public มาให้ใช้แล้ว แต่ไม่ฟรีนะ !!
หลังจากที่ GitHub Copilot ปล่อย technical preview ให้ไปขอลองใช้งานโดยมี developer มากกว่า 1.2 ล้านคน ใน 1 ปีที่ผ่านมาซึ่งตอนนี้ได้ปล่อยตัวเต็มเป็น public ออกมาให้ใช้งานแล้วแต่ &#
ว่าด้วยเรื่องของการแบ่งปัญหาออกมาแก้ไข
จากการแบ่งปันเรื่องการพัฒนา software นั้นมีเทคนิคหนึ่งที่ใช้งานบ่อย ๆ และแนะนำไป คือการแก้ไขปัญหาใหญ่ ๆ ด้วยการแบ่งเป็นปัญหาเล็ก ๆ ออกมาเพื่อแก้ไขทีละปัญหา และเมื่อแก้ไขจนครบจะช่วยให้เราแก้ไขปัญหาใหญ่ ๆ ได้หรืออาจจะเรียกว่าการทำ work break down นั่นเอง