cc :: somkiat

หลังจากที่แบ่งปันความรู้เกี่ยวกับ Test-Driven Development (TDD) สำหรับ Android app ตั้งแต่การเขียน Unit test หรือ Local unit test ที่ไม่ต้องการ Device หรือ Emulator จนถึง Instrumentation test, UI test และ Stress test ที่ต้องใช้ Device หรือ Emulator ในแต่ละ feature ในแต่ละ flow สำหรับผู้เริ่มต้นนั้นไม่ง่ายซะทีเดียว แต่ถ้ามีความพยายามก็ง่ายขึ้นเยอะ ดังนั้นจึงทำการสรุปเส้นทางการเรียนรู้ไว้นิดหน่อย เพื่อให้ง่ายต่อการศึกษามากยิ่งขึ้น เรื่องพื้นฐานมันสำคัญมาก ๆ นะครับ มาเริ่มกันเลย

1. เริ่มต้นเรียนรู้การเขียน test สำหรับ Android app ก่อนเลย

ทั้ง Unit test และ Instrumentation test แนะนำให้เริ่มต้นจากที่ Codelab มันแจ่มมาก ๆ

2. ว่าด้วยเรื่องของ Architecture หรือ Structure ของระบบงานที่เอื้อต่อการทดสอบ (Testable app)

โครงสร้างของระบบใหญ่ ๆ ที่ว่าสำคํญแล้ว โครงสร้างของระบบงานของ Android app ยิ่งสำคัญมาก ๆ ถ้าเขียน code แบบมั่ว ๆ ไม่คำนึงสิ่งใด ๆ นอกจากทำให้เสร็จแล้ว ผลที่ตามมาคือ ทดสอบได้ยากมาก ๆ ส่วนเรื่องแก้ไข หรือ เพิ่มความสามารถใหม่ ๆ ยิ่งยากขึ้นเรื่อย ๆ หรือทดสอบได้เพียงอย่างเดียวคือ Manual testing เท่านั้น ดังนั้นแนะนำให้ศึกษาโครงสร้างที่ดีในรูปแบบต่าง ๆ เช่น

3. เมื่อเข้าใจการเขียน test และโครงสร้างที่ดีแล้ว ก็ให้ศึกษาเรื่อง Test-Driven Development (TDD)

มี resource ดี ๆ แนะนำให้ศึกษาดังนี้

เมื่อทำตามสามขั้นตอนข้างต้นแล้ว

แนะนำให้ลงมือทำกับระบบงานที่ทำอยู่ อย่าผลัดวันประกันพรุ่ง เริ่มแบบง่าย ๆ วันละ test case ก็ดีกว่าไม่ทำแล้วนะ

ทำการ review code ของ Android app มาบ้างเล็กน้อย จึงทำการสรุปสิ่งที่พบเจอไว้นิดหน่อย น่าจะเป็นแนวทางหนึ่งในการปรับปรุง code ให้ดียิ่งขึ้นไป

อย่าตั้งชื่อในรูปแบบ Hungarian Notation นะ อ่านยาก
ช่วยลบ Default Unit test และ AndroidTest ทิ้งด้วย ถ้าไม่ได้ใช้งาน
จัด format code กันหน่อยด้วยการกดปุ่ม Control(Command) + Alt + L
แนะนำให้จัดโครงสร้าง package ตาม feature
อย่าจัดการเรื่อง Network เองด้วย HttpURLConnection และ AsyncTask ตลอดจนจัดการ JSON เอง
ช่วย run Code Inspectio/Lint กันด้วย เพื่อให้รู้ถึงปัญหาและ error ต่าง ๆ จากนั้นก็แก้ไขซะ อย่าปิด lint นะ
อย่าใช้ library ที่ out-of-date ดังนั้นให้ทำการ update อยู่อย่างสม่ำเสมอ
อย่าเก็บพวก API key ต่าง ๆ ไว้ใน repository หรือใน code นะ
ก่อนจะเขียน code ใด ๆ ให้เข้าใจก่อนว่า กำลังจะทำอะไร แก้ไขอะไร
ช่วยเขียนคำอธิบายต่าง ๆ ใน README ด้วย หรือก็เขียนใน WIKI ก็ได้
ใช้ Android Studio ในการพัฒนา ขาดมันใหญ่ feature มันเยอะ ช่วยใช้ความสามารถของมันเยอะ ๆ หน่อย

สุดท้าย ถ้าไม่รู้ ไม่เข้าใจ กรุณาถาม

มีคำถามที่น่าสนใจคือ ถ้าเราต้องการบันทึกผลการทดสอบ UI testing แบบอัตโนมัติในรูปแบบ VDO ได้ไหม ? ตอบง่าย ๆ ก็ได้นะ ทำง่ายด้วย คือเครื่องที่ทดสอบก็เปิดโปรแกรมบันทึก VDO เอาเลย หรือไม่ก็ตั้งกล้องหน้าจอกันไปเลย แต่วิธีการดังกล่าวมันอาจจะจะไม่โดนใจเราเท่าไร ดังนั้นจึงเป็นที่มาของการทดลองสร้างระบบง่าย ๆ โดยรวมใช้เวลาในการศึกษาและลองสร้าง จนได้ prototype ของสิ่งที่ต้องการประมาณ 4 ชั่วโมง จึงทำการสรุปไว้นิดหน่อย

Software ที่ใช้งานประกอบไปด้วย

ffmpeg สำหรับบันทึกการทดสอบในรูปแบบ VDO
xvfb (X Virtual Frame Buffer) เป็น virtual display ซึ่งทำงานอยู่บน memory ทำให้เราสามารถ run UI test โดยไม่ต้องมีหน้าจอ (Headless)
Robot framework + Selenium2Library สำหรับทดสอบระบบ Web application
Browser ที่ใช้ใน prototype ชุดนี้คือ Google Chrome
ระบบปฏิบัติการที่ใช้งานคือ Alpine เพราะว่าเล็กดี
จัดการทุกอย่างอยู่ในโลกของ container ด้วย Docker

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

การออกแบบระบบ Prototype

แยกส่วนการทำงานออกเป็น 3 container คือ 1. สำหรับการบันทึกผลการทดสอบเป็น VDO ด้วย ffmpeg 2. สำหรับ virtual display ซึ่งใช้งาน xvfb จะต้องทำการ start xvfb server ทิ้งไว้ 3. สำหรับ Robotframework และ Google Chrome

เมื่อแยกกันทำงานแล้ว ปัญหาที่ตามมาคือ

จะทำงานร่วมกันอย่างไร ? เช่น ffmpeg กับ xvfb container จะทำงานร่วมกันอย่างไร ? ตามจริงรวมกันทำงานเป็น container เดียวก็จบไปแล้ว แต่จากที่ออกแบบต้องการให้แต่ละส่วนการทำงานแยกกันทำงานอย่างเป็นอิสระ เพื่อให้ง่ายต่อการสร้างและดูแลต่อไป ดังนั้นเพื่อเชื่อมต่อการทำงานทั้งสองส่วน จึงต้องนำ Python Remote Server for Robotframework ซึ่งทั้งสอง container จะต้องทำการ run Python remote server ขึ้นมา โดยมี port default คือ 8270 ตรงนี้ก็เขียนโปรแกรมนิดหน่อย

ต่อมาคือส่วนของ Robotframework และ Google chrome

ก็ติดตั้ง library ต่าง ๆ ตามปกติ แต่ส่วนที่มีปัญหานิดหน่อยคือ การติดตั้ง font ภาษาไทยใน Alpine linux นิดหน่อย โดย font ที่ใช้คือ Fonts-TLWG การติดตั้งก็อธิบายได้ดีเหลือเกิน หาไม่เจอเลย ต้องทำการ extract ไฟล์ของ font ดังกล่าวมาถึงเห็นวิธีการติดตั้ง ความจริงงงตั้งแต่การ extract ไฟล์นามสกุล tar.xz แล้วนะ !! ปล. ไม่มีใครอธิบายส่วนนี้เลย !! ใน Dockerfile สามารถเขียนการติดตั้ง font ได้ดังนี้ [gist id="556581f40e67b86412a58a8ce0d29554" file="FontDockerfile"] คำอธิบาย ขั้นตอนการติดตั้งคือ 1. Download font จาก internet 2. ทำการ extract 3. จากนั้นก็ทำการ copy ตามเอกสารการติดตั้งของ font ซึ่งอยู่ในไฟล์ INSTALL

จากนั้นจึงทำการสร้าง image ของ 3 ส่วนการทำงานได้ดังนี้

โดย image ทั้ง 3 ตัวใช้ base image จาก python:alpine ทั้งหมด แต่ก็ยังมีขนาดใหญ่เนื่องจาก library ที่ทำการติดตั้ง ซึ่งน่าจะลดลงได้อีกมาก !! [gist id="556581f40e67b86412a58a8ce0d29554" file="image.txt"] ซึ่งผม upload image ทั้งสามไปไว้ที่ Docker Hub แล้ว ใครสนใจก็ลแงใช้งานแบบขำ ๆ ได้นะครับ

ต่อมาถึงการใช้งานซึ่งใช้งานผ่าน Docker compose เนื่องจากง่ายดี

มีการ configuration เพิ่มนิดหน่อยคือ

ทำการ map volume กับ ffmpeg container เพื่อนำ vdo ที่บันทึกไว้ออกมาง่าย ๆ
ทำการ map volume กับ robotframework container เพื่อให้จัดการ test case และ report ต่าง ๆ ได้ง่าย
robotframework container นั้นกำหนด entry point ไว้คือ pybot ดังนั้นใน compose file ก็ส่ง command ที่ต้องการซึ่งเป็น parameter ต่าง ๆ ของ pybot ได้เลย
จากตัวอย่างจะเป็นการกำหนด output folder และ ไฟล์ test case ที่ต้องการทดสอบ

สามารถเขียนได้ดังนี้ [gist id="556581f40e67b86412a58a8ce0d29554" file="docker-compose.yml"] จากนั้นก็ถึงเวลาทดสอบการทำงานด้วยคำสั่งดังนี้ [gist id="556581f40e67b86412a58a8ce0d29554" file="run.sh"] เพียงเท่านี้ก็จะได้ผลการทดสอบในรูปแบบ VDO แล้วครับ ผลการทำงานดังนี้ https://www.facebook.com/somkiatspns/posts/10155211622628588?pnref=story Reference Websites https://devopsism.wordpress.com/2016/06/20/capturing-video-during-test-runs/ https://linux.thai.net/projects/fonts-tlwg https://github.com/robotframework/PythonRemoteServer

ปัญหาอย่างหนึ่งของการพัฒนา android app คือ เรื่องการ build ไฟล์ APK ของ app เพื่อนำไปทดสอบ เพื่อนำไป deploy จะทำการ build อย่างไร ? จะทำการส่งไฟล์ APK ให้คนที่เกี่ยวข้องอย่างไร ? หนึ่งในวิธีการที่ใช้บ่อย ๆ คือ การส่งไฟล์ APK จาก Android Studio ไปยัง Slack ของทีม โดย slack คือเครื่องมืออย่างหนึ่งในการสื่อสารของทีม มาลองใช้งานกัน

1. ทำการติดตั้ง plugin ชื่อว่า InstApk ใน Android Studio

เมื่อทำการติดตั้งเรียบร้อยก็ต้องทำการ restart Android Studio

2. ทำการ Configuration InstApk ใน Android Studio

3. ทำการ Connect ไปยัง Slack หรือทีมที่เราต้องการให้ส่ง APK ไปหา

ดังนั้นต้องไป copy Access Token ของทีมมาใส่ซะ

4. จากนั้นทำการเลือกไฟล์ APK เพื่อส่งไปยัง Slack

สุดท้ายทำการตรวจสอบใน Slack ของทีมว่ามีไฟล์ APK ส่งมาหรือไม่ ?

แสดงดังรูป

ปล. ยังสามารถปรับปรุงการทำงานในส่วนนี้ให้ดีขึ้นอีกนะ เช่นการสร้างไฟล์และส่งไฟล์ APK แบบอัตโนมัติ

จากการที่ทีมพัฒนา Android ได้ประกาศหยุดการพัฒนา Jack toolchain นั่นหมายความว่าการใช้ความสามารถของ Java 8 ในการพัฒนา Android app จะเปลี่ยนไป ซึ่งล่าสุดได้ประกาศวิธีการออกมาแล้ว Support Java 8 support นั่นคือยัด feature ของ Java 8 เข้ามาให้เลย (Build-in) แต่ใช้ได้บาง feature เท่านั้น !!

ปล. แต่ในปัจจุบันการพัฒนา Android app ด้วยความสามารถของ Java 8 มันยังคงเป็นเพียงทางเลือกหนึ่งเท่านั้นนะครับ ดังนั้นเราไม่จำเป็นต้องใช้ก็ได้ หรือไม่พอใจก็เปิดความสามารถนี้เองได้

มาดูการใช้งานและการ migrate กันหน่อย

ถ้าต้องการใช้งาน Java 8 ตามแนวทางใหม่นั้น สิ่งแรกเลยต้อง download Android Studio 2.4 Preview 4 ขึ้นไปมาใช้ก่อน (ตอนนี้ Preview 5 แล้ว) ต่อมาต้องเปลี่ยนมาใช้ Android plugin for Gradle 2.4.0 alpha5 ขึ้นไป ยังไม่พอนะต้องปรับแต่ compileOptions ในไฟล์ build.gradle ให้เป็น Java 8 ด้วย ยังไม่พอนะหลาย ๆ feature ต้องกำหนด minSdkVersion เป็น API level 24 ขึ้นไปอีกด้วย [gist id="99c0c5f115a9992afa4caf0339ac6d91" file="build.gradle"]

มาดูขั้นตอนการทำงานบ้าง

แสดงการทำงานดังรูป โดยจะมีสิ่งที่เรียกว่า desugar เป็นตัวแปลง bytecode

เมื่อลองทำการ builld ด้วย gradle จะพบว่า มีขั้นตอนการทำงานดังนี้ ซึ่งเป็นไปตามรูปข้างบนเลย นั่นคือทำการแปลง ไฟล์ class ด้วย desugar ก่อนที่จะแปลงเป็นไฟล์ dex ต่อไป [gist id="99c0c5f115a9992afa4caf0339ac6d91" file="step.txt"] ปล. เพิ่มขั้นตอนในการ build เข้ามา แน่นอนว่าต้องใช้เวลาในการ build มากขึ้น !!

ถ้าใครต้องการอ่าน source code ของ desugar tool

สามารถอ่านและศึกษาเพิ่มเติมได้ที่

ส่วนใครที่ใช้งาน Jack toolchain และ Retrolambda อยู่

ก็เพียงลบมันทิ้งไปเท่านั้นเองนะ

ส่วนใครที่ต้องการปิด Java 8 support แล้ว

สามารถกำหนดได้ในไฟล์ gradle.properties ได้ดังนี้ [code] android.enableDesugar=false [/code] ขอให้สนุกกับการ coding ครับ

จากแบบสำรวจเรื่องการพัฒนาระบบงานด้วยภาษา Java นั้น เพื่ออยากรู้ระบบงานในไทยใช้งานอะไรกันบ้าง ? ซึ่งมีผู้เข้ามาทำแบบสำรวจทั้งหมดจำนวน 149 คน ได้ผลการสำรวจที่น่าสนใจดังนี้

60% ใช้ JDK 8 ในการพัฒนาระบบงาน รองลงมาเป็น 7 และ 6 ตามลำดับ

70% ใช้ Spring framework ในการพัฒนาเป็นหลัก รองลงมาคือ Struts framework

เวอร์ชันของ Spring framework ที่ใช้งานมากที่สุดคือ 4

แต่ที่น่าสนใจคือกว่า 50% ไม่ได้ใช้งาน Spring Boot ในการพัฒนา เป็นเรื่องที่แปลกดีเหมือนกัน

Build tool ที่ใช้ยังคงเป็น Apache Maven ส่วนที่รองลงมาคือ Gradle

แต่สิ่งที่น่ากลัวมาก ๆ คือกว่า 10% ไม่ได้ใช้ !!

IDE ที่ใช้ในการพัฒนา Eclipse กับ IntelliJ นั้นสูสีกันมาก ๆ

ส่วน Netbeans ผลแนะนำให้ uninstall ออกซะ !!

65% บอกว่าไม่ได้เขียนภาษาอื่น ๆ บน JVM เลยนอกจาก Java

โดยภาษาที่ใช้งานกันประกอบไปด้วย Groovy, Scala และ Kotlin

65% ใช้งาน Git สำหรับจัดการเวอร์ชันของ source code

57% ไม่มีระบบ Continuous Integration

โดยระบบ Continuous Integration ที่ใช้งานส่วนใหญ่คือ Jenkins

สุดท้ายพบว่ากว่า 50% ไม่เขียน blog !!

แต่ก็มีอีก 32% ที่วางแผนจะเขียน ... ดังนั้นมาเขียนกันเถอะนะ

เครื่องมือที่ใช้งานประกอบไปด้วย

Spring boot application ซึ่งจะมี 2 service คือ User service กับ Order service
Prometheus สำหรับจัดเก็บข้อมูลของแต่ละ service ในรูปแบบ time series
Grafana สำหรับแสดงข้อมูลในรูปแบบ graph ที่สวยงาม

มาดูขั้นตอนการสร้างระบบ Monitoring อย่างง่ายกันดู

ขั้นตอนที่ 1 พัฒนา service ต่าง ๆ ด้วย Spring boot

เริ่มต้นด้วยการพัฒนา service ด้วย Spring boot ซึ่งมีอยู่ด้วยกัน 2 service คือ 1. User service มีอยู่ 1 api คือ ดึงข้อมูลผู้ใช้งานตาม id 2. Order service มีอยุ่ 1 api คือ ดึงข้อมูลการสั่งซื้อของผู้ใช้งานแต่ละคน ทั้งสอง api นั้นถ้าไม่พบข้อมูลจะ return code 404 กลับมา (Not found) โดยปกติแล้วนั้น service ที่พัฒนาด้วย Spring boot จะยังไม่มีส่วนของ metrics ต่าง ๆ ให้ เราจะต้องเพิ่ม dependency ชื่อว่า Actuator ก่อนดังนี้ [gist id="a4e6cdc0dbf015ffc6c1077bfafb557c" file="pom.xml"] จาก dependency นี้ทำให้ service ของเรานั้นมี endpoint ต่าง ๆ ดังจต่อไปนี้

/health แสดงสถานะของ service เช่น uptime, disk และ database ที่ใช้งาน
/info แสดงรายละเอียดของ service
/metrics แสดงรายละเอียดของ server เช่นการใช้งาน CPU, Memory และพวก Heap size เป็นต้น
/trace แสดงการ access มายัง service ว่าเข้ามาใช้งาน api/endpoint อะไรบ้าง

ตัวอย่างของ health ดังรูป

ปัญหาที่ตามมาคือ ถ้าเราต้องการเก็บข้อมูลการใช้งานต่าง ๆ ของ service ในรูปแบบ time series จะต้องทำอย่างไร ? ตัวอย่างเช่น API แต่ละตัวนั้นในแต่ละนาทีมีการใช้งานอย่างไรทั้งสำเร็จและไม่สำเร็จ

ขั้นตอนที่ 2 ทำการเก็บข้อมูลของ service จากข้อ 1 ลงใน Prometeus

หลังจากการศึกษาแบบคร่าว ๆ พบว่า เราสามารถจัดเก็บข้อมูลการใช้งานของแต่ละ service แบบง่าย ๆ ลงใน Prometheus ได้ แต่ต้องสร้าง metric หรือข้อมูลให้ตรงตามรูปแบบของ Prometheus ด้วย มีสถาปัตยกรรมดังรูป

ปล. ตัวอย่างของรูปแบบข้อมูลที่จัดเก็บลงใน Prometheus มีรูปแบบตาม metric ของ Prometheus นั่นเอง ดูที่ metric url ของ Prometheus server ดังนี้

แต่ service ที่พัฒนาด้วย Spring boot นั้นยังมีข้อมูลการใช้งานไม่ตรงตามที่ Prometheus ต้องการ ดังนั้นจำเป็นต้องทำการ custom service กันนิดหน่อย โชคดีที่มีคนช่วยทำไว้ให้แบบง่าย ๆ (แต่ถ้าไม่ตรงตามความต้องการก็เขียน code เองได้นะ) แต่ในบทความนี้จะใช้วิธีการง่าย ๆ คือ เพิ่ม dependency ดังนี้เข้าไปก็จบเลย [gist id="a4e6cdc0dbf015ffc6c1077bfafb557c" file="pom2.xml"] โดย dependency ตัวนี้จะสร้าง endpoint ใหม่ชื่อว่า /prometheus ในแต่ละ service ซึ่งมีข้อมูลดังนี้

จากนั้นทำการ configuration ใน Prometheus ให้ดึงข้อมูลจาก 2 service ให้ทำการดึงข้อมูลทุก ๆ 5 วินาที ด้วยการแก้ไขไฟล์ prometheus.yml ดังนี้ [gist id="a4e6cdc0dbf015ffc6c1077bfafb557c" file="prometheus.yml"] ต่อมาให้ลองทำการ query ข้อมูลที่เราต้องการมาแสดงผลนิดหน่อย เพื่อตรวจสอบว่าการดึงข้อมูลถูกต้องตามที่ต้องการ เช่นต้องการดูข้อมูลการดึงข้อมูลจาก user service จาก metric ชื่อว่า counter_status_200_user_userId แสดงดังรูป

จาก graph ข้างต้นมีไว้สำหรับการทดสอบดึงข้อมูลมาแสดงผลตามที่ต้องการเท่านั้น แต่ถ้าต้องการสร้างเป็น dashboard หรือ graph แบบถาวรแล้ว มี 2 วิธีให้เลือกคือ 1. ใช้ Grafana 2. ใช้ Console template ในบทความนี้เลือกใช้งาน Grafana เพราะว่าง่ายดี แถมสวยด้วย !! ดังนั้นมาลองใช้งาน Grafana กันดู

ขั้นตอนที่ 3 นำข้อมูลจาก Prometheus มาแสดงผลด้วย Grafana

มีขั้นตอนการใช้งานดังนี้ 1. ทำการเพิ่ม Datasource เพื่อดึงข้อมูลจาก Promethus

2. ทำการสร้าง Dashboard และเพิ่ม Graph ที่เราต้องการดู สิ่งที่ผมต้องการคือ ใน graph แต่ละตัวให้แสดงข้อมูลจาก metric เดียวไปเลย ดังนี้

User service ในกรณีที่พบข้อมูลและไม่พบข้อมูล
Order service ในกรณีที่พบข้อมูลและไม่พบข้อมูล

ตัวอย่างการ configuration ใน graph ของ User service เมื่อพบข้อมูล โดยใช้ metric ชื่อว่า counter_status_200_user_userId แสดงข้อมูลในทุก ๆ 1 วินาที ที่สำคัญต้องกำหนด datasource ไปยัง prometheus ด้วยนะครับ แสดงดังรูป

แสดงผลทำงานทั้งหมดดังนี้

เพียงเท่านี้เราก็ได้ระบบ Monitoring สำหรับ service ที่พัฒนาด้วย Spring boot กันแล้วนะครับ โดยที่ dashboard ที่ได้ดูดีเลยทีเดียว ขอให้สนุกกับการพัฒนาและ monitoring ครับ

ภาษา Kotlin นั้นสามารถพัฒนาระบบงานได้ทั้ง Mobile app, Backend system และ Frontend application ซึ่งมีความน่าสนใจทั้งสามส่วน แต่ในบทความนี้จะเน้นไปที่ Front-end application เนื่องจากไปอ่านเอกสารใน web ของ Kotlin แล้ว มีแต่การสอนใช้งานผ่าน IDE, Apache maven, Gradle

ทำไมไม่สอนการพัฒนาตามแนวทางของ Front-end developer/Javascript developer บ้างนะ ?

ดังนั้นจึงลองมาสร้างระบบงานง่าย ๆ ด้วย NPM หรือ Yarn หรือ Grunt กันดีกว่า สิ่งที่ต้องติดตั้งก่อนคือ

Kotlin
NPM

1. ทำการสร้าง Javascript project ขึ้นมา

[gist id="9a1ef6293af18fc9c67670b1223b591b" file="package.json"]

2. จากนั้นลองทำการติดตั้ง Grunt cli เพื่อมาช่วยให้ระบบการ build ดูดีขึ้น

ซึ่งเราจะต้องสร้าง Gruntfile.js ขึ้นมา เพื่อกำหนดการทำงานตามใจเราดังนี้ 1. ทำการแปลง code จาก Kotlin ให้มาอยู่ในภาษา Javascript ด้วยคำสั่ง kotlinc-js 2. จากตัวอย่างนี้ผลการทำงานจะอยู่ในไฟล์ชื่อว่า hello.js 3. ทำการ copy ไฟล์ต่าง ๆ เช่น HTML, CSS และ Javascript ไปไว้ใน folder ชื่อว่า dist [gist id="9a1ef6293af18fc9c67670b1223b591b" file="Gruntfile.js"]

3. ทำการสร้างระบบที่เราต้องการนิดหน่อย

ตามธรรมเนียมก็ต้อง Hello world สินะ สิ่งที่ต้องการเป็นดังนี้

ใน method ที่เราต้องการจะพัฒนาด้วยภาษา Kotlin
method ชื่อว่า say() รับค่า 1 ตัวคือชื่อ
ผลการทำงานของ method say() คือ กล่าวคำทักทายว่า Hello + ชื่อที่ส่งเข้ามา

สามารถเขียนได้ดังนี้ [gist id="9a1ef6293af18fc9c67670b1223b591b" file="hello.kt"] คำอธิบาย สิ่งที่เพิ่มมานิดหน่อยคือ @JsName สำหรับการระบุชื่อของ method ไปเลย เพื่อไม่ให้ kotlin compiler ทำการแปลงไปเป็นชื่อที่ต่อด้วย random number ทำให้เราสามารถเรียกใช้งานผ่านชื่อ method say() ได้เลย สุดท้ายก็ทำการ run ด้วยคำสั่ง [code] $grunt [/code] จะทำการแปลง code จากภาษา Kotlin ไปเป็นภาษา Javascript และ copy ไฟล์ต่าง ๆ ที่เราต้องการไปยัง folder dist ให้

จากนั้นทำการ run ดูผ่าน web จะแสดงผลดังนี้ start server ด้วยคำสั่ง [code] $grunt connect [/code] แสดงผลการทำงานดังนี้

เพียงเท่านี้ก็สามารถพัฒนา Frontend application ด้วยภาษา Kotlin ได้แล้วนะ สามารถดูตัวอย่าง code ได้ที่ Github::Up1::Kotlin for fronted developer

เพิ่งเห็นว่า Google Cloud Platform นั้นมี feature ใหม่ชื่อว่า Cloud Function ทำให้เราสามารถ deploy Function ที่พัฒนาด้วย Node.js นั่นคือเราสามารถพัฒนาระบบงานด้วยภาษา Javascript ที่สำคัญเราไม่ต้องสนใจเรื่อง server ที่สำคัญเราไม่ต้องสนใจเรื่องการขยายระบบเพื่อรองรับจำนวนผู้ใช้งานที่มากขึ้น เนื่องจาก Google Cloud Platform จัดการให้ (BaaS => Backend-as-a-Service) ดังนั้นเรามาลอง deploy Function ที่พัฒนาด้วย Node.js กันดู นี่มัน Function-as-a-Service (FaaS) ชัด ๆ

ขั้นตอนที่ 1 ทำการติดตั้ง Google Cloud SDK ก่อน

ทดสอบการติดตั้งด้วยคำสั่ง [code] $gcloud --version [/code] ซึ่งผมใช้งาน version 151.0.1 ถ้าใครยังไม่ใช้แนะนำให้เปิด gcloud beta component ด้วยดังนี้ [code] $gcloud components install beta [/code]

ขั้นตอนที่ 2 สร้าง function ชื่อว่า helloWorld ด้วยภาษา Node.js

เขียน code ง่าย ๆ ดังนี้ [gist id="ab8b2693277e6c27681e1b497c1d5d40" file="index.js"] อย่าลืมทดสอบก่อนนะ ว่าทำงานได้อย่างถูกต้อง

ขั้นตอนที่ 3 ทำการเปิดใช้งาน Function Cloud ผ่าน Google Cloud Console ก่อน

ขั้นตอนที่ 4 ทำการสร้าง Storage โดยสร้าง bucket ชื่อว่า hello_up1

เพื่อใช้สำหรับจัดเก็บ code นั้นเอง

ขั้นตอนที่ 5 ทำการ deploy Function ที่เราต้องการ

[code] $gcloud config set project up1scala $gsutil mb -p up1scala gs://hello_up1 $gcloud beta functions deploy helloWorld --stage-bucket hello_up1 --trigger-http [/code] ได้ผลการทำงานดังนี้ [gist id="ab8b2693277e6c27681e1b497c1d5d40" file="result.txt"] คำอธิบาย

project id ชื่อว่า up1scala
ชื่อ bucket ของ storage ชื่อว่า hello_up1
ชื่อ function คือ helloWorld

จะใช้เวลาการ deploy ประมาณ 2 นาที สามารถเข้าไปดูรายชื่อ function ที่สร้างได้ดังรูป

ผลที่ได้คือ url ของ funtion ที่เรา deploy ไปนั่นเอง สามารถเข้าใช้งานได้เลย แสดงดังรูป

เพียงเท่านี้เราก็สามารถสร้าง Function-as-a-Service อย่างง่ายบน Google Cloud Platform ได้แล้ว

ปกติตารางธาตุเราคุ้นเคยกับตารางธาตุของเคมี แต่ในปัจจุบันในสายการพัฒนา Software ก็มีการสรุปสิ่งต่าง ๆ อยู่ในรูปแบบเดียวกับตารางธาตุเหมือนกัน จึงทำการสรุปไว้นิดหน่อย ใครมีอะไรแจ่ม ๆ แนะนำได้นะครับ 1. ตารางธาตุของ Scrum

2. DevOps Tools

3. Visualization methods

4. Data Sciences

5. IoT

6. Fintech

7. Software engineering

8. AI

9. Deep Learning Pattern

ใครมีตารางธาตุที่น่าสนใจแนะนำกันมาได้นะครับ

เมื่อวันที่ 13 เมษายนที่ผ่านมา หรือ วันสงกรานต์ของไทยนั่นเอง ทางทีมพัฒนา Google Chrome ได้ปล่อย Chrome 59 (อยู่ใน Chrome Canary Channel เท่านั้น) ซึ่งมี feature ที่น่าสนใจคือ Headless chrome Headless mode นั้นเป็นอีกหนึ่งช่องทางในการใช้งาน browser โดยที่ไม่ต้องแสดงออกมาทางหน้าจอ ซึ่งปกติเราจะใช้งาน Headless mode ผ่านโปรแกรมพวก Virtual Display Managerเช่น Xvfb, VNC ไม่เช่นนั้นก็ต้องใช้ PhantomJS และ NightmareJS เป็นต้น มี use case ที่ใช้งานได้เช่น

การทดสอบระบบ web
การดึงข้อมูลออกมาจาก web
การทำ screenshot หน้า web
การบันทึก vdo ของการทดสอบระบบ web

มาลองใช้งานกันดูนิดหน่อย

Software ที่ใช้งานประกอบไปด้วย

Mac OS
Homebrew

เริ่มด้วยการติดตั้งผ่าน brew ด้วยคำสั่ง [code] brew install Caskroom/versions/google-chrome-canary [/code] จากนั้นทำการ start Chrome แบบ headless ด้วยคำสั่ง [code] $/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --headless --remote-debugging-port=9222 --disable-gpu http://www.somkiat.cc [/code] คำอธิบาย ใส่ parameter --headless เพื่อบอก mode การทำงาน port ที่ใช้งานคือ 9222 ทดสอบไปที่ web ที่เราต้องการ สามารถทดสอบเข้าใช้งานผ่าน browser ด้วย url = http://localhost:9222 เป็นการเข้าไป debug ระบบดังรูป

มาดูตัวอย่างการใช้งานกันนิดหน่อย

โดยเป็นการ extract ข้อมูล link ต่าง ๆ ออกมาจาก website ซึ่งจะต้องใช้งานผ่าน Chrome Remote Interface มี code ตัวอย่างซึ่งเขียนด้วย Node.js ดังนี้ [gist id="f4e9a2df5c37510212db38a49b72d0fb" file="index.js"] เพียงเท่านี้ก็สามารถเริ่มต้นใช้งาน Chrome headless ได้แล้ว ถ้าออกเป็นตัวจริง ๆ แล้วน่าจะมีอะไรที่น่าสนใจกว่านี้

ช่วงวันหยุดยาวทาง Code School ได้ปล่อย Try Docker ออกมา ซึ่งเหมาะมาก ๆ สำหรับผู้เริ่มต้นศึกษา Docker ประกอบไปด้วย 3 หัวข้อพื้นฐานคือ

Container และ Image คืออะไร ใช้งานอย่างไร
Dockerfile สำหรับการสร้าง image
การจัดการ Data Volume สำหรับ container

โดยใน course นี้จะเน้นเรื่องการใช้คำสั่งพื้นฐานเช่น

docker container สำหรับการจัดการ container
docker image สำหรับการจัดการ image

ให้ทำการ copy and paste คำสั่งไป run เท่านั้นเอง แต่ก็มีให้พิมพ์เองบ้างเล็กน้อย ข้อควรระวัง ในการพิมพ์แต่ละ command นั้นต้องถูกต้อง ที่สำคัญลำดับของ parameter ต้องตรงตามโจทย์ด้วย ถึงแม้ว่าบางโจทย์มันจะขัดแย้งกัน เช่นชื่อ image web_server กับ web-server เป็นต้น !! ยิ่งการขึ้นบรรทัดใหม่ต้องระวังให้มาก !! อีกอาการที่มักจะเจอคือ การค้าง ... แสดงดังรูป

ขอให้สนุกกับการเรียนรู้ Docker ครับ

ปล. เมื่อเรียนแบบฟรี ๆ เสร็จแล้วก็จะเข้าสู่ course เสียตังต่อไปนะครับ

Reference Website Why Docker ?

นั่งอ่านเอกสาร OWASP Top 10 - 2017 RC 1 แล้ว พบว่ามีทั้งการเพิ่มและการลบออกไปจากของปี 2013 นิดหน่อย แต่มันกลับไปคล้ายกับปี 2003 มาก ๆ ซึ่งรายละเอียดลองไปอ่านกันดูนะครับ โดย Top 10 ที่ออกมานั้น มันสะท้อนถึงการพัฒนา software สมัยใหม่ ๆ ที่มีการพัฒนาที่รวดเร็วขึ้นกว่าเดิมเป็นอย่างมาก ๆ โดยเฉพาะการพัฒนา APIs ต่าง ๆ ที่ระบบใหม่นิยมทำกัน แต่สิ่งที่มักจะขาดหรือละเลยไปคือ ความใส่ใจเรื่องความปลอดภัย !!

เมื่อลงไปดูรูปแบบการโจมตีพบว่ายังคงอยู่ในรูปแบบเดิม

เพิ่มเติมคือการพัฒนา software ที่เปลี่ยนไปเท่านั้นเอง ดังนั้นทั้งส่วนของทีมพัฒนาและทีม security application ต้องทำงานร่วมกันมากขึ้น เนื่องจากรูปแบบการพัฒนาที่เปลี่ยนไป ทำให้เรื่องของ security ก็เปลี่ยนไปเช่นกัน ลองคิดดูว่า ถ้านักพัฒนา software ยังคงไม่ใส่ใจในเรื่องความปลอดภัย ถ้าทีม application security ยังคงไม่สนใจว่าจะพัฒนาเปลี่ยนไปอย่างไร ต่างฝ่ายต่างสนใจแต่งานของทีม ผลที่ออกมาคือ ตีกันไปมา !! ใครกันที่ได้ประโยชน์ ? ดังนั้นเรื่องความปลอดภัยต้องคุย แบ่งปันกันตลอดเวลา รวมทั้งกำหนด test case และรูปแบบการโจมตีไว้เลย จะได้ออกแบบระบบสำหรับป้องกันการโจมตีรูปแบบต่าง ๆ ไว้ ไม่ต้องมานั่ง hack ระบบกันเองไปมาให้วุ่นวายเกินไป ให้ทำเท่าที่จำเป็นเพื่อลดความเสี่ยง ที่สำคัญระบบที่พัฒนามันง่ายต่อการทดสอบหรือไม่ ?

แต่สิ่งที่น่าสนใจอย่างมากจากเอกสารชุดนี้คือ What’s Next for Security Testing ?

ในเอกสารพูดถึงคำว่า Continuous Application Security Testing นั่นคือทำการทดสอบเรื่องความปลอดภัยอย่างสม่ำเสมอ เนื่องจากรูปแบบการพัฒนาเปลี่ยนไป ตามแนวคิด Agile และ DevOps เนื่องจากรูปแบบการพัฒนาที่เป็นรอบสั้น ๆ นั่นคือมี feature ต่าง ๆ ออกมาเรื่อย

โดยที่การทดสอบเรื่องความปลอดภัยต้องไม่ทำให้การพัฒนาช้าลงด้วย นั่นแสดงว่าเรื่องของ automation testing ต้องถูกนำมาใช้ให้มากขึ้น

แต่ก่อนอื่นต้องเข้าใจสิ่งต่าง ๆ เหล่านี้ก่อน

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

คำถามคือ ตอนนี้ Application Security Testing เป็นอย่างไร ?

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

เป็น status report meeting ไป ซึ่งทุกคนจะรอรายงานความคืบหน้าให้ใครสักคน
ไม่มีรายละเอียดในสิ่งที่ทำเลย นั่นคือไม่มีคุณค่าใด ๆ ต่อใครเลย เช่น เมื่อวานทำงาน A วันนี้ทำงาน A ต่อ
กลายเป็นที่พูดคุยปัญหาต่าง ๆ เพื่อหาวิธีการแก้ไข แทนที่จะเป็นการบอกถึงปัญหาและพูดคุยหลังจากนี้ บ่อยครั้งจะเป็นการคุยกันอยู่ไม่กี่คน น่าเบื่อไหมละ ?
บ่อยครั้งจะมาถกเถียงและพูดคุยถึงรายละเอียดของ requirement งงไหมละ ? เราจะมี session planning ไปกันทำไม ?
เมื่อคนหนึ่งบอกว่ามีปัญหา ก็ไม่มีใครเข้ามาช่วยเหลือเลย หรือมีคนเสนอตัวช่วยเหลือแต่กลับไม่ไว้ใจอีก !! แปลกดีไหม ?
ยึดติดกับกรอบเวลาเกินไป ทำให้ขาดรายละเอียด หรือเป็นการพูดที่ไม่ใช่คน !! เป้าหมายของ Standup meeting คืออะไรกัน ?
แย่งกันพูด หรือ พูดแทรกกันไปมา หลายคนเอามือถือขึ้นมาเล่นอีก !!
มีใครคนหนึ่งมา assign task ให้กับคนในทีม !!
แต่ละคนไม่ได้เตรียมตัวมา Standup meeting เลย ไม่รู้ด้วยซ้ำไปว่า เป้าหมายคืออะไร อะไรบ้างที่สำคัญ
มาสายหรือไม่ตรงเวลาเลย เนื่องจากส่วนมากเวลาในการ Standup meeting ถูกกำหนดมาจากหัวหน้าหรือฝ่าย management !!
เมื่อมีหลาย ๆ ทีม มักจะพูดปัญหาที่เกิดจากทีมอื่น ๆ มากกว่าทีมตนเอง กลายเป็นการพูดถึงแต่ทีมอื่น
คิดว่า Standup meeting ไม่เหมาะกับทีมใหญ่ ๆ ซึ่งผิดมาก ๆ
มีฝ่าย management เข้ามาบันทึก performance ของแต่ละคนในทีมด้วย น่ากลัวมาก ๆ

ผลที่ตามมาคือ Standup meeting มันไร้สาระ ไร้ประโยชน์ เสียเวลาไปโดยเปล่าประโยชน์ ดังนั้นเลิกเถอะนะ !! แต่ทั้งนี้ก็ขึ้นอยู่กับสภาวะแวดล้อมและเงื่อนไขต่าง ๆ ของแต่ละทีมแต่ละองค์กรนะครับ

วันนี้ Standup meeting ของคุณเป็นอย่างไรกันบ้าง ?

ในงาน DockerCon ทาง Docker ทำการปล่อย 2 project ใหม่ออกมา คือ

โดยที่ LinuxKit นั้นคือ

Toolkit สำหรับการสร้าง custom Linux distribution ตามความต้องการ ซึ่งมีขนาดที่เล็ก นั่นคือมีเท่าที่ต้องการเท่านั้น รวมทั้ง service ต่าง ๆ นั้นอยู่ใน container ทั้งหมด ที่สำคัญ immutable อีกด้วยนั่นคือ สร้างมาแล้วไม่สามารถเปลี่ยนแปลงได้ ปล. ขนาดของ image ที่เล็กที่สุดคือ 35MB

ส่วน Moby project นั้นเป็นเครื่องมือที่ Docker ใช้ในการ

รวม component ต่าง ๆ เข้าด้วยกัน ซึ่งปัจจุบันมีมากว่า 80 component เพื่อสร้าง product ต่าง ๆ ออกมาให้ใช้งาน เช่น

Docker for Mac
Docker for Windows
Docker for AWS
Docker for Azure

เปรียบได้กับระบบการผลิตรถยนต์นั่นเอง แสดงดังรูป

มาเริ่มต้นใช้งาน Moby project กันนิดหน่อย

ขั้นตอนที่ 1 ติดตั้ง Moby

ผมทำการติดตั้งผ่าน go get เลย เพราะว่าง่ายดี ด้วยคำสั่ง [code] $go get -u github.com/linuxkit/linuxkit/src/cmd/moby [/code] ทดสอบใช้งานนิดหน่อย [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="moby.txt"]

ขั้นตอนที่ 2 ลองใช้งานจากตัวอย่างสิ เพื่อทำการ build image

โดยนำตัวอย่างมาจาก linuxkit นั่นเอง ซึ่ง configuration อยู่ในรูปแบบไฟล์ yml ดังนี้ [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="linuxkit.yml"] จากนั้นทำการ run ด้วยคำสั่ง moby build ดังนี้ แสดงการทำงานตั้งแต่การ init, onboot และ การเพิ่ม service container ต่าง ๆ [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="build.txt"] ผลลัพธ์ที่ได้จากการ run คือไฟล์ต่าง ๆ ดังนี้

linuxkit-bzImage
linuxkit-efi.iso
linuxkit.iso
linuxkit-cmdline
linuxkit-initrd.img

ขั้นตอนที่ 3 Run สิรออะไร

[gist id="53c1dc2cff4fff5c69d87dfd68357186" file="run.txt"] ใช้เวลาในการ boot นิดหน่อย จากนั้นทำการดูว่ามี service container อะไรทำงานด้วย runC ดังนี้ [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="runc.txt"] จะเห็นได้ว่ามี nginx ทำงานอยู่นะ ดังนั้นลองทดสอบใช้งานสิ [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="nginx.txt"] จากนั้นดู configuration ของ nginx หน่อย [gist id="53c1dc2cff4fff5c69d87dfd68357186" file="nginx-config.txt"]

มาถึงตรงนี้เราสามารถสร้าง Linux distribution ของเราได้เองแล้ว

โดยทุกอย่างทำงานในโลกของ container นั่นเอง เปรียบได้กับการต่อ Lego นั่นเอง ส่วนรายละเอียดเชิงลึกต้องไปศึกษาเพิ่มเติมต่อไปครับ สวัสดี Moby project !!! Reference Websites http://www.geekwire.com/2017/dockers-new-moby-open-source-project-lego-club-container-systems/ https://ordina-jworks.github.io/conference/2017/04/19/DockerCon-LinuxKit-And-Moby.html https://www.theregister.co.uk/2017/04/21/docker_renames_open_source_code_moby https://thenewstack.io/dockers-moby-project-aims-expand-container-usage-beyond-clouds/

วันนี้ทำการ review code นิดหน่อย พบ code ที่น่าสนใจเยอะพอสมควร หนึ่งในนั้นคือ code เกี่ยวกับการ mapping error code โดยมีขั้นตอนดังนี้

ทำการตรวจสอบว่า Exception แต่ละตัวจากนั้นกำหนด error code ให้
ทำการดึงรายละเอียดของ error ด้วย error code จาก Database !!

ปล. ดึงข้อมูลจาก database ไม่ค่อยดีนะ !!

โดย code ที่ทำการ review เป็นประมาณนี้

[gist id="d300141a8617d13f1d8fbb8e21e16150" file="MappingException01.java"] คำถามที่น่าสนใจคือ จะปรับปรุง code ชุดนี้อย่างไรดี ?

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

จาก code ดังกล่าวผมถามคำถามไปยังทีมพัฒนาดังนี้ ทำไมเราต้องทำการตรวจสอบด้วยว่า Exception/Error นั้นเป็นชนิดอะไร ? จึงจะกำหนด error code ให้ จากนั้นจึงทำการดึงรายละเอียดจาก Database !!! ที่สำคัญคือ จะมี Exception/Error เพิ่มขึ้นมาอีกหรือไม่ ? ตอบเลยว่ามาก ๆๆๆ แสดงว่าต้องมาเพิ่มการตรวจสอบไปเรื่อย ๆ มันไม่น่าจะเป็นทางเลือกที่ดีหรือเหมาะสมเท่าไรนัก

นี่คือปัญหาที่ได้รับจากคำถามต่าง ๆ ดังนั้นลองมาปรับปรุง code กันดูนิดหน่อย

เป้าหมายในการปรับปรุง code คือ ไม่มีการตรวจสอบ Exception/Error นั่นเอง

มาเริ่มกันเลย เริ่มด้วยการกำหนด Base class ของ Exception ขึ้นมาชื่อว่า BaseException โดยเป็น abstract class และมี abstract method ชื่อว่า getErrorCode() เพื่อกำหนดว่า Subclass ต้องมี method นี้เสมอ เพื่อกำหนด error code ของแต่ละ Exception นั่นเอง ดังนี้ [gist id="d300141a8617d13f1d8fbb8e21e16150" file="BaseException.java"] จากนั้น Subclass ก็ทำการ extends ไปดังนี้ [gist id="d300141a8617d13f1d8fbb8e21e16150" file="Subclass.java"] จะเห็นได้ว่า ในแต่ละ class จะทำการกำหนด Error code ไว้เลย ดังนั้นถ้าต้องการเพิ่ม Exception/Error ใหม่ ๆ ก็เพียงสร้าง class exception ที่มีชื่อตรงตามกับ business case ขึ้นมา ส่วนในการ mapping Exception/Error ก็ได้หายไปเรียบร้อย เหลือเพียง code ดังนี้ [gist id="d300141a8617d13f1d8fbb8e21e16150" file="MappingException02.java"]

เพียงเท่านี้ก็ปรับปรุง code ให้ดีขึ้นกว่าเดิมได้แล้วครับ (Continuous Improvement)

แน่นอนว่า มีอีกหลายวิธีการในการปรับปรุง code ชุดนี้ ประเด็นหลักคือ ปัญหาคืออะไร แล้วชุดคำถามเป็นอย่างไร ขอให้สนุกกับการเขียน code ครับ และอย่าลืมเขียน test ด้วยละ

บ่ายนี้นั่งอ่านบทความเรื่อง 5 key learnings after 8 years of iOS development ได้ทำการสรุปประสบการณ์ในการเรียนรู้เกี่ยวกับการพัฒนา iOS ให้

Efficient
Maintainable
Fun

ซึ่งเป็นอีกมุมมองหนึ่งที่น่าสนใจ จึงทำการแปลและสรุปไว้นิดหน่อย มาเริ่มกันเลย

1. Stay Native

แน่นอนว่าการพัฒนา iOS ด้วยภาษา native ทั้ง Objective-C, Swift ด้วยเครื่องมือพัฒนาเช่น XCode เลย เป็นแนวทางที่เหมาะสมที่สุดแล้ว เนื่องจากการนำ Cross-platform tool/framework มาใช้นั้น มันคือการเพิ่มความซับซ้อนขึ้นมา รวมทั้งก่อให้เกิด bug หรือข้อผิดพลาดต่าง ๆ ตามมา

ที่สำคัญ Native นั้นคือหนทางในการลดความเสี่ยงต่าง ๆ ออกไป

ปล. จากประสบการส่วนตัวของผม พบว่า Native มันเริ่มไม่นิ่งเท่าไรแล้ว ตั้งแต่ Objective-C มายัง Swift จาก Swift 1 มายัง Swift 2 จาก Swift 2 มายัง Swift 3 อีกอย่างคือ XCode ที่ตัวใหม่ ๆ bug เยอะเหลือเกิน

ที่สำคัญ Cross platform tool/framework ในปัจจุบันก็ดีขึ้นอย่างมาก ดังนั้นการเลือกเครื่องมือให้เหมาะสมกับ app จึงเป็นเรื่องที่สำคัญมาก ๆ

2. Avoid external libraries

เป็นเรื่องที่สำคัญมาก ๆ ในบทความแนะนำว่า อย่าใช้ external library คือแนวทางที่ดีที่สุด อะไรที่เขียนเองได้ก็เขียน คำถามคือ เราต้องการอะไรบ้าง ? แต่ถ้าเลี่ยงไม่ได้ เช่น การใช้งาน GoogleMap ก็อนุโลมได้นะ ปล. ผมนึกถึงแนวคิดเกี่ยวกับ Don’t Reinvent the wheel ขึ้นมาเลย เช่นเรื่องของการจัดการ network เป็นต้น คำถามที่ตามมาคือ ถ้าใช้ external library พวกนี้แล้ว คุณพร้อมรับกับความเสี่ยงต่าง ๆ หรือไม่ ? เช่นพร้อมรับกับการเปลี่ยนแปลงต่าง ๆ เช่นภาษาที่ใช้พัฒนาและ API ที่เปลี่ยนไป

3. Don’t use package manager

จากข้อ 2 นั่นเอง ถ้าไม่ใช้ external library แล้ว ก็ไม่มีความจำเป็นต้องใช้ package manager tool ใด ๆ เลย บ่อยครั้งนักพัฒนามีปัญหากับ package manager tool เสียอย่างนั้น

ประเด็นหลักคือ การลดความเสี่ยง ถ้าสามารถ copy library เข้ามายัง project ได้ ทำไปแล้ว !! มันก็มีความเสี่ยงนะ ลองพิจารณากันดู

4. Layout in code instead of Storyboard

Storyboard นั้นทำให้เราเริ่มต้นพัฒนา app ได้ง่ายและรวดเร็ว แต่ถ้าต้องการให้การแสดงผลเป็นแบบ dynamic มาก ๆ หรือใส่พวก animation แปลก ๆ เข้าไปตามที่ต้องการ พบว่าการเขียน code จัดการจะสะดวกกว่ามาก บาง app พบว่า Storyboard มีขนาดใหญ่มาก ๆ มีความซับซ้อน เชื่อมโยงไปมามากมาย ดังนั้นจึงแนะนำให้สร้าง layout ใน code ไปเลย เพราะว่ามันง่ายและยึดหยุ่นกว่า ปล. จากประสบการณ์ที่ผ่านมา พบว่าระบบงานที่สร้าง layout ใน code อย่างเดียว และมีขนาดที่ใหญ่ด้วย จะพบปัญหาในแง่ของการ maintain สูงมาก ๆ แต่ถ้ามีเอกสารหรือการเขียน code ที่ดี ก็น่าจะดี แต่ส่วนใหญ่จะเขียนแย่กว่าดี !! อีกอย่างหนึ่งคือ เมื่อ XCode เปลี่ยน version Storyboard ถึงกับพังเกลี้ยงกันเลยทีเดียว !! ดังนั้นผมคิดว่าควรใช้ทั้ง Storyboard, Xib และ code ร่วมกัน

5. Use Core Data

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

สุดท้ายแล้วเป้าหมายหลักของบทความนี้คือ

การ maintain หรือดูแลรักษาระบบให้ง่ายที่สุด เพื่อต่อสู้กับ version ที่เปลี่ยนไป iOS ดังนั้นทำให้เรียบง่ายที่สุดครับ อย่าซับซ้อนมาก ขอให้สนุกกับการ coding ครับ

วันว่าง ๆ ติดฝนมาลองทำความรู้จักกับ Java Modular ใน JDK 9 กันนิดหน่อย หรือบางคนอาจจะรู้จักในชื่อว่า Project Jigsaw ซึ่งเป็น feature ที่ถูกเลื่อมาอย่างยาวนานตั้งแต่ JDK 7, 8 หรือ 9 ดังนั้นลองมาทำความรู้จักกันหน่อยด้วยการเขียน code

ใน Java 9 นั้นมี feature ใหม่ ๆ ดังรูป

เริ่มด้วย Module คืออะไร ?

เป็นวิธีการแบ่งกลุ่มของ software ออกเป็นส่วนเล็ก ๆ ซึ่งในแต่ละ module ประกอบไปด้วย

ชื่อของ module
module นี้จะทำการ export package อะไรออกไปได้บ้าง เพื่อให้ module อื่น ๆ ใช้งาน
module นี้ต้องการใช้ package อะไรบ้างจาก module อื่น ๆ

โดยการประกาศทั้ง 3 อย่างนั้นจะอยู่ในไฟล์ module-info.java แสดงดังรูป

ว่าแล้วลองมาสร้าง Module กันดีกว่า

ตามธรรมเนียมต้องเริ่มด้วย Hello module ชื่อว่า demo.hellomodule ทำการประกาศในไฟล์ module-info.java ดังนี้ [gist id="6a470c7f363e44f1d40e76871093103d" file="module-info.java"] จากนั้นสร้าง class เพื่อแสดงคำว่า HelloWorld กันหน่อย [gist id="6a470c7f363e44f1d40e76871093103d" file="Main.java"] โดยใน module จะมีโครงสร้างดังนี้

คำอธิบาย

Folder src สำหรับจัดเก็บ code .java ทั้งหมดของ module
Folder module สำหรับเก็บไฟล์ .class ทั้งหมดของ module

จากนั้นทำการ compile code และลองใช้งานด้วยคำสั่ง [code] $javac -d module/demo.hellomodule src/demo.hellomodule/module-info.java src/demo.hellomodule/demo/hellomodule/Main.java $java --module-path module -m demo.hellomodule/demo.hellomodule.Main [/code] เพียงเท่าที่ก็สามารถใช้งาน Java Module ได้แล้ว

แต่ในการทำงานจริง ๆ นั้น แต่ละ Module ต้องทำงานร่วมกัน

ดังนั้นมาดูหน่อยสิว่าต้องทำอย่างไร ? ก่อนอื่นสร้างอีก module ขึ้นมาชื่อว่า demo.module.calculator โดยจะมี class Calculator ให้ใช้งาน ซึ่ง module นี้จะต้อง export package ของ class Calculator ด้วย เพื่อให้ module อื่น ๆ สามารถใช้งานได้ เริ่มด้วยการสร้างไฟล์ module-info.java ดังนี้ [gist id="6a470c7f363e44f1d40e76871093103d" file="module-info2.java"] จากนั้นทำการสร้าง class Calculator ขึ้นมา โดยมีเพียง method add() ดังนี้ [gist id="6a470c7f363e44f1d40e76871093103d" file="Calculator.java"] โดยใน module จะมีโครงสร้างดังนี้

ทำการ compile module นี้ด้วยคำสั่ง [code] $javac -d module/demo.module.calculator src/demo.module.calculator/module-info.java src/demo.module.calculator/demo/module/calculator/Calculator.java [/code] จากนั้นทำการแก้ไข code ใน Hello module เริ่มจากแก้ไขไฟล์ module-info.java เพื่อระบุว่าจะใช้ package จาก module Calculator [gist id="6a470c7f363e44f1d40e76871093103d" file="module-info3.java"] ทำให้สามารถเรียกใช้ class Calculator ได้ดังนี้ [gist id="6a470c7f363e44f1d40e76871093103d" file="Main2.java"] เมื่อทุกอย่างเรียบร้อยก็ทำการ compile และ run ด้วยคำสั่ง [code] $javac --module-path module -d module/demo.hellomodule src/demo.hellomodule/module-info.java src/demo.hellomodule/demo/hellomodule/Main.java $java --module-path module -m demo.hellomodule/demo.hellomodule.Main [/code] ซึ่งโครงสร้างรวมของ demo project เป็นดังรูป

เพียงเท่านี้เราก็สามารถลองใช้งาน Java Module ใน JDK 9 แบบง่าย ๆ ได้แล้ว ย้ำว่าแบบง่ายนะ !! สามารถดู source code ได้จาก Github::Up1::Demo Java Module ปล. ถ้าใครไม่ชอบมานั่ง compile เอง ไปใช้ IntelliJ IDE 2017 ได้นะครับ

อ่านบทความเรื่องการพัฒนา Android app ของ Basecamp ซึ่งมีความน่าสนใจตรงที่ทำการพัฒนาด้วยภาษา Kotlin ทั้งหมด ทางทีมพัฒนาได้เล่าและสรุปประสบการณ์ในการพัฒนา ตั้งแต่เริ่มจน publish app ออกมาให้ทุกคนได้ใช้ รวมระยะเวลากว่า 1 ปี ดังนั้นจึงนำมาแปลและสรุปในสิ่งที่น่าสนใจไว้นิดหน่อย

เริ่มต้นในการเลือกใช้ภาษา Kotlin ในการพัฒนานั้น

ทีมพัฒนาเชื่อว่า 1. ทำให้นักพัฒนามีความสุขในการพัฒนา 2. ช่วยปรับปรุงคุณภาพและความเร็วในการพัฒนา ซึ่งผลที่ออกมามันก็ใช้ได้เลย โดยทีมพัฒนาทำการแบ่งปันประสบการณ์และคำแนะนำในการพัฒนาระบบ ว่าการเปลี่ยนจากภาษา Java มาเป็นภาษา Kotlin ทั้งหมดเป็นอย่างไร ? เริ่มต้นอย่างไร ? ควรจะต้องดูและใส่ใจอะไรบ้าง ? แนะนำการเรียนรู้ภาษา Kotlin ว่าทำอย่างไร ?

พื้นฐานสำคัญที่สุด

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

VDO เรื่อง Kotlin for Android พูดโดยคุณ Jake Whaton ซึ่งเป็น VDO ที่ทำให้ทีมพัฒนาตัดสินใจเลือกใช้ภาษา Kotlin (ถ้าใครไม่รู้จักคนนี้ถือว่าบาปมาก ๆ อันนี้ผมเขียนเอง )
Feature ต่าง ๆ ของภาษา Kotlin ที่ทีมพัฒนาชอบ
หนีไม่พ้นสำหรับเอกสารจากทาง Kotlin Document

การเริ่มต้นพัฒนาด้วยภาษา Kotlin จะช้า แต่ให้เขียนบน product code เลย

แน่นอนว่าการเริ่มต้นมันยากเสมอ แถมใช้เวลามากด้วย ยังมีแรงกดดันต่าง ๆ อีกมากมาย บางคนบอกให้เริ่มด้วย test บางคนบอกให้เริ่มด้วย Gradle plugin บ่อยครั้งมันทำให้สับสน ไม่ไปไหนสักที ดังนั้นทีมพัฒนาจึงบอกว่า ให้เริ่มที่ production code ไปเลย เนื่องจากมันทำให้เราเห็นเลยว่า สิ่งที่เราพัฒนามัน work นะ เนื่องจากมันทำให้ทีมพัฒนาสนุกเมื่อเห็นความสำเร็จเล็ก ๆ เป็นการสร้างความเชื่อมันให้ทีม ในการเริ่มต้นอย่าทำการ convert จาก class ที่มีขนาดใหญ่ แต่ให้เริ่มจาก class เล็ก ๆ เช่น Utility, Helper เป็นต้น หลัก ๆ คือเสริมสร้างความมั่นใจล้วน ๆ ทำการพัฒนาและเรียนรู้แบบค่อยเป็นค่อยไป

อย่าเรียนรู้ feature ทั้งหมดของภาษา Kotlin ในครั้งเดียว

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

เรียนรู้จาก Auto convert

เนื่องจาก Kotlin plugin นั้นสามารถช่วย convert code จาก Java เป็น Kotlin ได้ เพื่อเรียนรู้ว่ามันทำงานอย่างไร เพื่อเรียนรู้โครงสร้างของภาษาว่าเป็นอย่างไร อย่าเอาแนวทางที่แย่ ๆ ของภาษา Java มาใช้นะ !! เช่นการใช้ if-else แนะนำให้ใช้ when แทน เช่นการตรวจสอบค่า null แนะนำให้ใช้ object?.let{} แทน การเขียนภาษา Kotlin ก็ต้องเขียนด้วยแนวทางของภาษานั้น ๆ ด้วย (Kotlin way) ที่สำคัญต้องค่อย ๆ ปรับปรุง ค่อย ๆ แก้ไขให้ดีขึ้น นั่นคือ code ต้องดีขึ้นกว่าเดิมเสมอ เรื่องนี้มันคือ mindset ของทีม ดังนั้นอย่าขี้เกียจนะครับ

อีกข้อที่สำคัญคือ ใช้ feature ของภาษาในแนวทางที่ถูกต้องด้วย

เช่นการใช้ when มากจนเกินไปก็ไม่ได้ เช่นการสนใจจำนวนบรรทัดน้อย ๆ จนมากเกินไปก็ไม่ดี เช่นการเขียน extension function มากจนเกินไปก็ไม่ดี มันส่งผลให้ code ที่ออกมาดูแลต่อไปยากมาก

สิ่งที่สำคัญมาก ๆ คือ ลูกค้า ดังนั้นอย่าลืม !!

ไม่ว่าภาษา Kotlin มันจะดีเพียงใด ไม่ว่าภาษา Kotlin มันจะทำให้ทีมพัฒนามีความสุขมากเพียงใด ให้จำไว้ว่า ลูกค้าไม่ได้สนใจมันเลย ดังนั้นคุณภาพของระบบที่พัฒนาออกมาจึงสำคัญสุด ๆ ห้ามลืม แน่นอนว่า ถ้าทีมพัฒนามีความสุขแล้ว จะส่งผลให้ code ดี นั่นคือส่งผลดีต่อระบบที่พัฒนา ซึ่งก็สำคัญเช่นกัน ดังนั้นให้รักษาสมดุลไว้ด้วย (win-win)

สุดท้ายอย่าเดินไปคนเดียว !!

ลองคิดดูสิ ถ้าเริ่มเขียน Kotlin เพียงคนเดียว มันไม่น่าจะรอดอย่างแน่นอน ดังนั้นหาเพื่อนซะ เพื่อแบ่งปันกัน เพื่อแนะนำกัน เพื่อจะเดินไปอย่างสนุกสนาน

หลังจากที่ทาง Google Chrome ได้ปล่อย feature ทำงานแบบ headless mode ในเวอร์ชัน 59 (Cannary) วันนี้มาลองใช้งานร่วมกับการทดสอบแบบอัตโนมัติด้วย Robotframework + Selenium2Library กันหน่อย ซึ่งพบว่าใช้งานไม่ยากเลย มาเริ่มต้นกันหน่อย ปล. ก็คือการทดสอบระบบ web ด้วย Selenium WebDriver นั่นเอง

Software ที่ต้องใช้งาน

Mac OS
Google Chrome version 59 (Canary version)
Google Chrome Driver version 2.29
Robotframework + Selenium2Library

มาเขียน code กันดีกว่า

ในการเขียน code ของ Robotframework นั้น ถ้าเราต้องการใช้ Google Chrome ตาม path ที่เราต้องการ รวมทั้งกำหนด headless mode แล้ว จะต้องทำการกำหนดใน Chrome option ด้วย ซึ่งใน Robotframework สามารถเขียนง่ายได้ดังนี้ [gist id="0d299f6aebfd3bdcf7e863bcc98c0be7" file="hello.robot"] เพียงเท่านี้ก็สามารถใช้งาน Chrome headless แบบง่าย ๆ ได้แล้ว