สิ่งที่น่าสนใจใน Spring Boot 2.4 จาก VDO เรื่อง What new in Spring Boot 2.4 ?
ทำการแนะนำ อธิบาย และตัวอย่างของความสามารถของ Spring Boot
มีหลายตัวที่น่าสนใจ ประกอบไปด้วย

JUnit 5’s Vintage Engine ถูกเอาออกไปจาก spring-boot-starter-test แล้ว

ทำให้ไม่สามารถใช้งาน JUnit 4 ใน JUnit 5 ได้แล้ว
นั่นหมายความว่าเป็นใช้ JUnit 5 ในการเขียน test
ดังนั้น code เดิมที่ใช้ JUnit 4 จะ compile ไม่ผ่าน
แต่ก็สามารถเพิ่มเข้ามาเองได้นะ

ทำการอ่านไฟล์พวก config ต่าง ๆ ผ่าน spring.config.location และ spring.config.import ได้เลย

ทำให้การอ่านค่าจากไฟล์เช่น property file ต่าง ๆ แบบง่าย ๆ ได้เลย

แบ่ง profile ในไฟล์ property/yml เดียวได้เลย ไม่ต้องแยกเป็นหลายไฟล์แล้ว

ปกติผมไม่ค่อยได้ใช้ profile เลย

เพิ่มเติม เพิ่งเห็นว่ามี Packaging OCI images ให้ด้วย [ก่อนหน้านี้แล้ว]

ซึ่งจะใช้งาน Image คือ paketobuildpacks/builder:base
ตัวอย่างการ config ใน Apache Maven

ที่สำคัญ สนับสนุน Layered Jar ให้เลยนะ

ลองดูเพิ่มเติมได้ครับ มีหลายสิ่งอย่าง
ทั้งเพิ่มแะเปลี่ยนแปลงเยอะใช้ได้เลย

Reference Websites

Blog :: Spring Boot 2.4
Release note

จากคำถามในกลุ่ม Docker Thailand
เรื่องของการใช้ Environment variable ใน Docker compose
ซึ่งที่เขียนมาใน post นั้น ทำการ hard code
พวก sensitive data ไว้ในไฟล์ docker-compose.yml เลย
ยกตัวอย่างเช่น hostname/ip, username และ password ของ database

ซึ่งไม่ควรทำอย่างยิ่ง ด้วยเรื่องของความปลอดภัยนั่นเอง
แต่ความง่ายมันไม่เข้าใครออกใคร จึงชอบทำกัน !!

จึงแนะนำไปว่าควรปรับเปลี่ยนให้ทำง่าย ๆ ดังนี้

เริ่มจากอ่านเอกสารจาก Docker เลย
เรื่องการใช้งาน Environment variables ใน Docker compose

โดยหลัก ๆ แนะนำให้แยกออกมาจากซะ

จากนั้นนำไปใส่ได้หลายที่ ประกอบไปด้วย

• กำหนดจาก OS
• ส่งผ่าน option -e env_name:value ของ docker-compose
• ถ้าใช้ไฟล์ .env ก็กำหนด env_file ในไฟล์ docker-compose.yml
• ใช้งาน Docker secret ได้

ปล. ถ้าใช้งานไฟล์ .env แล้วก็อย่า push ขึ้น repository ละ

ตัวอย่างง่าย ๆ

จากการนั่งดู​ Live การ refactor code
จาก JavaScript Cafe // มา Refactor Code Vue 370 บรรทัดกัน
เห็นเทคนิดที่น่าสนใจ สำหรับการจัดการ code ในไฟล์ที่มีจำนวนบรรทัดยาว ๆ
นั่นคือ การใช้ Folding ด้วย #region

ตัวอย่างการใช้งานก็ง่ายมาก

ลองดูเอกสารเพิ่มเติมได้ VS Code :: Folding with region

เนื่องจากมีงานเล็ก ๆ ที่พัฒนาด้วยภาษา Python ต้องทำส่งนิดหน่อย
โดยปกติจะใช้ Flask ในการพัฒนาเป็นหลัก
แต่เห็นว่ามี library อีกตัวที่น่าสนใจคือ FastAPI
ลองทำการศึกษา ลองใช้งาน แล้วก็ดันทำส่งลูกค้าไป
มาดูกันหน่อยว่า FastAPI มีอะไรที่น่าสนใจบ้าง ?

เป้าหมายของ FastAPI นั้นมี 3 เรื่องหลัก ๆ คือ

• Speed คือความเร็วของการทำงาน
• Developer experience
• Open standard

ในเรื่องของความเร็วนั้น

ถ้าใช้ค่า default หรือจากตัวอย่างเลย
พบว่าไม่ได้เร็วอย่างที่บอกแต่สามารถ config เพิ่มเติมได้
ยกตัวอย่างเช่น

• การปิด log ออก console
• การเพิ่ม worker เข้าไป

โดยการทำงานด้านหลังมันคือ Starlette และ Pydantic
ที่สำคัญเมื่อ Starlette + Uvicorn ก็จะสนับสนุน Asynchronous ให้อีกด้วย
สามารถใช้ syntax async และ await ได้เลย

ถ้ามองในแง่การความเร็วในการพัฒนาแล้ว

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

สิ่งที่สำคัญมาก ๆ คือ Live reload ก็มีมาให้พร้อม
ไม่ต้องไปหา program เพิ่มเติมอีก

แต่สิ่งที่แจ่มมาก ๆ คือ สนับสนุน Open API หรือชื่อเก่าคือ Swagger เลย

ดังนั้นเราจะได้ API Documentation ให้แบบอัตโนมัติ
รวมทั้งสนับสนุน JSON Schema สำหรับการ validate JSON อีกด้วย
โดยจะมีทั้ง Swagger UI และ Redoc ให้เลย

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

• Data validation
• Dependency Injection
• Serialize และ Deserialize
• Middleware
• Modular
• Security
• Testing
• Deployment

คิดว่าเอามาแทนที่ Flask ได้เลย

ไปอ่าน code ของ project ที่พัฒนาด้วยภาษา JavaScript
ก็เลยเจอ code แปลก ๆ คือ การใช้ Numeric Separator
ทำให้สามารถใช้สัญลักษณ์ underscore ( _ )
เพื่อแยกตำแหน่งของตัวเลข ช่วยให้อ่านง่ายมากยิ่งขึ้น
ดังนี้

จากบทความเรื่อง From 15,000 database connections to under 100: DigitalOcean's tale of tech debt
ทำการอธิบายถึง Technical Debt หรือหนี้ทางเทคนิค
ที่ทาง DigitalOcean ได้สร้างมันขึ้นมา

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

เริ่มต้นด้วยระบบงานจะมีโครงสร้างดังรูป

เป็นโครงสร้างที่เรียบง่ายไม่ซับซ้อน
พัฒนาในส่วนของ UI และ API ด้วย Rails
ส่วนของ backend ที่ใช้จัดการระบบ cloud พัฒนาด้วยภาษา Perl คือส่วนของ Scheduler และ DOBE
การติดต่อระหว่าง UI และ Backend จะผ่าน Message Queue
ซึ่งใช้งานบน MySQL database

MySQL database ทำ 2 หน้าที่คือ เก็บข้อมูล และ เป็น message broker

ขั้นตอนการทำงานเป็นดังนี้

• เมื่อผู้ใช้งานทำการสร้าง droplet ผ่าน UI
• UI จะส่งข้อมูลการสร้างไปยัง MySQL เพื่อ insert ข้อมูล
• ในฝั่ง scheduler ที่อยู่ backend จะทำการดึงข้อมูลจาก MySQL ทุก ๆ วินาที เพื่อดูว่ามีคำสั่งมาหรือไม่
• ถ้าเจอก็ข้อมูลใหม่ ก็จะทำการสร้าง droplet ตามการร้องขอนั้น ๆ

แสดงการทำงานดังรูป

ต่อมาในฝั่ง backend ก็เริ่มนำแนวคิด Microservices มาใช้งาน

เปลี่ยนจาก Perl มาเป็น Go
ติดต่อสื่อสารภายในกันผ่าน gRPC แทนที่ HTTPS
ส่วนตรงกลางยังเป็น MySQL เช่นเดิม

เมื่อเวลาผ่านไปตั้งแต่ปี 2012-2016 นั้น

เพิ่ม feature ต่าง ๆ เข้ามามากมาย
ส่งผลให้มีจำนวนผู้ใช้งานเพิ่มมากขึ้นถึง 10,000 %
ผลที่ตามมาคือ จำนวน connection ไปยัง MySQL database
จะเท่ากับจำนวนการสร้าง droplet เลย !!

ยังไม่พอยังมีชุดคำสั่ง SQL ที่เรียกว่า ลูกอีช่าง JOIN ถึง 18 table !!
ยิ่งก่อให้เกิดความซับซ้อน และ load database อย่างมาก
ซึ่งยากต่อการ scale และ ดูแลรักษา
ส่งผลให้ performance ของระบบแย่ลง

เมื่อมองกลับไปที่โครงสร้างที่ได้ทำกันมาแล้ว

พบว่าแต่ละส่วนงานผูกมัดกันมาก (Tight coupling)
มัน work ในช่วงเวลาหนึ่ง แต่เมื่อถึงอีกจุดหนึ่งมันไม่ work เสียแล้ว
แต่ละส่วนงานเกิดเป็นปัญหาคอขวดขึ้นมา
ดังนั้นจึงได้เวลา refactor ระบบแล้ว
มีเป้าหมายของการ refactor ดังนี้

• ลดจำนวนของ database connection ลง
• ปรับปรุงการทำงานของระบบ scheduler ให้มีความเสถียร
• แก้ไขปัญหาเรื่องของ messaging ซึ่งดันไปใช้ MySQL database

การแก้ไขปัญหาในส่วนของ Backend เพื่อลดจำนวน connection มายัง database

ด้วยการเพิ่มส่วนของ Proxy เรียกว่า Event router มาคั่นกลาง
แสดงดังรูป

ในส่วนของ Message Queue ก็เช่นกัน นำ RabbitMQ มาใช้แทน MySQL

โดยใช้ MySQL เก็บข้อมูลต่าง ๆ
ส่วน event จากฝั่ง UI ก็ใช้ RabitMQ ซะ เพราะว่ามันเก่งเรื่องนี้กว่ามาก
โดยมี API layer หรือ Microservices มาจัดการ droplet service ไปเลย

ส่งผลให้แต่ละส่วนงานทำงานแยกกันอย่างเป็นอิสระ

มีหน้าที่รับผิดชอบอย่างชัดเจน
เลือกใช้เครื่องมือให้เมาะกับงานนั้น ๆ และทำงานเดียวให้ดีไปเลย
ส่วนตรงไหนที่ก่อให้เกิดปัญหาคอขวดก็ทำการแก้ไข
ผลที่ตามมาคือ ระบบเอื้อต่อการ scale ของทั้ง busienss และ technical ด้วย

เราได้เรียนรู้อะไรจากบทความนี้บ้าง ?

จากที่ไปสอนและแบ่งปันความรู็พื้นฐานของภาษา Go
นึกขึ้นมาได้ว่า ลืมอธิบายเรื่อง internal package
ซึ่งเป็น package พิเศษของ Go
ที่เพิ่มมาตั้งแต่ Go version 1.4 เป็นต้นมา
ทำให้สามารถกำหนดขอบเขตการทำงานได้ดีขึ้น

เนื่องจากปกตินั้นจะมีรูปแบบการเข้าถึงทั้ง functions/variables/types 2 รูปแบบคือ

1. Local หรือ unexported เทียบได้กับ private นั่นคือ ขึ้นต้นด้วยตัวอักษรพิมพ์เล็ก
2. Global หรือ exported เทียบได้กับ public นั่นคือ ขึ้นต้นด้วยตัวอักษรพิมพ์ใหญ่

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

แต่มีในบางกรณีที่เราไม่ต้องการ

ให้ exported function/struct/interface ใช้งานจากภายนอก package ละ
จะทำอย่างไร ?
นั่นคือการ encapsulation การทำงานภายใน component/package ของระบบงานไว้
คำตอบคือ การใช้ internal package มาใช้งานนั่นเอง

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

สร้าง package ดังนี้ขึ้นมา demo/component/internal

จากนั้นลองทำการเรียกใช้งาน function GlobalFunction() จาก main package
จะเจอ error ดังนี้

โดย function GlobalFunction()
จะสามารถเรียกได้จาก package demo/component เท่านั้น

น่าจะพอทำให้เข้าใจ
เกี่ยวกับการจัดการการ access หรือ visibility ของ Go กันเพิ่มบ้างแล้วนะครับ

Deno 1.7 เพิ่งปล่อยออกมา
ส่วนใหญ่เป็นการปรับปรุงการทำงานให้ดีขึ้น
ความสามารถที่ผมสนใจมาก ๆ คือ
การปรับปรุงของ การ compile นั่นเอง
ทำการปรับปรุงดังนี้

ขนาดของไฟล์ binary ที่สร้างออกมา จะมีขนาดลดลง

ด้วยการใส่ flag เพื่อชื่อว่า --lite เข้าไปในการ compile
ซึ่งพบว่าขนาดของไฟล์ binary ลดลงจาก Deno 1.6 ลงมาเยอะมาก ๆ
แต่ถ้าไม่ใส่ flag แล้ว ขนาดก็ใหญ่ขึ้นกว่าเดิม
เพราะว่า Deno มันใหญ่ขึ้นนั่นเอง

ตัวอย่างที่ใช้งานคือ

ขนาดของไฟล์ welcome จะลดลงจาก 40 MB เหลือ 30 MB ถ้าใส่ flag --lite
แต่ถ้าไม่ใส่ขนาดไปถึง 50 MB กันเลย

อีกเรื่องคือ ในการ compile สามารถระบุ target ของ OS ได้ เลย

ไม่ต้องไป compile บน OS นั้น ๆ อีกต่อไป

แต่สำหรับ Windows OS นั้นยังมีปัญหา
ตาม error นี้

ซึ่งทำการ Merge การแก้ไขไปแล้วที่ PR 9203

วันนี้เพิ่งทำการ upgrade Postman มาใช้ version 8
ซึ่งทำการปรับเปลี่ยน User Interface ใหม่เลย
หลัก ๆ คือ การเพิ่มพวก workspace, search, API network เข้ามา
เพื่อปรับปรุงการใช้งานให้ดีขึ้น
รวมทั้งทำให้ Postman ทั้งบน desktop และ web เทียบเท่ากัน

แต่ความรู้สึกแรกที่เห็นคือ มันเยอะไปไหน !!

ยกตัวอย่างในหน้า Home ของ Postman

ส่วนต่อมาคือ Workspace จะเป็นที่จัดเก็บ Collection และ Request ต่าง ๆ ของเรานั่นเอง

ในส่วนนี้ดูง่ายขึ้น เรื่องจากแยกเป็นสัดส่วน
แถมมี context menu ให้ตามแต่ละ section ที่ใช้งาน เช่น

• Collections
• APIs
• Environments
• Mock Servers
• Monitors
• History

ภายในแต่ละ Request พบว่า User Interface ใหม่ มีครบเลย

แต่ดูไปดูมาจะเยอะไปไหน ต้องไปใช้บนจอใหญ่ ๆ ถึงจะดี
ส่วนถ้าจอเล็ก ๆ มีปวดหัวแน่นอน

ส่วนที่มีประโยชน์มาก ๆ คือ Explore เพื่อค้นหาสิ่งต่าง ๆ ที่สนใจ

ลอง Download และใช้งานกันดูครับ
อาจจะงง ๆ นิดหน่อย

Reference Websites

https://blog.postman.com/introducing-postman-desktop-app

ใน GitHub นั้น สามารถเข้าไปแก้ไขชื่อ branch ผ่าน web ได้แล้ว
เป็นผลมาจากการเปลี่ยน branch master มาเป็น main นั่นเอง
โดยการแก้ไขชื่อ branch นั้น จะส่งผลดังนี้

• ชื่อ branch เปลี่ยน มันก็ใช่นะสิ
• ทำการแก้ไข target ต่าง ๆ ของ PR, Release ต่าง ๆ ที่อ้างถึง branch
• ใน local repository ที่เชื่อมโยงกับ remote repository ใน GitHub จะทำการแจ้งเตือนว่ามีการแก้ไข branch แล้ว
• ถ้ามีการอ้างถึง branch เดิม ก็จะ reditect ไปยัง branch ใหม่ให้อัตโนมัติ
• ส่วน API ที่อ้างถึง branch เดิม จะทำการส่งกลับไปเป็น Redirect Permanent เพื่อแจ้งว่าเปลี่ยนชื่อแล้วนะ ไปใช้ branch ใหม่เลย

เห็นว่า Go เพิ่มปล่อย version 1.16 RC 1 มาให้ลองใช้งานกัน
ก็เลยลองเล่นกันหน่อยว่า มีอะไรที่เปลี่ยนแปลงไปบ้าง
ในการใช้งานทั่วไป มาดูกัน

โดยก่อนหน้าที่อธิบายเรื่อง Embed package ไปแล้ว

ในการทดสอบ ถ้าเจอ code ใช้ในงาน os.Exit(int) แล้ว การทดสอบนั้นจะ fail ทันที

ซึ่งแตกต่างจากเดิมคือ ไม่สนใจ
ทำให้การทดสอบนั้น ๆ ผ่าน

รวมทั้งการ run test ได้ต้อง runใน project ที่เป็น go module เท่านั้น

เพิ่ม env ตัวใหม่ชื่อว่า GOVCS เข้ามา

สำหรับกำหนดว่า จะทำการ download source code ของ library ต่าง ๆ มาจากไหน
โดยค่า default คือ git และ hg

เพิ่ม Package ใหม่ชื่อว่า io/fs เข้ามา สำหรับการอ่านไฟล์และ directory เท่านั้น

โดยการใช้งานผ่าน interface ชื่อว่า fs.FS ดังนี้

[gist id="f9f4bca9a3bad0909b8a3e7587a62b1f" file="fs.go"]

ยังไม่พอนะ ได้เตรียม package testing/fstest ใช้สำหรับการทดสอบให้อีกด้วย
ซึ่งจะทำการจำลองในหน่วยความจำให้แทน
ทำให้การทดสอบง่ายขึ้นไปอีก

ส่วน package io/ioutil นั้นถูก deprecated แล้ว
ใครใช้งานอยู่หรือคิดจะใช้งาน ก็เปลี่ยนได้แล้ว

จากที่ทดสอบการ build พบว่า ขนาดของไฟล์ binary ที่ได้เล็กลงอีกแล้ว !!

อ่านการเปลี่ยนแปลงเพิ่มได้ที่ Go 1.16 Release Notes

ในการทดสอบระดับ integration กับ Database ต่าง ๆ นั้น
บ่อยครั้งการจะทำการจำลองหรือ mock database
ทั้งผ่าน interface หรืออาจจะใช้งาน SQLMock ก็ได้
หรือบางคนใช้งาน Docker อยู่แล้ว
ก็เขียน script หรือ Make file มาใช้งาน
แต่เจอว่า มี package ชื่อว่า Dockertest
มาช่วยให้การทดสอบกับ database ผ่าน Docker container ได้สะดวกขึ้น
มาลองทำความรู้จักกันหน่อย

Dockertest เป็น package เล็ก ๆ

ที่ช่วยให้เราสามารถสร้างและลบ Docker container ด้วย code ได้เลย
เช่นการสร้าง Database container ต่าง ๆ ขึ้นมา
ก่อนที่จะทำการทดสอบตาม test case และ test scenario ที่ต้องการ

การใช้งานก็ไม่ยาก เขียนใน test ได้เลย

โดยแยกส่วนการทำงานนิดหน่อย

• ทำการ initial database ผ่าน TestMain สำหรับการ setup และ teardown ของแต่ละ test case
• เขียน test case เพื่อใช้งาน

ขั้นตอนที่ 1 ทำการ initial container ก่อน

ขั้นตอนที่ 2 ทำการทดสอบกับ container

เพียงเท่านี้ก็สามารถทดสอบระบบงานบน Docker container แบบง่าย ๆ ได้แล้ว
ใช้ resource เยอะตาม Docker นั่นเอง
เป็นอีกทางเลือกที่น่าสนใจ

มีแนวคิดคล้าย ๆ กันที่เคยแนะนำไปแล้วคือ Testing with testcontainer

ทาง Docker ได้ปล่อย Docker Hub CLI Tool version 0.3.0 ออกมา
เป็น experiment tool นะ ก่อนที่จะเพิ่มเข้าไปใน Docker
สำหรับการใช้งาน Docker Hub ผ่าน command line นั่นเอง
น่าจะช่วยให้การใช้งานสะดวกขึ้นมาอีก

ลองทำการ download มาใช้งานกันเลย

ตัวอย่างการใช้งานง่าย ๆ ก็เช่น
login และ ดู account ของเราเองว่า มี quota อย่างไร

ตอนนี้ IntelliJ IDEA 2021.1 EAP 1 (Early Access Program) ถูกปล่อยออกมาแล้ว
มีความสามารถที่น่าสนใจดังนี้

• สนับสนุน Java 16 แล้ว เช่น Record, Pattern, Local Enum และ interface
• สนับสนุน WSL 2 ซึ่งจะ detect JDK ที่ติดตั้งใน WSL ได้เลย ต่อไปจะสนับสนุน Maven และ Gradle ด้วย
• สามารถเรื่อง Run target เพิ่มได้ทั้ง Docker, SSH และ WSL

ลองไป Download มาลองใช้งานกันได้

วันนี้อ่านบทความ Cypress vs Selenium vs Playwright vs Puppeteer speed comparison
ทำการเปรียบเทียบความเร็วของการทดสอบของเครื่องมือแต่ละตัว
ประกอบไปด้วย

• Cypress
• Selenium
• Playwright
• Puppeteer

เป็นเครื่องมือสำหรับการทดสอบแบบ End-to-End ผ่าน web browser

การทดสอบจะมีทั้ง scenario แบบสั้นและยาว

ได้ผลการทดสอบดังรูป

จากผลการทดสอบจะเห็นได้ว่า

• Puppeteer และ Playwright นั้นมีความเร็วในการทดสอบสูงมาก ๆ ยิ่ง scenario สั้น ๆ ยิ่งเร็วมาก ๆ
• สำหรับการทดสอบแบบ scenario ยาว ๆ นั้น จะเห็นว่าความเร็วไม่ต่างกันมาก แถมความเร็วจะมาเทียบเท่าตัวที่ช้า ๆ อีกด้วย
• ตัวที่ช้ามาก ๆ คือ cypress นั่นก็เพราะว่า startup time นั่นเอง เนื่องจาก cypress มีมากกว่า end-to-end testing แต่ยังมีความสามารถอื่น ๆ ให้ใช้งาน ทำให้การ start ช้า แต่เมื่อทดสอบแบบยาว ๆ ก็จะไม่ช้ามาก
• ส่วน Selenium ก็อยู่กลาง ๆ ไม่ช้าเกินไป ไม่เร็วมากนัก ตาม style ของมัน

ไปดู Code ของการทดสอบครั้งนี้ได้ที่ GitHub

ไม่ว่าเครื่องมือจะเป็นอย่างไร

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

Choose right tool for the right job
แต่ถ้าคุณมีความรู้เพียงตัวเดียวละ คุณจะมีทางเลือกได้หรือ ?

เพิ่งเห็น Library ชื่อว่า Donkey
เป็น library สำหรับพัฒนา HTTP server และ client ในภาษา Clojure
โดยอ้างว่าสร้างมาเพื่อช่วยให้การพัฒนาง่ายขึ้น
รวมทั้ง performance ดีมากอีกด้วย
เป็น library ถูกสร้างจากทีมของ AppsFlyer
มีเป้าหมายเพื่อ

• รองรับการ scale ที่สูงขึ้นอย่างรวดเร็ว
• ประหยัดค่าใช้จ่ายของการประมวลผล

สิ่งที่น่าสนใจของ Donkey

• สร้างอยู่บน Vert.x สำหรับการพัฒนา reactive application บน JVM (Non-blocking IO by default)
• มี API ง่าย ๆ ให้ใช้งาน
• Open-source

ดังนั้นมาลองใช้งานกันหน่อย

ผลที่ได้ออกมานั้น สูงใช้ได้เลยนะ
รวมทั้งการใช้งานก็ไม่ยาก
น่าสนใจมาก ๆ

Reference Websites

• https://www.infoq.com/articles/clojure-donkey-http-stack/

มาดูผลที่น่าสนใจจากการสำรวจ  The state of Go 2020 จาก JetBrains
ประกอบไปด้วย

จีน ญี่ปุ่น รัสเซีย ยูเครน และ UK

คือประเทศที่ใช้ภาษา Go ในการพัฒนาระบบงานมากที่สุดตามลำดับ

ระบบที่พัฒนาด้วยภาษา Go มีดังนี้

• Web services
• Utility คือ ระบบงานเล็ก ๆ ที่ใช้แก้ไขงานเล็ก ๆ น้อย ๆ
• IT Infrastructure
• Library/Framework
• System software

ส่วนงานที่นำ Go ไปใช้เยอะ มีดังนี้

• IT services
• Finance และ FinTech
• Cloud computing/platform
• Big Data/ Data Analysis
• Mobile development น่าจะใช้ในฝั่ง backend สำหรับ Mobile app มากกว่า

Package Manager สำหรับภาษา Go คือ Go Module

ส่วนที่รอง ๆ ลงมาคือ dep, godep และ govendor

Router สำหรับ Web

นั้นก็ใช้ Gorilla/Mux และ Standard library จาก package net/http นั่นเอง
ส่วนที่ใช้รองลงมาคือ chi และ httproute

Web framework ส่วนมากจะใช้งาน Gin

รองลงมาคือ Echo และ BeeGo

ในการทดสอบก็ยังใช้งาน build-in testing package นั่นเอง

รองลงมาก็คือ testify, gomock และ ginkgo

การถามตอบเกี่ยวกับภาษา Go ใน StackOverflow

จะมีหัวข้อเด่น ๆ ดังนี้

• การจัดการกับ JSON
• การใช้งาน MongoDB, PostgreSQL และ MySQL
• ตัวภาษาก็มีเรื่อง string, array, pointer, regular expression, struct, interface และ concurrency  เป็นสิ่งที่ใช้งานบ่อย ๆ
• เรื่องของ testing และ unit testing

แสดงดังรูป

พอดีได้คุยเรื่องของ code ที่พัฒนาด้วย NodeJS + Express เล็กน้อย
ซึ่งมี code บางตัวที่น่าสนใจ
เนื่องจากเป็น code ที่ทำให้การทำงานมันเป็น Blocking IO ซะงั้น
เลยสรุปตัวอย่างไว้นิดหน่อย
เพื่อทำให้เห็นว่ NodeJS มันทำงานอย่างไร
เมื่อมีจำนวน concurrent ของผู้ใช้งานเยอะ ๆ

ตัวอย่าง code ง่าย ๆ

แยกเป็น

• / คือ router หลัก
• /block คือ code ที่ทำงานแบบ blocking ซึ่งจะรอไปจบกว่าเวลาจะเกิน 1 วินาที
• /non-block คือ code ที่ทำงานแบบ non-blocking แน่นอนว่าจะรอ 1 วินาทีเช่นเดียวกัน

คำอธิบาย

ระหว่าง /block และ /non-block จะได้ผลการทำงานที่แตกต่างกัน
เนื่องจาก NodeJS นั้นทำงานแบบ Single thread นั่นเอง
ถ้าเจอ code แบบ blocking เข้าไปแล้ว
request อื่น ๆ ก็ต้องรอเข้าคิวนั่นเอง
ทำให้การทำงานช้ามาก ๆ

ผลการทดสอบแบบง่าย ๆ

เขียน code เพื่อดูผล จะทำให้เข้าใจมากขึ้นเยอะเลย
ดังนั้นรูปแบบการเขียน code จึงสำคัญมากเช่นกัน

จากบทความเรื่อง
รวม Tips & Tricksในการสร้าง Swagger UI ให้กับ Gin REST API ด้วย Swaggo
อธิบายถึงการสร้าง API Documentation
โดยทำการสร้างมาจาก Code Annotation ในส่วนของ comment
ด้วย command swag
ซึ่งเป็นแนวทางหนึ่งในการสร้างเอกสารขึ้นมา

แต่ก็ยังไม่แนวทางอื่น ๆ ใช้งานเช่นกัน

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

การเขียน API Specification ในรูปแบบของ
Swagger 3 หรือ Open API specification ก่อน
ทั้งในรูปแบบ XML, JSON และ YAML เป็นต้น
จากนั้นทำการ generate source code ของ REST API หรือ Web Services ขึ้นมา
ให้แบบอัตโนมัติผ่านเครื่องมือที่สนับสนุน Swagger
แต่ต้องดูด้วยว่าสนับสนุน Swagger version ไหนบ้างด้วย (2 หรือ 3)

ตัวอย่างของเครื่องมือ เช่น

• Swagger codegen สำหรับการ generate code ในภาษาหลัก ๆ ทั้ง C#, Java, Go, JavaScript และ Python เป็นต้น
• Go swagger สำหรับการ generate code ในภาษา Go
• OpenAPI Codegen สำหรับ Swagger version 3 ขึ้นไป และได้ภาษา Go ออกมา (เลือกได้ด้วยทั้ง HTTP/Echo และ Gin)
• Swag สำหรับ Swagger version 2 ได้ออกมาเป็นภาษา Go
• สาย GRPC ก็มีเช่น GRPC Gateway

ในรูปแบบนี้ควรจะทำการออกแบบ API อยู่ในรูปแบบ Swagger ไปเลย

ไม่ต้องไปออกแบบใน Spreadsheet
มิเช่นนั้นมันจะเกิดความซ้ำซ้อนขึ้นมาโดยใช่เหตุ
แต่ code ที่ได้มานั้น หลาย ๆ คนอาจจะไม่ชอบ
เลยทำให้ไปเลือกใช้วิธีแรกคือ เขียน code
เพื่อสร้าง API Specification/documentation ออกมา

แสดงแนวทางทั้งสองดังรูป

ลองเลือกดูว่าแบบไหนที่เหมาะสมกับการทำงานของเรา

หลังจากที่เราได้ API Specification ออกมาแล้ว

มันสามารถนำไปใช้งานหรือประโยชน์ได้อีกเพียบ
แสดงดังรูป

สุดท้ายแล้ว เรานำเครื่องมือเหล่านี้มาเพื่อให้เกิดประโยชน์หรือไม่

หรือมันมาทำให้เราช้าลงหรือเป็นภาระมากยิ่งขึ้น
ดังนั้นต้องมาวางแผนและตกลงการใช้งานร่วมกันด้วยเสมอนะครับ

ในวันหนึ่ง ๆ นักพัฒนาบางคน
อาจจะอยู่ใน environment ของการพัฒนาที่แย่ ๆ
จึงทำการสรุปสิ่งที่คิดว่า
ไม่น่าจะดีต่อทีมพัฒนาไว้นิดหน่อย
ซึ่งอาจจะมีประโยชน์ต่อการปรับปรุงต่อไป
มาเริ่มกันเลย

ในแต่ละวันก็จะมี alert/notification บน production environment จำนวนมากมาย

ทั้ง ๆ ที่เรามี environment ต่าง ๆ มากมาย ทั้ง Dev, Test, PreProd, Production
เพื่อทำการทดสอบหรือตรวจสอบการทำงาน
เป็นเรื่องที่น่าแปลกดีว่า
เรามีมันไปทำไมกันนะทั้ง ๆ ที่ไม่ค่อยมีประโยชน์อะไรมากนัก

เมื่อได้รับปัญหาเข้ามาแล้ว

ต้องไปดูข้อมูลเพิ่มเติมจากระบบ monitoring ต่าง ๆ มากมาย
เรามีระบบ monitoring นะ แต่มันเยอะ
แถมแยกเป็นอิสระแก่กันอีก
ต้องรวมข้อมูลจากหลาย ๆ ที่ แล้วเอาไปคิด วิเคราะห์เอาเองนะ
มีเหมือนไม่มีจริง ๆ เสียเวลามาก ๆ

ยังไม่พอ เมื่อต้องการดู logging ของการทำงาน

เพื่อหา root cause ของปัญหา
พบว่าต้องไปดู log file จากระบบต่าง ๆ มากมาย
ที่แยกกันอีกแล้ว แถมไม่มี correlation id อีก
การหาปัญหาจึงเป็นเรื่องที่ใช้เวลานานมาก ๆ

ในการส่งมอบ software จะมีกลิ่นแปลก ๆ

ยกตัวอย่างเช่น
เมื่อพัฒนา feature ต่าง ๆ เรียบร้อยแล้ว
ต้องรอคนมาทดสอบ เพื่อบอกว่า ok ผ่านได้
ต้องรอคนมา review system/architecture เพื่อบอกว่า ok ผ่านได้
ต้องรอคนมาทำ performance testing เพื่อบอกว่า ok ผ่านได้
ต้องรอคนมา review เรื่อง security เพื่อบอกว่า ok ผ่านได้

รอกันต่อไป จากนั้นก็แก้ไขวนไป
แต่เวลา release ขอเวลาเดิมนะ !!
สู้ ๆ
แต่เรามีระบบ CI/CD นะ ดูมันย้อนแย้งแบบงง ๆ

หลาย ๆ คนในทีมต้องเข้าประชุมต่าง ๆ เกือบทั้งวัน

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

เมื่อทำงานร่วมกับทีมอื่น ๆ หรือส่วนงานอื่น ๆ

บ่อยครั้งเอกสารสำหรับการเชื่อมต่อมักจะไม่ใช่ version ล่าสุด
หนักกว่านั้น ทำแบบคร่าว ๆ หรือ draft มาให้ก่อน
แต่เมื่อลงมือทำกลับเปลี่ยนแปลงไปแบบหน้ามือเป็นหลังตีน
แถมแก้ไขโดยไม่บอกอะไรอีกด้วย
โยนปัญหากันไปมา
สรุปแล้วเสียเวลาไปกับเรื่องไร้สาระเยอะมาก ๆ
แต่ก็ทน ๆ กันไป
ปรับปรุงกันไป !!

สุดท้ายแล้ว เราต้องช่วย ๆ กันนะ

Deadline รอเราอยู่ สู้ ๆ
อยากกินอะไรบอกได้นะ
คืนนี้ยาวไป !!

เรื่องเล่าขำ ๆ ที่ไม่น่าเป็นจริง !!