もっと「役に立たない」ソフトウェアを書こう
(ntietz.com)- 役に立たないソフトウェアとは、実用的な成果物へのプレッシャーから離れ、コンピューティングの楽しさを取り戻すための遊びであり、Hurl も「冗談」から始まった実験だった
- 技術者は有用な成果を出すことを求められる環境に長く置かれがちで、プログラミングを始めたきっかけだった 楽しさの火種 が弱まってしまうことがある
- 遊びのプロジェクトでは、テスト、イシュートラッカー、完成の基準を自分で決められ、十分に学んだり面白さがなくなったりしたらいつでもやめられる
- チェスエンジン、Redis API の一部を実装したキー・バリューストア、Wake-on-LAN ユーティリティ、チェスの可視化、チェスデータベースは、GUI・システム・ネットワーク・DB 内部 を学ぶための実験だった
- コンピュータをあまり深刻に扱わず、「役に立たなさそうな」ものを作ってみることは、学びと楽しさを同時に得られる現実的な方法である
「役に立たなさ」がもたらす自由
- Hurl について「なぜ作ったのか？」と聞かれ、短い答えは 冗談のため だった
- もう少し長い答えは、役に立たないソフトウェアがコンピューティングの楽しさと探求を体験させてくれるからである
- 技術者はたいてい、有用なものを作る仕事に縛られている
- ソフトウェアエンジニアは実際の問題を解決するコードを書く
- コンピュータサイエンティストは新しく実用的な成果を生み出すために問題を研究する
- 技術文書ライターは実際の技術と文書を扱う
- プログラミングを始めた人の多くは、何らかの形でその作業に 楽しさ を感じており、キャリア選択にもその感覚が一部影響していたかもしれない
- 一日中役に立つことをしなければならないと、興味は薄れやすい
- やるべきことには義務とプレッシャーが伴う
- あらゆる活動が仕事そのものと結び付く
- その過程で大切な 遊びの要素 を失いやすい
- 役に立たないソフトウェアは、こうした義務から抜け出す方法である
- プロジェクトから何を得るかを自分で決められる
- いつでもやめられる
- テストを書きたくなければ省いてもいい
- イシュートラッカーを使いたくなければ捨ててもいい
- 学びたかったことを学び終え、面白くなくなったならプロジェクトを終えられる
遊びで作ったプロジェクトたち
- ひどいチェスエンジンと UI はバグだらけだったが、GUI プログラミング、ゲームプログラミング、チェスエンジンの仕組みをより深く理解するきっかけになった
- キー・バリューストア は Redis API の一部を実装しながら、システムプログラミング とより効率的なコードの書き方を学ぶのに役立った
- Wake-on-LAN ユーティリティ は、WOL の仕組みと Rust でのネットワークプログラミングを身に付けるためのプロジェクトだった
- チェスゲームの可視化 は、コードでアートを作り、好きなゲームを可視化する方法を試す機会を与えてくれた
- チェスデータベース では、ビットマップ とデータベース内部構造について多くを学んだ
- コマンドが何をするのかを「mansplain」する LLM ベースのツールも作った
- POP3 サーバー側プロトコルの実装は未完成だが、プロトコルを学び、POP3 ベースのアプリがどのようなものになるか想像するのは楽しかった
- 『Crafting Interpreters』を Rust でなぞりながら、インタプリタとコンパイラについて多くを学んだが、目標は完成ではなく楽しむことにあった
- 『Mazes for Programmers』は Rust で半分ほど進めたところで仕事のようになってしまい、中断したし、それ以上進めたいとも思わなかった
- 小さなスクリプトも、アイデアや概念で遊び、実験するために書いていた
- Hurl もこうした遊びの一形態であり、役に立たなくても、何かを学び作る過程そのものから楽しさを得られる
1件のコメント
Hacker News のコメント
役に立たないソフトウェアを作るのが好き。今年作ったものだけでも、https://lines.potato.horse の uncolouring book、https://meat-gpt.sonnet.io の MeatGPT、https://tidings.potato.horse の Medieval Content Farm、https://butter.sonnet.io の You deserve butter、https://mrr.sonnet.io の Mrr、https://mrrr.sonnet.io の物理的に正確な Mrr がある。
その一部は実際には手の込んだブログ記事に近く、現実の問題を解くよりもコードで遊びながら表現するほうが簡単なので、過剰に作り込まれたものだ。もっと長いリストは https://sonnet.io./projects にある。
8歳の子どもが毎日 Scratch をやっていて、質問があるとよく手伝っているのだが、ただ楽しみのために、無駄なアニメーションまで入れた突拍子もないプロジェクトを作るのはかなり楽しかった。おかげで家では今や「Hurry to love! Hurry to love!」が流行語になっている。
実際、この中のかなり多くを忘れていた。
完全に同意。最近道化師学校に行って、プロジェクトを「ちゃんと」やることや「うまく」やることにこだわりすぎていたと気づいた。
人生は生きるもので、ソフトウェアをあまりに「正しく」やろうとすると、楽しさを絞り出してしまう。だから最近はもっと楽しくコードを書くようにしていて、そうするとコードもずっとたくさん書くようになり、流れもよくなった。最近はスキーマ進化のアイデアを試すために protobuf 風のバイナリシリアライズライブラリを自作し、今は CRDT ベースのローカルファーストなデータベースを作っている。昨日、最初のデータ同期ができて本当に興奮した。何年もの間、Serious Problems を解くためのコードもたくさん書いたし、衝動的に作ったコードも多かったが、皮肉なことにいちばん誇りに思っているコードは、楽しみで作ったものだった。面白いプロジェクトには何度も戻ってきて保守や改善を続けるが、まじめなプロジェクトは自分が離れるとしぼんで死んでしまうことが多かった。
ゲームで流れに乗ってプロセスを信じるのではなく、人は最強キャラを作る攻略を読み、能力値を最大化し、100% クリアを目標にし始める。結局、そのゲームを良くしていた探索や偶然の出会いの楽しさが消え、ランダムなサイコロ振りのように能力値を最大化することに時間を使うようになる。ほかの活動も似たようなもので、富であれコード品質であれ、何かを最大化しようとしているうちに、驚きや「とりあえずやってみる」が消えてしまう。
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
ところが最適化にはまると、突然、正解が一つしかないゲームになり、一晩で面白さが全部抜け落ちてしまった。うぬぼれと気まぐれでひどいものを作るときのほうが、多くを学ぶことが多い。「どれほど難しいっていうんだ？」という考えのせいで、何度も手に負えない深みにまで入り込んだが、そこから抜け出す過程でいつもものすごく学び、楽しさも見つけた。
どんな**技（craft）**にも、直感に反する部分がある。とにかくもっとたくさんやれば、たいてい最終的には上達する。ひどい短編を書き、不格好な陶器を作り、ゆがんだ風景画を描けばいい。
練習効果もあるだろうが、期待できる完成品が頭の中で完全に見えていないと、アイデアを自分で引っ込めてしまう傾向も大きい。特に分析的な人には、無駄な時間を減らす賢い判断のように感じられるが、同時に何も作らなくなる確実な方法でもある。「役に立たない」ソフトウェアプロジェクトの中には、ずっと役に立たないままだったものも多いが、作る過程でより大きな有用性を見つけたものもあった。結局は「打たなかったシュートは100%外れる」みたいな陳腐な言葉につながるが、言いたいことは分かるはず。
これは「役に立たない」ソフトウェアを書こうという話だけでなく、小さなプロジェクトではいわゆるベストプラクティスを避けようという主張にもなる
アイテムカタログ用の静的サイトジェネレーターを作ったのだが、カタログは単純で、頻繁には変わらない。どのデータベースを使うか悩んだ末、結局コードベース内の静的配列に全部入れることにした。考えるべき依存関係が1つ減り、自分の目的には完璧に合っている
実際にそう変わったかどうかは知らないが、その後「データベースが必要だ」という話が出ると、いつも最初に聞く質問になった
どうせグラフアルゴリズムを走らせるために全データをメモリに持ってくるので、読み取り専用データをデータベースに保存する意味はほとんどないと気づいた。SQLでBellman-Fordを実装するつもりはまったくない
ひどいコーダーだと思っていた友人とコーディングしていて、これを学んだ
仲が良かったので面白いプロジェクトをたくさん一緒にやったのだが、彼は本当に自分が何をしているのかよく分かっていないように見えた。あちこちからコピー＆ペースト、アーキテクチャなし、設計なし、悪い命名、半分くらいはコードが実際に何をしているのか本人も確信していない。それでも動いた。結局、彼は自分より多くのことを成し遂げていたのだと気づいた。些細なことにこだわらず、はるかに多く作業していた。単体テストは書かなかったが、成果物を子どものようにいじり回しながら、ずっと手動でテストしていた。最終的にその考えを受け入れるようになった。欲しい機能を持つ連絡先ソフトウェアがなかったので自作しようとしたが、洗練されたUIを作ろうとはせず、django-adminを使って終わらせた。そのひどいフォームの寄せ集めを10年使い続けていて、必要なことはこなしている。TOTP用のCLIがなかったころにはPythonで作り、シードを平文のTOMLにダンプした。暗号化を追加するまで5年かかったが、Veracryptコンテナからファイルをシンボリックリンクするだけで十分で、手間も少なかったからだ。2カ月前には、運動すると時間予算が増え、ビデオゲームをすると消費されるタイマーが欲しくて作った（https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...）。ChatGPTが吐き出したTailwindの塊をHTMXで動かすように貼り合わせたが、それで十分だった。友人たちに見せたら4人がアカウントを欲しがり、1人は依存症プログラム向けに医師として試用したいと頼んできた。登録フォームすらなかったのでハードコードした。若いころの自分に、物事を正しくやることや重要な問題だけに取り組むことへの執着をやめろと言ってやりたい。どうせ人生で一度も「正しさ」に到達したことなどないのだから
プロジェクトが面白いと証明されるまでIDEが付けた名前をそのままにするようになってから、成功率が上がった気がする。同じ根本原理に関係しているように見える
特に他人のコードを整理するときには、妙な論理がある。悪態をつきながら「いったい何を考えていたんだ？」と思う一方で、その人がとにかく走り出させたという事実もある
しかし彼は賃金の低い国で時給100ドルを稼いでいた。ドメインとコンテンツを買ってソフトウェアを作り直し、検索エンジン最適化のようなことをして、3カ月後に買値の10倍で売っていた。3カ月の作業で約7000ドルの利益なら悪くないし、フルタイムでもなかった可能性が高い
だが結論はこうだった。第一に、成功するのと同じくらい失敗も頻繁で、どちらになるか予測できず、後から直すほうが最初からそうしないより難しいため、期待値がマイナスの賭けのように見える。第二に、個人的にそういう働き方が嫌いだ。第三に、だからそのやり方がもっともらしく合うかもしれない仕事に時間を使いたくない。この経験のせいで、小さく些細なことの連続よりも、より深く大きなプロジェクトを探すようになった。その代わり今では、他人が自分と違う好みを持ち得ることをずっと気楽に受け入れられる。ソフトウェアを作る正しい方法より、自分に合った方法をより多く考えるようになった
それでも動く。大変ではあるが生産的で、その過程で多くを学んでいる。後で整理し、磨き込み、保守や拡張ができるようにする方法は分かっているので、実際に動く何かができてからやるつもりだ。特に新しいことを試すとき、このアプローチは過去にもかなり生産的だったので、十分支持している
Appleに以前、私のアプリが役に立たないという理由で却下されたことがある。アプリ審査チームが直接電話してきて、このアプリは役に立たず、Mac App Storeでは承認されないだろうと言われた
それから約12年後、その小さくて役に立たないアプリであるKeyboardCleanToolは何千人もの人に使われた。キーボードとTouch Barの入力をすべてブロックする、ごく小さな無料アプリだが、人々は想像もしなかった使い方をした。幼児にキーボードを好きなだけ叩かせたり、猫をノートPCの上で寝かせたりする、といった具合だ。何が有用かは本当に主観的なものだ
さらに10回ほど検索したあと、キーボードを掃除するよい方法を扱った記事で、キーボードをロックできるという理由でそのアプリが勧められているのを見て、ようやく理解した。結局ダウンロードしたが、「役に立たない」アプリにしてはかなり便利だった
子どものころ、母が掃除中にうちのMac IIsiをうっかり起動してしまったことがあり、それを口実にAfter Darkのスクリーンセーバーが必要だと説得することに成功した。まもなく画面には飛び回るトースターが現れた。懐かしい
掃除のとき、傷を付けかねないホコリを見るにはMacBookの画面とモニターが完全に黒くなる必要があり、トラックパッドも無効化されている必要があった。クリーニングモードをオフにするキーの組み合わせは、偶然押すのは難しく、覚えやすいものにする必要があったので、Commandキーを少なくとも8回連打する方式にした。Appleのアプリ審査のやり方にはいつも苛立つ。なぜユーザーの代わりに何が有用かを決めようとするのか分からない。審査を通った詐欺アプリがApp Storeで何か月も生き残っていることは言うまでもない
表現力があり、楽しいソフトウェアを使うのが好きだ。学び、探究するためであり、それが私をプログラミングに引き込み、今もつなぎ止めている
残念ながら、そこに必要性が割り込んでくる。飢えの脅威の下では、生産的でなければならない。一緒に生産する人たちを大切に思うし、生産できないと罪悪感を覚える。それが個人の時間の動機まで吸い取ってしまう。自分を表現する安定性と自由を持つ人が多いことには驚く。Recurse Centerに行ける人たち、多くの個人プロジェクトや冒険談を載せた無数のブログ記事を持つ人たちがうらやましいが、同時にうれしくもある。たいていは、そういう人生を作れる立場に至るために懸命に働いてきたのだろう。私もそうしたい。だがそうするには、さらに多くの人生を生産性にくべなければならないように見える。十分な年月を犠牲として燃やせば、運が人生を楽しむ権利を許してくれるかもしれない。おかしな話だ。そうなれば、役に立たないソフトウェアをもっと楽しめるようになるだろう
以前は、有用なソフトウェアを作ることが有能なソフトウェア開発者の証だと感じていて、簡単に説明できる形で明らかに有用でないことには時間を使わなかった
それはソフトウェアを雑務に変えてしまう、とてもよい方法だ。今では役に立たないものを作ることに抵抗がなくなり、楽しい。既存のアイデアも新しいやり方で作り直し、すでに誰かがやったかどうかは気にしない。単に楽しみなら、他人の曲をカバーするように同じ方法でやってもいい。学び、楽しみ、それ自体に価値がある。ときには改善する方法も見つかる。これはファームウェアを書き始めてから学んだ。常に有用でなければならないという重圧が大きすぎて、プライドを下げて脇に置かなければならなかった。ばかげたことをする粗いコードを書くのがものすごく楽しいと分かり、低いプレッシャーの中で楽しく学び、アイデアを体験する素晴らしい方法になった。しかも役に立たないものは驚くほど有用になることもある。この数年で作った役に立たないものはすべて、予想外に有用なコードや洞察、知識につながった
ずっと昔にHouston Recreational Computer Programming Groupという集まりを運営していた。ほぼ完全に、役に立たなくて楽しいソフトウェアプロジェクトを見せる会で、とても楽しかった
今は引っ越してしまい、今住んでいる街がそういう集まりを作れるほど大きいのかも、自分にまた運営するエネルギーがあるのかも分からない。個人的によかったのは、月に一度、誰も何も持ってこなかった場合に備えて、見せるための小さなプロジェクトを作らなければならなかったことだ。2年ほどの間にそんなことは数回しかなかったが、そのうちの一つ[1]はかなりいい出来になり、誇りに思っている。完全に役に立たないわけでもない。[1] https://github.com/smcameron/gaseous-giganticus
つい数分前に役に立たないソフトウェアを完成させたところなので、この記事はとてもタイムリーだ
CFR Brackets: https://susam.net/cfr.html
Demo: https://susam.net/cfr.html#3
Source: https://github.com/susam/cfr
C（色変更）、F（前進）、R（回転）、[（ブロック開始）、]（ブロック反復）という5つの命令だけをサポートする、ごく小さな描画言語だ。命令はLogoプログラミング言語に少し影響を受けており、ミニマリズムはP′′に影響を受けている。ただし、その二つとは違ってチューリング完全ではない。実用的な用途は意図しておらず、楽しみで作った。入力コードをできるだけ小さく保ちながら、面白い図形を描いてさらに遊んでみるつもりだ。「計算機科学において、計算の楽しさを保つことは非常に重要だと思う。」 — Alan J. Perlis