Videos → Using GitHub as a database for rich content and video processing

แนะนำตัวและภาพรวมของ session0:00

โอเคครับทุกคน สวัสดีครับทุกคน

อ่า ก็จะแนะนำตัวนะครับผม ผมริฟฟี่ จาก Creatorsgarten นะครับผม session นี้จะเป็น session co-host กับพี่ไทปังนะครับผม ก็จาก Creatorsgarten เหมือนกันครับ วันเนี้ย คือตาม title ของ speaker

title ของ session นี้เลยครับผม ยาวๆ เลยครับผม วันนี้จะมา พามาดูกันเนาะ ว่าแบบ ระบบหลังบ้านของ Creatorsgarten เราทำอะไรกันบ้าง

กระบวนการทำวิดีโอของ Creatorsgarten0:39

ซึ่งตรงนี้เราจะแบ่ง session เป็น 2 อย่าง ก็คือ part แรก เดี๋ยวผมจะเล่าเรื่อง process การทำวิดีโอของตัวงานให้ฟังกัน

ว่าเรา simplify process อะไรอย่างยังไง และใน session ที่สองเนี่ย ก็จะเป็น session ของพี่ไท ที่จะพาดู Contentsgarten ซึ่งเป็นระบบ- ซึ่งเป็นระบบ wiki engine หลังบ้าน ที่เราทำกันเอง แล้วก็ใช้ แล้วก็ utilize ระบบหลายอย่างของ GitHub เยอะมาก ก็ เกริ่นก่อนเลยละกัน ก็ Creatorsgarten เนี่ย เราฟอร์มมาแบบ officially ก็ประมาณ 1 ปี 2 เดือนแล้ว อ่า ก็ในช่วงนี้นะครับผม เราก็ จัดมาหลาย event อยู่ แล้วนอกจากจัดหลาย event แล้วเนี่ย ทุกๆ event ที่เรา live stream เราเก็บเป็น archive ไว้ด้วย ซึ่งอีก purpose หนึ่งที่เราเก็บ archives เนี่ย เพราะว่าเราก็จะเอาไป publishing ใน YouTube เป็น public archives เพื่อเวลา

เวลาคนอื่นเนี่ย สนใจ interesting ใน topic ของ session ก่อนๆ ที่เราพูดกันมาเนี่ย เมื่อก่อนเราไม่ค่อยมี event community ที่ไล่ทำแบบนี้กันเท่าไหร่ เพราะว่าของแต่ละอย่างมันจะกระจัดกระจาย ของ Creatorsgarten เราก็เลยมีการทำ trimming trim วิดีโอแต่ละ session post processing นิดหน่อย แล้วก็อัปโหลดขึ้นไปใน YouTube ด้วย

การเตรียมอุปกรณ์และความท้าทายในการ stream2:02

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

เรามีคอมพิวเตอร์ speaker ที่อาจจะมีแค่สไลด์อย่างเดียว หรือว่าบาง speaker เนี่ย อาจจะต้องเล่นเสียงวิดีโอด้วย เราก็ไม่รู้ใช่ไหมว่าแบบ เอ เขาจะใช้หรือเปล่า อะไรอย่างนี้ แล้วคราวนี้ เรื่องไมโครโฟนของ เรื่องไมโครโฟนที่ speaker ที่จะเอาไว้ใช้พูดอีก เพราะว่าถ้าเกิดในที่ Cleverse เนี่ย เราจัด Cleverse มาเยอะมากๆ ถ้าเคสแบบนี้ เรารู้และ เราชินแล้วว่าแบบ เออ set up ที่เนี่ย หน้าตาเป็นยังไง แต่เมื่อไหร่ก็ตาม เวลาเราย้ายไป venue อื่น ที่สถานที่อื่นๆ อันนี้ เป็นสิ่งที่เรียกว่า

uncharted space และ ก็คือว่า เราไม่รู้ว่าพื้นที่เขาอะ มีอะไร provide ไว้ให้บ้าง ซึ่งมันก็จะเป็นความเสี่ยงของเราอีก ถ้าเกิดเขาไม่มีไมค์ให้ อ้าว แล้วเราจะหาไมค์จากไหน เราจะหาทันไหม อะไรยังไง แล้วอีกอย่างหนึ่งก็คือว่า เราจะ full control ได้ไหม ถ้าเกิดว่าแบบ ผมพูดดังเกินไป อะไรแบบนี้ครับ

มันเป็น คือเราไม่สามารถ control เสียง เราไม่สามารถ control เสียง output ได้

การใช้งบประมาณเพื่อปรับปรุงระบบ3:23

คำตอบคืออะไร? คำตอบของการแก้ปัญหานี้ คือการใช้เงิน

เรา Creatorsgarten เนี่ย แต่ละ session แต่ละ event เนี่ย เรารับเงิน sponsor มาจากหลายเจ้ามาก ซึ่ง เราก็ใช้กันเกือบหมดแหละ

แต่อันไหนเราใช้ไม่หมด เราก็เก็บ เราก็เก็บ sum เอาไว้ แล้ว sum เป็น pool เราก็เอางบประมาณตรงนี้มา improve ระบบ workflow ของเรา ก็เราก็ simplify ทุกอย่างเลยครับผม ตัววิดีโอเนี่ย เราก็ feed เข้าไปในตัว ATEM Mini ซึ่งตัว ATEM เนี่ย เราก็ output มาทั้งวิดีโอ ภาพที่ออกโปรเจคเตอร์บนจอแบบนี้ และเสียงที่ไหลเข้าซอฟต์แวร์ บน Mac Mini ครับผม เอ่อ แต่ว่าบางทีเนี่ย solution ที่เราออกแบบมาดีแล้วอะ บางทีอาจจะดีไม่พอ เพราะว่าเรารับเสียง ไป stream ได้ใช่ไหม- เอ้ย เรารับเสียงออกลำโพง venue ได้ แต่ว่าบางทีอะ เขาไม่มีอุปกรณ์ เพื่อแบบ feed เข้าคอมฯ ได้ บางทีก็แบบ- (หัวเราะ) บางทีก็

hotfix เราก็ hotfix ไป คือมันใช้งานได้ไหม ใช้งานได้ แต่มันดีไหม ไม่ดี แต่ว่า Ain’t broke, don’t fix ถ้ามันใช้งานได้ ก็ไม่ต้องไปแก้ แล้วคราวนี้ เวลาเราไปแต่ละ venue เนี่ย เราก็มีการ logging ไว้ด้วยว่า การไปใช้สถานที่นี้ เขามีอุปกรณ์อะไรให้เราบ้าง เพราะเวลาเราไปจัดที่ไหนซ้ำๆ เราก็จะได้ไม่ต้องไปถามเขาอีกว่ามีอุปกรณ์อะไรบ้าง โอเค

กระบวนการหลังการ live stream และการจัดการไฟล์5:03

คราวนี้ พอเรา record session live stream เสร็จแล้วเนี่ย live stream หนึ่ง ก็อาจจะแบบ 3 ชั่วโมง อาจจะแบบ 3-5 ชั่วโมง ซึ่งไฟล์ที่ออกมาจาก OBS อะ มันใหญ่มากๆ แบบ 32 GB ซึ่งไซส์เนี้ย มันไม่สามารถที่จะเอาเข้าไปตัดใน Final Cut ได้ตรงๆ เพราะว่าถ้าเกิดยัดเข้าไปใน Final Cut อะ ค้างแน่นอน แปลว่าเราก็ต้องเอาไปนั่ง เราก็ต้องมานั่ง optimize ก่อน ซึ่งคำตอบตรงนี้

เรามี preset command ffmpeg ที่เป็น preset แบบเสร็จสมบูรณ์แล้ว เรา re-encode จาก archive ที่เป็น H.264 ไป H.265

ขนาดลงจาก 32 GB เหลือ 5 GB ซึ่งเป็นขนาดที่ sustainable พอที่เราสามารถเอาไปตัดใน Final Cut ได้ แล้วก็ archive ไว้ใน physical NAS ด้วย เผื่อใน event วันไหนเกิดขึ้นว่า เพจ Creatorsgarten กลายเป็นช่อง live stream Elon Musk แทน เราก็มีเคสสำรอง เราก็มีเคสฉุกเฉิน โอเค

การจัดการ content บน YouTube6:05

เราอัดวิดีโอแล้ว

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

มันจะมี consistency ในตัวเอง ก็คือว่าตัววิดีโอ

มันจะมี consistency ในตัววิดีโอ title ว่าเราขึ้นต้นด้วย session แล้วตามด้วย speaker หรือบางทีถ้าเป็น stream ก็เป็นอีก format หนึ่ง

ถ้าเกิดว่าเป็น session แบบหลายๆ คน

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

การใช้ GitHub เพื่อจัดการ video metadata7:07

พี่ไทก็เลย

ก็เลย ก็เลย craft tooling ขึ้นมาอันหนึ่งใน repo ของเราชื่อว่า videos ครับผม ซึ่งตัวนี้ ก็คือว่าเราสามารถจัดการ เราจะจัดการ video metadata ทั้งหมดผ่าน repository ได้เลย แล้วตัว bot ก็จะไป take effect แทน ก็เวลาเรา manage- หูว- เวลาเรา manage แต่ละ session เนี่ยครับผม เราก็สามารถสร้างเป็นไฟล์ markdown ที่มีข้อมูลเป็น YAML metadata ได้ว่าแบบ title เป็น title นี้ เป็น speaker คนนี้ effect กับ YouTube ID นี้ หน้าตาเป็นยังไง แล้วก็ video description อะไรเนี่ยก็ใส่ไป

แล้วเวลา บางวิดีโอ ที่แบบเป็นเคสพิเศษ

อย่างเช่น แบบเป็น session hackathon อะไรอย่างนี้ เราก็สามารถเขียน code เพื่อ

เพื่อดักเฉพาะ type แล้วก็ take effect video title ที่หน้าตาต่างกันได้ ส่วนตัว subtitle การ manage subtitle เนี่ย เราไม่จำเป็นต้องมานั่งเก็บไฟล์เอง เก็บไฟล์ local เอง หรือว่าเก็บ หรือว่าฝากกับ YouTube ไว้ตลอดเวลา เราอาจจะแบบ- ซึ่งในเคสนี้ ใน repo videos เนี่ย เราก็สามารถอัปโหลด ไฟล์ subtitle ที่เป็น format VTT ซึ่งเป็น global standard เนี่ย ใส่เข้าไป แล้วก็ป้อนออกมาเป็น subtitle ได้เลย

คราวนี้อีกอย่างหนึ่งก็

การสร้าง thumbnail ด้วย Figma8:38

อีกระบบหนึ่งที่เรามี ที่สังเกตเรื่อง consistency ไม่ได้มีแค่เรื่องแบบ video title และ description อย่างเดียว แต่ว่ามีในส่วนของ video thumbnail ด้วย ก็คือตอนแรกๆ เมื่อก่อนนะครับผม thumbnail ตั้งใจว่าแบบว่า จะทำให้แต่ละ event หน้าตาไม่เหมือนกัน เราจะได้แยกออกว่า event นี้คือ event นี้ แต่ว่าพอไปๆ มาๆ ครับผม พี่ไทก็แนะนำว่า เราทำให้มันแบบมี consistency เหมือนกับช่องสอนวิดีโอเกมมิ่งของ Sakurai นะครับผม

ก็ solutions ที่ได้มาครับผม ไม่ได้เป็นการ automate อะไรฮะ แต่ว่า เราเป็นการใช้ ระบบ templating ของ Figma ครับผม ก็คือแต่ละวิดีโอ เรามีเป็น preset template อยู่แล้วว่า เราสามารถ- เรามี header ข้างบนนี้ เราใส่ภาพวิดีโอเข้าไปด้านหลัง แล้วก็ตัว-

แล้วเราก็ใส่ text catch แล้วก็ใส่ text เอาไว้แบบว่าเหมือนเป็น เขาเรียกว่า catchphrase สักสองบรรทัดอะไรประมาณนี้ ซึ่งบวกกับระบบ Figma เป็นระบบที่แบบว่า versatile มากๆ ในระดับที่ว่าเราสามารถสร้าง header ข้างบนเป็น component ได้ แล้วเวลาเราเข้าไปแก้ component อะไรสักอย่าง แล้วเวลาเราเข้าไปแก้ component เนี่ย มันก็จะ take effect กับทุกวิดีโอเลยทีเดียว เราไม่จำเป็นต้องมา เราไม่จำเป็นต้องมานั่งแก้ header ของทีละอันๆ

แล้วพอไฟล์ทั้งหมดนี้ครับผม

พอไฟล์ทั้งหมดนี้เราคลุกกันเสร็จแล้ว เราก็จะ run event เราก็จะ run event ใน GitHub Actions ซึ่ง event GitHub Actions ก็จะไป take effect ใน YouTube อีกทีหนึ่ง คราวนี้เราทำระบบ ไปทั้งหมดเนี่ย คือทำไปทำไม

นั่นสินะ แต่ว่าเราทำไป เพราะว่าเรื่องเกี่ยวกับ ownership

คือ Creatorsgarten เราเป็นกลุ่มที่ เราเรียกว่าเป็นกลุ่มที่ open source หลายอย่างมาก ขนาด financial ว่าเราใช้เงินยังไงอะ เราก็ open source มีเว็บอยู่ แต่ว่าการ open source content พวกนี้ เราไม่สามารถที่จะแบบ grant grant คนดูทุกคน เป็น owner ช่อง Creatorsgarten ได้ใช่ไหม เราไม่สามารถให้ ownership ในระดับนั้นได้ แต่สิ่งที่เราทำได้คือ เราเอา repo videos เนี่ย ไปเป็น open source แล้วเวลาใครอยากจะ make change อะไรในวิดีโอ ก็สามารถส่ง pull request ขึ้นมา เพื่อที่จะแก้ไข content ในช่อง YouTube ได้จริงๆ อันนี้คือ concept ของตัว repo ของ videos แต่จริงๆ แล้ว

เรา utilize GitHub กับอีก feature หนึ่งด้วย ก็คือ channel banner channel banner ของ YouTube ซึ่ง banner ของ YouTube เนี่ย ผมตั้งใจว่าจะให้มัน adapt ไปตามแต่ละ event ก็คือว่าพอมี event นี้ก็จะ adapt ก็จะ adapt ไปอีกสไตล์หนึ่ง อะไรอย่างนี้ แต่ว่าตอนนี้ concept ยังไม่เสร็จ แต่ว่า

เราจะใช้ Affinity หรือ Photoshop มานั่งลาก event ใหม่ใส่เข้าไปตลอดเวลาไม่ได้

มันเสียเวลา เราเป็นสายขี้เกียจ อืม เพราะฉะนั้น

การใช้ GitHub Actions สำหรับอัปเดต YouTube11:55

เราก็มีอีก repo หนึ่ง ที่ชื่อว่า banner ซึ่ง concept ง่ายๆ เลยก็คือว่า เว็บข้างในอะ เรารันเป็น SvelteKit เสร็จแล้ว พอเวลา trigger event วันเนี้ย ก็ Puppeteer ก็เข้าไป fetch เป็นหน้าเว็บ capture ทั้งหน้าเว็บ กลายเป็นรูปภาพ เสร็จแล้ว ก็เอารูปนั้นอัปขึ้นไปใน YouTube ใน API ของ YouTube ซึ่ง action ตัวเนี้ย ก็รัน consistency อยู่เรื่อยๆ อันเนี้ย ก็จะเป็นตัวอย่างการใช้งาน เอ่อ การใช้งานของเราเหมือนกัน ก็เดี๋ยวพาดูอะไรเล็กน้อย โอเค ก็ตัวนี้ครับผม ก็จะมีอย่างตัวนี้ครับผม ตัววิดีโอ thumbnails ของวิดีโอเนาะ ก็เวลาเราแบบ จะสร้าง thumbnail ของ event ใหม่อะไรอย่างเงี้ย สิ่งที่ผมทำได้เนี่ย ผมก็แบบ อาจจะ ก๊อบ-วาง เพื่อแบบ align

grid align grid มาก่อนใช่ไหม แล้วก็อยากได้ header

อันนี้สักอันหนึ่ง พอเสร็จแล้ว สิ่งที่ผมทำได้คือ ผม detach ตัวนี้ออกไป

เป็นการ full demo เอ๊ะ ปุ่มลบเขา- เขาย้ายปุ่มลบทิ้งไปเหรอ

ช่างมันแล้วกันครับ ช่างมันแล้วกันครับ เราไม่สร้างใหม่ก็ได้ แต่สิ่งที่โชว์ให้ดูได้คือการ edit แบบเมื่อกี้ครับผม ก็คือตัวอย่าง Side Projects Showdown เราอาจจะเปลี่ยนใหม่ กลายเป็น Code Golf Party ก็ถ้าเกิดเรายิ่งมีวิดีโอเยอะครับผม ก็จะเห็นว่าเวลาเราแก้… เวลาเราแก้ component ไปทีเดียว มันก็ take effect กับทุกที่เลย สิ่งที่ผมต้องทำที่เหลือ แค่นี้ ตอนนี้ก็แค่แบบ หยิบเฟรมนี้ออกมา export มา

เป็นเฟรม เสร็จแล้วก็ได้ result เสร็จแล้วก็ได้ result เป็น thumbnail ที่พร้อมที่จะไป publish แล้ว ก็พอผมได้ไฟล์แบบนี้มาใช่ไหม ก็ตัวอย่างเช่น ตัว repo ของ repo video สิ่งที่ผมทำได้ก็คือว่า เนี่ยฮะ ผมก็ ผมก็เข้าไปใน repo video

แล้วคราวนี้ เวลาไฟล์ของ session ไหน ที่ผมต้องการจะอัปเดต

thumbnail ผมก็เอาไฟล์ JPEG นี้ ทับเข้าไป เสร็จแล้วก็ push ขึ้นไปใหม่ action trigger 1 นาที แล้วก็ take change ใน YouTube ทันที ก็อะไรประมาณนี้ ครับผม

ออกกลับมาก่อน

ก็อันนี้คือ process ทำวิดีโอของเราแบบสั้นๆ เนาะ แต่ตอนนี้ เราจะเป็นส่วนของ part ที่ 2 แล้ว เกี่ยวกับว่าเรา manage content-

แนะนำ Contentsgarten: ระบบ wiki ของ Creatorsgarten14:44

เรา manage content ใน wiki engine ของ Creatorsgarten ยังไง ซึ่ง ซึ่งตัว session นี้ ผมก็จะอัญเชิญพี่ไทขึ้นมา ขึ้นมาอธิบายครับผม เชิญเลยฮะ ครับ ครับ ขอบคุณน้องริฟฟี่นะครับ ก่อนผมจะเริ่มนะ ขอเสียงปรบมือให้น้องริฟฟี่ดังๆ นะครับ เพราะว่า content ใน channel ตลอด 2-3 หลายๆ เดือนที่ผ่านมา น้องริฟฟี่เป็นคน manage เอง เกือบทั้งหมดเลย ก็คือผมก็ set ระบบไว้ ทำพวก Figma ทำอะไรพวกนี้

แล้วก็น้องริฟฟี่ก็คือ ทำงานที่เขาเรียกว่าค่อนข้างถึกแล้วกัน คอยตัดคลิปออกมา คอยเช็กเสียงว่าเสียงมันโอเคไหม อะไรพวกนี้ แล้วก็อัปโหลดขึ้น YouTube ทำ thumbnail อะไรพวกนี้ คือแบบ ถึงเรามี automation แต่ก็ต้องยอมรับว่างานพวกนี้มันถึกมากๆ ก็ channel เราจะไม่โตขนาดนี้ถ้าไม่มีริฟฟี่ ครับ ก็ต้องขอบคุณ ริฟฟี่มากๆ ครับ แล้วใครยังไม่ได้ไป subscribe channel Creatorsgarten นะครับ รบกวนช่วยไป subscribe กันด้วยนะครับ เราอยากจะมี- เราอยากจะให้ content ของเราได้

ได้แบบมีคนดูกันนะครับ อะไรนะครับ? อ้า อยากได้โล่ - ตอนนี้เรามี ประมาณ 200 กว่าคนแล้ว ฮ่าๆๆๆ 400 แล้วใช่ไหมครับ อ่า ครับ ก็คืออันนี้ก็เป็น-

อีกเรื่องหนึ่ง ก็คือนอกจากเราแบบ run event แล้ว live งานของเราเองเนี่ย เราก็แบบมี partner กับ organizer เจ้าอื่นๆ นะครับ อย่างรอบนี้ของ Microsoft ใช่ไหม Spark Tech ใช่ไหมครับ ก็เนี่ย เราก็มา เราก็มาช่วย live แล้วก็มา grow channel นะครับ งั้นก็ ก็หวังว่าจะเป็นประโยชน์ครับ คราวนี้ สำหรับหัวข้อ part part หลังนะครับ จะเป็นเกี่ยวกับตัวเว็บไซต์ Creatorsgarten นะครับ ที่เรา อ่า ที่เรามีนะครับ อันนี้จะเป็นเว็บ Creatorsgarten นะครับ creatorsgarten.org นะครับ ก็ให้ดู feature คร่าวๆ ก่อนนะ ก็จะมีหน้าหลัก มีหน้าที่รวบรวม event ต่างๆ นะครับ แล้วก็มีสิ่งที่เรียกว่า wiki wiki เนี่ย ก็จะเหมือนเป็นคลังความรู้ของเรา ที่แบบ อะไรก็ตามที่เป็นความรู้ที่เรา สามารถ public ได้เนี่ย เราก็จะพยายามเอามาใส่ไว้ที่ตรงนี้นะครับ อย่างเช่น เรื่องการ set up streaming เนี่ย

อ่า ก็คือเมื่อก่อนเนี่ย ก็จะมีผมกับริฟฟี่ช่วยกันทำ แต่ตอนนี้ เราก็เริ่มถ่ายทอดความรู้ให้หลายๆ คน จะได้มาช่วยกัน stream งานต่างๆ นะครับ เนี่ย ริฟฟี่เขาก็เขียนใน wiki ไว้ว่าวิธีการเตรียม อ่า พวก set up OBS อะไรต่างๆ เนี่ยทำยังไง พวกนี้ก็อยู่ใน wiki นะครับ ซึ่งระบบ wiki เนี่ย

คุณสมบัติของ Contentsgarten17:21

อ่า ก็จะเป็นหัวข้อของ talk อันนี้นะครับ เพราะว่าเว็บ Creatorsgarten เนี่ย เราเขียนระบบ custom wiki system ไว้ใช้เองนะครับ คำถามคือ เออ

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

โอเค คือ กว่าเราจะมาถึงจุดนี้นะ เราก็ได้ลองดูหลายๆ solution นะครับ เราจะไปจัด solution ที่เก่าแก่ จนถึง solution ที่ modern สุด อย่างแรกก็คือ พวกโปรแกรมที่เป็น wiki software แบบ classic นะครับ อย่างเช่น MediaWiki DokuWiki PMWiki อะไรพวกนี้นะครับ

โปรแกรมพวกนี้ อย่างแรกคือ มันแก้ง่าย อันนี้เป็นจุดที่ผมชอบมากๆ เลย คือถ้าเราอยากจะแก้เพจ เพจไหนนะ เรากดปุ่ม edit พิมพ์ แล้วก็ save ได้เลย

มันมีสิ่งที่เรียกว่า the wiki way ครับ เขาบอกว่า จิตวิญญาณของ wiki หรือว่า ทางของ wiki คือเราพยายามทำให้ bad edits easy to correct ถ้าเราแก้อะไรผิดเนี่ย เราแก้กลับง่าย แทนที่จะ ป้องกันไม่ให้เกิดความผิดพลาดขึ้น มันจะได้เกิดการเปลี่ยนแปลงบ่อยๆ ถี่ๆ นะครับ ซึ่งโปรแกรม MediaWiki เนี่ย ก็ทำให้ edit ได้ง่ายมากนะครับ อย่างที่สองที่ผมชอบคือ ตัว wiki ซอฟต์แวร์พวกนี้ มันเป็น format แบบ plaintext plaintext ดียังไง คือเวลาผมจะแก้เนี่ย

บางทีผมสามารถก๊อบข้อความพวกนี้ ไปแก้ใน VS Code

แล้วก็ใช้ text editor ที่ผมชอบ พอเสร็จ ก็ก๊อบแปะกลับเข้าไป แล้วก็กด save เป็นเรื่องหนึ่งที่ผมชอบ ก็คือ plaintext นะครับ อีกอย่างหนึ่งก็คือ ระบบมันค่อนข้าง flexible ครับ อย่างเช่น wiki ตัวนี้ชื่อว่า TV Tropes นะครับ มันเอา PMWiki มาโม จนมันกลายเป็นเว็บของตัวเอง มี feature อะไรก็ไม่รู้เต็มไปหมดเลย ซึ่งเป็น wiki หนึ่งที่ผมชอบมากๆ

หรือตัว MediaWiki เองเนี่ย extension มันมีเป็นร้อยเลยครับ เราสามารถเอามาติดตั้งเพื่อ customize wiki ของเราได้นะครับ อันนี้ก็คือเรื่องที่ผมชอบเกี่ยวกับพวกโปรแกรม wiki นะ แต่ว่า

แต่มันก็จะมี pain point อย่างแรกก็คือ โปรแกรมพวกนี้ ส่วนมากจะเขียนเป็น PHP ฉะนั้นเวลาเราจะ deploy เราก็ต้องเช่า server มา แล้วก็ set up database อะไรพวกนี้ มันไม่ค่อยมีแบบที่ทำเป็น container มันยัง เรียกว่า tech stack มันไม่ได้เป็นแบบ cloud native เท่าไหร่นะครับ อ่า อีกอย่างหนึ่งก็คือ ผมไม่ค่อยชอบ syntax ของมัน ที่มันไม่ใช่ Markdown ครับ อย่างของ MediaWiki เนี่ย ถ้าเราจะทำตัวหนา ให้เราใช้ single quote สามอัน ซึ่งถ้าคนที่เขียน Markdown ก็งงไง ว่าแบบ เออ พอมาเขียน wiki ต้องเปลี่ยน syntax

ก็อาจจะไม่ชอบ อีกอย่างหนึ่งก็คือ พวก wiki พวกนี้ มันมาทั้ง package ฉะนั้นมันจะมาพร้อม theme พร้อมอะไรต่างๆ ซึ่งก็จะเขียนเป็นแบบ template PHP แล้วก็ใช้พวก jQuery ใช้ CSS ธรรมดาครับ ทำให้ถ้าเราอยากจะ customize ด้วย Tailwind หรือ React มัน integrate ค่อนข้างยากครับ อันนี้ก็ ก็เลยทำให้ไม่ได้เลือกใช้ซอฟต์แวร์ที่เป็น wiki สำเร็จรูปนะครับ option ที่ 2 ก็คือ static site generator มันเพิ่งมาบูมในยุคประมาณ 10 กว่าๆ

ก่อนหน้านะครับ ก็จะมีพวก Jekyll, Eleventy, Hugo, VitePress อะไรพวกนี้ สิ่งที่ผมชอบก็คือ มันเป็น plaintext เป็น Markdown เนาะ แล้วก็ content ต่างๆ อยู่ใน Git แก้ไขง่าย แถมพอ generate เป็น static file เนี่ย เราอัปโหลดขึ้น hosting ได้เลย ไม่ต้องดูแล server ด้วย อ่า

ก็จะมี GitHub Pages ที่สามารถ host พวก static site พวกนี้ รวมถึงเจ้าอื่นๆ เช่น Netlify, Vercel, Cloudflare Pages อะไรพวกนี้ เต็มไปหมดเลยครับ แต่ ข้อเสียที่ผมเจอ เวลาทำเว็บด้วย static site generator คือ การจะ contribute มันค่อนข้างยากครับ เพราะ traditional wiki ทั่วไปนะ เรากด edit แก้ save จบ เห็นผลทันที แต่พอมาเป็น static site generator พวกนี้ ผมต้อง fork repo แก้ แล้วก็ run dev server แล้วก็เช็ก เสร็จแล้วก็ commit push ขึ้นไป เปิด PR รอให้คนมารีวิว PR แล้วมันถึงค่อยขึ้นบนเว็บใช่ไหม อย่างอันนี้ ผมลอง contribute ไปที่ documentation ของ Next.js เนี่ย จะเห็นว่าผมแก้

doc แค่สองบรรทัด แต่ผมต้องอธิบายว่าผมแก้อะไร อีกเกือบสิบบรรทัด ประมาณเนี้ยครับ อ่า มันก็ทำให้การแก้เนี่ย มันค่อนข้างยุ่งยาก มันเป็นคนละทางกับ the wiki way ที่บอกว่า แก้ง่ายๆ revert ง่ายๆ

แถมเวลาจะแก้ที ผมต้อง clone repo มา แล้วก็ run dev server มันก็ไม่ค่อยสะดวก แถมพอแก้เสร็จ push เสร็จ ยังไม่เห็นผลทันที ต้องรอให้เว็บ rebuild แล้วก็รอให้มัน redeploy มันถึงจะได้ content ใหม่ ก็เลยทำให้ตัดสินใจไม่ได้ใช้ static site generator

เปรียบเทียบกับ Notion และข้อจำกัด22:29

แต่ว่าพอเรามาอยู่ในยุคนี้นะ มันจะมี tool หนึ่ง ที่ใน 4-5 ปีที่ผ่านมาเนี่ย มัน บูมมากๆ ก็คือ Notion ครับ ซึ่งจริงๆ เนี่ย เราก็ใช้ Notion กันเยอะมากๆ ตั้งแต่ปี 2019 เราใช้ Notion สำหรับเก็บพวกองค์ความรู้ สำหรับงานต่างๆ เต็มไปหมดเลยนะครับ ซึ่ง Notion เราชอบมาก ตรงที่ว่า เวลาเรารวมกันแก้หลายๆ คน UX มันดีมากๆ

แล้วก็ปัจจุบัน หลายๆ คนก็ใช้ Notion กันเป็นเกือบหมดแล้ว แต่สิ่งที่ผมยังรู้สึกว่ามันขัดใจก็คือ อย่างแรกคือ บางทีผมอยากจะใส่พวก bar chart หรือใส่พวก speech bubble หรือใส่พวก widget ที่มันไม่ได้มีใน Notion เราไม่สามารถ full control หน้าตาของเว็บไซต์ได้ขนาดนั้นนะครับ อย่างที่สองคือ ผมเกลียด sidebar ของ Notion ครับ เพราะว่าผมพยายาม- พยายามจะ organize content

ใน Notion ของผมเนี่ย ไม่ว่าผมจะพยายาม organize จัดระเบียบขนาดไหน สุดท้ายมันก็เละอยู่ดี ผมเลยไม่ชอบ sidebar ผมชอบให้แบบมีบทความลอยๆ อยู่ แล้วก็ลิงก์กันไปลิงก์กันมามากกว่า อีกอย่างหนึ่งคือ content มันอยู่ในรูปแบบของมันเอง ไม่ได้เป็น plain text ผมก๊อบออกมาแก้ใน VS Code แล้วแปะกลับเข้าไปไม่ได้ แล้วก็ถ้าใช้กันหลายๆ คน แล้วมีข้อมูลเยอะ ก็อาจจะแพง

ก็เลยลงเอยด้วยการสร้าง wiki engine

รายละเอียดเทคนิคของ Contentsgarten23:50

เองนะครับ ตัว wiki engine นี้ ชื่อว่า Contentsgarten ครับ เดี๋ยวให้ดู feature คร่าวๆ นะครับ เป็น open source headless modern cloud native นะครับ เป็น wiki engine นะครับ หลักๆ คือใช้ Markdown syntax นะครับ เวลา- ก็จะเห็นตัวเนี้ย เป็น Markdown เลย จะพิมพ์ตัวหนา ก็ดอกจัน ไม่ต้องจำ syntax ใหม่นะ

แล้วก็ content ต่างๆ เนี่ย เก็บไว้ใน Git ฉะนั้นถ้าเข้าไปดูใน creatorsgarten/wiki ก็จะเห็น ข้อมูลทั้งหมด เป็นไฟล์ Markdown แบบนี้ แล้วพอมันอยู่ใน Git เนี่ย ข้อดีคือ เราสามารถแก้บนเว็บตรงๆ ก็ได้ เรามี UI สำหรับแก้บนเว็บ แต่เราจะ clone repo มา เพื่อแก้ใน editor ของเราเองก็ได้นะครับ หรือปัจจุบันเนี่ย GitHub มีเว็บ github.dev ที่เป็น VS Code ที่อยู่ใน browser ทำให้เราสามารถแก้ content

โดยใช้ editor ของ VS Code แต่อยู่ในเว็บ อันนี้เราก็ integrate เรียบร้อยแล้วนะครับ คือถ้าเราเข้าไปที่ wiki ของ Creatorsgarten แล้วกดปุ่มจุดเนี่ย มันก็จะพาเข้าไปที่ github.dev ให้เลย

หรือพอเราใช้ VS Code แก้ สิ่งที่ได้ก็คือ เวลาเราเขียน เราก็จะไม่ได้เขียนคนเดียวแล้ว เพราะเรามี GitHub Copilot ช่วยเราเขียน แล้วก็ถ้าอยากจะแบบ make large scale change อย่างเช่น บางที ผมต้องการแก้หลายๆ ไฟล์พร้อมๆ กันนะ ผมไม่ต้องมานั่งเขียน script เพื่อยิง API ไปที่แบบ API Notion หรือ API นู่น API นี่ ผมดูด repo มา เขียน script แก้ไฟล์ แล้วก็ commit push กลับเข้า wiki เข้าไปได้เลยนะครับ

แล้วก็โอเค feature ถัดไปคือ มัน integrate กับ GitHub อย่างแน่นมากๆ เวลาเราแก้หน้าสักหน้า ใน Contentsgarten เนี่ย สิ่งที่เกิดขึ้นคือ มันยิง API ไปที่ GitHub API เพื่อแก้ไฟล์นั้นบน GitHub ตรงๆ เลย ก็คือเราใช้ GitHub เป็นแบบ source of truth ครับ แล้วพอข้อมูลอยู่บน GitHub มันก็ทำให้เราสามารถใช้ feature ต่างๆ ของ GitHub ได้ เช่น webhook นะครับ เวลามีใครแก้หน้าอะไรก็ตาม

ผม set up webhook ให้มันยิงเข้า Discord ฉะนั้นเวลาใครแก้เนี่ย ก็รู้ทันทีเลย ไม่ต้องเขียน code เลย เพราะว่ามันเป็น feature ที่ GitHub มีให้อยู่แล้ว ไม่ต้องมา implement เองครับ แถม

ด้วยความที่ Git มันมี history ให้ใช่ไหม เราไม่ต้อง implement feature ที่ว่าแบบ ดูว่าเพจนี้ถูกแก้อะไรไปบ้าง เวลากด history มันวิ่งเข้า GitHub เลย แล้วก็พอมันเป็นเว็บที่เราทำเองนะ เราก็สามารถทำ syntax ทำ component ต่างๆ ของเราได้เองนะครับ เช่น บางทีเนี่ย เราอยากจะให้มันมีการ discuss เกี่ยวกับ content บางส่วน แต่ยังไม่พร้อมที่จะเขียนเป็นบทความจริงๆ เราก็สร้าง speech bubble แบบนี้ อ่า เอาไว้คุยกัน เอาไว้แบบให้คนที่เป็น editor คุยกันได้ หรือบางทีเนี่ย เราต้องการจะ visualize แบบ feedback ของงานเนี่ย เราก็ทำเป็น chart แบบนี้

หรือ อ่า อันนี้เพจ- เพจนี้จะเป็นเพจที่รวม event ทั้งหมดของเรานะครับ เราก็จะมีลิงก์ที่เกี่ยวข้อง เกี่ยวกับแต่ละ event นะครับ จะเห็นว่าเป็น table ที่ค่อนข้าง advance นะ อืม แต่ว่า code เบื้องหลังเนี่ย มีแค่นี้

มันสามารถ render template ได้ครับ แล้ว template

ก็จะสามารถ query ข้อมูลจากเพจอื่นๆ เพื่อเอามา generate เป็นตารางได้ อันนี้คือใช้ภาษาที่เรียกว่า Liquid นะครับ ทำให้เวลา-

ทำให้เราไม่ต้องมานั่ง maintain ตารางตัวนี้เองครับ เวลาเราสร้างเพจใหม่ ตารางนี้มันก็จะอัปเดตตามนะครับ อ่า อันนี้ก็มาจาก feature ที่เรียกว่า front matter เนาะ ก็คือเราสามารถใส่ data structure ที่เป็น YAML ไว้ในแต่ละหน้าได้ แล้วข้อมูลพวกนั้นมันจะถูก ใส่เข้าไปใน database ซึ่งเราเอามา query ทีหลังได้ อย่างเช่น หน้า event ตรงนี้ ก็คือ เราก็ไม่ต้องคอยอัปเดตเองตลอด มันก็ไป query มาจาก database เลย ฉะนั้นเนี่ย feature นี้ ทำให้เราสามารถ implement feature advance ได้ อย่างเช่น เราก็เก็บพวก setting ต่างๆ ของเว็บไซต์ไว้ใน wiki เลย อ่า พวก feature flag ต่างๆ เนี่ย ก็เก็บไว้ใน wiki ไปเลย หรือแม้แต่พวก inventory ต่างๆ พวกอุปกรณ์ต่างๆ ที่เรา track ว่าใน Creatorsgarten มีอุปกรณ์อะไรเนี่ย เราก็มีหน้านี้ไว้ track ว่าเรามีอุปกรณ์อะไรนะครับ แต่ว่าเราก็ไม่ได้

เก็บข้อมูลเป็น

markdown นะ เราเก็บเป็น YAML แบบนี้นะ เสร็จแล้วเราก็เขียนแบบเป็น script เป็น template

ไว้ให้มัน generate เป็นตารางสวยๆ อีกทีหนึ่ง ฉะนั้นเนี่ย ข้อดีของการที่เราเก็บทุกอย่างเป็น YAML เนี่ย คือมัน machine readable เราสามารถเขียน script หรือ tool เนี่ย ให้มันมา อัปเดตข้อมูลนี้ได้ นั่นแหละครับ ก็ผมชอบที่มันเป็น open data สุดท้ายก็คือ มัน headless ครับ ไอ้หน้าเว็บที่เห็นอยู่เนี่ย ไม่ได้เป็นส่วนหนึ่งของ Contentsgarten นะ เพราะว่า Contentsgarten มีแค่ API นะครับ อ่า มี API แบบนี้ อย่างเช่น เรายิง API Contentsgarten search ส่ง match event location เป็น Cleverse เนี่ย เวลาเรายิง API ตัวนี้ มันก็จะหา event มันก็จะหาหน้าทั้งหมด ที่

event.location เป็น Cleverse ก็คือเราเอาข้อมูลใส่เข้าไปใน wiki แล้วเราก็ถามคำถาม wiki มันก็จะตอบกลับมาได้นะครับ โอเค

สรุป tech stack ของ Contentsgarten29:31

ต่อไป อันนี้ก็คือ feature คร่าวๆ ของระบบนี้ เรามาดู tech stack กันดีกว่า หลักๆ ก็คือ ตัวเว็บไซต์ก็จะเป็น repo หนึ่ง เขียนด้วย Astro ถ้าไปงาน BKK.JS รอบก่อนใช่ไหม ริฟฟี่ก็แนะนำ Astro

ถ้าอยากรู้เรื่อง Astro นะครับ ก็ไปดู talk ย้อนหลังได้ใน channel YouTube นะครับ แล้วก็ตัว backend ก็คือ Contentsgarten ก็จะอยู่ที่ repo นี้นะครับ การทำงานก็คือ มันก็จะคุยกับ GitHub API เพื่อดึงข้อมูลจาก repositories ที่เราถือว่าเป็น source of truth แต่

จำตัวอย่างที่เราหา event ทั้งหมด ที่จัดที่ Cleverse ได้ใช่ไหม แต่ GitHub API มันไม่มี API ไว้ query ของแบบนี้ เราเลยต้องเก็บ database อีกอันหนึ่ง ไว้เป็น cache เป็น index ฉะนั้น source of truth จะเป็นอันนี้ แต่ว่าข้อมูลมันจะไหลมาที่ MongoDB แล้วเราจะมีการจัดรูปแบบข้อมูล เพื่อให้สามารถ query ข้อมูลที่อยู่ในแต่ละไฟล์ได้

ดังนั้นอันนี้ก็คือตัว content Contentsgarten นะครับ ก็มา

บทสรุปและข้อดีของการใช้ GitHub ecosystem30:40

conclusion กันดีกว่า

takeaway สำหรับ talk นี้ก็คือ ผมรู้สึกว่า ecosystem ของ GitHub มันทำให้เราสามารถสร้างระบบ wiki แบบ custom ได้อย่างรวดเร็วครับ ผมคิดว่าถ้าเราไม่มีพวก

webhook หรือว่า API ของ GitHub ที่มี API ที่แบบเก็บ history หรือเครื่องมือต่างๆ พวก GitHub.dev อะไรแบบนี้ หรือแม้แต่ GitHub Copilot ที่ช่วยผมเขียน code เนี่ย การจะสร้างระบบแบบนี้ มันน่าจะใช้เวลานานกว่านี้เยอะมาก คือต้องบอกก่อนว่า ตัว Contentsgarten มัน barebone มากนะ ขนาดแค่ลบเพจเนี่ย มันยังทำไม่ได้เลย แต่ผมไม่ต้อง implement เพราะว่าเราลบเพจไม่บ่อย เมื่อไหร่ก็ตามที่ผมอยากจะลบเพจนะ ผมกดเข้าไปใน repo แล้วก็ลบไฟล์ทิ้งเลย อ่า ไม่ต้อง implement เอง

ก็คือเรา stand on top of the shoulder of giants เนาะ อ่า

อย่างต่อไปก็คือ data ที่เราเก็บเป็น plain text แล้วเก็บไว้ใน Git ทำให้เราสามารถ build ของ ต่อเติม ต่อยอดได้ โดยที่ไม่ต้องใช้ API พิสดารอะไรแบบนี้ครับ ไอเดียหนึ่งที่เคยคิด ก็คืออยากจะลองดูว่า แต่ละหน้ามันเชื่อมกันอย่างไร อันนี้ผมทำกับเว็บตัวเองดูแล้ว แต่ว่ามันก็อาจจะเจ๋งดี ถ้าเราดูได้ว่าหน้าแต่ละหน้ามันแบบ

เชื่อมกัน แล้วมันกลายเป็น เขาเรียกว่า knowledge graph หรือ tool นี้ก็ grtn.org นะครับ ก็เป็น link shortener ที่ Creatorsgarten ใช้กันเองเนาะ เมื่อก่อนเนี่ย เราอาจจะต้องแบบให้ access bit.ly หรือว่าใช้บริการของบางเจ้าที่มันอาจจะแพง

อ่า แต่ว่าพอเรามี Contentsgarten เนี่ย เราก็เอาลิงก์ทั้งหมดไปเก็บไว้ใน wiki แล้วก็เขียนโปรแกรมให้ grtn.org เนี่ย ดึงข้อมูลจาก แบบ front matter ตรงนี้ แล้วก็จัดการ redirect ให้ ก็ผมก็มองว่าแบบ พอ data มัน open แล้วก็เอามาทำอะไรต่อยอดได้ง่ายครับ หรืออย่างใน channel YouTube เมื่อกี้ ที่ ริฟฟี่โชว์ให้ดูว่า banner ของ channel เนี่ย มันเป็นโลโก้ของ event

ต่างๆ ที่เราจัดนะ ไอ้เนี่ยก็ดึงข้อมูลมาจาก wiki เหมือนกันครับ แต่ก็ต้องบอกก่อนว่า เครื่องมือสุดท้ายเนี้ย เครื่องมือนี้ มันก็ไม่ใช่ silver bullet หลายๆ คนก็บ่นเหมือนกันว่า ไม่ชอบที่มันเป็น plain text อยากจะให้ editing experience มันเหมือน Notion อะไรแบบนี้ ใช่ไหม อืม

หรือบางทีเนี่ย มีบาง content ที่อาจจะ public ไม่ได้ หรืออาจจะไม่ practical ที่จะ public ผมก็แนะนำว่าแบบ อืม ก็ให้ใช้เครื่องมือ use the right tool for the right job ครับ ก็คือถ้าจะประชุมกัน ก็ใช้ Notion ไปก็ได้ หรือใช้ Google Docs ถ้าจะเก็บเป็นตารางก็ Google Sheets ถ้าจะ design ก็ Figma ก็ใช้เครื่องมือ ก็ใช้ right tool for the right job แต่ว่า เรื่องหนึ่งที่ผมก็จะ encourage ให้มีก็คือ พยายามให้ทุกอย่างมัน

reachable จาก wiki หมายถึง reachable ในที่นี้ หมายความว่า ถ้าเราไปที่หน้า wiki มันควรจะมีเส้นทางจาก จากหน้าเว็บไปยังข้อมูลชุดนั้น อย่างเช่น ถ้าเกิดผมอยากจะไปดูว่า ตอนที่เราจัดงาน Stupid Hackathon ครั้งที่ 2 เนี่ย ซึ่งอันนั้นเมื่อปี 2018 เมื่อประมาณ 7 ปีที่แล้ว proposal เราเขียนอย่างไรบ้าง เปิดหน้าเว็บเข้าไปที่ wiki แล้วก็ไปดู list of event แล้วก็ไปดูที่ Stupid Hackathon Thailand เข้ามาที่หน้าที่เป็น coverage ในนี้ก็จะมี list document ก็จะมี information for sponsor สมัยนั้นเรา ยังไม่ได้ใช้ Notion นะ สมัยนั้นเราเก็บไว้ใน Dropbox Paper

ไม่รู้ใครเคยใช้กันไหม Dropbox Paper อ่า อาจจะมาก่อน Notion ครับ อ่า แต่ว่าสรุปก็คือ ไม่ว่าข้อมูลอยู่ที่ไหนเนี่ย มันอย่างน้อยมัน reachable จาก จากหน้าหลักของเรา มันก็จะทำให้เราสามารถ- ความรู้ของเราก็จะไม่หายไป ถ้ามันยัง reachable อยู่นะครับ ดังนั้นอันนี้ก็เป็น conclusion

การจัดการความรู้และการเข้าถึงข้อมูล34:55

ที่อยากจะสรุปใน talk นี้นะครับ ก็อันนี้ก็จะเป็น ลิงก์ repo นะครับ แต่ว่าไม่ต้องจำก็ได้นะครับ ไปที่ wiki แล้วก็ไปดูที่ tech stack นะครับ ก็

สำหรับ session ของผมก็คงจะมีแค่นี้ครับ ก็

ขอบคุณทุกคนมากครับ แล้วก็

มีคำถามอะไรไหม ทั้งเรื่องวิดีโอ ทั้งเรื่อง content การเต้น หรืออะไรแบบนี้ เสริมคำถามได้ครับ พร้อมตอบตลอด ครับ

คำถามและตอบเกี่ยวกับการประเมินผลโครงการ35:27

ใช่ค่ะ ก็จะถามว่า เท่าที่เห็น มันเป็นแบบการทำ project planning ใช่ไหมคะ ทีนี้ อยากจะเห็นเรื่องของ evaluation ว่า เราเอาผลจาก evaluation form มาพัฒนาการจัดโครงการยังไงบ้างคะ มี database ด้านนี้ไหม อะไรทำนองนี้

ค่ะ โอเค หมายถึงแบบ พอดีว่า ถ้าหลังจากเราจัดโครงการไปแล้วใช่ไหมคะ ก็จะมีแบบ feedback form ว่าตรงนี้ควรปรับอย่างนั้นอย่างนี้อะไรอย่างเงี้ย เรามีการสรุปข้อมูล ประมวลผลข้อมูลยังไง ให้เราพัฒนาการจัดงานในอนาคตได้ดีขึ้นได้บ้าง มีการทำแบบ data ตรงนี้ไว้ไหม สำหรับพัฒนาทีมงาน อะไรทำนองนี้ค่ะ โอเคครับ อ่า โอ้ ขอบคุณมากครับ โอเคครับ ขอบคุณสำหรับคำถามนะครับ ก็อันนี้คือ feedback ของงาน Stupid Hackathon ครั้งที่ 7 นะครับ งานล่าสุดที่เราจัดนะ หลังจากที่จบงานเนี่ย เรายิง Google Form ไปถาม คำถามส่วนมากจะถาม 5 ข้อ 1. ชอบอะไร

2. อะไรควรปรับปรุง 3. อยากให้เราลองทำอะไร แล้วก็ข้อ 4. ก็คือให้คะแนน 1-10 แล้วก็ 5. บอกว่าอยากจะพิมพ์อะไรในนั้นก็พิมพ์ไปเลย เสร็จแล้วผมก็เอาข้อมูลทั้งหมด เอามาใส่ใน wiki ครับ ฉะนั้น staff รุ่นต่อๆ ไป จะสามารถไปดูใน list ของ event เพื่อดู feedback ของงานก่อนๆ ได้ ก็คือมันก็จะไม่หายครับ

ใช่ครับ อย่างของ Stupid 7 ชอบกิจกรรมอะไรมากที่สุด แต่ละคนที่ตอบมา เราก็จะ list ไว้ เสร็จแล้ว ที่ตอบมา เราโยนไปให้ ChatGPT สรุปออกมา

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

ทีมงานที่จัดงานรอบต่อๆ ไป

ก็สามารถเข้ามาดูได้ รวมถึง ideas for next year คล้ายๆ ว่า ถ้าอยากจะรู้ว่า คนที่จัดรุ่นก่อนหน้าเนี่ย มีไอเดียอะไรบ้าง

ก็เข้ามาดูพวกนี้ เข้ามาดูแบบสรุปที่เราคุยกันได้ครับ

แล้วก็จะมี เดี๋ยวขอหาแป๊บนึง

data นี่ครับ นอกจากนี้ เราจะมีเก็บ data ต่างๆ ของงาน Stupid เราจัดมา 7 รอบ เราก็มี keep track ว่า ในแต่ละปีเนี่ย มีจำนวนทีมกี่คน ticket เท่าไหร่ presenter มีคนมา present ผลงานกี่คน event rating อะไรแบบนี้ พอกดๆ ดูที่ event rating มันก็จะพาไปดู feedback อันนี้ก็คือเป็นวิธีที่เราเก็บ feedback ในงานต่างๆ ไม่ให้มันหายไปครับผม ตอบคำถามไหมครับอันนี้ โอเคครับ

มีคำถามเพิ่มเติมไหมครับ

สรุปและปิดการนำเสนอ38:50

โอเค งั้นก็น่าจะประมาณนี้ ขอบคุณพี่ไทกับริฟฟี่มากครับ วู้ว

เย้ เจ๋งมากเลยเนาะพี่ช้าง ได้ฮะ โอเค ก็เดี๋ยวรอ set up กันก่อนเนาะ เป็นยังไงบ้างครับ ปั๊บ เห็นวันนี้ โห - เพิ่งรู้ว่า Bitbucket ทำอะไรได้เยอะเลยฮะ - โอ๊ย เฮ้ย ยังอยากได้สติ๊กเกอร์ GitHub อยู่ ไอ้นี่ก็- โอเคครับ เอ้ย พูดผิด ก็เพิ่งรู้ว่า GitLab ทำอะไรได้เยอะเลย ก็จะไม่ได้จัดเพราะอย่างงี้แหละ