Posts

ช่วง 2 เดือนที่ผ่านมาเป็นช่วงเวลาที่ผมเริ่มหัดใช้ Emacs จาก 0 เลยซึ่งจากใจคนที่อยู่บน Vim และ Jetbrains ecosystem มานาน ผมค้นพบว่า มันมีหลายๆ อย่างมากที่ Emacs ทำได้ดีในแบบของมันและหลายๆ ครั้งเป็นแรงบันดาลใจให้โปรแกรมอื่นๆ ด้วย และจากชื่อที่มี EP1 แน่นอนครับว่า ผมไม่ได้มาเดี่ยวๆ เดี๋ยวมันจะพาลูกตามมาอีกเรื่อยๆ ก็คอยกดติดตามซีรีย์นี้กันได้ครับ สำหรับในตอนแรกนี้ ผมจะเล่าถึงวิธีการ ที่ผมศึกษาวิธีใช้ Emacs ในช่วงที่ผ่านมาครับ ซึ่งถ้าใครขี้เกียจรอตอนต่อๆ ไป ถ้าดูตามวาร์ปที่ผมลิสต์ไว้ก็ไปได้ไกลละครับ อย่างแรกเลยวิธีติดตั้ง Emacs ใน Mac เหมือนจะง่ายแต่ต้องรู้ ปกติเวลาเราจะลง Software อะไรใน Mac ถ้าแบบไม่คิดเลย เราจะมุ่งไปหา Homebrew ซึ่งแค่ brew install emacs แค่นี้ก็ใช้ได้ละ แต่ปัญหาคือ Binary นี้มันไม่ได้ถูก Optimize มาให้ Mac ซักเท่าไร จะเจอปัญหาปุ่ม Command บ้าง แต่ที่หนักที่สุดคือ Window mode นี่แหละ ซึ่งผมผู้ใช้งาน Magnet อยู่ทำงานกับ Emacs ด้วยไม่ได้ เพราะ Window Snapping ไม่ทำงาน (link) ...

ไปเจอ Repository นี้มาใน GitHub ครับ เป็นการตีความ Principles of Good Design ในตำนานของ Dieter Rams ในมุมของ Software Engineering ซึ่งมีอยู่ 10 ข้อด้วยกัน ผมเห็นว่าน่าสนใจดี เลยแปลมาฝากกัน \1.ซอฟท์แวร์ที่ดีต้องเป็นนวัตกรรม (Good software is innovative) ปรับปรุงซอฟท์แวร์เก่าด้วยเทคโนโลยีใหม่ๆ หรือสร้างซอฟท์แวร์ใหม่ด้วยเทคโนโลยีที่มีอยู่แล้ว จงพยายามที่จะสร้างสรรรค์สิ่งใหม่แก่โลกใบนี้ ถึงแม้สิ่งนั้นจะเป็นการลอกจากสิ่งที่มีอยู่ สังเกตุผู้ใช้เพื่อหาแรงบันดาลใจและพยายามทายใจว่าเขาอยากได้อะไรต่อไป \2.ซอฟท์แวร์ที่ดีต้องมีประโยชน์ (Good software is useful) ซอฟท์แวร์ต้องมีค่ากับผู้ใช้ มันควรทำให้เขามีชีวิตที่ดีกว่าเดิมโดยการเติมเต็มสิ่งที่ขาดหรือแก้ปัญหาให้กับเขา เราควรเก็บข้อมูลว่าซอฟท์แวร์เรามีค่ากับผู้ใช้งานเท่าไรอยู่เสมอ เพื่อทำให้มันมีค่าต่อๆ ไป \3.ซอฟท์แวร์ที่ดีต้องมีศิลปะ (Good software is aesthetic) ลองถอยกลับมาดูโค้ดของเราบ้าง มันควรดูงดงามในมุมมองของเรา ความงดงามนั้นบ่อยครั้งเกิดจากคุณสมบัติหลายๆ อย่างรวมกันขึ้นมาทำให้โค้ดที่งดงามต่อเรานั้นมักจะมีความ เข้าใจง่าย เป็นไปตามหลัก(ภาษา) และอธิบายตัวมันเอง ซึ่งเราในฐานะโปรแกรมเมอร์ให้คุณค่ากับสิ่งเหล่านี้ \4.ซอฟท์แวร์ที่ดีต้องเข้าใจได้ (Good software is understandable) โค้ดนั้นไม่เทพ ถ้าไม่มีใครสามารถเข้าใจมันได้ โค้ดเทพมักจะทำให้เราเกิดคำถามและข้อสงสัย โค้ดที่เข้าใจได้ต้องตรงไปตรงมากับคนอื่นและแม้แต่ตัวเราในอนาคต มันควรจะเขียนขึ้นมาโดยนึกถึงความเข้าใจของคนดูแลก่อนเสมอ ตามด้วยเครื่องจักร \5.ซอฟท์แวร์ที่ดีต้องตรงไปตรงมา (Good software is honest) เลี่ยงที่จะตั้งนามธรรม (abstraction) ที่เราไม่ต้องการ เลี่ยงที่จะห่อทุกอย่างโดยไม่คิด พยายามทำความเข้าใจเหตุผลของทุกอย่างก่อนที่เราจะเขียนมันไปเป็นโค้ด กล้าที่จะเปิดเผย ตัววัดคุณภาพซอฟท์แวร์ที่คุณรู้สึกลำบากใจเช่น ความครอบคลุมของชุดทดสอบและสิ่งที่เราไม่ควรทำ ทำให้สิ่งเหล่านี้หยุดยั้งการสร้างซอฟท์แวร์ของเรา เพื่อที่เราจะได้หาเวลาหรือความช่วยเหลือมาเก็บกวาดสิ่งเหล่านี้ ...

ใน ตอนที่แล้ว เราพูดถึงคีย์บอร์ด Ergodox EZ ไปแล้ว ในตอนนี้ผมจะมาพูดถึงตัว Dvorak Keyboard Layout บ้างในตอนนี้ว่าทำไม ผมถึงเลือกใช้ตัวนี้และผมเดาว่าหลายๆ คนน่าจะมีคำถามว่า เปลี่ยนแล้วพิมพ์เร็วขึ้นเหรอ เดี๋ยวผมจะมาตอบคำถามในตอนนี้นะครับ Dvorak ก่อนอื่น ถ้าใครเคยสังเกตุคีย์บอร์ดที่เราใช้อยู่กันปกติ ถ้าเป็นแป้นภาษาอังกฤษจะอยู่บนพื้นฐานของ Layout ชื่อว่า QWERTY ครับ ซึ่งใช้มาตั้งแต่ยุคเป็นเครื่องพิมพ์ดีดมา ซึ่งลือกันว่าที่ Layout ถูกวางแบบนี้เพื่อที่จะให้แป้นพิมพ์ขัดกันน้อยที่สุดในยุคนั้นครับ แต่จริงๆ เรื่องนี้มีอะไรมากกว่านั้นครับ ถ้าลอง Search ดูจะสนุกมาก แต่ไม่ใช่ประเด็นหลักที่ผมจะมาเล่าวันนี้ Dvorak Heat map จาก daskeyboard.com/blog/the-dvorak-keyboard-la.. ข้ามเรื่อง QWERTY มาจนปี 1932 August Dvorak ได้เปิดตัว Dvorak Simplified Keyboard โดยออกแบบมาเพื่อลดความผิดพลาด, เพิ่มความเร็วและลดความเมื่อยล้าที่เกิดจากการพิมพ์ครับ โดยศึกษาจากความถี่ของตัวอักษรที่ถูกพิมพ์ในภาษาอังกฤษ ฟีเจอร์หลักๆ จะมี นำเอาตัวอักษรที่พิมพ์บ่อยที่สุดมาไว้ใน home row ทำให้เรา ไม่ต้องขยับนิ้วขึ้นลงบ่อยๆ เหมือน QWERTY ตัวสระในภาษาอังกฤษทั้งหมดก็อยู่ใน home row ด้วยครับ ตัวอักษรที่พิมพ์บ่อยๆ Dvorak จะย้ายมันไปอยู่ top row แทน bottom row ครับ เพราะเชื่อว่า เราสามารถยกนิ้วขึ้นไปพิมพ์ได้ง่ายกว่ากดนิ้วลงมาใน bottom row โดยอัตราส่วนในการพิมพ์ของแต่ละ row (top-home-bottom) ของ Dvorak จะอยู่ที่ 22% - 70% - 8% เทียบกับ QWERTY ซึ่งอยู่ที่ 52% - 32% - 16% ...

ช่วงที่ผ่านมาหลายๆ คนน่าจะ WFH มากขึ้นใช่มั้ยครับ และผมเชื่อว่าหลายๆ คนน่าจะรู้สึกเหมือนผมว่า พอเรา WFH เราเริ่มจะอยู่กับคอมนานมากขึ้นไปอีกถ้าเราเป็น Programmer เพราะเราไม่ต้องเสียเวลาเดินทาง หรือออกไปซื้อข้าวเหมือนแต่ก่อน แล้วพอเราใช้เวลาอยู่หน้าคอมมากขึ้น เราก็จะเริ่มรู้สึกปวดเมื่อยล้าขึ้นตามมาในจุดต่างๆ ไม่ว่าจะเป็นที่คลาสสิกอย่าง คอ บ่า ไหล่ หรือจะเป็นข้อมือ หรือนิ้ว ส่วนตัวผมก็ประสบกับปัญหาพวกนี้ไม่ต่างกันครับ และหนึ่งในวิธีที่ผมใช้มาแก้ปัญหานี้คือ การเปลี่ยนมาใช้ Ergonomic keyboard อย่าง Ergodox EZ ครับ แต่ก่อนจะไปถึงจุดนั้น ผมอยากจะแนะนำให้ทุกคนรู้จักกับ Split keyboard และ Ortholinear layout ก่อนครับ อะไรคือ Split keyboard Split keyboard เป็นคีย์บอร์ดอีกประเภทนึงที่จัดอยู่ในแนว Ergonomic keyboard โดยจุดเด่นหลักๆ อยู่ที่ตัวแป้นคีย์บอร์ดจะโดนหั่นครึ่ง ออกมาแยกออกจากกัน ซึ่งมีทั้งแบบ split ที่แยกออกจากกันไปเลยเป็น 2 ชิ้นแล้วเชื่อมกันผ่านสายเช่น Ergodox, Matias Ergo Pro, Kinesis Freestyle ฯลฯ หรือแบบ unibody ที่ยังอยู่ในเคสเดียวกันแต่ถูกจัดวางให้เอียงออกมารับสรีระมากกว่าปกติเช่น Microsoft Sculpt Ergonomic, Kinesis Advantage 2 ...

ตั้งแต่จำความได้แล้วบอกที่บ้านว่าโตขึ้นจะเป็น Programmer เขียนโปรแกรม​ ฯลฯ จะต้องเจอคำพูดประมาณว่า อ่อคอมพิวเตอร์มันก็มีแค่ 0 กับ 1 เท่านั้นแหละ พอโตขึ้นมาอีกหน่อยตอนอยู่มัธยมก็เริ่มรู้จักตรรกศาสตร์​ซึ่งเป็นพื้นฐานของ Boolean Algebra แล้วก็พอรู้ว่า อ่อเดี๋ยวไปเขียนโปรแกรมน่าจะได้ใช้เยอะ (ตอนนั้นยังไม่รู้จัก Demorgan’s law) พอเข้ามหาลัยหน่อยได้เรียนวิชา Digital ก็รู้สึกว่าใกล้ละเริ่มเห็น OP AMP เห็น Microcontroller, Microprocessor แล้วก็ข้ามไปวิชา OS เลย ทิ้งช่องว่างระหว่าง Hardware กับ Software ไว้ในใจโยธินมาเป็นระยะเวลาหลายปี จนกระทั่งปีนี้เรียกว่าจับพลัดจับพลูมารู้จักคอร์ส nand2tetris จากพี่อรรถ จากบทสนทนาตอนเย็นในที่ทำงานที่คุยกันไปเรื่อยในหัวข้อการเขียนโปรแกรม ประกอบกับในช่วงนี้ของชีวิตรู้สึกโหยหาอะไรที่มัน Fundamental, Foundation, Theoretical มากเลยตั้งปณิธานไว้ว่า สงกรานต์นี้เราจะเรียนคอร์สนี้ ต้องเกริ่นก่อนว่าคอร์ส Build a Modern Computer from First Principles: From Nand to Tetris (Project-Centered Course) นี่เป็นหนึ่งในคอร์สระดับตำนานของ Coursera เลยครับ ที่มีคนเรียนมากกว่าแสนคน และได้รับคะแนนรีวิวถึง 4.9 คะแนนเต็ม 5 โดยคนสอนเป็น Professor จาก the Hebrew University of Jerusalem สองคนคืออาจารย์ Shimon Schocken และอาจารย์ Noam Nisan ครับ โดยใช้เวลา 6 สัปดาห์ในการสร้าง Hack Computer ขึ้นมา ตั้งแต่ระดับเบสิกที่สุดคือ NAND gate ไปจนถึงมีสถาปัตยกรรมคอมพิวเตอร์จริงๆ ...

หลายปีที่แล้วผมเคยพูดไว้ว่า หนึ่งในสิ่งที่ผมชอบเกี่ยวกับภาษา Python ที่สุดคือ Community ครับ และผ่านมาหลายปี ผมก็ยังยืนยันคำเดิมว่า Python Community เป็นหนึ่งใน Tech community ที่เปิดรับและเป็นมิตรมากที่สุดที่หนึ่งครับ และงานใหญ่ที่สุดประจำปีของชาว Python คืองาน PyCon US หรือหลาย ครั้งก็เรียกกันแค่ PyCon เพราะที่นี่เป็น Original ก่อนจะมี regional PyCon ต่าง ไม่ว่าจะเป็น Euro Python, PyCon AU, PyCon APAC หรือ PyCon Thailand ครับ และอย่างที่เรารู้กันดีว่าปี 2021 นี้ยังเป็นอีกปีที่การระบาดของไวรัส COVID-19 ทำให้นี่เป็นปีที่สองที่ PyCon US จัด Online ครับ ซึ่งข้อดีคือ ทำให้เราๆ ที่ไม่ได้อยู่ US สามารถร่วม Conference ได้เพียงแค่มี Computer / Internet เท่านั้นครับ แต่ข้อเสียคือ Timezone จะลำบากหน่อย เพราะเวลา US แทบจะกลับด้านกลางวันกลางคืนกับเวลาไทยเลย วิธีการ Scout หัวข้อผมก็ง่ายๆ ครับทำ Spreadsheet แล้วก็เรียงตาม timeline สำคัญคือ Track ไหนเวลาไหน ...

เห็นช่วงนี้สถานการณ์ COVID-19 มันกลับมาหนักอีกรอบ แล้วหลายๆ ทีมต้องปรับตัวมา Work From Home / Work Remotely กันอีกรอบ เลยคิดว่าจากประสบการณ์ที่ทำงานมาหลายปี ผ่าน Work Remotely มาตั้งแต่ Before it was cool นั้น เราได้ Lesson learn อะไรบ้าง หลายอย่างมาจากประสบการณ์จากตัวเราเอง หลายอย่างเราได้จากคนอื่น หลายๆ อย่างได้จากบทความที่อ่านมา ก็ลองเอาไปปรับใช้กันได้ครับ ⏰ Check-in & Check-out (Offline) สิ่งแรกที่เราควรทำคือ เราบอกทีมว่าเราพร้อมทำงานแล้วนะ ไม่ต่างจากเวลาเราเข้าไปทำงานในที่ทำงานปกติแล้วเราทักทายเพื่อนร่วมทีมเวลาเดินทางมาถึงที่ทำงานใช่มั้ยครับ ซึ่งการ check-in แบบนี้นอกจากจะช่วยให้ทีมรู้ว่าเราพร้อมทำงานแล้วแบบ Explicit แล้วยังเป็นโอกาสที่เราจะได้ใช้เวลาคุยเล่นด้วย ในช่วงเวลาที่เรายังไม่ลงไปโฟกัสกับงานเต็มตัว ในอีกมุมนึง เวลาเราทำงานปกติจะกลับบ้าน เราก็บอกลาคนในทีมใช่มั้ยครับ ว่า “เรากลับบ้านแล้วนะ” โดยหลายๆ ครั้งพอเรา Adapt มา Work remotely เรามักจะลืมสิ่งนี้ไป ซึ่งผมบอกได้เลยว่านี่เป็นสิ่งสำคัญอย่างนึงเลย ที่เราจะบอกทีมว่าโอเค เราเลิกงานแล้วนะ เราอาจจะตอบแชทได้ แต่ไม่ 100% เหมือนตอนเรา Check-in อยู่นะ อีกสิ่งหนึ่งที่เราชอบลืม Check-in & Check-out กันคือ ตอนพักเที่ยงครับ ซึ่งผมจำได้เลยว่าหลายปีก่อนที่ผม Work Remotely ใหม่ๆ ผมเถียงหัวหน้าผมขาดใจเลยว่า ผมยังไม่หิว เพราะเวลาเราทำงานอยู่บ้านเราจะ Flow มาก แต่หัวหน้าผมให้เหตุผลกลับมาว่า มันสำคัญมากที่เราต้อง Balance เวลาที่เราทำงานกับเวลาพัก ตอนนี้เหมือนจะไหว แต่ Long run มันจะทำให้เวลาเราเสียสมดุลไปหมด เพราะฉะนั้นเที่ยงก็พัก กลับมาก็ check-in ด้วยนะครับ ...

เหตุเกิดจากเมื่อวานมีน้องในทีมอยู่ดีๆ มาถามว่า “พี่เอาเวลาตอนไหนไปอ่านหนังสือนะ” ตอนนั้นคือไม่รู้ว่าจะมีเวลาเท่าไรเลยตอบแบบสั้นๆ ไป ทุกช่วงเวลาที่ว่างนะแหละ แล้วหลังจากนั้นผมก็ยกตัวอย่างช่วงเวลาที่ว่างที่พอจะนึกออกเช่น ระหว่างรอสั่งข้าว, ยืนบนรถไฟฟ้า,​ นั่งขี้, ก่อนนอน,​ ตื่นนอน ฯลฯ แต่กลัวว่าจะไม่เกทเลยรู้สึกว่าต้องมีเขียนบล็อกต่อนี่แหละ มันเริ่มมาจากความเจ็บปวด จริงๆ มันมีที่มาว่าผมรู้สึกแย่มากที่ตัวเองไม่ค่อยมีเวลาได้อ่านหนังสือ แบบ เห้ย เรารู้นะว่าการอ่านหนังสือมันดี พออ่านแล้วชีวิตเราดีขึ้น เราก็อยากจะอ่านมัน แต่แค่อยากมันไม่ได้ไง ยิ่งช่วงหลังๆ ที่มีสิ่งเร้าเยอะมาก เช่น พอกลับถึงคอนโด ก็เปิดทีวีเลย หรือถ้าว่างก็หยิบมือถือขึ้นมาไถๆ Facebook, Twitter ทำให้เราไม่มีที่ว่างให้หนังสือเลย แต่ถึงจะไม่มีเวลาให้หนังสือ แต่ผมสามารถซื้อหนังสือมาเติมได้เรื่อยๆ ด้วยจังหวะชีวิตที่พอเข้าฟิตเนส แล้วออกมามี Routine ว่าจะต้องแวบเข้าไปร้านหนังสือ มันทำให้จำได้เลยว่า เล่มไหนเพิ่งวางแผง เล่มไหนเล็งไว้ก่อนหน้านี้ คือสามารถ git diff ชั้นหนังสือดูได้เลยว่าอะไรเปลี่ยนไปตรงไหน แก้ที่พฤติกรรมก่อนเลย ตอนช่วงที่ผมแบบไม่ไหวแล้วโว้ย “อยากอ่านหนังสือ"​ เป็นช่วงเวลากับที่ผมเริ่มทำ Bujo ใหม่อีกรอบแล้วเอา tooling อย่าง Habit Tracker มาช่วยด้วย (อ่านได้ในบล็อก เรากลับมาทำ BuJo ได้หนึ่งเดือนแล้ว ครับ) แต่ที่ผมไม่ได้พูดถึงในนั้นมีอยู่ 2 เรื่องครับ ตอนผมทำ Tracker ผม Challenge ตัวเองหนักมากว่าต้องได้ Streak เยอะๆ คือไม่ต้องอ่านเยอะ แต่ต้องอ่านทุกวัน มันเลยค่อยๆ เริ่มจากอ่านใน BTS ตอนที่ยังต้องนั่งยาวๆ ไป 40 นาที ไปกลับก็​ 1 ชั่วโมง 20 นาทีละ ที่จะได้อยู่กับหนังสือ จังหวะที่ระบายสีลงในช่องแต่ละวันว่าเราได้อ่าน นี่มันฟินมากครับ ตอนผ่านไปอาทิตย์แรกนี่ก็ฟินแล้ว ว่าโห เราทำได้ติดต่อกันถึง 7 วันเลยเหรอ แล้วด้วยความกลัวเสียสถิติ ผมเลยพยายามทำลายสถิติตัวเองมากขึ้นทุกวัน ซึ่งตอนแก้พฤติกรรมมันเหนื่อยนะ และผมอยากให้รางวัลกับมันบ้าง จริงๆ เป้าหมายผมตอนนั้นง่ายมาก คือผมอยากได้ Kindle มาตั้งแต่สมัยเรียนมหาลัยละ แล้วก็ไม่มีโอกาสซักที พอถามแฟน แฟนก็บอกว่า อยากได้มาเดี๋ยวก็เบื่อ เลย Challenge กับตัวเองว่า ถ้าอ่านหนังสือได้ 30 วันติด จะถอยเลย ซึ่งทำได้จริงๆ นะ แล้วก็ถอยมาเลย Kindle Paperwhite ทำให้รู้สึกสนุกกับตอนอ่านหนังสือมากขึ้นอีก ...

สมมติว่าเรามีโจทย์ที่ต้องยิง HTTP Request เพื่อดึง resource มาจาก Web service อื่นหลายๆ ที่ ถ้าเราไม่คิดอะไรเราก็อาจจะเขียนโค้ดให้ ยิงทีละตัวแบบ Synchronous ไปได้ แต่ถ้าแต่ละ Request ไม่ได้ขึ้นต่อกัน เราจะมีตัวเลือกมากขึ้นผ่านการยิงแบบ Asynchronous ครับ ซึ่งผมเพิ่งรู้ว่า Java มันทำได้ Example สมมติว่าเรามี Service ที่ไว้ยิง HTTP Request ไปที่ API อื่นแบบง่ายๆ หน้าตาประมาณนี้ @Service public class ActivityService { RestTemplate restTemplate = new RestTemplate(); public ResponseSecond getEndpointOne() { String url = "http://localhost:8000/1"; ResponseSecond response = restTemplate.getForObject(url, ResponseSecond.class); return response; } } และมี Controller ที่เรียกใช้ Service นี้หน้าตาประมาณนี้ ...

ขอรีวิวคลาส “Domain Driven Design แบบรูฟๆ” หน่อยนะครับ เป็นการขอบคุณที่พี่รูฟ Twin Panitsombat มอบดาบให้ไปสู้กับไฮดรา (หรือไปสร้างไฮดราตัวใหม่นะ) “คนที่มาเรียนถ้าไม่มาเรียนเพื่อแสวงหาความรู้ ก็มาเรียนรู้เพื่ออธิบายสิ่งที่ตัวเองทำเป็นธรรมชาติอยู่แล้ว” ผมเริ่มค้นพบอย่างนึงว่า ผมชอบฟังเรื่องราวที่คนทำ Software ในยุคก่อนผมเข้าวงการ เค้าเจออะไร แล้วแก้ปัญหาอะไรมาก มันเหมือนกับการที่เราพยายามกลับไปทำความเข้าใจรากของปัญหาว่า ก่อนจะมาถึงทุกวันนี้ วงการนี้มันผ่านอะไรมาบ้าง แล้วภาพที่พี่รูฟ เล่าตั้งแต่ Software Crisis มันเหมือน Connect the dot ที่ผมรู้มาตลอดชีวิตเข้าด้วยกันตั้งแต่ XP, Scrum และ Kanban และช่องว่างตรงกลางที่ผมรู้สึกมาซักพักใหญ่มาก แต่ไม่รู้ว่ามันคืออะไร จนมาได้คำตอบว่ามันคือ Domain Driven Design ครับ คลาสนี้รู้สึกว่าได้เครื่องมือมาหลากหลายมาก ที่บอก How ในการทำ Architecture design ที่ตลอดชีวิตมา เริ่มด้วย Data model ก่อนเสมอ ตั้งแต่การ define space อย่าง Problem space กับ Solution space ซึ่ง ตอนจังหวะนี้ประสบการณ์ Scrum มาตลอดชีวิตภาพมันกลับมาทั้ง Sprint Planning, Refinement แต่ที่ surprise ตัวเองมากคือภาพตอนเรียน Category Theory ไม่กี่สัปดาห์ก่อนมันกลับมาด้วย และมันกลับมาบ่อยมากๆ ตลอดเวลาที่เหลือของ class DDD วันนี้ทั้งภาพ Domain, Co Domain, Functor, Object, Morphism, Category of Type ตอนทำ Workshop ทำ Context Mapping และหา Event Sourcing กับ CQRS และอื่นๆ อีกหลายจุดครับ เรียกได้ว่าหลอกหลอนมาก 555 ...