ในการพัฒนา Mobile app ด้วย React Native นั้นปกติก็จะมีการทดสอบด้วย Jest + React Testing มาให้ด้วยเป็นการทดสอบในระดับ unit test เท่านั้นแต่ปัญหาคือ เราจะมั่นใจได้อย่างไรว่าเมื่อถูก build เป็น App แล้ว ยังสามารถทำงานได้ตามที่คาดหวังหนึ่งในวิธีการคือ การทดสอบ App แบบอัตโนมัติ
จากหนังสือ Productivity Ninja นั้น อ่านไปเจอหัวข้อ D is for Decisionสำหรับเรื่องของการจัดการ Emailว่าอะไรมีความสำคัญอย่างไร เพื่อลงมือทำซึ่งน่าสนใจดี จึงทำการบันทึกไว้อ่านนิดหน่อย โดยที่ D นั้นจะมาจากได้หลายคำ ประกอบไปด้วย
คำถามเกี่ยวกับ Postmanถ้าต้องการ merge collection ต่าง ๆ เข้าด้วยกันก่อนที่จะทำการ run collection ด้วย Postman หรือ newmanจะต้องทำอย่างไร
จาก Release note ของ Spring Boot 2.5 นั้นพบว่ามี feature เกี่ยวกับการจัดการลำดับการทำงานของการ initial data ใน Database มาใหม่ซึ่งเปลี่ยนจาก Milestone version ไปเลยจึงทำการสรุปการทำงานและใช้งานไว้นิดหน่อย
จากการปรับเปลี่ยนโยบายการใช้งาน Docker Desktop ใหม่สามารถอ่านรายละเอียดเพิ่มเติมได้จาก Docker is Updating and Extending Our Product Subscriptionsซึ่งกำหนด price plan ของ subscriptionรวมทั้งเงื่อนไขต่าง ๆ ของการใช้งานแสดงดังรูป
จากบทความของ Slack เรื่อง How we design out APIs at Slackทำการสรุปแนวทางในการออกแบบ API ของระบบออกมาว่าเป็นอย่างไรบ้างเพื่อช่วยทำให้ผู้ใช้งานหรือ developer ใช้งานง่ายขึ้นอีกทั้งช่วยให้การดูแลรักษา API ง่ายขึ้นด้วยซึ่งควรต้องคิดตั้งแต่การออกแบบกันเลยทีเดียวมิเช่นนั้นแทนที่จะได้ API ที่ดีมีประโยชน์ กลับได้ของที่แย่ ๆ ออกมาโดยมีแนวทางของการออกแบบดังนี้
สัปดาห์ที่ผ่านมา ทำการออกแบบ review และ พัฒนา API ของระบบงานพบว่าสิ่งที่ทำออกมานั้นมีปัญหาหลายอย่างไม่ว่าจะเป็นการพัฒนาที่ยากไม่ว่าจะเป็นการใช้งานที่ยากอีกดังนั้นจึงสรุปต้นเหตุที่ก่อให้เกิดปัญหาขึ้นมา
Dart 2.14 นั้นถูกปล่อยออกมาพร้อมกับ Flutter 2.5 ซึ่งมีความสามารถที่น่าสนใจเพิ่มเติมและปรับปรุงจึงทำการสรุปไว้นิดหน่อยยกตัวอย่างเช่น สนับสนุน Apple silicon Standard lint สำหรับการทำ code analysis, code style และ format ปรับปรุงความเร็วของ Pub tool สำหรับจัดการกับ dependency ต่าง ๆ จากการปรับปรุงการทำงานของ Pub tool ช่วยทำให้การทดสอบผ่าน $dart test เร็วขึ้น การ build ก็ทำการแบบ parallel อีกด้วย
คำถามที่น่าสนใจ จากทีมที่เริ่มนำแนวทางของการทดสอบแบบอัตโนมัติมาใช้งานทั้ง Unit testทั้ง API testทั้ง UI testหรือจะเป็น integration, component และ contract test ก็ตามปัญหาที่มักจะพบเจอประกอบไปด้วย ใช้เวลาในการทดสอบเยอะขึ้นเรื่อย ๆ เนื่องจากจำนวน test เยอะขึ้น มี test case จำนวนมากที่ผ่านบ้าง ไม่ผ่านบ้าง ทั้ง ๆ ที่ไม่ได้เปลี่ยนแปลงอะไร (Flaky test) เราจะแก้ไขและปรับปรุงอย่างไรดี
ไม่มีอะไรมาก เห็นคุยกันเรื่องการทำ API สำหรับดึงข้อมูลรายชื่อจังหวัดของประเทศไทยเพื่อนำมาใช้งานกันจึงไปค้นหาดุใน Google ก็เจอเยอะเลยแสดงว่าเป็นแนวปฏิบัติปกตินะ !!!
