Quantcast
Channel: cc :: somkiat
Viewing all 2000 articles
Browse latest View live
↧

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

April 8, 2016, 7:51 am
$
0
0

android-good-resource

android-good-resource นั่งอ่านบทความเรื่อง Compile ‘android:best:1.1.1’ มันมีเนื้อหาที่ Android Developer ทุกคนไม่น่าพลาด ประกอบไปด้วย
  • แหล่งความรู้เกี่ยวกับ Android
  • เครื่องมือที่จำเป็นต่อการพัฒนา
  • Library ต่าง ๆ แบ่งเป็นกลุ่มได้ชัดเจน
ดังนั้นเลยขออนุญาตเจ้าของบทความ เพื่อนำมาแปลไว้อ่านนิดหน่อย บางหัวข้อก็ไม่ได้แปล

เริ่มจากแหล่งศึกษาหาความรู้เกี่ยวกับ Android

บอกได้คำเดียวว่าเยอะมากมาย เยอะจนไม่รู้จะเริ่มกันตรงไหน !! ดังนั้น developer ก็ลองเลือกดูได้นะ ว่าชอบแบบไหน ? ส่วนตัวผมติดตามจาก 4 แหล่งนี้
  • Android Developer ใน Google+ ขาดไม่ได้เลย อาจจะขัดใจหน่อย เพราะว่าคนส่วนใหญ่ไม่ค่อยใช้งาน
  • Android Weekly แนะนำให้ติดตามไว้เลย ส่วนผมเก็บไว้ใน feed
  • Google I/O มีของเยอะมาก ๆ ยังดูไม่หมดเลย
  • Google Developers บน Medium

ต่อมาเรื่องของเครื่องมือในการพัฒนา

แน่นอนว่า สิ่งที่ขาดไม่ได้เลยก็คือ Android Studio เพิ่งปล่อย Android Studio 2.0 ออกมาพร้อมกับ Instant Run ออกมาด้วย แต่แนะนำให้ปิดความสามารถนี้ไปก่อนนะครับ เพราะว่า มันพังบ่อยมาก ๆ ถ้าไม่เชื่อก็ลองดู รวมทั้งมี Emulator ตัวใหม่ที่เร็วจริง ๆ และมีความสามารถมากมาย แต่ก็แลกกับ Memory เริ่มต้นที่ 1 GB นะครับ ปล. ใครยังใช้ Eclipse อยู่ก็เปลี่ยนเถอะนะ เพราะว่ามัน deprecated ไปแล้ว สามารถเรียนรู้การใช้งาน และ configuration Android Studio เพิ่มเติมได้ที่ ส่วน Emulator อื่น ๆ แนะนำ Genymotion Emulator ซึ่ง Android Developer น่าจะใช้กันเกือบหมด

มาดู Library หลัก ๆ สำหรับการพัฒนา Android Application

1. Support Library ใครไม่ใช้นี่แปลกมากนะ ซึ่งมี library เพียบเลยไม่ว่าจะเป็น
  • V4 support library
  • Multidex support library
  • V7 appcompat
  • V8, V13, V14, V17 … จะเยอะกันไปไหน
ปล. อย่าลืม update version ใหม่ ๆ กัน ส่วนการใช้งานนั้น จากเอกสารของ google แนะนำให้เริ่มใช้งานจาก V4 และ V7 appcompat และควรใช้ version เดียวกันนะ ไม่เช่นนั้นเดี๋ยวจะ compile ไม่ผ่าน หรืออาจจะทำให้ app พังไปเลย ดังตัวอย่าง [gist id="0226c01d245e873950785dea920b25ef" file="support_library.txt"] 2. Google Play Service ถ้า app ไหนต้องการใช้งาน Google API ไม่ว่าจะเป็น Google Map, Google Pay, Ads และอื่น ๆ ก็ต้องใช้ library นี้ แต่การใช้งานนั้น แนะนำให้ใช้เฉพาะ service ที่ต้องการเท่านั้น ไม่เช่นนั้นจะมีปัญหาเรื่องจำนวน method ที่เกิน 65k นะ ตัวอย่างการใช้งาน [gist id="0226c01d245e873950785dea920b25ef" file="google_play_service.txt"] 3. Reactive library คงปฏิเสธไม่ได้ว่า Reactive programming ได้รับความนิยมสูงมาก รวมทั้ง Android ด้วย ทำให้จัดการเรื่อง asynchonous, event-based และ stream ง่ายขึ้น โดยใน Android ใช้ library ชื่อว่า RxAndroid การทำงานภายในจะใช้งาน RxJava ดังนั้นการใช้งานต้องการ library 2 ตัวดังนี้ [gist id="0226c01d245e873950785dea920b25ef" file="reactive.txt"] และยังมี Library อื่น ๆ เข้ามาช่วยเหลือ เช่น
  • RxLifeCycle เข้ามาจัดการเรื่อง unsubscription แบบอัตโนมัติ เพื่อลดปัญหาเรื่อง memory leak
  • RxBinding สำหรับการ binding API ต่าง ๆ เข้ากับ User Interface
  • Frodo plugin สำหรับเก็บ log การทำงานของ RxJava
แน่นอนว่า learning curve หรือการเรียนรู้เรื่อง Reactive programming มันต้องสูงกว่าปกติ แต่ก็ไม่ใช่เรื่องยากมากนัก เพราะว่ามีแหล่งเรียนรู้มากมาย เช่น

Library ต่าง ๆ ที่ช่วยทำให้ code สวย และ ดีขึ้น (Clean Code)

1. Support Annotation เป็น library ช่วยดักจับข้อผิดพลาดต่าง ๆ ให้ และทำให้ code ดูสวยงามมากขึ้น ซึ่งมี annotation มาให้ใช้งานมากมาย เช่น
  • @Nullable
  • @StringRes
สามารถศึกษาเพิ่มเติมได้จาก Annotations to support your contracts [gist id="0226c01d245e873950785dea920b25ef" file="annotation.txt"] 2. Butter Knife ได้เตรียม Annotation สำหรับการ binding กับ view และ event ต่าง ๆ ซึ่งทำให้ code มันน้อยลงไปอย่างมาก [gist id="0226c01d245e873950785dea920b25ef" file="butterknife.txt"] 3. Data Binding Library เป็น library จาก Google เอง เพื่อให้สามารถทำการ binding API ต่าง ๆ กับ layout xml ได้เลย นั่นทำให้ลด java code ไปอย่างมาก แต่ก็ยังคงอยู่ในสถานะ beta อยู่ !! สามารถใช้งานได้กับ Android Plugin for Gradle 1.5.0-alpha1 ขึ้นไปนะ 4. Dagger 2 เป็น Library ที่มาจาก Square อีกแล้วครับท่าน ปัจจุบัน Google เข้าไปพัฒนาเองแล้ว เป็น Dependency Injection framework นั่นเอง ทำให้ code ไม่ผูกมัดกันจนเกินไป ทำให้ code แยกส่วนการทำงานกันอย่างชัดเจน ส่งผลให้ code สามารถ reuse และ ทดสอบได้ง่ายขึ้นมาก แถมอ่านเข้าใจง่ายอีกด้วย (จริงไหมนะ !!) [gist id="0226c01d245e873950785dea920b25ef" file="dagger.txt"]

มาดู Library สำหรับการ Build และ Compile กันบ้าง

สำหรับ app ใหญ่ ๆ ต้องไม่พลาดกับ Multidex Support Library เพราะว่าจำนวน method เกิน 65k แน่นอน แต่แนะนำว่า นี่เป็นวิธีการสุดท้ายสำหรับการแก้ไขปัญหา !! ก่อนอื่นลดจำนวน library ที่ไม่จำเป็นลงไปก่อนนะ [gist id="0226c01d245e873950785dea920b25ef" file="multidex.txt"]

มาถึงเรื่องของการทดสอบบ้างสิ

ปล. ใครไม่ทดสอบระบบงานบ้างนะ ? คิดว่าไม่มีหรอก แต่ว่าจะทดสอบแบบไหนเท่านั้นเอง !! รู้ไหมว่า สำหรับ Android app เราก็สามารถเขียน code เพื่อทดสอบได้นะ ซึ่งมี library ต่าง ๆ ให้ใช้งานดังนี้ Testing Support Library พัฒนาจาก Google เองนั่นแหละ เตรียม library ต่าง ๆ ไว้ให้พร้อมเลย ประกอบไปด้วย 1. Pure JUnit test สามารถทำการ run โดยไม่ต้องการ emulator เลย ทำให้เราสามารถเขียนชุดการทดสอบกับ Java code ทั่วไป เช่นพวก domain และ business logic ต่าง ๆ ตลอดจนการใช้งาน resource ต่าง ๆ และสามารถนำแนวคิดของ TDD (Test-Driven Development) มาใช้งานได้ [gist id="0226c01d245e873950785dea920b25ef" file="junit.txt"] 2. Instrumentation test เป็นชุดการทดสอบที่ต้องการเครื่องจริง หรือ emulator แน่นอนว่า การทดสอบเหล่านี้ต้องใช้เวลาที่สูงขึ้น สำหรับทดสอบพวก function และ UI test นั่นเอง จะต้องใช้งาน Test Runner Library [gist id="0226c01d245e873950785dea920b25ef" file="runner.txt"] และยังมี Espresso สำหรับการทดสอบส่วนของ UI test แบบง่าย ๆ ให้อีกด้วย [gist id="0226c01d245e873950785dea920b25ef" file="espresso.txt"] ลองดูตัวอย่างเพิ่มเติมที่ Android Testing Blueprint และศึกษาเพิ่มเติมได้จากที่นี่ Practice for testing

ชักจะเยอะ และ ยาวล่ะ ขอปิดท้ายด้วยเรื่องของการจัดการข้อมูลดีกว่า

เริ่มด้วยการจัดการพวกรูปภาพ ประกอบไปด้วย 3 library หลัก คือ จะเลือกอะไรก็คิด วิเคราะห์ แยกแยะกันเอาเองครับ [gist id="0226c01d245e873950785dea920b25ef" file="image.txt"] ต่อมาเรื่องการติดต่อผ่าน REST API คงหนีไม่พ้น Retrofit โดย app ส่วนใหญ่น่าจะใช้ library ตัวนี้ [gist id="0226c01d245e873950785dea920b25ef" file="retrofit.txt"] ส่วนเรื่องการจัดการข้อมูล น่าจะใช้ Gson สำหรับการจัดการข้อมูลในรูปแบบ JSON และการจัดการ caching data น่าจะใช้งาน DiskLRUCache ส่วนการจัดการเรื่องวันที่ และ เวลา ต้องหนีไม่พ้น Joda Time แน่นอน ลองอ่านเพิ่มเติมได้จากต้นฉบับนะครับ ขอบอกได้คำเดียว มันเยอะมาก ๆ แต่มีประโยชน์มากเช่นเดียวกัน
↧
Search

คำถามที่น่าสนใจ “จะทดสอบ Facebook API กันอย่างไรดี ?”

April 10, 2016, 1:28 am
$
0
0

Dojo_mocking_external_dependancies

Dojo_mocking_external_Apis จากการพูดคุยเรื่อง การทดสอบ Facebook API คำถามหลักคือ จะเขียนทดการทดสอบอย่างไรดีล่ะ ?
  • Unit/Integration/System test ?
  • ต้องทำการ Mock/stub ระดับ API หรือ service ?
ส่วนตัวผมมีแนวคิดสำหรับกรณีนี้ดังนี้

เริ่มต้นด้วยการทดสอบด้วยการต่อ Facebook API ตรง ๆ ไปเลย

เพื่อทำให้เราเข้าใจว่า Facebook API ทำงานอย่างไร ทั้ง input ที่ต้องส่งไป ทั้ง output ที่ได้รับกลับมา รวมทั้งเรียนรู้การใช้งาน library ที่ทำงานกับ API อีกด้วย แต่การเรียกใช้งาน API ตรง ๆ เลย มันก่อให้เกิดปัญหาหลาย ๆ อย่าง ตัวอย่างเช่น
  • การควบคุมข้อมูล
  • ความเร็วของ Network
  • ข้อจำกัดในการใช้งาน API
ดังนั้นวิธีการแก้ไขปัญหามันมีหลายทางเลือก ทั้งลงแรงเยอะ และ น้อย ทั้งเขียน code เพิ่มเยอะ และ น้อย

วิธีการที่ผมชอบคือ เริ่มเขียนจากมุมมองของผู้ใช้งานก่อน !!

นั่นคือ สิ่งที่เราสนใจมันทำงาน และ ใช้งานอย่างไร อาจจะมองในมุมของ feature ของระบบเลยก็ได้ ขอเรียกว่าเป็น Acceptance test เช่น feature การดึง user profile จาก facebook ดังนั้นเขียน acceptance test ง่าย ๆ ว่า
  • ทำการดึงข้อมูล user profile ของนาย กอไก่ มาจาก facebook
  • ข้อมูลที่ได้รับประกอบไปด้วย ชื่อนายกอไก่ นามสกุลไข่เยอะ
จาก Acceptance test นี้ มันทำให้เราเห็นว่าเป้าหมายคืออะไร ไม่ต้องไปคิดเรื่องอื่นเยอะ ให้สนใจที่ดึงข้อมูลชื่อและนามสกุลของ นายกอไก่จาก Facebook มาให้ได้ก่อน แน่นอนว่า Acceptance test นี้มันทำงานไม่ได้ หรือทดสอบไม่ได้ และ ไม่ผ่านอยู่แล้ว เพราะว่า เรายังไม่ทำการเขียน code อะไรขึ้นมาเลย !! ดังนั้นเริ่มเขียน code กันเถอะ ซึ่งให้ทำการเรียก Facebook API ตรง ๆ ไปเลย จะได้ข้อมูลของนายกอไก่ถูกต้อง

จากปัญหาต่าง ๆ ข้างต้น ผมจึงพยายามทำให้ feature นี้มันทดสอบได้ง่ายขึ้น (Testable)

ซึ่งวิธีที่ผมชอบทำมี 2 ทาง คือ
  1. จำลอง Facebook API server ด้วยเครื่องมือต่าง ๆ เช่น Stubby4j และ WireMock เป็นต้น
  2. ใช้แนวคิด Stub และ Mock จาก test double มาใช้งาน
Dojo_mocking_external_dependancies ทั้งสองแนวทางนั้น ต้องแก้ไข code เดิมให้ทดสอบได้ง่ายขึ้น แน่นอนว่า code ดีขึ้นแน่นอน และ code แต่ละส่วนควรมี Unit testing ครอบคลุมเสมอนะ เพื่อทำให้เรารู้ว่า กำลังทำอะไร แก้ไขปัญหาอะไร และ จะทำงานเสร็จเมื่อไร
อย่าลืมว่า เรามี Acceptance test นะ ถ้าให้ดีลองให้มันทำงานแบบอัตโนมัติดูสิ น่าจะทำห้เรามั่นใจว่า สิ่งที่แก้ไขมันยังถูกต้อง หรือ ทำงานตามที่ตกลงกันไว้
ปล. ส่วนใหญ่วิธีการต่าง ๆ มันเกิดจากปัญหา และการตั้งคำถามทั้งนั้นเลย (หัดตั้งคำถามให้ดี) ส่วนวิธีการต่าง ๆ มันมีหลากหลายวิธีการ ดังนั้น ให้ทดลองใช้วิธีการต่าง ๆ ก่อนว่า อะไรที่เหมาะสม

สุดท้ายคือ เราต้องตอบให้ได้ว่า

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

จัดการ Python project ด้วย Docker กันหน่อย

April 10, 2016, 9:07 am
$
0
0

docker-python

docker-python วันนี้มานั่งฟังการแบ่งปันเรื่อง Docker ที่ SPRINT3R ตั้งแต่เรื่องพื้นฐานไปยัน Docker Swarm กันเลย !! ดังนั้นจึงลองมาสร้างสิ่งที่ต้องการนิดหน่อย คือการเตรียม environment ไว้สำหรับ Python project ประเด็นหลัก ๆ คือการจัดการ library หรือ dependency ต่าง ๆ ปล. ปกติจะใช้งาน virtualenv ซึ่งทำงานได้แจ่มมาก ๆ ทำให้เราจัดการ dependency ต่าง ๆ ตาม version ของ python บนเครื่องเดียวกัน แต่ถ้าต้องการเตรียม environment ต่าง ๆ เพิ่มล่ะ เช่น
  • Database
  • Messaging server
  • Search server
จะต้องทำอย่างไร ให้เราทำงานได้ง่ายและสะดวกขึ้น ? หนึ่งในทางเลือกก็คือ Docker ดังนั้นมาเริ่มสร้างกันหน่อยสิ

เริ่มด้วยวิธีง่ายสุด ๆ คือ ใช้ Dockerfile อย่างเดียว

โดย library ต่าง ๆ ของระบบงานจะอยู่ในไฟล์ requirments.txt ประกอบไปด้วย
  • Flask
  • Jinja2
  • Werkzeug
  • distribute
  • wsgiref
มีขั้นตอนการสร้างดังนี้

ขั้นที่ 1 ทำการสร้าง machine ด้วย Docker machine

ตั้งชื่อว่า default [code]$docker-machine create --driver virtualbox default[/code] จากนั้นเข้าใจงาน machine default ซะ [code] $docker-machine env default $eval "$(docker-machine env default)" [/code]

ขั้นที่ 2 สร้าง Dockerfile สำหรับระบบงาน

โดยสิ่งที่ต้องการประกอบไปด้วย
  • ใช้ระบบปฏิบัติการ Alpine เพราะว่าขนาดมันเล็กและเพียงพอต่อการใช้งาน
  • ทำการติดตั้ง package ต่าง ๆ ที่ต้องการผ่าน apt-get เช่น python เป็นต้น
  • ทำการ deploy ระบบงาน หรือ ทำการ clone มาจาก repository ก็ได้
  • ทำการติดตั้ง library/dependency ต่าง ๆ ผ่าน pip
โดยรวมแล้วสามารถสร้างใน Dockerfile ได้ดังนี้ [gist id="7fcc8cc00f4d4ce0c0e70fe0ddd06ca2" file="Dockerfile"] เมื่อเรียบร้อยก็มาสร้าง Image ใช้งานกัน ด้วยคำสั่ง [code] $docker build -t my_python_image . [/code]

ขั้นที่ 3 สร้าง container ใช้งานกันเถอะ

โดยสร้าง container มาจาก Image ที่สร้างจากขั้นที่ 3 นั่นเอง ด้วยคำสั่ง [code] $docker run --name my_python_container -p 8000:8888 -i -t my_python_image [/code] คำอธิบาย
  • ตั้งชื่อ container ว่า my_python_container
  • ทำการ mapping port 8000 เข้ากับ port ของ container ซึ่งกำหนดไว้เป็น 8888 ทำให้สามารถใช้งานผ่าน port 8000 ได้เลย
  • สร้างมาจาก image ชื่อว่า my_python_image
ทดลองการใช้งานแสดงดังรูป docker01 ตัวอย่างของ Dockerfile และ python project อยู่ที่ Github::Up1:: Docker python

เพียงเท่านี้ก็สามารถสร้าง environment แบบง่าย ๆ

สำหรับการพัฒนาระบบงานด้วยภาษา Python ได้ล่ะ ต่อไปถ้ามี service การทำงานเพิ่มขึ้น เช่น Frontend, Backend, Middleware และ Caching สามารถนำ Docker compose มาช่วยจัดการเพิ่มได้ หรือจะใช้ Dockerfile อย่างเดียวก็ได้ เอาที่สบายใจกันนะครับ

ปิดท้ายมาดูขนาดของ image จากการใช้ Ubuntu และ Alpine

ขนาด image เมื่อใช้ Ubuntu docker-ubuntu ขนาด image เมื่อใช้ Alpine docker-alpine
↧

ทำความเข้าใจการทำงานของ Jack and Jill ใน Android กันหน่อย

April 11, 2016, 9:06 am
$
0
0

android_04

เมื่อประมาณปลายปี 2015 นั้นทางทีมพัฒนา Android ได้ปล่อยเครื่องมือในการ build ใหม่ออกมาชื่อว่า Jack and Jill
  • Jack (Java Android Compiler Kit)
  • Jill (Jack Intermediate Library Linking)
เป้าหมายเพื่อเข้ามาปรับปรุงกระบวนการเดิมคือ javac และ dex นั่นเอง ดังนั้นเรามาทำความเข้ากับเครื่องมือต่าง ๆ เหล่านี้กันหน่อย ซึ่งจะอยู่ในระบบ Build ของ Android นั่นเอง ดังนั้นจึงเริ่มไปหาข้อมูลจาก Android Developer ก็เจอดังนี้ อธิบายได้ง่าย และ เข้าใจดี และไปเจอบทความเรื่อง The dark side of Jack and Jill อธิบายได้เข้าใจง่าย เลยนำมาสรุปนิดหน่อยดังนี้

เริ่มด้วยการอธิบายขั้นตอนการทำงานแบบเดิมก่อนว่าเป็นอย่างไร ?

เป็นการใช้
  • javac สำหรับการ compile java code ไปเป็น java byte code
  • dex สำหรับการแปลง java byte code เป็นไปไฟล์ DEX (Dalvik Executabel) หรือ Dalvik byte code นั่นเอง เพื่อ optimize เพื่อให้สามารถทำงานบนอุปกรณ์ที่มีจำกัดทั้ง CPU และ Memory
ปล. ปัจจุบันมี runtime ตัวใหม่ชื่อว่า ART (Android RunTime) ซึ่ง compatible กับ Dalvik จากนั้นจึงนำไปสร้างเป็นไฟล์ APK ต่อไป แสดงการทำงานดังรูป android_01 สังเกตไหมว่า พวก 3-party library นั้นจะไม่ถูก compile ใหม่ทำให้การทำงานเร็วขึ้น ดังนั้น ลองคิดสิว่า ถ้าใน project ของเรานั้น ทำการแยก code ที่ใช้งานซ้ำ ๆ ออกไปเป็น module หรือ library จากนั้นทำการ import เข้ามาใช้ใน project น่าจะทำให้ขึ้นตอนการ compile และ build เร็วขึ้นอีกนะ !!

คำถามต่อมาคือพวก proguard, jacoco มันทำงานตรงไหนกันล่ะ ?

คำตอบที่ได้กลับมาคือ เครื่องมือเหล่านี้มันทำงานกับ java byte code ทั้งหมด ซึ่งทำให้เราสามารถปรับปรุง java byte code ได้เลย แสดงการทำงานดังรูป android_02 ทำให้เราเข้าใจ และ เห็นภาพว่า Proguard มันเข้าไปวิเคราะห์ java byte code นี่เอง จากนั้นจึงทำการลบสิ่งที่ไม่ใช้งานออกไป ทำให้ขนาดของ java byte code มันเล็กลง Jacoco ทำการวิเคราะห์จาก byte code นี่เอง ก่อนจะสนับสนุน Java 8 ทำไมถึงใช้งาน Retrolambda ได้ นั่นคือเข้าไปแก้ไขจาก Lambda ของ Java 8 ให้เป็น annonymous inner class นั่นเอง ซึ่งกระบวนการทำงานต่าง ๆ เหล่านี้จะอยู่ในรูปแบบของ plugin เรียกกระบวนการเหล่านี้ว่า Post processing ผลลัพธ์ที่ได้คือ java byte code ใหม่นั่นเอง

มาถึงตรงนี้เราสามารถสรุปขั้นตอนการทำงานได้ 3 ขั้นตอนคือ

  1. ทำการ compile java code เป็น java byte code
  2. ทำการปรับปรุง java byte code
  3. ทำการแปลงเป็นไฟล์ DEX
ผลที่ตามมาคือ การ build มันช้ามาก ๆ การทดสอบช้ามาก ๆ การสร้างไฟล์ APK ช้ามาก ๆ ยิ่งในระบบงานใหญ่ ๆ จะเจอปัญหาเรื่องจำนวน method เกิน 65K อีก ก็ต้องแก้ไชปัญหา MultiDex กันอีกก็ยิ่งช้าไปกันใหญ่

ดังนั้นแนวทางใหม่ของทีมพัฒนา Android คือ Jack and Jill

มันยังคงเป็น Experiment Tool นะครับ โดยที่ Jack ย่อมาจาก (Java Android Compiler Kit) ทำการ compile java code คล้ายกับ javac เลย แต่ผลลัพธ์ที่ได้จาก Jack คือ ไฟล์ DEX หรือ Android byte code เลย แสดงการทำงานดังรูป android_03 สังเกตุไหมว่า เป็นการตัดขั้นตอนการทำงานตรงกลางออกไป แน่นอนว่า ย่อมทำให้ขึ้นการทำงานเร็วขึ้นสิ !! ใช้ได้กับ build tool 21.1.1 ขึ้นไปนะ

คำถามต่อมาคือ แล้วพวก module/library ต่าง ๆ ล่ะ จะนำเข้ามาใช้ได้อย่างไร ?

คำตอบคือ Jill (Jack Intermediate Library Linking) นั่นเอง ทำการแปลง java byte code ไปอยู่ในรูปแบบที่เรียกว่า jack library file สำหรับเป็นข้อมูลเพื่อส่งไปยัง Jack แสดงการทำงานดังรูป android_04

คำถามต่อมาแล้วเรื่องการจัดการ java byte code ล่ะ เช่น Proguard, Jacoco และ Retrolambda ?

คำตอบคือ
  • Pro guard นั้นมันอยู่ใน Jack อยู่แล้ว
  • ไม่สนับสนุน Jacoco !!
  • ส่วน Retrolambda ไม่จำเป็นแล้ว เพราะว่าตอนนี้สนับสนุน Lambda ใน Java 8 แล้ว
  • นั่นแสดงว่า มันไม่สนับสนุนการปรับปรุง แก้ไข java byte code เหมือนเดิมอีกต่อไป !!
  • ถ้าระบบใหญ่ ๆ จะเกิด OutOfMemory ได้อีกด้วย ดังนั้นให้ทำการเพิ่ม Memory ให้กับการทำงานด้วยนะ !!
ถึงแม้ว่า Jack and Jill ยังไม่ข้อจำกัดเยอะ แต่เป็นแนวทางที่ดีสำหรับขั้นตอนการ build ของ android app และตอนนี้ Jack มันสนับสนุนความสามารถต่าง ๆ ใน Java 8 แล้วนะ ซึ่งใช้ได้กับ Android N เท่านั้น มาถึงตรงนี้น่าจะทำให้เราเข้าใจเกี่ยวกับการทำงานภายในการ build android app มากขึ้นบ้างนะ
↧

สรุปแนวคิดดี ๆ เกี่ยวกับ devops

April 12, 2016, 12:24 am
$
0
0

devops

devops จากบทความเรื่อง From DEVOPS to devops ทำการอธิบายแนวคิดของ devops ไว้อย่างน่าสนใจ เนื่องจากเมื่อมีการพูดถึง devops แล้วมักจะถามเรื่องต่าง ๆ ดังต่อไปนี้เสมอ
  • องค์กรคุณมี devops ไหม ?
  • องค์กรคุณเป็น devlops ไหม ?
  • ทำการจับวัดประสิทธิภาพของ devops อย่างไร ?
  • ใช้เครื่องมืออะไรกันบ้าง ?
ส่วนคำตอบนั้นลองให้คุณเขียนคำว่า devops ออกมาก่อนสิ ว่ามีตัวพิมพ์ใหญ่กี่ตัว ? เช่น DevOps หมายความว่า สนใจ Devlopment กับ Operation ใช่ไหม ? แล้ว e, v, p, s มันไม่สำคัญหรือไง ? ดังนั้นเราควรทำความเข้าใจกับ DEVOPS แบบนี้กันก่อนนะ
Don’t start with a rename Evolve your thinking Variable reduction Obliterate silos Prevent the hero Share the pain

Don’t start with a rename

ไม่ใช่การเปลี่ยนชื่อแผนก หรือ ทีมนะ เช่นเปลี่ยนจาก operation team มาเป็น devops team แต่ยังทำงานเหมือนเดิมกับการใช้เครื่องมือใหม่ !!

Evolve your thinking

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

Variable reduction

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

Obliterate silos

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

Prevent the hero

นี่คือเรื่องของวัฒนธรรมของทีม และ องค์กรนั่นเอง ควรทำงานเหมือนกับ ทีมกีฬา ที่ทุกคนภายในทีมจะต้องช่วยเหลือซึ่งกันและกัน เก่งคนเดียวไม่ช่วยทำให้ทีมชนะได้ !! มีปัญหาก็ต้องช่วยกันแก้ไข

Share the pain

แบ่งปันความเจ็บปวด อย่าเก็บปัญหาไว้กับทีม และ ตัวเอง เพื่อทำให้เห็นว่า ปัญหามันมาจากตรงไหนกันบ้าง เช่น
  • Development
  • Deployment
  • Monitoring
เพื่อทำให้เห็นตรงกันว่า ควรจะปรับปรุงส่วนไหนกันบ้าง ไม่ใช่ทำงานไปตามความรู้สึก !!

สุดท้ายแล้วแนะนำให้เขียน devops เป็นตัวเล็กทั้งหมด

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

[แปล] ว่าด้วยเรื่อง Continuous Deployment ของระบบ Instagram

April 13, 2016, 9:48 am
$
0
0

cd-at-instagram

cd-at-instagram วันนี้เห็นมีการ share บทความเรื่อง Continuous Deployment at Instagram เป็นบทความที่อธิบายขั้นตอนการ deploy ระบบงานของ Instagram ว่าเป็นอย่างไร ดังนั้นจึงทำการแปล และ สรุปส่วนที่น่าสนใจไว้นิดหน่อย ซึ่งถือว่าเป็นแนวทางหนึ่งของการพัฒนา software ที่ดี เริ่มกันเลยดีกว่า

ระบบ Instagram นั้น ทำการ deploy code ส่วน backend ประมาณวันละ 30-40 ครั้งต่อวัน

หรือว่าทำทุก ๆ ครั้งเมื่อมีการเปลี่ยนแปลง code ที่ branch master โดยส่วนใหญ่แล้วจะไม่มีคนเข้าไปมีส่วนร่วมเลย !! นั่นคือทำงานแบบอัตโนมัตินั่นเอง เป็นไงล่ะ แค่เริ่มต้นก็ต้องร้อง ว้าววววว กันแล้ว และทาง Instagram บอกว่า ด้วยขนาดและการ scale ของระบบนั้น ต้องการการทำงานในรูปแบบนี้ ซึ่งมันแจ่ม และ เหมาะมาก ๆ ดังนั้นมาเรียนรู้กันว่า Instagram ทำกันอย่างไร ?

เริ่มด้วยคำถามอีกแล้ว ทำไปทำไม ?

ข้อดีของ Continuous Deployment มีดังนี้ ทำให้ทีมพัฒนาทำงานได้รวดเร็วขึ้น เนื่องจากสามารถทำการ deploy code ได้บ่อยเท่าที่ต้องการ ไม่ต้องมารอช่วงเวลา และ จำนวนครั้งที่จำกัดในการ deploy ต่อวัน ผลที่ตามมาก็คือ ไม่ต้องสูญเสียเวลาไปโดยเปล่าประโยชน์ รวมทั้งค่อย ๆ ทำการเปลี่ยนแปลงระบบไปทีละเล็กละน้อย ทำให้รู้ว่าแต่ละการเปลี่ยนแปลงมันผิดหรือถูกได้รวดเร็วขึ้น เนื่องจากทำการ deploy ทุก ๆ การเปลี่ยนแปลง ทำให้ไม่ต้องมานั่งหาข้อผิดพลาดจากการเปลี่ยนแปลงมากมาย ดังนั้น ถ้าการเปลี่ยนแปลงไหนผิด ก็จะรู้ได้ทันที ทำให้สามารถระบุปัญหาได้ทันที และ แก้ไขได้รวดเร็วขึ้น แนวคิดนี้คือ Fail fast, Break things จริง ๆ มันคุ้น ๆ ไหม ถ้าการ deploy แต่ละครั้งมีการเปลี่ยนแปลงเยอะ ๆ การหาข้อผิดพลาดแต่ละเรื่องก็ยากใช่ไหม ?

ทำการสร้างระบบอย่างไร ?

การพัฒนาระบบ Continuous Deployment จะประสบความสำเร็จได้นั้น มันมาจากหลายปัจจัย จะสร้างครั้งเดียวให้เสร็จนั้น เป็นไปไม่ได้เลย !! ดังนั้นวิธีการที่ทำคือ ค่อย ๆ สร้างอย่างยั่งยืน (Iterative approch) ค่อย ๆ สร้างที่ละส่วนขึ้นมา จากนั้นดูผลลัพธ์และทำการปรับปรุงให้ดียิ่งขึ้นอย่างสม่ำเสมอ จนทำให้ได้ระบบ Continuous Deployment ในปัจจุบันขึ้นมาได้

ก่อนที่จะมีระบบ Continuous Deployment นั้น ทำการ deploy อย่างไร ?

นักพัฒนาทุกคนจะทำการ deploy การเปลี่ยนแปลงต่าง ๆ เอง โดยงานเหล่านี้คืองาน ad-doc หรืองานที่ไม่ได้เตรียมการไว้ล่วงหน้า ซึ่งจะทำการ run script การ rollout เอง หรือบางครั้งก็ต้องรอคนอื่น ๆ ที่จะ deploy ด้วย โดยขั้นตอนแรกทำการ deploy ไปยังเครื่อง production server เพียง 1 ตัว เพื่อทดสอบว่า การทำงานมันถูกต้องตามที่คาดหวังหรือไม่ ? ด้วยการ run ระบบ และเข้าไปดู logg ที่ server ถ้าผลจาก logg ไม่มีข้อผิดพลาดอะไร ก็จะทำการ deploy ไปยังเครื่องทั้งหมด โดยระบบ logging ของการ rollout/deploy จะเรียกว่า Sauron ชื่อคุ้น ๆ ไหม จากเรื่อง The Lord of the Rings นั่นเอง ปล. การทดสอบนั้นใช้ traffic จริง ๆ กันเลยนะ

ต่อมาเริ่มมีการเตรียมเครื่อง server สำหรับการทดสอบโดยเฉพาะเรียกว่า Canary server

ทำให้ควบคุมการ deploy และทดสอบได้ง่ายกว่า แต่การทดสอบเพียงตรวจสอบการ log การทำงานอย่างเดียวมันไม่เพียงพอ จึงได้เพิ่มให้ทำการ run ชุดการทดสอบ ซึ่งแต่ก่อนชุดการทดสอบมีอยู่แล้ว เพียงแต่ถูกทดสอบเฉพาะเครื่องของนักพัฒนาแต่ละคนเท่านั้น ดังนั้นจึงทำการติดตั้ง และ configuration Jenkins server ขึ้นมา เพื่อทำการทดสอบในทุก ๆ การเปลี่ยนแปลงที่ branch master และส่งผลการทดสอบไปยังเครื่อง Sauron ดังนั้นในตอนนี้เครื่อง Sauron จะรู้ว่า ในแต่ละการเปลี่ยนแปลงผ่านการทดสอบหรือไม่ ? ถ้าไม่ผ่านการทดสอบ การเปลี่ยนแปลงเหล่านั้นก็ไม่ถูกสนใจ หรือนำไป deploy ส่งผลทำให้การ deploy มีประสิทธิภาพยิ่งขึ้น คือ ไม่ deploy สิ่งผิด ๆ ขึ้นไป โดยที่ Facebook นั้น ใช้ Fabricator สำหรับการทำ code review ใช้ Sandcastle สำหรับสร้างระบบ Continuous Integration ซึ่งสามารถทำงานร่วมกับ Fabricator ได้ ซึ่ง Sandcastle จะทำการทดสอบทุก ๆ ครั้งที่มีการเปลี่ยนแปลง และส่งผลการทดสอบของการเปลี่ยนแปลงนั้นออกมา

จากนั้นเริ่มสร้างระบบการทำงานแบบอัตโนมัติขึ้นมา

เมื่อระบบการทำงานรู้แล้วว่า ในแต่ละการเปลี่ยนแปลงมีสถานะเป็นอย่างไร ต้องใช้คนมาตัดสินใจว่า จะต้องทำอย่างไรต่อไป เช่นตัดสินใจว่า ต้องทำการ rollout/deploy การเปลี่ยนแปลงใด เมื่อผ่านไปสักระยะ จะเริ่มเห็นรูปแบบการทำงาน และทำการสร้าง algorithm สำหรับตัดสินใจว่า rollout/deploy อะไรบ้างขึ้นมา โดยรูปแบบที่ได้คือ
  • ต้องผ่านการทดสอบทั้งหมด
  • จำนวนการเปลี่ยนแปลงต้องน้อย ๆ
แต่ถ้ามีจำนวนการเปลี่ยนแปลงที่ผ่านการทดสอบมาก ๆ จะเลือกมาเพียง 3 การเปลี่ยนแปลงเท่านั้น จากนั้นจำเป็นต้องมี algorithm สำหรับการตรวจสอบผลการ rollout/deploy ด้วย ว่าการทำงานมันสำเร็จ หรือ ล้มเหลว นั่นคือ ถ้ามีเครื่องที่ทำการ deploy ผิดพลาดเกิน 1% แสดงว่าการ deploy ครั้งนั้นล้มเหลว ดังนั้นเมื่อระบบบอกว่า การเปลี่ยนแปลง A ต้องทำการ deploy แล้วนะ ระบบการ deploy จะทำงานแบบอัตโนมัติ ดังนี้
  1. ทำการ deploy การเปลี่ยนแปลง A ไปยัง Canary server
  2. ทำการทดสอบอีกรอบ
  3. ทำการ deploy ไปยังทุก ๆ เครื่อง
โดยในช่วงแรก ๆ นั้นจะมีคนที่มาดูแลการ deploy แต่เมื่อผ่านไปสักระยะ ก็ไม่จำเป็นต้องมีคนมาดูแลอีกต่อไปแล้ว

แต่เส้นทางนี้ ใช่ว่าจะโรยด้วยกลีบกุหลาบ ปัญหาก็เพียบเช่นกัน !!

โดยมีข้อผิดพลาด และ บกพร่องไปมากมาย อาทิเช่น การทดสอบที่ผิดพลาดและล่าช้า นั่นคือ การทดสอบมันผิดพลาดได้ง่าย หรือ ไม่เสถียรนั่นเอง บางครั้งทดสอบผ่าน บางครั้งทดสอบผิดพลาด รวมทั้งการทดสอบมันช้า !! แทนที่ระบบการทำงานจะดี กลับสร้างปัญหาให้อีก มันขัดแย้งกับข้อดีของ Continuous Deployment เลยนะ ดังนั้นจึงต้องลงทั้งแรงกายและแรงใจ เพื่อปรับปรุงให้การทดสอบจากเดิมที่ใช้เวลา 12-15 นาที ให้เหลือเพียง 5 นาที รวมทั้งแก้ไขระบบ infrastructure เพื่อทำให้ระบบการทดสอบมีความน่าเชื่อถือ และ เสถียรขึ้น ส่วนเรื่อง backlog ยังอ่านไม่เข้าใจ ขอข้ามไปก่อน !!

มาดูเรื่อง Key Principle หรือแนวคิดของการสร้างกันหน่อยว่ามีอะไรบ้าง ?

1. Tests หรือชุดการทดสอบแบบอัตโนมัติ ต้องทำงานอย่างรวดเร็ว มีจำนวน test coverage ที่เหมาะสม ไม่จำเป็นต้อง 100% เนื่องจากการทดสอบต้องทดสอบอยู่บ่อย ๆ ทั้งก่อนส่งการเปลี่ยนแปลง ทั้งระหว่างการทำ code review ทั้งหลังจากการ deploy 2. Canary ต้องมี canary server เพื่อป้องกันการ deploy การเปลี่ยนแปลงที่แย่ ๆ ขึ้นไป แน่นอนว่า ไม่ได้ต้องการการทำงานที่สมบูรณ์แบบ แต่ต้องการเพียงข้อมูลเชิงสถิติแบบง่าย ๆ เพื่อช่วยวิเคราะห์ว่า แต่ละการเปลี่ยนแปลงส่งผลกระทบอย่างไร 3. Automate the normal case เราไม่สามารถให้ทำงานแบบอัตโนมัติได้ทุก ๆ กรณี ดังนั้น ให้สร้างระบบทำงานแบบอัตโนมัติ เฉพาะส่วนที่เรารู้ และเป็นกรณีแบบปกติทั่วไป แต่ถ้ามีเหตุการณ์หรือกรณีอะไรที่ดูแปลก ๆ หรือผิดปกติ ให้ระบบหยุดการทำงานทันที และให้คนเข้ามาจัดการต่อไป 4. Make people comfortable ปัญหาเรื่องคน มันคือกำแพงที่ยิ่งใหญ่และใหญ่ยิ่ง ของการสร้างระบบการทำงานแบบอัตโนมัติ เนื่องจากคนที่ทำงานอยู่ตรงนั้นก่อนหน้านี้ จะรู้สึกว่า ตัวเองไม่มีความสำคัญ และ ไม่สามารถควบคุมอะไรเองได้เลย ดังนั้นสิ่งที่ต้องทำก็คือ การทำงานของระบบต้องแสดงออกมาให้ทุกคนเห็นอย่างชัดเจน ว่ามีงานอะไรที่ทำเสร็จไปแล้วบ้าง ว่ามีงานอะไรที่กำลังทำอยู่บ้าง ว่าสิ่งที่ทำคืออะไร เพื่อทำให้เห็นว่า สิ่งต่าง ๆ เหล่านี้มันเข้ามาช่วยนะ 5. Expect bad deploys ต้องทำการระบุว่าการเปลี่ยนแปลงใดที่มันแย่ ๆ ให้เร็วที่สุด เพื่อทำให้เราสามารถ rollback ได้รวดเร็ว นั่นคือลดผลกระทบจากความผิดพลาดนั่นเอง
สิ่งต่าง ๆ เหล่านี้ทุกบริษัทสามารถนำไปสร้างเองได้เลย โดยที่ระบบ Continuous Deployment ไม่จำเป็นต้องมีความซับซ้อน ให้เริ่มจากวิธีการที่ง่าย ๆ เน้นทำตามแนวคิดทั้ง 5 ข้อ เพื่อทำการแก้ไข และ ปรับปรุงกันต่อไป

สุดท้ายแล้วระบบ Continuous Deployment ของ Instagram ยังคงพัฒนาต่อไป

แน่นอนว่าในตอนนี้ ระบบมันยังทำงานได้ดี และ เหมาะสมสำหรับสถานะปัจจุบันของระบบ แต่ก็ยังมีสิ่งต่าง ๆ มากมายที่ต้องทำการปรับปรุง ดังนี้ Keeping it fast เนื่องจากระบบของ Instgram มันโตขึ้นสูงมาก ๆ ทำให้จำนวนการเปลี่ยนแปลงสูงมากเช่นเดียวกัน ดังนั้นต้องการให้ระบบ rollout/deploy ให้เร็วที่สุดเท่าที่จะทำได้ วิธีการหนึ่งที่น่าจะเอาเข้ามาทำคือ การแบ่งการ rollout/deploy ออกเป็นหลาย ๆ สถานะ และสร้าง pipeline ของการทำงานขึ้นมา Adding canary เนื่องจากนำนวนการเปลี่ยนแปลงสูงขึ้น เครื่อง canary ก็ได้กลายเป็นปัญหาคอขวด ดังนั้นการเพิ่มเครื่อง canary จึงมีความสำคัญมาก More data สิ่งที่ต้องการคือ ข้อมูล เพื่อทำให้ระบบรู้ว่า การเปลี่ยนแปลงใด ๆ มันแย่ได้ดีขึ้น เพื่อขจัดสิ่งที่แย่ ๆ ออกไปจากสายการ rollout/deploy เช่น logging การทำงานของแต่ละ feature กันไปเลย Improving detection ทำการปรับปรุงการตรวจสอบหลังจากทำการ rollout/deploy ออกไปแล้ว แทนที่จะทำเพียงการทดสอบ และ deploy ไปทุก ๆ เครื่อง ก็น่าจะทำการแบ่งการ deploy ออกเป็น region หรือ cluster จากนั้นทำการตรวจสอบและตัดสินใจว่า จะทำการ deploy ต่อไปหรือไม่

เป็นอย่างไรบ้างสำหรับระบบ Continuous Deployment ของ Instagram

น่าจะพอทำให้เห็นว่า การ rollout/deploy ทุก ๆ การเปลี่ยนแปลง มันเป็นเรื่องที่เป็นไปได้ และช่วยลดความเสี่ยงจากข้อผิดพลาดต่าง ๆ ด้วยสิ อะไรที่มันเจ็บก็ให้ทำบ่อย ๆ กันนะครับ ต้องสร้างระบบขึ้นมา โดยมีพื้นฐานอยู่บนสิ่งที่เรียกว่า คุณภาพ และความไว้เนื้อเชื่อใจกันนั่นเอง รวมทั้งต้องค่อย ๆ สร้างขึ้นมาและเรียนรู้ไปกับมัน แต่คำถามที่น่าจะอยู่ในใจของใครหลาย ๆ คนคือ แล้วแต่ละการเปลี่ยนแปลงมันเป็นอย่างไร ? เป็น feature ? เป็น bug ? เป็น .... ผมก็ไม่รู้เหมือนกัน แต่เชื่อว่าแต่ละการเปลี่ยนแปลงต้องมีคุณค่าสิ !!
↧

สรุปผลการสำรวจเรื่องการปรับปรุงคุณภาพของ code

April 14, 2016, 2:26 am
$
0
0

code-quality

code-quality ข้อมูลจากผลแบบสำรวจ State of code quality 2016 โดย Smartbear.com โดยผู้ทำแบบสำรวจเป็น software developer และ tester กว่า 600 คน เป้าหมายเพื่อสอบถามว่า มีความพึงพอใจกับคุณภาพของ code ที่พัฒนาขึ้นมาหรือไม่ ? และทำการปรับปรุงคุณภาพขึ้นมาได้อย่างไร ? ซึ่งเป็นสิ่งที่สำคัญอย่างมากในการพัฒนา software ดังนั้นมาดูผลสรุปที่น่าสนใจกันนิดหน่อย

เริ่มด้วยกว่า 70% ของผู้ทำแบบสอบถามนั้น

พอใจอย่างยิ่งสำหรับคุณภาพของ code ที่พัฒนาขึ้นมา แสดงผลดังรูป code-quality-01

ต่อมาจึงเริ่มถามว่า ทีมพัฒนาปรับปรุงคุณภาพของ code กันอย่างไร ?

ถึงทำให้ทีมพัฒนารู้สึกพอใจกับคุณภาพของ code ซึ่งได้รับคำตอบดังนี้
  • Code review 27%
  • Unit testing 19%
  • Functional testing 13%
  • Continuous Integration 12%
  • Integration testing 9%
แสดงผลดังรูป code-quality-02 สิ่งที่เราได้รับรู้ก็คือ Code Review และ Unit testing มันส่งผลอย่างมากต่อคุณภาพของระบบงาน โดยทั้งสองเรื่องมันไม่ใช่สิ่งแปลกใหม่อะไรเลยในการพัฒนา software แต่มันทำให้เราเห็นชัดขึ้นว่า ทีมพัฒนา software เริ่มมีความรู้ความเข้าใจแล้วว่า ทั้ง Code Review และ Unit testing มันมีความสำคัญอย่างไร !!
ปล. แล้วในประเทศไทยล่ะ เห็นความสำคัญและลงมือทำหรือยัง ?

เมื่อถามลงในรายละเอียดต่อไปอีกว่า Code Review มันมีประโยชน์อะไรบ้าง ?

ได้รับคำตอบกลับมาดังนี้
  • 90% ตอบว่าช่วยปรับปรุงคุณภาพของ code ให้ดียิ่งขึ้น
  • 72% ตอบว่าช่วยแบ่งปันความรู้กันระหว่างทีม
  • 52% ตอบว่าช่วยปรับปรุงการดูแลรักษา code ให้ดีและง่ายขึ้น
  • 56% ตอบว่าทำให้ง่ายต่อการแนะนำและสอน developer ที่มีประสบการณ์น้อย ๆ
  • 49% ตอบว่าทำให้เกิด coding standard ที่ทุกคนยอมรับและปฏิบัติตาม
  • 45% ตอบว่าทำให้การทำงานร่วมกันง่ายขึ้น
แสดงผลดังรูป code-quality-03

ถามต่อไปอีกว่า ทำ Code Review บ่อยไหม ?

คำตอบที่ได้รับมันน่าสนใจอย่างมากคือ 72% บอกว่าการทำ Code Review เป็นงาน ad-hoc และ 62% บอกว่าทำ Code Review อย่างน้อยเดือนละ 1 ครั้ง แสดงผลดังรูป code-quality-04 โดยรูปแบบในการทำ Code Review นั้นจะมี 2 แบบคือ
  • เป็นรูปแบบเหมือนกับการประชุม
  • นำเครื่องมือต่าง ๆ มาใช้งาน
จาก 2 แบบนี้พบว่า ทีมที่มีการนำเครื่องมือมาช่วย จะทำ Code Review บ่อยกว่าเป็นอย่างมาก จะเห็นได้ว่า Code Review มันมีประโยชน์อย่างมากต่อการพัฒนา software ทั้งเรื่องของคุณภาพ ทั้งความเข้าใจ ทั้งการทำงานด้วยกัน ทำให้ระบบงานที่พัฒนาออกมามีคุณภาพที่ดีขึ้นมาก

แต่ทีมก็ยังพบเจอปัญหาและอุปสรรคสำหรับการทำ Code Review

ประกอบไปด้วย
  • 66% คืองานเยอะล้นมือ
  • 44% คือใกล้ deadline แล้ว
  • 39% คือคนไม่พอ
แสดงผลดังรูป code-quality-05 ซึ่งถือว่าเป็นอีกหนึ่งความท้าทายขององค์กร และ ทีมพัฒนา ว่า ถ้าต้องการปรับปรุงคุณภาพของระบบงานแล้ว คุณก็ต้องพยายามลดปัญหาและอุปสรรคเหล่านี้ลงไป เพราะว่า ปัญหาและอุปสรรคเหล่านี้ มันไม่ใช่เรื่องแปลกใหม่ในการพัฒนา software เลยนะ สามารถอ่านเพิ่มเติมได้ที่ State of code quality 2016
↧

วิวัฒนาการจาก Spaghetti Driven Development ถึง Test-Driven Development

April 15, 2016, 4:09 am
$
0
0

Spaghetti-Future-Processing

Spaghetti-Future-Processing Spaghetti Driven Development มันเป็นอย่างไร ? เป็นอีกหนึ่งวิธีการของการพัฒนา software !! โดยมีขั้นตอนดังนี้
  • เขียน code โครตแย่ออกมา
  • ทำการ refactor code ให้ code ดีขึ้นและเข้าใจได้ง่ายขึ้น
  • ทำการเขียนชุดการทดสอบ
ฟังแล้วมันดูดีมาก แต่ส่วนใหญ่มักจะทำเพียงขั้นตอนแรกเท่านั้น จึงทำให้เกิด Spaghetti code ออกมาจำนวนมาก และไม่มีใครกล้าแตะต้องมัน ใจร้ายกันมาก ๆ ดังนั้นจึงมีวิธีการและแนวคิดไหม่ ๆ ขึ้นมา เพื่อทำให้ code ออกมามีคุณภาพ หนึ่งในนั้นคือ Test-Driven Development (TDD) เพื่อความเข้าใจมากขึ้นมาวิวัฒนาการของสิ่งเหล่านี้กันดีกว่า

เริ่มในยุค 80

เป็นยุคของ Spaghetti Driven Development นั่นคือเขียน code แย่ ๆ ยุ่งเหยิงออกมาก่อน จากนั้นทำการ refactor code จนกระทั่ง code เข้าใจได้ง่ายขึ้น และเขียน test ออกมา ถามว่า มี automated test ไหม ? ตอบได้เลยว่าไม่ ลองคิดถึงตัวเราเองตอนสมัยเรียนการเขียน program สิ คุณเรียนรู้ว่า จะเขียน code อย่างไรเท่านั้นใช่ไหม ?

ต่อมาในยุค 80 ถึง 90

เริ่มมีตำแหน่ง Analyst/Programmer เพื่อทำการวิเคราะห์และออกแบบระบบ ก่อนเริ่มเขียน programg เล็กน้อย ซึ่งนี่คือจุดกำเนิดของ Small Up Front Design !! มีขั้นตอนการทำงานดังนี้
  1. ทำการออกแบบระบบ
  2. ทำการเขียน program
  3. ทำการทดสอบแบบ manual
ในยุคนี้คำสั่ง goto ใน code เป็นสิ่งที่ดีมาก ๆ แน่นอนว่าสำหรับยุคนี้ภาษา COBOL มันไม่ใช่ Legacy code นะ

ต่อมาในยุค 90 ถึงปี 2000

เป็นยุคแห่ง Big Design Up Front !! เพราะว่ามีขั้นตอนจำนวนมาก รวมทั้งในแต่ละขั้นตอนเรามีตำแหน่ง และ แผนกแยกกันทำงาน เช่น
  • Business Analyst
  • Software Analyst
  • Programmer
  • QA/Tester
  • Database Administrator
  • System Admin
เริ่มมีการทดสอบแบบอัตโนมัติ (Automated Testing) แต่เป็นการทดสอบหลังจากที่เขียน program เสร็จแล้วทั้งหมด บ่อยครั้งที่มีทีมทดสอบแยกออกมาจากทีมพัฒนา !! ผลที่ตามมาคือ ปัญหามากมาย เป็นยุคที่ Object-Oriented Programming และ Design ได้รับความนิยมสูงมาก ๆ และทำให้เกิด Design Pattern ขึ้นมา เริ่มมีการพูดถึง Functional Programming กันด้วยนะ แถมมีแนวคิด DevOps ขึ้นมา ซึ่งเป็นแนวคิด Back to basic กลับไปในยุคก่อนหน้า !!

ต่อมาในช่วงต้นของยุค 2000

เริ่มกลับไปสู่ Small Design Up Front กลับมาสู่การทำงานแบบเป็นรอบสั้น ๆ (Interative and Incremantal Development) แต่ยังเขียนชุดการทดสอบแบบอัตโนมัติหลังจากเขียน program เสร็จ มีขั้นตอนการทำงานดังนี้
  1. เขียนโปรแกรม
  2. ทำการ refactor code
  3. ทำการเขียนชุดการทดสอบแบบอัตโนมัติ

มาถึงยุคปัจจุบันกันบ้าง

มีแนวคิดต่าง ๆ ที่ได้รับการยอมรับและนิยมนำมาใช้งาน ประกอบไปด้วย
  • Test-Driven Development (TDD)
  • Behaviour-Driven Development (BDD)
  • Acceptance Test-Driven Development (ATDD)
โดยแนวคิดต่าง ๆ นั้นถูกแนะนำมาจากแนวคิด Continuous Delivery และ Continuous Integration มีขั้นตอนการทำงานดังนี้
  1. เริ่มต้นจากการคิด และ เข้าใจภาพรวมของปัญหา
  2. ทำการพัฒนาเป็นรอบสั้น ๆ
  3. ก่อนที่จะเขียน program ให้เริ่มด้วยการเขียนชุดการทดสอบแบบอัตโนมัติ
  4. ทำการเขียน program เพื่อให้ชุดการทดสอบผ่าน
  5. ทำการ refactor code
  6. สนกลับไปเขียนชุดการทดสอบแบบอัตโนมัติใหม่
  7. วนแบบนี้ไปเรื่อย ๆ
ซึ่งเป็นวิธีการพัฒนาที่เป็นธรรมชาติอย่างมาก แต่มันก็ไม่ใช่เรื่องง่ายเช่นกัน ดังนั้นจึงต้องทำการฝึกฝนเพื่อให้ชำนาญ มาถึงตรงนี้น่าจะพอทำให้เราเห็นวิวัฒนาการ จาก Spaghetti Driven Development ถึง Test-Driven Development กันได้ชัดเจนขึ้น

สุดท้ายแล้ว TDD มันไม่ใช่สิ่งใหม่

แต่มันคือความสามารถที่นักพัฒนาทุกคนต้องมี และไม่ใช่สิ่งที่จะเอามาอ้างว่า ถ้าทำ TDD แล้วต้องใช้เวลาเพิ่ม !!!
คำถามตอนนี้เราพัฒนา software กันแบบไหนระหว่าง Spaghetti Driven Development ? Test-Driven Development ?
สรุปเนื้อหามาจากหนังสือ Test-Driven Development by Examples
↧
Search

สิ่งที่ต้องเสียไปและได้รับกลับมา จากการทดสอบแบบอัตโนมัติ

April 15, 2016, 8:19 am
$
0
0

making-test-automation-work-in-agile-projects-2012-27-638

good-bad ก่อนจะนำการทดสอบแบบอัตโนมัติเข้ามาประยุกต์ใช้งานนั้น สิ่งที่ควรต้องพิจารณาก่อนคือ ประโยชน์ที่จะได้รับ และ ค่าใช้จ่ายที่ต้องลงทุนไป ซึ่งทั้งสองอย่างนี้ต้องมีความสมดุลกันนะ โดยทำการสรุปไว้ดังนี้

ประโยชน์ที่จะได้รับ

  • ช่วยให้วิเคราะห์ requirement ได้ง่าย
  • เชื่อมั่นในการ refactor code
  • เมื่อเกิดปัญหาสามารถรู้ได้อย่างทันท่วงที (Fast feedback)
  • สามารถทดสอบซ้ำๆ ได้ง่าย ประหยัดเวลา และคนทำงาน
  • เป็นเอกสารที่เชื่อถือได้
  • เป็นคู่มือสำหรับ tester ซึ่งสามารถมาดูและศึกษา เป็นทางหนึ่งในการทำ exploratory testing อีกด้วย

Cost หรือ สิ่งที่ต้องเสียไป (Effort หรือ Time == Cost)

  • เวลาในการเรียนรู้เพื่อที่จะเขียนชุดการทดสอบ
  • เวลาในการเขียนชุดการทดสอบ
  • เวลาในการรอผลการทดสอบ
  • เวลาสำหรับการดูแลรักษาชุดการทดสอบ

ประโยชน์นั้นเป็นสิ่งที่ดี แต่อย่าประเมินค่าใช้จ่ายต่ำโดยเด็ดขาด

ยิ่งถ้าเป็นทีมที่อยู่ในช่วงเริ่มนำมาใช้งานด้วยแล้ว ยิ่งต้องเสียเวลาในการเรียนรู้สูง ทั้งการเขียนให้ได้ ทั้งการเขียนให้ดี มีประโยชน์ ไม่เช่นนั้นอาจจะทำให้เกิดความผิดพลาดต่างๆ ขึ้นมา ส่งผลให้การดูแลรักษาสูงขึ้นเช่นกัน แสดงดังรูป Hump of pain making-test-automation-work-in-agile-projects-2012-27-638

ดังนั้นก่อนเริ่มนำมาใช้งานควรที่จะมีการพูดคุย

เรื่องประโยชน์และค่าใช้จ่ายต่างๆ ของการทดสอบแบบอัตโนมัติ ซึ่งในการพูดคุยควรให้ทุกๆ ฝ่ายที่เกี่ยวข้องเข้ามาพูดคุยกัน เพื่อให้ทุกคนได้แบ่งมุมมองต่างๆ ต่อการทดสอบแบบอัตโนมัติอย่างเท่าเทียมกัน
ปล. เป็นที่เข้าใจตรงกันว่า ทุก ๆ การเปลี่ยนแปลงล้วนมีความกลัวเกิดขึ้นเสมอ แต่ถ้ามันเป็นสิ่งที่ดีมีประโยชน์ ก็ควรที่จะต้องทำให้ความกลัวนั้นน้อยลง
นั่นคือ การลงมือทำในสิ่งที่กลัวซะ เช่น
  • ถ้ากลัวว่าจะต้องใช้เวลาในการเรียนรู้นาน ก็เริ่มเรียนรู้ซะ
  • ถ้ากลัวว่าจะต้องใช้เวลาเพิ่มในการพัฒนา ก็เริ่มปรับปรุงความสามารถของตัวเองซะ
  • ถ้ากลัวว่าจะต้องมีค่าใช้จ่ายเพิ่มเติมจากเดิม ก็ให้เอาตัวเลขในปัจจุบันทั้งการพัฒนา การทดสอบ และ การแก้ไข bug และ การทำ re-test, regression test มาเป็นตัวตั้งต้น จากนั้นจึงทำการจับวัด ลองคิดดูสิว่า ถ้าเอาข้อมูลของมะยมมาเทียบกับแตงโม มันก็คงจะถูกหรอกนะ !!
  • ถ้ากลัวว่าทีมไม่มีความรู้ความสามารถเพียงพอ ก็จัด training กันภายในซะ ไม่เช่นนั้นก็ไม่หาคนที่รู้มาสอน

สุดท้ายถ้ากลัว ก็จงลงมือทำ

พร้อมด้วยตัวชี้วัดที่สามารถวัดค่าได้เป็นช่วงสั้น ๆ ไป อย่าลงมือทำอะไรโดยไม่มีเป้าหมายที่ชัดเจน อย่าลงมือทำอะไรโดยที่ทุกคนที่เกี่ยวข้องไม่เห็นด้วย และ ไม่รู้เรื่อง Reference Website http://blog.mattwynne.net/2013/11/18/costs-and-benefits-of-test-automation/ http://agilecoach.typepad.com/agile-coaching/2011/03/embrace-a-skeptic.html http://www.amazon.com/Fearless-Change-Patterns-Introducing-Ideas/dp/0201741571 http://www.slideshare.net/lisacrispin/making-test-automation-work-in-agile-projects-2012
↧
↧

ลองใช้ความสามารถ Java 8 ใน Android N Preview กันหน่อย

April 18, 2016, 1:05 am
$
0
0

android-java8-01

android-java8-01 ทีมพัฒนา Android เพิ่งปล่อย Android N Preview ออกมา (ก็นานอยู่นะ) ซึ่งมีการเพิ่มเติมและปรับปรุงความสามารถต่าง ๆ มากมาย หนึ่งในนั้นคือ feature ต่าง ๆ จาก Java 8 สำหรับ Jack compiler เท่านั้นนะ ดังนั้นเมื่อมีของใหม่ ๆ ออกมาให้ลอง จะพลาดได้อย่างไร มาลองใช้งานกันดูสักหน่อย ถ้าใครยังไม่รู้จัก Jack compiler แนะนำให้ไปอ่าน blog เรื่อง ทำความเข้าใจกาทำงานของ Jack and Jill ใน Android

Android ไม่ได้สนับสนุน feature ของ Java 8 ทั้งหมดนะ !!

ประกอบไปด้วย ถ้าอยากรู้ feature ลอง Java 8 มันเยอะไหม แนะนำให้ดู VDO นี้นะ New feature in Java 8

ต่อมาคือการติดตั้ง

โดยจะต้องทำการติดตั้ง software ในการใช้งาน
  • Android Studio 2.1 ตอนนี้ผมใช้ Preview 2
  • Android N Preview SDK
  • JDK 8
จากนั้นทำการ update project และเริ่มเขียนกันเลย สามารถดูขั้นตอนการติดตั้งได้ที่นี่ แสดงดังรูป android-java8-02 อย่าลืมตรวจสอบ Java SDK ด้วยนะครับ ต้องเป็น Java 8 นะ android-java8-03

จากนั้นทำการเปิดการใช้งาน feature ต่าง ๆ ของ Java 8 กับ Jack compiler

โดยปกติขั้นตอนการทำงานเป็นดังนี้
  1. javac ทำการแปลงจาก .java เป็น .class
  2. dx ทำการแปลงจาก .class เป็น .dex
ส่วน Jack นั้นทำการแปลงจาก .java เป็น .jack และสุดท้ายเป็น .dex การทำงานภายในจึงต่างกัน และ ไม่สนับสนุนการแก้ไขและวิเคราะห์ byte code นะ เช่นพวก Jacoco และ Mockito ไม่สามารถใช้งานร่วมกับ Jack ได้ !! ซึ่งหวังว่าก่อนที่จะออกเป็น preview version มา คงจะทำการแก้ไขและปรับปรุงปัญหานี้ให้ดีขึ้น !!

เริ่มด้วยการ configuration ของไฟล์ build.grade ก่อน

ให้ทำการเปิดการใช้งาน Jack compiler และ กำหนด version ของ java ซะ จากการลองใช้งานพบว่า ต้องกำหนดค่าของ minSdkVersion และ targetSdkVersion เป็น 24 ถึงจะสามารถ run ได้นะ !! แสดงตัวอย่างดังนี้ [gist id="4c3e0b0ff918cc4e51d65879ff82afd8" file="build.gradle"] ปล. อย่าลืมปิด Instant Run ของ Android Studio ด้วย เพราะว่ายังไม่สนับสนุน !! ปัญหาเยอะจริง ๆ แสดงดังรูป android-java8-04

เมื่อทุกอย่างพร้อม ก็มาเขียน code กันหน่อยดีกว่า

Default และ static interface method เป็น feature ที่ช่วยลดจำนวน utility method/class ต่าง ๆ ลงไป เนื่องจากเราสามารถสร้าง default method ใน interface ได้เลย แสดงดังตัวอย่าง [gist id="4c3e0b0ff918cc4e51d65879ff82afd8" file="Money.java"] ลองใช้งาน Lambda expression เป็น feature ที่พักพัฒนาหลาย ๆ คนชอบ เนื่องจากมันช่วยทำให้ code สั้น อ่านเข้าใจได้ง่าย ซึ่งมันมีประโยชน์อย่างมาก ใน version ก่อนหน้านี้ ถ้าต้องการเขียน Lambda expression ต้องใช้เครื่องมือและ library ช่วย เช่น Lambda support for Android แสดงดังตัวอย่าง [gist id="4c3e0b0ff918cc4e51d65879ff82afd8" file="MainActivity.java"] ตัวอย่าง source code เอาไว้ที่ Github::Up1::AndroidNPreviewWithJava8 สวัสดี Java 8 นะ ขั้นตอนการ build ช้าน่าดู !! android-java8-05

สุดท้ายแล้ว

นี่เป็นเพียงตัวอย่างเล็ก ๆ น้อย ๆ สำหรับการใช้งาน Java 8 ในการพัฒนา Android application แต่มันก็ยังเป็นเพียง Preview version เท่านั้น ทำให้เราเห็นข้อดี ข้อเสีย และปัญหาต่าง ๆ มากมาย รวมทั้งข้อจำกัดของ Jack compiler ที่น่าจะมีการแก้ไขก่อนออก version เต็ม ดังนั้น Android developer ไม่น่าพลาดที่จะทดลองด้วยตัวเองนะครับ
↧

สรุปการแบ่งปันเรื่อง Introduction to NoSQL

April 18, 2016, 10:38 am
$
0
0

nosql-01

nosql-01 วันนี้มีโอกาสไปแบ่งปันความรู้เรื่อง NoSQL ให้กับนักศึกษาคณะไอทีลาดกระบัง โดยเนื้อหาจะเป็นความรู้พื้นฐานต่าง ๆ ที่ควรรู้และเข้าใจ ก่อนนำ NoSQL ไปใช้งาน มาเริ่มกันเลย

เริ่มด้วยการทำความเข้าใจกับ RDBMS (Relational DataBase Management System)

ว่า RDBMS นั้นเป็น data model หนึ่งเท่านั้น ดังนั้น Database != RDBMS นะ ต้องเข้าใจว่า ACID consistency model คืออะไร มีความสำคัญอย่างไร ?
  • Atomicity
  • Consistency
  • Isolation
  • Durability
การจัดการข้อมูลที่จัดเก็บใน RDBMS คือ SQL (Structured Query Language) โดยที่ RDBMS มันสามารถทำงานได้ดีเป็นปกติ และได้รับความนิยมนำไปใช้งานกันมากมาย

แต่เมื่อการมาถึงของยุคที่มีข้อมูลเกิดขึ้นมาจำนวนมาก และ รวดเร็ว

นั่นคือโลกที่คนนิยมใช้ internet นั่นคือโลกที่มีการใช้งาน Social network จำนวนมาก นั่นคือโลกที่มีข้อมูลเกิดขึ้นมาจำนวนมาก บางคนบอกว่ามันคือยุคของ Big Data ซึ่งข้อมูลรูปแบบเหล่านี้นั้น RDBMS ไม่สามารถรองรับได้ดีเพียงพอ ถามว่ารองรับได้ไหม ตอบว่าได้ แต่ต้องใช้แรงเยอะ แต่ต้องใช้ค่าใช้จ่ายเยอะ nosql-02 ดังนั้นยักษ์ใหญ่แห่งวงการ internet คือ Google และ Amazon จึงสร้างระบบจัดการข้อมูลของตัวเองขึ้นมา Google สร้าง Bigtable Amazon สร้าง Dynano และนี่คือจุดเริ่มต้นของเครื่องมือจัดการข้อมูล หรือ database ชนิดใหม่ ๆ ที่นอกเหนือจาก RDBMS

เมื่อเกิด Database ชนิดใหม่ ๆ ที่ไม่ใช่ Non-relational database ขึ้นมาเยอะ ๆ

จึงได้เกิด meetup หนึ่งขึ้นมา มีเป้าหมายเพื่อพูดคุยสิ่งต่าง ๆ
  • คุยเรื่อง Non-relational database
  • Open-source
  • Distributed database
โดยชื่อของ meetup เกิดมาเพื่อต้องการสร้าง hashtag ของ meetup ครั้งนี้ ซึ่งได้ชื่อว่า #nosql ขึ้นมา สุดท้ายจึงได้ชื่อ meetup ว่า NoSQL meetup ผู้ที่เข้าร่วมงานครั้งนี้ ประกอบไปด้วย
  • ผู้พัฒนา Voldemort
  • ผู้พัฒนา Cassandra
  • ผู้พัฒนา Dynamite
  • ผู้พัฒนา HBase
  • ผู้พัฒนา Hypertable
  • ผู้พัฒนา CouchDB

ผลจาก meetup ครั้งนี้ได้ข้อสรุปที่น่าสนใจดังต่อไปนี้

1. คุณลักษณะของ NoSQL ประกอบไปด้วย
  • Non-relational database
  • ส่วนใหญ่เป็น Open-source
  • Cluster-friendly นั่นคือโดยปกติจะรองรับการทำงานแบบ distributed
  • Schema-less
  • ใช้สำหรับการพัฒนาระบบ web ใหม่ ๆ
2. Data model ต่าง ๆ ของ NoSQL ประกอบไปด้วย
  • Key-value
  • Document
  • Column-family
  • Graph
nosql-04

จากนั้นอธิบายเรื่อง Consistency ของ NoSQL

NoSQL จะใช้ BASE consistency model ซึ่งย่อมาจาก
  • Basic Availability คือ database ต้องทำงานอยู่ตลอดเวลา
  • Soft state คือการเขียนข้อมูลจะไม่บันทึกไปยังทุก ๆ เครื่องพร้อมกัน
  • Eventual consistency คือเมื่อผ่านไปสักระยะหนึ่งข้อมูลจะถูกต้องในทุก ๆ เครื่อง delay จะมีหน่วยเป็น milisecond

ยังไม่พอนะ NoSQL จะถูกสร้างมาจากแนวคิดของ CAP Thorem

ประกอบไปด้วย
  • Consistency
  • Availability
  • Partition tolerance
ซึ่งให้เลือกมาเพียง 2 ตัวเท่านั้น แสดงดังรูป nosql-03 โดยที่ CA คือ RDBMS ดังนั้นจึงเหลือเพียง 2 ทางเลือกคือ CP และ AP ซึ่งเป็นทางเลือกของการสร้าง NoSQL ชนิดต่าง ๆ นั่นเอง จะเลือก CP หรือ AP นั่นคือ สิ่งที่คุณต้องตัดสินใจ ว่าระบบของคุณจะเลือกอะไรระหว่า Consistency กับ Availability ส่วน Partition tolerance มันเป็นความสามารถที่ NoSQL ทุกตัวต้องทำได้

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

RDBMS จะตายไปหรือไม่ ? NoSQL จะเข้ามาแทนที่ RDBMS หรือไม่ ? คำตอบคือ ไม่ เนื่องจากเราสามารถนำเอา RDBMS และ NoSQL มาใช้งานร่วมกัน ดังนั้นในหนึ่งระบบสามารถมี database ที่หลากหลาย ตามความต้องการของการทำงานต่าง ๆ ได้ นั่นจึงเป็นที่มาของคำว่า Polyglot Persistence สุดท้ายให้เลือกเครื่องมือที่เหมาะสมกับงานนั้น ๆ แสดงว่าเราต้องเข้าใจทั้งระบบงาน และ เครื่องมือ โดย Slide อยู่ที่นี่ http://www.slideshare.net/up1/introduction-to-nosql-61023856 ขอขอบคุณสำหรับพื้นที่ในการแบ่งปันครับ
↧

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

April 22, 2016, 8:15 am
$
0
0

git-workflow-gitflow

git-workflow-gitflow วันนี้มีโอกาสไปแบ่งปันเรื่อง Branching Strategy ในงาน Thailand Agile Coaching Meetup 2/2559 ตอน Game Game และ Game ซึ่งจัดที่บริษัท THiNKNET โดยเนื้อหาเป็นแนวคิดสำหรับ การจัดการความเสี่ยงอย่างหนึ่งในนั้นคือ เรื่อง Branching แต่สิ่งที่ไม่เคยคิดกันต่อก็คือการ Merging มีรายละเอียดคร่าว ๆ ดังต่อไปนี้

เริ่มต้นด้วยปัญหาที่ได้รับจาก Cargo Cult

หนึ่งวิธีในการแก้ไขก็คือ การทำ branching ของ source code ใน Version Control System คำถามคือ แล้วเราจะทำการ branching แบบไหนล่ะ ? คำตอบของหลาย ๆ คนก็คือ ทำตามบริษัทใหญ่ ๆ สิ หรือบริษัทที่มันแจ่ม ๆ ยกตัวอย่างเช่น บางคนบอกว่าทำตาม Google สิ แสดงดังรูป CC51F790-D070-47ED-84DA-6C8D617F72BA แต่คนส่วนใหญ่กลับไม่อ่านข้อนี้ !! Screen Shot 2559-04-22 at 2.28.45 PM คำถามต่อไปคือ แนวทางเหล่านี้มันเหมาะสมกับระบบงานของเราหรือไม่ ? แนวทางเหล่านี้มันเหมาะสมกับทีมของเราหรือไม่ ? แนวทางเหล่านี้ได้รับการสนับสนุนจากฝ่าย management หรือไม่ ? ถ้าได้รับคำตอบที่ดี ก็น่าจะทำให้ผลออกมามันดี แต่ส่วนใหญ่จะได้ผลตรงกันข้าม !!

มาดูกันหน่อยว่ารูปแบบของการ Branching มีอะไรบ้าง ?

  • Integration branch หรือ Main/Trunk/Master
  • Release branch
  • Feature/task branch
  • Shelving branch
  • Fork and pull request
  • No branch (feature toggle)

โดยสรุปแล้วรูปแบบของการ braching ที่ได้พูดมี 3 แบบ

ประกอบไปด้วย
  1. No branching
  2. Branching by feature
  3. Branching by release
จะเลือกวิธีการไหน ต้องตอบให้ได้ว่า วิธีการที่ทำอยู่นั้นเป็นอย่างไร ? ปัญหาในปัจจุบันคืออะไร ? ปัจจุบันนโยบายของบริษัทเป็นอย่างไร ? (องค์กรเป็นแบบไหน branching ก็เป็นแบบนั้น) คำตอบจากคำถามเหล่านี้ จะนำไปสู่แนวทางการแก้ไขต่อไป ส่วนการนำไปใช้งานจริง ๆ นั้น อาจจะนำแนวคิดต่าง ๆ มาใช้งานร่วมกัน (Hybrid approach) และสุดท้ายก็นำเครื่องมือต่าง ๆ มาช่วยเหลือ เพื่อลด overhead ต่าง ๆ ลงไป
ดังนั้นให้เข้าใจความต้องการของตัวเอง หรือทำความเข้าใจกับปัญหาที่พบก่อนนะครับ
ข้อคิดสะกิดใจ ถ้าทำไปแล้วรู้สึกว่ามันลำบาก หรือ มีปัญหามากกว่าเดิม แสดงว่า สิ่งที่ทำอยู่ไม่น่าจะถูกต้อง หรือ เหมาะสมนะ ต้องทำการแก้ไข และ ปรับเปลี่ยนต่อไปอย่างต่อเนื่อง โดย slide อยู่ที่นี่ http://www.slideshare.net/up1/working-with-branch
↧

คำแนะนำสำหรับการทดสอบ Web application แบบอัตโนมัติด้วย Selenium

April 23, 2016, 1:05 am
$
0
0

selenium-testing2

selenium-testing วันนี้มีโอกาสแลกเปลี่ยนแนวทางการทดสอบ Web application โดยเครื่องมือที่ได้รับความนิยมอย่างมาก ก็คือ Selenium เนื่องจากไม่เพียงแค่ฟรีเท่านั้น แต่ยังมีความสามารถมากมายให้ใช้แบบครบครัน รวมทั้งทดสอบผ่าน browser ชนิดต่าง ๆ ได้หมด ไม่ว่าจะเป็น Firefox, Google Chrome และ Internet Explorer ยังไม่พอนะ เรื่อง community ก็ใหญ่มาก ถ้าไม่เชื่อลองไปค้นหาผ่าน Google ดูนะ !! ดังนั้น ถ้ามีปัญหาก็หาวิธีการแก้ไขไม่ยากเลย (ใช้ keyword ให้ถูกนะ) แต่สำหรับมือใหม่การใช้งาน Selenium มันอาจจะไม่ใช่เรื่องที่ง่ายเลย ดังนั้นจึงทำการสรุปคำแนะนำในการใช้งานที่ดีไว้นิดหน่อย
ปล. ปัจจุบันแนะนำให้ใช้งาน Seleniun 2 หรือ Web Driver กันนะครับ และที่สำคัญ framework และ library ต่าง ๆ ที่ทำการทดสอบระบบ web ส่วนใหญ่ก็ใช้ Selenium กันทั้งนั้น

1. ผลการทดสอบต้อง Stable หรือมีความเสถียรที่สูง

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

2. การทดสอบต้องเร็ว

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

3. เรียนรู้การใช้งาน Page Object เพื่อทำให้การทดสอบ Stable มากขึ้น

เนื่องจากเราต้องเขียนชุดการทดสอบขึ้นมา ซึ่ง Selenium นั้นจะอ้างถึง id ของ element ต่าง ๆ บน browser ดังนั้นให้ลองคิดดูว่า ถ้าในหนึ่งหน้าจอมีจำนวน test case จำนวนมาก การอ้างถึง id เหล่านั้นก็บ่อยมาก บางครั้งเขียนซ้ำแล้วซ้ำเล่าไปตลอด นั่นแสดงว่า เกิดการอ้างอิง id จากหลาย ๆ ที่ คำถามคือ ถ้าเกิดการเปลี่ยนในหน้านั้นขึ้นมาล่ะ จะเกิดอะไรขึ้น ? คำตอบคือ การทดสอบจำนวนมาก ๆ จะทำงานไม่ถูกต้อง ดังนั้น จะต้องทำการแก้ไข แต่จำนวนที่ต้องแก้ไขมันอาจจะเยอะมาก ๆ !!! นี่คือ ปัญหาของการดูแลรักษาชุดการทดสอบ ดังนั้น หนึ่งในวิธีการคือ Page Object นั่นเอง

คำแนะนำสำหรับการนำไปใช้งาน

เนื่องจากเป็นการทดสอบผ่าน User Interface ของระบบงาน ดังนั้นแน่นอนว่า การทดสอบในทุก ๆ test case ต้องใช้เวลาสูงมากขึ้นเรื่อย ๆ และต้องทำการทดสอบซ้ำ ๆ อย่างต่อเนื่อง ดังนั้น สิ่งที่ขาดไม่ได้คือ ระบบ Continuous Integration รวมทั้งการทดสอบต้องทำงานแบบขนานกันอีกด้วย (Parallel Testing) เพื่อเพิ่มความเร็วในการทดสอบ หรือบางครั้งเครื่องทดสอบไม่มีหน้าจอแสดงผล ดังนั้นจึงต้องทำการทดสอบผ่าน Virtual screen แทน ซึ่งเรามักจะเรียกว่า Headless ทำให้การทดสอบเร็วขึ้นมาอีกด้วย แต่ก็มีข้อเสียคือ ทีมพัฒนาไม่เห็นการทำงานนั่นเอง !!
ผลลัพธ์ที่ได้กลับมาก็คือ ความเร็วของการทดสอบ ซึ่งทำให้เรารู้ว่า ระบบทำงานถูก หรือ ผิดพลาดตรงไหนได้อย่างรวดเร็ว (Fast feedback)

ปิดท้ายด้วยคำเตือน

ในช่วงแรก ๆ ของการนำ Selenium มาใช้งานนั้น มันอาจจะดูดีอย่างมาก ทั้งในแง่ของความเร็ว ทั้งในแง่ของประโยชน์จากการทดสอบ เนื่องจากจำนวนการทดสอบยังน้อย เนื่องจากขนาดของระบบยังไม่ใหญ่มาก แต่เมื่อเวลาผ่านไปสัก 2-6 เดือน มักจะพบเจอปัญหามากมายเกี่ยวกับการทดสอบ ตัวอย่างเช่น ผลการทดสอบที่ไม่ Stable เลย บางครั้งทำงานได้อย่างถูกต้อง บางครั้งทำงานผิดพลาด รวมทั้งใช้เวลาในการทดสอบนานมาก ๆ ส่งผลให้หลาย ๆ ทีมไม่อยากจะใช้งานมันอีกต่อไป !! แต่เราลองกลับมาคิด วิเคราะห์ แยกแยะ กันหน่อยไหมว่า ปัญหาเหล่านี้มันเกิดมาจากสาเหตุอะไรกันบ้าง ?
  • Architecture ของระบบมันห่วยหรือไม่ ?
  • ระบบงานมันซับซ้อนหรือไม่ ?
  • ระบบงานมันช้าหรือไม่ ?
  • จำนวน test case มันเยอะเกินความจำเป็นหรือไม่ ?
  • ความสามารถของทีมเป็นอย่างไร ?
  • และอื่น ๆ อีกมากมาย
ดังนั้นให้ทุกคนที่เกี่ยวข้องต้องใส่ใจกับผลการทดสอบ ให้การทดสอบมันทำงานได้อย่างถูกต้องอยู่อย่างเสมอ ถ้าเมื่อใดก็ตาม ที่การทดสอบผิดพลาด สิ่งที่ต้องทำกันก็คือ หยุด !! เพื่อมาช่วยกันแก้ไขให้มันทำงานได้อย่างถูกต้อง
อย่าบอกว่า เดี๋ยวก็มีคนมาแก้ไข โดยเด็ดขาด อย่าคิดว่า มันไม่ใช่งานของเรา โดยเด็ดขาด มิเช่นนั้น คุณกำลังจะเดินเข้าสู่ด้านมืดของการใช้งาน Selenium นะ !! สุดท้ายก็จะเลิกใช้กันไป หรือทำให้มันมีเท่านั้นเอง ...
↧
↧

ว่าด้วยเรื่องของ Data Intelligence (Data IQ)

April 24, 2016, 1:18 am
$
0
0

data-iq

data-iq จากหนังสือ The Big Data Revolution ได้อธิบายถึงที่ไปที่มาของ Big Data ได้อย่างน่าสนใจ โดยหนึ่งในนั้นคือ เรื่อง Data Intelligence ซึ่งเรียกสั้น ๆ ว่า Data IQ ดังนั้นจึงทำการสรุปไว้นิดหน่อย

ก่อนที่จะทำอะไรกับข้อมูลที่มีอยู่ในมือ ต้องทำความเข้าใจ

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

Data Intelligence นั้นสามารถแบ่งเป็นกลุ่มได้ดังนี้

การแบ่งกลุ่มเพื่อทำให้เราเข้าใจเกี่ยวกับข้อมูล และความต้องการต่าง ๆ มากยิ่งขึ้น รวมทั้งทำให้เราเข้าใจความต้องการอีกด้วย ซึ่งจะเรียกว่า Data IQ แสดงดังรูป data-iq2 คำอธิบาย เริ่มจาก Static Report เป็นรายงานทั่วไปที่จะตอบคำถามต่าง ๆ ที่เราต้องการ ซึ่งเป็นสิ่งที่เฉพาะเจาะจงมาก ๆ โดยใน Data IQ นั้นใช้ประโยชน์ได้น้อยที่สุด และเป็นงานที่น่าเบื่อที่สุด แต่เป็นสิ่งที่ใช้งานมากที่สุด !!! Dashboard ทำการแสดงข้อมูล และ คำตอบต่าง ๆ ที่เราต้องการ และทำการ update ข้อมูลเหล่านั้นแบบ real-time แต่ข้อมูลที่แสดงใน dashboard นั้น จะตอบคำถามเท่าที่เราตั้งไว้ตั้งแต่แรก ซึ่งไม่สามารถเปลี่ยนแปลงได้ ทำให้มันไม่ค่อยยืดหยุ่นสักเท่าไรนัก Outlier หรือ ข้อมูลที่ผิดปกติ เราสามารถค้นหาและตรวจจับข้อมูลเหล่านี้ได้ เพื่อนำมาวิเคราะห์หาโอกาส และ คำเตือนต่าง ๆ ได้ บางครั้งข้อมูลเหล่านี้อาจจะมีขนาดใหญ่มาก ๆ หรือเล็กมาก ๆ จนไม่สามารถมองเห็นด้วยตา มันทำให้เราเข้าใจข้อมูลที่มีอยู่ในมือมากยิ่งขึ้น Correlation หรือ ความสัมพันธ์ของข้อมูล เราสามารถค้นหาและตรวจจับข้อมูลเหล่านี้ได้ เพื่อค้นหาข้อมูลที่มีความสำคัญ เช่นเมื่อข้อมูลมีการเปลี่ยนแปลงจะส่งผลกระทบอย่างไรบ้าง ? แนวโน้มของข้อมูลเป็นอย่างไร ? รูปแบบของข้อมูลเป็นอย่างไร ? Prediction หรือ การทำนายสิ่งต่าง ๆ ที่จะเกิดขึ้นในอนาคต เป็นสิ่งที่มีประโยชน์อย่างมาก แต่มักมีข้อจำกัดที่มาจากข้อมูลนั่นเอง เช่นข้อมูลที่นำมาใช้ในการทำนายไม่ถูกต้อง ไม่ครบ หรือ เลือกข้อมูลผิด เป็นต้น แต่ถ้าสามารถแก้ไขปัญหาเหล่านี้ไปได้ จะทำให้การ Prediction มีประโยชน์อย่างสุด ๆ ไปเลย Pattern recognition แปลเป็นไทยคือ การรู้จำรูปแบบ !! เป็นคำที่พูดถึงกันอย่างกว้างขวาง และ มีประสิทธิภาพอย่างสูง ซึ่งมันประกอบไปด้วยแนวคิดต่าง ๆ ดังต่อไปนี้
  • Outlier detection
  • Correlation information
  • Prediction
ใช้สำหรับการแจ้งเตือนผู้ใช้งานในเรื่องต่าง ๆ ที่ให้ความสนใจ ทั้งฝั่ง business และ customer

ดังนั้นก่อนอื่น ๆ คุณต้องตอบให้ได้ก่อนว่า ต้องการอะไรกันแน่ ?

เพื่อทำให้เข้าใจว่า เราต้องใช้ Data Intelligence รูปแบบใดบ้าง แต่ส่วนใหญ่มักนำหลาย ๆ ชนิดมาทำงานร่วมกัน โดยที่ฝั่งขวาบนของ Data IQ นั้น เป็นส่วนที่มีประโยชน์ และ ประสิทธิภาพอย่างมาก แต่ก็มาพร้อมกับความยาก และ ซับซ้อนเช่นกัน เนื่องจากต้องการทั้งคน เทคโนโลยี และ เครื่องมือต่าง ๆ เพื่อสร้างระบบขึ้นมา สุดท้ายแล้ว ลองถามตัวเราเองสิว่า เรายังทำเพียงแค่สร้างรายงานทั่วไปกันอยู่อีกหรือ ? 61896572
↧

TDD :: เริ่มเขียนด้วย Failing test หมายถึงอะไร ? ทำไปทำไม ?

April 25, 2016, 12:42 am
$
0
0

Failed test or exam and disappointed woman

[caption id="attachment_9259" align="alignnone" width="713"]Failed test or exam and disappointed woman Failed test or exam and disappointed woman[/caption] คำถามที่น่าสนใจเกี่ยวกับ Test-Driven Development (TDD)
  • การเริ่มเขียนด้วย Failing test หมายถึงอะไร ?
  • ทำไมต้องเริ่มด้วย Failing test ด้วย ?
ลองมาหาคำตอบให้ตัวเองกันหน่อยไหม ? แน่นอนว่า เป็นวิธีการที่ต้องทำให้เราคิดก่อนว่า (Think before Act) เรากำลังจะทำอะไร เรากำลังจะแก้ไขสิ่งใด นั่นคือ เรารู้ และ ควบคุมตัวเราเองว่า กำลังทำอะไรอยู่ และในเวลาหนึ่ง ๆ ควรทำ หรือ แก้ไขปัญหาเพียงปัญหาเดียวเท่านั้น

ในการพัฒนา software ส่วนใหญ่มักจะมีขั้นตอนการทำงานดังนี้

  1. ทำการอ่าน และ เขียนความต้องการขึ้นมา บางครั้งอาจจะเรียกว่า เป็นความเพ้อฝัน
  2. ทำการเขียน code เพื่อให้ได้ตามสิ่งที่ต้องการ
  3. ทำการทดสอบ code เหล่านั้นว่าตรงตามที่ต้องการหรือไม่
ประเด็นที่สำคัญคือ กว่าเราจะรู้ว่า code ที่เขียนขึ้นมานั้น มันทำงานถูกต้องหรือไม่ ? มันส่งผลกระทบอะไรหรือไม่ ? ต้องใช้เวลาที่ยาวนานมาก ๆ เช่น เป็นเดือน เป็นปี !! ซึ่งเป็นปัญหาหลักของการพัฒนา software เลย

ดังนั้นเราจึงต้องการวิธีการที่ทำให้รู้ผลกระทบจากการเปลี่ยนแปลงให้เร็วที่สุด ?

เช่น
  • เมื่อแต่ละ feature เสร็จ
  • เมื่อแต่ละ class เสร็จ
  • เมื่อแต่ละ function/method เสร็จ
  • เมื่อแต่ละบรรทัดของ code เสร็จ
สิ่งต่าง ๆ เหล่านี้เราเรียกว่าพฤติกรรมของการทำงาน ว่ามันเป็นอย่างไรบ้าง ทั้งทำงานถูกหรือไม่ ทั้งกระทบต่อส่วนอื่น ๆ หรือไม่ โดยแต่ละระบบก็มีพฤติกรรมที่แตกต่างกันไป มาดูตัวอย่างดีกว่า

ตัวอย่างการเขียนระบบตรวจสอบรูปแบบของ email

แน่นอนว่า ก่อนที่จะเริ่มพัฒนา สิ่งที่คุณต้องรู้คือ ความต้องการของสิ่งนั้น จากตัวอย่างคือ การตรวจสอบรูปแบบของ email ดังนั้นสิ่งที่ต้องรู้คือ email ที่ถูกต้อง และ ไม่ถูกต้องเป็นอย่างไร จากนั้นต้องมีตัวอย่างของข้อมูลในแต่ละกรณีอีกด้วย มาถึงตรงนี้สิ่งที่เราต้องได้ก็คือ test case ต่าง ๆ แต่ละ test case ประกอบไปด้วย requirement หรือ business requirement และ ข้อมูลตัวอย่างในการทดสอบเสมอ จากนั้นมาเริ่มขั้นตอนการเขียน code ดีกว่า ซึ่งมีลำดับความคิดที่แตกต่างกันไป แล้วแต่คนนะครับ แต่ล้วนมีเป้าหมายเดียวกัน ซึ่งผมจะทำการเขียน code ด้วยแนวคิดดังนี้
  • Email ไม่ถูกต้อง ถ้า email เป็นค่า NULL ผลการทำงานจาก function นี้คือ FALSE
  • Email ไม่ถูกต้อง ถ้า email เป็นค่าว่าง ผลการทำงานจาก function นี้คือ FALSE
  • Email ไม่ถูกต้อง ถ้า email ไม่มี @ เช่น somkiat-gmail.com ผลการทำงานจาก function นี้คือ FALSE
  • Email ถูกต้อง เช่น somkiat@gmail.com ซึ่งต้องทำการเขียน code เพื่อหาว่า email มี @ จริง ๆ นะ ผลการทำงานจาก function นี้คือ TRUE
  • Email ไม่ถูกต้อง ถ้า email มี domain name ที่ไม่ถูกต้อง เช่น somkiat@gmail.comx ผลการทำงานจาก function นี้คือ FALSE
  • Email ไม่ถูกต้อง ถ้า email มี domain name ที่ไม่มีอยู่จริง เช่น somkiat@gmaillll.com ผลการทำงานจาก function นี้คือ FALSE
และทำแบบนี้ไปเรื่อย ๆ จนกว่า code ของการตรวจสอบ email เป็น code ที่เรามั่นใจ และ แก้ไขปัญหาต่าง ๆ ได้ครบ หรือทำไปจนกว่า ไม่สามารถคิด test case อื่น ๆ ได้อีกต่อไปแล้ว และการทำงานของ test case ทั้งหมดต้องผ่านด้วยนะครับ

สังเกตุไหมว่า พฤติกรรมของการพัฒนาระบบเป็นอย่างไร ?

เราทำการทดสอบในแต่ละ test case เราทำการทดสอบในทุก ๆ test case นั่นคือ เรารู้เสมอว่า code ที่เราเขียนขึ้นมานั้น ทำงานถูกต้องตามที่ต้องการหรือไม่ และที่สำคัญมีการทำ regression testing อยู่เสมอ เพื่อทำให้เรามั่นใจว่า code ที่เขียนขึ้นมา มันไม่ส่งผลกระทบต่อส่วนการทำงานอื่น ๆ นะ
สิ่งที่เห็นได้ชัดเจนก็คือ ในแต่ละ test case มันทำให้เกิด code ชุดเล็ก ๆ ขึ้นมาเรื่อย ๆ และสุดท้ายจะทำให้ได้ code ที่แก้ไขปัญหาทั้งหมดของเรา
เมื่อเราไม่รู้จะเขียน test case อะไรต่อไป หรือคิด test case ไม่ออกแล้ว กลับมาปรับปรุง code ให้ดีขึ้นกว่าเดิม (Refactoring) สุดท้ายแล้วก็เป็นอันว่า งานเสร็จสิ้นแล้ว !!!
ซึ่งมันเป็นวิธีการพัฒนาระบบงานที่เรียบง่ายมาก ๆ แต่นักพัฒนาส่วนใหญ่ไม่ทำกัน และมักจะทำตรงกันข้ามเสมอ มันแปลกดีนะ !!
↧
Search

ตัวอย่างของ code ที่ขัดแย้งต่อแนวคิด Single Responsibility Principle (SRP)

April 26, 2016, 2:41 am
$
0
0

duplication

duplication วันนี้เห็น code ของ Android app ตัวหนึ่ง ซึ่งมี code ที่น่าสนใจ และ น่าศึกษา นั่นก็คือ code ที่ใช้งาน RecyclerView แน่นอนว่า ต้องทำงานร่วมกับ Adapter ของมันนั่นเอง ทำให้คิดถึงแนวคิดของ SOLID หนึ่งในนั้นคือ S = Single Responsibility Principle (SRP) มาดู code กันดีกว่า

RecyclerView นั้นมันช่วยทำให้

การแสดงผลข้อมูลมันง่ายและยืดหยุ่นขึ้นมาก ซึ่งต้องทำงานร่วมกับ RecyclerView Adapter เพื่อนำข้อมูลที่เราต้องการมาแสดงผลใน View ต่อไป โดยจะมีการทำงานที่ method onBindViewHolder() หรืออาจจะไปทำที่ ViewHolder เลยก็ได้ แต่ code ตัวอย่างจะทำงานอยู่ใน method onBindViewHolder() ถ้าปฏิบัติตามแนวคิดของ Single Responsibility Principle (SRP)
ใน Adpater จะต้องทำงานเพียงอย่างเดียว นั่นก็คือ ทำการ mapping ข้อมูลที่จะทำการแสดงผลบน View เท่านั้น
แต่นี่คือ code ที่เรามักจะเขียนกันขึ้นมา !! ซึ่งขัดแย้งกับแนวคิด SRP อย่างมาก [gist id="bfa175694d859fb831e2216c5b6fef95" file="OrderRecyclerAdapter.java"]

คำถามที่หนึ่ง มันขัดแย้งกับ SRP อย่างไร ?

ใน code ก็ทำการ mapping ข้อมูลของ order เพื่อมาแสดงผลนะ มันไม่น่าจะผิดหรือขัดแย้งกับ SRP นะ ? ลองพิจารณา code ใหม่สิ ว่าทำอะไรบ้าง ?
  • ทำการคำนวณราคารวมของ order
  • ทำการคำนวณราคาก่อนแสดงผล
  • ทำการจัดรูปแบบของราคาก่อนแสดงผล
ซึ่งในความเป็นจริงหน้าที่ของ Adpater มันทำอะไร ? ลองกลับไปอ่านจากขางบนนะ !!
ดังนั้น Adapter มันทำงานเยอะไปหรือเปล่า ? และการทำงานเหล่านั้น มันควรเป็นหน้าที่ของ Adapter หรือไม่ ?

คำถามที่สอง ปัญหาคืออะไร ?

นักพัฒนาก็มักจะบอกว่า code มันนิดเดียวเอง ไม่เป็นไรหรอกนะ ไม่มีปัญหาหรอกนะ !! code มันก็ทำงานได้อย่างถูกต้องนะ แต่เดี๋ยวก่อน ...
Class หรือ method ที่มันมีหน้าที่การทำงานมากกว่า 1 อย่างนั้น มันมักจะเกิดปัญหาตามมาเสมอ
ลองคิดดูสิว่า ถ้ารูปแบบการแสดงผลของราคาทำแบบนี้แล้ว มันจะเกิด code ที่ซ้ำซ้อนหลาย ๆ ที่หรือเปล่านะ ? จะมี code สำหรับคำนวณราคาต่อ order หลาย ๆ ที่หรือเปล่านะ ? นั่นคือเกิด Duplication code ขึ้นมา (Duplication is evil !!) มันไม่น่าจะเป็นเรื่องที่ดีสำหรับการพัฒนา software นะ

คำถามที่สาม แก้ไขอย่างไรดีล่ะ ?

จากตัวอย่างนี้ก็ไม่ยากเท่าไร นั่นคือ ทำการแยกส่วนการทำงานต่าง ๆ เหล่านั้น ออกมาจาก Adapter ซะ

คำถามที่สี่ แล้วจะย้ายการทำงานไปไว้ที่ไหนล่ะ ?

สำหรับการคำนวณราคาของ order ควรย้ายไปไว้ที่ class Order สิ สำหรับการจัดการรูปแบบการแสดงผลของราคา ควรย้ายไปไว้ที่ class สำหรับจัดการรูปแบบของค่าเงิน เช่น class CurrencyFormatter และถูกเรียกใช้จาก class Order ต่อไป แสดง code ใน Adapter หลังจากการแก้ไข code ให้เป็นไปตาม SRP [gist id="bfa175694d859fb831e2216c5b6fef95" file="After_OrderRecyclerAdapter.java"] เป็นไงล่ะครับ ง่ายไหม ? ตอบได้เลยว่า ปัญหานี้มันง่ายนะครับ แต่การทำงานจริงมันยากกว่านี้เสมอ ปล. นี่ก็มาจาก code จริง ๆ นะครับ

สุดท้ายแล้ว

สำหรับนักพัฒนาอย่าลืมแนวคิด SOLID กันนะครับ หนึ่งแนวคิดที่สำคัญคือ S = Single Responsibility Principle ลองกลับไปดู class และ method ที่เราสร้างขึ้นมา แล้วลองตั้งคำถามสิว่า
  • Class และ method มันทำงานอะไรบ้าง ?
  • Class และ method มันจะถูกเปลี่ยนแปลงด้วยเหตุผลอะไรบ้าง ?

คำถามสุดท้าย SRP มันยากไหม ?

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

TDD มันคือหนึ่งความท้าทายของคุณและทีม !!

April 27, 2016, 7:02 pm
$
0
0

practice

practice คำถามที่มักได้ยินมาเสมอ ฟังดูแล้ว TDD (Test-Driven Development) มันเป็นแนวคิดที่ดีนะ แต่เราควรนำมาใช้หรือเปล่านะ ? มันเหมาะสมกับเราหรือเปล่านะ ? ก่อนที่จะตอบนั้น ผมแนะนำให้ทดลองก่อนไหม ว่าแนวคิด และ เทคนิคของ TDD มันช่วยปรับปรุง code และ การพัฒนาระบบงานหรือไม่ ?
คำถามต่อมาคือ แล้วจะทดลองกันอย่างไรดีล่ะ ?
คำตอบสำหรับผมคือ
  • ในช่วงเวลาหนึ่ง ๆ ให้ทำหรือแก้ไขปัญหาเพียงอย่างเดียว
  • แต่ละ commit หรือ การเปลี่ยนแปลงต้องเล็ก ๆ
  • ลองบังคับตัวเองให้ฝึกแบบนี้ดูกัน

จากนั้นลองนำแนวคิดนี้ไปแนะนำ และ พาทีมลองทำกันดูไหม

ง่าย ๆ คือ
  • ใน commit แรกให้ทำการเขียน test
  • ใน commit ที่สองให้ทำการเขียน code เพื่อทำให้ test ผ่าน
แต่ว่ามันยากเกินไปสำหรับนักพัฒนาหรือเปล่านะ ? ดังนั้นลองไปถามทีมดูสิว่า เราจะนำแนวคิด และ เทคนิคของ TDD มาใช้งานกันไหม ? คำตอบที่มักได้ยินก็คือ
  • เขียนก็ได้นะ แต่ขอเวลาเพิ่ม !!
  • การพัฒนาจะช้ากว่าเดิมนะ !!
  • แค่เขียน code ให้ทำงานได้ และ เสร็จก็ยากแล้วนะ นี่ต้องเขียน test อีกไม่รอดแน่นอน !!
  • ต้องเพิ่มค่าใช้จ่ายเพิ่มขึ้นมากนะ 2-5 เท่าตัวเลย !!
ดังนั้นถ้าต้องการให้พัฒนาเร็ว ๆ ก็อย่าเอาแนวคิด TDD มาใช้เลยนะ !!

คำถามที่น่าสนใจคือ ทำไมการเขียน code โดยไม่มี test ถึงเร็วกว่าล่ะ ?

คำตอบคือคำถาม ลองตอบดูสิ
  • เราทำการฝึกฝนแนวคิด TDD แล้วหรือยัง ?
  • เราทำการฝึกฝนแนวคิด TDD เพียงพอแล้วหรือยัง ?
  • เราทำการฝึกฝนแนวคิด TDD บ่อยเพียงใด ? ทุกวันหรือไม่ ?
หรือว่าเราไม่เคยฝึกฝนเลย !!
เพราะว่าถ้าเราเรียนรู้ และ ฝึกฝนสิ่งใหม่ ๆ แล้ว มันจะทำให้เราทำงานอื่น ๆ ได้ช้าลง หัวหน้า และ ฝ่าย management ก็กดดันมากอีก ดังนั้น อย่าไปฝึก อย่าไปเรียนรู้อะไรใหม่เลยนะ ทำให้มันเสร็จก่อนเถอะ !! ปล. ที่บอกว่าเขียนเร็วนั้น ได้รวมเวลาแก้ bug หรือยัง ? ได้รวมเวลาที่ต้องรอการทดสอบหรือยัง ?

ดังนั้นก่อนที่จะเลือกใช้หรือไม่นั้น ให้ทำการทดลองก่อนดีไหม

เพื่อทำให้
  • คุณและทีมได้ฝึกฝนร่วมกัน เพื่อเรียนรู้ไปด้วยกัน
  • คุณและทีมได้ลองทำอะไรในรูปแบบใหม่นั่นคือ ลองเขียน test ก่อน จากนั้นจึงเขียน code
  • คุณและทีมได้ลองคิดว่า เราควรที่จะทำอะไรก่อนดี
  • ทำให้คุณเข้าใจการ review code เพราะว่า คุณต้องทำการอ่านและเขียน code ทั้ง test code และ production code อยู่เสมอ
  • ทำการเรียนรู้ว่าเราควรแยก What ออกจาก How นั่นคือ การเขียน test บอกว่าคุณกำลังจะทำอะไร และการเขียน code เพื่อให้ test ผ่านนั่นคือ การบอกว่าคุณทำอย่างไร สุดท้ายสิ่งที่ได้กลับมาคือ เอกสารสำคัญการอธิบาย code

คำถามต่อมาคือ แบบนี้มันไม่ทำให้เราช้าหรือ ?

ตอบได้เลยว่า ช้า แต่มันจะช้าในช่วงเริ่มต้น เพราะว่าคุณต้องเรียนรู้ในสิ่งใหม่ เพราะว่าคุณต้องเรียนรู้ในสิ่งที่ไม่เคยทำ เพราะว่าคุณต้องเรียนรู้ขั้นตอนการทำงานใหม่ที่แตกต่างไปจากเดิม ซึ่งทุกอย่างมันคือ การลงทุน (Effort = Cost) เพื่อทำให้คุณมีความมั่นใจในการพัฒนา ว่าทำงานได้ถูกต้องและไม่ส่งผลกระทบต่อส่วนอื่น เพื่อทำให้ code มีเอกสารอธิบาย เพื่อทำให้ code มีการปรับปรุงอยู่ตลอดเวลา โดยที่เราไม่กลัว โดยการลงทุนนั้นมันย่อมมีความเสี่ยงเสมอ แต่ว่ามันก็น่าลองนะเออ
มาถึงตรงนี้ คุณพร้อมที่จะปรับปรุงและเปลี่ยนแปลงแล้วหรือยัง ? เพราะว่ายังมีอีกหลายสิ่งที่ต้องทำการปรับปรุงนะ
↧
↧

Robot Framework :: ทำการทดสอบระบบที่มีหลายภาษาอย่างไรดี ?

April 28, 2016, 7:14 pm
$
0
0

robot

robot คำถามที่น่าสนใจสำหรับการนำ Robotframework มาใช้ทดสอบ web application ที่มีหลายภาษาคือ จะทำการทดสอบอย่างไรดี ? จะทำการวางโครงสร้างอย่างไรดี ?

โดยหนึ่งในแนวทางที่ผมใช้อยู่เป็นดังนี้

สิ่งที่ใช้คือทำการแยกไฟล์ resource ออกเป็น folder แต่ละภาษาไปเลย ถ้าต้องการจะทดสอบภาษาอะไรนั้น ก็ให้ส่งข้อมูลผ่าน parameter ตอน run test ได้เลย แต่วิธีการนี้ใช้สำหรับระบบที่ต่างกันเพียงข้อความต่าง ๆ เท่านั้น ถ้าขั้นตอนการทำงานเปลี่ยนแปลงในแต่ละภาษา ก็ตัวใครตัวมัน เพราะว่า ต้องเขียนชุดการทดสอบเพิ่มเอาเอง !!

วิธีการก็ไม่ยาก

เริ่มด้วยการสร้างไฟล์ resource แยกตามภาษา โดยในแต่ละไฟล์จะมี variable ชื่อเดียวกัน ต่างเพียงข้อมูลเท่านั้น ดังนี้ ภาษาไทย (th/message.txt) [gist id="feacf6fb772f5b64fc57def7032e698c" file="thai.txt"] ภาษาอังกฤษ (en/message.txt) [gist id="feacf6fb772f5b64fc57def7032e698c" file="en.txt"] ในไฟล์ทดสอบเป็นอย่างไร ? ให้ทำการรับข้อมูลมาจาก parameter ที่ส่งมาได้เลย ซึ่งจากตัวอย่างตั้งชื่อว่า LANG เพื่อใช้บอกว่าให้ไปดึงข้อมูลจากไฟล์ resource ของภาษาอะไร ดังนี้ [gist id="feacf6fb772f5b64fc57def7032e698c" file="test.txt"] จากนั้นก็ทำการทดสอบดังนี้ [code] //ภาษาไทย $pybot --variable LANG:th test.txt //ภาษาอังกฤษ $pybot --variable LANG:en test.txt [/code] เพียงเท่านี้ก็สามารถจัดการข้อมูลของแต่ละภาษาได้แล้วครับ สำหรับการเปลี่ยนภาษาของระบบงานล่ะ ทำอย่างไร คำตอบคือ ลองทำดูสิ !! ตัวอย่าง code อยู่ที่ Github::Up1 https://github.com/up1/demo-robot-with-multiple-language
คำถาม แล้วคุณล่ะทำการทดสอบกันอย่างไรบ้าง ? มาแบ่งปันกันหน่อยสิ
↧

สรุปสิ่งที่แบ่งปันเรื่อง Secure Test-Driven Development

April 30, 2016, 12:55 am
$
0
0

stdd

stdd วันนี้ไปแบ่งปันเรื่อง Secure Test-Driven Development ในงาน IT Connect :: MiSS Day จัดที่มหาวิทยาลัยเกษตรศาสตร์ ซึ่งสามารถสรุปเนื้อหาหลัก ๆ ได้ดังนี้

ปัญหาของการพัฒนา Software ในปัจจุบัน

โดยเฉพาะเรื่องของ Security testing ที่มักจะอยู่ในช่วงท้ายของการพัฒนา หรือ ก่อนทำการ deploy ระบบงาน และมักจะมีทีมแยกมาทำการทดสอบโดยเฉาะ ผลที่ได้รับมามันไม่ช่วยทำอะไรให้ดีขึ้นเลย !! คำถามคือ ทำการทดสอบอะไรบ้าง ? หรือ สอย อะไรบ้าง ? ถ้าถามทางทีมพัฒนา ก็จะได้คำตอบว่า ไม่รู้ หรือ น่าจะทดสอบ 1, 2, 3 ... สุดท้ายก็ไม่ผ่านการทดสอบ บางครั้งทีมพัฒนาก็ไม่อยากส่งระบบงานไปให้ทดสอบอีกต่างหาก !! สิ่งเหล่านี้มันสะท้อนถึงขั้นตอนการทำงานนั่นเอง

ดังนั้นเราต้องการแนวทางอื่น ๆ สำหรับการพัฒนา

หนึ่งในนั้นคือ Iterative and Incremental approach นั่นคือ การทำงานเป็นรอบสั้นและสร้างระบบให้โตขึ้นเรื่อย ๆ เพื่อต้องการ feedback loop ที่รวดเร็วที่สุดเท่าที่จะทำได้ เพื่อให้รู้ปัญหาได้อย่างรวดเร็ว จะได้แก้ไขได้ทันท่วงที โดยในขั้นตอนการทำงานนั้น ต้องมีการทดสอบต่าง ๆ เข้าไปในแต่ละ feature เสมอทั้ง
  • Unit testing
  • Integration testing
  • Acceptance testing
  • Security testing
  • Performance testing
สิ่งที่เน้นอย่างมากคือ Unit testing ทำตามแนวคิด TDD (Test-Driven Development) นั่นก็คือ
  • จะไม่เขียน production code ใด ๆ เลย จนกว่าจะมี test case ที่มัน fail
  • ลด code ที่ซ้ำซ้อนลงไป (Reduce duplication code)

เมื่อเรานำแนวคิดนี้มาใช้กับเรื่อง Security มันจะกลายเป็น Secure Test-Driven Development (STDD)

แต่มิใช่ว่า จะทำได้เลย เนื่องจากมีปัญหา และ ความท้าทายมากมาย เช่น
  • ทีมพัฒนาไม่มีความรู้เรื่องของ Security !! เช่น OWASP Top 10 Risks ทั้งระบบ web และ mobile
  • ทีมพัฒนาไม่มีความรู้ว่าจะสร้าง test case ที่เกี่ยวกับ security อย่างไร !!
  • ไม่มี process ที่เป็นทางการออกมาเท่าไร แต่ก็มีนะ เช่น Secure Development process ของ Microsoft และ OWASP Software Security Assurance Process เป็นต้น

จากปัญหาเหล่านี้ เราจึงต้องปรับปรุงกระบวนการมากมาย

แต่ให้เริ่มทำทีละอย่างและปรับปรุงอย่างต่อเนื่อง (Continuous Improvement) ถ้าทีมพัฒนาขาดความรู้แล้ว จำเป็นต้องมีการ training จากผู้เชี่ยวชาญ ถ้าทีมพัฒนาไม่สามารถคิดหรือสร้าง test case ได้แล้ว จำเป็นต้องมีการคุยและสรุปจากคนหลาย ๆ กลุ่ม เพื่อให้เห็นความต้องการในแต่ละมุมมอง เช่น
  • Business
  • Development
  • QA/Tester
  • Security
  • Performance
  • Operation
เพื่อให้ได้ข้อมูลที่ครอบคลุม เพื่อนำมาสร้าง test case ต่อไป โดย test case เหล่านั้น เราจะเรียกว่า Acceptance test ใช้สำหรับการตรวจสอบ และ ส่งมอบ feature นั้น ๆ ที่สำคัญทำให้ทุกคนเข้าใจความต้องการของ feature นั้น ๆ ตรงกัน

สุดท้ายเรื่องแนวคิดที่ต้องปรับเปลี่ยนไป เช่น

  • แต่ละคนแต่ละฝ่ายที่เกี่ยวข้องต้องคุยกัน และ ทำงานร่วมกัน (Communication and Collaboration)
  • ทำงานเป็นทีม ทีมจะต้องประกอบไปด้วยคนที่มีความสามารถต่าง ๆ สำหรับการสร้างระบบ
  • ต้องการ feedback ในเรื่องต่าง ๆ อย่างรวดเร็ว ทั้งการเพิ่ม และ การเปลี่ยนแปลง ว่าทำงานได้ตรงตามความต้องการหรือไม่ ?
  • การทดสอบเรื่องต่าง ๆ มันคือ กิจกรรมที่เกิดขึ้นอยู่ตลอดเวลา อย่ารอทดสอบตอนท้ายของการพัฒนา เราต้องการรู้ให้รวดเร็วที่สุด !!
เรื่องที่สำคัญมาก ๆ คือ คุณภาพนั้นไม่สามารถต่อรองได้ Quality Build-in อยู่ในทุกส่วนเสมอ
คุณพร้อมที่ปรับปรุงแล้วหรือยัง ? Slide :: Secure Test-Driven Development http://www.slideshare.net/up1/secure-testdriven-development
↧

แปลเรื่อง Infrastructure as Code

April 30, 2016, 8:13 am
$
0
0

infrastructure-as-code

infrastructure-as-code หลังจากอ่านบทความเรื่อง Infrastructure as Code ที่ bliki ของคุณ Martin Fowler เป็นอีกหนึ่งแนวคิด และ เทคนิคที่น่าสนใจอย่างมาก สำหรับจัดการ infrastructure ของระบบ ทั้ง server และ network ยิ่งในยุคของ Cloud computing ด้วยแล้วยิ่งน่าสนใจขึ้นมาอีก จึงนำมาแปล และ สรุปไว้นิดหน่อย

Infrastructure as Code คืออะไร ?

เป็นวิธีการสำหรับการกำหนดและสร้าง server และ network ต่าง ๆ ขึ้นมาด้วย source code เป็นงานที่สร้างความเจ็บปวดให้กับการพัฒนาและติดตั้ง software เนื่องจากเรามักจะทำการติดตั้ง และ configuration พวก server และ network แบบ manual เอง !!
ดังนันวิธีการนี้จะช่วยลดปัญหาและความเจ็บปวดลงไปอย่างมาก
โดยการสร้าง environment ต่าง ๆ จะอยู่ใน source code infrastructure-as-code-01 นั่นหมายความว่า เราสามารถทำการตรวจสอบขั้นตอนการทำงานได้ เราสามารถทำการสร้างซ้ำแล้วซ้ำอีกได้ และต้องมีขั้นตอนการทดสอบระบบได้อีกด้วย มันสำคัญมาก ๆ เพราะว่าคนส่วนใหญ่มักละเลย เพื่อทดสอบว่าสิ่งที่สร้างขึ้นมามันถูกต้อง และ ระบบงานทำงานได้ถูกต้องบน environment ที่สร้างขึ้นมาหรือไม่ ? สิ่งต่าง ๆ เหล่านี้มันสนับสนุนแนวคิดของ Continuous Delivery (CD) นั่นเอง โดย Infrastructure ในปัจจุบันนิยมใช้บริการผ่านระบบ Cloud computing ซึ่งเป็นแบบ Dynamic Infrastructure หมายความว่า เราสามารถสร้าง server ด้วยคำสั่งง่าย ๆ ซึ่ง server ที่สร้างขึ้นมามักจะเป็น Virtual Machine (VM) หรือบางครั้งอาจจะเป็นเครื่องจริง ๆ ก็ได้ จากนั้นทำการ configuration และ ติดตั้ง software ต่าง ๆ ที่จำเป็น สุดท้ายสามารถทำลาย server เหล่านี้ได้ตามที่ต้องการ มันก็สะดวกดีนะ แต่ต้องเรียนรู้เพิ่มเติม

แนวปฏิบัติของ Infrastructure as Code เป็นอย่างไร ?

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

Use definition files

ขั้นตอนการทำงาน และ configuration ต่าง ๆ จะอยู่ในไฟล์ที่สามารถ execute ได้ เช่น shell script, docker file, ansible playbook, chef recipe และ puppet manifest เป็นต้น ดังนั้น ถ้าต้องการเปลี่ยนแปลงขั้นตอนการทำงาน ก็เพียงแก้ไข source code ในไฟล์ต่าง ๆ เหล่านี้เท่านั้น ทำให้สามารถนำ source code เหล่านี้ ไปสร้าง server จำนวนมากได้อย่างง่ายดาย ที่สำคัญมันรวดเร็วกว่าให้คนทำ !!

Self-documented system and processes

ปกติขั้นตอนการสร้าง และ configuration server นั้น มักจะเขียนไว้ในรูปแบบเอกสารต่าง ๆ เช่น Spreadsheet เพื่อเอาไว้ให้คนอ่าน และ ทำตาม ซึ่งคนมักสร้างความผิดพลาดอยู่เสมอ บ่อยครั้งก็ไม่ยอมทำตามเอกสาร !! แต่ถ้าปรับเปลี่ยนมาเขียนขั้นตอนเหล่านั้นด้วย code ทั้งให้คนอ่านง่าย ทั้งให้เครื่องคอมพิวเตอร์อ่านออก และ execute ได้ มันจะกลายเป็นเอกสารที่คนอ่านได้ง่าย แถมให้เครื่องคอมพิวเตอร์ทำงานตาม code เหล่านั้นได้อีกด้วย ชีวิตก็น่าจะดีขึ้นนะ

Version all the things

Source code ต่าง ๆ สำหรับการสร้าง และ configuration server นั้น จะต้องจัดเก็บไว้ใน source control เสมอ เพื่อทำให้เราสามารถจัดการ version รวมทั้งบันทึกการเปลี่ยนแปลงต่าง ๆ ได้ นั่นคือสามารถทำการ audit และ เห็นปัญหาต่าง ๆ ได้ง่ายอีกด้วย

Continuously test systems and processes

สิ่งที่ขาดไปไม่ได้เลย คือ การทดสอบ (Testing) ทำให้เราหาปัญหา และ ข้อผิดพลาดต่าง ๆ จากขั้นตอนการสร้าง และ configuration server ได้อย่างรวดเร็ว โดยขั้นตอนการสร้าง และ ทดสอบนั้น จะอยู่ใน deployment pipeline ของ Continuous Delivery นั่นเอง ดังนั้นถ้ามีการเปลี่ยน source code ต่าง ๆ ของการสร้าง server หรือ configuration ต่าง ๆ แล้ว จะทำการ execute code แบบอัตโนมัติ รวมทั้งทำการทดสอบอีกด้วย

Small changes rather than batches

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

Keep services availlable continuously

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

ประโยชน์ที่ได้รับ มีอะไรบ้าง ?

แน่นอนว่าทำให้สามารถสร้างระบบ infrastruture ได้ตามที่ต้องการ รวมทั้งง่ายต่อการแก้ไขทั้งลดและเพิ่มสิ่งต่าง ๆ เข้าไป เช่น การเปลี่ยนแปลง configuration การเพิ่มหรือลดจำนวนเครื่อง server ยังไม่พอนะ เนื่องจากสามารถกำหนดค่าต่าง ๆ ใน source code ทำให้แต่ละเครื่องที่สร้างขึ้นมานั้นเหมือนกัน ทั้งเวอร์ชันของ OS ทั้งเวอร์ชันของ Web server ทั้งเวอร์ชันของ Database ทั้งเรื่องของชุดเครื่องมือ ทั้งเรื่องของ Library และ Framework ทั้งเรื่องของระบบ Monitoring ทั้งเรื่องของระบบ Network ทั้งเรื่องของการทำงานร่วมกันของส่วนต่าง ๆ ที่สำคัญยังช่วยลดความเสี่ยงต่าง ๆ ลงไปมากอีกด้วย ซึ่งมันเป็นปัญหาหลักของการสร้างเครื่องแบบ manual หรือให้คนทำ เมื่อเกิดปัญหาแล้ว หาสาเหตุได้ยากมาก ๆ ทั้งหมดทั้งมวล ก็เพื่อทำให้เราสามารถจัดการ server ที่เพิ่มขึ้นเป็นจำนวนมากได้ง่าย และ สะดวกขึ้น จากสถาปัตยกรรม Microservice ที่กำลังได้รับความนิยม
วันนี้เราพร้อมแล้วหรือยัง ?
สุดท้ายไปอ่านเพิ่มจากหนังสือ Infrastructure as Code newrules
↧
Viewing all 2000 articles
Browse latest View live
Search