สรุปช่วงบ่ายจากงาน YOW! Australia 2023 sharing ของชาว ODDS 😎

Taewapon B.
odds.team
Published in
4 min readJun 30, 2024

แชร์ประสบการณ์จากงาน YOW! ที่ Brisbane และ Sydney ส่งตรงจาก Australia!

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

สรุปช่วงเช้าจากงาน YOW! Australia 2023 sharing ของชาว ODDS 😎

OCAML 🐫 for fun and profit: An experience report

สำหรับหัวข้อแรกของช่วงบ่ายพี่อรรถและพี่ศิลป์มาเล่าเรื่อง OCAML (โอคาเมล) ให้ฟังครับว่ามันดียังไง แล้วทำไมเราควรใช้ภาษานี้ครับ

ภาพจาก Session OCAML จากพี่อรรถและพี่ศิลป์

OCAML คือภาษาในตระกูล ML ที่แนะนำตัวเองว่าเป็นภาษาที่ใช้งานได้ในทุกรูปแบบ (general-purepose), สามารถใช้งานในระดับอุตสาหกรรมได้ (industrial-strength), ถูกคลุมด้วย Type ทำให้เขียนได้ง่ายและเป็นระบบ สุดท้าย OCAML ยังมีความปลอดภัยสูงและถูกใช้โดยบริษัทใหญ่ ๆ ทั้ง Microsoft, Facebook, Docker, Bloomberg

ความน่าสนใจของ OCAML คือไม่หนักเครื่อง (Lightweight) มี Add-ons สำหรับการพัฒนามาให้พร้อมใช้แล้วบน Editor หลัก ๆ เช่น VS Code, Vim ทำให้ Developer สามารถโฟกัสไปที่ Application logic ได้อย่างเต็มที่ ซึ่งก็ส่งผลให้เราสามารถจัดการกับ Large, complex codebases ได้อย่างง่ายดาย รวมไปถึงการ Refactor ที่สะดวกขึ้นอีกด้วย!

สำหรับใครที่สนใจติดตามต่อได้ที่นี่เลย >> https://ocaml.org

OCAML เป็นภาษาที่น่าใช้งานที่มอบความสุนทรีในการเขียนให้กับ Developer, มีความเสถียร, ความปลอดภัยสูงและเป็นหนึ่งในภาษาที่อยู่เบื้องหลังงานใหญ่ ๆ ของหลายบริษัท 🐫

Infobesity: How to cope with the overload of information

ปัจจุบันข้อมูลข่าวสารมีอยู่เยอะมาก ผู้คนบางส่วน Interrupt กับข้อมูลมากมายที่เข้ามาในแต่ละวันเปรียบได้กับมนุษย์ที่มีปัญหาโรคอ้วน (Obesity) จากข้อมูลข่าวสาร (Infomation) เลยเป็นจุดเริ่มต้นที่ทำให้เกิด INFOBESITY หรือโรคอ้วนข้อมูลขึ้นมาครับ

สิ่งนี้นำมาใช้ในการวัดประมาณข้อมูลที่เรารับในแต่ละวัน (Digital Weight) เปรียบได้กับตาราง BMI เลย โดยที่เราจะมองข้อมูลเป็นอาหารที่รับเข้ามานั่นเอง แต่เราก็แบ่งอาหารได้ทั้งแบบที่มีประโยชน์และไม่มีประโยชน์ด้วยนะ

แหล่งของ Dopamine ทั้งดีและเสียที่เราได้รับ

สิ่งนี้เกิดจากการเราตัดสินใจเองหมดเลย ทั้งจาก Design ของสิ่งต่าง ๆ เช่น ปุ่ม Next Episode ของ Netflix ที่ทำให้เราอยากดูตอนต่อไปเรื่อย ๆ หรือพฤติกรรมของเราเองที่เรียกว่า Fear of missing out (FOMO) ทำให้เราไม่อยากพลาดข่าวสารอะไรเลย แต่เราเองก็สามารถใช้ MoSCoW (Must, Should, Could, Won’t) มาพิจารณาสิ่งที่เหมาะสมและจำเป็นกับเราจริง ๆ ในการใช้ชีวิตได้ครับ

ปัญหาโรคอ้วนข้อมูลส่งผลต่อสุขภาพเราได้ แบบเดียวกับโรคอ้วนจริง ๆ เลย ดังนั้นเราควรพิจารณาให้ดีว่าข้อมูลใดที่เราควรหรือไม่ควรบริโภค และในแง่ของ Developer เราก็ควรใส่ใจต่อ Design ที่ดีต่อสุขภาพของ User ด้วย 🥦

Livebook & Elixir: Where AI, Web, and Concurrency meet

หัวข้อนี้พี่โก้และพี่ปอนด์พูดถึง Livebook ของ Elixir ครับ ซึ่งก็คือ platform สำหรับ note & code ไปพร้อม ๆ กัน เปรียบเสมือน Jupyter Notebook รวมร่างกับ Notion

ข้อดีของ Livebook คือเป็น platform ที่ใช้งานสะดวก และใช้งานได้หลากหลายด้วย ตั้งแต่การเขียน document ไปจนถึงการใช้งาน machine learning models เลย ส่วนที่เท่อีกอย่างคือสามารถ integrate กับ tools ดัง ๆ หลายเจ้าได้ด้วย เช่น MySQL, SQLite, Cloudflare

พี่โก้และพี่ปอนด์กำลังพาไปเล่น Livebook

นอกจากนั้นพี่ ๆ ก็พาไปเล่น Livebook บนเว็บด้วย ทำให้เห็นข้อดีและภาพการใช้งานจริง ๆ ด้วยครับ สำหรับใครที่อยากลองตามไปที่นี่เลย >> https://livebook.dev/

ความน่าใช้งานและข้อดีของ Livebook กับภาษา Elixir ที่สามารถนำไปใช้งานได้หลากหลายรูปแบบ นับว่าเป็นอีกหนึ่งตัวเลือกที่น่าสนใจในการใช้งานในอนาคต 🎉

Event modeling from beginner to expert + Workshop

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

ตัวอย่างโครงสร้างของ Event Modeling

Event Modeling หรือชื่อเดิมคือ Single Flow Event Stroming คือสิ่งที่เรานำมาแสดงลำดับของเหตุการณ์ (Event) ในระบบของเราได้ ซึ่งใช้เพียง 4 อย่างในการอธิบายครับ

  1. User Interface/Wireframes — หน้าจอของผู้ใช้งาน
  2. Commands — คำสั่งที่เกิดขึ้นกับระบบ เช่น createOrder (Sticky สีฟ้า)
  3. Event — สิ่งที่เคยเกิดขึ้นกับระบบของเรา เช่น orderCreated (Sticky สีส้ม)
  4. View/Read Model — ภาพรวม/สถานะปัจจุบันของสิ่งที่เกิดขึ้นในระบบ (Sticky สีเขียว)

ซึ่งขั้นตอนในการสร้างสิ่งเหล่านี้ก็ประกอบไปด้วย 7 ขั้นตอนเท่านั้นครับ

  1. Brainstorming — ระบุ Event หรือสิ่งที่จะเกิดขึ้นภายในระบบของเรา
  2. The Plot — เรียง Event เหล่านั้นตามช่วงเวลาที่จะเกิดขึ้น เช่น 1. เพิ่มสินค้าลงตะกร้า > 2. ชำระเงิน
  3. The Story Board — ร่าง Wireframes คร่าว ๆ ของแต่ละ User (Client, Admin)
  4. Identify Inputs — ส่วนนี้เริ่มนำสิ่งที่เรียกว่า Command และ Event มาใช้งาน เป็นการจำกัดความสิ่งที่จะเกิดขึ้นภายในระบบของแต่ละหน้าจอครับ
  5. Identify Outputs — ต่อมาเราจะระบุข้อมูลที่ Read Model เพื่อส่งข้อมูลให้ User หรือ ระบบอื่น ๆ ได้นำไปใช้ต่อ
  6. Apply Conway’s Law — การแบ่งแต่ละชิ้นส่วนในระบบว่ามีการทำงานหรือติดต่อกันยังไง เพื่อให้สามารถแบ่งงานให้แต่ละทีมทำแยกกันได้
  7. Elaborate Scenarios — มองภาพรวมเพื่อใส่ Behavior เพื่อให้นำไปใช้งานต่อได้ (given when then)

สำหรับข้อมูลเกี่ยวกับ Event Modeling สามารถตามอ่านต่อได้ที่ Blog นี้เลยครับ

ป.ล. แอบได้ยินว่าจะมี workshop เรื่องนี้เพิ่มด้วยนะ 🫣

ทุก ๆ Design Pattern เกิดมาเพื่อแก้ปัญหาบางอย่าง เราควรเข้าใจธุรกิจ ทีม และวัฒนธรรมองค์กรของเรา ก่อนที่จะนำเทคโนโลยีเหล่านี้เข้ามาช่วยให้พวกเรามีเวลานอนมากขึ้น 🧑🏻‍💻

Building a metrics-driven organization

หัวข้อนี้เริ่มด้วยการวัดผล Software delivery performance จากทาง Google ครับ โดยพี่ ๆ ยกประเด็นว่าการที่จะเป็น Elite ของการส่งมอบ software ได้นั้นจำเป็นต้องมีความสามารถหลายอย่าง ทั้งความถี่ของการ deploy, เวลาที่ใช้กู้คืน service เป็นต้น

ตาราง Aspect of Software Delivery Performance

จากตารางด้านบนสามารถช่วยให้เราดูได้คร่าว ๆ ว่าปัจจุบันนั้นองค์กรเราอยู่ในระดับใดครับ โดยที่พี่ ๆ ก็มีเว็บมาแชร์สำหรับลองวัดผล software delivery performance คร่าว ๆ ของเราดูด้วยครับ >> https://dora.dev/quickcheck/

หลังจากนั้นเราจะมาดู Metrics framework ที่ใช้วัดจากตัวแปรทั้งสองคือ outcome เช่น ความพึงพอใจของลูกค้า, test coverage และ input เช่น response time, UI/UX ที่ดี โดยทั้งสองอย่างก็จะถูกนำไปใช้เพื่อระบุสิ่งที่ต้องทำและเป้าหมายเพื่อพัฒนาให้เป็นองค์กรที่วัดผลได้ชัดเจนต่อไปครับ

การสร้างองค์กรที่วัดผลได้ สามารถช่วยให้เรารู้ระดับของตัวเราเอง ทีม และองค์กร เพื่อให้สามารถวางแผนและเป้าหมายในการพัฒนาได้โดยง่าย ⬆️

Advancements and Future direction in AI-Assisted Coding

ประวัติศาสตร์ของ AI

ในช่วงนี้พี่ ๆ มาเล่าถึงมุมมองต่อทิศทางในอนาคตของ AI กันครับ ทำไมถึงควรดีใจที่ AI พัฒนาไปเร็วขนาดนี้ เริ่มเล่าตั้งแต่อดีตของ AI ในช่วงที่เป็น Non-monotonic Logic มาจนถึงปัจจุบันที่เป็น Generative AI ซึ่งสามารถใช้งานได้หลากหลายรูปแบบ รวมไปจนถึงปัญหาปัจจุบันของ AI ที่เราเผชิญอยู่ เช่น Prompt Drift

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

Organizational Sustainability with Platform Engineering

หัวข้อนี้เรามาดูเรื่องของการสร้างขั้นตอนการทำงานที่สามารถช่วยเหลือให้องค์กรเติบโตได้ด้วย platform engineering ครับ

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

ภาพ Platform Principles

โดยแต่ละหัวของ platform principles มีรายละเอียดดังนี้ครับ

Principles
แบ่งปันสิ่งต่าง ๆ ร่วมกัน เพื่อสร้างความเชื่อใจ สร้าง feedback และลดการเกิด silos ภายในองค์กร, ลดงานที่ซ้ำซ้อนให้เปลี่ยนเป็น automate เพื่อช่วยลด human error, ควรมีการเก็บข้อมูลเพื่อวัดผลทุกครั้ง เพื่อตรวจสอบและสร้าง Feedback ว่าทุกอย่างเป็นไปตามที่ต้องการหรือไม่

Community
ทำให้การสร้าง software เป็นเรื่องง่าย ลด software คุณภาพต่ำ, สร้าง flexible, scalable สำหรับทีมหรือองค์กร, ช่วยให้ engineers มีเวลาในการพัฒนาความสามารถอื่น ๆ, สร้างวัฒนธรรมที่ช่วยลดการเบิร์นเอาท์

Architecture
ใช้ best practice เพื่อให้งานออกมาดี, การสร้าง platform ที่เติมเต็มความต้องการผู้ใช้จริง ๆ, domain driven architecture สร้าง platform ที่ based on domain นั้น ๆ, เลือกเทคโนโลยีที่น่าเบื่อ (boring technology) ในที่นี้คือเลือกเทคโนโลยีที่เสถียรและมีผู้ใช้งานอยู่แล้ว แทนที่จะเลือกเทคโนโลยีใหม่ ๆ ป้องกันความไม่เสถียรของภาษาใหม่ ๆ

Communal learning is the only sustainable advantage — การเรียนรู้ร่วมกันคือข้อได้เปรียบที่ยั่งยืนที่สุด

The Many Faces of Identity

ในหัวข้อสุดท้ายพี่วุฒิพาเรามาดูเรื่องของวิธีการระบุตัวต้นของเราบนโลกออนไลน์ซึ่งปัจจุบันเองก็มีหลายวิธีมาก ตัวอย่างเช่น Username + Password, 2FA, Biometrics, SSO, Token-Based, Blockchain

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

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

การยืนยันตัวตนเป็นหนึ่งในสิ่งจำเป็น, ซับซ้อน, และไม่มีคำตอบตายตัวสำหรับการสร้างระบบในปัจจุบัน ดังนั้นการเข้าใจในระบบการทำงานของมันจะช่วยให้เราสร้าง Product ที่มีความปลอดภัยสำหรับทั้ง User และ Developer ได้

จบแล้ว! สรุปของแต่ละหัวข้อสั้นยาวตามความเข้าใจของผมเองครับ 😂 ก็เรียกได้ว่าเป็นอีกหนึ่ง Sharing Session ที่ทรงคุณค่ามากครับ ได้ทั้งความรู้แน่น ๆ ของแจกเต็มกระเป๋า และอาหารอร่อย ๆ เต็มท้องเลยครับ 🙏 🎉

--

--