Deno นั้นมี test runner มาให้ด้วยนะ เผื่อใครไม่รู้
เป็นหัวข้อเล็ก ๆ ในเอกสารของ Deno
สามารถเขียน test ด้วย JavaScript หรือ TypeScript ก็ได้
การใช้งานก็ไม่ยากผ่าน Deno.test ได้เลย
สนับสนุนทั้ง Synchronous และ Asynchronous เลย

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

จากนั้นทำการ run test ดังนี้

แต่ถ้าใครใช้พวก Jest และ Mocha มา อาจจะขัดใจเล็กน้อย

เพราะว่าเขียน test ในรูปแบบของ Jasmine ไม่ได้
ลองไปค้นหาดูว่า 
ถ้าต้องการเขียน test แบบเดิมแล้ว ต้องทำอย่างไรบ้าง
ก็ไปเจอที่ TypeOrm เขาบอกวิธีการไว้ที่นี่ TypeOrm Dependency มีให้ทั้ง

• chai
• mocha
• sinon

ดังนั้นลองนำมาใช้งานนิดหน่อย ดังนี้

ทำการ run test อีกแบบดังนี้

เพียงเท่านี้ก็เขียน test แบบปกติใน Deno ได้แล้ว

ปัญหา

ถ้าใครพัฒนาระบบด้วย Deno เพื่อติดต่อกับ MongoDB
ด้วย Library ชื่อว่า Deno Mongo
ใน version 0.7.0 จะมีปัญหากับ Deno 1.0.5 ซึ่งเป็นตัวล่าสุด

จะเจอปัญหาดังนี้

การแก้ไขปัญหานี้

วิธีการแรกคือ Downgrade version ของ Deno เป็น 1.0.3
แต่เมื่อวานทางคนพัฒนา Deno Mongo ได้ทำการแก้ไข
ด้วยการปล่อย version 0.8.0 มาแล้ว
สามารถใช้งานกันได้เลย

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

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

เรื่องแรกคือ รูปแบบของ Git Workflow

บ่อยครั้งจะพบว่า 

• ลืมสร้าง feature branch
• ที่หนักกว่าคือ สร้าง feature branch จาก feature branch 
• ทำการ commit ผิด branch

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

เรื่องที่สองคือ รูปแบบของการ commit

Commit message จะไม่สะท้อนถึงการเปลี่ยนแปลงเลย
รวมทั้งในแต่ละ commit มีการเปลี่ยนแปลงจำนวนมาก
ซึ่งทำให้ยากต่อการทำความเข้าใจอย่างมาก

ดังนั้นเรื่องรูปแบบของ commit message ควรต้องกำหนดและตกลงรูปแบบร่วมกัน
และการเปลี่ยนแปลงในแต่ละ commit ไม่ควรเยอะ

ตัวอย่างของ Commit message ให้ดูเพิ่มเติมได้ที่ Conventional Commits

เรื่องที่สามคือ การ push การเปลี่ยนแปลงไปยัง repository

บ่อยครั้งจะพบว่า

• ทำการ push ที่มีการเปลี่ยนแปลงมากกว่า 1 commit ขึ้นไป ซึ่งทำให้เกิดปัญหาตามมา
• ทำการ push การเปลี่ยนแปลง code ที่ไม่สามารถ compile และ ไม่ทดสอบการทำงานขึ้นไป
• ทำการ push เมื่อใกล้ deadline หรือไม่ทำการ push บ่อย ๆ นั่นเอง ก่อให้เกิดปัญหาอื่น ๆ ตามมา เช่นเรื่อง conflict ของการเปลี่ยนแปลงเป็นต้น
• ที่หนักสุดคือ ทำการ force push การเปลี่ยนแปลงขึ้นไป ซึ่งส่งผลต่อทีมทั้งหมดเลย อันตรายมาก ๆ

เรื่องที่สี่คือ การ merge 

เป็นส่วนที่น่าจะยากที่สุดของการใช้งาน Git และอาจจะทำเกิดปัญหา
เมื่อการ merge นั้น ๆ มีข้อขัดแย้งหรือ conflict และเสียเวลามาแก้ไขอีก

ต้นเหตุของปัญหานี้
จะมาจากไม่ทำการดึงการเปลี่ยนแปลงจาก repository มาบ่อย ๆ
และไม่ทำการ push บ่อย ๆ

อีกเรื่องหนึ่งในการ merge คือ คนใช้งานจะทำการ merge ผิด branch

เรื่องที่ห้าคือ การใช้งาน branch และ tag

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

เรื่องสุดท้ายคือ การ revert

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

จาก paper ตัวนี้ น่าจะทำให้เราเห็นว่า

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

Reference Website

https://medium.com/swlh/poor-practices-of-future-software-engineers-in-using-git-e42d37a12b72

เมื่อวันที่ 28-26 พฤษภาคมที่ผ่านว่า มีงาน Conference Online ของ Docker
ชื่อว่า DockerCon 2020 Live
ประกอบไปด้วย Speaker จำนวน 75 คน
มี session ต่าง ๆ เพียบถึง 57 session
ที่สำคัญทุก session ได้ทำการบันทึกและ upload ขึ้น web เรียบร้อย
ไปดูกันเลย

ตัวอย่าง VDO ที่น่าสนใจ ประกอบไปด้วย
Keynote เรื่อง Docker for Developers Now More Than Ever
ทำการ demo กันสด ๆ ไปเลยว่า Docker ใน version ล่าสุดนั้น
ช่วยให้ development team พัฒนาระบบงานได้ง่ายขึ้น
และพร้อมนำไป deploy บน Cloud

• การเริ่มต้นกับ Docker
• การใช้งาน Docker compose
• การใช้งาน Helm
• การสร้างและ deploy บน AWS
• การ Tracing
• การทำงานระหว่าง Dev และ Test สำหรับการจัดการ Database

ลองไปติดตามดูกันครับ เยอะมาก ๆ

ความต้องการ
ในการทำ performance testing ของระบบนั้น
มีเครื่องมือมากมายให้ใช้งาน ตัวที่ชอบใช้งานบ่อย ๆ คือ wrk
แต่ติดตรงที่ถ้าต้องการให้ dynamic หน่อย 
ก็ต้องเขียน script ด้วยภาษา Lua
ทำให้อาจจะลำบากขึ้นมานิดหน่อย

ความต้องการที่อยากได้คือ

• ทำการอ่านข้อมูลที่จะส่งไปในแต่ละ request จากไฟล์ CSV
• ส่งไปยังระบบที่ต้องการทดสอบ
• บันทึกผลการทดสอบลงไฟล์ CSV

เลยต้องมานั่งเขียน code กันนิดหน่อย

วิธีการก็ต้องเขียน Lua script

โดยที่ใน repository ของ wrk ก็มีตัวอย่างไว้ให้แล้ว
เพียงแค่ต้องมานั่งทำความเข้าใจกันหน่อย
ว่าในแต่ละ function มันทำงานตอนไหน แล้วเราจะต้องเขียนอะไร อย่างไร
ซึ่งก็ไม่ยากมากนัก ดังนี้

• function setup(thread) คือ function การ setup ข้อมูลต่าง ๆ ของแต่ละ thread จะถูกเรียกครั้งเดียวในแต่ละ thread
• function init(args) คือ function แรกที่จะถูกเรียกโดยส่ง arguments ต่าง ๆ จาก command line ของ wrk เข้ามา จะถูกเรียกครั้งเดียวในแต่ละ thread
• function request() คือ function ที่แต่ละ thread จะสร้างและส่ง request ไปยังระบบที่จะทดสอบ
• function response(status, headers, body) คือ function ที่จะรอรับ response กลับมาในแต่ละ request ที่ส่งออกไป
• function done() คือ function ที่ถูกเรียกครั้งเดียวเมื่อทำงานเสร็จสิ้นทั้งหมด

สามารถลองเขียน code เพื่อดูการทำงานง่าย ๆ ได้ดังนี้

คำว่า Thread และ Request แสดงด้วยภาพนี้น่าจะเข้าใจได้ง่ายสุด ๆ

เมื่อพอเข้าใจว่าแต่ละ function ทำงานอะไรแล้ว

ก็ลงมือเขียน code ตามที่การใช้งานดีกว่า

• อ่านข้อมูลจากไฟล์ CSV
• แต่ละ request ใช้ข้อมูลจากไฟล์ CSV ในแต่ละ row
• ส่วนของผลการทดสอบบันทึกลงไฟล์ CSV

เริ่มจากการอ่านข้อมูลจากไฟล์ CSV ออกมา

โดยจะกระจายข้อมูลแต่ละ row ไปยังแต่ละ request
ถ้าถึงบรรทัดสุดท้ายก็กลับมายัง row แรกวนไป
ในภาษา Lua นั้น index ของ array จะเริ่มที่ตำแหน่งที่ 1
ลองเขียนมั่ว ๆ ดูได้ประมาณนี้

จากนั้นในส่วนของผลการทดสอบที่ได้ทั้งหมด

ให้ทำการบันทึกลงไฟล์ CSV ก็เขียนข้อมูลที่ต้องการใน function done() ดังนี้

เพียงเท่านี้ก็สามารถใช้งานแบบง่าย ๆ แล้ว

มีดที่ไม่มีด้ามจับที่ดี มันจะใช้งานยากฉันใด
Dagger จึงต้องมี Hilt ฉันนั้น !!

ทางทีมพัฒนา Android ได้ปล่อย Hilt library ให้ใช้งาน
มาดูกันหน่อยว่า Dagger Hilt มีเป้าหมายและทำงานอย่างไร ?
และแตกต่างจาก Dagger Android อย่างไร ?

เป้าหมายหลัก ๆ ของ Hilt ประกอบไปด้วย

• ทำให้การใช้งานง่ายขึ้น ซึ่งทำการ gernerate Dagger component ต่าง ๆ  และ auto-inject ไปยัง Android class ให้เอง เหมือนกับ Spring Framework เลย
• ทำให้การจัดการ component ต่าง ๆ รวมทั้งการกำหนด scope การทำงานในรูปแบบที่เป็นมาตรฐาน
• ทำให้ code อ่านง่ายและเข้าใจง่ายขึ้น
• ลด code ขยะ ๆ ออกไปเยอะ
• ทำให้คนเริ่มต้นใช้งาน Dagger สบายขึ้น
• ที่ขาดไปไม่ได้คือ ช่วยให้การทดสอบง่ายขึ้นอีกด้วย เพราะว่า Hilt ทำการ generate Dagger component ที่เหมือนนกับ production ให้เลย และเราสามารถเปลี่ยนแปลงได้เองอีกด้วย เป็นส่วนที่ชอบมาก ๆ

ปล. เป็นการ generate code สำหรับสิ่งที่จะ generate code ต่อไป
อาจจะงง ๆ หน่อย แต่ก็พอเข้าใจได้

และแน่นอนว่ามีใน AndroidX package หรือ Jetpack นั่นเอง
ทำให้ทำงานร่วมกับพวก ViewMpdel และ WorkManager ได้

เพื่อความเข้าใจมาเริ่มต้นใช้งานกันหน่อย

เริ่มจากการ configuration เพื่อใช้งาน Hilt ใน Android project

เพิ่มที่ไฟล์ build.gradle ของ project

และเพิ่ม dependency ต่าง ๆ ใน app/build.gradle

มาลองใช้ความสามารถของ Hilt กันบ้าง ประกอบไปด้วย

• Dependency Injection ซึ่งสามารถนำ class ต่าง ๆ มาใช้งานใน Android class ได้เลย
• สามารถกำหนด scope ของ instance ต่าง ๆ ได้
• จัดการ Module ใน Hilt ทั้ง Provide, Scope และ Binding
• การทดสอบ ซึ่งทาง Hilt ได้เตรียม HiltAnddroidTest มาให้ใช้งาน จะทำการสร้าง Hilt component ของการทดสอบมาให้ รวมทั้งมี HiltAndroidRule สำหรับการจัดการ ccomponent และ state และ inject เข้ามาได้ในแต่ละ test

มาดูตัวอย่างง่าย ๆ ของ Depednency Injection กัน

เริ่มที่ class Application ของ project เขียนสั้น ๆ แบบนี้
เพื่อให้สามารถใช้งาน Hilt ได้ เป็นการสร้าง Container กลางไว้
สำหรับสร้าง instance ต่าง ๆ ไว้
รวมทั้งสามารถใช้งาน Depenendcy Injeccttion ได้แล้ว

จากนั้นทำการสร้าง class ทำงานนิดหน่อย

ในตัวอย่างคือ DateFormatter ดังนี้

จากนั้นใน class Activity/Fragment สามารถใช้งานได้

ด้วยการใส่ @AndroidEntryPoint เข้ามา
เพื่อให้ Hilt จัดการการสร้างแและใช้งาน instance ให้
แน่นอนว่าสาามารถ Inject Dateformatter มาใช้งานได้เลย 
ซึ่งการ Inject แบบนี้จะเรียกว่า Field Injection นั่นเอง ดังนี้

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

ข้อมูลเพิ่มเติม

• Cheat sheet ของ Hilt และ Dagger Annotation
• ตัวอย่าง code ในAndroid architecture sample
• CodeLabs :: Using Hilt in your Android app
• CodeLabs :: Migrate from Dagger to Hilt

ไปนั่งดูแนวทางในการเปลี่ยน banner ของการ start ระบบที่พัฒนาด้วย Echo
พอไปนั่งไล่ดู code และ issue เกี่ยวกับเรื่องนี้
ซึ่งมี Issue#1286 ทำเรื่องนี้
ก็เห็นแนวทางที่ทีมพัมนาเขาแนะะนำว่า
ไม่ต้องแก้ไขที่ตัว Echo นะ
เพียงแค่ทำการ disable banner ไปก่อน
จากนั้นก็ print สิ่งที่ต้องการเอง ก็เท่านั้นเอง
คิดอะไรให้มากมายไปทำไม
มานั่งคิดดี ๆ ก็ง่ายและสะดวกดีด้วยนะ

เลยบันทึกแนวคิดไว้เตือนตัวเองนิดหน่อย

เห็นข่าวว่าทาง GitHub จะเปลี่ยนชื่อ branch master ไปเป็นตัวอื่น
ดังนั้นเรามาเตรียมกันไว้ดีกว่า
ว่าถึงเวลาจะได้จัดการได้ง่ายขึ้น
ขั้นตอนเป็นดังนี้

เปลี่ยนชื่อจาก master เป็น main และ push ไปยัง GitHub repository

จากนั้นเข้าไปเปลี่ยน default branch เป็น main และ ลบ branch master ทิ้งไป

มีคำถามเกี่ยวกับการเข้าถึง element ต่าง ๆ
ใน User Interface ของการทดสอบพวก UI testing บน web browser 
ว่าจะทำอย่างไรดี ?

เนื่องจากทำการเข้าถึง element ด้วย xpath บ้าง
เข้าถึงด้วย css selector บ้าง
เข้าถึงด้วยการเขียน JavaScript บ้าง

เพราะว่า มีปัญหาของการทดสอบ จากการเปลี่ยนแปลงมาก ๆ

การแก้ไขเบื้องต้นคือ

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

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

• การกำหนด id ให้แต่ละ element ที่จะเข้าถึง และต้องเป็น unique id ด้วย
• ทำการกำหนด attribute ใหม่ขึ้นมา เพื่อใช้สำหรับการทดสอบ

มาดูจากเอกสารของ Cypress เรื่อง Best Practice กันบ้าง

มีคำแนะนำเกี่ยวกับการเข้าถึง element โดยแนะนำให้เพิ่ม attribute ใหม่ขึ้นมา
ชื่อขึ้นต้นด้วย data-* ไปเลย เพื่อใช้แยกออกมาจากส่วนของ UI อย่างชัดเจน
ว่าเป็น attribute ที่สร้างมาเพื่อการทดสอบเท่านั้น
น่าจะช่วยลดผลกระทบต่อการเปลี่ยน UI ได้

และเห็นว่ามี Cypress Testing Library ออกมาให้ใช้

โดยสามารถเพิ่ม attribute ชื่อว่า data-testid เข้ามาได้เลย
จากนั้นในชุดการทดสอบจะมี function cy.findByTestId() ให้ใช้งานเลย
ก็ง่ายขึ้นมาอีกเป็นกองเลยนะ

ความต้องการ
พอดีใช้คำสั่ง curl แล้วรู้สึกว่า มันเยอะ ๆ ไงไม่รู้
ก็เลยต้องการแปลงคำสั่งและ parameter ต่าง ๆ ที่ใช้ใน curl
ไปเป็น request ต่าง ๆ ใน Postman
เพื่อให้ง่ายต่อการใช้งานหน่อย

วิธีการ
เริ่มจากด้วยทาง postman team ได้สร้าง project ที่ชื่อว่า  curl to postman ให้
แต่ก็มีวิธีการที่ง่ายกว่า และ เพิ่งรู้คือ
การ import คำสั่ง curl เข้าไปยัง Postman แบบ Raw Text ได้เลย
ดังนี้

เพียงเท่านี้ก็ได้งานตามที่ต้องการแล้ว

จากการสอนและแบ่งปันการใช้งาน Docker ขึ้นพื้นฐาน
มีคำถามเกี่ยวกับเครื่องมือการจัดการ Docker
ที่เป็นแบบ User Interface ให้ใช้งานง่าย ๆ ไหม
ผมก็แนะนำไป 1 ตัวคือ Dashboard ใน Docker Desktop
แต่จริง ๆ แล้วมีเยอะเลย
ก็เลยทำการสรุปไว้นิดหน่อย
น่าจะมีประโยชน์สำหรับคนเริ่มต้นใช้งาน Docker

1. Portainer

ใช้งานผ่าน web browser

2. LazyDocker

ใช้งาน docker ผ่าน command-line หรือ terminal ไปเลย

3. Docker Station

ลองใช้งานกันดูครับ

Prisma คืออะไร ?

database toolkit ที่เป็น open source ประกอบไปด้วย 3 ส่วนคือ

• Prisma client คือเครื่องมือสำหรับสร้าง code ฝั่ง client แบบอัตโนมัติ (Node.js หรือ TypeScript)
• Prisma migrate (experimental) คือการทำ data model และ database migration ในแบบ declarative
• Prisma studio (experimental) เป็นระบบ GUI สำหรับดูและแก้ไขข้อมูลใน database

ที่น่าสนใจขึ้นไปอีกคือ Prisma client สามารถทำงานกับ API technology ต่าง ๆ ได้เช่น

• REST
• GraphQL
• Thrift
• gRPC

โดยที่ Prisma จะเข้ามาเติมเต็มในส่วนของ Data management

มีทั้งการใช้งาน database เช่นการใช้งาน ORM ต่าง ๆ
แต่ปัญหาของ ORM คือ ความซับซ้อนสูงขึ้น ตามระบบงานที่ใหญ่ขึ้น
ดังนั้นในแง่ของการดูแลยาว ๆ ไม่ดีแน่นอน

รวมทั้งเรื่องของ database migration ที่ไม่แยกออกไปจากเครื่องมือ
หรือใช้งานยาก
ทำให้ Prisma เข้ามาเติมเต็มในจุดนี้

ใน Prisma 2 จะมีความสามารถหลัก 2 ตัวคือ

1. Photon  คือเครื่องมือสร้าง database client code แบบอัตโมติ ที่สำคัญ Type-safe ด้วย

2. Lift คือเครื่องมือสำหรับ data model และ database migration

โดยเครื่องมือทั้งสองตัวเป็น command-line tool ทำงานแยกหรือรวมกันก็ได้
อยู่ที่ความต้องการของเราเลย

การเปลี่ยนแปลงของ Prisma จาก version 1 มา 2

โดยที่ Prisma core เขียนใหม่ด้วยภาษา Rust จากเดิมที่เขียนด้วยภาษา Scala
เหตุผลในการเปลี่ยนว่าด้วยเรื่อง 

• การใช้ memory
• ประสิทธิภาพการทำงานที่ดีขึ้น
• ง่ายต่อการ deploy และ monitoring

อธิบายไปไม่เข้าใจเท่ากับลงมือทำ

ดังนั้นมาลองใช้งานง่าย ๆ กัน โดยระบบที่ลองทำคือ Node.js ปกติ
ประกอบไปด้วย

• Express
• Sqlite database

มาเริ่มกัน

ก่อนอื่นทำการสร้าง project

และติดตั้ง module ที่จำเป็นดังนี้

จากนั้นทำการสร้างไฟล์ schema ของ data ที่เราจะใช้งาน (Prisma schema)

อยู่ในไฟล์ ./prisma/schema.prisma

• Database ที่ใช้งานคือ  Sqlite
• ทำการออกแบบ model หรือ table ใน database มี 2 ตัวคือ User และ Post ซึ่งมีความสันพันธ์กันด้วย

เมื่อสร้าง schema เรียบร้อยแล้ว

ต้องทำการ generate Prisma client ขึ้นมาจาก schema นั่นเอง
ด้วยคำสั่งดังนี้

แต่ว่าสิ่งที่ยังขาดไปคือ database และ table ต่าง ๆ ใน Sqlite ยังไม่มีเลย

ดังนั้นจำเป็นต้องสร้างขึ้นมา
ขั้นตอนนี้ Prisma ก็ได้เตรียม Prisma migrate database มาให้
สามารถทำได้ทั้งโครงสร้าง table และ ข้อมูลเลย

การใช้งานง่ายมาก ๆ
สามารถ run migrate ด้วยการระบุไฟล์ schema เท่านั้นเอง ดังนี้

เมื่อทุกอย่างเรียบร้อย ก็นำมาใช้ร่วมกับระบบงานของเรา
ซึ่งผมพัฒนา RESTFul API ด้วย express ดังนี้

เพียงเท่านี้ก็สามารถนำ Prisma มาใช้ในส่วนของการจัดการข้อมูลแบบง่าย ๆ ได้แล้ว

ทั้งการออกแบบ model ข้อมูล
ทั้งการ generate client code
ทั้งการ migrate database
เป็นสิ่งที่ใช้งานได้ง่ายดีและมีประโยชน์ ลองใช้งานกันดูครับ

Source code ตัวอย่างอยู่ที่ Github::up1

หลังจากที่ดู Firebase Live เรื่อง Unit testing security rules with the new Firebase emulator suite    
พบว่ามีกลายอย่างที่น่าสนใจมาก
ทั้ง Firebase emulator suite ที่เราสามารถใช้จำลอง Firebase ได้เลย
และสามารถเขียน test case สำหรับทดสอบการทำงานกับ Firebase emulator ได้อีก
ผ่าน library @firbase/testing ประกอบไปด้วย

• การทดสอบ security rule ว่าทำงานถูกต้องตามที่เรากำหนดหรือไม่
• การทดสอบการทำงานของระบบที่ทำงานร่วมกับ Realtime Database และ Firestore เป็นต้น

เรามาเรียนรู้ทีละตัวกันดีกว่า

เรื่องแรกคือ  Firebase emulator suite

เป็นการจำลอง environment ของ Firebase ขึ้นมาเลย
ทั้ง Realtime database, Firestore และ Remote config เป็นต้น

การทำงานคร่าว ๆ เป็นดังรูป

สามารถทำการ start ผ่าน Firebase CLI ได้เลย
เช่นทำการ start Firestore ขึ้นมา

ที่สำคัญจะมีส่วนของ Web UI มาให้ใช้งานด้วย

ใช้งานร่วมกับ Firebase CLI version 8.4.0 ขึ้นไปเท่านั้น ความสามารถประกอบไปด้วย

• จัดการข้อมูลของ Firestore และ Realtime database ได้เลย
• มี Log การทำงานให้

ทำการ start จะมี UI ดังนี้

เรื่องที่สองคือ การเขียน test case เพื่อทดสอบการทำงาน

เช่นการเขียน test เพื่อทดสอบ security rule
ยกตัวอย่างเช่น
security rule อนุญาตให้อ่านและเขียนข้อมูลใน Firestore 
ได้เฉพาะ request ที่ผ่านการ authenticate แล้วเท่านั้น

จากนั้นทำการเขียนชุดการทดสอบ

เพื่อตรวจสอบว่า security rule ที่เขียนมานั้น
ทำงานได้อย่างถูกต้องตามที่คาดหวังหรือไม่
ที่สำคัญสามารถเลือกไฟล์ security rule ได้อีกด้วย ดังนี้

ทำการ run test ได้ผลดังนี้

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

เรื่อง Generic ในภาษา Go น่าจะเป็นอีกหนึ่งเรื่องที่พูดถึงกกันมาก ๆ
โดย draft version ใหม่จะเอาแนวคิดของ contract ออกไป
จะเหลือเพียง type parameters
เนื่องจากทำให้เกิดความสับสนใจการใช้งาน
ถ้าใครต้องการทดลองใช้ความสามารถนี้ ทำได้ 2 วิธีคือ

• ทำการ build go จาก source เอง จาก tag ล่าสุด จะมี tool ชื่อว่า go2go ให้ใช้
• ใช้งานผ่าน Go2Go playground

หลังจากที่อ่าน specification ไปคร่าว ๆ
พบว่ามีเรื่องที่เข้าใจและสนใจดังนี้

1. เรื่องของ Generic คืออะไร ?

คือ function หรือ type ที่สามารถกำหนด type parameter ได้ จากเดิมที่เรามักจะประกาศ parameter ใน function เป็น type interface !! ทำให้การอ่าน code เข้าใจยาก รวมทั้งอาจจะต้องทำการตรวจสอบด้วยว่า สิ่งที่ส่งมานั้นมี type ตามที่เราต้องการ ก่อนนำมาใช้งานหรือไม่ ดังนั้น ถ้าทำการปรับปรุงตัวภาษา น่าช่วยทำให้ดีขึ้น
วิธีการอื่น ๆ ที่นำมาใช้ก่อนมี Generic ในภาษา Go เช่น

• Copy and paste code มาใช้งาน
• ใช้งาน interface ใน function
• ใช้ type assertion ทำงานร่วมกับ empty interface
• ใช้ reflection
• ใช้เครื่องมือพวก code generator

2. ลองใช้งานด้วยการเขียน code กันหน่อย ด้วย Generic ใน Go2Go playground

ในการอออกแบบจะมีส่วนต่าง ๆ ดังนี้

• Type parameters
• Multiple type paarameters
• Constraint
• Generic types

เยอะไปหมดเลย ลองอ่านเพิ่มเติมจาก link ของ specification ข้างต้นได้

มีโจทย์ง่าย ๆ เช่นการเพิ่มข้อมูลผลไม้เข้าไปยังตระกร้าสินค้า
สามารถเขียนแบบปกติได้ประมาณนี้

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

ยังสามารถประยุกต์ได้อีกเยอะ
แต่ก็ถือว่า เป็นอีกความสามารถหนึ่งที่เรียนรู้กันไว้ครับ

ไปเจอรูปนี้ใน Reddit มา น่าสนใจนะครับ

วันนี้เห็น theme ของ VS Code ชื่อว่า Slack Theme
ซึ่งจะทำให้ VS Code ของเราแสดงผลในรูปแบบของ program Slack
ลองติดตั้งและใช้แล้วสวยดี
ใครสนใจลองใช้งานดูครับ

สามารถเลือก Theme ได้เยอะ

แสดงผลดังนี้

ใน timelineใน Twitter ของ Deno
ทำการแนะนำ library เกี่ยวกับการทดสอบชื่อว่า Orange
จะมี decoration ให้ใช้งานง่ายขึ้น (ยังไม่มี code/test coverage เช่นเดิม)
น่าจะช่วยทำให้การทดสอบง่ายขึ้นกว่า Deno testing แบบเดิม
มาลองใช้งานกันดู

Software requirements

• Deno 1.1.2
• Orange 0.0.1

เริ่มต้นต้องทำการสร้างไฟล์ tsconfig.json สำหรับ Orange

ส่วนการเขียน test script สามารถใช้งาน Orange แบบง่าย ๆ ได้เลย

มี decoration @Test ให้ใช้งาน ซึ่งมี option หรือ attribute ดังนี้

• Name คือ ชื่อ test case
• Description คือ รายละเอียดของ test case
• Ignore test

ซึ่งจะมีตัวอย่างการเขียนดังนี้

การ run ก็ใช้ deno test เหมือนเดิม เพิ่มเติมคือ security ที่ต้องเปิดเพิ่มเติม

แสดงผลการทดสอบดังนี้

ลองใช้งานกันดูครับ
น่าจะเป็นอีกหนึ่งทางเลือกของการทดสอบระบบที่พัฒนาด้วย Deno

ว่าง ๆ มาลองพัฒนา API ด้วย Oak
Oak มันมาจาก Koa
และ Koa ก็มาจากทีมพัฒนา Express ใน Node.js นั่นเอง

โดยที่ Oak อธิบายว่า เป็น middleware framework สำหรับการพัฒนา HTTP server
ดังนั้นความสามารถหลัก ๆ จึงประกอบไปด้วย
Middleware ต่าง ๆ ตามรูปแบบของ express และ koa
รวมทั้งยังมี Application และ Context ให้ใช้งาน

ปล. ใช้แนวคิดการเขียนเดิมจาก Node.js มาได้เลย 

รูปแบบการเขียน code ไม่ได้ต่างจาก Express และ Koa มากนัก

อาจจะบอกว่า เหมือนกัน

มาใส่ router แบบง่าย ๆ กันหน่อย

หรือจะแยก router ออกมาให้สวยงามก็ทำได้เช่นกัน

โดยแยกไฟล์ route ออกกมา

มีไฟล์รวมทุก ๆ route ดังนี้

เพียงเท่านี้ก็สามารถพัฒนาระบบ API ได้ง่าย ๆ ด้วย Oak framework ได้แล้ว

และยังมีพวกการจัดการ Error ผ่าน middleware ให้เป็นปกติ
จัดการ static file ได้แน่นอน
ความเร็วถือว่าแจ่มเลย
ลองใช้งานกันดูครับ

เห็นว่า Deno นั้นพัฒนาด้วยภาษา Rust
แต่ก็ยังเขียน code ด้วยภาษา JavaScript ได้
ก็เลยอยากลองดูว่า
ถ้าเราเขียน Node.js โดยใช้ library/module ที่พัฒนาด้วยภาษา Rust แล้ว
มันน่าเร็วขึ้นกว่าเดิมไม่น้อย
ก็เลยลองค้นหาตัวอย่างและลองพัฒนาเล่น ๆ ดูหน่อย
มาเริ่มกันเลย

Software ที่ใช้ในการพัฒนา

• MacOS
• Rust และ Cargo สำหรับสร้าง library โดยผลที่ได้คือ Dynamic library (ไฟล์นามสกุล dylib)
• Node.js version 10 กับ FFI module (Foreign Function Interface) สำหรับ load Dynamic library ที่ได้จาก Rust

ปล. FFI module ทำงานได้กับ Node.js version 10 เท่านั้น ส่วน 12 และ 14 ใช้งานไม่ได้

ขั้นตอนที่ 1 เริ่มด้วยการสร้าง library ใน Rust ดังนี้

ทำการ build จะได้ไฟล์นามสกุล dylib ใน folder target/release

ขั้นตอนที่ 2 พัฒนาระบบด้วย Node.js version 10 เท่านั้น

พร้อมทั้งติดตั้ง FFI module ไปด้วย เขียน code
เพื่อ load dynamic library และใช้งาน ดังนี้

ทำการ run เพื่อดูผล จะเห็นว่า
การใช้ Dynamic library ที่สร้างด้วยภาษา rust นั้น
ทำงานเร็วกว่าถึง 6 เท่า

เป็นผลลัพธ์ที่น่าสนใจมาก ๆ
ลองศึกษากันดูครับ สนุกดี

Source code ตัวอย่างอยู่ที่ GitHub:Up1

Reference Websites

https://medium.com/paloit/speed-up-your-javascript-with-rust-7661922562fa
https://medium.com/@vinicius.ld/how-to-generate-a-webassembly-module-using-rust-and-node-js-e365d5157df

ทาง StackOverflow เขียนบทความและสรุป Q/A ต่าง ๆ ที่น่าสนใจในทุก ๆ สัปดาห์
โดยในสัปดาห์ที่ผ่านมา
มีบทความที่น่าสนใจเรื่อง DevOps
นั่นก็คือเรื่อง The rise of the DevOps mindset

มีคำที่น่าสนใจคือ DevOps เป็นคำที่หลาย ๆ คนเข้าใจไม่ตรงกัน
แต่ผลการสำรวจในต้นปี 2020 ของ StackOverflow 
บ่งบอกว่ามันมีความสำคัญต่อหลาย ๆ องค์กรอย่างมาก

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

เรื่องแรก What is DevOps and why is it so popular?

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

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

ความซับซ้อนที่มากมาย
บางครั้งมาจากปัญหาคอขวดในบางส่วนงาน
ก่อให้เกิดปัญหามากมายตามมา
โรคเลื่อนก็เกิดขึ้นบ่อย
ยิ่งเรื่องของคุณภาพยิ่งไม่ต้องพูดถึง ไปวัดกันบน production เลย !!

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

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

• ปรับปรุงการ deploy ให้บ่อยขึ้น
• ลดข้อผิดพลาดต่าง ๆ ลง
• ทันต่อความต้องการของตลาด

มีคำพูดที่น่าสนใจจาก CPO ของ StackOverflow คือ

The right DevOps culture ultimately makes the product you deliver better

เรื่องที่สอง Which problems is DevOps trying to solve?

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

• Communication
• Automation
• Measurement

มาดูสิ่งที่ DevOps พยายามแก้ไขให้ดีขึ้นกัน ประกอบไปด้วย 6 เรื่องดังนี้

1. From silos to One-team-thinking เรื่องนี้ยากมาก ๆ เพราะว่าบ่อยครั้งเรามักจะมีอีกทีมคือ DevOps ทีม ทำให้ปัญหาไม่หายไป ลด ละ เลิกการแยก แต่ให้มีการคิดและทำงานร่วมกัน เป้าหมายเดียวกัน บางคนมี KPI ควรใช้ร่วมหรือ share กัน
2. No more ‘hell month’ during releases ถ้าทำตามแนวคิด DevOps แล้วยังคงกลัวการ release ทุกครั้ง พังทุกครั้ง เป็นช่วงเวลาที่เครียดทุกว่า แบบนี้ไม่น่าจะได้นำแนวคิดมาใช้ แต่น่าจะเปลี่ยนแค่ชื่อ
3. Standardizing tech stacks and lazy paths เรื่องของเทคโนโลยีที่ใช้งานก็น่าสนใจ ควรมีแนวทางที่ชัดเจนว่าจะใช้อะไรบ้าง เพื่อให้ง่านต่อการเรียนรู้และการทำระบบ automation อีกด้วย
4. From finger pointing to feedback loops แทนที่จะบอกว่าใครผิด ตรงไหนผิด เปลี่ยนมาเป็น feedback loop ที่รวดเร็วดีกว่า feedback ที่ดีที่สุดคือ มาจากลูกค้าหรือผู้ใชงานจริง ๆ
5. Making friends with failure เรื่องความผิดพลาดกลายเป้นเรื่องปกติ แต่เรารู้ความผิดพลาดได้รวดเร็วเพียงใด เท่านั้นเอง และเรียนรู้ไปกับมัน
6. DevOps as self-service นี่คือเป้าหมายปลายทางคือ คนใช้งานสามารถใช้ได้เลย

เรื่องที่สามคือ Tools: What are the defining  tools?

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

จาก DevOps Tags Top 30 ใน StackOverflow ประกอบไปด้วย

สามารถสรุปได้ดังนี้

• การ tracking งาน มี Asana, Monday และ Jira
• การจัดการ source code มี Git, GitHub, GitLab, BitBucket และ TFS
• CI/CD มี Jenkins, Team City และ GitHub Actions
• การวิเคราะห์ Source code มี SonarQube
• การจัดการพวก Artifact ต่าง ๆ มี Artifactory และ Docker Container Registry
• Configuration management มี Terraform, Ansible, Puppet และ Chef
• การจัดการ container มี Docker และ Kubernetes
• การ monitoring มี Prometheus

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

มีคำถามเกี่ยวกับการเข้าถึง element ต่าง ๆ
ใน User Interface ของการทดสอบพวก UI testing บน web browser 
ว่าจะทำอย่างไรดี ?

เนื่องจากทำการเข้าถึง element ด้วย xpath บ้าง
เข้าถึงด้วย css selector บ้าง
เข้าถึงด้วยการเขียน JavaScript บ้าง

เพราะว่า มีปัญหาของการทดสอบ จากการเปลี่ยนแปลงมาก ๆ

การแก้ไขเบื้องต้นคือ

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

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

• การกำหนด id ให้แต่ละ element ที่จะเข้าถึง และต้องเป็น unique id ด้วย
• ทำการกำหนด attribute ใหม่ขึ้นมา เพื่อใช้สำหรับการทดสอบ

มาดูจากเอกสารของ Cypress เรื่อง Best Practice กันบ้าง

มีคำแนะนำเกี่ยวกับการเข้าถึง element โดยแนะนำให้เพิ่ม attribute ใหม่ขึ้นมา
ชื่อขึ้นต้นด้วย data-* ไปเลย เพื่อใช้แยกออกมาจากส่วนของ UI อย่างชัดเจน
ว่าเป็น attribute ที่สร้างมาเพื่อการทดสอบเท่านั้น
น่าจะช่วยลดผลกระทบต่อการเปลี่ยน UI ได้

และเห็นว่ามี Cypress Testing Library ออกมาให้ใช้

โดยสามารถเพิ่ม attribute ชื่อว่า data-testid เข้ามาได้เลย
จากนั้นในชุดการทดสอบจะมี function cy.findByTestId() ให้ใช้งานเลย
ก็ง่ายขึ้นมาอีกเป็นกองเลยนะ