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

สิ่งที่นักพัฒนามือใหม่ชอบทำผิดพลาด

November 10, 2017, 7:41 pm
$
0
0

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

ไม่ถามและชอบคิดไปเอง

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

แก้ไขปัญหาใหญ่ ๆ ในครั้งเดียว

เมื่อได้งานไปทำ ไม่ว่าจะมีขนาดเล็กหรือใหญ่ ก็มักจะลงมือทำไปเรื่อย ๆ แก้ไขไปเรื่อย ๆ เขียน code ไปเรื่อย ๆ ก็ให้เกิด spaghetti code หรือ arrow function (ไม่ใช่ JavaScript นะ) บางครั้งก็แก้ไขปัญหาวนไปวนมา แก้ตรงนั้นพังตรงนี้ ดังนั้นก่อนจะลงมือทำอะไร ขอให้ทำการวางแผนก่อน แบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาเล็ก ๆ แบ่ง component ใหม่ ๆ ออกเป็น component เล็ก ๆ จากนั้นจึงลงมือแก้ไขปัญหา เขียน code ในแต่ละส่วน จะทำให้ผลที่ได้ดีกว่าเดิมอย่างมาก แต่ปัญหาที่เจอคือ ไม่ชอบถาม ไม่สามารถแบ่งปัญหาออกมาได้ (Work break down) ดังนั้นจำเป็นต้องฝึกครับ

ประเมินเวลาได้แย่มาก ๆ

ในข้อนี้คิดว่าเป็นทุกคน เนื่องจากการประเมินที่แย่มี 2 แบบหลัก ๆ คือ ประเมินมากเกินไป (Over estomation) ประเมินน้อยเกินไป (Under estimation)
ปัญหาของการประเมินเวลาในโลกของการพัฒนา software นั้น มีสิ่งที่เราไม่รู้เพียบ ทั้งเรื่องคน process เครื่องมือ และสิ่งแวดล้อมรอบข้าง
ยิ่งเป็นนักพัฒนามือใหม่ การประเมินเวลามันยิ่งยาก ถ้าไม่ถาม ถ้าไม่เข้าใจ ยิ่งโดนกดดันไปอีก ยิ่งทรมานมาก ๆ บ่อยครั้งมักจะมีหัวหน้าที่ไม่ค่อยเข้าใจ เมื่อนักพัฒนาประเมินเวลาไปมากกว่าที่หัวหน้าคิด ก็จะโดนต่อรองจากคนที่ไม่ได้ทำ คำถามในใจคือ จะให้ตรูประเมินทำโล่ห์อะไร ? ดังนั้นสิ่งแวดล้อมรอบข้างมันสำคัญมากเช่นกัน
ปล. เราทำการประเมินงานระยะยาวเป็นปี ๆ กันได้อย่างไร ? สิ่งเหล่านั้นมันคือการโกหกใช่ไหม ?

ไม่เขียนชุดการทดสอบเลย

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

ยังมีเรื่องอื่น ๆ อีกนะ ยกตัวอย่างเช่น

  • Over Engineer
  • ไม่ใช้ Version Control ที่ดี
  • ใช้ 3-party library/framework มากจนเกินไป
ขอให้สนุกกับการ coding นะครับ
↧
Search

สรุปเรื่องโครงสร้าง project ภาษา Go ที่ DigitalOcean

November 11, 2017, 3:10 am
$
0
0

ทีมพัฒนาของ Digitalocean นั้นได้ออกมาเล่าถึงประสบการณ์การพัฒนาระบบงานด้วยภาษา Go ซึ่งเป็นระบบงานภายในชื่อว่า Cthulhu โดยเป็นระบบงานที่ใช้งาน version control แบบ Monorepo นั่นคือ code ทุกสิ่งอย่างอยู่ใน repository เดียวกัน แม้ว่าจะมีมากกว่า 1 project ก็รวมกันอยู่ในนี้

แน่นอนว่า ต้องเจอปัญหาต่าง ๆ มากมาย

ทั้งเรื่องของโครงสร้าง ทั้งเรื่องการ scale ทั้งเรื่องของการจัดการ dependency ต่าง ๆ ทั้งเรื่องของเครื่องมือที่ใช้งาน ทั้งเครื่องของเวลาในการ build ของ CI server ทั้งเรื่อง code ownership
มาดูกันว่าทางทีม Digitalocean ทำอย่างไรบ้าง ? น่าสนใจมาก ๆ

สถิติต่าง ๆ ของ repository

28,639 commits 824 branches 142 contributors 830,434 lines of DigitalOcean-authored Go code 2,136,373 lines of vendored Go code โครงสร้างของ repository ของระบบเป็นดังรูป คำอธิบาย
  • GOPATH คือ cthulhu/decode
  • do จะเป็น prefix ของ code ทุก ๆ อย่าง ซึ่งเป็น internal code ทั้งหมด
  • โดยที่ folder ใน do/ ก็จะแยกตามหน้าที่การทำงานไป
  • doge ย่อมาจาก DigitalOcean Go Environment เก็บ standard library ซึ่งใช้งานจากทุก ๆ service เช่น logging, metric และ RPC เป็นต้น
  • exp หรือ Experiment code เป็น code สำหรับการทดลองเรื่องต่าง ๆ
  • services แยกตาม service ของ DigitalOcean แต่ทำให้เกิดปัญหาว่าทีมไหนดูแล ดังนั้นจึงเปลี่ยนไปใช้ folder teams แทน
  • teams ทำการเก็บแต่ละงานแต่ละ service ของทีมไปเลย แต่ก็ยังมีปัญหาคือ แต่ละทีมไม่ sync กัน ทำให้โครงสร้างภายในแต่ละงานแตกต่างกัน
  • tools ทำการเก็บเครื่องมือต่าง ๆ ที่ใช้แบบเฉพาะงานไปเช่น CI/CD tool, static code analysis เป็นต้น
  • vendor สำหรับ 3-party library ที่ใช้ข้ามทีมหรือ service/project ซึ่งในโครงสร้างของ project แบบนี้ Go Vendor ไม่สนับสนุนนะ เพราะว่าทำได้เพียง vendor ที่ root project เท่านั้น แต่สิ่งที่ต้องการคือใน sub folder ดังนั้นจึงต้องทำเองใช้เอง
  • scripts เก็บ shell script ต่าง ๆ ที่ใช้งานใน CI/CD server หรือในกระบวนการ build เช่น compile, static analysis, testing และสร้าง binary สำหรับ deploy เป็นต้น

CI build tool

ข้อดีของ monorepo คือ code ทั้งหมดอยู่ที่เดียวกัน ดังนั้นไม่ต้องกลัวเลยว่า code จะไม่ update ไม่ต้องกลัวเลยว่า dependency จะไม่ update แต่ผลที่ตามมาคือ เวลาในการ build มันสูงมาก ๆ โดยในปี 2016 นั้นที่ DigitalOcean ใช้เวลาในการ build ถึง 20 นาที !! ส่งผลให้การพัฒนาช้าเป็นอย่างมาก ปัญหาจึงตามมาเพียบ ความเจ็บปวดเยอะสุด ๆ ดังนั้นจึงทำการสร้างเครื่องมือมาใช้งานเองชื่อว่า gta (Go Test Auto) ก่อนเริ่มการ build จะตรวจสอบ code ก่อนว่ามีการเปลี่ยนแปลงอะไร กระทบส่วนไหนบ้าง จากนั้นทำการ build และ test ในส่วนที่เกี่ยวข้องเท่านั้น ซึ่งลดเวลาไปอย่างมาก จาก 20 นาทีลงมาเหลือประมาณ 2-3 นาทีเท่านั้นเอง

Static Analysis Tool

ในทุก ๆ commit นั้นจะทำการตรวจสอบ code ก่อนเสมอ ด้วย gofmt, go vet , go lint และอื่น ๆ อีกมากมาย เพื่อทำให้มั่นใจในคุณภาพของ code และในบางทีมก็มีเครื่องมือเฉพาะหรือสร้างขึ้นมาใช้เช่น staticcheck และ buildlint เป็นต้น รวมทั้งยังใช้ godoc ในการสร้าง document ของทุก ๆ package ด้วยนะ

จากคำอธิบายที่ผ่านมาจะพบว่า

ปัญหาจะเปลี่ยนไปเรื่อย ๆ ดังนั้นโครงสร้างและเครื่องมือต่าง ๆ ที่ใช้งานใน project ก็จะเปลี่ยนไปเรื่อย ๆ เช่นกัน นั่นคือ ความท้าทายที่ทีมต้องพบเจอและก้าวผ่านไปให้ได้ สิ่งที่ดีวันนี้อาจจะไม่ดีในวันหน้า แต่ถ้าเวลานั้นมาถึงก็ต้องพร้อมที่จะรับมือด้วยเช่นกัน ยกตัวอย่างเช่นการทดสอบของระบบ ซึ่งเดี๋ยวทดสอบผ่านบ้างไม่ผ่านบ้าง ยิ่งต้องทำงานร่วมกับระบบอื่น ๆ เช่น Database, Webservice เป็นต้น ยิ่งก่อให้เกิดปัญหามากมาย ซึ่งตรงนี้ทางทีมพัฒนาจะแก้ไขปัญหาต่าง ๆ ที่คิดว่าดี และส่งผลให้การทดสอบมันเสถียรและน่าเชื่อถือเพิ่มขึ้น แน่นอนว่า ความไว้เนื้อเชื่อใจต่อทีมนั้นสูงมาก มันคือวัฒนาธรรมของทีมและองค์กรนั่นเอง Reference Websites https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/ https://blog.gopheracademy.com/advent-2015/go-in-a-monorepo/ https://speakerdeck.com/farslan/go-at-digitalocean
↧
↧

รูปแบบของ code แย่ ๆ ที่มักพบเจอ

November 11, 2017, 10:33 pm
$
0
0

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

Global state/variable

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

Code duplication

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

ไม่สนใจหรือใส่ใจเรื่องการจัดการ deplendency ต่าง ๆ

บ่อยครั้งพบว่า นักพัฒนาจะเขียน code ไปเรื่อย ๆ ยกตัวอย่างเช่น ถ้าเรื่องที่ 1 สำเร็จจะทำเรื่องที่ 2 ถ้าเรื่องที่ 2 สำเร็จจะทำเรื่องที่ 3 ถ้าเรื่องที่ 3 สำเร็จจะทำเรื่องที่ 4 code ที่ออกมาต้องเป็น if ซ้อน if ซ้อน if ไปเรื่อย ๆ แน่นอน ก็ให้เกิด code แต่ละส่วนผูกมัดกันอย่างแรง บางครั้งเราจะเรียก code เหล่านี้ว่า Spaghetti code
จะอ่านและเข้าใจก็เหนื่อย จะทดสอบก็ยาก จะแก้ไขก็ลำบาก ไม่มีใครอยากไปยุ่งกับมัน
ดังนั้นแนะนำให้แยกแต่ละส่วนการทำงานหรือแต่ละเรื่องออกจากกัน นั่นคือการ dependency ต่าง ๆ ออกจากกัน ทดสอบแยกกันไป จากนั้นจึงสร้างส่วนที่รวบรวมส่วนต่าง ๆ เข้าด้วยกัน ถ้ามีการเปลี่ยนแปลง แนะนำให้สร้างส่วนที่รวบรวมใหม่ มันคือ business/service layer นะครับ ซึ่งมันไม่สามารถ reuse ได้เลย การมานั่งแก้ไขไม่สนุกนะ แนะนำให้ศึกษาเรื่อง SOLID principle เพิ่มนะ

Code มันอ่านยาก

ไม่ใช่บอกว่า การตั้งชื่อไม่ดีนะ แต่กำลังบอกว่า code มันอ่านยาก เช่นเขียน code เพียงบรรทัดเดียว แต่เข้าใจยากมาก หรือบางครั้งการตั้งชื่อดีมาก แต่ logic การทำงานยากและซับซ้อน หรือทำการเข้ารหัสทาง logic ไว้ !! บ่อยครั้งมักจะมี abstraction layer ของ code ที่ผิด ดังนั้นสิ่งที่ควรทำและฝึกคือ การทำ pair programming และ code review กับคนอื่น ๆ ในทีม

ไม่กล้าแก้ไข code เพราะว่าไม่รู้ว่า จะกระทบอะไรบ้าง !!

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

สุดท้ายแล้ว

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

เก็บมาเล่าเกี่ยวกับ Programming

November 12, 2017, 7:04 am
$
0
0

วันนี้มี Post ที่น่าสนใจในกลุ่มสมาคมโปรแกรมเมอร์ไทย
สมมติถ้าออกโจทย์แบบนี้ให้นักเรียนทำ มันจะยากไปไหมครับ :) หาว่าบั๊กอยู่ตรงไหน
ความน่าสนใจของ post นี้มันเกี่ยวกับ programming นี่แหละ ทำให้นึกถึงสมัยเขียน code ใหม่ ๆ เลย เลยสรุปความคิดเห็นกับสิ่งที่ผ่านมาไว้นิดหน่อย

ถ้าถามว่าโจทย์นี้ยากไหม ?

สิ่งที่ต้องรู้ก่อนคือ ต้องการวัดอะไรจากโจทย์นี้ เพราะว่าโจทย์ลักษณะนี้มีเป้าหมายเพื่อ วัดความละเอียดในเรื่องของ syntax และ sematic ของ code วัด logic ของผู้เรียน จากตัวอย่างมัน compile ผ่านแต่ทำงานแล้วมี bug อาจจะเกิด RuntimeException ได้มั้ง!! จำได้ว่าสมัยทำงานแรก ๆ บ้าไปสอบ certified ด้าน Java กับเขามา (ไม่เกี่ยวกับ post นะ) ผ่านทั้ง SCJA, SCJP, SCJS, SCWCD, SCBCD, SCEA (สมัยยังเป็น SUN แบบว่าแก่มาก ๆ) ในส่วนที่เกี่ยวกับ programming คือ SCJA, SCJP จะเน้นในเรื่องของ syntax สุด ๆ สับขาหลอกกันจนหัวหมุน คือ ให้ code ตัวอย่างมา แล้วถามว่าผลการทำงานเป็นอย่างไร มีตัวเลือกให้ครบตามที่คิดเลย ทั้งผิดและถูกมีครบหมด ตั้งแต่ compile error, runtime error และ ผลการทำงานต่าง ๆ ดังนั้นผู้สอบต้องเข้าใจในรูปแบบของภาษาพอสมควร แถมละเอียดด้วย ยังมีเรื่อง inheritance และ polymorphism อีก หลอกมากมาย ปล. คนไม่ได้เขียนภาษา Java ยังสอบผ่าน ถ้าเข้าใจ !!

สิ่งที่อธิบายมาก็เพื่อจะบอกว่า

พื้นฐานของภาษามันสำคัญมาก ๆ อย่าพึ่งแต่ IDE ให้ตรวจสอบให้ พิมพ์จุดมันก็แนะนำให้ !! Control + Space bar มันก็แนะนำให้ !! บอกเลยว่ามันง่ายมาก ๆ แต่จะดีกว่าไหม ถ้าคุณเข้าใจและใช้งานได้โดยใช้เครื่องมือเหล่านี้ช่วยให้เร็วขึ้น ไม่ใช่มาพิมพ์จุดแล้วนั่งดูว่าจะทำอะไรต่อดี แบบนี้ไม่น่าใช่ !!

สำหรับผู้เริ่มต้น

ผมแนะนำให้ลองเริ่มจาก Editor ธรรมดาที่ไม่มีอะไรช่วยเลย อดทนนิดหน่อย แต่สิ่งที่ได้กลับมามันคุ้มค่ามาก ๆ เพราะว่า ผมก็ถูกฝึกถูกสอนมาแบบนี้เช่นกัน ยกตัวอย่างเช่นภาษา Java คุณเคย compile เองไหมผ่าน command line ? คุณเคน run เองไหมผ่าน command line ? ถ้าไม่ก็ลองซะนะ สิ่งที่น่าตกใจมาก ๆ คือ ให้ไปเขียน code ใน Editor ทั่วไปที่ไม่มีอะไรช่วย กลับทำอะไรไม่ได้เลย อันนี้ก็น่ากลัว เพราะว่าถ้าไม่มีเครื่องมือช่วยเหลือแล้วไปไม่เป็น แบบนี้น่าจะต้องปรับปรุง

ถามว่ามันน่าเบื่อไหมกับโจทย์แบบนี้ ?

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

เน้นย้ำว่าพื้นฐานมันสำคัญมาก ๆ

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

สุดท้ายถ้าแนวคิดหรือ Logic ได้แล้ว

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

ว่าง ๆ มาแกะ build.gradle ใน code ตัวอย่างของ Google Sample

November 12, 2017, 8:59 pm
$
0
0

นั่งดูตัวอย่าง code ตัวอย่างของ Android Architecture Component พบสิ่งที่น่าสนใจมากมาย หนึ่งในนั้นคือ การจัดการไฟล์ build.gradle (Gradle) หรือไฟล์ configuration ของระบบงานนั่นเอง มาดูกันว่ามีอะไรที่น่าสนใจบ้าง

เริ่มด้วย deps คืออะไร version ของ library/dependency มันหายไปไหน ?

ชื่อ library มันดูแปลก ๆ ไม่เหมือนที่เคยเห็นมา มาดูตัวอย่างกัน [gist id="b798e30da2eab03490e1488318295d13" file="1.txt"] เมื่อไล่ดู configuration พบว่า มีการเขียนเพิ่มเติมในไฟล์ gradle เพิ่มดังนี้ [gist id="b798e30da2eab03490e1488318295d13" file="2.txt"] วิธีการช่วยทำให้อ่าน library ได้ง่ายขึ้นกว่าเดิมนะ แต่ก็เพิ่มความซับซ้อนขึ้น โดยปกติที่พบมาก ๆ จะทำการประกาศ library และใส่ comment ไปดังนี้ !! [gist id="b798e30da2eab03490e1488318295d13" file="3.txt"]

ลองคิดเพิ่มเติม ถ้าเรากำหนด library แบบนี้จะง่ายกว่าไหม ?

[gist id="b798e30da2eab03490e1488318295d13" file="4.txt"] จากนั้นลองไปค้นหาข้อมูลเพิ่มเติม ก็เจอบทความที่อธิบายเพิ่มเติมเรื่อง Experimenting with Gradle dependencies ซึ่งตรงกับที่ต้องการ โดยใช้งานความสามารถของ Dependency Handler ใน Gradle แน่นอนว่า ความซับซ้อนเพิ่มขึ้น แต่สิ่งที่ได้กลับมาคือ ใช้งานง่ายขึ้นมาก ๆ ที่สำคัญ อ่านง่ายสุด ๆ !! [gist id="b798e30da2eab03490e1488318295d13" file="dependencies.gradle"] ตัวอย่างการใช้งานดูเพิ่มเติมที่ github::up1:sample

ว่าด้วยเรื่องของ Code Coverage Report

โดยปกติแล้วนั้น Android project จะทำการสร้าง Code Coverage Report ให้เฉพาะ UI Testing เท่านั้น ส่วนพวก Unit Testing จะไม่จัดทำและจัดเก็บให้ ดังนั้นถ้าต้องการใช้งาน ต้องทำการเปิดให้เก็บค่า code coverage ก่อนนะ รวมทั้งต้องทำการสร้าง Gradle task ใหม่ชื่อว่า fullCoverageReport ขึ้นมา เพื่อทำการรวมค่า code coverage จาก UI และ Unit testing นั่นเอง ปล. ทำไมไม่ทำแบบ build-in มาให้เลยนะ [gist id="b798e30da2eab03490e1488318295d13" file="build_coverage.gradle"]

สิ่งที่น่าสนใจอีกสำหรับการทดสอบคือ ถ้าต้องการ share code ระหว่าง test และ androidTest

ให้ทำการ custom นิดหน่อย ดังนี้ [gist id="b798e30da2eab03490e1488318295d13" file="5.txt"]

สุดท้ายถ้าใครศึกษา Android Architecture จาก GoogleSample

จะเจอเรื่องของการแยกการทดสอบด้วย flavor ทำให้การทดสอบง่ายขึ้น แต่ก็มีความซับซ้อนและ code เยอะขึ้นด้วยเช่นกัน เป็นอีกหนึ่งแนวคิดที่น่าสนใจ ตัวอย่างจาก TODO app น่าจะพอมีประโยชน์สำหรับ Android developer บ้างนะ  
↧
↧

บันทึกการใช้งาน Firefox 57 (Quantum) 2 วัน

November 17, 2017, 1:58 am
$
0
0

หลังจากที่ Firefox 57 ถูกปล่อยออกมา ซึ่งบอกว่า เร็วกว่าเดิม ใช้ resource น้อยกว่าเดิม แจ่มกว่าเดิม เนื่องจากยกเครื่องใหม่หมดจาก Quantum หรือ Servo ซึ่งพัฒนาด้วยภาษา Rust และใช้ rust-bindgen สำหรับสร้าง C++ binding เพื่อให้สามารถทำกับ Firefox ที่พัฒนาด้วยภาษา C++ นั่นเอง ยกเครื่อง UX/UI ชื่อว่า Photon มีความปลอดภัยมากขึ้นด้วย Private Browser Mode โบกมือลากับ Firebug แล้ว เนื่องจากใส่เข้ามาให้เลย ระบบการค้นหาโดย default จะเป็น Google พร้อมกับความสามารถต่าง ๆ มากมาย ดังนั้นมาดูกันว่ามีอะไรที่น่าใช้งานกันบ้าง ?

ใน Quantum นั้นมี project ย่อย ๆ เพียบนะ เช่น

  • Quantum CSS หรือ Stylo
  • Quantum Render สำหรับการ render
  • Quantum Compositor
  • Quantum DOM
  • Quantum Flow

1. Pocket integration มาให้เลย

สำหรับใครที่ชอบ bookmark ก็สบายเลย ไม่แปลกใจเท่าไร เนื่องจาก Firefox ได้ซื้อ Pocket มาสักพักละ

2. Take screenshot ได้แบบง่าย ๆ

ถ้าสังเกตุเพิ่มเติมตรง Address bar นั้นมี Page Action Button เพียบเลย ทั้งการ bookmark, copy link, Email link และ Send to device จากนั้นเลือกตำแหน่งที่ต้องการ รูปจะถูกเก็บไว้ที่ https://screenshots.firefox.com/shots มีอายุ 14 วันหลังจากบันทึก

3. แต่ละ Tab และ Extionsion ใน Firefox นั้นจะแยก process กันนะ เหมือน Google Chrome เลย

เมื่อทำการลบ process ไปแล้วใน browser จะแสดงผลดังนี้

4. เรื่องของ Inspector ใน web ต่าง ๆ มันง่ายมาก ๆ

มีลูกเล่นต่าง ๆ มากมายก่ายกอง ไปลองใช้กันดู มันเยอะ ๆ มาก สำหรับ Web Developer Tool

5. เข้าสู่ Private Browser Mode กัน สีม่วงมาก ๆ

6. เมื่อ Network มีปัญหา ก็แสดงหน้าน่ารักเลย

แต่ไม่มีเกมส์ให้เล่นกันนะ !!

7. ลองใช้งานใน Device ต่าง ๆ ด้วย account เดียวกันดูนะครับ

ต้องลองหน่อยแล้ว

ยังมีของเล่นสนุก ๆ เพิ่มเติมที่ Firefox Test Pilot อีก

เช่น Notes และ Snooze Tabs เป็นต้น

สำหรับ web พวก facebook และ youtube ยังหน่วง ๆ แบบห่วง ๆ ไงไม่รู้

ไม่แน่ใจเป็นที่ web เองหรือ Firefox กันแน่ เลยไม่แน่ใจว่า ที่บอกว่า Firefox 57 มันเร็วกว่า Google Chrome นั้นเป็นอย่างไรกันแน่ ?

ลองมาทางฝั่ง Automated Testing กันด้วย Selenium กันหน่อย

ซึ่งปกติผมจะใช้งาน Robotframework แน่นอนว่าต้องทำการ update Geckko driver ใช้ได้เลย แสดงตรง Address bar ให้ด้วยว่าถูกทดสอบด้วย Robotframework
ลองใช้งานดูครับ คิดว่า release ต่อ ๆ ไปน่าจะดีขึ้นกว่านี้อีก นี่เป็นเพียงการเริ่มต้นของ Firefox ใหม่เท่านั้น
Reference Websites https://blog.mozilla.org/blog/2017/11/14/introducing-firefox-quantum/ https://blog.mozilla.org/blog/2017/09/26/firefox-quantum-beta-developer-edition/
↧

สรุปการทำ profiling ระบบ Web application ที่พัฒนาด้วยภาษา Golang

November 17, 2017, 8:33 am
$
0
0

เนื่องจากต้องมาดู performace ของระบบ web application ที่พัฒนาด้วยภาษา Golang นิดหน่อย จึงทำการสรุปสิ่งที่ต้องใช้งานไว้นิดหน่อย เครื่องมือที่ใช้งานคือ pprof ประกอบไปด้วย
  • CPU profile
  • Heap profile
  • Goroutine profile
ใช้งาน pprof version ใหม่ด้วยนะ ทำการติดตั้งด้วยคำสั่ง [code] go get github.com/google/pprof [/code]

จัดเตรียม code ของระบบกันนิดหน่อย

ซึ่งจะใช้งาน package net/http/pprof และทำการ custom URL ของ pprof เพิ่มเติมนิดหน่อย เพื่อไว้ใช้งาน เขียน code ง่าย ๆ ได้ดังนี้ [gist id="01fa258358250ea1c0159e296d70ead1" file="main.go"] จากนั้นทำการ build จะได้ไฟล์ binary ของระบบหรือ service มา จากตัวอย่างชื่อว่า demo ดังนั้นทำการ run demo ขึ้นมา (นั่นคือการ start server ของระบบหรือ service)

เมื่อทุกอย่างพร้อม มาเริ่มต้นกันเลย

ให้ทำการยิง load test ไปยัง endpoint ของ service ที่เราต้องการ สามารถใช้เครื่องมือง่าย ๆ เช่น Apache Wekrbench และ wrk เป็นต้น ยกตัวอย่างเช่น [code] $ab -k -c 10 -n 1000000 "http://127.0.0.1:8080/" [/code] ในระหว่างนั้นทำการ run pprof เลย ดูการใช้งาน CPU ด้วยคำสั่ง [code] $pprof demo http://127.0.0.1:8080/debug/pprof/profile [/code] จะใช้เวลาการทำงานนานนิดหน่อย เนื่องจากจะจัดเก็บข้อมูลจากการทดสอบ service นั่นเอง ที่สำคัญ เราสามารถใช้ pprof บน production environment ได้เลย เนื่องจากมี overhead น้อยมาก ๆ เมื่อเข้ามาใช้งานแล้ว ดู method ที่ใช้งาน CPU มาก ๆ ด้วยคำสั่ง top [gist id="01fa258358250ea1c0159e296d70ead1" file="1.txt"] หรือถ้าต้องการดูเป็นรูปสวย ๆ ก็ใช้คำสั่ง web ผลที่ได้มาคือ ไฟล์ SVG ดังรูป

แต่ถ้าต้องการดูผ่าน web แบบ interactive ก็ทำได้

ด้วยคำสั่งดังนี้ [code] $pprof -http=:8888 ชื่อ profile [/code] ได้ผลดังนี้ สามารถดูข้อมูลในรูปแบบต่าง ๆ ได้เลย ทั้ง top, graph, peak และ detail ยังไม่พอนะ สามารถค้นหาข้อมูลได้อีก แสดงดังรูป
ผลลัพธ์ที่ได้จากการทำ profiling นั้น ช่วยทำให้เราเห็นว่าปัญหาอยู่ส่วนไหน จากนั้นก็ลงมือแก้ไขได้ง่ายขึ้น
สามารถดูส่วนอื่น ๆ ได้อีกเช่น [code] $pprof demo http://127.0.0.1:8080/debug/pprof/heap $pprof demo http://127.0.0.1:8080/debug/pprof/goroutine $pprof demo http://127.0.0.1:8080/debug/pprof/block [/code] และยังมีวิธีการอื่น ๆ อีก เช่น Benchmark และ Escape analysis เป็นต้น ขอให้สนุกกับการ coding ครับ
↧

มาปรับปรุงการเขียน Test กันหน่อย

November 18, 2017, 4:30 am
$
0
0

การเขียน Test หรือชุดการทดสอบนั้นเป็นสิ่งที่ดี เริ่มเขียนว่ายากแล้ว การเขียนให้ดียากยิ่งกว่า ดังนั้นจึงสรุปวิธีปรับปรุงการเขียน Test ให้ดีขึ้น โดยนำมาจากบทความเรื่อง Write Better Tests in 5 Steps เริ่มกันเลย

Code ของ Test นั้นต้องดูแลให้เหมือนกับ Production code

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

วางโครงสร้างของ Test code ให้ดี

ในแต่ละ test case ควรมีโครงสร้างเดียวกัน หรือ ไปในทางเดียวกัน เพื่อช่วยทำให้ Test อ่านและทำความเข้าใจได้ง่ายขึ้น สิ่งชอบใช้คือ AAA (Arrange-Act-Assert)
  • Arrange เป็นการเตรียมสิ่งต่าง ๆ ก่อนการทดสอบ เช่นข้อมูลเริ่มต้นของการทดสอบ
  • Act เป็นการสร้าง action หรือเรียกใช้งานส่วนที่ต้องการทดสอบ
  • Assert ทำการตรวจสอบผลจากการทดสอบ ว่าเป็นไปตามที่คาดหวังหรือไม่
ยังมีโครงสร้างอื่น ๆ อีก เช่น Give-When-Then เป็นต้น

ดูแล Test ให้มีสุขภาพที่ดี ระวัง Test ที่ไม่เสถียร !!

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

เลือกระดับหรือชนิดการ Test ให้ถูกต้องและเหมาะสม

การ Test นั้นมีหลายระดับหลายชนิด แต่ละชนิดล้วนมีค่าใช้จ่ายด้วยกันทั้งสิ้น ทั้งการเขียน ทั้งเวลาในการทดสอบ ยกตัวอย่างเช่น ถ้าทำการทดสอบ UI Test เพียงอย่างเดียว เมื่อชุดการทดสอบเยอะขึ้น ต้องใช้เวลาในการทดสอบมากขึ้น ค่าใช้จ่ายเพื่อทำให้เร็วขึ้นก็สูงมาก ๆ ดังนั้นควรต้อง Test ในส่วนอื่น ๆ ด้วย เช่น Unit test และ Service test มากขึ้น แต่ถ้ายังไม่รู้ ก็จัดเต็มทุกส่วนเลย เพื่อทำให้รู้และเข้าใจว่า อะไรควรหรือไม่ควรทำ !!

ต้องเรียนรู้เทคนิคต่าง ๆ ในการ Test เพิ่มเติม

ยกตัวอย่างเช่นการ Mock หรือ Test Double เพื่อช่วยลดค่าใช้จ่ายหรือเวลาในการ Test ลงไป แต่ก็ต้องแลกมาด้วยการออกแบบระบบงานด้วย นั่นคือระบบจะต้องสามารถทดสอบได้ง่าย (Testable Architecture) ยกตัวอย่าง การจำลอง Database การจำลอง REST API server การใช้งาน Stub/Spy/Mock สำหรับการตัด dependency ต่าง ๆ ออกไปจาก code การจำลอง Environment สำหรับการทดสอบขึ้นมา เป้าหมายเพื่อ Fast feedback คือรูปผลการเปลี่ยนแปลงได้อย่างรวดเร็ว นั่นคือการลดค่าใช้จ่ายนั่นเอง
ลองแบ่งเวลามาเขียนและปรับปรุง Test กันเถอะ เพื่อสร้างระบบงานดีให้ผู้ใช้งานและลูกค้า รวมทั้งช่วยให้ทีมมีความเชื่อมั่นเมื่อทำการแก้ไขและดูแลระบบ รวมทั้งรู้ปัญหาได้อย่างรวดเร็ว
Reference Websites http://fabiopereira.me/blog/2012/03/18/introducing-depth-of-test-dot/ https://martinfowler.com/articles/nonDeterminism.html http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html https://www.thoughtworks.com/insights/blog/just-re-run-build-it-should-go-green http://xunitpatterns.com/Fragile%20Test.html
↧
Search

การเริ่มต้นใช้งาน Docker สำหรับการพัฒนาระบบ Frontend ด้วย Vue.js

November 19, 2017, 8:39 pm
$
0
0

เมื่อวานทำการแบ่งปันความรู้เรื่องการใช้งาน Docker สำหรับการพัฒนา web application ด้วย Vue.js นิดหน่อย โดยแบ่งขั้นตอนการนำ Docker มาใช้งานดังนี้ 1. สรุปขั้นตอนการพัฒนา 2. สรุปเครื่องมือต่าง ๆ ที่ใช้ในการพัฒนา 3. ลงมือทำ เพื่อให้เห็นผล 4. เริ่มนำ Docker เข้ามาใช้งานหรือมาช่วย 5. รออะไรลงมือกันเลย

เริ่มต้นด้วยสรุปขั้นตอนการพัฒนาด้วย Vue.js

ซึ่งผมก็ไม่รู้หรอกว่าทำอย่างไร !! เลยให้ทำการสรุปมา รวมทั้งเครื่องมือที่ใช้งานด้วย มีดังนี้ 1. สร้างระบบงานด้วย Vue CLI 2. ทำการติดตั้ง dependency/library ด้วยคำสั่ง npm install 3. ทำการทดสอบบนเครื่องของ developer แต่ละคนด้วยคำสั่ง npm run dev 4. ทำการ build เพื่อแปลงเป็น HTML/JS/CSS สำหรับการ deploy บน production ด้วยคำสั่ง npm run build จะทำการสร้างใน directory ชื่อว่า dist มาให้ จากนั้นลงมือทำซะ สามารถสรุปขั้นตอนของการพัฒนาได้ดังนี้ [code] $vue init webpack hello $cd hello $npm install $npm run build [/code]

ต่อมาต้องคิดก่อนว่า จะนำ Docker มาใช้เพื่ออะไรบ้าง ?

สิ่งที่แนะนำไปมี 2 เรื่องคือ 1. สำหรับการพัฒนาของ developer ทุกคนในทีม 2. สำหรับการ deploy ระบบงาน สำหรับการพัฒนาของ developer ทุกคนในทีม เป้าหมายเพื่อแก้ไขปัญหาเรื่อง version ของเครื่องมือและ library ที่ใช้งาน ดังนั้นทุกคนในทีมควรใช้สิ่งเดียวกัน นั่นคือ เราจะทำการสร้าง Docker image เพื่อให้ developer ทุกคนใช้งาน ประกอบไปด้วย
  • npm install
  • npm run dev
  • npm run build
ดังนั้นสร้าง Dockerfile เพื่อเอาไว้ใช้แบบขำ ๆ ดังนี้ [gist id="73e1fa2624781aa72c57927a86b4f330" file="Dockerfile_develop"] คำอธิบาย
  • สิ่งสำคัญมาก ๆ คือการเลือก Based image ซึ่งเลือกใช้ NodeJS นั่นเอง
  • ต้องกำหนด tag หรือ version ของ Docker image ด้วยเสมอ อย่าใช้ latest นะ
  • ทำการกำหนด Working directory
  • ทำการกำหนด Entry point default ให้เป็น npm
  • ทำการกำหนดคำสั่ง default ให้เป็น install
ดังนั้นถ้าสร้าง container จาก image นี้จะทำการ npm install ให้ทันที แต่ถ้าต้องการ run คำสั่งอื่น ๆ เพียงใส่ run dev และ run build ไป ดังนี้ [code] $docker container run --rm -v $(pwd):/somkiat/src -t web:0.1 $docker container run --rm -v $(pwd):/somkiat/src -t web:0.1 run dev $docker container run --rm -v $(pwd):/somkiat/src -t web:0.1 run build [/code]

สำหรับการ deploy ระบบงาน

ซึ่งแน่นอนว่าต้องมีกระบวนการคล้าย ๆ กับการพัฒนามาก่อน แต่เพิ่มอีกขั้นตอนคือ การ deploy ไฟล์ต่าง ๆ จาก directory dist ไปยัง server ดังนั้น เพื่อความง่ายก็เลยเลือกใช้ nginx เป็น Web server และสามารถเขียน Dockerfile สำหรับการ deploy ได้แบบนี้ ใช้ความสามารถ Multi-stage build [gist id="73e1fa2624781aa72c57927a86b4f330" file="Dockerfile_deploy"] เพียงเท่านี้ก็จะได้ Docker image สำหรับการ deploy แล้ว นำไปใส่ในขั้นตอนของระบบ CI/CD ต่อไปได้เลย

ดังนั้นก่อนจะนำเครื่องมือใด ๆ มาใช้งานนั้น

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

วันนี้ใช้ Git Standup กันหรือยัง ?

November 21, 2017, 6:40 am
$
0
0

เมื่อเช้าอ่านเจอบทความเรื่อง Git for Daily Standup โดยนักพัฒนาหลาย ๆ คนอาจจะต้องมีประชุมที่เรียกว่า Standup meeting หรือ Daily Standup เพื่อทำการพูดคุย บอกความคืบหน้า และ ปัญหาที่เกิดขึ้น เช่น เมื่อวานทำอะไร เพื่อทำให้เป้าหมายสำเร็จ วันที่ทำอะไร เพื่อทำให้เป้าหมายสำเร็จ ติดปัญหาอะไร ที่จะทำให้เป้าหมายไม่สำเร็จ ปัญหาหลัก ๆ ของนักพัฒนาคือ ขี้ลืม หรือ ความจำสั้น จำไม่ได้ว่า เมื่อวานทำอะไรไปบ้าง ดังนั้นจึงขอแนะนำ git standup หรือถ้าอยากทำเอง ก็เพิ่ม alias ในไฟล์ .gitconfig เองซะ เช่น ขอให้สนุกกับการ coding ครับ
↧

สวัสดีกับ Jaeger ระบบ Distributed Tracing จาก Uber

November 24, 2017, 7:11 pm
$
0
0

หลังจากใช้งาน Zipkin มาสักพัก ก็มีเจอสิ่งที่คล้าย ๆ กันและน่าสนใจมาก ๆ คือ Jaeger จาก Uber โดยมีแรงบันดาลใจมาจาก Dapper และ OpenZipkin เป้าหมายหลักของเครื่องมือตัวนี้ คือทำการ tracing การทำงานต่าง ๆ ของระบบงาน ไม่ว่าจะอยู่ในรูปแบบไหนก็ตาม แน่นอนว่าทุก ๆ ระบบน่าจะมีหรือคิดหรือทำไว้บ้าง เพื่อทำการ monitoring การทำงานของระบบ เพื่อช่วยวิเคราห์เรื่อง dependency ต่าง ๆ ของระบบ เพื่อช่วยหา root cause ของปัญหาต่าง ๆ เพื่อช่วยดู performance การทำงานของส่วนต่าง ๆ ของระบบ

โดยที่ Jaeger ก็มีเป้าหมายเช่นเดียวกัน

แต่เขียนว่าสร้างมาเพื่อ Microservice เลยนะ พร้อมกับรูปแบบก็เข้ากันกับ OpenTracing นั่นหมายความว่าจะไปใช้พวก ZipKin ก็เปลี่ยนได้สบาย ๆ แถมมี Client library หลายตัวเลย เช่น Go, Java, NodeJS, Python และ C++ ดังนั้นคิดว่าทุกอย่างน่าจะพร้อม

ส่วนโครงสร้างของ Jaeger เป็นดังนี้

  • Frontend พัฒนาด้วย React
  • Backend พัฒนาด้วยภาษา Go
  • ในส่วนของที่จัดเก็บข้อมูลประกอบไปด้วย Cassandra และ Elasticsearch
  • มี Spark สำหรับ aggregation ข้อมูลจากหลาย ๆ ที่ด้วย

สิ่งที่ควรรู้ไว้บ้าง เพื่อทำให้เข้าใจมากขึ้น

Span คือส่วนการทำงานต่าง ๆ ของระบบ ประกอบไปด้วยชื่อ เวลาเริ่มต้น และเวลาการทำงาน โดยที่ Span สามารถซ้อนการและเรียงลำดับ เหมือนกับการทำงานทั่วไปนั่นเอง ยกตัวอย่างเช่น web -> api -> caching -> database เป็นต้น

ยังไม่พอนะ Jaeger มันมี component มากมาย

ดังรูป

จะรออะไรมาลองใช้งานกันดีกว่า

Jaeger นั้นประกอบไปด้วย 3 ส่วนการทำงานหลักคือ
  1. Agent เป็น process ที่จะ run อยู่ที่ client หรือ host ต่าง ๆ ที่ต้องการจัดเก็บข้อมูล
  2. Collector เป็นส่วนการจัดเก็บข้อมูล ซึ่งมีทั้ง Cassandra และ Elasticsearch
  3. Query เป็นส่วนการดึงข้อมูลไปแสดงผล
สามารถติดตั้งง่าย ๆ ด้วย Docker แบบ all in one ดังนี้ [code] docker run -d -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 -p5775:5775/udp -p6831:6831/udp -p6832:6832/udp \ -p5778:5778 -p16686:16686 -p14268:14268 -p9411:9411 jaegertracing/all-in-one:latest [/code] จากนั้นเข้า URL localhost:16686 สำหรับหน้าแสดงผลข้อมูลต่าง ๆ แสดงดังรูป แต่ถ้าต้องการ deploy ให้งานจริง ๆ ดูเพิ่มเติมจาก Deployment

มาลองเขียน code เพื่อ tracing การทำงานของระบบด้วย Jaeger กันดีกว่า

เป็นตัวอย่างของการเขียนด้วยภาษา Go ดังนั้นจึงใช้ Client library ชื่อว่า Jaeger client go สามารถเขียน code ง่าย ๆ ได้ดังนี้ ทำการสร้าง Jaeger tracer ขึ้นมาก่อน จากนั้นก็ระบบชื่อของ Span ไป ชื่อว่า service01 [gist id="6c85e901224cd1489972956e14fd72a3" file="main.go"] โดยในส่วนอื่น ๆ เราจะส่ง tracer นี้เข้าไปเช่นกัน จากนั้นก็กำหนดชื่อของ span ตามที่ต้องการ จะได้ผลการทำงานดังนี้ เพียงเท่านี้เราก็ได้ระบบ tracing ของระบบแบบง่าย ๆ แล้วครับ วันนี้เรา tracing ระบบกันอย่างไร ? ขอให้สนุกกับการเขียน code ครับ Referencen Websites https://eng.uber.com/distributed-tracing/
↧

บันทึกผลการทดสอบประสิทธิภาพของ Docker ไว้นิดหน่อย

November 24, 2017, 11:09 pm
$
0
0

เนื่องจากพบว่าการนำ Docker และ Docker Swarm ไปใช้งานนั้น มักจะมีปัญหาเรื่องของ performance ยิ่ง Docker Swarm ยิ่งมีปัญหาเรื่องของ network ที่ช้าอีก ดังนั้นจึงทำการทดสอบ performance แบบง่าย ๆ ไว้นิดหน่อย ซึ่งทำให้เห็นและเข้าใจปัญหามากขึ้น

รายละเอียดของการทดสอบ

  • ทดสอบบน Digital Ocean
  • CPU Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
  • Memory 2G
  • OS Ubuntu 16
  • Nginx 1.13.6
  • Docker 17.09.0-ce
  • WRK

การทดสอบใช้ WRK

ยิ่งผ่าน host เท่านั้น เป็นเวลา 20 วินาที (ยิงนานเหนื่อย) [code] $wrk -t5 -c400 -d20s http://localhost [/code]

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

  • ติดตั้ง nginx บนเครื่อง host โดยตรง
  • ติดตั้ง nginx ด้วย Docker ซึ่งใช้ network ดังนี้ bridge, host และ Cailco
  • ติดตั้ง nginx เป็น service ด้วย Docker Swarm
ทำการทดสอบอย่างละ 5 ครั้ง เพื่อให้ได้ขอบเขตของการทำงานที่ชัดเจนขึ้น ได้ผลที่น่าสนใจดังนี้

การติดตั้ง nginx บน host โดยตรงผ่าน apt-get เลย

มีประสิทธิภาพสูงมาก ๆ คือ 10K request ต่อวินาที สิ่งที่ลืมจดมาคือ min/max ของ response time !! ต่อมาทำการทดสอบผ่าน docker ด้วย network default คือ bridge ผลการทำงานตกลงมากอย่างน่าใจหายไปอยู๋มรา 5-6 K request ต่อวินาที แต่เมื่อเปลี่ยนมาใช้ network host ก็วิ่งขึ้นมาสูงถึง 7-9 K request ต่อวินาที แต่ตัวที่น่าสนใจว่าคือ Docker Swarm พบว่าเมื่อสร้าง service ขึ้นมามี replica = 1 ใน Swarm มีเพียงเครื่องเดียวเท่านั้น แน่นอนว่าใช้ overlay network นั่นเอง ได้ผลการทดสอบที่น้อยมาก ๆ คือ 3-4 K request ต่อวินาที เท่านั้น แต่เมื่อทำการเพิ่มค่า replica เป็น 2, 3 และ 4 ตามลำดับ ได้ผลการทดสอบที่สูงขึ้นเรื่อย ๆ จนไปถึง 7-9 K request ต่อวินาที ซึ่งทำให้เห็นภาพชัดเจนว่า ถ้า Docker Swarm มี service ที่ replica เป็น 1 ต้องเสีย overhead เรื่องของ network ไปแน่นอน แต่เมื่อเพิ่ม replica ขึ้นมา พบว่าการทำงานใกล้เคียงกับการติดตั้งปกติมาก แต่สิ่งที่ได้กลับมาเพิ่มคือ High Avaiability นั่นเอง
นี่ยังเป็นเพียงการทดสอบแบบง่าย ๆ ที่สำคัญเป็นแบบ static อีกด้วย แต่น่าจะทำให้เห็นอะไรมากพอสมควร ยังมีเรื่องอื่น ๆ อีก เช่นการพูดคุยกันระหว่าง container เป็นต้น
ไปอ่านมามีคำแนะนำให้ใช้ network อื่น ๆ อีก ไม่ว่าจะเป็น Cailco, Weave เป็นต้น
↧

คำสั่ง Git ที่ใช้อยู่เป็นประจำ

November 25, 2017, 5:50 am
$
0
0

จาก post เรื่อง 6 คำสั่งของ Git ที่คุณจำได้หรือนึกออก นั่นหมายความว่าเป็น 6 คำสั่งที่ใช้เป็นประจำ จึงทำการสรุปไว้นิดหน่อย น่าจะมีประโยชน์สำหรับมือใหม่บ้าง เพราะว่าคำสั่งที่ผมใช้มันพื้นฐานสุด ๆ git init สำหรับการสร้าง git repository ใหม่บนเครื่องของเราเอง บางครั้งทั้ง project คุณอาจจะทำเพียงครั้งเดียวก็เป็นไปได้ git clone สำหรับการดึง repository จาก git server มาจากเครื่องของเรา ใช้บ่อยมาก ๆ สำหรับการทำงานเป็นทีม หรือนำ code ของคนอื่นมาใช้งานหรือศึกษา สามารถระบุ branch หรือ tag ที่ต้องการได้อีกด้วย git add สำหรับทำการเพิ่มสิ่งที่เราเปลี่ยนแปลงและสร้างใหม่ไปยัง index (unstage -> stage) ก่อนที่จะทำการ commit ต่อไป เป็นชุดคำสั่งที่ใช้บ่อยมาก ๆ การใช้งานที่เจอบ่อย ๆ คือ git add . git commit ทำการยืนยันการเปลี่ยนแปลงจากการ add หรือทำการ update HEAD ที่ local repository นั่นเอง แต่ไม่ได้เปลี่ยนแปลงที่ remote repository นะ ทำการ commit จากสิ่งที่ถูกเพิ่มมาจากคำสั่ง git add เท่านั้น
อธิบายง่าย ๆ คือ git add คือการนำของใส่กล่อง git commit คือการปิดกล่องเมื่อของในกล่องครบตามที่ต้องการ
git status ใช้ตรวจสอบสถานะของ local repository ว่าเป็นอย่างไร มีอะไรเพิ่มเข้ามาใหม่ มีอะไรแก้ไข มีอะไรลบออกไป เป็นคำสั่งที่ใช้งานบ่อยสุด ๆ git push สำหรับส่งการเปลี่ยนแปลงหรือ commit ที่ local repository ไปยัง remote repository git pull เมื่อมี push ก็ต้องมี pull สำหรับดึงการเปลี่ยนแปลงล่าสุดจาก remote repository มายัง local repository git log สำหรับดูประวัติเปลี่ยนแปลง บน local repository เช่น มีใครทำอะไรบ้าง ในช่วงเวลาหนึ่ง ๆ มีอะไรเปลี่ยนแปลงบ้าง แต่ละการเปลี่ยนแปลงเป็นอย่างไร git branch สำหรับจัดการ branch ต่าง ๆ โดยปกติแล้ว git repository ต้องมี 1 branch เสมอ ถ้าสังเกตุคือ master branch นั่นเอง แต่สามารถลบได้นะ ถ้ามี branch มากกว่า 1 ซึ่งเรื่องของการจัดการ branch เป็นสิ่งสำคัญมาก ๆ ดังนั้นต้องตกลงและจัดการให้ดี มิเช่นนั้นปัญหาเรื่อง conflict หรือข้อขัดแย้งต่าง ๆ จะมากมาย ส่งผลให้ต้องใช้เวลาในการ merge หรือรวม code มากและวุ่นวาย
ส่วนพวก git merge, rebase, bisec และ cherry-pickt ผมไม่ค่อยได้ใช้เท่าไร
↧
↧

เราขาด Developer ที่ดีต่างหาก !!

November 26, 2017, 7:50 am
$
0
0

บ่อยครั้งมากที่เรามักได้ยินว่า Developer มีน้อยไม่เพียงพอต่อความต้องการของตลาด Developer ด้านนั้นด้านนี้หายากมาก ๆ ภาคการศึกษาผลิต Developer ออกมาได้น้อย หรือ ไม่ตรงกับที่ตลาดต้องการ ยิ่งในฝั่ง recuitor แล้วยิ่งเจอปัญหาอย่างมาก

หลาย ๆ บริษัทก็มีวิธีการแจ่ม ๆ ในการแก้ไขปัญหาเหล่านี้

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

มาดูสิ่งที่เกิดขึ้นในวงการ IT กัน ผมเรียกมันว่ากำแพง !!

ส่งผลให้ Developer ที่ดีหมดโอกาสไปอย่างมาก

เขียน Job description ในการรับงานเยอะเหลือเกิน บ่อยครั้งไม่ได้เกี่ยวกับตำแหน่งเลย

ทำให้คนที่น่าสนใจถูกกรองไปเยอะ ต้องการคนที่มีความสามารถเยอะไปไหน บางครั้งในบริษัทยังจะไม่มีเลย

ระบุระดับการศึกษาว่า

ต้องจบจากมหาวิทยาลัยนะ หนักกว่านั้น ระบุชื่อมหาวิทยาลัยไปเลย ต้องจบ Computer Science, Computer Engineering เท่านั้นอีก จะให้ดีต้องมีหนังสือแนะนำอีกด้วย คำถามที่น่าสนใจคือ คนที่จบมานั้นมีความสามารถเพียงพอต่อการทำงานหรือไม่ ? คุณเชื่อว่าทำงานได้ไหม ? เข้าใจการ programming ในรูปแบบต่าง ๆ มากเพียงใด ? เข้าใจ Software design และ Testing ไหม ? รู้และเข้าใจเทคโนโลยีใหม่ ๆ ไหม ?

ยิ่งมีใบ certified มายิ่งดี

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

ชอบใส่อายุและประสบการณ์เข้ามา

ลองคิดดูว่า ถ้า developer ที่ต้องการ ต้องจบมหาวิทยาลัย ต้องมีประสบการณ์ 2-5 ปี นั่นหมายความว่า กำลังจะบอกว่าต้องการคนที่มีอายุ 24 หรือ 25 ปีขึ้นไปใช่ไหม หายากไหมละ

ขั้นตอนการสัมภาษณ์และว่าจ้างซับซ้อนมากมาย

คนติดต่อและสัมภาษณ์รอบแรกคือ คนที่ไม่ได้อยู่ในการพัฒนา software ใช่ไหม ?

ต้องทำงาน onsite เท่านั้น

ทั้ง ๆ ที่ในปัจจุบันการทำงานแบบ remote มันสะดวกมาก ๆ หรือทำงานแบบ onsite 70% และ remote 30% น่าจะทำให้ได้ Developer ที่น่าสนใจกว่า เพราะว่า Developer ที่ทำงานแบบ remote ได้ดี น่าจะมีความรับผิดชอบสูงใช้ได้เลย

เงินเดือนที่ให้มันสมเหตุสมผลกับ Job description หรือไม่ ?

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

วัฒนธรรมขององค์กรเป็นอย่างไร ?

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

สิ่งต่าง ๆ เหล่านี้คือส่วนหนึ่งของกำแพง

ที่เราสร้างขึ้นมาเพื่อกั้น Developer จำนวนมากมาย ถ้าเราทำลายหรือลดกำแพงเหล่านี้ลงไป น่าจะทำให้จำนวนของ Developer ที่ดีเยอะขึ้นนะ
↧

Android :: ว่าด้วยเรื่องของการทดสอบด้วย Espresso กับ Retrofit/OkHttp

November 28, 2017, 10:14 am
$
0
0

จากการแบ่งปันเรื่องของ Automation Test ด้วย Espresso สำหรับ Android app ปัญหาอย่างหนึ่งที่พบเจอคือ เมื่อต้องทำการสอบระบบงานที่ทำงานแบบ Background operation ยกตัวอย่างเช่น การเชื่อมต่อไปยัง REST API หรือ WebService ด้วย Retrofit และ OkHttp รวมทั้งการจัดการเรื่องของ Thread เอง โดยสิ่งต่าง ๆ เหล่านี้อยู่เหนือขอบเขตความสามารถของ Espresso
คำถามคือ แล้วจะจัดการอย่างไรดีละ ? เรามาหาคำตอบกัน

เริ่มจาก code ตัวอย่างของระบบงานกันดีกว่า

ซึ่งทำการเรียกใช้งานข้อมูลจาก REST API ด้วย Retrofit และ OkHttp ดังนี้ [gist id="7a74d4297397365285ebb12dd1360568" file="MainActivity.java"] เมื่อทำการเขียนชุดทดสอบด้วย Espresso ดังนี้ [gist id="7a74d4297397365285ebb12dd1360568" file="MainActivityTest.java"] ผลที่ออกมาคือ Error หรือการทดสอบไม่ผ่าน [gist id="7a74d4297397365285ebb12dd1360568" file="result_fail.txt"]

แนวทางในแก้ไขเป็นอย่างไร ?

เริ่มต้นด้วยแนวทางสุดฮิตคือ รออะไรจัดไปด้วย Thread.sleep() แต่วิธีการนี้มันไม่ stable เลย บางเครื่องช้า บางเครื่องเร็ว ทำให้การทดสอบพังบ้างไม่พังบ้าง ทำให้หลาย ๆ คนหมดความเชื่อถือกับชุดการทดสอบ บางคนกำหนดเวลาการรอไปเป็นนาทีเลยก็มี ไม่รู้จะรออะไรกันนานขนาดนั้น !! แสดงดัง code นี้ [gist id="7a74d4297397365285ebb12dd1360568" file="MainActivityTest2.java"] ดังนั้นมาหาวิธีการที่ดีกว่ากันหน่อย

ใน Espresso นั้นได้เตรียม Idling resource ไว้ให้

ใครไม่ใช้นี่ถือว่า บาปนะเออ (อันนี้พูดเล่น เพราะว่าคนไม่รู้กันสักเท่าไร) แต่ถ้ารู้แล้วก็ใช้กันนะ ดังนั้นต้องเขียน Idling resource เพื่อจัดการกับ OkHttp แต่ยังก่อน เนื่องจากมีคนใจดีทำไว้ให้คือ OkHttp Idling Resource การใช้งานก็ไม่ยากเลยมั้ง !! เริ่มด้วยการเพิ่ม dependency/library ใน build.gradle [gist id="7a74d4297397365285ebb12dd1360568" file="build.gradle"] จากนั้นทำการแก้ไขไฟล์ MainActivity ด้วยการเพิ่ม OkHttp3IdlingResource เข้าไป [gist id="7a74d4297397365285ebb12dd1360568" file="MainActivity2.java"] เพียงเท่านั้นชุดการทดสอบก็จะผ่านแบบชิว ๆ มาก

แต่ยังก่อน !! จาก code ตัวอย่างนั้นจะพบว่า

ส่วนของการใช้งาน Idling Resource นั้นมันอยู่ใน production code เลย ดังนั้น code ส่วนนี้จะถูกรวมเข้าไปใน APK ด้วย แต่ code ส่วนนี้ควรอยู่ใน Test หรือ Debug เท่านั้น ทำให้ต้องเปลี่ยนวิธีการแล้วนะ ซึ่งมีหลายแนวทาง เช่น
  • ทำการ Inject OkHttpClient มาจากในส่วนของการทดสอบเลย หรือนำ Dagger มาใช้ก็ไม่ว่ากัน
  • ทำการแยก code ในส่วน Debug ออกจาก production code หรือ Release

ใน blog นี้เลือกวิธีง่าย ๆ คือ แยก code ของ Debug และ Release ออกจากกัน

โดยใน Debug จะมีการใช้งาน Idling Resource ส่วนใน Release จะไม่มี สามารถทำได้ดังนี้ เริ่มด้วยแก้ไขไฟล์ build.gradle เพื่อระบุใช้ Idling Resource ใน Debug เท่านั้น [gist id="7a74d4297397365285ebb12dd1360568" file="build2.gradle"] จากนั้นก็ตรวจสอบนิดหน่อยสำหรับใช้ใน Debug เท่านั้น [gist id="7a74d4297397365285ebb12dd1360568" file="MainActivity3.java"] มันก็ทำงานได้นะ

แต่ยังก่อน code มันก็ยังอยู่รวมกันเหมือนเดิม

แน่นอนว่าตอน Release ไม่รอดแน่ ๆ ดังนั้นให้ทำการแยก code ออกไปตาม build type คือ debug กับ release เลย แสดงดังรูป โดยในส่วนของ Debug จะมี code ของการใช้งาน Idling Resource ส่วนของ Release จะไม่มี ดังตัวอย่าง [gist id="7a74d4297397365285ebb12dd1360568" file="AddIdlingResources.java"] เพียงเท่านี้ก็สามารถทดสอบได้แล้วนะครับ ง่ายไหมละ ? Source code ตัวอย่างอยู่ที่ Github:: Up1 ขอให้สนุกกับการ coding นะครับ
↧
Search

สรุปเรื่อง QA in Production นิดหน่อย

November 29, 2017, 2:25 am
$
0
0

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

ถ้าเรามีระบบ monitoring, logging, alert ที่ดี

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

จากบทความแบ่งการเรียนรู้จากข้อมูลบน Production เป็นดังนี้

  • การรวบรวมข้อมูล
  • การเรียนรู้จากข้อมูล

1. การรวบรวมข้อมูล

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

Logging

โดยพื้นฐานแล้ว logging เป้นสอ่งที่สำคัญมาก ๆ สำหรับการรวบรวมข้อมูลการทำงานของระบบ แต่ ทำการจะเก็บไว้ในไฟล์หรือไม่ ? มันหาง่ายหรือไม่ ? มันช่วยให้หาต้นเหตุของปัญหาได้ง่ายไหม ? ข้อมูลมันอ่านรู้เรื่องหรือไม่ ? ไม่จำเป็นต้องเป็นข้อมูลเชิง technical เท่านั้น เราเขียน log เพื่อให้คนเข้าใจ รูปแบบข้อมูล log เป็นอย่างไร ? หรือได้ไฟล์ใหญ่ ๆ มาแล้วมาทำค้นหา ผลสุดท้ายไม่ได้ช่วยเลย แถมทำให้ลำบากอีกหรือไม่ ? อย่าลืมว่าบน production นั้นข้อมูล log มันมหาศาลมาก ๆ เก็บข้อมูลที่จำเป็นต้องใช้เท่านั้น
ดังนั้นก่อนที่การเก็บ log ต้องคิดก่อนว่าต้องการจะดูอะไรบ้าง ไม่ใช่เก็บทุกอย่างไว้ก่อน แบบนี้มันเปลืองทรัพยากรอย่างมาก
บทความยกตัวอย่างของการจัดการ log ไว้อย่างน่าสนใจคือ การทำงานหลักจะไม่เก็บ log ไว้ แต่ละส่งข้อมูลไปเก็บที่ server หรือ service อื่น ๆ แทน โดย server หรือ service ที่จัดการนั้น จะเก็บข้อมูลลง Database ที่สนับสนุน full-text search เช่น Elasticsearch และ Apache Solr เป็นต้น ทำให้สามารถค้นหาข้อมูลได้อย่างง่ายดาย ทั้งสนับสนุนการ query ทั้งสนับสนุนการแสดงผลในรูปแบบรูปกราฟสวย ๆ แน่นอนว่า ทาง business เข้าใจได้ง่าย ทั้งสนับสนุนการทำ aggregation ข้อมูลเพื่อสรุปและดูแนวโน้มต่าง ๆ น่าจะช่วยทำให้เห็นปัญหาได้เร็วขึ้น ไม่ใช่รู้ปัญหาจากผู้ใช้งานเท่านั้น !! หรือว่าทีมสร้างรู้ปัญหาจากผู้ใช้งาน มันแปลก ๆ นะ

Metrics

ส่วนเพิ่มเติมของ logging คือ metric ต่าง ๆ เป็นสิ่งที่ใช้วัดค่าต่าง ๆ ที่เราต้องการ ยกตัวอย่างเช่น จำนวนการกดปุ่มในแต่ละชั่วโมง จำนวนการ register ในแต่ละชั่วโมงในแต่ละวัน จำนวนของการ register ไม่สำเร็จในแต่ละชั่วโมงในแต่ละวัน ซึ่งเป็นประโยชน์อย่างมากต่อการ monitoring การทำงานของระบบ เครื่องมือที่ชอบให้งานกันเช่น Statd และ Prometheus เป็นต้น
โดยเก็บข้อมูลทั้ง technical และ business ช่วยทำให้เห็นแนวโน้มการใช้งานและทำงาน ช่วยทำให้เราเรียนรู้ระบบได้เป็นอย่างดี ช่วยทำให้เราเห็นแนวโน้มของปัญหาได้อย่างดี

2. การเรียนรู้จากข้อมูล

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

ระบบ Alert

เพื่อทำการ monitoring การทำงานของระบบว่า มีจำนวนหรือปริมาณถึงจุดที่อาจจะก่อให้เกิดปัญหาหรือไม่ เช่น Latency หรือ reponse time ของการทำงาน การใช้งาน CPU และ Memory ที่สูง จากนั้นทำการแจ้งเตือนผ่านช่องทางต่าง ๆ เช่น Email, Instant messaging เป็นต้น แต่ถ้าแจ้งเตือนบ่อยเกินไปก็ไม่ดี เพราะว่าสุดท้ายแล้วจะเป็นการรบกวนมากจนเกินไป
ระบบ Alert ที่ดีต้องสามารถแจ้งเตือนก่อนที่ปัญหาจะเกิด เราจะได้มีเวลาวางแผนและเตรียมรับมือ ไม่ใช่แจ้งเตือนเมื่อเกิดปัญหาขึ้นมาแล้ว มันไม่ได้ช่วยอะไรเลย แค่ทำให้รู้เท่านั้น

ระบบ Dashboard

ใช้สำหรับแสดงผลข้อมูลต่าง ๆ ของระบบในรูปแบบที่เข้าใจง่าย ซึ่งนำข้อมูลที่รวบรวมมาจากหลาย ๆ ที่ มาทำการประมวลผล เช่น aggregation หรือ data processing และแสดงผลออกมาในรูปแบบของกราฟและรูปภาพที่เข้าใจได้ง่าย ที่สำคัญต้องเป็นสิ่งที่มีประโยชน์ต่อระบบและทีมด้วยนะ นั่นคือสามารถอธิบายและระบุปัญหาได้ ยังไม่พอ Dashboard ต้องง่ายต่อการเข้าถึงอีกด้วย ยกตัวอย่างเช่น Github status page และ Tes dashboard

แล้ว QA จะปรับตัวอย่างไร ?

เมื่อพูดถึง QA (Quality Assurance) แล้วจะคิดว่าคือ กลุ่มคนที่มาทำการทดสอบระบบ เป็นกลุ่มคนที่จะบอกว่าระบบงานมีคุณภาพหรือไม่ ? หรือตัดสินใจได้ว่าจะ deploy และ release ระบบหรือไม่ ? ดังนั้นเรื่องของการเรียนรู้และวิเคราะห์ปัญหาเชิงคุณภาพจึงเป็นสิ่งที่ถูกมองข้ามไป !! การทดสอบนั้นเป็นเพียงการบอกว่า ระบบทำการตาม scenario ที่กำหนดไว้ได้เท่านั้น การทดสอบมันช่วยหาข้อมูลผิดพลาดตามที่เราคาดหวังไว้เท่านั้น แต่บน production นั้นมักจะมีแต่เรื่องแปลกประหลาดเกิดขึ้นทุกครั้งไป ทั้งพฤติกรรมของผู้ใช้งานที่แตกต่างกัน ทั้งระบบ network มีความเร็วที่แตกต่างกัน ทั้ง browser ที่ใช้งานมีหลากหลายมาก ทั้ง device ที่ใช้งานมีหลากหลายมาก ซึ่งมีหลายสิ่งอย่างมาก ที่สำคัญทำนายหรือคาดเดาไม่ได้เลย ดังนั้นการทดสอบจึงไม่ครอบคลุมอย่างแน่นอน สิ่งที่เราต้องการเพิ่มเติมคือ ระบบ monitoring ที่ดี เพื่อทำให้เราเห็นว่าเกิด scenarioที่เราคาดไม่ถึงได้อย่างรวดเร็ว จากนั้นจึงนำมาเพิ่มเติมในหารทดสอบ นั่นคือการเรียนรู้นั่นเอง
ทำให้เราเข้าใจพฤติกรรมการทำงานของระบบและผู้ใช้งานจริง ๆ ยิ่ง QA แล้วด้วยสิ่งต่าง ๆ เหล่านี้สำคัญมาก ๆ แต่เรามักจะมองข้ามไป !!
ดังนั้นทีมควรจะส่งมอบงานที่มีคุณภาพอย่างต่อเนื่อง ด้วยการทดสอบและแจ้งเตือนเมื่อเกิดเหตุการณ์ที่จะทำให้ระบบมีปัญหา เพื่อที่จะหาต้นเหตุปัญหาและแก้ไขได้อย่างทันท่วงที
คำถามที่น่าสนใจคือ คุณพร้อมไหม ?

ส่วนการประยุกต์ใช้งานนั้น มันขึ้นอยู่กับบริบทขององค์กรด้วย

เช่นถ้าระบบมันทดสอบยาก หรือ ต้องใช้เวลาและค่าใช้จ่ายสูงมาก ๆ ดังนั้นไปลงทุนกับทำระบบ monitoring ดีกว่าไหม ซึ่งทำให้เราและองค์กรเดินไปข้างหน้าได้รวดเร็วขึ้น ดังนั้นต้อง balance ให้ดีด้วย ถ้าองค์กรมีระบบ Continuous Delivery ที่ดีและเร็ว อาจจะไม่ต้องมีการทดสอบเลย เนื่องจากถ้ามีปัญหาที่ production ก็สามารถรู้และแก้ไขได้อย่างรวดเร็ว บางระบบมันยากต่อการ recovery และแก้ไขปัญหา ดังนั้นสิ่งที่ควรทำคือ ต้องลงทุนในส่วนของ pre-production environment ให้เหมือน production เพื่อทำให้มั่นใจว่า จะไม่เกิดข้อผิดพลาดที่ production บางที่อาจจะทดสอบและแก้ไขบน production กันไปเลย ซึ่งถือว่าเป็น anti-pattern อย่างหนึ่ง !!
เป้าหมายหลักคือ การทำให้ระบบดีขึ้นกว่าเดิม นั่นคือการปรับปรุงคุณภาพของระบบนั่นเอง ถ้าคุณบอกว่า ระบบมันก็ดีอยู่แล้ว แสดงว่าคุณไม่ได้เรียนรู้อะไรเลย
ขอให้สนุกกับการ coding ครับ
↧

Kotlin 1.2 ออกมาแล้ว เน้นเรื่องการ share code ระหว่าง platform

November 29, 2017, 8:11 am
$
0
0

เมื่อวันที่ 28 พฤศจิกายนที่ผ่านมา Kotlin 1.2 ถูกปล่อยออกมา เป็นอีกก้าวที่สำคัญของ Kotlin คือการ reuse code ระหว่าง JVM และ JavaScript โดยที่ Kotlin 1.1 เน้นในเรื่องของ JavaScript เป็นหลัก ดังนั้นทำให้นักพัฒนาสามารถเขียน business logic ด้วยภาษา Kotlin ส่วนการทำงานอื่น ๆ เช่น frontend, backend และ Android app สามารถใช้ code เหล่านี้ได้เลย

โดยที่ Kotlin 1.2 นั้นถูกเพิ่มเข้ามาใน IntelliJ IDEA 2017.3

ซึ่งจะถูกปล่อยออกมาในสัปดาห์นี้ แต่ถ้าใช้งาน Android Studio หรือ IntelliJ IDEA เก่า ๆ ต้องทำการติดตั้งเอง โดยเข้าไปที่เมนู Tools -> Kotlins -> Configure Kotlin Plugin ใน Kotlin 1.2 นั้นมีความสามารถมากมายที่มาจาก contributor ภายนอก ทำให้เห็นว่าชุมชนของ Kotlin โตขึ้นเป็นอย่างมาก มาดูความสามารถที่น่าสนใจกัน

Multiplatform Projects

สามารถทำการสร้างระบบงานต่าง ๆ ทั้ง Backend, Frontend และ Android app จาก code ชุดเดียวกันได้ ซึ่งในแต่ละ project ประกอบไปด้วย
  • Common module สำหรับ code ที่ใช้ในทุก ๆ platform
  • Platform module สำหรับ code ของแต่ละ platform เช่น JVM และ JavaScript โดยสามารถเรียกใช้งาน code จาก common module ได้
แสดงโครงสร้างของ project ดังรูป ในส่วนของ common module นั้นจะมี common code จาก common library ของ Kotlin ประกอบไปด้วย
  • kotlin.test  สำหรับการทดสอบ
  • kotlinx.html สำหรับ Isomorphic rendering หรือ render HTML
  • kotlinx.serialization สำหรับการ marshal พวก Kotlin object ทีส่งไปมาระหว่าง platform ซึ่งสนับสนุนพวก JSON และ PhrotoBuf
ปล. ความสามารถนี้ยังอยู่ในขั้นการทดลองเท่านั้น (experiment) นั่นหมายความว่าพร้อมใช้งาน แต่อาจจะมีการเปลี่ยนแปลงอีก แต่ถ้าเป็นอย่างนั้น ทีมพัฒนาจะมีเครื่องมือในการ migrate ให้

Compilation Performance

ใน Kotlin 1.2 นั้นทำการปรับปรุงเวลาในการ compile ให้รวดเร็วขึ้น โดยเร็วกว่า Kotlin 1.1 ประมาณ 25% และจะทำการปรับปรุงให้เร็วขึ้นใน minor release ต่อ ๆ ไปอีกด้วย รูปแสดงความเร็วในการ compile ของ Kotlin ในระบบงานใหญ่ ๆ ของ Jetbrains

การปรับปรุงความสามารถของภาษาและ library ต่าง ๆ

มีการปรับปรุงบ้างเล็กน้อย ประกอบไปด้วย
  • ปรับปรุง syntax สำหรับการส่ง multiple argument ผ่าน annotaiton
  • สามารถใช้ lateinit สำหรับ property และ local variable ได้แล้ว
  • เรื่องของ Smart cast และ Type inference
  • เพิ่ม package kotlin.math เข้ามาใน standard library
  • เพิ่ม function ใหม่ ๆ สำหรับการทำงานกับ sequence และ collections
สามารถดูข้อมูลและ code ตัวอย่างเพิ่มเติมที่ What’s New in Kotlin 1.2

มาดูความเคลื่อนไหวของ Kotlin

หลังจากที่ในเดือนมีนาคมได้ปล่อย Kotlin 1.1 ออกมา มีการนำไปใช้งานจำนวนสูงขึ้นอย่างมาก มีงาน Kotlin Conference ครั้งแรก ซึ่งมีคนมาร่วมงานประมาณ 1,200 คนจากทั่วโลก สามารถตามไปดู VDO ต่าง ๆ ได้เลย

ที่สำคัญภาษา Kotlin นั้นเป็นอีกภาษาหนึ่งที่ใช้พัฒนา Android app ได้

เป็น Official language สำหรับการพัฒนา Android app โดยใน Android Studio 3.0 นั้นสนับสนุนภาษา Kotlin เลย โดยไม่ต้องทำการติดตั้งอะไรเพิ่มเติม สามารถอ่านเอกสารจากทาง Android ได้อีกคือ ตัวอย่าง code และ Style guide

ข้อมูลที่น่าสนใจจาก Android Studio 3.0 คือ

มี project ที่สร้างด้วยภาษา Kotlin ถึง 17% กันเลยทีเดียว

ในฝั่ง Server side ก็ไม่น้อยหน้า

Spring Framework 5.0 ก็สนับสนุนความสามารถต่าง ๆ ของภาษา Kotlin รวมทั้ง vert.x 3.4.0 ก็สนับสนุนเช่นกัน ฝั่ง Gradle ก็สามารถเขียน Kotlin DSL ได้อีกเช่นกัน

มาดูข้อมูลจาก Github พบว่าจำนวนบรรทัดของ code

ที่เขียนด้วยภาษา Kotlin มีมากกว่า 25 ล้านบรรทัดแล้ว รวมทั้งข้อมูลจาก StackOverflow ก็สูงขึ้นมาเช่นกัน

ยังไม่พอนะ community ก็มีมากกว่า 100 กลุ่มทั่วโลก

สำหรับผู้เริ่มต้นศึกษาสามารถเรียนรู้ได้จากหนังสือต่าง ๆ เช่น

  • Kotlin in Action
  • Kotlin for Android Developers
  • Modern Web Development with Kotlin
อีกทั้งยังมี online course และเอกสารต่าง ๆ ลองไปศึกษากันดูนะ

ถ้าต้องการ upgrade Kotlin สามารถทำได้ดังนี้

เริ่มด้วยการศึกษาผ่าน online คือ Try Kotlin ส่วนช่องทางอื่น ๆ เป็นดังนี้
  • สำหรับ Apache Maven, Gradle และ npm ให้ทำการระบุ version 1.2.0 สามารถอ่านเพิ่มเติมได้
  • สำหรับ IntelliJ IDEA 2017.3 จะมี Kotlin 1.2 มาด้วยอยู่แล้ว ส่วน version ก่อนหน้าต้องทำการ update Kotlin plugin 1.2 เอง
  • สำหรับ Android Studio ให้ทำการติดตั้งและ update ผ่าน Plugin Manager
  • สำหรับ Eclipse IDE ให้เข้าไปยัง Marketplace
  • สำหรับ command-line compiler ให้ทำการ download จาก Github

สุดท้ายเรื่อง compatibility หรือความเข้ากันได้กับ version ก่อนหน้า

ยังคงใช้งานได้ปกติ รวมทั้งยังสามารถปิดความสามารถใหม่ ๆ ได้อีกด้วย ขอให้สนุกกับการเขียน code นะครับ
↧
↧

ลาก่อนนะ Postman บน Google Chrome

November 29, 2017, 6:51 pm
$
0
0

วันนี้เปิดใช้ Postman app บน Google Chrome ก็เจอประกาศบอกว่า Chrome apps are being deprecated !! นั่นหมายความว่าเลิกพัฒนา app บน Google Chrome แล้วนะ ให้ไปใช้ Native app แทนได้เลย ซึ่งมีทั้งบน Mac, Windows และ Linux อยู่แล้ว เป็นผลมาจากการที่ทาง Google ประกาศที่จะไม่สนับสนุน Chrome app นั่นเอง ที่สำคัญทีมพัฒนาของ Postman ได้พัฒนาความสามารถของ Postman native ให้เท่าเทียมกับบน Chrome app แล้วด้วย แถมมีความสามารถดีดีกว่าอีกด้วย ดังนั้นคนที่ใช้อยู่แบบผมก็ migrate ข้อมูลกันได้แล้วนะ Reference Websites http://blog.getpostman.com/2017/11/01/goodbye-postman-chrome-app/
↧

Swift :: ลองปรับปรุงการใช้งาน protocol กันนิดหน่อย

November 30, 2017, 1:21 am
$
0
0

วันนี้เจอ code ที่เขียนด้วยภาษา Swift ที่น่าสนใจ เกี่ยวกับการใช้งาน protocol แถมเจอบทความอธิบายเรื่องนี้ด้วย  Protocol Composition เลยนำมาสรุปกับ code ที่พบเจอด้วยเลย

โดย code เหมือนจะดูดีนะ แต่มีหลายเรื่องที่สามารถปรับปรุงให้ดีขึ้นได้

มาเริ่มกันเลย [gist id="f702eba2cea3970f917b30f5eacff07a" file="1.swift"] คำอธิบาย ใน protocol สำหรับการจัดการข้อมูล ซึ่งมีความสามารถในการอ่านและเขียนข้อมูล ดังนั้นถ้า struct/class ทำการ implement protocol นี้ ต้องทำการ implement ทั้งการอ่านและการเขียนเสมอ เหมือนจะดูดี

แต่ไป ๆ มา ๆ เจอ code แนวนี้ใน project อีก

[gist id="f702eba2cea3970f917b30f5eacff07a" file="2.swift"] คำอธิบาย คำถามที่เกิดขึ้นมาทันทีคือ มันคือ read only แล้วทำไมต้องมีการเขียน หรือ method write() ด้วย ? ไม่แน่ใจนักพัฒนาหลาย ๆ คนเคยเจอ code แนวนี้หรือไม่ ?

ถ้าเจอแล้ว สิ่งที่ทำคืออะไร ?

  • ปล่อยมันไป อย่าไปยุ่งกับมัน
  • ถ้าต้องใช้ protocol นี้อีกก็ทำเหมือน ๆ กัน
  • ต้องแก้ไข
  • แก้อะไร มันมีอะไรผิดหรอ

ในบทความนี้จะทำการแก้ไขและปรับปรุงนิดหน่อย

สิ่งแรกที่ต้องเข้าใจก่อนคือ code ชุดนี้มันมีอะไรที่ต้องปรับปรุง ถ้าไม่รู้จะทำอะไรกัน !! จาก code ต้องการเพียงการอ่านข้อมูลเท่านั้น ดังนั้นปัญหาที่เจอคือ เรื่องของ ISP (Interface Segregation Principle) นั่นหมายความว่า ผู้ใช้งานควรใช้ interface ที่แตกต่างกันไปตามความต้องการ ในที่นี้ interface ของเราคือ protocol นั่นเอง โดยจะสร้าง protocol ขึ้นมา 2 ตัวคือ DataReader และ DataWriter [gist id="f702eba2cea3970f917b30f5eacff07a" file="3.swift"] จากนั้นทำการแก้ไข struct/class ที่ทำการ implement protocol เดิมดังนี้ [gist id="f702eba2cea3970f917b30f5eacff07a" file="4.swift"]

ดูเหมือนจะดีขึ้นแล้วนะ

แต่สิ่งที่น่าสนใจคือ ถ้ามี protocol จำนวนเยอะ ๆ ละ ชีวิตไม่น่าจะดีเท่าไร ดังนั้นใน swift นั้นมี typealias ให้ใช้ ทำให้ code อ่านง่ายขึ้นดังนี้ [gist id="f702eba2cea3970f917b30f5eacff07a" file="5.swift"]

มาถึงตรงนี้น่าจะทำให้ code ดูดีขึ้นกว่าเดิมมาบ้างนะ

สิ่งที่นักพัฒนาควรต้องทำคือ การปรับปรุง code ต่าง ๆ ให้ดีขึ้นอยู่อย่างเสมอ แล้วชีวิตจะดีขึ้นครับ ขอให้สนุกกับการ coding ครับ Reference Websites https://dzone.com/articles/protocol-composition-in-swift?edition=334920
↧

มาแล้วสำหรับ Technology Radar Vol. 17

December 1, 2017, 7:44 pm
$
0
0

มาแล้วสำหรับ Technology Radar Vol. 17 โดยในครั้งนี้เน้นในเครื่องของ
  • บริษัทใหญ่ ๆ ในจีนปล่อยของที่ใช้งานออกมาเป็น open source อย่างมาก เช่น Alibaba และ Baidu เนื่องจากแนวคิดและนโยบายต่าง ๆ ที่เปลี่ยนไป
  • Kubernetes เป็นตัวเลือกหลักสำหรับ Container Orchestrator ซึ่งช่วยแก้ไขปัญหาต่าง ๆ มากมาย ดังนั้นใช้ซะ อย่ารอ
  • เรื่องของ Cloud มันกลายเป้นเรื่องปกติหรือ default ของหลาย ๆ บริษัทแล้ว ดังนั้นใครยังไม่ลองใช้ ต้องจัดแล้วนะ
  • Blockchain เป็นเทคโนโลยีที่ได้รับความน่าเชื่อถือในโลกของ distributed แล้ว ต่อจากนี้จะจะพูดถึงการ implement แล้วทั้ง distributed ledger และ smart contract

มาดูใน 4 ส่วนหลักกันว่ามีอะไรที่น่าสนใจกันบ้างสำหรับนักพัฒนาคือ

1. Techniques 2. Tools 3. Platforms 4. Languages and Frameworks

ส่วนที่ 1 Techniques

สิ่งที่ควรนำไปใช้งานคือ Lightweight Architecture Decision Records เป็นเทคนิคในการจัดเก็บข้อมูลเกี่ยวกับ Architecture ของระบบ พร้อมทั้งบริบทและผลต่าง ๆ ที่ตามมา แนะนำให้จัดเก็บไว้ที่ Source Control ซึ่งดีกว่า Wiki หรือ Website เนื่องจากสามารถดูประวัติการเปลี่ยนแปลง พร้อมทั้ง sync กับ source code อีกด้วย
วันนี้เราจัดเก็บสิ่งต่าง ๆ เหล่านี้ไว้หรือไม่ และอย่างไร ? ที่สำคัญเอกสารที่จัดเก็บมันสัมพันธ์กับ source code หรือไม่ ?
มาดูสิ่งที่น่าสนใจสำหรับการลองนำไปใช้งาน เรื่องแรกคือ Applying product management to internal platforms เน้นคำว่า internal นะ ปัญหาที่เจอคือ คนข้างในจะเชื่อและเคารพ external platform มากกว่า แต่กลับไม่ไว้ใจหรือเชื่อใจ internal platform หรือเชื่อใจคนภายในมากเท่าไร ดังนั้นเรื่องนี้จะเน้นการให้ความสำคัญกับคนข้างใน ให้ความสำคัญกับการทำงานร่วมกันตั้งแต่การคิดและออกแบบ เพื่อทำให้แน่ใจว่าสิ่งที่คิดและส่งมอบนั้น มันมีคุณค่าทาง business และ ช่วยปรับปรุงประสบการณ์ของ developer สิ่งที่เหล่า Platform product manager ต้องทำหลังจากที่ส่งมอบคือ การใช้ metric มาวัดผล การปรับปรุงอย่างต่อเนื่องและสม่ำเสมอ
มิเช่นนั้นคุณจะ transform ไปยัง Digital platform ได้อย่างไร ถ้ายังคงทำงานแบบตัวใครตัวมัน
เรื่องที่สองคือ DesignOps ได้รับแรงบันดาลใจมาจาก DevOps มันคือ culture และกลุ่มของแนวปฏิบัติที่ช่วยให้ คนจากส่วนต่าง ๆ ขององค์กรทำงานร่วมกัน ออกแบบร่วมกัน โดยยังคงเรื่องคุณภาพที่สูง ที่สำคัญยังช่วยลดแรงที่ลงไปในการทำงาน เนื่องจากจะค่อย ๆ ทำ เพื่อให้ได้รับ feedback จากนั้นนำ feedback มาใช้ปรับปรุงต่อไป ทำแบบนี้ไปเรื่อย ๆ มันคือ continuous improvement นั่นเอง ตัวอย่างเครื่องมือที่ช่วยเช่น Storybook เป็นต้น ทำให้แต่ละคนทำงานใกล้ชิดกันมากขึ้น เรื่องที่สาม Pipelines for infrastructure as code ในเรื่องของ Continuos Integration และ Continuous Delivery นั้น ถูกนำมาใช้งานอย่างแพร่หลายและกลายเป็นสิ่งที่ต้องมีในการพัฒนา software แต่สิ่งที่ยังขาดหายไปคือ เรื่องของการทดสอบ infrastructure แบบอัตโนมัติ เพื่อช่วยทำให้พบข้อผิดพลาดต่าง ๆ ก่อนการเปลี่ยนแปลง ซึ่งสำคัญมาก ๆ ต่อการจัดการ environment ต่าง ๆ ดังนั้นใน pipeline ควรมำการทดสอบ environment ต่าง ๆ ด้วย ว่ามีการ configuration และทำงานได้ตามที่ต้องการหรือไม่ เรื่องที่สี่ TDD’ing containers เรื่องของ TDD (Test-Driven Development) นั้นเป็นแนวปฏิบัติที่นักพัฒนาต้องมีไว้ เมื่อเข้ามาสู่โลกของ container ตั้งแต่ package และ deploy แล้ว แนวปฏิบัติ TDD นี้ยิ่งมีสำคัญอย่างมาก จะรู้ได้อย่างไรว่าสิ่งที่สร้าง ยังทำงานได้ตรงตามที่ต้องการ ดังนั้น ทั้ง code และ container ต้องมีชุดการทดสอบเสมอ โดยมีเครื่องมือให้ใช้เช่น ServerSpec และ Goss
ส่วนสิ่งที่ใช้อย่างระมัดระวังหรือว่าเลิกเถอะ !! ก็มี Recreating ESB anti pattern with Kafka ซึ่ง ESB มันกลับคืนชีพอีกครั้งด้วย Kafka Spec-based codegen เช่นพวก Swagger และ RAML มันยากต้องการทดสอบและดูแล

ส่วนที่ 2 Tools

มีเครื่องมือมากมายที่น่าสนใจ ทั้ง Fastlane สำหรับ iOS และ Android app ใครไม่ใช้นี่บาปมาก ๆ ส่วนเครื่องมือที่อยากให้ลองใช้ดู
  • Buildkite สำหรับชาว CI/CD ไม่ควรพลาด
  • CircleCI สำหรับใครที่ไม่ต้องการติดตั้งเอง ไปใช้เลย ลองดู
  • Gopass เครื่องมือสำหรับการจัดการ password
  • Headless Chrome for front-end test เป็นความสามารถใหม่จาก Google Chrome
  • jsoniter สำหรับ JSON encoder/decoder แบบแรง ๆ
  • Prometheus สำหรับระบบ monitoring ซึ่งข้อมูลจัดเก็บในรูปแบบ Time series
ส่วนเครื่องมือที่ยังต้องศึกษาต่อไปมีอีกเพียบเลย
  • Spring Cloud Contract
  • Flow
  • Jupyter
  • Kong API Gateway
  • Yarn

ส่วนที่ 3 Platforms

เริ่มด้วย Kubernetes ที่เป็นวิธีการหลักสำหรับการ deploy ระบบงาน ในรูปแบบ container บน cluster รวมทั้งเป็นตัวเลือกหลักบน Public Cloud Platform ด้วย ไม่ว่าจะเป็น Microsoft Azure Container Service และ Google Cloud รวมทั้งมี platform และ product ต่าง ๆ สร้างขึ้นมาเพื่อซ่อนการทำงานของ Kubernetes ไว้ เพื่อให้ใช้งานง่ายขึ้นอีกด้วย ดังนั้นมาใช้กันได้แล้วนะ ส่วนสิ่งที่อยากให้ลองนำมาใช้กัน เยอะเลย เช่น สิ่งที่ควรระมัดระวังอย่างมาก !! คือ การใช้งาน API gateway เนื่องจากปัจจุบันนิยมนำมาใช้งานอย่างมาก เพราะว่า API gateway นั้นช่วยให้งานหลาย ๆ อย่างง่ายขึ้น เช่นการ authentication, authorization และ rate limi เป็นต้น ทำให้ทุก ๆ service ที่ใช้งานผ่าน API gateway ไม่ต้องทำเครื่องต่าง ๆ เหล่านี้ แต่โชคไม่ดีที่หลาย ๆ ครั้งพบว่า มีการนำ business logic ต่าง ๆ ของระบบมาใส่ใน API gateway ส่งผลให้ยากต่อการทดสอบและ deploy

ส่วนที่ 4 Languages and Frameworks

ได้เวลาของ Python 3 แล้ว มีความสามารถที่มีประโยชน์มากมาย โดยจะถูกใช้ใน Machine Learning และ Web application รวมทั้งมี library ต่าง ๆ มากมาย แต่มันไม่ compatibility กับ Python 2 นะ !! สิ่งที่อยากให้ลองนำมาใช้เยอะมาก ๆ เช่น ของใหม่ ๆ เพียบเลย
  • Android Architecture Component
  • ARKit/ARCore
  • TensorFlow Mobile
  • LeakCanary สำหรับการตรวจหา memory leak สำหรับ Android และ Java
  • Weex เป็น framework สำหรับการพัฒนา cross platform mobile app ด้วย syntax ของ Vue.js
  • Solidity และ Truffle เป็นภาษาและ framework สำหรับการพัฒนาบน Ethereum platform
ยังมีอีกเยอะมาก ๆ ลองไปศึกษากันดูครับ น่าจะมีประโยชน์มากพอสมควร
↧
Viewing all 1997 articles
Browse latest View live
Search