distrobox が mac というか非 linux 環境で使えないので開発用コンテナをなぜか自前した
なんやかんやあり、久しぶりに macos をお勤めで使うことになった。私用では arch linux を使っているので単純に UNIX like 系統の os に慣れていないが故にとっつきづらいという事情がある。
巷では devcontainer が肩で風を切って歩いているが、devcontainer のファイルフォーマットを覚えたりするのがだるいというのがあるので自分しか使わない前提で開発用コンテナ管理用の簡単なツールを作って常用してみている。
distrobox のアイデアがめちゃくちゃ気に入ってるのでほぼ同じことをしてるだけではあるが、個人的に必要な開発用のツールのセットアップを済ませた状態の開発コンテナを生成するベースイメージをテンプレートとして、必要に応じて依存を追加してイメージのコミットすることで、開発環境をポータブルにする処理を bash で定義しただけの簡易的なもの。
ちなみに Asahi linux をさすがにお勤めPCに入れる勇気がないし、UTM が思ったよりもアレだったので mac でも linux を使うみたいな歪んだ欲望を現実化する、あるいは開発環境でホストを汚さないようにすることを目的とした場合はコンテナイメージによる独立性がよいかと思った。
欠点としてはいろいろ詰め込んでいるゆえに一つのイメージサイズがそこそこでかくてリソースをそれなりに食うということがある。
これに関しては distrobox を参考にホスト側のバイナリと設定をそのまま使うとかでもいいかなと思ったけど、そうすると共有リソースとなってしまので設定だけする感じのコンテナにすべきか？とかいろいろ考えているがそもそも個人用途であるわけだし、汎用的にする意味がないので特に気にしないことにした
distrobox でよくなった
開発環境構築戦争で devcontainer とか nix とか散々試してきたが、結局のところ
を使うことですべてが解決してしまった。
*env のようなユーザーではなくディレクトリを仮想環境とするのも嫌いじゃないけどホストマシンのOSに依存するし、nix のユーザー管理方法は好きだったのだけど複雑すぎるし履歴管理の都合上、富豪的という難点もあってなかなか正解を見つけることはできなかった。
virtualbox や vagrant のような VM も悪くないが、機能が多すぎるというのと開発環境の再現がちょっと面倒というのもある。
そうなるとコンテナを使った環境が選択肢として残るわけだけど devcontainer とか devpod が候補にあがるけどどちらも使い方を覚えるのがおっさんにはつらい。
そうした状況の中、distrobox を見つけて今のところ個人的には最適解となった。特にホストマシンの設定とシームレスである点が非常に心地いい。
開発用コンテナに入っているという意識をせず、ホストマシンを触っている感覚で個別の開発ができる体験が本当に良すぎる。
読む必要のないコードがいいコードの定義であるという考え方
Good code is rarely read を読んで結構同意した。
確かに内容を把握しなくては使えないようなコードは抽象化や一般化が足りてない指標になりうるだろうし、メンテコストもかかるということだ。
一番の理想として、コードの内容を読んだり理解していなければならない機会というのは原則的にはレビュー、改修とテストであるべきだろう。
利用する側としてはドキュメントなりテストケースなりで仕様が自然言語で表現できていれば具体的な実装を知る必要性は本来ない。
ということは、利用者側にとっていわゆる"リーダブル"であることはそれほど重要ではない。ただし、そんな現実ではそんな単純な話ではなく普通は複数人開発ともなると実装者と異なる人でもそのコードを理解しないといけない。
個人的にはテストコードで仕様やデータ構造の理解することを習慣としているのでアプリケーションコードの読みやすさについては、おそらく世間一般で言われるほどは気にしてない方だと思っているが、主観ではあるもののやはり読みやすいコードというのは存在するように思う。
ただし、読みやすいコードがいいコードであるかということを考え場合、読みやすいコードがいいコードであるという十分条件ではないように思う。
個人的にはいいコードとは
- 修正しやすい
- テストしやすい
- 一義的である
- 問題個所を調査しやすい
- 名前が適切である
くらいなものであったが、良し悪しを判断する観点として内容を把握しなくても使えるは確かに参考になる考え方かもしれない。
Nix やめて普通に Arch のパッケージマネージャ使うことにした
Nix はめちゃくちゃに便利なのだが、たまにパッケージの更新でやたらビルドに時間がかかったりコミュニティのごたごたがあったりで微妙なところがないでもなかった。
んで個人用途であればそもそも Arch でいいのではとなったので、bash で構成管理するモジュール作ってエントリポイントたたいたら必要なパッケージと各種設定ファイルのデプロイをするようにした。
AUR があれば素直に yay たたけばいいし、そうでなくともビルドステップを定義した単なる shellscript を書いてやればいいだけなのでこれはこれで煩雑さがなくて手軽。
プロジェクトごとの開発環境は asdf なり docker + dev-container になるかなあという感じになったけどNix を使うのがすっかり習慣化してしまって shell.nix 一枚置いておくお手軽さを手放すは少々名残惜しくはあった。
けど Nix 使う前にもともと docker 使ってたわけだしじきに慣れるだろう
最近不穏なNix界隈について
でXe氏が Nix コミュニティから距離を取ったとのことで(結構読んでて心が痛い)、経緯がいまいちわからなくて調べた。
いいまとめ
にことの経緯が要約されていた。
要点
- 権力構造がらみでNixコミュニティ自体のガバナンスがここ数年やばい状況だった
- 主要メンバーの Eelco Dolstra氏はかなり父権的な意思決定をしていた
- Dolstra氏からはこの危機的状況の解決を阻害するような振る舞いが見られた
- そのような横暴さに辟易するようなコミュニティメンバーも多数いて、氏に対するオープンレターも公開されている
- Dolstra氏はオープンレターに対する返答としてNixコミュニティの代替として彼の運営する会社のコミュニティを宣伝し始めた
なるほど、という感じ。 ちなみに Eelco Dolstra はNixOSの創始者。
オープンレター
オープンレターは結構分量があるので見出しと数段落だけ適当に目を通したくらいだけど、まあいろいろとヘイトを集めている様子がよくわかる。
個別具体的な事象に対する意見ということになるので、端的にまとめることが困難なんだけど同まとめに書いてあることを箇条書きにすると以下の感じ。
スポンサー問題
NixコミュニティはNixへのコントリビュートが許可されていないうえに、プロジェクトの性質上全く関連のないはずの軍事関係の企業がスポンサーとなっている。
これ、カンファレンスとかする際の協賛としてこの軍事関係の企業をNixコミュニティ公認として公表することになるので結構不穏だわね。
しかもこれについての議論はDolstra氏が率先する形で意図的に避けられているらしいっぽくて、不健全だなって感じ。
なんか粛清もあるらしい。こわい。
Meson互換性問題
Dolstra氏も賛同して進められていたMeson への移行について数年単位かけてコミュニティの努力のたまものとして着々とすすんでいたそうな。
ところがDolstra氏は突如として手のひらをひっくり返して Meson 移行を保留して5年くらい足止めしてるらしい。そこに正当な理由があるのかはよくわからないが、まとめにある引用から察するにマジで先述のスポンサーと利害関係ありまくりじゃねーかとしか思えない。(出典元参照のこと)
特に NDA を理由に意思決定の根拠について回答拒否すんの、結構深い闇を感じる。
Dolstra氏の反応
彼の会社である通称 DetSys のブログで彼の返答が公開されている。これは同まとめを読む前にXe氏のブログのリンクから、経緯がよくわからないまま読んだんだけどなんか当たり障りのないこと言ってるなという感じだった。
で、この内容についてどうまとめではそれについての(おそらく筆者の)所感が加えられている。ものすごい意訳になるけどざっとこんな感じ。
- 氏はブログ内で数いるうちの主要メンバーの一人であるかのように語っているが待ったくそんなことないし、めちゃくちゃ指揮系統のトップにいるだろーが
- RFC について関与してないというが(具体例をいくつも出しながら)全然そんなことねーよ
- 古参のNix開発メンバーが力持ち過ぎてコミュニティの自治とか実質効いてないないじゃねーかよ
- 軍事関係の企業がスポンサーになって金銭面での支援を受けてることのコミュニティの長にいる身として、その是非について明言しろよ
- お前のせいで台無しになってるコミュニティの避難所としててめーの会社に誘導すんのは不条理すぎるからやめろ
ということらしい。
まー確かにこう見ると信頼性にかなり問題がありそう。
仮に RFC 策定に関与してなかったとしても結局Nixのマージ権限を握ってるんだったら封建的な意思決定に変わりないしブログでの釈明については自信のふるまいという話題から権力構造に論点をすり替えたかったのかなあと思う。
感想
どんな問題もつきつめればすべて人間関係だな。
なんか Nix 使い続けるのちょっと抵抗出てきたので開発環境の構成管理は Ansible とか Vagrant を検討しようかなと思ってきた。
別に make でも shellscript でもなんでもいいけど。
XGHというものについて
日頃、スクラム開発は単なるバズワードであって手法ばかりに注目が行って有体に言ってコンサルの飯のタネとしか思ってない。 重要なのは不確定要素を可能な限り取り除いたうえで振り返りという形でイテレーションの終わりに自分たちが組織としてどのようにふるまえたかを客観的に評価する健康診断という強制的なイベントを実施して、代謝が機能するような体制づくりのことだと思う。
それゆえ、イテレーションを1か月とか長い期間とってしまうと不確定要素の相対量が増え、振り返りも難しくなるので1~2週間が望ましいと個人的には思っていて、たぶんそれが世のなかの一部エンジニアの皮をかぶった謎の存在も含めた現実を直視することが苦手なソフトウェア開発の苦労や困難の実情を知らない人間たちにとっては「開発スピードがあがるんだ！！！」みたいな的外れな幻想を抱かせてしまうのだろうと思っている。
で、そんなことを常に考えていてむしゃくしゃすることがないことはないんだけど medium.com の記事を読んで前半の Sprint に対する筆者の洞察は私と全く同じで、首肯のしすぎで頸椎が疲労骨折した。
ただし、後半の XGH なるものは極端すぎてほとんど賛同できなかった。というより、ものすごい優秀なエンジニアでないと成立しないという感想を持った。
どのようなものかは原文を参照してもらうこととして、以下が直感的な理由。
- 優先順位とかなくて必要な時に必要な価値が届けられればよい
- PO に当たるような役割はなく、要求はエンジニアが完璧に理解している前提
- 問題が発生したら局所的な対応か、作り直しをする
- テストは書かない
- それゆえリファクタリングが存在しない
- 他人の書いたコードに介入しない
一方、共感できる部分が特にない。
要はこの記事、差分を各担当者の責務としてメンテしろという話であってチーム運用の話ではないとしか思えないし、品質の話を一切してないんだけど皮肉として述べてるんだろうか。一筆書きで過不足なく動くときは動くものを作る(開発スピードについては言及なし)ということを目指しているよう思える。
チームメンバーにこの記事の感想を出してもらうことで価値観のすり合わせはできるかもしれないとは思ったけど、今のところ私には XGH は無理という結論が出ている。
Java21のパターンマッチは醜いと思う
JDK だか Java だか知らねーけど開いた口がふさがらなくて口腔内が砂漠化したのでヘイト記事を通して膿を出す。
Java (￢ JVM) がそれなりにひどいのはわざわざ表明する必要もないんだけど、JEP 441: Pattern Matching for switch で提案されているパターンマッチはひどく醜いと思う。
後付けなので仕方がないにしても permits で親子関係を明示するというのは拡張に開いていないので OCP 違反であるように思う。OCP の是非はおいておいて、とりあえず SOLID 原則の考え方は広く敷衍してるのでまあ恣意的なものであるけどそこまで無茶苦茶ではないだろうということにしておく。
Haskell のデータ型でもデータコンストラクタ並べるじゃんというのはあるんだけど、見かけは同じでも Java の interface は実用上実装が必要になる時点で全く別物だろう。
domain を決める直和的なデータ表現であることには確かに変わりないだろうけど Java の interface と Haskell の data を同列に語るのはさすがに無理がある。
だからこそこの苦し紛れな文法が導入されたんだろうけど、Java を使わないに限るなという確信が強くなった。
Java、あなたはよくやったよ。もう言語としての進化はあきらめてぐっすりお眠り。
