เก็บตกความรู้ที่น่าสนใจจาก session Android Testing

December 6, 2015, 8:47 pm

≫ Next: แปลเรื่อง Android Development Culture

≪ Previous: ทำความรู้จักกับ Hermetic Testing กันหน่อย

$

0

0

จากงาน Android Dev Summit 2015 นั้น ได้นั่งดู VDO เรื่อง Android Testing ซึ่งได้แนะนำเทคนิคที่น่าสนใจเกี่ยวกับการพัฒนา Android app รวมทั้งวิธีการทดสอบ ดังนั้น มาดูกันหน่อยว่ามีอะไรที่น่าสนใจบ้าง

1. เกี่ยวกับการจัดการ version ของ Library ต่าง ๆ

ทำการประกาศตัวแปรสำหรับกำหนด version ของ library ต่าง ๆ ไว้ในไฟล์ build.gradle ที่ root project ตัวอย่าง [gist id="ae92b71ebf84214dcef2" file="root_build.gradle"] ส่วน module ไหนต้องการใช้งาน หรืออ้างถึงตัวแปรเหล่านี้ ก็ใช้งานผ่าน rootProject.ext.variable_name ได้เลย ตัวอย่าง [gist id="ae92b71ebf84214dcef2" file="app_build.gradle"] น่าจะเห็นข้อดีของการจัดการ version ของ library ต่าง ๆ แล้วนะครับ นั่นคือ จัดการเพียงที่เดียวไงล่ะ สบายกว่าเดิมเยอะ !!

2. เกี่ยวกับโครงสร้างของ project สำหรับการทดสอบ

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

• androidTest เก็บ Android test เช่นเดิม ซึ่งจำเป็นต้องใช้ Emulator หรือ device จริง ๆ
• androidTestMock เก็บ Android test สำหรับ mock flavor โดยเฉพาะ ซึ่งใช้สำหรับการทดสอบบน Hermetic environment นั่นเอง
• main ใช้เก็บ code หลักของระบบ
• mock ใช้สำหรับการ custom mock flavor นั่นเอง จะมี Injection class เพื่อใช้งานพวก dummy และ fake data แทนระบบจริง
• prod ตรงข้ามกับ mock เลย นั่นคือทำงานบนของจริง
• test เก็บพวก Unit test

แสดงดังรูป

3. เกี่ยวกับการทดสอบโดยใช้ความสามารถของ Build Variant กับ Dependency Injection

โดยใน project จะมี Build Variant ดังนี้

• mockDebug
• prodDebug
• proRelease

แสดงดังรูป คำถาม สิ่งที่น่าสนใจ คือ ถ้าเราทำการทดสอบผ่าน Mock server ล่ะ จะเปลี่ยนการทำงานภายใน code อย่างไร ? คำตอบ วิธีการที่เรา ๆ ท่าน ๆ ทำกันก็คือ comment เอาสิ แล้วก็ทำการ build ใหม่ !! แต่จาก VDO เรื่อง Android Testing ได้แนะนำวิธีการที่ดูดี และ ยึดหยุ่นกว่า นั่นคือใช้งานผ่าน Dependency Injection สิ ประเด็นหลักคือ การแยก หรือ Isolate พวก Dependency ออกจากการทำงานก่อน เช่นการดึงข้อมูลจาก APIs เราสามารถแยกการทำงานด้วยการสร้าง Interface ขึ้นมาดังนี้ [gist id="ae92b71ebf84214dcef2" file="BlogServiceAPI.java"] จากนั้นใน folder mock เราจะทำการสร้าง class Injection ขึ้นมา เพื่อเป็นตัวกลางสำหรับการเรียกใช้ข้อมูลจาก Dummy และ Fake server โดย class Injection จะมีทั้งใน folder mock และ prod ซึ่ง Injection ใน prod นั้นจะเป็นของจริงนั่นเอง แสดงดังรูป สำหรับการเรียกใช้งานก็เพียงสร้าง instance ของ Injection ซะ [gist id="ae92b71ebf84214dcef2" file="CallInjection.java"] เท่านี้ก็ใช้งานได้แล้ว ซึ่งสามารถทำการทดสอบ แยกตาม environment ที่เราต้องการได้เลย สะดวกมาก ๆ เช่น ./gradlew assembleMockDebugAndroidTest ./gradlew assembleDebugAndroidTest น่าจะทำให้การทดสอบ Android app เป็นเรื่องที่สนุกมากยิ่งขึ้นนะครับ และสามารถดูตัวอย่างได้จาก CodeLab::Android Testing ทำการอธิบายแยกเป็นเรื่อง ๆ อย่างชัดเจน พร้อมตัวอย่าง code

ใครยังไม่เขียน test สำหรับ Android app บ้างนะ ?

---

แปลเรื่อง Android Development Culture

December 7, 2015, 8:01 am

≫ Next: สิ่งที่บ่งบอกว่ากำลังนำ DevOps ไปใช้แบบผิด ๆ

≪ Previous: เก็บตกความรู้ที่น่าสนใจจาก session Android Testing

$

0

0

จากบทความเรื่อง Android Development Culture ได้พูดถึงรูปแบบการพัฒนา Andriod app ซึ่งน่าจะต้องปรับเปลี่ยนไปจากเดิมที่เคยเป็นมา เนื่องจาก project ต่าง ๆ นั้นล้วนไม่มี automated test เลย ทั้ง unit test, integration test และ functional test รวมไปถึงไม่มีการใช้ lint tool ในการตรวจสอบ code ชอบสร้าง code ที่มันยุ่งเหยิง ที่เราเรียกกันว่า spaghetti code ในปัจจุบันมันมีคำเรียกใหม่ คือ reactive spaghetti และอื่น ๆ อีกมากมาย ดังนั้นมาดูว่า เราควรต้องปรับเปลี่ยนสิ่งใดกันบ้าง ?

ประโยคที่น่าสนใจ

Optimization without a good level of code quality is a kind of premature optimization, premature optimization is also known as the root of all evil.

ดังนั้นเรื่อง คุณภาพของ code จึงเป็นเรื่องที่สำคัญมาก

Fail Fast, Fail Early

เราต้องเจอปัญหาของ app ก่อนที่จะส่งมอบให้ผู้ใช้งานเสมอ หรือรู้ปัญหาก่อนผู้ใช้งาน

ลองถามตัวเราเอง และ ทีมพัฒนาสิว่า ในปัจจุบันนั้น เรารู้ปัญหาก่อนหรือหลังผู้ใช้งาน ?

โดยแนวปฏิบัติดังต่อไปนี้ จะช่วยเรื่องนี้ทั้งหมด

1. Pull Request, Code Review และ Continuous Integration

แน่นอนว่า code ของระบบงานทั้งหมดต้องถูกจัดการด้วย Version Control System ไม่ว่าจะเป็น Git, Mercurial HG และ Subversion โดยขั้นตอนการพัฒนาควรเริ่มต้นจาก Pull request ซึ่ง developer แต่ละคนเป็นคนส่งการเปลี่ยนแปลงเข้ามา จากนั้นจะมีระบบ Continuous Integration เพื่อทำการ build ระบบแบบอัตโนมัติ เช่นการ build, code review และ test ถ้าผลการทำงานผ่าน จะทำการ merge code เข้ามายัง main branch แต่ถ้าไม่ผ่าน จะไม่ทำการ merge เข้าไปยัง main branch

2. Code quality

Code ที่สร้างขึ้นมานั้น ควรที่จะเป็น SOLID ซึ่งไม่ใช่ก็น่าจะใกล้เคียงกันบ้าง โดยไม่จำเป็นต้องไปยึดติดกับ Design Pattern ใด ๆ เช่น MVC, MVP, MVVM และ VIPER เป็นต้น แต่ควรที่จะแยกการทำงานต่าง ๆ ออกจากกันให้ชัดเจน (Isolation) หรือบางคนจะเรียกว่า Separation Of Concern เพื่อลด bad code ในการ review นั่นเอง

3. Static code/resource analysis

เครื่องมือพวก Static code analysis นั้นช่วยเราหา code ที่น่าจะก่อให้เกิดปัญหา ก่อนที่จะทำการ package และ ส่งมอบไปให้ผู้ใช้งาน และเป็นเครื่องมือช่วยเหลือในการทำ Code Review อีกด้วย โดยใน Android มีเครื่องมือให้ใช้มากมาย เช่น

• Android Lint
• FindBugs
• PMD
• SonarQube
• FB Infer

แนะนำให้นำเครื่องมือเหล่านี้ ไปใช้ที่เครื่อง developer ทุกคน และนำไป run ไว้ในระบบ Continuous Integration เพื่อทำให้รู้ว่า code ของคุณได้ไปต่อหรือไม่ !!

4. Unit test

แน่นอนว่า code ทุก ๆ บรรทัด แน่นอนว่า code ทุก ๆ class แน่นอนว่า code ทุก ๆ method/function ที่ developer ทุกคนเขียนขึ้นมานั้น มันสามารถทำงานได้อย่างถูกต้องตามที่คาดหวัง ยิ่งมีการทดสอบที่เยอะ ครอบคลุม และ ทำงานรวดเร็ว ก็จะยิ่งเพิ่มความมั่นใจต่อระบบให้กับเรา และ ผู้อื่น และก็ช่วยให้ app ที่ส่งมอบให้ผู้ใช้งานมีคุณภาพมากขึ้น ในปัจจุบันการทดสอบ Android app เป็นเรื่องไม่ยากอีกต่อไปแล้ว เนื่องจากทีมพัฒนา Android นั้น ได้เพิ่มความสามารถต่าง ๆ ในการทดสอบมาให้แล้ว ไม่ว่าจะเป็น

• JUnit 4
• Android Unit test หรือ Android Instrumentation
• รวมทั้งยังสามารถนำ Mock framework มาใช้ได้ด้วย เช่น Mockito เป็นต้น

จะเขียนตามแนวคิด Test-Driven Development (TDD) หรือไม่ก็ตาม มันขึ้นอยู่กับคุณ และ ทีม แต่ Unit test นั้น คุณ และ ทีมจำเป็นต้องเขียน !!

แน่นอนว่า developer ทุก ๆ คนต้องสามารถ run unit test นี้ได้เสมอ รวมทั้งทำการ run unit test บนระบบ Continuous Integration อีกด้วย

5. Code coverage

เมื่อคุณเริ่มเขียน Unit test แล้ว น่าจะต้องอยากรู้ว่ามันครอบคลุม code ไปเท่าไร ? มี code ส่วนไหนบ้างที่ยังไม่มี Unit test ครอบคลุมบ้าง ? โดยใน Android project นั้น เราสามารถใช้ Code Coverage Tool ชื่อว่า Jacoco ช่วยในการตรวจสอบได้เลย รวมทั้งสามารถเพิ่มขึ้นตอนการตรวจสอบ ในระบบ Continuous Integration ได้อีกเช่นกัน โดยที่จำนวน Code coverage นั้น มีไว้สำหรับการปรับปรุงการเขียน test ของทีมนั่นเอง

6. Functional หรือ UI test

เพียง Unit test มันคงยังไม่พอ เราต้องการการทดสอบที่มากกว่านั้น นั่นก็คือ การทดสอบ function การทำงานต่าง ๆ ด้วยมุมมองของผู้ใช้งานนั่นเอง นั่นคือเราต้องการทดสอบด้วยการเปิด app ขึ้นมา แล้วทำการตรวจสอบในแต่ละการกระทำ แล้วทำการตรวจสอบในแต่ละหน้า หรือ flow การทำงาน ผ่านหน้าจอการทำงานของ app จริง ๆ เชื่อว่าในปัจจุบันจะมีกลุ่มของ QA/Tester สำหรับทำการทดสอบแบบ manual test แต่มันกลับกลายเป็นปัญหาคอขวดของการพัฒนาไป ดังนั้น เราต้องการการทดสอบแบบอัตโนมัติ เพื่อลดภาระของ QA/Tester ลงไป ไม่ใช่ว่าไม่มีคนกลุ่มนี้นะครับ โดยใน Android ก็ได้เตรียมการทดสอบไว้ให้แล้ว เช่น

• Android Instrumentation test
• UI Automator
• Espresso

ซึ่งแนะนำให้เริ่มจาก Espresso ก่อนเลย คำถามที่น่าสนใจ คือ ใครเป็นคนเขียน test ล่ะ ? ตอบง่าย ๆ คือ Developer ไงล่ะ แต่ถ้าสามารถสอนให้ QA/Tester เขียนได้ จะเป็นเรื่องที่ดีอย่างมาก เนื่องจาก QA/Tester จะมีวิธีการคิด สำหรับการทดสอบที่แตกต่างออกไปจาก developer และอย่าลืมควรสอบ Code coverage ด้วยล่ะ สุดท้ายแล้วเราต้องสามารถ run ชุดการทดสอบเหล่านี้ได้บนเครื่อง developer เอง รวมทั้งนำไป run ในระบบ Continuous Integration ด้วย

7. Integration test

ทำการทดสอบอีกแล้ว แต่ Integration test เอาไว้ตรวจสอบว่า แต่ละส่วนการทำงาน หรือ แต่ละ component มันทำงานร่วมกันได้อย่างถูกต้องตามที่คาดหวัง เช่น

• HTTP layer
• REST API layer
• Executor layer
• Persistence layer

ดังนั้นสิ่งที่เราต้องการมากกว่า Unit test ก็คือ การจำลองส่วนการทำงานต่าง ๆ ของแต่ละ component ขึ้นมานั่นเอง ซึ่งผมเขียนอธิบายไว้ในเรื่อง Hermetic Testing โดยเราสามารถทำการทดสอบพวก Integration test ด้วย Unit test และ Android Instrumentation ได้เลย ซึ่งมันทำงานได้รวดเร็วมาก และแน่นอนว่าสามารถนำไป run ในระบบ Continuous Integration ได้อีกด้วย

มาถึงตรงนี้ น่าจะพอทำให้เห็นภาพแล้วว่า

การพัฒนา Android app ที่ดีนั้นควรเป็นอย่างไร ซึ่งในฐานะที่เป็น developer ก็ควรที่จะนำแนวปฏิบัติเหล่านี้ไปใช้งานบ้างนะครับ เพื่อจะได้ไม่เป็นภาระให้แก่ลูกหลานในอนาคต เริ่มง่าย ๆ จากปัญหาที่คุณเจออยู่เป็นประจำ แล้วลองนำแนวปฏิบัติเหล่านี้ไปใช้ เพื่อแก้ไข หรือ ลดปัญหาลงไป

สิ่งที่บ่งบอกว่ากำลังนำ DevOps ไปใช้แบบผิด ๆ

December 8, 2015, 8:14 pm

≫ Next: Time to Main คือตัวชี้วัดที่ดีสำหรับ Continuous Integration

≪ Previous: แปลเรื่อง Android Development Culture

$

0

0

จากบทความเรื่อง 7 SIGNS YOU'RE DOING DEVOPS WRONG ได้อธิบายเกี่ยวกับการนำ DevOps ที่ผิด ๆ เป็นสิ่งที่น่าสนใจมาก เพื่อไม่ให้เดินไปในทางที่ผิด จึงนำมาแปลนิดหน่อย มาดูกันว่ามีอะไรบ้าง ?

Anything that can go wrong, will go wrong. -- Murphy's law

1. จำเป็นต้องซื้อทุกอย่างสำหรับ DevOps

ไม่ว่าจะเป็น Hardware เช่น Server, Network, Router, Switching และ Load balance ไม่ว่าจะเป็น Software เช่น OS, Antivirus, Project management, Business และ Monitoring เป็นต้น ไม่ว่าจะเป็นพนักงานใหม่ เพื่อมาดูระบบใหม่ของ DevOps ส่วนใหญ่จะเป็นคนใหม่หรือเลือดใหม่มาเลย เนื่องจากบริษัทเชื่อว่า ในการจะทำสิ่งใหม่ ๆ ที่ยิ่งใหญ่ได้นั้น จำเป็นจะต้องลงทุน และ ซื้อทุกสิ่งทุกอย่าง เพื่อช่วยให้ business มันประสบความสำเร็จ ซึ่ง DevOps ก็เช่นกัน ซื้อ DevOps กันไปเลย !! แต่เดี๋ยวก่อน DevOps มันไม่ใช่ product หรือ service ที่จะซื้อขายกันได้ ดังนั้น ต้องเริ่มต้นแนวคิดพื้นฐานของ DevOps ก่อน จากนั้นจึงเริ่มทำการปรับเปลี่ยนขั้นตอนการทำงานด้วยแนวปฏิบัติต่าง ๆ

If your company has a devops budget, you're doing devops wrong.

2. บอกว่า DevOps มันคือ software และ เครื่องมือ

อย่าเริ่มต้นด้วย software หรือ เครื่องมือ แต่ให้เริ่มจากเรื่องพื้นฐานตามข้อ 1 เราปฏิเสธไม่ได้ว่า DevOps จะประสบความสำเร็จไม่ได้เลย ถ้าปราศจาก software และ เครื่องมือต่าง ๆ เนื่องจากหัวใจหลักอย่างหนึ่งของ DevOps คือ Automation แต่เราควรรู้ว่า เมื่อไรเราจึงนำเอาเครื่องมือเหล่านั้นมาใช้งาน เราควรต้องรู้ tradeoff ของเครื่องมือ เราควรต้องรู้ความต้องการ อย่างให้เครื่องมือมาล้อมกรอบความคิดในการแก้ไขปัญหาโดยเด็ดขาด

If your company bought Chef or Puppet as a cure-all for its devops needs, you're doing devops wrong.

3. ใช้ checklist หรือ หนังสือคู่มือสำหรับการ deploy ระบบงาน

เนื่องจากหัวใจหลักอย่างหนึ่งของ DevOps คือ Automation ดังนั้นองค์กรจะพยายามเปลี่ยนขั้นตอนแบบ manual ให้เป็นแบบ Automate ให้มากที่สุดเท่าที่จะเป็นไปได้ เพื่อลดความผิดพลาดที่เกิดจากคน (Human error) รวมทั้งให้เกิดขั้นตอนการพัฒนา software ที่มีมาตรฐาน แต่จะทำให้เกิดขึ้นได้นั้น เรื่องของความเชื่อมั่นต่อระบบ ต่อคนต้องสูงในระดับหนึ่ง ถือว่าเป็นสิ่งที่ท้าทายอย่างมากสำหรับองค์กร ถ้าปราศจาคสิ่งเหล่านี้แล้ว ถึงแม้จะนำ DevOps มาใช้งาน ก็จะยังคง deploy ระบบงานเช่นเดิม นั่นคือ มีการเขียน checklistและมีหนังสือคู่มือไว้สำหรับการ deploy ระบบ มัน Automate ตรงไหนนะ !! หรือบางครั้ง เพื่อนร่วมงานอาจจะบอกว่า เราไม่มีเวลาสำหรับการ Automate หรอกนะ ส่วนนี้เรามาทำงานแบบ manual ดีกว่า มันเร็วกว่านะ แสดงว่า คุณต้องมีปัญหาอะไรสักอย่างแล้วนะ

If your company spends hours poring over checklists to ensure code is ready to be deployed, you're doing devops wrong.

4. ใช้เวลาหลายเดือน หรือ เป็นปี สำหรับการ release ระบบแต่ละรอบ !!

เป้าหมายของ DevOps คือ Automation เป้าหมายของ DevOps คือ ต้องการ release feature ใหม่ ๆ ให้รวดเร็ว เป้าหมาบของ DevOps คือ ต้องการแก้ไขความผิดพลาดอย่างรวดเร็ว แต่ถ้านำ DevOps มาใช้แล้ว แต่ยังช้าเหมือนเดิม แสดงว่า คุณเพียงแค่เปลี่ยนชื่อของการทำงานหรือไม่ ? เพื่อให้มันเป็นไปตามกระแสนิยม หรือ ความนิยมของตลาด มันต่างกับการพัฒนาในรูปแบบเดิม หรือ Waterfall อย่างไรกัน ? DevOps นั้นได้มีที่มาที่ไปจาก Continuous Integration และ Continuous Delivery/Deployment โดยหัวใจหลักของสองอย่างนี้ คือ Continuous ดังนั้น เมื่อนำแนวคิดมาใช้งานแล้ว ลองถามตัวคุณเองสิว่า คุณทำงานแบบ Continuous หรือไม่ ? เช่น ทำการ checkout/commit code บ่อยหรือไม่ ? ทำการทดสอบบ่อยหรือไม่ ? ทำการทดสอบแบบอัตโนมัติหรือไม่ ? ทำการ deploy code บ่อยหรือไม่ ? ทำการ release ระบบบ่อยหรือไม่ ?

If your company releases code changes less frequently than the harvest moon, you're doing devops wrong -- no matter how small the changes or how quickly you make them.

5. ความผิดพลาดเป็นสิ่งที่ยอมรับไม่ได้ หรือ เป็นเรื่องขอขาดบาดตาย

เมื่อเกิดปัญหา หรือ ข้อผิดพลาดขึ้นมาบน production server สิ่งที่เกิดขึ้นตามมา นั่นคือ ความหายนะของคน ปิดห้องประชุมเครียด หาคนทำผิด เพื่อต่อว่า หรือ ลงโทษ อาจจะถึงขั้นต้องไล่ออก หรือ เปลี่ยนงานกันเลย แสดงว่ามีการนำ DevOps มาใช้ในทางที่ผิดอย่างมาก สิ่งที่มันควรเป็น คือ เราต้องเรียนรู้จากความผิดพลาด ไม่ใช่มาหาคนทำผิด ไม่ใช่โยนปัญหาไปมา ให้เปลี่ยนเป็นการเรียนรู้ และ ช่วยกันหาจุดผิดพลาด จากนั้นทำการเขียน Automate test ขึ้นมา เพื่อจำลองปัญหาเหล่านั้นซะ จากนั้นทำการแก้ไขปัญหา สุดท้ายเราจะได้ Automate test เพิ่ม นั่นคือ การเพิ่มความเชื่อถือ เชื่อมั่นต่อคน และ ระบบมากขึ้นไปอีก ประเด็นหลัก คือ คุณรู้ความผิดพลาดได้รวดเร็วเพียงใด ? คุณแก้ไขความผิดพลาดได้รวดเร็วเพียงใด ? ไม่ใช่มีคน หรือ กลุ่มคนหนึ่ง ๆ มาจัดการ แต่มันคือเรื่องของทุกคน ที่ต้องช่วยเหลือกัน เมื่อใดก็ตามที่ทุก ๆ คน กลัวการ deploy ระบบขึ้น production นั่นหมายถึง คุณกำลังนำ DevOps มาใช้ในทางที่ผิดแล้วนะ

If you are no longer trusted with commit rights to production because you have made or might make a mistake, you're doing devops wrong.

6. เมื่อมีปัญหาเกิดขึ้น เราจะโยนความผิดไปให้คนอื่น (Blame organization)

แนวคิดหลักของ DevOps นั้นนำมาจาก Lean และ จะไม่ทำการโยนความผิด หรือ ความรับผิดชอบไปให้คนอื่น ๆ ซึ่งถือว่าเป็นหัวใจหลัก ๆ ของ DevOps เช่นกัน นั่นคือ มันทำให้เราไม่กลัวความผิดพลาด ลดการโยนงาน โยนความผิด เราชอบเรียกว่า การโบ้ย หรือความดีเอาใส่ตัว ความชั่วใส่คนอื่น ตัวอย่างเช่น ทีมพัฒนาทำการพัฒนาเสร็จแล้ว ทดสอบที่ developement server เรียบร้อย ทำการส่ง code ให้กับทางทีมoperation ทำการ deploy ไปยัง production server แต่ว่าไม่สามารถ deploy ได้ คำถาม จะเกิดอะไรขึ้นหลังจากนี้บ้าง ? คำตอบ ทีม operation ก็จะบอกว่า code ผิด ส่วนทีมพัฒนา ก็จะบอกว่า operation ทำการเตรียม server ต่าง ๆ ไม่ถูกหรือไม่ ? นี่แหละที่เรียกว่า Blame organization ซึ่งมันไม่ส่งผลดีกับใครเลย !! ส่วนการแก้ไขด้วยแนวคิด DevOps มันจะต่างออกไป นั่นคือทำการตรวจสอบว่า ทั้งสอง environment นั้นมันแตกต่างกันอย่างไรบ้าง ? เมื่อเจอปัญหาแล้ว จะทำการเขียนชุด Automate test ขึ้นมาทดสอบ เพื่อทำให้มั่นใจ และ แน่ใจว่า จะไม่เกิดปัญหานี้ในอนาคต หรือถ้าเกิดปัญหาเราจะรู้ต้นเหตุของปัญหาได้อย่างรวดเร็ว

If your company is firing staff simply for bringing down production, you're doing devops wrong -- regardless of any presumed role or responsibilities you attribute to those involved.

7. ทีมพัฒนา และ ทีม operation แยกกันทำงานอย่างชัดเจน (Silo)

DevOps มันมาจากสองคำ คือ Developer และ Operations ดังนั้น ถ้า developer และ operation ไม่พูดภาษาเดียวกัน ถ้า developer และ operation ไม่ทำงานด้วยกัน ถ้า developer และ operation ไม่เข้าใจซึ่งกันและกัน เป็นไปได้ยากที่การนำ DevOps มาใช้งานจะดี และ ประสบความสำเร็จดังที่ตั้งไว้ DevOps มันเน้นเรื่องของการทำงานร่วมกันอย่างมาก ทุกคนที่เกี่ยวข้องกับการพัฒนา software นั้น ๆ จะต้องมาร่วมทำงานกันเป็นทีม โดยทุกคนมีเป้าหมายของการทำงานเดียวกัน นั่นคือสร้าง software ที่มีคุณภาพ และ ช่วยทำให้ business วิ่งไปข้างหน้าและเติบโต

If your company has developers on one floor and operations on another, with code commit messages as the only means of communication, you're doing devops wrong.

It’s all about the culture

แน่นอนว่า DevOps มันไม่ได้เหมาะสมกับทุก ๆ องค์กร ทั้ง 7 ข้อนั้น คือ สิ่งที่บ่งบอก หรือ เตือนคุณว่า กำลังใช้ DevOpsใ นทางที่ผิดนะ เพื่อให้ปรับปรุง และ แก้ไขให้ดีขึ้น ให้มันเหมาะสมในแต่ละระบบ แต่ละทีม แต่ละองค์กรไป การนำ DevOps มันไม่ง่ายเลย ต้องทำงานอย่างหนัก ต้องใช้ความอดทนสูง ต้องเข้าใจคนทำงาน และแน่นอนว่า ฝั่ง business และ management ต้องเข้าใจ และ ให้การสนับสนุนด้วยนะ

Time to Main คือตัวชี้วัดที่ดีสำหรับ Continuous Integration

December 9, 2015, 6:02 am

≫ Next: มาดูความนิยมของภาษา Swift หลังจากที่เปิดเป็น Open Source

≪ Previous: สิ่งที่บ่งบอกว่ากำลังนำ DevOps ไปใช้แบบผิด ๆ

$

0

0

จากหนังสือ Beautiful Builds ทำการอธิบายเกี่ยวกับ Time to Main หรือ Time to Trunk ซึ่งเป็นสิ่งที่ใช้วัดเรื่อง Continuous Integration มาดูกันว่า Time to Main มันคืออะไร ? และมันใช้วัดอย่างไร เพื่ออะไร ? ผมคิดว่าหลาย ๆ ทีมได้นำแนวคิด Continuous Integration ไปใช้งาน หรืออาจจะสร้างระบบ Continuous Integration ขึ้นมา เพื่อทำให้ขั้นตอนการพัฒนาดีขึ้น เช่น การ build การทดสอบ เป็นต้น

คำถามที่น่าสนใจคือ

เราจะทำการวัดว่าระบบ Continuous Integration ของเรามันเป็นอย่างไร ? เราจะรู้ได้อย่างไรว่า ระบบที่กำลังพัฒนามันค่อย ๆ โตขึ้นตามเป้าหมายที่วางไว้นะ ? หลาย ๆ ที่จะต้องมีตัวชี้วัดในการทำงาน เช่น KPI (Key Performance Indicator) เพื่อช่วยให้เราไปถึงฝั่งฝัน หรือ เป้าหมายที่ตั้งไว้ เช่นเดียวกันสำหรับ Time to Main ก็เป็นหนึ่งในตัวชี้วัดที่น่าสนใจตัวหนึ่งของการพัฒนาระบบงาน

มาดูตัวอย่างของปัญหาที่ต้องได้รับการแก้ไข

โดยปกติในการพัฒนาระบบงาน ต้องมีหลายทีมทำงานร่วมกัน ระบบงานมี Architecture ที่ดีสุด ๆ จึงทำให้เกิด dependency ระหว่างทีมมากมายไปหมด แสดงดังรูป คำอธิบาย มีทีมพัฒนาในระบบนี้ 4 ทีม แต่ละทีมก็มี branch สำหรับจัดการ code ของแต่ละทีมไป โดยในการ release ระบบงานจะอยู่ที่ main branch สิ่งที่มันสนุกก็คือ ทุก ๆ ทีมจะต้องใช้ Library จากทีม NEO เสมอ ไอ้ทีม NEO มันต้องเป็น Component team สำหรับทำระบบหลักแน่ ๆ นั่นหมายความว่าทีม NEO มันคือ dependency ของทุก ๆ ทีม ยังไม่พอนะ จากนั้นทีม HAMMER จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม ORCA จากนั้นทีม ORCA จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม DRAGON จากนั้นทีม DRAGON จะทำการ update และ build binary เพื่อส่ง binary ไปให้กับทีม ADAM เมื่อทุกอย่างเรียบร้อย จึงทำการ merge code ไปยัง main branch ตามลำดับ

มาถึงตรงนี้ น่าจะพอเห็นภาพของปัญหาแล้วนะ

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

นั่นคือ เราใช้เวลานานเท่าไรกว่าจะทำการ merge code จากทุกทีมมายัง main branch ?

มาดูสถานการณ์ในปัจจุบันก่อนสิ จากรูปจะใช้เวลา Time to Main = 1 + 3 + 3 + 5 = 12 วัน ยังไม่พอต้องเผื่อเวลาในการ merge code อีกนะ เพราะว่า ถ้าระบบใหญ่ ๆ จะมี code จำนวนมาก ดังนั้นเผื่อไปอีกสัก 3 วัน สรุปแล้ว Time to Main = 15 วัน นี่ยังไม่รวมการทดสอบอีกนะ ว่าทำแบบ manual หรือ automated เมื่อเรารู้ค่าเริ่มต้น หรือ based line หรือ สถานะปัจจุบัน รวมทั้งวิธีการวัดการทำงานแล้ว

ต่อไปคือ จะแก้ไข หรือ ปรับปรุงขั้นตอนการทำงานอย่างไรดีล่ะ ?

• ทุกทีมทำงานบน main branch ไปเลยดีไหม ?
• สร้างที่เก็บ dependency library ตรงกลางดีไหม ? เมื่อมีการเปลี่ยนแปลงก็มีเก็บที่นี่แทน ใคร ๆ ก็ใช้ได้
• ลดการทดสอบแบบ manual ลงไปดีไหม ?

แต่ไม่ว่าจะวิธีการไหนก็ตาม สิ่งที่ต้องถามตัวเราเอง และ ทีมอยู่เสมอก็คือ วิธีการเหล่านั้น มันส่งผลกระทบต่อ Time to Main อย่างไรบ้าง ? ถ้ามันช่วยลดเวลาลง ก็ให้ลงมือทำในกรอบเวลาสั้น ๆ จากนั้นทำการวัดผลว่ามันช่วยปรับปรุงจริงไหม ? ยิ่งค่า Time to Main น้อยมากเท่าไร ก็ยิ่งดีใช่ไหมล่ะ

ดังนั้น Time to Main มันน่าจะเป็นอีกตัวชี้วัดหนึ่ง

ที่ช่วยให้เราเห็นว่า การทำงานของเรามีข้อจำกัด หรือ ปัญหาอะไรบ้าง ที่จะขัดขวางให้เราส่งมอบงานได้ล่าช้า ยิ่งแต่ละทีม หรือ แต่ละคนใช้เวลาบน branch ของตัวเองนาน ก็ยิ่งส่งผลต่อ Time to Main มากขึ้น ปัญหาที่ตามมาก็เยอะเช่นกัน !! ดังนั้นมาปรับปรุงกันเถอะครับ

คำถามสำหรับทีมที่นำเอา Continuous Integration มาใช้งาน เวลาของ Time to Main เป็นเท่าไรกันบ้าง ?

มาดูความนิยมของภาษา Swift หลังจากที่เปิดเป็น Open Source

December 9, 2015, 7:56 pm

≫ Next: Review Android App แบบแปลก ๆ กันหน่อย :: iTAX Pro

≪ Previous: Time to Main คือตัวชี้วัดที่ดีสำหรับ Continuous Integration

$

0

0

หลังจากทาง Apple เปิดให้ภาษา Swift เป็น Open Source ซึ่งเป็นการเปลี่ยนแปลง developer community ครั้งใหญ่เลยก็ว่าได้ ดังนั้น เรามาดูกันหน่อยว่าได้รับความนิยมอย่างไรบ้าง ?

ข้อมูลจาก Github เกี่ยวกับภาษา Swift

Swift พัฒนาด้วยภาษา C++ Repository นั้นถูก Star ไปกว่า 20,000 คน ขึ้นมาเป็นอันดับหนึ่งของ repository ทั้งหมดของ Github ที่ Active กันเลย อีกทั้งถูก fork ไปมากกว่า 2,500 ครั้ง แสดงดังรูป ส่วนอันดับรองลงมาได้แก่

• Rust
• Go
• CoffeScript
• Ruby
• PHP

เป็นยังไงบ้างสำหรับความนิยมของภาษา Swift น่าจะพอทำให้นักพัฒนาเห็นอะไรบ้างนะครับ

ลองไปดูข้อมูลจาก TIOBE Index ประจำเดือนธันวาคม 2015 พบว่า

ภาษา Swift มันแซง Objective C ไปแล้ว !! แสดงดังรูป ยังไม่พอนะ มี Swift Package Manager มาให้ใช้งาน สำหรับจัดการ library หรือ package อีกด้วย เป็น project ที่ active สุด ๆ ของภาษา Swift บน Github อีกด้วย ยังมีอีก ไปดูกันได้ว่ามี repository อะไรที่พัฒนาด้วยภาษา Swift กันได้ที่ Swift trending สุดท้ายไป Download มาใช้งานได้เลยทั้ง Mac และ Linux

Review Android App แบบแปลก ๆ กันหน่อย :: iTAX Pro

December 10, 2015, 11:46 pm

≫ Next: แนวคิดดี ๆ จากการอ่านหนังสือเกี่ยวกับ Programming

≪ Previous: มาดูความนิยมของภาษา Swift หลังจากที่เปิดเป็น Open Source

$

0

0

เห็นมีคน share iTAX pro app ที่ Facebook กันเยอะเลย ใกล้จะสิ้นปีแล้ว เรื่องของภาษีจึงสำคัญมาก ๆ นั่นเอง โดย app นี้จะเข้ามาช่วยเราวางแผน และ คำนวณการเสียภาษี รวมทั้งมีข้อมูลต่าง ๆ มากมาย มีให้ใช้งานทั้ง Android, iOS หรือ ผ่าน web ได้อีกด้วย ลองนำไปใช้งานดูครับ แต่เรามา review app นี้ในมุมมองของ developer เพื่อดูว่า app นี้เป็นอย่างไร ง่ายต่อการทดสอบแบบอัตโนมัติหรือไม่ ? มาเริ่มกันเลย

สิ่งแรกที่สะดุดตามาก ๆ คือ ชื่อ id หรือ package name ของ app นั่นเอง

ใช้ชื่อว่า com.ld.itax_pro_android ซึ่งน่าจะผิด naming convention ของการตั้งชื่อไปสักหน่อย ต่อมาขนาดของ app ประมาณ 13 MB ซึ่งถือว่าไม่ใหญ่ ใช้เวลาในการ download ไม่นาน สบาย ๆ ส่วนจำนวนของ Activity ไม่เยอะเพียง 6​ Activity เท่านั้น แสดงว่ามีการใช้ Fragment นั่นเอง !!

จากนั้นมาดูกันหน่อยว่า app นี้ใช้ library อะไรกันบ้าง ?

• Dagger
• Retrofit
• OKIO
• Butterknife สำหรับการ binding view ด้วย Annotation
• Bolts
• Icepick สำหรับการจัดการ state ต่าง ๆ ของ Android
• ReLinker สำหรับการ load library ต่าง ๆ
• Fabric ซึ่งหลัก ๆ ใช้ crashlytics
• ใช้ Yahoo Flurry สำหรับเก็บผลเกี่ยวกับ Analytics เอาไว้ดูเรื่อง User eXperience

มาเริ่มใช้งาน app กันดีกว่า

หน้าแรก คือ หน้า Login

แสดงดังรูป ประกอบไปด้วย

• 43 elements เยอะใช้ได้สำหรับหน้า login
• การตั้งชื่อเป็นแบบ Snake case เช่น custom_edit_text_style_ios_edit_text เป็นต้น แต่มี Camel case ปะปนมา 1 ตัวคือ disableIcon
• รูปแบบของชื่อแต่ละ element คือ name_type อ่านง่ายดีครับ
• แต่ Font ที่ใช้ใน app มันไม่ชัดเลย ถ้าปรับจะแจ่มมาก ๆ

หลังจากทำการ login และ ใส่ข้อมูลเริ่มต้นแล้วจะเข้ามาหน้าหลัก

แสดงดังรูป ประกอบไปด้วย

• 70 elements
• เป็นหน้าหลักของการวางแผนจ่ายภาษี ประกอบไปด้วย
  • income_button คือ รายได้
  • deduct_button คือ ลดหย่อน
  • planing_button คือ วางแผน
  • summary_button คือ สรุป
• การตั้งชื่อของแต่ละ element ยังคงเหมือนเดิม มีผิดนิดหน่อยคือ planing_button น่าจะเป็น planning_button
• ปัญหาหลักที่เจอหน้านี้ คือ เมื่อกดตรงสิทธิ์ลดหย่อนไป และ รูปแถบ progress พบว่า app จะปิดตัวเองบ่อยมาก ๆ

หน้าต่อไปที่ลองทดสอบ คือ หน้ากรอกข้อมูลรายได้ (Income)

แสดงดังรูป ประกอบไปด้วย 116 elements ที่เยอะเพราะว่า แถบเมนูด้านล่างนั่นเอง

ปัญหาที่พบคือตรง ? มุมขวาบน เมื่อเข้าไปแล้วพบว่า App มัน crash ไปเลย !!

เมื่อกดปุ่มเช็คเงื่อนไขแบบละเอียด เมื่อไปดูใน log พบว่าปัญหาคือ ActivityNotFoundException เนื่องจาก app ต้องการใช้ Google Play Service นั่นเอง แต่ emulator สำหรับการทดสอบไม่ได้ทำการติดตั้ง รวมทั้งกับ app ไม่ได้ทำการตรวจสอบไว้เช่นกัน แสดงดังรูป

จากนั้นทำการกรอกข้อมูลรายได้ที่มาจากเงินเดือน

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

• 74 elements
• โดยชื่อของ element เงินเดือนชื่อว่า income_salary_salary ซึ่งน่าจะเป็น income_from_salary
• โดยชื่อของ element ค่าจ้างทั่วไปชื่อว่า income_salary_freelance ซึ่งน่าจะเป็น income_from_freelance
• ในการกรอกข้อมูลรายได้นั้น จะทำการ custom keyboard ขึ้นมาเอง มี element ดังต่อไปนี้
  • btnDone
  • btn0, btn1 ไปจนถึง btn9
• ซึ่งการตั้งชื่อจะขัดแย้งกับการตั้งชื่อในส่วนอื่น ๆ ทั้งหมดเลย !!
• การ custom keyboard ทำให้กรอกข้อมูลผ่าน Automate test ยากนิดหน่อยเพราะว่า ต้องทำการกรอกทีละตัว

แสดงดังรูป

โดยรวมแล้วเป็น App ที่น่าใช้งาน และ มี UI ที่เรียบง่าย สบายตา

แต่มีปัญหาเกี่ยวกับการจัดการ State ของ app เช่นการกดปุ่ม back (ไม่มีใครกดแล้วมั้ง !!) โดย app มันจะขึ้น popup ถามว่า ต้องการปิดโปรแกรมใช่มั้ยคะ ตลอดเลย น่าจะเป็นเพราะว่าใช้ Fragment ทำให้การจัดการ state ยากขึ้น !! แสดงดังรูป กับเมนูต่าง ๆ อยู่ด้านล่าง ซึ่งไม่เหมาะเท่าไรสำหรับ Android app แต่ขอเดาว่า น่าจะมี template มาจาก iOS app ซึ่งไม่อยากให้หน้าตาของ app มันต่างกันมากนัก ดังจะเห็นได้จาก UI ที่พยายาม custom ให้เหมือน หรือ คล้าย iOS app ให้มากที่สุด คิดว่าตอนเขียน Custom UI น่าจะสนุกมาก ๆ เพราะว่า Custom ทั้ง app เลย

เกี่ยวกับ Logging ต่าง ๆ พบว่า

มี Log message ออกมาจาก Retrofit เยอะมาก ๆ หนึ่งในนั้นก็คือ Response ของแต่ละ request ซึ่งคิดว่า ไม่น่าจะพ่น log message พวกนี้ออกมาจาก app นะครับ แสดงดังรูป

กับอีกเรื่องที่เจอบ่อย ๆ คือ เมื่อเปิด app ขึ้นมาอีกครั้งจะรอการ Sync นานมาก ๆ

ทำให้การทดสอบแบบอัตโนมัติ fail ได้ง่าย แสดงดังรูป สาเหตุน่าจะมาจากการไปเรียกข้อมูลล่าสุดจาก server ปัญหามาจากเรื่อง Certified SSL นั่นเอง ไม่แน่ใจเป็นปัญหาเพราะว่า ผมใช้ผ่าน emulator หรือเปล่า แสดง log การดึงข้อมูลจาก server ดังรูป

ปิดท้ายด้วยเขียน Automated Acceptance Test ด้วย Calabash for Android นิดหน่อย

เป็น flow การ login เข้ามาเพื่อกำหนดหน้ารายได้ (Income) กำหนดค่าลดหย่อนนิดหน่อย ปิดท้ายไปหน้าสรุป (Summary) ดังนี้

จากการทดสอบเขียน Automated test ของ app ด้วย Calabash พบปัญหาดังนี้

• สามารถเขียนได้ไม่ยากเท่าไร แต่ในการเปลี่ยนหน้าจอนั้น ต้องทำการ delay การทดสอบเพื่อให้หน้าจอ render ให้ครบก่อน
• ข้อตกลงในการตั้งชื่อดี เป็นไปในทิศทางเดียวกัน มีเพียง Custom Keyboard เท่านั้นที่แตกต่าง
• ปัญหาเรื่องของการจัดการ state ของ Android app กับ Fragment
• การแสดง log ต่าง ๆ ออกมาทาง console เยอะมาก โดยเฉพาะจาก Retrofit
• ในหน้าแรกของ app มีการ sync ข้อมูลกับทาง server ตลอด ซึ่งก่อให้เกิดปัญหาบ้าง
• ส่วนของเมนูอยู่ด้านล่าง อาจจะงง ๆ เล็กน้อยสำหรับคนใช้งาน Android ซึ่งเอาตัวผมเองเป็นตัววัด !!

ส่วน Script ของ Automated Script อยู่ที่นี่ Gist::iTax Pro with Calabash Android

แนวคิดดี ๆ จากการอ่านหนังสือเกี่ยวกับ Programming

December 11, 2015, 7:13 pm

≫ Next: Test Automation มันแย่ เลิกเถอะ !!

≪ Previous: Review Android App แบบแปลก ๆ กันหน่อย :: iTAX Pro

$

0

0

จากการอ่านหนังสือเกี่ยวกับ Programming พบว่ามันคือส่วนหนึ่งของการเรียนรู้สิ่งใหม่ ๆ และเน้นย้ำสิ่งที่เรารู้และ เข้าใจมาแล้ว หรืออาจจะหลง ๆ ลืม ๆ ไปบ้าง ไม่ว่าจะเป็นหนังสือกระดาษ หรือ E-book ก็เป็นส่วนหนึ่งของการเรียนรู้ทั้งนั้น ดังนั้นจึงสรุปเทคนิคง่าย ๆ ของการอ่านหนังสือ Programming ไว้นิดหน่อย

1. อ่านให้ช้าลง ทำความเข้าใจให้มากขึ้น ลึกซึ้งขึ้น มันทำให้เราใช้ความจำน้อยลง

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

2. ให้ทำแบบฝึกหัดต่าง ๆ และจดบันทึกลงกระดาษ

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

3. อ่านหนังสือก่อนนอน

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

4. พูดและอธิบายให้คนอื่นฟัง

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

5. ฟังเสียงจากสมองของคุณบ้าง !!

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

6. ลงมือทำด้วยมือคุณเอง

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

สุดท้ายกินน้ำ และ พักผ่อนเยอะ ๆ ครับ

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

Test Automation มันแย่ เลิกเถอะ !!

December 12, 2015, 11:53 pm

≫ Next: แบ่งกลุ่มการทดสอบด้วยขนาดดีกว่านะ  Small, Medium, Large

≪ Previous: แนวคิดดี ๆ จากการอ่านหนังสือเกี่ยวกับ Programming

$

0

0

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

เนื่องจากระบบงานต้องทำงานตลอด 24 ชั่วโมง

แน่นอนว่า ต้องมีคนคอย support ตลอดเวลา บ่อยครั้งที่ระบบจะมีปัญหาช่วงกลางดึก (บ่อยมาก ๆ ) แถมชอบเกิดขึ้นช่วงวันหยุดอีกด้วย สรุปได้เลยว่า งานแม่ง ..... มากมาย !! ดังนั้นจึงนำเอา Test Automation มาช่วยทดสอบระบบทุก ๆ ชั่วโมง ซึ่งเป็น Functional หรือ UI testing นั่นเอง เพื่อช่วยตรวจสอบว่า ระบบยังคงทำงานได้อย่างถูกต้องตามที่คาดหวังหรือไม่ แต่ว่ามีอยู่วันหนึ่งช่วงกลางดึก Test Automation ทำการแจ้งบอกว่าการทดสอบมัน fail แต่เมื่อทีม support เข้ามาตรวจสอบ และทดสอบใช้งานระบบแล้ว พบว่าระบบไม่มีปัญหาแต่อย่างใด ซึ่งเกิดเหตุการณ์แบบนี้บ่อยมาก ๆ บรรดาหัวหน้าทีม และ manager ต่าง ๆ จึงสรุปปัญหาได้ดังนี้

• ระบบ Test Automation มันไม่เสถียร
• ระบบ Test Automation มันทำงานผิดพลาดตลอด
• มันไม่ยุติธรรมต่อทีม support ที่ต้องตื่นมาตรวจสอบปัญหาเหล่านี้ ทั้ง ๆ ที่มันไม่มีปัญหา

ทำให้ได้ข้อสรุปของการแก้ไขปัญหา คือ ปิดการทำงานของ Test Automation ซะเถอะ !!

แต่เดี๋ยวก่อนนะ เรามาหาความจริงกันหน่อยดีไหม ?

ระบบ Test Automation มันไม่เสถียร ?

จากการพูดคุยในรายละเอียดพบว่า ใช้ Selenium WebDriver สำหรับการทดสอบ โดยผลจากการทดสอบพบว่า บางหน้าใช้เวลาในการดึงข้อมูลมาแสดงผลมากกว่า 10 วินาที !! ซึ่ง Test Automation ที่สร้างไว้ก็รอไปเรื่อย ๆ จนสุดท้ายก็ยังดึงข้อมูล และ แสดงผลไม่เสร็จ คำถามที่เกิดขึ้นมาก็คือ ปัญหาแบบนี้มันคือ Test Automation มันไม่เสถียร หรือ ระบบงานมันไม่เสถียรกันแน่ ? ซึ่งข้อมูลที่ใช้มีทั้งรูปภาพที่ capture ไว้ พร้อม VDO แต่ไม่นำมาใช้งาน และ นำมาวิเคราะห์กัน คำถามที่ถามกลับไปยังทีมคือ เรายอมรับให้ระบบงานใช้เวลาดึงข้อมูลนานเกิน 10 วินาทีกันเลยใช่ไหม ? คำตอบที่ได้รับกลับมาก็คือ ใช่แล้ว !!

ลองคิดดูสิว่า ลูกค้า หรือ ผู้ใช้งานระบบจะรอไหมนะ ? อาจจะมีแต่น้อยหรือเปล่านะ

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

ระบบ Test Automation มันทำงานผิดพลาดตลอด !!

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

• เพิ่ม Timeout ไปสิ
• ใส่การ retry ไปสิ

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

ดังนั้นไปแก้ไขปัญหาที่ต้นเหตุได้แล้ว

มันไม่ยุติธรรมต่อทีม support ที่ต้องตื่นมาตรวจสอบปัญหาเหล่านี้ ทั้ง ๆ ที่มันไม่มีปัญหา

ตอบได้เลยว่า ใช่แล้ว ไม่มีใครอยากตื่นกลางดึก เพื่อมาแก้ไขปัญหาจากสิ่งที่ตนเองไม่ได้ทำหรอกนะ แต่มันต้องทำ เพราะว่าเป็นงานที่ถูกจ้างมานั่นเอง แน่นอนว่า มันทำให้สุขภาพย่ำแย่ มันทำให้เราโกรธ แต่ควรไปลงที่ปัญหาจริง ๆ สิ ไม่ใช่ไปลงที่ Test Automation ปัญหาจริง ๆ คืออะไรบ้าง ? เขียน code ได้แย่ เขียน test ได้ห่วย Server ห่วย Network แย่

สุดท้ายแล้ว ก่อนจะเลิกใช้งาน Test Automation

ช่วยคิด วิเคราะห์ แยกแยะก่อนว่า

• วิธีการ และ เครื่องมือที่นำมาใช้สร้างนั้น มันเหมาะสม หรือ มีปัญหาหรือไม่ ?
• ต้องทำการพิสูจน์ให้ได้ว่า Test Automation มันแย่ หรือ ไม่แย่ ช่วย หรือ ไม่ช่วย ดี หรือ ไม่ดี ?
• ถ้า Test Automation มันทำงานถูกต้องของมันแล้ว ดังนั้น สิ่งต่อไปที่ต้องแก้ไขคือ การแก้ไขระบบ และ code นั่นเอง
• ทาง Manager ของคุณอาจจะไม่เห็นด้วยกับคุณ แต่สิ่งที่คุณทำได้ก็คือ นำข้อมูลต่าง ๆ ออกมาเพื่อสนับสนุนเหตุผลของคุณให้ได้มาก และ ดีที่สุด ว่าสาเหตุที่แท้จริงมันเกิดมาจากอะไร

สุดท้ายควรจะต้อง Test early, Test often นะครับ เพื่อป้องกันไม่ให้เกิดเหตุการณ์แบบนี้กัน หรือถ้าเกิดขึ้นเราจะรู้ได้ตั้งแต่เนิ่น ๆ ไม่ใช่มารู้กันบน production

---

แบ่งกลุ่มการทดสอบด้วยขนาดดีกว่านะ  Small, Medium, Large

December 14, 2015, 12:12 am

≫ Next: Feature ที่ถูกเอาออกไปจาก Elasticsearch 2.x

≪ Previous: Test Automation มันแย่ เลิกเถอะ !!

$

0

0

คำถาม เราทำการเรียกชื่อของการทดสอบผ่าน User Interface (UI) ของระบบว่าอะไร ? คำตอบที่ได้มันจะหลากหลายมาก ๆ ไม่ว่าจะเป็น

• UI test
• End-to-End test
• Acceptance test
• Functional test
• System test
• Web test
• Selenium test

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

จากปัญหาเหล่านี้นี่เองทาง Google Testing จึงได้เสนอว่า งั้นแบ่งกลุ่มตามการทำงานดีไหม ?

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

1. Small
2. Medium
3. Large

ในแต่ละกลุ่มทำการจัดแบ่งด้วยข้อมูลต่าง ๆ ซึ่งเราสามารถใช้เพื่อสรุปได้ว่า การทดสอบของเรานั้นอยู่ในกลุ่มไหน ทำให้เราเข้าใจได้ชัดเจนมากยิ่งขึ้น ทั้งรูปแบบการทดสอบ ไม่ว่าจะผ่านหรือไม่ผ่านระบบ Network ไม่ว่าจะใช้หรือไม่ใช้ Database รวมทั้งเวลาที่ใช้ในการทดสอบ ซึ่งเราสามารถเปลี่ยนให้เข้ากับระบบได้อีกด้วย แสดงดังรูป แน่นอนว่า ตารางนี้อาจจะไม่ครบทุกการทดสอบ แต่คิดว่า น่าจะครอบคลุมในการทดสอบส่วนใหญ่ของระบบต่าง ๆ ตอนนี้น่าจะทำให้เราสามารถกำหนด DEFINITION หรือ คำจำกัดความของการทดสอบได้ง่าย และ ตรงกันแล้วนะ และน่าจะช่วยปรับปรุงเรื่องการพูดคุยของคนในทีม และ องค์กรมากขึ้น !! ดังนั้น Small test น่าจะเป็นพวก Unit test เป็นการทดสอบที่ใช้เวลาน้อย ไม่ทำการใช้งานระบบ Network และ Database Medium test น่าจะเป็นพวก Integration test ทำการทดสอบภายในระบบเดียวกัน Large test น่าจะเป็นพวก End-to-End test, UI test ทำการทดสอบกับระบบภายนอก ใช้งานผ่านระบบ Network และ Database

ถามว่าแล้วมีที่ไหนแบ่งกลุ่มการทดสอบเป็นแบบนี้บ้างล่ะ ?

เท่าที่เห็น และ ใช้งานมาก็มีใน JUnit 4 ใน Android ซึ่งจะมี Annotation ให้ใช้ คือ

• @Small
• @Medium
• @Large

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

Feature ที่ถูกเอาออกไปจาก Elasticsearch 2.x

December 18, 2015, 1:51 am

≫ Next: สรุปสิ่งที่ได้รับและแบ่งปันจาก 2 meetup ใน 1 สัปดาห์

≪ Previous: แบ่งกลุ่มการทดสอบด้วยขนาดดีกว่านะ  Small, Medium, Large

$

0

0

เนื่องจาก Elasticsearch นั้นออก version 2.x มาแล้ว โดยตอนนี้ถึง 2.1 แล้วนะ รู้ยัง ? ดังนั้น ถ้าใครยังใช้ 1.x และต้องการจะย้ายมายัง 2.x จำเป็นต้องรู้ว่ามีการเปลี่ยนแปลงอะไรบ้าง หนึ่งในนั้นคือ feature ที่ถูกเอาออกไป มาดูกันว่ามีอะไรบ้าง ?

1. River

จากก่อนหน้านี้คือ 1.7 ได้ทำการแจ้ง deprecated feature นี้ไปแล้ว ดังนั้นใน 2.x จึงเอาออกไปโดยปริยาย ซึ่งถ้าใครยังใช้ river อยู่ก็ต้องคิดให้ดี ๆ

2. Facet

เนื่องจาก Facet เป็น API ที่ deprecated มานานแล้ว ซึ่งไม่ได้ทำการพัฒนาต่อเลย เนื่องจากไม่สามารถพัฒนาหรือเพิ่มความสามารถอะไรได้ ตลอดจนเรื่องประสิทธิภาพในการทำงาน ดังนั้น แนะนำให้ไปใช้ Aggregation API แทน ซึ่งมีความสามารถที่ดี มีประสิทธิภาพที่ดี และ ยืดหยุ่นมาก ๆ จากการใช้งาน Elasticsearch มายังไม่เคยใช้งาน Facet เลย ยกเว้นคนที่เคยชินกับการใช้ Facet จาก Apache Solr เท่านั้น

3. MVEL เป็น default scripting language

ทำการเปลี่ยนเป็นภาษา Groovy แทนแล้ว

4. Delete by query กลายเป็น plugin

สำหรับใครที่เขียน Query DSL สำหรับลบข้อมูล ตอนนี้ทำไม่ได้แล้ว เนื่องจากได้ลบ feature ออกไปแล้ว เนื่องจากเป็น feature ที่ส่งผลต่อการทำงาน เช่น out of memory และ ทำให้ Elasticsearch พังได้ แต่ถ้าต้องการใช้ ก็สามารถใช้ได้ ด้วยการติดตั้ง plugin แทน สรุปคือเปลี่ยนไปเป็น plugin แทนนะ

5. Multicast dicovery กลายเป็น plugin

Elastic search 2.x นั้นใช้ unicast เป็นค่า default ส่วน multicast ถูกเอาออกไปเป็น plugin แทน มีสาเหตุมาจาก

• Linux ไม่อนุญาตให้ทำงานแบบ multicast บน localhost
• บาง network ไม่อนุญาตการทำงานแบบ multicast

6. _Shutdown API ถูกเอาออกไป

7. Bulk API แบบ UDP เอาออกไปแล้ว

ดังนั้นไปใช้ Bulk API ปกตินะ ดังนั้นก่อนจะย้ายไปใช้ Elasticsearch 2.x ก็ควรจะตรวจสอบสิ่งที่ใช้งานก่อนว่าส่งผลกระทบอะไรหรือไม่ ? Reference Websites https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_removed_features.html

สรุปสิ่งที่ได้รับและแบ่งปันจาก 2 meetup ใน 1 สัปดาห์

December 19, 2015, 9:01 pm

≫ Next: แนะนำแหล่งข้อมูลดี ๆ สำหรับการใช้งาน Docker ร่วมกับ Jenkins

≪ Previous: Feature ที่ถูกเอาออกไปจาก Elasticsearch 2.x

$

0

0

ในสัปดาห์นี้ได้เข้าร่วมแบ่งปัน 2 meetup ประกอบไปด้วย งานจากกลุ่ม Thailand PHP User Group จัดที่ Kaidee.com และงาน How The Geek Become Great Entrepreneur ? จัดโดย FiveLoop ที่ NE8T จึงได้ทำการสรุปสิ่งที่ได้รับและแบ่งปันดังนี้

Meetup จากกลุ่ม Thailand PHP User Group

แบ่งปันเรื่อง Continuous Delivery(CD) with PHP ซึ่งแบ่งปันความเข้าใจในเรื่อง CD คืออะไร CD เป็นอย่างไร โดยไม่ได้พูดในเรื่องของเครื่องมือใด ๆ ทั้งสิ้น สิ่งที่สำคัญคือ ต้องสร้างความสมดุลระหว่างความเร็วกับคุณภาพด้วย เนื่องจากส่วนใหญ่มักเลือกความเร็วมาก่อนคุณภาพ ผลที่ได้คืออะไรล่ะ ? พังนะสิ !! รวมทั้งสรุปสิ่งที่ได้เรียนรู้จากการลงมือทำ และ ความผิดพลาดต่าง ๆ มีดังต่อไปนี้

1. ต้องใช้ Version Control สำหรับจัดการทุกสิ่งอย่าง ไม่ใช่เพียง source code เท่านั้นนะ
2. ต้องพร้อมสำหรับการ deploy และ release ไปยัง production server เสมอ
3. ต้องทำการ deploy แบบอัตโนมัติ ( deploy ไม่เท่ากับ release นะครับ )
4. เรื่องของ Feedback loop มันสำคัญมาก ๆ ยิ่งรับรู้ผลได้เร็วยิ่งดี ยิ่งได้รับรู้บ่อยยิ่งดี
5. ควรต้องรู้การทำงานภายในของระบบอย่างดี คำถามง่าย ๆ เรารู้ว่าระบบมีปัญหาจากลูกค้าหรือไม่ ?
6. เราไม่สามารถ automate โดยปราศจากเรื่องของคุณภาพไปได้ ดังนั้น คุณภาพต้องออกมาจากคน จากวัฒนธรรม ไม่ใช่จากการถูกบังคับ

ดู Slide เพิ่มเติมได้จากที่ SlideShare [slideshare id=56199743&doc=php-meetup-continuous-delivery-151216113820&w=600&h=400] ส่วนเรื่องที่ได้รับจาก meetup ครั้งนี้เยอะมาก ๆ แต่เท่าที่จำได้ประกอบไปด้วย เรื่องของ Automated Acceptance Test ด้วย Behat ซึ่งมีรูปแบบการเขียนเหมือนกับ Cucumber และรูปแบบของการเขียน specification หรือ ขั้นตอนการทำงาน คือ Given-When-Then หรือ Gherkin นั่นเอง และต้องเขียน step definition หรือ FeatureContext เพื่อจับคู่การทำงาน ผ่านการ comment แบบ Java Document คำถามที่น่าสนใจ คือ เมื่อเปรียบเทียบกับ Robot Framework แล้วเป็นอย่างไร ?? เรื่องโครงสร้างการทำงานผ่าน Messaging server ชื่อว่า Beanstalk เป็นอีกตัวที่ไม่เคยรู้จักเลย โดยใช้งานด้วยภาษา PHP ผ่าน library ชื่อว่า Pheanstalk และเมื่อได้ดูการ demo การใช้งานมันก็น่าสนใจเพิ่มขึ้นอีก การทำ Messaging server มาคั่นการทำงานเพื่อ ช่วยให้ระบบสามารถรองรับการขยายตัวผู้ใช้งานได้ดี ปิดท้ายด้วยเรื่อง Docker จากทางทีมของ Kaidee.com น่าจะเป็นครั้งแรกที่ได้ฟังเรื่องเกี่ยวกับการนำ Docker มาใช้บน production เนื่องจากก่อนหน้านั้น เคยใช้งานเพียงเครื่อง development เท่านั้น ซึ่งแน่นอนว่า ได้รับความรู้ และ ความมึนงงพอ ๆ กัน เนื่องจากจะลงรายละเอียด และ รูปแบบการนำไปใช้งานจริง ๆ ซึ่งคงต้องไปศึกษาเพิ่มเติมอีกมาก และได้แนวทางในการศึกษาที่ดีมาก ๆ

Meetup จากงาน How The Geek Become Great Entrepreneur ?

มีโอกาสให้ไปแบ่งปันความคิดเห็นในหัวข้อวิกฤติของ programmer และ จะแก้ไขกันอย่างไรดี ? โดยผมพยายามนำเสนอมุมมองจากภาคส่วนต่าง ๆ ไม่ว่าจะเป็นจากมุมมองของ programmer ที่มองสายอาชีพตัวเอง ไม่ว่าจะเป็นจากการพูดคุยใน Social Network ไม่ว่าจะเป็นจากภาคการศึกษา ไม่ว่าจะเป็นจากองค์กร และ บริษัทต่างๆ เพื่อให้เห็นว่า เรามักจะหาคนผิด !! เพื่อให้เห็นว่า เรามักจะโทษกันไปมา !! ดังนั้นให้ทุกภาคส่วนควรมาร่วมมือกันเพื่อหาทางออกที่ดีกว่าหรือไม่ ? programmer คุณเลิกมองว่าตัวเองคือ กรรมกร IT ได้แล้ว และ ปรับปรุงให้ดีขึ้น องค์กร และ บริษัท ทำอย่างไรเพื่อรักษาคนไว้ ไม่ใช่ทำร้ายคน องค์กร และ บริษัท ถ้าอยากได้คนแบบไหน จากส่วนใด น่าจะลงเข้าไปช่วย หรือ บอก spec ดีกว่าไหม ส่วนของการศึกษาน่าจะปรับปรุง และ เข้ามาดูโลกความจริงกันหน่อยไหม แล้วคุณล่ะ คิดว่า มันวิกฤติจริง ๆ ไหม ? ดู Slide เพิ่มเติมได้จากที่ SlideShare [slideshare id=56300191&doc=meetup-crisis-programmer-151219151831&w=600&h=400] และยังมีเรื่องอื่น ๆ ที่น่าสนใจอย่างมากจากอาจารย์ Dave Rawitat และ อาจารย์ Teepakorn เช่นแนวคิดต่าง ๆ จากการเป็น mentor ของเหล่า Startup ต่าง ๆ และประสบการณ์ที่ล้มลุกคลุกคลานจนมีวันนี้ได้ ซึ่งได้ความรู้ ข้อคิด และ ประสบการณ์อย่างมากมาย มีผู้ร่วมงานทำการสรุปไว้ดีมาก ๆ ลองอ่านกันดูที่ สรุปข้อคิดจากงาน How the geek become great entrepreneur ?

แนะนำแหล่งข้อมูลดี ๆ สำหรับการใช้งาน Docker ร่วมกับ Jenkins

December 19, 2015, 9:50 pm

≫ Next: ทำความรู้จัก Backend For Frontends (BFF) กัน

≪ Previous: สรุปสิ่งที่ได้รับและแบ่งปันจาก 2 meetup ใน 1 สัปดาห์

$

0

0

ไม่ได้เข้า website ของ Jenkins มานาน พบว่า ได้ทำการเพิ่มข้อมูลที่น่าสนใจ คือ การทำงานร่วมกับ Docker ขึ้นมา ประกอบไปด้วย

• Blog
• Presentation/VDO
• Docker plugin for Jenkins

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

ทำความรู้จัก Backend For Frontends (BFF) กัน

December 21, 2015, 3:32 am

≫ Next: สิ่งแย่ ๆ ที่ Programmer ควร ลด ละ เลิก ได้แล้ว

≪ Previous: แนะนำแหล่งข้อมูลดี ๆ สำหรับการใช้งาน Docker ร่วมกับ Jenkins

$

0

0

จาก ThoughtWorks Technology Radar นั้น มีเทคนิคที่น่าสนใจ คือ BFF (Backend For Frontends) เนื่องจากในปัจจุบันระบบงาน จำเป็นต้องสนับสนุน client มากมาย ไม่ว่าจะเป็น web browser, mobile และ embedded system จากเดิมเราจะทำการสร้าง Backend APIs เพียงตัวเดียวสำหรับทุกอย่าง แต่เรากลับลืมไปว่าแต่ละ client นั้น มีหลายสิ่งที่แตกต่างกันทั้ง hardware, performance และขนาดของ network ดังนั้น สิ่งที่เราควรจะทำก็คือ แยกBackend APIs ตามชนิดของ client ซึ่งถูกเรียกว่า Backend For Frontends (BFF) นั่นเอง

จาก blog เรื่อง BFF ของระบบ SoundCloud

อธิบายประสบการณ์จากการการเปลี่ยนแปลงโครงสร้างของระบบ มาดูกันว่าเป็นอย่างไรบ้าง ? แต่ก่อนโครงสร้างระบบ SoundCloud นั้น จะสร้าง APIs เดียวสำหรับใช้งานจากทั้ง Web, Android และ iOS แสดงดังรูป

แต่ปัญหาเริ่มเกิดขึ้นเมื่อระบบใหญ่ขึ้นและมีจำนวน feature มากขึ้น

ส่งผลให้ต้องใช้เวลาในการพัฒนาสูงเพิ่มขึ้นอย่างมาก !! ทั้ง Web, Android และ iOS ต่างต้องการใช้ APIs ที่แตกต่างกัน เนื่องจาก Mobile ต้องการข้อมูลที่เล็ก และ เร็ว มีจำนวนการใช้งานที่สูงกว่า มีขนาดของ network ที่จำกัดกว่า ดังนั้นจึงต้องเกิดการเปลี่ยนแปลงขึ้นมา แต่สิ่งที่ยากก็คือ ทั้งฝั่ง Frontend และ Backend ต้องคุยกันอย่างมาก และปัญหาจะเริ่มมากขึ้นในฝั่ง Backend เนื่องจากการสร้าง APIs ใหม่ ๆ มารองรับการใช้งานจากทางฝั่ง Frontend บนระบบเก่าที่มันทำทุกสิ่งทุกอย่าง ดังนั้นวิธีการแก้ไขที่ง่าย และ ได้ผลมาก ๆ คือ สร้างส่วนการทำงานใหม่ขึ้นมาสำหรับผู้ใช้งานกลุ่มหรือชนิดนั้น ๆ ไปเลย ซึ่งตอนนี้ BFF ได้เริ่มถือกำเนิดมาแล้ว !! แสดงดังรูป เห็นไหมว่า เราได้ทำการเพิ่ม layer การทำงานใหม่ขึ้นมา เพื่อแก้ไขปัญหาที่เราพบเจอ แต่มันก็คือการสร้างปัญหา N+1 ขึ้นมาเช่นเดียวกัน รวมทั้งก่อให้เกิดปัญหาอีกมากมาย เช่น ทีมฝั่ง Backend จะมีงานที่เยอะมากขึ้น งานเข้าเยอะนะสิ !! ดังนั้น ฝั่ง Frontend จำเป็นต้องเขียน Backend ด้วย แต่ฝั่ง Backend นั้นต้องเขียนง่าย ๆ เล็ก ๆ ไม่ยาก รวมทั้งต้องมีระบบ Monitoring, Alert และ Authentication ด้วยนะ ทำให้เกิดมาตรฐานที่เหมาะสมกับ BFF ของแต่ละระบบนั่นเอง

เมื่อเราทำการสร้าง BFF สำหรับ API ต่าง ๆ ได้แล้ว มันมีประโยชน์ดังนี้

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

• แยกการทำงานออกเป็นส่วน ๆ
• เพื่อความสามารถต่าง ๆ เข้าไปได้ง่าย
• สามารถ share library ได้ง่าย
• สามารถ deploy ได้ง่าย
• ลดผลกระทบจากการเปลี่ยนแปลงต่าง ๆ

ในปัจจุบันสถาปัตยกรรมของ SoundCloud ได้พัฒนาและปรับปรุงมาเยอะมาก ๆ

ซึ่งมีกฎที่น่าสนใจอยู่ว่า จะใช้ share library เมื่อ library ชุดนั้นมันไม่ทำการเปลี่ยนแปลง แต่ถ้ายังทำการเปลี่ยนแปลงบ่อย ๆ แนะนำให้ใช้งานผ่าน service แทน และให้เน้นไปที่ feature และการใช้งานของผู้ใช้งานเป็นหลัก ก่อนที่จะไปมองว่าจะ reuse หรือลด duplication อย่างไร แสดงดังรูป

โดยสรุปแล้ว BFF มันเป็นแนวทางที่ดี

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

สิ่งแย่ ๆ ที่ Programmer ควร ลด ละ เลิก ได้แล้ว

December 22, 2015, 1:50 am

≫ Next: มาช่วยกันทำให้การพัฒนา software ปลอดภัยมากขึ้น

≪ Previous: ทำความรู้จัก Backend For Frontends (BFF) กัน

$

0

0

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

Bad :: เขียน code ที่ต้องการ comment

เคยไหมที่ต้องเขียน code และต้องเขียน comment เพื่ออธิบาย code เหล่านั้นอีก !! ดังนั้น ถ้าเกิดเหตุการณ์แบบนี้ แนะนำให้เรียนรู้ และ เพิ่มความสามารถเรื่อง

• การ refactoring code แบบ step-by-step
• การดูว่า bad code หรือ code แย่ ๆ เป็นอย่างไร
• เทคนิคในการออกแบบระบบที่ดี

Bad :: ยังทดสอบแบบ manual เป็นหลักกันอยู่

ดังนั้นสิ่งที่ต้องทำ คือ ทำการเรียนรู้ และ นำ unit test มาใช้ หนึ่งในวิธีการคือ TDD (Test-Driven Development)

Bad :: เข้ารหัสชื่อตัวแปร method และ class

ชื่อต่าง ๆ ที่เราตั้งขึ้นมา ชอบเข้ารหัส ชอบย่อ ดังนั้นจึงก่อให้เกิดการ comment code !!

Bad :: ทำสิ่งเดิม ๆ มาหลายปี

ดังนั้นให้เรียนรู้สิ่งใหม่ ๆ ทุกปี ดังนั้นให้เรียนรู้ภาษา programming ใหม่ ๆ ทุกปี ลองถามตัวคุณเองว่าเป็นอย่างไร ?

Bad :: มีขั้นตอนการทำงานแบบ manual และก็ทำซ้ำ ๆ อยู่เรื่อยไป

คล้าย ๆ กับการทดสอบแบบ manual เช่น การเลื่อน mouse ไปกดปุ่ม build อยู่บ่อยครั้ง การตรวจสอบข้อมูลใน log file ซึ่งสิ่งที่ทำซ้ำ ๆ แบบนี้ น่าจะสร้างระบบขึ้นมาช่วยเหลือดีไหม ? ให้มันทำงานแบบอัตโนมัติดีกว่า แล้วเอาเวลาที่เหลือไปทำอย่างอื่นที่สำคัญกว่า

Bad :: เขียน class และ method ที่มีขนาดใหญ่

Programmer ส่วนใหญ่มักจะทำแบบนี้อยู่อย่างเสมอ เรามักจะได้ยินพวก

• God class
• Fat controller
• Massive controller
• Fat service

และอื่น ๆ อีกมากมาย ซึ่งล้วนบ่งบอกถึงปัญหาที่ได้รับ ทั้งการอ่าน และ การทำความเข้าใจที่ยากมาก ๆ เนื่องจากจำนวนบรรทัดของ code เยอะจัด ไม่ต้องพูดถึงการแก้ไขเลยว่าจะยากเพียงใด ดังนั้นหัดแยก code ที่ยาว ๆ ออกมาเป็น method และ class ใหม่ซะ จงจำไว้ว่า Small is Better ดู VDO เรื่อง RailsConf 2014 - All the Little Things by Sandi Metz เพิ่มเติมได้

Bad :: Copy and Paste Programming

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

มีอะไรอีกนะที่ Programmer ควร ลด ละ เลิกได้เล้ว ?

มาช่วยกันทำให้การพัฒนา software ปลอดภัยมากขึ้น

December 22, 2015, 10:08 pm

≫ Next: 7 วิธีสำหรับนำ DevOps เข้ามาใช้ในองค์กร

≪ Previous: สิ่งแย่ ๆ ที่ Programmer ควร ลด ละ เลิก ได้แล้ว

$

0

0

วันนี้เข้าไปอ่านข้อมูลต่าง ๆ ที่ OWASP (Open Web Application Security Project) ซึ่งเป็น community ที่ร่วมกันสรุป guildeline ต่าง ๆ สำหรับการพัฒนา software ให้มีความปลอดภัยมากยิ่งขึ้น เนื่องจากเป็นสิ่งที่ developer มักจะหลงลืม และ มองข้ามไปเสมอ

โดยหนึ่งใน guideline ที่น่าสนใจคือ OWASP Proactive Control

นั่นจะช่วยให้ developer ทำการพัฒนา secure software แบบเชิงรุกมากกว่าเชิงรับ ซึ่งตอนนี้ได้เปิดให้ developer จากทั่วโลกเข้ามาช่วยกันเขียน และ สรุปได้แล้ว มาช่วยกันเขียน มาช่วยกัน review เพื่อให้ได้ guideline ที่ดี และ มีคุณภาพกันครับ อยู่ใน Google Doc :: Proactive Control

โดยประกอบไปด้วย 10 เรื่อง ที่อ้างอิงมาจาก Top 10 Security Problem ดังนี้

1. Parameterize Queries
2. Encode Data
3. Validate All Inputs
4. Establish Identity and Authentication Controls
5. Implement Appropriate Access Controls
6. Protect Data and Privacy
7. Implement Logging and Intrusion Detection
8. Leverage Security Features of Frameworks and Security Libraries
9. Error of Exception Handling
10. Verify for Security Early and Often

Developer ทั้งหลายมาช่วยกันครับ

---

7 วิธีสำหรับนำ DevOps เข้ามาใช้ในองค์กร

December 23, 2015, 9:05 pm

≫ Next: 3 ขั้นตอนในการเรียนรู้สิ่งใหม่ ๆ ของ Software Developer

≪ Previous: มาช่วยกันทำให้การพัฒนา software ปลอดภัยมากขึ้น

$

0

0

การนำเอาแนวคิด DevOps เข้ามาประยุกต์ใช้ในองค์กรนั้น มันอาจจะทำให้หลายที่สับสน และ ไม่ได้ผลตามที่คาดหวังไว้ เนื่องจากแต่ละองค์กรล้วนแตกต่างกัน ไม่ว่าจะเป็นเรื่องของโครงสร้าง ไม่ว่าจะเป็นเรื่องของวัฒนธรรม ไม่ว่าจะเป็นเรื่องของคน ไม่ว่าจะเป็นเรื่องของแนวปฏิบัติต่าง ๆ ตลอดจนเครื่องมืออีกด้วย ดังนั้นทาง VersionOne จึงได้ทำการสรุปวิธีการไว้ในบทความเรื่อง 7 Ways to Get Started with DevOps Today มาดูว่าได้แนะนำอย่างไรบ้าง ?

1. Invite Your Operations Team Into Your Development Process

ให้เชิญ Operation team เข้ามาอยู่ในกระบวนการพัฒนา software ด้วย ให้ทำการเปลี่ยนแปลงแบบเล็ก ๆ น้อย ๆ ตัวอย่างเช่น ในการประชุมทุก ๆ เช้าหรือ Standup meeting ก็ให้เชิญคนทาง Operation team เข้ามาด้วย ให้คนจาก Development team ไปนั่งทำงานกับ Operation team เมื่อมีการพูดคุย หรือ ทำการ deploy ระบบงาน เนื่องจากเป้าหมายหลักของ DevOps คือ การทำงานร่วมกันของทั้งสองทีมอยู่แล้ว และเป็นการเริ่มต้นเล็ก ๆ ที่ดีมากของทั้งสองทีม

2. Visualize the Work Together

ให้เพิ่มขั้นตอนการทำงานของ Operation team และ Development team เข้าด้วยกัน เช่นถ้า Development team มี board การทำงาน ก็ให้เพิ่มขั้นตอนการทำงานของ Operation team เข้าไปด้วย เช่น Waiting to deployment และ Deployed เป็นต้น มันทำให้เรารู้ และ เข้าใจว่า แต่ละ feature ทำการ deploy แล้วหรือยัง ? น่าจะเป็นสิ่งที่ดีกว่าเดิมนะครับ

Code ที่อยู่ใน repository โดยปราศจาคการ deploy มันคือสิ่งที่ไร้ค่า หรือ waste ใช่หรือเปล่า ?

3. Automate Your Test/Build Process

ทำการปรับเปลี่ยนวิธีการพัฒนาจาก maunal ไปเป็นแบบ automated แต่ก่อนอื่นคุณต้องรู้ และ เข้าใจการทำงานแบบ manual ก่อน เช่น

• ทำการดึง code ล่าสุดจาก repository ใน Version Control System
• ทำการ compile code
• ทำการ run unit test
• ทำการ package เพื่อให้พร้อมสำหรับการ deploy
• ทำการ deploy

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

4. Create a Deployment Plan

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

• ทำการ deploy ระบบช่วงดึก ๆ หรือ ช่วงวันหยุดหรือไม่ ?
• มักจะเจอปัญหาที่ไม่คาดฝันในการ deploy ระบบงานเสมอ และจะพยายามแก้ไขให้ระบบทำงานได้ไปก่อนหรือไม่ ?

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

5. Identify Fragile Systems

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

6. Smooth Out Wait States

จากข้อ 5 คือ การหาระบบ หรือ ขั้นตอนที่มันพัง หรือ ผิดพลาดได้ง่ายไปแล้ว ซึ่งเป็น pain point อย่างมากของการ deploy ระบบ ต่อมาคือ การหาขั้นตอน หรือ ระบบ ที่จำเป็นต้องรอเป็นเวลานาน ๆ หรืออาจจะต้องรอให้คนเข้ามามีส่วนร่วม เช่นการ approve ซึ่งมันเปลืองเวลาโดยใช่เหตุ เอาเวลาที่รอไปทำอย่างอื่นดีกว่าไหม !! ดังนั้นนำปัญหาเหล่านี้มาพูดคุยกัน ทั้ง Development team และ Operation team เพื่อหาทางแก้ไข ปรับปรุง ให้เวลาในการรอลดน้อยลงไป

7. Link Your Work to Your Value

ที่ผ่านมาทั้ง 6 ข้อเป็นเรื่องของ teachnical ทั้งหมดเลย

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

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

โดยทั้ง 7 ข้อคือการเปลี่ยนแปลงก้าวเล็ก ๆ

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

3 ขั้นตอนในการเรียนรู้สิ่งใหม่ ๆ ของ Software Developer

December 24, 2015, 9:34 pm

≫ Next: คำว่า คุณภาพ ในการพัฒนา software มันหายไปไหน ?

≪ Previous: 7 วิธีสำหรับนำ DevOps เข้ามาใช้ในองค์กร

$

0

0

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

1. Exploring
2. Planning
3. Focusing

มาดูรายละเอียดกัน

1. Exploring

ก่อนที่จะเริ่มศึกษาสิ่งใด ๆ ก็ตาม คุณควรทำการสำรวจ และ ค้นหาก่อนว่า สิ่งที่คุณชอบและสนใจก่อนว่า มันคืออะไรกันแน่ ? โดยให้ดูที่ภาพใหญ่ หรือ ภาพรวมของสิ่งนั้น ๆ แต่ไม่ใช่นั่งคิดแบบนิ่ง ๆ นะครับ จำเป็นจะต้องฟัง อ่าน ดู เพื่อให้ได้ข้อมูลพื้นฐานว่าแต่ละเรื่องมันเป็นอย่างไรบ้าง สิ่งที่สำคัญ คือ ไม่จำเป็นต้องรู้เรื่องทั้งหมด เพียงให้รู้พื้นฐาน และ keyword ต่าง ๆ ไว้บ้าง เพื่อใช้ในการเรียนรู้ต่อไป จากนั้นลองลงมือเล่นแบบผ่าน ๆ หรือลองติดตั้ง และ setup/run ให้ผ่าน เพื่อทำให้เข้าใจมากยิ่งขึ้น เพื่อทำให้เข้าใจมากกว่าการฟัง และ อ่าน เมื่อคุณเริ่มต้นได้แล้ว มันจะทำให้คุณเห็นว่าจะศึกษาอย่างไรต่อไป ไม่ว่าจะเป็นการต่อยอด หรือ ทิ้งมันไปซะ !!

2. Planning

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

ถ้าคุณไม่เลือก ไม่เรียงความสำคัญเลย แสดงว่า คุณไม่ได้ทำการ focus เรื่องใดเรื่องหนึ่งเลย สุดท้ายแล้ว คุณจะไม่ได้เรียนรู้อะไรเลย !!

3. Focusing

นั่นคือการเลือกที่จะเรียนรู้ นั่นคือ การ focus นั่นเอง เป็นสิ่งที่สำคัญอย่างมากสำหรับการเรียนรู้ การจับปลาสองมือ หรือ เรียนรู้หลาย ๆ สิ่งพร้อมกัน มันไม่ใช่แนวทางที่ดีเลย !! ให้ทำการเรียนรู้ทีละอย่างไปเรื่อย ๆ บน project ที่คุณพยายามจะสร้าง เรียนรู้ทีละอย่าง สร้างทีละสิ่ง ไปจนกว่า project จะสำเร็จ นั่นคือ Continuous Learning นั่นเอง

ดังนั้น Developer ทั้งหลาย

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

จงเรียนรู้กันต่อไปครับ

Reference Websites https://dzone.com/articles/my-3-steps-process-to-learn-new-skills-as-a-softwa http://blog.sqwiggle.com/10-techniques-for-learning-something-new-every-day/

คำว่า คุณภาพ ในการพัฒนา software มันหายไปไหน ?

December 29, 2015, 5:37 pm

≫ Next: ในปี 2016 มาเรียนรู้เครื่องมือเกี่ยวกับ Big Data กัน

≪ Previous: 3 ขั้นตอนในการเรียนรู้สิ่งใหม่ ๆ ของ Software Developer

$

0

0

การพัฒนา software ในปัจจุบัน สิ่งหนึ่งที่เรามักหลง ๆ ลืม ๆ กันไปมาก บางครั้งอาจจะทิ้งขว้างมันไป หรือ ทิ้งไว้กลางทางเสมอ นั่นก็คือ คำว่า คุณภาพ หรือ Quality ทำไมถึงเป็นอย่างนั้นนะ ?

Developer ทั้งหลายจำรูปนี้ได้หรือไม่ ?

มันคือรูป Project Management Triangle !! ประกอบไปด้วย 3 ส่วนหลัก คือ

1. Scope คือ จำนวน function ที่ถูกพัฒนาขึ้นมา
2. Time คือ เวลาที่ใช้ในการพัฒนา
3. Resource/Cost คือ จำนวนคน หรือ ค่าใช้จ่ายในการพัฒนา

ผลจากการควบคุม 3 ส่วนจะได้ Quality ออกมา !! นั่นหมายความว่า Quality มันจะเพิ่มขึ้นหรือลดลง ตาม Scope, Time และ Cost เสมอใช่ไหม ? แต่ถ้าเราลดอย่างใดอย่างหนึ่งแล้ว คุณภาพจะลดลงใช่ไหม ? มันไม่น่าจะเป็นแบบนี้ใช่ไหม ? สิ่งที่ควรจะเป็นไปก็คือ เราควรกำหนดคำว่า Quality ให้ชัดเจนไปเลยว่าเป็นอย่างไร เช่น

• กำหนดไปเลยว่าต้องมี resource ทำการทดสอบแบบ manual ด้วย
• กำหนดไปเลยว่าต้องมี resource เขียน automated test ขึ้นมา

แต่ถ้าเราคิดใหม่ว่า Quality ไม่น่าจะเป็นผลที่ตามมานะ

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

แต่ดูเหมือนว่าจะต้องควบคุมไปทุกอย่างเลย !! ซึ่งในความเป็นจริงแล้วนั้น Scope มันควรที่จะยืดหยุ่นหรือเปล่านะ ?

ส่วน Quality เป็นตัวเลือก หรือ เงื่อนไขหนึ่งนั่นเอง และจำเป็นต้องกำหนดความหมายของมันซะ ว่าทำอย่างไรบ้าง ? ทำให้เราสามารถวัดความสำเร็จของการพัฒนาจาก scope ที่เสร็จ ทั้งในแต่ละ release ทั้งในแต่ละรอบ หรือ iteration สิ่งนี้ทำให้ทีมพัฒนาเน้นไปที่การเพิ่มจำนวนงานที่เสร็จ ภายใต้ Quality, Time และ Cost ที่กำหนดกัน หรือ ตกลงร่วมกัน แสดงดังรูป  

คุณคิดว่ารูปไหนที่เหมาะกับการพัฒนา Software ? เพื่อทำให้ Quality มันดีขึ้นกว่าเดิม

ปล. ในการพัฒนา software ส่วนใหญ่ ถ้าการพัฒนามันช้า หรือ ไม่ทัน deadline ที่กำหนด สิ่งที่จะทำการตัดทิ้งไปคืออะไร ? ตอบได้เลยว่าเรื่องของ Quality ไงล่ะ !! ดังนั้น ลด ละ เลิก ความคิดแบบนี้กันดีกว่านะครับ

ในปี 2016 มาเรียนรู้เครื่องมือเกี่ยวกับ Big Data กัน

December 31, 2015, 12:54 am

≫ Next: สรุปข้อมูลต่าง ๆ ของ somkiat.cc ในปี 2015

≪ Previous: คำว่า คุณภาพ ในการพัฒนา software มันหายไปไหน ?

$

0

0

สิ่งหนึ่งที่สำคัญสำหรับ Big Data คือ ชุดของเครื่องมือต่าง ๆ ช่วยทำให้การทำงานกับ Big Data ง่ายขึ้น โดยในปี 2016 เราน่าจะศึกษาสิ่งต่าง ๆ ดังต่อไปนี้บ้างนะ

• Visualization
• Apache Spark
• HBase
• Cask Data Application (CDA)

มาดูรายละเอียดกันหน่อย

Visualization

Library ที่ต้องศึกษาเลยก็คือ D3.js นั่นเอง แต่ว่ามันใช้งานยากมาก ถึง มากที่สุด ซึ่งทำให้มีคนสร้าง libary หุ้มมันมาให้ใช้ง่าย ๆ มากมาย มีตัวที่น่าสนใจสำหรับ Big Data คือ NVD3 ซึ่งทำให้ชีวิตง่ายขึ้นเยอะ

Apache Spark และ HBase

เป็น framework ที่ไม่ควรพลาดด้วยประการทั้งปวง สำหรับการประมวลผลข้อมูล และจัดเก็บข้อมูลขนาดใหญ่ แน่นอนว่าในปี 2016 นั้น มันจะมีบทบาทที่สำคัญอย่างมาก

Cask Data Application (CDA)

เป็น abstraction layer ที่ทำงานอยู่บน Apache Hadoop ทำให้การพัฒนาระบบงานมันง่าย และ รวดเร็วมากขึ้น ทั้ง real time และ batch processing แน่นอนว่าสามารถทำงานร่วมกับเครื่องมือเหล่านี้ได้ด้วย

• HBase
• Hive
• Tephra คือ Transaction management สำหรับ HBase
• Tigon คือ Real time streaming ด้วย Apache Twill

นักพัฒนา software ลองศึกษากันไว้นะครับ ทั้งเรื่องความรู้พื้นฐานของ Big Data ทั้งเรื่องเครื่องมือต่าง ๆ สำหรับจัดการ และ พัฒนาระบบ

สรุปข้อมูลต่าง ๆ ของ somkiat.cc ในปี 2015

December 31, 2015, 10:57 pm

≫ Next: สรุปสิ่งที่น่าสนใจจากบทความเรื่อง Scrum does not work here in Asia 

≪ Previous: ในปี 2016 มาเรียนรู้เครื่องมือเกี่ยวกับ Big Data กัน

$

0

0

สวัสดีปีใหม่ 2016 ทำสรุปสถิติข้อมูลต่าง ๆ ของ Somkiat.cc ในปี 2015 กันหน่อย ว่าเป็นอย่างไรบ้าง ? โดยนำข้อมูลมาจาก Google Analytic

จำนวน blog ในแต่ละเดือนเป็นดังนี้

1. มกราคม 36 blog
2. กุมภาพันธ์ 26 blog
3. มีนาคม 34 blog
4. เมษายน 31 blog
5. พฤษภาคม 32 blog
6. มิถุนายน 29 blog
7. กรกฎาคม 27 blog
8. สิงหาคม 30 blog
9. กันยายน 28 blog
10. ตุลาคม 26 blog
11. พฤศจิกายน 37 blog
12. ธันวาคม 29 blog

มาดูข้อมูลจาก Google Analytic กันหน่อย

ในแต่ละเดือนก็พอมี developer เข้ามาอ่านบ้างนิดหน่อย

เนื่องจากเป็น blog ภาษาไทย ดังนั้นคนอ่านจึงเป็นคนไทย จากประเทศไทย

จังหวัดที่เข้ามาเยอะสุดเป็นกรุงเทพตามระเบียบ ตามมาห่าง ๆ ด้วยเชียงใหม่ นครปฐม ขอนแก่น สงขลา และ โคราชตามลำดับ ส่วน not set นี่ก็ไม่น้อยเลย

มาดู OS ที่เข้ามาเยอะ หน่อยสิ

น่าจะพอเดากันได้ว่า Desktop กับ Mobile มันพอ ๆ กันเลยนะ ปีนี้คงต้องพัฒนา Mobile app ออกมาได้แล้ว

มาดู Browser กันหน่อยสิ

อันดับหนึ่งก็คือ Google Chrome นั่นเอง

แล้วคนอ่านส่วนใหญ่มากจากไหนกันบ้าง ?

กว่าครึ่งมาจาก Social Networking นั่นเอง ประกอบไปด้วย

• Facebook 96%
• Twitter 3%
• Google plus 1%

รองลงมาคือ จากการค้นหา และ เข้ามาตรง ๆ

ปิดท้ายด้วย 10 อันดับ blog ที่มีคนเข้ามาอ่านเยอะ ๆ บ้าง

1. มาดูเบื้องหลังการทำงานของ How-Old.net
2. คุณไม่มีเวลาในการพัฒนาตัวเองกันเลยใช่ไหม ?
3. การใช้งานกระดาษ Post-it แบบผิดๆ
4. เพิ่งรู้ว่า Integer ใน Java นั้น 100 เท่ากับ 100 แต่ 1000 ไม่เท่ากับ 1000
5. ทำไม developer ชอบสร้าง software แย่ๆ ออกมา !!
6. 7 อย่างที่ควรหยุดทำ เพื่อเพิ่ม productivity ให้สูงขึ้น
7. Programmer vs Developer vs Coder มันแตกต่างกันอย่างไร ?
8. ข้อดีและข้อเสียของ NoSQL ที่ต้องรู้ !!
9. Code ที่มันสั้นๆ คุณเขียนเพื่ออะไร ?
10. PHP developer ต้องเตรียมตัวสำหรับการเปลี่ยนแปลงบ้างนะ !!

สวัสดีปีใหม่ครับ