ลองเอา Cotton ขึ้น Homebrew ด้วย Tap

หลังจากเมื่อวานลองเอา cotton ขึ้น homebrew ไม่สำเร็จ ทาง commitay ซึ่งเป็น member ของ homebrew ก็มา comment ใน pull request ที่ถูก reject ซึ่งเป็นอะไรที่น่าสนใจดี เขาเขียนว่า

ลองเอา cotton ขึ้น homebrew ครั้งแรก

จั่วหัวไว้ว่าครั้งแรก แปลได้เลยว่าไม่สำเร็จ แต่ได้เรียนรู้อะไรหลายอย่างจากการลอง รวมถึงเหตุผลว่าทำไมถึงไม่ได้ เริ่มจากทำ cotton ด้วย go แล้วอยาก install cotton ได้ด้วยคำสั่ง brew install cotton มันน่าจะสะดวกไม่น้อย ไม่ต้องมาเสียเวลา go get https://github.com/chonla/cotton บางคนไม่มี go อีกต้องมานั่ง install go เองอีก

ลองใช้ caddy ทำ https server บน docker

ทำ Cotton มาสักพัก อยากจะเพิ่ม feature ให้มันสามารถทดสอบกับ HTTPS ที่มัน verify cerificate ไม่ได้ (เช่น https://localhost หรือ self-signed cert) แต่ไม่รู้จะไปหา site ไหนที่มี cert แบบนั้นมาลอง อะกิแนะนำ server ตัวนึงที่ชื่อ caddy มาให้ เลยเอามาลองใช้กับ project ที่เป็น headless cms เดิมอยู่ดู

ลอง Clojure ครั้งแรกกับแบบฝึกหัด Budget List

ไปเรียน Coding Professional กับ Josepth กับ Jackson มา มีโจทย์หนึ่งเรียกว่า Budget ที่เขาให้เป็นมาลองทำด้วยวิธี pair programming เลยไปจับคู่กับอะกิ แล้วใช้ภาษา golang พอทำเสร็จก็คุยกันได้ความว่า ถ้าเอาใช้กับ map-reduce จะสวยกว่านี้อีก พี่รูฟเลยชวนให้ลองเอามาเขียนเป็น functional programming ด้วย clojure ซึ่งแน่นอน ไม่เคยเขียนเลยสักครั้ง ไม่แม้จะรู้จัก syntax มัน เลยเอามาลองกัน

อย่ายัดเยียดความคิดตัวเองลงไปในงานลูกค้า

เวลาเราเก็บ requirement จากลูกค้ามา โปรแกรมเมอร์โบราณมักจะทำสิ่งที่เรียกว่า คิดเองเออเองเสมอว่าลูกค้าอยากได้อะไร พอทำบ่อย ๆ มันก็กลายเป็นมาตรฐานระหว่างลูกค้า กับโปรแกรมเมอร์ไป พอเป็นมาตรฐานกันบ่อย ๆ ก็จะตั้งชื่อเล่นเท่ ๆ ให้กับมาตรฐานที่ทึกทักกันขึ้นมาเองว่า common sense โดยตอนที่ทำงานกันหลาย ๆ คนเนี่ย ไอ้ common sense แต่ละคนมันไม่เคยจะเหมือนกัน

อย่าดูถูกตัวเองด้วยการลดคุณภาพของสิ่งที่ทำ

หลังจากที่ได้อ่านเรื่องของพี่โอเกี่ยวกับเบอร์เกอร์กระรอก ก็ทำให้นึกถึงเรื่องที่เคยคิดว่าจะจดไว้ในนี้ แต่ไม่ได้ทำสักที เริ่มเลยละกัน หลาย ๆ องค์กรมีทีม IT ที่คอยพัฒนาซอฟต์แวร์ให้ทั้งผู้ใช้ที่เป็นลูกค้าภายนอก รวมถึงผู้ใช้ที่เป็นพนักงานภายในบริษัทเอง โดยตั้งโจทย์แบบเดียวกันกับเรื่องของเบอร์เกอร์กระรอก คือ “จะเอาทั้งหมด” ภายใต้ resource ที่มีอยู่อย่าง “จำกัด” (คำว่า resource ในที่นี้ หมายถึง resource ทุกอย่าง ยกเว้น คน เพราะคนไม่ใช่ resource) ปัญหาที่ตามมาคือ การใช้ secret toolbox ไม่ว่าจะเป็นการสร้าง smell ลงไปในของที่ตัวเองทำ การไปก๊อปปี้โค้ดมาจากอินเตอร์เน็ตโดยไม่ได้สนใจว่ามันคืออะไร ทำงานยังไง การไม่ทำความเข้าใจโค้ดที่ทีมเขียนหรือไม่ทำให้โค้ดที่ตัวเองเขียนอ่านง่ายขึ้น และที่สำคัญคือ การไม่เขียนเทสต์

สร้าง LEMP stack ด้วย docker

อยากทำ dev environment สำหรับทำเว็บที่ไม่กระทบกับ environment ของเครื่องที่ใช้อยู่ โดยมีของที่อยากได้คือ linux, nginx, mariadb และ php (LEMP) จริง ๆ จะเป็น linux, apache, mysql และ php (LAMP) ก็ได้ แต่เอา nginx มาใช้แทนเพราะอยากหัดด้วย ส่วน mariadb เห็นว่า performance ดีกว่า mysql เลยเลือก mariadb ตั้งโจทย์ไว้แบบนี้เลยมอง ๆ เรื่องเอา docker มาใช้

Migrate jasmine ไปใช้ jest ใน Angular 6

อะกิมาบอกว่า jest น่าสนใจดีนะ จำได้ว่ามีคนเคยชวนไปใช้ jest แต่ตอนนั้นก็ยังไม่ได้สนใจอะไร ตอนนี้พอมีเวลาก็เลยมาลองซะหน่อย มี project ทดสอบอยู่ตัวนึงที่เอาไว้ใช้สอน robot คือ ng-calculator ซึ่งเดิมใช้ jasmine อยู่ เดี๋ยวจะมาลองเปลี่ยนเป็น jest ดู

เขียน test บน go ด้วย testify

จริง ๆ ใน golang มี package ชื่อ testing อยู่ ใช้ตัวนั้นก็ได้ ตรงไปตรงมาดี ความซับซ้อนก็จะเริ่มมาตอนที่เราอยากจะทำอะไรที่ยากขึ้น เช่น การทำ test double หรือการเปรียบเทียบ struct 2 ตัว ซึ่งจริง ๆ แล้วเราสามารถเอาพวก reflect มาใช้เปรียบเทียบ struct ได้ ส่วนการทำ test double ก็จะซับซ้อนกว่านั้น

โชว์ Code Coverage ของ Angular Project ใน Github

เข้าไปเห็น repo ใน github ของหลาย ๆ คน เขาแสดง code coverage เป็น badge แล้วมันดูเท่ไม่หยอก ที่สำคัญมันออโต้ด้วย ไม่ต้องมานั่งพิมพ์เองหลังจาก run unit test เสร็จว่า code coverage เราเท่านี้แล้วนะ ให้มันอัพเดทโดยอัตโนมัติดีกว่า จิ้ม ๆ ดูเห็นเขาใช้ service ของ codecov.io เลยไปลองมั่งดีกว่า จริง ๆ วิธีนี้ใช้กับ provider เจ้าอื่นได้ด้วย ไม่ใช่แค่ github พวก bitbucket, gitlab ก็ได้นะ