ソフトウェアエンジニアリングチームはオーケストラか

専門的な技能を持った個人の集団がコミュニケーションを取りながら成果物を完成させるという点で、ソフトウェアエンジニアリングチームはオーケストラに似ている。長い期間に渡って同じシステムを育て続けるチームを想定している。

似ていること

  • 一人ひとりの能力の総和が単純にチームの能力にならない。良いコミュニケーションと良い文化・伝統が必要。
    • 一人のスーパースターの存在は、ある程度成果物の質に効いてくるが、決定的ではない。トランペットだけ超うまいオーケストラはトランペットパートで見せ場を作れはするが、それが他の弱点を覆い隠せるわけではない。スーパーエンジニアはアーキテクチャを設計できるが、同時にチームを教育し浸透させないと少しずつアーキテクチャの意図からズレたコピペが横行し、破綻する。
    • 技術的なボトルネックの解決とかは一人で大きく貢献できるかもしれない

違うこと

  • ソースコードは有形で永続化されている。いつ誰がどのような判断でその一行を書いたのか、高い確率で検証することができる。
    • オーケストラも楽譜に歴史が刻まれているとは言える。オーケストラは楽譜を所有しており、過去にやった曲であれば当時の書き込みが残った状態で使う。指揮者が変わって演奏指示が変わったりした場合は書き込みが更新される。しかしgitのように履歴を追跡できるわけではない。
  • コードを全く触らなくてもある程度の期間は動かし続けることができる
  • 新人をカバーし教育をすることができる。オーケストラでは一人音程が違えばバレてしまうが、ソフトウェアエンジニアリングではプルリクエストとレビューを通してカバーすることができる。
    • リアルタイム性の違い
    • しかし負担は大きい。『人月の神話』で論じられているように、新人の教育役として作業から離脱する人間が出るので人員追加の採算が取れるまでの時間が長い。

特にここから何かを主張したいというわけではない。それほど考えを深めているわけではない。しかしオーケストラの組織運営は何百年という歴史の中で洗練されてきたので、ソフトウェアエンジニアリングチームもそこからなにか学ぶことが、できたりできなかったりするかもしれない?

  • 全体の方向性を指示し、ときにはマイクロマネジメントを行う指揮者(ただしそれらの指示は全て全団員が聴いている)
    • 桜井政博氏も組織論の動画でディレクターの指示は誰でも自由に聞ける場でやるって言ってた
  • 全体に対してより具体性の高い指示を出すコンサートマスター
  • 同一の演奏機能を有する奏者が1つのパートを構成する(レイヤードアーキテクチャ+コンウェイの法則?)が、その中でも1st, 2ndのような役割分担がある
  • パート内ではパートリーダーに合わせる
  • パートリーダーは必要に応じて他パートと調整を行う

こう、風呂で思いついたときにアイデアとしては面白いと思うんだけど、文章に纏めてみると大した内容じゃないなってやつ、あるある。

Ubuntu23.10に上げたときの作業記録

私物のUbuntuは定期的に(だいたい年に2,3回)OSの再インストールをしている。このくらいの頻度でやっていると再インストール後の作業にも慣れてくる。手元にメモはあるが、一応インターネットにも載せておこう。

前提

  • インストールするのは純正のUbuntu
    • 日本語Remixではない
    • 普段はLTSしか使わないが今回はpipewireを今すぐ使いたかったので特別に23.10
    • 経験的にLTSとそれ以外の安定性にはかなりの差があるので、よほどの理由がない限りはLTSを使うべき
  • ルートはNVMe SSD
  • ホームディレクトリ下の以下はHDD上の同名のディレクトリへのシンボリックリンクにしてある
    • Documents
    • Downloads
    • Music
    • Pictures
    • Public
    • Templates
    • Videos
    • workspace
      • 個人開発のコードが置いてある
    • .ssh
  • なので、持ち越したいデータは全部HDDに置いているのでNVMe SSDはUbuntu Installerで全消ししている

再インストール作業

  • USBメモリにISOを焼いてUEFIの起動メニューからそちらを起動
  • Default Installation(全部入りではないほう)
    • サードパーティソフトウェアは入れる
    • メディアフォーマットサポートも入れる
  • NVMe SSDを完全に上書きする設定
    • LVM, ZFS, 暗号化はしない
  • パスワードはpasswordとしておいて後で変更する
    • インストールウィザード中に記号を含んだ複雑なパスワードを設定すると、なぜか正確に記録されず、後で同じパスワードを入力してもログインできない

セットアップ作業

  • ディスプレイの並びを物理空間と一致させる
  • 4KディスプレイをWQHDに設定しなおす
  • アクセシビリティから「大きな文字」を有効化、カーソルを最大に
  • ホームディレクトリ上のディレクトリ名を英語にする
    LANG=C xdg-user-dirs-gtk-update
  • 「ディスク」からHDDを ~/storage にマウントする
  • 前述のホームディレクトリ上のディレクトリをstorage下へのシンボリックリンクにする
    ln -s ~/storage/Documents/ ~/Documents
  • firefoxからvivaldiを入れる
  • vivaldiの拡張機能としてbitwardenを入れる
  • vivaldiの設定をsync機能で復旧する
    • syncにはID/パスワードとは別に復号パスワードも必要なのでそれもbitwardeに覚えさせておく
  • フォントをtakao系に戻す
    sudo apt install 'fonts-takao-*'
  • vscode入れる
  • steam入れる
  • 日本語変換をできるようにする
    sudo apt install fcitx5-mozc
    im-config # fcitx5を選択
    fcitx5-configtool # 変換・無変換をそれぞれ入力メソッドオン・オフに割り当てる
    再起動
  • nerdctl入れる
  • vim入れる
  • git入れる
    • ユーザー名・メールアドレス・デフォルトエディタ
  • thunderbird入れる
    • メールアカウントの登録。YahooはIMAPとPOPを選べるがIMAP

あとは必要になってから

  • 各種プログラミング言語処理系

Q. 今回はなんでUbuntu23.10にしたの?

A. https://github.com/edisionnano/Screenshare-with-audio-on-Discord-with-Linux にpipewireが必須だったから(そして22.04のpulseaudioを止めてpipewireを入れたらなぜか日本語変換が壊れるという大事故が起きたから)

実際にやってみたところ音質が悪かったのでこれを使うのはやめたが、pipewireに移行したことによってbluetoothヘッドホンの扱いがよくなり、これまで何故か使えなかったHSP接続が可能になり完全に死に機能だったヘッドホンのマイクが使えるようになった。まあこれも音質悪いからあまり使う気ないけど…

あとはPC内での音声入出力の繋がり方が、pavucontrolでは見づらかったが、 https://github.com/Ax9D/pw-viz を使って視覚化できるようになった。

Q. LTSじゃないけど大丈夫?

OBSのソースに画像ファイルを選択するとき、ファイル選択ダイアログを開くと非常に重くなる。なんで?

自分用ActivityPubインスタンスとしてGoToSocialを立てた

ツイッターがいよいよヤバそうなのでActivityPubのインスタンスを立てたくなった。まずMastodonを検討したが、リソースの要求が高いので諦めた。不慣れなRoRだしTypeScriptじゃないし構成も複雑なので個人で管理・改造するのは負担が大きいというのもある。

改めてActivityPub実装の中で軽量なものを探したところGoToSocialが良さそうだったので立てた。AWS EC2のt4g.microで現状問題なく稼働している。と言ってもまだフォローが少ないからかもしれない。ActivityPub、というか分散型SNSという仕組み上フォロー関係が増えると加速度的に通信が増大していくはず。

GoToSocial

GoToSocialはGoで書かれている。シングルバイナリで吐かれるアプリケーションとsqliteで動き、公式に提供されるdocker-compose.ymlを少し調整してリバースプロキシとしてnginxを立てるだけで動かすことができた。

現段階ではアルファリリースという位置づけであるが、大部分の基本的な機能に問題はない。今自分が把握している問題は以下の2つだ。

  • 動画が表示されない
  • notestockが利用できない
    • 利用を開始するためのnotestockのbotアカウントへのメッセージ送信がエラーで失敗する
    • mastodonには送れるのでnotestock側に何か問題があるのではと思っているが、notestockのソースコードは公開されていないので詳細不明

フロントエンドをほとんど持たず、サードパーティのクライアントから叩かれるAPIサーバーに専念している。推奨されているクライアントはpinaforeだが、pinaforeは2023年1月に開発の停止が発表された。webクライアントに限ればこれが最も盛んに開発されていたので先行きが不安だ(しかし作者自身が述べているようにpinaforeもだいぶ技術スタックが尖っていて将来性は怪しかった…)。ActivityPubデビューする人は最初にサーバーに登録してからクライアントを導入するだろうが、GoToSocialはユーザー登録用のフロントエンドも持っていないので一般に公開するにはハードルが高めかなと思う。自分はdockerコンテナに入ってCLIからアカウントを作成した。

自分でちょっとした改造を試みたときにdocker buildが大量のメモリを食ってEC2が落ちた(2GBでは足りなかった)。Dockerfileからswagger関連の処理をゴリッと消してやると直る。

最近考えていること@202206

読書

『ザ・ゴール』

スクラムでベロシティを安定化するにはどうしたらよいかで紹介されていたので8割方読んだ。8割方というのは、途中生産管理の話から思考法っぽい話に移ったところで興味を失って止まっているからだ。

この本では問題を抱えた工場の工場長が、学生時代の恩師(作者がモデルのようだ)から断片的なヒントを得ながら、それまでとは全く違う思想の生産管理を取り入れて成功するというストーリーが物語仕立てで描かれる(無職やめ太郎氏のようなものだ)。端的に言えば全員を休みなく働かせるのが最高効率というわけではなく、むしろボトルネックに着目しろという話だったように思う。「ように思う」というのは、教科書ではなく物語だから論理的な筋立てはあまりよくわかっていないからだ。

興味深い読み物ではあったが、単純にソフトウェアエンジニアリングに応用できるかは疑問だ。ソフトウェアエンジニアリングには固定化した生産ラインはないし、在庫コストもないからだ。しかしフロー効率とリソース効率とか、従属事象・統計的変動の概念はなんとなく掴めたので、もうちょっとかっちりした制約理論の教科書を読んでみたいと思った。

『プロを目指す人のためのTypeScript入門』

言わずと知れた有名人uhyo氏の著作。3割くらい読んだ。

僕は既にプロなので9割くらいはもう知ってる知識だ。しかし端々に挟まれる詳細な仕様の知識とか歴史的経緯、さらにuhyo氏の思想などが勉強になる。知っていると思い込んでいるものをもう一度学び直すという意味で価値のある読書だなと思う。思うのだが、やっぱり大体は知ってる話なので退屈になってしまってなかなか読み進められない。

『HTML解体新書』

仕様が広大ゆえに使いこなすのは難しいHTMLの本。全然読めてない。

『データ構造とアルゴリズム(五十嵐健夫)』

連結リストやスタック、木、ハッシュなどから始まり、ソートやグラフや文字列検索なども扱うらしい。これも3割くらい。

C++で実装しながら読み進めている。2-3木は辛かった。コアになるアルゴリズムはシンプルなのだが場合分けがドエラい数になる。平均計算量に関してはある程度計算で求める必要があるが、理解できないほどではなかった(自分で発想しろと言われても無理だが…)。

労働

あまり多くは語れないが、ここ半年くらいはずっと悩んでいる。4年目にもなるとこれまで通りの仕事をしていても学びがなくなってくる。だから更にスコープを広げて何かチャレンジしたいなと思っているけど、なかなかうまくできない。仕事に学びを求めるのが間違いなのかもしれない。

だからまあ、最近本をたくさん買ってみたり個人開発頑張ってみたりというのは、何か突破口が見つからないかなあということですね。

個人開発

最近はもっぱら https://anime.chao.tokyo の開発を進めている。Animetickからしょぼいカレンダー(手入力のアニメ放送予定API)への依存を切って、大量視聴を管理するための可視化などを足してみたいなという狙い。

使用技術はRemix+PrismaでEC2に雑に(DBもEC2で動いてるw)立てている。バックエンドの処理をパイプラインに見立ててfp-tsで書いているのが自分的こだわり。

飽きたら次にやってみたいのはweb componentsとかかなあ。Reactを捨てて生のHTMLと最低限のJSで何ができるのかというところを勉強してみたい。あるいはなんかOSSとかも。GoやRustも触っておきたい。学ぶべきことはいくらでもある。その気になればTypeScript一本でなんでも書けてしまうので、意図的にコンフォートゾーンの外に出るようにはしたい。

料理

以前から美味しいものを食べるなら外食で、自炊は楽で身体に悪くないものというポリシーでやっている。最近は以下のセットで固まっている。

  • ご飯
  • 味噌汁
  • 自作サラダチキン
  • ブロッコリーの惣菜(冷凍食品)
  • スーパーで買ってきたサラダ(ごぼう・コールスロー・切り干し大根のローテーション)
  • 納豆
  • ヨーグルト

サラダチキンを切らしたときは適当に惣菜買ってきたり。ここから50年くらいずっと同じものを食べ続ける可能性すらあるので、自炊は変に偏らないようには気をつけたい(何食っても塩分過多で怒るのであすけんは嫌いです)。

健康

3月末に右足首を捻挫して結構長く歩行で痛んだり疲れやすかったりした。ようやく治りつつある。

アニメ視聴

まあ、そこそこ見てます。

Dota2

ちょっとやる気なくなってます。4月頃は調子よくて3880まで上がったけどしばらくやらなくなって今3430。

自分の持ちキャラのメタ変動の話をすると、Dazzleの7.31の変化が気に入らない。タイミングの概念を捨てて単にCD上がるたびにスキル撃つのを推奨するようなメカニクスになっていて、こんなの人間がプレイする必要ないじゃんと思ってしまう。

ということでプロの間で大流行していたPugnaばかり使っていた。癖はあるもののスキルセットが強力。サポートでも積極的にタワーを折れる1番、SavingにもDisableにもなる2番、設置するだけで大きなダメージを叩き出せるNether Ward、そしてダメージにも大回復にもなるUlt。Shardは弱いと思うけど…(相手にPLかNagaがいたら買うかも)。

ただPugnaも7.31dでかなりお仕置きを受けてしまったのでやめる。またDazzleに戻ることも検討しているが、単に数字上のbuffがあったというだけでメカニクスは改善していないので悩ましい。あるいはEnchantressもいいかもしれない。これもプロで猛威を奮っていたので7.31cでEnchantにレベルキャップがついてしまったが(なかったほうがおかしいだろ!)、それでもタンクやラットができるサポートというのは貴重だ。

Stunがないサポートは嫌がられるのでHoodwinkを使っていた時期もあったが肌に合わず全然勝てなかったのでやめてしまった。

歯バトル・ファイナル8/20

いつまでやってんだという話だが、4月から続いている歯とのバトルは8月20日に右上親知らずの抜歯が決まったことによってひとまず決着しそうだ。なんで長引いたかと言うと右上の親知らずを抜くべきか抜かざるべきか、かかりつけ医とデカい病院の口腔外科医の意見が微妙に異なり(対立というほどではない)、そこに僕自身の迷いが重なったからだ。

いよいよ夏が来ている。僕の通勤ルートは徒歩の割合が大きい。早く歩けば歩くほど発汗は増えるだろうが、ゆっくり歩いて日差しに当たる時間が伸びてもやはり発汗は増える。つまりどこかに最適な歩行速度があるはずなのだ。発汗のことはともかく、歩行には最適な速度がある。伸ばした足が直線であると仮定すると(ホンマか?)、その足を半径として体が円弧を描く遠心力と重力が釣り合うのが2.5m/sだという。つまりこれより早く歩行しようとすると無理な体勢を強いられ、エネルギー効率が悪化する。このモデルは大雑把だが実測した歩行→走行の移行ポインともだいたい一致するようだ。詳しくはAlexandar(1984)に書いてあると思う。僕は直接読んでなくて教科書で紹介されてるの読んだだけだけど(学問的に不誠実な発言)。

京都アニメーション放火殺人事件の犠牲者の遺族を自称するツイッターアカウントがにわかに出現し、マスコミの強引な取材を「告発」し20万RTを超えている。「ウソをウソだと見抜ける人でないと難しい」はどこに行ったのか。本当の遺族は遺族じゃない人に比べてああいうツイートをする確率は確かに高いだろうが、そうは言っても遺族じゃない人の方が世界には圧倒的に多い。つまりあのツイートの主が本当の遺族である確率は非常に低いことになる。ベイズの定理というやつだ(詳しくない)(これ読んで)。

2連続で大学の知識の残滓を披露してしまって辛い。じゃあ新しいことを勉強できているかと言うと、まあできてなくもない。DDDを簡単に説明した同人誌をそろそろ読み終わるので本格的な本を読み始めたい。しかし、有名な教科書がKindle Cloud Readerで読めない。辛い。紙の本で買うと値段が倍になる。辛い。

DDDDDDDDDD

DDD(ドメイン駆動設計)について『わかる!ドメイン駆動設計 ~もちこちゃんの大冒険~』を読みながら勉強している。言葉からはどういうものかイメージがつかなかったが、ビジネスをプログラムに落とし込むための考え方のようだ。エヴァンズの原典は長大でどのレビューを読んでも「他の本である程度理解してから」と書いてあったし、Kindle Cloud Readerで読めなかったので後回しにした。

抽象的な設計論の勉強と具体的な手を動かすタイプの勉強はどうやって進めていけばいいんだろう。一つずつ倒すのか、平行していくのか。

任天堂の音楽

※この記事は『金麦』を飲んで書かれた。

なにやら任天堂の発表会があるらしく、プログラムを書きながら聞いていた。任天堂が世界に冠たる企業であることは知っているし、その作品が高く評価されていることも知っているが、僕は任天堂のゲームをあまりやったことがない。というかゲームをあまりやったことがなかった。強いて言えばポケモン赤とポケモンホワイトはどちらも発売からかなり経ってからやったが、ネタバレを知った状態だったしそれほど熱心ではなかった。

その程度の任天堂認識の僕だったが、Nintendo Directはどのゲームも音楽が素晴らしく聞いているだけで楽しかった。大してゲームをやっていない僕でもどこかで聞いて覚えている音楽がたくさんあったのはすごいことだ。

なにか任天堂のゲームをやってみようか。と思っても任天堂のキャラクターをあまり知らないので何をやれば楽しめるのかよくわからない。もう出来上がっている世界観に参入するのはハードルが高く感じる。年をとってしまった。遊ぶ時間もそんなにないし。

住環境に投資する価値を知った

※この記事は『麦とホップ』を飲んで書かれた。

家賃が2倍ほどの家に越してきて1日生活したが、素晴らしい。優れた家の構造はアプリケーション開発に似ている。その心は疎結合だ。

以前住んでいた家は大きめの収納スペースが1箇所あった。これは全ての収納を集約できるというメリットに見えるが、実際は違う。1箇所に収納するモノが増えるほどそこから望みのモノを出し入れする手間は増大する。つまり収納は分散していたほうがいい。

今の家は台所にも洗面所にもそれぞれに収納がある。これがどれほど効果的なのか今日知った。台所で使うものは台所に、洗面所で使うものは洗面所に収納しておくことで探索効率が向上し、さらにモノを持って部屋の間を移動する必要がなくなる。モノを出し入れするコストが低減することでモノを使ってその部屋を手入れすることも簡単になる。台所のことは台所で完結するようになる。モノの場所が複雑に入り組んで生活が崩壊するということがない。

高い家は相応に良い。高い家に住み続けたいし、そうなると借家暮らしよりも持ち家の方が効率的になるかもしれない。

Mastodon諦めました/Spotify諦めました

今日はコンピュータに嫌われた一日だった。悲しい。

Mastodon

再びマストドン立てようと思ったんだがメールが送れないのと他インスタンスとの通信ができないトラブルを解決できず諦めた。どちらも初めて出くわした。

前者は名前解決なんちゃらのエラー、後者はどうやらSSLと関係があるようだったが僕の知識では理解できなかった。そもそもMastodonは恐ろしく複雑だ。使いやすくする努力はされているが少しでも不具合が起きるとそれを解決するためにはとんでもない知識と労力が必要になる。

Spotify

Spotifyでローカルの音楽ファイルを再生したかったのだが、mp3にしか対応していなかった。そこで急遽音楽フォルダ内を全部掘ってmp3じゃないファイルをmp3に変えるスクリプトを書いた。

しかしそうして生成したファイルをSpotifyで再生しようとすると、再生ボタンを押した瞬間にSpotifyアプリが終了する。ターミナルからアプリを開いているとログが残るが、終了時に表示されるのはこれだ。

[0228/053947.271857:ERROR:input_method_base.cc(146)] Not implemented reached in virtual ui::InputMethodKeyboardController *ui::InputMethodBase::GetInputMethodKeyboardController()Using InputMethodKeyboardControllerStub
Segmentation fault (コアダンプ)

うーん。軽く調べてみるとChromiumのバグの疑いが強く、2018年11月辺りに報告が頻発している。しかしローカルの曲を再生するときだけこうなるのでSpotify側にも問題がありそうだ。