cc :: somkiat

ทาง Firebase ได้ปล่อย Cloud Firestore ใน beta version ซึ่งเป็น NoSQL database มีโครงสร้างข้อมูลแบบ Document พูดง่าย ๆ คือโครงสร้างข้อมูลเดียวกับ MongoDB แต่อยู่บน Cloud platform นั่นเอง สามารถใช้ทั้ง iOS, Android และ Web ตลอดจนสามารถ integate ได้กับของที่มีอยู่ใน Firebase ได้เลย รวมทั้ง Google Cloud Platform, Cloud function ยังไม่พอนะ ตามแนวทางของ Firebase คือใช้ง่ายและรองรับการ scale อีกด้วย

ความสามารถหลัก ๆ ของ Cloud Firestore

Document-based และ collection ตามปกติ
รองรับการทำงานแบบ offline mode ทั้ง Android, iOS และ Web
Realtime synchronous
ทำการ Replicate ข้อมูลแบบ multi-region ให้แบบอัตโนมัติ ทำให้ไม่ต้องกลัวข้อมูลหาย ถ้าโลกไม่แตก !!
มี SDK ให้ใช้พัฒนาทั้งภาษา Node, Python, Go และ Java

ไปดู VDO แนะนำได้เลย https://www.youtube.com/watch?v=QcsAb2RR52c

สิ่งที่น่าสนใจมาก ๆ สำหรับนักพัฒนาคือ

จัดเก็บข้อมูลเป็น Document-based นี่แหละ ที่น่าจะเข้าใจได้ง่าย ไม่ต้องเรียนรู้อะไรเพิ่มเติมมากนัก ยิ่งเป็น infrastructure ของ Google อีก รวดเร็วแน่นอน

ในการพัฒนาระบบจะมี collection ที่สัมพันธ์กัน หรือ sub-collection ทำให้การออกแบบง่ายขึ้น

ในการดึงข้อมูล จะดึงเท่าที่จำเป็นเท่านั้น (shallow) นั่นหมายความว่าไม่ต้องไปดึงข้อมูลที่สัมพันธ์กันมาทั้งหมด ดังนั้นความสัมพันธ์ที่เราเห็นนั้น มันเป็นแค่ในแง่ของ logical เท่านั้น ซึ่งตรงนี้ส่งผลต่อประสิทธิภาพในการดึงข้อมูลอย่างมาก

แถมมีคำแนะนำให้สร้าง index อีกด้วย

ส่วนเรื่อง security ก็มีมาให้ เพราะว่าได้เตรียมเรื่อง security rule มาให้พร้อมเลย ทำให้สามารถควบคุมสิทธิ์ในการเข้าถึงข้อมูลได้

อีกอย่างหนึ่งถ้าใครใช้ Realtime database มาก่อน

จะพบว่า ถ้า app มีขนาดใหญ่และการเก็บข้อมูลซับซ้อนขึ้น จะทำให้ JSON data model มันซับซ้อนและมีปัญหาเรื่องประสิทธิภาพ ได้ ดังนั้น Cloud Firestore จึงเข้ามาช่วยตรงจุดนี้

มาถึงเรื่อง Pricing บ้าง จะต่างกับ Realtime database เลย

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

ดังนั้นนักพัฒนาลองมาใช้งานกันดู

เริ่มได้จาก Sample App มี CodeLab ให้อีก ใจดีมาก ๆ

ถ้ามีปัญหาอะไรก็ไปถามใน StackOverflow ได้ เพิ่มเติมสำหรับ Android Developer https://www.youtube.com/watch?v=kDZYIhNkQoM สำหรับชาว Web Developer https://www.youtube.com/watch?v=2Vf1D-rUMwE ขอให้สนุกกับการ coding นะครับ

มีโอกาสคุยกับกลุ่มในสาย Data Science พบว่า ปัญหาหลัก ๆ ของคนกลุ่มนี้คือ เรื่องการจัดการ environment ที่ใช้งาน ประกอบไปด้วย

ปัญหาในการติดตั้ง software
ปัญหาในการติดตั้ง library หรือ dependency ต่าง ๆ
ปัญหาในการ configuration และ setting ค่าต่าง ๆ

ทำให้ขั้นตอนการวิเคราะห์ข้อมูลมันช้าอย่างมาก บางคนใช้ได้ บางคนใช้ไม่ได้ บางองค์กรต้องรอให้ฝ่าย IT มาทำการติดตั้งให้ ถ้าขั้นตอนการทำงานช้า ก็รอกันต่อไป หรือแม้แต่การนำเครื่องมือใหม่ ๆ มาใช้ ก็ยากเย็นเหลือเกิน บางครั้งทำเองได้ แต่ก็ลืม ลืมขั้นตอนการติดตั้งและ configuration ลืม configuration ค่าต่าง ๆ ที่ไปหาจาก internet !! บ่อยครั้งพบว่า library ต่าง ๆ ที่ใช้ ไม่ได้ update version ใหม่ ๆ มาใช้เลย บางคนใช้ version เก่า ๆ มาเป็นปี ๆ !! เราทำงานเป็นทีม Data Science นะ แต่ว่า ... แต่ละคนต่างคนต่างทำ OS ที่ใช้งานต่างกัน เครื่องมือที่ใช้ต่างกัน หรือถ้าเหมือนกัน แต่ configuration ต่างกัน หรือทำไปเปลี่ยนไป หรือไม่สามารถ run งานเก่า ๆ ได้เลย เนื่องจาก environment ต่าง ๆ มันเปลี่ยนไปหมดแล้ว ผลที่ตามมาแล้วจะทำอย่างไรละ ? ต้องทิ้งงานนั้นกันไปหรืออย่างไร ? ยิ่งรับสมาชิกใหม่เข้ามาในทีมยิ่งลำบาก เพราะว่า เพียงแค่การติดตั้ง environment ให้เริ่มทำงานได้ก็ยากแล้ว บางคนถึงขั้นถอดใจ ออกดีกว่า สุดท้ายถ้าทำการ update/upgrade สิ่งต่าง ๆ แล้ว ไม่รู้เลยว่ามันส่งผลกระทบต่อส่วนการทำงานใดบ้าง ดังนั้นก็วนกลับไปเรื่องเดิมคือ ไม่ต้องทำอะไร มันทำงานได้ !!

บริษัทต่าง ๆ เขาแก้ไขปัญหานี้อย่างไรกันนะ ?

เท่าที่คุยมาก็มีอยู่ 2 แบบคือ

แบบที่ 1 ใครอยากทำอะไร ติดตั้งอะไรก็ทำไปเลย ง่ายนะ เร็วด้วย แต่ว่าต่างคนก็ต่างไปคนละทาง
แบบที่ 2 บริษัททำการควบคุมทุกอย่าง ลงได้เท่าที่กำหนดเท่านั้น ทำให้ฝ่าน IT ควบคุมได้หมด แต่สำหรับคนใช้มันยากต่อการเปลี่ยนแปลงมาก ๆ

ไม่ว่าแบบไหนก็มีปัญหากันไปคนละแบบ แต่ก็ไม่ได้แก้ไขปัญหาให้หมดไป ดังนั้นมีวิธีการอื่น ๆ อีกไหมละ ?

หนึ่งในวิธีการที่ขอแนะนำคือ Docker

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

ปัญหาที่มักเจอเช่น Python 2.7 vs 3.x

คำถามคือ ลำบากไหมที่ต้องสลับ version ของ Python ไปมา !! เลยยกตัวอย่างของการนำ Docker มาแก้ไขปัญหาเหล่านี้นิดหน่อย เริ่มด้วยการสร้าง Docker Image สำหรับ Python 3 ขึ้นมาก่อน มี library ที่ต้องการใช้คือ

numpy
scipy
scikit-learn

ทำการกำหนด library เหล่านี้ไว้ในไฟล์ชื่อว่า requirements.txt [gist id="e5bf51998c094843bcce62818defb2e2" file="requirements.txt"] ทำการสร้าง Dockerfile ไว้ใช้สำหรับสร้าง Docker Image มีขั้นตอนดังนี้

เลือก base image เป็น Python 3.6.8
กำหนด working directory
ทำการ copy ไฟล์ requirements.txt เข้าไป
ทำการ copy ไฟล์ทั้งหมดเข้าไป
ทำการติดตั้ง library ต่าง ๆ ที่กำหนดไว้ในไฟล์ requirement.txt
กำหนดให้ทำการ run คำสั่ง python app.py เพื่อทดสอบไฟล์ที่เราต้องการนั่นคือ app.py

[gist id="e5bf51998c094843bcce62818defb2e2" file="Dockerfile"] เรายังขาดไฟล์ app.py ซึ่งเป็น code ทำงานของเรานั่นเอง ตรงนี้เอาที่สบายใจเลย เมื่อทุกอย่างเรียบร้อย ทำการสร้าง image จาก Dockerfile และสร้าง container เพื่อทำงานตามที่ต้องการ ดังนี้ [code] $docker image build -t my_python_3 . $docker container run --rm my_python_3:latest [/code] เพียงเท่านี้ก็สามารถทำงานได้แล้ว ง่ายมาก ๆ แต่ที่เหลือยากหมดเลย !!!

ขอยกตัวอย่าง Docker image ที่น่าสนจาก Kaggle

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

kaggle/python สำหรับภาษา Python
kaggle/rstats สำหรับภาษา R
kaggle/julia สำหรับภาษา Julia

แต่ขนาดของ Docker image เหล่านี้จะมีขนาดใหญ่มาก ๆ เนื่องจากมี library ต่าง ๆ เพียบนะครับ ยกตัวอย่างเช่น kaggle/python มีขนาดกว่า 900 MB ดังนั้นใช้งานแบบมีสตินะครับ เพียงนำสิ่งเหล่านี้ไปใช้ ก็สามารถเริ่มในสิ่งที่ต้องการได้แล้ว ถ้าใครไม่พอใจ ก็นำไปแก้ไขหรือสร้างใหม่ให้กับทีมได้เลยครับ

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

ขอให้สนุกกับการ coding ครับ

วันนี้ไปร่วมงาน GDG DevFest Bangkok 2017 มี session ที่น่าสนใจเยอะเลยแบ่งออกเป็น 3 ห้อง ดังนั้นก็ต้องเลือกเข้า session ในห้องใดห้องหนึ่งไปเลย โดย session แรกที่ได้เข้าไปคือ One Espresso with Kotlin, please เป็นการแนะนำและทำ workshop เกี่ยวกับ การเขียน UI Test ของ Android app ด้วย Espresso ที่น่าสนใจคือ เขียนด้วยภาษา Kotlin แต่ที่น่าสนใจกว่าคือ การออกแบบ DSL (Domain Specific Language) สำหรับการทดสอบ ซึ่งทำให้ชุดการทดสอบอ่านง่าย เข้าใจง่าย มันสวยนะ มาดูกันนิดหน่อย

หน้าขอการทำงานของ app ใน workshop เป็นดังนี้

เริ่มด้วยชุดการทดสอบ UI test ด้วย Kotlin

ไม่ได้แตกต่างจากภาษา Java มากนัก แค่สั้นลงนิดเดียว เขียน code ได้ดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="1.kt"]

ถ้าเขียนแบบนี้ ดูจะง่ายไปเกินไป ยังไม่ได้ใช้ความสามารถของภาษา Kotlin กันเลย !! มาดูสิ่งที่สนุกสำหรับ session นี้คือ การออกแบบ DSL สำหรับใช้ในการทดสอบ

สิ่งที่ต้องทำคือ การออกแบบ DSL

ใน workshop พาออกแบบง่าย ๆ ดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="2.kt"] คำอธิบาย ในการ click item ใน list (RecyclerView) ตามตำแหน่งที่ต้องการ สิ่งที่ต้องการคือ สร้าง class KView ขึ้นมา ต้องกำหนด id ของ RecyclerView จากนั้นจะเรียก method perform() เพื่อสั่งให้ทำการ click item ตามตำแหน่งที่ต้องการ เหมือนจะง่าย แต่ไม่ง่ายเลย เนื่องจากใน workshop นำความสามารถของ Kotlin มาใช้งาน เช่น

extension เพื่อเพิ่ม method perform() เข้ามาใน class KView
infix เพื่อให้สามารถเรียกใช้งาน method perform() แบบสวย ๆ ไม่ต้องใช้ dot(.)

สามารถเขียน code ใน Helper.kt ได้ดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="Helper.kt"] ตัวอย่าง source code ของ Workshop อยู่ที่ Github :: Sneaker-app

ว่าง ๆ เลยลองนั่งคิดว่า ไม่ต้อง generic ขนาดนี้ก็ได้ (มือใหม่หัดมั่ว)

จึงลองนำแนวคิด Page Object มาลองใช้งาน ทำการออกแบบ DSL สำหรับการทดสอบใหม่นิดหน่อย เป็นดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="3.kt"] ดูไม่ค่อยดีเท่าไร แต่ก็พอทน !! เมื่อออกแบบแล้ว ถึงเวลาสร้างมันขึ้นมากันแล้ว เริ่มจากการสร้าง class ProductPage ขึ้นมา ทำหน้าที่สำหรับการเลือก product ในตำแหน่งที่ต้องการ ดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="ProductPage.kt"] จากนั้นสร้างส่วนของการตรวจสอบข้อมูลในหน้า Product Detail ตั้งชื่อว่า class ProductDetailPage ดังนี้ [gist id="e1bf46a2f1689831d8a96600c4d37b5f" file="ProductDetailPage.kt"] เพียงเท่านี้ก็ได้ชุดการทดสอบแบบสวย ๆ แล้ว !!

ปล. ผมเขียนภาษา Kotlin ไม่เป็นนะครับ แค่ลองมั่ว ๆ ไปเท่านั้นเอง

ข้อเสียของ session นี้คือ

การ setup project สำหรับคนเริ่มต้นใหม่ ก็ download library และ build นานหน่อย บวกกับระบบ WIFI ก็เข้าได้บ้างไม่ได้บ้าง ทำให้เหนื่อยหน่อย ส่วนเรื่องของเนื้อหาก็ถือว่า ยังไม่เยอะเท่าไร แต่ได้แนวทางและแรงบันดาลใจเยอะเลย

โดย speaker ที่มาจาก Agoda บอกว่า ในวันจันทร์นี้จะเปิดเผย source code ชุดสร้างการทดสอบ DSL ด้วย Kotlin ชื่อว่า KaKao ให้ด้วยนะ ใจดีมาก ๆ ไว้วันจันทร์มาลองกัน !!

ขอให้สนุกกับการ coding นะครับ

ก่อนทำงานมานั่งสรุป extension ใน Google Chrome ที่ใช้งานเป็นประจำ ซึ่งคิดว่าน่าจะมีประโยชน์สำหรับนักพัฒนาบ้าง แต่เท่าที่ใช้มาคิดว่ามีประโยชน์ แถมช่วยเพิ่ม productivity ด้วยนะ ลองมาดูว่ามีอะไรบ้าง 1. TwitterDeck App สำหรับจัดการข้อมูลต่าง ๆ ใน twitter (บางคนถึงจะเล่น) เนื่องจากสามารถทำการกรองข้อมูลในสิ่งที่ต้องการได้ ช่วยให้เราคัดกรองข้อมูลได้เป็นอย่างดี ที่สำคัญต่างประเทศเขาใช้กันเยอะนะ และ ข้อมูลเพียบเลย ยกเว้นไทยมั้ง !! ที่จะนิยม Facebook และ Line กัน 2. Feedly App ใช้สำหรับการจัดการ feed ต่าง ๆ ซึ่งถ้าเราชอบ web ไหน แล้วเขาเปิด feed เช่น RSS/Atom ให้ ก็ใช้ feedly จัดการไปเลย จะหมวดหมู่ต่าง ๆ ได้ง่าย เหมาะมากกับโลกที่ข้อมูลเยอะเหลือเกิน ดังนั้นจำเป็นต้องเลือกที่จะศึกษาและติดตาม 3. Postman App ใช้สำหรับการทดสอบ web และ API ซึ่งใช้ง่ายถ่ายคล่อง อาจจะช้าหน่อย แต่คิดว่าเป็นของที่ใช้แล้วติดมือ รวมทั้งถ้าต้องการความสามารถเพิ่มเติมแนะนำให้ติดตั้ง Postman Interceptor Extension เพิ่มนะครับ 4. Octotree extension สำหรับการใช้งาน Github และ Bitbucket ให้ง่ายขึ้น โดยจะแสดง menu แบบ tree ทางด้านซ้ายมือ ใน tree นั้นจะเป็น file และ folder ใน repository ของเรานั่นเอง ซึ่งทำให้ง่ายต่อการเข้าถึงไฟล์ต่าง ๆ อย่างมาก ติดตั้งเถอะนะ ขอร้อง 5. JSONView extension สำหรับแสดงผล JSON response ใน browser แบบสวยงาม ถ้าใครยังแสดง JSON reponse แบบ plain text หรือต้องเข้าไปดูใน developer tool อยู่ แนะนำเลยว่าติดตั้งเถอะ จะได้ไม่เป็นภาระนะครับ มาถึง Extension เฉพาะงานกันบ้าง 1. Sourcegraph for Github extension สำหรับคนที่ใช้ Github บ่อย ๆ เมื่อเจอ code ต่าง ๆ อยากทำการค้นหา อยากรู้ว่า reference เป็นอย่างไร อยากรู้ว่าเขียนหรือใช้งานอย่างไร ใช้ตัวนี้เลย ง่ายและสะดวกมาก ๆ สนับสนุนทั้งภาษา Go, Java, TypeScript และ Python 2. Elasticsearch Head extension ตัวนี้สำหรับจัดการข้อมูลต่าง ๆ ใน Elasticsearch ซึ่งเป็น realtime search engine ที่น่าสนใจ ที่ต้องมาใช้ตัวนี้เพราะว่า version ใหม่ ๆ ของ Elasticsearch มันลบ plugin ต่าง ๆ ทิ้งไป ดังนั้นจึงต้องย้ายออกมานั่นเอง สำหรับนักพัฒนาที่ใช้ Elasticsearch แนะนำว่าต้องใช้ตัวนี้นะ 3. JSON to Golang extension สำหรับคนขี้เกียจแบบผม ขี้เกียจเขียน code ภาษา Go ในการแปลงจาก JSON มาเป็น code ดังนั้นใช้ extension ตัวนี้เลยง่ายดี !! 4. Apollo Client Developer Tool extension สำหรับนักพัฒนาสายติดตามของใหม่ ๆ อย่าง GraphQL คงไม่ค่อยพลาด เป็นเครื่องมือในการ debug สำหรับ Apollo client มีทั้ง console ในการ query และ inspector ต่าง ๆ ถือว่าอำนวยความสะดวกเยอะเลย 5. Service Worker Detector extension ปิดท้ายด้วยตัวนี้ดีกว่า ใช้สำหรับตรวจสอบว่า web ไหนทำการใช้งาน Service Worker บ้าง เพื่อระวัง website ที่อาจจะมาใช้เครื่องเราขุด bitcoin นะเออ !! เพิ่มอีกตัว มันไร้สาระมาก ๆ คือ Comment to Cats สุดท้ายนี้ใครมี extension ดี ๆ มีประโยชน์ก็แนะนำกันได้นะ

ปล. สำหรับ Google Chrome นั้นสิ่งที่ต้องระวังให้มาก ๆ คือ แต่ละ Tab มันกิน RAM มากนะครับ พวก extension ก็เช่นกัน

ขอให้สนุกกับการ coding ครับ

ช่วงวันที่ 1 ถึง 5 ตุลาคมที่ผ่านมามีงานใหญ่ของโลก Java คือ JavaOne 2017 อาจจะเงียบ ๆ หน่อย แต่ก็มีสิ่งที่น่าสนใจมากพอควร จึงทำการสรุปจาก VDO Keynote มานิดหน่อย น่าจะพอทำให้เห็นทิศทางของโลก Java ได้บ้าง รวมทั้ง vendor เจ้าใหญ่ ๆ ของโลก และ แนวทางของ Oracle มาเริ่มกันเลย

Java EE 8

Java First , Open, Nimble และ Scalable ฟังดูดีมาก ๆ แต่ว่า Java EE 7 นั้นปล่อยออกมาเมื่อ 4 ปีที่แล้ว มันเร็วใช่ไหม ? การเปลี่ยนแปลงครั้งสำคัญของ Java EE 8 คือ Java EE จะถูกปล่อยออกมาเป็น open source ทั้งหมด ซึ่งอยู่ภายใต้ Eclipse Foundation นั่นคือย้ายทุกสิ่งอย่างของ Java EE มายัง Eclipse foundation ทั้งหมด ชื่อใหม่คือ EE4j (Eclipse Enterprise for Java) ส่วนเรื่องของ feature ต่าง ๆ ของ Java EE 8 นั้น จะเป็นไปตาม Java SE 8 และของใหม่ ๆ เช่น

JAX-RS 2.1 สนับสนุน reactive แล้ว
Servlet 4.0 นะ นั่นคือสนับสนุน HTTP 2.0 ด้วย

รวมทั้งเปิดตัว MicroProfile 1.2 อีกด้วย แน่นอนว่า ย้ายมายัง Eclipse foundation อีกด้วย

Java 9

สิ่งที่น่าสนใจคือ feature ของ Oracle JDK จะเหมือนกับ OpenJDK ทั้งหมด มีรอบการ release ทุก ๆ 6 เดือน โดยที่ feature ใหม่ ๆ ที่จะเพิ่มเข้ามาต้องเสร็จแล้วเท่านั้น

ทางฝั่งของ Oracle ได้เปิดตัวของใหม่ ๆ เช่น

Oracle Autonomous Database Cloud ซึ่งทำงานแบบอัตโนมัติเกือบทั้งหมด เช่น การทำ patching, upgrade, backup และ availability แน่นอนไม่ต้องการคนมาดูแล รวมทั้งยังเปิดตัว FN Project หรืออาจจะเรียกว่า Java Function เป็น opensource serverless platform จากทาง Oracle สร้างมาเพื่อสู้กับ AWS Lamda ยังไม่พอนะทาง Oracle นั้นยังได้ลงทุนลงแรงไปกับ Kubernetes มากอีกด้วย ซึ่งเป็นสิ่งที่น่าสนใจอย่างมาก แต่มีดูทิศทางและความสามารถของ Kubernetes แล้ว ก็น่าจะเข้าใจได้เลยว่า Oracle กำลังจะเดินไปทางไหน ดู VDO เพิ่มเติมได้เลยครับ https://www.youtube.com/watch?v=Tf5rlIS6tkg

เจอ Infographic เรื่อง 11 types of programmers ทำการแบ่งกลุ่มของ programmer ออกเป็น 11 กลุ่มได้อย่างน่าสนใจ จึงนำมาสรุปไว้นิดหน่อย คำถามที่น่าสนใจคือ เราอยู่กลุ่มไหนกันบ้าง ? กลุ่มที่ 1 Community Leader เจอตัวได้ในงาน meetup ต่าง ๆ มีเพื่อน ๆ เยอะ

กลุ่มที่ 2 The Anal Syntax Nazi programmer ในกลุ่มนี้จะมีความเป็นระเบียบสูงมาก มี drama ที่ไหนเกี่ยวกับ programming เจอได้ทางตัวอักษร สามารถจดจำ style guide ของบริษัทได้หมด

กลุ่มที่ 3 The Inept Outsourced Coder programmer ในกลุ่มนี้จะไม่ค่อยเข้าใจตอนคุย requirement มักจะบอกว่า เป็นแบบนี้จริงหรอ ? งานงอกจะเยอะ ชอบไม่อยู่หรือติดต่อไม่ได้ในเวลาปกติ หายไปเฉย ๆ ชอบเขียน code แย่ ๆ ออกมา ทำให้เสร็จ ๆ ไป แน่นอนว่าสุดท้ายคนจ้างก็ต้องมาเขียนใหม่เสมอ

กลุ่มที่ 4 The new thing evangelist programmer ในกลุ่มนี้เรียนในสิ่งใหม่ ๆ อยู๋อย่างเสมอ รู้ภาษาโปรแกรมต่าง ๆ เยอะมาก แต่ในงานยังใช้ของเก่า ๆ อยู่ !! ชีวิตมันเครียด จึงต้องหาสิ่งใหม่ ๆ บ้าง

กลุ่มที่ 5 The open source wizard programmer ในกลุ่มนี้ชอบแบ่งปัน ทั้ง การตอบคำถามต่าง ๆ ใน webboard/forum เช่น StackOverflow การพูดใน meetup/conference ของกลุ่ม programmer มีกิจกรรมใน github สูง ๆ

กลุ่มที่ 6 The Sage programmer ในกลุ่มนี้รู้ทุกสิ่งอย่าง อะไรพังหรือกำลังจะพังรู้หมด เหมือนนกรู้เลย แต่ว่ามีเครื่องมือใช้เพียบ รู้และมีความเชี่ยวชาญในภาษาโปรแกรมต่าง ๆ เยอะ ค่าตัวของคนกลุ่มนี้มักจะสูงมาก ๆ เมื่อเทียบกับ programmer โดยเฉลี่ย (สิบเท่า)

กลุ่มที่ 7 The Data Scientist programmer ในกลุ่มนี้จะพูดในภาษาที่ programmer คนอื่น ๆ ไม่เข้าใจ มักจะเขียนด้วยภาษา Python และ R ส่วนใหญ่จะมีดีกรีปริญาโทหรือเอก

กลุ่มที่ 8 The Noob programmer ในกลุ่มนี้มาเขียน code เพราะว่ารู้สึกว่ามันแจ่ม สามารถจ่ายเงินเพื่อเข้าร่วมงาน programming bootcamp ต่าง ๆ ได้ ส่วนใหญ่จะต้องพึ่งกลุ่ม Open source wizard

กลุ่มที่ 9 The Security Expert programmer ในกลุ่มนี้จะรู้เทคนิคเกี่ยวกับการเจาะระบบ ทำการ hack ระบบต่าง ๆ เป็นงานอดิเรก มักใช้จะ Ghostery และ VPN ในการซ่อนตัวตน แน่นอนว่า ทุก ๆ คนกลัวคนในกลุ่มนี้

กลุ่มที่ 10 The Hipster Coder programmer ในกลุ่มนี้มักจะมีแรงบันดาลใจ ว่าอยากเป็นคนนั้นคนนี้ บางครั้งจะทำการเขียน code ด้วยภาษา JavaScript หรือ Swift แน่นอนว่าใช้เครื่อง MacBook ที่บ้านมีลำโพงดี ๆ แพง ๆ หูฟังขั้นเทพ จะละเอียด ๆ ใหญ่ ๆ เอาไว้เขียน code !!

กลุ่มที่ 11 The Struggling Project Manager programmer ในกลุ่มนี้คนที่ทำงานร่วมด้วยมักไม่ค่อยชอบขี้หน้าเท่าไร ชอบบอกให้คนร่วมงาน ทำให้เสร็จตามที่สั่ง โดยไม่สนใจอะไรทั้งสิ้น แต่ถ้ามีคนถามว่า ทำไมถึงทำงานนี้ ? มักจะตอบออกทำนองว่า งานนี้มันคือความฝันของ ... แต่ในความจริงคือ เงินดีนั่นเอง

จากการ์ตูนขำ ๆ เรื่อง Business logic on the Frontend ก่อให้เกิดคำถามหนึ่งขึ้นมาคือ เราเขียน Business logic ของระบบไว้ที่ไหนกันบ้าง ?

Frontend ฝั่ง Client side เช่น JavaScript, Mobile app เป็นต้น
Frontend ฝั่ง Server side หรือเรียกว่า Web/Presentation Tier
Backend
Database เช่น Store procedure เป็นต้น

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

บางคนอาจจะบอกว่า สิ่งที่เกิดขึ้นแล้วมันดีเสมอ !! สิ่งที่อยู่บน production ที่ทำงานได้ ก็ดีนะ !!

ยกตัวอย่างเช่น

ระบบงานพัฒนาด้วยภาษา JavaScript stack ในส่วนของ Frontend ฝั่ง client side นั้น ก็ใช้พวก JavaScript framework ต่าง ๆ ไม่ว่าจะเป็น React, Angular และ Vue บ่อยครั้งพบว่า นำ business logic รวมทั้งการควบคุม flow หรือ ขั้นตอนการทำงานไว้ในส่วนนี้ ส่วนของ Backend ก็เพียงสร้าง REST APIs ที่ทำงานเพียง CRUD (Create Read Update Delete) เท่านั้น ผลที่ตามมาคือ ส่วนมากจะแบ่งออกเป็น 2 ทีมคือ Frontend และ Backend งานในช่วงแรก ๆ Backend ดูเหมือนจะเยอะ แต่ไม่เยอะ เพราะว่า ทำเพียง CRUD เท่านั้น แต่งานในส่วนของ Frontend ดูเหมือนจะง่ายและน้อย กลับเยอะมาก ๆ ไหนจะส่วนของ UI ไหนจะส่วนของการจัดการกับ event/interaction จากผู้ใช้งาน ไหนจะส่วนการควบคุม flow การทำงาน มักจะเรียกว่า ร้อย flow การทำงาน ไหนจะจัดการกับ exception/error ต่าง ๆ ไหนจะ ... ดูแล้วเยอะไปหมด ยังไม่พอนะ เมื่อมีการเปลี่ยน UI และ Flow การทำงานมันจะนรกมาก ๆ พอปิดการ execute JavaScript ใน browser ก็ตายตามระเบียบ ทำการ validate ข้อมูลเฉพาะฝั่ง Frontend เท่านั้น !! จะจัดการ transaction กันอย่างไร ? ยังไม่พอนะ เราเห็นขั้นตอนการทำงานต่าง ๆ หมดเลย ฝั่ง Backend ก็ไว้ใจฝั่ง Frontend อีก ส่งข้อมูลอะไรมาก็ทำตามหมด โดยไม่สนใจ ไม่ตรวจสอบอะไรเลย เรื่อง security issue หนักเลย ปัญหาที่ตามมาอีกคือ ในแต่ละส่วนการทำงานนั้น เรียกใช้งาน Backend เยอะมาก ๆ เช่น การกดเพียง 1 ปุ่มเท่านั้น ก็ทำการเรียกฝั่ง Backend หลักสิบครั้งขึ้นไป !! มันเหมือนเป็นการระดมยิงระบบ แถมถ้าระบบ network ที่ใช้งานมีปัญหาก็น่าจะเกิดข้อผิดพลาดบ่อย ๆ ความน่าเชื่อถือของระบบก็น่าจะลดลงมั้ง มาถึงตรงนี้ชีวิตน่าจะนรกน่าดู

ดังนั้นเมื่อพัฒนาไปได้สักระยะหนึ่งเริ่มเจอปัญหาต่าง ๆ ที่ผ่านมา

จึงมีแนวคิดว่า เราน่าจะย้ายส่วน business logic และการควบคุม flow การทำงานมาไว้ที่ฝั่ง Backend นะ แต่เมื่อถึงเวลาทำก็ย้ายมาซะหมดเลย !! นั่นหมายความว่า งานฝั่ง Frontend มีเพียง การแสดงผล และ การจัดการ event ต่าง ๆ จากผู้ใช้งานเท่านั้น ส่วนการทำงานโยนมาฝั่ง Backend หมดเลย ผลที่ตามมาคือ จัดการเรื่อง transaction ได้ง่าย จัดการเรื่อง security ได้ง่าย แต่ งานฝั่ง Backend เยอะมาก ๆ บาง business logic มีขั้นตอนการทำงานที่เยอะและยาวนาน ฝั่ง Frontend ก็รอไป นานมาก ๆ ก็กำหนด timeout เยอะ ๆ ในส่วนการแสดงผลก็ดู loading กันไป แก้ไข business logic หนึ่งก็ไปกระทบส่วนอื่นอีก งานเยอะก็ bug เยอะ และปัญหาอื่น ๆ อีกเพียบ

ดูเหมือนว่าสองทางก็ไม่ค่อยรอดทำอย่างไรดีละ ?

บางครั้งก็เกิดสิ่งที่เรียกว่า Middleware ขึ้นมา ถ้าไปฝั่งใดฝั่งหนึ่งมันไม่ดี ดังนั้นเราหาระบบกลางขึ้นมาเพื่อจัดการ business logic ซะ !! ซึ่งเราจะเจอได้เยอะ เช่นพวก Enterprise Service Bus, API gateway รวมไปถึง GraphQL เป็นต้น แน่นอนว่าลดงานในส่วนของ Frontend และ Backend แต่เราได้เพิ่มความซับซ้อนของระบบ บ่อยครั้งจะกลายเป็น Single Point of Failure อีก (SPoF) เหมือนเรากำลังเจอปัญหา N + 1 นะ !! ชีวิตดูยากนะ แต่ผมเชื่อว่าแต่ละระบบมันมีคุณลักษณะที่แตกต่างกัน มีข้อจำกัด ไม่ใช่สิต้องบอกว่า ความท้าทายที่ต่างกัน ดังนั้นแบบไหนอาจะไม่ถูกหรือไม่ผิด แต่มันเหมาะสมไหม ? ทั้งจากองค์กรและทีม ดังนั้นระบบงานที่ดีมันจึงต้องพร้อมรับต่อการเปลี่ยนแปลงเสมอ ซึ่งการเปลี่ยนแปลงมันบ่อยเสียด้วย ระบบที่คุณกำลังสร้างมันตอบโจทย์เหล่านี้หรือไม่ ? ลองถามใจดูเอานะ

ยังไม่พอ บางระบบทำการเขียน business ไว้ใน Data Store เช่น Store procedure ใน RDBMS

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

คำถาม developer เขียน business logic ไว้ในส่วนใดบ้าง ?

UI Testing หรือ User Interface Testing UI คือส่วนที่ผู้ใช้งานเห็น และใช้งาน ทั้งการ click และ drag & drop ด้วย mouse ทั้งการกดปุ่มใน keyboard รูปแบบของ UI จะมี 2 แบบหลัก ๆ คือ

Command line
GUI (Graphic User Interface)

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

กลับมาในส่วนของการพัฒนาระบบ

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

ดังนั้น GUI คือหน้าต่างบานแรกที่สำคัญมาก ๆ

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

โดยที่ UI Testing นั้น ควรสร้างตั้งแต่เริ่มการพัฒนา เพื่อลดความเสี่ยงที่จะเกิดขึ้นในช่วงท้ายของการพัฒนา แต่เรามักไปทดสอบช่วงท้ายกัน ทำไมนะ ?

มาถึงตรงนี้แล้ว UI Testing คืออะไร ?

หลัก ๆ คือการทำให้มั่นใจว่า การทำงานผ่าน GUI มันถูกต้องตามที่คาดหวัง ระบบงานทำตาม specification ที่เขียนไว้นะ ระบบงานทำตามข้อตกลง เพื่อดูว่ามี defect ตรงไหนบ้าง ? เพื่อตรวจสอบว่าการออกแบบถูกต้องหรือไม่ ? รวมไปถึงหน้าจอ และ element ต่าง ๆ ซึ่งเยอะแยะมากมาย อีกทั้งการรับ event และ แสดงผลตรงตามที่ตกลงไว้หรือไม่ ? ปล. มีบางคนอาจจะถามว่า เราต้องไปตรวจสอบถึง database เลยไหมว่ามีข้อมูลเข้าหรือเปลี่ยนแปลง ก็ตอบง่าย ๆ เลยว่า เรากำลังทำการทดสอบ GUI นะ ดังนั้นไม่ต้องไปสนใจ

รูปแบบของ UI Testing ประกอบไปด้วย

Manual testing หรือการทดสอบด้วยคน
Automation testing หรือการทดสอบแบบอัตโนมัติด้วยโปรแกรม

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

Record and Play back หรือ Capture and Replay testing
Model based testing

โดยที่ Record and Play back นั้นง่าย สะดวก เหมาะกับคนที่ไม่ชอบ coding !! แต่ข้อเสียคือ

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

ดังนั้นสิ่งแนะนำคือ Model based testing

หลัก ๆ เป็นการสร้าง model หรือส่วนอธิบายพฤติกรรมการทำงานของระบบผ่าน GUI ต่าง ๆ ทำให้เราเข้าใจในรายละเอียดของระบบมากขึ้น ทำให้เราเข้าใจ state การทำงานมากขึ้น ในบางครั้งอาจจะลดความสนใจจาก GUI ลงไปได้เยอะ นั่นหมายความว่า ถ้า GUI เปลี่ยนแปลงแต่ state ไม่เปลี่ยน ก็จะไม่ส่งผลต่อ test case มากนัก

สิ่งที่ควรพิจารณาสำหรับ UI Testing

เนื่องด้วยเป็นการทดสอบส่วน GUI จึงหลายสิ่งอย่างให้คิด มีหลาย test case ที่ควรและไม่ควรทดสอบ บางอย่างอาจจะไม่ใช่ test case แต่น่าจะเป็น checklist ที่ดีได้ ยกตัวอย่างเช่น การตรวจสอบ Font หรือตัวอักษร ว่ามีชนิดตรงตามข้อตกลงหรือไม่ ว่ามีขนาดตรงตามข้อตกลงหรือไม่ รูปแบบของ icon ต่าง ๆ ของระบบว่าตรงตามที่ตกลงหรือไม่ การตรวจสอบสีตรงตาม style guide หรือไม่ ทั้ง background, hyperlink, ปุ่ม การตรวจสอบ look & feel ของระบบ รวมทั้งความเข้ากันได้ของระบบ การตรวจสอบข้อมูลเข้าหรือ input ว่าเป็นอย่างไร ว่าแสดงในรูปแบบเดียวกันทั้งหมดหรือไม่ ทั้ง required field และ optional field อีกทั้งการจัดการ error ต่าง ๆ จะแสดงอย่างไรบ้าง รวมไปถึงความยาวของข้อมูลเข้าในแต่ละ field การยืนยันเมื่อต้องลบหรือแก้ไขข้อมูล เป็นอย่างไร และอื่น ๆ อีกมากมาย

คำถามที่น่าสนใจคือ สิ่งต่าง ๆ เหล่านี้คือ test case หรือไม่ ? หรือมันเป็นเพียง checklist ที่ควรมี ระหว่างตรวจสอบแบบ manual กับ automation อะไรน่าจะเหมาะสมกว่ากัน ?

ทำไมเราควรทำ UI Testing ?

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

ปล. ทำเยอะไปก็ไม่ดีนะครับ เปลืองน่าดู แต่ถ้าไม่ทำเลยก็ไม่ได้ เหมือนหน้าตาดูดี แต่ใช้งานอะไรไม่ได้เลย !! แนวทางที่ดีลองดู Pyramid Testing เพิ่มเติมนะ

ปิดท้ายด้วยเครื่องมือสำหรับ UI Testing กันบ้าง มีอะไรบ้าง ?

ในภาษาโปรแกรมต่าง ๆ ไม่ว่าจะเป็น Python, Swift, Scala, Clojure ล้วนมีสิ่งที่เรียกว่า REPL (Read Eval Print Loop) สำหรับการ run statement ต่าง ๆ ของ code โดยไม่ต้องทำการสร้างไฟล์ใด ๆ ขึ้นมาเลย เพื่อทดสอบ เพื่อทดลอง เพื่อตรวจสอบ ชุดของ code ที่สำคัญใน Java 9 ก็มีความสามารถนี้เช่นกัน นั่นคือสิ่งเล็ก ๆ ที่เรีกยว่า JShell ดังนั้นมาลองใช้งานกันนิดหน่อย เริ่มด้วยการเข้าใช้งาน jshell [gist id="74c99e82585f34d98d767ec2f657bedb" file="1.txt"] มาดูว่าใน jshell ทำการ import อะไรให้บ้าง [gist id="74c99e82585f34d98d767ec2f657bedb" file="2.txt"] ดังนั้นชาว Java มีเครื่องคิดเลขแล้วนะ นั่นคือเราสามารถพิมพ์ expression ต่าง ๆ ได้เลย ที่สำคัญสามารถกำหนด mode ของการแสดงได้ด้วย ซึ่งผมทำการเปลี่ยนเป็น verbose mode เพื่อให้แสดงชนิดของตัวแปรด้วย ยกตัวอย่างเช่น [gist id="74c99e82585f34d98d767ec2f657bedb" file="3.txt"] ยังไม่พอนะ สามารถประกาศตัวแปร และ method ต่าง ๆ ได้เลย ซึ่งมันอำนวยความสะดวกอย่างมาก [gist id="74c99e82585f34d98d767ec2f657bedb" file="4.txt"] ที่สำคัญ jshell ยังมีคำสั่งหรือ command อื่น ๆ ให้ใช้อีก เช่น

/vars สำหรับดูตัวแปรทั้งหมด
/methods สำหรับดู method ทั้งหมด
/list ดู code ทั้งหมดที่พิมพ์มา

สุดท้ายก็ออกจาก jshell ด้วย /exit สวัสดี น่าจะมีประโยชน์บ้างนะครับ

คำถามที่น่าสนใจสำหรับนักพัฒนา code ของระบบงานมี dead code หรือไม่ ? คำตอบอาจจะมีหลากหลายเช่น ไม่มีแน่นอน น่าจะมี ไม่มี หรือ dead code มันคืออะไร ?

ก่อนอื่นมาทำความเข้าใจกับ dead code กันหน่อย

Code ที่ถูก execute หรือเรียกใช้งาน แต่ไม่ได้ส่งผลอะไรเลย หรือผลลัพธ์ที่ได้ ไม่ถูกนำไปใช้งาน

ปล. Code ที่ไม่ถูก execute หรือไม่เรียกใช้งานเราเรียกว่า unreachable code

ดังนั้น code เหล่านี้จึงเป็น overhead ของการทำงาน รวมทั้งการใช้งาน resource เช่น CPU และ Memory อีกด้วย แน่นอนว่า เวลา มันคือค่าใช้จ่ายที่ต้องเสียไป ดังนั้นลดมันลงซะ ลองคิดดูสิว่า ถ้าเราต้องดูแลรักษา code ที่ไม่มีประโยชน์ หรือ ไม่ใช้งาน ต้องใช้เวลามากเพียงใด

ดังนั้นนักพัฒนามาหัดลบ code กันนะ มาเริ่มกันเลย

ลบ code ที่ถูก comment ออกไปซะ

ใช้ version control แล้ว จะเก็บ code เหล่านี้ไว้ทำไม ทำไว้เพื่อดูว่า เคยทำอะไรมาบ้าง ทำไว้เพื่อเผื่อจะเอากลับมาใช้ ทำไว้เพื่อทดสอบบางสิ่งบางอย่าง แล้วลืมเอาออก [gist id="2d489695d7b21a57d1e82624920406a4" file="1.txt"]

ปล. นักพัฒนาบางคนอาจจะบอกว่า เก็บไว้ก่อนนะ !! บอกเลยว่า ลบเถอะ ไม่งั้นผมจะลบให้นะ

ลบพวก Unreachable code ทิ้งซะ

[gist id="2d489695d7b21a57d1e82624920406a4" file="2.txt"] ลบเถอะนะ ที่สำคัญบางภาษามีการเตือน บางภาษาถึงกับ compile ไม่ผ่าน หรือนำเครื่องมือพวก lint หรือ Static code analysis มาใช้นะ

พวก Variable, Field และ Parameter ที่ไม่ใช้งานก็ลบเถอะนะ

ประกาศเท่าที่ใช้ก็พอ อย่าเผื่อ แน่นอนว่า IDE ต่าง ๆ มีการเตือนเสมอนะ แก้ซะ นั่นคือ ลบซะ เนื่องจากการแก้ไขผ่าน IDE จะปลอดภัยมาก ๆ

พวก method ต่าง ๆ ก็เช่นกัน ถ้าไม่ใช้ก็ลบไป

บ่อยครั้งเจอกับ method ที่ไม่ใช public method เช่น private method รวมไปถึง scope ของ class, method, variable ด้วย กำหนดให้ตรงกับที่ใช้ ไม่ใช่ว่า กำหนดให้เป็น public ทั้งหมด ดังนั้นให้ดูขอบเขตหรือscope ของการใช้งานด้วย เช่น private, protected และ public

สุดท้ายแล้ว

นักพัฒนาต้องให้ความสำคัญต่อการเขียน code ด้วย ทั้งลดความซับซ้อน ทั้งการจัดโครงสร้างที่ดี ทั้งการตรวจสอบ code ว่ามี dead code หรือไม่ เพื่อทำการแก้ไขทันที อย่าบอกว่า เดี๋ยวก่อน ( Later === Never )

เขียน code ก็ยากแล้ว ดูแลรักษา code ยิ่งยากกว่า ดังนั้นลด code ที่ไม่จำเป็นออกไปเถอะนะ

ขอให้สนุกกับการ coding ครับ Reference Websites https://dzone.com/articles/you-have-no-excuse-for-your-dead-code https://blog.ndepend.com/paying-for-dead-code/ https://blog.ndepend.com/alternatives-lines-of-code-loc/

อ่านเจอเอกสารเกี่ยวกับ Agile Security Manifesto เห็นว่าน่าสนใจดี จึงนำมาแปลและสรุปไว้นิดหน่อย มีอยู่ 4 ข้อเท่ากับ Agile เลย เป็นแนวทางสำหรับการสร้าง software ที่มีความปลอดภัย ตามแนวทางของ Agile ดังนี้

Rely on developers and testers more than security specialists.
Secure while we work more than after we’re done.
Implement features securely more than adding on security features.
Mitigate risks more than fix bugs.

ดูในรายละเอียดกันบ้าง

1. Rely on developers and testers more than security specialists

ให้ความรู้เรื่องความปลอดภัยสำหรับการพัฒนาระบบงานให้กับทางนักพัฒนาและทดสอบ มากกว่าจะพึ่งทาง Security specialist หรือผู้เชี่ยวชาญเพียงอย่างเดียวเท่านั้น แน่นอนว่า Security specialist นั้นมีความสำคัญอย่างมาก แต่มีน้อยทีมมากที่จะมี Security specialist ประจำอยู่ในทีมพัฒนา และส่วนใหญ่จะทำการตรวจสอบหลังจากที่พัฒนาระบบงานเสร็จสิ้นแล้วเท่านั้น ซึ่งมักก่อให้เกิดปัญหาต่าง ๆ ตามมามากมาย สิ่งที่ควรจะเป็นไปก็คือ เรื่องของ security ต้องให้เสร็จภายในทีมพัฒนาหรือรอบการพัฒนาไม่ต้องรอ เรื่องของ security ต้องถูกรวมเข้ากับการพัฒนาและทดสอบไปเลย การที่จะมารอให้ security มาทำการ review แบบ manual คงไม่ทันการ แน่นอนว่า Security specialist ต้องเข้ามาร่วมในทีมด้วยเสมอ ดังนั้นทีมพัฒนาทั้ง developer และ tester รวมไปถึงคนที่เกี่ยวข้อง ต้องมีความรู้ความเข้าใจเรื่องของ security ด้วย แต่ถ้าไม่มีก็ต้องทำการสอนให้เข้าใจจากผู้เชี่ยวชาญนั่นเอง (Security specialist)

Security is First and Foremost

ส่วนเครื่องมือต่าง ๆ เกี่ยวกับ security ก็ให้ไป integrate เข้ากับระบบ CI/CD กันไปเลย

2. Secure while we work more than after we’re done

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

3. Implement features securely more than adding on security features

เรื่องของ security นั้นต้องถูกใส่เข้าไปในทุก ๆ feature ไม่ใช่ทำการเพิ่ม feature ที่เกี่ยวกับ security เข้ามา เช่น feature authentication/authorization และการเข้ารหัสข้อมูล เป็นต้น ดังนั้นในแต่ละ feature ควรมีการพูดคุยและตกลงเรื่อง security ด้วยเสมอ สิ่งที่ควรเน้นคือ การส่งมอบ feature ที่มีคุณค่าทาง business ส่วนสิ่งที่นำมาใช้พัฒนาควรเลือกสิ่งที่ปลอดภัย เช่น framework ที่มีระบบ security ที่ดี build-in ให้อยู่แล้ว หลีกเลี่ยงการ custom library ต่าง ๆ

4. Mitigate risks more than fix bugs

ควรทำการลดความเสี่ยงมากกว่าการแก้ไขข้อผิดพลาด นั่นหมายความว่า เราควรทำการป้องกันไม่ให้เกิดข้อผิดพลาดมากกว่าค้นหาข้อผิดพลาด (Prevent > Detect) ในการสร้าง secure software หรือระบบงานที่มีความปลอดภัย ต้องคำนึงถึงความเสี่ยงทางด้วยธุรกิจ ผู้ใช้งาน และ ข้อมูลต่าง ๆ เพื่อลดความเสี่ยงต่าง ๆ ทั้งหมดให้เหลือน้อยที่สุดเท่าที่จะทำได้ ประเด็นหลัก ๆ คือ เราคุยเรื่องความเสี่ยงเหล่านี้กันเมื่อใด ควรระบุและสรุปรูปแบบการโจมตีต่าง ๆ ไว้ เพื่อทำให้เราเห็นว่า มีสิ่งใดบ้างที่ควรระวัง หรือ ควรหรือไม่ควรทำ ถ้ายังมานั่งแก้ไขข้อผิดพลาดที่ละข้อ ทีละ feature เหมือนที่เคยทำกัน เผลอ ๆ อาจจะต้องรื้อทำใหม่กันเลย

Building secure software in an agile way is fundamentally just building software in an agile way.

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

สำหรับการทดสอบก็เช่นกัน มาเริ่มกันเลยกับ Test/Unit Test Smell ว่ามีปัญหาอะไร อย่างไรกันบ้าง ที่บ่งบอกว่าจะทำให้เกิดปัญหาขึ้นมาได้

ชุดการทดสอบมันเขียนยากนะ ต้องใช้เวลาเพิ่ม

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

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

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

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

ชุดการทดสอบมาก หรือ ละเอียดจนเกินไป

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

คำถามคือ เราควรทดสอบทั้งสอง method เลยหรือไม่ ? ลองถามใจดูนะ

การทดสอบควรเน้นพฤติกรรมให้มากกว่าลงรายละเอียด เพื่อช่วยลดผลกระทบของชุดการทดสอบจากการเปลี่ยนแปลง เช่นทำการเปลี่ยนแปลง code หรือ production code เป็นต้น

ทำการ Mock มากจนเกินไป (Mock Bubble)

สิ่งสำคัญมาก ๆ สำหรับการเขียนชุดการทดสอบคือ การแยก dependency หรือส่วนการทำงานต่าง ๆ ออกจากกัน เช่น แยกส่วนของ Database, API, Legacy ออกจากส่วนการทำงานหลัก หรือแยกออกไปจากส่วนที่เราสนใจ ทำให้สามารถจำลองและส่งสิ่งที่เราต้องการใช้เข้ามา (Mock, Stub) วิธีการนี้เรามักจะเรียกว่า Dependency Injection แต่ถ้าส่วนที่เราสนใจมี dependency จำนวนมาก ๆ !! ทำให้เราต้องสร้าง mock และ stub จำนวนมาก แน่นอนว่า สามารถทดสอบได้ แต่มันคือปัญหาเรื่องการออกแบบหรือไม่ ? ส่งผลให้ชุดการทดสอบพังได้ง่าย ? ส่งผลให้ยากต่อการเปลี่ยนแปลงหรือไม่ ? จำนวนของการทดสอบจะเยอะมาก ๆ ?

การทดสอบช้ามาก ๆ

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

คำถามคือ เร็วเท่าไรดี ? ตอบง่าย ๆ คือ เร็วกว่าเดิมและเร็วกว่าเดิม (Continuous Improvement)

ปัญหาหลัก ๆ ของการทดสอบที่ใช้เวลานาน มักประกอบไปด้วย

เป็น Integration test หรือไม่ ? เช่นต้องต่อกับ Database, API จริง ๆ หรือไม่ ?
มีการ setup ต่าง ๆ ก่อนการทดสอบเยอะและซับซ้อนมากเกินไปหรือไม่ ?
การทดสอบเป็นแบบ sequencial หรือไม่ ? ถ้าใช่ก็ลองเปลี่ยนไปเป็นแบบ parallel สิ
ระบบงานแยกเป็น module หรือ ออกแบบผิดหรือไม่ ?

ชุดการทดสอบมัน fail แบบ Random Fail

เป็นปัญหาที่น่ากลัวมาก ๆ นั่นคือ ชุดการทดสอบมัน fail แบบสุ่ม ทั้ง ๆ ที่ไม่ได้เปลี่ยนแปลงอะไรเลย !! input ก็หมือนเดิม แต่ทำไมผลการทำงานไม่เหมือนกัน ทำให้ยากต่อการแก้ไขมาก ๆ บอกได้เลยว่าโครตน่ากลัว ปัญหานี้มักจะมาจาก ไม่เข้าใจพฤติกรรมการทำงานของระบบเช่น มีการทำงานแบบ asynchronous มีการทำงานกับเวลา หรือ dependency ที่ควบคุมไม่ได้ มีการทำงานที่ใช้งาน CPU/Memory มากจนเกินไป มีการใช้ resource pool ออกแบบระบบผิดหรือไม่

จากนั้นก็ลงมือแก้ไขซะ

สุดท้ายสิ่งที่นักพัฒนาควรทำคือ

หัดฟังเสียงหรือผลการทำงานจากชุดการทดสอบด้วยเสมอ จากนั้นทำการปรับปรุงให้ดีขึ้นอย่างต่อเนื่อง ให้จำไว้เสมอว่า ชุดการทดสอบควรมีความสำคัญเทียบเท่ากับ production code เสมอ

คำถาม นักพัฒนาคิดว่า การทดสอบยังมีปัญหาอื่น ๆ อีกหรือไม่ ?

ขอให้สนุกกับการ coding นะครับ

การสร้างชุดการทดสอบแบบอัตโนมัติระดับ User Interface ของ Android app นั้น เป็นเรื่องที่สำคัญมาก ๆ โดยที่ทาง Android ก็ได้เตรียมเครื่องมือและ library ต่าง ๆ ไว้ให้ครบ ยกตัวอย่างเช่น Espresso และ UIAutomator เป็น ที่สำคัญยังมี opensource library อื่น ๆ อีก ไม่ว่าจะเป็น Appium และ Calabash ดังนั้นการสร้างชุดการทดสอบแบบอัตโนมัติจึงไม่ใช่เรื่องยากหรือเป็นไปไม่ได้เลย

แต่เหล่าทีมพัฒนามักไม่ชอบทำ !! ทำไมนะ ?

ปกติการเขียน UI Test ของ Android app นั้น

มักจะเขียนด้วย library ที่ชื่อว่า Espresso ซึ่งสามารถทดสอบ Android app ได้เกือบครบทั้งหมด การใช้งานก็ไม่ยาก ยกตัวอย่างด้วยภาษา Kotlin ดังนี้ [gist id="d12656c1a3236e9d90609aa15e83e066" file="1.kt"] คำอธิบาย ทำการตรวจสอบ element id=username ว่าแสดงผลหรือไม่ ทำการกดปุ่ม id=login_button ทำการกรอข้อมูล Hello ใน element id=name_field ทุกอย่างดูเป็นปกติ และทำงานได้ตามที่ต้องการ

แต่เมื่อการทดสอบเริ่มซับซ้อนขึ้น ขั้นตอนการทำงานมากขึ้น

ส่งผลทำให้ code ของ UI Test ที่เขียนขึ้นมานั้น อ่านลำบาก แก้ไขยาก ยิ่งจำนวน test case เยอะขึ้น ปัญหาก็ตามมาเพียบ ทำให้คนเขียนมักจะเป็น developer/programmer ทำให้งานเพิ่มอีกแล้ว แน่นอนว่า มันคือปัญหา classic สุด ๆ ยกตัวอย่างเช่น [gist id="d12656c1a3236e9d90609aa15e83e066" file="2.java"]

ดังนั้นเราน่าจะต้องการวิธีการใหม่ ๆ เข้ามาช่วยนะ

ยิ่งการพัฒนา Android นั้นมีทางเลือกทั้งภาษา Java และ Kotlin น่าจะทำให้เรามีทางเลือกมากขึ้น ซึ่งตอนนี้มีคนสร้าง library ด้วยภาษา Kotlin เพื่อทำให้การเขียน UI Test ด้วย Espresso ง่ายขึ้น ด้วยการเขียนในรูปภาษาที่ง่าย ๆ เป็น DSL หรือภาษาเฉพาะขึ้นมา จาก code ด้านบน ถ้าเราสามารถเขียนง่าย ๆ ด้วย DSL ง่าย ๆ แบบนี้ น่าจะทำให้การเขียน UI Test ง่ายและสนุกขึ้นหรือไม่ แน่นอนว่า ทำให้ง่ายได้อ่านขึ้นเยอะ รวมทั้งใคร ๆ ก็สามารถเขียนได้ ยกตัวอย่างเช่น [gist id="d12656c1a3236e9d90609aa15e83e066" file="3.kt"]

โดยมีคนทำ library ในรูปแบบนี้ให้ด้วยนะ

จึงนำมาแนะนำไว้ เผื่อว่าจะนำไปใช้กัน ประกอบไปด้วย

จากทั้ง 3 ตัวนั้น Kakao น่าใช้งานสุด ซึ่งลองใช้งานก็ไม่ได้ยากอะไร แต่อาจจะติดตั้งยากขึ้นมาหน่อย ยิ่งถ้าต้องทดสอบระบบที่พัฒนาด้วยภาษา Java แล้ว ต้องทำให้ Android project สนับสนุนภาษา Kotlin ก่อนด้วยนะ ตัวอย่างของการเขียนด้วย Kakao [gist id="d12656c1a3236e9d90609aa15e83e066" file="4.kt"] ขอให้สนุกกับการ coding ครับ

อ่านบทความสรุปสำหรับ Keynote ในงาน KotlinConf แล้วน่าสนใจมาก แต่ที่น่าสนใจสุด ๆ คือ นักพัฒนาสามารถพัฒนาระบบทั้งหมดเหล่านี้ด้วย Kotlin ได้

Android app
Server side
Web frontend
iOS app ออกมาล่าสุดเลยจาก Kotlin Native

ทำให้นักพัฒนาสามารถใช้ Kotlin พัฒนาระบบงานได้ทุก platform แน่นอนว่าต้องมี App ตัวอย่างให้สิ ซึ่งเป็น iOS app

ยังไม่พอ code ตัวอย่างอยู่ใน Github ที่สำคัญมีครบทุก platform ดังนี้

โดยที่ Demo app ในแต่ละ platform พัฒนาด้วย library/framework ดังนี้

Serverside/Backend ใช้ Ktor
Web application ใช้ Kotlin React Wrapper
Android app ใช้ Anko และ Android Architecture Component
iOS ใช้ Kotlin Native และ UIKit

ยังไม่พอนะ Kotlin 1.2 RC (Release Candidate)

ได้ปล่อยความสามารถใหม่ออกมาคือ Multiplatform project นั่นคือ เราสามารถเขียน code เพียงชุดเดียว แล้ว compile ไปทำงานได้ในทุก ๆ platform (มันคุ้น ๆ นะ !!) ซึ่งตอนนี้จะมีเพียง JVM และ JavaScript เท่านั้น ส่วน Native ต้องรอไปก่อน ที่สำคัญยังอยู่ในช่วงทดสอบนะ ดังนั้นมีการเปลี่ยนแปลงอีกเยอะแน่นอน

สำหรับใครที่เป็นแฟนของ Kotlin Native แล้ว ตอนนี้ IntelliJ IDE สนับสนุนแล้วนะ

สำหรับนักพัฒนา React ต้องหันมามอง Create React Kotlin App แน่นอน

ช่วยทำให้ง่ายต่อการพัฒนา React ด้วย Kotlin !!! เครื่องมือดีมีชัยไปกว่าครึ่ง อาจจะเยอะแยะไปหน่อยนะ แต่ก็ลองดูกัน

ปิดท้ายด้วยการศึกษา Kotlin

ตอนนี้เราสามารถลอง plugin ชื่อว่า Kotlin Education Tool ใน IDE ทั้ง IntelliJ IDE และ Android Studio ได้ด้วย ลองใช้งานกันดู

ขอให้สนุกกับการ coding นะครับ

ช่วงนี้นั่งไล่อ่านหนังสือเก่า ๆ ที่ดองไว้เพียบ หนึ่งในนั้นคือ หนังสือ The Art of Thinking Clearly: Better Thinking, Better Decisions เหมือนว่าจะมีหนังสือแปลเป็นภาษาไทยด้วยนะครับ มีหลาย ๆ เรื่องที่น่าสนใจ แต่ข้อที่ชอบและนำมาบันทึกไว้คือ Social Loafing - Why teams are so lazy (SocialLazy) ? ว่าด้วยเรื่อง ความขี้เกียจของคนเมื่อมารวมกันเป็นสังคม

เริ่มต้นด้วยการยกตัวอย่างเรื่องของม้า

ทำไมม้าสองตัวที่วิ่งเร็วมาก ๆ เมื่อมาวิ่งพร้อมกัน กลับวิ่งไม่ได้เร็วไปกว่าม้าตัวเดียวเลย ยังไม่พอนะ ความเร็วกลับตกลงไปอย่างมาก

แถมยกตัวอย่างเมื่อคนมากกว่า 1 คนมาทำงานร่วมกัน

พบว่า ยิ่งจำนวนคนมากขึ้น ความพยายามของแต่ละคนก็ยิ่งลดลงดังนี้

2 คนพบว่าแต่ละคนจะทำงานประมาณ 93% จากที่ทำงานคนเดียว
3 คนพบว่าแต่ละคนจะทำงานประมาณ 85% จากที่ทำงานคนเดียว
8 คนพบว่าแต่ละคนจะทำงานประมาณ 49% จากที่ทำงานคนเดียว

ถ้าผลเป็นแบบนี้เราทำงานเป็นทีมกันไปทำไม ? ถ้างานที่ไม่ซับซ้อนก็ทำงานคนเดียวได้ แต่โชคไม่ดีที่งานส่วนใหญ่มันจะซับซ้อน

จากหนังสืออธิบายว่า

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

ในหนังสือยกตัวอย่างของการแข่งชักเย่อ

จะพบว่ามีทั้งคนที่ออกแรงสุดชีวิต ออกแรงกลาง ๆ และไม่ออกแรงเลย ทำไมนะ ?

แต่มันจะได้ผลดีกับทีมขนาดเล็ก

แต่ละคนในทีมมีหน้าที่หรือความสามารถเฉพาะไปเลย ยกตัวอย่างเช่น

มีคนเชี่ยวชาญเรื่องการออกแบบ
มีคนเชี่ยวชาญเรื่องการพัฒนา
มีคนเชี่ยวชาญเรื่องการทดสอบ
มีคนเชี่ยวชาญเรื่องการ deploy

ผลที่ออกมาคือ แต่ละคนต่างมีหน้าที่ต่างกันอย่างชัดเจน ทำให้ได้ผลลัพธ์ที่ดี แต่ละคนไม่สามารถขี้เกียจได้เลย เพราะว่าผลที่ออกมาจะชัดเจนอย่างมาก

ในหนังสือยกตังอย่างการวิ่ง 4 x 100 เมตร

แน่นอนว่า ถ้าใครอู้หรือขี้เกียจมันเห็นผลชัดเจนอย่างมาก

ดังนั้นจึงพอสรุปได้ว่า

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

แต่ถ้าต้องการให้คนในทีมขี้เกียจน้อยลง

ก็จำเป็นต้องมีการวัดผลของแต่ละคนที่ชัดเจนและตรงไปตรงมา พร้อมเปิดเผยกันอยู่อย่างเสมอ รวมทั้งการ motivate คนในทีม เช่นการนำ 3C มาประยุกต์ใช้คือ Collaboration, Content และ Choice การงานหรือเป้าหมายที่ท้าทาย หรือส่งผลกระทบต่อผู้คนจำนวนมาก หรือมีรางวัลต่าง ๆ ตบท้ายอีกด้วย ปล. ลองดูสิว่า ทีมที่เราทำงานเป็นรูปแบบนี้หรือเปล่านะ

ถ้าเป็นอยู่ น่าจะถึงเวลาที่ต้องปรับเปลี่ยนสิ่งต่าง ๆ แล้วนะ

ยังมีเรื่องอื่น ๆ ที่น่าสนใจอีกนะ ลองไปอ่านกันดูครับ ได้เห็นในมุมแปลก ๆ เยอะเลย Reference Websites http://www.ontheagilepath.net/2016/01/lazy-team-members-about-social-loafing-and-ways-to-prevent-it-in-your-teams.html http://meaningring.com/2016/04/04/social-loafing-by-rolf-dobelli/

6 เดือนแล้วสำหรับการประกาศให้ภาษา Kotlin เป็น first-class language สำหรับการพัฒนา Android app ที่สำคัญแนวโน้มการใช้สูงขึ้นอย่างมาก โดยเฉพาะการพัฒนา Android app ยิ่งในตอนนี้ Android Studio 3.0 ก็สนับสนุนเต็มที่ Android Support Library 27 ก็ได้เพิ่ม Nullability annotation เพื่อช่วยลดปัญหา NullPointerException แน่นอนมันทำให้ app มีคุณภาพมากขึ้น ไม่ crash ง่าย ๆ ยังไม่พอนะ ทาง Google ทำการสร้างเอกสาร Android Kotlin Style Guide ไว้ให้ด้วย ซึ่งทำการสรุปกฏและ coding stadard ต่าง ๆ สำหรับการพัฒนา Android app ด้วยภาษา Kotlin เช่น

Naming
Structure
Formatting
Indentation
Whitespace
Documentation

น่าจะเป็นแหล่งความรู้ที่นักพัฒนาพลาดไม่ได้ Reference Websites https://android-developers.googleblog.com/2017/11/update-on-kotlin-for-android.html

จาก Post ใน Facebook ของพี่อู

จงเขียนโปรแกรมบวกเลขเฉพาะเลขคี่ที่อยู่ระหว่าง 1 ถึง n ใด ๆ แล้วเอา code มาอวดกัน

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

ดังนั้นจึงลองคิดใหม่หน่อยสิ

เริ่มด้วยการเขียนลงกระดาษนี่แหละ ง่ายสุด พอเขียนไปเขียนมา ทดเลขไป ๆ มา ๆ เลยพอเห็นว่ามันมีรูปแบบนี่หว่า 1=1 1+3=4 1+3+5=9 1+3+5+7=16 1+3+5+7+9=25 มันคือ 1 ยกกำลัง 2 2 ยกกำลัง 2 3 ยกกำลัง 2 4 ยกกำลัง 2 5 ยกกำลัง 2 เลขข้างหน้ามันคือจำนวนของเลขคี่นี่หว่า !! หาจำนวนอย่างไรดีละ ? ง่าย ๆ ก็ (first + last) / 2 ไงละ หรือใช้การหารปัดเศษขึ้น มาถึงตรงนี้ ก็เลยเห็นทางสว่างมาทันที ทำให้แปลกใจว่า ทำไมเราไม่เคยรู้เรื่องนี้มาเลยนะ ? แสดงว่า ไม่ตั้งใจเรียนคณิตศาสตร์แน่นอน

เพื่อความสบายใจเลยลองไปค้นหาดู

พบว่า มันคือเรื่องพื้นฐานทางคณิตศาสตร์เลย ทั้งการหาผลรวมของตัวเลข ทั้งการหาผลรวมเลขคี่ ... โลกของคณิตศาสตร์มันสวยงามมากครับ สามารถพิสูจน์มาจนเป็นสูตรตามนี้เลย

นี่แหละคนไม่ตั้งใจเรียน ช้ำใจมาก ๆ

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

ทำให้นึกถึงชื่อเรียกอื่น ๆ ที่น่าสนใจ ดังนั้นลองไปค้นหาดูพบว่า มีการพูดคุยใน StackOverflow ตั้งแต่ปี 2010 แต่ปัจจุบันได้ถูกลบไปแล้ว แต่มีการสรุปไว้ที่ New Programming Jargon เลยนำชื่อที่น่าสนใจมาสรุปไว้นิดหน่อย เริ่มด้วย Yoda Condition

Refuctoring คือกระบวนการเพื่อให้ได้ code ไม่สามารถดูแลต่อไปได้หรือยากมาก ๆ โดยคนอื่น ยกเว้นตัวเราเอง บ่อยครั้งนักพัฒนาจะพูดว่า code ชุดนี้ผมเข้าใจนะ แต่ถ้าคนอื่นอันนี้ก็ไม่รู้สินะ ปล. มันคล้าย ๆ กับ Refactoring นะ แต่ว่าผลที่ได้ต่างกันแบบสุดขั้ว Hydra Code code แบบนี้น่ากลัวมาก ๆ แก้ไข 1 เรื่อง อาจจะสร้างปัญหาใหม่มาอีกมากมาย !! Smurf Naming Convention เป็นการตั้งชื่อ class/file ต่าง ๆ ด้วยคำนำหน้าเหมือน ๆ กัน เช่น SmurfView -> SmurfController -> SmurfService -> SmurfDao -> SmurfLog Smug Report คือการแจ้ง bug report จากคนที่คิดว่ารู้ดีและรู้เยอะมาก ๆ จะเขียนรายละเอียดมามากมาย ทั้งทางด้าน technical และ ไม่ technical พร้อมกับการบอกถึงปัญหาต่าง ๆ รวมทั้งแนวทางในการแก้ไข และส่วนมากมักจะผิด !! Protoduction มันคือสิ่งที่เราทำ prototype ขึ้นมาเพื่อทดสอบอะไรบางอย่าง แต่กลับพบว่า มันดันขึ้น production server ซะงั้น Jenga code เมื่อเราลบหรือแก้ไข code บางส่วน กลับทำให้ทั้งระบบพังหรือทำงานผิดพลาด

หลัง ๆ มาจะมีเยอะเลย เช่น

Deadline/Fear Driven Development
Timesheet Architecture

ใครมีชื่อแปลก ๆ ฮา ๆ น่าสนใจก็เอามาแบ่งปันกันได้นะ ชื่อเรียกต่าง ๆ มันสะท้อนโลกของ programming ได้อย่างชัดเจนและน่าดูชม

ขอให้สนุกกับการ coding ครับ

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

ต้องเข้าใจเกี่ยวกับการทดสอบขั้นพื้นฐานก่อน

ความรู้พื้นฐานมันสำคัญมาก ๆ เช่น การทดสอบคืออะไร ลองให้คนในทีมเขียนลงกระดาษสิ แล้วจะเข้าใจได้ทันทีว่าเป็นอย่างไร จากนั้นก็ว่าด้วยเรื่องของ Test Matuarity Model (TMM) ซึ่งเป็น framework ว่าด้วยเรื่องของ test management process ที่สำคัญต้องเข้าใจด้วยว่า ทำไมถึงต้องทดสอบ ถ้ายังไม่เข้าใจ นั่นคือปัญหา ที่ทุกคนในทีมต้องเข้าใจร่วมกัน ที่สำคัญ ความหมายของการทดสอบแต่ละอย่าง ก็สรุปกันให้ชัดเจน เช่น Unit test Regression test Integration test UAT Non-functional test ว่าเมื่อใดควรใช้ ใช้อะไร ทำอย่างไร เพื่อให้สามารถนำไปใช้ใน testing priocess ได้อย่างถูกต้องเหมาะสม เพื่อให้ได้ผลลัพธ์ที่ดีขึ้น

ทำไมต้องทดสอบแบบอัตโนมัติด้วย ?

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

หัวใจคือ ต้องเริ่มที่คน (People) คนจะเป็นคนคิดและวางขั้นตอนการทำงาน (Process) จากนั้นจึงเลือกเครื่องมือที่เหมาะสมกับคนและขั้นตอนมาใช้งาน (Tool)

เมื่อพร้อมแล้ว ทำการศึกษาที่ทำความเข้าใจกับเครื่องมือซะ

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

บอกไว้เลยว่า เริ่มต้นที่ว่ายากแล้ว ที่เหลือนั้นยากกว่ามาก

อย่าลืม Refactor หรือทำการปรับปรุงโครงสร้างของ test case ด้วยละ

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

ที่สำคัญอย่างลืมปรับปรุงขั้นตอนทำงานให้ดีขึ้นด้วยนะ

อย่าลืมนำชุดการทดสอบแบบอัตโนมัติไปใส่ในขั้นตอนการทำงานด้วย

ชุดการทดสอบควรทำงานแบบอัตโนมัติ เมื่อระบบงานมีการเปลี่ยนแปลงเสมอ ยกตัวอย่างเช่น เมื่อ source code มีการเปลี่ยนแปลง เมื่อมีการ deploy ระบบใหม่ เมื่อมีการแก้ไข bug เมื่อมีการเพิ่มหรือแก้ไขชุดการทดสอบ

อย่าลืมเก็บชุดการทดสอบต่าง ๆ ไว้ใน version control system ด้วย

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

สุดท้ายแล้ว ต้องเรียนรู้อยู่อย่างสม่ำเสมอ (Keep learning)

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

จาก VDO เรื่อง Modernizing Java Apps with Docker จากงาน DockerCon EU 2017 ซึ่งเป็นอีก session หนึ่งที่ตรงกับแนวคิดหลักของงานคือ Modernizing Traditional Application (MTA) โดยที่ Traditional Application คือระบบงานที่พัฒนามาหลายปีแล้ว แต่ยังเป็นหัวใจหลักหรือตัวขับเคลื่อนหลักขององค์กร แน่นอนว่า ทั้ง developer และ operation ต้องทำงานอย่างหนักเพื่อพัฒนาและดูแลรักษาระบบเหล่านี้ เนื่องจาก code มันยุ่งเหยิงมาก ๆ มีหลาย ๆ ส่วนเรียกกันไปมา แก้ไขครั้งแต่ละครั้งใช้เวลานานและผลกระทบสูงมาก ๆ จะแก้ไขต้นเหตุของปัญหาก็ไม่ได้ เวลาไม่พอ หรือไม่อยากรับผิดชอบ ดังนั้นจึงทำการ patch/hack code เพื่อให้สามารถทำงานได้ หรือทำการ wrapper สิ่งต่าง ๆ เหล่านี้ไว้อีกชั้น ยิ่งทำให้เกิดความซับซ้อนมากขึ้นไปอีก การทดสอบและ deploy/release ระบบงาน ต้องใช้เวลานานมาก ๆ ปัญหาเยอะจริง ๆ นะ Traditional Application !!

โดยใน session นี้เน้นไปที่

การจัดการ infrastructure ของระบบ การจัดการ dependency/library ต่าง ๆ เพื่อช่วยลดปัญหาในเรื่องของการ ทดสอบ และ deploy ส่งมอบได้รวดเร็วขึ้น สามารถรับมือกับการเปลี่ยนแปลงของตลาดที่รวดเร็วได้ ทำให้แข่งขันกับคู่แข่งได้ดีขึ้น กระบวนการทำงานหรือที่เรียกว่า Pipeline จะเริ่มตั้งแต่การ push code มายัง version control จนไปถึงการส่งมอบหรือ delivery ซึ่งทำงานแบบอัตโนมัติ ปลอดภัย และรวดเร็ว ยังไม่พอนะ ระบบต้องสามารถ scale ตามความต้องการได้ ทั้งการขยายหรือหด (Elastic Scaling) ยังไม่พออีกนะ ระบบต้องสามารถไป run ใน infrastructure ที่แตกต่างกันได้อีก (Portability) ถ้าการ deploy มีปัญหาหรือไม่สำเร็จ ต้องสามารถ rollback กลับไปยัง version ก่อนหน้าได้แบบอัตโนมัติ

สิ่งต่าง ๆ เหล่านี้รวมกัน มันคือคุณสมบัติของ Modern Application

แน่นอนว่ามันขัดแย้งต่อ Traditional Application อย่างมาก ดังนั้นนี่คือ ความท้าทายที่หลาย ๆ คนกำลังเผชิญอยู่ เพื่อหาเส้นทางไปให้ถึง Moden Application !! หนึ่งในเครื่องมือที่นำมาช่วยแก้ไขปัญหาคือ Docker นั่นเอง

ตัวอย่างระบบงานใน session นี้เป็นระบบที่พัฒนาด้วย Java EE 7

โดยใช้ JavaServer Face กับ JPA (Java Persistence API) ชีวิตมัน monolith มาก ๆ ตายหมู่ชัด ๆ สามารถดู code ได้ที่ Github:: JavaEE Demo ดังนั้นจากระบบดังกล่าว สิ่งที่ต้องทำก่อนเลย คือ การแยกส่วนของ Frontend และ Backend ออกจากกัน

Frontend พัฒนาใหม่ด้วย React ซึ่งทำแบบค่อยเป้นค่อยไป ไม่ใช่ทำครั้งเดียวนะ
Backend พัฒนาด้วย JPA + REST API + JSON

เพื่อให้ระบบงานเล็กลง ทำงานอย่างเดียว ที่สำคัญง่ายต่อการนำ Docker มาใช้งานอีกด้วย โดย code ตัวอย่างจะใช้ Mono-repository คือทั้ง Frontend และ Backend อยู่ใน repository เดียวกัน

จากนั้นทำการสร้าง Dockerfile ของแต่ละส่วน

สำหรับ Java application นั้นจะมีการทำงาน 2 ขั้นตอนคือ

ทำการ compile/test และสร้าง artifact file เช่น JAR/WAR/EAR
ทำการ deploy artifact file ไปยัง Application server ซึ่งใช้ทั้ง JBOSS Wildfly และ Apache TomEE

โดยในการสร้าง Dockerfile จะใช้ multi-stage ดังนั้นจึงสร้างเพียงไฟล์เดียวเท่านั้น ง่ายมาก ๆ ยังไม่พอนะ ยังนำ docker-compose มาช่วย เมื่อทำการ deploy ระบบทั้ง Frontend และ Backend ส่งผลให้ปัญหาเรื่องของการ deploy ลดน้อยลงไปอย่างมาก ซึ่งเป็นอีกหนึ่งตัวอย่างที่น่าสนใจนะครับ สามารถดู VDO ในทุก session ของงานได้ที่ DockerCon EU 2017 :: All Videos Reference Websites https://blog.docker.com/2017/11/mta-java-apps-for-it-pros/