สำหรับใครเป็นแฟนหนังสือ The Phoenix Project 
ไม่น่าพลาดกับหนังสือใหม่ชื่อว่า The Unicorn Project
เล่าเรื่องราวเกี่ยวกับ DevOps transformation
อาจจะไม่ถูกใจกับองค์กรขนาดใหญ่ เพราะว่าเกือบทุกอย่างที่มันจะขัดแย้ง

โดยจะแนะนำ 5 แนวทางสำหรับการทำงาน
ซึ่งจะช่วยขับเคลื่อนองค์กรไปในทางที่ยั่งยืน

5 แนวทางประกอบไปด้วย

1. Locality and Simplicity
2. Focus, Flow, and Joy
3. Improvement of Daily Work
4. Psychological Safety
5. Customer Focus

Locality and Simplicity

เน้นไปที่การออกแบบระบบและองค์กร
เน้นไปที่ locality ของทีมงาน
มีการอ้างอิงไปถึงแนวทาง Two-pizza rule team
เน้นที่กระบวนการทำงานที่ Simplicity
นั่นคือ กระบวนการทำงานที่ช่วยเหลือให้คนทำงาน
สามารถทำงานได้ง่าย มิใช่ทำให้การทำงานยากขึ้น !!
โลกภายนอกเราควบคุมมันยาก
ส่วนโลกภายในองค์กรเราน่าจะควบคุมได้และควรมีประโยชน์ต่อคนทำงาน

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

หรือถ้าทดสอบผ่านหมดแล้ว
สามารถนำ code ชุดนี้ deploy ขึ้น production ได้ไหม ?
ถ้าตอบว่าไม่ได้ หรือต้องผ่านการ UAT หรือทดสอบในวันจันทร์ก่อน !!
คิดว่าเราน่าจะมีปัญหาเรื่องของ Locality and Simplicity

Focus, Flow, and Joy

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

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

Improvement of Daily Work

เป็นองค์กรและทีมที่มีการปรับปรุงการทำงานในทุกวันอย่างต่อเนื่อง
มันคือองค์กรแบบ Continuous Learning

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

หนักกว่านั้น มีหลาย ๆ  feature จำเป็นต้องทำงานกับหลาย ๆ ทีม
ส่งผลให้กว่าจะนัดคุยกัน
กว่าจะตกลงกัน
กว่าจะพัฒนา
กว่าจะทดสอบ
กว่าจะ deploy
ต้องใช้เวลานานมาก ๆ นี่คือปัญหาหรือไม่ ?
หรือมันกลับกลายเป็นเรื่องปกติขององค์กร ?
ดังนั้นต้องกลับไปเรื่องแรกคือ Locality and Simplicity
และเรื่อง Focus, Flow, and Joy

Psychological Safety

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

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

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

Customer Focus

เรื่องนี้คงไม่ต้องอธิบายแล้วนะ

ตอนนี้เปิดให้ pre-order กันแล้วที่ ITRevolution.com

และทาง InfoQ ก็ได้ตัดบางส่วนของหนังสือมาให้อ่านกัน

Reference Websites

• https://www.infoq.com/articles/unicorn-project

เมื่อ Technology Radar Volume 21 จากบริษัท ThoughtWorks ออกมา
ก็มีทั้งเทคนิค เครื่องมือและเทคโนโลยีต่าง ๆ ที่น่าสนใจออกมา
ดังนั้นเรามาดูกันว่าในครั้งนี้ มีอะไรที่น่าสนใจบ้าง ?
แยกออกเป็นหัวข้อหลักได้ดังนี้

• การใช้ function ต่าง ๆ จาก Cloud provider เยอะ ก็มีทั้งข้อดีและข้อเสีย จากครั้งที่ผ่านมาให้ระวังเรื่อง vendor lock-in
• เรื่องของกระบวนการส่งมอบ software (CI/CD) ทำงานแบบอัตโนมัติ ดังนั้นเรื่องของการป้องกันกระบวนการนี้จึงมีความสำคัญ ทั้ง security, dependency management และปรับการทำงานที่สำคัญ ๆ ให้เป็นแบบอัตโนมัติ
• ว่าด้วยเรื่องของ Machine Learning เราต้องเข้าใจการทำงาน ความเหมาะสมและข้อจำกัดต่าง ๆ 
• Software development เหมือนกันทีมกีฬา โดยที่เรื่องของ 10x engineers นั้นขอให้เลิกใช้หรือใช้อย่างระมัดระวัง แต่ให้เน้นไปที่ 10x teams มากกว่า นั่นคือการทำงานแบบ Cross functional

มาดูในเรื่องของความปลอดภัยและการป้องกันกระบวนการทำงาน

พบว่าในส่วนของเทคนิคนั้นมีเพียบเลย
ยกตัวอย่างเช่น

• Container security scanning ซึ่งทำงานอยู่ใน pipeline ของ CI/CD เลย
• Run cost as architecture fitness function (เป็นคำมาจาก Evolutionary architecture) เป็นขั้นตอนที่ช่วยทำให้รรู้ว่า cost ที่ใช้ไปมันคุ้มค่าหรือไม่ เนื่องจากการเปลี่ยนแปลงมันเกิดขึ้นได้ตลอดเวลา
• Dependency drift fitness function ทำการตรวจสอบและ tracking dependency ต่าง ๆ ที่ใช้งานกัน ว่าต้องทำการเปลี่ยนแปลงหรือไม่ ? เช่นมันเก่าแล้ว หรือ เป็นส่วนที่ส่งมอบล่าช้า หรือ มีปัญหาในการทำงาน ยกตัวอย่างเรื่องมือเช่น Dependabot เป็นต้น
• Security policy as  code นั่นคือการกำหนดนโยบายเรื่องความปลอดภัยด้วย code เลย เหมือนกับ pipeline as a code และ infrastructure as a code ทำให้เราสามารถเก็บไว้ใน version control, ทำการตรวจสอบได้อย่างอัตโนมัติ เมื่อทำการ deploy หรือ monitoring เป็นต้น ยกตัวอย่างเช่น Open Policy Agent (OPA) และ Istio เป็นต้น
• Sidecars for endpoint security ก็มาเช่นกัน ช่วยทำให้เราสามารถจัดการ component/service ได้ง่ายขึ้น

มาดูเครื่องมือที่น่าสนใจฝั่งการพัฒนาระบบงานบ้าง

มีหลายตัวแจ่มมาก ๆ เช่น

• Commitizen ช่วยเรื่องของการ commit ด้วย git
• Detekt คือ Static code analysis สำหรับภาษา Kotlin
• KotlinTest เป็นเครื่องมือสำหรับทดสอบระบบที่พัฒนาด้วยภาษา Kotlin ซึ่งสามารถทำ properties-based testing ได้ด้วย
• Jib สำหรับการสร้าง Docker image ของ Java application
• React styleguidist ใช้สำหรับเป็น development environment ของการสร้าง react component นั่นเอง ใช้ง่ายดี มีประโยชน์มาก ๆ
• Figma สายออกแบบไม่พลาดแน่นอน เพราะว่าออกแบบมาให้ทำงานร่วมกันได้ง่ายและสะดวกมากยิ่งขึ้น หลาย ๆ คนน่าจะย้ายมาใช้กันแล้ว ยิ่งสาย DesignOps ไม่น่าพลาด
• Docker notary สำหรับการ signed Docker Image ที่สร้างด้วย private key และการ hash ทำให้เราสามารถตรวจสอบ Docker image ได้เลยว่ามันสิ่งที่เราสร้างขึ้นมาหรือไม่ ?
• ส่วน Enzyme นั้น ที่ใช้ทดสอบระบบงานที่พัฒนาด้วย React แนะนำให้ไปใช้งาน React Testing Library แทนเลย  เนื่องจาก Enzyme ไม่ค่อยถูก maintain และ update แล้ว

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

มีโอกาสไปพูดและแนะนำเกี่ยวกับการเขียน code นิดหน่อย
การจะทำ slide ใน Keynote หรือ Powerpoint
มันก็จะดูน่าเบื่อแถมไม่ค่อยเหมาะสมเท่าไร
เนื่องจากต้องทำการเขียน code มากกว่า
ดังนั้นจึงคิดว่า 
ถ้าทำ slide บน editor ที่เขียน code นั่นคือ VS Code เลยน่าจะดีกว่า
ดังนั้นมาหาวิธีการทำหน่อย ว่าเป็นอย่างไร ?

ความต้องการไม่มีอะไรมาก คือ

• เขียน code ไป นำเสนอไปพร้อม ๆ กัน เป็น live code ไปเลย
• ไม่ต้องการลูกเล่นและ animation อะไรมากมาย
• แสดงรูปต่าง ๆ เพื่ออธิบายได้ code ได้

ดังนั้นเลยลองไปหา extension ของ VS Code ดู

พบว่ามีคนทำไว้ให้ด้วย สบายเลย ตัวที่เลือกนำมาลองใช้คือ Slides

สามารถสร้าง slide ง่าย ๆ ด้วยรูปแบบ Markdown
และตั้งชื่อไฟล์เรียงลำดับไปเลยเช่น 1,2,3,4,5 เป็นต้น
จากนั้นสามารถทำการ export เป็น pdf หรือรูปภาพใช้งานได้เลย

สามารถใช้งานได้เลย
โดยเข้าสู่ mode Presentation ด้วยการกดปุ่ม Ctrl Alt p (⌘ ⌥ p on Mac)
เพียงเท่านี้ก็สร้าง slide และการ live code ใน VS Code แบบง่าย ๆ ได้แล้ว

เท่าที่ใช้มา มันตอบความต้องการขั้นพื้นฐานได้เลย
ลองมาใช้งานกันครับ

ทำการสรุปจากการดู VDO เรื่อง Eighteen Years of Spring
ซึ่งพูดโดยคุณ Rod Johnson
เรียกได้ว่าเป็นผู้สร้าง Spring Framework นั่นเอง
ทำการอธิบายสิ่งที่สร้างและพัฒนาขึ้นมาว่า
เป็นแนวคิดและโครงสร้างอย่างไร
ตลอดจนการเปลี่ยนแปลงต่าง ๆ ที่ผ่านมา จนถึงคำแนะนำต่าง ๆ 
มาดูกันว่ามีอะไรที่น่าสนใจบ้าง

สิ่งแรกที่ยังจำได้คือ หนังสือเล่มแรก Expert One-on-One J2EE Design and Development

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

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

• Expert One-on-One J2EE Development without EJB
• Professional Java Development with the Spring Framework

แน่นอนว่า นี่คือจุดเริ่มต้นของ Spring Framework นั่นเอง (ถูกสร้างมาก่อนหน้านี้อยู่แล้ว คือ ปี 2001)

Make the right thing easy to do.
Don't constrain developers: empower them to do the right thing more efficiently.

เพื่อให้การพัฒนาระบบงานง่ายและชัดเจนต่อการนำมาใช้งาน

นั่นคือการช่วยลด effort ทั้ง cost และ time ของการพัฒนาได้
เนื่องจากลด code ต่าง ๆ ออกไปให้เหลือเฉพาะ code ที่ต้องพัฒนาระบบงานเท่านั้น
นี่คือเป้าหมายของ Spring framework
ส่งผลให้เป็น framework หลักของการพัฒนาระบบงานด้วยภาษา Java ในเวลาต่อมา

ทางทีม Spring core นั้นก็จะเน้นไปที่คุณภาพของงาน
มากกว่าที่จะขยายทีมเพื่อทำงานให้มากขึ้น
เนื่องจากการเพิ่มคนเข้ามา
อาจจะไม่ช่วยอะไรเท่าไร
แถมจะลดคุณภาพอีกด้วย

ส่วนเรื่องแนวคิดต่าง ๆ ในการสร้าง Spring framework นั้น
ก็มีการนำแนวคิดดี ๆ มาจาก framework อื่น ๆ เช่นกัน
ไม่ว่าจะเป็น Rails, PicoContainer และ DropWizard เป็นต้น
ที่สำคัญก็มีการ reference ไปยังเจ้าของแนวคิดนั้น ๆ ด้วยเสมอ

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

ดังนั้นเราต้องการแนวทางที่ช่วยให้พัฒนาและส่งมอบได้อย่างรวดเร็ว
หรือแบบค่อยเป็นค่อยไปแบบ feature by feature 
เป็นแนวทางที่น่าสนใจมาก
แนวคิดนั้นก็คือ Microservices
ซึ่งในส่วน Java ด้วย Spring framework ก็คือ Spring Boot นั่นเอง
ถึงแม้ว่า Spring นั้นจะไม่ได้เหมาะสมกับทุก ๆ งาน
แต่น่าจะเป็นตัวเลือกแรก ๆ ที่ต้องพิจารณากัน

ที่สำคัญในตอนนี้ทาง Spring แนะนำให้พิจารณาภาษา Kotlin
เพื่อนำมาพัฒนาระบบงานเช่นกัน
เทียบ Kotlin กับ Java เหมือนกับ Spring มาแทน J2EE นั่นเอง !!

Reference Website

• https://blog.atomist.com/eighteen-years-of-spring/

เพิ่งคุยเรื่องของการพัฒนา software กันไปว่า
มันมี waste อะไรบ้างที่มักจะเกิดขึ้นมา
แถมส่งผลมากมายต่อการพัฒนา
หนึ่งในนั้นคือ speed หรือความเร็วของการพัฒนา
เลยหยิบรายละเอียดมาจาก Lean for Software Development
มาสรุปไว้กันลืมในบางข้อ
มาเริ่มกันเลย

โดยที่ waste ประกอบไปด้วย 7 อย่างคือ

1. Partially done work
2. Extra features
3. Relearning
4. Handoffs
5. Delays
6. Task switching
7. Defects

มาดูเรื่องที่น่าสนใจในบางเรื่องกันนิดหน่อย

เรื่องที่ 1 Partially done work (In-process Inventory)

ในการพัฒนา software นั้น เราจะพบว่า
Code ที่พัฒนาขึ้นมานั้น 
ที่ทีมบอกว่าเสร็จ มันเสร็จจริง ๆ ไหม ?
ทำการ checkin ไปยัง version control ไหม ?
ทำการทดสอบไหม ?
ถูก integrate เข้ากับระบบจริง ๆ ไหม ?
ทำการ deploy จริง ๆ ไหม ?
ทำการส่งมอบไปถึงมือลูกค้าหรือผู้ใช้งานจริง ๆ ไหม ?
หรือต้องรอส่งเป็นชุดใหญ่ไฟกะพริบ เช่น เดือน หรือ หลายเดือน หรือ ปีละครั้ง

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

ตัวอย่างของ Partially done work ที่พบเจอบ่อย ๆ คือ code เช่น

• Code ที่ copy and paste มาใช้
• Code ที่ถูก comment ซึ่งไม่ได้ใช้งาน มีไว้ทำไม ?
• Code กับ เอกสารต่าง ๆ ไม่ตรงกัน
• Code ของนักพัฒนาแต่ละคนไม่ตรงกัน หนักกว่านั้น code ที่ขึ้น production ก็ code ที่พัฒนาไม่ตรงกัน
• Code ที่ไม่ทำการทดสอบ หรือ ทำการทดสอบเพียงบางส่วน เรามักจะเจอคือ แก้ไข 1 bug ได้กลับมาอีก 5 bug เป็นต้น
• Code ที่ไม่สามารถอธิบายได้ หรือ ไม่มีเอกสารอธิบายการทำงาน ทำให้การดูแลรักษาลำบากอย่างมาก
• Code ที่ไม่ถูก deploy ไปยัง production ส่งผลให้เราต้องทำการ deploy แบบ big bang ซึ่งส่งผลให้เกิดปัญหามากมายตามมา

เรื่องที่ 2 Extra features (Overproduction)

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

• Code ต้องถูก track ว่าถูกใช้หรือไม่ และมีการเปลี่ยนแปลงอย่างไร
• Code ต้องถูก compile
• Code จำเป็นต้องใช้งาน dependency/library ต่าง ๆ ดังนั้นต้องไป download มาอีก
• Code ต้องถูก integrate เข้ากับส่วนต่าง ๆ
• Code ต้องถูกทดสอบ
• Code ต้องดูแลรักษาได้ง่าย
• Code จะมีความซับซ้อนขึ้นเรื่อย ๆ
• Code ยิ่งเยอะก็ยิ่งเพิ่มโอกาสผิดพลาด
• Code อาจจะไม่ถูกใช้งานอีก

ประเด็นหลัก ๆ คือ เราจะแก้ไขปัญหาของงานต่าง ๆ เหล่านี้ไปได้อย่างไร ?
แนวทางที่น่าสนใจคือ short feedback loop
ทำการพัฒนาเฉพาะ feature ที่มีความสำคัญ
จากนั้นทำการ demo บ่อย ๆ
ยังไม่พอ ต้องทำการ deploy ไปยัง production บ่อย ๆ 
เพื่อให้ถึงมือผู้ใช้งานบ่อยๆ
จะช่วยลดปัญหา เวลาและค่าใช้จ่าย ๆ จาก extra work หรืองานงอกต่าง ๆ 

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

นี่มันแนวคิดของ YAGNI (You Ain't Gonna Need It) นี่ !!
นั่นคือการเพิ่ม feature/code ต่าง ๆ เข้าไป
เท่าที่ผู้ใช้งานต้องการหรือใช้งาน

เรื่องที่ 3 Hand offs (Transportation)

นั่นคือการส่งงานจาก role หนึ่งไปอีก role หนึ่ง
ในการพัฒนาระบบงานมักจะมีการส่งงานแบบนี้เยอะมาก เช่น
Business analyst -> Analyst -> Designer -> Programmer/Developer -> Tester/QA -> Operation

ในแต่ละ role ก็มีหน้าที่และบทบาทต่างกันไป
แต่ปัญหาที่ตามมาจากการทำงานในรูปแบบนี้คือ
ปัญหาในการส่งต่อความรู้ (Transfer knowledge)
พบว่าความรู้ความเข้าใจจะลดลงไปอย่างมาก เมื่อส่งต่อเยอะ ๆ ดังนี้

• ส่งไป 1 ต่อ ความรู้จะลดลงไปเหลือเพียง 50%
• ส่งไป 2 ต่อ ความรู้จะลดลงไปเหลือเพียง 25%
• ส่งไป 3 ต่อ ความรู้จะลดลงไปเหลือเพียง 12%
• ส่งไป 4 ต่อ ความรู้จะลดลงไปเหลือเพียง 6%
• ส่งไป 5 ต่อ ความรู้จะลดลงไปเหลือเพียง 3%

ดังนั้น เรายังทำงานในรูปแบบนี้อีกหรือ ?

ปัญหานี้ต้องรีบทำการแก้ไข
ยกตัวอย่างเช่น

• ลดจากการส่งงานเป็นทอด ๆ แบบนี้ลง กลับมาทำงานเป็นทีมดีกว่า (Cross-functional team)
• เปลี่ยนการติดต่อสื่อสารให้มีประสิทธิภาพมากยิ่งขึ้น เช่น face-to-face, vdo เป็นต้น ส่วนการติดต่อสื่อสารด้วยตัวอักษรก็ลดลงไป
• เอกสารก็ทำเท่าที่จำเป็นต่อการทำงานร่วมกัน ยกตัวอย่างเช่นการเขียนใน Wiki เป็นต้น
• ต้องทำให้เกิด fast feedback หรือ ให้มีขั้นตอนการทำงานที่สั้น ๆ ไม่เทอะทะ

เรื่องที่ 4 Task Switching (Motion)

ในการทำงานนั้น เราจะเข้าใจกันว่า
ถ้าคน ๆ หนึ่งทำงานจนเข้าสู่สถานนะไหลลื่นหรือ flow แล้ว
จะช่วยทำให้คนนั้นมี productivity ที่สูงมาก

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

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

ช่วงว่าง ๆ เห็นบทความเรื่อง Practical Persistence in Go: Organising Database Access
ไม่แน่ใจว่าใคร share มา แต่เมื่อได้อ่านและลองทำตามแล้วพบว่า
มีสิ่งที่น่าสนใจและน่าเรียนรู้มาก ๆ
จึงทำการแปลและสรุปไว้อ่านนิดหน่อย
มาเริ่มกันเลย

เริ่มจากที่มาของบทความคือ

มีการถามใน Reddit ว่า
ในการจัดการข้อมูลใน database ของระบบ web application 
ที่พัฒนาด้วยภาษา Go นั้น
มีแนวปฏิบัติที่ดีหรือ best practice อะไรและอย่างไรบ้าง ?    
ซึ่งในการพุดคุยนี้ ก็มีคำตอบที่น่าสนใจจำนวนมาก
ยกตัวอย่างเช่น

• ใช้งาน dependency injection
• ใช้งานง่าย ๆ ผ่าน Global variable
• ใช้ connection pool โดยใช้งานผ่าน pointer ของ Context

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

ดังนั้นมาดูว่าแต่ละวิธีเป็นอย่างไร
มีข้อดีและข้อเสียอย่างไร ตลอดจน code ตัวอย่างอีกด้วย

ในบทความประกอบไปด้วย 4 วิธีดังนี้

• Global variable
• Dependency Injection
• Interface
• Request-scopes context

วิธีที่ 1 Global variable

เป็นวิธีที่ง่ายและตรงไปตรงมาสุด ๆ
นั่นคือการจัดเก็บการเชื่อมต่อไปยัง database ไว้ใน Global variable
ซึ่ง Global variable นี้สามารถใช้งานได้จากตรงส่วนไหนของ code ได้เลย
นั่นคือจะมีส่วนการสร้างการเชื่อมต่อ database ไว้ที่เดียว
ส่วนมากจะทำการสร้างไว้ตอน program เริ่มทำงาน
จากนั้นสามารถใช้งานได้ทั้ง production code และ test code เลย

มาดูตัวอย่าง code ที่ใช้งาน Global variable
ทำการสร้าง Global variable ชื่อ db ไว้ใน package models ดังนี้

ตัวแปร db นี้สามารถถูกใช้จาก package ต่าง ๆ ได้เลย ดังตัวอย่าง

โดยที่วิธีการนี้มีมีข้อดีดังนี้

• ส่วนของการจัดการกับ database อยู่ที่เดียว นั่นคือจัดการได้ง่าย
• เหมาะกับระบบงานที่มีขนาดเล็ก เนื่องจากง่ายต่อการดูว่า Global variable ถูกใช้งานอย่างไร แต่ถ้าใหญ่ขึ้นการดูแลจะยากขึ้น
• ในการทดสอบนั้น เราจะใช้งาน database จริง ๆ เหมือนกับ production code ไม่ทำการ mock database

วิธีที่ 2 Dependency Injection

วิธีการนี้ คือ ทำการส่ง pointer ของการเชื่อมต่อ database ไปยัง HTTP handler
จากนั้นก็ถูกส่งไปยัง business logic อีกต่อหนึ่ง
ซึ่งค่าที่ส่งเข้ามาอาจจะเป็นสิ่งอื่น ๆ ที่ต้องใช้งานอีกก็ได้
ยกตัวอย่างเช่น logger และ caching เป็นต้น

ยกตัวอย่าง code ของสิ่งที่จะส่งเข้ามา
สามารถเขียน code ในรูปแบบของ struct ได้ดังนี้

จากนั้นทำการสร้างสิ่งต่าง ๆ ที่ struct ตัวนี้ต้องการทั้งหมด
ในตัวอย่างคือ การเชื่อมต่อไปยัง database
จากนั้นทำการสร้าง struct และส่ง struct เข้าไปยัง HTTP handler
ซึ่งการส่งค่าในภาษา Go นั้น ทำได้ 2 แบบคือ
receiver และ closure (เป็นการส่งผ่าน parameter) ดังนี้

จากวิธีการนี้จะเห็นได้ว่า
เราสามารถกำหนดได้ว่า ในแต่ละ HTTP handler ต้องการใช้อะไรบ้าง
ก็ส่งไปเพียงเท่านั้น ไม่สิ้นเปลือง
ส่วนการทดสอบนั้น เราจะใช้งาน database จริง ๆ เหมือนกับ production code
ไม่ทำการ mock database ได้
เนื่องจากต้องทำการสร้าง database ขึ้นมาจริง ๆ เท่านั้น
แต่ fake ได้นะ คือการจำลอง database ขึ้นมา

วิธีที่ 3 Interface

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

มาดูตัวอย่าง code กัน

เริ่มด้วยการสร้าง interface ชื่อว่า Datastore ขึ้นมา
ซึ่งมี function 1 ตัวคือ allBooks()
สำหรับดึงข้อมูลของหนังสือทั้งหมดจาก database ออกมา

ในส่วนของ books.go นั้น
จะเห็นได้ว่ามี function ที่มี signature เดียวกับ interface Datastore
(มันคือการ implementation นั่นเอง)
ตรงนี้อาจจะทำให้มือใหม่งง ๆ กันสักหน่อย

ช่วยทำให้เราสามารถเขียนชุดการทดสอบแบบ Unit test ได้ง่าย ๆ ดังนี้

วิธีที่ 4 Request-scoped context

วิธีการนี้จะทำการส่งและเก็บการเชื่อมต่อกับ database ผ่าน context package นั่นเอง
โดยที่เจ้าของ blog ต้นทางบอกว่า ไม่ชอบวิธีการนี้
เพราะว่ามันดูยุ่งยากและวุ่นวายเกินไป

ในเอกสารของ context package นั้น อธิบายไว้ว่า

Use context Values only for request-scoped data that transits processes and APIs,
not for passing optional parameters to functions.

นั่นคือส่งค่าเฉพาะสิ่งที่จะใช้ในการทำงานของ API เท่านั้น
ส่วนค่าอื่น ๆ ที่ส่งไปยัง function อื่น ๆ อย่างส่งมาเลย

มาดูตัวอย่างกัน ซึ่งจะส่งข้อมูลของ struct ContextInjector ผ่าน context package

ตัวอย่างของ code อยู่ใน GitHub::Up1

จากการแบ่งปันและพูดคุยเรื่องของ Event-Driven Architecture ไปนิดหน่อย 3 วัน
พบว่าแนวคิดนี้มันมีเพื่อน ๆ ตามมาเยอะมาก
ไม่ว่าจะเป็น Command, Event, Event sourcing, Aggregate, Replay, DDD (Domain-Driven Design)
และอื่น ๆ อีกมากมาย มันจะเยอะไปไหนนะ !!
(ก่อนจะใช้งานอะไร ก็ควรรู้และเข้าใจที่ไปที่มาของมันหน่อยสิ)
ก็เลยมาสรุปไว้นิดหน่อย
ทั้งความรู้พื้นฐาน และ รูปแบบของการนำไปใช้งาน

Event-Driven Architecture (EDA)

ไม่ได้เป็นแนวคิดใหม่อะไรเลย ซึ่งจะพูดถึง

• Produce event
• Capture event
• Process event
• Persist event

โดยใน Event-Driven Architecture

นั้นจะแยก object ออกมา 2 ตัวหลักคือ

1. Command
2. Event

แล้ว object ที่สองชนิดต่างกันอย่างไร ?

Command หรือ คำสั่ง

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

ส่วนของ Event หรือ เหตุการณ์

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

ส่วนรูปแบบของ Event-Driven Architecture หลัก ๆ 

ประกอบไปด้วย

• Notification pattern
• Event-Carried State Transfer (ECST)
• Event Sourcing (ES)
• CQRS (Command Query Responsibility Segregation)

อธิบายเพิ่มเติมนิดหน่อย

Notification pattern

เป็นรูปแบบที่ถูกนำมาใช้งานมากที่สุด เพราะว่า เรียบง่าย และ เป็นธรรมชาติ
นั่นคือ ระบบการทำงานหลัก หลังจากที่ทำงานเสร็จจาก command ต่าง ๆ แล้ว
จะทำการโยน event ต่าง ๆ ออกมา
(เก็บไว้สักที่เช่น Messaging หรือ Event bus)
จากนั้นถ้ามีส่วนงานใดสนใจ event นี้
ก็ทำการรับค่าไป หรือ ทำการ subscribe (ปักตะไคร้ซะ)

ยังไม่พอนะ
ข้อมูลใน event รูปแบบนี้ มักจะมีแต่ id หรือ reference id ของข้อมูลเท่านั้น
ถ้าต้องการข้อมูลเพิ่มเติม ต้องทำ id นี้ไปดึงข้อมูลจากระบบหลักอีกครั้ง
ส่งผลให้ข้อมูลนั้นเป็นค่าล่าสุดเสมอ
(มีคุณสมบัติ Consistency หรือความถูกต้องแน่นอน)
แต่ข้อเสียคือ แต่ละส่วนการทำงานยังผูกมัดกันอยู่ !!
แสดงดังรูป

ดังนั้นแก้ไขปัญหาใน pattern แรกด้วยวิธี Event-Carried State Transfer (ECST)

นั่นคือในแต่ละ event จะมีข้อมูลและรายละเอียดที่ฝั่ง subscribe ใช้งานครบ
แต่ระวังด้วยว่า
ต้องมีข้อมูลเท่าที่จะใช้งานเท่านั้น อะไรที่ไม่ใช้งานก็ไม่ต้องส่งมา ไม่ต้องเผื่อ !!
ทำให้ไม่ต้องไปดึงข้อมูลอีกรอบ
ข้อดีคือ แต่ละส่วนงานตัดขาดออกจากกัน มีความเป็นอิสระ
ได้เรื่องของ availability มาเพิ่มอีกด้วย
แต่ปัญหาที่ได้รับกลับมาคือ
เรื่องของความถูกต้องของข้อมูลนั่นเอง (Eventully Consistency)
แสดงดังรูป

Reference Websites

• https://en.wikipedia.org/wiki/Event-driven_architecture
• https://medium.com/@kasunranasinghe303/four-event-driven-patterns-4b1cad5ac5e3

อ่านหนังสือเจอเรื่องของ Testing in Production environment (TiP)
สำหรับการพัฒนา software
หลาย ๆ คนอาจจะมองว่ามันเป็นเรื่องตลก
ใครกันจะกล้าทำกันแบบนั้น
นี่มัน Production environment เชียวนะ !!
มันไม่น่าจะเป็นสิ่งที่ถูกต้อง
หรือคนจริงต้องทดสอบบน production กัน

ในการพัฒนา software นั้น

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

สิ่งที่น่าสนใจคือ 

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

ยังไม่พอ เนื่องจากการทดสอบระบบงานมีหลายกลุ่ม

ดังนั้นเราจึงมี environment ที่หลากหลาย  ยกตัวอย่างเช่น

• Dev สำหรับทีมพัฒนา
• QA/Test สำหรับทีม QA และ Tester
• CI สำหรับระบบ Continuous Integration ซึ่งทำงานแบบอัตโนมัติ
• Pre-prod สำหรับก่อนขึ้น production
• Production นี่แหละของจริง

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

ถ้าเป็นแบบนี้ก็มี Production environment อย่างเดียวก็พอดีไหม ?

ว่าด้วยเรื่องของ Testing in Production นั้น

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

ลองเทียบกับระบบงานของเราสิว่า 
ผลที่ออกมามันจะเป็นอย่างไร ?
ไม่น่าจะออกมาดีใช่ไหม ?

แต่ทำไมถึงมีการพูดถึงเรื่อง Testing in Production กันเยอะ

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

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

แต่การนำแนวคิดนี้มาใช้ จำเป็นต้องมีกระบวนการทำงานเช่นกัน

ไม่ใช่จะไป deploy และ ทดสอบบน production กันอย่างเดียว
ยกตัวอย่างเช่น

• A/B testing
• Beta testing
• Monitoring as testing

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

อีกอย่างที่สำคัญมาก ๆ คือ Automated feedback จาก production

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

จะเห็นได้ว่าเรื่องของ Testing in Production นั้น มันไม่ใช่แค่แนวคิด

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

สวัสดี !!!

ช่วงวันหยุดที่ผ่านมา มีเวลานั่งอ่านหนังสือ Real-World Functional Programming
ลองอ่านไป ทำตามไป รู้เรื่องบ้างไม่รู้เรื่องบ้าง
จึงบันทึกการอ่านไว้นิดหน่อย
มาเริ่มที่บทแรกในเรื่อง Thinking differently about problems
หรือแนวคิดสำหรับปัญหาหนึ่ง ๆ ที่ต่างออกไป
มาเริ่มกันเลย

ในปัญหาหนึ่งนั้น ๆ เรามักจะมองมันในรูปแบบเดิม ๆ ที่เราเข้าใจ

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

ในหนังสืออธิบายไว้ว่า Functional programing

เป็นอีกหนึ่งรูปแบบที่เกิดขึ้นมานานแล้ว เกิดก่อน computer อีก !!
โดยที่ตัวภาษานั้นจะสั้น กระทัดรัด ชัดเจน ซึ่งมันดีมาก
แต่กลับไม่ได้รับความนิยม หรือ ถูกปฏิเสธจากกลุ่มนักพัฒนา จนถึงปัจจุบัน

แล้วทำไมเราถึงกลับมาพูดถึง Functional programing กัน ?

เนื่องจากในปัจจุบันมีการเปลี่ยนแปลงมากมายนั่นเอง
ยกตัวอย่างเช่น จำนวนข้อมูลที่มีขนาดใหญ่มาก ๆ  (Big Data)
ดังนั้นเราต้องการแนวทางการเขียน program ที่สามารถจัดการ ประมวลผล
และ รองรับการขยายตัวได้ง่ายและเหมาะสม
ต้องการการเขียน program ที่ง่ายต่อการทดสอบ
ต้องการการเขียน program ที่อธิบาย logic หรือขั้นตอนการทำงานที่ชัดเจน
นั่นช่วยทำให้เราอ่านเข้าใจได้ง่ายขึ้น
และเข้าใจเหตุผลการทำงานของ program
ซึ่งแนวทางหนึ่งที่ตอบโจทย์เหล่านี้คือ Functional programing

ผลที่เห็นได้อย่างชัดเจนของแนวทางนี้คือ

ภาษาโปรแกรมต่าง ๆ ที่ได้รับความนิยมในท้องตลาด
ไม่ว่าจะเป็น .Net (C#) และ Java ต่างก็ได้เพิ่มความสามารถเชิง functional
เข้ามาด้วย ยกตัวอย่างเช่น

• Generic ใน C# 2.0
• Anonymous method ใน C# 2.0
• Lambda expression ใน C# 3.0
• LINQ นี่ก็สร้างในเชิง declarative และ functional กันเลย

เมื่อแต่ละภาษาโปรแกรมเริ่มนำความสามารถของ Functional programming เข้ามาใช้
หรือบางภาษาถูกสร้างมาตามแนวคิด Functional programming เลยเช่น F#
มันทำให้หลาย ๆ คนเริ่มกลับไปให้ความสนใจต่อ
ที่มาที่ไปของ Functional programming มากขึ้น

สิ่งที่ผมสนใจในหนังสือเล่มนี้คือ

เข้าบอกว่า Functional programming นั้น
จะช่วยเพิ่ม productivity ของการพัฒนาระบบงาน
นั่นคือ มันกระชับ อ่านเข้าใจได้ง่าย
แต่ก็ยังยากต่อการนำไปใช้งานจริง ๆ !!
ดูมันขัดแย้งกันพอสมควร 

รูปแบบของ Functional programming ที่ช่วยนักพัฒนาและทีมคือ 

มีการเขียน program ในเชิง Declarative (Declarative programming style)
ในหัวก็คิดว่า มันคืออะไรวะ ?

เมื่อเราเขียน program นั้น
ปกติเราก็ต้องเขียนด้วยชุดคำสั่งที่ computer เข้าใจ
เพื่อแปลงชุดคำสั่งเหล่านั้นไปทำงาน นี่คือความรู้พื้นฐาน

โดยรูปแบบแรกที่เรามักจะเจอกันมาก่อนคือ Imperative style
ซึ่งจะมีชุดคำสั่งต่าง ๆ เตรียมไว้มากมาย
รวมทั้งเราสามารถเพิ่มชุดคำสั่งใหม่ ๆ เข้าไปได้ด้วย
จะทำการอธิบายขั้นตอนการทำงานไปเรื่อย ๆ
แต่เมื่อ program ใหญ่ขึ้น
ชุดคำสั่งก็มีมากขึ้น
การใช้งาน การจัดการและดูแลก็ยากขึ้นตามไปด้วย
ทำให้เกิดรูปแบบการเขียน program ใหม่ ๆ
หนึ่งในนั้นคือ Object-Oriented Programming (OOP)

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

แล้ว Functional programming ละ เป็นแนวคิดเพื่อแก้ไขปัญหาอะไร ?

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

ต้องพยายาม เขียนเพื่ออธิบายว่า มันคืออะไร ทำงานอะไร (What)

มากกว่าทำงานอย่างไร (How)

อีกเรื่องที่  Functional programming มีมาให้เลยคือ เรื่องของConcurrency-friendly

นั่นคือเราสามารถปรับเปลี่ยนการทำงาน จาก sequential
ไปยัง Concurrency และ parallel ได้ง่าย
รวมทั้งการประมาณผลบน CPU แบบ multi-core
และจากแนวคิดนี้จะไม่สามารถแก้ไขสถานะของ program ได้ (immutablity)
ทำให้ไม่เกิดปัญหาเรื่อง race condition และ dead lock !!! อีกด้วย

แต่อย่างเพิ่งไปเชื่อ !!

ว่าแล้วลองเป็นเขียน code ด้วยภาษา C# และ F# ก่อนละ !!
ผมก็ไม่เคยคิดและเขียนแนวนี้เหมือนกัน
ไว้ลองเขียนแล้วจะเอามา share ต่อไป

เห็น timeline ของคุณ Greg Young ทำการ tweet รูปภาพ
เพื่ออธิบายเรื่องของ Eventual Consistency
คิดว่าชันเจนดี ทั้งหมายถึงอะไรและเป็นอย่างไร
จึงนำมาฝาก

คำถามคือ คิดเห็นอย่างไรกับรูปชุดนี้กันบ้าง ?

หลวมตัวลงสมัครวิ่งงานตะนาวศรีเทรลที่จังหวัดราชบุรี
ระยะที่ลง 73 กิโลเมตร (TAB = Tanaosri Along the Border)
เขาบอกกันว่าแต่ก่อนมันคือ boss ใหญ่ของเขาตะวันตก
แต่ปีนี้เพิ่มระยะ 110 กิโลเมตรขึ้นมา
ดังนั้นระยะ 73 กิโลเมตรจึงกลายเป็นรอง boss ไป
ตรงนี้มารู้ก่อนจะวิ่งนั่นแหละ !!

ก่อนวิ่งมาดูแผนที่วิ่งของ TAB กันหน่อย

ส่วนความชันสะสมก็แค่นี้ !!!

มาเริ่มวิ่งกันดีกว่า

เวลาวิ่งดีมาก ๆ เริ่มวิ่งกันตอนสามทุ่มในวันเสาร์และไปจบในวันอาทิตย์เวลา 17.30 น.
อุณหภูมิตรงจุดปล่อยตัวก็ 17-19 องศาเซลเซียส !!
(ทุก ๆ 100 เมตรจะเย็นลง 1 องศาเซลเซียส )
ปีนี้โชคดีที่ฝนไม่ตก ทำให้ทางไม่ลื่น
แต่สิ่งที่ได้มาคือ พื้นแห้งจนลื่น
นี่ข่าวดีใช่ไหม
คนวิ่งทั้งหมด 600 กว่าคน !!

ก่อนวิ่งมาดูจุด Cut off กันหน่อย

ซึ่งมีอยู่ 4 จุดคือ

1. A7 ต้องถึงก่อน 8 โมงเช้า
2. A8 ต้องถึงก่อนเที่ยง
3. COT ต้องถึงก่อนบ่ายสามครึ่ง
4. FINISH ต้องถึงเส้นชัยก่อน 17.30 น.

ความสนุกของการวิ่งเริ่มตั้งแต่ช่วงแรกคือ ไป A1 (12 กิโลเมตร)

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

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

เป้าหมายต่อไปคือ A5 (11 กิโลเมตร)

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

แต่สิ่งที่ประหลาดใจมาก ๆ คือ
ที่ A5 คน DNF หรือออกจากการแข่งขันเยอะเลย
(มีรถรอรับเลย แถมมีแจ้งด้วยว่าใครจะ DNF ขึ้นรถเลย)
ทั้งอากาศที่หนาวลงมาก
ทั้งมีอาการบาดเจ็บ
ทั้งกลับตามเพื่อน
ทั้งอุปกรณ์วิ่งตอนกลางคืนไม่ครบ เช่น ลืมเอาถ่ายไฟฉายมา

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

ออกเดินทางไปเขากระโจม A6 ขึ้นแบบไม่รู้จบ (13 กิโลเมตร)

ออกจาก A5 ก็วิ่งลงไปตามถนนประมาณ 2 กิโลเมตร จากนั้นก็ขึ้นเขา
ซึ่งของจริงมันเริ่มตรงนี้นี่เอง
ทางขึ้นเขากระโจม สนุก โหดดีมาก ๆ 
เป็นถนนดินลูกรัง ดินแดง ฝุ่นเพียบ
ขึ้นและขึ้นและขึ้นและขึ้น ไปเรื่อย ๆ
ช่วงแรก ๆ พอวิ่งได้ ช่วงหลัง ๆ เดินกระจาย
เส้นทางไม่รู้ว่าเป็นอย่างไร เพราะว่า focus ไปแต่ที่ถนน 
เพราะว่ามืดมาก ต้องเล็งตามไฟฉาย
ตอนนี้ขาเริ่มตึง ๆ กันเป็นแถว รวมผมด้วย แต่ก็พอไปได้

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

ในช่วงขึ้นเขากระโจม เห็นดาวบนท้องฟ้าสวยมาก ๆ
แต่พี่ ๆ เพื่อน ๆ ที่วิ่งมาด้วยกันบอกว่า
เดี๋ยวเราต้องขึ้นไปถึงดาวตรงนั้นละนะ !!
ดังนั้นก้มหน้าดันขึ้นไปต่อ ...

ดันไปเรื่อย ๆ เริ่มเจอนักวิ่งลงมา ก็เลยรีบดันขึ้นไป
พอถึงยอดเขากระโจม ลมแรงมาก รับสติกเกอร์ เติมน้ำ เติมพลังต่อ
แถมมีชาวบ้านมาขายของกินด้วย เลยจัดมาม่าไป 1 ถ้วย 

พอกินเสร็จเท่านั้นแหละ งานเข้าเลย
ท้องไส้ปั่นป่วน !!
เลยต้องแวะเข้าห้องน้ำที่ยอดเขากระโจม ทำให้เสียเวลาตรงนี้ไปนานเลย
ถ้าจำไม่ผิดตรงนี้ใช้เวลานานไป
จะเช้าแล้วน่าจะตีห้ากว่าได้ !!
เหลือระยะประมาณอีก 10 กิโลเมตรกว่าจะถึงจุด cut off แรกเวลา 8 โมงเช้า
ดังนั้นรีบดีกว่า !!

วิ่งหนี cut off แบบไม่คิดชีวิต ไปที่ A7  (10 กิโลเมตร)

ความสนุกมันอยู่ตรงนี้ หลังจากถ่ายท้องเรียบร้อย
เติมพลังงาน เปลี่ยนถ่านไฟฉายเรียบร้อย
ก็รีบลงจากเขากระโจม
ดูเวลาแล้วเหลือเวลาไม่เยอะเลย
มองไปบนท้องฟ้า ฟ้าเริ่มสว่างแล้ว
ไปได้สักกิโลเมตร มองเห็นทางได้อย่างชัดเจน
ไม่น่าเชื่อว่าจะขึ้นกันมาได้
เก็บไฟฉาย เก็บของ จากนั้นดูเวลา ได้เวลาต้องวิ่งแล้ว
เพราะว่า เหลือระยะทางอีกไกลเลย
ก็วิ่ง jog และเดินไปเรื่อย ๆ จนไปถึงถนนคอนกรีตเข้าหมู่บ้าน
เป็นทางลงยาว ๆ ระยะทางประมาณ 4 กิโลเมตร
ดูเวลาแล้ว ต้องวิ่งเร็ว ๆ กันแล้ว
ก็จัดเลยประมาณ pace 6-7 กันไป
ตอนวิ่งลงก็เจาคนเดินสวนขึ้นมา ให้กำลังใจกันไป
(คิดในใจลงแล้วก็ต้องขึ้นนี่หว่า !! ซวยละ)

พอมาถึง A7 ทางทีมงานบอกว่าเหลือเวลา cut off อีก 30 นาที
ให้รีบเติมพลัง เติมน้ำ แล้วรีบออกไป เพราะว่า sweeper เตรียมตัวแล้ว !!
งานเข้าเลยต้องรีบแล้วเรา ชิวมานานเกินไป
ช่วงนี้ได้รับสายรัดข้อมือ DIE

ใน A7 ไม่มีโอวันติน ข้าวต้มรอคิวนาน เสียเวลามากไป
เลยจัดขนมปังราดนมไป 3 ชุด ตามด้วยน้ำร้อน
จากนั้นเติมน้ำ นวดขาแล้วรีบออกไปเลย
ตอนนี้คิดอย่างเดียวคือ หนี cut off ให้เยอะกว่านี้

ออกเดินทางไป A7 เขาแหลมเฟี้ยวและบ้านกี้ (13 กิโลเมตร)

ตอนที่ออกมาจาก A7 มีเวลาเหลือแค่ 20 นาที
ดังนั้นจึงรีบเดินและ jog ขึ้นเขาประมาณ 4 กิโลเมตร
จากที่ลงมาเร็ว ขึ้นก็เร็วเช่นกัน
ตรงนี้ขาขึ้นใช้เวลาไป 40 นาที
หัวใจเต้นแรงส์มาก ๆ
แต่ต้องทำเวลาให้ดีขึ้น ช่วงนี้แซงแหลก !!

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

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

ปีเขาแหลมสูง ๆ ชัน ลงเขาแบบเรียงคิวยาวเพื่อไป COT ต้องถึงก่อน 15.30 น. (8 กิโลเมตร)

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

แต่ที่มันยากคือ ตอนลงมากกว่า
เพราะว่า เริ่มเจอคนที่ลงแข่งระยะ 30 กลุ่มหลัง ๆ 
ที่สำคัญคือ ทางลงเพื่อไป COT มันชันมาก ๆ และเป็น single track 
พลาดพลั้งไปอาจจะตกเขาได้
ทำให้กลุ่มที่มาด้วยกันยืนรอวนไป
บางช่วงกิโลเมตรโดนไป 32 นาที (จะรอด cut off เวลา 15.30 น. ไหม )

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

ปล. ผ่านตรงนี้ไป 100 เมตร จะมีน้ำให้เติม
แต่ว่าช่วงที่ผมผ่าน หมด นะ 
ดังนั้นถ้าใครเตรียมน้ำมาไม่พอจาก A7 มีหวังพังแน่ ๆ
แต่ข่าวดีคือ ไปอีกสัก 1-2 กิโลเมตร 
พี่ ๆ เจ้าหน้าที่ป่าไม้หรือทหารทำการกรองน้ำไว้ให้เพียบเลย แจ่มมาก ๆ

มาถึงตรงนี้ก็ล้างหน้าล้างตา เพื่อขึ้นเขาลูกสุดท้ายคือ เขาเขียว และเข้าสู่เส้นชัย (7 กิโลเมตร)

เขาเขียวไม่ชันเท่าเขาแหลม แต่ก็ไม่ธรรมดา
เพราะว่าโดนนวดมาตลอด 60 กว่ากิโลเมตรแล้ว !!
ขาก็เริ่มตึง ๆ ต้องหยุดนวดและฉีดสเปร์เรื่อย ๆ

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

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

บทสรุป
ใช้เวลาไป 19.18 ชั่วโมง
ได้อันดับที่ 138 ของผู้ชาย รวมน่าจะ 160 มั้ง
ไว้ไปแก้มือใหม่ปีหน้า !!

จากหัวข้อแรกในงาน Code Mania 1010 :: All about passion
ช่วง keynote speaker นั้น
พูดในหัวข้อ Toward Virtual People: A Case Study on Fake Obama
เป็นการพูดถึงโลกและเทคโนโลยีมีการปรับปรุงและเปลี่ยนไปอย่างมาก
ยิ่งในโลกของ AI (Artificial intelligence), Computer vision และ ML (Machine Learning)
แน่นอนย่อมมันทั้งข้อดีและข้อเสีย

โดยเรื่องนี้ผมเคยดูและฟังมาน่าจะ 2 ครั้งแล้ว (ยังชอบเสมอ)

สามารถดูผ่าน TED :: Fake videos of real people -- and how to spot them

ส่วนตัวอย่างของ Fake Obama ก็จาก BBC News ได้เลย ชัดมาก ๆ

ใน VDO :: Fake Obama created using AI video tool - BBC News

แต่สิ่งที่ผมสนใจมาก ๆ คือ อนาคตของงานและการวิจัย

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

• การเปลี่ยนปากของผู้พูดใน VDO/หนัง ให้เป็นไปตามภาษาของแต่ละประเทศ
• การสร้าง VDO ต่าง ๆ จากรูปภาพ
• การลองเสื้อผ้าแบบ reality มากขึ้น

อีกอย่างที่ผู้พูดอยากให้มีเยอะ ๆ ในเมืองไทย คือ

เรื่องของความรู้ความเข้าใจเกี่ยวกับ Computer Vision
นั่นคือ การสนใจในปัญหาเกี่ยวกับการมองเห็นของ computer
แน่นอนว่า ปัญหาหลัก ๆ คือ
การสอนให้ computer เข้าใจการมองเห็นตามมุมมองของมนุษย์ (Machine Learning)
เนื่องจากปัญหานี้นั้น
ทาง Computer Vision นั้นยังเหมือนเด็ก
นั่นคือ ยังไม่มีความรู้และเข้าใจเหมือนมนุษย์
จึงทำให้ผลการทำงานผิดพลาดบ่อยมาก ๆ (Overfitting problem)

เรื่องของ Computer Vision มีเยอะมาก ๆ 

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

• Image recognition
• Image segmentation
• Image captioning
• 3D understanding คือการทำความเข้าใจหรือรู้จักในมุมมองต่าง ๆ

Computer จะเก่งมาก ๆ 
แต่ปัญหาใน Computer Vision ก็ยังกว้างและมีปัญหามากมาย
นั่นคือ  Teach computer to imagine
จะสอนให้ computer สามารถจินตนาการได้อย่างไร ?

ทั้งเรื่องของ Image generation
ทั้งเรื่องของ Music generation
ทั้งเรื่องของ Image inpainting (เพิ่มเติมส่วนที่ขาดหายไป)
ทั้งเรื่องของ Style transfer 
ทั้งเรื่องของ Image translation และอื่น ๆ อีกมากมาย

เราจำเป็นต้องสอน computer เพื่อให้รู้และเข้าใจ

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

สิ่งที่เป็นปัญหาต่อมาของ Computer Vision คือ

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

ใน self-driving car
ถ้าทำการหลอกที่ป้ายความเร็ว ให้ขับเร็วได้ อาจจะก่อให้เกิดอันตรายได้

ในเรื่องของการ scan หน้า
มีการสร้างแว่นพิเศษสำหรับหลอกว่าเป็นคนอื่นได้อีกด้วย

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

จากงาน Code Mania 1010 :: All about passion
ผมเข้าไปฟังบาง session โดยที่ session ที่ 2 ที่เข้าไปฟัง
คือ DevOps 101 - what the heck DevOps is ?
ว่าด้วยเรื่องของ DevOps คืออะไร
ประกอบไปด้วยแนวคิดอะไรบ้าง
รวมไปถึงเรื่องของ DevOps topologies ที่ถูกนำมาใช้งาน
ทั้งในแนวทางที่ดีและแนวทางที่แย่ แต่ก็ขึ้นอยู่กับองค์กรนั้น ๆ ด้วยว่าเป็นอย่างไร
มาเริ่มกันเลย

DevOps คืออะไร ?

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

แต่ที่แน่ ๆ 
มันไม่ใช่เรื่องของ automation
มันไม่ใช่เรื่องของ tool หรือเครื่องมือ
หนักกว่านั้น มันไม่ใช่ role หรือตำแหน่งใหม่ ๆ ในองค์กร
แต่มันคือ culture ขององค์กรมากกว่า
เพื่อทำให้ไปถึงเป้าหมายที่ตั้งไว้อย่างไร้ปัญหา
และช่วยทำให้คนที่เกี่ยวข้องมีความสุขกับมัน (Happy)

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

โดยอาจจะมี DevOps team ขึ้นมาเพื่อเป็นทีมสนับสนุน (Support team)
เพื่อช่วยให้แนวคิด DevOps มาเกิดเป็นรูปธรรมขึ้นมา
แสดงดังรูป

ในแนวคิด DevOps นั้น ให้เน้นเรื่องของ

• Respect in production นั้นคือ production เป็นสิ่งที่สำคัญ ควรให้ความเคารพ คนจริงต้องทดสอบบน production จริง ๆ ไหม ต้องมีกระบวนการที่ดี มีคุณภาพ กระชับและรวดเร็ว
• Break team silo การแยกทีมรับผิดชอบแต่ละเรื่องเป็นสิ่งที่ดี แต่ทำงานจริง ๆ มันคือการโยนขี้ไปมาหรือไม่ ? แทนที่จะช่วยกันว่า จะทำงานร่วมกันอย่างไร เพื่อให้ขั้นตอนการพัฒนาและส่งมอบระบบงานมันไหลลื่น
• ลดสิ่งต่าง ๆ ที่ทำให้ทีมตั้งแต่ business, development และ operation มีปัญหาหรือปวดหัวลงไป หรือไม่ให้เกิดขึ้นเลย

โดยแนวคิด DevOps จะมีกรอบ หรือ framework ของมันด้วย

ใน session นี้ผู้พูดแบ่งออกเป็น 5 เรื่องคือ

1. Culture เรื่องของวัฒนธรรมของคนในองค์กร ที่ต้อง share หรือแบ่งปันสิ่งต่าง ๆ ทั้งหน้าที่รับผิดชอบ ปัญหาต่าง ๆ รวมทั้งความเชื่อใจต่อกัน เช่นลดการ approve สิ่งต่าง ๆ ลงไป แต่ก็ใช่ว่าจะเปิดให้ทำทุกอย่างก็ต้องมีกรอบเช่นกัน แต่มีเท่าที่จำเป็นเท่านั้น
2. Risk reduction เรื่องของการลดหรือการจัดการความเสี่ยง เนื่องจากส่วนต่าง ๆ มันพร้อมพังแน่นอน ดังนั้นควรต้องเตรียมพร้อมรับมือหรือคิดวิธีจัดการไว้ได้เลย ที่สำคัญต้องซ้อมด้วยนะ
3. Automation งานอะไรที่มันต้องทำซ้ำ ๆ แนะนำให้ทำงานแบบอัตโนมัติ เนื่องจากมันเป็นแนวทางที่ช่วยให้ DevOps ประสบความสำเร็จและจับต้องได้ง่ายที่สุด
4. Lean ลด waste ต่าง ๆ ลงไปให้มากที่สุด เช่นการรอ ดังนั้นต้องหาจุดที่เป็นปัญหาและแก้ไขมันซะ ถ้า deploy ระบบงานยาก เพราะว่ามันใหญ่เกินไป ก็ลดขนาดลงซะ ไม่ใช่มาสร้างขั้นตอนที่ซับซ้อนมาตรวจสอบ แบบนี้ก็ไม่น่าจะ Lean นะ รวมทั้งลดการพูดคุยหรือการติดต่อสื่อสารให้มากที่สุด ทำให้มากคุยให้น้อยแต่มีคุณภาพ
5. Measure ทุกสิ่งทุกอย่างที่ทำลงไป ควรต้องวัดค่าได้เสมอ นั่นคือจำเป็นต้องเก็บข้อมูลต่าง ๆ ที่จำเป็น ทั้งฝั่ง business, application และ infrastructure เน้นที่เก็บเท่าที่จำเป็นและต้องการเท่านั้น

การนำแนวคิด DevOps ไปใช้งานในองค์กรต่าง ๆ 

ก็มีรูปแบบมากมายที่น่าสนใจ
ซึ่งทำการสรุปไว้ที่ DevOps team topologies
ทั้งแบบที่ดีและแบบ anti-pattern

ยกตัวอย่างเช่น DevOps Team Silo
เกิดเป็นอีก silo หรือ ทีม หรือ แผนกใหม่
คำถามคือ มันคือการแก้ไขปัญหาที่มีอยู่ หรือ เป็นการสร้างปัญหาใหม่ขึ้นมากันแน่

ลองไปอ่านเพิ่มเติมกันดูครับ สนุกมาก ๆ

หัวข้อสุดท้ายที่เข้าฟังในงาน Code Mania 1010 :: All about passion
คือ Real-time Bot Detection using Machine Learning จาก Agoda
ส่วนที่น่าสนใจคือ ขั้นตอนของการสร้าง model
เพื่อนำมามาตรวจสอบ ในแต่ละ request ที่เข้ามายังระบบว่า
เป็น Bot ที่เราไม่ต้องการหรือไม่
ตลอดจนการนำไปใช้งาน ซึ่งจะมี feature จำนวนมาก
แน่นอนว่า feature ต่าง ๆ ไม่สามารถเปิดเผยได้
มิเช่นนั้น จะโดนเล่นงานแน่นอน !!
มาเริ่มกันเลย

เริ่มด้วยประเภทของ Bot

ประกอบไปด้วย 2 ประเภทคือ

1. Good bot คือ bot ที่ดี และเราไว้ใจให้เข้ามา เช่น Google Bot หรือพวก search engine bot นั่นเอง
2. Unwanted bot คือ bot ที่เราไม่ต้องการ  เข้ามาโดยมีเจตนาไม่ดี ทั้งยิงระบบ ทั้งดึงข้อมูลจากระบบไปใช้งาน โดยที่ bot ประเภทนี้มักชอบทำตัวให้เหมือนกัคนใช้งานทั่วไปอีกด้วย

ดังนั้นเป้าหมายของการตรวจสอบคือ
ทำการตรวจสอบ bot ประเภทที่สองนี่เอง
คำถามคือ เราจะทำการตรวจสอบได้อย่างไร ?

การตรวจสอบ bot แบ่งออกเป็น 2 กลุ่มคือ

• กลุ่มที่ 1 ตรวจสอบแบบ offline ทำการเก็บข้อมูลไว้ก่อน จากนั้นจึงทำการตรวจสอบย้อนหลัง เพื่อหารูปแบบของ bot
• กลุ่มที่ 2 ตรวจสอบแบบ online ทำการตรวจสอบในแต่ละ request ที่ส่งเข้ามายังระบบทันที ว่าเป็น bot หรือไม่ ?

เป้าหมายของการตรวจสอบคือ แบบ online นั่นเอง
คำถามคือ ทำอย่างไร ?

ทางผู้พูดบอกว่า เริ่มด้วยการตั้ง policy หรือ pattern ขึ้นมา

ยังไม่ได้ใช้ Machine Learning นะ
ทำการสร้าง policy และ pattern ขึ้นมา
ตามที่ได้วิเคราะห์จากข้อมูลที่เก็บไว้
จะเป็นไปในรูปแบบ static  ยกตัวอย่างเช่น

• จำนวน request ของแต่ละ session หรือผู้ใช้งานว่า เข้ามาดูโรงแรมเกิน 100 ที่หรือไม่
• จำนวน request ต่อ IP นั้นเกิน 1,000 หรือไม่ 

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

ดังนั้นจึงจำเป็นต้องมีระบบตรวจสอบที่ dynamic ขึ้น
นั่นจึงเป็นที่มาของการนำเอา Machine Learning เข้ามาใช้งาน

การนำ Machine Learning เข้ามาสร้างระบบตรวจสอบ Bot แบบ online/realtime

โดยจะเริ่มจากศูนย์กันเลยทีเดียว
แต่สิ่งที่ดีคือ ระบบทำการเก็บข้อมูลของแต่ละ request ไว้อยู่แล้ว
ส่วนข่าวร้ายคือ ข้อมูลที่เก็บยากต่อการนำมาใช้งาน
ดังนั้นจึงต้องมีขั้นตอนการทำงาน
และแน่นอนว่า ระบบที่สร้างขึ้นมานั้นจะเป็นแบบ trial and error 

ขั้นตอนการทำงานหรือสร้างระบบด้วย Machine Learning เป็นดังนี้

ไม่ได้มีความแตกต่างจากขั้นตอนปกติ

1. Data collection คือการจัดเก็บข้อมูล
2. Feature engineer คือการปรับแต่งข้อมูล ให้ข้อมูลพร้อมและเหมาะสมต่อการนำไปใช้งาน เช่นการเพิ่ม feature ใหม่ ๆ เข้าไป โดยในระบบที่สร้างนั้นมีมากกว่า 300 feature และน่าจะมีเพิ่มไปเรื่อย ๆ แน่นอน
3. Training model เป็นการสร้าง model ขึ้นมานั้นเอง
4. Evaluate model ทำการทดสอบและประเมินผลการทำงานของ model ที่สร้างขึ้นมา
5. Deploy model บน production environment
6. Monitoring การทำงาน ซึ่งจะมี metric และ dashboard ดู ทั้งการทำงานว่า overfit หรือไม่ รวมทั้ง feedback ต่าง ๆ
7. Improvement ทำการปรับปรุงทั้งจากตัวระบบเอง และจากคนใช้งานหรือทีมงานที่ดูแล การทำงานอาจจะไม่สามารถตรวจจับ bot ในรูปแบบใหม่ ๆ ได้ แต่มีการแจ้ง ดังนั้นจึงต้องทำการปรับหรือเพิ่ม feature ซึ่งนั่นนำไปสู่การ training model วนไป

หัวใจหลัก ๆ คือ

เรื่องของข้อมูลที่จัดเก็บ ซึ่ง storage ต้อมีขนาดใหญ่ ดังนั้นที่จัดเก็บก็ต้องพร้อม
ที่ Agoda จะใช้ Apache Hadoop
มี Apache Kafka เป็น messaging มาคั่นกลาง
ดังนั้นทุก ๆ ระบบก็ส่งข้อมูลมายัง Apache Kafka
จากนั้นมี process/service ทำการบันทึกลง Apache Hadoop ต่อไป
การใช้งานก็นำเอา Apache Spark มาดึงด้วย SQL script นั่นเอง

ขั้นตอนต่อมาที่ไม่สามารถเปิดเผยได้คือ Feature engineer
เพราะว่ามีการเพิ่ม feature ต่าง ๆ เข้าไป
เพื่อให้ข้อมูลสามารถใช้งานในขั้นตอนการ training model ได้ง่ายขึ้น
โดยข้อมูลที่จัดเก็บมีจำนวนมาก
ดังนั้นการสร้าง feature ใหม่ ๆ จึงเป็นขั้นตอนที่ไม่ง่าย
จึงนำพวก key-value database มาช่วยเก็บข้อมูลในการคำนวณต่าง ๆ
โดยส่วนใหญ่ feature จะมีค่าเป็นตัวเลขทั้งหมด
จะสัมพันธ์กับ algorithm ที่นำมาใช้ในการ train model คือ XGBoost

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

แสดงดังรูป

เป็นอีกระบบหนึ่งที่น่าสนใจ

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

ยกตัวอย่างเหตุการณ์ที่เจอบ่อย ๆ มั้ง !!

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

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

จึงมีคำพูดติดตลกคือ Later is Never !!
และผลที่ตามมาเป็นอย่างไร ?
สิ่งเหล่านี้มันคือ สัญญาณเตือนอะไรบางอย่างหรือไม่
ที่เราควรต้องหยุดคิดหน่อยว่า
อะไรคือผลที่ตามมาจากคำว่า เดี๋ยวทำทีหลัง !!

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

สิ่งที่ทำมันคือ workaround (แก้ผ้าเอาหน้ารอด)
หรือ มันคือ solution แก้ไขปัญหาจริง ๆ
เรื่องนี้มันบ่งบอกถึงคำว่า มืออาชีพในสิ่งที่ทำหรือไม่ (professional)

คำว่าเดี๋ยวค่อยทำ มันมีอะไรบ้างนะ ?

• เดี๋ยวเราค่อยปรับปรุง code ให้ดีภายหลัง ตอนนี้ทำให้มันเสร็จ ๆ ก่อน
• ทำ ๆ ไปก่อน เดี๋ยว requirement จริง ๆ ก็จะตามมา
• เดี๋ยวค่อยแก้ bug
• เดี๋ยวค่อยเขียน test
• เดี๋ยวค่อยสร้าง feature ที่ลูกค้าต้องการ
• เดี๋ยวค่อยแก้ไข code ชุดนี้ เพื่อให้ test ผ่าน
• เดี๋ยวค่อยแก้ไข code ที่มันซ้ำซ้อน ทำการ copy and paste มาก่อนเลย
• เดี๋ยวค่อย deploy เพราะว่ายังไม่พร้อม
• เดี๋ยวเราค่อยทำเรื่อง performance testing

วันนี้คุณพูดคำว่าเดี๋ยวบ้างหรือยัง ?
ควรเดี๋ยว หรือ ลงมือทำตอนนี้เลยดีกว่ากัน ?

หลังจากที่ทาง IT Revolution นั้นได้เปิดตัวหนังสือ The Unicorn Project มา
วันนี้ได้ทำการเปิดให้ download e-book เรื่อง The Phoenix Projectแบบฟรี ๆ !!
โดยมีเวลาเพียง 24 ชั่วโมงเท่านั้น
ไป Download กันเลย

ว่าด้วยเรื่องของคำว่า Fun หรือว่าความสนุก
ยิ่งเรื่องของความสนุกในบริษัทหรือที่ทำงาน
เป็นสิ่งหนึ่งที่สำคัญอย่างยิ่ง น่าจะส่งผลดีต่อคนทำงานและองค์กร
ทั้ง productivity และ performance
และมันสะท้อนออกมาได้ชัดเจนกับตัวงานหรือ product นั่นเอง
โดยบทความเรื่อง  The Importance of Fun in the Workplace จาก InfoQ
ได้ทำการสรุปแนวทางไว้นิดหน่อย ดังนี้

เริ่มด้วย ความสนุกมันบังคับให้เกิดไม่ได้ แต่ค่อย ๆ สร้างมันขึ้นมาได้

Fun can’t be forced, but it can be fostered.

โดยการสร้างความสนุกให้เกิดขึ้นนั้น จะมีอยู่ 3 ขั้นตอนดังนี้

ขั้นตอนที่ 0 :: Stop prohibiting fun

เป็นขั้นตอนสำคัญมาก ๆ  ถ้าทำไม่ได้ก็ไปต่อไม่ได้

ขั้นตอนที่ 1 :: Removing un-fun things

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

ขั้นตอนที่ 2 :: Having fun

แต่คำว่าสนุกของแต่ละที่มีความหมายต่างกัน ลอกกันไม่ได้
ยกตัวอย่างเช่น
ความสนุกกับการออกกำลังกาย
เพื่อช่วยลดภาวะความเครียด แถมช่วยให้ผ่อนคลาย
ยกตัวอย่างเช่น การมีโต๊ะปิงปอง หรือ เกมส์ หรือ การดูหนัง หรือ ร้องเพลง เป็นต้น
แต่ถ้ามีกฏมากไป ก็จะไม่สนุกแล้ว ให้กลับไปดูขั้นตอนที่ 0
ยกตัวอย่างเช่น
มีห้องเล่นเกมส์ แต่ว่ามัน lock ไว้ ต้องไปขอกุญแจจากคนดูแล
มีโต๊ะปิงปองแต่เล่นได้เฉพาะช่วงพักเท่านั้น
มีไปทำไมนะ  !!!

เมื่อย้อนกลับมาดูในการพัฒนา software ละ !!

มันจะสนุกอย่างไร ?
โดยปกติการ coding นั้นมันสนุกในตัวมันเอง
เนื่องจากเหมือนเป็นการต่อ jigsaw นั่นเอง
เมื่อนำแต่ละตัวมาประกอบกัน มันสามารถทำงานได้อย่างน่าอัศรรย์
แต่บ่อยครั้งมันก็ไม่ได้สนุกเลย !!

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

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

ระหว่างเอกสารกับ code คุณเลือกที่จะเชื่ออะไร ?
เป็นคำถามที่สะท้อนสถานการณ์ปัจจุบันได้อย่างดีเยี่ยม

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

มาลองสร้างองค์กรและทีมที่มีความสนุกกันครับ

Fun isn’t about what people are doing, 
it’s about how they’re feeling.

พอดีเพิ่งลองทำ project ส่วนตัว เพื่อแก้ไขปัญหาบางอย่างของตัวเอง
ซึ่งทำการเขียน code ด้วยภาษา Go นี่แหละ
มีขั้นหนึ่งต้องทำการ filter ข้อมูลที่อยู่ใน array/slice
ปกติก็ใช้งาน for loop กับ if statement นี่แหละ

แต่ก่อนหน้านี้ เพิ่งเขียน JavaScript มา
ซึ่งมีพวก map/reduce/filter อะไรพวกนี้ให้
แล้วในภาษา Go ละ มีไหมนะ ?

ก็เลยลองไปหาและดูใน community ก็เจอเยอะเลย

มี project ตัวนึงของคุณ Rob Pike ชื่อว่า Filter
ซึ่งมี พวก map/reduce/filter ให้ใช้งานด้วย
เป็น project ที่สร้างขึ้นมาเพื่อทดลอง

การใช้งานในกรณีของผมก็ไม่ยาก
ต้องการเพียง filter หรือกรองข้อมูลที่ต้องการเท่านั้น

ดังนั้นเขียน function ของเงื่อนไขในการกรองสิ่งที่ต้องการดังนี้

จากนั้นก็ใช้งาน filter ที่สร้างดังนี้

เพียงเท่านี้ก็ใช้งานแบบง่าย ๆ ได้แล้ว
โดยส่วนตัวผมชอบในเรื่องของการใช้งาน
เพราะว่าง่าย สะดวก ดูง่ายดีนะ

ไปดูแนวทางการสร้าง project filter หน่อยสิ

ใช้งาน package reflect นั่นเอง 
ดังนั้นก็ต้องระวังการใช้งานมาก ๆ ในตอน runtime
แน่นอนว่า ต้องป้องกันด้วยการเขียน test ให้ครอบคลุมนั่นเอง

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

ลองไปดูการพูดคุยเกี่ยวกับ project filter เพิ่มได้
หรือไปดู project ที่คล้าย ๆ กันเช่น Go-funk
หรือไปดู Map/Reduce/Filter in Go

ลองทำ project เล่น ๆ แต่ก็ได้ความรู้ที่เราคาดไม่ถึงเยอะเลย
ขอให้สนุกกับการ coding ครับ

อ่านเจอบทความอธิบายเรื่องของการทำงานแบบ

• Sequencial
• Concurrency
• Parallelism

โดยอธิบายจากการทำงานของ Santa Claus
ว่าขั้นตอนการเตรียมและส่งของขวัญให้กับเด็ก ๆ ทั่วโลกเป็นอย่างไร
แสดงออกมาในรูปแบบของรูปภาพได้อย่างน่าสนใจและเข้าใจได้ง่าย
มาดูกันว่าเป็นอย่างไรบ้าง ?

การทำงานแบบ Sequencial หรือเรียงตามลำดับ

การทำงานแบบ Concurrency การทำงานหลายงานพร้อม ๆ กัน

การทำงานแบบ Parallel หรือการทำงานเดียวกันพร้อม ๆ กัน

อ่านบทความเรื่อง Taming Complex Systems in Production
มีเรื่องที่น่าสนใจเยอะ หนึ่งในนั้นคือ
เรื่องเกี่ยวกับการพัฒนาระบบ
ให้สามารถ recover กลับมาจากความผิดพลาดได้ด้วยระบบเอง
โดยไม่ต้องมีคนเข้าไปยุ่งเกี่ยว
ซึ่งสรุปว่าระบบที่จะทำได้จำเป็นจะต้องมีคุณสมบัติดังต่อไปนี้

• Graceful termination เมื่อระบบงานผิดพลาดเช่น node พังแล้ว ต้องสามารถจัดการได้เช่น ทำการ deploy ระบบใน node ใหม่ได้เอง
• Transactional ถ้าระบบทำงานผิดพลาดแล้ว ข้อมูลยังคงต้องถูกต้อง เช่น commit หรือ rollback นั่นเอง ไม่ใช่มีข้อมูลเพียงครึ่ง ๆ กลาง ๆ
• Clean restarts ถ้า node พังขึ้นมา ระบบต้องการันตีว่า node นั้นออกไปจากการทำงานแล้ว ไม่มีการส่งงานไปให้ แต่จะส่งงานไปให้จนกว่าจะพร้อมหรือสร้างขึ้นมาใหม่
• Queue backed เมื่อระบบทำงานผิดพลาด เช่น node พังไปแล้ว ต้องทำกลับมาให้ได้ หนึ่งในนั้นคือ การนำ event หรือการทำงานไปไว้ใน queue เพื่อรอการทำงานต่อไป
• Idempotency เป็นความสามารถของระบบที่ดี นั่นคือเมื่อ request หนึ่งทำงานซ้ำมากกว่า 1 ครั้งแล้ว ผลการทำงานยังต้องเหมือนเดิม ไม่ใช่ทำงานซ้ำ เนื่องจากถ้าระบบทำงานผิดพลาด เราจะสามารถ replay หรือสั่งให้ทำงานใหม่ได้โดยไม่กลัวความผิดพลาด
• Stateless ถ้าระบบงานทำงานแบบ stateless แล้ว นั่นคือไม่เก็บข้อมูลหรือ state ใด ๆ ในตัวเอง ส่งผลให้สามารถจัดการหรือย้ายระบบงานไปที่อื่นได้ง่ายขึ้น

ว่าแล้วก็ลองกลับมาตรวจสอบระบบงานเรากำลังพัฒนาหรือดูแลอยู่
มีคุณสมบัติตามนี้หรือไม่ ?