去年の8月末ごろにメルカリでエレキベースを購入し、楽器演奏に手を出し始めた。これは自分にとってDJ、DTMに続く第三の音楽趣味だ。齢28にして演奏技術など習得できるものかと不安だったが、幸いなことにある程度の才能はあったらしく、練習2〜3ヶ月目程度でとある演奏会に参加した際、その練習期間にしては「上手い」、アドリブにおいて「耳が良い」との評価をメンバーの方から頂いた。その他の趣味や人間関係、仕事のことなどもあり、[1日8時間練習できておらず友達を失くせていないのが残念でならない](https://keisuke-gt-ymsk.hatenablog.com/entry/20190806/1565101851)。今のところベース練習9:1ギター練習といった割合で、基本的にはベーシストとしてやっていこうと思っている。

---

練習を続ける傍ら、次第に楽器やエフェクター類の電装系の仕組みにも興味が出てきた。各所で電子部品を買い集め、簡単なバッファー（音声信号のインピーダンス変換を行う装置）をブレッドボード上に組んでみたりもした。ただ動作するだけのエフェクターならある程度作れる自信はついたが、筆者にはデザインセンスがないため実際にモノとして何か作って頒布したりはおそらくしないと思う。逆に言うと、ケースやパッケージさえ適切に作れるのなら全然販売したい設計がいくつもある。

市販のエフェクターの最大の問題点はセンターマイナスのDC入力を採用している点だ。これは電子楽器界隈の最大の汚点や恥と言っても差し支えない。まともに電子工学を学んだ人間がこんな設計を許すとは思えないので、誰かが声をあげて正し始めなければならない。少なくとも、センターマイナス（すなわちDCプラグのスリーブ端子に電圧を印加する）と聞いて、即座に活線挿抜によるシャーシグランドやフレームグランドへのショート事故を想像できない人間は電子機器を作るべきでない。しかしそれが横行しているのがエフェクターペダル界隈だ。

センターマイナスの利点や理由を説明しようとしている人たちも[いる](https://note.com/matananika/n/neb1fef88e1f9)には[いる](https://kanengomibako.github.io/pages/00333.html)。しかしショート事故防止の方が絶対的に重要であり、正気な人間ならいくらコストダウンといってもそこを削ろうとは思わない。また、伝統的にそうなっているからそれを選択する、というのは最悪の理由だ。というより、それが理由であってはならない、不幸の再生産である。ダイオードブリッジを嚙ませてセンタープラス・センターマイナスどちらにも対応させるという選択もありうるが、どちらかと言えば、あまりに危険なセンターマイナスのDCプラグを許容することによる世界規模の悪影響の方が大きいので、センタープラスに統一するのが適切な選択だったはずだ。

活線挿抜をしないことを強制はできない。いくら呼びかけようとやる人はやる。人は横着する生き物である。人が機械の面倒を見るのではなく機械が人の面倒を見るべきである。自分が常に活線挿抜をしないと自信を持てる（＝機械の面倒を見れる）のならセンターマイナスの機器をそのまま用いてもよいかもしれないが、そうでない人間は自分の用いるすべての機器をセンタープラスに修正してから使う（＝機械に面倒を見てもらう）べきである。筆者は、そのような改造専門の業者として働いてもいいと思えるくらいにはこの状況を問題視している。

---

最低限の間に合わせとして、トラベルギターやトラベルベース、5弦ベースなども買った。現時点で筆者が所有する楽器は下記のとおり。

0. GrassRoots G-JV-58
1. Donner HUSH-X
2. Batking 5弦トラベルベース
3. Ibanez TMB425B-BKF

自宅に置くアンプ類はVOXのPathfinderシリーズを使っている。0.は重心的にヘッド落ちしやすいため右肩掛けで使っている。2.は[Amazonで入手した謎の中華製ベース](https://amzn.asia/d/07ZcHYHv)だが、普段の練習用に取り回しが良いため一番よく触っているかもしれない。この軽さに慣れるのが怖い。いずれヘッドレスのちゃんとしたベースが欲しいと思う。

---

全体的に5弦ベースの方が演奏が楽だと感じる。大抵の曲は4弦前提で譜面が作られているため、シンプルに5弦は鳴らすことがほぼ無く、むしろ4弦を弾く時の指置きとして使うことができ、1〜2弦を弾く時と同じ感覚で4弦まで弾くことができる。自分はたまたま4弦ベースから練習を始めたが、5弦から入ればよかったと思う。他人に勧めるなら5弦だ。

しばしば人が親指をピックアップに置くやり方を初心者に勧めているのを見かけるが、1〜2弦を弾く時に3〜4弦をミュートしなければいけない関係上、親指は常に側面を弦に押しあてておくやり方にした方がいいと思う。その方がどの弦を弾くときもフォームを変えなくて済むようになる。また、親指をピックアップにおいてしまうと、位置的に撥弦する指がピックアップ表面にカチカチ当たってしまい不要なノイズ源にもなってしまう。ミュート可能・フォーム安定・ノイズ抑制の一石三鳥である。

ベースが弾きたい

Web2.0時代のWebアプリケーションたちは、ユーザーがインターネット上にアップロードしたデータが引き続き自分のコントロール下にあるというまやかしを人々に信じ込ませてしまった。画面に「削除」ボタンと「編集」ボタンを白々しく提示することによって。

---

本来、インターネット上に何かをアップロードするという行為は、メッセージをボトルに詰めて海に流すようなものであり、少なくとも物理レベルではそのコントロールを手放すこととほぼ同義だ。ユーザーアカウントはボトルが最初に辿り着いた先と連絡をとる手段にすぎず、「削除」ボタンを押して「削除しました」と表示されたからといって、実際に削除されたかどうかなどわからない。それは引用符付きの「削除」にすぎず、論理削除かもしれない。さらには、もしそのデータがほんのひとときでもインターネット上に公開されている状態であったのなら、誰がどこにデータを複製しているかなどわからないので、アップロード先のサーバー管理者ですらその実態を知ることはできない。

そのような事実を知らない人々に対して、アップロード後にあたかも引き続きデータがユーザーの独占管理下にあるかのようなUIを提示するのは、もはや計画的な犯行といっても過言ではない。なぜなら、仮に利用規約において、ユーザーがアップロードされたデータに対する一部の権利を事実上引き渡すということに合意していたとしても、特にリテラシーのないユーザーはそもそも利用規約など読まない[^0]。また、実質的に削除および変更の権利が全世界に奪われることになると知れば、そのWebアプリケーションやプラットフォームを利用することを躊躇う人々が現れ始めるのは、少なくともこれまでの人類の利己的さを考えれば自明の理であり、ビジネスとしてWebアプリケーションをやっていくにあたってユーザー数というのは土台であるから、多少欺いてでも最初に人々をユーザーとして取り込もうという魂胆が働くのは理解できる。

しかし、それでもWeb2.0アプリケーションは人々を欺くべきではなかった。あの時代は、人々がまだインターネットを知らなかった。そしてより悪いことに、今や人々はインターネットを誤解している。「無断転載禁止」「保存禁止」「削除要請」⸺などと、自分がボトルを放った海に向かって叫んでいる[^1]。この滑稽な状況は、Web2.0アプリケーションが人々に取り入るために、インターネット上にあたかもユーザーが家や庭を持っているかのように錯覚させたことによって引き起こされたのである。各々の承認欲求などは、それを加速させた燃料にすぎない。

アップロードされるのが、人々がまだ扱い方を掴みかねていた電子情報であるという点も、この錯覚に寄与した。それとはつまり、電子情報は完全に同じコピーを複製できるという点である。物理情報（物体）は少なくとも現在までの人類の技術水準では分子レベルで複製することなどできないので、ユーザーが物体の扱いとの類推を電子情報にも当てはめてしまったのも無理はない。しかし、ここにおいてもボトルメッセージの比喩は成り立つ⸺アップロードとは、より正確には、単に自分でメッセージを複製して海に流すようなものだ。オリジナルコピーが少なくとも自分の手元にあるのだから、同じデータの載った全てのコピーは完全に自分の権限下にあるのだ、などという考えは、全人類が今すぐ捨てるべき虚妄である[^2]。その事実を、「削除」や「編集」ボタンが見えなくさせているのである。

インターネット上のデータの「削除」「編集」は、最も正確な表現では「非表示」「フォーク」とするのが適切である。仮に「削除」「編集」によって内部で実際にデータの破壊的変更が起こっていたとしても、それをユーザーが知る術がない以上、そう信じ込ませておくのは危険すぎる。理由の根本はすでに述べたが、そこから導かれる事態として、ローリテラシーユーザーが考えなしにセンシティブ[^3]な情報をアップロードしてしまい、その結果本人が不幸になる、などは容易に考えられる一例である。インターネット上にアップロードしたデータを完全に削除しきることは、少なくともユーザーの視点からはできないし、公開するならばWebアプリケーション提供者の視点からすらもできない、ということをWebアプリケーションはUI上で赤く大きく警告しておくべきだった。

---

要するに、人類にインターネットは早過ぎた、というありきたりなまとめ方になる。ここまで貶してきたが、Web2.0アプリケーションの設計者にとっても早過ぎたのだろうし、ハンロンの剃刀が正しいケースもあるだろう。とはいえそのようなアプリケーションから「削除」「編集」ボタンを無くすという選択は誰も採ろうとしないだろうから、もはや引き返せないが、Web3時代のアプリケーションでは、ブロックチェーンやパーマウェブのようなアイデアに代表されるとおり、少なくとも情報の不変性は保証されたデザインになっていることから、順当に反省できているとは言える。

現実的な問題はWeb2.0アプリケーションを使うに留まっている人々の誤解をどう解くかであるが、これについてはまだ考えがまとまっていないのでそのうち書く。

[^0]: 残念なことにそのようなユーザーが大部分であるのがWeb2.0時代のアプリケーションである。
[^1]: 断っておくが、このようなことを言う人々すべてにリテラシーがないと言いたいわけではないし、リテラシーがない人々自身に問題の原因があると言いたいわけでもない。この記事はあくまで、論理削除うんぬん以前に、データをアップロードしたりダウンロードしたり、あるいは画面に表示したりする時でさえ、毎回データの複製が発生している、ということすら知らないような本当の電子機器初心者に対して、ナイーブな「削除」や「編集」という表現の操作を実行させてしまうWebアプリケーションのことを問題視している。データの被りうるあらゆる扱いの可能性を理解した上でアップロードするならば、それはその人の自己責任なのでここでは問題としない。もちろん、さらにその上でこのようなことを言う行為は、この記事で取り上げたような問題を風刺したパフォーマンスアートか、もしくは単なるウケ狙いと看做されることを免れない。
[^2]: 著作権やそれに類する法的権限によってそれが保障されていたとしても、である。法律はあくまで建前にすぎない。殺人が禁止されていようと殺人は可能であり、不可能であると信じ込ませて警戒しないようにさせるのは教育として正しくない。
[^3]: エロいという意味ではなく、パスワードなどの機密情報や、住所氏名などの個人情報、デジタルタトゥーとなりうるような自らの行為の証拠、などのこと。

Web2.0の功罪の罪の部分

筆者の音響機器遍歴は以下のとおり偏っているので大部分の人にはあまり参考にならないかもしれないが、似たような遍歴の希少な読者のために書く。

凡例: [HP]ヘッドフォン、[EP]イヤフォン、[SP]スピーカー、[IF]オーディオインターフェース

- （2009年以前（小学生時代）は何かしらの安価ヘッドフォン（3000円前後）を使っていたはずだが憶えていない）
- [HP] [beyerdynamic DT 250](https://beyerdynamic.co.jp/product/dt-250/): 2010年ごろ購入、DT 1990 PROに乗り換えるまで愛用。楽器屋でMDR-CD900STなどの同価格帯のモニター機と聴き比べて一瞬でベイヤー信者になりこっちにした思い出。
- [SP] Logicool Z120BW: 2013年購入。なんとまだ現役。もちろん制作用途ではなく動画視聴など。ちゃんとしたスピーカーは適切に設置するためのコストが嵩むので手が出ない。
- [EP] Fostex KOTORI: 2013年ごろ購入、数年後紛失。通学中にiPhoneで使用していた。おしゃれさ優先。
- [EP] Etymotic Research hf5: 2015年1月購入、2017年ごろ破損。主にiPhoneで使用。装着すると無音になるし音質も素晴らしく、コスパ最高だったので生産終了しているのが残念でならない。これでエティモのことを好きになり、今でもER4SRとか普通に欲しいが、現在の生活スタイルでは持て余す予感。
- [IF] Roland Rubix22: 2017年8月購入。音楽制作側に興味を持ち始めたのがこの頃で、MIDIキーボードなども購入した。それまでは何経由で音を鳴らしていたかよく憶えていないので、おそらくPC直挿し（！！）。
- [HP] [SONY MDR-Z1000](https://www.sony.jp/headphone/products/MDR-Z1000/): 2017年8月購入。しばらく使ったが解像感が物足りずDT 250に戻り、こちらは売却。
- [HP] [beyerdynamic DT 1990 PRO](https://beyerdynamic.co.jp/product/dt-1990-pro/): 2018年2月購入、2025年5月破損。奮発して上位機種に手を出してみたが大正解だった。MK IIも欲しい。
- [HP] nura nuraphone: 2019年ごろ購入。音はそれなり。装着感があまり良くなく、ほぼ使っていない。
- [EP] nura nuraloop: 2020年ごろ購入。音はそれなり。ノイキャンは結構優秀（hf5の耳栓性能には遠く及ばない）。外音取り込み機能もあるので出先では今はこれ。
- （2020年ごろDJを始めた）
- [IF] MOTU M2: 2021年11月購入。音楽体験が上次元にアセンションしてしまうので万人におすすめしたい。
- [EP] final E500: 2022年11月購入。DLsite音声作品用途で現役。音楽には使えない。
- （2023年ごろ本格的にDTMを始めた）
- [HP] [OLLO Audio S5X 1.1](https://olloaudio.com/products/s5x-1-1-reference-headphones): 2025年6月購入。現在のメイン機。
- ここに書いたもの以外にもこまごまと買ってはいるが、通話用だったり骨伝導だったりと色物なので除外した。

長らく使っていたDT 1990 PROを床に落下させて左ドライバーユニットを壊してしまったので、この機会に最近話題になっていたOLLO AudioのS5Xを買ってみた次第。

---

結果、以下の点以外は全部**S5Xの方が良い**と感じた。

- ヘッドバンドからのイヤーユニットの引き出し具合を固定する機構がなく、装着するたびにズレを調整しなければならず不便。
- それまで使ってたDT 1990 PROと比べると長時間の装着では耳が少し痛くなってくる（頭骨や耳介の形、髪型、眼鏡やピアスの有無など、装着感は人それぞれ異なる要素の相乗効果なので、この評価は決して誰も参考にすべきでない）。
- 高域の表現力はDT 1990 PROにあと一歩及ばない。
- 公称でDT 1990 PROは40kHzまで出るのに対してS5Xは22kHz。人間の可聴域は20kHzまでなのだから気にするべきでないという人もいるが、そこで音が出ている限りは差音が発生し可聴域に何かしらの影響はあるはず。

やはり中高域の生々しさはDT 1990 PROの方が精細に感じられた。「Beyer treble」としてよく知られているとおり、DT 1990 PROにも典型的なトレブルピークがあり、これが苦手な人は苦手らしいが、筆者は逆にそこが耳に心地よく感じるタイプであった。ただしこれはあくまでリスニング的な評価（中高域表現力があまりに高すぎて、一般的ではない再生環境に耳が慣れてしまう）なので、リファレンスとしてはS5Xの方が正解に近いと思う。もちろんS5Xも単体で見れば非常に精細である。

冒頭の遍歴を見て大体わかるかもしれないが、筆者はむしろSONYのヘッドフォンような、高域がはっきりせず低域ボッフボフの音が嫌いである。聴いていて生きた心地がしないくらいには。リファレンスやモニターと謳っているミドルハイエンド以上の製品ですらそうなので、開発陣は本当にあれでいいと思っているのだろうし、実際に業務で使用している人もいるはずなので、つまるところ実際にはある程度のラインをクリアすれば音響特性に絶対的な優劣などなく、人それぞれ特性に偏りのある色眼鏡（耳）で物を見ているからそれを補正するような特性の逆色眼鏡（ヘッドフォン）を選べばいいというだけの話なのだろう。

S5Xは立体音響のモニタリングに最適とされているようで、確かに空間表現はDT 1990 PROより優っているように感じられる。とはいえDT 1990 PROも悪いわけでは決してなく、方向性の異なる空気感がある。表現が難しいが、S5Xの空間は前後に開けていて、部屋にいる自分をさらに別の自分がサードパーソンで見下ろしているかのような冷静な空気感であり、一方DT 1990 PROの空間は上下に開けていて、屋外にいながらファーストパーソンで目の前の物を見ているかのような鮮明な空気感である。単に個々の音の解像感、分離感という意味ではどちらも良い勝負だが、全体的にはS5Xの方が全方向への均等な広がりを俯瞰しているように感じられる分、S5Xの方が上と言ってもいいかもしれない。筆者は今のところ特に立体音響を意識した制作はせず普通のステレオのみだが、それでも音の聴き分けにおいて恩恵を感じられる。

装着感に関して今のところベイヤーの右に出るものはいないと感じる。ローエンドモデルのDT 250ですらそうだった。筆者の頭骨の形状に対して力のかかり方がちょうどよく、強すぎず弱すぎずの絶妙な力加減で、全く疲れずに作業を続けられる。ベイヤーのそれを知らなければS5Xも最高と言えたかもしれないが。この辺は本当に装着者との相性であり、たまたま筆者の頭の形状がbeyerdynamic社内でモデルとしている頭のそれに近いのだろう。

総じて、少なくとも今年買ってよかったものランキングの上位には躍り出そうな気配である。

---

余談だが、包括的にヘッドフォンや再生環境のことを知りたいなら[DIY-AUDIO-HEAVEN](https://diyaudioheaven.wordpress.com)を見るとよい。大体何でも載ってる。

OLLO Audio S5Xとbeyerdynamic DT 1990 PROの比較感想

In recent decades, a number of package ecosystems have been built around the concept of [Semantic Versioning](https://semver.org) (SemVer hereafter) in the wild. To me, this seems absurd from the perspective of reliable systems engineering.

## Problem: You Have to Trust Your Ability to Version

To get started in SemVer, the first problem you have to deal with is to decide which number to bump for your releases. There will be almost no reduction in the cognitive load required to make these decisions, even after dozens of releases you published. You sometimes might include breaking changes into a minor release by mistake, or even if you believe that the change is definitely nonbreaking before releasing, eventually your users might experience the change as breaking.

The more disappointing fact is that there's no general algorithm to prove a version tag is correct for a release—it's simply impossible. The correctness varies depending on the situation of the software. For example, when you noticed a seemingly undesirable behavior in your library, do you think the release fixing the behavior is patch level, or major level? You would think it's a patch as usual, but what if you know one of downstream softwares has code that depends on that behavior? Or what if you know almost all of downstream do so? Or what if *actually* they do so while you can't even know? Library authors have to consider such situations all along upon their releases. Of course it's correct to release as “a patch because it's undesirable on its own”, and still other options are also downright correct like “a patch because the dependents are ignorably few” and “a major because the dependents are considerably numerous”. But I'd say not so many developers could decide like that confidently and bravely.

Under SemVer, no matter how confident a developer believes their change is really great, they have to be overcareful when releasing. SemVer forces library authors to suffer from being seized with fear that they might break uncountable builds of softwares anywhere in the world.

### Pseudosolution: Do Not Trust Your Ability to Version

Bump the major version only. There's no one who can recognize every single usage of their library, thus it's always *better* choice to go for releasing as a major.

As you notice, SemVer doesn't make sense anymore if you always release as a major.

## Problem: You Have to Trust Every Developer's Ability to Version

Once you've got a misversioned library in the dependency graph of your software, you shall confront unhelpful build errors while autoupdating your dependencies, or users might experience a bug after a release. The idea of “compatibility between versions” is all too often a fantasy.

Systems built on top of SemVer only works as long as such vulnerable relationships of interhuman trust is working. One could say the idea of reusing libraries made by someone is itself already based on some kind of trust, but wait, the greatness of a software and the ability to develop such a software are totally different thing than the ability to version. Library updates are always likely to cause broken builds regardless of how much the library is great.

### Pseudosolution: Don't Trust Every Developer's Ability to Version

Pin each of your dependencies to a specific version.

Again, SemVer will become useless then.

## The Worst Abusage Ever: Deduplication

Unfortunately, most package managers not only deduplicate dependencies as per SemVer by default, but even don't support disabling it! While deduplication must be carefully done by involved developers preferably manually ensuring the version combination really works well in that specific situation, current systems automatically deduplicate as much as possible as per the version range requirements in the dependency graph. The infamous “[dependency hell](https://en.wikipedia.org/wiki/Dependency_hell)” all comes out of this process, but this is how it is done.

I'd agree with [this topic in the users forum of Rust](https://users.rust-lang.org/t/psa-please-specify-precise-dependency-versions-in-cargo-toml/71277), especially the following sentence in [this comment](https://users.rust-lang.org/t/psa-please-specify-precise-dependency-versions-in-cargo-toml/71277/23):

> And so I say: if you’re not deliberately testing on minimal versions, all approaches other than exact version dependencies (like `serde = "=1.0.130"`) are Wrong™.

Almost every library would be developed by a single developer (at least initially), and with such a low development resource it's too hard to ensure their library works with every possible combination of versions of the dependencies. **No two versions of a library should be considered compatible unless tested explicitly**. I believe this is supposed to be the baseline concept of software development. 

Sounds radical? Yes, radically installing multiple copies of the same library might cause special-case problems in turn, for instance:

- **Mutable statics**. Libraries that internally use static area as a global mutable state might not work correctly. Mutating statically allocated memory must be a deprecated idea for any future software development. Instead, we should be passing states all around as arguments like done in functional-styled programming.
- **Type system**. In major implementations of nominal type systems, types with the same name but from different versions are actually treated as completely different ones, thus cannot be used interchangeably. This is just a false problem where language design tightly couples the identity of types with *where it was defined*. Instead, language designers should find a way to identify types by *what purpose it was defined for*.

These points should be thought of as temporary thing in the migration period to the next technological innovation that eliminates any form of dependency hell.

## Core Purpose of SemVer

Reading down to this section, you already understand that mechanically relying on systems based on SemVer (like package managers) is inherently problematic. Then what's the point of SemVer?

SemVer is just a convention. Nothing more, nothing less. Sometimes wrong versioning is made, because the versioner is a human. It's no surprise that we (humans!) make mistakes, but unfortunately we've been still making the biggest mistakes these days: trying to build reliable systems on top of a mere convention.

The heart of SemVer is literally “semantic” versioning; this means that SemVer is purely for humans, not for machines. One of the dark side of SemVer is that it defines the machine readable form of version tags, and looks promising about compatibility between versions of softwares, while actually it doesn't guarantee the semantics at all. These version tags are just given as a hint for users by the developer, and it's all up to users to trust this hint. Pessimists like me would think the hint is almost meaningless, but quite a few people wouldn't think so, and probably that's why SemVer gained this popularity.

## Real Solution: Stop Using “Packages”

Those pseudosolutions are just workarounds under the reign of packages. If possible, humanity should progress to the direction not relying on “packages”. It might sound ridiculous, but I mean somewhat more specific: just **to stop thinking about software development ecosystems in the unit of packages**. At least developers of a new programming language should reconsider whether to involve the concept of package into their automation systems.

Fundamentally, I think it's pointless to release softwares at the granularity of package. It's rather reasonable to give a version number for each public API (exported symbol) and release separately.

There're multiple issues in releasing in the unit of packages. For example:

- When a major version of a package is released with some bugfixes, users who are not using the part of the APIs the breaking change was made on will receive an impact that they can't get a very simple bugfix to the part they're using without investigating and validating the whole released contents. Not all developers have resource to provide backports.
- Package authors have to manage a complex schedule to determine the order in which they merge changes, to reduce the impact described above as much as possible.
- The more a package grows large, the more the difficulty of versioning gets increased. A large package means a large cognitive load to understand the relationships between the public APIs.

Per API versioning addresses these cases, although whether we should use SemVer again or not anymore for tagging versions would be another debatable topic.

---

Further reading:

- There's already a study called [version polymorphism](https://prg.is.titech.ac.jp/papers/pdf/thesis-m/2020-tanabe.pdf) that proposes a core calculus enriched with version numbers and statically verify compatibility of programs.
- The [Unison](https://www.unison-lang.org) programming language implements a thrilling idea: [the global content-addressed syntax forest library called “codebase”](https://www.unison-lang.org/docs/the-big-idea/). This consequently deduplicates code instead of packages, in a sound manner.

Semantic Versioning Is Abused

何かがスケールすると発生し始める問題の一つに、「FLOSSの有名税」とでも言うべきものがあると筆者は考えている。

以前、[expressjs/express](https://github.com/expressjs/express)がスパムPR爆撃を受けていた件が[話題](https://socket.dev/blog/express-js-spam-prs-commoditization-of-open-source)になっていた。ざっくり言うと、GitHubのPRの作り方を説明するチュートリアルをYouTubeに出していたIT教育系動画投稿者がいて[^0]、それを観た大量のバカが実際にスパムPRを作成しまくったという事件だ。

expressjs/expressの件はさすがに極端な例だけど、そこまでいかなくとも、そのソフトウェアが有名になるにつれて、作成される（スパムではない）Issueが多すぎてメンテナーが対処しきれなくなるという事態は往々にして発生する。これ自体は仕方のないことだし、メンテナーが疲弊するのも理解できるが、そのせいで自動クローズbotみたいな仕組みを導入し始めるのは、いくらメンテナンスが大変でもやってはいけないことだと思う。それは隠密的なメンテナンスの放棄に等しいし、Issueという仕組みの意義を破壊してしまう。問題があってIssueが作成されたのであれば、問題が解決していないのにIssueをクローズするのは、メンテナーの自己満足、欺瞞であり、臭いものに蓋をしているだけである。それをわかっていてやるのであればまだいいが、メンテナーは本当にその不評を被る覚悟があるのだろうか。

---

自動クローズbotの導入方法がGitHubの公式ドキュメントに[書かれている](https://docs.github.com/en/actions/managing-issues-and-pull-requests/closing-inactive-issues)ということも、なかなかに信じがたい。Issueのクローズ理由の一つに“stale”があるので、動きがないIssueをクローズするというのはGitHub的には正当なのかもしれない。

<img width="328" alt="Screenshot 2024-03-18 at 15 19 05" src="https://github.com/yuhr/blog.yuhr.org/assets/18474125/031d9a2e-018a-473b-8afe-d4ccb0984af2">

個人的には、Issueの分類やクローズ理由としての“stale”というのは、ソフトウェアの他の部分で機能追加したりバグ修正したりすることによって、そのIssueに挙げられた問題が副作用的に解決していた場合を指しているのかと思っていたが、その認識がおかしいのかもしれない。というか、そもそも「解決していた」なら“resolved”扱いでいいのかもしれない。そうなってくると、筆者の立場としては、クローズ理由から“stale”を削除するべきという話になる。

---

「ソフトウェアに問題がある」という旨のIssueを「Issue作成日時が古いから」という理由でクローズしていいケースというのは存在しない。表立ってメンテナンスを放棄していたとしても、である。オープンなIssueは「治っていない問題」の一覧であり、いくら古くても問題が残っている限りIssueを残しておかなければならない。それがメンテナンス放棄ということの意味である。

手動で作成された、ちゃんと意味のあるIssueを自動で[^1]クローズしていいケースというのも存在しない。Issue消化に関する自動化として最大限考えうるのは、「重複するかもしれない既存のIssueをAIでリストアップしてチェックボックスを出しておき、メンテナーによってチェックされたらそのIssueのduplicateとしてクローズする」とか、「質の低い（再現手順がないなど）可能性のあるIssueにそういうタグをつける」などといった、あくまで「判断をメンテナーに任せる」自動化だけだろう。

あまりGitHubでIssueを漁ることがない人には、何を当たり前のことをと思われるかもしれないが、実際にそうやってクローズされているIssueがGitHubにはたくさんある。特に大きいプロジェクトほどそのような傾向が認められる。

---

思うに、自動クローズなどをやり始めてしまうのは、Issueをカスタマーサポートのようなものだと考えているメンテナーたちだろう[^2]。カスタマーサポートというものは、その成り立ちからして、問題ベースではなくカスタマーからのアクションベースで動いているものだ。苦情がなければ動かなくていいという行政的な考えと、自動クローズとの間には親和性がある。しかしFLOSSにおいては、ユーザーとメンテナーを立場上分離するような考え方や、それら人間を中心とする考え方ではなく、ソフトウェアそれ自体を中心とする考え方で開発を進めるべきだし、それに基づけば、メンテナーの労力の都合でソフトウェアの問題がなかったことにされるというのは、発想すらあり得ないような事態だ。

正しい方法で大量のIssueに対処するなら、各メンテナーの稼働時間を増やすか、メンテナーの数を増やすしかないのだが、それはそれでまた別の問題が発生するおそれが出てくるので、難しい。とにかく、何かがスケールすればするほどその世界は崩壊に向かっていく、というのが自然の摂理なのだろう。政治の直面する不可能そのものである。結局のところこれは倫理や良心の問題であって、考え方が異なる人たちがいる以上、無くなることはないのかもしれない。

---

[^0]: 一応、少なくともコメントでは「実際にはテスト用のPRを送らないように」という旨の[免責文](https://www.youtube.com/watch?v=Ez8F0nW6S-w&lc=UgyjLIPaIm6z029WBhp4AaABAg)が出されてはいる。筆者は動画本体は観ていないので確かなことは言えないが、動画の中にも同じ旨の注意はあったらしい。
[^1]: 「自動で」というのは「人間の判断なく」という意味。関連付けられたPRのマージに従ってクローズされるケースは、人間の判断によるので含まない。
[^2]: メンテナーにそう思わせてしまうGitHubのUIにもいささか問題があるかもしれないが、かといってどうデザインすればいいのかという案は筆者には湧いてこない。おそらく、そもそもGitHubのような場所で中央集権的にソフトウェアを管理するのをやめる必要がある。

FLOSSのIssue消化戦略

というのは嘘で、この記事はむしろ私が熱心にツイートしていた時代にTwitterの何が良かったのかを思い返して述べるものであって、何が悪かったのかについてはすでに巷で無限に議論があると思うし、そのほとんどに私は同意するだろうので、ここではあまり言及しないでおく。

「Twitter辞めて本当に良かった⋯⋯」は、いつから始まったのかはわからないがそういう定型文のミームであり、Twitter上でそう呟くからこそ面白いのであって、今回は単に私がそれを懐かしんでいるから表題にしたに過ぎず、特に意味はない。

---

まずそもそもなぜツイートしなくなったかというと、それ以外のことで忙しいからである。私が移行先として使っているNostrも、今はほぼポストしておらず、見てもいない。使っているかどうかでいうと、どちらかと言えば今のところTwitterの方が使っていると言える。ただ、本拠地はNostrであるという意識は捨ててはいない。今後も何か短文投稿することがあればNostrに流す。Nostrの何が良いかという話は別で記事にするかもしれない。

では何に勤しんでいるかというと、色々である。以前から作ろうと思っていたソフトウェア開発にいよいよ本腰を入れ始めたり、DJ趣味が飛び火してDTMに手を出すなどした[^0]。主にこの2点が今の私の生活の大半を占めている。あとはゲーム。

---

ここからが本題。ツイートしなくなって感じたのは、何かについて本格的に思考することが明らかに減った、ということだ。これは私の狙い通り（前述したような趣味のために手を動かす時間を確保したかった）ではあるので、後悔してはいないのだが、ツイートするという行為が私にとっていかに思考を触発するものであったかということに気付かされ、少し不思議に感じた。

これはあくまで「私にとっては」という注釈付きなのだが[^1]、連ツイすることで「[**意識の流れ**](https://ja.wikipedia.org/wiki/意識の流れ)」をそのままに実現していたようなものかもしれない。しかし、単にそれを実現するだけなら、プライベートなメモ帳などに適当に一つ一つ書きつければ済む話である。しかし、どうにもそれはやってみたところで（ツイートのようには）続かないだろうということは予感できる。ではそれはなぜか、と考えたときに思い当たるのは「張り合い」くらいなものだろう。意識の流れをパブリックな場で垂れ流すことは、様々な危険が伴うことではあるが[^2]、むしろそのような危険があったからこそ筆が進んでいた、という側面があったことは確かだ。少なくともある程度は、後から（あるいは外から）読み返して意味が通るような文を書かなければいけないし、社会不適合的な考えをある程度は社会適合的な表現でラップしなければならないし、考えは一貫していなくてもいいけれどもその変化がわかるように書いておかなければならない[^3]。これは読みやすさのためだとか、記録のためだとか*ではなく*[^4]、そういう神経を働かせることで辿り着ける「**思考の境地**」[^5]というのがあったのである。脳トレと言い換えてもいい。つまり、プライベートなメモ帳に書いていただけでは考えもしなかったような帰結に思い至ることができる、ということだ。仕組みはわからないが、シンプルに思考継続力や直観力にブーストが掛かるのである。私は以前から、よく言われる常識に反して「Twitterは議論に向いて*いる*」と感じていたが、その実態はそういうことだったのかもしれない。

もちろん、パブリックに思考を垂れ流すことで外部からのアイデアが飛んでくることもあり、それによって初めて到達できる思考の境地もある。しかし、その恩恵を受けるためにはまず自分の思考力が持続している必要がある。ツイートによって思考することは、私にとってその前提を確保するために必要なことだったのである。

---

上述したような点以外で、ツイートすることによる利点は特に感じない[^6]。というか、私にとってその利点は同時に欠点でもある。仮に私が執筆作業を本懐とする人間であれば、*何かについての*思考はそれについての執筆を捗らせるが、残念ながら今の私はそのような意欲をあまり持っていない（まったく興味がないわけではないが）。Nostrでもほぼポストしていないのはそのためである。最近は短文投稿SNSの代わりにYouTubeを見ていることが多い。今考えると、私が数年前まで盛んにTwitterをやっていたのは、おそらく今やっていることの「準備期間」だったからというような気がしている。

「良いものができる」と信じることができているときは、とても捗る。逆に言うとそのときぐらいしか生きている実感がない。

---

[^0]: 楽曲制作者としての名義をこちらに繋げるつもりはない。
[^1]: とはいえ実際、一定数の人間には同じことが当てはまるのではないかと思う。
[^2]: その危険が何かということにはここでは深く触れないが、ざっくり言うと、プライベートな場では問題にならないような考えが一瞬でグローバルに配信されることからくる様々な問題のこと。
[^3]: もちろんこれは誰に課されたわけでもなく、実際に徹底できていたわけでもない、単なる私の内的自然である。
[^4]: むしろ私はある時期から、私の短文投稿を私の思考の記録として捉えることは、他者からはもちろんのこと自分から見ても、長期的に考えると非合理的であるという考えを抱くようになった。それらの記録からでは、いくら注意深く書いていたとしても、当時の自分の現状認識と意識の流れにはどうやっても辿り着くことができないからである。ここら辺の捉え方は人によると思う。思考のうんこである短文投稿よりはむしろ、当時観ていたアニメのワンシーンや読んでいた本の引用などの方が私にとっては記録としての価値がある。
[^5]: これは一次元的な価値判断に基づく概念ではなく、マインドマップ的な平坦な空間における、単なる一部の領域をイメージしている。そのような領域にある帰結が、必ずしもそれ以外の領域にある帰結よりも優れていると言いたいわけではない。到達できる領域が広がるという話である。
[^6]: 強いて言うなら「人間関係をやれること」くらいだろう。私の欲動は基本的に自分一人で閉じているので、自分を含む人間関係には根本的には意義を感じない。

Twitter辞めて本当に良かった⋯⋯

Every time I hear people saying “hard” or “soft” when talking about indentation style, I feel it's the other way around, because what people call the “soft” way is to bake the visual width of indentation into the file, which can be thought as a typical instance of hardcoding, like in analogy with “hard wraps”.

Actually, they're saying “hard” or “soft” about “tabs”, not about “indentation”, so I understand it's okay to say baking tabs into the file as “hard tabs”. But wait...

Strictly speaking, what exactly we want to do is to *perform indentation*, not to *insert tabs or spaces* specifically. Tabs or spaces are just two naïve implementations of indentation. It sounds unnatural to me to use the words like “hard *tabs*” and “soft *tabs*” when talking about indentation. I don't know who has started such wording, but this is the time to reconsider what those words mean.

Instead I propose this wording: “**soft indentation**” and “**hard indentation**”. Just like the “soft wrapping” leaves where to insert line break to the renderer, “soft indentation” leaves how much width a single level of indentation takes to the renderer. On the other hand, “hard indentation” hardcodes it by encoding the width to the number of spaces. Quite natural, isn't it?

TL;DR, the correspondence is:

- **Soft indentation = Hard tabs**
- **Hard indentation = Soft tabs**

So, remember, **soft tabs are hard**.

Soft Tabs Are Hard

今週末はずっと[崩壊スターレイル](https://hsr.hoyoverse.com/ja-jp/home)をプレイしていた。最初はスマホでやっていたのだが、原神と同じくこれは大画面で観たいという感じになりPCにインストールした。20GBくらい必要だった。

ﾍﾟﾗﾁｬﾝｶﾜｲｲﾔｯﾀｰ

![ペラさんの肖像](https://user-images.githubusercontent.com/18474125/235380198-c3b0536b-09dc-4049-9256-88f3dd37887e.png)


---

主人公のキャラクター性がかなり面白い。主人公は記憶喪失で、経緯や出自が不明である[^1]。なにやら重要そうな「星核」というオブジェクトが物語冒頭で主人公の体内に埋め込まれるが、それがつまるところ何なのかもわからない。とはいえ、訳もわからず異世界に召喚され、これから星々を旅する冒険が始まる、といったような現状のことを「SF映画の世界にでも召喚されたの？」と形容するなど、普通に地球人間として生まれ育ったかのような思考様式を備えていることは看て取れる。あまり表情豊かではなく、常に超然としていながらも、行動は奇特で、喋り方は妙に俗っぽい。筆者はこのようなキャラクターに弱いのだと思う。ミステリアスな風貌と飄々とした言動。

メッセージという機能があって、ゲーム内の他のキャラクターと主人公との会話が読めるのだが、これをすらすらと読めている自分に驚いた。他のゲーム（ブルアカやNIKKEなど）の類似する機能はだいたい読むのが億劫になってしまって放置してしまいがちなのだが、このゲームのメッセージは、そもそも絶対量が少なく現実的な数しか届かないということもあるが、おそらくそれを通して主人公の性格が窺い知れるということが、メッセージのやりとりを読み進める主な動機になっている気がする。仮にプレイヤー（筆者のことだが）が自己投影できてしまっていたら、単純に**自分自身が**会話相手のキャラクターに興味を持てるかどうかの問題になってしまうだろう。

実際の主人公の言動やゲーム冒頭の雰囲気は[マシーナリーとも子の記事](https://news.denfaminicogamer.jp/kikakuthetower/230426a)を見てほしい。

---

全体的なUXはよく考えられている。戦闘部分はシンボルエンカウント方式のターン制バトルで、コマンド数が絞られており[^2]考えることが少なくて済むのと、必殺技だけ任意のタイミングで割り込み発動できるため、若干のアクション性があり退屈しない。そして特筆すべきは、**戦闘後のリザルト画面というものが存在しない**ことだ。場転がテキパキと進むおかげで、この手のゲームシステムでありがちな「だれている」感がない。

姫子さんとヘルタさんの追加攻撃が強すぎる。追加攻撃に対しても追加攻撃が発生したりするので、ペラさんの秘技などで開幕攻撃→追加攻撃→追加攻撃みたいな感じで一切操作せずに戦闘が終了することがある。模擬宇宙の中では「愉悦」の祝福によってさらに追加攻撃が強化され、自動で敵が溶けていく。追加攻撃最高！ 一番好きな攻撃です！

---

操作体系はスマホ向けゲームをとりあえず移植しましたといった趣で、原神ほど洗練されておらず、UI上をカーソル移動しなきゃいけないことが多くて不便である。筆者はコントローラーでプレイしているが、一番の不満はキーコンフィグ機能の貧弱さで、自由に設定できるわけではなく、例えば「OK」と「キャンセル」ボタンは○か×しか割り当てられず、「通常攻撃」と「秘技」ボタンは□か△しか割り当てられない。あっても意味がない機能である。

また、このゲームにジャンプする機能はない。もちろんゲーム上まったく必要ではないからなのだが、こんなに精巧な3Dのマップとキャラクターがあってジャンプできないのはもどかしい。原神に飼い慣らされている。

[^1]: 物語の導入部で主人公を記憶喪失にしたり殺したりするのは、観者が新しい物語に没入しやすくするための典型的な工夫である。
[^2]: できることは「通常攻撃」「戦闘スキル」「必殺技」の三つしかない。

崩壊スターレイルやってる

このたびブログを立ち上げることにした。筆者のプロフィール表示等はまだ実装していないので、誰なのか知りたければとりあえず[GitHubを見てほしい](https://github.com/yuhr)。また、ここでは今後常体でいこうと思う。他の媒体（Zennなど）で書くときに比べて、あまり読みやすさなどに気を払いすぎて手が止まってしまうことがないよう、つらつらと書き殴っていきたい。

---

あえて今ブログ立ち上げに至ったのは、何の気なしにTwitterを眺めていたら、それとなく機運の高まりを感じたからだ。

<blockquote class="twitter-tweet">はてなブログに投稿しました <a href="https://twitter.com/hashtag/%E3%81%AF%E3%81%A6%E3%81%AA%E3%83%96%E3%83%AD%E3%82%B0?src=hash&amp;ref_src=twsrc%5Etfw">#はてなブログ</a> 言葉だけが最後に残る - 鷲はいまどこを飛ぶか<a href="https://t.co/tpUA1kn48E">https://t.co/tpUA1kn48E</a>&mdash; washoe2.2 (@washoe2020) <a href="https://twitter.com/washoe2020/status/1650144629017427969?ref_src=twsrc%5Etfw">April 23, 2023</a></blockquote>

<blockquote class="twitter-tweet">とても問題意識に共感する（実際自分も「意識的に記述しておかねば各時点の自分が何を考えていたのかは簡単に揮発してしまう」という問題意識から去年自分用のWebサイト↓を立てたので： 緒言 - gfnweb <a href="https://t.co/7kX5X1wwIw">https://t.co/7kX5X1wwIw</a> ）&mdash; 画力・博士号・油田 (@bd_gfngfn) <a href="https://twitter.com/bd_gfngfn/status/1650147533388419072?ref_src=twsrc%5Etfw">April 23, 2023</a></blockquote>

それぞれのツイートからリンクされている記事をここからもリンクしておく。

- [言葉だけが最後に残る - 鷲はいまどこを飛ぶか](https://washibane.hatenablog.com/entry/2023/04/23/232820)
- [緒言 - gfnweb](https://gfngfn.github.io/ja/posts/2022-05-09-preliminary-remarks/)

---

これらの記事を読んだことは行動のトリガーにすぎず、もともと将来的には何かしらのブログのような媒体を利用したいとは思っていた。執筆媒体という括りでいうと、以前はQiitaを利用していたが、最近では[Zennを利用している](https://zenn.dev/yuhr)。少なくとも今までは、ブログよりはこういった単発記事プラットフォームの方が性に合っていたということなのだろう。しかし、そこでも特に最近はエッセイ記事を書くことが多くなり、これもうさっさとブログこさえた方がいいのでは、と漠然と思いつつ特に行動してはいないという状態だった。

はてなブログにもその他の媒体にも、最後まで食指が動かず、なぜかというとおそらく三日坊主になるのを恐れたのだと思う。これらのBlog as a Serviceとも言うべきマネージドな媒体は、サイトテーマなどを活用して自分好みのブログを作れる感を醸し出しているわりには、とにかく何かしようと思えば自由を制限され、細かい部分を弄れないという事態に直面する経験が繰り返されることで次第に興が削がれていき、どうせその媒体を静かに見捨てることになるのだろう、という先入観がある（これはプロダクトが悪いのではなく単に筆者の性質とのミスマッチの話）。実際、いつだったか、立ち上げて設定を弄くり回しただけでそのまま放置したはてなブログがある。

---

GitHub IssuesをヘッドレスCMSとして使って簡単にブログを立ち上げられるようなソフトウェアがそういえばあったな、と思い出して適当にググってみたところ、r7kamuraさんのブログ記事『[GitHub Issuesでブログを書く](https://r7kamura.com/articles/2022-05-03-github-issues-as-blog)』を見つけた。当人作成の[gialog](https://github.com/r7kamura/gialog)というソフトウェアが紹介されていた。他にも[似たようなソリューション](https://zenn.dev/masaino/articles/aad220db388b5a)が世の中にはたくさん存在するらしかったのでいくつかリポジトリを見てみたりした。

そうしてわかったのは、gialogが最も素晴らしいということだった。 驚くべきことだが、**GitHub上でフォークするだけでブログが立ち上がる**のだ。本当に、文字通り、フォークするだけである。これ以上手順を減らすことはできない。GitHubをすでに日常的に利用しているユーザーが使うブログシステムとしては、間違いなく最高のエルゴノミクスを備えたシステムである。

そんなわけで、今筆者が立ち上げたこのブログは、gialogを以下のリポジトリにフォークして動かしている。

- <https://github.com/yuhr/blog.yuhr.org>

一応、独自ドメインで動かすためには少しソースコードに[変更](https://github.com/yuhr/blog.yuhr.org/compare/7a0199519be7d4790d667fa84872f277b64bdc1d..95a57e7c4aff82ac7ca6e3ad480f70293e902ca4)を加える必要はあった。また、これらの変更を加えた後、独自ドメインでアクセスするとキャッシュの関係でうまくCSSが当たっていないように見えたりもしたが、待つことで解決された。

まったく文句がない。魂がこういうものを求めていたことを実感する。

---

デモサイトの投稿例を見てみると、一つ面白いことに気づく。

- 投稿例: <https://r7kamura.github.io/gialog-example/articles/1>
- 該当するIssue: <https://github.com/r7kamura/gialog-example/issues/1>

Issueの最初の投稿だけでなく、そこに付けたコメントまで含めてコンテンツとしてデプロイされ、できあがったブログ記事の下部に追加表示されている。つまり、本題から逸れるような補足などを後から足すといった、ある意味Twitterのようなマイクロブログと従来の古典的ブログとの中間のような執筆スタイルが可能になる。これは[Zennのスクラップ機能](https://zenn.dev/zenn/articles/about-zenn-scraps)を彷彿とさせる、執筆媒体としては新しめのスタイルだと思う。てっきり、この手の（GitHub IssuesをCMSとして使う類の）ブログシステムは、Issueへのコメントは記事の間違いの指摘とかに使われるものと思っていた。

色々試してみよう。