หลังจากอ่านบทความเรื่อง Guide: How To Detect and Mitigate the Log4Shell Vulnerability (CVE-2021-44228)
เกี่ยวกับแนวทางการแก้ไขปัญหาของ Log4j version 2 แล้ว
มีสิ่งที่น่าสนใจคือ

• คำแนะนำต่าง ๆ หรือบทความในโลก online มีทั้งผิดและล้าสมัย
• มีคำแนะนำที่ไม่ดีมากมาย เช่น แก้ไขด้วย WAF หรือ ทำการ upgrade version ของ Java หรือ update format ของ log เป็นต้น

การตรวจสอบ

เนื่องจากผลกระทบจาก log4j นี้
มีผลทั้ง Java, Scala, Groovy และ Clojure
ดังนั้น จึงทำการสร้างเครื่องมือชื่อว่า log4shell ขึ้นมาพัฒนาด้วยภาษา Go
เพื่อทำการ scan แบบอัตโนมัติให้
โดย scan ได้ทั้ง JAR แล WAR file
ซึ่งจะทำการ scan หา library จาก checksums ดังนี้

หรือจะทำการตรวจสอบพวก vendor software ต่าง ๆ
ก็มีทำการสรุปไว้ให้เพียบ เรียงตั้งแต่ A-Z กันไปเลย

การแก้ไขที่ถูกต้อง

• Upgrade log4j เป็น version 2.15.0
• ทำการ config formatMsgNoLookups=true หรือกำหนดใน environment variable ชื่อว่า LOG4J_FORMAT_MSG_NO_LOOKUPS=true หรือใน JVM argument variable ชื่อว่า JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
• สาย Hacker สามารถทำการแก้ไข jar file เลย ด้วยการแก้ไข class org.apache.logging.log4j.core.lookup.JndiLookup แต่ไม่แนะนำ

ลองอ่านเพิ่มเติมได้ครับ น่าจะพอมีประโยชน์

เพิ่งเห็นว่าทาง supabase ทำการ open-source
project ชื่อว่า pg_graphql ออกมา
ซึ่งเป็น extension สำหรับการเพิ่ม GraphQL เข้าไปใน PostgreSQL กันไปเลย
แต่ยังเป็น pre-alpha version นะครับ
โดยความสามารถที่มีประกอบไปด้วย

• Schema generation จาก table ใน database
• Query parser
• Resolver

ตอนนี้ยังไม่ได้ทดลองใช้งาน
แต่จากเอกสารพบว่า performance ใช้ได้เลย
รวมทั้งอยู่ใน database เลย
ทำให้การเปลี่ยนแปลง schema จะตามการเปลี่ยนแปลงของ table ไปเลย

ดูไปดูมา PotgreSQL จะไม่ใช่ database แล้วนะ

สามารถทดลองใช้งานได้เลยที่นี่ Getting start

Reference websites

https://supabase.com/blog/2021/12/03/pg-graphql

วันนี้อ่านเจอเรื่อง Knowledge Silos หรือ Information silos
ก็เลยลองไปหาอ่านเพิ่มเติมหน่อยว่า มันคืออะไร เป็นมาอย่างไร
ซึ่งมันมักจะเกิดจาก

• จำนวนพนักงานที่มากขึ้น
• จำนวนแผนกหรือส่วนงานในองค์กรที่มากขึ้น
• ต้องมีความเชี่ยวชาญในด้านต่าง ๆ มากขึ้น
• ผลตอบแทนแต่แตกต่างกันไปตามสายงาน ที่ต่างกันอย่างมาก

โดยเรื่องของ Silo ในองค์กร มักจะเกิดขึ้นเสมอ

ผลที่ตามมามักทำให้แต่ละส่วนแยกกันทำงาน
มักจะเกิด conflict หรือข้อขัดแย้งกันตลอด
มักจะทำให้เกิดความไม่ไว้ใจกัน
ผลที่เกิดขึ้น มันคือ performance ขององค์กรหรือไม่
ดังนั้นจากคำว่า แผนกของเรา ให้เป็นบริษัทของเราจะดีกว่าไหม ?

ในแง่ของการพัฒนา software นั้นเรื่องของ Knowledge Silos มีมากมาย

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

การสร้างสิ่งที่ไร้ประโยชน์ขึ้นมา
หรือเรามักจะเรียกว่า secondary work
นั่นคือ มันคืองานที่้ไม่ได้มีคุณค่าต่อ business เลย
เช่นเมื่อนักพัฒนาเขียน code เสร็จแล้ว
ต้องมีการทำ review code
ต้องมีการทำ architecture review
มันคือการแยกความรู้ของการสร้าง software ออกเป็น 3 ส่วนอย่างชัดเจน
มันคือการเสียเวลามากเกินไปหรือไม่
หนักกว่าเดิม คือ สร้างสิ่งที่ไม่มีใครใช้ออกมา
การทำงานซ้ำซ้อน
ทีมช้าลงเพราะว่า Bus number/factor

ต้นเหตุของปัญหา Knowledge Silos มาจากอะไร

ส่วนมากเกิดจากปัญหาการทำงานร่วมกันที่ไม่ดี
รูปแบบการทำงานที่แตกต่างกัน
ต่างคนต่างทำงาน แม้จะทำงานด้วยกัน
ยิ่งถ้าต่างแผนกกันยิ่งไปกันใหญ่
ดังนั้นถ้าต้องการความรู้จากส่วนต่าง ๆ ต้องทำอย่างไร ?

Reference Websites

https://www.pluralsight.com/tech-blog/knowledge-silos/
https://www.atlassian.com/blog/teamwork/how-to-break-down-information-silos

คำถาม
ในการพัฒนาระบบงานด้วยภาษา Go นั้น
ใช้ library อะไรกันบ้าง ?

คำตอบ
มันขึ้นอยู่กับระบบงานด้วยว่าเป็นอย่างไร ใช้ technology อะไรบ้าง

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

• ถ้าใช้งาน PostgreSQL ก็ใช้งาน pg กับ sqlx
• ถ้า MongoDB ก็ใช้งาน go-mongo-driver
• ถ้า Kafka จะใช้งาน confluent kafka go กับ kafka go

แต่ถ้าเป็นเรื่องพื้นฐานที่ใช้งานบ่อย ๆ
ที่ไม่ใช้ standard library ของ Go สามารถสรุปได้ดังนี้

• Testing จะใช้งาน testify กับ Mockery และอีกตัวคือ gotestsum
• จัดการ environment ด้วย env
• จัดการ errors
• Logging แต่ก่อนใช้งาน logrus หลัง ๆ มาใช้งาน zap กับ zap driver
• Web หรือ REST API จะใช้งาน gin และ echo

หลังจากที่ Dart และ Flutter ปล่อย version ใหม่ออกมาให้ใช้งาน
แน่นอนว่า มีการเปลี่ยนแปลงและปรับปรุงตัวภาษา
รวมทั้งเรื่องของ performance
จึงทำการสรุปแบบสั้น ๆ ไว้ดังนี้

Dart 2.15

• การปรับปรุงหลักคือ เรื่องของ concurrency ที่เพิ่มเรื่อง worker isolatesเข้ามา ช่วยปรับปรุง performance ให้ดีขึ้น
• ทำการ compress pointer ซึ่งช่วยลดการใช้งาน memory ลง ส่งผลดีต่อ Flutter อีกแล้ว
• เพิ่ม Constructor tear-offs ช่วยให้การสร้าง Fluter UI ได้ง่ายขึ้น
• ปรับปรุงเรื่องของ generic และ enum อีกแล้ว !!
• ตอนนี้ Dart DevTools เพิ่มเข้ามาใจ Dart SDK แล้ว
• Dart จะทำกาค้นหาและตรวจสอบ secret keys ในระบบ และทำการแจ้งเตือนให้รู้ ช่วยเรื่องของ security ได้เยอะเลย สำหรับคนขี้ลืม เนื่องจากเรื่องนี้เจอเยอะมาก ๆ ใน GitHub repository

Flutter 2.8

• Start time ของ app เร็วขึ้น
• ใช้ memory น้อยลง
• ใช้ความสามารถของ Dart 2.15 จากด้านบน
• เห็นที่เน้น ๆ คือ ขั้นตอนการ authentication จาก google และ apple ที่ง่ายขึ้น
• ทางสาย game engine ก็มี Flame ที่ปล่อย version 1.0 ออกมาแล้ว

ได้เวลา update กันได้แล้ว

Reference Websites

• https://medium.com/dartlang/dart-2-15-7e7a598e508a
• https://medium.com/flutter/whats-new-in-flutter-2-8-d085b763d181

เห็นในโลก online มีการทำ meme ของปัญหา Log4Shell ออกมา
เลยทำการบันทึกไว้นิดหน่อย
ใครเห็นเพิ่มเติม แนะนำมาได้นะครับ

Reference Websites

https://blog.devgenius.io/log4shell-as-explained-by-metaphor-and-memes-38de224a2eb7

สำหรับการเก็บข้อมูลรูปแบบ JSON ใน PostgreSQL นั้น
ก่อนหน้านี้จะเก็บใน type JSON
ซึ่งการจัดเก็บก็คือ type text นั่นเอง
จะเหมาะสำหรับเก็บข้อมูล JSON ที่มีรูปแบบที่ถูกต้องไว้
และไม่ต้องการการทำ index ของข้อมูลที่จัดเก็บ
ทำให้เพิ่มข้อมูลได้อย่างรวดเร็ว
โดย use case ที่เหมาะสมคือ log การใช้งานต่าง ๆ หรือพวก history ต่าง ๆ

แต่ถ้าเราต้องการเข้าถึงข้อมูลใน JSON ละ ?
สิ่งที่เก็บไว้ใน database ที่มี type JSON จะไม่ตอบโจทย์
โดยทาง PostgreSQL 9.4 ก็ได้เพิ่ม type JSONB (Binary or Better) มาจัดเก็บ
รวมทั้งสามารถทำ index ด้วย GIN indexing
ช่วยให้เข้าถึงข้อมูลตาม attribute/property ต่าง ๆ ใน JSON ได้อย่างรวดเร็ว
แต่โครงสร้างของ JSON ที่จัดเก็บต้องไม่ซับซ้อนด้วย
ดังนั้น การออกแบบสำคัญมาก ๆ

ใน PostgreSQL 14 ได้เปลี่ยนวิธีการเข้าถึง attribute/property ใหม่
รวมทั้งการใช้งานเบื้องต้นไว้ดังนี้

เป็นอีกหนึ่งทางเลือกของการออกแบบและพัฒนาระบบงานที่น่าสนใจ
ลองศึกษาเพิ่มเติมกันดูครับ

หลังจากที่ Oracle JDK 17 ถูกปล่อยออกมา
ด้วย Oracle No-Fee Terms and Conditions License
นั่นคือใช้งานได้ฟรี ๆ ไม่สัยสนอีกแล้ว
ส่วนการ download ก็มี URL ตรง ๆ ให้ download ในแต่ละ OS ได้เลย
ซึ่งน่าจะทำให้ง่ายและสะดวกต่อการใช้งานมากขึ้น

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

• https://download.oracle.com/java/17/archive/jdk-17_linux-x64_bin.tar.gz
• https://download.oracle.com/java/17/archive/jdk-17.0.1_linux-x64_bin.tar.gz
• https://download.oracle.com/java/17/archive/jdk-17.0.2_linux-x64_bin.tar.gz

ลองทำการ Download ดูครับ

อีกทั้งได้เตรียม Docker Image ไว้ให้ใช้งาน อยู่ที่ Oracle Container Registry อีกด้วย

วันนี้อ่านบทความเกี่ยวการพัฒนา
แล้วไปสะดุดกับคำว่า SPACE framework
ซึ่งบอกว่าใช้ช่วยเพิ่ม productivity ให้กับทีมพัฒนา
จึงไปดูเพิ่มว่ามันคืออะไร
ก็ไปเจอบทความ The SPACE of Developer Productivity

สำหรับการอธิบายเรื่อง productivity
ที่ไม่ใช่เป็นเรื่องส่วนบุคคล หรือ ทีม หรือ ระบบเพียงอย่างเดียว
ที่ไม่ใช่การใช้งาน metric เพียงไม่กี่ตัวก็วัดได้
หรือไม่ใช่สิ่งเดียวที่ manager สนใจ

โดยที่ SPACE ย่อมาจาก

• Satisfaction and well-being
• Performance
• Activity
• Communication and collaboration
• Efficiency and flow

Satisfaction and well-being

ความพึงพอใจของ developer
ที่มีต่องาน ทีม เครื่องมือ หรือวัฒนธรรมขององค์กร ว่าเป็นอย่างไร
งานที่ทำมี impact อย่างไร

Performance

ควรต้องทำการวัดจาก outcome ที่ออกมา ไม่ใช่จาก output ที่ทำได้
เพราะว่าเรื่องของ performance ไม่สามารถวัดได้ในแต่ละคน
เนื่องจากทำงานเป็นทีมดังนั้นควรต้องวัน performance ให้ถูก
เช่น

เรื่องของคุณภาพ
ก็วัดกันที่ความเสถียรและน่าเชื่อถือของระบบ
มี bug เยอะไหม

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

Activity

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

การ Design และ coding
วัดที่จำนวนหรือปริมาณของเอกสารและ spec ต่าง ๆ
จำนวน commit, code review และ pull request เป็นต้น

จากระบบ Continuous Integration และ Deployment
นับจากจำนวนการ build, test และ deploy หรือ release
รวมถึงการใช้งาน resource ต่าง ๆ ของระบบ

ไปจนถึง operation activity
ที่ดูถึงจำนวน issue หรือ incident ที่เกิดขึ้นและแยกตาม severity อีกด้วย
ไปจนถึงจำนวนการ on-call
และการแก้ไข incident ต่าง ๆ ว่าเยอะไหม

โดยที่ตัวเลขต่าง ๆ จะช่วยให้เราเห็นการทำงานตลอดจนปัญหา
และวิธีการแก้ไขต่อไป

Communication and collaboration

ว่าด้วยเรื่องของการทำงานร่วมกันว่าเป็นอย่างไร
เนื่องจากการพัฒนา software นั้น มันคือการทำงานร่วมกัน
ตั้งอยู่บนการติดต่อสื่อสารที่ดี มีประสิทธิภาพ
การประสานงานที่ดี ไร้รอยต่อทอเต็มผืน
ยิ่งการทำงานระหว่างทีมหรือหลาย ๆ ทีม ยิ่งสำคัญ
ไม่ให้เกิดปัญหาคอขวด หรือ deadlock

โดยส่วนใหญ่จะวัดจาก

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

Efficiency and flow

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

โดยจะวัดจาก

• มีอะไรที่มาขัดจังหวะการทำงานบ้าง
• เวลาต่าง ๆ ที่ใช้ไป เช่น เวลาทั้งหมดตั้งแต่ต้นจนจบ หรือ เวลาที่ต้องรออะไรสักอย่าง
• จำนวนเวลาที่ไม่มีอะไรมาขัดจังหวะเลย
• จำนวนงานที่ต้องทำใน process หรือ ข้ามทีม

ตัวอย่างตัวชี้วัด หรือ metric

เป็นอีกเรื่องที่น่าสนใจ ลองศึกษาเพิ่มกันดูครับ

ไป review ดูการทำงานของการเขียน SQL statement ใน Database
พบว่ามีสิ่งที่น่าสนใจ หรือ ปัญหานั่นเอง ประกอบไปด้วย

• ทำการ update เสมอ ไม่ว่าจะมีข้อมูลตามเงื่อนไขหรือไม่
• ทำการ query ข้อมูลบ่อยเกินไป

ส่งผลให้ database มีการทำงานมากผิดปกติ
คำถามคือ จะแก้ไขหรือลดการใช้งาน database อย่างไร ?

เริ่มจากปัญหาแรก คือการ update

เท่าที่ดูการทำงานมีการใส่เงื่อนไข และ join ข้อมูลข้ามหลาย table
ซึ่งจะทำงานเสมอทั้งมีข้อมูลและไม่มีข้อมูล
ตรงนี้เลยไปดูหน่อยว่า จะทำการปรับปรุงได้อย่างไร ?
ซึ่งก็ทำไปทำมาหลายวิธี
ทั้งการเพิ่มเงื่อนไขให้ถูกต้องตาม business condition ขึ้น
เพื่อลดเวลาของการการ update และจำนวน row ที่ถูก update
ก็ดีขึ้นมาก

แต่ก็ได้ลองดูอีกวิธีคือ
ถ้าไม่มีข้อมูลตามเงื่อนไขแล้ว จะไม่ทำการ update
เพราะว่าการ update ใช้ resource ที่สูงมาก ๆ
น่าจะดีกว่า
เพราะว่าจากข้อมูลที่เก็บพอว่า มีการ update มากกว่า 60-70% ที่ไม่มีข้อมูลตามเงื่อนไข
ดังนั้นจึงลองเพิ่มขึ้นตอนการตรวจสอบข้อมูลก่อน
ถ้าไม่มีก็จบการทำงาน
แต่ถ้ามีข้อมูลจึงทำการ update ตามที่เจอไป
ผลที่ตามมาคือ ลดการใช้งาน resource ของ database ลงไปประมาณ 20-30%
ซึ่งเป็นวิธีการที่ไม่คิดว่าจะทำให้ดีขึ้น

ปัญหาที่สอง คือ การ query ที่มากเกินไป

การแก้ไขไม่ยาก ก็แค่ลดจำนวน query ลงไป
แต่ผลกระทบที่มากคือ การเขียน code ที่ต้องเปลี่ยนไป
ก็ใช้เวลานานหน่อย
กับนำเรื่อง caching data มาช่วยเก็บข้อมูลที่ไม่ค่อยเปลี่ยนแปลงและใช้งานบ่อย ๆ
ก็ช่วยลดปัญหาไปได้เยอะ

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

อ่านบทความเรื่อง Best practices can slow your application down
จากทาง Stack Overflow
โดยได้อธิบายว่า ไม่ค่อยทำตาม best practice ในการพัฒนาระบบมาเลย
ทั้งการออกแบบ เขียน code ที่ช่วยให้อ่านและดูแลได้ง่าย
รวมถึงการทดสอบ และ deploy ระบบ
เป็นเรื่องที่น่าสนใจมาก ๆ ว่า แล้วตัดสินใจกันอย่างไร ?
ว่าจะเลือกไปทางไหนในการพัฒนาระบบ

สิ่งที่ใช้ในการตัดสินใจคือ Cynefin framework
แสดงดังรูป

โดยระบบของ Stack Overflow ในปัจจุบันนั้น เรียกได้ว่าเป็น Obvious แล้ว
เนื่องจากเป็นปัญหาที่ชัดเจนมาก ๆ แล้ว
มี best practice เพื่อแก้ไขปัญหาให้ทำตามเพียบ
ซึ่งทำให้เราพัฒนาได้เร็วขึ้น

แต่เมื่อย้อนกลับไปเมื่อปี 2008 แล้ว ปัญหาที่เจอหรือระบบที่พัฒนาไม่ได้ Obvious เลย

น่าจะเป็น complex หรือ complicate มากกว่า
เพราะว่า จะทำอย่างไรให้ระบบที่เป็นอยู่ scale ได้
ซึ่งไม่มีคำตอบที่ชัดเจน
รวมทั้งไม่มี expert มาช่วยได้เลย
มีคนที่เจอปัญหาเหมือน ๆ กัน มาคุยกัน

จนมาวันหนึ่งได้ตั้งเป้าหมายไว้ว่า Performance is a feature
นั่นหมายความว่า ต้องทำการปรับปรุง เปลี่ยนแปลงระบบให้ดีขึ้น
ด้วยการลองแยก ลองทดสอบ ลอง deploy
จนได้แนวทางที่เหมาะสม
และกลายมาเป็น best practice ในที่สุด
และเหมาะสมกับความต้องการของเราเอง
จากปัญหาที่เป็น complex/complicate กลายมาเป็น obvious

ดังนั้นเราอาจจะต้องรู็และเข้าใจปัญหาของเราก่อน
ที่จะเลือก solution ใด ๆ มาแก้ไข

Remix คืออะไร ?
มันคือ full stack web framework
มีเป้าหมายหลักที่ user interface รวมทั้งหลังบ้าน
ที่ต้องการให้ส่งมอบและทำงานได้อย่างรวดเร็ว
แน่นอนว่า มาพร้อมกับความน่าเชื่อถือ
และ ประสบการณ์การพัฒนาและใช้งานที่ดี (DX vs. UX)

เพิ่งปล่อยออกมาในเดือนพฤศจิกายนที่ผ่านมา
เทียบได้กับ react framework ใหม่ตัวหนึ่งนั่นเอง (ไม่ใช่ Remix IDE นะ)

สิ่งที่ต้องรู้ไว้ก่อนของ Remix คือ

• ตอนนี้ฟรีและ open source แล้วนะ
• ใช้ esbuild
• สนับสนุน SSR (Server-Side Rendering)
• เรื่อง Routing มีทั้งแบบปกติและ nest roting มาให้ครบ
• มี HTTP caching ให้ อยู่ในส่วนที่เรียกว่า Loader
• สร้างบน Web Fetch API ดังนั้นจะ run ได้ทั้ง Node และ Non-Node server เช่น Vercel, Netlify และพวก Cloudflare worker เป็นต้น

เพื่อให้เห็นภาพขึ้น มาลองติดตั้งและใช้งานกันที่ Geting start with Remix
มีชุดเครื่องมือให้ใช้ครบครันเลย

การทำ code review ในขั้นตอนการพัฒนา software นั้น
เป็นสิ่งที่จำเป็น และ ควรเป็นสิ่งที่เกิดขึ้นอยู๋ตลอดเวลาหรือบ่อยที่สุด
โดยไม่รู้เหมือนกันว่าจะทำตอนไหนอย่างไร ?
เพราะว่า มันขึ้นอยู่กับสถานการณ์ หรือ ข้อจำกัดอะไรบางอย่าง
แต่ควรทำให้บ่อย ๆ และงด drama ให้มากที่สุด

แต่ถ้าเราทำ code review ที่ดีแล้ว
ผลที่ได้น่าจะเป็นดังนี้

• จำนวน review ที่น้อยลง หรือต้องมีกรอบเวลาที่ชัดเจน
• ลดจำนวนของ bug หรือ ข้อผิดพลาดลง
• แน่นอนว่า code นั้นง่ายต่อการดูแลรักษา หรือ เพิ่ม Developer Experience
• ความรู้ของ code ไม่ผูกติดกับคนใดคนหนึ่ง เนื่องจากทุกคน หรือ มากกว่าหนึ่งคนรู็และเข้าใจ
• ลดปัญหาคอขวดจากงานที่ load ไปอยู่กับคน ๆ เดียวเยอะเกินไป
• เหมาะสำหรับคนเข้ามาร่วมทีมใหม่ เพื่อเรียนรู็และเข้าใจระบบได้ดีและเร็วขึ้น
• ลดการ review ซ้ำ ๆ ด้วยเครื่องมือที่ทำงานแบบอัตโนมัติ เช่น code style หรือพวก static code analysis tool เข้ามาช่วย

วันนี้ทำ code review กันแล้วหรือยัง
ถ้าทำ ทำบ่อยไหม
ถ้าบ่อย มีคุณภาพที่ดีขึ้นไหม

คำถาม
รู้หรือไม่ว่า ตั้งแต่ Java 9 ขึ้นมา underscore (_) มันคือ keyword ใหม่นะ
และใน Java 8 จะเป็น warning !!
ตามจริงใช้ได้ตั้งแต่ Java 7 แล้ว

โดยในภาษา Java เราสามารถใช้ _ ใน identifier ต่าง ๆ ได้
เช่นตัวแปร ชื่อ class/function/package เป็นต้น
หรือใช้เพื่อให้ชื่อต่าง ๆ อ่านง่ายขึ้น

เมื่อประกาศตัวแปรชื่อว่า _ เพียงอย่างเดียวใน Java 9 ขึ้นมา
แต่ถ้ามากกว่า 1 ตัวจะได้นะ
จะแสดงผลดังนี้

ประเด็นคือ _ มีไว้ทำอะไรใน Java ?

ใช้นำมาปรับปรุงเรื่องของรูปแบบตัวเลขให้อ่านง่ายนั่นเอง
มันคุ้น ๆ เหมือนภาษาอื่น ๆ เลย
มาดูตัวอย่างการใช้งานกัน

มาลองใช้งานกันดูครับ
เป็นอีกหนึ่ง feature เล็ก ๆ ที่น่าสนใจ
ขอให้สนุกกับการ coding ครับ

จาก Refcard เรื่อง Getting Started With Observability for Distributed Systems
ทำการอธิบายเรื่องต่าง ๆ เกี่ยวกับ Distributed System หรือ ระบบแบบกระจายว่า

• มันคืออะไร
• มีข้อดีและข้อเสียอย่างไร
• จะดูแลรักษา และดูเรื่อง observability อย่างไร เช่น log, tracing และ metric เป็นต้น

แต่สิ่งหนึ่งที่น่าสนใจคือ Distributed System มีประโยชน์อย่างไรในเชิง business
โดยทำการสรุปด้วยภาพนี้

คำอธิบายเพิ่มเติมของภาพนี้
ใน Distributed System นั้นจะมี key feature ที่สำคัญ
ซึ่งช่วยให้การพัฒนาและส่งมอบมีความคล่องตัวและรวดเร็วทันต่อความต้องการของตลาดประกอบไปด้วย

• Availability
• Scalability
• Deployability
• Testability
• Maintainability

ถ้าขาดสิ่งใดสิ่งหนึ่งไปน่าจะส่งผลต่อการส่งมอบหรือไม่ ?
เน้นแต่ Velocity หรือความเร็ว
แต่ขาดเรื่องของ Testability, Deployability และ Maintainability จะเกิดอะไรขึ้น ?

ลองอ่านเพิ่มเติมกันดูครับ น่าจะมีประโยชน์

ปัญหาที่พบเจอ
วันนี้มานั่ง review code และ metric การใช้งาน
ของระบบ API ที่เชื่อมต่อกับ MySQL database
พบว่ามี API ตัวหนึ่งมี response time ที่สูงขึ้นมาก
จะเจอมากขึ้นเมื่อมีผู้ใช้งานมากขึ้น
ซึ่งเป็นปัญหาที่พบเจอได้บ่อยมาก ๆ
ก็เลยไป review code และดู SQL query กันหน่อย

สิ่งที่พบเจอคือ
ใน logic การทำงาน ต้องการตรวจสอบว่า
ข้อมูลผู้ใช้งานเป็นไปตามเงื่อนไขที่กำหนดหรือไม่ ?
โดยทำการเขียน SQL ด้วย SELECT id FROM USERS WHERE conditions;

ปัญหาแรกที่เจอคือ มี index แต่ไม่มีประสิทธิภาพ
เลยแก้ไขไปก่อน ก็ดีขึ้น เรื่องนี้พลาดบ่อยมาก ๆ

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

• SELECT count(1)
• SELECT with EXISTS

ผลที่ได้การ query ใช้เวลา fetch time ดังนี้

• SELECT id = 0.000010 - 0.000020 วินาที
• SELECT count และ exists ใช้เวลาพอ ๆ กัน = 0.0000060 - 0.0000080 วินาที

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

ผลจากการแก้ไข โลกสงบสุขขึ้นเยอะ

จากผลการสำรวจของ JavaScript Rising Star 2021 นั้น
มี project ที่น่าสนใจและได้รับความนิยมในโลกของ JavaScript เยอะมาก
แต่มี project หนึ่งที่แปลกดีและน่าสนใจมากคือ zx จาก Google

เป็นเครื่องมือจาก Google ที่ช่วยให้เราเขียน command line script
หรือเขียน script ในรูปแบบเดียวกับ shell script
ด้วยภาษา JavaScript และ TypeScript ได้แบบง่าย ๆ
เป็นอีกตัวช่วยหนึ่ง ที่ช่วยให้ง่ายต่อการเขียน script
นั่นหมายความว่า เราเรียนรู้ภาษาเดียวใช้งานได้หลายหลายขึ้น

ในการใช้งานนั้น จำเป็นต้องติดตั้ง NodeJS 14.13.1 ขึ้นไป
จากนั้นก็ติดตั้ง zx ได้เลย

โดยการเขียน script นั้นมีตัวอย่างและการใช้งานดังนี้

ให้ทำการบันทึกเป็นไฟล์นามสกุล .mjs
ซึ่งจะใช้ async-await ได้เลย

ใน zx นั้นจะเตรียม package ที่ใช้บ่อย ๆ และเป็นที่นิยมไว้ให้ใช้ด้วย เช่น

• node-fetch
• fs-extra
• globby

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

เพิ่งเห็นว่าใน YouTube นั้น ได้เอาจำนวนการ dislike ออกไปแล้ว
แต่ปุ่มยังคงให้กด แต่ตัวเลขจะแสดงเฉพาะเจ้าของ content เท่านั้น
ซึ่งมีผลตั้งแต่เดือนพฤศจิกายนปีที่แล้ว

การเปลี่ยนแปลงครั้งนี้ มีผลต่อคนเข้าใช้งาน YouTube มาก ๆ
เพราะว่า หลาย ๆ คนมักจะดูจำนวน like vs dislike และ view ของ content นั้น ๆ
เพื่อใช้ในการตัดสินใจดูหรือไม่ดู
ซึ่งการเอาออกไป ย่อมส่งผลแน่ ๆ ทั้งดีและไม่ดี
ยกตัวอย่างเช่น

• จำนวน like vs dislike มันช่วยสร้างความคาดหวังบางอย่างต่อ content นั้น ๆ
• จำนวน like vs dislike มันช่วยให้เราเสียเวลาน้อยลง เพราะว่า มีความคิดเห็นจากคนอื่น ๆ ช่วยให้ตัดสินใจง่ายขึ้น
• ทำให้ผู้ใช้งานดู content นานขึ้น แต่คุณค่าที่ได้อาจจะน้อยลง ซึ่งอาจจะตรงข้ามกับเวลาที่เสียไป
• ทำให้แยกยากมากขึ้นระหว่าง content ที่ดีและไม่ดี อาจจะมี fake มากขึ้นหรือไม่
• การ click dislike อาจจะน้อยลงหรือไม่ เพราะว่า กดไปก็ไม่เห็นอะไรเลย
• เป็นการปิดรับ feedback แบบตรงไปตรงมาหรือไม่
• หรือเป็นการให้คนดู ตัดสินใจด้วยตนเอง ไม่ใช่ดูจากคนอื่น
• แต่ทาง creator หรือผู้สร้าง content น่าจะรู้สึกสบายใจมากขึ้น

ดังนั้นเพื่อน ๆ คิดเห็นอย่างไรกับการเปลี่ยนแปลงครั้งนี้บ้าง ?

ปล. หรือไป feedback กันใน comment กันไป

ไปเห็น Mobile app แต่ละตัวมีการจัดการเลข version หลายแบบ
เลยทำการสรุปไว้นิดหน่อย
โดยปกติมักจะใช้เลข version แบบ Semantic versioning

Semantic versioning จะมี 3 หลักดังนี้ MAJOR.MINOR.PATCH

• MAJOR จะขยับเมื่อมีการเปลี่ยนแปลงแล้วทำให้เกิด breaking change จาก version เก่า
• MINOR จะขยับเมื่อมีการเปลี่ยนแปลงหรือเพิ่ม feature ใหม่เข้าไป โดยไม่เกิด breaking change
• PATCH จะขยับเมื่อทำการแก้ไข issue หรือ bug ต่าง ๆ บางที่ก็ใช้จำนวน bug หรือวันที่ทำการ deploy เป็นต้น

มาดูว่า Mobile App แต่ละตัวที่ใช้จัดการ version อย่างไร ?

• TRUE ID เอาไว้ดูบอล จะมีเลข version 4 หลัก เช่น 3.4.1.5
• TRUE Money เอาไว้จ่ายค่าอาหาร ค่าน้ำ ค่าไฟ ค่าโทรศัพท์ จะมีเลข version 3 หลัก และมีเลขต่อท้ายอีก ไม่รู้ว่าเลขอะไร เช่น 5.30.1 (1047)
• KPLUS จะมีเลข version 3 หลัก เช่น 5.15.2
• LINE MAN ไว้สั่งอาหารมากิน จะใช้ version 4 หลัก โดยหลักสุดท้ายจะเยอะมาก ๆ เช่น 10.0.0.3838 น่าสนใจว่า 3838 คืออะไร !! โดยจะเหมือนกับ Spotify เลย
• Shopee นั้นไม่มีอะไรแปลกใช้ version 3 หลัก แต่พบว่าหลักที่ 2 เยอะมาก ๆ เช่น 2.81.31

ใครใช้งาน App อะไรกันบ้างลองสังเกตกันดูครับ
เรื่องนี้ไม่ได้สำคัญอะไร แต่ก็น่าสนใจดี
ปกติใน App ที่พัฒนากัน จัดการเลข version กันอย่างไรบ้าง ?

พอดีเห็นว่า plugin ชื่อว่า Publish over SSH ใน Jenkins นั้นถูกระงับการใช้งานแล้ว
เนื่องจากปัญหาเรื่องของความปลอดภัย และการ maintain
ซึ่งอาจจะก่อให้เกิดปัญหาได้ สำหรับคนใช้งาน
ปล. แต่หลาย ๆ ที่คงไม่ใช้กันแล้วนะ !!

โดยแนะนำให้ไปใช้ plugin SSH Pipeline Steps แทนกันได้แล้ว
และสามารถดูรายชื่อ plugin ที่ถูกระงับการใช้งานเพิ่มเติมได้