มาอัพเดตเทคกับงาน DevFest Bangkok 2023

Event Nov 7, 2023

และแล้วก็มาถึงงานประจำปี อย่าง DevFest Bangkok ที่มีเนื้อหาทั้งสาย Web, Firebase, Flutter, AI และ Kotlin นั่งฟัง session อย่างตั้งใจ ที่สถานที่ทำเอาเราปวดหลังเลยทีเดียว นั่งนาน 5 ชั่วโมงโดยประมาณ

รายละเอียดงานจากเว็บของทาง GDG งานจัดขึ้นวันเสาร์ที่ 4 พฤศจิกายน ที่ SCB NEXT TECH

https://gdg.community.dev/events/details/google-gdg-bangkok-presents-devfest-bangkok-2023/

เริ่มต้นด้วยชามะนาวฟรีจาก JOIN หลังจากไป dip chip และมีโต๊ะให้เขียนด้วยนิดหน่อย อ่ะลุยเลยยยย 🔥

ภายในงานมี session อะไรบ้าง มาดูกัน

Opening - Wittaya Assawasathian

คร่าว ๆ คือที่ไทยเป็นเมืองแรก ๆ ที่จัดงาน Devfest โดยในปีนี้มีโคกับทาง SCBX เลยได้มาจัดที่นี่เนาะ

ก่อนหน้านี้ทางเราจะได้มากับคอมมูฝั่ง web3 มาหลายรอบแล้ว ทั้งงานของทาง JFIN แล้วก็งานของ Bullmoon NFT ก็เพิ่งได้มางานที่นี่หลังหลาย ๆ คนไปเยอะเลย

View Transition API the next generation of web transition - Warat Wongmaneekit

ตอนแรกคุณตั้งยังไม่ได้ตื่นเต้นกับตัว View Transition API เท่าไหร่ จนรู้ว่ามันทำอะไรได้บ้าง

ปัญหาโลกแตกของฝั่ง web คือ มันไม่ smooth เท่าแอพ ซึ่งจริงถ้าทำด้วย Iconic มันก็ไม่ได้ช้า ส่วน Flutter เป็นแนวเอาของมาวาดบน canvas แถมยังไม่ support SEO ให้ฝั่งเว็บ เอาไงล่ะทีนี้ว้าวุ่นเลย

แล้วก็มีคนทำ poll ซึ่งเรื่องนี้มันติด top 3 ของ voted feature from state of HTML 2023 ทุกคนที่เป็น web developer ทั่วโลกก็บ่นกัน

แล้วทำไมมันทำยากจังเลยน้า?

เพราะ Native provide transition มาให้แล้ว ส่วน web ในการ implement เราจะใช้ตัว framework ต่าง ๆ เข้ามาช่วย

และสาเหตุนี้เอง ทำให้มันช้า เพราะทำให้มันเป็น native โดยการเอาอะไรบางอย่างไปยำไปมา ทำให้มันกระตุก

ซึ่งจริง ๆ ทาง Microsoft ก็เคยพยายามแล้ว แต่ตัว IE ก็ขิตไปแล้ว

แล้วทำไมถึงช้าล่ะ?

การทำงานคือ มีการ detech event จากนั้น append CSS class เข้าไป รอแสดง animation จนเสร็จ แล้วค่อยเอาของออก

สาเหตุ เพราะว่าการใช้ CSS ในการทำ animation ทำให้กิน CPU ทำให้ชาวคนทำเว็บตัดสิ่งนี้ทิ้งไปเพราะมันกระตุก

View Transitions API เป็น solution ในการแก้ปัญหาในเรื่องนี้ให้

ตัวอย่าง กดที่ item ซึ่งมันเป็น event นึงที่สามารถ detect ได้เนาะ ไปหน้า detail ที่แสดงรูปนี้เต็ม

เบื้องหลังคือมีการ capture หน้า เปลี่ยนหน้าใน background สร้าง transition เป็น CSS บน low level

แล้วมันเขียนยังไงกันนะ?

มี demo มาให้ชม โดยการ implement ผ่านเจ้า Glitch โดยตัวอย่างเว็บอันนี้เป็น single page เปลี่ยนหน้าโดยการ routing

ใส่ document.startViewTransition ลงไป โดย default มันจะเป็น fade

กำหนด transition name ที่ footer ให้กับทั้งสองหน้า ทำให้ footer สามารถเลื่อนขึ้นลงเมื่อเปลี่ยนหน้าได้ โดยใส่ style="view_transition-name=footer" ที่ HTML tag ของ footer

มีโชว์เพิ่มเติม คือ กดเพื่อ zoom ปก album และกดลบ album นั้นแล้วโชว์ animation แบบ slide

ถามว่าสามารถกำหนด custom animation ได้ไหม? ทำได้โดยการสร้าง pseudo class ขึ้นมา แล้วเขียน CSS animation ที่เราต้องการได้

เราสามารถ debug เพื่อดู state ได้

แต่อันนี้รองรับได้บาง browser ดังนั้นอย่าลืม handle เผื่อด้วยนะ

ความคาดหวังของคุณตั้ง คือ คาดหวังว่าตัว View Transition API จะอยู่ใน interop ของปีหน้านี้

Interop คือตัวนี้จะบอกว่ามี feature อะไรที่ browser บอกว่าเราจะทำไปด้วยกัน ในปีนั้น ๆ

ในตอนนี้ View Transition API support แค่ Single Page เท่านั้น ถ้า multipage ให้ไปเปิด setting ตัวนี้ก่อน viewTransition API for navigations

Reference

https://developer.chrome.com/docs/web-platform/view-transitions

https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API

อันนี้เป็น sample project ที่คุณตั้ง demo

https://glitch.com/edit/#!/view-transition-api-devfest-2023

Billboard Hot 100

https://view-transition-api-devfest-2023.glitch.me/

Better UX on the Web with Core Web Vital - Vin Lim

ถ้าอ่านแล้วงงหน่อยขออภัย ทางนี้ไม่ใช่สาย web เลยจะงง ๆ นิดหน่อย

UX เป็นเรื่องสำคัญ เป็นตัวชี้วัดเลยว่า user จะอยู่กับเว็บของเราต่อไหม โดยหลัก ๆ มี 3 อย่าง คือ Look, Feel และ Usability ซึ่งอันนี้ดูจะสำคัญสุด

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

Web vital ที่เรารู้จักกัน จะมี 3 อัน คือ

LCP (Largest Contentful Paint): loading performance เช่น โหลด content ขึ้นหน้าเว็บได้เร็วแค่ไหน มันจะวัดแบบ 1 by 1 อ่ะ เท่าที่ฟังนะ

CLS (Cumulative Layout Shift): input responsive ว่าเว็บเราตอบสนองกับการคลิกของ user ได้ไวแค่ไหน เช่น กด checkout ต้องคิดเงินแล้ว
FID (First Input Delay): Visual Stability

ถ้าเรา implement web vital ดี ก็มีผลที่ดีต่อ web ranking ของเว็บเราด้วยนะ แล้วแต่ละตัวคืออะไร ไปดูกัน

State of Core Web Vitals

จากเดิม 60% ตอนนี้เป็น +64% แล้ว

ซึ่งมันเพิ่มขึ้นเรื่อย ๆ ทุกปี เพราะอะไรก็ยังฟังงงๆ อยู่ น่าจะเรื่อง delivery good UX by optimise website แหละเนอะ

Gaps in First Input Delay

INP หรือ Interaction to Next Paint

เอามาวัดเรื่องการทำ action บางอย่างแล้วไปหน้าถัดไปโดยเฉพาะ โดยจะวัดจากการ tap, click, keypress

ค่า INP ของเว็บของเรา สามารถดูจาก PageSpeed Insights ได้

Toolbox

tool ที่ช่วยวัด และปรับปรุง UX ของเว็บเรา แล้วนอกจาก PageSpeed Insights ยังมีตัวอื่น ๆ อย่าง Web Vitals plugin, Chrome Devtools, Lighthouse, Unlighthouse, Chrome UX Report API

demo คือ check web vital กับเว็บ blocknomics สามารถ check ได้ จาก Chrome Devtools แล้วสามารถดู detail ต่าง ๆ ได้ด้วย

Unlighthouse ถึงจะคล้าย lighthouse แต่สามารถดู performance ราย page ได้ด้วยนะ

อันนี้สามารถอ่าน Chrome UX Report เพิ่มเติมได้เนอะ

Recommendation for optimise

บางอันถ่ายมาไม่ทัน กำลังฟังจับคำอยู่

LCP

ปรับพวก tag ต่างๆ อันนี้เรายังตามเขาไม่ค่อยทัน แหะ ๆ รู้สึกมันมี detail ประมาณนึง

Ensure the LCP resource is prioritized: prioiritized ใส่ใน tag ได้ด้วย แต่ละ web plalform มีปรับที่ตรงนี้ด้วย

Use a CDN to optimize document and resource TTFB: ใช้ CDN ในการช่วย optimise เว็บเรา มันจะช่วยให้เว็บเราไม่ทำงานหนักจนเกินไป

https://almanac.httparchive.org/en/2022/cdn#fig-1

CLS

กำหนด size ให้กับรูป

กำหนด aspect-ratio ของ video

set min-height & no layout shift

บาง element load นานมาก ให้ save to bfcache ก่อน และ test ด้วย Chrome DevTools และ Lighthouse 10 ได้

https://web.dev/articles/bfcache#test-to-ensure-your-pages-are-cacheable

https://developer.chrome.com/docs/lighthouse/performance/bf-cache/

หลีกเลี่ยงการใช้ animation หรือ transition ให้ใช้ transform แทน

FID & INP

หลีกเลี่ยงการทำ long tasks ให้แยก thread ใด ๆ แล้ว optimise มัน

avoid unnecessary javascript ดูเรื่อง code coverage ด้วย

https://developer.chrome.com/docs/devtools/coverage/

Firestore Advanced Queries by Derek Chan

เล่าถึงการวาง data structure ให้กับ Firestore ของเรา ทำให้การ queries ข้อมูลได้ง่ายขึ้น

Concept: one view, one collection ทำให้มัน sample ที่สุด โดยการหา data structure ที่เหมาะสมกับงานของเรา เช่นในที่นี้เป็นเว็บให้คะแนนร้านอาหาร ข้อมูลบนเว็บนี้จะเก็บลง Firestore เนอะ

ก่อนอื่นแยก collection ตามหน้า หลัก ๆ มี 3 หน้า คือ Users, Restaurants และ Ratings

จากนั้นแปลง View ที่มี เป็น Collection

View: List of Restaurants แสดงร้านอาหารพร้อม rating รวมของร้าน เราสามารถให้มันเรียงลำดับตามราคาได้

View: Search Result สามารถค้นหาร้านอาหารจากเมือง หรือจาก category ของอาหารก็ได้ โดยรับเป็น array เพราะสามารถใส่ได้หลายอย่างในการค้นหาเดียวได้ เช่น ต้องการร้านที่อยู่ในกรุงเทพ กับเชียงใหม่ หรือต้องการเมนูประเภท soup กับ curry หรือเลือกไม่เอาร้านที่ไม่มีประเภทอาหารนั้น ๆ ได้ สามารถทำ function ต่าง ๆ เพื่อรองรับแต่ละเคสต่าง ๆ ได้

View: Single Restaurant ข้อมูลร้านอาหารนั้น ๆ อันนี้ใช้ collection restaurant ในการหาร้านอาหารร้านนั้น ๆ โดยหาจาก id

View: Single User แสดงข้อมูลของ user คนนั้น ๆ พร้อมด้วยรีวิวของ user คนนั้น และมีการเพิ่มในภายหลังว่า เราได้ login account อะไรด้วย

Collections (Denormalization)

สามารถมองได้ว่า ก้อนของ Users และ Restaurants มีการใช้ก้อน Ratings เหมือนกันอยู่ แล้ว Ratings ควรอยู่กับก้อนไหนดี?

ที่ถูกต้องควรอยู่กับก้อน Restaurants

Indexes in Firestore

บน console สามารถดูข้อมูลการ queries ใด ๆ ได้

และสามารถทำ sub collection บน collection group ได้ด้วย แต่ถ่ายไม่ทัน แหะ ๆ

View: Search results ข้อมูลส่วน ratings คำนวณเรื่อง star ratings เฉลี่ย และรีวิวทั้งหมด สามารถทำผ่านตรง getAggrgateFromServer เพื่อนับ count และหาค่า average ได้

สรุปทั้งหมด

Designing Data Structures: ออกแบบ data structures ให้เหมาะสมกับโปรเจกต์ของเรา
Firebase Queries: สามารถออกแบบการใช้งานให้ยืดหยุ่นได้
Data Relation: แสดงความสัมพันธ์ของข้อมูลที่ซับซ้อน โดยการจัด data โดยใช้ subcollection และ query ระหว่างกัน
Aggregate Queries: ใช้งานได้ง่ายและทรงพลังสุด ๆ

Build a Generative AI Chatbot with PaLM API and Cloud Functions for Firebase 2nd Gen by Jirawat Karanwittayakarn

ในปีนี้ AI ถูก adopt ใช้ในชีวิตประจำวันมากขึ้น ใน session นี้จะเป็นการใช้ PaLM API ร่วมกับ Cloud Function for Firebase ที่เป็น 2nd generation

ก่อนหน้านี้ Google ประกาศเรื่อง AI first แล้วเขา develop ไปเรื่อย ๆ อย่างใน gmail มี feature ที่ชื่อว่า smart compose ตัวช่วยในการ reply email ว่าเราควรพิมพ์อะไรต่อไปดี

และอีก feature นึงคือ smart reply มี bubble ให้ติ๊กอยู่ เหมือนเป็น option ให้เราเลือกว่าจะตอบอะไรดี

และล่าสุดกับ Help me write อยู่ในช่อง reply ด้านล่าง ให้ AI คิดประโยคให้เรา และสามารถกำหนดความยาวความสั้นของประโยคตามใจเราได้

เช่นพี่ตี๋ทำ case หูฟัง pixel หาย อาจจะซื้อเคสใหม่ แต่เขาไม่ขาย เลยให้เป็นเงินมาแทน จะตอบ Thank you ก็ดูจะห้วนไปหน่อย เลยให้ AI แต่งประโยคให้ เราสามารถเรียนรู้การตอบ email เป็นภาษาอังกฤษจาก AI ได้ และเราเพิ่มลดได้เองนะตามความชอบของเรา

ตัว Bard รองรับ 40 ภาษา และรองรับภาษาไทยแล้ว สามารถใช้งานได้ฟรีเลย

ไปเล่นกันได้ที่ https://bard.google.com/ เลย

บทความ: เชื่อมต่อ PaLM ผ่าน LINE Chatbot ข้อจำกัดในที่นี้คือ ใช้ฟรี แต่ได้แค่ภาษาอังกฤษภาษาเดียว

https://medium.com/linedevth/linebot-palm-api-cloud-functions-a4a6751e46a8

ใน session นี้จะมีการเพิ่มเติม คือนำเอา Translate API มาช่วยแปลภาษาจาก output ที่ได้จาก PaLM แล้ว reply กลับไปหา user

ในที่นี้เราไม่ต้องเขียนโค้ดอะไรเองให้เยอะแยะวุ่นวายให้ยุ่งยาก เรามีตัวช่วย คือ Firebase Extension เป็น pre-package solution ที่เป็น plug & play ทำให้ build ได้ไวขึ้น

ในที่นี้จะใช้ 2 ตัว คือ

Chatbot with PaLM API ใช้ AI จาก PaLM มาตอบแชท ในตอนนี้ใช้ฟรี แต่ได้แค่ภาษาอังกฤษอย่างเดียว
Translate Text in Firestore ใช้แปลไทยเป็นอังกฤษขา input และอังกฤษที่ได้จาก AI เป็นไทย ขา outout

demo

ให้ทำการสร้าง project ผ่าน Firebase console จากนั้นไปที่ extension เพื่อไปตามหา extension ที่เราต้องการที่ Firebase Extension Hub

เราจะทำการค้นหา Translate Text in Firestore จากนั้นกดปุ่ม install เลือก project ที่เราต้องการ จากนั้นกด next ไปเรื่อย ๆ ส่วน config ที่ต้อง setting

Cloud Functions location: Tokyo (asia-northeast1) เลือกอันนี้เพราะใกล้กับ LINE
Target languages for translations: en
Translate existing documents?: No เพราะใช้ของใหม่เลย No ถ้าเอาของเก่ามาทำ เลือก Yes

อันอื่นเหมือนเดิม ไม่ต้องแก้อะไร จะได้ได้ตรงกันเนอะ

เมื่อเรียบร้อยแล้ว กด Install Extension รอ 3 - 5 นาที

กลับมาที่ Firestore เราลองเพิ่ม document แล้วรอผลแปปนึงว่ามันแปลเรียบร้อยไหม พบว่าเรียบร้อย ราบรื่นดี

จากนั้นค้นหา Chatbot with PaLM API กันต่อเลย ส่วนที่ต้อง config เพิ่มเติม

Palm API Provider: Vertex AI อันนี้เป็นตัวหลัก ถ้าเลือกเป็น Generative Language AI for developer ต้อง generate key แล้วเอา API Key ไปใส่
พวก collection ล้อตามเมื่อกี้ อย่าง Collection Path ใส่ translations ส่วน Prompt Field ใส่ translated.en และ Response Field ใส่ response
Cloud Functions location: Tokyo (asia-northeast1)
Language model: chat-bisan

จากนั้นลองสร้าง document ดูผลอีกรอบว่าทำงานถูกต้องไหม รอบนี้ยังทำงานดีเหมือนเดิม

สุดท้าย เอา result ที่ได้แปลเป็นไทย install translate text อีกรอบ เพื่อส่งกลับไปให้ user

Cloud Functions location: Tokyo (asia-northeast1)
Target languages for translations: th
Input field name: response
Translations output field name: reply
Translate existing documents?: Yes

ทดสอบอีกหนึ่งรอบ จบแบบสวยงาม

ขั้นตอนสุดท้าย implement กับ LINE Chatbot บน VS Code

สร้าง webhook ของ LINE โดยเราสนใจ webhook event ที่เป็น text เนอะ คือข้อความที่ user พิมพ์เข้ามา เอาอันนี้มา write data บน Firestore โดยเพิ่ม input ไป 2 อย่าง คือ text และ replyToken ที่มีอายุ 20 นาที เพียงพอในการทำงานแล้ว เพราะที่เราเห็นตอน demo ทำงานไวสุด ๆ

ส่ง message แล้ว มีการ interact ถ้า database มีการเปลี่ยนแปลงใน document นั้น ๆ ให้ reply ตัวที่แปลไทยเรียบร้อยแล้วไปให้ user event.data.after.data() ที่เราเห็นการเปลี่ยนแปลงในนั้นทั้งหมด มี 3 ครั้ง คือ ตอนที่แปลที่เราพิมพ์เป็นอังกฤษ ตอนที่ได้รับคำตอบจาก PaLM และตอนที่แปลคำตอบเป็นไทย เราสนใจครั้งที่สามเนอะ

จากนั้น deploy แล้วนำ url webhook ที่ได้ผูกกับ LINE Chatbot และลองของจริงเลย พบว่าสำเร็จได้ด้วยดี เย้ๆ ทางเราอัดคลิป demo มาด้วยล่ะ

Demo section ของพี่ตี๋ @Jirawatee "Build a Generative AI Chatbot with PaLM API and Cloud Functions for Firebase 2nd Gen" จากงาน Devfest Bangkok 2023
.
กล่าวถึงการสร้าง AI Chatbot ที่ถามภาษาไทย แล้วตอบกลับเป็นภาษาไทย ด้วย Firebase Extension 2 ตัว คือ
- Chatbot with PaLM API ใช้… pic.twitter.com/og0Dlu641Q
— Minseo (💙,🧡)🛸 (L3, ❄️) (@mikkipastel) November 4, 2023

แบบ YouTube

https://youtu.be/w1_yisMDhb8

อันนี้โค้ดหน้าที่พี่ตี๋อธิบาย

ฟังเสร็จได้ไอเดีย เอาไปใช้กับ discord ดีกว่า เห็นมีคนเอาไป plug กับ ChatGPT กัน

Ship Faster with Feature Flags by Session by Steve Wilber

aganda ในวันนี้

Continuous Integration vs Delivery vs Deployment

Continuous Integration (CI) เป็นระบบ auto ในการ integrate เช่น การ merge code ต่าง ๆ และการรันเทส

ส่วน Continuous Delivery (CD) จะเป็นระบบในการส่งมอบโค้ดเพื่อเอาไปใช้งานเนอะ โดยมันจะ depend กับตัว Continuous Integration (CI)

โดยเราคาดหวังว่าเราจะส่งมอบของ ในการขึ้นไปอยู่บน market ได้ไว และใช้เวลาอันสั้น และโค้ดจะต้องมีความเสี่ยงน้อย เพราะ code base ตัวนี้ต้องเอาขึ้นจริง แต่เราจะ deploy code ที่ยังไม่พร้อมได้อย่างไรบ้างนะ (เอ้ออแล้วทำไมนะ)

Source Control Branching Strategies

deploy vs release โดยการ deploy บน CD เราอยากให้ merge code บ่อย ๆ แต่โค้ดไม่พร้อมใช้จริง ไม่เหมือนการ release ที่ทุกอย่างต้องพร้อมในการส่งถึงมือลูกค้า ดังนั้นจะต้องเอา feature flagging มาช่วยด้วย

done คือสามารถใช้งานได้จริงบน prod และมีรอบ deploy ที่สั้น

ตามปกติที่เราทำงานกัน จะเป็นแบบ long-lived branches มี feature branch ที่ออก release ต่างกันไป ทำ feature นี้เสร็จค่อย merge

แบบ truck-based development ทำ feature นั้น ๆ โดยมี feature flags

และแบบ short-lived branches คือจะมี feature branch แต่จะ merge อันเล็ก ๆ เข้ามาเรื่อย ๆ โดยมี feature flags

long-lived branches → truck-based development → short-lived branches

Feature flagging

merge code ได้บ่อย มีการ roll back ได้ และเข้ากับ business goal

Test / Release / Monitor

Testing เราจะเทสกันที่ master branch แทนที่จะเป็น feature branch และทำ feature flag เพื่อเปิดปิดให้ tester ด้วย และสามารถเอาไปเทสแบบ integrate ได้เต็ม ๆ

Release / roll out พอมี feature flags เนี่ย ถ้าเจออะไรก็สามารถชะลอการเปิด feature นี้ได้ และสามารถ roll back กลับมาได้

Monitoring แน่นอนต้องดูผลด้วยเนอะว่าปล่อยไปแล้วเป็นยังไง มี performance เป็นยังไง คนใช้เยอะไหม

สรุปคร่าว ๆ จากที่ฟัง คือแบ่งรอบการ merge ให้ดีขึ้น ตามหลัก short-lived แล้วเปิดปิด feature นั้น ๆ ในการเทส

Putting it together in Firebase

แน่นอนว่า Firebase รับจบทุก process

Develop เปิดปิด feature flag ด้วย remote config

Deploy ส่งแอพไปเทสด้วย Firebase App Distribution

Test เทสโดยการเปิดปิด feature flag กับบางกลุ่ม user

Release เปิด feature แบบ prod มีการปรับ roll-out เป็น % ตามกลุ่มเป้าหมาย สามารถใช้ A/B Testing ในการทดสอบ feature ที่ทำได้

Monitor ดู crash ที่เกิดขึ้นผ่าน Crashlytics และดู performance ที่เกิดขึ้นผ่าน Monitoring ในการตรวจสอบ และ improve performance ต่าง ๆ ที่เกิดขึ้น และ Analytics ดูพวก active user, conversion, event, user engagement, total revenue และ lasted release

สรุปทั้งหมดจ้า

Managing a component library in Flutter - Yong Shean

แอบไปเข้าห้องนํ้ามา เนื้อหาคร่าว ๆ ที่จับใจความได้ คือเรื่องของการขึ้น design system บน Flutter project แหละมั้ง

คร่าว ๆ คือเราเป็น code เป็น class ของแต่ละชิ้นส่วนของ design เช่น class ของ text, class ของสี

ใน palette จะมีเรื่อง interaction, text, color กับอะไรสักอย่าง จดไม่ทัน แหะ ๆ

ตัว error color จะไม่ใช่สีของ accent กับ highlight นะ แนะนำให้แยกกันคนละสี

Typography: พวก text style ต่าง ๆ ที่ designer ออกแบบไว้ เช่น font-family weight text size

Space: margin และ padding ในส่วนนี้ developer และ designer ใช้แล้วต้องเข้าใจตรงกัน เวลาเอาไปลงใน Figma จะได้ไม่งง

Icons: น่าจะคล้าย ๆ พวก drawable ฝั่ง Android แหละ

สามารถติดตั้ง package ของ Taxonomy เพื่อ share design system ไป module อื่น ๆ ได้

widget มีความซับซ้อนมาก เราต้อง make sure ว่ามันจะถูก reuse ทีหลังได้ไหม

UI ←→ use case components เหมือนทำ custom view มาใช้ โดยการนำ UI มา extends widget

localising widgets ใส่ label (หรือใส่ text นั่นแหละ) ว่าแแสดงยังไง เหมือนใช้ string resource ฝั่ง Android

localisation-as-a-package: install package และใส่ generate: true และเพิ่มตัว local ทำ file arb ตามแต่ละภาษา และ generate ออกมา แล้วไปใส่ใน pubspec.yaml (คล้าย ๆ build.gradle ของ Android)

What's WidgetBook?

คล้าย ๆ Storybook เน้น ccomponent ในแอพ สามารถปรับแต่ง design และดูได้ว่าถ้าเกิด action แล้ว ทำอะไรต่อ

การ setup สร้าง new project และเอาของเพิ่มเข้ามาใน pubspec.yaml (คล้าย ๆ build.gradle ของ Android)

demo

ดู design แต่ละ category เช่น typography palette พวกสีต่าง ๆ ทำ gradient ได้นะ image สามารถกดเล่นได้นะ ดูเรื่อง localize ได้ด้วย

สรุปทั้งหมดก่อนจบ session

แล้วก็ contract ของ speaker เนอะ

Make for Large, Make for Fold with Flutter - Amorn Apichattanakul

Large คือมือถือจอใหญ่ขึ้น รวมถึงพวก TV ด้วย
Fold เริ่มมีผู้เล่นมากขึ้น นอกจาก Samsung ตอนนี้มี Oppo แล้ว Pixel ก็ลงมาเล่นในตลาดนี้ด้วย

session นี้ว่ากันด้วยการ design app เพื่อใช้บนจอใหญ่ หรือบน foldable ได้ โดยการปรับจูนนิดหน่อย โดยนำเนื้อหานี้ไป adapt concept เหล่านี้ได้ เช่น iOS เอาแอพลง iPad ส่วน Android ก็เอาลง Tablet และ TV

แล้วทำไมเราต้อง design เพื่อ support large screen devicec ต่าง ๆ ด้วยล่ะ?

มาดูตัวเลขพวกนี้กัน

มี 280M active large screen และ foldable device สำหรับ Android

และมี 333M active large screen สำหรับฝั่ง mac มี iPad กับ MacOs เนอะ

เมื่อดู market size แล้วพบว่า ถ้าเราทำแอพ support หน้าจอขนาดใหญ่ขึ้น เราจะได้กลุ่ม user ที่มากขึ้น โดยจะได้เพิ่มขึ้น 23% ของฝั่ง iOS และ 9% จากฝั่ง Android

การทำมี conept เดียวกันทั้งของ iOS และ Android เลย โดยการ adjust อะไรนิดหน่อย ก็สามารถใช้ได้เลย ที่เราเห็นกันบ่อย ๆ คือด้านซ้ายเป็น list กด item จาก list ก็แสดงหน้า detail ที่ด้านขวานั่นเอง

ภาพตัวอย่างจากทางเราเอง จาก Notion กลัวทุกคนไม่เห็นภาพตอนอ่าน 555

การทำแอพที่ support จอใหญ่ เช่น tablet คนจะใช้วลากับแอพนี้มากขึ้น 70% ซึ่งมัน make sense กับบางแอพ เพราะการใช้พวก tablet ส่วนใหญ่จะใช้ที่บ้าน อย่างตั้งใจ ทำให้มี user engagement มากกว่าการใช้แอพบนโทรศัพท์ ตัวอย่างก็คือแอพวาดรูปแหละ อย่างเราวาดรูปนึงก็ใช้เวลาประมาณนึง

source: https://android-developers.googleblog.com/2023/03/concepts-users-spend-more-time-using-app-on-tablets-than-phones.html

ฝั่ง Play Store ได้กล่าวไว้ว่า ถ้าเราทำแอพ support แอพบนจอใหญ่แล้ว

source: https://android-developers.googleblog.com/2023/07/introducing-new-play-store-for-large-screens.html

จะได้ ranking ที่ดีขึ้น และมีการ support การ promote ให้ด้วย
มี alert สำหรับบางแอพที่ไม่รองรับ tablet ด้วย ซึ่งปกติส่วนใหญ่เราจะ fix orientation เป็นจอแนวตั้งกัน ไม่ใช่ว่า dev ไม่อยากทำ แต่เป็นเรื่องของ business ด้วย
มี rating ของแอพแยกแต่ละ hardware ด้วย แบ่งเป็น mobile, tablet, Chrome OS, TV เช่นแอพนี้บน mobile ได้ 4.8 แต่บน tablet ได้ 2 งี้ ซึ่งมัน apply แบบนี้ เพราะ Pixel Fold กำลังจะออก (ส่วน Apple เหมือนจะมีข่าวลือว่าจะออก tablet แบบ fold ก่อน)

Benefit ที่ได้ ก็คือ

ได้ user เพิ่มมากขึ้น แค่ trigger ตรงนี้
user มีความ enjoy ในการใช้กับ tablet มากกว่า
แอพของเราถูกมองเห็นมากขึ้นบน Play Store เขาเลย convince ให้ developer ทำแอพ support จอขนาดใหญ่
เป็นเทรนในอนาคต

อยากเริ่มแล้ว ทำยังไงดี?

source: https://www.youtube.com/watch?v=QaTvA-rDny8

ทาง Google เขาทำแอพทั้งหมดของเขา รองรับจอใหญ่แล้ว

จอใหญ่ที่ว่า นอกจากมือถือ foldable แล้วก็ tablet

Continunity: ความต่อเนื่องในการใช้งาน ไม่ว่าจะเป็นการหมุนจอ การเปิดจอพับจอ และการใช้งาน multi-window ของ Android เวลาหมุนจอแลว state เดิมหาย ต้องโหลดหน้าใหม่ ซึ่งเหมือนตรงนี้จะมี ViewModel มาช่วยมาสักพักแล้วแหละ

Large screen experiences: concept ในการ reuse ของได้ ไม่ต้องไปทำหน้าเพิ่ม

Form factor hero experience: มี input เพิ่มให้ปวดหัวมากจึ้น เช่นพวก pencil ใด ๆ, keyboard ที่ถ้าเชื่อมต่อแล้ว จะเพิ่ม parameter บางอย่างให้ แล้วก็พวกถ่ายรูปจากกล้องหน้าหลัง มี UX ที่แตกต่างกัน (เรื่องเกี่ยวกับกล้องหน้าหลัง session ของงาน Android มีพูดถึงอยู่)

Letterboxing: มีการถมดำซ้ายขวา ให้กับแอพที่ไม่ support จอใหญ่ ของ iPad เมื่อกด x2 จะพบว่าจอภาพของแอพดูแตก

source เพิ่มเติมจาก slide ของ speaker

https://developer.android.com/guide/topics/large-screens/large-screen-compatibility-mode

แล้วเราจะ improve มันยังไงดี?

ของ Google ขอ 2 ส่วน คือ แอพต้องหมุนจอได้ ไม่ fix orientation และสามารถ resize จอได้

ของฝั่ง Android เขาแบ่ง checklist ออกเป็น 3 tier ด้วยกัน คือ

Tier 3 (Basic): สามารถ remove letterboxing ได้ ตัว font in UI ขยายแบบโง่ ๆ
Tier 2 (Better): เอา 2 screen มาชนกัน
Tier 1 (Best): ยังไม่เห็น use case เพราะ market ยังไม่น่าจับต้องขนาดนั้น

Guideline

layout, continuity and multitasking, สามารถ drag & drop ได้
windows size class: Jetpack ทำกับ Google ออกมาให้ใช้เป็น API

Flutter base size จาก iOS และ Android อยู่แล้ว

Demo

แอพนี้ใช้ Flutter ทำเนอะ ของฝั่ง iOS เพิ่ม dseatination ก็กลายเป็น tier 3 ล่ะ แล้วเพิ่ม iPad orientation ติ๊กมันทุกอัน

note: foldable ต้องแบ่งซ้ายขวา แต่ tablet ไม่เป็นต้องแบ่งครึ่งนึง

ตัว demo หรือการอธิบายต่าง ๆ อยากให้คนอ่านเห็นภาพมากขึ้น เลยเป็น video อันนี้จ้า

https://youtu.be/RsQvaX3xp6o

Diversity in AI - Fony Lewprasert

session จากทาง Women Techmakers ระหว่างฟังอยากไปเจนรูปเพื่อ proof เลยทีเดียว 555

หลาย ๆ คนคงจะสงสัย ว่าคอมมู Women Techmakers คืออะไร? คร่าว ๆ คือเขาผลักดันสาว ๆ ในสายเทคแหละ แต่ในตอนนี้ขอบข่ายขยายไปในเรื่อง diversity ด้วย ไม่จำเป็นต้องเป็นผู้หญิงเท่านั้นที่เข้าร่วมได้ ในไทยมี ambassador 2 คน คือคุณ Mils และคุณฝน ซึ่งคุณฝนเป็น GDG Cloud ด้วยน้า เขาก็จะมีกิจกรรมประจำ คือตอนเดือนมีนา ที่เป็นเดือนสตรีสากล

ใครสนใจไปสมัครสมาชิกเพื่อรับข่าวสารกันได้น้า

https://developers.google.com/womentechmakers/members

Bias

เริ่มเนื้อหากันด้วยเรื่องของ bias ซึ่งไม่ควรเกิดขึ้นใน model มี 3 แบบ คือ อายุ เพศ และเชื้อชาติ ไม่งั้นจะเกิดสิ่งชั่วร้ายขึ้น เกิด bias ระหว่างบุคคลใด ๆ กัน

แล้ว bias เกิดจากสิ่งใด? เกิดจาก data ซึ่ง AI จะ learn ไม่ได้ ถ้าไม่มี data

ตัวอย่าง เวลาค้นหาบน Google พบว่าพยาบาลมีแต่ผู้หญิง ส่วน developer มีแต่ผู้ชาย มีรูปผู้หญิงคนเดียว ที่เป็นรูปกราฟฟิก

ถ้าไป gen รูปด้วย prompt "CEO in Silicon Valley" พบว่ามีแต่ผู้ชายที่มีเชื่อชาติแตกต่างกัน แต่งตัวคล้าย ๆ กัน

แอบไปลองบ้าง บนเว็บ playgroundai.com ใช้ model Stable Diffusuion XL, filter Dreamshaper ได้ผลเหมือนกัน

เรื่องของ bias เกิดมานานตั้งแต่ก่อนยุค AI ครองเมือง เช่น product นึงปรับอุณหภูมิของแอร์ให้เย็นสบายตลอดเวลา ผู้ชายสบาย แต่ผู้หญิงหนาว แล้วตอน test product ทำไมตกสิ่งนี้ไปล่ะ? เพราะทีมเป็นผู้ชายล้วน เลยไม่รู้ว่าอุณหภูมินี้ หนาวสำหรับผู้หญิง

source: https://www.newyorker.com/tech/annals-of-technology/is-your-thermostat-sexist

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

ตรวจสอบแล้วไม่พบ source ตามใน slide นี้นะ แนะนำไปหาเอาเอง

ถ้าอยากรู้เรื่องพวกนี้เพิ่มเติม คุณฝนแนะนำหนังสือที่ชื่อว่า Weapons of Math Destruction หรือหนังสือแปลไทยที่ชื่อว่า บิ๊กดาต้า มหาประลัย กล่าวถึงการเอา AI ไปใช้ในทางที่ผิดในตอนนั้นยังไง เช่น บริษัทแห่งหนึ่งใช้ AI ในการ pre-screen candidate ที่สมัครงานเข้ามาในบริษัท เลยเอาทุกคนในบริษัทเป็นเกณฑ์ สิ่งที่เกิดขึ้น คือ AI คัดแต่ candidate ผู้ชาย ตัดผู้หญิงทิ้งหมด เพราะคนส่วนใหญ่ในองค์กรเป็นผู้ชาย หรือการที่ตำรวจจับตามองที่ที่เกิดอาชาญกรรรมบ่อย ๆ ทั้ง ๆ ที่มันสามารถเกิดได้ทุกที่

บน Generative AI ก็เช่นกัน เช่น มีคนอยากได้บาร์บี้ที่มาจากประเทศซูดาน ก็ดันเจนว่าเป็นบาร์บี้ที่ถือปืน ดังนั้นจะต้องระวัง data ไม่ให้ไปเหยียดคนบางกลุ่ม

source: https://www.youtube.com/watch?v=L2sQRrf1Cd8

แล้วทำยังไงให้ AI มัน fair เป็นมิตรกับชาวโลก?

จาก session นี้ของ Ted Talk เขาแนะนำว่า

source: https://www.youtube.com/watch?v=BRRNeBKWvNM

Aware of bias(es): ให้ระวังเรื่องของ bias เหล่านั้น ในตอนนี้ AI ทำงานดีมากขึ้น ทำงานอย่างระวังมากขึ้น
Diversity team: ได้ความเห็นและไอเดียต่าง ๆ จากทีมที่มีความ diverify จากหลาย ๆ ด้าน ได้ feedback ต่างกัน นำมาปรับปรุงข้อผิดพลาดต่าง ๆ ได้
Diverse Experience: ไม่จำเป็นต้องทำงานด้าน tech หรือมีพื้นฐานด้าน tech ทุกคนก็สามารถทำงานนี้ได้

แล้วเราใช้ tool อะไรในการป้องกันดีล่ะ?

What-If Tool: อันนี้ของ TensorFlow เอา class ต่าง ๆ เอามาจำลองสถานการณ์ ได้ ratio ที่เหมาะสม โดยใช้หลาย ๆ method เข้ามาช่วย แต่ของใหม่เขาใช้ LIT แทน

ไปหาเล่นกันที่ https://pair-code.github.io/what-if-tool/

Language Interpretability Tool (NLP): จาก LIT เป็น NLP เช่นมีข้อความอะไรบ้าง เราอาจจะลองแบ่งเป็น negative และ positive ดู และมี confusion matrix แต่ละ class ให้ด้วย

Know Your Data: อันนี้มี data class ต่าง ๆ ให้เราได้ลองเล่นกัน ไม่ต้องไปเก็บเอง

ตัวอย่าง เลือก dataset ของเซเลปผู้หญิงมา แล้วดู dataset ตามกลุ่มที่เราต้องการ

responsible AI หรือ AI ที่ดี มี 3 จุดมุ่งหมาย คือ possible issues, limitations, or unintended consequences

AI ควรที่จะโปร่งใส สามารถตรวจสอบได้, มีความ fair, เมื่อมีปัญหาเกิดขึ้น สามารถรับผิดชอบได้, เป็น AI ที่ถูกสร้างสำหรับทุกคน, model ผ่านการ research ว่า ok

Google's AI Guidelines มีทั้งหมด 7 ข้อ

เป็นประโยชน์ต่อสังคม
หลีกเลี่ยงความไม่ fair ที่จะเกิดขึ้น
ผ่านการเทสว่าปลอดภัยสำหรับทุกคน
มีความรับผิดชอบต่อผู้คน
ทำตาม privacy design principles
มีมาตรฐานที่สูง
ใช้งานได้ดีกับ AI ที่ทำตาม principle เหมือนกัน

สุดท้าย ทุกอย่างขึ้นอยู่กับ trust เป็นสิ่งที่ได้มายาก แต่เสียไปง่ายมาก (ซึ่งก็จริง จากประสบการณ์ในชีวิตที่เจอมา)

อยากเรียนรู้ความเชื่อใจเพิ่มเติม เอ้ยยยย การสร้าง AI ที่มีความรับผิดชอบต่อสังคม สามารถเรียนรู้ได้ที่นี่เลย

ท้ายสุด เดือนหน้าจะมี DevFest Cloud Bangkok 2023 ของทาง GDG Cloud เนอะ จัดวันที่ 17 ธันวาคม ที่นี่ที่เดิมเลย

รายละเอียดงานเหมือนจะมี agenda อะไรใด ๆ ออกมาแล้ว สามารถดูได้ที่นี่เผื่อใครสนใจจ้า (ทางเราไม่ได้ไปเน้อ ไม่ใช่สายนี้อ่ะ)

https://gdg.community.dev/events/details/google-gdg-cloud-bangkok-presents-devfest-cloud-bangkok-2023/

Testing strategy for Kotlin Multiplatform Apps

พบกับ session สุดท้ายของงานนี้แล้ว ว่าด้วยการ test บนโปรเจกต์ที่เป็น Kotlin Multiplatform

Kotlin Multiplatform ภาพง่าย ๆ คือนอกจากที่เราเอา Kotlin มาเขียนแอพ Android แล้ว ยังสามารถเขียนเว็บหน้าบ้านได้ เขียนฝั่ง server ได้อะไรงี้ รันแล้วสามารถใช้ได้ทั้งบนมือถือทั้ง Android และ iOS รวมไปถึงฝั่ง deaktop อย่าง macOs, Windows, Linux โดยเขาเน้นในการ reuse code

การแบ่งโค้ด จะมีส่วน Native Code ที่เป็น View ฝั่ง iOS และ Android และ Shared Code ที่จะเน้นพวก business logic ต่าง ๆ และการเรียกใช้ API ในส่วนนี้จะแชร์การทำงานกัน ไม่ต้องแยกเขียนของใครของมัน

การเดินทางของ Kotlin Multiplatform ในตอนนี้ stable แล้ว

ทำให้บางแอพของทีมที่ speaker เขาทำ สามารถเอาเข้า production ได้แล้ว ส่วนอันที่ดูคล้ายแอพเทรด อันนี้กำลัง release โดยใช้ Kotlin Multiplatform (ดีแล้วที่เซ็นเซอร์555)

แรงผลักดันในการใช้ Kotlin Multiplatform

Leverage new tech: เชื่อว่าจะนำพาออกจาก confort zone ทำให้ทีมเรียนรู้ในการใช้ tech ใหม่ ๆ ในการทำงาน
Engineering growth: เป็นการ upskill และ scale ในการเรียนรู้อะไรใหม่ ๆ
Centralization and Reusability: รวมโค้ดไว้ในที่เดียว และสามารถ reuse ได้ ทำให้ดูแลง่าย
More focus: ทำให้ focus ในการทำงานที่มี outcome ที่มีคุณภาพ

อันนี้เป็น Native Mobile Application Architecture ของเขาเนอะ ตัว shared module มีการใช้พวก RxJava, RxSwift ต่าง ๆ พวก data source, repository และ usecase ก็จะอยู่กันที่นี่ ในส่วนของ Native ก็จะใช้ ViewModel คุยกับ UI

frontend และ backend ต่างมี layer และความรับผิดชอบในส่วนงานต่าง ๆ ที่แตกต่างกันไป

goal ก็คือต้องการ develop ของได้ไวขึ้น ยังได้แอพที่มีคุณภาพที่ดีอยู่ และใช้ pattern ที่มี learning curve น้อย ๆ ในระหว่างการ adoption

ดังนั้นบน shared module จะใช้ coroutine with Flow ในการจัดการ แล้วใน ViewModel ก็รับของจาก shared module ด้วย Flow object

อันนี้เป็น benefit และ trade-off ต่าง ๆ

ฟังแล้วอยากทำ เราจะเริ่มยังไงดีนะ?

เริ่มจากสร้าง new project จาก Android Studio เลือก Kotlin Multiplatform เลือกเป็น app สำหรับฝั่ง native หรือ lib สำหรับฝั่ง shared

mono repository เราแบ่ง native module ของ iOS และ Android และพวก shared module ที่ทั้งสองใช้ร่วมกัน

basic ingradient ความเหมือนและความแตกต่างของแต่ละ OS

การทำงานระหว่างกันบนชั้น shared module

อันนี้ตัวอย่าง สามารถไปส่องกันได้

แล้วกลยุทธ์ในการ test ล่ะ?

Objectives: ได้ feedback เร็ว, สามารถทำงานร่วมกันได้, สามารถทำงานได้บนของจริง, ลดเวลาในการ regression และอะไรที่มันไม่ปลอดภัย, ไม่ต้องทำ document ของโค้ดของเราเยอะ

Structure: ตัวแอพสามารถเทสได้ทั้ง manual test และ instrumental testส ่วนตัว shared module สามารถทำ unit test และ instrumental test

tool ที่ใช้ในการ test ก่อนอื่นใส่ dependency กันก่อนเลย

Kotlin Standard Library Testing

Mockative

KoTest

KoinTest

การ run test จะทำแยกแต่ละ OS ประมาณนี้

สรุปสุดท้าย

Closing Remarks

มีถ่ายภาพร่วมกัน และสุ่มชื่อคนได้เสื้อเพิ่ม ทางเราไม่มีใครได้เสื้อกลับบ้านเพิ่มเลย

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

ทางเราไม่ได้เดินลงมา วิวจากข้างบนเป็นแบบนี้ เอาจริงแอบกังวลว่าจะเห็นหน้าเวทีแค่ไหนกันนะ

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