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

มาเขียน Robotframework บน Jupyter notebook กันดีกว่า

March 28, 2018, 11:00 pm
$
0
0

เห็น Docker Image ชื่อว่า RobotKernel จากงาน RobotCon 2018 ซึ่งเป็นสิ่งที่ทำให้สามารถเขียนและ run ชุดการทดสอบ ที่เขียนด้วย Robotframework บน Jupyter notebook ได้ จากที่ลองใช้ดูก็สะดวกดีนะ ลองใช้กันดู ปล. แต่มันเป็น PoC project นะครับ วิธีการติดตั้งก็ง่ายมาก ๆ ผ่าน Docker เลย [code] $docker run --rm -p 8888:8888 datakurre/robotkernel [/code] จากนั้นเข้าใช้งานเลย ชีวิตน่าจะสบายขึ้นเยอะนะครับ ดังนี้   ไว้จะมาอธิบายการใช้งานอีกรอบนะครับ
↧
Search

มาสร้าง Build caching server ของ Gradle กันหน่อย

April 2, 2018, 8:32 pm
$
0
0

สำหรับการใช้งาน Gradle ทั้ง Android, Backend และ Frontend นั้น ในแต่ละ task นั้นสร้าง cache data ไว้เสมอ ทำให้ทำงานได้เร็วขึ้น แต่ความเร็วของแต่ละเครื่องที่ build ขึ้นอยู่กับการสร้าง cache data นี่แหละ ดังนั้นถ้าแต่ละเครื่องทำการ share cache data ก็น่าจะดีนะ ดังนั้นมาใช้งาน Caching server กันหน่อยดีกว่า
เป้าหมายเพื่อความเร็วในการ build นั่นคือทำให้ชีวิตนักพัฒนาดีขึ้น

เริ่มด้วยการสร้าง Caching server ของการ build

ซึ่งทางทีม Gradle ได้เตรียม Docker Image ชื่อว่า build cache node ไว้ให้แล้ว ดังนั้นก็สร้าง container ใช้งานได้ทันที [code] $docker container run -d -p 80:80 gradle/build-cache-node:3.2 [/code] เข้าใช้งานผ่าน browser url http://localhost สำหรับใครที่ชื่อชอบ security ก็มีให้กำหนด user/password และ role ต่าง ๆ อยู่ในส่วนของ seeting ของ Build cache

เมื่อทุกอย่างพร้อมก็มาใช้งานกัน

ตัวอย่างการใช้งานเป็น Android app แบบง่าย ๆ เปิดใช้งาน build cache ก่อนนะ ทำได้ทั้ง
  • ใส่ผ่าน command line ด้วย --build-cache
  • ใส่ในไฟล์ gradle.properties ด้วยค่า org.gradle.caching=true
ต่อมาทำการเชื่อมต่อไปยัง Caching server ที่สร้างไว้ ด้วยการแก้ไข configuration ในไฟล์ settings.gradle ดังนี้ [gist id="69bbc959f19a673a02643cd801dbacf3" file="settings.gradle"] เมื่อทุกอย่างพร้อมก็ใช้งานสิ [gist id="69bbc959f19a673a02643cd801dbacf3" file="run.txt"] ตรวจสอบขนาดของ cache data ผ่าน browser ได้นะ ดังนั้นเราสามารถใช้ cache data ของการ build ร่วมกันแบบข้ามเครื่องได้แล้ว น่าจะทำให้การพัฒนารวมไปถึงการ setup และการทำงานของ CI server ง่ายและเร็วขึ้น ลองนำไปใช้กันดูนะ
↧
↧

[Python]สร้าง API ง่าย ๆ ด้วย Flask และ Connexion

April 5, 2018, 10:08 am
$
0
0

วันนี้มีโอกาสได้แบ่งปันความรู้สำหรับการสร้าง API ด้วยภาษา Python โดยสิ่งที่ต้องการคือ
  • พัฒนาได้ง่าย
  • ยิ่งถ้าสร้างจาก specification บางอย่างด้วยน่าจะดี
  • ขนาดไม่ใหญ่
  • ไม่ซับซ้อน
ดังนั้นจึงเลือก Flask ซึ่งเป็น microframework สำหรับการพัฒนาระบบ web รวมทั้งใช้ Connexion เพื่อช่วยทำการสร้าง API แบบอัตโนมัติ จากการกำหนดค่าต่าง ๆ ในรูปแบบ OpenAPI หรือ Swagger Specification นั่นเอง ซึ่งน่าจะเป็นทางเลือกที่น่าสนใจ มาลองใช้งานกัน

ขั้นตอนที่ 1 สร้างไฟล์ requirements.txt เพื่อกำหนด library ที่ใช้

[code] Flask connexion [/code]

ขั้นตอนที่ 2 สร้างไฟล์สำหรับเขียน specification ของ API ที่ต้องการ

จากตัวอย่างต้องการ API มี endpoint คือ /v1/product สำหรับดึงข้อมูลสินค้าทั้งหมดจากระบบ โดยที่ api จะส่งข้อมูล list ของ product กลับมา Product แต่ละชิ้นประกอบไปด้วย id, name และ price ดังนั้นสามารถเขียนได้ดังนี้ [gist id="82038d4af0be1eb2aa74d1db0efff132" file="sample.yaml"] จะสังเกตได้ว่า จะมี property ชื่อว่า operationId ใช้สำหรับกำหนดชื่อ method เริ่มต้นการทำงานของ API ชื่อว่า /product

ขั้นตอนที่ 3 สร้างส่วน operation สำหรับ API สิ

[gist id="82038d4af0be1eb2aa74d1db0efff132" file="api.py"]

ขั้นตอนที่ 4 สร้างส่วนการทำงานหลักด้วย Flask และ Connexion

[gist id="82038d4af0be1eb2aa74d1db0efff132" file="app.py"]

ขั้นตอนที่ 5 ทำการ run สิ

ได้ผลการทำงานดังนี้ หน้า API /v1/product หน้าของ API Specification ในรูปแบบของ Swagger เพียงเท่านี้เราก็ได้ API แบบง่าย ๆ จากการเขียน Specification กันแล้ว ที่สำคัญได้โครงสร้าง code ของระบบงานอีกด้วย ขอให้สนุกกับการเขียน code ครับ
↧

code ที่นักพัฒนาเขียนขึ้นมานั้น S.A.F.E ไหมนะ ?

April 6, 2018, 7:28 pm
$
0
0

สิ่งที่นักพัฒนา software ควรต้องรู้และเข้าใจสำหรับ code ที่เขียนคือ code ที่เขียนขึ้นมานั้นปลอดภัยหรือไม่ ? แน่นอนว่า นักพัฒนาบางคนอาจจะบอกว่า แค่เขียน code ให้เสร็จตามเวลาก็ถือว่าดีแล้ว ส่วนเรื่องของ security ไม่ใช่หน้าที่ ให้ทางฝ่าย security ดูเองก็แล้วกัน ถ้ามีเจอปัญหาอะไรก็แจ้งมา เดี๋ยวแก้ไขให้ !! แต่คิดว่าไม่น่าจะเป็นแนวคิด แนวทางที่ดีนัก เนื่องจากนักพัฒนาต้องมีความรู้และเข้าใจ การเขียน code ให้มีความปลอดภัยกันบ้าง อ่านเจอบทความเรื่อง S.A.F.E จึงนำมาสรุปไว้นิดหน่อย
Sensitive Access control Foolproof Enforce

Sensitive

ใน source code ไม่มีข้อมูลหรือเก็บข้อมูล sessitive data หรือไม่ เช่น password, ข้อมูลที่เป็นความลับหรือส่วนตัว และ session หรือ token ต่าง ๆ รวมทั้งเก็บใน version control มีด้วยหรือไม่ ถ้ามีก็ให้แยกออกมาโดยด่วน ข้อมูลที่ส่งไปมาระหว่าง server นั้น ทำการเข้ารหัสหรือไม่ ในส่วนของ log message ต่าง ๆ ทำการเก็บข้อมูล sesitive data หรือไม่ หรือข้อมูลส่วนตัวที่ไม่ได้รับอนุญาตจากเจ้าของหรือไม่ ดังนั้นตรวจสอบกันด้วยนะ !!

Access control

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

Foolproof

เราทำการตรวจสอบในแต่ละ request หรือไม่ ? ทั้งการตรวจสอบข้อมูลว่า เป็นไปตามที่ต้องการหรือไม่ เพื่อลดปัญหาต่าง ๆ ทั้ง JavaScript และ SQL Injection เมื่อทำการส่งผล error กลับไปยังผู้เรียก ต้องไม่ส่งรายละเอียดของการทำงานภายในออกไป เพราะว่า มันอาจจะเป็นข้อมูลที่ใช้ในโจมตีระบบได้เลย ยกตัวอย่างเช่นถ้า password ผิด น่าจะแจ้งด้วยคำว่า login fail มากกว่า password ผิดนะ

Enforce

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

สุดท้ายแล้ว

น่าจะช่วยทำให้ code ที่เขียนขึ้นมานั้นปลอดภัยมากขึ้น นักพัฒนาลองเข้าไปศึกษาเพิ่มเติมได้ที่ OWASP ยิ่งถ้าบริษัทไหนมี security specialist/expert แล้ว ให้คนเหล่านั้นมาสอน มาเขียนให้ดูเลยครับ ขอให้สนุกกับการเขียน code นะครับ
↧

สวัสดี Jenkins X

April 7, 2018, 7:29 pm
$
0
0

มาทำความรู้จักกับ Jenkins X กันหน่อย ซึ่งเป็น project ใหม่ที่ทาง cloudbees เป็นหัวหน้าทีมพัฒนา มีเป้าหมายเพื่อช่วยให้การทำ Continuous Delivery และใช้งาน Kubernestes ง่ายขึ้น หรือเป็น Automated pipeline บน Kubernetes นั่นเอง ดังนั้นมาทำความรู้จักและใช้งานกันหน่อย
ปล. project นี้ยังอยู่ในช่วงเริ่มต้นเท่านั้น project นี้ไม่ได้มาแทนที่ Jenkins แต่เข้ามาช่วยให้การทำงานกับ container และ cloud ง่ายและสะดวกขึ้น โดยไปดู Roadmap เพิ่มได้

ถ้าถามว่า Jenkins X คืออะไร

ตอบสั้น ๆ ว่า CI/CD platform สำหรับ Kubernetes นั่นเอง เป็น sub-project ของ Jenkins Jenkins X นั้นถูกออกแบบด้วยเป้าหมายตาม DevOps เลย นั่นคือ
  • Time to market ที่เร็วกว่า
  • ปรับปรุงการ deploy ให้บ่อยขึ้น
  • ช่วยทำให้เวลาในการแก้ไขสั้นลง
  • ลดจำนวนข้อผิดพลาดของการ release ระบบลง
  • ค่า Mean Time To Recovery ให้เร็วขึ้น

สถาปัตยกรรมของ Jenkins X เป็นอย่างไร ?

แสดงตามรูปแลย มี component ที่สำคัญดังนี้
  • Kubernetes และ Docker โดยที่หัวใจคือ Kubernetes ซึ่ง Cloud provider หลัก ๆ สนับสนุนอยู่แล้วทั้ง Google Azure และ AWS
  • ใช้ Helm (Kubernetes Package Manager) กับ Draft ในการจัดการ configuration ของระบบงาน เนื่องจากการใช้งานผ่าน kubectl และ YAML ตรง ๆ ของ Kubernetes นั้นมีความซับซ้อนและเกิด human error ได้ง่าย
  • Jenkins X ถูกออกแบบมาเพื่อการทำงานที่มีหลาย ๆ ทีม รวมถึง microservices อีกด้วย
  • จัดการ versioning, สร้าง change log ให้แบบอัตโนมัติ

มาดูความสามารถของ Jenkins X กันบ้าง

  • มี command line ให้ใช้งาน ทั้งการสร้าง cluster, project, จัดการ environment และการ deploy
  • มี pipeline ให้ใช้งานโดย default อยู่แล้ว (Build -> Test -> Packaging -> Deploy)
  • สามารถจัดการ environment ได้ง่าย ๆ ซึ่งสามารถใช้ชื่อ Testing, Staging และ Production ได้เลย ทำให้ง่ายขึ้นไปอีก
  • สามารถทำการ promote version ของ application ไปยัง environment ต่าง ๆ ได้เลย แสดงดังรูป
  • Preview environment ใน pull request แต่ละตัวนั้น สามารถสร้าง environment ขึ้นมาเพื่อทดสอบ ก่อนจะ merge มายัง branch หลัก ซึ่งช่วยลดปัญหาต่าง ๆ ลงไปได้มาก
  • มีระบบ Addon ให้ใช้งาน นั่นคือสามารถเพิ่ม software ต่าง ๆ เข้ามาได้เลย ซึ่งตอนนี้ยังมีน้อย

มาลองใช้งาน Jenkins X กันดีกว่า

ขั้นตอนที่ 1 ติดตั้ง jx ก่อน เป็น command line สำหรับใช้งาน

[gist id="de3353507b3a3df6bdc561dcea3b87fb" file="1.txt"]

ขั้นตอนที่ 2 สร้าง Cluster ของระบบ

โดยที่สนับสนุนทั้ง
  • GKE (Google Cloud Engine)
  • AWS (Amazon Web Services)
  • AKS (Azure Container Service)
  • Local ด้วย minikube
ตัวอย่างชุดคำสั่ง [code] $jx create cluster gke $jx create cluster aws $jx create cluster aks $jx create cluster minikube [/code] ใน blog นี้ผมทำการสร้างบน Google Cloud Engine ดังนี้ ถ้าไม่มี dependency หรือ library ใด ๆ ที่ต้องใช้ จะทำการ download และติดตั้งให้เลย ทั้ง gcloud และ helm ที่สำคัญอย่าลืมเปิด Google Kubernetes Engine API [gist id="de3353507b3a3df6bdc561dcea3b87fb" file="2.txt"] ใช้เวลาการสร้าง cluster นานพอสมควรนะ !! จากนั้นจะทำการเชื่อมต่อไปยัง github แต่ต้องไปสร้าง API Token มาใช้ก่อน และเมื่อทุกอย่างเรียบร้อย ก็มีอะไรไม่รู้สร้างมาเพียบ [gist id="de3353507b3a3df6bdc561dcea3b87fb" file="1.txt"] ลองไปดูใน Google Cloud Console ก็เจอ cluster ที่สร้างดังรูป ได้ Jenkins ด้วยนะ บอก username และ password เข้าใช้งานมาให้ครบ มี job สำหรับ environment แต่ละตัวให้มาพร้อม ทั้ง staging และ production สร้าง repository ใน Github ให้อีกด้วย ใช้สำหรับจัดการ environment ต่าง ๆ ของระบบนั่นเอง สร้างให้ทั้ง staging และ production รวมทั้งสร้าง webhook ให้อีกด้วย มันจะทำเยอะไปไหนนะ เมื่อทุกอย่างพร้อม ก็ได้สิ่งต่าง ๆ มาดังนี้ [gist id="de3353507b3a3df6bdc561dcea3b87fb" file="4.txt"] ว่าแต่มันมีอะไรบ้างมาดูหน่อยสิ
  • Docker Registry V2 สำหรับจัดเก็บ Docker Image
  • Jenkins X App สำหรับดูการ deploy ระบบงาน
  • Nexus Repository Manager Server สำหรับจัดเก็บ library และ dependency ต่าง ๆ

ขั้นตอนที่ 3 ได้เวลาสร้าง Spring Boot Application กันแล้ว

แน่นอนว่าจะทำการสร้าง Git repository โดยมีทั้ง code Dockerfile สำหรับใช้สร้าง Docker Image Jenkinsfile สำหรับสร้าง Job ใน Jenkins ดังนี้ [gist id="de3353507b3a3df6bdc561dcea3b87fb" file="5.txt"] มีความจริงจังมาก ๆ จากนั้นจะ trigger ให้ Job ใน Jenkins ทำการ build ซึ่งมี pipeline มาตรฐานดังนี้ [gist id="de3353507b3a3df6bdc561dcea3b87fb" file="Jenkinsfile"] ดูไฟล์ Jenkinsfile ไปแล้วงง มาดูรูป pipeline กันดีกว่า
  • Pull code
  • ทำการ build คือ compile, test และ packaging
  • ทำการ promote ไปยัง environment ต่าง ๆ ทั้ง staging และ production
เมื่อเข้าไปดูรายละเอียดจะพบว่า มีการสร้าง docker image ของ project จากนั้นทำการ push ไปยัง Docker Registry V2 ก่อน ก่อนทำการ promote ไปยัง environment ต่าง ๆ มีการทำ changelog แบบอัตโนมัติ มีการทำ versioning ของ project สร้าง pull request ไปยัง environment ต่าง ๆ เพื่อเริ่มกระบวนการ deploy แสดงดังรูป สามารถดูเพิ่มเติมได้ที่ VDO :: Create Spring Boot

มาถึงตรงนี้จะพบว่า

Jenkins X นั้นทำสิ่งต่าง ๆ ให้เยอะมาก (เยอะจนมึนงงกันไปเลย ยิ่งมือใหม่จะงงมาก ๆ) แต่ก็มองได้สองมุมคือ มุมแรกมันเยอะไปไหม พังมานี่ยุ่งเลย แก้ไม่ถูกแน่ ๆ มุมสองมันก็ง่ายดีนะ ไม่ต้องมาสนใจ pipeline เลย แถมมีขั้นตอนเหมือนกันอีก
แต่ถึงอย่างไรก็ตาม นักพัฒนา software ก็ต้องศึกษาเพื่อให้รู้ ข้อดีและข้อเสีย เพื่อให้เข้าใจมันก่อนที่จะตัดสินใจ
ปล. ตอนนี้ bug เพียบนะ ขอให้สนุกกับการเขียน code นะครับ
↧
↧

Java Developer จัดการ version ของภาษา Java กันอย่างไร ?

April 9, 2018, 9:10 am
$
0
0

หลายครั้งที่ไปแบ่งปันเรื่องต่าง ๆ เกี่ยวกับการพัฒนาระบบงานด้วยภาษา Java สิ่งหนึ่งที่ต้องประหลาดใจคือ หลาย ๆ คนไม่ได้กำหนดค่าของ JAVA_HOME สามารถทำการ run ด้วยคำสั่ง java ได้ แต่ไม่สามารถ compile ด้วยคำสั่ง javac ได้ นั่นหมายความว่า ในเครื่องมีแต่ JRE (Java Runtime Environment) แต่ไม่มี JDK (Java Development Kit) หรือบางคนก็มี JDK นะแต่ run ไม่ได้ เนื่องจากทำการกำหนดไว้ใน IDE เท่านั้น แต่ไม่ได้กำหนด JAVA_HOME หรือบางคนก็กำหนดนะ แต่กำหนดไว้ใน PATH ตรง ๆ เลย ไม่มีกำหนดใน JAVA_HOME
คำถามที่น่าสนใจคือ ถ้ามี Java หรือ JDK หลาย ๆ version จะจัดการกันอย่างไร ?
ยังไม่พอนะ Java หรือ JDK ที่ใช้ในงานนั้น แต่ละคนใช้ version เดียวกันหรือไม่ ?
ปล. JAVA_HOME คือชื่อ environment variable ของระบบ ใช้สำหรับกำหนด path ของการติดตั้ง JDK นั่นเอง

ดังนั้นลองมาแบ่งปันปันกันหน่อย ว่าจัดการ version ของ Java กันอย่างไร ?

แบบที่ 1 มากำหนดใน environment ชื่อ JAVA_HOME กัน เป็นวิธีแบบพื้นฐานสุด ๆ ถ้าใครไม่ทำจัดว่าแย่ใช้ได้เลย สำหรับ Java Developer นะ บางคนอาจจะบอกว่า ก็ใช้ IDE นะ มันก็ทำงานได้ !! อันนี้ไม่เถียงนะ แต่ถ้าไม่มี IDE ละ จะทำงานกันอย่างไร ? compile อย่างไร ? run อย่างไร ? packaging พวก JAR, WAR และ EAR กันอย่างไร ? ตัวอย่างการใช้งาน [code] //Windows set JAVA_HOME=<path ในการติดตั้ง JAVA> set PATH=.;%JAVA_HOME%\bin;%PATH% //Mac หรือ Linux export JAVA_HOME=<path ในการติดตั้ง JAVA> export PATH=.:$JAVA_HOME\bin:$PATH [/code] สิ่งที่ได้ตามมาคือ สามารถใช้งานทั้งการ compile และ run ผ่าน command line ได้เลย พวก build tool ต่าง ๆ ก็ใช้งานค่าเหล่านี้ ทั้ง Apache Maven และ Gradle แบบที่ 2 สำหรับชาว Mac น่าจะต้องใช้กัน โดยใน MacOS จะมี /usr/libexec/java_home ให้ใช้งาน สำหรับจัดการ version ของ Java นั่นเอง การใช้งานก็ไม่ยากเลย [gist id="3ad3c81f5ebcd03d935c874b6a4157ba" file="1.txt"] แบบที่ 3 ใช้งาน jenv (Java Environment Management) สามารถใช้งานได้เหมือนกับ rbenv ของภาษา ruby เลย [gist id="3ad3c81f5ebcd03d935c874b6a4157ba" file="2.txt"] แบบที่ 4 ใช้ Docker Image มันไปเลยง่ายสุด ๆ
คำถาม วันนี้ Java Developer จัดการ version ของ Java หรือ JDK กันอย่างไร ?
↧

Java 10 เป็นมิตรกับ Docker แล้วนะ

April 10, 2018, 11:45 am
$
0
0

สำหรับระบบงานที่ run ใน JVM (Java Virtual Machine) นั้น ไม่ว่าจะเป็น Java Spring, Apache Spark, Apache Kafka และอื่น ๆ มีนำมาอยู่ในโลกของ container แล้วนั้น พบว่าจะมีปัญหาเรื่องการจัดการและใช้งาน memory และ CPU เป็นอย่างมาก ทั้งกิน memory และใช้ CPU เกินขนาดที่กำหนด ทำให้ประสิทธิภาพการทำงานใน container แย่มาก ๆ แต่ใน Java 10 พบว่ามีการแก้ไขและปรับปรุงให้แล้ว ประกอบไปด้วย
  • กำหนด memory limit ในแต่ละ container
  • กำหนดจำนวน CPU ในแต่ละ container
น่าจะทำให้ชีวิตดีขึ้นมาอีกพอสมควร ตัวอย่างการกำหนด memory limit ให้แต่ละ container ทำการกำหนด memory ขนาด 512M ขนาดของ Heap ต้องมีขนาด 1/4 ของที่จองไว้ แน่นอนว่าใน Java 10 แก้ไขแล้ว นั่นคือมีขนาดประมาณ 130M ดังนี้ [gist id="24f2e19000d1607de00da4048f220644" file="1.txt"] ตัวอย่างการกำหนดจำนวน CPU ให้แต่ละ container ทำการกำหนด CPU ไป 2 ดังนี้ [gist id="24f2e19000d1607de00da4048f220644" file="2.txt"] จากการใช้งานพบ Java 10 ทำให้เราไม่ต้องมาพะวงเรื่องเหล่านี้ต่อไปอีกแล้ว ไปทำ profiling กันดีกว่า ว่าระบบงานในแต่ละ container ต้องใช้ resource เท่าไรกันแน่ ขอให้สนุกกับการ coding นะครับ Reference Websites https://blog.docker.com/2018/04/improved-docker-container-integration-with-java-10/
↧

แนะนำ LearnStorybook

April 11, 2018, 8:19 am
$
0
0

วันนี้ไปเจอ LearnStorybook เป็น web สำหรับสอนเกี่ยวกับการใช้งาน Storybook แน่นอนว่าฟรี อีกทั้งเป็นแหล่งความรู้ที่ดีสำหรับการใช้งาน Storybook มาศึกษากันเถอะ โดยแบ่งเนื้อหาออกเป็น 9 บท ตั้งแต่ความรู้พื้นฐาน แนวคิดของ Component-Driven Development การติดตั้งและใช้งาน การทดสอบแบบอัตโนมัติ ทั้ง Visual testing, Snapshot testing และ Unit testing การติดตั้ง Addons ต่าง ๆ เช่น Storyshots สำหรับ Snapshot testing การจัดการกับหลาย ๆ component การจัดการข้อมูลต่าง ๆ เช่น props, state ไปถึง Redux การ deploy ระบบงานแบบอัตโนมัติด้วย Netlify สุดท้ายแล้วมาช่วยกันแปลกันครับ
↧
Search

สิ่งที่นักพัฒนาชอบทำผิด

April 12, 2018, 8:26 am
$
0
0

เขียน code โดยไม่ทำการวางแผน

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

แต่การวางแผนหรือคิดมากไปก็ใช่จะเป็นสิ่งที่ดี !!

การวางแผนเป็นสิ่งที่ดี แต่การแผนที่มากไปหรือใช้เวลานานเกินไปกลับเป็นสิ่งที่แย่ เหมือนกับการกินน้ำ กินมากไปมันก็จุก วิ่งหรือเดินไม่ไหว เราไม่ได้ต้องการแผนงานที่สมบูรณ์แบบ แต่ต้องการแผนที่พอเพียงให้เริ่มต้นเดินทางได้ เนื่องจากนั้นแผนงานต่าง ๆ ต้องมีการเปลี่ยนแปลงเสมออยู่แล้ว ดังนั้น plan อย่านิ่งนะ ต้อง plan กันบ่อย ๆ วางแผนมากหรือน้อยไปก็ไม่ดีนะ เช่นวางแผนทีเดียวทั้ง project/product ไม่น่าจะดี ลองวางแผนเป็นส่วน ๆ ดีไหม เช่นวางแผนของ feature ที่จะทำต่อไปดีไหม

ชอบใช้ solution หรือวิธีการแก้ไขแรกที่ทำได้ หรือ คิดได้

บ่อยครั้งพบว่า วิธีการแก้ไขปัญหาแรก ๆ มักจะเป็นวิธีการชั่วคราว ไม่ดี แต่ทำงานได้ แต่เรามักจะเลือกใช้ ทั้ง ๆ ที่อาจจะมีวิธีการอื่น ๆ อีก ดังนั้น สิ่งที่ควรต้องทำคือ ลองหาวิธีการอื่น ๆ บ้าง เพื่อทำให้เห็นข้อดีและเสีย เพื่อทำให้เข้าใจปัญหา จากนั้นจึงทำให้เราเลือกวิธีการที่ดีกว่าได้
สิ่งที่นักพัฒนาทำนั้น ไม่ใช่หาวิธีการแก้ไขปัญหาเท่านั้น แต่วิธีการเหล่านั้นต้องแก้ไขปัญหาได้ดี มีประสิทธิภาพที่ดี รวมไปถึงง่ายต่อการอ่าน ทำความเข้าใจและดูแลรักษา
ยังไม่พอนะ !! เมื่อต้องมาแก้ไข code ที่ทำไว้แล้ว พบว่า code เหล่านั้นมันไม่ดี มีวิธีการที่ดีกว่า สิ่งที่ทำคือ การพยายามแก้ไข code เหล่านั้นให้ทำงานได้ตามที่ต้องการ แต่ไม่ได้ทำให้ code นั้นดีขึ้น !! หรือไม่ยอมเขียน code ด้วยวิธีการใหม่ ๆ ทั้ง ๆ ที่ใช้งาน version control ด้วยนะ แปลกดีนะ !! อีกอย่างที่สำคัญ ปัญหาที่เราเจอนั้น เชื่อเถอะว่าคนอื่น ๆ น่าจะเจอแล้วและแก้ไขแล้ว ดังนั้นลองค้นหาดูสิ แต่ต้องระมัดระวังให้มาก เพราะว่า สำหรับมือใหม่ชอบ copy and paste มาใช้โดยที่ไม่เข้าใจเลย แต่มันทำงานได้ตามที่ต้องการเท่านั้นเอง

ปัญหาที่หนักมาก ๆ คือ Data Structure ที่ใช้มักจะผิดหรือไม่เหมาะสม

เนื่องจากบางครั้งสนใจ algorithm มากจนเกินไป จนหลงลืมเรื่องของ data structure ที่เหมาะสมกับปัญหา ทำให้มักจะเลือกใช้งานผิดบ่อยมาก ๆ

มักเขียน code แย่ ๆ ขึ้นอย่างต่อเนื่อง

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

ชอบถามหา Best Practice !!

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

ยังไม่พอนะ ชอบใช้ Shared หรือ Global State มากจนเกินไป

ทำให้เกิดปัญหา หรือ side-effect ตามมาเยอะมาก แถมหา root cause ไม่เจออีกด้วย เพราะว่าทำการ shared state ทั้งระบบกันไปเลย ไม่รู้ว่ามีใคร ตรงไหน มาทำการแก้ไขหรือเปลี่ยนแปลง ดังนั้น ลด ละ เลิก กันนะ หรือใช้แต่พองาม

มีอะไรอีกละ เยอะจริง ๆ อีกเรื่องคือ ไม่ยอมพัก

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

Backend Developer จำเป็นต้องเรียนรู้อะไรกันบ้าง ?

April 14, 2018, 4:04 am
$
0
0

หลังจากที่อ่านเรื่องของ Web Developer Roadmap 2018 แล้ว ซึ่งแนะนำเฉพาะส่วนของ Web Developer เท่านั้น แต่น่าจะมีส่วนของ Backend Developer บ้างนะ จึงทำการสรุปสิ่งที่น่าจะต้องรู้ไว้นิดหน่อย ซึ่งคิดว่าเป็นความรู้พื้นฐานแบบติดดินที่ควรรู้ไว้บ้าง

1. เลือกภาษาโปรแกรมสักอย่าง เพื่อเรียนรู้และฝึก ฝึก ฝึก

คำถามแรก จะเลือกภาษาโปรแกรมอะไรดี ? คำตอบคือ ดูความต้องการของตลาดสิ ดูแนวโน้มความนิยมของภาษาต่าง ๆ สิ เท่าที่เห็นจะมี เช่น Node.JS, Java, Python, PHP, C#, Go จากนั้นก็ลงมือทำ ฝึก ฝึก ฝึก เพื่อทำให้เข้าใจแนวคิดพื้นฐานของภาษานั้น เขียนให้เป็น เขียนให้ถูกและดี ที่สำคัญแนะนำให้สร้างระบบเล็ก ๆ ขึ้นมาด้วย เพื่อทำให้เข้าใจมากยิ่งขึ้น

2. เรียนรู้พวก Package Management Tool และฝึก ฝึก ฝึก

เป็นสิ่งที่สำคัญมาก ๆ สำหรับการจัดการ library/dependency ต่าง ๆ ที่นำมาใช้ในระบบ ซึ่งแต่ละภาษาก็ใช้เครื่องมือที่แตกต่างกัน คงไม่มีใครที่ยัง copy library/dependency กันนะ !! ยกตัวอย่างเช่น
  • Java ใช้ Apache Maven และ Gradle
  • Python ใช้ PIP
  • Node.JS ใช้ NPM และ Yarn
  • PHP ใช้ composer
ทำการศึกษาและเข้าใจเครื่องมือที่เลือกให้ดีนะครับ

3. เรียนรู้พวกการทดสอบในรูปแบบต่าง ๆ และฝึก ฝึก ฝึก

เนื่องจากการทดสอบแบบอัตโนมัติเป็นสิ่งที่สำคัญมาก ๆ ถ้าเรียนรู้อะไรใหม่ ๆ ควรเรียนรู้มันไปด้วย ทั้งการเขียน Unit test ทั้งการเขียน Integration test ทั้งการเขียน API test ทั้งการเขียน Component test ทั้งการเขียน End-to-End test รวมไปถึงแนวคิดเรื่อของ Test double เช่น Stub และ Mock อีกด้วย จากนั้นก็ลงมือเขียน ฝึก ฝึก ฝึก

4. เรียนรู้เรื่องของ RESTful API และฝึก ฝึก ฝึก

เพื่อให้เข้าใจพื้นฐานว่า REST เป็นอย่างไร เนื่องจากระบบ Backend ในปัจจุบันมักจะสร้างตามแนวคิดนี้ รวมทั้งเรื่องรูปแบบข้อมูลที่รับส่งไปมาด้วยทั้ง JSON และ XML ยังไม่พอนะ เรื่องของ Authentication และ Authorization ก็ขาดไม่ได้เลย ต้องทำความเข้าใจเกี่ยวกับวิธีต่าง ๆ ดังนี้ ว่ามีความเหมือนหรือต่าง รวมถึงข้อดีข้อเสียด้วย
  • Basic Authentication
  • Token/Ticket Authentication
  • OAuth (Open Authentication Standard)
  • JWT (JSON Web Token)

5. เรียนรู้เกี่ยวกับ Database ทั้ง RDBMS และ NoSQL และฝึก ฝึก ฝึก

การจัดเก็บข้อมูลเป็นสิ่งที่สำคัญมาก ๆ ต่อระบบ ดังนั้นต้องศึกษา เพื่อรู็และเข้าใจว่า ที่จัดเก็บข้อมูลมีกี่แบบ แต่ละแบบมีข้อดีข้อเสียอย่างไรบ้าง แต่ละแบบต้องทำการออกแบบอย่างไร ต้องจัดการ transaction อย่างไร ต้องจัดการ index อย่างไร ต้องทำการ normalization อย่างไร เพื่อเลือกใช้ให้ตรงกับความต้องการของแต่ละงานได้ ไม่ใช่ใช้แต่ RDBMS อย่างเดียวกับทุก ๆ งาน ส่วนการเลือกก็ค่อย ๆ เลือกทีละตัว จากความนิยมเช่น
  • RDBMS อาจจะเลือก MySQL หรือ PosgreSQL
  • Document Database อาจจะเลือก MongoDB
  • Key-Value Database อาจจะเลือก Redis
  • Graph Database อาจจะเลือก Neo4J

6. เรียนรู้เกี่ยวกับการทำ Caching และฝึก ฝึก ฝึก

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

7. เรียนรู้ Web Server และ Application Server ที่ใช้งาน

เนื่องจากเราต้องทำการติดตั้งระบบของ Backend บน Web Server และแน่นอนว่ามีให้เลือกหลายตัว ดังนั้นเราควรต้องรู้และเข้าใจว่า Web Server แต่ละตัวมีขีดจำกัดและข้อจำกัดอย่างไร รวมไปถึงการ tunning ค่า configuration ต่าง ๆ ให้เหมาะกับงาน

8. เรื่องของ Container

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

ยังมีเรื่องอื่น ๆ อีกมากมายให้ศึกษาทั้ง

เรื่อง standard ของแต่ละภาษา เรื่องการจัดการ security เรื่องจาก Messaging Server
วันนี้ Backend Developer เรียนรู้อะไรกันอยู่บ้าง มีอะไรบ้างที่ยังไม่รู้ ไม่เข้าใจ จงเรียนรู้กันได้แล้วนะ และจงเรียนรู้กันต่อไป
ขอให้สนุกกับการ coding ครับ
↧

มาลองใช้งาน TICK stack กับระบบที่พัฒนาด้วย Spring Boot 2.0 กัน

April 15, 2018, 4:45 am
$
0
0

ไม่ว่าระบบงานใด ๆ ก็ตามจำเป็นต้องมีระบบ monitoring เพื่อดูและวิเคราะห์ว่าประสิทธิภาพของระบบงานเป็นอย่างไร เพื่อดูและวิเคราะห์ว่าระบบงานยังคงทำงานได้ดีอยู่นะ แน่นอนว่า มีวิธีการและเครื่องมือให้ใช้งานมากมาย หนึ่งในตัวเลือกที่มีการพูดถึงคือ TICK stack ดังนั้นมาลองทำความรู้จักและใช้งานกันหน่อย โดยระบบงานที่จะใช้นั้นพัฒนาด้วย Spring Boot 2.0 นั่นเอง มาเริ่มกันดีกว่า

TICK stack คืออะไร

เป็น platform สำหรับจัดการข้อมูลแบบ Time Serie จาก InfluxData แน่นอนว่า ประกอบไปด้วย product ที่เป็น open source ทั้งนั้นดังนี้ Telegraf สำหรับรวบรวมข้อมูลในรูปแบบ Time Serie จากแหล่งข้อมูลต่าง ๆ InfluxDB สำหรับจัดเก็บข้อมูล Time Serie Chronograf สำหรับแสดงผลข้อมูลในรูปแบบ visualization และ graph Kapacitor สำหรับจัดการเรื่อง alert และการ detect ข้อมูลในรูปแบบต่าง ๆ ที่กำหนด แสดงการทำงานร่วมกันของ TICK ดังรูป
ปล. เราสามารถใช้แต่ละตัวแยกกันได้ ไม่จำเป็นต้องใช้ทั้งหมด ขึ้นอยู่กับความต้องการของระบบนะ

อธิบายไปก็งง ใช้งานกับระบบที่พัฒนาด้วย Spring Boot 2.0 กันดีกว่า

เนื่องจากใน Spring Boot 2.0 นั้นมีการเปลี่ยนแปลง Actuator มาพร้อมกับ Micrometer ซึ่งช่วยให้จัดเก็บข้อมูลพวก metric ต่าง ๆ ได้ง่ายขึ้น รวมทั้งสนับสนุน monitoring tool หลาย ๆ ตัว ทั้ง StatD, Datadog และ Telegraf ดังนั้นการใช้งานกับ TICK stack จึงง่ายมากขึ้น อ่านการใช้งาน Actuator ใน Spring Boot 2.0 ได้ โดยที่ต้องเพิ่มค่าในไฟล์ application.properties สำหรับกำหนดรูปแบบข้อมูลในรูปแบบของ Telegraf และกำหนด port ของ Telegraf คือ 8125 [gist id="34e4754713a245c37098dfd8e79084d6" file="application.properties"] ส่วนการติดตั้ง TICK stack นั้นก็ไม่ง่ายเลย แต่ก็ไม่ยากถ้าเราใช้งานผ่าน Docker compose ซึ่ง Docker Image ก็ใหญ่อยู่นะ แต่ก็ทำให้สะดวกขึ้นมากมาย [gist id="34e4754713a245c37098dfd8e79084d6" file="docker-compose.yml"] จากนั้นก็ docker-compose up ก็ได้ระบบ monitoring ของระบบงานเราแล้ว [gist id="34e4754713a245c37098dfd8e79084d6" file="1.txt"] ปล. ส่วนบน production ก็อีกเรื่องนะครับ เพียงเท่านี้ก็ได้ Chronograf มาให้ใช้แบบสวย ๆ แล้ว จากนั้นก็เริ่มใช้งานสิ รออะไร Reference Websites https://aboullaite.me/spring-boot-metrics-monitoring-using-tick-stack/ https://www.influxdata.com/time-series-platform/
↧

แนะนำ Dockly เครื่องมือสำหรับจัดการ Docker ใน terminal !!

April 17, 2018, 10:16 pm
$
0
0

ไปเจอเครื่องมือจัดการ Docker ชื่อว่า Dockly ซึ่งใช้งานผ่าน command line หรือ terminal นั่นเอง พัฒนาด้วย Node.js เท่าที่ใช้งานมาก็ง่าย และ สะดวกดี มาลองใช้งานกันหน่อย

การใช้งานก็ไม่ยากเลย

เริ่มจากการตัดตั้งผ่าน npm ดังนี้ [code] $npm install -g dockly [/code] จากนั้นก็เริ่มใช้งานด้วยคำสั่ง $dockly จะแสดง container ต่าง ๆ รวมทั้งสามารถจัดการ container ได้เลยทั้ง
  • กดปุ่ม Enter/Return สำหรับดู log ของแต่ละ container
  • กดปุ่ม M สำหรับการแสดง menu เพื่อว่าจะ stop/start/remove container ทั้งหมด
  • กดปุ่ม I สำหรับดูรายละเอียดของ container
  • กดปุ่ม S สำหรับ stop container
  • กดปุ่ม L สำหรับการเข้าไปใน container
  • กดปุ่ม Q สำหรับออกจากระบบ
ดังนี้

เมื่อเข้าไปดู source code ของ Dockly ก็พบว่า

ใช้ library ชื่อว่า Dockerode สำหรับการติดต่อไปยัง Docker Engine ผ่าน Docker Remote API นั่นเอง โดยมี operation ต่าง ๆ ดังนี้ (ดูเพิ่มเติมได้ที่ไฟล์ DockerUtil)
  • Ping สำหรับตรวจสอบการทำงานของ DockerEngine
  • listImages รายชื่อของ Image
  • listContainers รายชื่อของ Container
  • listServices รายชื่อของ Service
  • การจัดการ image/container/service
ลองใช้งานกันดูครับ
↧

บันทึกเขียนภาษา Go บน Jupyter Notebook

April 19, 2018, 5:48 am
$
0
0

ว่าง ๆ นั่งดูว่าเราสามารถเขียนภาษา Go บน Jupyter Notebook ได้หรือไม่ ? เพื่อใช้สำหรับการบันทึกขั้นตอนการศึกษาต่าง ๆ ของภาษา Go ได้ง่ายขึ้น ก็ไปเจอว่ามีวิธีการเยอะเลย แต่ลองเลือกมาสักตัวคือ LGo ดังนั้นมาลองใช้งานกันหน่อย การติดตั้งใช้ผ่าน Docker นิดหน่อย ดังนี้ [code] $git clone https://github.com/yunabe/lgo.git $cd lgo/docker/jupyter $docker-compose up -d [/code] เมื่อทุกอย่างพร้อมก็เข้าใช้งานไปเลย แค่นี้ก็ใช้ได้แล้ว สวัสดี   Reference Websites http://www.datadan.io/announcing-a-golang-kernel-for-jupyter-notebooks/ https://hub.mybinder.org/user/yunabe-lgo-binder-y3i398mq/notebooks/basics.ipynb
↧
↧

ทำความรู้จักกับ Android Test Orchestrator

April 20, 2018, 1:17 am
$
0
0

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

Android Test Orchestrator คืออะไร

เป็นเครื่องมือสำหรับ Instrumentation test หรือการทดสอบที่ต้องการ Device จริง ๆ หรือ Emulator เสมอ ยังไม่พอนะ ในแต่ละ Test Case หรือ method ที่ขึ้นด้วย @Test นั้น จะทำงานหรือทดสอบคนละ instance กัน นั่นหมายความว่า ในแต่ละ Test Case จะไม่ส่งผลกระทบต่อกัน ยกตัวอย่างเช่น ถ้าบาง Test Case ส่งผลให้การทดสอบ crash หรือพังไป เช่นเกิด RuntimeException เป็นต้น จะไม่ส่งผลต่อ Test Case อื่น ๆ แต่ถ้าไม่ได้ใช้ Android Test Orchestrator แล้วจะทำให้ Test Case อื่น ๆ ไม่ถูกทดสอบได้ ถ้าบาง Test Case ต้องไปทดสอบการทำงานของ app แบบ asynchronous แล้ว มันอาจจะเกิด overlab หรือทับซ้อนกันระหว่างการทดสอบ ซึ่งอาจจะทำให้การทำงานของแต่ละ Test Case ผิดได้ง่าย ๆ เช่น Test Case ที่ 1 ต้องเป็นเรียกใช้ Service บางอย่าง แน่นอนว่า การทดสอบมันผ่านไปแล้ว จากนั้น Test Case ที่ 2 ถูกทดสอบ ในขณะนั้นเองที่ ผลจากการทำงานของ Service ถูกส่งกลับมา มันอาจจะทำให้การทดสอบของ Test Case ที่ 2 พังหรือผิดก็ได้ เพราะว่า แต่ละ Test Case ทำงานอยู่ใน instance ของการทดสอบเดียวกัน instance ของอะไร ? instance ของ AndroidJUnitRunner นั่นเองนะ นี่คือประโยชน์ของ Android Test Orchestrator

โครงสร้างการทำงานของ Android Test Orchestrator เป็นดังนี้

คำอธิบายการทำงาน ในการทำงานจริง ๆ จะมีการติดตั้งไฟล์ APK ไปยัง Device หรือ Emulator 4 ไฟล์ คือ
  1. Application Under Test คือ APK ของ app ที่จะถูกทดสอบ
  2. Test คือ APK ของชุดการทดสอบทั้งหมด
  3. Orchestrator คือ APK ของ Android Test Orchestrator สำหรับ run แต่ละ Test Case
  4. Test Service คือ APK ที่แยกออกมาจาก Orchestrator APK
APK ตัวที่ 3 และ 4 ดูได้จาก command line ตอนใช้งานดังนี้ [code] Download https://dl.google.com/dl/android/maven2/com/android/support/test/services/test-services/1.0.1/test-services-1.0.1.apk Download https://dl.google.com/dl/android/maven2/com/android/support/test/orchestrator/1.0.1/orchestrator-1.0.1.apk [/code]

มาลองใช้งานกันดีกว่า

ขั้นตอนที่ 1 เปิดใช้งานด้วยการเพิ่ม dependency และ configuration ใน build.gradle [gist id="43a7e30d6107680344e2c0db8726d117" file="build.gradle"] ขั้นตอนที่ 2 ทำการ run แบบง่าย ๆ ผ่าน command line ด้วยคำสั่ง [code] $./gradlew connectedCheck [/code] เพียงเท่านี้ก็ใช้งาน Android Test Orchestrator ได้แล้ว ขอให้สนุกกับการ coding นะครับ
↧

สิ่งที่น่าสนใจสำหรับ บทความเกี่ยวกับย้ายจาก PHP มายังภาษา Go ของ Kairos

April 23, 2018, 3:35 am
$
0
0

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

ก่อนที่จะเลือกภาษา Go นั้น

ทางทีมทำการมีการทำ research ในภาษาต่าง ๆ ก่อน ไม่ใช่เอะอะก็เลือกใช้เลย แน่นอนว่า เลือกตามเป้าหมายที่ได้ตั้งเอาไว้ การพัฒนาใหม่นั้น ก็ไม่ใช่ทำแบบ big bang แต่ค่อย ๆ ทำเป็นทีละส่วน จากนั้นทำการ validate และ ทดสอบ จากการใช้งานจริง ๆ เพื่อให้เห็นปัญหา เพื่อทำการแก้ไขได้ง่ายขึ้น เพื่อลดความเสี่ยงต่าง ๆ อีกด้วย

ประโยชน์ที่ได้จากการเปลี่ยน ประกอบไปด้วย

  • ความเร็วในการทำงานต่อ transaction เร็วขึ้นจาก 1-2 วินาที เหลือ 300 ms
  • การ deploy ง่ายขึ้น รวมถึงขนาดของ Docker Image ที่เล็กลง
  • ลดการใช้ memory ลงไป 50%
  • ลดค่าใช้จ่ายของ server ลง 50%

สิ่งที่น่าสนใจคือ ในส่วนของ Professional Development

ในทีมพัฒนานั้นไม่มีใครมีประสบการณ์ ในการพัฒนาและ deploy ระบบงานด้วยภาษา Go บน production เลย ดังนั้นในการเปลี่ยนแปลงครั้งนี้ มันเป็นโอกาสที่ดีสำหรับการเรียนรู้อย่างมาก เพื่อให้ได้รับบทเรียนต่าง ๆ จากงานจริง ๆ จากลูกค้าจริง ๆ No pain No gain เพื่อปรับปรุงสิ่งต่าง ๆ ให้ดีขึ้น รวมทั้งความสามารถของทีมอีกด้วย

สิ่งที่สำคัญมาก ๆ ของการใช้งานภาษา Go ประกอบไปด้วย

  • ​การจัดการเรื่อง memory leak และ garbage collection ซึ่งมี profiling tool มาให้ใช้งาน ดังนั้นใช้ซะ ให้คล่อง
  • ปัญหาในการจัดการข้อมูล JSON ขนาดใหญ่ ซึ่งพบว่า JSON package ของ Go ไม่สามารถแก้ปัญหาใน use case ของทีมได้ ซึ่งก็แก้ไขด้วยการเลือก data structure และการ process ข้อมูลที่จะส่งมานั่นเอง
↧
Search

สวัสดี Node 10

April 25, 2018, 4:35 am
$
0
0

Node 10 ออกมาแล้ว มี code name ว่า Dubnium มาดูกันว่ามี feature อะไรที่ใหม่ ๆ บ้าง ที่ช่วยทำให้ชีวิตของนักพัฒนาดีขึ้น
  • สนับสนุน HTTP 2 ซึ่งเปลี่ยนจาก experiment feature เป็น stable แล้ว
  • นำเอา ESM module (ECMAScript Module) มาใช้
  • เพิ่ม Error code เข้ามา จากเดิมที่มีแต่ error message
  • Fs promise เป็น experiment feature
  • ปรับปรุงเรื่องของ trace event การทำงาน ซึ่งสามารถเปิดปิดในขณะ runtime ได้
  • N-API สำหรับการเพิ่ม native addon ด้วยภาษา C ซึ่งปรับจาก experiment มาเป็น stable แล้วแต่ผมไม่เคยใช้
  • Chrome V8 version 6.6 เพิ่ม async generator และ ปรับปรุงประสิทธิภาพการทำงานของ Array
  • ปล่อยมาพร้อมกับ NPM 6.0 ซึ่งปรับปรุงเรื่อง performance การทำงานและเพิ่ม security เข้ามาเช่น npm audit
อ่านเพิ่มเติมได้ที่ Changelogs Node 10 มาใช้งานกัน สวัสดี [code] $node -v v10.0.0 $npm -v 6.0.0 [/code]
↧

Storybook 3.4 สนับสนุน Polymer แล้ว

April 26, 2018, 9:13 am
$
0
0

ช่วงนี้เครื่องมือใหม่ ๆ ออกมาเยอะเลย หนึ่งในนั้นคือ Storybook 3.4 ซึ่งเป็นเครื่องมือที่มีประโยชน์มาก ๆ สำหรับการพัฒนาและทดสอบ UI component ของ React, React Native, Vue และ Angular ล่าสุดก็สนับสนุน Polymer แล้ว ยังไม่พอนะ มีความสามารถอื่น ๆ ที่แจ่ม ๆ อีก เช่น
  • Storyshot image snapshot สำหรับ Component testing มันคือ Jest Snapshot Testing นั่นเอง เป็น add-on ใหม่ติดตั้งได้เลย
  • ปรับปรุง UI ด้วยการเพิ่ม Multiple story hierarchy เข้ามา
  • Storysource เป็น add-on ใหม่ สำหรับแสดง code ของแต่ละ component ได้
รออะไรอยู่ ไป Download และใช้งานกัน [code] $npm i -g @storybook/cli $cd your-project getstorybook npm run storybook [/code] Reference Websites https://medium.com/storybookjs/announcing-storybook-3-4-db4d1341dedd
↧
↧

ข้อผิดพลาดเมื่อนำ DevOps มาประยุกต์ใช้งาน

April 28, 2018, 11:14 pm
$
0
0

เรื่องที่ 1 Speed vs Quality แน่นอนว่าต้องเร็วมาก่อน !!

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

เรื่องที่ 2 มักจะแยก DevOps ไปอีกแผนกหรือกลุ่มใหม่ !!

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

เรื่องที่ 3 ต้องการเห็นผลอย่างรวดเร็ว !!

สิ่งที่ชอบตั้งคำถามมายังทีมพัฒนาและ operation คือ ทำอย่างไรที่จะส่งมอบหรือ release ระบบงานได้ X ครั้งต่อวันหรือสัปดาห์หรือเดือน นั่นคือ ต้องการขั้นตอนการทำงานที่สมบูรณ์ตั้งแต่ต้นยันจบเลย !! แต่เมื่อเข้าไปดูรายละเอียดกลับพบว่า ยิ่งองค์กรมีขนาดใหญ่เพียงใด ยิ่งมีขั้นตอนการทำงานที่ซับซ้อนมากขึ้นเท่านั้น ซึ่งเป็นการยากที่จะเขียนหรือสร้างกระบวนการทำงานขึ้นมาใหม่ !! ดังนั้นสิ่งที่องค์กรต้องเข้าใจและพิจารณาคือ การนำ DevOps เข้ามาใช้นั้น ต้องทำแบบค่อยเป็นค่อยไป เป็นขั้นตอนเป็น phase แน่นอนว่าในแต่ละขั้นตอนต้องมีการวัดผล เลือกสิ่งที่จะทำหรือปรับปรุงขึ้นมา 1 เรื่อง หาค่าที่จะใช้วัดตั้งแต่ก่อนทำ จากนั้นลงมือทำ และ วัดผลต่อไป ซึ่งจะทำให้เราเห็นได้อย่างชัดเจนว่า สิ่งที่ลงมือทำไปนั้นเป็นอย่างไร ต้องการการอบรมหรือเรียนอะไรบ้าง ต้องการคน ขั้นตอน และ เครื่องมืออะไรรบ้างที่เหมาะสม มันทำให้คนทำงานพูดคุยกันและทำงานร่วมกันมากขึ้น ตามแนวคิดของ DevOps เพื่อปรับปรุงการทำงานให้ดีขึ้น

เรื่องที่ 4 DevOps เอามาใช้แล้วต้องดีขึ้น !!

มันไม่ใช่ของวิเศษอะไรเลย จำเป็นต้องมีทีมที่ดีและเหมาะสม ทั้งแนวคิด มุมมอง ความสามารถ และการเรียนรู้ รวมทั้งต้องมีการจัดการหลายสิ่งอย่าง ทั้ง resource ทั้ง scope ทั้งเวลา ทั้งการ tracking process การทำงาน รวมไปถึงการแบ่ง project ใหญ่ ๆ ออกเป็น project เล็ก ๆ เพื่อให้ง่ายต่อการจัดการ และ ลดความเสี่ยงจากผลกระทบต่าง ๆ อีกทั้งเวลาที่วางแผนไว้ต้องเหมาะสม (คนทำมักจะไม่ได้วางแผนหรือไม่ ?) หัวใจหลัก ๆ ของ DevOps คือ รู้ปัญหาของตัวเอง แก้ไขทีละปัญหา วัดผล แก้ไขต่อ นั่นคือการเรียนรู้และปรับปรุงอย่างต่อเนื่อง

สุดท้ายการทดสอบอยู่ช่วงท้ายของขั้นตอนการพัฒนา !!

แนวคิดของ DevOps พยายามรวมเรื่องของ configuration management continuous integration/deployment/delivery automation testing เข้าไปในทิศทางเดียวกัน เพื่อเพิ่มประสิทธิภาพ ไม่ใช่ต่างฝ่ายต่างทำงานกันไป สิ่งหนึ่งที่พบได้บ่อย ๆ คือ การทดสอบมักอยู่ในช่วงท้ายของการพัฒนา ทั้ง functional testing ทั้ง non-functional testing เช่น performance/load testing และ security testing เนื่องจากเข้าใจกันว่า จะทดสอบได้นั้น ระบบงานต้องเสร็จแล้ว ต้องมีหน่วยงานหรือคนอื่น ๆ มาทดสอบ เนื่องจากทีมพัฒนาและทีมทดสอบไม่มีความรู้ และ เครื่องมือ ทำให้การทดสอบนั้นใช้เวลาและค่าใช้จ่ายสูงมาก ๆ ดังนั้นต้องเข้าใจตรงกันก่อนว่า การทดสอบต่าง ๆ เหล่านี้ต้องเกิดขึ้นอย่างต่อเนื่อง (Continuous testing) แน่นอนว่า จะทำได้การทดสอบต้องเป็นอัตโนมัติให้ได้มากที่สุด ถามว่าต้องมีเยอะเท่าไร ตอบได้เลยว่าต้องมากว่าเดิมอย่างต่อเนื่อง
จำไว้ว่า การทดสอบที่ดีนั้น ต้องไม่เพิ่มเวลาของการส่งมอบหรือ deploy ระบบงาน
สิ่งต่าง ๆ เหล่านี้ คือความผิดพลาดที่เกิดขึ้นจากการนำ DevOps มาใช้งาน ดังนั้นเราได้เรียนรู้อะไรบ้าง เพื่อจะได้ไม่ไปในทางที่ผิด ๆ อีกต่อไป
↧

แนะนำ Embedding Kotlin Playground

April 30, 2018, 12:40 am
$
0
0

อ่านเจอบทความเรื่อง Embedding Kotlin Playground จาก web ของ Kotlin ซึ่งทำให้เราสามารถนำ code ภาษา Kotlin ไปแปะและ run ผ่าน browser ได้ง่ายขึ้น เช่น
  • Blog
  • Forum ต่าง ๆ
  • Slide
ลองไปดูเพิ่มเติมได้ที่ Github :: Kotlin Playground ส่วน Wordpress ก็มี plugin ให้ใช้เช่นกันที่ Kotlin Playground Wordpress plugin แสดงการใช้งานดังตัวอย่าง [kotlin] fun main(args: Array) { print("Hello, Kotlin World!") } [/kotlin]
↧

เมื่อการทดสอบมันน่าเบื่อ ทำอย่างไรดี ?

May 1, 2018, 12:41 am
$
0
0

ในการทดสอบระบบงานนั้น บ่อยครั้งจะพบว่ามันน่าเบื่อ ทั้งการเขียน bug report ทั้งการต้องทดสอบ test case เดิม ๆ ซ้ำแล้วซ้ำอีกอยู่นั่นแหละ ไหนจะต้องปากเปียกปากแฉะ กลายเป็นคนปากจัด จู้จี้ไปโดยปริยาย (แก่ก่อนวัย) มันไม่มีความท้าทายอะไรเลย ทำงานไปวัน ๆ ซึ่งมันน่าเบื่อมาก ๆ
แต่บางคนก็บอกว่า เป็นแบบนี้มันดีแล้วนะ ทำ ๆ ไป ก็สบายแล้ว จะไปคิดอะไรมาก ดังนั้นก็ข้าม blog นี้ไปเลยนะครับ !!

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

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

ขั้นตอนที่ 1

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

ขั้นตอนที่ 2

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

ขั้นตอนที่ 3

ลองตั้งเป้าหมายหน่อยสิว่า ใน 1, 3, 6, 9, 12 เดือนนี้คุณต้องการจะประสบความสำเร็จอะไรบ้าง ? จากนั้นลองดูสิว่า ในแต่ละวันคุณได้ทำงานตามเป้าหมายนั้นหรือไม่ หรือเข้าใกล้เป้าหมายไปทุกวันหรือไม่ อย่าโกหกตัวเอง ว่าสิ่งที่ทำมันใกล้ถึงเป้าหมาย ทั้ง ๆ ที่มันไม่เป็นจริง

ขั้นตอนที่ 4

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

ขั้นตอนที่ 5

ฝึกเขียน ฝึกอธิบาย ฝึกเล่าประสบการณ์ต่าง ๆ ที่เราพบเจอ รวมทั้ง how-to ในการแก้ไขปัญหาต่าง ๆ จากนั้นทำการแบ่งปันให้คนอื่น ๆ ทั้งคนมนทีม บริษัทและนอกบริษัท อย่ากลัวที่จะแบ่งปัน ถึงแม้ว่าเรื่องนั้นมันจะดูธรรมดามาก ๆ สิ่งที่ควรตั้งเป้าคือ เราได้เรียนรู้อะไรบ้าง นั่นแกละดีแล้ว

ขั้นตอนที่ 6

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

ขั้นตอนที่ 7

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

ขั้นตอนที่ 8

ถ้าเบื่องานการทดสอบแบบ manual testing ลองคุยกับหัวหน้าดูว่า จะของานการทดสอบแบบอื่น ๆ มาทำได้ไหม ทั้ง security testing, performance testing และ automated testing เพื่อจะได้ลองและเรียนรู้สิ่งใหม่ ๆ ดูบ้าง

ขั้นตอนที่ 9

คำถามคือ ในปัจจุบันคุณเรียนรู้อะไรเพิ่มขึ้นบ้าง อ่านหนังสือเกี่ยวกับการทดสอบและการพัฒนา software บ้างไหม ? อ่านบทความอะไรเพิ่มบ้างในแต่ละวัน ? เข้าร่วมงาน conference/meetup อะไรบ้างไหม ? ถ้ายังไม่ทำเลย ลงมือเถอะนะ เริ่มจากตัวคุณเองก่อน

สุดท้ายแล้ว

ถ้าทำทุกอย่างที่ผ่านมาแล้ว ยังคิดว่างานที่ทำยังน่าเบื่ออยู่อีก ลองถามหัวหน้าเรื่องการเปลี่ยนงานหรือ project ทำดูบ้าง แต่ถ้าเปลี่ยนแล้วงานยังน่าเบื่อ บริษัทยังน่าเบื่อ น่าจะถึงเวลาที่ต้องเปลี่ยนบริษัทแล้วนะ !!
↧
Viewing all 1997 articles
Browse latest View live
Search