เขียนเทสนี่มันยากจริงๆ

เราไม่ชอบเขียนเทสเพราะอะไรกันนะ

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

แต่ไม่มีใครบอกว่าต้องทำยังไง

เลยทำไปแบบงงๆ เขียนโปรแกรมให้มันทำงานได้ก่อนก็แล้วกัน

พองานเสร็จ เราจะมาเขียนเทส ก็พบว่า ทำไมมันยากจังวะ

• เขียนเทสนี่มันเขียนยังไง ไม่เห็นมีใครมาบอก ในมหาลัยก็ไม่ได้สอน
• Test case เค้าออกแบบกันยังไง
• อยากจะเทสแค่หน่อยเดี่ยว ทำไมต้อง setup นู่นนี่นั่นเต็มไปหมด
• แล้ว UI ล่ะ จะเทสยังไง
• Database ต้องมา Roll back ทุกครั้งที่รัน unit test เนี่ยนะ !?

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

แล้วก็เลิกเขียนเทสกันไปในที่สุด มีใครมีอาการคล้ายๆผมอย่างนี้บ้างไหมครับ :)

การต่อ Micro Block กับการเขียนโค้ด

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

โอเค กลับมาที่การต่อ Micro block ของผมนี่ ขอเล่าย้อนไปสักเล็กน้อยตอนที่ผมเริ่มซื้อมาต่อกล่องแรก ก็ไม่มีอะไรมาก ก็กางคู่มือความหาชิ้นส่วนจากในกองมาต่อๆ จนเสร็จ
แต่ผมค้นพบว่า การคุ้ยหาชิ้นส่วนมาจากกองนั้นมันเหนื่อยเอามากๆ
ยิ่งถ้าเป็นตัวที่รายละเอียดสูงๆล่ะก็ ยิ่งเหนื่อยมากขึ้นไปอีก -_-'
แถมความแสบของเจ้าตัวต่อจีนแดงนี้อีกอย่างหนึ่งคือ มันให้ชิ้นส่วนมาไม่ครบ!!
ลองคิดดูนะฮะ ว่ามันปวดร้าวแค่ไหน ที่ชิ้นส่วนที่คุณหามาเนิ่นนานน่ะ มันไม่มีอยู่อ่ะ ;_;
นี่อาจจะเป้นสาเหตุของการดองเรื่องต่างๆเอาไว้ของมนุษยชาติก็ได้นะครับ แหะๆๆ

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

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

ที่ว่ามานั้นมันทำให้ผมนึกถึงข้อความนี้ในบทที่ 10 ของหนังสือ  Clean code ของ  Robert C. Martin ครับ

"Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?"

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

อันนี้เป็นลิงค์ของหนังสือ Clean code ครับ http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

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

[Review] คอร์ส Passionate Product Ownership by Jeff Patton

สวัสดีครับ ด้วยการสนับสนุนจากผู้ใหญ่ใจดีท่านหนึ่ง ทำให้ผมได่มีโอกาสได้เข้าเรียนในคอร์สที่ผมใฝ่ฝันมานาน ก็คือคอร์สนี้แหละครับ ผู้เรียนจะได้รับใบประกาศ CSPO (Certified SCRUM Product Owner) โดยอัตโนมัติ (คนสอนบอกว่าขอแค่ survive ให้ครบ2วันก็พอ ไม่ต้องสอบครับ อิอิ)

โอเค มาเริ่มกันเลย เรื่องจากworkshopนี้เป็นส่วนหนึ่งของงาน Agile India 2015 ดังนั้นผู้เรียนส่วนใหญ่จึงเป็นคนอินเดีย มีคนไทยบินมาเรียน2คนถ้วนและฝรั่งอีกจำนวนหนึ่งครับ  มีผู้เข้าเรียนประมาณ 40 คน นั่งได้โต๊ะละ 5 คน ก็ได้มีเพื่อนรวมโต๊ะเป็นชาวอินเดียสองท่านครับ ปัญหาก็คือผมฟังภาษาอังกฤษสำเนียงอินเดียไม่ค่อยออกครับ แต่คนสอน(ต่อไปขอเรียกว่า ลุงJeff นะครับ เพื่อความสะดวก...ของผม อิอิ) ฟังออกแฮะ น่าจะคุ้นเคยกับคนอินเดียเป็นอย่างดี แต่ก็ผ่านมาได้ครับ รู้เรื่องบ้างไม่รู้เรื่องบ้าง เออๆออๆ ตามน้ำไป ฮิฮิ

มาดูทางด้านการเรียนการสอนกันบ้าง ก็จะเป็นการฟังบรรยายสลับกับทำ workshop สั้นๆ ประมาณ 5 นาทีครับ มากับเนื้อหาที่อัดแน่นสุดๆ แต่ด้วยสไตล์การสอนของ  Jeff  นี่ไม่มีเบื่อเลยครับ น่าทึ่งมากๆ

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

พูดถึงเนื้อหาที่เรียนกันบ้าง ก็เกี่ยวกับการทำ Software, เรื่องของ Collaboaration แล้วก็เข้าเรื่อง Process แกเอา Paper ของ Waterfall model มากางให้ดูเลยครับ ว่ามันเขียนไว้ตั้งแต่ปี 1970 แล้วนะ ว่าทำแบบนี้แล้วมันจะเจ๊งนะ ในpaperมันมีการevolveไปเรื่อยๆจนสุดท้าย เราจะได้ข้อสรุปว่า Good process is messy
อันนี้เป็นการปูเรื่องเพื่อเข้าสู่ที่มาของ SCRUM ซึ่งผมว่าเป็นการเล่าเรื่อง SCRUM ที่เจ๋งมากๆ หาจากอาจารย์ท่านอื่นไม่ได้แน่นอน (ไม่ได้บอกว่าท่านอื่นสอนไม่ดีนะครับ)

พอจบเรื่อง SCRUM แล้วแกก็เล่าเกี่ยวกับการทำงานของProduct manager หรือ owner ใน SCRUM นั่นเองครับ พูดถึงการทำงานร่วมกันระหว่าง PO, Dev และ UX,BA ฯลฯ ภาพที่ควรเกิดขึ้นนั้นเป็นอย่างไร, งานของ UX นั้นมีอะไรบ้าง, กระบวนการทำ Product discovery, เรื่อง Output กับ Outcome, การทำ Story mapping, การหา MVP, Metric ที่นำมาใช้วัดความสำเร็จของ Product, การทำ Persona, การกำหนด Prioritize Backlog Strategy ฯลฯ  แล้วยังมีดีเทลยิบๆย่อยๆอีกเยอะครับ เขียนไม่หมด

หมดเรื่อง Product discovery แล้วก็กลับมา cover เรื่อง SCRUM กันอีกครั้ง ก็หยิบเรื่อง กิจกรรมต่างๆใน SCRUM มาคุยกัน เช่น Daily standup PO ควรทำอะไร? อันนี้เป็นคำถามปลายเปิด ให้ผู้เรียนหาคำตอบกันเอาเอง แล้วก็เรื่อง Sprint Review ที่ควรแยกกันกับ Stakeholder Review
ต่อด้วย แนวคิดของ Lean startup นำมาช่วยในการออกแบบ Product ,การทำ Prototype แล้วปิดท้ายด้วย Design thinking แล้วก็ตอบคำถามอีกนิดหน่อย ได้ Key takeaway มาเยอะมากๆครับ ถ้ามีแรงจะเอามาเล่าต่อเรื่อยๆนะ

ระหว่างเรียน ก่อนจะไปเบรก ลุงJeff แกจะให้เราเขียน Key takeaway (หรือ A-ha) มาอย่างน้อยหนึ่งอย่างลงใน Post-itไปแปะที่บอร์ดครับ (คอร์สนี้ใช้ Post-it เปลืองมากๆ บริษัท 3M มาเห็นนี่ต้องน้ำตาไหลอ่ะ) ผมชอบเทคนิคนี้มาก เหมือนกับว่าได้ทบทวนไปในตัว น่านำมาใช้ครับ เวลาไปแชร์ความรู้ให้คนอื่นๆ

จบชั้นเรียนด้วยการให้ผู้เรียนทุกคนเลือก Key takeaway ที่ชอบที่สุดมาหนึ่งอัน แล้วก็จบ ก็แยกย้ายกันกลับ (มีบางท่านยังมันส์อยู่ ก็ไปคุยกับ Jeff ต่อครับ ยาวๆไป อิอิ)

อ้อที่สำคัญคือ คอร์สนี้แจกแหลกครับ ทั้ง Handout ที่พิมพ์สีทั้งเล่ม, ตัวอย่างที่ใช้ใน workshop ก็เก็บกลับบ้านไปด้วยได้เลย(ไม่มีใครเก็บไปเลยแฮะ แอบแปลกใจเล็กน้อย) สุดท้ายคือแกแจกหนังสือครับ ใช่ครับ User Story Mapping ของแกนั่นแหละ แถมยังเซ็นชื่อให้ครบทุกคนอีกตะหาก โคตรป๋าอ่ะ

สรุปว่าสุดยอดมากๆครับคอร์สนี้ ไม่ว่าคุณจะเป็นใครที่เกี่ยวข้องกับการทำ Product น่าจะหาโอกาสมาเรียนกันครับ ไม่ต้องทำ SCRUM ก็ได้ ไม่มีอะไรเกี่ยวข้องกับ Agile เลยก็ยังได้ครับ ลองดูๆ ใบ Cert. เป็นแค่ของแถมครับ

Even a single line is worth extracting if it needs explanation.

อ่านเจอประโยคนี้ในหนังสือ Refactoring  ของลุง Martin Fowler

แปลเป็นไทยก็ได้ความว่า

"ต่อให้เป็นโค้ดแค่บรรทัดเดียว แต่ถ้ามันต้องการคำอธิบายเพิ่ม มันก็ควรจะถูก Refactor"

ยกตัวอย่างง่ายๆเช่น ผมมีเงื่อนไข สักอย่างแบบนี้

if (username !== null && email !== null && password === confirmPassword) {
    ...
}

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

เราสามารถช่วยโลกใบนี้ได้ ด้วยการ Extract  ออกไปเป็น  Method หรือ  Function แบบนี้

if(isRegistrationFormCompleted()) {
    ...
}

function isRegistrationFormCompleted(){
    return username !== null && email !== null && password === confirmPassword
}

จะเข้าใจเลยว่าเงื่อนไขชุดนี้เอาไว้เช็คว่าฟอร์มใส่ข้อมูลมาครบแล้วหรือยังใช่มั้ยครับ

ทีนี้ดูต่อไปอีกหน่อย ในชุดเงื่อนไขพวกนี้ ยังดูแล้วยุ่งๆนะฮะ ลองแยกเงื่อนไขแต่ละอันออกไปเป็น Function ดูสิ

if(isRegistrationFormCompleted()) {
    ...
}

function isRegistrationFormCompleted(){
    return isUsernameNotNull() && isEmailNotNull() && isComfirmPasswordMatched();
}

function isUsernameNotNull(){
    return username !== null;
}

function isEmailNotNull(){
    return password !== null;
}

function isComfirmPasswordMatched(){
    return password === confirmPassword;
}

สามารถมองออกได้ทันทีเลยว่าแต่ละเงื่อนไขเราจะเช็คอะไร

ผมจะพอเท่านี้แหละ แต่โค้ดนี้ยัง Refactor ต่อไปได้อีกนะครับ เช่นแยกส่วนเงื่อนไขเหล่านี้ออกไปเป็น Class ใหม่, เปลี่ยนเงื่อนไขเป็น Strategy pattern ฯลฯ แล้วจะมาเขียนแนะนำกันเรื่อยๆครับ

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

Refactoring กับ Performance

พอดีไปอ่านเจอในหนังสือ Refactoring to patterns เลยอยากมาแชร์ครับ

คือเรามักจะกังวลไปก่อนว่า เวลาเราทำการRefactorให้Functionมันเล็กๆ แล้ว มันเรียกต่อๆกันเยอะๆแล้วมันจะต้องมีปัญหาเรื่องPerformanceตามมา

ด้วยเหตุผลนี้ เราก็เลยไม่ค่อยอยากจะRefactorเป็นFunctionเล็กๆ กัน (หรือแค่ขี้เกียจก็ไม่รู้นะครับ ฮ่าๆๆ)

ซึ่งในความจริงแล้ว มันเป็นอย่างนั้นจริงหรือเปล่านะ

ในหนังสือเขาว่าไว้อย่างนี้ครับ

First, good designers don't prematurely optimize code

Second, chaining together small method calls often costs very little in performance—a fact you can confirm by using a profiler.

Third, if you do happen to experience performance problems, you can often refactor to improve performance without having to give up your small methods.

สรุปแบบง่ายๆ

ข้อแรก อย่าเพิ่งคิดเรื่อง Performance ตั้งแต่แรก

ข้อสอง มันมีผลกับ Performance นิดเดียวเท่านั้นแหละ ไม่เชื่อก็เอา Profiler มาจับดู

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

ลองไปหาอ่านกันดูนะครับ

รู้จักกับ New Media Art กันหน่อย

เมื่อวันเสาร์ที่ 1 พฤษจิกายน 2557 ที่ผ่านมา ได้มีโอกาสไปร่วมงาน Codemania มาครับ เป็นงานเกี่ยวกับแวดวงซอฟต์แวร์ที่รวบรวมคนมาได้หลายหลายมาก นับเป็นงานที่ดีงานหนึ่งเลยครับ จะติดตามต่อไป

ภาพจาก http://www.coolhunting.com/culture/bmw-kinetic-scu

ในงานมี Session หนึ่งที่สะกิดความสนใจผม ก็คือ When Programming Meets Art ซึ่งเปิดหูเปิดตามากครับ ไม่นึกว่าเมืองไทยจะมีงานแบบนี้อยู่ด้วย เลยอยากเอามาเล่าต่อครับ

ถ้าพูดถึงงานศิลปะกับซอฟต์แวร์ จะนึกถึงอะไรกันครับ หลักๆเลย ก็คงเป็นเว็บ แอพฯ หรือ เกม อะไรพวกนี้ใช่มั้ยครับ แต่ใน session นี้เขาพูดถึงอีกแขนงหนึ่งที่ไม่ค่อยเห็นคนทำกันเท่าไหร่ในบ้านเรา ก็คือ Software ทางด้าน Visual Effect ครับ พวกเอฟเฟกต์ต่างๆในหนัง แสงเงา ขนสัตว์ ฯลฯ อะไรงี้ ที่ยกตัวอย่างกันบ่อยๆ ก็เช่นพี่เสือใน Life of Pi ก็มีการเขียนซอฟต์แวร์เพื่อเรนเดอร์ขนของพี่เสือให้มันพริ้วๆอย่างที่เห็นในหนังแหละครับ

ทีนี้ อยู่ๆไปเหมือนกับว่างบประมาณทางด้าน Visual effect นี้จะค่อยๆลดลง จะด้วยเหตุผลอะไรก็ตามแต่
แต่เอาเป็นว่า คนที่ทำงานด้านนี้เริ่มจะอยู่ไม่ไหวกันแล้ว ก็เลยมีการนำเอางานทางด้านนี้ไปประยุกต์ใช้กับอย่างอื่นดูบ้าง ไปๆมาๆ ก็มาลงที่ New Media Arts นี่ล่ะครับ

Wikipedia เค้าว่างี้

New media art is a genre that encompasses artworks created with new media technologies, including digital art, computer graphics, computer animation, virtual art, Internet art, interactive art, video games, computer robotics, and art as biotechnology. The term differentiates itself by its resulting cultural objects and social events, which can be seen in opposition to those deriving from old visual arts (i.e. traditional painting, sculpture, etc.). 
ที่เหลือไปอ่านต่อเอาเองนะครับ

ต่อมาก็เอาตัวอย่างมาโชว์ให้เราดู สองสามอัน อย่างเช่นตัวนี้ค่อนข้างตั้งใจนำเสนอเลยทีเดียว ชื่อว่า Moment of truth ครับ คนที่เดินผ่านไปผ่านมาสามารถเล่นกับมันได้ด้วย โดยรูปแบบของการไหลนั้นมาจากลายหินอ่อนครับ (ถ้าจำไม่ผิดน่าจำทำให้ cotton)
https://www.youtube.com/watch?v=RXICUjebT8o
นอกจากนี้ยังมีอีกหลายอันครับ เข้าไปดูได้ในเว็บของเขาได้เลย
http://www.thebitstudio.com/

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

เพิ่มความสนุกสนานในการทำงานด้วย Jenkins sound plugin

ในทีมที่ผมทำงานอยู่เราใช้ Jenkins กันครับ

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

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

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

ซึ่งมันจะไปเพิ่มความสามารถให้ Jenkins สามารถส่งเสียงออกมาเวลาที่มันทำงานสำเร็จหรือล้มเหลวได้

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

รายละเอียดเข้าไปดูได้ที่นี่ครับ 

https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Sounds+plugin

วิธีการติดตั้งก็ไม่ยาก ก็เป็น Jenkins plugin ธรรมดาๆนี่แหละ

เสร็จแล้วมันจะโผล่มาใน Post built action  ของเราครับ ชื่อว่า Jenkins sounds โดย 1 job มีได้แค่ 1 อัน เท่านั้น

พอเพิ่มเข้าไปแล้วมันจะมีหน้าตาแบบนี้ครับ ผมก็จัดการให้มันมีเสียงเมื่อเกิดเหตุการณ์สองอย่างคือ Success กับ fail

จากในรูป ผมได้ทำการเพิ่มเสียงเข้าไปเองอีก ไว้จะมาแนะนำในโอกาสหน้าครับ