Malleable Computing、Emacs、そしてあなた

notes from /dev/null by Charles Choi 최민수 Malleable Computing, Emacs, and You 22 Jul 2026 Charles Choi すべては日常的なタスクから始まった。私は公開プロジェクトすべてにGitHubイシューを使用しているが、私の好みはOrg Agendaで物事を管理することだ。この2つを連携させるために、私はGitHubイシューをOrgファイルに手動でコピーしていた。タイトルと説明、そしていくつかのメタデータを、まるで動物のように。この分離にもかかわらず、重複したイシューはOrgで表現できるあらゆるものに対するスクラッチパッドとして扱うことを可能にした。このように、私はOrgでの重複イシューを、メモを取るための専用領域として、また公開されているイシューに共有したいフォローアップコメントを作成するための「ステージング」エリアとして使用した。私は、認めたくないほど長い間、手動でコピーしていた。 Emacsでタスクを十分に繰り返すと、必然的に「これを自動化すべきだ」という考えが浮かび上がる。この記事は、私がこのタスクをどのように自動化したかを recount し、その過程でEmacsのMalleable Computing（柔軟なコンピューティング）の能力を強調する。また、私の以前の記事「In Emacs, Everything Looks Like a Service」のフォローアップとしても考慮されるべきである。 要件 どのような自動化の試みにおいても、不可欠な質問は「何をしたいのか？」である。私は以下のことができたいと思っていた： GitHubイシュー（タイトル、説明、いくつかのメタデータ）を、Agendaビューで追跡可能なOrgタスクとして簡単にコピーできること。 EmacsとWebブラウザ間のコンテキストスイッチを最小限に抑えるため、主にEmacsから作業できること。 Org構文で自分の考えを表現できること。 新しいGitHubイシューを作成できること。 GitHub認証を扱うことを避けられること。 Emacsから、WebブラウザでGitHubイシューを開けること。 もう一つの不可欠な質問は「何を（したく）ないのか？」である。 フル機能のGitHubクライアントをインストールまたは記述すること。 ローカル（Emacs）とサーバー（GitHub）の状態間の同期ロジックについて、過度に心配すること。 これに多くの時間を費やすこと（理想的には1日で作業が完了し、長くても1週間）。 仕様 上記の要件を踏まえると、次の質問は「どうやってこれを構築するか？」である。この特定の演習のために、私は既存のGitHubコマンドラインユーティリティ`gh`のインストールを活用することにした。これの利点は以下の通りである： GitHub認証は`gh`に委任される。Emacsから直接扱う必要はない。 Emacsは、以下の図に示すように、`gh`をGitHubへのRESTサービスとして扱うことができる。 ツールセットを完成させるために、さまざまなElispパッケージやプログラムを活用できる： ユーザーインターフェースには、メニューと表示にそれぞれTransientおよびVariable Pitch Table (vtable) パッケージを使用する。 OrgからMarkdownへの変換には、ox-gfmを使用する。 MarkdownからOrgへの変換には、Pandocを使用する。 ElispネイティブのJSONサポートを、`gh`からのJSON応答をデシリアライズするために使用する。 実装 上記の実際の実装は、パッケージ`fj`として公開されており、そのソースコードは`fj.el`ファイルで確認できる。特筆すべきは、以下のコードに示すように、`gh`経由でGitHubイシューを取得する作業を行う関数`fj-request-issues`である。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16(defun fj-request-issues (repo) "Request issues for REPO." (let* ((fields fj-browser-fields) (cmd-list (list "gh" "--repo" (format "'%s'" repo) "issue" "list" "--limit" (number-to-string fj-request-issue-count) "--json" (string-join fields ",")))) (json-parse-string (shell-command-to-string (string-join cmd-list " ")) :null-object nil))) `fj-request-issues`が提供する高い抽象度を考慮すること： `cmd-list`リストはリクエストを形成する（この場合、`gh`を呼び出す引数）。 `shell-command-to-string`はリクエストを`gh`にディスパッチする。 返されたJSON応答は、`json-parse-string`によって処理され、JSONをElispハッシュテーブルにデシリアライズする。 これらすべては、20行未満のコードで達成される。 返されたハッシュテーブルの結果は、その後、以下のコードに示すように`vtable`を埋めるために処理される。 `vtable`から、ユーザーは付随するウィンドウに表示される詳細を表示しながら、イシューのリストをナビゲートできる。 上記の要件を満たすために、複数のコマンドと関数がこのハッシュテーブルと連携して作成された。これらは以下のTransientメニューからアクセスできる： Malleable Computing に関する考察 Elispは動的プログラミング言語であるため、上記の関数（またはそのバリアント）は、実行中のEmacsセッション内でコーディングおよび評価できる。Emacsでは、再起動することなくコードの動作をプロトタイプ化するのが日常的な実践である。これは、静的言語で構築され、拡張性がないツールとは対照的である。これらのツールでは、ソースコードが利用可能であれば、動作を実行するために編集-コンパイル-デバッグの開発サイクルを適用する必要がある。 Emacsは、Elispコードの編集と評価のための多数の方法を提供している。その中には以下のようなものがある： スクラッチバッファ Elispファイル Orgソースブロック IELM REPL Eshell eval-expression (M-:) ロードされたElispコード間には分離がないため、すべてを即興的にオーケストレーションできる。シェル経由でEmacsからアクセスできるあらゆるプログラムが、このミックスにさらに追加される。 高い抽象度があれば、望ましい動作のために書く必要のあるコード量は少なくなる可能性がある。 この記事の執筆時点で、`fj.el`は約400行のコードで構成されている。これは`cloc`によって測定されている： 1 2 3 4 5 6github.com/AlDanial/cloc v 2.08 T=0.01 s (146.4 files/s, 76550.1 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Lisp 1 93 38 392 ------------------------------------------------------------------------------- 私が望む基本的な動作（GitHubからイシューを取得し、表示する）を構築するのに約2時間半かかり、残りの日は元の要件すべてをカバーするのに費やされた。それ以降のすべてはリファクタリングだった。 意欲のある読者は、`fj.el`を調べてその詳細を理解することを歓迎する。しかし、現時点では、ソフトウェアエンジニアリングとMalleable Computingについて考察する機会を得たい。 ソフトウェアのスコープ - あるパーセンテージの逸話 90/90ルールは、「コードの最初の90パーセントが開発時間の最初の90パーセントを占め、残りの10パーセントのコードが開発時間の残りの90パーセントを占める」と提唱している。これに密接に関連するのは、ソフトウェア開発に（誤って）適用されるパレートの法則（別名80/20ルール）である：ユーザーの80パーセントは、機能の20パーセントしか実際には使用しない。 制御理論には、有界入力・有界出力（BIBO）安定性という概念がある。システムがBIBO安定であれば、有界な入力は何であれ、有界な出力も生成される。これらの考えを組み合わせると、望む機能（BIBO安定性）がその20パーセントの提供範囲内にある場合、望ましい結果をより速く得られる位置にいることになる。残念ながら、この観察は、大規模な聴衆を満たす必要があるツールを出荷する多くのプロデューサーには利用できない。 Sinofsky氏の投稿「What is Software Bloat, Really?」では、特に機能セットに関して、Microsoft Officeの製品定義の問題を説明している。彼らのユーザー調査から、彼らはこの発見に至った：「…データは完全に決定的だった。Officeのほとんどは使用されていた。しかし、一人の人間が製品全体を使用していたわけではない。」 製品定義について議論する際には、2つの非公式なダイナミクスを区別することが役立つ：供給と需要である。供給のみで提供されるソフトウェア（MS Officeの場合など）では、製品定義の重みはプロデューサーが負うことになる。プロデューサーが広範な聴衆にサービスを提供したい場合、その機能セットと対応する開発スコープも広範になる可能性が高い。需要側では、消費者は新機能のリクエストを行うことができるが、その優先順位はプロデューサーによって制御される。この状況では、プロデューサーと消費者の役割は明確に区別される。 Malleable Computing、つまりユーザーがデジタルツールを適応させ、再形成する主体性を持つソフトウェアは、別の可能性を提供する。プロデューサーはビルディングブロックを提供し、消費者が独自のツールを作成できるようにする。この中で、既存のコードとプログラムは新しい動作を作成するために再結合される。