Bypass หน้า Setup Wizard ของ Jenkins

ความตั้งใจจริง ๆ แค่อยากได้ jenkins ที่เป็น docker แล้วมี go install ไว้ให้แล้วเท่านั้น พอลอง compose up (ด้วย docker compose) jenkins ขึ้นมาก็เจอหน้าอย่างที่เคย ๆ เจอ คือ หน้า setup wizard พอลอง compose up ตัว jenkins บ่อย ๆ ก็รู้สึกว่า ต้องมานั่ง unlock jenkins ทุกครั้งด้วนยการเอา initialAdminPassword มากรอก เสร็จแล้วต้องไปเลือก plugin ที่อยากลงอีก ซึ่งกว่าจะลงเสร็จก็ใช้เวลาสักพัก ถัดมาต้องมาสร้าง account อีก กว่าจะเสร็จทุกขั้นตอนนี่โคตรเสียเวลาเลย เลยคิดว่า มันมีวิธีไหนมั่งที่สามารถข้ามขั้นตอนพวกนี้ไปได้ เป็นแบบ compose up เสร็จปุ๊บ พร้อมใช้เลย เลยกลายมาเป็นที่มาของการ bypass หน้า setup wizard ของ jenkins

อ่านต่อ »

ลองเอา 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 มาใช้

อ่านต่อ »

เข้าใจเหตุและผลด้วย Causal Loop Diagram (CLD)

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

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

อ่านต่อ »

Brooks’s Law

ในบริบทการพัฒนาซอฟต์แวร์ที่ feature ถูกกำหนดไว้แล้ว (fixed scope) และเวลาที่จะต้องส่งมอบก็ถูกกำหนดไว้แล้ว (fixed time) หลาย ๆ องค์กรยังคิดว่า การเพิ่มคนลงใน software project จะช่วยให้ project เสร็จเร็วขึ้น หรือเสร็จทันเวลาได้

Fred Brooks กล่าวไว้ในหนังสือ The Mythical Man-Month เกี่ยวกับ Software Project Management ว่า “adding human resources to a late software project makes it later”

อ่านต่อ »