จากที่เคยเขียน blog เรื่อง Jaeger ระบบ Distributed Tracing นั้น
ใช้งานผ่าน library ชื่อว่า OpenTracing
สำหรับจัดการรูปแบบข้อมูลของ tracing message
และจัดเก็บข้อมูลด้วย Jaeger

ในตอนนี้ OpenTracing ได้รวมกับ OpenCensus ในชื่อ OpenTelemetry
จึงมาดูการใช้งานหน่อย เห็นเขาว่าง่ายดี

จากคำถามใน course Microservices เกี่ยวกับ Tracing ว่า

ถ้าจะทำการ tracing ของ producer และ consumer
ที่ทำงานผ่าน messaging เช่น ActiveMQ, RabbitMQ และ Kafka เป็นต้น
จะต้องทำอย่างไร ?

ซึ่งผู้ถามนั้นได้ใช้งาน RabbitMQ ซึ่งแน่นอนว่า

มี library สำหรับการติดต่อสื่อสารผ่าน AMQP protocol
แต่ผลที่ออกมา สามารถดู tracing ได้ 
แต่ไม่สามารถแยก producer และ consumer ออกจากกันได้
นั่นคือ ในส่วนของ graph depenency ไม่สามารถแสดงผลได้

คำถามคือ ทำอย่างไรดี ?
คำตอบคือ กลับมาสู่เรื่องพื้นฐาน
คือทำเองนั่นเอง
จากรูปโครงสร้างของ tracing เป็นดังรูป

จากปัญหา ความต้องการคือ

• Service A คือ Producer
• Service B คือ Consumer ซึ่งจะเป็นลูกของ Service A นั่นเอง

โดยจากแนวคิดจะทำการสร้างฝั่ง Producer ขึ้นมาก่อน

จากนั้นเมื่อทำการสร้าง message ส่งไปยัง messaging 
ใน message ที่ส่งนั้นต้องมีข้อมูลของ

• Trace ID (group ของการทำงาน)
• Span ID (parent span)

ดังนั้นจำเป็นต้องดึงค่าทั้งสองออกมาด้วย code ตัวอย่าง

ต่อมาในส่วนของ Consumer นั้น ก็ต้องสร้าง Parent span จาก Trace ID และ Span ID ที่ส่งมา

ก่อนที่จะทำการสร้าง Span ของตัวเองต่อไป
ซึ่งก็สร้างไม่ยากถ้าไปอ่านชุดการทดสอบของ Trace นะ ดังนี้

ได้ผลการทำงานดังนี้

และในส่วนของ Dependency แสดงดังนี้

เท่านี้ก็สามารถสร้าง tracing แบบง่าย ๆ ในทุก ๆ ส่วนได้
โดยไม่ต้องไปง้อ library เพิ่มเติมในแต่ละ protocol แล้ว
พื้นฐานสำคัญมาก ๆ ครับ

สามารถดู code ตัวอย่างได้ท่ี Github:: Up1

ปัญหา เมื่อทำการแก้ไข production code หรือ test code แล้ว
ต้องทำการ run ชุดการทดสอบเองเสมอ ซึ่งน่าเบื่อมาก ๆ 
ดังนั้นจึงอยากให้ทำการทดสอบแบบอัตโนมัติ (Continuous Testing)
เมื่อมีการเปลี่ยนแปลง เหมือนกับพวก JavaScript framework ต่าง ๆ

วิธีการแก้ไข

เมื่อไปดู proposal ที่เปิดมาใจภาษา Go พบว่า
เคยมีคนขอ feature นี้แล้วที่ 
Proposal: cmd/go : add "go test" with "-watch" argument for automatic reload test
เป็นแนวทางที่น่าสนใจมาก ๆ  ชื่อคนขอคุ้น ๆ นะ !!

แต่ว่าก็ตกไป เนื่องจากเรื่องของความซับซ้อน
และเครื่องมือที่ใช้ในการสร้าง feature นี้เยอะเกินไป
รวมทั้งมีปัญหาเรื่องของ portability บน OS ต่าง ๆ นั่นเอง

ดังนั้นให้ไปใช้เครื่องมือตามแต่ละ OS นะ

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

• Linux ใช้ inotifywait
• Mac ใช้ fswatch

ตัวอย่างการใช้งาน fswatch ดังนี้

ให้ทำการ run file ข้างต้นค้างไว้
จากนั้นทำการแก้ไขไฟล์ต่าง ๆ ที่มีนามสกุล *.go
ได้ผลการทำงานเป็นดังนี้

เพียงเท่านี้ก็ใช้งานได้ละ มีสีด้วยนะ
ขอให้สนุกกับการ coding

ปัญหาที่มักเจอใน XCode สำหรับการเขียน iOS app ด้วยภาษา Swift คือ
รูปแบบการเขียน code ที่แตกต่างกัน ซึ่งมักจะแก้ไขด้วย
การพูดคุยและกำหนด rule ด้วยข้อตกลงหรือนำเครื่องมือมาใช้งาน
ยกตัวแย่างเช่น Swift Lint

แต่ปัญหาก็ยังตามมาอีกคือ รูปแบบของ indentation ของ code

แน่นอนว่า แตกต่างกันอีก
จะใช้ Format code แบบอัตโนมัติจาก  XCode ก็พึ่งไม่ค่อยได้
เลยมีโอกาสได้ลอง Swift Format
ผลออกมาใช้ได้เลย แถมใช้งานง่ายด้วย เนื่องจากมีทั้งแบบ

• ผ่าน command line
• ติดตั้ง extension ใน Xcode ได้เลย

การใช้งานก็ไม่ยาก เริ่มจากการติดตั้ง

หรือทำการติดตั้ง extension ใน XCode ได้เลย

ใช้งานดังนี้

และไปที่ menu Editor -> SwiftFormat

เพียงเท่านี้ก็ใช้งานได้แล้ว ง่ายขึ้นเยอะเลย

Reference Websites

• https://github.com/apple/swift-format
• https://nshipster.com/swift-format/

หลังจากที่ทำการ update Go มาเป็น version 1.14 แล้วพบว่า
มีความสามารถหลาย ๆ อย่างเปลี่ยนแปลงเข้ามา
ทั้งสิ่งที่เข้ามาเปลี่ยนแปลงตัวภาษาคือ Overlapping interface
รวมกับการเปลี่ยนแปลงหลัก ๆ ที่น่าสนใจเช่น

• ไม่สนับสนุน SSLv3 แล้ว
• ทำการตรวจสอบและใช้งาน vendor package โดยอัตโนมัติ
• ปรับปรุงประสิทธิภาพการทำงานของ defer
• ทำการเขียน code การทำงานของ Escape analysis ใหม่
• เพิ่ม environment variable ชื่อ GOINSECURE เข้ามาเพื่อให้สามารถยกเลิกการ validate certificate ได้เลย
• Go module สนับสนุน Subversion repository แล้ว
• ใน testing เพิ่ม method CleanUp() มาให้ สำหรับเรียกใช้งานสุดท้าย เพื่อคืน resource ต่าง ๆ
• ในการทดสอบ ผลการทดสอบจะถูกแสดงออกมาในรูปแบบ stream ผ่าน t.Log แล้ว แทนที่จะทำการแสดงเมื่อทำการทดสอบเสร็จสิ้น
• เพิ่งเห็นว่า เรากำหนด path ของ GOCACHE สำหรับเก็บ cached ของ module ต่าง ๆ ที่เราใช้ได้เลย

ยกตัวอย่างของ Overlapping interfaces

ไป Download กันเลยนะ !!

ไปอ่านดู feature ที่น่าสนใจใน Android Studio 3.6  พบว่าเยอะมาก
หนึ่งในนั้นคือ  การใช้งาน view binding
แทนการใช้งาน method findViewById() ไปเลย
ที่สำคัญใช้งานได้ทั้ง Java และ Kotlin ด้วย

โดยความสามารถนี้จะมาพร้อมกับ Android Gradle Plugin 3.6

แต่ไม่ได้เปิดเป็นค่า default นะ
ดังนั้นต้องทำการเปิด feature ขึ้นมาก่อน
ด้วยการแก้ไขที่ไฟล์ build.gradle ดังนี้

แต่ใน Android Studio 4 ต้องใช้แบบนี้ ไม่เข้าใจว่าทำไมต้องเปลี่ยนนะ !!

การเขียน code เพื่อใช้งานก็ต่างออกไปเล็กน้อยดังนี้

ความแตกต่างของ View binding กับ Kotlin และ ButterKnife

ว่าแล้วก็ไปใช้งานกันครับ

Referene Websites

• https://medium.com/androiddevelopers/now-in-android-13-483740e711c0
• https://medium.com/androiddevelopers/use-view-binding-to-replace-findviewbyid-c83942471fc

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

วันนี้แนะนำ Fastify ซึ่งเป็น web framework พัฒนาสำหรับ Node.JS
เป็นตระกูลเดียวกับ express, koa, hapi นั่นเอง
มีเป้าหมายเพื่อ

• เป็นมิตรกับนักพัฒนามากขึ้น นั่นคือเพิ่ม productivity
• ลดการใช้ทรัพยากรต่าง ๆ ลงไป เพื่อลดค่าใช้จ่ายของ infrastructure ลง
• มีประสิทธิภาพการทำงานที่สูง เมื่อเทียบกับ framework อื่น ๆ
• มี overhead การทำงานที่ต่ำลง
• มีระบบ plugin ที่ดี

โดยที่มีแรงบันดาลใจมาจาก express และ hapi

6 ความสามารถหลักของ Fastify

1. ตามชื่อเลยคือ ความเร็ว ซึ่ง hello world projectรองรับได้มากกว่า 30,000 request/sec
2. สามารถเพิ่มส่วนต่อขยายได้ง่าย ทั้ง hook, plugin และ decorator
3. ใช้ JSON Schema ในการตรวจสอบ routing ต่าง ๆ รวมทั้งการ serialize output ซึ่งช่วยเพิ่มประสิทธิภาพของการทำงาน
4. Logging จะใช้งาน pino ซึ่งทั้งเร็ว เล็ก แรงส์
5. เป้าหมายเพื่อเป็นมิตรต่อมักพัฒนา ทั้งความเร็วและความปลอดภัย
6. ถึงจะไม่ใช่ framework ที่พัฒนาด้วย TypeScript แต่ก็สนับสนุน TypeScript เต็มที่

ตัวอย่างของ code ในการทดสอบ performance

ลองยิงขำ ๆ บนเครื่อง Mac ได้แค่นี้

มาลองใช้งานกัน

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

คำถามคือ แล้วจะแก้ไขปัญหาได้อย่างไร ?

โดยในบทความจะอธิบายถึง

เหตุผลในการตัดสินใจเลือกแนวทางในการออกแบบ architecture ของ software
ว่า ควรที่จะต้องออกแบบตาม business value เป็นหลัก
เนื่องจากพบว่าส่วนใหญ่แล้ว
ถ้าพูดถึงการออกแบบ architecture ของ software
เรามักจะพูดถึงเรื่องของ Architecture attribute มากกว่า Business attribute

• Performance ของระบบว่าเป็นอย่างไร
• Resilient ของระบบว่า ถ้าเกิดปัญหาแล้วจะนำระบบกลับมาเป็นปกติได้อย่างไร
• ระบบงานต้องรองรับการเปลี่ยนแปลงได้ง่าย

แต่กลับไม่เคยพูดถึงว่า
ระบบที่ออกแบบมามานั้น มีคุณค่าเชิง business อย่างไรบ้าง
สร้างมาเพื่อสนับสนุน business นั้น ๆ จริงไหม
Architecture ที่ออกแบบมามันตอบโจทย์ business อะไรบ้าง

สิ่งที่ตามมาก็คือ การตัดสินใจในการเลือก architecture ต่าง ๆ

อาจจะเป็นทางที่ over-engineering ไป
อาจจะเป็นทางที่ยาก และมีค่าใช้จ่ายเยอะเกินไป
โดยไม่ได้ส่งผลดีต่อ business เลย

โดยช้างตัวนี้ มักจะมีส่วนประกอบต่าง ๆ ดังรูป

สิ่งท่ีน่าสนุกกว่าคือ เมื่อให้เชิญ business เข้ามาคุยกับทาง technical 

ผลปรากฏว่า ทาง technical ก็จะถามว่า
จะให้ business เข้ามาพูดคุยกับเราทำไม ?
มันคนละส่วนงานกันนะ ไม่เกี่ยวกัน !!
นี่คือสัญญาณที่อาจจะบอกว่า technical ตัดสินใจในทางของตนเองเท่านั้น
ไม่ได้สนใจ business value เลย
มันคือ ต้นเหตุของปัญหาต่าง ๆ หรือไม่นะ ?

ยกตัวอย่างเช่น ถ้าเราต้องการแยกระบบงานจาก Monolith ที่มีขนาดใหญ่และซับซ้อน

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

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

แนวทางของการ mapping ระหว่าง business value กับ architecture

ถ้าเรายังไม่เคยทำการสรุปว่า Architecture ของระบบงานกับ business value
มีความสัมพันธ์กันอย่างไรบ้าง
ในบทความแนะนำหลาย ๆ แนวทาง ทั้ง

• Value stream mapping
• ผลกระทบของระบบที่ผิดพลาด ส่งผลต่อ business อย่างไรบ้าง
• ใช้ระบบ monitoring มาช่วยดู business value 

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

มีระบบการทำงานที่รองรับ business เยอะ ๆ ไหม ?

เป็นชุดคำถามที่น่าสนใจ
ถ้าระบบเป็นแบบนี้แล้ว
อาจจะมาจากเรื่องของการ sharing
อาจจะมาจากเรื่องของการ reuse
เพื่อลดค่าใช้จ่ายในการพัฒนา แต่สิ่งที่ต้องทำเพิ่มเข้ามาจากแนวทางนี้คือ 

• Flexibility หรือความยืดหยุ่น
• Resilience

แต่ก็พบว่า เมื่อมีการเปลี่ยนแปลงหรือเกิดปัญหาขึ้นมาแล้ว

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

หรือถ้าเรานำเอาเรื่องของ bussiness value มาพูดถึงก่อน technical
เราน่าจะได้ระบบงานที่เฉพาะเจาะจงกับ business นั้นเลยหรือไม่
ซึ่งน่าจะมีผลดีต่อ business มากกว่าหรือไม่ ?
ซึ่งตรงนี้ก็น่าคิดนะ

อีกตัวอย่างหนึ่งที่น่าสนใจคือ การย้ายระบบไปขึ้น Cloud !!

คำถามคือ 
เราจะย้ายระบบขึ้นไปบน Cloud ทั้งหมดหรือไม่ ?
เราย้ายขึ้นไปเพื่อ หวังว่าระบบงานจะทำงานดีขึ้นหรือไม่ ?
หรือเร้าย้ายขึ้นไป เพื่อช่วยทำให้ business ทำงานได้ดีขึ้น สะดวกขึ้น ?
เราย้ายเพื่ออะไรกันแน่ ?

ก่อนย้ายควรพูดคุยและพิจารณาก่อนหรือไม่

ว่าอะไรควรย้ายหรือไม่ควรย้าย
อะไรควรแก้ไขก่อนที่จะย้าย
อะไรควรทิ้งก่อนย้าย
มันคือ คุณค่าที่เราต้องนำมาพิจารณาหรือไม่ ?

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

เหมือนกับขี้ ไม่ว่าจะอยู่ที่ไหน มันก็คือ ขี้ !!

ที่สำคัญ business value มันเปลี่ยนแปลงอยู่อย่างเสมอ
อะไรที่เคยสำคัญอาจจะไม่สำคัญก็ได้
ดังนั้น architecture ของระบบก็เช่นกัน

สุดท้ายสิ่งที่บทความแนะนำเลยก็คือ  ความรู้เชิง business เป็นสิ่งสำคัญของสายงาน techical 

ควรต้องทำการเรียนรู้และเข้าใจก่อนเสมอ
ยิ่งคนทำงานใหม่ ๆ ยิ่งต้องเรียนรู้ business domain ที่ทำงานอยู่ให้ชัดเจน
นั่นคือเรียนรู้ทั้ง Hard skill และ Soft skill

ยิ่งเรารู้และเข้าใจมากเท่าไร
เราก็จะพยายามออกแบบและสร้างระบบที่เหมาะสมมากเท่านั้น
เนื่องจากเรื่องนี้เป็นปัญหาหลักของ Business vs IT (Technical) กันเลยทีเดียว
ทำให้ต้องมีคนกลางมาแปลงสารอีก
มันคือการแก้ไขปัญหาด้วยการสร้างปัญหา
มันคือ ช้างอีกตัวที่เราสร้างกันขึ้นมา !!
โดยที่ไม่แก้ไขที่ต้นเหตุ
ดังนั้น ทั้งสองฝั่งต้องปรับตัวเข้าหากัน เดินหน้าไปด้วยกัน

คำถาม
ถ้าต้องเก็บข้อมูลสำหรับการค้นหาและวิเคราะห์ไว้ใน Elasticsearch
โดยข้อมูลต้นทางจะถูกเก็บไว้ใน RDBMS เช่น MySQL และ PostgreSQL เป็นต้น
ถ้ามีการแก้ไขข้อมูลที่ RDBMS แล้ว
จะทำการ sync หรือ update ข้อมูลใน Elasticsearch อย่างไรได้บ้าง ?

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

แต่หลาย ๆ คนอาจะบอกว่า

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

• ใช้ Kafka connect + JDBC
• ใช้ Logstash + JDBC input plugin

โดยใน blog นี้จะใช้งาน Logstash + JDBC input plugin

แนวคิดการทำงานของ JDBC input plugin ก็ไม่ได้ยากอะไร คือ
จะทำการ poll ถาม RDBMS ตามช่วงเวลาที่เรากำหนด 
เช่น ทุก ๆ นาที เป็นต้น เหมือนกับการกำหนดใน crontab นั่นเอง

จากนั้นจะทำการตรวจสอบว่า มีการเพิ่มหรือเปลี่ยนแปลงข้อมูลใน RDBMS หรือไม่ ?
จะทำการตรวจสอบผ่าน column ชื่อว่า modification_time และ insertion_time
ว่ามีค่ามากกว่า เวลาที่ poll หรือดึงล่าสุดหรือไม่
โดยที่ค่าทั้งสอง column จะถูกเพิ่มเข้ามาในการ update และ insert นั่นเอง

การสร้างก็ง่าย ๆ เริ่มจากสร้าง database และ table ข้อมูลหลักก่อน

ซึ่งต้องเพิ่ม 2 colum ไปด้วยดังนี้

จากนั้นทำการสร้าง config สำหรับ logstash 

โดยกำหนด input คือ JDBC จาก database ที่สร้างไว้
ในตัวอย่างผมใช้ MySQL
และ output ให้แสดงออกที่ console และ Elasticsearch server นั่นเอง

เพียงเท่านี้ก็ใช้งานได้แล้วนะ

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

ไว้ blog ต่อ ๆ ไป จะเอาตัวอย่างของ Kafka connect มาให้ดู

เจอรูปที่น่าสนใจว่า เราให้ความสำคัญกับคำว่า Loose coupling มากจนเกินไป
ทำให้เกิดระบบแยกกันมาก ๆ
ทำการเกิด communication และ relationship กันเยอะไป
ยิ่งกว่านั้นกลายเป็น dependency ที่เหนียวแน่นมาก ๆ (แยกกัน แต่ตอนทำงานดันติดกันมาก)
สุดท้ายก็กลายเป็นระบบที่ Complicate หรือซับซ้อนจนเอาไม่อยู่กันอยู่หรือเปล่านะ ?

ไปเจอว่า OWASP นั้นเพิ่มเรื่องของ API Security มาด้วย
(ตามจริงมานานละ แต่เพิ่งเห็น) กับมีงานที่ต้องนำไปใช้นิดหน่อย
เนื่องจากทุกระบบงานก็มีการใช้งาน API (Application Programming Interface) อยู่แล้ว
ไม่ว่าจะอยู่ในรูปแบบไหนทั้ง REST, Web API และ WebService เป็นต้น
ยิ่งเปิดให้ใช้งานแบบ public ด้วยแล้ว (ไม่ว่าทางตรงหรือทางอ้อม)
สิ่งที่สำคัญมาก ๆ คือ เรื่องของความปลอดภัยนั่นเอง

โดยจาก OWASP API Security Top 10 ปี 2019

ทำการสรุปว่า เรื่องที่ API โดนโจมตีหรือหลุดบ่อย ๆ มีดังนี้

1. Broken Object Level Authorization
2. Broken User Authentication
3. Excessive Data Exposure
4. Lack of Resources & Rate Limiting
5. Broken Function Level Authorization
6. Mass Assignment
7. Security Misconfiguration
8. Injection
9. Improper Assets Management
10. Insufficient Logging & Monitoring

จากที่อ่านดูนั้น พบว่าเรื่องของ Authorization นั้นมักจะหลุดบ่อยมาก ๆ

ทำให้สามารถดึงข้อมูลไปใช้งานได้โดยตรง จากผู้ที่เราไม่ต้องการให้เข้าถึง
หรือบ่อยครั้งจะทำการ authentication และ authorization เรียบร้อยแล้ว
แต่ดันไม่ส่งข้อมูลการทำการหรือตรวจสอบใน API อื่น ๆ หลังจากนั้น (Lack มาก ๆ)
รวมทั้งเรื่องของการ expose หรือส่ง response ออกมาเยอะจนเกินไป
หนักกว่านั้น เอาข้อมูลทุก ๆ  field ที่เก็บไว้ใน data store ออกไปเลยซะงั้น

อีกเรื่องที่ทำน้อยมาก ๆ คือ เรื่องของ Rate limit ในการเข้าถึง API
ซึ่งทำให้โดนระดมยิงหรือพวก DoS หรือ D-DOS แล้ว
ทำให้ประสิทธิภาพการทำงานของระบบแย่ลง หรือล่มไปง่าย ๆ

ส่วนของ Injection ประเภทต่าง ๆ ทั้ง SQL, NoSQL และ Command Injection
จากการไม่กรองข้อมูลขาเข้าให้ดี ก็ยังเกิดขึ้นเยอะ

ในเรื่องของการ configuration ที่ผิดพลาดในฝั่ง Server ก็ยังคงเกิดขึ้น
ซึ่งต้องระวังให้มาก ๆ  ทั้งเรื่องของ CORS, HTTP Header
และ HTTP method ที่ไม่จำเป็น
รวมทั้ง error message ที่แสดงข้อมูล sensitive data มากจนเกินไป

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

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

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

ส่วนเรื่องอื่น ๆ ก็มี

• Web
• Mobile
• Docker

อีกเรื่องที่น่าสนใจในการเขียน code ด้วยภาษา Go คือ Static Code Analysis
ซึ่งมีเครื่องมือให้ใช้เพียบเลย
แต่มีอีกตัวที่เพิ่มเห็นเลยขอลองสักหน่อย
นั่นคือ Golang CI Lint

การใช้งานก็ไม่ยาก

ทำการติดตั้งดังนี้ ซึ่งผมใช้งานบน Mac OS

โดยปกติแล้ว Golang CI Lint จะทำการตรวจสอบ

สิ่งต่าง ๆ เหล่านี้ให้เลย

• govet
• errcheck
• staticcheck
• unused
• gosimple
• structcheck
• varcheck
• ineffassign
• deadcode
• typecheck

แต่เราสามารถเปลี่ยนแปลงตามที่ต้องการได้ผ่านไฟล์ชื่อว่า  .golangci.yml
ยกตัวอย่างเช่น เปิดเฉพาะ golint เท่านั้น

เพิ่มเติมคือ อยากให้ทำการคอยตรวจสอบทุกครั้งที่มีการเปลี่ยน code

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

จากนั้นทำการ run ไฟล์นี้ทิ้งไว้ 

ก็จะทำการแจ้งให้เรารู้ว่า code มีอะไรที่ผิดปกติบ้าง
ยกตัวอย่างเช่น ประกาศตัวแปรไว้ แต่ไม่ได้ใช้ ดังรูป

เท่านี้ก็ใช้งานได้แล้ว สบายขึ้นเยอะ

ทาง Microsofts ได้ปล่อย project ที่ชื่อว่า .NET Interactive ออกมา
ซึ่งเป็นการรวมชุดเครื่องมือและ APIs ต่าง ๆ
ที่ให้ผู้ใช้งานสามารถใช้งานแบบ interactive
ผ่าน Web, Markdown และ Jupyter Notebook ได้
โดยที่จะแบ่งออกเป็น 3 ส่วนคือ

• dotnet interactive
• dotnet try
• trydotnet.js

โดยตัวที่ชอบคือ dotnet interactive ใน Jupyter Notebook นี่แหละ

การติดตั้งก็ไม่ยาก ก่อนอื่นต้องติดตั้ง

• .NET core 3.1 
• Python 3 + Jupyter ก่อน

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

ใช้งานดังนี้

มาใช้งานกันผ่าน web

Reference Websites

• https://devblogs.microsoft.com/dotnet/net-interactive-is-here-net-notebooks-preview-2/

ช่วงนี้การทำงานแบบ Remote หรือ Work From Home (WFH)
หรือบางคนอาจจะแย้งว่า มันคือ Work From Coffee shop มากกว่า
แน่นอนว่า การทำงานแบบ Remote ของทีมพัฒนา software
จำเป็นต้องมีเครื่องมือที่ดี เพื่อให้ทำงานร่วมงานกันได้ดี
ดังนั้นเรามาแบ่งปันกันหน่อยว่า
ใช้เครื่องมือะไรกันบ้าง

เริ่มต้นด้วย Git-based project น่าจะหนีไม่พ้น GitHub, BitBucket และ GitLab

ช่วยทำให้ทีมพัฒนาทำงานร่วมกันได้ง่ายขึ้น
ทั้งการจัดการ version ของ source code
ทั้งการจัดการเรื่อง task และ issue ต่าง ๆ
โดยนำมาจัดการเรื่อง release management ได้อีกด้วย
ทั้งการจัดการเรื่องของ การวางแผน หรือทำ board การทำงาน 

ใน GitHub ก็มี projects ให้ว่าจะจัดการแบบไหน

ใน BitBucket ก็มี Trello และ Jira ให้ใช้

รวมทั้งยังมีระบบ CI/CD ไว้ให้ใช้งาน เช่น

• GitHub มี GitHub Actions
• BitBucket มี Pipeline
• GitLab มี GitLab CI

ส่วนเอกสารต่าง ๆ นั้น ผมแนะนำให้ใช้งานผ่าน Wiki ได้เลย

สะดวกมาก ๆ แต่ต้องเข้าใจ Markdown format นิดหน่อย
หรืออาจจะไปใช้ Google Docs ก็ได้
ช่วยทำให้การจัดการเอกสารสะดวกมากยิ่งขึ้น

เครื่องมือตัวเดียวมีความสามารถให้ใช้ครบเลย
อยู่ที่ว่าเรารู้ หรือใช้งานหรือไม่เท่านั้นเอง

ส่วนเรื่องของ Communication tool

ที่ใช้บ่อย ๆ ก็

• Slack ตัวนี้ใช้ประจำ สามารถ integrate เข้ากับระบบอื่น ๆ ได้ง่าย สะดวกดีมาก
• Facebook group ก็พอได้
• เห็นในบริษัทหลาย ๆ ที่ใช้งาน Microsoft teams (หน้าตาไปทาง Slack เลย) ถ้าใช้ Office 365 suite ก็น่าจะไปตัวนี้กัน

ส่วนการพูดคุยแบบเห็นหน้าเห็นตาก็สำคัญ ทั้งประชุมและ VDO conference

มีทั้งแบบฟรีและเสียเงินถ้าต้องการพูดคุยแบบกลุ่มใหญ่ ๆ 
ยกตัวอย่างเช่น

• Zoom
• Google Hangout
• Skype

แต่เหนื่อสิ่งอื่นใดนั้น

การทำงานแบบ remote เรื่องความรับผิดชอบนั้นสำคัญมาก ๆ
ยิ่งต้องความรับผิดชอบที่สูงขึ้น
ยิ่งต้องการการ focus มากขึ้น  เนื่องจากมีสิ่งที่รบกวนเยอะมาก ๆ

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

สุดท้ายบริษัทต่าง ๆ เตรียมพร้อมกับเรื่องนี้กันหรือยัง
หรือทำเพียงเป็นการแก้ไขปัญหาเฉพาะหน้าเท่านั้น
ทั้งเรื่องของนโยบาย เป้าหมาย และเครื่องมือต่าง ๆ

ใครมีแนวคิด วิธีการและเครื่องมือที่ใช้งานแบบ Remote 
ก็นำมาแบ่งปันกันได้นะครับ

มีโอกาสไปคลุกคลีกับคำว่า DevOps เยอะหน่อย
พบว่าในแต่ละองค์กรนั้นจะเชื่อมั่นว่า DevOps เป็นแนวทางที่มีประโยชน์
ทั้งทางด้วย IT และ Business
เนื่องจากช่วยทำให้คนในกลุ่มต่าง ๆ ที่เกี่ยวของทำงานร่วมกันได้ดีขึ้น
มีการส่งมอบที่เร็วและบ่อยขึ้น พร้อมคุณภาพที่ดี
รวมทั้งต้องมีขั้นตอนการทำงานที่เหมาะสม
และชุดเครื่องมือที่เข้ามาช่วยให้ทำงานแบบอัตโนมัติได้ดียิ่งขึ้น

แต่กลับพบว่า เมื่อมีการนำ DevOps มาประยุกต์ใช้งาน

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

มีเครื่องมือใหม่ ๆ มาติดตั้งและใช้งาน
คำถามคือ เหมาะสมกับงานและ product ต่าง ๆ หรือไม่
หรือเหมาะสมกับคนทำงานหรือไม่

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

ดังนั้นมาลองปรับปรุงวิธีการนำ DevOps มาใช้งาน
ในเชิง practical กันหน่อยไหม
น่าจะช่วยให้ผลที่ออกมาดีขึ้น มาเริ่มกัน

เริ่มด้วยระบบที่ทำต้องไม่ใหญ่เกินไป แต่ก็ไม่เล็กจนไร้ค่าหรือง่ายไป

แต่สิ่งที่ทำนั้น ต้องสามารถนำไปแสดงหรือมีคุณค่า
เพื่อให้เห็นคุณค่าทั้งในเชิง IT และ Business

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

ดังนั้นแทนที่จะมีเป้าหมายที่กว้าง
ก็ให้เน้นไปที่เป็นเรื่อง ๆ ไป
ว่าจะปรับปรุงอะไรให้ดีขึ้น
ทั้งเรื่องของคน
ทั้งเรื่องของ process
ทั้งเรื่องของ technology

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

จากนั้นต้องสร้างสภาวะแวดล้อมที่เอื้อต่อการทดลองและเรียนรู้

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

แน่นอนว่า ต้องมีทั้งผิดและถูก
ดังนั้นสภาวะแวดล้อมต้องไม่ซ้ำเติม
จำเป็นต้องได้รับการสนับสนุนที่ดีจากฝ่ายบริหาร

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

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

สิ่งที่สำคัญมาก ๆ คือ ทีมงานทั้งหมดต้องเข้าใจและยอมรับ

ว่าเป้าหมายของการนำ DevOps มาใช้เพราะอะไร
ต้องยอมรับว่าเรามีปัญหาอะไร
สิ่งที่กำลังจะทำเข้ามาช่วยแก้ไขและปรับปรุงปัญหาอะไร
ทำไมต้องทำงานร่วมกันแบบจริงจัง 
ทำไมถึงต้องเริ่มเข้าใจและทำ CI/CD

สุดท้ายแล้ว เริ่มที่ปัญหาว่ามีอะไรบ้าง

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

เรื่องที่สำคัญของการพัฒนา software คือ
ขั้นตอนการ build, test, release และ deploy เป็นอย่างไรบ้าง
ในการพัฒนาที่ดี น่าจะต้องวางแผนและกำหนดขั้นตอนการทำงานไว้
ซึ่งเราจะเรียกขั้นตอนเหล่านี้ว่า Build pipeline (workflow)
นำมาจากแนวคิดของ Continuous Integration และ Continuous Delivery

โดยในบทความนี้ จะนำ GitHub Actions มาสร้างกระบวนการเหล่านี้
มาเริ่มกันเลย

ก่อนจะใช้เครื่องมือ ต้องคิดและออกแบบว่าเราต้องการอะไรบ้าง ?

ลองสร้างระบบง่าย ๆ เมื่อมีการ push หรือเปิด Pull Request มายัง repository
โดยมีขั้นตอนการทำงานดังนี้

• Manage dependency ทำการ download dependency ต่าง ๆ ที่ใช้งาน
• Lint
• Test
• Code coverage ด้วย CodeCov
• Build สำหรับสร้าง binary file 
  • กระบวนการ release เช่นสร้าง binary file ของระบบปฏิบัติการต่าง ๆ ด้วย Go Releaser

มาลงมือสร้างขั้นตอนการทำงานด้วย GitHub Actions

ตัวอย่างของ source code อยู่ที่ GitHub:Up1

จากนั้นทำการสร้าง GitHub Actions ใน repository เลย
หรือจะสร้างเองด้วยการสร้าง file .github/workflow/build.yml 

เริ่มต้นด้วยขั้นตอนแรกคือ Lint ด้วย Golint

จะทำงานเมื่อมีการ push และ ส่ง Pull Request มายัง branch master

จากนั้นเข้าไปดูใน menu Actions จะทำงานและได้ผลดังนี้
เนื่องจากใน code ไม่ทำการเขียน comment ของ public function
แสดงดังนี้

แน่นอนว่า ต้องแก้ไข code และทำการ push ขึ้นไปใน repository
จะได้ผลการทำงานดังนี้

ขั้นตอนที่ 2 ทำการทดสอบและ code coverage report 

ไปดู code coverage report ได้ดังนี้

หรือลองเปิด Pull Request เข้ามายัง repository ดูหน่อย
จะมีผลการทำงานดังนี้

ขั้นตอนที่ 3 ทำการ release ด้วยการสร้าง file สำหรับ deploy บน OS ต่าง ๆ

ด้วยการใช้ Go Releaser ซึ่งง่ายมาก ๆ 
จะทำการเมื่อมีการสร้าง tag ขึ้นมาใน repository 
โดยที่ชื่อ tag ต้องเป็น Semantic versioning ด้วย
ดังนี้

เมื่อทำการ push tag ขึ้นไปใน repository จะทำงานดังนี้

ลองนำไปใช้กันดูครับ สะดวกดีนะ
สามารถนำไปต่อยอดเรื่องของ deploy ต่อไป
รวมทั้งเรื่องของ functional testing อีก
ขอให้สนุกกับการ coding ครับ

ทาง O'reilly ได้ปล่อยหนังสือแบบฟรี ๆ ชื่อว่า What is SRE ?
ซึ่งย่อมาจาก Site Reliability Engineering
เป็นอีกเรื่องที่สำคัญของระบบงานในปัจจุบัน
เพื่อช่วยทำให้ระบบงานมีความถูกต้องและน่าเชื่อถือ

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

ไป Download กันได้เลยครับ

เห็นว่า GitHub ได้ประกาศว่า ปล่อย GitHub app for mobile ออกมา
ซึ่งพัฒนาด้วย Native app เลย
ดังนั้นมาแกะดู GitHub app for Android กันหน่อย
ว่าพัฒนาด้วยอะไรบ้าง

จากการไป download และลองเข้าไปลอง reverse engineer

ไฟล์ APK จะเป็นแบบ Multiple APK
ขนาดของ APK เพียง 6 MB เท่านั้นเอง

ส่วนการพัฒนาจะใช้เครื่องมือและ library ต่าง ๆ ดังนี้

• ใช้ภาษา Kotlin และใช้งาน AndroidX library
• ติดต่อไปยัง RESTFul API ด้วย OkHTTP 3
• จัดการแสดงรูปภาพด้วย Glide
• Push notification ใช้งาน Firebase ตามระเบียบ
• ใช้งาน Firebase analytic และ Crashlytic ตามปกติ
• เรื่องของการจัดการเวลาใชข้งาน Joda Time

ในส่วนของการ Authentication จะสร้างเป็น Service ขึ้นมา

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

• addAccount
• confirmCredentials
• getAuthToken
• hasFeatures
• updateCredentials

ส่วนของ permission ที่ขอไว้มีดังนี้

ในส่วนของ Activity จะแบ่งออกเป็นเรื่องต่าง ๆ

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

• SplashActivity
• RepositoriesActivity
• RepositoryActivity
• UsersActivity
• SearchResultsActivity
• SettingsActivity
• PullRequestReviewActivity
• CreateIssueActivity
• CommitActivity
• CreateIssueRepoSearchActivity

โดยในแต่ละ Activity จะมี fragment แยกกันไป
ส่วน View อะไรที่ใช้งานร่วมกัน จะแยกออกไปในส่วนของ View กลางอีกที

เป็น App ที่ใช้งาน library ตามปกติ ไม่มีอะไรที่แปลกใหม่มากนัก
เนื่องจากเป็นเหมือน UI สำหรับอีก device เท่านั้นเอง

ทำการรวบรวม website สำหรับติดตามข้อมูล COVID-19 ของไทยไว้นิดหน่อย
ซึ่งน่าจะพอเป็นประโยชน์สำหรับการติดตาม
จะได้ง่ายขึ้นหน่อย (มั้ง)

• Work point news
• The Standard
• Lab 5 Covid-19 tracker
• เกาะติดสถานการณ์ โรคติดเชื้อไวรัสโคโรนา 2019 (COVID-19) จากกระทรวงสาธารณสุข
• รายงานสถานการณ์ โรคติดเชื้อไวรัสโคโรนา 2019 (COVID-19) จากกรมควบคุมโรค
• สถานการณ์ในประเทศ เป็นรูป ทำการ update ทุกวัน
• Dashboard สถานการณ์โดยรวมของโลก
• ติดตามจากรัฐบาลไทย ประจำวัน
• TH Stat

และสามารถติดตามได้จาก WHO
รวมทั้งคำแนะนำต่าง ๆ

บทที่ 1 เรื่อง Why is This a Great Time to Learn Elm ?
ทำไมถึงเป็นช่วงเวลาที่ดีมาก ๆ สำหรับการเรียนรู้ Elm
โดยจะมีเนื้อหาประกอบไปด้วยสิ่งต่าง ๆ ดังนี้

• Elm คืออะไร
• จุดเด่นของ Elm สำหรับการพัฒนา frontend ของ web
• เปรียบเทียบกับ JavaScript
• เริ่มต้นพัฒนาระบบงานด้วย Elm ซึ่งมีตัวช่วยทั้ง Ellie-app, Cloud9 และ Text Editor

มาเริ่มกันเลย

Elm คืออะไร 

เป้าหมายหลัก ๆ คือ นำแนวทาง functional programming 
มาใช้สำหรับการพัฒนา frontend ของ web
และช่วยทำให้ได้รับระสบการณ์ในการพัฒนาที่ดีกว่าเดิม
รวมทั้งยังช่วยลดปัญหา error ที่มักเจอบน production
เช่น JavaScript error เป็นต้น

นั่นหมายความว่า Elm จะทำการตรวจสอบในช่วง compile time ว่า
จะมี error ใด ๆ มีโอกาศเกิดขึ้นได้บ้าง
ทำให้เรารู้ปัญหาต่าง ๆ ตั้งแต่การ coding กันเลย
นั่นช่วยสร้างความมั่นใจให้นักพัฒนาได้อย่างสูง

ที่สำคัญ Elm สร้างด้วยแนวทางของ functional programming 
หนึ่งในนั้นคือ Pure function ช่วยทำให้ไม่เกิด side effect
รวมทั้งเรื่องของ immutable ด้วย
ทำให้การ debug ง่ายขึ้นเป็นกอง

และยังทำงานร่วมกัน library ต่าง ๆ ได้

แน่นอนว่า Elm ให้เราสามารถจัดการกับ event หรือเกตุการณ์ต่าง ๆ ที่เกิดขึ้น ได้อีกด้วย ซึ่งยังคงความ immutable ไว้ให้

ทำไมต้องเรียนรู้ Elm ด้วย

โดยที่จะมีจุดเด่นต่าง ๆ เหล่านี้

• Virtual DOM ทำงานเร็วมาก ๆ
• Compile-time error นั่นคือจับ error ได้ตั้งแต่การเขียน code
• Zero runtime exception เป้นสิ่งที่ชอบมาก ๆ
• ช่วยเพิ่ม productivity ให้ทีม
• มีระบบ Type ให้ ซึ่งดีมาก ๆ 
• ง่ายต่อการ refactoring
• ขนาดของ output ที่ได้เช่น HTML, CSS และ JavaScript มีขนาดเล็กกว่า framework อื่น ๆ
• Time-traveling debugging
• ที่ชอบอีกตัวคือ Pipe syntax ( |> )

มาเริ่มต้นด้วยการเขียน code ดีกว่า

การเริ่มต้นทำได้หลายแบบ ยกตัวอย่างเช่น

• Elm try
• ตัวอย่างจาก Elm เลย มี editor online ให้ใช้
• Ellie app เป็น Editor online
• สร้าง project ผ่าน Create-elm-app

ทำการติดตั้งแบบง่าย ๆ และมี REPL ให้ใช้งานดังนี้

จากนั้นก็ Hello World กันหน่อยสร้าง project ดังนี้

ทำการสร้างไฟล์ /src/Main.elm

เมื่อทุกอย่างเรียบร้อย ทำการ run ดูดังนี้เพื่อเปิด app ตัวอย่างใน browser

แสดงผลดังนี้

เปิดไฟล์ src/Main.elm

มาเริ่มเรียนรู้ Elm กันต่อไปลองมาศึกษากันต่อ ตามรูปนี้