Pattern หนึ่งในการทำ Puppet Deployment

ช่วงนี้มีโอกาสได้ลองเริ่มใช้ Puppet กับงานที่บริษัทแบบจริงๆ จังๆ แล้วก็กำลังคิดถึงวิธีที่จะเอาสคริป Puppet ของเราไปวางไว้ที่ตัว Master สเต็ปที่คิดว่าจะทำคือ

  1. เขียนโค้ด รันเทสบนเครื่องให้เสร็จ
  2. Push เข้า Github
  3. ให้ CI รันเทสให้อีกที
  4. เอาสคริปสำหรับการ Deploy เข้า Puppet Master ไปวางไว้ใน CI แล้วให้ CI เป็นคนรัน

ไม่ค่อยแน่ใจว่าชาวบ้านทำกันแบบนี้หรือเปล่า เลยลองกูเกิ้ลเรื่อยๆ อยู่หลายวันก็ไม่ค่อยเจอคนบอกรายละเอียดสักเท่าไหร่ ส่วนใหญ่จะเจอแต่คำว่า Deploy แต่ไม่ค่อยเจอว่าเค้าทำกันอย่างไร วันนี้ว่างจัดเลยนั่งเคลียร์อีเมลที่ดองไว้ แล้วก็เจอเมลของ Sysadmin Casts ข้างในเนื้อหามีหัวเรื่องว่า Git to Puppet Deployment workflow ลองเข้าไปดูแล้วก็มั่นใจว่าที่เราคิดไว้ก็ถือว่าเป็น Pattern หนึ่งเหมือนกัน :) ลองดูรูปข้างล่างนี้

Episode #33 - Git to Puppet Deployment Workflow

Git to Puppet Deployment Workflow (Credit: https://sysadmincasts.com/)

Pattern ที่เค้าทำ (เจ้าตัวก็บอกว่าไม่รู้ผิดหรือเปล่าเหมือนกัน) ก็คล้ายๆ กับที่คิดไว้ แต่ของเค้าจะใช้ Hook แทนเป็นตัวคอยรันเทสแล้วก็เอาโค้ดเข้า Puppet Master

 

สรุปโคตรสั้นกับหัวข้อที่ไปฟังมาในงาน 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 นะครับ ชีวิตสบายขึ้นเยอะ

Read More

 

บางส่วนของบทสัมภาษณ์ Justin Moore หนึ่งในทีม Data Science ที่ Facebook

ตัดมาจากบทความของ VentureBeat ที่เค้าได้ไปสัมภาษณ์ Justin Moore (Data Science Manager ในทีม Places ที่ Facebook) และได้ถามว่า ที่ Facebook คุณจำเป็นต้องมีความรู้ความสามารถอะไรบ้างที่จะเป็น Data Scientist ได้ ลองไปดูคำตอบกัน

Eric Blattberg: What skills do you need to be a data scientist at Facebook?

Justin Moore: You need to have really strong math skills, the ability to pick up statistics, and whatever else you need to be a strong software engineer. It’s the same interview process: You’re basically a software engineer, which we have a very high bar for here. You also need to have a product sense: You need to be someone who can not only just write algorithms, you need to know why, to figure out when somebody says that something is a problem, to say, ‘This is what I think we should do from an algorithmic perspective to solve that problem.’

ผมใช้สีแดงเพื่อเน้นประโยคที่เป็นการตอกย้ำว่าความรู้ทางด้านคณิตศาสตร์และความสามารถในการเอาความรู้ทางด้านสถิติมาใช้เป็นสิ่งที่จำเป็นอย่างมากถึงมากที่สุดในการทำงานด้านนี้

อ่านบทสัมภาษณ์นี้จบค่อยมีแรงกระตุ้นให้ขยันขึ้นอีกระดับหนึ่งหน่อย ความรู้ด้าน Math & Statistics ของเรายังอ่อนด้อยนัก..

 

 

Elasticsearch คืออะไร?

เนื่องจากที่บริษัทกำลังจะก้าวเข้าสู่โลก Big Data (จริงๆ เข้ามานานแล้วแหละ แต่เริ่มจะมีโอกาสได้ใช้ประโยชน์จากมัน) ช่วง 3-4 วันที่ผ่านมานี้ก็เลยมีโอกาสได้ลองแตะๆ Elasticsearch อยู่บ้าง จริงๆ มีอีกตัวหนึ่งที่คิดไว้คือ Solr แต่ส่วนตัวแล้วชอบชื่อ Elasticsearch มากกว่า ดูหล่อกว่า เลยเริ่มศึกษาจาก Elasticsearch ก่อน

Read More