ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ

March 23, 2016, 9:12 am

≫ Next: ทำอย่างไร ถึงจะได้ feedback ที่รวดเร็ว ?

≪ Previous: Developer ใช้ Coding Standard กันหรือเปล่านะ ?

$

0

0

วันนี้มีโอกาสได้แบ่งปันความรู้เรื่อง Continuous Integration (CI) สำหรับปรับปรุงคุณภาพของการพัฒนา Software ให้ดีขึ้น โดยหัวใจของ CI นั้นประกอบไปด้วย 2 คำคือ

1. Continuous หรือ Frequent คือ ทำบ่อย ๆ อย่างต่อเนื่อง
2. Integrate หรือ Merge คือ การรวมกันของสิ่งต่าง ๆ ในระบบ

รวมกันก็หมายความว่า ให้ทำการรวมกันบ่อย ๆ อย่างต่อเนื่อง มีคำถามที่น่าสนใจคือ

• อะไรที่ต้องนำมารวมกันบ้าง ?
• ทำการรวมกันที่ไหน ?

ตอบได้ง่าย ๆ คือ

• source code ไงล่ะ
• รวมกันที่ Version Control System หรือ Repository ไงละ

ดังนั้น CI เป็นกระบวนการที่นำการเปลี่ยนแปลงต่าง ๆ ของ source code ไปรวมกันไว้ที่ Version Control System บ่อย ๆ และ อย่างต่อเนื่อง

ปล. ถ้าใครไม่ใช้งาน Version Control System เช่น Git, SVN เป็นต้น ก็น่าจะบาปอย่างแรงส์ !!

สิ่งที่ขาดไม่ได้เลยในกระบวนการของ CI คือ คำว่าคุณภาพ

เราจะรู้ได้อย่างไรว่า แต่ละการเปลี่ยนแปลงนั้น

• ระบบยังสามารถทำงานได้อย่างถูกต้องหรือไม่ ?
• ระบบยังสามารถทำงานได้ตามความคาดหวังหรือไม่ ?

ขอเน้นย้ำว่าทุกการเปลี่ยนแปลงนะ หนึ่งในนั้นคือ การทดสอบนั่นเอง แน่นอนว่า ต้องเป็นการทดสอบแบบอัตโนมัติอย่างแน่นอน (Automated testing) ไม่ว่าจะเป็น Unit testing, Integration testing และ Functional testing ส่งผลให้สามารถทดสอบได้บ่อย ๆ ส่งผลให้สามารถรู้สถานะของระบบได้ตลอดเวลา ส่งผลให้ได้ feedback ของระบบอยู่อย่างเสมอ ไม่ว่าจะดีหรือร้าย ทำให้ทุกคนเห็นความคืบหน้าของการพัฒนา

มาดูกันหน่อยว่าขั้นตอนใน CI ควรเป็นอย่างไรบ้าง ?

อาจจะเรียกว่า Continuous Integration Process หรือบางคนอาจจะเรียกว่า Build pipeline ซึ่งผมขออธิบายตั้งแต่เรื่องพัฒนาของ Developer แต่ละคนกันเลย มีขั้นตอนดังนี้

1. Developer แต่ละคนต้องสามารถ build, test และ run ระบบที่เครื่องตัวเองได้
2. เมื่อทำการพัฒนา feature เสร็จ แน่นอนว่าต้องมีชุดการทดสอบแบบอัตโนมัติด้วยเสมอ
3. Developer ต้องทำการ build, test และ run บนเครื่องของตัวเอง เพื่อทำให้แน่ใจว่าระบบทำงานได้ถูกต้อง
4. Developer ต้องทำการ build, test และ run บนเครื่องของตัวเอง เพื่อทำให้แน่ใจว่าสิ่งที่เปลี่ยนแปลงไม่กระทบส่วนอื่น ๆ
5. ให้ทำการดึง source code ล่าสุดจาก Repository ของระบบ เพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่
6. ถ้ามีการเปลี่ยนแปลงก็ให้ทำการรวม หรือ merge ที่เครื่องของ Devleoper ก่อน จากนั้นจึงทำการ build, test และ run อีกรอบ
7. แต่ถ้าเกิดปัญหา หรือ ข้อขัดแย้งต่าง ๆ ก็ให้ทำการแก้ไขที่เครื่อง Developer ก่อนเสมอ
8. เมื่อทุกอย่างผ่านทั้งหมด ให้ทำการส่งการเปลี่ยนแปลงไปยัง Repository กลาง
9. เมื่อ Repository กลางมีการเปลี่ยนแปลง จะต้องมีระบบ CI ทำการ build, test และ run อีก เพื่อทำให้มั่นใจต่อระบบ
10. แต่ถ้าเกิดความผิดพลาดบนระบบ CI จะทำการแจ้งไปยังทีมพัฒนา เพื่อให้ทุกคนหยุด เพื่อทำการแก้ไขให้ผ่าน
11. เมื่อทุกอย่างบนระบบ CI ทำงานเรียบร้อยก็สามารถส่งผลลัพธ์ไปยังส่วนการทำงานอื่นต่อไป เช่น การทดสอบ และ การ deploy หรือส่งต่อไปยังระบบ Continuous Delivery เป็นต้น

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

• ระบบจะไม่พังจริง ๆ หรอ ?
• สิ่งที่แก้ไขจะไม่กระทบส่วนอื่น ๆ จริงหรอ ?
• เสร็จจริง ๆ หรอ ?
• .....

มาดูประโยชน์ของ Continuous Integration กันบ้าง

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

ถ้าอยากรู้ว่าจริงหรือไม่ ก็ให้ลงมือทำด้วยมือของตัวเองสิ

ปล. การทดสอบแบบอัตโนมัตินั้น ควรครอบคลุมทั้ง Functional และ Non-functional requirement

โดย Continuous Integration (CI) นั้น

เป็นพื้นฐานที่สำคัญอย่างยิ่งของ Continuous Delivery และ Continuous Deployment ทำให้เราพร้อมที่จะ deploy และ release ระบบงานได้ตามที่ต้องการ โดยเรื่องคุณภาพนั้นมันไม่สามารถต่อรองได้เลย ต้อง Build-in อยู่ในทุกขั้นตอนของการพัฒนา สามารถอ่านเรื่อง 10 แนวปฏิบัติที่ดีของ Continuous Integration ได้ ปิดท้ายด้วยเรื่องของเครื่องมือสำหรับระบบ CI ก็ลองไปดูเพิ่มเติ่มได้ที่ List of CI Tools

แต่เหนือสิ่งอื่นใดทุกสิ่งทุกอย่างมันถูกสร้างมาจากคน ดังนั้นเรื่องคุณภาพของคนจึงสำคัญอย่างมาก

---

ทำอย่างไร ถึงจะได้ feedback ที่รวดเร็ว ?

March 25, 2016, 5:43 am

≫ Next: ทำการ update ข้อมูลระหว่าง Elasticsearch กับ Database อย่างไรดี ?

≪ Previous: ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ

$

0

0

เรามักจะได้ยินคำว่า Fail Fast Lea[r]n Fast ในการพัฒนา software แบบ incremental และ interactive นั้นเราต้องการ feedback ที่รวดเร็วที่สุดเท่าที่จะทำได้ เพื่อทำให้เรารู้ว่า สิ่งที่ทำอยู่นั้นมันถูกต้อง และ เป็นสิ่งที่ต้องการ ในการพัฒนา software เราต้องการรู้สิ่งต่าง ๆ เหล่านี้อย่างรวดเร็ว

• สิ่งที่เราสร้างทำงานได้อย่างถูกต้อง ?
• สิ่งที่คนอื่นสร้างทำงานได้อย่างถูกต้อง ?
• เมื่อ deploy ระบบงานแล้วยังทำงานได้ ?
• สิ่งที่พัฒนานั้นมันตรงกับความต้องการของลูกค้า ?
• ทำให้ business มันดีขึ้น ?

ดังนั้นเรามาตอบคำถามต่าง ๆ เหล่านี้กันดีกว่า

1. สิ่งที่เราสร้าง สามารถทำงานกับส่วนอื่น ๆ ได้อย่างถูกต้อง ?

คำตอบสำหรับผมคือ คุณทำการตรวจสอบ code ที่เขียนหรือไม่ ? นั่นคือการเขียน Unit test และ Integration test นั่นเอง มันทำให้คุณมั่นใจได้ว่า ส่วนเล็ก ๆ ที่คุณสร้างขึ้นมานั้น ยังสามารถทำงานได้ตามความคาดหวัง และยังทำงานกับ code ส่วนอื่น ๆ ได้อีกด้วย โดย feedback ในส่วนนี้จะได้รับ feedback ที่รวดเร็วมากถึงมากที่สุด อยู่ในระดับวินาทีกันไปเลย

2. สิ่งที่แต่ละคนในทีมสร้างขึ้นมานั้น เมื่อนำมารวมกันยังทำงานได้อย่างถูกต้องหรือไม่ ?

คำตอบสำหรับผมคือ Continuous Integration (CI) ไงล่ะ ไม่ใช่ทำการ integrate ส่วนต่าง ๆ ในช่วงท้ายของการพัฒนา แต่เราจะทำการ integrate ส่วนต่าง ๆ กันอย่างบ่อย ๆ บ่อยเท่าใดล่ะ ก็ทุกครั้งที่เกิดการเปลี่ยนแปลงนั่นเอง เพื่อทำให้เรารู้ว่า เมื่อนำส่วนการทำงานต่าง ๆ มารวมกันแล้ว ระบบงานยังคงทำงานได้อย่างถูกต้อง ทำให้เราไม่ต้องเสียเวลาในการแก้ไขเป็นสัปดาห์ หรือ เป็นเดือน !! แสดงการทำงานดังรูป

3. เมื่อทำการ deploy ระบบยังทำงานได้อย่างถูกต้อง​ ?

สิ่งที่เราต้องการคือ ทำการ deploy และดูว่าระบบทำงานได้อย่างถูกต้องหรือไม่ เพื่อทำให้เรามั่นใจว่า ระบบมีคุณภาพเพียงพอที่จะ deploy ไปยัง production server ซึ่งในตอนนี้เรามี Unit test, Integrate test และระบบ Continuous Integration มันทำให้เรามั่นใจว่า ระบบทำงานได้ดีใน development environment แน่นอนว่า เราต้องทำการ deploy และ ทดสอบใน environment อื่น ๆ ด้วย เพื่อทำให้เรามั่นใจ ก่อนที่จะนำขึ้น production server จากรูป ทำอย่างไรเพื่อให้ได้ feedback ที่รวดเร็ว ? คำตอบคือ ต้องจัดการและเตรียม Deployment Pipeline เพื่อทำให้เราสามารถ deploy และ ทดสอบในแต่ละ environment ได้อย่างรวดเร็ว และจะทำให้เรามั่นใจ และ เชื่อมั่นต่อ code และ ระบบมากยิ่งขึ้น โดยในแต่ละ environment นั้นควรทำการทดสอบอบบขนาน (Parallel testing) เพื่อให้ได้รับ feedback ที่รวดเร็วมากขึ้น

4. สิ่งที่เราพัฒนาขึ้นมานั้นตรงกับความต้องการของลูกค้า และ ทำให้ธุรกิจดีขึ้น ?

เนื่องจาก feedback จากลูกค้า และ ผู้ใช้งานนั้น มักจะมีจำนวนที่เยอะมาก ๆ ดังนั้นสิ่งที่เราควรจะทำก็คือ รู้ให้รวดเร็วที่สุดเท่าที่จะทำได้ เพื่อทำการเรียนรู้จากความต้องการเหล่านั้น เพื่อทำให้สามารถปรับเปลี่ยนได้อย่างรวดเร็ว มิเช่นนั้น จะมีแต่งานเร่ง กับ งานด่วน และ งานด่วนมาก ๆ คำถาม เราจะได้รับ feedback ต่าง ๆ จากลูกค้า และ ผู้ใช้งานได้รวดเร็วอย่างไร ? คำตอบ คุณต้องทำการ deploy และ release บ่อย ๆ ไงล่ะ นั่นคือ คุณต้องเรียนรู้และนำแนวคิด Continuous Delivery (CD) และ Continuous Deployment (CD) มาใช้งาน โดยเราสามารถนำเอาแนวคิด CD และ Deployment pipeline มาใช้ ก็จะช่วยให้คุณได้รับ feedback กลับมาอย่างรวดเร็ว หรือช่วยตอบคำถามหรือข้อสงสัยของคุณได้เร็วยิ่งขึ้น รวมทั้งยังช่วยให้คุณสามารถปรังปรุง และ เปลี่ยนแปลง business model ได้ดีอีกด้วย

สุดท้ายแล้ว มีสองสิ่งที่จะช่วยทำให้คุณได้รับ feedback อย่างรวดเร็ว

สิ่งแรกคือ ต้องทำบ่อย และเป็นประจำ แน่นอนว่ามันช่วยทำให้สิ่งที่ยากกลายเป็นสิ่งที่ง่ายไปเลย อะไรที่มันยาก ก็ทำบ่อย ๆ เท่านั้นเอง แสดงดังรูป ลองคิดดูสิว่า ถ้าเราสามารถทำบ่อย ๆ ได้ แสดงว่า งานเหล่านั้นต้องมีขนาดเล็ก ๆ รวมทั้งทำให้เราสามารถนำ feedback ไปปรับปรุงได้อย่างรวดเร็ว และทำให้เราสร้างสิ่งที่ใช่มากขึ้น สิ่งที่สองคือ ต้องทำงานแบบอัตโนมัติ ถ้ายังทำงานแบบ manual หรือใช้คนมาก ๆ แล้ว เป็นไปไม่ได้เลยที่จะได้รับ feedback อย่างรวดเร็ว และ บ่อย ๆ เพราะว่า คนมีชีวิตจิตใจ สร้างความผิดพลาดได้เสมอ ดังนั้น งานอะไรที่ทำซ้ำ ๆ ก็ ลด ละ เลิก และให้ทำงานแบบอัตโนมัติซะ ดังนั้นเมื่อเข้าใจขั้นตอนการทำงานต่าง ๆ แล้ว จึงไปศึกษา และ เลือกเครื่องมือที่เหมาะสมกับความต้องการต่อไป อย่าเริ่มจากเครื่องมือนะครับ !!

สิ่งที่ต้องถามตัวเราเอง คือ เรารู้ feedback ในเรื่องต่าง ๆ อย่างไร และรวดเร็วเพียงใด ?

Reference Website https://blog.snap-ci.com/blog/2016/03/22/fail-fast/ https://www.thoughtworks.com/insights/blog/fail-fast-learn-fast http://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-delivery-continuously

ทำการ update ข้อมูลระหว่าง Elasticsearch กับ Database อย่างไรดี ?

March 27, 2016, 1:31 am

≫ Next: สรุปจากการอ่านหนังสือ Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

≪ Previous: ทำอย่างไร ถึงจะได้ feedback ที่รวดเร็ว ?

$

0

0

คำถามหนึ่งที่ได้ยินบ่อยมาก ๆ สำหรับการนำ Elasticsearch มาใช้งานนั่นก็คือ

จะทำการ migrate และ update ข้อมูลระหว่าง  Elasticseach กับ Database อย่างไรดี ?

โดย Database นั้นหมายถึง ที่จัดเก็บข้อมูลของระบบในปัจจุบัน ตัวอย่างเช่น RDBMS, File system และ Memory เป็นต้น มาดูกันว่ามีวิธีการใดบ้าง ?

ถ้าเป็น Elasticsearch ก่อนเวอร์ชั่น 2.0

จะมีสิ่งที่เรียกว่า River API ให้ใช้งาน ซึ่งจะมี JDBC River ไว้สำหรับการดึงข้อมูลจาก Database มาจัดเก็บที่ Elasticsearch อย่างอัตโนมัติ แต่ว่าตั้งแต่เวอร์ชั่น 2.0 ได้นำเอาความสามารถนี้ออกไป ดังนั้นวิธีการนี้จึงไม่ขอแนะนำอีกต่อไป

ส่วนวิธีการที่ขอแนะนำคือ เขียนโปรแกรมเอาเองเลยดีกว่า !!

เนื่องจากการเขียนโปรแกรมเอง มันจะยืดหยุ่นกว่า ตอบรับกับความต้องการที่เปลี่ยนแปลงอยู่ตลอดเวลามากกว่า แต่ข้อเสียคือ ต้องเสียเวลามาเรียนรู้วิธีการเขียนโปรแกรมอีก ซึ่งมันเป็นเรื่องปกติที่มีข้อดีก็ต้องมีข้อเสีย รูปแบบการ update หรือ sync ข้อมูล แสดงดังรูป

ก่อนที่จะลงมือเขียนโปรแกรมหรือเลือกเครื่องมือ มาดูรูปแบบของข้อมูลที่จะจัดเก็บก่อนไหม ?

เพื่อทำให้เข้าใจก่อนว่า ข้อมูลที่จะจัดเก็บเป็นอย่างไร ซึ่งนำข้อมูลมาจากบทความ Four ways to index relational data in Elasticsearch รูปแบบที่ 1 ข้อมูล 1 row จาก Database คือ 1 Document ใน Elasticsearch เป็นวิธีที่ง่าย และ ตรงไปตรงมาสุด ๆ แสดงดังรูป รูปแบบที่ 2 ข้อมูลจำนวนมากกว่า 1 row จาก Database คือ 1 Document ใน Elasticsearch แสดงดังรูป ดังนั้นสิ่งที่ต้องทำก่อนนำข้อมูลเข้า Elasticsearch คือ ต้องทำการ join ข้อมูลจาก 2 Table ก่อนเสมอ แสดงดังรูป จากนั้นในการจัดเก็บที่ Elasticsearch ก็ให้เก็บลง field/property ในรูปแบบของ Array ได้เลย เป็นรูปแบบหนึ่งของการ Denomalization นั่นเอง รูปแบบที่ 3 ทำการจัดเก็บข้อมูลใน Elasticsearch แบบ Nested object มาดูตัวอย่างเพื่อความเข้าใจมากขึ้น เป็นข้อมูลจาก 2 table คือ products และ sizes แสดงดังรูป ก่อนที่จะจัดเก็บข้อมูลลงไปยัง Elasticsearch ต้องทำการ join ข้อมูลกันก่อน และเลือกเฉพาะ column ที่จำเป็นต่อการใช้งานเท่านั้น ไม่ควรเก็บข้อมูลที่ไม่จำเป็นหรือไม่ได้ใช้งาน ส่วนข้อมูลจาก sizes มีโครงสร้างแบบ Nested object หรือข้อมูล 1 product จะอยู่ใน 1 document เท่านั้น แสดงดังรูป

ข้อควรจำ

ก่อนจะเก็บข้อมูลลงใน Elasticsearch ต้องคิดก่อนเสมอว่า ปัญหาคืออะไร และ จะแก้ไขอย่างไร ไม่ใช่ตั้งหน้าตั้งตาเก็บกันอย่างเดียว !! นั่นคือ เก็บเท่าที่จำเป็น เก็บเท่าที่ใช้ เรานำ Elasticsearch มาใช้เพื่อช่วย ทำให้ระบบการค้นหามันสะดวกขึ้น ทำให้ระบบการค้นหามันง่ายขึ้น ทำให้ระบบการค้นหามันเร็วขึ้น มิใช่นำมาแทนที่ Database หลักนะครับ คำแนะนำจาก Elasticsearch บอกว่าในการ update/sync นั้นให้ใช้ Bulk API และเขียนเองเถอะ ไม่จำเป็นต้องไปเครื่องมือใด ๆ เลย ซึ่งอ้างอิงมาจากบทความเรื่อง Keeping elasticsearch in sync  

สรุปจากการอ่านหนังสือ Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

March 27, 2016, 10:30 am

≫ Next: ความเข้าใจผิดเกี่ยวกับ Continuous Integration และ Continuous Delivery

≪ Previous: ทำการ update ข้อมูลระหว่าง Elasticsearch กับ Database อย่างไรดี ?

$

0

0

วันนี้ระหว่างเดินทางกลับจากเชียงใหม่ เดินผ่านร้านหนังสือในสนามบิน เห็นหนังสือชื่อว่า Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days เพียงแค่เห็นชื่อหนังสือเท่านั้นแหละ หยิบไปจ่ายเงินเลย ทั้ง ๆ ที่ไม่ได้เปิดดูเนื้อหาในหนังสือเลย แต่เมื่ออ่านไปได้ 3 บท ก็ต้องหยุด และ มาสรุปกันเลยทีเดียว !!

เริ่มด้วยโครงสร้างของหนังสือ หรือ ของ Sprint นั่นเอง

แสดงดังรูป เริ่มด้วยที่มาที่ไปของคำว่า Sprint หรือรอบการทำงาน ว่าทำไมต้อง Sprint ละ 5 วัน ? โดยมาจากการลองผิดลองถูก ตั้งแต่รอบละ 2-4 สัปดาห์ พบว่า รอบการทำงานมันยาวนานเกินไป และไม่ได้ผลที่ต้องการเมื่อจบ Sprint การทำงาน หรือได้รับ feedback จากผู้ใช้งานจริง ๆ ช้าไป บางครั้งจมอยู่กับปัญหา และ ไม่ focus ในเป้าหมาย อันเนื่องมาจากเป้าหมายมันใหญ่ และ เยอะจนเกินไป !!

จากนั้นทำการแนะนำการเตรียมตัวก่อนเริ่มเข้า Sprint เรียกว่า Set the stage

ต้องประกอบไปด้วยสิ่งต่าง ๆ ดังนี้

1. เป้าหมายที่ชัดเจนและมีความท้าทายด้วย (Challenge)
2. ทีมงานที่ลงตัว (Team)
3. มีการจัดการเวลาที่ดี และ พื้นที่การทำงานที่เหมาะสม สำหรับการทำงานของ Sprint (Time and Space)

ถือว่าเป็นสิ่งจำเป็นอย่างมาก เนื่องจากถ้าไม่มีเป้าหมายที่ชัดเจน และ ท้าทาย งานนั้นก็ไม่น่าทำ ในแต่ละ Sprint ควรมีปัญหา และ ความท้าทายที่ใหญ่ ถ้างานมันง่ายไป ใคร ๆ ก็ทำได้แล้ว ผลที่ออกมามันจึงไม่ชัดเจน !! ที่สำคัญไม่มีปัญหาที่ใหญ่ไปกว่า 1 Sprint หรือ 5 วัน ดังนั้นสิ่งที่ทีมต้องรู้และเข้าใจ คือ เป้าหมายที่ชัดเจน และในแต่ละ Sprint ทีมจะต้องเรียนรู้จากมุมมองของ product สุดท้าย ซึ่งทำให้ทีมเห็นว่า สิ่งที่ทำนั้นยังอยู่ในเป้าหมายที่ตั้งไว้หรือไม่นั่นเอง เนื่องจากถ้าไม่มีทีมงานที่ลงตัว มีความพร้อม มีความสามารถในด้านต่าง ๆ ที่จำเป็น ก็ไม่สามารถทำงานที่ดีออกมาได้ แถมมีเวลาเพียง 5 วันเท่านั้น !! ดังนั้นความสามารถของคนในทีมต้องแจ่มเช่นกัน ซึ่งต้องประกอบไปด้วยคนที่มีหน้าที่ต่าง ๆ ดังต่อไปนี้

• คนที่ตัดสินใจได้ (Decider)
• คนที่คอยกำหนดจังหวะต่าง ๆ ของการทำงาน (Facilitator)
• Expert domain ในเรื่องต่าง ๆ ที่จำเป็นต่องานที่กำลังทำ เช่น การเงิน การตลาด เกี่ยวกับลูกค้าสัมพันธ์ เทคโนโลยี และ การออกแบบ เป็นต้น

ทีมจะต้องทำงานกันเป็นทีมเสมอ

เนื่องจากถ้าไม่มีการจัดการเรื่องเวลาที่ดี ก็จะวางแผนอะไรไม่ได้เลย เช่นการประชุม และ สิ่งรบกวนต่าง ๆ สิ่งที่ผมชอบมาก ๆ คือ การอธิบายว่า สาเหตุที่งานไม่คืบหน้าเลย หรือ productivity แย่มาก ๆ เนื่องจากมีสิ่งรบกวนมากมายตลอดทั้งวัน เช่น การประชุม, email, มือถือ รวมไปถึงงานแทรกต่าง ๆ มากมาย แสดงดังรูป ดังนั้น การทำงานใน Sprint 5 วันนั้น จำเป็นต้องเปลี่ยนจังหวะการทำงานใหม่ โดยให้เริ่มทำงานตั้งแต่ 10.00 - 17.00 น. ช่วงที่หายไป คือ

• 9.00 - 10.00 น. ให้ทุกคนเตรียมตัวก่อนเริ่มทำงาน
• 17.00 - 18.00 น. ให้ทุกคนหยุดทำงาน พักเหนื่อยก่อนกลับ อย่าลืมว่าต้องทำงานกันทั้งสัปดาห์

ห้ามมีสิ่งรบกวนต่าง ๆ ในระหว่างการทำงานด้วย นั่นคือ ทุกคนในทีมจะต้อง focus ในงานสูงมาก ๆ รวมทั้งมีการพักผ่อนระหว่างการทำงานด้วย แสดงดังรูป ในหนังสือแนะนำเรื่อง The no-device rule นั่นคือ ให้ทุกคนปิดโทรศัพท์ และ สิ่งรบกวนต่าง ๆ หรือถ้าจะรับโทรศัพท์ หรือ chat ก็ให้ออกไปข้างนอก ไม่ใช่เล่นไป คุยไป ทำงานไป เพื่อให้ทุกคนมีสมาธิกับงานที่ทำ เนื่องจากถ้าไม่มีการจัดเตรียมพื้นที่การทำงานที่เหมาะสม ก็ไม่สามารถทำงานร่วมกันได้ เช่น ห้อง โต๊ะ เก้าอี้ พวก whiteboard และ อุปกรณ์ต่าง ๆ ที่พร้อมจะเปลี่ยนแปลงและเคลื่อนย้ายอยู่ตลอดเวลา

Good workspace not to be Fancy

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

มีคำถามที่น่าสนใจ คือ งานแบบไหนที่เหมาะกับการทำงานเป็น Sprint ?

คำตอบในหนังสือคือ เหมาะสำหรับงานทุกประเภทนั่นแหละ ถ้ารู้ว่ามันคืออะไร ? ถ้ารู้ว่ามันสำคัญอย่างไร ? ถ้ารู้ว่าอะไรคือสิ่งที่สำคัญ ? เนื่องจากการทำงานในช่วงสั้น ๆ มันทำให้เรา focus กับงานนั้น ดังนั้น จะไม่มีเวลามา drama กันหรอกนะ

ต่อมาทำการอธิบายว่า ในแต่ละวันต้องทำอะไรบ้าง

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

1. วันจันทร์ ทำความเข้าใจกับเป้าหมาย และ ปัญหา เพื่อให้เห็นว่าอะไรที่สำคัญ และกำลังจะทำอะไรกัน
2. วันอังคาร ทำการคิดและเขียน solution ต่าง ๆ ออกมา ซึ่งเขียนบนกระดาษ
3. วันพุธ ทำการตัดสินใจว่าจะทำอะไร เพื่อเปลี่ยนจากแนวคิดมาเป็นสิ่งที่สามารถนำไปทดสอบได้
4. วันพฤหัสบดี ทำการสร้างและพัฒนาออกมาเป็น prototype ที่ใช้งานจริงได้
5. วันศุกร์ ทำการทดสอบกับผู้ใช้งานจริง ๆ

โดยรวมแล้วเป็นหนังสือแบ่งปันประสบการณ์ที่ดีมาก

ได้เห็นและเข้าใจที่ไปที่มาของแนวคิด ว่าลองผิดลองถูกมาอย่างไรบ้าง และเป็นหนึ่งแนวทางของการทำงานเท่านั้น เพื่อทำให้คุณทำงานได้อย่างรวดเร็ว และทำให้คุณมั่นใจได้ว่า สิ่งที่ทำมันยังอยู่ในเส้นทางที่ถูกต้อง ใครสนใจก็ลองไปซื้อหามาอ่านกันได้ ผมว่าหลาย ๆ คนน่าจะชอบนะครับ Reference Websites http://www.thesprintbook.com/

ความเข้าใจผิดเกี่ยวกับ Continuous Integration และ Continuous Delivery

March 28, 2016, 4:10 am

≫ Next: ทำการ Deploy Android app ขึ้น Google Play แบบอัตโนมัติด้วย Fastlane Supply

≪ Previous: สรุปจากการอ่านหนังสือ Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

$

0

0

เมื่อมีการพูดถึงคำว่า Continuous Integration (CI) และ Continuous Delivery (CD) แล้ว คนส่วนใหญ่มักจะคิดถึง หรือ พูดถึงเครื่องมือต่าง ๆ ก่อน ไม่ว่าจะเป็น Jenkins บ้างล่ะ ไม่ว่าจะเป็น Bamboo บ้างล่ะ ไม่ว่าจะเป็น Travis CI บ้างล่ะ ไม่ว่าจะเป็น Circle CI บ้างล่ะ ไม่ว่าจะเป็น Docker บ้างล่ะ ไม่ว่าจะเป็น Ansible บ้างล่ะ ซึ่งเครื่องมือเหล่านี้มันเป็นเพียงตัวช่วยทำให้ความต้องการเราสำเร็จเท่านั้น แต่ก่อนอื่นต้องเข้าใจตัวเองก่อนว่า

• ปัญหาคืออะไร ?
• แต่ละคน แต่ละทีมต้องการอะไร ?
• ขั้นตอนการทำงานเป็นอย่างไร ?
• คนพร้อมไหม ?
• องค์กรพร้อมไหม ?

บ่อยครั้งในการพูดคุยเรื่อง CI และ CD

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

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

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

หนักไปกว่านั้นต่างฝ่ายก็ตั้งแง่ตั้งโล่ห์ใส่กัน กลายเป็นการทำงานแบบ Silo หรือของใครของมันหนักกว่าเดิมอีก !! แทนที่จะช่วยแก้ไขปัญหา กลับมาสร้างปัญหา

ดังนั้นสิ่งที่ต้องรู้ และ เข้าใจก่อนคือ

Continuous Integration Process Continuous Delivery Process จะเห็นว่าคำว่า process หรือ ขั้นตอนการทำงาน มันจะตามหลัง CI และ CD นะ เพื่อทำให้คุณ คุณ คุณ ทำความเข้าใจกับขั้นตอนการทำงาน และความต้องการของฝ่ายต่าง ๆ ในองค์กร เพื่อให้ได้ขั้นตอนการทำงานที่เหมาะสม ที่ช่วยลดปัญหาต่าง ๆ ลงไป ที่ช่วยลดความเจ็บปวดต่าง ๆ ลงไป จากนั้นจึงเริ่มมองหาวิธี และ เครื่องมือมาใช้งานต่อไป

ในองค์กรใหญ่ ๆ นั้น แน่นอนว่าต้องมีคนประสานงาน

เพื่อให้ทุกฝ่ายทำงานไปในทิศทางเดียวกัน ถามว่า งานเยอะไหม ? ตอบว่าเยอะมาก ถามว่า ปัญหาเยอะไหม ? ตอบว่าเยอะมาก แต่ถามว่ายากไหม ? ตอบว่ายาก นั่นแสดงว่าทำได้นะสิ !! ต้องค่อย ๆ แก้ไขปัญหาไปเรื่อย ๆ อย่าหยุดยั้ง แสดงดังรูป

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

สุดท้ายขอสรุปแนวทางที่ดีสำหรับการเริ่ม CI และ CD ไว้ดังนี้

1. ให้เริ่มที่คนและขั้นตอนการทำงาน ก่อนเครื่องมือเสมอ
2. ให้เข้าใจปัญหา และ ความต้องการของแต่ละทีมก่อนเสมอ
3. สร้างขั้นตอนการทำงานเดียวเท่านั้น โดยรวมเอาความต้องการต่าง ๆ ของแต่ละทีม (พร้อมที่จะเปลี่ยนแปลงเสมอเสมอ)
4. จากนั้นจึงเริ่มนำเอาเครื่องมือมาใช้งาน
5. ต้องมีคนที่คอยจัดการตั้งแต่ข้อ 1-4 เสมอ

ดังนั้นมาเริ่มสร้าง CI และ CD process ที่ช่วยแก้ปัญหากันดีกว่าสร้างปัญหานะครับ !! Reference Website https://dzone.com/articles/why-most-companies-are-getting-continuous-delivery http://sdtimes.com/software-testing-is-all-about-automation/ http://devjam.com/2015/05/08/from-ci-to-cd-misunderstandings-of-devops-and-continuous-delivery/

ทำการ Deploy Android app ขึ้น Google Play แบบอัตโนมัติด้วย Fastlane Supply

March 29, 2016, 8:14 am

≫ Next: แนะนำ WireMock และ Stubby4J สำหรับการจำลอง REST APIs

≪ Previous: ความเข้าใจผิดเกี่ยวกับ Continuous Integration และ Continuous Delivery

$

0

0

วันนี้นั่งสรุปการนำ Fastlane มาใช้กับการพัฒนา Android application โดยในตอนนี้จะมีชุดเครื่องมืออยู่ 2 ตัวคือ

• Supply สำหรับการแก้ไข Android app บน Google Play เช่น APK และ metadata ต่าง ๆ
• Screengrab สำหรับการบันทึกรูป screenshot การทำงานของ app ซึ่งทำงานร่วมกับ Espresso หรือ UI Testing

ดังนั้น เราลองนำเครื่องมือทั้งสองมาใช้งานร่วมกันดีกว่า ความต้องการเป็นดังนี้

• ทำการ build app ด้วย Gradle
• ทำการทดสอบ UI Test ด้วย Espresso
• ทำการบันทึกรูป screenshot การทำงานของ app สำหรับ upload ขึ้น Google Play
• ทำการ upload APK และ metadata ต่าง ๆ ขึ้น Google Play

ดังนั้นมาเริ่มต้นสร้างระบบกันเลยดีกว่า

1. เครื่องมือสำหรับการ Upload APK และ metadata ต่าง ๆ ขึ้น Google Play ชื่อว่า Supply

ข้อจำกัดอย่างหนึ่งของ Supply คือ ต้องทำการสร้าง App และ Upload APK ขึ้น Google Play ก่อนเสมอ จากนั้นก็เริ่มต้นใช้งาน Supply ได้เลย

โดยที่ supply นั้นจะทำงานผ่าน Google Play Developer Publishing API ดังนั้นต้องทำการขอสิทธิ์ในการเข้าใช้งานจาก Google Play Developer Console เสียก่อน แสดงดังรูป จากนั้นให้ทำการสร้าง Service Account key ให้เลือก Key type เป็น JSON และอย่าลืม download มาเก็บไว้ที่เครื่อง ซึ่งผมตั้งชื่อไฟล์นี้ว่า google_play.json เนื่องจากจะต้องใช้ใน suppply นั่นเอง

2. เริ่มใช้งาน supply ผ่าน fastlane กันเลย

ให้สร้าง fastlane project ด้วยคำสั่ง [code]$fastlane init[/code] ให้ทำการแก้ไขไฟล์ Appfile ใน folder fastlane เพื่อใส่ข้อมูล json_key_file สำหรับการใช้งานผ่าน Google Play Developer Publishing API ดังนี้ [gist id="db1e34b556fcc77b7442" file="Appfile"] จากนั้นให้ทำการดึงข้อมูล metadata ต่าง ๆ ของ Android app จาก Google Play ด้วยคำสั่ง [code]$supply init[/code] ทำการดึงข้อมูล metadata ต่าง ๆ ดังนี้มา

• Title
• Short description
• Full description
• Screenshot ต่าง ๆ

แสดงดังรูป

3. ทำการบันทึกรูป screenshot การทำงานของ app ด้วย Screengrab

ซึ่งผมเคยเขียนอธิบายการใช้งาน ไว้ที่ Blog :: ทำการ capture หน้าจอการทำงานด้วย Fastlane Screengrab กัน และนำรูปเหล่านี้มาไว้ใน folder phoneScreenshots เพื่อ upload ขึ้น Google Play ต่อไป

4. ทำการ upload การเปลี่ยนแปลงต่าง ๆ ไปยัง Google Play

ประกอบไปด้วย APK และ Metadata ต่าง ๆ ซึ่งมีขั้นตอนการทำงานดังนี้

1. ทำการสร้าง APK ที่ signed เรียบร้อย
2. ทำการ upload สิ่งต่าง ๆ ไปยัง Google Play ด้วย supply

โดยสามารถกำหนดการทำงานผ่าน Fastfile หรือ configuration ของ Fastlane นั่นเอง ในตัวอย่างทำการ upload APK ไปยัง Alpha testing ดังนี้ [gist id="db1e34b556fcc77b7442" file="Fastfile"] เมื่อทุกอย่างเรียบร้อยก็ทดสอบการทำงานด้วยคำสั่ง [code]$fastlane deploy[/code] แสดงผลการทำงานดังนี้

สุดท้ายทำการตรวจสอบผลการทำงานที่ Google Play Developer Console

จะพบว่า

• ทำการแก้ไข APK ในส่วนของ Alpha testing เรียบร้อย
• ทำการแก้ไข metadata เรียบร้อย
• ทำการแก้ไขรูปภาพเรียบร้อย

ข้อมูลของ Metadata แสดงดังรูป รูปภาพการทำงานของ App แสดงดังรูป

เพียงเท่านี้เราก็สามารถทำการ

ทำการทดสอบ android app ด้วย Espresso ทำการบันทึกรูป screenshot การทำงานของ app ทำการสร้าง file APK ทำการ upload APK และ metadata ต่าง ๆ ขึ้น Google Play ด้วยชุดคำสั่งเดียวเท่านั้น ..

มันน่าจะทำให้ชีวิตของนักพัฒนา Android app สะดวกสบายมากขึ้นหรือเปล่านะ ?

แนะนำ WireMock และ Stubby4J สำหรับการจำลอง REST APIs

March 30, 2016, 9:34 pm

≫ Next: สวัสดีกับ Elastic Graph

≪ Previous: ทำการ Deploy Android app ขึ้น Google Play แบบอัตโนมัติด้วย Fastlane Supply

$

0

0

จากการพูดคุยกับหลายทีม พบว่า ปัญหาอย่างหนึ่งที่มักพบเจอคือ การเชื่อมต่อกับระบบต่าง ๆ ผ่าน REST APIs หรือแม้แต่การพัฒนาระบบเดียวกันที่ต้องแบ่งเป็น 2 ทีม คือ

1. ทีม Frontend อาจจะเป็น Web หรือ Mobile ก็ได้
2. ทีม Backend หรือ ทีม API

เนื่องจากต้องทำการเชื่อมต่อ และ integrate กันตลอด ถ้า API ยังพัฒนาไม่เสร็จล่ะ ? ถ้าระบบ network มันล่มล่ะ ? ถ้าระบบ API มันล่มล่ะ ? คำถามคือ จะแก้ไขปัญหาเหล่านี้อย่างไรดี ?

ก่อนที่จะไปหาเครื่องมือมาช่วยเหลือ ต้องเริ่มจากการคิด และ คุยรายละเอียด

ว่าในแต่ละ API เป็นอย่างไร เช่น

• Endpoint ของ API
• Input ของ API เป็น GET/POST/PUT/DELETE
• Output ของ API
• รูปแบบข้อมูลเป็น XML หรือ JSON

ซึ่งเป็นข้อตกลงร่วมกันก่อนเริ่มทำงาน จากนั้นเราสามารถใช้เครื่องมือต่าง ๆ มาจำลองการทำงานของ API ได้เลย ระหว่างที่รอให้ API พัฒนาเสร็จ ที่สำคัญทีมพัฒนาสามารถควบคุมข้อมูลได้อีกด้วย ดังนั้น ทีมพัฒนาจะไม่มีข้ออ้างว่า API ไม่เสร็จอีกต่อไป ซึ่งมีเครื่องมือมากมาย โดยที่ผมมักจะใช้งานมี 2 ตัวคือ

1. WireMock
2. Stubby4j

แสดงการทำงานดังรูป มาดูตัวอย่างการใช้งาน WireMock กันนิดหน่อย

1. ทำการติดตั้ง

เพียงแค่ download และนำมาติดตั้งไปที่ Servlet Container หรือ run แบบ Standalone ก็ได้ โดยผมจะใช้การ run แบบ Standalone เพื่อความง่าย ให้ทำการ download ไฟล์ JAR จาก WireMock Standalone จากนั้นทำการ run ด้วยคำสั่ง [code]$java -jar wiremock-1.57-standalone.jar --verbose[/code] แสดงผลการทำงานดังรูป โดยค่า default นั้นจะทำงานที่ port 8080 แต่เราสามารถเปลี่ยน port ได้ด้วยคำสั่ง [code]$java -jar wiremock-1.57-standalone.jar --port 9090 --verbose[/code] สามารถดูการใช้งานเพิ่มเติมได้ที่ Running standalone เมื่อ run WireMock เรียบร้อยแล้วจะสร้าง folder ขึ้นมา 2 folder คือ

1. __files
2. mappings

2. การใช้งานส่วนของ Admin

เข้าไปที่ url http://localhost:8080/__admin/ เพื่อดูว่า mapping ต่าง ๆ ของ API ใน WireMock มีอะไรบ้าง แน่นอนว่า ตอนเริ่มต้นต้องไม่มีอะไรเลย แสดงดังรูป

3. มาสร้าง Mock API กันดีกว่า

ความต้องการของผมคือ สร้าง API สำหรับการคงข้อมูลสินค้า ดังนี้

• Endpoint = /products
• ใช้งานผ่าน HTTP GET
• Response ที่ส่งกลับมาอยู่ในรูปแบบของ JSON ซึ่งประกอบไปด้วย id, name, price ของสินค้า

ดังนั้นให้ทำการสร้างไฟล์ชื่อว่า product.json ใน folder mappings ดังนี้ [gist id="e71de6c7f1dada28a15701b76360ff1f" file="product.json"] จากนั้นทำการ restart WireMock แล้วเข้าไปในส่วนของ Admin จะแสดงดังนี้

4. ใช้งานจริง ๆ กันดีกว่า

สามารถเข้าใช้งานผ่าน URL http://localhost:8080/products แสดงผลการทำงานดังนี้ หรือสามารถทดสอบผ่าน Postman หรือ REST Client หรือ Curl ก็ได้นะ เลือกได้ตามความสะดวกของแต่ละคน เพียงเท่านี้ก็สามารถจำลอง API Server ด้วย WireMock กันได้แล้วนะ

ส่วน Stubby4J ก็ทำการติดตั้งและใช้งานคล้าย ๆ กัน

ต่างกันเพียงรูปแบบของไฟล์ configuration และ รูปแบบข้อมูล ซึ่งอยู่ในรูปแบบของ YAML จากการใช้งาน Stubby4J จะ configuration API ง่ายกว่า WireMock พอสมควร แต่ขอแนะนำให้ลองด้วยตนเองนะครับ

มีคนถามว่า ถ้า API พัฒนาเสร็จแล้ว มีการเปลี่ยนแปลงจากที่ตกลงกันไว้ล่ะ ?

คำตอบคือ ต้องเปลี่ยนไงล่ะ อย่าลืมเปลี่ยนใน WirMock ด้วยนะ และถ้าคุณมีชุดการทดสอบ ก็จะรู้ได้ทันทีว่า การเปลี่ยนแปลงเหล่านั้น กระทบต่อระบบของคุณหรือไม่ ?

ซึ่งเป็นประเด็นที่สำคัญมาก ๆ คุณรู้หรือไม่ว่า การเปลี่ยนแปลงต่าง ๆ มันส่งผลกระทบอะไรบ้าง ?

และยังมีเครื่องมืออื่น ๆ ให้ลองใช้งานอีกมากมาย

ไม่ว่าจะเป็น

• Betamax
• REST-driver
• MockServer
• Moco
• Mountebank

สวัสดีกับ Elastic Graph

March 31, 2016, 3:28 am

≫ Next: สรุปสิ่งที่แบ่งปันในงาน iOS Dev Meetup ครั้งที่ 4

≪ Previous: แนะนำ WireMock และ Stubby4J สำหรับการจำลอง REST APIs

$

0

0

ไม่มีอะไรมาก แค่อยากจะแนะนำ Graph เป็น product ตัวใหม่ของ Elastic เพิ่งเปิดตัวไปในงาน Elastic Con 2016 ทำให้เราสามารถค้นหาข้อมูลที่ความเกี่ยวข้องกันได้ง่าย และ สะดวกขึ้น แน่นอนว่า ข้อมูลต้องจัดเก็บอยู่ใน Elasticsearch นั่นเอง สามารถนำมาประยุกตืใช้งานได้มากมาย ไม่ว่าจะเป็น

• ระบบ Recommending Content
• ระบบ Detecting Sources of Risk
• ระบบค้นหาข้อมูลจากความเกี่ยวข้อง และ สัมพันธ์ต่างๆ

โดยรวมแล้วมันคือเรื่องของ Information Retrieval นั่นเอง

ส่วนการใช้งานก็ผ่าน API ง่าย ๆ

และแน่นอนว่า ใช้งานผ่าน Query DSL ของ Elasticsearch ได้ แถมยังมี Graph UI บน Kibana อีกด้วยนะ

ว่าแล้วทำการติดตั้งและลองใช้งานกันดีกว่า

ก่อนอื่นต้อง download ทั้ง Elasticsearch 2.3 และ Kibana 4.5 !! จากนั้นทำการติดตั้ง Graph ตามขั้นตอนดังนี้ ปล. เห็นไหมว่าต้องติดตั้ง license ด้วย นั่นแสดงว่า Graph มันไม่ฟรีอย่างแน่นอน !! แต่ไม่เป็นไรลองใช้งานแบบขำ ๆ ไปก่อน

เมื่อติดตั้งเสร็จแล้ว ลองมาดู Graph UI ใน kibana นิดหน่อย

แสดงดังรูป เพียงเท่านี้ก็สามารถเริ่มต้นใช้งานได้แล้ว ส่วนตัวอย่างการใช้งานจะตามมาใน blog ต่อ  ๆ ไป แต่ตอตนี้แนะนำให้อ่านเพิ่มเติมได้ที่

• Documentation แต่ยังน้อยมาก ๆ
• VDO :: Elastic Graph
• VDO :: Sneak Peek of Graph Capabilities with the Elastic Stack

---

สรุปสิ่งที่แบ่งปันในงาน iOS Dev Meetup ครั้งที่ 4

April 2, 2016, 4:24 am

≫ Next: สรุปเรื่องของ Redux สำหรับ Mobile Application

≪ Previous: สวัสดีกับ Elastic Graph

$

0

0

วันนี้มีโอกาสมาแบ่งปันเรื่อง Continuous Delivery with Fastlane ในงาน iOS Dev Meetup ครั้งที่ 4 จากกลุ่ม iOS Developer Thailand จึงทำการสรุปสิ่งที่แบ่งปันไว้นิดหน่อย หัวข้อต่าง ๆ ในงาน meetup ประกอบไปด้วย

• Continuous Delivery with Fastlane
• Redux
• React Native

สรุปสิ่งที่แบ่งปันเรื่อง Fastlane ก่อน

เริ่มด้วยแนวคิดของ Continuous Delivery(CD) ว่าเป็นอย่างไร ซึ่งเน้นไปที่เรื่องของ คุณภาพ (Quality) ที่ต้องอยู่ในทุก ๆ กระบวนการของการพัฒนา software ไม่ว่าจะเป็น web หรือ mobile ก็ตาม โดยแนวคิดเบื้องต้นของ CD คือ Continuous Integration(CI) นั่นคือ ต้องทำการ build -> test -> run อยู่บ่อย ๆ เพื่อทำให้เรารู้ feedback หรือ ผลการทำงานหลังการเปลี่ยนแปลงสิ่งต่าง ๆ ได้อย่างรวดเร็ว แน่นอนว่า การทำงานแบบ manual หรือ ให้คนทำส่วนนี้ จะได้รับ feedback ที่ช้ามาก ๆ และไม่สามารถไม่สามารถทำงานได้บ่อยเท่าที่ต้องการ ดังนั้น จึงต้องสร้างระบบการทำงานแบบอัตโนมัติขึ้นมา (Automation)

เมื่อเราสร้างการ build -> test -> run แบบอัตโนมัติ และทำให้เรามีความมั่นใจต่อระบบมากขึ้น นั่นคือระบบงานของเรามีคุณภาพนั่นเอง ทำให้เราสามารถสร้างระบบ Continuous Delivery ขึ้นมาต่อยอดได้ง่าย

ดังนั้นกลับมาที่ iOS app development บ้าง !!

คำถามคือ เราทำการ build -> test -> run กันอย่างไร ? เราทำการ deploy app กันอย่างไร ? คำตอบ คือ แบบ manual ไงล่ะ !! ดังนั้นจึงขอแนะนำเครื่องมือที่ช่วยทำงานสิ่งต่าง ๆ เหล่านี้ เพื่อทำให้การทำงานซ้ำ ๆ มันง่ายขึ้น เพื่อทำให้การทำงานซ้ำ ๆ มันสะดวกขึ้น เพื่อทำให้การทำงานซ้ำ ๆ มาเป็นแบบอัตโนมัติ ทำให้เราสามารถสร้างระบบ CI และ CD ได้ง่ายขึ้น นั่นคือ Fastlane ซึ่งผมแนะนำไว้ที่ blog ทำความรู้จักกับ Fastlane กันหน่อย

โดยเครื่องมือใน Fastlane ที่แนะนำ และ demo เป็นดังนี้

• produce ทำการสร้าง App บน iTune Connect และ Apple Developer Portal
• cert ทำการจัดการ certificate
• sign ทำการจัดการ provisioning profile
• gym ทำการสร้างไฟล์ IPA
• pilot ทำการ upload App ขึ้น TestFight
• deliver ทำการ upload ขึ้น AppStore
• scan ทำการ run Unit test
• snapshot ทำการ run UI test และ Snapshot หน้าจอการทำงาน ซึ่งจะเป็น metadata หนึ่งของ app ได้เลย

ซึ่งเราสามารถกำหนดขั้นตอนการทำงานในสิ่งที่เรียกว่า Lane อยู่ในไฟล์ Fastfile ของ Fastlane ดังนี้ 1. ทำการ Provisioning ก่อน ประกอบไปด้วย

• สร้าง App
• สร้าง Certificate
• สร้าง Provisioning profile

ถ้าทำแบบ manual มันเหนื่อยพอสมควร แต่ Fastlane มันทำให้เราง่ายขึ้นด้วย Produce, Cert และ Sigh ดังนี้ [gist id="20ee6e9e7e7bfdeb49a16b84d3ab1578" file="Fastfile01"] สามารถใช้งานด้วยคำสั่ง [code]$fastlane provision[/code] ปล. ให้ run เพียงครั้งเดียวเท่านั้นนะครับ 2. ทำการสร้างไฟล์ IPA และ Upload ขึ้น TestFight สำหรับการทำ Beta testing [gist id="20ee6e9e7e7bfdeb49a16b84d3ab1578" file="Fastfile03"] สามารถใช้งานด้วยคำสั่ง [code]$fastlane beta[/code] 3. ทำการสร้างไฟล์ IPA และ Upload ขึ้น AppStore โดยก่อนจะ Upload ขึ้น AppStore สามารถดู preview ของ metadata ได้อีกด้วย [gist id="20ee6e9e7e7bfdeb49a16b84d3ab1578" file="Fastfile04"] สามารถใช้งานด้วยคำสั่ง [code]$fastlane appstore[/code] 4. ทำการ run unit test, ui test, สร้างไฟล์ IPA และ Upload ขึ้น AppStore [gist id="20ee6e9e7e7bfdeb49a16b84d3ab1578" file="Fastfile02"] สามารถใช้งานด้วยคำสั่ง [code]$fastlane all[/code]

สังเกตุได้ว่า เราสามารถกำหนด Lane การทำงานของเราได้

นั่นทำให้เราสามารถปรับเปลี่ยนขั้นตอนการทำงานตามที่เราต้องการได้ อีกอย่างหนึ่ง คือ มันเป็นภาษา Ruby ดังนั้น เราจึงสามารถเขียน script ด้วยภาษา Ruby เพื่อเพิ่มความสามารถต่าง ๆ ได้ เช่น

• จัดการเรื่อง version ของ app
• จัดการเรื่อง metadata ต่าง ๆ ของ app สามารถดึงมาจากไฟล์ หรือ REST APIs ได้

รวมทั้งสามารถ integrate การทำงานกับ Slack หรือระบบอื่น ๆ ได้ง่าย ปล. เนื่องจาก Fastlane นั้นมันใหม่มาก ๆ ดังนั้น จึงทำให้เกิด error ต่าง ๆ พอสมควร ทั้งเรื่องของ permission ทั้งเรื่องของ version ของ Xcode command line tool แต่ก็สามารถเปิด issue ต่าง ๆ ได้จาก Fastlane issue และได้รับ feedback กลับมาเร็วมาก ๆ โดยที่ Slide แบ่งปันอยู่ที่นี่ [slideshare id=60379523&doc=continuous-delivery-for-ios-app-160402085655&w=640&h=480]

ใน blog ต่อ ๆ ไปจะเขียนอธิบายการใช้งานในแต่ละ usecase มาเรื่อย ๆ

สรุปเรื่องของ Redux สำหรับ Mobile Application

April 2, 2016, 11:27 pm

≫ Next: มาดูกันว่า Swift และ Kotlin มันเหมือนหรือต่างกันอย่างไร ?

≪ Previous: สรุปสิ่งที่แบ่งปันในงาน iOS Dev Meetup ครั้งที่ 4

$

0

0

จากงาน iOS Dev Meetup ครั้งที่ 4 มีหนึ่ง session พูดเรื่อง Redux - Brings Web Architecture to Mobile เป็นสิ่งที่น่าสนใจมาก ๆ ที่สำคัญเข้าใจได้ไม่ยาก ดังนั้นจึงนำมาสรุปนิดหน่อย ประกอบไปด้วย

• ที่มาของแนวคิด Redux
• Principle 3 ข้อ
• โครงสร้างการทำงาน
• Code ตัวอย่าง ซึ่งพัฒนาด้วยภาษา Swift

เริ่มต้นกันเลย

ที่มาของแนวคิด Redux

เป็นการนำเอาแนวคิดดีมากจาก framework/library/architecture ต่าง ๆ ไม่ว่าจะเป็น

• Flux
• Elm
• Immutable
• Baobab
• RxJS

โดยที่ Redux จะเน้นในเรื่องของการจัดการ State หรือ สถานะต่าง ๆ ของ App เนื่องจากในระบบงานนั้น จะมี State จำนวนมาก ยิ่งระบบงานมีขนาดใหญ่ขึ้น ยิ่งมากขึ้นไปอีก รวมทั้ง State ส่วนใหญ่มักจะถูกเปลี่ยนแปลงได้ตลอดเวลา (Immutable) แถมยังมีความซับซ้อนแบบเท่าทวีคูณไปอีก ทำให้จัดการได้ยากมาก ๆ แสดงดังรูป ดังนั้นจึงเกิดคำถามว่า แล้วเราจะจัดการ State ต่าง ๆ เหล่านี้ของระบบอย่างไรดี ? หนึ่งในคำตอบนั้นคือ Redux นั่นเอง

Principle 3 ข้อของ Redux ที่ต้องเข้าใจ

ประกอบไปด้วย

1. Single source of truth
2. State is read-only
3. Changes are made with pure functions

1. Single source of truth หมายความว่า State ต่าง ๆ ของระบบงาน จะถูกจัดเก็บไว้เพียงที่เดียวเท่านั้น โดยที่จัดเก็บจะเรียกว่า Store อยู่ในรูปแบบของ object tree 2. State is read-only สถานะต่าง ๆ ไม่สามารถเปลี่ยนแปลงได้ ดังนั้นเมื่อเกิดเหตุการณ์ หรือ Action ขึ้นมา จะทำการสร้าง State ใหม่ขึ้นมาต่อจาก State เดิม โดยไม่ทำการแก้ไข State เดิม ทำให้เราสามารถจัดเก็บ State และ Replay ได้อีกด้วย นั่นคือ เราสามารถ recovery state ต่าง ๆ ได้ รวมทั้งง่ายต่อการทดสอบอีกด้วย 3. Changes are made with pure functions เมื่อมีเหตุการณ์ขึ้นมาแล้ว State ต่อไปคืออะไร ? นั่นเป็นหน้าที่ของ Reducer ซึ่ง Reducer นั้นจะเป็น pure function โดยพิจารณาจาก State ปัจจุบัน + Action ทำให้จะได้ State ต่อไปขึ้นมา ซึ่ง Reducer จะส่ง State ใหม่ออกมาเท่านั้น โดยไม่เปลี่ยนแปลง State ก่อนหน้าโดยเด็ดขาด คำถามคือ Pure function คืออะไร ? ดังนั้นต้องมี Inpure function แน่นอน ประเด็นหลักมันคืออะไรกันล่ะ เกิดมาเพิ่งเคยได้ยิน !! คำตอบง่าย ๆ คือ เป็น function/method ที่ไม่ก่อให้เกิดผลกระทบ (Side Effect) ใดต่อระบบ นั่นคือไม่ทำการเปลี่ยนแปลงข้อมูลใด ๆ ที่ส่งเข้าไปยัง function/method และจะส่งค่าใหม่ออกมาเท่านั้น แนะนำให้ดูจาก VDO เรื่อง JavaScript Redux pure and impure function แสดงดังตัวอย่าง [gist id="296447def187f60be31872d1c37fc1a7" file="pure-function.js"]

โครงสร้างการทำงานของ Redux (Flow)

ส่วนการทำงานต่าง ๆ ของ Redux จะประกอบไปด้วย

• State คือ สถานะต่าง ๆ ของการทำงาน
• Action คือ เหตุการณ์ต่าง ๆ ที่เกิดขึ้น
• Store คือ ที่จัดเก็บ State ต่าง ๆ หรือสามารถเรียกว่าเป็น State Container และ notify ไปยังส่วนต่าง ๆ ที่ subscribe ไว้
• Reducer คือ pure function ที่ทำการสร้าง State ถัดไปโดยพิจารณาจาก State ปัจจุบัน และ Action ที่เกิดขึ้น

ขั้นตอนการทำงานของ Redux จะเป็นแบบ Unidirectional data flow หรือการทำงานแบบทางเดียว ไม่มีย้อนกลับ แสดงดังรูป คำอธิบาย

1. เมื่อเกิด Action ต่าง ๆ ขึ้นมา ไม่ว่าจะเกิดจาก view/data source หรืออะไรก็ตามที่ต้องการเปลี่ยนแปลง State จะถูกส่งมาที่ Store
2. จากนั้น Store จะทำการเรียกใช้งาน Reducer โดยส่ง State ปัจจุบัน และ Action ไปให้
3. ทำการเรียก Reducer เพื่อทำงานตาม Action
4. จากนั้น Reducer ทำการส่ง State ใหม่กลับมา
5. ส่ง State ใหม่กลับไปให้ Store
6. จากนั้น Store จะทำการ notify หรือแจ้งไปยังส่วนการทำงานต่าง ๆ ที่ subscribed ไว้ เพื่อทำการ update ต่อไป เช่น การแสดงผล เป็นต้น
7. ส่วนการแสดงผล หรือ data source อาจจะสร้าง Action ใหม่ ๆ ขึ้นมาได้อีก เช่น จากผู้ใช้งาน และ ข้อมูลจากภายในระบบ เป็นต้น

และทำแบบนี้วนไปเรื่อย ๆ ในทุก ๆ Action

สังเกตุไหมว่า การจัดการ State นั้นมันอยู่ระหว่าง View กับ Model นั่นเอง

มาลองเขียน Code ด้วยภาษา Swift กันบ้าง

Source code มาจาก meet up นั่นเอง ReduxPlayground เป็นตัวอย่างการสร้าง TODO App จึงนำมาสรุปใหม่นิดหน่อย 1. เริ่มด้วยการกำหนด Action ก่อน ว่าใน app ของเรานั้นจะมี Action หน้าตาอย่างไร และมี Action อะไรบ้าง ตัวอย่าง code จะมี Add TODO Action ก่อน [gist id="296447def187f60be31872d1c37fc1a7" file="Action.swift"] 2. ทำการสร้าง State ขึ้นมา โดยเราสามารถกำหนดโครงสร้างของ State ในรูปแบบใด ๆ ก็ได้ จากตัวอย่าง State จะประกอบไปด้วย

• List ของ TODO
• การเปลี่ยนแปลง

[gist id="296447def187f60be31872d1c37fc1a7" file="State.swift"] 3. สร้าง Reducer function ขึ้นมา โดยมี input คือ State และ Action และทำการส่งค่า State ใหม่กลับไป [gist id="296447def187f60be31872d1c37fc1a7" file="Reducer.swift"] 4. สร้าง Store ซึ่งเป็น Container ของการทำงานเลย มีส่วนการทำงานต่าง ๆ ดังนี้

• ทำการเก็บ State ทั้งหมดของระบบ
• อนุญาตให้ getState() ได้
• สามารถส่ง Action เข้ามาได้
• สามารถ subscribe ได้

โดยมีโครงสร้างดังนี้ [gist id="296447def187f60be31872d1c37fc1a7" file="Store.swift"] จากนั้นทำการสร้าง Store ขึ้นมา [gist id="296447def187f60be31872d1c37fc1a7" file="CreateStore.swift"] 5. เมื่อทุกอย่างพร้อม ก็นำมารวมกันเพื่อใช้งาน [gist id="296447def187f60be31872d1c37fc1a7" file="Try.swift"] จากนั้นจึงนำไป integrate เข้ากับ ViewController ในการพัฒนา App ต่อไป

มาถึงตรงนี้คิดว่า น่าจะทำให้เราเข้าใจกับแนวคิดของ Redux มากขึ้นบ้าง

ซึ่งการเริ่มต้นด้วยการเขียน code เองตั้งแต่ศูนย์ มันทำให้เราเข้าใจแนวคิดมากขึ้น ลองดูกันครับ

ปล. ได้ยินมาอีกว่า Kotlin มันก็คล้าย ๆ กับ Swift นะ ดังนั้นสามารถเอาควาวมรู้เหล่านี้ไปเขียนด้วย Kotlin สำหรับการพัฒนา Android app ได้เลย มันน่าสนใจมาก ๆ

มาดูกันว่า Swift และ Kotlin มันเหมือนหรือต่างกันอย่างไร ?

April 3, 2016, 8:34 am

≫ Next: ลองดู code ที่เขียนหน่อยสิว่า มัน DRY หรือ WET กัน ?

≪ Previous: สรุปเรื่องของ Redux สำหรับ Mobile Application

$

0

0

จากงาน iOS Dev Meetup #4 มีการพูดถึงภาษา Kotlin กันพอสมควร ว่าตัวภาษามันเกือบจะเหมือนกับภาษา Swift เลย ต่างกันเพียง

• Swift ใช้สำหรับพัฒนา iOS app
• Kotlin ใช้สำหรับพัฒนา Android app

ดังนั้นถ้าพัฒนา Mobile app ด้วยสองภาษานี้ ก็น่าจะทำให้การพัฒนา app มันง่ายขึ้น หรือสามารถใช้แนวคิดในการพัฒนาเหมือนหรือคล้ายกันไปได้เลย ส่งผลให้การดูแลรักษาระบบงานมันง่ายขึ้น !! ดังนั้นมาดูว่าทั้งสองภาษานี้เหมือนหรือต่างกันอย่างไรบ้าง เพื่อทำให้การศึกษาภาษาใหม่ ๆ ง่ายขึ้น มาเริ่มนับ 1 กับ ภาษา Kotlin กัน อย่างแรกเลยคือ Semicolon คือ optional จะบอกไปทำไมล่ะเนี่ย !!

Swift คือภาษา self Kotlin คือภาษา this

การประกาศตัวแปร ใช้ var เหมือนกันทั้ง infer type และ explicit type [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="variable.txt"] การประกาศแปรแบบ Immutable ใน swift จะใช้ let ส่วน Kotlin ใช้ val ดังนี้ [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="immutable.txt"] เรื่องของ Optional และ Nullable เหมือนกันเลย [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="optional.txt"] แถม Type checking และ Casting ก็เหมือนกันอีก [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="cast.txt"] ดูเรื่องของ String template หน่อยสิ มันก็ต่างกันนิดหน่อย ดังนี้ [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="string.txt"] การสร้าง function ต่างกันที่ keyword สำหรับประกาศ function Swift ใช้ func Kotlin ใช้ fun (ภาษาสนุก !!) และสัญลักษณ์ของการ return นั่นเอง [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="function.txt"] ส่วนการเรียกใช้งาน function นั้น สิ่งที่แตกต่างกันคือ Swift นั้นต้องใช้ name parameter Kotlin ไม่ต้อง [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="call_function.txt"] การสร้าง class ต่างกันในส่วนของ constructor คือ Swift ใช้ init() Kotlin ใช้ constructor() [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="class.txt"] การสร้าง instance ใหม่ขึ้นมาก็เหมือนกัน การ overriding ระดับ function ก็เหมือนกันอีก !! ยังไม่พอนะ Swift มี protocol Kotlin มี trait มีอะไรอีกล่ะ !! Enum ก็แล้วกัน ต่างกันนิดหน่อย คือ Kotlin จะมี keyword class ด้วยดังนี้ [gist id="1159a6806ec9deb92ce705ac7c30e64b" file="enum.txt"] และอื่นๆ อีกมากมาย

สุดท้ายแล้ว ทั้งสองภาษามันคล้ายกันมาก ๆ เราศึกษาทั้งสองภาษาไปพร้อม ๆ กันได้เลย ดังนั้นเริ่มศึกษาทั้งภาษา Swift และ Kotlin กันเถอะนะ

Reference Websites https://nilhcem.github.io/swift-is-like-kotlin/

ลองดู code ที่เขียนหน่อยสิว่า มัน DRY หรือ WET กัน ?

April 4, 2016, 3:58 am

≫ Next: Android :: ลด ละ เลิกการใช้ findViewById() !!!

≪ Previous: มาดูกันว่า Swift และ Kotlin มันเหมือนหรือต่างกันอย่างไร ?

$

0

0

DRY ย่อมาจาก Don’t Repeat Yourself เป็นแนวคิดสำหรับการลดจำนวน code ที่ซ้ำซ้อน WET ย่อมาจาก Write Everything Twice เป็นแนวคิดที่ตรงข้ามกับ DRY โดยสิ้นเชิง คำถามคือ ในปัจจุบัน developer เขียน code กันแบบไหน ระหว่าง DRY กับ WET ? ถ้าตอบว่า WET !!! แนะนำให้พยายาม ลด ละ เลิก เพื่อทำให้ code มัน DRY หรือลดจำนวน code ที่มันซ้ำซ้อนในหลายๆ จุดนั่นเอง

ข้อดีของ DRY ประกอบไปด้วย

เรื่องแรกคือ การดูแลรักษา code ง่ายขึ้น ลองคิดดูสิว่า ในระบบที่มีความซับซ้อนมาก ๆ แถมมี code ที่ทำงานเรื่องเดียวกันหลาย ๆ ที่ มันก็ยากต่อการแก้ไขอย่างแน่นอน เท่าที่พบเจอคือ developer ชอบ copy-and-paste จากที่หนึ่งไปใช้งานอีกที่หนึ่ง ซึ่งถามว่า มันทำงานได้ไหม ตอบได้เลยว่า ได้ แต่มันคือการสร้าง code ที่ซ้ำซ้อนขึ้นมา แถม developer เป็นคนที่ขี้ลืมอีกด้วยว่า ทำอะไรไปแล้วบ้าง ทำอะไรตรงไหนไปบ้าง เรื่องที่สอง คือ ทำให้ code มันอ่านง่ายขึ้น ปัญหาที่พบคือ developer อ่าน code ไม่รู้เรื่อง และ เข้าใจยาก ทำให้ไม่สนใจ code ที่มีอยู่มากนัก ดังนั้น อาจจะทำให้เขียน code ชุดเดิม ๆ ในรูปแบบใหม่ไปเรื่อย ๆ ทำให้เกิด code ตามกลุ่มของ developer ที่เข้ามารับช่วง สุดท้าย code ก็ซ้ำซ้อนในเชิงแนวคิด แต่ต่างในการ implement ดังนั้น ถ้าต้องการปฏิบัติตามแนวคิด DRY แล้ว developer ต้องใช้ความพยายามอย่างมาก ในการเขียน code ให้อ่านง่ายนั่นเอง เรื่องที่สามคือ การ reuse code การ reuse เป็นผลมาจาก การที่เราพบเจอ code ที่ซ้ำซ้อนตั้งแต่ 2 ที่ขึ้นไป ทำให้เราทำการรวมการทำงานนั้นไว้ที่เดียว ดังนั้น การ reuse จะเกิดมาเมื่อ code มันซ้ำซ้อนนั่นเอง ส่งผลทำให้การพัฒนาระบบงานเร็วขึ้น เรื่องที่สี่ คือ ค่าใช้จ่ายในการพัฒนา และ แก้ไขลดลง ยิ่ง code มีจำนวนมากเท่าไร จำนวนคนดูแลก็ต้องมากเท่านั้น นั่นคือเป็นการเพิ่มค่าใช้จ่ายนั่นเอง ทั้งค่าใช้จ่ายจากการพัฒนา ทั้งค่าใช้จ่ายจากการทดสอบ ทั้งค่าใช้จ่ายจากการแก้ไข bug สุดท้ายมันจะส่งผลออกไปยังลูกค้าหรือผู้ใช้งานต่อไป !! เรื่องที่ห้าคือ การทดสอบ ลองคิดดูสิ ถ้า code มันซ้ำซ้อนมาก ๆ การทดสอบก็ต้องมากเช่นกัน แต่ถ้าแก้ไข code ซ้ำ ๆ ออกไป การทดสอบก็ลดลงไปมาก

การทำตามแนวคิด DRY ก็ต้องใช้แบบมีสติด้วยเช่นกัน

เนื่องจาก code บางส่วนอาจจะเหมือนกันมาก ๆ แต่กลับใช้กันคนละเรื่อง ไม่เกี่ยวกัยเลย หรือรวมกันแล้ว กลับทำให้การดูแลมากกว่าเดิม ดังนั้น ก็ไม่ควรรวมกันนะ !! หรือบางครั้งทำเยอะเกินไป หรือ Over DRY !! ก็อาจจะทำให้ code อ่านยาก เข้าใจยากขึ้นไปอีก ซึ่งเป็นสิ่งที่บอกว่า คุณกำลังหลงทาง และแนวคิด DRY นั้น ไม่ได้ใช้เฉพาะ code เท่านั้นนะ แต่สามารถนำไปใช้กับสิ่งอื่น ๆ ได้อีก เช่น Document, Database design และ testing เป็นต้น

สุดท้ายแล้ว

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

ถ้าคุณต้องการพร้อมรับต่อการเปลี่ยนแปลงอยู่อย่างเสมอ จำเป็นต้องปรับปรุง code ให้พร้อมด้วย

Reference Websites https://dzone.com/articles/is-your-code-dry-or-wet http://c2.com/cgi/wiki?DeveloperBillOfRights

Android :: ลด ละ เลิกการใช้ findViewById() !!!

April 4, 2016, 8:46 am

≫ Next: ทดลองสร้าง REST API ด้วย Kotlin กันหน่อย

≪ Previous: ลองดู code ที่เขียนหน่อยสิว่า มัน DRY หรือ WET กัน ?

$

0

0

พอดีกำลังศึกษาการพัฒนา Android app ด้วยภาษา Kotlin แต่ดันไปเจอคำแนะนำหนึ่งที่น่าสนใจคือ

ให้ลด ละ เลิก การใช้คำสั่ง findViewById ซะ ไม่งั้นชีวิตจะลำบากนะ

คำถามที่เกิดขึ้นมาคือ

• ทำไมล่ะ ?
• ถ้าไม่ใช้ แล้วจะใช้อะไรล่ะ ?

ดังนั้นเรามาหาคำตอบกันดีกว่า

Method findViewById(int) นั้นใช้สำหรับการหา view ต่าง ๆด้วย id

จาก Activity, View, Fragment และ Adapter การใช้งานปกติก็ไม่น่ามีปัญหาอะไรมากนัก แต่เมื่อระบบงานใหญ่ และ ซับซ้อนมากขึ้น จึงเกิด code รูปแบบนี้ขึ้นมา !!! [gist id="a04cce1323b2659a15a22ff81b6c0f5f" file="BigActivity.java"] ซึ่งจะเห็นว่า code มันซ้ำซ้อนมาก ๆ บางคนถึงกับบอกว่า ทำไมเราต้องเขียนแบบนี้กันด้วยล่ะ

คำถามที่เกิดขึ้นมาคือ มีวิธีการอื่น ๆ อีกไหม ?

คำตอบ มีนะ เพียบเลย ทั้ง Data binding library ที่มีมากับ Android เลย ทั้ง 3-party library สำหรับทำ view binding เช่น

• Butter Knife
• InjectView
• Android Annotation

โดยวิธีการเหล่านี้ มันดีขึ้นกว่าเดิมนะ แต่ต้องทำการเพิ่ม code และ configuration ต่าง ๆ ขึ้นมาอีกเช่นกัน ตัวอย่างเช่น [gist id="a04cce1323b2659a15a22ff81b6c0f5f" file="ButterKnife.java"]

คำถาม มันน่าจะมีวิธีการที่ดีกว่านี้อีกไหมนะ ?

ตอนนี้มาศึกษา Kotlin for Android ทำให้พบว่า มันมีแนวทางที่ง่ายกว่าอีกนะ ไม่ต้องทำอะไรเพิ่มเติมมากนัก เพียงแค่นำ Kotlin StdLib มาใช้ใน Android project และเปลี่ยน Java File เป็น Kotlin ก็ใช้งานได้แล้ว แสดงด้วย code ดังนี้ [gist id="a04cce1323b2659a15a22ff81b6c0f5f" file="MainActivity.kt"] ชีวิตมันดีขึ้นมากมายเลยนะ ของแบบนี้มันต้องนำมาพัฒนา Android app กันได้แล้ว ตัวอย่าง source code อยู่ที่ Github::Up1::Hello Kotlin Reference Websites https://kotlinlang.org/docs/tutorials/kotlin-android.html http://cirorizzo.net/2016/03/04/building-a-kotlin-project/ https://ragunathjawahar.wordpress.com/2015/03/23/kotlin-findviewbyid-dead-as-dinosaurs/

ทดลองสร้าง REST API ด้วย Kotlin กันหน่อย

April 4, 2016, 11:53 pm

≫ Next: ความสามารถของ Developer ที่ดี ควรมีติดตัวไว้บ้าง 

≪ Previous: Android :: ลด ละ เลิกการใช้ findViewById() !!!

$

0

0

เนื่องจากต้องการพัฒนา Application ด้วยภาษา Kotlin ทั้งในฝั่ง Android และ Server (REST API) ดังนั้นจึงอยากรู้ว่า ในฝั่ง Server จะพัฒนาได้อย่างไร และง่ายเพียงใด มาเริ่มกันเลยดีกว่า

ปล. Kotlin มันทำงานบน JVM ดังนั้นอะไรที่ทำงานบน JVM ก็ทำงานด้วยกันได้

ปกติในการสร้าง REST API ที่ใช้เป็นประจำ ประกอบไปด้วย

• Servlet 3
• Spark Java
• Spring Boot
• Drop Wizard

ดังนั้นมาดูว่าพัฒนา REST API ด้วย Kotlin ได้อย่างไร ? โดย software ที่ใช้งานประกอบไปด้วย

• IntelliJ IDE
• Gradle

ตามธรรมเนียมต้องเริ่มด้วยการสร้าง HELLO WORLD API กัน ซึ่งทำงานเหมือนกันหมด

1. Kotlin with Servlet 3.0 เขียน Servlet กันแบบธรรมดานี่เอง ง่ายมาก ๆ [gist id="64508ca4003af86f9b5afad7bc4a8049" file="HelloController.kt"] 2. Kotlin with Spark Java เป็น framework ที่ได้รับแรงบันดาลใจมาจาก Sinatra ทำให้เราสามารถสร้าง Routing ได้ง่ายมาก ๆ [gist id="64508ca4003af86f9b5afad7bc4a8049" file="HelloSpark.kt"] 3. Kotlin with Spring Boot ก็จะเยอะตามระเบียบ นั่นคือต้องมีไฟล์ Application เป็นหลัก ส่วน Rest Controller ก็เป็น class ธรรมดาเหมือนเดิม แต่เขียนสั้นกว่าเดิม [gist id="64508ca4003af86f9b5afad7bc4a8049" file="HelloSpringBoot.kt"] 4. Kotlin with DropWizard ต้องทำการ config และสร้างไฟล์เยอะหน่อย แต่ส่วนตัวชอบโครงสร้าง และ แนวคิดของ DropWizard [gist id="64508ca4003af86f9b5afad7bc4a8049" file="HelloDropWizard.kt"] เมื่อลองไปค้นหาเพิ่มเติมก็เจอ wasabi และ kara อีก ซึ่งพัฒนาด้วยภาษา Kotlin เลย ดังนั้นจึงลองนำมาเล่นสักตัว คือ wasabi เนื่องจาก kara สร้างมาสำหรับพัฒนา web application มากกว่า API นั่นเอง [gist id="64508ca4003af86f9b5afad7bc4a8049" file="HelloWasabi.kt"] โดยสรุปจากทั้ง 5 library พบว่า ถ้าเขียนด้วย Kotlin มันก็ไม่ได้ยากอะไรมากนัก เพียงแค่เปลี่ยนรูปแบบการเขียนให้สั้น และ สวยขึ้น ส่วนจะเลือกอะไรนั้น ผมคิดว่าอยู่ที่ตัวคนใช้แล้วล่ะ ว่ารัก ชอบ อะไรมากกว่ากัน ตัวอย่าง source code ทั้งหมดอยู่ที่ Github :: Up1 :: Demo Kotlin REST API

ความสามารถของ Developer ที่ดี ควรมีติดตัวไว้บ้าง 

April 5, 2016, 5:17 am

≫ Next: สิ่งที่น่าสนใจใน Technology Radar เดือนเมษายน 2559 จาก Thoughtworks

≪ Previous: ทดลองสร้าง REST API ด้วย Kotlin กันหน่อย

$

0

0

จากบทความเรื่อง 5 Skills a Software Developer Should Have to Be a Smart Developer ทำการสรุปความสามารถที่ Developer ที่ดีต้องมีไว้บ้าง ทั้ง Soft skill และ Technical skill เห็นว่ามีประโยชน์เลยนำมาแปลบางส่วน ดังนี้

ทำอะไรต้องตั้งใจ และ มีเป้าหมายเสมอ

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

•  ต้องแยกการทำงานของ code ออกเป็น Module
• Code ที่เขียนต้องดี เข้าใจง่าย และเป็นไปตามกฎที่ได้ตั้ง หรือ ตกลงกันไว้ และ ตรวจสอบได้
• Code ต้องไม่ผูกมัดกัน เพื่อให้ง่ายต่อการแก้ไข และ ทดสอบ
• Code ที่เขียนต้องจับวัดในเชิงตัวเลขได้เสมอ และ ต้องวัดอยู่อย่างสม่ำเสมอ เช่น ความซับซ้อน ประสิทธิภาพ เป็นต้น

หัดพูดภาษาคนให้ผู้อื่นรู้เรื่อง

เป็น Softskill ที่ developer ส่วนใหญ่มักไม่ค่อยสนใจ บ่อยครั้งมากที่มักมีคนบ่นว่า คุยกับพวก developer ไม่รู้เรื่อง ไม่รู้พวกนี้พูดภาษาอะไรกัน !! ดังนั้น เมื่อต้องนำเสมอแนวคิดอะไรใหม่ ๆ ดี ๆ ส่วนใหญ่มักจะตกม้าตายเสมอ ดังนั้น ให้เริ่มจากการอ่าน และ ฟังให้มาก ว่าคนทั่วไปเขาพูด สื่อสารกันอย่างไร จากนั้นต้องเริ่มฝึก ฝึก ฝึก และ ฝึก เพื่อทำให้พูด และ สื่อสารกับคนอื่นรู้เรื่อง ผลที่ตามมาก็คือ คุณสามารถสื่สารได้ดี ทำให้นำเสนอแนวคิดต่าง ๆ ได้ดียิ่งขึ้น

รวมทั้งต้องเป็นนักเล่าเรื่องที่ดีอีกด้วย เพื่อทำให้ผู้อื่นเข้าใจได้ง่ายขึ้น

ปล. เรื่องนี้ผมก็กำลังฝึกเหมือนกัน เพราะว่า พูดไม่ค่อยรู้เรื่องนั่นเอง !!!

เพิ่ม productivity และ เรียนรู้อยู่อย่างสม่ำเสมอ

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

• การอ่านบทความจากบริษัทดัง ๆ เช่น Netflix blog, AWS blog, Facebook, Airbnb และ DZone เป็นต้น
• ถามและตอบคำถามจาก website ต่าง ๆ เช่น Quora และ Stack Overflow เป็นต้น ส่วน Pantip นี่ไม่แนะนำ!!
• เรียนรู้จาก Course online ต่าง ๆ เช่น Coursera, Udemy, edX และ Youtube channel ต่าง ๆ เป็นต้น
• ติดตามบริษัท หรือ เทคโนโลยี หรือ คน ที่มีความสำคัญด้านเทคโนโลยีที่เราสนใจ

สุดท้ายต้องรักษาสุขภาพให้แข็งแรง

เป็นสิ่งที่สำคัญที่สุด เพราะว่า ถ้าร่างกาย และ จิตใจของคุณแข็งแรง การจะทำงาน หรือ สร้างสรรค์อะไร มันก็จะออกมาดี และ มีคุณภาพ ดังนั้นอย่าลืมออกกำลังกายกันนะ ไปวิ่งกันเถอะ ...

ดังนั้น Developer มาฝึกความสามารถต่าง ๆ เหล่านี้กันเถอะ

---

สิ่งที่น่าสนใจใน Technology Radar เดือนเมษายน 2559 จาก Thoughtworks

April 5, 2016, 11:27 pm

≫ Next: แนะนำ GitUp :: เพื่อทำให้เข้าใจ Git มากขึ้น

≪ Previous: ความสามารถของ Developer ที่ดี ควรมีติดตัวไว้บ้าง 

$

0

0

ทางบริษัท Thoughtworks จะสรุปเทคโนโลยีที่ใช้งาน และ แนวโน้มต่าง ๆ ในอนาคต โดยในครั้งนี้จะเน้นใน 4 เรื่อง คือ

1. Open Source
2. Cloud และ Platform as a Service (PaaS)
3. Docker ecosystem
4. Over-Reactive ?

จึงนำมาสรุปนิดหน่อย ซึ่งสามารถอ่านฉบับเต็ม ๆ ได้ที่ PDF Thoughtworks Technology Radar April 2016

จาก 4 เรื่องหลักของ Technology Radar

สิ่งที่ developer น่าจะสนใจคือเรื่องของ Over-Reactive ? ในปัจจุบันเรื่องของ Reactive programming ได้รับความนิยมอย่างมากมาย ดังจะเห็นได้ว่าทุกภาษา program ล้วนมี Reactive extension/library/framework ให้ใช้งาน ทั้งฝั่ง frontend และ backend แต่การใช้ที่มากจนเกินไป หรือ หลากหลายรูปแบบจนเกินไป !! มันก่อให้เกิดความซับซ้อนของระบบ และยากต่อการทำความเข้าใจ ดังนั้น ทีมพัฒนาความใช้งานในรูปแบบเดียวกัน และใช้เท่าที่จำเป็น อีกเรื่องที่น่าสนใจคือ Web Scale Envy ว่าด้วยเรื่องของการขยายระบบ และ เรื่องของ performance พบว่าหลาย ๆ ทีมมักจะมีปัญหาเรื่องนี้เสมอ เนื่องจากเลือกใช้เครื่องมือที่มีความซับซ้อน รวมทั้ง framework และ architecture ของระบบ บ่อยครั้งที่ทีมพัฒนาจะไปอ้างถึง architecture และ เครื่องมือของ Twitter, Facebook และ Netflix ซึ่งมีปริมาณการใช้งานที่สูงมาก ถึง โครตสูง ดังนั้นจำเป็นต้องมีเครื่องมือ และ architecture ที่ซับซ้อนแบบนั้น รวมทั้งความสามารถของแต่ละคนในทีมต้องสูงด้วยเช่นกัน ถึงจะใช้งาน และ จัดการความซับซ้อนเหล่านี้ได้ แต่เมื่อย้อนกลับมาดูทีมพัฒนาของเราสิ ดูปริมาณผู้ใช้งานสิ ดูความสามารถของแต่ละคนในทีมสิ มันต้องการความซับซ้อนเหล่านั้นหรือไม่ ?

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

ตามธรรมเนียมของ Technology Radar จะแบ่งออกเป็น 4 กลุ่มคือ

1. Techniques
2. Tools
3. Platforms
4. Languages และ Framework

ซึ่งจะสรุปบางตัวที่ผมสนใจจากแต่ละกลุ่มมาอธิบายนิดหน่อย จะเน้นสิ่งใหม่ ๆ ที่เข้ามา ทั้งดีและไม่ดี พยายามจะไม่ให้ซ้ำจากรายงานครั้งที่ผ่านมา ThoughtWorks Technology Radar ประจำเดือนพฤศจิกายน 2015

1. Techniques

เทคนิคใหม่ ๆ ที่เข้ามาอยู่ในกลุ่ม Assess จะเป็นเรื่องของ security ทั้ง Content security policy และ OWASP เนื่องจากทีมพัฒนาส่วนใหญ่ ไม่ค่อยนำเรื่อง security มาพูดคุยตั้งแต่เริ่มต้นการพัฒนา บางทีมอาจจะไม่สนใจเลยด้วยซ้ำ เนื่องจากคนส่วนใหญ่มีความรู้ด้านนี้น้อยมาก ๆ ซึ่งสิ่งเหล่านี้มันคือความเสี่ยงของระบบงานมาก ๆ แต่เรามักมองข้ามไปกันหมด ดังนั้นความเพิ่มเรื่อง security เข้าไปใน functional requirement ด้วยนะ ไม่ว่าจะเป็น

• Authentication process
• Access control
• Error handling
• Logging

มันจะทำให้เห็นว่าต้องพัฒนา และ ทดสอบอะไรบ้างนั่นเอง ส่วนเรื่องที่ไม่ควรทำ หรือ ถ้าจะทำต้องใช้ความระมัดระวังอย่างสูง !! การติดตั้ง CI server ที่เดียวเพื่อให้ทุก ๆ ทีมใช้งาน มันเคยเป็นแนวคิดที่ดี เนื่องจากจะได้ใช้งานเพียงที่เดียว ทำให้จัดการ และ monitoring ได้ง่าย แต่เมื่อมีระบบมากขึ้น คนใช้เยอะขึ้น การใช้งานเพียงเครื่องเดียวมันก่อให้เกิดปัญหามากมายตามมา ตัวอย่างเช่น

• เกิดข้อขัดแย้งในเรื่องของ configuration ที่หลากหลาย
• การเข้าคิวเพื่อที่จะ build หรือ ทำงาน
• การทำงานชนกัน
• ถ้าเครื่องนี้ล่มไป พังกันทุกทีมแน่นอน !!
• อื่น ๆ อีกมากมาย

ซึ่งมันเป็น Single Point of Failure (SPoF) ชัด ๆ ดังนั้นก่อนใช้งานต้องพิจารณาถึงข้อดีและข้อเสียให้มาก

คำแนะนำคือ แยก CI Server ตามทีมที่ทำงาน หรือ ระบบไปเลยนะครับ

เรื่องต่อมาคือ Big Data Envy !! ในปัจจุบันนั้นคำว่า Big Data มันเข้าไปอยู่ในทุกองค์กรแล้ว ซึ่งเข้าใจกันแล้วว่ามันคืออะไร มีคุณค่าอย่างไร แต่ปัญหาที่เกิดตามมาก็คือ การนำเครื่องมือที่ไม่เหมาะสมมาใช้งาน !! เช่นการนำเครื่องมือที่มีความซับซ้อนมาก ๆ มาจัดการกับข้อมูลที่ไม่ใช่ Big Data บ่อยครั้งพบว่า ข้อมูลที่มีอยู่นั้น สามารถสิเคราะห์ และ ประมวลผล เพียงเครื่องมือง่าย ๆ หรือใช้คอมพิวเตอร์เพียงเครื่องเดียว หรือใช้เพียง RDBMS ปกติก็ทำได้แล้ว หรือไม่เช่นนั้น ก่อนที่จะประมวลผลข้อมูล ช่วยเลือกเฉพาะข้อมูลที่ต้องการ และ จำเป็นมา จากนั้นจึงใช้เครื่องมือง่าย ๆ มาช่วยวิเคราะห์ และ ประมวลผล

ปล. อย่าทำอะไรที่มากเกินความจำเป็นนะครับ และให้เข้าใจด้วยว่ากำลังจะทำอะไร

2. Platforms

เป็นที่แน่นอนว่า Docker เข้ามาเป็น Platform หลักไปแล้ว ซึ่งตอบสนองความต้องการทั้งจาก ทีมพัฒนา, ทีม operation และ ทีม infrastructure และยังได้เกิด Docker ecosystem ขึ้นมาเยอะมาก ๆ ส่วนตัวอื่น ๆ ที่น่าสนใจ เช่น

• Realm คือ database สำหรับ mobile application เน้นเรื่อง high performance เป็นหลัก แน่นอนว่ามันเข้ามาเพื่อแทนที่ SQLite และ Core Data
• TensorFlow เป็น open source เรื่อง Machine Learning จาก Google ซึ่งพลาดไม่ได้ด้วยประการทั้งปวง

ส่วนเรื่องที่ต้องพึงระวังคือ Overambitious API Gateway !! หรือการจัดการ และ ใช้งาน API Gateway ที่ยาก และซับซ้อนเกินไป แทนที่จะส่งผลดี กลับส่งผลร้ายออกมาแทน !! เนื่องจากแนวคิดของ API Gateway นั้น มันทำให้เราง่ายต่อการจัดการเรื่องพื้นฐาน เช่น authentication, authorization และ rate-limit ต่าง ๆ แต่สำหรับงานอื่น ๆ พวก data transform, data processing นั้น มันไม่จำเป็นต้องมาผ่าน API Gateway เลย เพราะว่า ทำให้ควบคุม และ จัดการได้ยาก ดังนั้นควรให้ไปอยู่ใน application หรือ service นั้น ๆ ไปเลย

ปล. อะไรที่มันเยอะ มันยาก มันซับซ้อนเกินไป นั่นแสดงว่า คุณกำลังเดินผิดทางนะ

3. Tools

เป็นกลุ่มเครื่องมือต่าง ๆ ซึ่งมีเครื่องมือใหม่ ๆ เข้ามาเยอะมาก เริ่มต้นด้วย capsul เป็น service discovery tool ถูกย้ายมาในส่วนของ Adopt นั่นคือ แนะนำให้นำไปใช้งานบน production ได้เลย มันแจ่มมาก ๆ (ผมก็ใช้อยู่) ทำให้เราสามารถดูได้ว่า ในระบบของเรานั้นมี service อะไรทำงานอยู่บ้าง แน่นอนว่า สามารถทำงานกับ Docker ได้อย่างสบาย ต่อมาคือ เรื่องของ security อีกแล้วนั่นคือ OWASP Dependency-Check เป็นเครื่องมือสำหรับช่วยตรวจสอบเรื่อง security แน่นอนว่า มันทำให้ชีวิตของ developer ดีขึ้นแน่นอน ถ้าไม่เชื่อก็ลองนำไปใช้กันดูสิ โดยใช้ได้ทั้ง Java, .Net, Ruby, Python และ Node.js ส่วนเรื่องที่ต้องระมัดระวังคือ Jenkins as a Deployment Pipeline ซึ่งจะพูดถึงกรณีที่ กระบวนการ build มันมีความซับซ้อนมาก ต้องการเครื่องมือสร้างมาเพื่อจัดการโดยเฉพาะ ถึงแม้ใน Jenkins จะมี plugin ชื่อว่า Deployment Pipeline ถึงแม้ใน Jenkins 2.0 จะมี plugin ชื่อว่า Pipeline as Code แต่ก็ยังเป็นเพียง plugin ไม่ได้ทำการเปลี่ยน core หรือ การทำงานหลักของ Jenkins เลย เพื่อให้จัดการเรื่อง deployment pipeline โดยเฉพาะ

ปล. ผมยังไม่เคยเจอปัญหาเท่าไร เพราะว่า build pipeline ของผมยังไม่ซับซ้อนนั่นเอง

โดยในปัจจุบันมีเครื่องมือที่สร้างมาเพื่อ Deployment Pipeline เลย เช่น

• ConcourseCI
• LambdaCD
• Spinnaker
• Drone
• GoCD

4. Language และ Framework

ขอบอกได้เลยว่า มันเยอะมาก ๆ ไม่รู้จะเยอะไปไหน !! กลุ่มที่สามารถนำไปใช้กันได้เลย คือ

• ES6
• React.js
• Spring Boot
• Swift

สิ่งที่เกี่ยวกับ Mobile เยอะเลย เช่น

• Butterknife
• Dagger
• React Native
• Rebolectric
• Alamofire
• OkHttp

ส่วน JavaScript ก็เพียบ เช่น

• Ember.js
• Redux
• AngularJS
• Cylon.js
• Aurelia

และตัวอื่น ๆ ที่น่าสนใจ คือ Elm และ Elixir

สุดท้ายลองถามตัวเราเองสิว่า มีเรื่องอะไรที่ไม่รู้บ้าง ?

แนะนำ GitUp :: เพื่อทำให้เข้าใจ Git มากขึ้น

April 6, 2016, 6:42 am

≫ Next: ต้องทำอย่างไรดีเมื่อต้องไปแก้ไข Legacy Code ?

≪ Previous: สิ่งที่น่าสนใจใน Technology Radar เดือนเมษายน 2559 จาก Thoughtworks

$

0

0

เนื่องจากการใช้งาน Git นั้น มันอาจก่อให้เกิดความสับสน และ มึนงง สำหรับผู้เริ่มต้นใช้งานทั้งหน้าเก่า และ หน้าใหม่ ถ้าไม่เชื่อลองไปดูใน Stack Overflow สิ ว่าคำถามเกี่ยวกับ Git ถูกถาม และ vote เยอะมาก ๆ

ส่วนใหญ่เป็นคำถามพื้นฐานมาก ๆ เช่น

• How do you undo the last commit ?
• Edit an incorrect commit message in Git ?
• Delete a Git branch both locally and remotely ?
• What are the differences between 'git pull' and 'git fetch' ?

ซึ่งปัญหาเหล่านี้มันอยู่กับ Git มานานกว่า 10 ปี (เท่ากับอายุของ Git เลย) ทำให้เสียเวลามากมายไปกับการหาวิธีการแก้ไขปัญหา ดังนั้น GitUp จึงเกิดมา เพื่อช่วยแสดงการทำงานต่าง ๆ ของ Git repository ในรูปแบบของ Graphic User Interface (GUI) สามารถใช้งานบน Mac เท่านั้นนะ !! ทำให้เราสามารถเห็นผลการทำงานจากคำสั่งต่าง ๆ ของ Git ผ่าน command line ทำให้เราเรียนรู้การใช้งานได้ดีขึ้น ทำให้เราเข้าใจการทำงานได้ดีขึ้น เหมาะอย่างยิ่งสำหรับผู้เริ่มต้นใช้ใหม่ ๆ

โดยมีความสามารถเยอะใช้ได้เลย

นอกจากจะแสดงผลการทำงานเป็น graph สวย ๆ แล้ว ยังมีความสามารถอื่น ๆ อีก เช่น

• แก้ไข commit message
• ใช้งานพวก checkout, reset, revert ได้ง่ายมาก ๆ
• ใช้งานพวก merge และ rebase ได้อีก
• แสดง log ต่าง ๆ ได้ชิว ๆ
• ค้นหาข้อมูลได้
• แถมเร็วอีกต่างหาก

แสดงการแก้ไขต่าง ๆ ดังรูป แสดง log ของ commit message นิดหน่อย

สุดท้ายแล้วสำหรับคนใช้งาน Git บน Mac ผมแนะนำให้ลองใช้งาน GitUp ดูครับ เหมาะมาก ๆ สำหรับการเริ่มต้นเรียนรู้ Git

Reference Websites https://github.com/git-up/GitUp

ต้องทำอย่างไรดีเมื่อต้องไปแก้ไข Legacy Code ?

April 6, 2016, 11:35 pm

≫ Next: ทำความรู้จักกับ Reindex API ใน Elasticsearch 2.3 กัน

≪ Previous: แนะนำ GitUp :: เพื่อทำให้เข้าใจ Git มากขึ้น

$

0

0

เป็นเรื่องปกติของ Developer ทุกคนที่ต้องผจญภัยกับ Legacy Code แต่สำหรับ Developer หน้าใหม่ ๆ นั้น อาจจะมีความคิด และ ความคาดหวังว่า เมื่อเข้ามาทำงานแล้ว ต้องมาพัฒนา feature ใหม่ ต้องมีเขียน code ใหม่ โดยไม่สนใจใคร แต่ในโลกความเป็นจริงมันไม่เคยเป็นเช่นนั้นเลย เนื่องจากต้องเข้าไปแก้ไขสิ่งเล็ก ๆ ที่เรียกว่า Legacy Code บางคนเรียกว่า Death Star !! บางคนอาจจะบอกว่า ซวยล่ะ งานเข้าแน่นอน !! ดังนั้นเรามาดูกันหน่อยว่าจะรับมือกับมันอย่างไรบ้าง ?

อย่างแรก คือ เตรียมตัวและเตรียมใจไว้ก่อน

สิ่งแรกที่คุณต้องเจออย่างแน่นอนคือ Code ที่มันยุ่งเหยิง ทั้งในระดับ method ที่มีจำนวนบรรทัดเยอะ ๆ ทั้งในระดับ fiel/class ที่มีขนาดใหญ่มาก ๆ บางคงเรียกว่า God class Code ที่มี dependency ทั้งจากภายในและภายนอกมากมาย แน่นอนว่า น่าจะไม่มีชุดของการทดสอบ หรือ มีน้อยมาก ๆ

จึงเป็นที่มาของคำพูดจากปากหลาย ๆ คน คือ อย่าไปยุ่งกับมันเลย มันดีอยู่แล้ว อย่า ... แต่ ... รอเขียนใหม่ดีกว่า !! (ได้ Legacy code ชุดใหม่ขึ้นมาอีก)

แต่ Legacy Code เหล่านี้ กลับเป็นส่วนที่สร้างรายได้ให้กับทีมและบริษัท และนำเงินเหล่านั้นมาจ่ายเป็นเงินเดือน และ ค่าจ้างให้คุณ มีแต่คนไม่ชอบ Legacy Code เหล่านี้ !! มันขัดแย้งกันดีนะเออ !!

จากนั้นสิ่งที่ต้องทำคือ ทำตามแนวคิด The Boy Scout Rule

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

• รู้ไหมว่า ถ้าแก้ไขส่วนนี้ไปแล้วมันจะกระทบส่วนไหนบ้าง ?
• รู้ไหมว่า การทำงานส่วนนี้มันสำคัญมาก ๆ ?
• รู้ไหมว่า มันเสี่ยงมาก ๆ ?
• รู้ไหมว่า ? มั่นใจไหมว่าจะไม่กระทบ ?

คำตอบที่มักได้รับกลับมาคือ ก็ไม่รู้เหมือนกัน .. น่าจะไม่ ... !! สุดท้ายจึงได้ข้อสรุปว่า อย่าไปยุ่งกับมันเลยนะ !! ทั้ง ๆ code มันแย่มาก แต่ทำงานได้นะ เช่น

• Loop​ ซ้อนกัน 5-10 ชั้น
• ใช้ Global variable เยอะมาก
• แต่ละ method มีขนาดใหญ่มาก ๆ
• และอื่น ๆ อีกมากมาย !!

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

ตอบง่าย ๆ คือ ให้ทำการแก้ไขเมื่อ code เหล่านั้นมีข้อผิดพลาด (Bug) หรือต้องการแก้ไข หรือ เพิ่มเติมความสามารถใหม่ ๆ เข้าไป นอกจากนี้ก็อย่าไปยุ่งกับมัน ? !!!

ถ้ายังไม่เข้าใจ มึนงงอยู่ ก็อย่าไปยุ่งกับมันสิ

มิเช่นนั้น ถ้าทำการแก้ไขแล้ว ทั้งที่ไม่เข้าใจ อาจจะส่งผลเสียมากกว่า ผลดีนะ ทั้งต่อตัวคุณเอง และ ระบบงาน บางครั้งผลมันอยู่เหนือการคาดเดาใด ๆ ทั้งสิ้น ดังนั้นก่อนจะทำการแก้ไข Legacy Code ต้องถามตัวเองว่ามั่นใจหรือเปล่า ? มีวิธีการอื่นที่ไม่ต้องแก้ไข code หรือไม่ ? เช่นการเพิ่ม Wrapper, Proxy, Facade และ Adapter เข้าไป ? หรือ extend มันมาได้ไหม ? ซึ่งให้ระมัดระวังเป็นอย่างมาก รวมทั้งต้องมีความมั่นใจด้วย

จากนั้นลองพิจารณาสิว่า การเปลี่ยนแปลงเหล่านั้นมันมีความเสี่ยงสูงไหม ?

เนื่องจากการเปลี่ยนแปลง Legacy Code ล้วนมีความเสี่ยงด้วยกันทั้งนั้น แต่จะเสี่ยงมากหรือน้อยเท่านั้นเอง ดังนั้นก่อนทำการแก้ไข ต้องตรวจสอบ และ ทำความเข้าใจก่อนว่า code เหล่านั้นมันส่งผลกระทบมากหรือน้อย ลองคิดกันเองนะว่า คุณจะแก้ส่วนไหน ระหว่างส่วนที่มีความเสี่ยงมาก และ น้อย ? อย่าลืม The Boy Scout Rule นะครับ ก่อนทำการแก้ไข ให้เรียนรู้พฤติกรรมการทำงานของ code ซะ เป็นเรื่องที่หลาย ๆ คนไม่อยากเรียนรู้ และเข้าใจ เพราะว่า มันซับซ้อน มันยาก (อะไรที่ไม่เขียนเองมันยากทั้งหมด) สุดท้ายก็ไม่ทำการแก้ไข !!

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

หนึ่งในวิธีการทำความเข้าใจคือ การเขียน unit test นั่นเอง ซึ่งอธิบายทั้งการทำงาน และ พฤติกรรมการทำงานจริง ๆ ของ code รวมทั้งการเขียนเอกสารเพิ่มอธิบาย code ก็เป็นอีกหนึ่งทางเลือก

โดยสรุปแล้ว

ก่อนที่จะทำการแก้ไข Legacy Code นั้น คุณต้องเข้าใจมันก่อนว่า ทำงานอย่างไร ? คุณต้องเข้าใจด้วยว่า ทำไมต้องแก้ไข ? คุณต้องเข้าใจด้วยว่า ผลจากการแก้ไขเป็นอย่างไร ? และอย่าลืมว่า ต้องทำการเปลี่ยนแปลง ปรับปรุงให้ดีขึ้นอยู่อย่างเสมอ แล้วคุณจะอยู่กับ Legacy Code ได้ดีขึ้น

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

Reference Website https://jvaneyck.wordpress.com/2015/07/27/legacy-code-retreat/ http://www.daedtech.com/know-touch-legacy-code/

ทำความรู้จักกับ Reindex API ใน Elasticsearch 2.3 กัน

April 7, 2016, 7:41 am

≫ Next: REST กับ SOAP ต่างกันอย่างไร ?

≪ Previous: ต้องทำอย่างไรดีเมื่อต้องไปแก้ไข Legacy Code ?

$

0

0

ใน Elasticsearch 2.3 มีความสามารถใหม่ที่น่าสนใจ ก็คือ Re-index API (_reindex) ทำหน้าที่ย้ายข้อมูลจาก index หนึ่งไปยังอีก index หนึ่ง โดยปกติเราจะใช้เครื่องมืออื่น ๆ มาช่วย ดังนั้นเรามาลองใช้งานกันดีกว่าว่า API ตัวนี้เป็นอย่างไร ?

ปล. การใช้งานควรคิดให้มาก ๆ เนื่องจากยังมีสถานะเป็น experiment นะ สามารถเปลี่ยนแปลงได้ตลอดเวลา แถมการเปลี่ยนแปลงนั้น ๆ ไม่สนับสนุนของเดิมด้วยนะ (Not backward compatible)

เริ่มด้วยปัญหาที่ผู้ใช้งาน Elasticsearch พบเจอกันมาก

คือ เมื่อทำการ indexing ข้อมูลเข้ามายัง Elasticsearch แล้ว พบว่า mapping ของข้อมูลไม่ถูกต้อง ยกตัวอย่างเช่น เมื่อนำข้อมูลมาแสดงใน Kibana แล้วจะแจ้งเตือนดังรูป คำถามคือ เราจะต้องแก้ไขปัญหานี้อย่างไรดี ? ตอบง่าย ๆ คือ ก็ทำการ re-indexing ไงล่ะ คำถามต่อมาก็คือ แล้วทำอย่างไรกันดี ? คำตอบง่าย ๆ คือ

• ลบ index แล้วสร้างใหม่ไงล่ะ ?
• ถ้ามีข้อมูลก็ต้องสร้าง index ใหม่ จากนั้นทำการย้ายข้อมูล
• แน่นอนว่าต้องใช้งาน Alias index ด้วยเสมอ

ประเด็นสำคัญอยู่ที่ข้อ 2 คือ การย้ายข้อมูล ซึ่งวิธีการย้ายข้อมูลก่อน Elasticsearch 2.3 นั้น แนะนำให้ทำการ Re-indexing แบบ Batching ด้วยการใช้งาน Scroll และ Bulk API หรืออาจจะใช้เครื่องมือช่วยย้ายข้อมูล เช่น Elasticsearch Dump ตัวอย่าง script ของการ Re-index เป็นดังนี้ [gist id="d03e1ba2aad382cdd1f521a9a12f716c" file="old_way.sh"]

เมื่อ Elasticsearch 2.3 ถูกปล่อยออกมาก็มี  Re-indexing API

ดังนั้นมาดูกันว่าใช้งานกันอย่างไร ? ขั้นตอนที่ 1 ทำการสร้าง index ใหม่ก่อน ชื่อว่า sample_new ซึ่งมี mapping ดังนี้ [gist id="d03e1ba2aad382cdd1f521a9a12f716c" file="new_way_create_index.sh"] ขั้นตอนที่ 2 ทำการย้ายข้อมูลด้วย _reindex API ดังนี้ [gist id="d03e1ba2aad382cdd1f521a9a12f716c" file="new_way_reindexing.sh"] คำอธิบาย ในการใช้งาน Re-index api ประกอบไปด้วย 2 ส่วนคือ

1. source คือ index ต้นทาง
2. dest คือ index ปลายทาง

เมื่อเสร็จสิ้นการทำงาน จะพบว่าข้อมูลถูก copy ไปยัง sample_new index ทั้งหมด และลองเข้าไปดูใน Kibana จะพบว่าคำเตือนจาก Kibana จะหายไปแล้ว ง่ายไหมล่ะ ? แถมยังสามารถกรองข้อมูลเฉพาะที่ต้องการได้ด้วยนะ เช่นถ้าต้องการเอกสารที่มี tags = elasticsearch จำนวน 3 เอกสารเท่านั้น แสดงตัวอย่างดังนี้ [gist id="d03e1ba2aad382cdd1f521a9a12f716c" file="new_way_filter.sh"] ตัวอย่างของ script ทั้งหมดอยุ่ที่ Github::Up1::Elasticsearch sample

สุกท้ายแล้ว

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

REST กับ SOAP ต่างกันอย่างไร ?

April 7, 2016, 9:35 pm

≫ Next: [แปล] compile ‘android:best:1.1.1’  ห้ามพลาดสำหรับ Android Developer !!

≪ Previous: ทำความรู้จักกับ Reindex API ใน Elasticsearch 2.3 กัน

$

0

0

สิ่งหนึ่งที่ developer ควรทำความเข้าใจก็คือ เรื่องของ REST vs SOAP ก่อนตัดสินใจใช้นั้น ควรรู้และเข้าใจก่อนว่า

• REST และ SOAP คืออะไร ?
• ทั้งสองมีข้อดีและข้อเสียอย่างไร ?
• ใช้งานแต่ละตัวเมื่อใด ?

เรื่องความรู้พื้นฐานมันสำคัญมาก ๆ ดังนั้นมาปูพื้นแบบเบา ๆ กันนิดหน่อย SOAP ย่อมาจาก Simple Object Access Protocol ถูกกำหนดขึ้นมาตั้งแต่ปี 1998 เป้าหมายเพื่อใช้ในตลาด enterprise โดยเฉพาะ ปล. developer หลาย ๆ คนอาจจะไม่รู้จัก SOAP ก็เป็นได้ !! REST ย่อมาจาก Representational State Transfer ถูกกำหนดขึ้นมาตั้งแต่ปี 2000 เป้าหมายเพื่อเป็นรูปแบบหนึ่งในการออกแบบ open web technology

แนวคิดพื้นฐาน

SOAP นั้นต้องสร้างให้ application logic ออกมาเป็น service ทำให้การตั้งชื่อเป็นดังนี้

• getUserInformation
• payInvoice

โดย SOAP เป้าหมายเพื่อเป็น protocol ใหม่ของการติดต่อสื่อสาร ส่วน REST นั้นต้องการทำให้ข้อมูลอยู่ในรูปแบบของ resource ส่วนการกระทำต่าง ๆ เป็นไปตาม HTTP Verb หรือ HTTP Method (GET, POST, PUT, DELETE) และทำงานแบบ Stateless ทำให้การตั้งชื่อเป็นดังนี้

• userinformation
• invoice

ข้อดีและข้อเสียของ SOAP

ข้อดี

• สามารถทำงานอยู่บน protocol ใด ๆ ก็ได้
• อธิบาย service ด้วย WDSL (Web Service Description Language)
• มีความน่าเชื่อถือ เมื่อเกิดปัญหาสามารถทำการ retry ได้
• สนับสนุนเรื่อง security อยู่แล้ว ทั้ง authentication, authorization และ การเข้ารหัสข้อมูล

ข้อเสีย

• ยากต่อการพัฒนา ทำให้ไม่เป็นที่นิยมสำหรับระบบ web และ mobile
• สนับสนุนรูปแบบข้อมูล XML เพียงอย่างเดียว
• เนื่องจากมันเป็น standard ทำให้มีข้อจำกัดเยอะ
• เนื่องจากโครงสร้างมันมีหลายส่วนทำให้มี overhead สูง หรือ ต้องใช้ bandwidth สูงกว่า REST

ข้อดีและข้อเสียของ REST

ข้อดี

• ทำการอยู่บน HTTP และทำตามมาตรฐานของ HTTP จึงทำให้พัฒนาได้ง่าย
• สนับสนุนรูปแบบข้อมูลมากมาย เช่น XML, JSON, Plain Text และอื่น ๆ อีกมากมาย
• รองรับการขยายระบบได้ง่าย
• มีประสิทธิภาพการทำงานที่ดี
• รองรับเรื่อง caching ข้อมูล

ข้อเสีย

• ทำงานได้เฉพาะ HTTP protocol เท่านั้น
• ไม่มีเรื่องของ security และ reliability มาให้ในตัว ดังนั้นต้องทำเอง
• รูปแบบข้อมูลที่ส่งไปมาระหว่าง client-server ไม่มีข้อจำกัดอะไรเลย

คำถามที่น่าสนใจคือ จะใช้ SOAP และ REST เมื่อใดบ้าง ?

ใช้ SOAP เมื่อ ต้องการจัดการ transaction เมื่อต้องทำงานกับหลาย ๆ ระบบ ต้องการความเข้มงวดในการเชื่อมต่อระหว่าง client/server ตัวอย่างเช่น Finacial service และ Telecommunication service ดังนั้นจึงไม่แปลกว่า ทำไมในองค์กรใหญ่ ๆ เหล่านี้ใช้ SOAP กันมาก ใช้ REST เมื่อ ต้องการลดขนาดของข้อมูล และ จำนวน bandwidth ที่ใช้งาน ต้องการเมื่อทำงานอยู่บนระบบ web และ mobile ตัวอย่างเช่น Social media service, Web Chat service ดังนั้นจึงไม่แปลกว่า ทำไมระบบ web และ api ต่าง ๆ ผ่าน web จึงเป็น REST บางคนไปหาข้อมูลสำหรับ Open API น่าจะข้อมูลดังนี้ ซึ่งบอกว่า REST มันได้รับความนิยมกว่า SOAP มากมาย

สุดท้ายแล้ว ก่อนจะเลือกใช้งานอะไร

ต้องมีความรู้พื้นฐานก่อน ต้องมีความเข้าใจก่อน ต้องเข้าใจความต้องการของระบบก่อน จึงจะเลือกได้อย่างถูกต้องและเหมาะสม

มิใช่เพียงฟังเขาบอกมา ว่ามันดี จึงใช้ตาม !!

ปิดท้ายด้วย Infographic ของ REST vs SOAP Reference Websites http://stackoverflow.com/questions/19884295/soap-vs-rest-differences https://dzone.com/articles/rest-or-soap-which-one-to-use http://searchsoa.techtarget.com/tip/REST-vs-SOAP-How-to-choose-the-best-Web-service