33 điểm bởi GN⁺ 12 giờ trước | 8 bình luận | Chia sẻ qua WhatsApp
  • Trong mảng trình soạn thảo, Helix, Emacs, Neovim, Sublime Text, Zed và JetBrains IDE được nhắc đi nhắc lại, với trade-off của từng công cụ thể hiện rất rõ
  • Ở lĩnh vực quản lý phiên bản, xu hướng jujutsu(jj) thay thế git CLI nổi bật hẳn lên, bên cạnh đó còn có nhiều công cụ GUI hỗ trợ như Magit, lazygit, Sublime Merge
  • Với shell · terminal · quản lý môi trường, Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin, fzf... xuất hiện như một stack cốt lõi
  • Thông điệp lặp đi lặp lại là "hãy chọn công cụ có mặc định tốt để tránh cấu hình vô tận""càng lớn tuổi càng nên thích nghi với mặc định tốt thay vì uốn công cụ theo mình" (dù cũng có ý kiến phản đối)

Bối cảnh thảo luận

  • Chủ đề hỏi trên Lobsters: "Công cụ yêu thích nhất của lập trình viên là gì?" với mạch thảo luận rằng "lập trình viên thường có quan điểm rất mạnh, nên khó chọn ra chỉ một công cụ duy nhất"
  • Hơn 130 bình luận được đăng chỉ trong 19 giờ
  • Triết lý xuất hiện lặp lại: "càng lớn tuổi, tôi càng điều chỉnh sở thích của mình theo những công cụ có mặc định tốt thay vì bắt công cụ phải hợp với mình", "nhờ vậy ở trên con đường được kiểm thử nhiều nhất nên cũng gặp ít bug hơn"
    • Ý kiến ngược lại: "càng lớn tuổi càng ít kiên nhẫn với những mặc định tệ. Nếu không thể đưa nó vào trạng thái dùng được trong vài phút thì tôi đổi công cụ khác"

Trình soạn thảo văn bản / IDE

  • Helix

    • "điểm cân bằng hợp lý giữa khả năng tùy biến và trải nghiệm mặc định xuất sắc"
    • Khi dùng cùng jujutsu, sau khi chuyển commit cần tự tay reload các file đang mở — giải pháp tạm thời là gán phím cho :reload-all
    • PR về theo dõi file (#14544) đang được maintainer xử lý
    • Cũng có khá nhiều trường hợp không thích nghi được với mô hình selection-first nên quay lại vim
    • Fork hỗ trợ một phần keybinding của vim: evil-helix
  • Emacs

    • Nhiều người chỉ đơn giản trả lời là "Emacs"
    • Magit được khen ngợi nhiều đến mức được nhắc riêng
    • Dòng chuyển dịch quen thuộc theo từng mảng: Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired
  • Neovim

    • "Tôi đã cho .vimrc dùng hơn 10 năm nghỉ hưu và chuyển hẳn sang Neovim"
    • Xu hướng các bộ phân phối plugin:
      • LazyVim: hoàn thiện nhất, nên tắt keybinding của flash.nvim
      • AstroNvim: lựa chọn thay thế gọn nhẹ hơn
      • Kickstart.nvim: điểm khởi đầu đơn giản, thiên về tự tùy biến
      • MiniMax: config khởi đầu do nhóm mini.nvim tạo ra
  • JetBrains IDE

    • Rất khuyến nghị debugger của PyCharm — hoạt động cả trong Django REPL, hỗ trợ template HTML/CSS/JS, có thể cherry-pick từng hunk
    • Nếu dùng từ 2 sản phẩm JetBrains trở lên thì giấy phép All Products rẻ hơn
  • Sublime Text / Zed

    • "Sublime Text bị đánh giá thấp", có người nói dùng hằng ngày suốt hơn 20 năm
    • Dù code ở nơi khác thì hiệu năng nhanh, buffer chưa lưu vẫn tồn tại bền vững là lý do họ dùng mỗi ngày
    • Cũng xuất hiện xu hướng thử chuyển sang Zed vì VSCode ngày càng nặng nề
  • Kate / Notepad++

    • Kate ở phía Linux và Notepad++ ở phía Windows cũng được nhắc đến bằng các câu trả lời ngắn

Quản lý phiên bản

  • jujutsu (jj) — công cụ được gọi tên nhiều nhất năm nay

    • "Tôi không nghĩ mình sẽ bỏ git CLI, nhưng cuối cùng đúng là đã bỏ"
    • "Hiếm có công cụ nào vừa dễ hơn lại vừa mạnh hơn, nhưng jujutsu làm được cả hai"
    • Có nhận xét rằng rebase và commit amend trở nên thú vị hơn
    • Nhược điểm: mặc định chưa được trau chuốt, cần chỉnh color/template — mặc định bị ví như "đống chữ nôn cầu vồng kỳ lân tương phản cao"
  • Công cụ hỗ trợ Git

    • tig: "bản git log được cải tiến", dùng cho interactive staging
    • Magit: công cụ cốt lõi với người dùng Emacs
    • Sublime Merge: "lớp GUI cho git nhưng được làm cực kỳ tốt", cũng có thể tích hợp với jj qua merge-editor = "smerge"
    • lazygit: khiến người dùng mạnh dạn thử các thao tác phức tạp như rebase, revert, stash, nhiều remote
    • delta: khi đặt làm git pager sẽ có diff tô sáng cú pháp; kết hợp với lazygit có thể chuyển đổi side-by-side / inline
    • difftastic: diff dựa trên cú pháp thay vì từng dòng
    • git revise: "đáng lẽ phải được tích hợp sẵn trong git"
    • Beyond Compare: công cụ diff/merge/đồng bộ thư mục đã được dùng suốt 20 năm

Shell / terminal

  • Fish

    • "xử lý được mọi thứ mà bash·zsh làm, đồng thời mang lại trải nghiệm tuyệt vời mà gần như không cần cấu hình"
    • Khi cần vẫn có thể chạy nguyên các script bash
    • Được xem là công cụ khiến người dùng liên tục khám phá ra phím tắt mới (ví dụ: alt+<left|right> để đi lại trong lịch sử thư mục)
  • Trình giả lập terminal

    • WezTerm: copy/paste chỉ bằng bàn phím (ctrl+shift+space), nhân bản tab trên cùng hệ thống bằng ctrl+shift+t, có sẵn SSH client và multiplexer
    • Ghostty: tích hợp native với macOS — popover từ điển bằng Cmd+Ctrl+D, drag-and-drop, tab native, chất lượng render font
    • kitty: "mẫu mực của một công cụ tốt, nơi mặc định cứ thế mà chạy nhưng vẫn còn rất nhiều chỗ để cấu hình"
  • tmux

    • lệnh đầu tiên được chạy mỗi khi mở phiên terminal
    • Giúp chống việc SSH bị ngắt hoặc terminal bị đóng nhầm — vẫn giữ được cùng một thói quen dù chuyển qua lại giữa môi trường Mac và NixOS
  • Starship

    • Cắm được vào mọi shell, điểm trừ là các lệnh git status·branch chậm trên repo lớn

Quản lý môi trường / phụ thuộc

  • Nix / NixOS

    • "Có thể là Stockholm syndrome, nhưng nó khiến tôi không còn dùng nổi các bản phân phối Linux và hệ thống build khác"
    • Với nix shell theo từng dự án, có thể tối thiểu hóa package hệ thống và ghim đúng phiên bản mà không làm bẩn PATH toàn cục
    • "Mang lại mức độ tin tưởng rất cao rằng 1 năm sau, 5 năm sau nó vẫn chạy y như vậy"
    • "Chỉ cần vượt qua đường cong học tập thì nó gần như ma thuật. Việc cấu hình OS lẽ ra phải như thế này"
  • mise

    • Trình quản lý phiên bản công cụ thay thế direnv, còn tích hợp được vào CI nhẹ
    • "phương án thay thế tốt hơn hẳn cho asdf"
    • Khi phát hiện ra tính năng mise activate, có thể bỏ hẳn direnv
    • Với mise watch và hệ thống task, có thể gắn hành động theo từng dự án và chạy việc khi file thay đổi
  • Dev Containers

    • Ưu điểm là có thể dùng chung môi trường docker/container triển khai và môi trường dev
    • Nhược điểm: tooling còn non (CLI tham chiếu thậm chí còn chưa có lệnh stop)
  • chezmoi

    • Giúp duy trì môi trường phát triển nhất quán giữa máy công việc và máy cá nhân, quản lý luôn git alias, cấu hình Neovim, access token và cài đặt các công cụ khác

Gỡ lỗi / profiling

  • rr — debugger record/replay

    • "công cụ chủ lực để debug C/C++, chỉ cần ghi lại một lần là có thể phát lại vô hạn một cách tất định"
    • Có thể đặt watch theo địa chỉ bộ nhớ rồi tua ngược về lần ghi cuối cùng
    • "temporal debugging bisection" — kết hợp watchpoint để dò tới lui quanh điểm xảy ra hỏng bộ nhớ
  • Pernosco

    • Debugger có time-travel + phân tích luồng dữ liệu
    • Giúp rất nhiều trong xử lý focus của multi content process trên Firefox và công việc tương thích Chrome cho about:blank
  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: công cụ vạn năng cho debug đồ họa, các tính năng cơ bản còn tốt hơn debugger Metal của XCode
    • Tracy: "nếu làm profiler với tài nguyên vô hạn thì cuối cùng cũng sẽ thành Tracy"
    • RemedyBG: debugger có trải nghiệm thao tác rất tiện
  • XCode Instruments

    • Trong profiling shader 3D/GPU, cung cấp chú thích chi phí runtime theo từng dòng
    • Phân tích nguyên nhân stall — chờ nạp bộ nhớ, chờ đồng bộ, hay phân kỳ luồng điều khiển
    • "lợi thế của một hệ sinh thái kiểm soát được cả phần cứng, driver, ngôn ngữ shading Metal lẫn tooling"
  • Khác

    • strace, extrace, perf — bộ ba thiết yếu để gỡ lỗi
    • gdb — vẫn có nhiều người chỉ trả lời ngắn gọn như vậy

Tìm kiếm / xử lý văn bản

  • fzf: tích hợp tìm ngược lịch sử shell, "mức độ fuzzy vừa đủ"
    • Dùng mẫu rg '' | fzf để tìm toàn bộ văn bản trong repo; khi chọn kết quả khớp thì trả ngay về shell prompt ở dạng vim foo.rs +123
  • ripgrep: "hoạt động đúng ngay khi dùng, tôi chưa từng thấy cần phải cấu hình nó"
  • septum: tìm kiếm mã nguồn tương tác — ví dụ các điều kiện như "mọi dòng trong phạm vi 7 dòng phải chứa triangle·vertex·mesh nhưng loại trừ physics"
  • fastmod / spacemod: thay thế hàng loạt
  • autojump: dùng j whatevs để fuzzy match vào lịch sử thư mục làm việc trước đó rồi di chuyển
  • zoxide: tương tự autojump, điều hướng mượt hơn
  • awk: vẫn cực mạnh cho các việc kiểu "trích một ít rồi chỉnh một ít"
  • entr: "theo dõi các file này rồi chạy cái này" — rất hợp để tự động chạy test cho codebase

JSON / dữ liệu / công cụ chuyển đổi

  • jq: gần như là tiêu chuẩn thực tế cho xử lý JSON, khuyên nên đọc hết manual, và cũng gợi ý jq track của Exercism
    • gojq: thông báo lỗi vượt trội hẳn so với jq native, lại hỗ trợ input yaml nên vẫn tận dụng được muscle memory cũ
  • fx: drill-down các đầu ra JSON lớn
  • hexdump: đặc biệt hexdump -C hữu ích cho debug embedded — mẫu picocom --baud 115200 /dev/ttyUSB | hexdump -C
  • hexyl: trình xem hex có màu
  • bat: lựa chọn thay thế cho cat với syntax highlighting
  • choose, fd: lần lượt là lựa chọn thay thế cho cut và find

Lịch sử shell / clipboard / ghi chú

  • Atuin: đồng bộ lịch sử shell, tìm kiếm lịch sử theo ngữ cảnh thư mục·repo git
  • CopyQ: clipboard manager lưu khoảng 2000 mục, giúp khôi phục lại các tác vụ trước đó khi bỏ lỡ ghi chú
  • histprune: bản tùy biến Ctrl+R của fzf — nhấn alt+D để xóa ngay một mục lịch sử
  • Obsidian: chuyển từ Logseq sang, việc lưu bằng Markdown thuần có lợi cho cộng tác với LLM/agent
  • Joplin: AGPLv3, hỗ trợ app desktop·mobile·web, backend WebDAV/OneDrive/S3, lưu nguyên file .md

Build / tự động hóa công việc

  • just: thay thế make — tập trung vào task hơn là build, cung cấp giao diện nhất quán kiểu just lint không phụ thuộc ngôn ngữ
    • "có thể chuyển qua lại theo từng target giữa chế độ từng dòng như make và chế độ script đầy đủ bằng shell/python/node"
    • Nhược điểm: ghi script nhúng vào $TMPDIR rồi mới chạy, và dùng ngôn ngữ template riêng (gây cảm giác uncanny valley)
  • Task (go-task): phương án thay thế dựa trên yaml, thiên về batteries-included
  • universal-test-runner: tự phát hiện cách chạy test của repo rồi thực thi, hỗ trợ pass-through thêm đối số
  • chezmoi: quản lý nhất quán cả dotfile lẫn cài công cụ giữa các máy

HTTP / mạng / bí mật

  • Hurl: "hãy quên các ứng dụng HTTP GUI luôn muốn thu thập thông tin đi" — định dạng văn bản đơn giản cho các request kiểu curl, phù hợp với kiểm thử tích hợp
  • curl: cũng được nhiều người nhắc đến ngắn gọn
  • SOPS: mã hóa secret bằng age/SSH key, với mẫu sops exec-env secrets.yaml -- some command
  • Mutagen: đồng bộ file hai chiều theo thời gian thực qua SSH — hữu ích khi làm việc trên máy từ xa
  • forge: thay thế GitHub CLI, hỗ trợ Codeberg, nhanh hơn và gọn gàng hơn

Khác / quy trình làm việc

  • Quarto: làm slide nhanh bằng markdown
  • Nushell: shell chịu ảnh hưởng từ PowerShell, có thể viết đáng tin cậy các script chuyển đổi quy mô lớn như GeoPackage → PostGIS, PostGIS view → PMTiles. Nhược điểm: còn trước 1.0 nên hay vỡ sau mỗi lần cập nhật
  • Typst: được nhắc như lựa chọn thay cho LaTeX, với cú pháp dựa trên call-by-value được ưa thích
  • Topiary: formatter đa ngôn ngữ
  • Hunk: trình xem diff terminal review-first cho agentic coder, có kiểu dùng mở --watch cạnh coding agent
  • Raycast / Alfred: launcher cho macOS, có snippet·clipboard·tìm kiếm web tham số hóa
  • Ergodox EZ: bàn phím dùng suốt 10 năm, hài lòng cả về khả năng tùy biến lẫn điện năng
  • Joplin / Fossil: tự host ghi chú và wiki
  • AeroSpace / Sway: trình quản lý cửa sổ kiểu tiling

Những thông điệp meta lặp lại

  • "hãy chọn công cụ có mặc định tốt để tránh cấu hình vô tận" — Helix, Fish, ripgrep, mise được nêu như các ví dụ tiêu biểu cho triết lý này
  • Góc nhìn ngược lại: cũng có trường hợp sau khi tweak không ngừng đã hoàn thiện được hẳn một hệ công cụ riêng — "giờ tôi chỉ phải chỉnh vài lần mỗi năm"
  • Hệ quả của thời đại AI agent: ngày càng có nhận thức rằng jq, Markdown và các công cụ văn bản có cấu trúc rất phù hợp để cộng tác với LLM — Markdown thuần của Obsidian, chế độ watch của hunk, hay lời khuyên học kỹ manual của jq đều nằm trong cùng dòng chảy này
  • Ưu thế debug đồ họa của macOS: profiling GPU của XCode Instruments được đánh giá là vượt trội hẳn so với Linux/Windows
  • Phục hưng CLI vs typography: trong khi công cụ terminal ngày càng phong phú, nhiều người cũng quan sát rằng các đầu ra dài của LLM/agent rốt cuộc vẫn dễ đọc hơn trong trình duyệt hoặc ứng dụng chuyên dụng nhờ typography tốt hơn

8 bình luận

 
kirinonakar 25 phút trước

Tôi đã thử vài cái nhưng vẫn chưa có cái nào thực sự vừa ý, nên đang tự làm một cái. Tôi đang tham khảo notepad++, VS Code, Zed, Obsidian và chỉ lấy những tính năng cần thiết để tạo ra nó.

 

Dạo này tôi đang gộp 3 thứ là cmux, tmux và mux để dùng khá hiệu quả.
Khi SSH đăng nhập vào server được kết nối bằng tailscale, tôi dùng fzf để hiện gom các phiên đăng nhập tmux có sẵn, rồi chọn và vào từ đó.

cmux - Terminal cho macOS dựa trên Ghostty dành cho AI coding agent
Show GN: mux – Trình quản lý phiên tmux biến các phiên lập trình AI thành live preview

 

Trên macOS, nếu muốn nhập tiếng Hàn trong terminal thì chẳng phải phải nhấn Enter hai lần sao? (sau khi hoàn tất tổ hợp chữ Hàn thì phải nhấn 2 lần mới nhập được)
Chỉ có mỗi wezterm là không bị vấn đề này nên tôi đã chuyển sang dùng nó.

 
onixboox 3 giờ trước

Mình thích zed

 

Giờ tôi đã thành kiểu không thể sống thiếu Claude Code. + tmux..
Nói thêm thì có vscode làm trình soạn thảo văn bản..
Ngoài ra thì chắc chỉ đến mức IDE thiết yếu như Visual Studio để build..

 
hwhang0917 8 giờ trước

fzf, jq, rg, awk ❤️

 

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,

 
Ý kiến trên Lobste.rs
  • Tôi dùng Helix làm trình soạn thảo văn bản. Với tôi, nó cân bằng vừa đẹp giữa khả năng tùy biến và trải nghiệm mặc định rất tốt
    Vì lý do tương tự, tôi dùng Fish làm shell terminal. Mặc định đã rất ổn, hầu như không cần chỉnh gì để dùng theo ý mình
    Càng lớn tuổi, tôi càng thích điều chỉnh gu của mình theo những công cụ có mặc định được thiết kế tốt một cách có chủ đích, hơn là mải miết vọc cấu hình vô tận
    Atuin rất hay cho việc đồng bộ lịch sử shell giữa các máy từ xa và tìm kiếm lịch sử theo ngữ cảnh dựa trên thư mục hiện tại hoặc kho git. Nó còn nhiều tính năng khác nhưng tôi chỉ dùng mấy cái đó
    Tôi cũng rất thích Mise theo nhiều mặt, nhưng chủ yếu là như một trình quản lý phiên bản công cụ. Nó đã thay thế direnv trước đây của tôi, và tôi cũng bắt đầu tích hợp nó chút ít vào luồng CI nhẹ cho các dự án cá nhân

    • Đi theo con đường dùng mặc định tốt nghĩa là đi theo con đường được kiểm thử nhiều nhất, nên ít gặp lỗi hơn. Nhìn chung là lựa chọn khôn ngoan
    • Không phải chỉ có “điều chỉnh gu theo mặc định” và “vọc cấu hình vô tận”. Theo trải nghiệm n=1 của tôi, tôi đã chỉnh đi chỉnh lại mãi rồi cuối cùng cũng tới được điểm mình muốn, và giờ thì gần như không còn đụng vào nữa
      Mỗi năm chỉ vài lần thôi. Emacs của tôi giờ giống như hộp dụng cụ Studley của riêng mình
    • Tôi muốn thích Helix. Đây thật sự là một dự án rất bóng bẩy và các mặc định cũng hấp dẫn, nhưng trí nhớ cơ bắp kiểu Vim của tôi đã ăn quá sâu
      Thay vào đó, vài tháng trước tôi đã hoàn toàn chấp nhận Neovim và cho .vimrc đã lớn dần một cách hữu cơ suốt hơn 10 năm nghỉ hưu. Cũng hơi tiếc nhưng nhờ vậy tôi bớt ghen tị với Helix hơn
      Mise cũng rất tốt và thực tế gần như không cần cấu hình. Tôi cũng mới dùng Fish từ vài tháng trước, và ngoài vài hàm do người dùng tự viết ra thì hầu như vẫn để mặc định
      Ripgrep cũng làm “đúng việc cần làm” ngay từ đầu đến mức tôi còn không nhớ nổi mình đã từng thử cấu hình nó chưa
    • Nên học Helix thế nào để dùng cho ra hồn? Tôi đang cố rời khỏi Neovim vì cấu trúc kéo về hơn 50 kho lưu trữ do plugin gây ra khiến tôi quá lo về tấn công chuỗi cung ứng
    • Tôi cực kỳ đồng cảm với điều này. Càng lớn tuổi tôi càng không hiểu nổi những người cứ động vào công cụ và phần mềm nhiều đến thế. Vừa không vui vừa không đáng
  • Emacs

  • Có thể là hội chứng Stockholm, nhưng với tôi là Nix. Nó không hoàn hảo, nhưng một khi đã có thể làm việc với Nix theo cách giàu biểu đạt và hiệu quả hơn, nó gần như làm hỏng trải nghiệm của tôi với các bản phân phối Linux khác và các hệ thống meta build
    Nhân tiện, pwntools cũng là một công cụ rất vui để dùng cả ngoài CTF. Chẳng hạn như nghịch socket theo từng bit trong Python REPL cũng rất ổn

    • Tôi thích cả Nix lẫn pwntools. Là một người cũng chơi CTF, tôi tò mò nếu bạn có một môi trường pwn CTF dựa trên Nix thì bạn cấu hình nó thế nào
      Tôi thì lúc nào cũng bật một Ubuntu VM mới bằng libvirt rồi nhét công cụ vào đó để làm việc, nhưng nếu làm theo kiểu Nix thì có cách nào đáng khuyên không?
  • Emacs thì tất nhiên rồi, đặc biệt là Magit

  • Nix. Nó có đường cong học tập. Tôi đã ở quanh những người dùng hoặc truyền bá Nix vài năm rồi mới nghiêm túc thử, nhưng rốt cuộc nó khá tuyệt
    Làm nhiều dự án khiến tôi chán ngấy chuyện mỗi công cụ quản lý phụ thuộc cấp hệ thống lại một kiểu. Một cái cho phiên bản Node, một cái cho phiên bản Python, đại loại thế
    Tôi cũng mệt với các lỗi build khó debug do khác biệt không tương thích giữa các dự án. Kiểu như $foo hỏng trong Dự án A nên tôi cập nhật bằng Homebrew, xong giờ $foo lại hỏng trong Dự án B
    Cũng rất mệt với chuyện quy trình build dựa vào đủ loại phụ thuộc đã cài trong hệ thống, thường còn bị ẩn đi, khiến build thất bại “chẳng hiểu vì sao”
    Tôi đã chuyển mọi thứ có thể sang nix shell theo từng dự án. Gói cấp hệ thống thì giữ mỏng nhất có thể, còn trong dự án thì ghim chính xác những công cụ cần thiết như phụ thuộc, runtime, compiler, v.v.
    Nó không làm bẩn PATH toàn cục hay các dự án khác. Nếu bây giờ nó chạy được với tôi, tôi có mức tin tưởng khá cao rằng 1 năm hay 5 năm nữa nó vẫn chạy được
    Khi muốn nâng cấp công cụ, tôi cũng có thể làm mà không lo ảnh hưởng dự án khác, và nếu có hồi quy thì dễ dàng quay lại hoặc chỉ ghim một phụ thuộc cụ thể về phiên bản cũ hơn
    Với đồng nghiệp, các dự án dùng Nix cũng tốt hơn. Thời gian thêm vào để thiết lập và duy trì nix shell được chia sẻ, và độ chắc chắn rằng mọi người có cùng môi trường phát triển cũng cao hơn nhiều

    • Vì những lý do tương tự nên gần đây tôi rất mê Dev Containers. Tôi thấy ý tưởng này khá hay, nhưng tiếc là chất lượng công cụ chưa theo kịp
      Ví dụ ngay cả CLI chuẩn cũng còn chưa triển khai lệnh stop. Dù vậy, nếu bạn dùng Docker/container để triển khai thì có lợi thế là chia sẻ được khá nhiều cấu hình giữa môi trường phát triển và môi trường triển khai
      https://containers.dev/
      https://github.com/devcontainers/cli
  • rr(https://rr-project.org/) là kiểu phần mềm thần kỳ hay đến mức tôi không thể sống thiếu nó

    • Trước đây đây sẽ là công cụ tôi cần mỗi ngày. Phát hiện quá hay. Tôi định đưa nó vào bộ não thứ hai của mình để còn tìm lại được khi sau này cần đến
    • Tôi tò mò không biết bạn nhận được giá trị lớn nhất từ rr ở điểm nào? Tôi hiểu phần giới thiệu trên trang dự án ở mức khái quát
      Khái niệm ghi lại một lần thất bại rồi debug bản ghi đó một cách quyết định bao nhiêu lần cũng được rõ ràng nghe rất hữu ích
      Chỉ là tôi hỏi về trải nghiệm thực tế vì tôi vẫn chưa thật sự cảm được kiểu “wow, lỗi/quy trình làm việc cụ thể này mà không có rr thì chắc không thể giải quyết nổi”
  • Với nền tảng quản trị hệ thống, tôi gần hơn nhiều với kiểu “dùng mặc định tốt với cấu hình tối thiểu”. Nhưng gần đây có hai thứ làm tôi phá lệ
    jujutsu(jj) thì trang này cũng nói nhiều rồi, nhưng thành thật mà nói dùng nó rất sướng. Tôi không nghĩ mình sẽ bỏ git CLI, thế mà lại bỏ
    Tôi đã tránh học cách dùng và cấu hình nvim suốt nhiều năm, nhưng nvchad đã giúp tôi bắt đầu được. Tên thì kinh khủng, nhưng với tôi nó là một cấu hình khởi đầu tuyệt vời, vừa đủ có chính kiến mà vẫn tối giản
    Dĩ nhiên giờ thì tôi đã tự dùng cấu hình tối thiểu của riêng mình ngay từ đầu
    Ngoài ra, vì tôi dùng Python khá nhiều nên cũng phải nói rằng các công cụ của astral luôn mang lại trải nghiệm dễ chịu khi dùng. Mong là Anthropic sẽ chăm sóc họ tốt

    • jujutsu còn đúng gấp đôi. Ban đầu thì việc chuyển sang nó đã hay rồi, sau đó lại thấy mặc định của jj chưa thật sự được trau chuốt lắm nên lại phải chỉnh thêm một lượt nữa
      Nếu không dùng kiểu chữ giống “cầu vồng kỳ lân nôn mửa” tương phản cao cổ điển trên nền tối, thì bạn sẽ phải chỉnh màu và template khá nhiều
  • Thật ra là Emacs. Tôi đang dần chuyển từng phần công việc dùng máy tính của mình sang Emacs và bắt đầu chấp nhận các mặc định của nó
    Emacs rất dễ tùy biến, và nhiều tổ hợp phím trong mọi mode đều làm những việc phù hợp
    Danh sách tôi đang chuyển dần sang là Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired
    Quarto cũng khá tốt khi cần làm slide nhanh bằng Markdown. Tôi dùng Nix và nix-darwin cho toàn bộ dotfiles

    • Với mục đích dùng dired thì có thể nên xem qua Dirvish
  • Emacs. Dù không dùng thường xuyên, nhưng viết parser bằng ragel rất vui

  • Sublime Text chắc chắn đang bị quá nhiều người đánh giá thấp

    • Tôi từng muốn thích Sublime Text, nhưng chế độ vi của nó không khớp đủ với trí nhớ cơ bắp tôi có từ Vim nên tôi không gắn bó được
      Hình như nó tên là “vintage” gì đó. Giờ thì trong những tình huống trước đây tôi muốn thích Sublime Text, tôi dùng Zed