Skip to content

Instantly share code, notes, and snippets.

@sile

sile/main.md

Last active December 17, 2025 04:49
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save sile/ff7080fd41d3f74100f80c963bcbb429 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save sile/ff7080fd41d3f74100f80c963bcbb429 to your computer and use it in GitHub Desktop.
Download ZIP
2025年の趣味開発環境
Raw
main.md

2025年の趣味開発環境

2025年は趣味開発環境の変化が大きかったので備忘録として残しておく。

前提:

  • 趣味開発はほぼ毎日している
  • 開発するのはコマンドラインツールやライブラリが多い
  • 言語はほぼRust
  • 開発はほぼAndroid上
  • GUI 系ツールは基本使わない（GitHubをブラウザで見るくらい）
  • 仕事の開発環境はまた別（このgistの対象外）

ハイライト

  • E Inkタブレットでの開発に移行
  • Emacsから自作エディタへの移行

2025/12/14時点での趣味開発環境

ハードウェア:

Androidアプリ:

  • Termux: Linuxターミナルエミュレータ
  • Unexpected Keyboard: プログラミング向けのソフトウェアキーボード

コマンドラインツール（使用頻度が高いもの）:

  • git: 説明不要
  • gh: GitHub CLI
  • tmux: ターミナルマルチプレクサ
  • fish: シェル（デフォルト設定でもいろいろと便利に使える）
  • cargo: Rustのビルドツール
  • 自作系:
    • kk: テキストエディタ（Emacsからの移行）
    • niho: ローマ字から日本語への変換（DDSKK からの移行）
    • daberu: Claude API クライアント
    • mamediff: git diff フロントエンド（Magit からの移行）
    • mamegrep: git grep フロントエンド（helmからの移行）
    • grepatch: grep の出力形式を利用したテキスト一括置換ツール（helmからの移行）

詳細: E Ink Android タブレット

最近「ViwoodsのE Inkタブレットがヨドバシカメラの店頭で購入できるようになった」というニュースを見かけて衝動買いした。 それまではブランド自体を知らなかったけど、E Inkデバイスで有名なBooxのタブレットは、もともといくつか持っていたし、趣味開発は主にAndroid上で行っていた。

似たサイズ感のタブレットとしてはBoox Go 10.3を持っているけど、Viwoods AI Paperとは一長一短ある感じ（どちらもいいデバイス）:

  • 共通:
    • Good: 質感がいい
    • Good: 薄くて軽い（どちらも370g程度）
    • Good: 画面がキレイで見やすい（特に文字 主体の場合）
    • Good: フロントライトがない（ない方が好み）
    • Good: コートの内ポケットにギリギリ入る
    • Not Good: 画面のリフレッシュレートが高くはない（E Inkとしては普通）
  • Viwoods AI Paper:
    • Good: 指紋認証がある
    • Good: スピーカーがない（余計な機能はない方がいい）
    • Good: 画面のコントラストがより高い
      • [NOTE] Boox Go 10.3も十分高くて比較しないと分からないくらいではある
    • Good: 物理ボタンがある
      • 3つの内の1つが「AIボタン」なのはもったいない（不要なので無効にしている）
    • Good: ストレージが128GB（Boox Go 10.3の64GBでも不足はしていないけど、多い方が安心感がある）
    • Not Good: 標準で画面回転を行う方法がない（サードパーティのアプリをインストールすればできる）
    • Not Good: 画面のリフレッシュレートがより低い（ハードウェアキーボードだと少し気になるレベル）
    • Not Good: タッチ感度が悪いことがある（手で持たずにスタンドにおいて操作すると反応が悪い気がする）
  • Boox Go 10.3:
    • Good: 画面のリフレッシュレートがより高い
    • Good: ジャイロセンサ（？）がついていて、画面の自動回転ができる
    • Good: 画面分割ができる（ただ、そこまで使いやすくはない）
    • Good: 背面の質感がいい
      • Booxはレザーで、Viwoodsはガラスっぽい感じ
      • 左手でタブレットを保持して、右手でキー入力するスタイルだとBooxの方が快適

正直、自分の用途であればどちらでもいいけど、外に持ちだす時に指紋認証があるのは大きいのでViwoodsをメインにしている。

なお、コートの季節ではなくなったら、おそらく（大きめのポケットに入る）7~8インチサイズのタブレットをメインにする。 実際、今年の春夏はBoox Go 7（モノクロ）を使っていた。 ただし、このGo 7はマルチタッチに問題 （別のタッチイベントがあると、押下したままのはずのところが再タッチ判定になってしまう）があって、 ソフトウェアキーボードでのプログラミングに支障が出てしまうのだけが残念 （サポートに問い合わせた感じでは個体差ではなさそうだった）。

また、昨年はカラーE Inkタブレットを試したこともあるけど、プログラミング（とKindle）が主体の自分の用途ではモノクロの方が向いていた。

趣味開発をE Inkタブレットで行うようになって気づいた面白い発見としては 「意外とシンタックスハイライトがなくてもプログラミングには困らない」ということ (「シンタックスハイライトありの液晶」よりは「シンタックスハイライトなしのE Ink」の方が好み）。

この発見のおかげで、自作テキストエディタに実装すべき機能がひとつ減って楽になった。

E Ink特有の画面のリフレシュレートの低さ（に起因する入力レイテンシ）は気になるといえば気になるけど、慣れたら許容できる。

ViwoodsもBooxメモリやプロセッサは（ハイエンド端末に比べたら）貧弱だけど、自分の開発用途では問題ない （基本、タブレットローカルでの開発やビルドだけど、そんなに重いものは作らない ）。

詳細: Termux

Termux自体は数年前から使っているLinuxターミナルエミュレータ。 通常のLinux環境とは、細かいところでいろいろと差異はあるけど、おおむね問題なく開発用途で使えている。

E Ink環境向けには表示がモノクロ（グレースケール）になるように colors.properties を設定している。

ただ、TermuxのGitHubリポジトリのREADMEを見るとメンテナを募集しているようで、長期的な利用可能性には少し不安がある。

Androidが公式でLinuxターミナルを提供する、という話もあるけど、春頃のPixel Feature Dropで試してみた感じでは、 まだまだ実用には遠い印象だった。 こちらが正式リリースされたら切り替える可能性はある。

詳細: ハードウェアキーボード

2年前からVoyagerキーボードを使っているけどほぼ満足。 キーのレイアウトはブラウザから簡単に変更可能だけど、デフォルトが使いやすいのでそのまま使っている。 なお、Voyagerキーボードに慣れた弊害として、普通のキー配列でブラインドタッチができなくなった。

最近トラックボールアタッチメントと一緒に、キーボード追加で購入した。 トラックボールの使用感は悪くなかったけど、趣味ではポインティングデバイスを使う機会がないので、仕事専用。

キーボードには十分に満足しているけど、あえて要望を挙げるなら、 一番上の列を使っていないので、そこを削ってよりコンパクトにしたバージョンがほしい。

参加はしていないけど、今年は日本で複数回イベントをやっていたり、サポートに日本語で対応してくれたりと、地味に日本対応が手厚い。

詳細: ソフトウェアキーボード

感覚的には、今年の趣味開発の半分くらいはソフトウェアキーボードで行っているので、この使いやすさは重要。

しばらくはいろいろと試していたけど、（おそらく）昨年からはUnexpected Keyboardに落ち着いている。

日本語入力には対応していない（あとはそもそもTermuxがIMEと相性がよくない）けど、 今年はnihoを使って日本語入力を行うアプローチを確立したので、この問題は解決した。

ソフトウェアキーボードはそのうちに自作したい（「来年やりたいこと」を参照）。

詳細: Emacsからの移行

ある意味で今年一番の変化はこれ。 Emacsは（おそらく）15年以上使っており便利ではあった。

移行を考えた主な理由は、

  • Emacsとtmuxで役割に少し重複がある
    • たとえばどちらも複数ウィンドウを扱う仕組みがある
    • => それなら（この目的のためには）tmuxだけがあれば十分では？
  • Emacsで使っている便利パッケージは、他では使えない
    • 特にTermux環境で、DDSKK（日本語入力パッケージ）がEmacs以外で使えないのは不便
  • Emacsは自分には複雑すぎる
    • たぶん1%くらいの機能しか使いこなせていない
    • バージョンが更新されても新機能を使うことがほぼない（そもそもチェックしていない）
      • その割に使用パッケージで問題がでたりすることがある
  • デフォルトないし標準で提供されているスタイルとモノクロE Inkとの相性がそこまで良くない (いくつかほぼ白黒に近いスタイルはあった)
  • 単純にTUIテキストエディタを実装してみたかった

なお VSCode への移行を昨年以前に何度か試みたことがあったけど、結局挫折した （プラグイン周り仕組みは魅力的だったけど、GUIしかないのが致命的）。

Emacsからの自作テキストエディタへの移行にあたっては、 エディタそのものというよりは「Emacs上で動作するパッケージ使って実現していた機能をどうするか」ということの方が問題だった。

それに対処するため今年の始めから、それぞれの機能を実現するための独立したTUIツール群を実装していき（or 特定機能は不要という判断をして）、 それらが一通り揃った夏頃に、自作エディタの実装とEmacsからの移行を行う流れとなった。

別ツールで代替した機能:

  • gitのdiff確認やコミット、プッシュ:
    • Magitが便利だった
    • diffの確認や編集はmamediffというTUIツールを実装して代替
    • またmamediffの中で、任意の外部コマンドを実行可能にすることで、mamediffで差分を確認しながらコミットやプッシュも行えるようにした
    • mamediffはtmuxのポップアップウィンドウとして起動するようにショートカットを割り当てる
    • "mameXXX"という名前のツールが続いているのは、当初はエディタの名前をmameにしようと思っていたから
      • 途中で別にこれらのツールがエディタを密結合する必要もないと思い、エディタの名前も変わった
  • 複数ファイルを跨いだコード検索:
    • helmをmamegrepというTUIツールで代替
    • gist全体分量が増えてきたので詳細は省略
  • 複数ファイルを跨いだコード置換:
    • helmをgrepatchというコマンドラインツールを実装して代替 -「一括置換のフォーマットにgrepの出力を使うといいのでは」というひらめきが元
    • gist全体分量が増えてきたので詳細は省略
  • 日本語入力:
    • DDSKKをnihoというコマンドラインツールを実装して代替
    • nihoの動作としては「標準入力から受けとったローマ字列を辞書に従って、ひらがなや漢字に変換して標準出力に出す」という単純なもの
    • テキストエディタから使う場合は「選択範囲を標準入力で渡してnihoを起動して、結果で選択範囲を置換」する
    • gist全体分量が増えてきたので詳細は省略

不要と判断した機能:

  • 画面分割（や複数ファイルのオープン）:
    • tmuxに任せる
  • プラグイン的な仕組み:
    • 代わりに外部コマンドの呼び出しや、ファイルを通しての情報のやりとりを行いやすくする
    • テキストエディタはテキストを編集できればいい
  • シンタックスハイライト:
    • そもそもカラー表示はモノクロE Inkと相性が悪い
    • シンタックスハイライトなしでもあまり困らないことが分かった
    • ただ、キーワードの太字表示くらいはあってもいいかもしれないとは思う（けど実装しなさそう）
  • LSP:
    • こっちは（不要と判断するまで）けっこう迷った
    • このサポートがあるとプログラミングをする上で便利なのは間違いない
    • ただし、エディタでサポートすることをためらう理由はあった:
      • RustのLSPが原因でTermuxが落ちることがあった（タブレットのメモリスペックが貧弱なので）
        • 「バックグラウンドで勝手に動作する」というモデルも（あえて言うなら）あまり好みではない
      • エディタの実装がだいぶ複雑になる
    • 別ツールに切り出すアプローチ（sile/lspterm）も試してみたけど、これはしっくりこなかった
      • やっぱりLSPを使うならエディタと密に連携している方がいい
    • 不要と判断した一番の理由はLLM
      • そもそも自分でコードを書く機会が減るならLSPサポートの重要性も下がる
      • 手でコードを書く部分で（LSPがないことによって）多少時間が掛かるようになっても、それが全体のボトルネックになることはなさそう
      • 実際にLSPなしでしばらく試してみてもなんとかなった
        • そもそもLSPを使わずにプログラミングをしていた時間の方が長いので、当然といえば当然ではある

結果的に、自作エディタ（kk）自体はかなり単機能な仕様になったので満足している。 ただ確実にかなりニッチな需要を満たすためのエディタとなったので一般向きではない（というかほぼ自分専用）。

詳細: LLM関連

今年はLLMを使った開発が一気に当たり前になった年だった。

自分の趣味開発での使い方としては、Claude APIの呼び出しを薄くラップしたコマンドラインツール（daberu）経由での利用がほとんど。 使用モデルはclaude-haiku-4-5-20251001。

よくやるのは、以下のようにコードの実装させたい箇所にTODOコメントを残しておき、それをClaude APIに依頼して実装させる、というもの。

struct Foo;

// NOTE: 次の3行を選択する（選択内容は ~/.kk.clipboard ファイルに保存される）
impl std::fmt::Display for Foo {
  // TODO
}
// TODO部分とファイル全体を渡して実装を依頼する
// （必要なら`-r`で関連するファイルを追加で指定する）
$ cat ~/.kk.clipboard | daberu -s'Fix TODO' -r foo.rs
...レスポンス（必要な範囲を手でコピペしてコードに反映）...

// レスポンスが不十分な場合は追加でやりとりする
$ echo 'あそこはこんな感じで修正して' | daberu -c
...レスポンス...

感覚的には、モデルの性能やプロンプトよりは「参考ファイルを適切に指定する」ことの方が重要な印象 （そもそも自分のLLMの使い方の大半が「すでに存在するベースコードの一部を改変して別の用途に適用する」というものなのが影響していそう）。

LLMを使うようになっても設計面ではあまり変化はなかったけど、 独自マクロを定義することはほぼなくなった。

もともと自分がマクロを定義したくなるケースは、（関数などでは表現できないけど） 比較的単純な定型コードを人間が繰り返し記述するのが手間だったからだけど、 LLMはこういったコードの生成が得意なので、マクロの必要性を感じることがあまりなくなった （その分、マクロ自体の実装の可読性やメンテナンス性の悪さ、 DSL的要素の追加による利用側コードの理解負荷の増加といったデメリットの方が、より気になるようになった）。

それ以外では、

  • LLMのおかげで「自作エディタでLSPをサポートしない」という判断ができた（上述）
  • ちょっとした調べものはClaude APIで済むことも多いので、ブラウザに移動せずにターミナルで作業が完結することが増えた

辺りが嬉しいところ。

なお、Claude APIについては会社が「仕事で使っているアカウントを私的用途でも使って大丈夫」と言ってくれているので、 どれくらい料金が掛かっているかを全く意識せずに済んでいる（実際知らない）。 感謝。

来年やりたいこと

  • 自作ソフトウェアキーボード
    • Unexpected Keyboardは悪くないけど不満点もある
    • 不満点:
      • レイアウトの自由度は高くない（キー配置は基本固定で、右寄せや分割もできない）
      • スワイプでの記号等の入力は（プログラミングだと頻度が高いこともあり）地味に面倒
      • Termux以外では普通のキーボードを使いたいので切り替えが少し手間
    • そのため、ソフトウェアキーボードの自作は以前から興味はあった
    • ただ、そのためだけにAndroidアプリの開発環境を用意するのが面倒で放置していた
    • しかし、最近「Termux用のキーボードは（AndroidアプリではなくTermux内で動作する）TUIでもいいのでは」と思ったので、これを試してみたい
      • tmuxならキーボード用のpaneから別のpaneにキー入力を送るのも簡単（tmux send-keys）
      • ただtmuxベースだといろいろと制限もある（下に続く）
  • 自作ターミナルエミュレータ
    • tmuxは全体的にはいい感じだけど、ポップアップウィンドウ周りはいまいち
      • ポップアップ内では機能がいろいろと機能が制限されたりする
      • ポップアップは便利なので多用したいけど、既存機能では物足りなくなってきた
    • 上のTUIキーボードを自作した場合もtmuxだと相性が良くない
      • キーボード用のpaneはカーソルやウィンドウ切り替えの際の処理を特別扱いしたい
    • つまりポップアップウィンドウが柔軟に扱えて、ソフトウェアキーボードが組み込まれたターミナルエミュレータを作ってみたい
  • 自作エディタの正式リリース
    • 今はまだ細かいバグがたくさんあるけど、なんだかんだで使えてしまっているので放置している
    • ドキュメントも最低限のものは書きたい
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment