ลอง Clojure ครั้งแรกกับแบบฝึกหัด Budget List

ไปเรียน Coding Professional กับ Josepth กับ Jackson มา มีโจทย์หนึ่งเรียกว่า Budget ที่เขาให้เป็นมาลองทำด้วยวิธี pair programming เลยไปจับคู่กับอะกิ แล้วใช้ภาษา golang พอทำเสร็จก็คุยกันได้ความว่า ถ้าเอาใช้กับ map-reduce จะสวยกว่านี้อีก พี่รูฟเลยชวนให้ลองเอามาเขียนเป็น functional programming ด้วย clojure ซึ่งแน่นอน ไม่เคยเขียนเลยสักครั้ง ไม่แม้จะรู้จัก syntax มัน เลยเอามาลองกัน

อ่านต่อ »

อย่ายัดเยียดความคิดตัวเองลงไปในงานลูกค้า

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

อ่านต่อ »

อย่าดูถูกตัวเองด้วยการลดคุณภาพของสิ่งที่ทำ

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

หลาย ๆ องค์กรมีทีม IT ที่คอยพัฒนาซอฟต์แวร์ให้ทั้งผู้ใช้ที่เป็นลูกค้าภายนอก รวมถึงผู้ใช้ที่เป็นพนักงานภายในบริษัทเอง โดยตั้งโจทย์แบบเดียวกันกับเรื่องของเบอร์เกอร์กระรอก คือ “จะเอาทั้งหมด” ภายใต้ resource ที่มีอยู่อย่าง “จำกัด” (คำว่า resource ในที่นี้ หมายถึง resource ทุกอย่าง ยกเว้น คน เพราะคนไม่ใช่ resource) ปัญหาที่ตามมาคือ การใช้ secret toolbox ไม่ว่าจะเป็นการสร้าง smell ลงไปในของที่ตัวเองทำ การไปก๊อปปี้โค้ดมาจากอินเตอร์เน็ตโดยไม่ได้สนใจว่ามันคืออะไร ทำงานยังไง การไม่ทำความเข้าใจโค้ดที่ทีมเขียนหรือไม่ทำให้โค้ดที่ตัวเองเขียนอ่านง่ายขึ้น และที่สำคัญคือ การไม่เขียนเทสต์

อ่านต่อ »

สร้าง LEMP stack ด้วย docker

อยากทำ dev environment สำหรับทำเว็บที่ไม่กระทบกับ environment ของเครื่องที่ใช้อยู่ โดยมีของที่อยากได้คือ linux, nginx, mariadb และ php (LEMP) จริง ๆ จะเป็น linux, apache, mysql และ php (LAMP) ก็ได้ แต่เอา nginx มาใช้แทนเพราะอยากหัดด้วย ส่วน mariadb เห็นว่า performance ดีกว่า mysql เลยเลือก mariadb ตั้งโจทย์ไว้แบบนี้เลยมอง ๆ เรื่องเอา docker มาใช้

อ่านต่อ »

เข้าใจเหตุและผลด้วย Causal Loop Diagram (CLD)

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

แต่ในปัญหาเดียวกัน หากเรามองปัญหาใน scale ระดับใหญ่ขึ้นมาอีกหน่อย เราเริ่มเพิ่มตัวแปรที่เกี่ยวข้องลงไปในปัญหาให้มากขึ้น เช่น จำนวน feature, เวลา, จำนวน developer เราจะเริ่มเห็นผลกระทบที่ซับซ้อนมากขึ้น จนลำบากที่จะอธิบายด้วยคำพูดสั้น ๆ ให้เข้าใจได้ ทำให้การนำไปสื่อสารเพื่อให้คนอื่นเข้าใจเป็นไปได้ยากมากขึ้น หรืออาจจะเข้าใจผิด หรือตีความผิดได้ง่ายขึ้น

อ่านต่อ »

Brooks’s Law

ในบริบทการพัฒนาซอฟต์แวร์ที่ feature ถูกกำหนดไว้แล้ว (fixed scope) และเวลาที่จะต้องส่งมอบก็ถูกกำหนดไว้แล้ว (fixed time) หลาย ๆ องค์กรยังคิดว่า การเพิ่มคนลงใน software project จะช่วยให้ project เสร็จเร็วขึ้น หรือเสร็จทันเวลาได้

Fred Brooks กล่าวไว้ในหนังสือ The Mythical Man-Month เกี่ยวกับ Software Project Management ว่า “adding human resources to a late software project makes it later”

อ่านต่อ »

Retrospective ด้วย ORID

ORID เป็นกิจกรรมแบบหนึ่งที่คนที่ทำหน้าที่เป็น facilitator ใช้วิธีการพูดคุยในการดำเนินกิจกรรม ในกิจกรรมจะเป็นการตั้งคำถามให้ผู้เข้าร่วมกิจกรรมตอบผ่านคำถาม 4 คำถาม โดยทั้ง 4 คำถามจะเป็นคำถามที่นำไปสู่การตัดสินใจ (Decision Making) ของผู้เข้าร่วมกิจกรรม

อ่านต่อ »

Migrate jasmine ไปใช้ jest ใน Angular 6

อะกิมาบอกว่า jest น่าสนใจดีนะ จำได้ว่ามีคนเคยชวนไปใช้ jest แต่ตอนนั้นก็ยังไม่ได้สนใจอะไร ตอนนี้พอมีเวลาก็เลยมาลองซะหน่อย มี project ทดสอบอยู่ตัวนึงที่เอาไว้ใช้สอน robot คือ ng-calculator ซึ่งเดิมใช้ jasmine อยู่ เดี๋ยวจะมาลองเปลี่ยนเป็น jest ดู

อ่านต่อ »

เขียน test บน go ด้วย testify

จริง ๆ ใน golang มี package ชื่อ testing อยู่ ใช้ตัวนั้นก็ได้ ตรงไปตรงมาดี ความซับซ้อนก็จะเริ่มมาตอนที่เราอยากจะทำอะไรที่ยากขึ้น เช่น การทำ test double หรือการเปรียบเทียบ struct 2 ตัว ซึ่งจริง ๆ แล้วเราสามารถเอาพวก reflect มาใช้เปรียบเทียบ struct ได้ ส่วนการทำ test double ก็จะซับซ้อนกว่านั้น

อ่านต่อ »

โชว์ Code Coverage ของ Angular Project ใน Github

เข้าไปเห็น repo ใน github ของหลาย ๆ คน เขาแสดง code coverage เป็น badge แล้วมันดูเท่ไม่หยอก ที่สำคัญมันออโต้ด้วย ไม่ต้องมานั่งพิมพ์เองหลังจาก run unit test เสร็จว่า code coverage เราเท่านี้แล้วนะ ให้มันอัพเดทโดยอัตโนมัติดีกว่า จิ้ม ๆ ดูเห็นเขาใช้ service ของ codecov.io เลยไปลองมั่งดีกว่า

จริง ๆ วิธีนี้ใช้กับ provider เจ้าอื่นได้ด้วย ไม่ใช่แค่ github พวก bitbucket, gitlab ก็ได้นะ

อ่านต่อ »