重力に縋るな

千種夜羽です

久しぶりに dotfiles を弄った

たまには雑なブログを書きたい.

要約はこれ.

Neovim

テキストエディタには長いこと Neovim を使っている. 「そういえばこれはいつからなのだろう,dotfiles の first commit は2018年の4月なのでまあそのぐらいなのかな」と思って自分のツイートを検索してみたらこのブログの過去記事が出てきた.なるほど.

sksat.hatenablog.com

この記事を書いた後に Vim と Neovim の間で揺れ動く,みたいなことをした覚えは無いので,2017年11月からずっと Neovim を使っているのだろう.

というか apt-get とか書いてあるし,この頃はまだ Ubuntu で生活していたんだなー.懐かしい. Neovim も Ubuntu の公式リポジトリ入りしてなかったっぽくて PPA 入れてるし. 5年前とかってそんなかんじだったんだな.

やったことは大体この Pull Request. github.com

lazy.nvim

Neovim の plugin manager には長いこと(というか,さっきの記事を見る限り最初から)dein.vim を使っていた. github.com

これは設定ファイルが TOML で書けたり,プラグイン遅延読み込みができたり,依存関係を設定できたりして便利だった. 別に dein にそんなに不満があったわけではないのだけど,せっかく色々見直す気持ちになっているのだから他の実装を調べてみるか,と思って色々見てみたところ,lazy.nvim が気に入ったので乗り換えることにした.

github.com

一応の背景としては2年前ぐらいから Neovim の設定を Lua 化しようとしていたというのがある.

github.com

僕はほとんど Vim script が書けないし書けるようになるつもりもあまりない*1ので,できるだけ Lua に設定を寄せたいと思っている. で,その上で dein の設定を見直してみると,各 plugin の設定をする時に結局 hook_add とかで Vim script 書かないといけないじゃんか~,という問題があった.

dotfiles/dein.toml at 473f9a8082a5a8a5971711e079e89f40aa098eda · sksat/dotfiles · GitHub

hook_add = '''
    autocmd BufEnter,BufWinEnter,TabEnter *.rs :lua require'lsp_extensions'.inlay_hints{}
    nnoremap <Leader>h :lua require'lsp_extensions'.inlay_hints()<CR>
'''

はてなブログ,Gist はコード埋め込みできるのに GitHub リポジトリはできないのか......)

まあここで lua してしまえば Lua で書けるのだけど,そうか?とはなる*2シンタックスハイライトとか効かないし(当然).

lua require() してしまえば .lua ファイルを読み込むこともできるけれど,ここで書きたいような設定の多くは気持ちの面では「このリポジトリから持ってくる」とか「遅延読み込みする」とかと似通っているし,同じような気持ちで設定しているのだから同じ場所で記述した方が認知コストが小さくて済む. 「どういった類のプラグインか」という文脈をもって分割したいことはあれど,同じプラグインという1つの文脈を分割したいことは個人的にはあまりない. 認知コストの面で言うと,init.lua -> dein -> TOML -> Vim script -> Lua という設定の読み込みフローも大概複雑だ. *3

ここで,Lua で完結する plugin manager を使うことで,すべての設定を init.lua に書くことができる.

もちろん,なんでもかんでも init.lua に書いたら init.lua がすごい行数になってそれはそれで体験が悪くなってしまうのだけど,その時は「keymap の設定」とか「プラグインの設定」みたいな文脈毎に Lua のモジュールとして設定を分割してしまえばよい. そうしたらこれはもうただのいつものプログラミングだ. なんなら,いつでも分割できることによって最初はベタッと1つにまとめておいた方が後で適切な分割が行いやすくなるまである.*4

あと,式年遷宮してしまえば手元の環境がなんだかんだで dotfiles リポジトリと同期してなくて diff まみれになっているやつの処理の気持ち的な手間が省ける,みたいな事情もあった. よし,乗り換えよう.

Lua で完結する plugin manager」の具体的な実装としては,packer.nvim や lazy.nvim などがある.

github.com

github.com

どちらを使うかはちょっと悩んだが,Lockfile(lazy-lock.json)があるのが気に入ったので lazy.nvim を使ってみることにした. README にもデカデカとあるけど,わかりやすいダッシュボードがあるのも面白い.

lazy.nvim のダッシュボード

LSP

Neovim 0.5.0 のリリース前から意地で Neovim builtin LSP client を使っていたので,久しぶりに見てみたら builtin LSP client でもエコシステムが整っていたしちゃんと動くので感動した.しました.

nvim-lspconfig を入れるだけでスッと動くわけ.素晴らしい.

github.com

あと,trouble.nvim と rust-tools.nvim の体験がだいぶよかった.これでまだまだ Neovim に引き篭もることができそうだ.

github.com github.com

tree-sitter

あと,今回は前から気になっていた tree-sitter による syntax highlighting も導入してみた.

tree-sitter はインクリメンタルに,かつ高速*5にパースを行うためのパーサジェネレータだ.

github.com

「syntax highlight なんてキーワードの一覧並べて正規表現とかでマッチしたやつに色付ければいいんじゃないか」みたいな気もするし,実際多くの(ほとんどの?) syntax highlighting はそのように実装されている. 実際それで十分なことがほとんどだし,コンパイラを作るわけでもないのにいちいちパーサを書くのは面倒だし,みなさんが思い思いにパーサを実装していく*6と管理できなくなっていくし,技術記事とかならともかく手元のエディタでは1文字書き換える度に色がなくなってバカ真面目にパースが走って色が付き直していたら体験が悪すぎる.

しかし,ある程度ちゃんとパースした上で syntax highlight されるとうれしいことは結構ある. まあ細かいことは置いておいて,雑に比較してみたので見てみてほしい.

syntax highlight の tree-sittter と素の VIm の比較

左が tree-sitter で右が素の Vim(つまり,keyword 登録しての雑マッチ)だ. 比較対象がC言語という syntax がおしまいすぎてマトモにパースすることすら面倒な言語というのはあるのだけど,差は歴然だ. もちろん左は2行目のコメントを戻したら色が変化する.偉すぎ. あと,引数/変数と型を区別できるところとかはコードをパッと見て内容を把握する時の負荷に結構寄与する,気がする.

そして,tree-sitter の一番偉いところは単なるパーサ実装,単なるパーサジェネレータ,というだけでなく,(テキストエディタ向けの syntax highlighting を強く意識した上で)1つのエコシステムを作っている点だろう. GitHub organization を見てみると,tree-sitter を使った各言語向けの"grammar"がたくさんあるし,それらがちゃんとメンテナンスされていることがわかる. github.com

Neovim では 0.5 から tree-sitter を使うためのサポートが入った. 実際使うためには nvim-treesitter というプラグインを使うのが手っ取り早く確実だ.

github.com

このプラグインには色々な tree-sitter grammar が登録されているので,このプラグインの設定で統一的に tree-sitter の恩恵を受けることができる.便利.

あと,tree-sitter による恩恵は syntax highlight にとどまらず,例えば nvim-treesitter-context プラグインなどでは「今この関数にいる」みたいなのを上部に表示することができる.便利.

github.com

wezterm

今回の dotfiles 盆栽の主な目的は Neovim の設定が腐っているのをどうにかすることだったのだけど,ついでに terminal emulator も変えた.

terminal emulator としては,ここ2,3年は Alacritty が顕著に人気だと思う. github.com

昔は「terminal emulator なんてバーンと黒い背景で terminal を emulate してくれればええねん,人気も何もあるかい」,みたいな気持ちもあった. しかし騙されたと思って Alacritty を動かしてみると,なんかこう,露骨に速い.terminal emulator に"速い"とかあるんだ,となる.

まあ文字列の表示って他の普通の計算・メモリコピーとかと比較すると一般に遅い処理だというのはよく知られた事実だけれど*7,それって terminal emulator 部分の律速もあったのかー,というか. これは(概ね OS 側寄りの気持ちで)OS・アプリケーションの2択(とそもそも OS が無い環境)で物事を認識しがちなところがあるからだろうな,とは思う.

それはそれとして最近は GPU の気持ちになることも増えてきたので,今考えてみると「まあうまくやったら色々速くできるわなー」という納得はある.納得. 納得ついでにちょっと思ったけど,これからは Electron 物体とかでも WebGPU でバーン(オノマトペ),みたいなかんじのやつが出てくるんだろうか(知らず).

さてこんなに Alacritty の話をしたので Alacritty を使い始めたのかというと,実はそんなことはない(オイ). これはなんだかんだ言いつつ今使っている Tilix に手が依存してしまっているからだ.

元々,「バーンと黒い背景で terminal を emulate してくれればええねん」と思っていた時期は sakura というシンプルな terminal emulator を使っていた.

github.com

これはとにかくシンプルでいい.黒いし.

ちなみに今見てみたら実装は sakura.c 1ファイルだけでめちゃめちゃびっくりした.そうなんだ. あとタブ機能が存在したことも今知った.そうなんだ2.

Alacritty もシンプル志向なので,このまま sakura をずっと使っていたならなんの支障もなく Alacritty に移行できていたと思うのだが,3年前から Tilix に乗り換えていたのでそうもいかなくなってしまっていた.

github.com

まずはこれを見てほしい

Tilix の実装言語

Dだ.

......D?

............D言語

https://raw.githubusercontent.com/dlang-community/d-mans/gh-pages/dman-original.svg

そう.D言語で実装されているのだ. D言語で実装されたプロダクトってあるんだ(超失礼).

というわけで「D言語で実装されている」という驚きによってこの Tilix を使っていた*8のだけど,使い始めた理由はともかくとして,これが非常に手に馴染んでいた.

その理由はまさにこれが"A tiling terminal emulator"だからだ*9. window manager にずっと i3wm を使っているような人間なので,あらゆるウィンドウ的なモノはタイル状に並んでいてほしい. そういう欲求がある.Tilix はそれを叶えてくれる. 1つのウィンドウでタイル状に terminal のセッションを切っていける.僕のプログラミングスタイルは完全にこれに依存してしまった.

「どうせタイル型 WM 使ってるんだから terminal emulator のウィンドウを開いて並べればいいだろ」?

いや違う,そうじゃないんだ. terminal は同時にたくさん開きたいけど,その上で他のアプリケーションのウィンドウ(主にブラウザ)と「terminal の集合」を同等に扱いたいんだ.

「それって tmux とかの terminal multiplexer でやればいいんじゃないの」?

そう思います!!!!!!でも僕の手に馴染まないんだあれらは*10

で,まあ何が問題かって alacritty はタイル状にセッションを切れないのだ. それ以前に,タブ機能みたいなものすらない. なんと sakura にすらあったというのに*11

これは単に無いだけでなく,そもそも実装する気がビタいち無いらしい.

github.com

まあそういうことなら仕方ない.仕方ないのだけど,少なくとも今は Not for me であることも事実だ.

というわけで,「救いはないんですか?」となるわけだが,意外と救いはある.それが wezterm だ.

github.com

GPU-acceleratted だし,horizontal/vertical split もできるし,設定は Lua で書ける. こういうのでいいんだよこういうので.

というところまでちょうど2年前にまったく同じことを考えて,wezterm に移行しようとしていたことがある.

ただし,この移行はこの後無事に失敗していた. 理由はいくつかあるが,一番致命的なのは日本語入力がろくすっぽ動かなかったからだ. 当時は IME 対応がまったく無かったわけではなく,「動くこともあるらしい」みたいな怪情報が出回っているもののまあ結局安定してはいない,みたいな状態だったと思う. 少なくとも自分の手元では動かなかった.ざんねん.

そして,最近はどうなのかなと思って見てみたらここらへんの問題が大体解決していたのでリベンジしてみるか,というわけだ. 特に IME 周りはどうにも去年あたりに色々対応が入ったようだ.

設定は一旦こんなかんじだ. github.com

大した設定はまだしていないけれど,概ねいいかんじに使えているので今度は長続きするんじゃないだろうか.

強いて言えば,Tilix でいうところの "Add terminal automatically" がとても欲しい. split したい領域が縦長だったら縦に,横長だったら横に分割するやつだ.

しかし,まあ一旦 horizontal/vertical split の keybind が分かれていても思ったよりはダメージはなかった. 1秒くらいのディレイは発生するけれど,split は個人的にはそこそこの頻度でやるので意外と慣れる. それはそれとして気持ちがあるときにパッチを書いてもいいかもしれない.

== 記事とゴールデンウィークの終わり

2日ほどこの環境でやっているけど結構快適に生活できている.

ちなみに,今クソデカ find を各 terminal emulator で雑に戦わせてみたら,

  • Alacritty: 30s
  • wezterm: 1m
  • kitty*12: 1m
  • Tilix: 1m15s

みたいなかんじだった.

悔しい!!!!!!

あとなんか連休とかいうやつも終わるらしい!!!!!!!!!!

*1:単にプログラミング言語的にどうこうとか syntax がどうこうみたいな問題ではなくて,そもそも僕が気合を入れて Neovim の設定を弄るようなことが1年ぐらいの間隔でしか無いのでメリットがあまりないこと,設定がろくすっぽ構造化されていないので渋い気持ちになる,などが理由

*2:ヒアドキュメントで複数行も書けるけど,少なくともなんか負けた気持ちにはなる

*3:ちゃんと計測とかしてないけど,ここの読み込みコストも気にならなくはない.まあ LuaJIT が速すぎることによって大して問題になっていない,みたいなのもありそうだが......

*4:monorepo と同じ利点

*5:Fast enough to parse on every keystroke in a text editor とのこと

*6:思い思いにパーサを実装するのは,楽しい

*7:これによって「printf を挟むと動く」みたいなやつが発生しがち

*8:本当に失礼

*9:なお,それにめちゃめちゃ依存しておいて tiling を意識している上に名前の由来もそれなことに今気付いた

*10:ちゃんと理由を考えてみる必要があるなとは思っている

*11:いやまあ,使ってなかったというか存在に気付いていなかったけれども

*12:そういえばちゃんと試してなかったので検討する価値はある

ArkEdge Space で正社員になって半年が経った

タイトルの通りなのだけれど,ArkEdge Space で正社員になって半年が経っていた.

何をやっているかといえば,そこかしこで何度も言っているが,人工衛星を作っている.

sksat.hatenablog.com

正社員になるなんてことは人生で始めてのことだけれど,正直なところその「変化」の瞬間には思い入れがあるわけではない. というかあんまり覚えていない.その前日と同じように仕事をしたんだと思う. たぶん一番大変だったのはバックオフィスの人だろう. まるで正社員かのように働くインターン生も,(大学生をやりながらであることによって)インターン生かのように働くこともある正社員も,どちらもとても面倒だと思う.いつも本当にありがとうございます.

だったらなんでこんな記事を書いているかといったら,まあ久しぶりに文章を書きたい気持ちになってきているからだろう. 一歩引いて考える余裕ができてきたということかもしれない. それも当然といえば当然で,期間を半年から1年に伸ばせば,家出しての一人暮らしに退学に入学にと,単純に生活環境があまりに大きく変わって最初の1年だったからだ,という話は年末に少し書いた.

sksat.hatenablog.com

それにしても,(いい機会なのでちゃんと懐古しておくが)個人的な事情を含めずとも実におもしろい半年だったし1年だった. うちのチームの振り返り記事もあるので貼っておく.

blog.arkedge.space

仕事そのものがおもしろいことはもちろん,組織の成長を目の当たりにできるというのもとてもいい経験だった. 成長というか,ほとんど無いようなところからだったので,だいぶ感慨深い. そう言ってうちのチームの Slack channel を遡ると,一番最初の投稿が音信不通になった僕と Twitter DM で連絡を取ってたり,その後初手で寝坊かますみたいなかんじだったりする.まあ,うん.ごめんて.

正社員というロール

なんだかんだ書いたけど,正社員になったことによる変化が無いのかというかというと,当然そんなこともない. まあ最も生活に関わる部分で言えば給料と社会保険なのだけど,それに限らず.

ひとつ大きいものを上げるとすれば,「明確に責任を持てるようになった」ということがあると思う. こういう書き方をすると責任を取りたい人みたいになってしまうが,そういうことではない. ぶっちゃけ責任なんてできる限り取りたくない. コードだってそうだ.各構成要素はそれが必要な最小の権限を持つべきだし,それぞれが小さな責任を果たすべきだ.

では何かというと,それこそコードで例えるなら「適切に AssumeRole したい」みたいな話だ. 単純に「このリポジトリのメンテ権限が欲しい」みたいなやつから, 「あのコンポーネントのソフトウェアは僕が面倒見ます」みたいなやつもある. 前者については,気軽に言える空気感と,"誰に言えばいいか"が明瞭であれば問題無いし,弊社ではそれこそ1年前ぐらいにレポートラインが大きくリファクタリングされたのもあって,その点についてはあんまり心配していない. しかし,後者は結構難しい.なんというか,その運用がだ.

なにをもって(特にソフトウェアに対して)責任を持つと言えるのかというのも難しいけれど, ここで大事なのはスケジュールを考えることだと思う. より正確には,本物のスケジュールを考えメンテするという部分には僕は気持ちも経験もあまり無く,実際それはマネージャ側の責務なので, 重要なのはスケジュールを考えるための制約条件をちゃんと解きほぐすことだ. 「コレはあの人タスクだからそこでブロッキングが発生する」とか, 「実はコレとコレは並列で回せるしそうした方が速い(ので,そのためにまずココを分割するのが最優先)」,みたいな.

そして,だからこそ正社員ではないインターン生には「スケジュール的な制約があまりないものの今やっておくと後で活きる」みたいなタスクを投げるのがよいのだと思う. うちの部長: id:meltingrabbitインターン生を取る時に面接で毎回これを本人に言っていて本当に正しいと思う(「なので,ちゃんと余裕のある時期にね」,みたいな suffix が付く). そういった言葉の意味というか裏側がちゃんと分かるようになったというか,実感を持てるようになったのは正社員になってからのことな気がする.

ソフトウェアエンジニアとして働くということ

似たようなところでいうと,他人の仕事だったり,その仕方についての興味が強くなった,というのもある. この他人というのは当然ながらソフトウェアエンジニアに限らない. なんというか,元々興味はあったけれど,それを元にコミュニケーションができるようになったというか,それを勘定に入れて振る舞えるようになった,という方が正確かもしれない. 具体的には,「アレはあのヒトに任せられるから,一旦任せておいて僕の出番が来そうになったら出現しよう」とか, 「あのヒトがやっていることはたぶんアレにも使えるから感触を聞いておこう」みたいな動きをするようになった. スケジュールを考えながらどうこうするのだって似たようなものだ. 「いついつまでにアレとかソレの試験をしたいということは,そのための試験用ソフトウェア(とそれをうまくやるための仕組み)を作っておかないとなあ」とか.

そして,僕はどうやら色々なことに首を突っ込むのがかなり得意なのだ. ベンチャー企業で平社員一人にそんなにたくさん首突っ込める(そしてそれが有効に機能する)ことなんてあるかよという気もするが,宇宙開発というやつが総合格闘技であるからか,そうでもない. 姿勢(制御, 計算)系をやっているヒトも,通信系をやっているヒトも,熱系をやっているヒトも,電源系をやっているヒトも,構造系をやっているヒトも,そしてバックオフィスをやっているヒトも全然やっていることが違うのだ. やっていることが違う中で,ソフトウェアというやつはなんだかんだ大抵全部に関係する.そこに実機のマイコンがあれば言わずもがなだし, 数値計算をしていればその計算をするソフトウェアがある. わかりやすいところでも,全員 GitHub と Slack というソフトウェアを使っているわけだ.

インターンとして入って最初にやった大きなことが GitHub/Slack を使った働き方を整備・普及させる活動だったのも,こういうところから来ていると思う. まあこれに関しては自分が働きにくくて困ったので率先してやったというところもあるけれど.

blog.arkedge.space

そこにソフトウェアがある以上,多少なりともソフトウェアを知っている奴として首を突っ込んで「それこうすると便利っすよ」とか「そのやり方だと後で詰むんでこうした方がいいです」とか言うだけでも価値があることは多い. なんとなくリポジトリを見かけて CI が無くて組めるなら Pull Request を投げに行くし, ソフトウェアでなくても,省力化・自動化できそうなことを見つけたら「これってどうなんですかね?」と聴きに行く.

もちろん,それですぐに本当の問題に辿りついたり,問題が解決するとは限らない. だって後から首を突っ込んできているのだ.そもそもその問題の対象をよく知らないし,聴いても中身は全然分からないこともある. とはいえ,中身がちゃんとわからないなりにそこをブラックボックスとして扱ってもを考えられることは結構ある. ソフトウェアエンジニアってやつにはレイヤーを分けて考えるとか問題の切り分けとかに関しては一日の長はやっぱりある. それはそれとして,そもそも全然知らないことに対する好奇心が結構あるので,自在に操れるようにはならなくとも「どういう気持ちがあるのか」までは咀嚼しに行くようにしている. まあ,最悪なんも役に立てなくても,ドメイン知識の無い他人に対して説明することで思考が整理されるとかは(自分がやる側になっても)結構あるし, あとで別の人が似たようなことを気にしていたときに「それあの人が詳しいですね」みたいなルーティングもできるし,ドキュメント化されるべきものがドキュメント化されるいい機会になったりもするし,ということで許してほしい(?).

他人と働くということ

あと,こういったことを考えるようになったことで,本当の意味で他人にタスクを投げられるようになってきたとも思う. 色々なことに首を突っ込むということは,仕事を増やすということでもある. 大抵の場合は首を突っ込んでいる理由は自動化だとか開発体験の改善だとかのスケールメリットのためだし,そこについてはあんまり大外れしたことは無いので突っ込む先の人には許してほしい. それはそれとして,一人で各所に首を突っ込んでいる僕自身の仕事は首を突っ込めば突っ込むほどに増えていくのだ. 自分から仕事増やして仕事が多いというのも本末転倒だが,悲しいかな首は1本しか無いのだ. 増やせるなら増やしたい.ついでに頭も.

じゃあどうするかというと選択肢はいくつかあって,

  • 首のスループットを上げて超人になる
  • 他の人に託す
  • 未来の自分(たち)に託す

などがある.首のスループットを上げるのはなんとか頑張っていきたいところだけど,時間がかかる. そしてその瞬間に性能が足りていないなら取らぬ狸の皮算用なので,実際には後の2つだ. ちなみに,完全に諦めるという選択肢はあんまり無い. これは脳筋だからではなくて,(首を突っ込んでいることそのものではなく)首を突っ込んだ結果仕事,つまりなんらかのタスクが発生しているということは, なにかしらの問題の把握ができていて,それを解決するための手段(直接的な解決策ではなく,それを探るためのメタタスクでもいい)への分割には成功しているからだ.

もちろん,単にやれる人がいないので一旦やらないとか,スケジュール的に無理があるのでやらないとか,もっといい解決策が出てきたのでそっちでやるとか,そういうことはある. しかし,それは一つの問題への対処ではあるし,そもそも我々は何機も何機も人工衛星を作ろうとしているのだから,どこかで発生した/させられた問題というか,課題意識はどこかで絶対に役に立つと言っても過言ではない. そういう意味では,一旦の諦めも大体未来の自分(たち)に託すのとあまり変わりない.その課題感が GitHub の Issue のようなストック情報から読み取れるようになっていれば完璧だ. さらにまとめてしまうなら,未来の自分(たち)に託すのだって他の人に託すようなものだ. 「数ヶ月後の自分は他人なので,一人でやっていてもコメントを書くべき」みたいなことはよく言われるけれど,だいたい同じだ.

そういうところでいうと,上司とか経営陣みたいなロールの人たちは1つ2つレイヤーの高い「タスク」を我々に投げているのだからすごい. もちろん彼らは使用者なのだから,そこにはカネという明確な媒介物とかがあるとはいえ,それにしたってすごい信頼関係モデルである. まあそういう関係そのものを信仰してもお互いによくないので,こっちに関しては一歩引いて見ていなければならなくはあるけれど.

ビルドシステムの面倒を見るということ

責任を取るとか,面倒を見る,みたいなところでいうと,最近社内で「ビルドシステム大臣」と名乗っている. いや,別にそのように名乗りを上げているわけではないけれど,Slack の自分の profile の末尾に書いたり, なんらかのビルドシステムで困っていそうな Slack post を見かけたら出現したりしている. というか,そういう振る舞いをしているので名前を付けたという方が正しい.

「ビルドシステム大臣」という語には, CI/CD 大臣という意味も含めているつもりだ. そこにデプロイがあるならできるだけ自動化したいし,当然デプロイするモノをビルドする過程がある. それはビルドシステムと呼んで差し支え無いだろう.

一方で,CI でやりたいものは test だったり lint だったりして,それはビルドではないのではという気もするが,これもまた無関係な話ではない. test のための小さなプログラムがどのようにビルドされるかはかなり大事だ. その test にはアーキテクチャ依存はあるのか?そこで使う別のコンポーネントのバージョン管理は?見るべきところは多い. lint だってそうだ.特にコンパイル型言語であれば,目の前にある最重要の linter はコンパイラの error/warning である. clang-tidy みたいな linter 専用のモノもあるし,弊社でもこういうのはとても使っているけれど, この類の linter は「めちゃめちゃ warning を出すコンパイラ」として振る舞いがちだ.つまり結局ビルドしている. 余談だが,こういう側面からしても「とりあえず rust-analyzer と clippy」,と言える点で Rust は本当によい.

ちなみに,clippy, clang-tidy の出力を reviewdog に喰わせて PR comment とかに流すための GitHub Action を作ってある. reviewdog は本当によい文化だと思う. CI がコケた時には赤いバツマークと共に status check failed とだけ表示される以上の情報が出てくるべきだ. 何より,機械に理路整然と怒られるのは気分がよいのだ*1. どうしても人間に怒られるのは(別に感情的になってるとかそういうことではなく,ある程度本質的に)ムカついてしまうのだ,人間というやつは. 今日も一日コンパイルエラーに,そしてワーニングに,ありがとう.

github.com

github.com

さて,なんでわざわざ自分の振る舞いに「ビルドシステム大臣」なんて名前を付けたかと言えば,責務を表明するためだ. 我々はよくソフトウェアを細かい責務に分割しているししていくべきだけれど, コンポーネントの区切り方にしても,変数の名前にしても,命名という行為は常に責任分割の単位だ. 個人的に「名の無いところに責務は立てられぬ」などと言ったりしている. これは不適切な命名をしてしまうと責務の分割も不適切になってしまいがちということでもある. とまあグダグダと書いたけれど,「CI/CD 大臣」ではなく「ビルドシステム大臣」なのは,CI/CD みたいな目の前の(あえて言ってしまうと)瑣末な自動化に気持ちがあるのではなく, もっと広範なところに気持ちがあるのだということをみなさんになんとなく認識してもらいたい,みたいな意図がうっすらとある.

そしてそれを表明するということは,そういう話題があったらまず僕に話を通せという意思表示だ. 人工衛星の実機に焼くソフトウェアのビルドシステムも,それをコンテナに固めて AWS 上で仮想的な人工衛星を飛ばすための仕組みも,マイコン毎にコードを共有するための仕組み作りも,全部だ. 弊社で僕の目の届かないビルドシステムは高速に腐って手に負えなくなるだろう.断言していい.少なくとも今は.だから任せてくれ.

数十cm角の箱,あるいは調整の塊

弊社で作っている人工衛星はそこかしこで口酸っぱく言っているように超小型人工衛星というやつで,どれくらい小さいかと言ったら僕のメインのATXのデスクトップマシンの半分未満か1/3くらいだ. デスクトップマシンが地球を回っているだけだったらまだラクだったのだけど, そんな中にとてもたくさんのモノが詰まっている.*2

たくさんのモノが詰まっているということは,たくさんのヒトがいるということだ. しかも,そのたくさんのヒトが,それぞれの専門性を持ってあの数十cm角の箱について考えて手を動かしているということだ. そこに載せるマイコンボード一つを挙げても,その上で動くソフトウェアについてばかり考えているヒトもいるし,そこで使うネットワークプロトコルやIDが気になるヒトもいるし,その電力収支が気になるヒトもいるし,それが発する熱の影響が気になるヒトもいるし,それが慣性モーメントに与える影響が気になるヒトもいる.

そして,そのたくさんヒトたちがあの箱をどのように・どう作るかについてやいのやいの言いながら,あの箱が作られている. つまり,あの箱を作るのにも,なんなら軌道上にデプロイしてもらうためにも恐ろしい量の調整が行われている. 我々は調整の塊を軌道上にデプロイしているのだ.

というようなことを書くと,「みんなでつくる感」というか,ちょっと感動的なかんじがしてくるかもしれない. まあ正直個人的にもそういうのは自分でやる分にはかなり好きだと思う.*3 とはいえ,我々はビジネスとしてやっているのだから,観客がいるのならまだしも我々自身が感動しても一銭にもならない. そして我々だって別に感動したくてやっているわけでもない. モノを作るついでに感動できるならそれに越したことはないけれど,感動してモノが作れなかったらそれは本末転倒だ. 別に感動もできない.みなさんの努力の結果軌道上に文鎮をデプロイしても何もおもしろくない. 軌道上にある文鎮,遠すぎて目の前にある紙の上に置けないし.

国家プロジェクトとかで,莫大なカネとヒトを注ぎ込んで1つ2つの巨大な調整の塊を打ち上げるならそれもいいだろう. しかし,今はもうそんな時代ではない. 地球・宇宙観測のために,通信インフラのために,安全保障のために,なんならエンターテイメントのために人工衛星が打ち上がるのだ. ようは人工衛星が特別な一品物ではなくなって,ポンポン作って打ち上げて気軽に使えるようになっていくし, なにより我々はそうしていきたいのだ.

prtimes.jp

これはつまり10個,100個,1000個とたくさん人工衛星を作って打ち上げていくということだ. とりあえず弊社が関わっている人工衛星というだけでも,この年始で2機軌道に放出された.幸先のいいことだ. まあデプロイしたということは運用が始まるということで,本当はこっちが本番だし,これも当然調整の塊なので超大変なのだけれど.

ちなみに前者は SpaceX の Transporter-6 というミッションで打ち上げられ, これは小型衛星だけを同時に114機軌道に投入するものだった. 様々な組織が様々な目的のために作った衛星群とはいえ,一度の打ち上げで114機も上がるのだ. なんならそれを打ち上げている SpaceXStarlink のために 3000機ほど上げている. というかこの文章を書いている間にも Starlink 衛星が上がっていた.今日は49機増えたらしい.

さて,こうなってくると,調整の塊をそのまま増やすだけでも調整の量が扱いきれなくなる. しかも,当然調整の塊を増やすための調整も発生してくる. 調整の塊を1個から10個にするための調整も,10個から100個にするための調整も,100個から1000個にするための調整もそれぞれ別種のものであることを考えると,ナイーブにやればその調整はもはや人類に扱い切れない量になるだろう. 調整という言葉を,時間計算量とか空間計算量に倣って「人間計算量」みたいに言い換えてもいいかもしれない.

何を言いたいかというと,人間計算量のオーダーを下げなければならない. つい最近うちの部のポリシーが公開されたけれど,「開発機数に対してコストが劣線形になるように(スケールメリットが出るように)ソフトウェアを開発するべきである」とかはまさにこういうことだ.

blog.arkedge.space

宇宙は近くて遠い

少し話が逸れるけど,どうにも宇宙というやつは雲を掴むような話と思われるというか,遠い世界の話のように思われがちなので,我々が働いている世界観の話を少し書いておきたいと思う. 実際宇宙は雲より遠いし,「宇宙」と呼べる範囲から遠くは全部宇宙なので,なんというか平均的な宇宙は遠い. 単純に地上からの距離というか,高度を持って宇宙の話をするなら,100km < 宇宙 というかんじだ. 実際の閾値は 100km とは限らない*4のだけど,だいたい 100km (より上)と言っておけば間違いはない.

ja.wikipedia.org

100km.遠くはある.でもちょっと考えてみてほしい. 実は東京を中心に半径 100km の円を描いたら,「関東圏」は入るかな,という程度だ. 東京-名古屋とか実は 300km くらいだ.桁を一つ足して 1000km にしても,まあ「日本列島」の目立った範囲は入るかな,という程度だ. 僕のとても好きなアニメのひとつに,『宇宙よりも遠い場所』という女子高校生が南極まで行く作品があるのだけど, 実は東京から新幹線に乗って名古屋に行ってひつまぶし食べてくるだけで宇宙よりも遠い場所への旅である. というかつくばから東京のオフィスに出社するだけで 50~60km くらいだ.往復したら宇宙より遠い. そして,この距離にしてはつくばエクスプレス(TX)が十分に速すぎるのでそこまで遠くは感じない.

じゃあなぜ宇宙が「遠い」のかといえば,理由は大きく分けて2つある.

  • 宇宙まで新幹線やTXが開通していないから
  • 本当に必要なものは距離ではなく速度だから

前者は身も蓋もないようであるけれど,それはそうだ. 人工衛星のデプロイ先に新幹線で出張に行って帰ってこられるなら解決する問題は多い.デバッガ刺してアタッチできるし. でも新幹線は宇宙に停車してくれないのだ.そればかりか地上を2次元的にしか移動できない.上方向に伸びているホームも今のところ見当たらない.残念.

そして,最大の問題は後者の速度だ.ぶっちゃけ距離が遠いとかは比較的どうでもいい.距離が問題になるのは光が遅すぎて渋いときとかだ. これも考えてみれば単純な話だ.宇宙にモノをデプロイしたい.そして宇宙とは地上から 100km より高いところである. ナイーブな発想としては,モノを勢いよく上にブン投げればいい.まあ実際にはあの箱を 100km 上空までブン投げられる筋力のあるヒトはいないのでもうちょっと考えることはあるけれど,基本的にはそうだ. さて 100km 上空まで真上にブン投げることに成功したとする.するとどうなるかは賢明な読者ならもうお気付きだろう*5. そう,落ちてくるのだ.なんと重力とかいうやつがあるのでね. 幸いなことに地球は回っているし,空気抵抗とかもあるので顔面にぶつかってきてケガをする心配はあまりないけれど,これでは困る.

じゃあどうするかといったら,真上ではなく真横にブン投げればいい. ある程度の速度で投げることに成功すると,地球が丸いおかげで「常に落ち続けている」という状態が発生する. 実際には真横に投げるとビルとか山とかがとてもジャマだ. あと空気抵抗ってやつが一番ジャマだ.せっかく速くブン投げてもアイツが速度を奪っていってしまうのだ. そのため,結局 100km くらいの高度は欲しくなってくる.アレは「空気がほとんどなくなってくるライン」だからだ. 高校物理みたいな話をしたけれど,結局のところ人工衛星をデプロイするのがなんで大変かといったら,めちゃめちゃ速くブン投げないといけないからなのだ. そして,その速さってのは秒速 8km とかになってくる.時速じゃなくて秒速.まあそりゃ大変だ.

この大変な速度は TX も新幹線も飛行機も出せないのだけれど,ひとつだけこの速度を実現可能な輸送システムがある.それがあのロケットってやつだ. アレは巨体に燃料をたくさん詰めて,それをひたすらに燃やしまくって,そのガスを後ろに押し出して反作用で前に進む,という動作モデルのシステムだ. 燃料と書いたけど,実は酸素が無かったら燃料は燃やせない(燃やす,という操作がそもそも酸素とくっつけることだ). なので酸素ないし酸素を含んだモノも同じくらい詰めてそれを使って燃やす.酸化剤ってやつだ. ちなみに酸素とかをガスのまま詰めても大した量を詰められないので,めちゃめちゃ冷やして液体として使うことが多い. なので(液体燃料)ロケットってやつはめちゃめちゃ冷えたものでめちゃめちゃ熱いガスを吹くシステムだったりする.まあ大変そうだ.

で,もちろん燃やし方とかもめちゃめちゃ頑張っているのだけれど,それでも軌道に乗れるような速度に到達するためにはあの巨体の9割以上を燃やし尽くすことになる. なのであの巨体のほとんどは燃料タンクだ.そんでもって先っちょの方の本の少しの部分に人工衛星が鎮座ましましていて,それだけが軌道に投入される. そういう乱暴なモデルの輸送システムなのだ.乱暴なモデルではあるけれど,素朴にやったら燃料に火が付いて大爆発するだけだし, 投入したい軌道ってやつも結構ちゃんと決まっているので,緻密に制御しなければならない. そんなわけで,これのコストがめちゃめちゃ高い. その結果,宇宙開発というやつは元々国家プロジェクトでしかできない領域だったと言っても過言ではないだろう.

その後,主に通信衛星とかの需要によって,民間企業も人工衛星を作るようになった. とはいえこれも結局とても高いのは変わらない. で,これをある程度どうにかする方法が「人工衛星をめちゃめちゃ小さく作って,他の人工衛星のついでに打ち上げてもらう」というものだ.相乗りってやつである. 小さく,というのは体積的にもそうだけれど,質量の方が大事だ. 大きな人工衛星は数トンとかあるので,ここで例えば 数十kg とか 数kg とかのオーダーの人工衛星を作ることができれば,まあついでに載せてやらんこともないかなという気がしてくる*6. これが小型衛星とか,我々がやっている超小型衛星ってやつなのだ.

ついでに載せてもらう以上,もちろん色々と制約はある.軌道が自由に選べないとか. とはいえ,人類が使いたくなる軌道というか,人類にとって便利な軌道というのは結構限られている. なので,これは意外と困らない.実は人類は日々色々な人工衛星を打ち上げているので,そこそこの頻度で使いたいような軌道に上がる人工衛星はある. というかロケットに拘りがあるわけでもあんまりないので,ダメだったら次を探せばいい.そういうかんじの世界観だ. これでデプロイ費用はだいぶ安く済む.代わりにめちゃめちゃ小さい人工衛星でいったい何がどのようにできるかは考えないといけないけれど,まあここがチャレンジングな要素なわけだ. そして意外と小さい人工衛星にもできることは色々あるぞ,というのは分かってきている.

これで桁がいくつか違うレベルでデプロイ費用が安くなった.まあそれでも一番インパクトがある金額ではあるのだが. そしてここはロケット屋さんという運送業者側の責務だ.必要以上に考えても仕方ないし,何より彼らも日々安くするための努力をしている. 我々はロケットの縛りはあんまりなく,あの小さな箱を軌道上までデプロイしてもらえればそんなに文句は無い. 安くて便利なロケットが出てきたらそれを使えばいいだけの話だ.

それでも,人工衛星にかかるトータルのコストは十分企業がためらう額になってしまう. なので,更に安く人工衛星が使えればそれに越したことはない.なのでここもチャレンジングな要素だ. で,デプロイコストの他にどういうコストが発生しているのかといえば,人件費と原価だ. 人件費という点で,上で書いた"人間計算量"はとても重要だ.ベンチャー企業みたいな少ない人数で効率的にたくさん人工衛星を作って売れれば最高というわけ. まあ別に経営者でも無いし単純に詳しくないのでこのぐらいにしておくが.

ということで次は原価だ.実はあの箱は普通に原価がめちゃめちゃ高いのである. こっちはまだ自分に近い話なのだけど,なんかもう数百万とか数千万みたいな桁の金額の話はちょっと見慣れてしまった. これは全体の価格ではなくて,一部のコンポーネントでの話だ. まあ宇宙という極限環境でもブッ壊れない特殊なデバイスであることを考えると,ある程度はどうしようもないものがある. ECC メモリが高いみたいな話だ.世の中には「航空宇宙グレード」みたいな概念があって,ようは一番すごくて高いやつである.しかも大抵の場合量産していない.そりゃあ高い.

そして,そんな高くてすごいモノを使っても,実はダメな時はダメだ.ちょっと太陽が元気で荷電粒子がめちゃめちゃ降り注いできて回路がブチ壊れる,とか. そこで,よくあるのが同じモノを2個とか3個とか載せて冗長化することだ. 我々とはまた別の世界観の話だけれど,有人宇宙機では三重冗長が基本みたいな話も聞いたことがある. しかし,そんなことをしていたら当然どう考えてもコストが倍どころではなくなってきてしまう. それだけではなく,我々の人工衛星はとても小さく作っていて,あの大きさで色々なことを実現するために中身がギチギチに詰まっている. そうなると単純に増やした分を入れるだけで超大変だ.

観察し手を動かす

じゃあどうするかというと,リスク評価をちゃんとやる. つまり,その対策は(とくに超小型人工衛星という文脈において)リスクに見合うのか?ということをちゃんと突き詰めて考えて,見合わなければ割り切るということだ.

まず一つ重要な観点として,超小型人工衛星は大型衛星と比較して寿命が短くても構わない. 大型衛星は打ち上げコストも開発コストも開発期間もすごいことになっているので,10年とかは使えないとコストに見合わないのだが,超小型衛星はそうではない. もちろん長く動いてくれたらそれに越したことはないのだけど,そもそもが桁が違うレベルで安く済むし,開発期間も短くできるというモデルなのだから,リプレースする期間は短くていい.

ここではソフトウェアに関連するマイコンとかメモリの話をするけれど, 次に重要なのは人工衛星の中には結構たくさんのマイコンが載っているという点だ. 電源管理をしているもの,温度管理をしているもの,ミッションを実行するためのもの(望遠鏡が付いてるとかならそのカメラとか画像処理とかをやる),中心で API サーバみたいなことをしているものと,色々ある. そして,この中で一番重要なのは当然電源管理をしているものだ.コイツの気が狂うと流石に困る. 人工衛星全体が完全に再起不能になる可能性が高いからだ.軌道上を周回する文鎮にはなんの価値も無い. なので,コイツはカネとか電力とか体積とか質量みたいな貴重なリソースを割いてでも冗長化する意味がある.

では,他はどうだろうか?中心にいるやつとか結構大事そうだ. しかし,例えばコイツをハードウェア的に冗長化するとして,どのようにしたらいいのだろうか. 冗長化というか,HA構成みたいなかんじにするとかはアリかもしれない.でもそうなると3台とかあってほしい気がしてくる. でもそれで得られる効果はカネ・電力・体積・質量に見合うのか? そもそも人工衛星にアクセスできるのは人工衛星が地球の周りを回ってきて,地上局の上に来てくれた時だけだ. 衛星間通信とかをやるなら話は変わってくるけれど,別に文鎮にさえならなければダウンタイムは結構許容できるのではないか? 訂正できないレベルでメモリの中身がビット反転してる状態は困るが,回路が焼き切れてるとかでなければ再起動すればいいのでは? などなど,色々と考えてみることができる.

また,特に放射線というやつは実は地上で試験することができる. 世の中には加速器で高エネルギー粒子をブチ当てまくって試験できる設備というやつがあるのだ. ここで数年分の放射線を当てながらマイコンやメモリの動作をテストすることができる. これにより,「このくらい当たったらこれくらいビット反転したり壊れたりするんだな」というのを定量的に評価することができる.

そして,これがとても重要なのだけど,「航空宇宙グレードではないけれど,秋月で買ってきたアレがある程度は動いた」みたいなことが結構ある. コストという面でも桁が3つ4つ違うことがあるし,量産されていることによって圧倒的に使いやすかったりする.つまりこれもリスクに見合うなら全然アリなのだ. もちろんそういう普通のもの,「民生品」は宇宙での動作なんて保証していないし,just works ではあるのだけれど,ある程度は動くというのはまた一つの正義だ. こういうのは COTS (commercial off-the-shelf) なんて呼ばれている.

というか,超小型人工衛星そのものが「秋月で買ってきたやつで小さい人工衛星っぽいものを作って飛ばしてみたら結構動いた」みたいなところから始まっているまであるのだ. 大学で人工衛星作ってますみたいな話で,何百万もする航空宇宙グレードのブツをポンポン買えるわけがないので,それはそうだ. そしてそいつらはある程度は全然動いているのだ.その事実は否定できない. 当然,何も考えずに「無保証で安いモノ使ったけどこれでよかったわw」みたいなことを言いたいわけではない. できることはやるし,何のために何を取って何を取らないかって話だ.

「枯れた技術」を盲目的に信仰するなということ

ちゃんと観察して手を動かそうぜ,ということに関しては一つ強く言いたいことがある.

宇宙業界ってやつでは,なにかしらの技術選定をするときに「あの衛星ではアレを使ってたよ」というのを参考にするというか,丸パクリすることが多い. 「軌道上実績」というやつだ.もっと大雑把に「枯れた技術」みたいな言葉を好む人も多い. 軌道上実績があるのはとても強い.「動いたことがある」という事実が与える安心感はとても大きい. しかし,業界全体でこの言葉が一人歩きしすぎているように思う.

ようは全体的に新しいモノに対するかなり強い忌避感があるのだ. ハードウェアが絡むとそういうところがありがちではあるけれど,中でも群を抜いて執着があると思う. まあファーストペンギンをやるのが大変すぎるので,気持ちはわかるし技術選定の方針としても特段間違ったものではない. 巨人の肩に乗るのもとてもいいことだ.

でも,その肩ちゃんと巨人なんだろうか. 別にペンギンは大きくはない. 宇宙でやりたいことが色々と増えてきているし身近にもなりつつあるところで, ちょっとペンギンの肩に重荷を載せすぎていやしないだろうか. 彼らにモノを載せられるような肩あるかわからないけど(滑りそうだ).

これはソフトウェアでは特にそうだ. そもそも,「宇宙開発」の界隈の人たちは別にソフトウェアに明るいわけではない. 大抵の場合専門外なのだから至極当然ではある. とはいえ,人工衛星というやつはどこからどう見ても計算機の集合体であり,要求が特殊な組み込みシステムだし, ナニカを宇宙でやりたくて作っているそのナニカを実行することになるのも,そのデータを受信して処理するのもソフトウェアなのだ. そんなこんなで,「結果的にソフトウェアをやっているヒト」が多い.

それ自体はいい.なんなら両方できる体力はめちゃめちゃすごいと思う. しかし,しかしだ.ロボコンとかをやったことがある人にはなんとなくわかってもらえると思うのだが,彼らが書いたソフトウェアは,なんというかすごいことになっている. 超巨大な main 関数だとか,コピペされまくった違いがよくわからないしコメントがあるわけでもない謎の関数とか,フラグとしてもカウンタとしてもアドレスとしても使われる謎の変数とか, それの名前が謎の3文字だとか,そういうやつだ. 運が良ければその謎の3文字は謎の PDF ファイルの用語集とかに載っていることもある*7

あと,そういう背景と,組み込みってやつが C言語 でありがちなことが悪魔合体してとても直視できない代物になっているところも多い. 我々ソフトウェアに気持ちがあるマンでも「こればっかりはどうしようもないので void* で......」みたいなことばかりやることになるのだから. そして,悲しいかなこれが動いてしまうのである.気合と根性で. いや,動かないこともあるけど,そんなことになっていたらデバッグは困難を極める. というか「ちゃんと動いている」ことの判定すら難しい.その「動作試験」にはどれだけ妥当性があるのだろうか.

で,もう何を言いたいかわかると思うけれど,これが「軌道上実績」というやつと非常に,非常に相性が悪いのだ. 気合と根性で宇宙で1回動いてしまったら,もしくは動いたように見えてしまったらもう悲惨である. それはもう軌道上実績である.免罪符の誕生である.なんてことだ.もう助からないぞ!!!

軌道上実績があるということは再利用できるということだ.きっと使い回せる.きっと. 今度は前と少し違ったミッションをしたい.少しなのでそんなに変更点はないはずだ.

じゃあ実装変更しようか~,............どこを!?!?

......みたいなことは容易に想像が付く.

では,そのコンポーネントは丸ごと使い回すみたいな場合だったらいいのか?ソフトウェアに「改修」が「必要ないはず」だったらいいのか?

そんな甘い話は無いということは,我々ソフトウェアエンジニアは「2000年問題」とでも横から囁かれたらハッとするはずである. まあ僕はその年に生まれたんでその時のことは知らないのだけど.

そう,ソフトウェアは腐るのだ.コードの書き方がひどかろうとマトモであろうとだ. 2000年問題みたいないずれ来ると分かっていたものならまだマシだ. 宇宙業界にだってちゃんとそういう話はある. まあ正直あんまり表に出てないだけでたくさんあるだろうと思うのだけど,最も有名な事例はアリアン5初号機というロケットのバグだろう.

www.shippai.org

ja.wikipedia.org

これは 64bit 浮動小数点数から 16bit 整数 へのキャストでオーバーフローして制御装置がハングし,5億ドルが文字通り爆発して吹き飛んだ,「高くついた」バグとして名高い. そして,このシステムはアリアン4の「実績のある」実装を再利用したものだ. アリアン4ロケットは実際とても実績のあるロケットだ. だが,アリアン4では水平方向の加速度がこのキャストに失敗しない程度の範囲に収まっていたことで,このバグは発現してこなかった. ところが,アリアン5では性能が上がり,あら残念,というわけだ.

(これはこれで雑な物言いであることは承知の上で)ソフトウェアの「実績」なんて割とそんなもんである. なぜ,どのように「実績」が打ち立てられてきたのかにこそ意味があるが,「実績」そのものは安心するための言い訳でしかないことは常に頭の片隅に入れておくべきだ.

こういうことは高校生の時から思っているし,弊社と巡り会う前からずっとそういう気持ちがある.

*8

「必ずしも新しい技術がいいとは限らない」とか言ってる人も見たことがあるけれど,そんなの当たり前だ. 当たり前のことを言って何かカッコイイことを言った気にならないでほしい. だったら「古い技術」ってやつだっていいとは限らないに決まってるだろうに. 技術選定をサボるな.

「古い技術」が信頼するに足るとき,その理由はその歴史の長さから well-tested なことが期待できるからだ. 使われ続けてきて,先人が足を踏み抜きまくり,穴が潰されてきたからだ.古いからじゃない. それっぽい言い方が好きなら,「踏み均された」とか言ってもいい.

欲しいのは安心感じゃない.踏み均された有用性・確実性と,高速に踏み均すための仕組みだ.

「宇宙開発」をソフトウェアでやっていくということ

弊社では人工衛星を作っている,とよく言っているけれど,それだけではあまり正確ではない. では何を作っているかというと,人工衛星人工衛星の作り方を作っている,というのが正しい. 人工衛星をたくさん作ろうとしているのだから,一つ一つをゼロからチマチマ作り直していたら単純にやってられない.コストがかかりすぎる. コストが何かと言ったら,原義コストであるところのお金と,上で書いた人間計算量だ.

原義コストについては,上で書いた COTS なブツを使うとか,買っていたコンポーネントを自作するとか,そういうことはできる. できるのでやるけれど,結局のところ大事なのは確立された開発・生産方法と,量産だろう. 目の前でチマチマとした努力をしたところで,10~1000機とかのスケールに対して毎回「一点物」をやっていたら人生が終わってしまう. それこそ大型衛星では数個でも終わってしまうという話は聞く.人生が終わるだけで作れはするとかならそういうタイプの買い物で済むけども.

じゃあ何をやらないといけないかって,人工衛星とかいう面倒な代物を速く・安く作れるやり方・仕組みを作らないといけない. そして,うまいやり方とか仕組みみたいなやつを作るのって,我々の大好物なところなわけだ. そもそもオーダーを下げるみたいな発想がソフトウェア的でもある. 目的がソフトウェア的なんだから,ソフトウェア的にやって何も損は無いだろう.それこそ踏み均された方法論はたくさんある. ちょっと適用先が見慣れないだけだ.開発体制とか,組み込み開発とか,ナイーブには組めないテストだとか.

まあ色々と面倒な対象はあるが,個人的には最近は「開発体験」みたいなものに気持ちがある. この前 id:koba789 に教えてもらったのだけど,英語だと "Developer Enablement" みたいな言葉があるらしい.いい言葉だ. 開発体験をよくする活動は,まさに人間計算量を下げるための一つのアプローチだ.

我々が Rust でやっていくと常々主張しているのだって,開発体験のためによるところが大きい. 組み込みソフトウェア開発ではありがちだけれど,謎の巨大 IDE を苦労してインストールして*9, 謎の何故か不安定な上にシングルスレッドなビルドシステム*10がチマチマと謎のCコンパイラ*11を呼び出していくのをジッ......と待って, ようやくビルドできたものをポチポチして書き込むとか,やってられんのだ. 仕事でそんなことしないといけないものなら労災請求したくなる.いやカネ貰ってもやりたくはないが.

単に手元でやってられんと僕が済むだけならまだマシですらある.自動化できないのだ.CI も組めない. そしてまた,ああいったソフトウェアもソフトウェアが主戦場なわけではない人間が作っていがちなことによって,どうにも挙動もとても不穏ないしは不安定だ. 何をどうしたらあんなことになるのかはよくわからないが,しかし現実としてそうなのだ. 大抵は「枯れた技術」ってやつをちょっとビルドして試してみたいだけなのだけど,それすらままならないこともある. 仮にソースコードは信頼できるとして,あの不安定な開発環境が吐き出したバイナリをどれだけ信頼できるだろうか. 個人的にはとてもじゃないが安心して首を縦には振れない. しかし悲しいことにこういう点は「枯れた」判定をする人の視界の外にありがちだ.

さて,一方の Rust である.

環境構築? rustup を入れよう.組み込みならお好みのターゲット向けに rustup target add も叩いておくといい.

ビルド? git clone して cargo build.それだけだ.

もちろんそれだけにするために中で色々なことをやってはいるのだけど,ありがたいことにそのエコシステムは結構整ってきている.しかも全部オープンソースだ. ボードが違うとか,アーキテクチャが違うとか,そういうのは当然あり得るけれど,何より Rust というエコシステムそれ自体が様々なモノを細かい責務に(半ば偏屈なほどに)分割可能だしする特徴がある. stdcore が分割されてるのなんかも最高だ.そして,これが本当に都合がいい. それこそ別のボードに移植するみたいな話も,そのボード特有の部分の crate を切って開発すればいい.trait があればそれに沿って実装するだけだ. そして実装したものは他の crate と驚くほど簡単かつ確実に接続する. 使う側は Cargo.toml に crate とバージョンを書くだけだ.2023年現在の本当のコードの再利用の姿はこういう形だ. Git submodule?冗談も大概にしてくれ.

とまあ Rust をべた褒めした(安全性とかはみなさん言っているしもはや当然のものなので書かなくてもいいでしょう)けれど, じゃあ一気に全部 Rust で書き直すのかというとそういうわけでもない. 別に Rust が向いていないケースだってたまにあるし,なにより C/C++ で書かれた本当に有用な(踏み均された)資産が世界に満ちているのはみなさんご存知だろう. そもそも普通に Rust でアプリケーションを書いてもみなさん glibc のお世話になっている. で,Rust ってやつは C/C++ の資産を適切な形で再利用するのにも超便利なんだな,みたいな真面目な話はいくらなんでも長くなってきたので別のところで書こう.

とまあ,本当に長々と書いたが,最近はこういうかんじだ(どういう?). なんでこんなポエムで2万字(今見たら倍になってた.なんで?)とか書いてるんだろうな.

ポエムだし,ピチピチの大学一年生(2回目)なので,恥ずかしいことでも言って締めということにする.

結局のところ,やっていくぜということだ.準備は結構整ってきた.やっていこう.

*1:まあ,ChatGPT みたいなやつにレビューされるようになった時にムカつかないかというとちょっと怪しいが

*2:空気がほぼ無いところで動くので空冷とかしてなくてギチギチというのはある.

*3:仲間内で"文化祭病"と呼んでいる.

*4:ちなみにこれはカーマン・ラインというやつだ.雑に地上と書いたけど,正確には海抜高度から 100km としている.とはいえ,そのキリのいい数字から分かるように,これは「まあそんくらいでいいよね」という値である.なんなら「80km にしてもいいんじゃね?」みたいな話もあったらしい.実際アメリカの軍とかは50海里とか 80km とかの値を使っていることもある.

*5:一回こういうの書いてみたかった

*6:アポロ計画の時代であれば,あれは載せる側のためにロケットを作っていたし,少しでも切り詰めようとしていたので数kgとか減らせたらパーティーものだったみたいな話もあるけれど,現代ではロケットもできるだけ同じ設計で同じものを作るし,そこまでの切り詰めは基本的にやっていないので,そのぐらいの余裕はある.なくても余裕があるやつを使えばいいのだ.実はロケットってやつは日々たくさん打ち上がっている.

*7:まあそれも事前に誰かが相当苦しんだ結果としてのものだろうし,その場合でも命名を見直すとかより気合で覚えるみたいなかんじになりがちである

*8:まあこれは大学1年生(1回目)のときのツイートだが,この前から思っているし,「宇宙」で「ソフトウェア」をやりたいと言い続けてきた理由の一つだ

*9:たまによくインストーラも本体の IDE も機嫌を損ねてダンマリしがち

*10:実は GNU Make を呼び出していた,とかならだいぶマシなのだけど,なんかよくわからないやつもたまにありがち

*11:GCC 4 系の fork ならまだマシだが,なんかそうでないやつもあるし,そうだったとしても本当に謎のパッチが当たっていて gcc なのにも関わらず動作が不安定になっている,みたいなことすらある.GPL にありがとうと叫びながらソースコードは見られるが,果たしてビルドできるかは見物だ

2022年振り返り

お久しぶりです.sksatです.1年の振り返りブログになりつつあってよくないですね. 書けることというか書くことというか書きたいことはたくさんあるので,ちゃんとアウトプットしていきたいですね.,ああそれは来年の抱負ということでお願いします.

という前置きだけして月ごとにセクションを切って書き始めたんですが,いつもの癖でブログを Togetter にしてしまっていました.まあいいか.

1月

ほぼ1年前,何してたかな......と思ったんですが,この頃はsksat_install_battleが佳境も佳境でした. なんだかんだでまだsksat_install_battleのことをちゃんと公開していないのでなんのこっちゃというかんじですが.

sksat_install_battleは簡単に言うと僕の退学・実家脱出・入学という一連の計画のことです. オタクの悪ノリとライフハック/八苦を煮詰めたようなやつですが,(特に家庭環境が微妙になってしまった状況から)新生活を開始するためのテクが詰まってたり詰まってなかったりするので,公開する予定です. と言ったまま2022年が終わりつつあるんですが.あとでちゃんと公開します.ほんとですって.

まずはなんといっても(???)ageHaですね.クラブイベントというかなんてものはそれまで一度も行ったことがなかったんですが,デカい音には興味があったのでオタクに誘われるまま『俺たちなりのageHa』に行きました. www.ageha.com

これが本当によかったんですよね.この月にageHa無くなっちゃいましたが. だからこそのあの熱量とかもあったんだとは思いますけどね.

とはいえあのフィナーレがクラブイベントの原風景になっちゃったのはどうしてくれんねんオイという気持ちもあります.どうしてくれんねん.

ということで無事その後たまにクラブイベントに行くオタクとなりましたとさ. デカい音は好きなのに知ってる音楽のレパートリーが少なすぎるという問題が根深いので,これは2023年どうにかしていきたいかもしれないですね.

さて,なんでsksat_install_battleの話をして即全然関係なさそうなageHaの話をしたかというと,実はこれの後にそのままつくばまで行って新居の入居手続きをしたからです. 新居の原風景は何もない床の上に置かれた ageHa のペットボトルです.

新居が生えたので,ここから物体の輸送が本格的に開始しました. なぜ"本格的に"というprefixが付くかというと,これの前から登山用のザックに荷物を詰め込んで持っていって友人宅に放り投げて帰る,みたいなことをしていたからです. https://user-images.githubusercontent.com/23310673/143662919-1a9cb486-3449-4940-8330-b41d4bb0c65b.jpg

あと,この頃はまだ所属はインターンでしたが,ArkEdge がめっちゃ資金調達してました.すごいですね(他人事). www.nikkei.com

2月

オタクに誘われて『地球外少年少女』を観ました.『電脳コイル』が好きなのもあって作品そのものがとても楽しめたのは言わずもがなですが, 「2022年の宇宙モノのSFアニメには Starship が出てくるのだなあ」という感想を抱いた覚えがあります.

あと,この頃は本格的に新居の整備をしていましたね.実家からこっそり(しかし大量の荷物を持って)新居に行っては,荷物を放出して新居整備をして帰る,ということを繰り返していました. 良くも悪くも新居の整備をするのには時間をかけられたので,全体的にはじっくりと自分の生活空間を設計して 0 → 1 をすることができたのはよかったし,おもしろかったです. その代わり,初期は床にマットで寝て,折りたたみ机にショボい計算機とディスプレイ1枚とテザリングで生活してましたけどね.あれは人生に一度でいいかな.

3月

Tundra Tracker

実家を出ました.出ていったという方が適切ですね.

南朝というのは sksat_instal_battle の隠語なんですが,結局まだ公開していないのでなにも伝わりませんね. リポジトリを公開したら隠語集を見てください.怪しいCSVファイルがcommitされています. 南朝が実家で北朝が新居です.書いてもなんもわからんな.

実家を出ていった理由については,書くとしてもそれはsksat_install_battleを公開する時でしょうし,別に同情を求めているわけでもないのでここでどうこう言うようなことはしません. まあ当然色々と思うところあってのものなので,どこかで愚痴を言うことぐらいはありますが.

ひとつどうでもいい話としては,KickstarterでバックしていたTundra Trackerが届いたのがこの直前で,脱出前に間に合うのか,それとも住所変更できないものか,ということであたふたしたりしていました.

これの出来が本当によくて,この後 VIVE Tracker 2.0 をほとんど使っていないですね.そう書くとちょっともったいないかも.

その後,退学しました.ふざけて雑なリングを退学届に置いた画像をツイートしたら Twitter の通知が壊れた.人間は愚か.

退学という選択もまあ例によって色々と思うところあってのことなので,深くは書きません. 退学しといてなんですが,いい環境だったと思います.活かし切れなくてすみませんね.

4月

なんか退学処理が詰まってて4月4日付けの在学証明書が発行できました.嘘つけ.

そして,入学しました.人々の退学への心配を返せ.

まあでも入学なんですよね.編入学ではなく.これが何を意味するかというと,僕は学部1年生だということです. あれれ~おっかしいぞ~~~???去年は学部3年生じゃなかったっけ~~~???

ということで,学年がデクリメントしたのでした.ちゃんちゃん. ちなみに例によって学力試験は受けていなくて(仕事もしてたんでね),まあその......アレをもう一度受けたということです. 面接では「......2回目だよね?」と言われました.はいそうです.なぜ通した?

ちなみに,編入学でなかろうと編入のみなさんがよくやっている「単位認定」という技が使えたので,多少イージーモードからのスタートとすることはできました. (学費・生活費を自分で稼ぐという意味も含めて)仕事しながらなのでこれはありがたかったです.これが社会人学部生ってやつですか.

そんでもって,そんなコーナーケースは当然考慮されていないので手続き関係はちょっと困ったりしました.手続き苦手すぎる.

こうしてなんとか入学したのはよかったんですが,大学生をやりながら社会人風のことをするのは思ったより大変でした. 正確には働きながら大学生をやるのは,かもしれないですが. 何が難しいって,労働はいつ何時であろうと(注: いつ何時もではない)出勤ボタンを押して問題を解決したり掘り起こしたり作ったりすればいいんですが, 講義ってやつは毎週決まった時間にクソデカミーティングが刺さっているようなものなんですよね.難しくないですか?いや,普通はそんなに難しくないのかもしれないですが.

と思ったので,「労働のような体験で学生をやる」という変な団体を作りました.

今は過疎っています.だめじゃん. そしてこれを書いていて思い出したんですが,「学生になるボタン」を作るのを忘れていたので今度作ろうと思います. 「学生になるボタン」というのは出勤ボタンの学生バージョンのことです.

あと,この頃オタクから HiFive Unmatched を引き取りました.これをネタにして,教授とキャイキャイしながらものづくりができるタイプの実験をやろうと思っていたんですが, 話だけして手続きを完全に忘れていたので,教授に HiFive Unmatched を見せびらかしただけのオタクになりました.

5月

オタクにそそのかされて,3Dプリンタ(Ender3)を買いました.まあ元から欲しかったからね.

オタクにそそのかされて(2),中華鍋を合羽橋で買いました.そそのかされすぎでは?

たまにチャーハンを作る時にだけ活躍しています.

シェイカーも買いました.これはたまにカルピスを攪拌するのに活躍しています.

特にそそのかされたわけではないんですが,うっかり RTX3090 を買いました.ついでにCPUとかマザボとかSSDも付いてきました.べんりですね.

あと,急に id:cra2ypierr0t に呼びつけられて奈良に行ったりしました.マジで何言ってんのかと思ったけど(全然いいけどさ).

実はこれは急におかしくなって奈良に行ったのではなくて,NAISTオープンキャンパスに行ったのでした. 元々興味はあったんですけどやっぱりおもしろいところでよかったですね.まあ僕は学部生の学年すらデクリメントしたんですが.

あと(2),CLUB CITTA' でやっていた "Vの宴2022"に行きました.オタクがたくさんいてよかったです.

『新衣装』が本当に好きなので置いておきます. youtu.be てれかすさんへ: 諸々の情勢もありますが,teleka.su はもうちょっと安泰です.

あと(3),深夜にオタクと突発的に大洗に行きました.

行ったのはいいし,実際よかったけど,当然朝早くには飯屋は一切やっていませんでした.惨めな気持ちで帰り道でなんともいえないラーメンを食べました.

6月

ラックサーバをお迎えしました.

お迎えしたというか,正確には後先考えずにヤフオクで落札した id:cra2ypierr0t から引き取りました.そうはならんやろ.

まあ僕は元から欲しかったんでいいんですけどね!!!

その後コイツは cra2ymanai7a と名付けられ,自宅の洗濯機置き場に建立したメタルラックの中で元気に動いています.え?洗濯機?なんですかそれは.

こんなかんじで(?)我が家には曖昧に電子機器が増えるので,気が付いたら電気代が結構な額になっていました. 結構な額というか,ほぼ常に単調増加してたんですよね.

ではこの問題とどう向き合うべきか.計算機を無闇矢鱈に増やさない?それは根本的な解決策ではありません.増えるし. 何より,本当に曖昧に計算機を増やしているのが支配的な要因とは限りません.常にめちゃめちゃ負荷がかかっているわけでもないですし.

ということで,まずは計測です.正しい評価は正しい計測から. そのために,ワットチェッカーなる物体を買いました.具体的には RS-BTWATTCH2 www.ratocsystems.com

これの利点はなんといっても無線(Bluetooth)でデータを収集できることと,ハック実績があることです.

ruby-btwattch2にはお世話になりました. github.com

その後,データ収集クライアントをRustで書き直し,データはInfluxDBに発射するようにしました.

github.com

今は大統一 Grafana を整備したのでそこに突っ込んでいます.

7月

友人にリアルで誕生日を祝ってもらうという得がたい体験をしました.本当にありがとうございます.skastさんは結局どなただったんですかね.

骨伝導イヤホンのAfterShokz OpenComm を買いました.これの前から Aeropex は持っていたんですが,会議用途にはこっちの方が断然便利ですね. ここ数ヶ月は OpenComm の方しか使ってないかも.

近所の寿司屋に始めて行きました.色々とおかしい.

id:totsugekitai と突発的に犬吠埼に行きました.この時は常識的な時間に行ったので,5月の大洗のリベンジができてよかったです.

あと,炊飯器を買いました.なんとコメが炊けてべんりです.

8月

実は正式にはこのタイミングでArkEdge Space Inc. の正社員になりました. この前からなんだかんだでめちゃめちゃ働いていたので,特段これによって働き方自体にはそんなに変化はありませんでしたが,社会保険が本当にありがたいですね.

そして,字面上のタイミング的には入社即というかんじですが,始めての海外出張に行きました. ちなみに,"初めての海外出張" は "始めての海外"*1 + "出張" です.出張はもうしてたしね(?).

で,なにしに行ったかというと,アメリカのユタ州で開催された Small Satellite Conference 2022 という世界最大の小型人工衛星に関する学会に行きました(通称SSC).

smallsat.org

なんというか,文字通り世界の広さを知ることができてよかったです. あと単にアメリカの風景は全部がデカい.

ちなみにこれは特に関係の無い保安検査通ったときに便利な画像.

少しふざけたので少し真面目なことを書いておくと,あの場は本当に小型衛星に関する技術的な動向の最前線が露出しているので, 僕みたいな最年少のペーペーも含め,エンジニアを中心にそこそこの人数を連れて行ってもらえたのは本当にありがたかったです. 僕個人は(今後への期待込みで)若いので雰囲気を知っておいてほしい + SSCという場を(宇宙のドメイン知識もありつつ)ソフトウェアエンジニアの視点で見てきてほしい,という意図で連れて行ってもらったと理解しているんですが, 拙いながらも多少は期待に答えられたんじゃないかと自負しているつもりです.英語は頑張りたいですが......

SSC のおもしろかった点は,学会とは言いつつも「アカデミック」な雰囲気はあまりなかったことです. もちろん無いということはないんですが,軌道上実証したかどうかが(特に発表とかに)採択される要件になっていそうなのと,企業の出展がとても多かったことで,とても「エンジニアリング」な場だなと思いました. そして,エンジニアリングな場であるこそ,そこにいる彼らがどのような問題意識を持ち,どのような技術スタックで,どのように問題と向き合っているかを観察することが肝要です.

例えば,ある会社は我々がよく知る AMD の CPU(Ryzen) と GPU(Radeon) を衛星上でのエッジコンピューティング用途で使えるようにしようとしていました. そこで技術的な話を聞いてみると,「Linux 5.18 で Radeon 向けの CRIU のサポートが入ったから,これで衛星間で GPU task を送信できたりするかもしれなくない?」みたいなことを言っていて, 低レイヤに気持ちのあるソフトウェアエンジニアとしての僕は「あ,これ本気な上にめっちゃ手動かしてんのか......」とか思ったわけですが,当然宇宙だけやってきた人からしたら何言ってるかわからんわけです. 当然それが悪いわけではないですけれど,何言ってるかわからんなというままで放置していたら,気が付いた時には喰い尽くされて終わりです.

もちろんこれは敢えて極端な例を挙げていて,実際には結局放射線耐性どうなんですかとか,消費電力どうなのよみたいな問題はあります.とてもある. しかし,しかしですよ.デカい問題があるからといって問題そのものから目を背けることはよくないです. よくないだけならいいですが,確実にあとで足を掬われます.賭けてもいいです(何に?). そして,「枯れた技術」とかいう言葉はよく単に問題から目を背けるためだけに使われがちだ,という愚痴を曖昧に置いておきます. ちゃんと枯れてるかも確認しましたか?

それはそれとして,KSP に FSW を接続するネタは完全に同じことを考えていたので,既にやられていたのはちょっと悔しかったですね.

これは帰る直前に見た SpaceX 本社前に雑に転がってる Falcon9 のブースター.ちなみにデカい.

あと,なんか PC98 が生えました.なんで?

9月

2台目の3Dプリンタ(KP3S)が生えました.実は最近はもっぱらこっちしか動いていません.

なぜか深夜テンションで北海道旅行に行きました.魚が喰いたかったんです.

何があるのかろくに知らずに洞爺湖にも行ったんですが,かなり体験がよかったです. 次行く時は昭和新山リベンジもしたいですね.

あと,西はりま天文台に定期的に襲来する謎の団体に入れてもらい,西はりま天文台に行ってきました. 天文台自体は高校生の頃に部活の合宿という名目で行ったことがあったんですが,その時はスケジュール的に昼のみだったので,ちゃんと夜に星を見ることができたのはとてもよかったです.晴れてたし.

ついでに中間にある京都を観光したりもしました.これもよかった.

京都鉄道博物館もとてもよかったです.正しく金のかかった博物館というかんじでした.

帰る前に大阪にある国立民俗学博物館に行こうとしてギリギリ時間が無くて諦めたんですが,それで空いた時間で太陽の塔とその中を見られたのもよかったです. 実は結構岡本太郎好き.

帰りに赤福を買っていったのでめちゃめちゃ使い古されたコピペを使ったら Twitter の通知が壊れました.人間は愚か.

10月

なんやかんやあり,複数条件下で焙煎されたコーヒーの味を評価するオタクの実験に被験者側として参加したりしていました. 定性的評価なんもわからん.マジで.

同僚であるところの id:koba789Starlink をポチッていたので,「動いてんなー」「普通にインターネットだなー」,と言う会をしました. 普通に動いてしまうモノを作りたいもんですね.

オタクにそそのかされて ヤフオクONKYO の BASE-V50 を買いました.音がデカくなったりよくなったりすると,よい.

11月

AmazonBlack Friday Saleで4Kモニタを買いました. これは元々持っていたやつとほぼ同型のもので,これで4Kモニタ2枚体制ができました.やったあ.

なんとなく安い望遠鏡を買いました.

せっかく有明にオフィスがあるので,市場近くにある寿司屋に行ってみました. 「うまい寿司」に対する概念が書き換わりましたね.

川崎チネチッタの100周年記念で上映していた『2001年宇宙の旅』を観ました. ずっと劇場で観てみたい,なんで僕はこれを劇場で観ることができなかったんだ(当然),と思っていたので,劇場で観ることができて本当によかったです. 劇場で観るべき.

この日はついでに目黒寄生虫館にも行きました.

コスパのいい経緯台と噂のAZ-GTiを買いました.

買った望遠鏡で月食がいいかんじに見えてよかったです.流石に天王星はあんまりよくわかりませんでしたが.

特に僕自身が関係あるわけではないんですが,この頃は Artemis-1 が本当に打ち上がって本当にびっくりしました.飛べたんですねあれ.

アバターを作り直しました.例によって見た目というか構成はほぼ同じですが.

と思っていたんですが,流石にこの季節にこの恰好では寒そうなので,厚着させました.思ったよりなんというかオタクになってしまった.

あと,僕が入社してからは始めて弊社の人工衛星が宇宙に上がりました. まだ ISS の中にいて,放出・実運用はもうちょい後ですけどね. arkedgespace.com

12月

今ですね.なにしたっけな.まあ続けて曖昧に書いていきます.疲れて曖昧になってるな.

ComSys2022 に行きました.畏まった k/vm というかんじでよかったです.2日目絶起した上に体力切れして行けなかったけど. www.ipsj.or.jp

経緯台の接続パーツが手に入ったので雑に使ってみました.雑なスマホM42 が撮れるのかなり体験いいです.

アニメ『ぼっち・ざ・ろっく!』が終わりました.実は逆張りして観ていなくて途中から観はじめたんですが(カスオタク仕草),いや本当によかったです.アルバム買いました. 『忘れてやらない』がとても好きです. youtu.be

近所のおかしい寿司屋で大盛を頼んでみました.酢飯で命の危機を感じました.

カメラのセンサ部分だけみたいなやつを買いました.まだ使えてないです.

pi4が実在したのでつい買ってしまいました.まあ普通にずっと欲しかったのでよし.

おわり

曖昧な Togetter であろうと,久しぶりにブログを書くと疲れますね.いや Togetter 方式は特に疲れるみたいなところはあるんですけど.じゃあなんでやったんだ.

というのはさておき,まあ色々あった1年でした.まあ今まで生きてきた中で一番色々あった1年を去年に引き続き更新といったところですね. まあ退学脱出入学してますしね.流石に来年はこれは越えないとは思います.たぶん.

よく考えたら来年の抱負とか書いた方がいいやつですねこれ. 最近とても思うのは体力が欲しいということですかね.エコノミー症候群万歳みたいな生活してる/たのでちょっとどうにかしないとまずいです. 特に「大学生」をやる日は大学行って帰ってきたらもう疲れててなんもできませ~んみたいなことがありがちです.これは生活時間帯がズレてる問題もありますが. ということで2023年は体力を付けていきたいと思います.引き続きやることは個人的にも多いし,会社でのやっていきとしても多いのでね.特に来年は「衛星運用」ってやつとも向き合っていこうと思います. ではでは.

*1:本当は完全に始めてではないが,ほぼ記憶が無いので主観的には始めて

2021年振り返り

お久しぶりです.気が向いたので振り返るやつやります.

今年は個人的にだいぶ濃い1年でした.

大学

Twitterではゴチャゴチャ言ってましたが,去年留年したので学部2年生をおかわりしていました.ざんねん! 今年の話ではないですがこれも振り返っておきます.

原因は言語単位なんですが,1限起きられなかったからとかでは全然なく,履修申告失敗です.これが履修深刻ってワケ.

でもこれ僕の責任多く見積もっても6割くらいだと思うんですよね. いやまあ履修選抜とかいうやつ考え始めるのが少し遅かった(全然間に合ってはいる)のは僕の責任ですが,

  • 言語だけ履修選抜が分離していてクソ分かりにくい
  • SFC-SFSが大爆発して一生シラバスが見られなかった
  • ようやく履修成功したと思ったら第1回講義の後講師から「実は君はこの講義履修できないっぽい」ってSlackで言われて履修不許可になる
  • 履修不許可になった単位も履修上限にはカウントされるので進級を諦めたところでろくに講義履修できない

のは僕というよりはシステムが悪いでしょう. 1つ目については何度かやってんだから覚えんかいと言われればそうだし,あとは早めにやっておけば結果的に防げた事態ではあるので真人間に指摘されたらそれまでなんですが. あと,最後の履修不許可のカス挙動は他学部の講義でもめちゃくちゃ発生したので個人的な恨みが強いです.

なんだかんだ書きましたが,その後素直にチョロい英語*1を受け,学部2年生は1.5年で済みました.なので今年の後半からちゃんと(?)学部3年生です.よろしくおねがいします.

それはそれとして最近は結構クネクネしてます.すみません.

労働

今年は色々とマトモに労働ってやつをやりました.まあ例によっておもしろ労働しかしていないのですが.

Tier IV

まず,ろくに言及していなかったんですが5月からTier IVでパートタイムエンジニアとして働いていました. tier4.jp

Tier IVは元々存在は知っていたんですが,パートタイム募集のツイートをしていたので何気なく見に行ったらRustみたいな文字列が見えたので非常に曖昧に申し込みました. なんなら応募理由に「Rustって書いてあったから...」みたいな舐めたことを書いた覚えがあります.

最も難しかったのは履歴書の生成でした.アレ難しいですね. 例によってWordみたいなやつを使う気は微塵も無かったのでkaito256先生のyaml_cvをありがたく使わせて頂きました.

github.com

ちなみに,このyaml_cvはかなり気合で履歴書という物体を生成していて,実態としてはstyle.txtでひたすら線と文字列の位置とサイズを指定しています.ヤバい. そして,標準のstyle.txtはオタクが雑に会社に応募する用途としてはちょっと欄が多いので,適度に削って調整したstyle.txtを置いておきます.

オタク向け yaml_cvのstyle.txt · GitHub

で,まだ応募の話しかしてないんですが,初回の面接で低レイヤオタクとして目を付けられたっぽくていきなりおもしろ低レイヤ労働をたくさん紹介されておもしろかったです. 最終的にはおもしろ独自アクセラレータのコンパイラ自作関連のことをやっていました. めちゃくちゃバイナリとLLVMと戯れることができてとても楽しかったです.

ちなみに色々と過去形になっているのは,今ちょっと色々あって忙しいのと,後述するように別の会社でかなり働いているのもあって一旦中断させてもらっているからです. とてもおもしろくはあるので,色々落ち着いたら配分考えつつ再開したいですね. アクセラレータとかコンパイラ話に興味がある低レイヤオタクは気軽に申し込んでみるといいんじゃないでしょうか.

ArkEdge Space

はい.以前ブログ書いたやつです.

sksat.hatenablog.com

この記事でも書きましたが,「"枯れた技術"に強く依存した宇宙開発に新しいソフトウェア技術で殴り込んでいく」という,本当にずっとやりたいと思っていたことそのものができていて本当に楽しいです. 単に宇宙関係のことをやりたい,というアバウトなところであれば幼少期からの夢ですし,ソフトウェアという具体的な方向性を含めても5,6年来の夢だったんですよね. そもそも宇宙関係のところに進むのか,という点も含めて身の振り方を色々考えていたため,意外と早く叶いつつあってその意味ではとても拍子抜けしています.やっていきたいですね.

ベンチャーということもあり,様々なインフラを整えるようなことも色々とやっているんですが, 今年かなりインフラへの気持ちが出てきていたところだったのもあって,直接宇宙に関わらない部分も非常に楽しめています. フットワーク軽くて働きやすいですしね.

あと,最近だと会社の発生元である東大中須賀・船瀬研の諸々のソフトウェアがOSSになりつつあり,その手伝いや改善なども行っています.

github.com

ArkEdgeのソフトウェアも近いうちに色々オープンにしていきたいですね.ご期待ください.

VRChat

去年後半あたりから色々とぐちゃぐちゃになっていたり,なんか去年末にkuso.domainsとかやってたのもあって年の初めの方はめちゃくちゃやっていました. kuso.domains

まあ1/1にフルトラになったしね.いやその後も全然地面這ってましたが.

kuso.domainsというと,kuso-subdomain-adderとかいうものを作ってしまったために,インフラ周りに興味を持ってしまいその後も色々ありました. VRChatの話じゃないなこれ.

github.com

あと,最近アバターの髪型を弄りました.本人の髪は乱雑に1年以上伸び散らかしてるのにねえ. 例によって雑な改変なんですが,パッと見いいかんじだし結構評価もいいので満足してしまっています. Unityとかいう機序の読めないソフトウェアの起動時間を1秒でも短くしたいというどうしようもない感情がある.

ちなみにアバターは全部いつものArch Linux環境からアップロードしています.なのでこんなAURパッケージを生やしました.

aur.archlinux.org

なんかこのパッケージ,意外と使われているらしくてたまーに海外VRChatterからメールでおたよりが来る(N=2)んですが,僕は(大して弄っていない)アバターしか上げてないし, そもそもLinux版のUnity Editorの挙動怪しいこともあるみたいな話もあるので,「ワールド作って上げようと思ったらうまくいかんのだが」と言われてもちょっと困りますね......

GitHub

なんかめちゃくちゃGitHub使うようになりました.去年もだいぶGitHub使うようになったな,と思ったような気がしますが, 今年は確実に自分の中で無くてはならないインフラになりましたね.ベンダーロックインともいう. GitHubが障害起こすとTwitterよりも困ると思うようになった気がします.

ずっとsk2satで甘んじていたIDをついにsksatにできたのはかなり大きいですね.本当にうれしい.

そして,なんかやたらとすべてをGitHubで管理するマイクラサーバこと[mc.yohane.su[(https://github.com/sksat/mc.yohane.su)みたいなことをやっていました. github.com sksat.hatenablog.com

mc.yohane.suについてはこのスライドでも見てください. speakerdeck.com

そんなこんなあったものの,Issue/PRへの心理的ハードルが下がったのはとてもよかったです.なんならついさっきもムッこれ無いやんけとなったので1発PRを投げました(即マージされてウケた*2 ). 最近は労働もGitHubベースになってきたので,その意味でも良かったと思います.

あと,GitHub Actionsを本当にめちゃくちゃ使うようになりました.CIという概念がめちゃくちゃ好きだということに気付けたのはよかったです. papermc-dockerみたいな禍々しい物体を組んでしまったりもしていますが. github.com

ふと欲しくなったActionもちょいちょい作っているので,よかったら使ってあげてください(なんかニッチなやつが多いですが). github.com

あと,コンテナもかなり好きなので,GitHub Container Registryくんも大好きです.挙動が変わってスクリプトが一気にブチ壊れてキレたりするぐらいには.あとpapermc-dockerもタグの数がヤバいことになってる. github.com

その他

ここで書くべきかわからないですがRustってやつは本当にいい言語ですね.ちょうどマトモに触り初めてから1年くらいですが,変に逆張りせずにもうちょい早めに触っておくべきだったと思います.

あと,おそらく僕が始めて尊敬した人物である野口聡一宇宙飛行士が日本人として始めてCrew Dragonで宇宙に行っていて本当によかったです*3. 大幅に制限解除されて久しぶりに宇宙飛行士募集も開始されましたし,日本の有人宇宙開発ってやつにもがんばってほしいですねえ. Space Xってやつもあの調子でがんばってもらいたいですね.界隈に圧をかけ続けてほしい.

余談

そういえば,今年の元旦に気合を入れた感情に決着がつきました

*1:これは余談なんですが,そもそも言語単位が足りなくなりがちだったのは入学初手で英語ちゃんとやるかと思って進級にカウントされない入門編みたいなやつを受講したからなのに,それ以降のレベルの英語が最初のやつよりぜんぶカスなのは一体全体どういうことなんですかね...?

*2:https://github.com/itamae-kitchen/mitamae/pull/115

*3:かなり偉いポジに納まっていてもう飛ばないのかなとうっすら思っていました

最近は人工衛星作ってます(ブログタイトル回収)

こんにちは.最近元気になってきてツイート数が減っているsksatです. 最近労働ってやつがおもしろいのでその話をします.

おもしろ労働というと実は5月ぐらいからTierIVという会社でLLVMをいじくり回していていてとてもおもしろいです. が,今日は8月からバイトしてるもう一つの会社の話をします.

ArkEdge Space

ということで社ですが,ここです.

ArkEdge Space Inc.

はい.ずっとやりたいと思っていた本物の宇宙開発です.やったぜ.

具体的にどういう会社かというと,東大中須賀研発の超小型人工衛星のスタートアップです. 本当にまだ人の少ない会社ですが,かなり強い人材が揃っていますし,実際既に衛星も受注してます.

経緯

最近色々と仲良くしてもらってるKOBA789さんがオファーを受けるタイミングに何故かついてきた謎のオタクをやり, めちゃくちゃ興味あるんですが...→おk,みたいなかんじで入りました.そんなことある?

ということでKOBAさんの転職エントリもどうぞ. diary.hatenablog.jp

やっていること

僕の将来の目標はかなり前から「"枯れた技術"に強く依存した宇宙開発に新しいソフトウェア技術で殴り込んでいく」だったりします. そして,この会社は僕のこの目標とかなり方向性が近く,実際そういうことをやらせて貰っていますし,やっていくと思います.

具体的にはKOBAさんが言及しているようなRust製のフライトソフトウェア開発や, フライトソフトウェアの動作を含めて再現するシミュレータの開発といったことに取り組んでいます. もちろんやることは山積みですが,何十年くらいでやっていけるかな,と思っていたこの目標は自分の想像よりもかなり早く達成できそうです.

感想とか

とりあえず1ヶ月ぐらい働いてみた感想としては,マジで楽しいです. 大学が始まったら働ける時間が減っちゃうな,と思ってしまうぐらいには楽しい. 今までの個人的な(なんだかんだ稀有な)経験がかなり役に立っているのもかなりポイント高いです. 自分の関わったものが文字通り軌道に乗るのが待ち遠しいですね.

ということでWe are hiringというかんじなので,気になる人はぜひ. でもまずは僕が正社員になりたいですね(?)

マイクラサーバをGitHubで運用する

こんちわ〜.珍しく1ヶ月という短期間でブログ記事を書くsksatです. 今回はここ数ヶ月運用しているマインクラフトサーバについて書きます.

Minecraft

みなさんマイクラやってますか?僕はそんなにやってないです.運用するのはまあまあおもしろい.

とはいえそんなにやってないわけでもなくて,5月頃はけっこうやっていて,空中から海をブチ抜いて地中まで刺さっている畑などがあります. まあかなりのcontribution(?)は他のオタク各位ですけどね.

で,このマイクラサーバなんですが,以下のようなかんじで運用しています.

  • サーバ: PaperMC 1.17.1
  • モード: サバイバル
  • Mod/Plugin: 基本バニラ.使ってるものは以下.
    • PrometheusExporter
    • DiscordSRV
    • CoreProtect
  • ユーザ管理: ホワイトリストGitHub repoへのPull Requestで追加

GitHubでのマインクラフト運用

というわけで本題ですが,このサーバはGitHubを使って運用しています.

github.com

どういうことだよ,となると思うんですが,見ればわかる. このサーバはdocker-composeを使って運用していて,このリポジトリにはマイクラサーバをデプロイするためのスクリプト群がある,ということです.かんたんだね.

じゃあこのリポジトリをcloneしてきて,docker-compose upすればマイクラサーバが立ち上がってうれしい,ということかと思うじゃないですか. それは半分正解です.しかしそれだけではありません.

正確には,このリポジトリは常にmainブランチが本番環境に同期されるようになっています.

そしてよく見てほしいのですが,このリポジトリにはdata/whitelist.jsonがあります. そしてこのサーバに参加しているオタクが登録されています. 極めつけはREADMEの一番下.

how to join

Edit whitelist.json and send a pull request

はい.GitHubで運用するということは,つまりそういうことです.

なので,このマイクラサーバに参加したい人がいる時,僕はサーバにSSHしてwhitelist.jsonを書き換える必要はまったくありません. 必要なのは,「あ,じゃあmc.yohane.suのREADME読んでプルリク送ってね」の一言と,マージボタンを押すことだけです.

CD(Continuous Deployment)

みなさんマイクラサーバ運用でCDしてますか?僕はしてる.

mainブランチが本番環境に同期されるというのはこれの話です.

CD,したいですよね.でもこれdocker-composeなんですよね. CDするための良さげなツールとかないんですよ(あったら教えてほしい). Kubernetes使ってたらArgoCDでポン,みたいなかんじでいいんですけどね. というかできるならそのうちそっちに移行したい.

じゃあどうしてるのかというと,雑なスクリプトを書きました. 「docker-composeでもCDをしたい!」ということで,その名もcompose-cd

github.com

これはmc.yohahe.suのためではなく,kuso-subdomain-adderというものの運用自動化のために書いたスクリプトなんですが,けっこう便利なので最近はよく使ってます.

kuso-subdomain-adderteleka.suというクソドメインサブドメインを生やすためだけのWebサービス(?)です. ここらへんの話はVRC-LT #9でやりました.

speakerdeck.com

というのはさておき,compose-cdの話に戻りますが,使い方は超簡単. 各リポジトリdocker-compose.ymlがあるディレクトリに.compose-cdという設定ファイルを置くだけです.

compose-cdでは,docker-composeなプロジェクトで使うために,デプロイが走るタイミングとしてリポジトリ自体が更新される場合と,リポジトリで使っているイメージが更新される場合を想定しています.

リポジトリが更新される場合というのは,リポジトリでコンテナからマウントされるような設定ファイル(マイクラであればwhitelist.json)を管理していて,それが更新される場合です.

次にイメージの更新ですが,これは新しいバージョンのイメージが出たら更新する,という話ではありません. CDなんてことをする以上,ある時点でのリポジトリからはそのリポジトリ内で設定されているバージョンのモノがデプロイされるべきです. 更新してupstreamのリポジトリも更新するようにすればよいかもしれませんが,それは管理のしやすさ的にもセキュリティ的にもよくないでしょう.

端的に言うと,compose-cdの責任範囲はupstreamのリポジトリとイメージの更新を確認し,更新があればデプロイを実行する,ということまでだということです. ただし,latestのようなイメージタグを使っている場合は例外です. まあlatestなんて基本的に使うべきではないわけですが,別にプロダクションではなく趣味なので雑に使いたい時もありますよね. 最近は後述するRenovateのおかげでほぼないけども...

これらの2つの場合に対応するため,.compose-cdでは基本的にリポジトリ,イメージ,イメージタグを指定します. 例えば,kuso-subdomain-adderではこんなかんじ.ghcr.ioにも対応しています.

REPO="https://github.com/sksat/kuso-subdomain-adder"
REGISTRY="ghcr.io"
IMAGE="sksat/kuso-subdomain-adder"
IMG_TAG=master

compose-cdがやっていることはめちゃくちゃ単純です. 実際実装も300行程度のBashスクリプトとsystemd timerです.

compose-cd.timerがsystemd timerの設定で,毎分compose-cd.serviceを呼び出すだけです. compose-cd.serviceはcompose-cd updateを呼び出すだけです. compose-cd updateでは,SEARCH_ROOT以下のディレクトリで.compose-cdがあるディレクトリを探索し,.compose-cdにある設定に従ってリポジトリとイメージの更新を確認し,更新があればgit pullないしdocker-compose pullをして再起動(docker-compose down, docker-compose up -d)します.

まあ超単純なんでそんなに書くことはないですね. ghcr.ioだとうまくいくのにDockerHubだとうまくいかなかったりとか, うまくいっていたghcr.ioが突然動かなくなったりしたのは面白かったですが*1

github.com

ところで,今これを書いていてイメージだけの更新を使う場合に複数イメージ使うことを一切想定してないな,という気付きがあったので気が向いたら実装します. とはいってもそんな場合は自分で使っている分にはほぼないので別に要らないかな...ちゃんとdocker-compose.ymlでハッシュまで指定してくれ.

CI(Continuous Integration)

みなさんマイクラサーバ運用でCIしてますか?僕はしてる.

mc.yohane.suでは前述の通りwhitelist.jsonGitHubで管理しており,ユーザの追加はPull Requestで行うのですが, JSONって手書きするのダルいですよね.いやそんなにダルくない人もいるだろうし別にwhitelist.jsonは全然ダルくないんですが,プルリクが送られてきたのを何も見ずにマージするのも渋い.そこでCIです.

というわけでできたのがこちら.minecraft-whitelist-validatorです.

github.com

これはRustでちょろっと書きました. またしてもやってることは超単純で,whitelist.jsonをserde_jsonで読んで,Mojang APIを使ってユーザとそのUUIDを検証するだけです. そして,Docker Imageを作ってGitHub Action化もしたので,uses: sksat/minecraft-whitelist-validator@v0.2.0みたいなかんじで使えます.やったね.

そしてcargo initした後に気付いたんですが,これってcurlとjqでいいんですよね.まあRust書きたかったのでいいでしょう.

イクラマルチ鯖をGitHub repoでIaCしてwhitelist.jsonへのPRを募っていて, UUIDとかが合ってるかぐらいをCIでチェックしたい人がもし万が一僕以外にもいれば使ってあげてください(?)

コンテナイメージ

さてここまでwhitelist.jsonGitHubとプルリクでやっている話をしましたが,たぶんみなさんが気になるところがあるとすればdocker-composeでどんなイメージを使っているかでしょう. もちろんこれも自作です.

まあDocker/docker-composeでマイクラマルチサーバやるなら普通有名なitzg/docker-minecraft-server使えばいいとは思うんですが,ここまで自作の物体でガチャガチャやっておいてイメージも自作しないわけはありません.

github.com

というわけで作ったのがこちら.papermc-dockerです.

github.com

PaperMCというのはJava版マイクラサーバに大量のパッチを当てまくることでなんかいいかんじにすることで有名なSpigotのforkのPaperというやつのことです.

papermc.io

なんかパフォーマンスがいいらしく,オタクにも人気らしい.ということで使っています.詳しいことは知らない. ちなみにitzg/docker-minecraft-serverにもPaperMCのexampleはあります.マジで要らないね.

github.com

と思ったけど僕の方がイメージサイズが小さいな.じゃあ勝ちということで.

ちなみに,マイクラサーバをコンテナ化するにあたって,SpigotとかPaperMCみたいに公式のJava版サーバにパッチを当てまくる系の奴は注意が必要です. docker build時に元の公式サーバのjarファイルを含めた上でイメージをpublicにしてしまうと再配布になってしまいますからね. しかしPaperMCなら安心.Paperclipというものがあります.

github.com

Paperclipはマインクラフトサーバのランチャーであると同時に,Paperのパッチをバニラのサーバに適用するシステムです. これは普通に起動するだけでマイクラサーバとして使えるのですが, 初回起動時にバニラのサーバのjarファイルをダウンロードしてきて,それにパッチを当てて起動します. 2回目以降の起動時はパッチ適用後のjarファイルを直接呼び出します.

なので,これを使ってpapermc-dockerを作ったというわけです.

papermc-dockerでは,GitHub ActionsでイメージをビルドしてGitHub Container RegistryとDockerHubにイメージをpushしています.

で,このビルドなんですが,Paperは普通にいいかんじにビルドされて各commit毎のビルド済みバイナリが公開されているので,それを取ってきてイメージに埋め込めばいいだけです.

papermc.io

だけなんですが,そんなつまらないことはしておらず,ソースからビルドしています. しかも,masterに追従するようにしています. 毎日自動でmasterのPaperをcloneして,更新があったらupdate/paperブランチに自動でcommitされるようにはなっているので,適当なタイミングでプルリクを作ってマージしています. マージはともかくプルリク作るのは自動化したいですね.

papermc-dockerの自動更新

さて,そんなわけでmc.yohane.suではpapermc-dockerを使っているのですが,papermc-dockerでやっているイメージのビルドなどは元々mc.yohane.suでやっていました. これを分離したのは,単にゴチャッとしていて気持ち悪かったのもありますが,イメージの自動更新をいいかんじに,というかRenovateを使ってやりたかったからです.

Renovateはdependencyの更新をするPull Requestを自動で生やしてくれる奴です.

github.com

そして,Renovateはdocker-composeに対応しているので,docker-compose.yml内で指定されているイメージが更新されたらプルリクを作ってくれます. これをcompose-cdと組み合わせるとCI/CDってやつで優勝できるってワケよ.

papermc-docker分離以前は,

mc.yohane.suでPaperのcommitを更新→イメージのビルド開始→compose-cdgit pull・再起動→イメージのビルド終了→compose-cddocker-compose pull・再起動

となっていたのが,

papermc-dockerupdate/paperをマージ→mainでのイメージビルド→Renovateがdocker-compose.ymlの更新PRを生成→PRをマージ→compose-cdgit/docker-compoe pull・再起動

というかんじになりました.無意味な再起動が減ってうれしいですね.

ちなみに,mc.yohane.su.compose-cdの中身はこんなかんじです.

REPO="https://github.com/sksat/mc.yohane.su"
UPDATE_REPO_ONLY=true
UPDATE_IMAGE_BY_REPO=true

UPDATE_REPO_ONLYはイメージの更新をスキップしてリポジトリの更新のみをcompose-cdが行うオプションで, UPDATE_IMAGE_BY_REPOはイメージの更新の責任をリポジトリが負うことにするオプションです. これらはつまり,イメージのマニフェストを見に行ってdocker-compose pullすることはしないが, git pull時にdocker-compose pullもする,ということです.

こんなことをやってるので,mc.yohane.suのdocker-compose.ymlではイメージの指定にタグではなくハッシュ値を指定しています.

ちなみに,compose-cdはログをDiscordに流す機能もあるので,こんなかんじの見た目になります.

f:id:sksat:20210826012307p:plain

papermc-dockerもRenovateで自動更新(2021/09/11追記)

実はRenovate先生は独自フォーマットのファイルの更新もできちゃいます.

swfz.hatenablog.com

ということで,papermc-dockerもRenovateで更新できるのでは?ということに気付きました.

まあ元々はこれできるの知らなくて,自分でGitHub Actions組んでやろうとしていたんですけどね. 書くの忘れてたけどupdate/paperブランチなるものはまさにそれで, GitHub Actionsのcronで毎晩update/paperブランチの,envファイル(Paperのcommit hashが入っている)を更新していました. なので定期的にupdate/paperをマージすればよかった,というわけです.

github.com

本当はこういうPull Requestも自動で出したかったんですけど, GitHub Actionsからsecrets.GITHUB_TOKENを使ってプルリクを出してしまうとCIが走ってくれないという罠があったりするんですよね. まあやってなかったのは面倒だったというだけなんですが.

workflowはこんなかんじ. github.com

で,これもRenovateでできた,というわけです.Renovateすげ〜. 実際のrenovate.jsonはこんなかんじになりました.

papermc-docker/renovate.json at bf275c89842a9cb1cf3f26d6cf81c3799bf7a35b · sksat/papermc-docker · GitHub

{
  "extends": [
    "config:base"
  ],
  "regexManagers": [
    {
      "fileMatch": [".env"],
      "matchStrings": ["depName=(?<depName>.*?)?\\s.*?_COMMIT=(?<currentValue>)(?<currentDigest>.*?)\\s"],
      "versioningTemplate": "git",
      "datasourceTemplate": "git-refs"
    }
  ]
}

papermc-dockerはPaperMC/Paperの(めちゃくちゃ更新される)masterブランチに追従しようとしている狂ったイメージなので,datasourceにはgit-refsを使っています. そもそもPaperはタグ打ちもリリースもしてくれないのでこうするしかないんですがね!(公式サイトにcommit毎のビルド済みバイナリあるんだからそれでいいんだよなあ)

で,無事にRenovate先生がプルリクを出してくれるようになりました.やったぜ.

github.com

プラグインの自動更新(2021/09/11追記)

みなさんマイクラサーバ運用でプラグインアップデート自動化してますか?僕はしてる.

Renovateで独自フォーマットのファイルも更新できることが分かりました. あっこれプラグインの更新もできますねえ.できるならやるしかない.

実は元々プラグインってやつの管理どうしたらいいかな〜とは思っていたんですよね. マイクラプラグインってやつはフォーラムにバイナリがポン置きされてるとかいうマジで狂ったWindowsとかいうクソボケOSみたいな文化が蔓延っているらしいんですが, 幸いにも僕が欲しいものはGitHub上で開発されてタグ打ちされてリリースも出されているようなやつだったので,なんとかなりました*2

これはどうやって実装したかというと,特定バージョンのプラグインをダウンロードして配置するシェルスクリプトを書き, これをcompose-cdのカスタムスクリプト機能で呼び出す,という方法です. compose-cdには再起動前ないし後にカスタムスクリプトを実行する機能がある*3ので, このスクリプトを再起動前に実行します.

プラグインのデプロイスクリプトのバージョン指定はこんなかんじ.

mc.yohane.su/deploy-plugin.sh at 43c4f50829a6153ccfbddef1bd9e9a0218f5da04 · sksat/mc.yohane.su · GitHub

PLUGINS=(
  # datasource=github-releases versioning=docker
  "PlayPro/CoreProtect v20.1 CoreProtect"
  # datasource=github-releases
  "DiscordSRV/DiscordSRV v1.24.0 DiscordSRV-Build"
  # datasource=github-releases
  "sladkoff/minecraft-prometheus-exporter v2.4.2 minecraft-prometheus-exporter"
)

あとはrenovate.jsonからこんなかんじで拾って上げれば大丈夫です.

mc.yohane.su/renovate.json at 43c4f50829a6153ccfbddef1bd9e9a0218f5da04 · sksat/mc.yohane.su · GitHub

{
  "extends": [
    "config:base"
  ],
  "regexManagers": [
    {
      "fileMatch": ["deploy-plugin.sh"],
      "matchStrings": [
        "datasource=(?<datasource>.*?)( versioning=(?<versioning>.*?))?\n  \"(?<depName>.*?) (?<currentValue>.*) .*?\"\n"
      ],
      "versioningTemplate": "{{#if versioning}}{{versioning}}{{else}}semver{{/if}}"
    }
  ]
}

というわけで,こんなかんじのプルリクが生えてくれるようになりました.やったね!

github.com

ちなみに,CoreProtectのバージョニングがdockerなのはバージョニングがクソボケだからです. クソボケなのでクソボケな正規表現versioning=regex:~~~みたいに書いたろ,と思ったんですがそれは無理でした.

github.com

無理だったんですが,みなさんだいすきなドッカーイメージってやつも頻繁によくクソボケなバージョニングがされているので, dockerを指定してお茶を濁しています. 問題はなかった.

docs.renovatebot.com

あと,プラグインを色々入れるなら入れた後もちゃんと起動するか確認したいですよね. というわけでCIの出番です.

github.com

まあこれはpapermc-dockerで既にやってたんでそれをパクってきただけですね*4

*1:結局,これはDockerHubがちゃんと認証をやっていたのにghcr.ioの挙動が雑で何も考えずに使えていたのが後から修正されたということっぽかったんですけどね.まあちゃんと両方いけるようになったのでOK.

*2:CoreProtectとかいうやつはかなりちょっとだいぶ微妙なんですが,まあ途中からとはいえGitHubに上がって今回使えたのはいいことではあるので許してあげましょう.

*3:これはセキュリティ的にどうなんだという気持ちがややあり,あんまりautomergeする気になれなかったりする.

*4:master追従なんてしてたら平気で起動しなくなることがあるので

REALFORCEを買った

はい.バイト代が入ったのでまた勢いで買った. あとなんか楽天ポイントが8000円分くらいあったので*1

sksat.hatenablog.com

前回メカニカルキーボード買ったのが去年3月とかなんで,1年強ぐらいでの乗り換えになりましたね.まあいいか,

静電容量無接点方式のキーボードにはずっと興味があったんですよねえ. それこそメカニカルキーボード買う前から.めちゃくちゃHHKBやらREALFORCEの方向見ながら「いや高いしな...」となってじゃあ1万以下ぐらいのメカニカルキーボードで...となってアレを買ったような気がする. と思ったら記事の最後でめちゃくちゃ未練滲み出てますね.

そんなこんななので,今のがダメだ!と思って乗り換えたというわけではなく,勢いで前から欲しかったものを買ったというだけ.

最近誕生日でオタクからトラックボールマウスを貰ったというのもあり,この機会に手の負担軽減キャンペーンやっちゃうか!みたいな気持ちもあった.まあ勢いだな.

静電容量無接点方式

前回と大きく違うのはここ.端的に言うと高いけどすごいやつ.なんの説明にもなってねえ. まあREALFORCEなりHHKBなりのサイト見た方が早いけど,マジで名前の通りで静電容量でやってるんで接点が必要ないので耐久性がよかったりする.なるほどよさそうじゃねーの.

www.realforce.co.jp

あと,なぜか知らんけどセブン銀行ATMのテンキーがこの方式なんですよね.たしかにあれはよくできてるし打鍵感もいい.

で,問題は何を買うか.まあ何をといってもHHKBかREALFORCEかなんですが. ただ,HHKBは思想は分かるんだけどちょっと僕には合わないなあと思ったので最初から候補には無かったですね. 前にオタクの家に行った時に触らせて貰ったけどやっぱりちょっと無理だった.慣れればいけるかもしれないですけどね. 少し前にTwitterで流れてきたHHKB誕生秘話みたいなやつで最初から小さくて持ち運びやすいことが割と主眼に置かれてたのはなるほどなあと思ったし,実際持ち運びたいのはすごいわかる. でも僕はちゃんとデカいキーボードじゃないとやっていけないかな...テンキーは要らないけど.

というわけでREALFORCEにするのは確定.じゃあどれにするか. REALFORCEのサイトに条件絞るボタンが付いてるので,ポチポチする.

www.realforce.co.jp

まずオタクは黒が好きなのでブラック. APCはよくわからんがあるに越したことはないだろう.保留. レイアウトはもうUSじゃないとちょっと嫌だなという体になってしまったのでUS. 今のキーボードはちょっとうるさいなと思っているので,せっかく買うなら静音がいい.

ということで残ったのがこれ. f:id:sksat:20210726141019p:plain

実は先週ぐらいにこのPFU limited editionとかいうのがセールでちょっと安くなってたんですよね. なんの割引もなくキーボードにドンと3万は出せないし... なので正直欲しかったんですが,その時はマジの無一文でどう足掻いても買えませんでした.オイ.

ということで,(セール直後に買うのは悔しいし)30gか55gか変荷重か.それなら変荷重にしてみるかなあ, となり今回はR2TLS-USV-BKを買うことにしたのでした.

で,どうなの

打鍵感はこの記事書いててもかなりいいです. とはいえ,前回がマジでゴミみたいなキーボードから比較的まともなメカニカルキーボード,という大きな変化だったので,それに比べると驚きは少ないかな,というかんじ. もちろん感覚はかなり違うのだけど,流石に新天地が開けてやべえ,とはならない.第一印象あっセブン銀行ATM,だし. あーでもこう気楽に文字書いてるとちょっとなるほどなあという気持ちにはなりますかね.

少し思ったのは,変荷重にしてはみたけれど実際外側の方のキー叩く時にちょっと強く叩きすぎてるかな,みたいな認識があるので,もしかしたら等荷重の方が合っていたのかもしれない. 感覚がかなり違うというのはあるので,慣れの問題かもしれませんが.

じゃあ2万出したけどそんなに感動しませんでした,ということかというとそういうわけでもない. 静音性は本当にすごい.そりゃあわざわざ静音モデル選んで買ってるんだから静かじゃないと困るんですが,これは本当にすごい. 「え,でもWH-1000XM3つけてノイキャンするんだから別に変わんなくね?」そうかもしれん. でもこれはいいですよ.あとキーボードの近くにマイクあるからボイスチャットの向う側の人もうれしいでしょたぶん(マイクをキーボードの近くに置くな)(いやでもどうせバカがきて高速ミュートするし)(じゃあいいか)

余談

全然キーボード関係ない話なんですが,実は数か月前に静的ブログシステムもどき,というか正確にはMarkdownもどきのパーサと,それを使った雑な静的ブログシステムもどきコマンドとOGP画像生成をRust+wasm+Cloudflare Workersでやる太郎を書いたりしたんですよね. なので実はずっとブログをそっちに移行したいな,次のブログ投稿はその移行記事にしよう,と思っていたんですが全然進めてなかったりする. https://blog.sksat.net/にデプロイされてはいるんですけどね.見て分かる通り無があります. 実はHTMLになった記事が存在しているので,URLをエスパーすれば記事が読める.記事リンク一覧くらい作れよ.

blog.sksat.net

ちょっと気合入れたら最低限ブログの形をするところまではすぐ行くと思うので,やるだけですね.やらんかい.

とはいえもう夏休みなんで(まあ今年はちょっとやることが色々あるのだけど),やるだろ. やったら移行するかはちょっと分からないですけどね.同時に投稿してもなんだかなというかんじだし. Markdownもどきの仕様決めとパーサ書くのがやりたかっただけで,実はブログを作りたかったわけではないというのはかなりある気がする. あとOGP生成太郎.こっちはもしかしてできるのか?と思ってやったらPoCができてしまったので飽きた. さっきembedで置いたリンクのところに"お〜じ〜ぴ〜"とかいうクソやる気ない文字列が出てたらそれです. こっちもやるだけではあるのだけど,結局文字描画なんで真面目にやるとクソダルいはず.ダルいなあ.

そんなこんなで,この記事はTwiterでキーボードに言及してそういや去年は書いたなと思って書いた体をした,課題やるのが微妙にダルいし眠いので逃避して書いてるやつでした,というオチで締めたいと思います.締まってないな.あと普通にスルスル文字打てて気持ちよかったです.よし締まった.

*1:たぶんE495のポイントが紆余曲折の末結局ちゃんと入ってたのを放置してたっぽい