neovim on blog.kyu08.com

最近はこんな感じでdiffview.nvimを使ってPRのdiffはすべてNeovim上で見るようにしている。コードをレビューしていると周辺の実装も含めて確認したいことがよくあるので、エディタ上でレビューしているとすぐに該当ファイルに飛べて便利。（octo.nvimにコメント周りのバグがあったのでレビューコメントの書き込みはGitHubのWebUIから行っている。）

GitHub - sindrets/diffview.nvim: Single tabpage interface for easily cycling through diffs for all modified files for any git rev.

Single tabpage interface for easily cycling through diffs for all modified files for any git rev. - sindrets/diffview.nvim

https://github.com/sindrets/diffview.nvim

今はGo/TypeScript/Rustあたりしか書いてないので特に困ってないが、JVM系をNeovimで書こうとすると若干辛みがあるかもしれない。（ちょっとだけJava/ScalaをNeovimで書いたことがあるが重かったり不安定だったりして辛かった）

AI時代になって設定を自分好みにするコストが格段に減ったのでNeovimのカスタマイズが捗っており嬉しい。最近はPRレビュー効率化のための色々をClaude Codeにやってもらっている。（Luaの書き方を覚える前にAI時代が来てしまった…）

久々に起動時間を測ってみたら60msくらいになっていたので気が向いたらもうちょっとチューニングしてもいいかもしれない。（たぶん30msくらいまではいけるはず）

一時期cursorも頑張って設定ファイルを作り込んだうえで慣れようとしてみたが、どうもVSCode系エディタとは思想が合わなかったので結局数日で戻ってきてしまった。

AIツール

ClaudeとDevin、GitHub Copilotを使っている。

ClaudeはDesktop App経由で壁打ちや検索用途で使ったり、Claude Codeでコードを書いてもらったりしている。

Claude Codeを使うときはNeovim plugin等ではなくtmuxのpaneを切ってそこで直接動かしている。

Devinは主にAsk Devinを使ってコードベースの調査などに使っている。レスポンスがめっちゃ早くてありがたい。

GitHub Copilotはエディタのインライン補完で使ったり、GitHubのWebUI上でタスクを依頼したりするときに使っている。特にこのブログの機能開発ではよく使っている。（issueさえ書けばそのままWebUIからタスクを依頼できて便利）

ターミナルエミュレータ

Alacrittyを使っている。ターミナルにはタブ機能がない方がcmd+w等を誤爆したりとかが起きないので好きで使っている。（iTerm2を使っていたときはたまに誤爆してシェルが消えて悲しくなっていた。）

正直早いかどうかはあまりわかってないが特に不満もない。（少し前に日本語入力もいい感じになったし）

GitHub - alacritty/alacritty: A cross-platform, OpenGL terminal emulator.

A cross-platform, OpenGL terminal emulator. Contribute to alacritty/alacritty development by creating an account on GitHub.

https://github.com/alacritty/alacritty

ターミナルマルチプレクサ

tmuxを使っている。1セッションに好きなだけウィンドウを開く運用で使っている。

tmux-fzfでのwindow切り替えがとても便利で気に入って使っている。

設定手順は過去にこちらに書いた。

tmux-fzfを使ってwindow切り替えをできるようにする手順

これはなにこんな感じでtmuxでwindowをfzfで切り替えられるようにするための設定方法手順 .tmux.confに以下を追記 set -g @plugin 'tmux-plugins/tpm' # す

https://blog.kyu08.com/posts/tmux-fzf-window/

前述の通りalacrittyとの相性がいい感じなのでよほどのことがない限りこの組み合わせは変えなさそう。²

Status Lineはこんな感じで画面下側にwindow名と現在時刻を表示している。

詳しくは後述するが、nvim-orgmode/orgmodeでClock In(時間計測)しているタスクがあるときはそのタスク名と経過時間をStatus Lineに表示するようにしている。1つのタスクに集中できて割と作業が捗っている。

その他のtmuxの設定とか工夫を紹介する記事は別で書きたい。

Zellijも試したことはあるが、自分の環境だとなぜか表示が崩れてしまったので使っていない。

シェル

zshを使っている。

元々はネットに落ちているshellのコードが（fishよりも）動きやすいから、という理由で使っていたのを惰性で使い続けている。

少し前にこの記事を参考にして起動を高速化したりした。（最近は測ってないが多分今も数10msくらいで起動するはず）

究極のzshプラグイン読み込み高速化: プラグインマネージャーの限界を越えろ【起動時間14.6ms】

https://zenn.dev/fuzmare/articles/zsh-plugin-manager-cache

2024/4頃からzeno.zshを使っていてよく使うコマンドの実行がかなり効率化できている。snippetがいい感じに展開されるのは言わずもがな嬉しいが、zeno-insert-snippetでzenoに登録したsnippetをfzfで選択&挿入できるのがとても便利。設定ファイルはまだyaml形式で書いている。

GitHub - yuki-yano/zeno.zsh: zsh fuzzy completion and utility plugin with Deno.

zsh fuzzy completion and utility plugin with Deno. - yuki-yano/zeno.zsh

https://github.com/yuki-yano/zeno.zsh

プロンプト表示にはstarshipを使っている。

GitHub - starship/starship: ☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell!

☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell! - starship/starship

https://github.com/starship/starship

こんな感じでk8sのcontextとnamespaceを表示するようにしている。

誤ってprod環境を壊すことがないようにこんな感じでcontextにprodという文字列が含まれていたら目立つようにしている。

設定はこんな感じ。

[kubernetes]
format = '[[$symbol]($style)\[ctx\]$context \[ns\]$namespace]($style) '
disabled = false
contexts = [
  { context_pattern = ".*dev.*", style = "blue", symbol = " " },
  { context_pattern = ".*prod.*", style = "bold red", symbol = "🔥 " },
]

その他の設定とか便利スクリプトを紹介する記事は別で書きたい。

ランチャー

AlfredとRaycastを併用している。

基本的に不満がないかつ操作性がRaycastよりも好みなので基本的にはAlfredを使っている。

使い道は至って普通でスニペットやweb検索、ローカルのファイル検索などに使っている。

あとはWorkflowを利用してよく使うアプリを以下のようなキーバインドで呼び出せるように設定している。

Alacritty: opt + space
Brave: cmd + esc
Slack: opt + opt
Notion: opt + n
Claude: opt + x
TickTick: opt + t
Spotify: ctrl + esc

今は治ってるかもしれないが、一時期Alfredのクリップボードの動作がとてつもなく重くなってしまったのでそこだけRaycastを使っている。

ウィンドウマネージャー

yabaiとskhdを使っている。設定をコード管理できるのが嬉しい。たまに動作が不安定になるのでそのたびにyabai --restart-service && skhd --restart-serviceを実行している。とはいえ特に不満もない。

GitHub - asmvik/yabai: A tiling window manager for macOS based on binary space partitioning

A tiling window manager for macOS based on binary space partitioning - asmvik/yabai

https://github.com/asmvik/yabai

GitHub - asmvik/skhd: Simple hotkey daemon for macOS

Simple hotkey daemon for macOS. Contribute to asmvik/skhd development by creating an account on GitHub.

https://github.com/asmvik/skhd

めっちゃ雑に書くとよく使うのはこの辺のやつ。

windowを右半分に表示
windowを左半分に表示
windowを左上に表示
windowを左下に表示
windowを右3/4に表示
windowを左1/4に表示

フォント

M+1Code Nerd Font Monoを使っている。まるっとしていて好き。nerd fontも入っているのでNeovimを使っていても豆腐が出ず嬉しい。（あまり原理はわかってないがCicaなどの他のnerd font対応フォントよりも豆腐が出なくてありがたい）

タスク管理

ここ1年くらいはnvim-orgmode/orgmodeを使っている。emacsのorg-modeライクな機能をNeovimで使えるようにしたプラグイン。

GitHub - nvim-orgmode/orgmode: Orgmode clone written in Lua for Neovim 0.11.0+.

Orgmode clone written in Lua for Neovim 0.11.0+. Contribute to nvim-orgmode/orgmode development by creating an account on GitHub.

https://github.com/nvim-orgmode/orgmode

少し前まで素朴にこんな感じのマークダウンファイルを毎日生成して管理していたが、期日が違うタスクをいい感じに管理したくて使い出した。

## TODO
- 実装

## DONE
- コードレビュー

Neovimでタスク管理できるのとタスクに優先度、期日を設定してそれをいい感じにソートして表示してくれるのがかなり肌にあっていて気に入っている。

最近は時間の使い方を振り返る目的でClock In的な機能を使ってタスクごとの所要時間も管理してみている。

これに関してはそのうち別の記事として詳しく書きたい。

ブラウザ

数年前からBraveを使っている。広告をブロックしてくれつつChrome拡張も使えるので便利。一時期Arcも使っていたが肌に合わない挙動があったので使うのをやめてしまった。（具体的には覚えていない）

よく使うChrome拡張は少し前にこの記事に書いた。

ソフトウェアエンジニア目線で使ってみて便利だったChrome拡張を紹介する

本記事はUnipos Advent Calendar 2024の13日目の記事です。本記事では使ってみて便利だったChrome拡張を紹介します。 Stylus Stylus ユーザー定義のCSSを

https://blog.kyu08.com/posts/chrome-extensions-for-dev-2024/

IME

Google日本語入力を使っている。

たまーにひらがなの変換がおかしいのが気になっているが全体的には割と満足している。

azooKeyも試したが辞書登録した単語の優先度が低いのが使いづらくて使うのをやめてしまった。（ライブ変換はとても便利だった。）

ならissueを立てんかい…という話ではあるがちょっとこのところ忙しくそこまではできていない。

CLI/TUIツール

よく使っているCLI/TUIツールはこのあたり。

fzf

GitHub - junegunn/fzf: :cherry_blossom: A command-line fuzzy finder

:cherry_blossom: A command-line fuzzy finder. Contribute to junegunn/fzf development by creating an account on GitHub.

https://github.com/junegunn/fzf

言わずと知れたあいまい検索ツール。
ディレクトリ履歴移動やファイル検索などあらゆるスクリプトで使っている。

lazygit

GitHub - jesseduffield/lazygit: simple terminal UI for git commands

simple terminal UI for git commands. Contribute to jesseduffield/lazygit development by creating an account on GitHub.

https://github.com/jesseduffield/lazygit

gitのTUIクライアント。
gitの操作はすべてlazygitでやっている。
add commit push pullなどの日常の操作やブランチ操作などをかなり少ないキー入力で行えるのがとても便利。
git rebase -i相当のことができたり、commitの一部だけstagingに戻したりと細かいこともできる。
ここ2年くらいで細々とPRを送っており、去年末頃に9番目にcommitが多い人になることができた。

k9s

GitHub - derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!

🐶 Kubernetes CLI To Manage Your Clusters In Style! - derailed/k9s

https://github.com/derailed/k9s

GKEのリソースを見たり操作したりするときに使っている。とても便利。（画像はサンプル用にkindでローカル起動したクラスタのもの）
ログはあまり使いこなせてないので普段の開発ではDatadogやCloud Loggingを見ていることが多い。

<PRここから>

fzf-make

fzf-makeというmake targetをfuzzy finder形式で選択、実行できるTUIを開発している。

コマンド名やその内容を覚えずとも楽に実行できたり、履歴機能があるのが特徴。

現在はMakefileに定義されたmake target以外にも以下のようなコマンドに対応している。

package.jsonのscriptsに定義されたコマンド(pnpm, yarn, npmに対応)
justfileに定義されたrecipe
Taskfile.ymlに定義されたtask

次のようなコマンドでインストールできるのでぜひ使ってみてください。

brew install fzf-make

cargo +1.90.0 install --locked fzf-make

スターもしてもらえると嬉しいです🙏

GitHub - kyu08/fzf-make: A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task.

A command line tool that executes commands using fuzzy finder with preview window for make, npm, pnpm, yarn, just and task. - kyu08/fzf-make

https://github.com/kyu08/fzf-make

</PRここまで>

キーリマッパー

Karabiner-Elementsを使っている。

vimmerなのでAの左側のキーを

単押しでesc
長押しでctrl

となるように設定している。

あとはよくある左cmdを英数、右cmdをかなにリマップする設定とか、ctrl+shift+hjklで←↓↑→が入力する設定とかを入れている。

キーボード

7sPro
- 2021/8から使っている。今は家でメインのキーボードとして使っている。
- キースイッチはYushakobo Fairy Silent Linear Switchを使用。
- https://shop.yushakobo.jp/products/7spro
EPOMAKER SPLIT70
- 2026/1に買って職場で使っている。分割キーボードかつガスケットマウントでとても打鍵感が良い。
- キースイッチは同じくYushakobo Fairy Silent Linear Switchを使用。
- https://epomaker.jp/products/epomaker-split70

その他

fuwari
- スクリーンショットを付箋のように画面上に貼り付けておけるmacアプリ。画面に表示されている何かをちょっとメモ的に見たいときにとても便利
- https://github.com/kentya6/Fuwari
- こんな感じで動く

まとめ

ここ数年で主要な使用ツール（Neovim, tmux, zsh）が変わっていないので安定して自分好みのカスタマイズが進められている。

AIツールの実装力がかなり上がったのもあり、Neovimやtmuxのカスタマイズも今まで以上にかなり捗るようになっている。

好みの環境で作業ができると作業自体が楽しくなって仕事や趣味のモチベーションも上がるので2026年もやっていき。

みなさんのこだわりもぜひ教えてください〜！

これ系の記事でNeovimの使用率が1位になってるの初めて見た。Neovimユーザーとしては嬉しい。 ↩︎
画面内の文字を検索するのにcmd+fをよく使うのでGhosttyは自分には合わなかった。 ↩︎

VimConf 2025 Smallに参加した

Sun, 02 Nov 2025 01:07:08 +0000

2025年11月2日（日）にアキバプラザ・アキバホールで開催されたVimConf 2025 Smallに参加した。

こちらはノベルティ。食器とかお箸はたくさんあっても困らないのでありがたい。

お茶碗
お箸
コースター
巾着
お茶

nvim-cmp retrospective: Exploring Completion and Facing FOSS Challenges

hrsh7thさんによる発表。

Explore Completion

nvim-cmpのcmpって「シーエムピー」って読むんだ（「コンプ」って読んでた）
補完プラグインってめちゃめちゃいろんなケースを考慮して作られているんだな…（全然詳しくないので薄い感想しか出てこない）

FOSS Challenges

大きなOSSプロジェクトをメンテすることになったことでの学びの共有。

もともとはユーザーが求めるものと自分のやりたいことが合致していた。自分がやりたいことをやることで感謝してもらえていた。
- あるときから自分のやりたいこととユーザーの要望が乖離してきた
  - やりたいこと
    - コード品質を上げたい
    - 実験的な新機能を追加したい
  - ユーザーが求めること
    - 安定した動作
- 結果モチベが下がった
- 予期せずプロジェクトが大きくなって責任が芽生えた
- モチベが低いならコミュニティ主導にすればいいのでは？という意見も見るが…
  - 直接話したこともない人をrepositoryに招待するのは危険だと感じた（ユーザー数も多いのでサプライチェーンアタックが怖い）
    - 実際にhrsh7thさんが作ったプラグインのコピープラグインがリリース1週間後にできて、そこにマルウェアが含まれていたことがあるらしい（怖すぎる）
  - 新メンテナのオンボーディングをサポートするのも大変
とはいえOSS開発は楽しい
- nvim-cmpを公開して「これめっちゃ便利だね！」といってもらえたのはとても印象に残っている
- 意図せず人気になってしまうと責任も生じる

感想

たくさんのユーザーを抱えるOSSのメンテ目線のリアルな心境を聞けてよかった。

大規模OSSのメンテナに憧れる気持ちもあるが、楽しいこともあればその分大変なこともあるんだろうな〜などと思った。（それはそう）

とはいえたくさんの開発者、プロジェクトに寄与するような大規模OSSメンテナへの憧れはあるのでコミットしたいOSSが見つかったら挑戦してみようと思う。

And Yet, Vim Survived: Thinking and Seeing in the Age of Code You Don’t Write

Λlisueさんによるコードリーディングに関する発表。

以下の3stepに分けてコードを読む。

Where - Seeing the flow
What - Seeing the structure
Why - Seeing the Reasoning

Where - Seeing the Flow

File Jumps
- gf / gF - open file under cursor
- これ知らなかった。go testの結果を見て失敗しているファイルに飛ぶときとかに便利そう。
Search Jumps
- /や?で検索しnでジャンプ
fall.nvim(fuzzy finder)
- 検索してnで飛ぶのに比べて<c-o>で直前の位置に戻れるので便利
Quickfix
- ]q / [qでジャンプできる

What - Seeing the structure

Window management
- <c-w> + s/v/h/j/k/l
- <c-w> + o: （複数ウィンドウを開いているときに実行すると）現在のウィンドウのみを表示する
  - nativeだと元の状態に戻れない
- goyo.vim¹を使うと<c-w> + oをもう一度実行するともとのウィンドウの状態に戻れる。
file treeは知らないファイルを探すために使う
fuzzy finderは知っているファイルを開くために使う

Why - Seeing the Reasoning

git blameを活用してコードの背景を理解しながらコードを読む

感想

ありすえさんが発表がうますぎてその点でも勉強になった。特にこのあたりのポイントが勉強になった。

論理構造が自然で理解しやすかった
話す速度、スライドの情報量が多すぎなかったのでついていきやすかった
ユーモアを交えていて楽しく聞けた
シンプルに滑舌が良かった（わかんないけどマイクの使い方とかも違うんだろうか。なんかとにかく声が明瞭で聞き取りやすかった）

Beyond Syntax Highlighting: Unlocking the Power of Tree-sitter in Neovim

atusyさんによるtree-sitterに関する発表。

GitHub - atusy/treemonkey.nvim

Contribute to atusy/treemonkey.nvim development by creating an account on GitHub.

https://github.com/atusy/treemonkey.nvim

便利そう

tree-sitterをもっと深く理解したくなった（趣味のプロジェクトでIndianBoy42/tree-sitter-justに依存しているので自分もメンテに参加できるようになりたい）

Designing Repeatable Edits: The Architecture of . in Vim

Satoru Kitaguchiさんによるドットリピートの解説。

.でリピートできる操作
- ノーマルモードから始まってバッファを編集し、ノーマルモードに戻ってくる
- undoツリー上のlast-change nodeを再実行している = 直前の編集チャンクを再適用する
daw, ci"などはリピートできる
Visual modeを含んだ操作などはリピートできない
- Visual modeでは内部的には選択された文字数や行数しか保持されないため

さらっとVimの内部動作を解説していてかっこよすぎた。Vimのコードを読んだのか、Vimの内部構造を解説しているsomethingがどこかに存在するのかちょっと気になった。かなり周到に調査されてスライドを作られてそうな印象を受けた。

便利なプラグインの情報を集めるのも楽しいが、たまにはちゃんとVim自体の機能を学んだ方がかえって効率よく日々の操作を効率化できそうだな〜と思った。

実践Vimを読みたい気持ちが芽生えた。（n回目）

LT

ryoppippiさんの https://github.com/ryoppippi/nvim-in-the-loop がかなり便利そう。

自分のVimの操作履歴を記録し、AIにどのようなキーマップを登録すると無駄な操作を減らせるかを分析させるというものらしい。すごい。

まとめ

学びや刺激を得られたので行って良かった。

発表内容もさることながらプレゼンが上手な方がいたり、（おそらく日本の方だけど）英語が超上手な方がいたりして、その意味でも刺激を得られた。

今回初参加なので他の回との比較はできないが全然Smallな感じがせず、満足感が高かった。（もしやSmallじゃない回は2トラックとかあったりする…?）

運営の皆さん、登壇者の皆さんありがとうございました！

おそらくこれ https://github.com/junegunn/goyo.vim ↩︎

`Process failed to start: too many open files: "/opt/homebrew/bin/git"`というエラーが出てNeovimのプラグインが動作しなくなる問題の回避策

Mon, 13 May 2024 04:11:01 +0000

問題

ここ数日Neovimを使っていると、Process failed to start: too many open files: "/opt/homebrew/bin/git"といったエラーとともにプラグインが動作しなくなることがあり困っていた。

記憶にある範囲だとnvim-telescope/telescope.nvimやakinsho/toggleterm.nvimを使っているときにこのエラーが起きることが多かった印象。

筆者の環境

$ nvim --version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1703358377

利用しているプラグインは後述。

回避策

この記事にしたがってファイルを作成したところエラーが出なくなった。

Macの「Too many open files」エラーを解消 - Qiita

「Too many open files」と出てで、ファイルが保存できないことがあった。 Railsを起動して、Gulpも起動してほげほげしてるとよく起こる。 Sublime Textでこのエラーが出ると設定も何もかも保存されないし、HotExitも効かないし、ファイルは開...

https://qiita.com/sou_lab/items/1ca051a1f3b906a23dc8

以下記事より引用。

sudo vi /Library/LaunchDaemons/limit.maxfiles.plist

viでもnanoでもcodeでもお好きなエディタのコマンドで下記コードをコピペ。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>524288</string>
      <string>524288</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceIPC</key>
    <false/>
  </dict>
</plist>

参考

同時に開くことができるファイル数の上限に引っかかってしまっている模様。

もしかしたら一部のNeovimプラグインの特定のバージョンに原因があるのかもしれない。

もしかしたらこれをみた人の参考になるかもしれないのでlazy-lock.jsonを貼っておく。（原因特定までする元気はなかった）

{
  "Comment.nvim": { "branch": "master", "commit": "0236521ea582747b58869cb72f70ccfa967d2e89" },
  "alpha-nvim": { "branch": "main", "commit": "41283fb402713fc8b327e60907f74e46166f4cfd" },
  "barbecue": { "branch": "main", "commit": "cd7e7da622d68136e13721865b4d919efd6325ed" },
  "bufferline.nvim": { "branch": "main", "commit": "73540cb95f8d95aa1af3ed57713c6720c78af915" },
  "cmp-buffer": { "branch": "main", "commit": "3022dbc9166796b644a841a02de8dd1cc1d311fa" },
  "cmp-look": { "branch": "master", "commit": "971e65a6be0e75c3438fe7b176d4fc020cb89d7b" },
  "cmp-nvim-lsp": { "branch": "main", "commit": "5af77f54de1b16c34b23cba810150689a3a90312" },
  "cmp-nvim-lsp-signature-help": { "branch": "main", "commit": "3d8912ebeb56e5ae08ef0906e3a54de1c66b92f1" },
  "cmp-nvim-lua": { "branch": "main", "commit": "f12408bdb54c39c23e67cab726264c10db33ada8" },
  "cmp-path": { "branch": "main", "commit": "91ff86cd9c29299a64f968ebb45846c485725f23" },
  "cmp-vsnip": { "branch": "main", "commit": "989a8a73c44e926199bfd05fa7a516d51f2d2752" },
  "copilot.vim": { "branch": "release", "commit": "b603990a639bb4b8651d054ef8d5a8fe5db56e0c" },
  "dial.nvim": { "branch": "master", "commit": "27eb570085db2ef44bff4f620d3806039184651c" },
  "fzf": { "branch": "master", "commit": "24ff66d4a9d6889988e4d7e373f33f4098870b9e" },
  "gitsigns.nvim": { "branch": "main", "commit": "bc933d24a669608968ff4791b14d2d9554813a65" },
  "gotests-vim": { "branch": "master", "commit": "42abccb59e9889cd1ce427b11b2ffbb36f2a46a6" },
  "gruvbox.nvim": { "branch": "main", "commit": "dd0ab08b17d2ead7bdb4838b48e1d08034ead0f0" },
  "harpoon": { "branch": "harpoon2", "commit": "0378a6c428a0bed6a2781d459d7943843f374bce" },
  "indent-blankline.nvim": { "branch": "master", "commit": "3d08501caef2329aba5121b753e903904088f7e6" },
  "lasterisk.nvim": { "branch": "main", "commit": "bbcfcaeca50f686e338a03386e41645fc3305f44" },
  "lazy.nvim": { "branch": "main", "commit": "ebdd0499551765e6a7aba220cc8ae4e0cdb6be69" },
  "lazygit.nvim": { "branch": "main", "commit": "0ada6c6e7e138df92f5009b6952f4ac41248305a" },
  "lsp-lens.nvim": { "branch": "main", "commit": "48bb1a7e271424c15f3d588d54adc9b7c319d977" },
  "lsp_signature.nvim": { "branch": "master", "commit": "c6aeb2f1d2538bbdfdaab1664d9d4c3c75aa9db8" },
  "lspkind.nvim": { "branch": "master", "commit": "1735dd5a5054c1fb7feaf8e8658dbab925f4f0cf" },
  "lspsaga.nvim": { "branch": "main", "commit": "052234296f13e2705d5d290c7bd5a36d3dd81fde" },
  "lualine.nvim": { "branch": "master", "commit": "0a5a66803c7407767b799067986b4dc3036e1983" },
  "mason-lspconfig.nvim": { "branch": "main", "commit": "05744f0f1967b5757bd05c08df4271ab8ec990aa" },
  "mason.nvim": { "branch": "main", "commit": "751b1fcbf3d3b783fcf8d48865264a9bcd8f9b10" },
  "neo-tree.nvim": { "branch": "v2.x", "commit": "80dc74d081823649809f78370fa5b204aa9a853a" },
  "noice.nvim": { "branch": "main", "commit": "f4decbc7a80229ccc9f86026b74bdcf0c39e38a7" },
  "nui.nvim": { "branch": "main", "commit": "274fa89a9b4bed746647c2917091902f882509ec" },
  "nvim-autopairs": { "branch": "master", "commit": "14e97371b2aab6ee70054c1070a123dfaa3e217e" },
  "nvim-bqf": { "branch": "main", "commit": "52703d7adc3be3f7c09eea9a80c5b8caa615fb25" },
  "nvim-cmp": { "branch": "main", "commit": "8f3c541407e691af6163e2447f3af1bd6e17f9a3" },
  "nvim-hlslens": { "branch": "main", "commit": "3e8fceb2b030100857ee72741a8f48c9a1d8595e" },
  "nvim-jdtls": { "branch": "master", "commit": "8eb5f0dbe6e126b392ddcaf45893358619893e45" },
  "nvim-lspconfig": { "branch": "master", "commit": "ee450e6a9364fc740236166dd57aaca1ec7cdb48" },
  "nvim-metals": { "branch": "main", "commit": "c6268555d0b471262af78818f11a086ddf30688b" },
  "nvim-navic": { "branch": "master", "commit": "8649f694d3e76ee10c19255dece6411c29206a54" },
  "nvim-scrollbar": { "branch": "main", "commit": "35f99d559041c7c0eff3a41f9093581ceea534e8" },
  "nvim-treesitter": { "branch": "master", "commit": "4b70dde72753a179333b4bba02518d234a30510e" },
  "nvim-ts-context-commentstring": { "branch": "main", "commit": "a6382f744f584bbf71d0a563af789af7190aabda" },
  "nvim-web-devicons": { "branch": "master", "commit": "475fbcfcb6ee7c35aa33a6b6207ebd4032791d87" },
  "plenary.nvim": { "branch": "master", "commit": "08e301982b9a057110ede7a735dd1b5285eb341f" },
  "pounce.nvim": { "branch": "master", "commit": "0c044cad69571d57d8f64a41cca95332859b6abc" },
  "sqlite.lua": { "branch": "master", "commit": "d0ffd703b56d090d213b497ed4eb840495f14a11" },
  "telescope-egrepify.nvim": { "branch": "master", "commit": "728dc1b7f31297876c3a3254fc6108108b6a9e9d" },
  "telescope-frecency.nvim": { "branch": "master", "commit": "6b6565e6584c86ca501bdac485cbdc2ca64556e4" },
  "telescope-fzf-native.nvim": { "branch": "main", "commit": "9ef21b2e6bb6ebeaf349a0781745549bbb870d27" },
  "telescope.nvim": { "branch": "master", "commit": "fac83a556e7b710dc31433dec727361ca062dbe9" },
  "todo-comments.nvim": { "branch": "main", "commit": "a7e39ae9e74f2c8c6dc4eea6d40c3971ae84752d" },
  "toggleterm.nvim": { "branch": "main", "commit": "066cccf48a43553a80a210eb3be89a15d789d6e6" },
  "translate.nvim": { "branch": "main", "commit": "30cc9e9f339b61e7bd40bc1ba7af73ea193bf589" },
  "vim-illuminate": { "branch": "master", "commit": "e522e0dd742a83506db0a72e1ced68c9c130f185" },
  "vim-test": { "branch": "master", "commit": "eb5bd18d58a859e7d55d732d37e4e2b94fa50275" },
  "vim-to-github": { "branch": "master", "commit": "9ea9c75b6cd48bd42823a39c56a05a2ff8161536" },
  "vim-vsnip": { "branch": "master", "commit": "02a8e79295c9733434aab4e0e2b8c4b7cea9f3a9" },
  "vim-vsnip-integ": { "branch": "master", "commit": "1914e72cf3de70df7f5dde476cd299aba2440aef" },
  "yode-nvim": { "branch": "develop", "commit": "eaf3141b919c143ebf174d7ad180abd9c032b38c" }
}

2023年を振り返る

Fri, 29 Dec 2023 15:03:17 +0000

趣味

OSS貢献

今年は初めてOSS貢献¹をできた年でもあった。2023年に行った貢献を種類ごとにリポジトリごとでまとめたものが以下。²

2023年8月以降で20個のPRをマージしてもらうことができた！ほとんどが簡単なPRだったとはいえ感謝してもらえることも多かったので単純に嬉しかった。

一定数OSSに貢献できたのは嬉しいが、ドキュメントやCIの修正など比較的ハードルが低めの貢献が多かったのも事実。

流石にOSSにPRを出すことには慣れてきたので2024年は上記のような貢献もしつつ何らかのOSSのアプリケーションコードへの貢献もしていきたい。

OSSメンテナ観点では、どのプロジェクトのメンテナも非常に紳士的で優しく接してくれる方が多かったので自分も見習っていきたい。特にRustコミュニティは初心者を歓迎する雰囲気があり、PRを送った際の体験がとてもよかったので真似したい。

Rustを書き始めた

2023年2月³ごろからRustを書き始めた。きっかけはkenkooooさんのこのスライドを読んで「Elmに似てて開発者体験がよさそう」と感じたので触ってみることにした。

満を持して始める Rust

入門に際して以下のようなことをやった。

Tour of Rustを読んでなんとなく雰囲気をつかむ
The Rust Programming Languageを手を動かしつつ(わからないところはいったん飛ばしつつ)一通り読む
RustでCLIアプリを作る

3. で作ったアプリをOSSとして公開した。

kyu08/fzf-make⁴

fzf-makeを公開した

こんな感じでMakefileに定義したtargetを曖昧検索で絞り込んで実行できるツールを作った。プレビューウィンドウがあるのが地味に便利なポイントでtargetの内容を確認しつつ実行できる。

Rustの理解を深めるのと自分の普段の作業を効率化したくて作ったがその両方が割と達成できているので満足している。特に所有権やスマートポインタに関してはThe Rust Programming Languageを読んだときにはイマイチ理解できなかったが実際に自分でコードを書いてコンパイラに指摘されてコードを修正することで理解を深めることができた。⁵

最初は身近な人に紹介して使ってもらったりしていたが、ある日面識のない日本人の開発者の方がバグ報告issue⁶を立ててくれて、インターネットの向こう側の人に自分のアイディアが届いて気に入ってもらえて、しかもわざわざバグ報告をしてくれたという事実がとても嬉しかった。

当然個人の趣味開発なので副業などとは違い時給を得て開発しているわけではないが、ものづくりを通して他者に喜んでもらうということが自分にとって最高の喜びだとわかっただけでも非常に良い経験だった。自分がOSSコミュニティに貢献したいと考えているのも究極は「人に喜んで欲しいから」なのかもしれない。

その後も何人かの人がstarしてくれたりTwitter(現X)で言及してくれたり⁷、issueを立ててくれたり、時にはPRを送ってくれたりして自分が書いたツールを通して海外のエンジニアとも交流できたのは自分にとって非常に刺激的だった。

これから開発したい機能や修正したいバグはまだまだあるので来年以降も引き続き開発を続けていきたい。Homebrewをはじめ、いくつかのパッケージマネージャでインストールできるのでぜひ使ってみてください。あとスターくれると大変嬉しいです！よろしくお願いします！

kyu08/fzf-make

Neovimへの寄付

筆者はNeovimには仕事・趣味のプロジェクトなど自分が行うすべての開発に収まらずちょっとしたタスク管理やブログ執筆などあらゆる場面でとにかくお世話になっている。

Neovim自体はOSSなので無償で利用できるわけだが、あるときNeovimコミュニティの成果にフリーライドに近い状態⁸になっている自分に気付いてからNeovimをはじめとしたOSSへの自分の関わり方に対し違和感を感じるようになったのでまずは経済的な支援でNeovimに貢献してみようと思い、GitHub Sponsorsを通じてNeovimに対して5$/Monthの寄付を開始した。⁹¹⁰

冗談抜きにNeovimのメンテナあっての自分の開発生活なのでこれは来年も続けたい。(本当のところはもっと稼いでもっと寄付したい)

ブログ

2023年は20個の記事を書いた。たまに「あの記事読んだよ！」的な反応をもらうことがあって嬉しかった。Twitterで話しかけたり感想を伝えてくれたりするのは嬉しいのでお待ちしています。

以下のような目的でやっているいて、後者はともかく前者は効果を実感できているので来年も適度に続けていきたい。

アウトプットを通して自分の理解と記憶への定着を深める
知見を共有して見た人の役に立つ

fzf-bookmark-openerを公開した

ブックマークをfzfで絞り込んで開くことができるCLIツール。自分が欲しかったので作った。

kyu08/fzf-bookmark-opener¹¹

同時期に書いたkyu08/gcp-url-generatorと組み合わせて業務でよく使っている。特定のGCPプロジェクトの特定のGCPサービスのコンソールをターミナルから開きたいことが多いので重宝している。

ktr0731/go-fuzzyfinderのおかげで100行程度のコードでやりたいことが実現できて大変助かった。

買ってよかったもの

Nuphy Air60 v2
klack
コアラマットレスのマットレス
オーダーメイド枕
Salomon XT-6
なすの天ぷら

大晦日に元気があったら記事として書きます。

仕事

やったこと

SaaSプロダクトのバックエンドエンジニアとして主に負債解消プロジェクトに取り組んでいた。

Scalaで書かれたアプリケーションのGoへの移行
DatastoreからCloud Spannerへの移行
E2Eテストの整備

などを行った。マイクロサービス何もわからないのでオライリーのマイクロサービス本あたりを読んで勉強したい。

学びなど

12月ごろからこれまでよりは大きめのプロジェクトを任せてもらっている。これまで担当したプロジェクトよりは自分で考える幅が広いのもありかなり楽しく働けている。引き続きより大きな信頼を勝ち取って自分の仕事の幅を広げていけるように頑張っていきたい。
ローカルでテストできる環境が整っていると開発速度が爆上がりすることを実感した。多少整備に時間がかかったとしてペイすることが多いと思うので他のプロジェクトでもうまいこと時間を確保して整備していけるとよさそう。
DBに関連する色々を雰囲気でやってしまっていると自覚があるので年末年始はRDBの基礎的な原理¹²や業務でメインで使っているDBであるCloud Spanner¹³の理解を深めていきたい。

2024年の抱負

引き続き仕事をモリモリがんばる。
OSS貢献を続ける。何らかのOSSのアプリケーションコードにも貢献する。

まとめ

最後まで読んでくれてありがとうございました！良いお年を〜

2024年もがんばるぞー

初めてOSS貢献したときの記事はこちら。 OSSに初めてPRを送ってマージされた話 ↩︎
(主に来年の自分向け)このスクリプトを使ってデータを集めた。GitHubで自分がOSSに送ってマージされたPRを集計するやつ.md ↩︎
tour-of-rustのメモリポジトリが2023/2頃にできていたのできっとこの頃から書き始めたはず。そういえばkeenさんのこのメモリの記事がすごくわかりやすかった。メモリとスタックとヒープとプログラミング言語 ↩︎
モチベーションになるのでスターください！拡散もしてくれると泣いて喜びます！ ↩︎
そういえばrust-lang/rustlingsというコンパイルエラーを修正していくことでRustの理解を深めるというコンセプトのリポジトリがあるので作りたいものはないがRustの理解を深めたい人にはおすすめかもしれない。（筆者はREADMEを読んだだけで触ったことはない） ↩︎
https://github.com/kyu08/fzf-make/issues/21 ↩︎
https://twitter.com/orhunp_/status/1692511841270841502 ↩︎
songmuさんも言っているようにOSSを使っていることを公言することもOSSプロジェクトにとってはプラスになるとは思うが、それぐらいでは済まないくらいNeovimに自分の開発人生を豊かにしてもらっている自覚がある。 ↩︎
初めてNeovimに寄付をしたときの話はこちら。GitHub Sponsorsを通してNeovimに寄付をした ↩︎
ちなみにNeovimへの寄付の使途はopen collective上で公開されている。 https://opencollective.com/neovim ↩︎
紹介記事はこちらyamlに定義したbookmarkをfzfで選択してブラウザで開くCLIツールをGoで作った ↩︎
SQLのインデックスとそのチューニングについてのオンラインブックや図解 DB インデックスあたりを読んでみようと思っている。 ↩︎
地道に公式ドキュメントを読んでいくつもり ↩︎

ThePrimeagen/harpoon を使ってみた

Fri, 17 Nov 2023 15:20:13 +0000

ThePrimeagen/harpoonというNeovimプラグインを使ってみたので気になっている人の参考になればと思い感想を書いてみる。

できること

ファイルをマークしてquick_menu(マークしたファイルの一覧)からファイルを開くことができる。操作している様子は以下の通り。

1. ファイルをマークして

:lua require("harpoon.mark").add_file()を実行してファイルをマーク

2. quick_menuからファイルを開く

:lua require("harpoon.ui").toggle_quick_menu()を実行してマークしたファイル一覧からファイルを開く

機能は他にもありそう¹だが筆者はこの機能しか使ってないので割愛。

嬉しさ

個人開発などファイル数が少ないプロジェクトだとそこまで効果を感じないが業務では(当然だが)一定数のファイルがあり、かつ定義ジャンプを繰り返しているとバッファにはたくさんファイルが存在しているのでtelescopeなどのfuzzy-finderプラグインを使ったとしてもファイルの行き来には多少時間がかかってしまっていた。

harpoonの導入によってファイルの行き来が爆速になってかなり作業効率が爆上がりした。

推しポイント

1. マークしたファイルが一度エディタを閉じても保持される

LSPが不調だったりしてNeovimを再起動することがたまにあるので地味に便利。

(一度Neovimを閉じてもマークしたファイルが保持されている様子。)

2. 自由に編集できる quick_menu

作者自身もお気に入りと言及しているが²quick_menuは純粋なテキストなので自由に編集できる。

つまりこんな感じでdd -> yのようなコマンドで自由に順番を入れ替えたり削除したりできる。普段のvimの操作感で扱えるのでとても直感的で使いやすくて嬉しい。

quick_menuを自由に編集している様子³

まとめ

気になった方はぜひ試してみてください。

インストール方法はこちら

GitHub - ThePrimeagen/harpoon

Contribute to ThePrimeagen/harpoon development by creating an account on GitHub.

https://github.com/ThePrimeagen/harpoon?tab=readme-ov-file#-installation

余談

そういえばThePrimeagenの好きな動画があるので貼っておく。

- YouTube

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

https://www.youtube.com/watch?v=nMHxdz-N7EU

他にはターミナルを開く機能とかtelescopeやtmuxとの連携機能もある模様 ↩︎
https://github.com/ThePrimeagen/harpoon/issues/205#issuecomment-1241921113 ↩︎
ちなみにdemoで使っているcolorschemeはcatppuccin-mocha ↩︎

GitHub Sponsorsを通してNeovimに寄付をした

Thu, 10 Aug 2023 16:35:48 +0000

Neovimに対してGitHub Sponsorsを通してOne-time¹の寄付をしたという話。

Neovimには仕事・趣味のプロジェクトなど自分が行うすべての開発に収まらずちょっとしたタスク管理やブログ執筆などあらゆる場面でとにかくお世話になっている。

なんでもカスタマイズしたくなってしまうこだわりの強い自分には非常にあっていて数多のプラグインを使って快適に開発を行っている。

大変お世話になっているOSSプロジェクトなのでいつかPRで貢献したいな〜と思いつつ何の気なしにNeovimのリポジトリを眺めていたら「そういえばGitHub Sponsorsでの金銭的な支援も立派なcontributionじゃん！」と思ったのでとりあえず寄付することにした。

案外あっさりできた

今回はひとまずOne-timeで20$だけ寄付してみることにした。

初めてGitHub Sponsorsを使ってみたが必要なのは

請求先住所の入力
クレジットカード情報の入力

くらいだったので5分もかからずにできた。

手続きが完了するとこんな感じでSponsorsに自分のアイコンが表示される。(嬉しい)

さらには自分のプロフィール画面にNeovimのアイコンが表示される。組織の一員感がでて地味にいいですねこれ。(結構嬉しい)

日頃から「OSSにお世話になっている分コードを書いて恩返ししたい…。けどなかなかすぐに解決できそうなissueも見当たらない²」みたいなことを思っていたのでまずは寄付という形でOSSに貢献できてよかった。

今後はPRでもOSSコミュニティに貢献していくぞという気持ちになった。

と思っていた矢先

個人開発のプロジェクトで使えそうなGitHub Actionsを物色していたところ早速自分でも修正できそうな箇所があったのでOSSに初めてPRを送ってみた。

(docs): use environment files instead of set-output by kyu08 · Pull Request #57 · mislav/bump-homebrew-formula-action

Thanks for creating a great workflow! What this PR changes This PR changes usage example in the README.md to use environment files instead of set-output because set-output is deprecated. close #56 ...

https://github.com/mislav/bump-homebrew-formula-action/pull/57

その時の記事はこちら。 OSSに初めてPRを送ってマージされた話

今後

Neovimの話に戻るが冷静にもし自分がJetBrainsのIDEユーザーだったら毎年ライセンスを購入するのは厭わないだろうにNeovimを使い倒させてもらっている自分が今回のOne-timeの寄付だけじゃ全然足りなくね？という気持ちになった。

なのでこれからはJetBrainsのライセンスと同じくらいの額(10$/monthくらい？)はmonthlyで寄付していこうと思う。

いずれはPRでもNeovimに貢献していきたいが、直近のPRを軽くみた感じluaやCが書けた方がよさそうだった。

自分が今一番書ける言語はGoなので何かGoを使ったOSSに貢献できないかな〜と思っていたところ自分がよく使っているTUIのgit clientであるLazygit³がGo製でかつドキュメントも整っていた⁴のでまずはコードリーディングからチャレンジしてみようと思う。

定期的な寄付ではなく、一度きりの寄付 ↩︎
一時期Good First Issueを漁りまくったりしてみたが、typo修正やUT追加などの一部を除いてはプロジェクトについての理解が浅い状態で貢献できそうなissueはあまり見当たらなかった。やはり全体のアーキテクチャや実際の動作を理解した上でなんらかのissueに取り組むのがいいんだろうなと思ったので腰を据えて特定のプロジェクトへのcontributionを狙っていこうと考えを改めた。 ↩︎
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
simple terminal UI for git commands. Contribute to jesseduffield/lazygit development by creating an account on GitHub.
https://github.com/jesseduffield/lazygit

↩︎
CONTRIBUTING.mdのようなドキュメントが整備されているだけでなく、authorのjesseさんが実際にLazygitに機能を追加する様子を収めた動画も公開されていたりと貢献に対してかなりオープンな印象 ↩︎

Tmux+NeovimでJetBrains IDEのScratchみたいな機能を実現している話

Sat, 04 Feb 2023 16:15:48 +0000

任意の構成のSandbox的な環境をTmuxのwindowとして用意するようにしたところターミナルから出ずにサクっと動作検証とかが行えてハッピーになったよ、という記事。ここではvanillaなGoのプロジェクトの例を紹介しますが、お好みの構成でSandbox環境を作ってみてください。

全然大したことをやっているわけではないですがTmux, Neovimやそれらのプラグインの普及活動になれば嬉しいので書いてみます。

動作イメージ

こんな感じでvanillaのGoプロジェクトをTmuxのwindowに開いておいて、確認したくなったときにすぐwindowを切り替えてコードを書いて実行結果を確認できるようにしている。(Gifの例はGoの書式指定子%+vの動作を忘れて試してみているところ)

Gifでやっていることは以下

GoのSandbox環境を開いたNeovimが起動しているwindowに切り替え
コードを書く
Neovim上でターミナルを表示
make runを実行してコード実行
結果を確認
元いたwindowに戻る

tmux-fzfなど筆者のターミナル環境については以下参照

開発の効率化のためにやっていることターミナル編

筆者はGoの動作を確認したいことがほとんどなのでこういった構成にしているが、必要に応じてよく使うFWをセットアップした環境を作っておくと便利そう。

プロジェクトの内容

Go固有の内容もあるので参考程度で。

├── .git
├── .gitignore
├── go.mod
├── go.sum
├── main.go
├── main.go.sample
├── main_test.go
└── Makefile

基本的にmain.goの中身を編集して、go run .で実行して実行結果を確認するということをしている。

Makefileの中身は以下のような感じになっていて、make runでコード実行、make clearでmain.goをまっさらにできるようにしているだけである。

.PHONY: run clear

run:
  @go run .

clear:
  @cp ./main.go.sample ./main.go

main.go.sampleの内容は以下。

package main

func main() {
}

あとはよく見返したくなるコードはmain.go以外のファイル名で保存したり、commitしておくと後からでもさっと確認できてよさそう。(筆者はそこまでやってない)

感想

ターミナルから出ずに作業が完結できてうれしい。

同様のことはGoの場合はブラウザからThe Go Playground(※)を開いても行えるが筆者は何でもターミナルでできると嬉しい人なのでできるようにしてみた。

※ブラウザ上で実行できるGoのエディタ + 実行環境がセットになったやつ。

Go Playground - The Go Programming Language

https://go.dev/play/

あとやるとしたらThe Go PlaygroundにあるURL発行機能とかを実現できると他の人への共有も楽になっていいのかもしれない。(今のところあんまり他の人に共有する機会がないので困っていない)

補足

最後に補足としてGif内で使っているNeovimのプラグインを紹介します。

ターミナル表示

voldikss/vim-floaterm

GoのSandbox環境のmain.goに書いたスクリプトを実行するために、Neovimからターミナルを表示するシーンで使っている。

コード編集してサクっと動作確認したいときなどに便利。(といいつつ最近動作の重さが目立ってきたので<C-z>でNeovimの起動元に戻ってターミナルを操作することが多い)

カーソル移動

yuki-yano/fuzzy-motion.vim

fmt.Printf("u: %v\n", u)のuから%vの位置にカーソル移動する際に使っているプラグイン。

動作のイメージはこんな感じ。

起動すると文字がグレーアウトするのでジャンプしたい文字列を入力するとその文字にジャンプするためのキーワードを表示してくれるというプラグイン。

同様の機能をもつプラグインとしてはeasy-motionなどのプラグインが有名だが、fuzzy-motionはジャンプしたい文字列をfuzzy-finder形式で絞り込んでくれるのが大きな特徴。(詳しくはリポジトリのREADME参照)

筆者はノーマルモードでfキーを押下するとプラグインが起動するように設定している。

カーソル移動の効率がよすぎて正直もうこれなしでは開発したくない。

LSP Server

neoclide/coc.nvim

Language Serverをホストするためのプラグイン。

すごく簡単にいうと補完や関数定義を表示したり定義ジャンプできるようにしたりしてくれる。

以上です。ここまで読んでくれてありがとうございました。