เครื่องมือนักพัฒนาที่คุณชอบคืออะไร?

 (lobste.rs)
33 คะแนน โดย GN⁺ 12 시간 전 | 8 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในหมวด เอดิเตอร์ มีการพูดถึง Helix, Emacs, Neovim, Sublime Text, Zed และ JetBrains IDE ซ้ำๆ โดยแต่ละตัวก็มี trade-off ที่ชัดเจน
  • ในด้าน การจัดการเวอร์ชัน กระแสการใช้ jujutsu(jj) แทน git CLI โดดเด่นมาก และยังมีเครื่องมือ GUI เสริมอย่าง Magit, lazygit, Sublime Merge ถูกกล่าวถึงจำนวนมาก
  • ในหมวด เชลล์·เทอร์มินัล·การจัดการสภาพแวดล้อม มี Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin, fzf ฯลฯ เป็นสแต็กหลัก
  • ข้อความสำคัญที่ถูกพูดซ้ำคือ "เลือกเครื่องมือที่มีค่าเริ่มต้นที่ดีเพื่อหลีกเลี่ยงการตั้งค่าไม่รู้จบ" และ "ยิ่งอายุมากขึ้นก็ยิ่งปรับตัวเข้ากับค่าเริ่มต้นที่ดี แทนที่จะพยายามดัดเครื่องมือให้เข้ากับตัวเอง" ซึ่งเป็นฉันทามติหลัก (แม้จะมีความเห็นคัดค้านด้วย)

พื้นหลังของการสนทนา

  • เธรดคำถามบน Lobsters ว่า "เครื่องมือที่นักพัฒนาชอบที่สุดคืออะไร?" พร้อมความเห็นว่า "นักพัฒนามักมีความเห็นแรงกล้า จึงยากที่จะเลือกเครื่องมือเพียงตัวเดียว"
  • มีคอมเมนต์มากกว่า 130 รายการภายใน 19 ชั่วโมง
  • ปรัชญาที่โผล่ซ้ำๆ คือ "ยิ่งอายุมากขึ้นก็ยิ่งปรับความชอบของตัวเองให้เข้ากับเครื่องมือที่มีค่าเริ่มต้นดี แทนที่จะดัดเครื่องมือให้เข้ากับตัวเอง", "ทำให้ได้อยู่บนเส้นทางที่ผ่านการทดสอบมาดีที่สุด จึงเจอบั๊กน้อยลง"
    • ความเห็นฝั่งตรงข้าม: "ยิ่งอายุมากขึ้นก็ยิ่งทนกับค่าเริ่มต้นที่แย่ได้น้อยลง ถ้าทำให้พร้อมใช้งานไม่ได้ภายในไม่กี่นาที ก็เปลี่ยนเครื่องมือทันที"

เอดิเตอร์ข้อความ / IDE

  • Helix

    • "จุดสมดุลที่เหมาะระหว่างความสามารถในการปรับแต่งกับประสบการณ์ใช้งานเริ่มต้นที่ยอดเยี่ยม"
    • เมื่อใช้ร่วมกับ jujutsu หลังสลับ commit แล้ว ไฟล์ที่เปิดอยู่ต้อง reload เอง — วิธีชั่วคราวคือผูกปุ่ม :reload-all
    • ฟีเจอร์เฝ้าดูไฟล์อยู่ระหว่างทำ PR(#14544) โดย maintainer
    • หลายคนปรับตัวกับ โมเดลแบบ selection-first ไม่ได้ จึงกลับไปใช้ vim
    • มีฟอร์กที่รองรับ vim keybinding บางส่วน: evil-helix

  • Emacs

    • มีผู้ใช้จำนวนมากที่ตอบสั้นๆ แค่ว่า "Emacs"
    • Magit ได้รับคำชมมากจนถูกพูดถึงแยกต่างหาก
    • กระแสการย้ายงานตามหมวดก่อนหน้า: Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired

  • Neovim

    • "เลิกใช้ .vimrc ที่ใช้มานานกว่า 10 ปี แล้วเปลี่ยนมาใช้ Neovim เต็มตัว"
    • กระแสของปลั๊กอินดิสทริบิวชัน:
      • LazyVim: สมบูรณ์ที่สุด แนะนำให้ปิด flash.nvim keybinding
      • AstroNvim: ทางเลือกที่เพรียวกว่า
      • Kickstart.nvim: จุดเริ่มต้นแบบเรียบง่ายสำหรับคนที่อยากปรับแต่งเอง
      • MiniMax: config เริ่มต้นที่ทีม mini.nvim ทำขึ้น

  • JetBrains IDE

    • แนะนำ debugger ของ PyCharm อย่างมาก — ใช้ได้แม้ใน Django REPL, รองรับ template HTML/CSS/JS และ cherry-pick hunk ได้
    • ถ้าใช้ผลิตภัณฑ์ JetBrains ตั้งแต่ 2 ตัวขึ้นไป ไลเซนส์ All Products จะคุ้มกว่า

  • Sublime Text / Zed

    • มีความเห็นว่า "Sublime Text ถูกประเมินค่าต่ำเกินไป" และมีคนบอกว่าใช้ทุกวันมานานกว่า 20 ปี
    • แม้จะไปเขียนโค้ดที่อื่น แต่ยังใช้ทุกวันเพราะ ความเร็วสูงและ unsaved buffer ที่คงอยู่ถาวร
    • ยังมีแนวโน้มที่คนพยายาม ย้ายไปใช้ Zed เพราะ VSCode ใหญ่เทอะทะเกินไป

  • Kate / Notepad++

    • มีการพูดถึง Kate ฝั่ง Linux และ Notepad++ ฝั่ง Windows แบบตอบสั้นๆ เช่นกัน

การจัดการเวอร์ชัน

  • jujutsu (jj) — เครื่องมือที่ถูกเรียกชื่อบ่อยที่สุดในปีนี้

    • "ไม่คิดว่าจะเลิกใช้ git CLI ได้ แต่สุดท้ายก็เป็นแบบนั้น"
    • "หาเครื่องมือที่ทั้งง่ายกว่าและทรงพลังกว่าไปพร้อมกันได้ยาก แต่ jujutsu ทำได้ทั้งคู่"
    • มีคนบอกว่า rebase และ commit amend กลายเป็นเรื่องสนุก
    • ข้อเสีย: ค่าเริ่มต้นยังขัดเกลาไม่พอ ต้องปรับ color/template เอง — ค่าเริ่มต้นถูกเปรียบว่าเป็น "ตัวอักษรอ้วกยูนิคอร์นสีรุ้งคอนทราสต์จัด"

  • เครื่องมือเสริมสำหรับ Git

    • tig: "git log เวอร์ชันปรับปรุง" ใช้สำหรับ interactive staging
    • Magit: แกนหลักของผู้ใช้ Emacs
    • Sublime Merge: "เป็น GUI layer ของ git ที่ทำออกมาได้ดีมาก" และยังผสานกับ jj ได้ผ่าน merge-editor = "smerge"
    • lazygit: ทำให้คนกล้าลองงานซับซ้อนอย่าง rebase, revert, stash และหลาย remote มากขึ้น
    • delta: เมื่อใช้เป็น git pager จะได้ diff แบบ syntax-highlighted และเมื่อใช้กับ lazygit ยังสลับ side-by-side / inline ได้
    • difftastic: diff ตาม syntax แทนที่จะเป็นรายบรรทัด
    • git revise: "ควรเป็นส่วนหนึ่งของ git มาตั้งแต่แรก"
    • Beyond Compare: เครื่องมือ diff/merge/sync โฟลเดอร์ที่มีคนใช้มายาวนาน 20 ปี

เชลล์ / เทอร์มินัล

  • Fish

    • "ทำทุกอย่างที่ bash·zsh ทำได้ พร้อมมอบประสบการณ์ที่ยอดเยี่ยมโดยแทบไม่ต้องตั้งค่า"
    • หากจำเป็นก็ยังรัน bash script เดิมได้ตรงๆ
    • ถูกมองว่าเป็นเครื่องมือที่ทำให้ค้นพบคีย์ลัดใหม่ได้เรื่อยๆ (เช่น alt+<left|right> สำหรับประวัติไดเรกทอรี)

  • เทอร์มินัลอีมูเลเตอร์

    • WezTerm: คัดลอก/วางด้วยคีย์บอร์ดล้วน (ctrl+shift+space), โคลนแท็บในระบบเดียวกันด้วย ctrl+shift+t, มี SSH client และ multiplexer ในตัว
    • Ghostty: ผสานกับ macOS แบบเนทีฟ — มีป๊อปโอเวอร์พจนานุกรมด้วย Cmd+Ctrl+D, drag-and-drop, native tabs และคุณภาพการเรนเดอร์ฟอนต์ดี
    • kitty: "เป็นตัวอย่างของเครื่องมือที่ค่าเริ่มต้นใช้งานได้ดีทันที แต่ก็ยังเปิดพื้นที่ให้ปรับแต่งได้มาก"

  • tmux

    • เป็นคำสั่งแรกที่รันทันทีเมื่อเปิดเทอร์มินัลเซสชัน
    • ช่วยรับมือกรณี SSH หลุดหรือปิดเทอร์มินัลพลาด — และยังคงรูปแบบการทำงานเดิมได้แม้สลับระหว่าง Mac กับ NixOS

  • Starship

    • ใช้เป็นปลั๊กอินได้กับทุกเชลล์ แต่ข้อเสียคือคำสั่ง git status·branch ช้าบน repo ขนาดใหญ่

การจัดการสภาพแวดล้อม / dependency

  • Nix / NixOS

    • "อาจเป็น Stockholm syndrome ก็ได้ แต่ทำให้กลับไปใช้ Linux distro และระบบ build อื่นแทบไม่ได้"
    • ใช้ nix shell แยกตามโปรเจกต์ เพื่อลดแพ็กเกจระดับระบบ และ ล็อกเวอร์ชันได้อย่างแม่นยำ โดยไม่ทำให้ global PATH สกปรก
    • "มั่นใจได้สูงว่าผ่านไป 1 ปีหรือ 5 ปีก็ยังทำงานเหมือนเดิม"
    • "ถ้าผ่านเส้นโค้งการเรียนรู้ไปได้ มันเหมือนเวทมนตร์ นี่แหละคือวิธีที่การตั้งค่า OS ควรเป็นตั้งแต่แรก"

  • mise

    • ตัวจัดการเวอร์ชันเครื่องมือที่มา แทน direnv และยังผสานเข้ากับ CI แบบเบาๆ ได้
    • "เป็นตัวแทนของ asdf ที่ดีกว่าแบบชัดเจน"
    • เมื่อค้นพบฟีเจอร์ mise activate ก็สามารถลบ direnv ออกได้หมด
    • ใช้ mise watch และระบบ task เพื่อกำหนด action ต่อโปรเจกต์และรันงานเมื่อไฟล์เปลี่ยน

  • Dev Containers

    • ข้อดีคือสามารถ แชร์ สภาพแวดล้อม docker/container ระหว่าง deployment กับ development ได้
    • ข้อเสีย: tooling ยังไม่สุกพอ (reference CLI ยังไม่มีแม้แต่คำสั่ง stop)

  • chezmoi

    • ใช้คง สภาพแวดล้อมพัฒนาให้สม่ำเสมอ ทั้งเครื่องที่ทำงานและเครื่องส่วนตัว พร้อมจัดการ git alias, config ของ Neovim, access token และการติดตั้งเครื่องมืออื่นๆ

การดีบัก / โปรไฟลิง

  • rr — record/replay debugger

    • "เป็นเครื่องมือหลักสำหรับดีบัก C/C++ บันทึกครั้งเดียวแล้วเล่นซ้ำแบบกำหนดแน่นอนได้ไม่จำกัด"
    • สามารถ watch ที่อยู่หน่วยความจำ แล้ว ย้อนกลับไปยังจุดที่มีการเขียนครั้งล่าสุด ได้
    • "temporal debugging bisection" — ใช้ watchpoint เพื่อไล่หาจุดที่ memory corruption เริ่มเกิดขึ้นแบบเดินหน้าและถอยหลัง

  • Pernosco

    • debugger แบบ time-travel + วิเคราะห์ data flow
    • ช่วยอย่างมากกับงาน focus handling ของ multi-content process ใน Firefox และงานทำให้ about:blank เข้ากันได้กับ Chrome

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: เครื่องมือสารพัดประโยชน์สำหรับดีบักกราฟิก โดยฟีเจอร์พื้นฐานดีกว่า XCode Metal debugger
    • Tracy: "ถ้าจะสร้าง profiler แบบมีทรัพยากรไม่จำกัด สุดท้ายมันก็จะออกมาเหมือน Tracy"
    • RemedyBG: debugger ที่ใช้งานลื่นไหลสะดวกมาก

  • XCode Instruments

    • ให้ คำอธิบายต้นทุน runtime ระดับต่อบรรทัด ในงานโปรไฟลิง 3D/GPU shader
    • ช่วย วิเคราะห์สาเหตุของ stall — แยกได้ว่าเกิดจากรอ memory fetch, รอ synchronization หรือ control flow divergence
    • "เป็นข้อดีของ ecosystem ที่ควบคุมทุกอย่างได้ตั้งแต่ฮาร์ดแวร์ ไดรเวอร์ ภาษา Metal shading ไปจนถึง tooling"

  • อื่นๆ

    • strace, extrace, perf — ชุดเครื่องมือจำเป็นสำหรับการดีบัก
    • gdb — ยังถูกพูดถึงแบบสั้นๆ จากหลายคน

การค้นหา / ประมวลผลข้อความ

  • fzf: ใช้รวมกับการค้นหาย้อนประวัติใน shell และมีความเห็นว่า "ระดับความ fuzzy พอดีมาก"
    • ใช้แพตเทิร์น rg '' | fzf เพื่อค้นหาข้อความทั้ง repo และเมื่อเลือกแมตช์แล้วจะส่งกลับไปที่ shell prompt ในรูปแบบ vim foo.rs +123 ทันที
  • ripgrep: "ทำงานได้ถูกต้องตั้งแต่แกะกล่อง และไม่เคยคิดจะตั้งค่าอะไรเพิ่มเลย"
  • septum: การค้นหาโค้ดแบบโต้ตอบได้ — เช่นค้นหาเงื่อนไขว่า "ภายใน 7 บรรทัดต้องมีทั้ง triangle·vertex·mesh แต่ต้องไม่มี physics"
  • fastmod / spacemod: ใช้แทนที่จำนวนมาก
  • autojump: ใช้ j whatevs เพื่อย้ายไปยังไดเรกทอรีที่เคยทำงานผ่าน fuzzy matching จากประวัติ
  • zoxide: คล้าย autojump แต่การนำทางลื่นกว่า
  • awk: ยังทรงพลังมากกับงานประเภท "ดึงออกมานิดหน่อยแล้วแต่งต่ออีกนิด"
  • entr: "คอยดูไฟล์พวกนี้แล้วรันสิ่งนี้" — เหมาะกับการรันทดสอบโค้ดเบสอัตโนมัติ

JSON / ข้อมูล / เครื่องมือแปลง

  • jq: มาตรฐานโดยพฤตินัยสำหรับการจัดการ JSON และมีคำแนะนำให้ อ่าน manual ให้จบ รวมถึงแนะนำ jq track ของ Exercism
    • gojq: มีข้อความ error ดีกว่า native jq อย่างมาก และ รองรับ input แบบ yaml ทำให้ใช้ muscle memory เดิมได้
  • fx: ใช้ drill down กับผลลัพธ์ JSON ขนาดใหญ่
  • hexdump: โดยเฉพาะ hexdump -C มีประโยชน์มากกับการดีบัก embedded — แพตเทิร์นอย่าง picocom --baud 115200 /dev/ttyUSB | hexdump -C
  • hexyl: ตัวดู hex แบบมีสี
  • bat: ตัวแทน cat ที่มี syntax highlighting
  • choose, fd: ใช้แทน cut และ find ตามลำดับ

ประวัติเชลล์ / คลิปบอร์ด / โน้ต

  • Atuin: ซิงก์ประวัติ shell และค้นหาประวัติจากบริบทไดเรกทอรี·git repo
  • CopyQ: ตัวจัดการคลิปบอร์ดราว 2000 รายการ ช่วยกู้คืนงานเก่าเมื่อพลาดจดอะไรบางอย่าง
  • histprune: การปรับแต่ง Ctrl+R ของ fzf — กด alt+D เพื่อลบรายการประวัติได้ทันที
  • Obsidian: ย้ายมาจาก Logseq โดยมองว่า Markdown ล้วน เหมาะกับการทำงานร่วมกับ LLM/agent มากกว่า
  • Joplin: AGPLv3 รองรับแอปเดสก์ท็อป·มือถือ·เว็บ ใช้ backend ได้ทั้ง WebDAV/OneDrive/S3 และเก็บเป็นไฟล์ .md ตรงๆ

การ build / งานอัตโนมัติ

  • just: ตัวแทนของ make — โฟกัสที่งาน task มากกว่างาน build และให้ interface ที่สม่ำเสมอแบบไม่ผูกกับภาษา เช่น just lint
    • "สามารถสลับระหว่างโหมดแบบ make ที่ทำงานทีละบรรทัด กับโหมด shell/python/node แบบเต็มสคริปต์ได้ราย target"
    • ข้อเสีย: เขียน embedded script ลง $TMPDIR ก่อนแล้วค่อยรัน และใช้ภาษา template ของตัวเอง (ให้ความรู้สึก uncanny valley)
  • Task (go-task): ทางเลือกแบบ yaml ที่มีแนว batteries-included
  • universal-test-runner: ตรวจจับวิธีรันทดสอบของ repo อัตโนมัติแล้วสั่งรัน พร้อมส่ง args เพิ่มผ่านต่อได้
  • chezmoi: จัดการ dotfile และการติดตั้งเครื่องมือให้สม่ำเสมอข้ามหลายเครื่อง

HTTP / เครือข่าย / ความลับ

  • Hurl: "ลืมแอป GUI HTTP ที่พยายามเก็บข้อมูลของคุณไปได้เลย" — ใช้ฟอร์แมตข้อความเรียบง่ายสำหรับคำขอแบบ curl และเหมาะกับ integration test
  • curl: มีคนพูดถึงแบบสั้นๆ จำนวนมาก
  • SOPS: เข้ารหัส secrets ด้วย age/SSH key และใช้แพตเทิร์น sops exec-env secrets.yaml -- some command
  • Mutagen: ซิงก์ไฟล์แบบสองทางเรียลไทม์ ผ่าน SSH — มีประโยชน์มากกับงานบนเครื่องระยะไกล
  • forge: ตัวแทน GitHub CLI ที่รองรับ Codeberg และทำงานได้เร็วกว่าเป็นระเบียบกว่า

อื่นๆ / เวิร์กโฟลว์

  • Quarto: ทำพรีเซนเทชันได้เร็วด้วย markdown
  • Nushell: เชลล์ที่ได้รับอิทธิพลจาก PowerShell ใช้เขียนสคริปต์แปลงข้อมูลขนาดใหญ่ เช่น GeoPackage → PostGIS, PostGIS view → PMTiles ได้อย่างเชื่อถือได้ ข้อเสียคือยังไม่ถึง 1.0 จึงพังได้ทุกครั้งที่อัปเดต
  • Typst: ถูกพูดถึงในฐานะตัวแทนของ LaTeX โดยชอบไวยากรณ์แบบ call-by-value
  • Topiary: formatter สำหรับหลายภาษา
  • Hunk: ตัวดู terminal diff แบบ review-first สำหรับ agentic coder โดยมีแพตเทิร์นเปิดโหมด --watch ไว้ข้างๆ coding agent
  • Raycast / Alfred: launcher บน macOS รองรับ snippet·clipboard·การค้นหาเว็บแบบใส่พารามิเตอร์
  • Ergodox EZ: คีย์บอร์ดที่ใช้มานาน 10 ปี และพอใจทั้งด้านการปรับแต่งและพลังงาน
  • Joplin / Fossil: ใช้ self-hosting สำหรับโน้ตและวิกิ
  • AeroSpace / Sway: tiling window manager

ข้อความเมตาที่วนซ้ำ

  • "เลือกเครื่องมือที่มีค่าเริ่มต้นที่ดีเพื่อหลีกเลี่ยงการตั้งค่าไม่รู้จบ" — Helix, Fish, ripgrep, mise มักถูกยกเป็นตัวอย่างของปรัชญานี้
  • มุมมองตรงข้าม: บางคนก็สร้างชุดเครื่องมือของตัวเองจากการ tweak ไม่รู้จบได้สำเร็จ — "ตอนนี้แตะปีละไม่กี่ครั้งเท่านั้น"
  • ผลพลอยได้จากยุค AI agent: มีการรับรู้เพิ่มขึ้นว่าเครื่องมืออย่าง jq·Markdown·structured text เอื้อต่อการทำงานร่วมกับ LLM — เช่น Markdown ล้วนของ Obsidian, โหมด watch ของ hunk และคำแนะนำให้เรียนรู้ manual ของ jq ก็อยู่ในกระแสเดียวกัน
  • ความได้เปรียบด้านกราฟิกดีบักของ macOS: มีความเห็นว่า GPU profiling ใน XCode Instruments เหนือกว่า Linux/Windows อย่างชัดเจน
  • ยุคฟื้นคืนของ CLI vs ตัวอักษรที่อ่านง่าย: แม้เครื่องมือบนเทอร์มินัลจะอุดมสมบูรณ์ขึ้น แต่ผลลัพธ์ยาวๆ จาก LLM/agent ก็ยังอ่านสบายกว่าบนเบราว์เซอร์หรือแอปเฉพาะทางในแง่ typography

บทความที่เกี่ยวข้อง

8 ความคิดเห็น

 
kirinonakar 23 분 전

ลองใช้มาหลายตัวแล้ว แต่ยังไม่มีตัวไหนที่ถูกใจแบบเป๊ะ ๆ เลย เลยกำลังทำขึ้นมาใช้เองอยู่ อ้างอิงจาก notepad++, VS Code, Zed, Obsidian แล้วดึงมาเฉพาะฟีเจอร์ที่จำเป็นครับ
 
xguru 10 시간 전

ช่วงนี้ผมใช้ cmux, tmux และ mux ควบคู่กันอยู่บ่อย ๆ ครับ
พอ ssh เข้าไปยังเซิร์ฟเวอร์ที่เชื่อมไว้ด้วย tailscale ก็จะใช้ fzf แสดงรายการเซสชัน tmux ที่ล็อกอินค้างไว้รวมกัน แล้วเลือกเข้าไปจากตรงนั้นครับ

cmux - เทอร์มินัลสำหรับ macOS บนพื้นฐาน Ghostty สำหรับ AI coding agent
Show GN: mux – ตัวจัดการเซสชัน tmux ที่เปลี่ยน AI coding session ให้เป็น live preview
 
edunga1 2 시간 전

บน Mac ถ้าจะพิมพ์ภาษาเกาหลีในเทอร์มินัล ปกติต้องกด Enter สองครั้งไม่ใช่เหรอครับ? (หลังประกอบอักษรเกาหลีเสร็จ ต้องกดอีก 2 ครั้งกว่าจะป้อนเข้าไปได้)
มีแค่ wezterm เท่านั้นที่ไม่มีปัญหานี้ เลยย้ายมาใช้ครับ
 
onixboox 3 시간 전

ชอบ zed
 
snisty 5 시간 전

ตอนนี้ฉันกลายเป็นคนที่อยู่ไม่ได้ถ้าไม่มี Claude Code ไปแล้ว + tmux..
ถ้าจะเพิ่มอีกก็คือ vscode เป็นตัวแก้ไขข้อความ..
ไม่งั้นก็ประมาณ IDE จำเป็นอย่าง Visual Studio สำหรับใช้ build..
 
hwhang0917 8 시간 전

fzf, jq, rg, awk ❤️
 
jjpark78 10 시간 전

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,
 
GN⁺ 12 시간 전
ความคิดเห็นจาก Lobste.rs

  • ผมใช้ Helix เป็น text editor สำหรับผมมันสมดุลพอดีระหว่างความสามารถในการปรับแต่งกับประสบการณ์ใช้งานเริ่มต้นที่ยอดเยี่ยม
    ด้วยเหตุผลเดียวกัน ผมใช้ Fish เป็น terminal shell ค่าเริ่มต้นมันดีมากอยู่แล้ว และแทบไม่ต้องปรับอะไรเพื่อให้ใช้งานได้อย่างที่ต้องการ
    ยิ่งอายุมากขึ้น ผมยิ่งชอบปรับรสนิยมของตัวเองให้เข้ากับเครื่องมือที่มีค่าเริ่มต้นดีแบบตั้งใจ มากกว่าจะไปนั่งจูนไม่รู้จบ
    Atuin เหมาะมากสำหรับการซิงก์ประวัติ shell ระหว่างเครื่องรีโมตและการค้นหาประวัติแบบมีบริบทตามไดเรกทอรีปัจจุบันหรือ git repository ฟีเจอร์อื่นก็มี แต่ผมใช้แค่นี้
    ผมก็ชอบ Mise ในหลายด้าน แต่ชอบมันที่สุดในฐานะตัวจัดการเวอร์ชันของเครื่องมือ มันมาแทน direnv ที่เคยใช้ และในโปรเจ็กต์ส่วนตัวก็เริ่มเอาไปผสานกับ flow แบบ CI เบา ๆ บ้างแล้ว

    • เส้นทางที่ยึดตามค่าเริ่มต้นที่ดีมักเป็นเส้นทางที่ถูกทดสอบมามากที่สุด จึง เจอบั๊กน้อยกว่า โดยรวมแล้วเป็นทางเลือกที่ฉลาด
    • มันไม่ได้มีแค่ “ปรับรสนิยมให้เข้ากับค่าเริ่มต้น” กับ “จูนไม่รู้จบ” เท่านั้น จากประสบการณ์ n=1 ของผมคือผมจูนแล้วจูนอีกจูนอีกจนสุดท้ายไปถึงจุดที่ต้องการ และตอนนี้แทบไม่แตะแล้ว
      ปีหนึ่งมีไม่กี่ครั้ง Emacs ของผมตอนนี้เหมือน กล่องเครื่องมือ Studley ฉบับส่วนตัว
    • ผมอยากจะชอบ Helix มาก มันเป็นโปรเจ็กต์ที่ลื่นไหลมากและค่าเริ่มต้นก็น่าสนใจ แต่ผมมี muscle memory ของ Vim สะสมไว้เยอะเกินไป
      แต่เมื่อไม่กี่เดือนก่อนผมยอมรับ Neovim เต็มตัวแล้ว และปลดระวาง .vimrc ที่ค่อย ๆ เติบโตมาแบบอินทรีย์กว่าสิบปี มันก็แอบเสียดายนิดหน่อย แต่ก็ทำให้ผมอิจฉา Helix น้อยลง
      Mise ก็ดีมาก และแทบไม่ต้องตั้งค่าอะไรเลยจริง ๆ Fish เองผมก็เพิ่งเริ่มใช้เมื่อไม่กี่เดือนก่อน และนอกจาก user function ไม่กี่ตัวก็ใช้ค่าเดิมแทบทั้งหมด
      Ripgrep ก็เป็นอีกตัวที่ทำ “สิ่งที่ถูกต้อง” ได้เลยตั้งแต่แรก จนผมไม่แน่ใจด้วยซ้ำว่าเคยลองปรับแต่งมันไหม
    • ถ้าจะใช้ Helix ให้เป็นจริง ๆ ควรเรียนยังไง? ผมกำลังพยายามหนี Neovim เพราะโครงสร้างที่ดึง repository ของปลั๊กอินมามากกว่า 50 ตัวทำให้กังวลเรื่อง supply-chain attack มากเกินไป
    • เห็นด้วยกับประโยคนี้มาก พออายุมากขึ้น ผมยิ่งไม่ค่อยเข้าใจคนที่ชอบไปยุ่งกับเครื่องมือและซอฟต์แวร์ขนาดนั้น มันไม่สนุกและไม่คุ้มค่า

  • Emacs

  • อาจจะเป็น Stockholm syndrome แต่ของผมคือ Nix มันไม่สมบูรณ์แบบหรอก แต่พอทำงานได้อย่างแสดงออกได้มากขึ้นและมีประสิทธิภาพขึ้นด้วย Nix แล้ว มันก็ทำให้ Linux distro อื่นกับ meta build system อื่น ๆ เสียรสชาติไปเลย
    ขอเสริมว่า pwntools ก็เป็นเครื่องมือที่สนุกมากแม้นอกโลก CTF เช่น ใช้เล่นกับ socket ระดับบิตจาก Python REPL ก็ยังได้

    • ผมก็ชอบทั้ง Nix และ pwntools ในฐานะคนเล่น CTF เหมือนกัน ผมสงสัยว่าถ้าคุณมี สภาพแวดล้อม CTF pwn ที่อิง Nix คุณจัดมันยังไง
      ปกติผมจะเปิด libvirt Ubuntu VM ใหม่ทุกครั้งแล้วติดตั้งเครื่องมือทำงานในนั้น ไม่ทราบว่ามีแนวทางแบบใช้ Nix ที่แนะนำไหม?

  • แน่นอนว่าต้อง Emacs โดยเฉพาะ Magit

  • Nix มี learning curve อยู่บ้าง ผมอยู่ใกล้ผู้ใช้ Nix หรือพวกนักเผยแพร่มันมาหลายปี กว่าจะลองจริงจังก็ใช้เวลา แต่สุดท้ายมันดีมาก
    พอทำหลายโปรเจ็กต์ ผมเริ่มเบื่อที่เครื่องมือจัดการ dependency ระดับระบบมีหลายตัวกระจัดกระจาย ตัวหนึ่งไว้จัดการเวอร์ชัน Node อีกตัวไว้จัดการเวอร์ชัน Python อะไรทำนองนั้น
    และก็เบื่อกับ build failure ที่ debug ยากเพราะความไม่เข้ากันระหว่างโปรเจ็กต์ เช่น $foo พังใน Project A เลยอัปเดตผ่าน Homebrew แล้วสุดท้าย $foo ก็ไปพังใน Project B แทน
    ยังมีความน่าปวดหัวจากกระบวนการ build ที่พึ่ง dependency หลายตัวที่ติดตั้งอยู่ในระบบ ซึ่งมักซ่อนอยู่ ทำให้ build fail แบบ “ไม่รู้ทำไม” อีกด้วย
    ผมย้ายทุกอย่างที่ทำได้ไปอยู่ใน nix shell รายโปรเจ็กต์ แพ็กเกจระดับระบบทำให้บางที่สุดเท่าที่จะทำได้ ส่วนในโปรเจ็กต์ก็ pin เครื่องมือที่ต้องใช้ทั้งหมดไว้ ทั้ง dependency, runtime, compiler และอื่น ๆ ให้ตรงเวอร์ชัน
    มันไม่ไปทำให้ global PATH หรือโปรเจ็กต์อื่นปนเปื้อน ถ้าตอนนี้มันใช้ได้บนเครื่องผม ผมก็มั่นใจพอสมควรว่ามันจะยังใช้ได้อีกในอีก 1 ปีหรือ 5 ปีข้างหน้า
    เวลาจะอัปเกรดเครื่องมือก็ทำได้โดยไม่ต้องกังวลว่าจะกระทบโปรเจ็กต์อื่น และถ้ามี regression ก็ย้อนกลับได้ง่าย หรือจะ pin แค่ dependency ตัวเดียวให้เป็นเวอร์ชันเก่าก็ได้
    สำหรับโปรเจ็กต์ที่เพื่อนร่วมทีมใช้ Nix ด้วยก็ยิ่งดี เวลาเพิ่มขึ้นในการตั้งค่าและดูแล nix shell ถูกแชร์กัน และทุกคนก็มั่นใจได้มากขึ้นว่าสภาพแวดล้อมพัฒนาเหมือนกัน

    • ด้วยเหตุผลคล้ายกัน ช่วงนี้ผมอินกับ Dev Containers มากเหมือนกัน ผมว่าแนวคิดมันดีมาก แต่น่าเสียดายที่คุณภาพเครื่องมือยังตามไม่ทัน
      ตัวอย่างเช่น แม้แต่ CLI มาตรฐานยังไม่มีการ implement คำสั่ง stop เลย ถึงอย่างนั้นถ้าคุณใช้ Docker/containers สำหรับ deployment อยู่แล้ว ข้อดีคือสามารถแชร์การตั้งค่าระหว่างสภาพแวดล้อมพัฒนากับสภาพแวดล้อม deploy ได้เยอะ
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/) เป็นซอฟต์แวร์ที่ดีราวกับเวทมนตร์จนขาดไม่ได้

    • ถ้าเป็นเมื่อก่อน นี่คงเป็นเครื่องมือที่ผมต้องใช้ทุกวัน เจอของดีเลย แบบนี้ผมจะเก็บใส่ second brain ไว้ เผื่อวันหลังต้องใช้จะได้หาเจอ
    • อยากรู้ว่าจุดที่คุณได้คุณค่ามากที่สุดจาก rr คืออะไร? ผมเข้าใจคำอธิบายภาพรวมในหน้าแรกของโปรเจ็กต์อยู่แล้ว
      แนวคิดที่ว่าบันทึกความล้มเหลวไว้ครั้งหนึ่ง แล้วกลับมาดีบักบันทึกนั้นแบบกำหนดผลได้ซ้ำ ๆ ก็ดูมีประโยชน์ชัดเจน
      แต่ที่ถามถึงประสบการณ์จริงก็เพราะผมยังนึกภาพไม่ออกในระดับว่า “ว้าว บั๊ก/เวิร์กโฟลว์เฉพาะแบบนี้ คงแก้ไม่ได้แน่ถ้าไม่มี rr”

  • ผมมาจากสายผู้ดูแลระบบ เลยใกล้กับแนว “ใช้ค่าเริ่มต้นที่ดีด้วยการตั้งค่าน้อยที่สุด” มากกว่า แต่ช่วงหลังมีสองอย่างที่ทำให้ผมเปลี่ยนนิสัย
    jujutsu(jj) มีคนพูดถึงบนเว็บนี้เยอะแล้ว แต่พูดตรง ๆ ว่ามันใช้งานสนุกมาก ผมไม่คิดเลยว่าจะเลิกใช้ git CLI ได้ แต่ก็เป็นไปแล้ว
    ตลอดหลายปีที่ผ่านมา ผมเลี่ยงการเรียนรู้และตั้งค่า nvim มาโดยตลอด แต่ nvchad ทำให้ผมเริ่มได้ แม้ชื่อจะชวนสยอง แต่สำหรับผมมันเป็นชุดตั้งต้นที่ดีมาก มีความเห็นชัดกำลังพอดีบนฐานของความมินิมอล
    แน่นอนว่าตอนนี้ผมก็เขียน minimal config ของตัวเองใหม่ตั้งแต่ต้นแล้ว
    นอกนั้นเพราะผมใช้ Python ค่อนข้างเยอะ ก็ต้องบอกว่าเครื่องมือจาก astral ก็ใช้อย่างสม่ำเสมอแล้วรู้สึกดี หวังว่า Anthropic จะดูแลมันดี ๆ

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

  • ที่จริงคือ Emacs ผมค่อย ๆ ย้ายงานคอมพิวติ้งของตัวเองเข้าไปอยู่ใน Emacs และเริ่มยอมรับค่าเริ่มต้นของมัน
    Emacs ปรับแต่งได้ง่ายมากจริง ๆ และ key binding หลายอย่างก็ทำสิ่งที่เหมาะสมในทุกโหมด
    รายการที่กำลังค่อย ๆ ย้ายมี Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired
    Quarto ก็ใช้ทำสไลด์พรีเซนต์จาก Markdown ได้เร็วดีมาก ผมใช้ Nix และ nix-darwin กับ dotfiles ทั้งหมด

    • ถ้าใช้ dired ลองดู Dirvish ได้

  • Emacs ถึงจะไม่ได้ใช้บ่อย แต่การเขียน parser ด้วย ragel เป็นเรื่องที่เพลิดเพลิน

  • Sublime Text นี่ชัดเจนเลยว่าถูกประเมินต่ำเกินไปโดยคนจำนวนมาก

    • ผมอยากจะชอบ Sublime Text แต่ vi mode ของมันเข้ากับ muscle memory ที่สั่งสมจาก Vim ได้ไม่พอ เลยปักหลักไม่ได้
      น่าจะชื่อประมาณ “vintage” อะไรสักอย่าง ทุกวันนี้ในสถานการณ์ที่เมื่อก่อนผมน่าจะอยากชอบ Sublime Text ผมใช้ Zed แทน