お気に入りの開発者ツールは何ですか？

 (lobste.rs)
33 ポイント 投稿者 GN⁺ 12 시간 전 | 8件のコメント | WhatsAppで共有
  • エディタ分野では Helix、Emacs、Neovim、Sublime Text、Zed、JetBrains IDE が繰り返し言及され、それぞれの trade-off が明確に表れている
  • バージョン管理分野では jujutsu(jj) が git CLI を置き換える流れが目立ち、Magit・lazygit・Sublime Merge のような GUI 補助ツールも多数挙がっている
  • シェル・ターミナル・環境管理では Fish、WezTerm、Ghostty、kitty、tmux、Nix、mise、atuin、fzf などが中核スタックとして登場
  • 繰り返し現れるキーメッセージは 「デフォルトが良いツールを選び、終わりのない設定を避けよう」 と 「年齢を重ねるほど、ツールを自分に合わせるより良いデフォルトに自分が適応する」 という合意（反対意見もあり）

議論の背景

  • Lobsters に投稿された「開発者が最も好きなツールは？」という質問スレッド。「開発者は意見が強いので、たった1つのツールを挙げるのは難しい」
  • 19時間で130件以上のコメントが付いた
  • 繰り返し現れた哲学: 「年齢を重ねるほど、ツールを自分に合わせるより、良いデフォルトを持つツールに自分の好みを合わせる」、「最もよくテストされた道を進むことになり、バグにも遭いにくい」
    • 反対意見: 「年齢を重ねるほど、悪いデフォルトへの忍耐力がなくなる。数分で使える状態にできないなら別のツールに替える」

テキストエディタ / IDE

  • Helix

    • 「カスタマイズ性と優れた初期体験のちょうど良いバランス」
    • jujutsu と併用すると、コミット切り替え後に開いていたファイルを手動で reload する必要がある — 暫定対応として :reload-all キーバインドを使用
    • ファイル監視機能の PR(#14544) がメンテナーによって進行中
    • selection-first モデルに適応できず vim に戻る例も多い
    • vim キーバインドを一部サポートするフォーク: evil-helix

  • Emacs

    • 単に「Emacs」とだけ答えたユーザーが多数
    • Magit は別途言及されるほど高評価
    • 分野別の移行例: Git → Magit、Email → mu4e、RSS → elfeed、Notes/TODO/Calendar → org-mode、Finder → dired

  • Neovim

    • 「10年以上使った .vimrc を引退させ、Neovim に完全移行した」
    • プラグインディストリビューションの流れ:
      • LazyVim: 最も完成度が高い、flash.nvim のキーバインドは無効化推奨
      • AstroNvim: よりスリムな代替
      • Kickstart.nvim: カスタマイズ前提のシンプルな出発点
      • MiniMax: mini.nvim チームが作った開始用 config

  • JetBrains IDE

    • PyCharm のデバッガーを強く推す声 — Django REPL の内部でも動作し、テンプレートの HTML/CSS/JS をサポートし、hunk 単位の cherry-pick も可能
    • JetBrains 製品を2つ以上使うなら All Products ライセンスの方が安い

  • Sublime Text / Zed

    • 「Sublime Text は過小評価されている」、20年以上毎日使っているという声
    • コーディングは別の場所でしていても、高速さと永続的な unsaved buffer が毎日使う理由
    • VSCode が肥大化し、Zed への移行を試す流れも見られる

  • Kate / Notepad++

    • Linux 派の Kate、Windows 派の Notepad++ も一言コメントで挙がった

バージョン管理

  • jujutsu (jj) — 今年もっとも多く名前が挙がったツール

    • 「git CLI を手放すとは思わなかったが、結局そうなった」
    • 「より簡単でありながら同時により強力なツールは珍しいが、jujutsu はその両方を実現している」
    • rebase と commit amend が楽しくなるという評価
    • 欠点: デフォルトが洗練されておらず color/template の調整が必要 — 「高コントラストの虹色ユニコーンの吐瀉物テキスト」が標準

  • Git 補助ツール

    • tig: 「git log の改良版」、インタラクティブ staging に活用
    • Magit: Emacs ユーザーの中核
    • Sublime Merge: 「git の GUI レイヤーだが非常によくできている」、jj とも merge-editor = "smerge" で統合可能
    • lazygit: rebase、revert、stash、複数 remote など複雑な作業にも積極的に挑戦する気にさせる
    • delta: git pager に設定すると syntax-highlighted diff を表示し、lazygit と組み合わせれば side-by-side / inline の切り替えも可能
    • difftastic: 行単位ではなく syntax ベースの diff
    • git revise: 「git に標準搭載されるべき」
    • Beyond Compare: 20年間使われてきた diff/merge/folder 同期ツール

シェル / ターミナル

  • Fish

    • 「bash・zsh がやることをすべてこなしつつ、ほとんど設定なしで素晴らしい体験を提供する」
    • 必要なら bash スクリプトもそのまま実行可能
    • 新しいショートカットを継続的に発見できるツールと評価される（例: alt+<left|right> のディレクトリ履歴）

  • ターミナルエミュレータ

    • WezTerm: キーボードだけでコピー/貼り付け（ctrl+shift+space）、ctrl+shift+t で同一システム上にタブ複製、内蔵 SSH クライアントとマルチプレクサ
    • Ghostty: macOS ネイティブ統合 — Cmd+Ctrl+D の辞書ポップオーバー、ドラッグアンドドロップ、ネイティブタブ、フォントレンダリング品質
    • kitty: 「デフォルトがそのまま動きつつ、同時に十分な設定余地がある良いツールの見本」

  • tmux

    • ターミナルセッションを開いたら最初に実行するコマンド
    • SSH 切断や誤って閉じたターミナルへの備え — Mac と NixOS を行き来しても同じパターンを維持できる

  • Starship

    • どのシェルにもプラグインできるが、欠点は大きな repo で git status・branch コマンドが遅いこと

環境 / 依存関係管理

  • Nix / NixOS

    • 「Stockholm syndrome かもしれないが、他の Linux ディストリやビルドシステムを使えなくなる」
    • プロジェクトごとの nix shell によりシステムパッケージを最小化し、グローバル PATH を汚さず 正確なバージョン固定 が可能
    • 「1年後、5年後でも同じように動くという高い確信」
    • 「学習曲線さえ越えれば魔法のよう。OS 構成は本来こうあるべきだった」

  • mise

    • direnv を置き換えるツールバージョンマネージャーで、軽量な CI にも統合可能
    • 「asdf の strictly better な代替」
    • mise activate を知ると direnv を完全に外せる
    • mise watch と task システムにより、プロジェクトごとのアクションやファイル変更時の処理を実行

  • Dev Containers

    • docker/container のデプロイ環境と dev 環境を 共有できるのが利点
    • 欠点: tooling が未成熟（reference CLI には stop コマンドすら未実装）

  • chezmoi

    • 仕事用・個人用マシン全体で 一貫した開発環境 を維持し、git alias・Neovim config・access token・その他ツールのインストールも一緒に管理

デバッグ / プロファイリング

  • rr — record/replay デバッガー

    • 「C/C++ デバッグの主力ツール。一度記録すれば決定論的に何度でも再生できる」
    • メモリアドレスを watch したうえで 最後に書き込まれた時点まで巻き戻すことが可能
    • 「temporal debugging bisection」 — watchpoint と組み合わせ、メモリ破損が発生した地点を前後に探索

  • Pernosco

    • time-travel + データフロー解析デバッガー
    • Firefox のマルチコンテンツプロセスにおける focus handling、about:blank Chrome 互換対応で決定的な助けになった

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: グラフィックスデバッグの万能ツールで、XCode Metal デバッガーより標準機能が優秀
    • Tracy: 「無限のリソースでプロファイラを作るなら、結局 Tracy になる」
    • RemedyBG: 作業しやすさに優れたデバッガー

  • XCode Instruments

    • 3D/GPU シェーダープロファイリングで 行ごとの実行時間コスト注釈 を提供
    • stall の原因分析 — メモリフェッチ待ち、同期待ち、制御フロー分岐を区別
    • 「ハードウェア・ドライバ・Metal シェーディング言語・tooling まで全部を制御するエコシステムの強み」

  • その他

    • strace, extrace, perf — デバッグ必須の組み合わせ
    • gdb — 依然として一言コメントで多数言及

検索 / テキスト処理

  • fzf: shell の逆引き検索と統合され、「fuzzy 具合がちょうど良い」
    • rg '' | fzf パターンで repo 全体のテキスト検索を行い、マッチ選択時に即座に vim foo.rs +123 の形でシェルプロンプトへ返す
  • ripgrep: 「out of the box で正しく動き、設定を試したことすらない」
  • septum: 対話的コード検索 — 「7行以内に triangle・vertex・mesh をすべて含み、physics は除外」のような条件付き検索
  • fastmod / spacemod: 大量置換
  • autojump: j whatevs で過去の作業ディレクトリ履歴に fuzzy マッチして移動
  • zoxide: autojump に似ているが、より滑らかなナビゲーション
  • awk: 「少しだけ抽出して少しだけ整える作業」に今も強力
  • entr: 「これらのファイルを監視して、これを実行して」— コードベースのテスト自動実行に適している

JSON / データ / 変換ツール

  • jq: JSON 処理の事実上の標準で、manual を最後まで読むことを推奨、Exercism の jq track も勧められている
    • gojq: native jq よりエラーメッセージが圧倒的に優秀で、yaml 入力をサポートするため muscle memory をそのまま活かせる
  • fx: 大きな JSON 出力のドリルダウン
  • hexdump: 特に hexdump -C が組み込みデバッグに有用 — picocom --baud 115200 /dev/ttyUSB | hexdump -C パターン
  • hexyl: カラー hex ビューア
  • bat: cat の syntax-highlighted 代替
  • choose, fd: それぞれ cut、find の代替

シェル履歴 / クリップボード / ノート

  • Atuin: shell history の同期、ディレクトリ・git repo コンテキストベースの履歴検索
  • CopyQ: 約2000件の項目を扱えるクリップボードマネージャーで、メモし損ねたときに過去の作業を復元できる
  • histprune: fzf の Ctrl+R カスタム — alt+D で履歴項目を即削除
  • Obsidian: Logseq から移行、純粋な Markdown で保管できることが LLM/agent との協業に有利
  • Joplin: AGPLv3、デスクトップ・モバイル・Web アプリをすべてサポートし、WebDAV/OneDrive/S3 backend、.md ファイルをそのまま保存

ビルド / タスク自動化

  • just: make の代替 — ビルドではなく task に焦点を当て、言語に依存しない just lint のような一貫したインターフェースを提供
    • 「make の行単位モードと shell/python/node のフルスクリプトモードを target ごとに切り替えられる」
    • 欠点: 埋め込みスクリプトを $TMPDIR に書き出してから実行し、独自テンプレート言語を使う（uncanny valley）
  • Task (go-task): yaml ベースの代替で、batteries-included 指向
  • universal-test-runner: repo のテスト方式を自動判定して実行し、追加 args もそのまま渡せる
  • chezmoi: マシン間で dotfile やツール導入まで一貫管理

HTTP / ネットワーク / シークレット

  • Hurl: 「情報を集めようとする GUI HTTP アプリは忘れよう」 — シンプルなテキスト形式で curl リクエストを書けて、統合テストに適する
  • curl: 一言コメントで多数言及
  • SOPS: 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: 多言語フォーマッタ
  • Hunk: agentic coder 向けの review-first ターミナル diff ビューアで、--watch モードをコーディングエージェントの横に表示しておく使い方
  • Raycast / Alfred: macOS ランチャー、snippet・クリップボード・パラメータ化 Web 検索
  • Ergodox EZ: 10年使っているキーボードで、カスタマイズ性・電力面ともに満足
  • Joplin / Fossil: ノートとウィキのセルフホスティング
  • AeroSpace / Sway: タイリングウィンドウマネージャ

繰り返し現れるメタメッセージ

  • 「デフォルトが良いツールを選び、終わりのない設定を避けよう」 — Helix、Fish、ripgrep、mise がこの哲学の代表例として挙がった
  • 反対の視点: 延々と tweak した結果、自分だけのツール体系を完成させた例もある — 「今では年に数回しか手を入れない」
  • AI エージェント時代の副産物: jq・Markdown・structured text ツールが LLM との協業に向いているという認識が広がっている — Obsidian の純粋な Markdown、hunk の watch モード、jq の manual 学習推奨などが同じ流れ
  • macOS のグラフィックスデバッグ優位: XCode Instruments の GPU プロファイリングは Linux/Windows と比べて圧倒的という評価
  • CLI ルネサンス vs タイポグラフィ: ターミナルツールが豊かになる一方、長い LLM/agent 出力は結局ブラウザや専用アプリのタイポグラフィの方が読みやすいという両義的な観察

関連記事

8件のコメント

 
kirinonakar 24 분 전

いくつか使ってみたのですが、これだと思えるものがなかったので、今は自分で作っています。notepad++、VS Code、Zed、Obsidianを参考にして、必要な機能だけを取り入れて作っています。
 
xguru 10 시간 전

最近は cmux、tmux、mux の3つをまとめてうまく使っています。
tailscale でつないだサーバーに ssh ログインすると、fzf で既存の tmux ログインをまとめて表示してくれて、そこで選んで入ります。

cmux - AIコーディングエージェント向けのGhosttyベース macOS用ターミナル
Show GN: mux – AIコーディングセッションをライブプレビューに変える tmux セッションマネージャー
 
edunga1 2 시간 전

Macでは、ターミナルで日本語入力するには Enter を2回押さないといけないんじゃないですか？（日本語の変換確定後、入力までに2回）
これだけは唯一 wezterm ではこの問題がなかったので、乗り換えたんです。
 
onixboox 3 시간 전

Zed が好きです
 
snisty 5 시간 전

私はもう Claude Code なしでは生きられない体になってしまった。+ tmux..
付け加えるなら、テキストエディタは vscode..
それ以外だと、ビルド用の Visual Studio みたいな必須 IDE くらい..
 
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 を使っている。自分にとっては、カスタマイズ性と優れたデフォルト体験のバランスがちょうどいい
    同じ理由で、ターミナルシェルには Fish を使っている。デフォルトのままで優秀で、自分好みに使うための調整がほとんど要らない
    年を取るにつれて、延々と設定をいじるよりも、意図的に良いデフォルトを持つツールに自分の好みを合わせるほうが好きになってきた
    Atuin は、リモートマシン間でのシェル履歴同期や、現在のディレクトリや git リポジトリに基づく文脈付き履歴検索に便利。他にも機能はあるが、自分はこの機能しか使っていない
    Mise もいろいろ気に入っているが、主にはツールのバージョンマネージャとして一番気に入っている。以前使っていた direnv を置き換えたし、個人プロジェクトでは軽い CI フローにも少しずつ統合し始めている

    • 良いデフォルトに従う道筋は、最もよくテストされた道筋でもあるので、バグに遭遇しにくい。たいていは賢い選択だ
    • 「デフォルトに好みを合わせる」と「延々と設定をいじる」しかないわけではない。自分の n=1 の経験では、ひたすら、ひたすら、ひたすら設定をいじり続けて最終的に望む地点に到達し、今ではほとんどいじっていない
      年に数回くらいだけだ。自分の Emacs は、自分専用の Studley の工具箱 みたいな状態になっている
    • Helix を好きになりたい。とても洗練されたプロジェクトだし、デフォルトも魅力的なのだが、Vim の筋肉記憶 があまりにも染み付いている
      その代わり、数か月前に Neovim を完全に受け入れて、10年以上かけて有機的に育った .vimrc を引退させた。少し寂しかったが、Helix を羨む気持ちは減った
      Mise も良くて、実質的に設定がほとんど要らない。Fish も数か月前から使い始めたが、いくつかのユーザー関数以外はほぼデフォルトのままだ
      Ripgrep もデフォルトのままで「ただ正しいことをしてくれる」ので、設定を試したことがあるかどうかすら分からない
    • Helix をちゃんと使うには、どう学べばいいのだろう？ Neovim はプラグインのせいで 50 を超えるリポジトリを引っ張ってくる構造なので、サプライチェーン攻撃 があまりにも心配で、そこから離れようとしている
    • この話、本当に共感する。年を取るにつれて、ツールやソフトウェアをあれほどいじり回す人たちがよく分からなくなってきた。面白くもないし、それだけの価値も感じない

  • Emacs

  • ストックホルム症候群かもしれないが Nix。完璧ではないが、Nix によってより表現力高く効率的に作業できるようになってしまい、他の Linux ディストリビューションやメタビルドシステムを事実上台無しにしてしまった
    ついでに言うと、pwntools も CTF の外でも使っていて楽しいツールだ。たとえば Python REPL でソケットをビット単位でいじるような使い方にも向いている

    • Nix も pwntools も両方好き。同じ CTF プレイヤーとして気になるのだが、Nix ベースの CTF pwn 環境 を持っているなら、どう構成しているのか知りたい
      自分はいつも libvirt の Ubuntu VM を新しく立ててツールを入れ、そこで作業していたのだが、Nix ベースでおすすめのやり方はあるだろうか？

  • Emacs は当然として、特に Magit

  • Nix。学習コストはある。Nix ユーザーや伝道者の周りに数年いてから本気で試したが、結局かなり良い
    複数のプロジェクトをやっていると、システムレベルの依存関係を管理するツールがバラバラなのにうんざりしてくる。Node のバージョン用に一つ、Python のバージョン用に一つ、という具合だ
    プロジェクト間の非互換性のせいで、デバッグしづらいビルド失敗が起きるのにも疲れた。Project A で $foo が壊れたので Homebrew で更新したら、今度は Project B で $foo が壊れる、といった感じだ
    ビルド過程がシステムにインストールされた多数の、しかもしばしば隠れた依存関係に頼っているせいで、「なぜか」ビルドが失敗する状況にもうんざりする
    可能な限りすべてを プロジェクトごとの nix shell に移した。システムレベルのパッケージはできるだけ薄く保ち、各プロジェクトには必要なツール、つまり依存関係・ランタイム・コンパイラなどを正確なバージョンで固定する
    グローバルな PATH や他のプロジェクトを汚染しない。今自分の環境で動くなら、1年後でも5年後でも動くという確信がかなり高い
    ツールをアップグレードしたいときも、他のプロジェクトに影響する心配なく行えるし、回帰が起きたら簡単に戻したり、特定の依存関係一つだけを古いバージョンに固定したりできる
    同僚も Nix を使うプロジェクトではさらに良い。nix shell の設定と保守にかかる追加時間を共有できるし、開発環境が同じだという確信もかなり高まる

    • 似た理由で最近 Dev Containers にかなりハマっている。アイデア自体はかなり良いと思うが、残念ながらツールの品質が追いついていない
      たとえば標準 CLI でさえ、まだ stop コマンドを実装していない。それでも、デプロイに Docker/コンテナを使うなら、開発環境とデプロイ環境の間で多くの設定を共有できるという利点がある
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/) は、これなしでは生きられないくらい魔法のように素晴らしいソフトウェアだ

    • 昔だったら毎日必要としていたはずのツールだ。いい発見だった。後でまた必要になったとき見つけられるように、自分の セカンドブレイン に入れておこうと思う
    • 気になるのだが、rr で最も大きな価値を感じるのはどんな場面なのだろう？ プロジェクトのトップページの説明は大枠では理解している
      失敗を一度記録して、その記録を決定論的に何度でもデバッグするという概念は、確かに有用に思える
      ただ、実際の体験を聞きたい理由は、「うわ、この 特定のバグ/ワークフロー は rr なしでは解決不可能だっただろう」という実感がまだ足りないからだ

  • システム管理者のバックグラウンドがあるので、「良いデフォルトを最小限の設定で使う」寄りの人間だ。だが最近、その習慣を崩したものが二つある
    jujutsu(jj) はこのサイトでもよく話題になるが、正直使っていて本当に気持ちいい。git CLI を捨てることになるとは思わなかったが、そうなった
    何年ものあいだ nvim の利用や設定を学ぶのを避けていたのだが、nvchad のおかげで始められた。名前はひどいが、自分にとってはミニマルさから少しだけ主観を足した、素晴らしい初期設定だ
    もちろん今では、最初から自分の 最小構成 を直接使っている
    それ以外では、Python をかなり使うので、astral のツール群も一貫して楽しく使えていると言っておきたい。Anthropic がうまく面倒を見てくれるといいのだが

    • jujutsu はその意味で二重にそうだ。最初は移行自体が良く、その次に jj のデフォルトがそこまで洗練されていないので、もう一段手を入れたくなる
      暗い背景に典型的な高コントラストの虹色ユニコーンの吐瀉物みたいなテキストを使わないなら、色やテンプレートの調整がかなり必要になる

  • 実際のところ Emacs。自分のコンピューティング作業を少しずつ Emacs に移し、デフォルトを受け入れ始めている
    Emacs はカスタマイズが本当に簡単で、多くのキーバインドがあらゆるモードで適切な仕事をしてくれる
    ゆっくり移行中の一覧は、Git → Magit、Email → mu4e、RSS → elfeed、Notes/TODO/Calendar → org mode、Finder → dired だ
    Quarto も、Markdown で素早くプレゼン資料を作るときにはかなり良い。Nix と nix-darwin はすべての dotfiles で使っている

    • dired 用途なら Dirvish を見てみる価値がある

  • Emacs。頻繁に使うわけではないが、ragel でパーサを書くのは楽しい

  • Sublime Text は、間違いなくあまりにも多くの人に過小評価されている

    • Sublime Text を好きになりたかったのだが、vi モードが Vim で培った筋肉記憶と十分に一致せず、定着しなかった
      たしか “vintage” のような名前だった気がする。今では、Sublime Text を好きになりたかったような場面で Zed を使っている