จากบทความของ Google Cloud เรื่อง Build slim Docker images for Dart apps
จากบทความอธิบายวิธีการสร้าง Dockerfile ของระบบงานที่พัฒนาด้วยภาษา Dart
เพื่อลดขนาดของ Docker Image ให้เล็กลง
และเหมาะสมกับการ run ในโลกของ Container

เนื่องจาก base image ของ Dart นั้นมีขนาดที่ใหญ่เกินไป

นั่นคือมีขนาดใหญ่กว่า 600 MB
ยกตัวอย่างของการใช้งาน base image ปกติ

ดังนั้นจึงทำการแก้ไข เพื่อปรับปรุง

ด้วยการสร้าง Docker Image ที่สร้างจาก scratch กันไปเลย
อยู่ที่ subfuzion/dart-docker-slim
จึงนำมาใช้งานดังนี้ เขียนด้วย Docker Multi-stage build
โดยขนาดของ image เหลือเพียง 40 MB เท่านั้น

เป็นอีกวิธีการที่น่าสนใจครับ
ตามจริงเรายังสามารถใช้ dart compile ได้
รวมทั้ง dart2native ได้อีก

จากงาน Robocon 2021 มีหลายเรื่องที่น่าสนใจ
หนึ่งในนั้นที่นั่งดูและฟังคือ HOW TO AVOID JAIL FOR NASTY CODE ?
แนะนำ Static code analysis tool สำหรับ Robot Framework
โดยมีเครื่องมือแนะนำทั้ง

• Robocop
• Robo Tidy
• Test data clean-up tool (build-in)
• Robot Clean

ตัวที่น่าสนใจคือ Robocop มีความสามารถดังนี้

• ช่วยตรวจสอบคุณภาพของ code
• ทำงานได้อย่างรวดเร็ว
• ใช้งานง่าย
• Config rules ต่าง ๆ ได้ง่ายและยืดหยุ่น
• ได้ report ของการตรวจสอบที่อ่านเข้าใจง่าย
• ทำการ parsing ผ่าน Robot Framework API documentation

ทำการติดตั้งดังนี้

โดยทำงานบน Python 3.6 ขึ้นไป และ Robot FRamework 3.2.1 ขึ้นไป

ลองใช้งานกันดูครับ
ว่า Code ที่เราเขียนด้วย Robot FRamework เป็นอย่างไรกันบ้าง ?
และดูเครื่องมือต่าง ๆ เพิ่มเติมได้ที่ Awesome Robot Framework

จากที่คุยเรื่อง Component Testing ของ Cypress ใน alpha version
หรือเรียกว่า Cypress Component Testing Library
พบว่า มีความเข้าใจผิดเรื่องของ Component testing นิดหน่อย
เพราะว่า ชื่อดันไปเหมือนกับ Service Component Testing ใน Microservices อีกด้วย
จึงทำการอธิบายไว้นิดหน่อย

ปล. Cypress Component Testing Library สามารถเปลี่ยนแปลงได้อีกมาก

ก่อนอื่น ๆ Component Testing ของ Cypress นั้น

คือการทดสอบแต่ละ component ที่เราต้องการ
ไม่ว่าจะเป็น Component ใน ReactJS, Angular และ VueJS

ซึ่งปกติการทดสอบในแต่ละ component
จะทดสอบผ่าน test framework/library เช่ร Jest หรือ Mocha
รวมทั้งการ render จะใช้ virtual browser แทนคือ JSDom นั่นเอง

แต่ใน Cypress นั้นจะทดสอบบน browser จริง ๆ ไปเลย
ทำให้ง่ายต่อการทดสอบและ debugแสดง
ดังรูป

การทดสอบแบบนี้ เราสามารถเข้าถึง Component ที่ต้องการได้เลย

ไม่จำเป็นต้องเข้า URL ใด ๆ
เพียงแค่ mount Component ที่ต้องการได้เลย
จากภาพ Component ที่สามารถทดสอบได้ด้วย Cypress คือ

• Main component
• Component 1
• Component 2

ส่วนอีกเรื่องคือ Service Component Testing

ซึ่งมีที่มาจาก Microservices Testing
เป็นการทดสอบในแต่ละ service แยกกันไปเลย
แน่นอนว่า มีแนวคิดเดียวกันคือ Isolated component/service testing นั่นเอง
ช่วยทำให้เรามั่นใจมากยิ่งขึ้นว่า
service หนึ่ง ๆ ของเราทำงานได้ตามที่เราคาดหวัง
ด้วยการเข้าตาม URL ที่ต้องการ
รวมทั้งมีการจำลองหรือควบคุมการทำงานของ dependency ที่ใช้งาน
ยกตัวอย่างเช่น External REST API เป็นต้น

ดังนั้นถ้าเรามองว่าระบบงานในฝั่งของ Frontend เป็น service หนึ่งของเรา

แล้วมี dependency ที่ใช้คือ External REST API
เราสามารถทดสอบส่วนของ Frontend แบบ Service Component Testing
ด้วยการใช้งาน Cypress ได้เลยด้วยการใช้ Intercept network request
ที่ออกจาก browser ของ Cypress ได้เลย

เพียงเท่านี้เราสามารถทดสอบการทำงานของระบบงาน
ได้ตามที่เราต้องการ
เพื่อเพิ่มความมั่นใจต่อระบบงานให้มากยิ่งขึ้น

ทาง Microsoft ได้ปล่อย OpenJDK ที่ build ออกมาให้ลองใช้งานแบบฟรี
แถมมี Long term support ให้ด้วย
แต่ตอนนี้ยังไม่แนะนำให้ขึ้น production นะ
เป็นอีกหนึ่งทางเลือกของ OpenJDK

ซึ่งก่อนหน้านี้จะมีทางเลือกให้คือ

• OpenJDK
• Adoption JDK
• Corretto ของ Amazon

เท่าที่เข้าไปดูในส่วนของ Download
จะมีให้คือ OpenJDK 11 และ 16
รองรับทั้ง Linux, Mac และ Windows
แต่ Docker Image ยังไม่มีนะ ยังเป็น coming soon อยู่
ลองใช้งานกันดูครับ

จะเห็นได้ว่า Cloud Provider ก็ build OpenJDK ออกมาใช้ภายในเองเยอะ
เนื่องจากต้องทำการปรับบางอย่างให้ทำงานกับระบบของตนเองได้ดี
แต่ถ้าเราจะนำมาใช้งาน ก็ต้องควรทดสอบให้ดี
ทั้งเรื่องความสามารถต่าง ๆ และ performance

YAML เป็นอีกหนึ่งรูปแบบของข้อมูลที่ให้อ่านเข้าใจง่าย
ถูกใช้อย่างมากในโลกของ DevOps และ Container
ดังจะเห็นบ่อย ๆ ใน configuration ต่าง ๆ เช่น

• Docker compose
• Manifest file ของ Kubernetes
• Mock server

ดังนั้นมาทำความรู้จักและเข้าใจเกี่ยวกับ YAML กันหน่อย

YAML (YAML Ain't Markup Language) คืออะไร

โดยเริ่มต้นย่อมาจาก Yet Another Markup Language
แต่เปลี่ยนมาเป็น YAML Ain't Markup Language
เพื่อทำให้ชัดเจนว่าแตกต่างจาก Markup Language นะ
เพราะว่ามันคือ Data Serialization Language

จะมีรูปแบบคล้ายกับ XML และ JSON แต่ใช้ syntax ที่น้อยหรือง่ายกว่า
เพื่อให้ใช้งานและดูแลได้ง่าย
และบอกว่าถูกออกแบบมาให้คนอ่านง่ายขึ้น
จริงไหมนะ ?

ปล. แต่ถ้าไม่ได้ใช้ Text Editor หรือ IDE ที่สนับสนุน YAML แล้ว
อาจจะทำให้คุณมีปัญหาได้ยกตัวอย่าง
เช่น เพียงแค่ผิด 1 space bar อาจจะใช้เวลาหาข้อผิดพลาดมากก็ได้

ความสามารถของ YAML ที่แจ่ม ๆ คือ

• มี Build-in data type มาให้
• Multi-document support นั่นคือ สามารถรวมหลาย ๆ ไฟล์ อยู่ด้วยกัน โดยคั่นด้วย dash 3 ตัว (---) หรือ === ก็ได้
• Build-in comment ด้วย # ได้เลย
• มี Syntax ที่ผ่านเข้าใจง่าย โดยจะใช้ indentation เป็นหลัก เหมือนกับภาษา Python เลย โดยจะใช้ space แทน tab ไป เพื่อไม่ให้เกิดความสับสนต่อการใช้งาน
• Auto data type หรือเราจะกำหนดเองก็ได้ สำหรับชนิดของข้อมูล

ยกตัวอย่างเช่น

รูปแบบ หรือ symtax ของ YAML

• เป็นข้อมูล key-value ซึ่งคั่นด้วย :
• สำหรับ String data type ไม่ต้อง double quote
• รูปแบบข้อมูลของ value แบบ string มีหลายรูปแบบ ทั้ง
  • | สำหรับใส่บรรทัดใหม่ของแต่ละข้อมูล
  • > สำหรับการแสดงเป็น paragraph หรือต่อเนื่องกัน

ต่อมาเก็บข้อมูลในรูปแบบของ sequence

ซึ่งจะมีลักษณะคล้ายกับ array หรือ list
สำหรับเก็บหลาย ๆ ค่าใน key เดียว
ยกตัวอย่างเช่น

รูปแบบ dictionary ก็มี

แน่นอนว่ายังมีรูปแบบอื่น ๆ ให้ศึกษาและใช้งานอีก
แต่นี่คือความรู้เบื้องต้นที่ควรต้องรู้จักไว้บ้าง
ยกตัวอย่างที่อาจจะเจอคือ Manifest file ของ Kubernetes เป็นต้น

Keep learning ครับ

ความต้องการของการทำงานสำหรับ Load testing ของระบบงาน ด้วย Locust
ซึ่งอยู่บน Kubernetes cluster เป็นดังนี้
ทำการ setup Locust แบบ Master-slave หรือ Manager-worker
เพื่อช่วยสร้าง virtual user จำนวนมากตามที่ต้องการ
มีขั้นตอนการเตรียมดังนี้

สิ่งที่ต้องการคือ สร้าง Locust แบบ Master-slave

เพื่อช่วยสร้าง virtual user จำนวนมาก ๆ
จากนั้นส่งผลการทดสอบจาก target system
กลับมายัง master node เพื่อมาแสดงผลสวย ๆ ต่อไป
แสดงดังภาพ

ขั้นตอนที่ 1 ทำการสร้าง test case หรือ task สำหรับการทดสอบ

โดยเขียนด้วยภาษา Python
แสดงดังตัวอย่าง

คำอธิบาย
ทำการทดสอบ 2 endpoint คือ

• / สำหรับ index หรือ หน้าแรก
• /users สำหรับดึงข้อมูล user ทั้งหมด

ขั้นตอนที่ 2 สร้าง Dockerfile สำหรับสร้าง Image ของ Locust

ทำหน้าที่ run test case จากขั้นตอนที่ 1

โดยมีไฟล์ run.sh สำหรับกำหนด mode ของแต่ละ node
หรือในแต่ละ container ว่าทำงานแบบใด

• standalone
• master
• worker

ทำการสร้าง Docker image ให้เรียบร้อย
ซึ่งสามารถสร้างผ่าน Docker, Docker compose หรือ Swarm ได้เช่นเดียวกัน
แต่ในครั้งนี้จะทำการ deploy บน Kubernetes cluster

ขั้นตอนที่ 3 สร้าง Manefest file สำหรับการ deploy Locust บน Kubernetes

จะประกอบไปด้วยไฟล์ต่าง ๆ ดังนี้

• Deployment ของ master จำนวน 1 pod
• Deployment ของ worker จำนวน 6 pod
• Service สำหรับการ expose UI ของ Locust admin

Deployment ของ master จำนวน 1 pod

Deployment ของ worker จำนวน 6 pod

Service สำหรับการ expose UI ของ Locust admin

จากนั้นทำการ deploy บน cluster เป็นอันเรียบร้อย
เข้าใช้งาน Locust ผ่าน Web user interface ที่ deploy

ตัวอย่าง code เต็ม ๆ อยู่ที่ Github:Up1

Technical Debt หรือ หนี้เชิงเทคนิคนั้นมีที่มาหลายอย่างทั้ง

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

ส่งผลให้ยากต่อการดูแลรักษาต่อไป

จากบทความเรื่อง Technical Debt and Tradeoffs in Engineering

แบ่งชนิดของ Technical Debt ออกเป็นดังนี้

• Knowledge Debt
• Technology Debt
• Code Debt
• Architecture Debt
• Testing Debt

ได้อธิบายอย่างน่าสนใจว่า

Software development process นั้นเป็นกระบวนการที่ไม่มีที่สิ้นสุด
จะวนทำซ้ำไปเรื่อย ๆ
ดังนั้นเรื่องของการรับฟัง feedback ทั้งจากผู้ใช้งาน ทั้งจากคนสร้าง
เพื่อนำมาปรับปรุงจึงเป็นสิ่งที่สำคัญมาก ๆ

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

ดังนั้น เราต้องยอมรับก่อนว่า เรามีปัญหา
จากนั้นมาดูว่าปัญหาคืออะไร และ จะปรับแก้อย่างไร
ลงมือแก้ไข วัดผล และวนซ้ำไป

เป็นเรื่องปกติของการพัฒนา software ที่จะต้องมี technical debt

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

คำถามที่น่าสนใจ สำหรับคนที่อยากจะเป็น Java programmer/developer
ว่าจะต้องเรียนรู้ หรือมีความรู้และความสามารถอะไรบ้าง ?
เป็นคำถามที่ตอบยากมาก
เนื่องจากวิธีการมีเยอะมาก ๆ
ไม่ว่าจะเป็นการลงมือทำ การสอบถาม การเรียน
จากนั้นนำมาปรับปรุงอยู่อย่างสม่ำเสมอ

แต่เพื่อให้มีแนวทางที่เข้าใจง่ายหน่อย
จึงไปค้นหาว่ามีใครสรุปแนวทางไว้หรือไม่
ก็ไปเจอรูปสรุปเกี่ยวกับ Java programmer/developer roadmap 2021
จึงทำการสรุปไว้นิดหน่อย
น่าจะพอมีประโยชน์ต่อผู้เริ่มต้น

เรื่องที่ 1 ความรู้พื้นฐาน

• Version Control System คือ Git
• เกี่ยวกับการใช้งาน Linux ขั้นพื้นฐาน ทั้ง command line และ shell script
• เรื่องของ Data structure และ algorithm ที่เหมาะสม สำหรับการจัดการข้อมูลและประมวลผล

เรื่องที่ 2 Programming skills

• แนวคิดในการแก้ไขปัญหาต่าง ๆ
• เรื่องของ networking เช่น HTTP protocol เป็นต้น
• พื้นฐานของ Design pattern

เรื่องที่ 3 Java Programming

• ทำความเข้าใจเกี่ยวกับ JDK vs JRE vs JVM ซึ่งมีทั้ง vendor และ version ที่ต้องเลือกใช้งาน
• เกี่ยวกับ feature ที่สำคัญของ Java เช่น Collection framework ที่เตรียมเรื่องของ Data structure และ Algorithm ไว้ให้ใช้งาน
• เครื่องมือที่สำคัญคือ IDE สำหรับการเขียนและ run code รวมทั้ง build tool ต่าง ๆ ทั้ง Apache Maven และ Gradle
• Framework และ library ที่ได้รับความนิยมในการพัฒนาเช่น Spring framework และ Spring boot รวมถึง ORM เช่น Hibernate และ JPA
• การทดสอบแบบอัตโนมัติใน level ต่าง ๆ ด้วย JUnit 5 สำหรับ Unit testing เป็นต้น
• ความรู้เกี่ยวกับ Database ทั้ง RDBMS และ NoSQL

เมื่อเราเรียนรู้เรื่องพื้นฐานแล้ว จากนั้นก็ลงมือทำและเรียนรู้ต่อไปครับ
Keep learning ...

แสดงดังรูป

เช้านี้เจอการ์ตูนเกี่ยวกับ Code Review
เรื่อง The secret of a successful code review
มีความคิดเห็นอย่างไรกันบ้าง กับแนวคิดนี้ !!!

เห็นคำถามในกลุ่ม Spring Developer Thailand
เรื่องการจัดการ transaction ในการบันทึกข้อมูลลง database
ผ่าน repository layer ว่าทำอย่างไร ?
ก่อนที่จะรู้ว่าต้องทำอย่างไร
ควรต้องเข้าใจพฤติกรรมการทำงานพื้นฐานกันก่อน

เริ่มต้นผมลองสร้าง project ด้วย

• Spring Boot
• Spring Data JPA ใชสำหรับจัดการกับ database
• H2 คือ in-memory database

จากนั้นทำการสร้าง Repository 3 ตัวตามคำถามจาก link ในกลุ่ม
ในส่วนของการจัดการบันทึกข้อมูลทั้ง 3 repository
จะทำงานใน Service Layer แบบปกติ ดังนี้

จากนั้นทำการ config เรื่องการแสดง logging ของ Transaction และคำสั่ง SQL

เพื่อดูการทำงานของระบบ

จากนั้นลอง run และดูผล

จะเห็นได้ว่า จะทำการ commit ในแต่ละ repository
นั่นคือเกิด 3 transaction

แต่ถ้าเราต้องการให้ทั้ง 3 repositry ให้อยู่ใน Transaction เดียวกัน

ให้ทำการจัดการในส่วนของ Service Layer ด้วยการใส่ @Transactional ไปดังนี้

ผลการทำงานจาก log จะเป็นดังนี้
ซึ่งเป็นไปตามที่ต้องการคือ อยู่ใน transaction เดียวกัน
ดังนั้นถ้ามี repository ใด ที่ fail ขึ้นมา
จะทำการ rollback transaction ให้เอง

จะเห็นว่า เราสามารถจัดการ transaction พื้นฐานใน Service Layer ได้แล้ว
เพื่อให้ต่อยอดต่อไปได้

ใน Technology Radar Vol. 24 นั้นมีรายละเอียดที่น่าสนใจคือ
สิ่งที่ถูก Hold คือ proceed with caution
นั่นคือ ดำเนินการอย่างระมัดระวังเพราะว่า
อาจจะส่งผลแย่มากกว่าดี !!
มาดูกันว่ามีอะไรบ้าง ในแต่ละกลุ่ม

กลุ่มที่ 1 Techniques

เรื่องที่น่าสนใจ ประกอบไปด้วย

ตัวแรกคือ GitOps ซึ่งผลยังไม่เคยใช้งาน

แต่จากเอกสารบอกว่า
มันดีนะ
แต่เมื่อใช้งานแบบ branch per environment
จะก่อให้เกิดปัญหาในการ config ของแต่ละ environment ขึ้นมา
ซึ่งเป็นปัญหาเดียวกับ branch ที่มาอายุนาน ๆ ใน GitFlow นั่นเอง

ตัวที่สอง คือ Layered platform teams

เป็นการแบ่งทีมตาม layer หรือ technology
ทำให้เกิด component team เช่นเดิม
ยกตัวอย่างเช่น แยกเป็น frontend, backend และ database team
แน่นอนว่า ปัญหาเดิม ๆ ในการทำงานก็ตามมา

ตัวที่สาม คือ Separate code and pipeline ownership

จะเป็นปัญหาเดียวกันกับเรื่องก่อนหน้านี้
คือแยกทีมทำหรือรับผิดชอบระหว่าง code และ pipeline
ก่อให้เกิดการทำงานของใครของมัน
อาจจะต้องมีการสร้าง process การทำงาน
เช่นเปิด ticket/request การทำงานและเปลี่ยนแปลง
ผลคือ ช้าลงไปอีก

อีกทั้งยังมีเรื่องของ SAFe และการ peer review equals pull request อีกด้วย

กลุ่มที่ 2 Tools

มีตัวเดียวคือ AWS CodePipeline
ซึ่งผมก็ไม่เคยใช้งาน
แต่จากเอกสารบอกว่า
เพียงแค่จะทำ process ง่าย ๆ กลับต้องใช้เวลาและการ setup ยุ่งยาก และมากเกินไป
ดังนั้นน่าจะเป็นเรื่องแนวทางการใช้งานที่ไม่ค่อยยืดหยุ่นและสะดวก

กลุ่มที่ 3 Platforms

มี 2 เรื่องคือ

• Azure Machine Learning ที่ scale ได้ยาก และเอกสารที่ไม่ดีพอ
• Homemade infrastructure-as-code (IaC) products คือทำเองใช้เอง ปัญหาหลัก ๆ คือ product roadmap ที่จะไม่ชัดเจนมากกว่า

ก่อนหน้านี้ Deno นั้นจะสนับสนุนเพียง HTTP 1 เท่านั้น
ซึ่งพัฒนาอยู่ใน package std/http นั่นเอง
ใน Deno 1.9 นั้นทำการเพิ่ม HTTP 2 เข้ามา
แต่การไปแก้ไขหรือเพิ่มใน package std/http ไม่ใช่เรื่องง่ายเลย
จึงทำการพัฒนาใหม่เป็น native มาใน Deno เลย
โดยใช้งาน Hyper เป็น fast HTTP implementation พัฒนาด้วยภาษา Rust นั่นเอง
ผลที่ได้คือ ทำงานเร็วขึ้น 48%

ตัวอย่าง code

จากนั้นทำการ run และดูผล
ซึ่งยังต้องใส่ flag --unstable ด้วย ดังนี้

จาก blog ของ Deno ก็ได้วัด performance มาให้ดู

ลองทำการ Download มาใช้งานกันดูครับ

เนื่องจากมีโอกาสนำ Flutter 2.0 มาพัฒนาระบบ web application
ซึ่งก่อนหน้านี้ใช้พัฒนาแต่ Mobile app เท่านั้น
ใน Flutter 2.0 นั้นเพิ่ม web application เข้ามาด้วย
แต่เมื่อนำมาใช้พัฒนาระบบงานจริง ๆ
ก็เจอปัญหาหรือ issue ต่าง ๆ ขึ้นมา
จึงจดบันทึกไว้นิดหน่อย

เรื่องที่ 1 คือ CORS (Cross-Origin Resource Sharing)

จะไม่เจอใน Mobile app เลย
แต่เมื่อเป็น Web application จะเจอเรื่องนี้แน่นอน
มันคือ security ของ web browser นั่นเอง
ดังนั้นการจัดการเรื่องของ CORS และ Authentication เป็นสิ่งที่สำคัญ
แสดงการทำงานดังรูป

เรื่องที่ 2 โครงสร้างที่เหมาะสมกับระบบงาน

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

• Flat
• Layered
• Feature/domain/page
• Clean architecture

เรื่องที่ 3 การจัดเก็บข้อมูลในฝั่ง client

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

เรื่องที่ 4 การจัดการ Routing ของระบบงาน ซึ่งเป็น Client-side routing

เรื่องของ URL strategy ว่าจะจัดการและออกแบบอย่างไร ?
ต้องสามารถทำการ share หรือเข้าตรง ๆ ได้หรือไม่ ?
SEO ?

รวมไปถึงการจัดการกับ life cycle ของ Web application
ที่ทำงานบน web browser เช่นการกดปุ่ม refresh หรือ back เป็นต้น
จะต้องทำการจัดการอย่างไร
ซึ่งจะไม่เจอปัญหานี้บน Mobile app เลย

เรื่องที่ 5 การทดสอบระบบงาน

การทดสอบ Flutter application นั้น
มีทั้ง Unit, Widget, Integration, Mobile app เป็นต้น
ส่วน Web application ก็ใช้แนวทางเดียวกันอาจจะเพิ่มเข้ามาคือ พวก

• Cypress
• Selenium
• Playwright

เป็นสิ่งที่นักพัฒนามักไม่สนใจเรื่องนี้เท่าไรนัก
แต่เป็นสิ่งที่สำคัญมาก ๆ

ยังมีเรื่องอื่น ๆ อีก ยกตัวอย่างเช่น

• Responsive UI
• Security
• Performance
• SEO

วันนี้ใช้งาน docker-compose แล้วสะดุดตากับ message ว่า
Docker Compose is now in the Docker CLI, try docker compose up

ก็เลยงงว่า มันเปลี่ยนไปตอนไหนกัน ?
หรือว่าเราตกข่าวอะไรไปนะ ?
ลองไปดูในเอกสาร ก็ไม่เห็นว่า update นะ !!
แต่ไม่เป็นอะไร มาลแงใช้งานกันดู

โดย compose จะคล้าย ๆ กับ Management command หนึ่งของ docker นั่นเอง

แต่พอไปดูใน Management command ก็ไม่มีเหมือนกัน !!
การใช้งานก็ไม่ยาก โดยรวมแล้วเหมือนเดิม
เพียงเปลี่ยนจาก docker-compose มาเป็น docker compose เท่านั้น
การใช้งานเป็นดังนี้

ความเห็นส่วนตัวในการออกแบบ command line
ทำให้ผู้ใช้งานเข้าใจง่ายขึ้น
เหมือนกับการเพิ่ม Management command เข้ามานั่นเอง

วันนี้เพิ่งเห็นว่า NodeJS ได้ปล่อย version 16.0.0 ออกมา
พร้อมกับ npm 7.10.0 ด้วยเช่นกัน
หลัก ๆ คือ การ upgrade ไปใช้ V8 9.0
รวมทั้งสนับสนุน Apple Silicon แล้ว ซึ่งแยกตัวติดตั้งออกมาจากปกติ

ทำการ upgrade และลองใช้งานกันดูสำหรับ current version นี้

Reference :: Node 16

วันนี้ได้ลองใช้งาน Extension ใน VS Code ชื่อว่า Better Comments
ช่วยให้การเขียน comment ต่าง ๆ ดีขึ้น
ที่สำคัญเราสามารถจัดกลุ่มชนิดของ comment ได้ด้วย
ทั้ง TODO, Query, Alert และอื่น ๆ อีกเพียบ
แถมสนับสนุนหลายภาษาโปรแกรมอีกด้วย
มาลองใช้งานกันดูครับ
น่าจะเพิ่ม productivity ให้ดีขึ้น

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

เริ่มต้นจากคำถามที่ไม่ชัดเจน ไม่มีตัวอย่าง code ไม่มีอะไรเลย

คนตอบจินตนาการเอาเอง ว่าคนถามทำอะไร ติดปัญหาอะไร !!

ดังนั้นในการตั้งคำถามที่ดี ควรอธิบายให้ชัดเจน

ยกตัวอย่างเช่น

• OS ที่ใช้คืออะไร
• รายละเอียดของ Software ที่เกี่ยวข้อง
• รายละเอียดของ ภาษา Program ที่ใช้งาน
• ยกตัวอย่างของสิ่งที่กำลังทำหรือต้องการ เช่น มีตัวอย่าง input และ output ที่คาดหวังคืออะไร แนวคิดเป็นอย่างไร
• มีภาพหรือ code ประกอบในคำถาม

จากนั้นถ้าเป็นพวกการ configuration หรือ code ต่าง ๆ
ควรมีตัวอย่าง configuration หรือ code มาด้วย
จะให้ดีแนะนำให้ใส่ไว้ที่ Gist เลย
จะดีกว่าการ capture หน้าจอ หรือ copy code มา post

ถ้าเคยลองทำอะไรมาบ้าง ก็ควรอธิบายขั้นตอนให้ชัดเจนว่า

ทำขั้นตอนที่ 1, 2, 3, 4 มาใช้วิธีการนี้เพื่อแก้ไขปัญหาแล้ว
ซึ่งก่อให้เกิดปัญหา 4,5,6 ต่าง ๆ
ก็ควรอธิบายให้ชัดเจน
อธิบายให้เข้าใจง่าย ๆ คือ
คนอ่านหรือจะมาช่วยตอบจะได้ทำการ reproduce ปัญหานั้น ๆ ขึ้นมาได้ด้วย
เพื่อช่วยหาวิธีการแก้ไขได้รวดเร็วขึ้น

หลาย ๆ ครั้งจะพบว่า แค่บอกปัญหาที่เจอ

คำถามคือ ใครจะไปรู้ว่า
คุณกำลังทำอะไรเพราะว่าปัญหาหนึ่ง ๆ มันมาจากหลายสาเหตุได้เช่นกัน

และถ้าแก้ไขปัญหาได้แล้ว

ก็ควรกลับมา update ใน post ของคำถามด้วยว่าแก้ไขปัญหาอย่างไร
เพื่อให้ผู้อื่นตามมาอ่านหรือมีปัญหาเหมือนกัน ได้ลองนำไปใช้งานต่อไป (Give and Take)

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

หวังว่าจะมีประโยชน์นะครับ

จากคำถามในกลุ่ม Docker in Thai
เรื่องการ build Angular project ใน Docker
ว่าเกิด error ขึ้นมา คือ ไม่เจอคำสั่ง ng (Angular CLI)
ในการสร้าง Docker Image ด้วย Dockerfile
ดังนั้นจึงสรุปแนวทางการแก้ไขไว้นิดหน่อย

ในการใช้ Docker เพื่อ build Docker image

ควรรู้และเข้าใจก่อนว่า
เราต้องทำการติดตั้งอะไรบ้าง
เมื่อติดตั้งในแต่ละ OS แล้วจะเข้าใช้งานอย่างไร
จะทำให้การทำงานง่ายขึ้นและสามารถทำซ้ำได้
ทั้งในเครื่องเราและเครื่องอื่น ๆ (Repeatable)
ไม่ควรเกิดเหตุการณ์ที่ Work on my Machaine/Docker อีกแล้ว
นั่นหมายความว่า มีอะไรที่แตกต่างอย่างแน่นอน

สิ่งที่ควรระวังมีดังต่อไปนี้

• อย่า copy node_modules จากเครื่องเราไป ให้ทำการ build ในการสร้าง Image เท่านั้น
• เพื่อไม่ให้ลืมหรือพลาด ควรกำหนดพวก node_module ในไฟล์ .dockerignore ไปด้วยเสมอ
• ใช้คำสั่ง COPY . . เมื่อคุณเข้าใจและต้องการมันจริง ๆ อย่าใช้เพราะว่า เห็นตัวอย่างเขาก็ทำแบบนี้

มาดูตัวอย่าง Dockerfile ในการ build Angular app แบบง่าย ๆ

โดยสิ่งที่ทำเพิ่มเข้ามาคือ การ set PATH ไปยัง node_module ที่สร้างใน Image ด้วย

ลองใช้งานดูครับ

ปล. จะสังเกตได้ว่า ในการสร้าง Dockerfile นั้น
จำเป็นต้องใช้ skill ทั้ง developer และ operation ด้วย
ดังนั้นควรทำงานร่วมกันเพื่อสร้าง Dockerfile ขึ้นมา
ไม่ใช่กำหนดไปเลยว่าต้องหน้าที่ใคร
เพราะว่าต้องใช้งานจากทั้งคู่ครับ

เห็น extension ใน VS Code ที่น่าสนใจผ่านจาก feed ของ Facebook
นั่นคือ Thunder Client
ซึ่งอธิบายว่าเป็น Lightweight REST Client for Testing APIs
จะมีรูปแบบคล้ายกับ REST Client และ Postman เลย
จึงลองใช้งานดูหน่อย มาเริ่มกันเลย

การใช้งานคร่าว ๆ กัน

เริ่มด้วยความสามารถพื้นฐาน ประกอบไปด้วย

• สร้าง Request และ เพิ่มลงไปใน collection ได้ ซึ่งเหมือน Postman เลย
• สร้าง environment ต่าง ๆ ได้
• ในแต่ละ request สามารถเขียน Test ได้ เขียน code เองไม่ได้ เลือกตามที่มีให้เท่านั้น ไม่มี pre-request นะ
• ดูพวก history ต่าง ๆ ได้

เรื่องของ Authentication ในส่วนของ HTTP Request ก็มีให้ทั้ง

• Basic Authentication
• Bearer Token
• OAuth 2.0

โดยรวม เป็นอีกเครื่องมือช่วยทดสอบ API ครับ
เรียนรู้ไว้ไม่เสียหาย เผื่อมี use case ต้องใช้งาน

ปัญหาที่เจอ
ในระบบ Web หรือ API ที่พัฒนาด้วย .Net + C# นั้น
พบว่าเมื่อเราทำการ start server ขึ้นมาแล้ว
request แรกที่เข้ามาจะช้ามาก ๆ
เมื่อเทียบกับ request ต่อ ๆ มา
จะแก้ไขอย่างไรดี ?

ตัวอย่างของปัญหา ซึ่งความเร็วต่างกันมาก ๆ

เป็น code ที่ถูกสร้างมาจาก default project
เพื่อทำการ reproduce ปัญหา ดังนี้

วิธีการแก้ไขปัญหามีอะไรบ้าง ?

ลองคิดกันดูครับ ก่อนดูในบรรทัดต่อไป ...

จากที่คิดคือ ถ้าง่ายสุด ๆ ก็ทำการยิง request แรกก่อนเลย

ซึ่งเป็นการยิงจากระบบของเราเองในขั้นตอนสุดท้าย
หลังจากการ deployก่อนที่จะเปิดให้ใช้งาน
ผมคิดว่า น่าจะเป็น workaround มากกว่านะ
แต่ก็ง่ายที่สุดแล้ว !!

การทำก็ง่าย ๆ คือ สร้าง endpoint ขึ้นมา

เพื่อใช้สำหรับตรวจสอบความพร้อมของ Web หรือ API
หรือจะเรียกว่า Health Check แบบ readiness นั่นเอง
จากนั้นถ้าใช้พวก Docker หรือ Kubernetes ก็สามารถนำไปใส่ได้

• Docker ใช้  Health check
• Kubernetes ใช้งาน ReadinessProbe

แน่นอนว่า จะทำการส่ง request ไปยัง endpoint ก่อนเลย
เท่านี้ก็จบแล้ว

แต่ถ้าไม่ได้ใช้ Docker หรือ Kubernetes ละ ทำอย่างไร ?

ลองทำการ warmup หรือเรียก endpoint ที่กำหนดไว้เองเลย

โดยทำการสร้าง class ที่ implements IHostedService มา
จากนั้นทำการเรียก endpoint หลังจากที่ server ทำการ start เรียบร้อยแล้ว
ด้วยการใช้งาน HTTPClient นั่นเอง
ซึ่งวิธีการนี้ก็ง่ายดี
แต่ต้องเข้าในลำดับของการ start server นิดหน่อย

มาดู code ง่าย ๆ กัน
สร้าง Warmup service สำหรับส่ง request ไปยัง Endpoint URL ที่ต้องการ

ทำการ start service หลังจากที่ server start เสร็จแล้ว

ผลการทดสอบเป็นดังนี้

รวม ๆ แล้วคือการกระตุ้นการทำงานของ request แรกนั่นเอง

ก็น่าจะช่วยให้แก้ไขปัญหาที่พบเจอได้เช่นกัน
ตามจริงเราสามารถ initial service ต่าง ๆ
ทั้ง singleton และ non-singleton ได้อีกนะ
หรือถ้ายิง Endpoint ที่ต้องการหรือทั้งหมดก็ได้
แต่คิดว่า น่าจะซับซ้อนเกินไปหน่อย

อาจจะเขียน script สำหรับการ start service อีกก็ได้
ซึ่งทั้งหมดนี้ น่าจะเป็นเพียง workaround เท่านั้น