Jan. 2026

Akeometastic!

Last Modified: Sun Jan 18 03:41:37 UTC 2026

ソフトウェア設計の過程 (その3) 2026-01-18 [Sun] 12:13

さて、あとは実装するだけだが、ここでの質問は「Node.jsか、Pythonか?」ということであった。 これも悩んだすえ、Nodeでやることにした。バイナリサイズはNodeのほうが10倍以上デカいし、 JavaScriptは腐っていると思うのだけど、やっぱ Python で http.server使うよりは軽いので。 つうわけで、できたのは以下のようなコードである (抜粋のみだが、何をやっているかは推測できるだろう):

import fs from 'node:fs';
import path from 'node:path';
import http from 'node:http';
import querystring from 'node:querystring';
...

function quote(text) { ... }

function genFilename() { ... }

function genPage(text) { ... }

function renderPage(res) { ... }

function handler(req, res) { ... }

const server = http.createServer(handler);
server.listen(PORT);

ちょうど100行。こいつを起動しておき、nginx から proxy させる。 繰り返すが、フレームワークやライブラリは使っていないし、 fsやらhttpやらの原始的な機能はしばらく変化しそうにない。 コーディングにかかった時間は1時間ぐらいだが、実際には「仕様」を決めるのに1ヶ月ぐらい悩んでいた。 最初から AI にやらせてみたらどの程度のものができたのかは今度実験してみようと思っているが、 このレベルまで単純化させるにはそれなりの指示が必要そうだし、 頭の中にあるいろんな制約を言語化するにはそれなりの時間を必要とする。 結局、全部自分でやったほうがストレスは少ないだろう。

で、こんなことを長々と書いたのはなぜかというと、TODOアプリのような 超単純・原始的なものでさえ、プログラマの頭の中ではこれだけの要因と 何十という (暗黙の) 選択肢を考えているわけだ。 すべて列挙できているかどうかはあやしいが。 これが本当に複雑なプログラムになったら、その構成要素は2〜3ケタ上がると思われる。 2

ソフトウェア設計の過程 (その2) 2026-01-16 [Fri] 05:35

…ということで、使用するスタックは以下のとおりである:

…んなわけない。 以下、新山の好みによる勝手な仕様を追加する:
  1. 動かすプロセスは 1つだけ。だって1人しか使わないんだから、独立したDBを動かすなんて無駄。Dockerもこの時点で論外。
  2. 実際のコードは 1ファイルだけ。ビルドとかデプロイなんて面倒くさいことはしない。
  3. 依存モジュールは言語のランタイムだけ。パッケージのアップデートとか面倒。
  4. chroot環境下で動かせること。

ごく妥当な要求だよね? 最後まで迷ったのは「データ用のバックエンドとして何を使うべきか」ということであった。 履歴を残したいんならgitで、となるところだが、1個のファイルだけだし、自前データベースを設計してもよいのでは? ということで、そうする。その名も「ファイルシステム」である:

これでうまくいく理由は、そもそも1日にたかだか数回しか更新しないので、 以前のバージョンをため込んでいても大した容量にならないからだ。 たとえば1000回更新して、各テキストが 1MB 以上になったとしよう。 その場合の容量は 1000×1MB = 1GB である。しかしそうなるのは1年以上先だろうし、 そうなったらまた考えればよい (過去のデータは圧縮するか消してもいい)。 ということで、データモデルはこんだけ。Brooks も言っているように、 究極的にはデータモデルさえ決まればコードはおのずと決まる。 つうことで、あとは実装するだけだ。

つづく。

ソフトウェア設計の過程 (その1) 2026-01-12 [Mon] 06:49

これはソフトウェアに限ったことではないかもしれないが、 ソフトウェアの設計というものは、何百・何千という (隠れた) 決定の積み重ねである。 ここでは、その決定を逐一、解説していくことで、プログラマの頭の中にある 推論過程というものを明らかにしていこうと思う。

たとえば、さいきん新山が個人的に作った簡易TODO・メモ管理アプリとでもいうものを例にみてみよう。 これは、とあるサーバで動いており、そこにはテキストのFORMが一個だけあるという超単純なものである。 なぜこんなものを作ったのかというと…

そもそもの要求

  1. 通勤中とか寝床で浮かんだ考えとかメモとかを、とにかく記録しておきたい。
  2. 究極的には、1個の長いテキストファイルを保持できればいい
  3. PCからもスマートフォンからもアクセスできるようにしたい。
  4. 他人のアプリを使いたくない。 すでに似たようなものはオープンソースでいくつもあるだろうが、 30年後も保守されているかどうかわかんないから。 (ちなみに、新山はすでに30年近くこの日記を書いている。)
  5. クラウドストレージを使いたくない。そんなのに金を払いたくないし、これもいつ仕様が変わったりサポートが打ち切られるかわからない。
  6. できるだけ簡単なデータ形式を使いたい。いざとなったら手で編集できるように。

キモなのは c. で、そのためローカルなマシンにファイルを置いておくのではダメだということである。 過去数年、電子メールで同様のTODO管理ができないか試してみたが、やはりメールを書くのは面倒くさいので 長続きしないのだった。まえにも書いたが、TODOや日記のようなものが長続きする秘訣は 「とにかくアクセス障壁を下げる」ということにつきる。思い立ったら1-clickで書けるようなものがいいのである。 つうことで、これは自前で実装・ホストするしかないよなあ。しかしメンテが面倒なので、とにかく単純なのにしたい。 いっぽうで、この要求には以下のようなメリット? もあった。メリットというよりは、手抜きできるポイントというか。

ということで要求仕様はこんだけ。 設計フェーズに続く。


Yusuke Shinyama
Document ID: e8549e54f9104f7c06b9c105b9dab53d2e1f3c70fb577c5c2ae082c4e8ce4247