แวะไป Thailand Practical Software Engineering Conference 2015 มา #TPSE2015

งานนี้มีหลายหัวข้อที่น่าสนใจอยากเข้าฟัง แต่แยกร่างไม่ได้ ต้องเลือกตามที่สนใจมากที่สุดแล้วสรุปแบบโคตรสั้นได้ตามนี้

You Are Not Alone: Reflection on Global Software Development Industry โดยคุณ Tamara Nation จาก Rally Software

Tamara on You Are Not Alone: Reflection on Global Software Development Industry at TPSE 2015
ยุคสมัยนี้บริษัทจะอยู่รอดได้ต้องมีการตอบสนองต่อการเปลี่ยนแปลงที่รวดเร็ว การตลาดของบริษัทต้องปรับเปลี่ยนไปให้เร็วตาม การที่จะทำแบบนั้นได้สิ่งสำคัญคือเราต้องโฟกัสที่ value และ release บ่อยๆ เพื่อให้ได้ feedback กลับมาในเวลาอันรวดเร็ว

Machine Learning in Agoda โดยคุณ Uri Weiss จาก Agoda

Weiss on Machine Learning in Agoda at TPSE 2015

ที่ Agoda มีทีม data scientist อยู่ case study หนึ่งที่เอามาบอกเล่ากันคือการนำเอา machine learning ไปใช้กับการ bid ของ Google AdWords กล่าวคือเวลาที่ผู้ใช้ search ข้อมูลที่พักจาก Google แล้ว Agoda จะหาที่พักแล้วพยายามทำให้ rank ของผลลัพธ์จากการ search ไปอยู่ rank ต้นๆ เนื่องจาก Agoda มีคู่แข่งหลายบริษัท ดังนั้นการที่ทำให้ผลลัพธ์จากการ search มี Agoda อยู่ใน rank ที่สูงกว่าคู่แข่งนั้นย่อมเป็นเรื่องที่ดี

การนำเอา machine learning มาใช้ในส่วนนี้ทำให้ลดค่าใช้จ่ายไปได้เยอะเลยทีเดียว ยกตัวอย่างเช่น ถ้ามีคำว่า bangkok ในการ search เยอะๆ แล้วโรงแรมที่ผ่านการ search ด้วยคำๆ นี้สามารถเพิ่มยอดการจองได้ ทางทีมก็จะนำข้อมูลพวกนี้ไปเพิ่ม bid ให้สูงขั้นใน AdWords

Better Deliver with DevOps Driven Development โดยคุณ Jirayut Nimsaeng (เดียร์) จาก Kaidee

Jirayut on Better Delivery with DevOps Driven Development at TPSE 2015

คุณเดียร์กล่าวว่า DevOps ควรจะเป็นคนๆ หนึ่งที่เป็นทั้ง software engineer และ infrastructure engineer โดยมีวิธีคิดแบบทั้ง dev และ ops มีหน้าที่คือเรียนรู้ business ของบริษัทตั้งแต่การพัฒนาไปจนถึงการส่งมอบ แล้วได้แบ่งขั้นตอนการเริ่มต้นพัฒนาเพื่อการส่งมอบที่ดีขึ้นออกเป็น 3 ขึ้นคือ

  1. ขั้นการวางแผน คือการจ้างคนมาทำตำแหน่งนี้เลยจะได้โฟกัส หรือพัฒนาคนขึ้นมาทำตำแหน่งนี้เอง แล้วก็ลองออกแบบ development flow ในอุดมคติขึ้นมา
  2. ขั้นการปฏิบัติ คือให้ลองทำโปรเจคแบบ pilot ขึ้นมาสักโปรเจคหนึ่ง โปรเจคนี้จะต้องมีขนาดเล็กที่สามารถทำ development flow แบบในอุดมคติที่คิดขึ้นมาได้ ต้องทำออกมาจริงๆ
  3. ขั้นตอนการขยับขยาย คือทำ knowledge sharing หรือลองให้งานของ DevOps ให้คนอื่นลองทำบ้าง
ใครสนใจเรื่อง DevOps ลองดูจากสไลด์เพิ่มเติมนะครับ

สรุปโคตรสั้นกับหัวข้อที่ไปฟังมาในงาน Agile Tour Bangkok 2014 #AgileTourBKK

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

Scrum and Waterfall from the view of Plato and Aristotle โดย Fredrik Carleson

fredrik-agiletourbkk2014-scrum-philosophy

เมื่อ 2500 ปีก่อน ก็มีแนวคิดของ Agile หรือ Scrum กับ Waterfall เกิดขึ้นแล้วนะ อย่างแนวคิดของพลาโต้จะเน้นความคิดเป็นหลัก ความคิดสมบูรณ์จะไม่เปลี่ยนแปลง จะออกแนว Waterfall ที่ประมาณว่าความต้องการของลูกค้าจะไม่เปลี่ยนแปลง การพัฒนาระบบก็จะไปได้อย่างราบรื่น ส่วนแนวคิดของอริสโตเติ้ลจะแตกต่างไป แนวคิดนี้จะไม่บอกให้เชื่อแนวคิดของตัวเราเอง จะเน้นให้ออกไปทดลองทำจริง แล้วกลับมาพัฒนาแก้ไข..​ ซึ่งแนวคิด Scrum ก็เป็นเช่นนั้น

Practical Guide for First Time Product Owners โดย Alex Phelps

alex-agiletourbkk2014-po-guide

Product Backlog เป็นอาวุธที่ Product Owner (PO) จะนำเสนอแนวคิดให้กับทีมให้เข้าใจ อเล็กมีวิธีการสร้าง Product Backlog ที่ค่อนข้างจะแตกต่างจาก PO ทั่วไปคือ

  1. เก็บเกี่ยว หรือศึกษาแนวคิดต่างๆ โดยการ คุยกับ Stakeholder คุยกับ User รวมไปถึงการลองใช้ระบบของคู่แข่ง
  2. วิจัยทางด้านเทคนิค หรือทำ Spike เพื่อดูความเป็นไปได้ และดูว่าตรงความต้องการหรือเปล่า ก่อนที่จะเขียน User Story
  3. เขียน User Story เพื่อสื่อสารกับทีม
  4. สร้าง Prototype ทำ Basic UX Design รวมไปถึงทำ Mockup แบบจับต้องได้ เพื่อให้ทีมได้เข้าใจความต้องการมากขึ้น

สิ่งที่ PO ไม่ควรทำ เช่น อย่าตอบตกลงเพื่อที่ทำให้ลูกค้าพอใจ อย่าพลาดการประชุมบ่อยๆ อย่าเปลี่ยน requirement ตอน last minute ส่วนสิ่งที่ควรทำ เช่น ให้คอยบริหารจัดการความคาดหวังจาก Stakeholder อยู่ตลอดเวลา จัดการ Product Backlog ทุกวัน แล้วก็พยายามทำตัวให้ว่างเพื่อทีมจะได้ถามคำถามต่างๆ

Abstraction Is A Communication Tool, Period. โดย Terry Yin

terry-agiletourbkk2014-abstraction

คนส่วนใหญ่จะพยายามที่จะเอา Abstraction มาแก้ปัญหา ใช้เป็น Solution แต่จริงๆ แล้ว Abstraction นั้นเป็นแค่เครื่องมือในการสื่อสาร เราควรจะใช้แค่นั้น

Do and Don’t for Continuous Delivery โดย Michael Athiwat Wongwaisayawan

michael-agiletourbkk2014-cd

สิ่งที่ควรทำก็มีอย่างเช่น สร้างวัฒนธรรม DevOps ขึ้นมา รวมไปถึงการทำ Feature Toggle สิ่งที่ไม่ควรทำก็อย่างเช่น จ้างตำแหน่ง DevOps มา ซึ่งตรงนี้มองว่าเป็นการแก้ปัญหาไม่ถูกจุด การแก้ปัญหาจริงๆ ควรจะเป็นการสร้างวัฒนธรรม DevOps ขึ้นมามากกว่า โดย Dev Team กับ Ops Team จะต้องร่วมมือกัน และสื่อสารกันให้ดี ผมชอบสไลด์ข้างล่างนี้มากเลย

michael-agiletourbkk-2014-devops

ส่วน Panel Discussion นั้น.. ไม่ได้เข้าครับ แหะๆ

ปล. ดูตารางงานได้ที่  Agile Tour Bangkok 2014 Schedule
ปล. อีกรอบ สไลด์ของแต่ละหัวข้อจะอยู่ที่ Agile Tour Bangkok 2014 Slides

ลองเล่น Puppet Master กับ Puppet Agent บนเครื่องเราเอง

หมายเหตุ ทดสอบกับ Ubuntu เวอร์ชั่น 14.04 Vagrant เวอร์ชั่น 1.5.3 และ Puppet เวอร์ชั่น 3.7.3

อย่างน้อยเราต้องมีเครื่องสัก 2 เครื่อง เครื่องหนึ่งติดตั้ง Puppet Master และอีกเครื่องหนึ่งติดตั้ง Puppet Agent วิธีที่ง่ายที่สุด และถูกที่สุดคือสร้าง Virtual Machine (VM) ขึ้นมาใช้งาน ถ้า Geek หน่อยก็ใช้ Vagrant สร้าง Multi-Machine สร้าง VM บล็อกนี้จะขอแนะนำให้ใช้ Vagrant นะครับ ชีวิตสบายขึ้นเยอะ

Continue reading "ลองเล่น Puppet Master กับ Puppet Agent บนเครื่องเราเอง"