Tag Archives: CITCON

CITCON Asia 2012 at Singapore

มันย่อมาจาก Continuous Integration Testing Conference ซึ่งเริ่มตั้งแต่เมื่อวานตอนเย็น และวันนี้ทั้งวัน มีคนไทยมาร่วมงานนี้ด้วยอีก 2 คน คือ พี่ @kluak110 กับพี่ @sinapam ครับ

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

Openspace

หัวข้อโดยคร่าวๆ ก็เป็นตามนี้  http://citconf.com/wiki/index.php?title=CITCONAsia2012Sessions แต่ในระหว่างวันก็โดนผู้ร่วมงานสลับสับเปลี่ยนกันตามใจ เลยทำให้งานจริงๆ ต่างจากนี้ไปบ้าง บางหัวข้อคนพูดไม่อยากพูดแล้วเพราะเวลาชนคนที่เค้าอยากเข้าฟัง ก็ไปถอดออกจากบอร์ดเลยก็มี

Session ที่ผมเข้าฟังก็มีตามนี้ครับ

CI In A System Of Systems Environments 

หัวข้อนี้คนพูดทำอยู่ในสายเกี่ยวกับการวางระบบเน็ตเวิร์คของ Australia การทำ test ของงานเค้ามันดูยากมากเลย ทั้งต้อง test คลุมตัวอุปกรณ์ของบริษัทอื่นๆ ที่เอามาใช้ด้วย ทั้งมีอุปกรณ์เก่าที่ใช้งานอยู่แล้วอีกไม่รู้กี่พันกี่หมื่นตัว ฟังแล้วคิดไม่ออกเลยว่าจะทำยังไงให้มันมี feedback cycle ที่สั้นๆ ได้ยังไง

TDD vs BDD
หัวข้อนี้คนเริ่ม topic ตั้งใจจะนำไปคนละทางกับบทสนทนาที่เกิดขึ้นจริงในห้องเลย เค้าอยากคุยเรื่องใครใช้สไตล์การเขียน test แบบไหนใคร stub, mock, fake object แต่มันกลายไปเป็นหัวข้อที่พูดถึงเรื่องต่อไปนี้แทน

  • สไตล์การพัฒนาโปรแกรม outside-in, middle-out(?) แล้วก็ inside-out ซึ่งก็พอได้ข้อสรุปว่างานส่วนมากเหมาะกับ outside-in เพราะช่วยให้เราลดการเขียน code แล้วไม่ได้ใช้น้อยลง แต่มีงานบางอย่างที่มีคุณสมบัติว่า requirement ไม่ได้สำคัญมากเท่า technical limitation ซึ่งงานแบบนั้นก็เหมาะกับ inside-out มากกว่า
  • พบว่า ATDD, BDD, User story driven development และ Specification by Example มันคือสิ่งเดียวกัน มันคือ TDD + business requirement นั่นเอง ข้อเสียของการเกิดเหตุการแบบนี้คือ แต่ละค่ายทำ tool ของตัวเองที่สุดท้ายแล้วมันก็คือสิ่งเดียวกัน เช่น robotframework (ของค่าย ATDD) และ cucumber (ของค่าย BDD) ซึ่งทำให้เสียโอกาสในการพัฒนาไป

CI In A Lean Startup World ผู้พูดเสนอแนวคิดดังนี้

  1. Continuous Integration เป็น process เพื่อทดสอบว่าการรวมกันของ code เราสามารถทำได้
  2. Continuous Deployment เป็น process ต่อจาก CI เพื่อทดสอบว่า deployment ที่เกิดจาก code เราสามารถทำงานได้ไม่มีปัญหา
  3. Lean Startup เป็น process ต่อจาก CD เพื่อทดสอบว่า product ที่เกิดจาก code เรา user ชอบ

ซึ่งในโลกความเป็นจริง แล้วมันก็ไม่สามารถเทียบได้โดยตรงแบบนั้น มีคนนึงแสดงความเห็นว่าเพราะในขั้น Lean Starup เราทดสอบกับ user ซึ่งคือคนจริงๆ ที่เป็นสิ่งที่มี state มีการจดจำสิ่งที่เคยเกิดขี้นมาก่อน แต่ใน CI กับ CD เราทดสอบกับ test ที่เราพยายามเขียนให้ไม่มี state ผลที่ได้จาก Lean Statrup จึงไม่ได้เที่ยงตรงและ revert ได้เหมือน CI, CD แต่อย่างไรก็ตาม พบว่าการพยายามสร้างความสัมพันธ์นี้เป็นความคิดที่น่าสนใจทีเดียว

Pair Programming Done Right
session นี้ผมเข้าเพราะที่บริษัทผมทำ pair programming อยู่แล้ว และผมมีคำถามคาใจอยู่

pair programming ทำเพื่อป้องกัน bus effect (รถบัสชนคนที่รู้ code นั้นคนเดียวตาย)
คำตอบของคนที่ไม่ชอบ pair มีสองเรื่องที่ถูกตอบบ่อยมากคือ เบื่อขี้เกียจรออีกคน และอีกคนไม่รอทำอะไรไม่รู้
ผู้พูดเสนอ pattern การทำ pair programming มี 3 แบบ

  • Ping-pong A เขียน 1 test, B ทำให้ test ผ่าน และเขียนอีก 1 test ส่งกลับให้ B, … เหมาะสำหรับคู่ pair ที่เท่าเทียมกัน
  • Board and mouse คนรู้มากกว่าใช้ mouse คนรู้น้อยกว่าใช้ keyboard ใช้แก้ปัญหาคนรู้ไม่รอคนไม่รู้
  • pattern ที่สาม(ฟังชื่อภาษาอังกฤษไม่ออก) เหมือนกับการซ้อมตี Baseball โดยคนรู้เขียน test อย่างเดียว คนไม่รู้เขียน production code อย่างเดียว ใช้สำหรับให้คนรู้สามารถสร้างกรอบทางเดินให้คนไม่รู้ได้

Frameworks Dont Make Testing Easy Enough
session นี้เหมือนรวมญาติ เพราะคนที่ร่วมเป็นคนที่ทำๆ งานด้วยกันเกินกว่าครึ่งห้อง

คนเริ่มหัวข้อเค้าแสดงความเห็นว่า framework ที่เค้าได้เคยใช้ (Rails และ Android) มันรัน test ช้า ทำให้มีปัญหากับ TDD cycle เค้าเลยได้ลองคิดว่าจะพัฒนา หรือทำใหม่ควรจะต้องทำอะไร

แต่พอคุยกันไปมาพบว่าตัว Rails จริงๆ ตอนใช้แรกๆ ก็เร็วเพียงพอ แต่มันมาช้าเพราะ gem ที่ load เข้าไปเยอะๆ มากกว่า การจัดการระบบ module ที่ดีขึ้นอาจจะช่วยได้ แต่ก็จะไปขัดกับเจตนาที่ให้ feature ทั้งหลายมันออกมาแบบ out-of-the-box อย่าง magic อีก

ปิดงานด้วยการพูดรายคนว่าใครมี AHA moment อะไรในงานนี้กันบ้าง

ชอบมากครับงานนี้ ไม่เคยไป conference ไหนที่ไม่มีช่วง session ที่รู้สึกไม่อยากเข้าห้องไหนเลยมากก่อน

 

ขออภัยที่ไม่ได้ลงรูป ไม่ได้ถ่ายเยอะเท่าไหร่ และที่ถ่ายมาเบลอมาก
สามารถติดตามรูปได้จาก Facebook ของ Stanly คนจัดประจำของ Agile Singapore meetup
และจาก Facebook ของ agile66 group ที่พี่ๆ เค้าถ่ายละกัน (กด previous)