blog.8-p.info

Staff Engineer: Leadership beyond the management track を読みはじめて、うーんと思っていたら、プログラム雑談で私の名前が出てきてびっくりした。

日本のソフトウェア業界の一部には、PG から SE にステップアップする (つまり後者がえらい) とか、プログラマはえらくないとか、マネージャーがえらいとか、そういうはなしがあって、日本のインターネットにおけるプログラマ語りでは、そういうものに対する反感とか、アメリカはそうじゃないとか、日本でも Web 業界はちがう、という話がされがちだったと思う。「日本の大手企業に入ったけれど、設計だけして、下請けにまわすばかりで将来が不安でした。来月からソシャゲ作ります!」みたいな退職エントリを、一昔前はよく見かけた。

でも、アメリカでも、とりわけ人をどんどん採用するような大きい会社だと、ジュニア -> 平 -> シニア -> スタッフ、というエンジニアトラックにのって、えらくなるにつれてコードを書く量は減ってしまうよなあと思う。大きい問題を分割して統治して、他の人々の活躍の場をつくり、彼らを育てる、みたいなものが評価されること自体に異論はない。一方で、自分がそれを目指したいかというと、どうなんだろう。シニアの上にいくのは全ての人に求められるわけでもないので、半分以上は杞憂でしかないけれど。

プログラム雑談の話をすると、私も、もうちょっと「これが私のアウトプットです」と呼べるものを増やしたい。会社のものはチームの作品という感じがあって、でもそれは前述の理由でむしろ目指すべきところだと思うので、自分のものは家で作るのがいいのだろう。認知の問題なので「人々を動かして作ったこれが私の作品です」というのもやればできるけど、それは会社員的な都合の良さにむけて現実を曲げすぎな気がする。

Hugo から Blackfriday が消えてしまっていて、Edward Tufte とか Ink & Switch みたいに脚注の縦位置をそろえるのがむずかしくなった。そもそも、複数の投稿が並ぶページだと、リンクのアンカー番号がかぶってしまう。

こういうことがあると、やっぱり Markdown を HTML に変換するくらいは、自分で書くのが良いのかなあと思ってしまう。依存するソフトウェアは少なくて単純なほうがいい。

一方で、Docusaurus, Jupyter Book, Quarto みたいな、長い文章を書くためのソフトウェアも気になる。こっちは複雑路線なので、バージョンアップするとちょっと壊れる、みたいなものにつきあう覚悟が必要だけれど。

containerd の cio.LogURIGenerator に、パスの最初が / かどうかで絶対パスかどうかをチェックしているところがあって、Windows では C:\foo\bar.txt とかあるよね、というので直している。

• Fix LogURIGenerator on Windows

先月末に手をつけはじめたときは、横着して、GitHub Actions の結果を見ながら直していたんだけど、流石に効率が悪いので、今日はちゃんと EC2 で Windows をたてて直した。

Get started with OpenSSH for Windows をみながら OpenSSH を入れて、Chocolaty から Go, Git と rsync あたりをいれると、手元で編集したものを rsync して、Windows でテストを走らせられるようになる。

file:/// の後のスラッシュは、ローカルホストならびにホストの概念がないときは3個が正しく、Windows のように絶対パスが / ではじまらないときは、例えば file:///C:/foo/bar.txt となるというのを学んだ。

「ソフトウェアを完成させる」話はよく読まれたので、ちょっと続き。前回の話では、いくつかの話が一緒になっていたので、Twitter やはてなブックマークで見かけた話も含めて、分けて考えてみる。

GUI のはなし。私は最近の GUI の変化をあんまり好ましく思っていない。Windows 95 とか NeXTSTEP とか BeOS あたりが一つの完成形で、スキューモーフィズムはやりすぎだったし、フラットデザインは見た目のキュー (これが押せますよ) がなさすぎるんじゃないか。アイコンの多用とか、スクロールしていないときは消えるスクロールバーとかも、スマートフォンのような狭い画面だったら意味があったものが、意匠として外に輸出されすぎていると思う。ただ、GUI は専門ではないので、この話はあまり深掘りできない。

役割分担のはなし。2022年に log4j とかをみると、なんか色々やっているなあと思う。ログに関しては、12 Factor App やコンテナ、あるいは systemd でも、アプリケーションはただバイト列を吐いて、それをディスクに書いたり、外の世界に持ち出すのは、アプリケーションの仕事ではない、というのが主流になりつつある。あるいは、パブリッククラウドでも、EC2 インスタンス、コンテナ、関数 (Lambda みたいなやつ) と並べると、どんどんユーザーが責任をもってアップグレードしたりする範囲が減っている。他の分野でも分担を変えられるところはあるだろうか。

セキュリティのはなし。コンシューマ向けのアプリケーションでは「カメラを使ってもいいですか」みたいな権限を尋ねるのが普通になって平和になってきたし、Linux だとプロセス単位のケイパビリティをつけられる。プログラミング言語も安全になってきた (C/C++ で書かなくてはいけないものが減ってきた) し、安全なソフトウェアを書くのはやりやすくなってきた。

再現性のはなし。C と共有ライブラリの時代には、あるライブラリに脆弱性があったら、それをアップグレードしておわり、ということができた。いまだと、go.mod とか、ベースのコンテナイメージをアップグレードしなくてはいけなくて、めちゃくちゃ困るわけではないけど、ちょっと面倒くさい。ソフトウェアの再現性を保つためには便利だけど、それと引き換えに、交換可能なものをくっつけているきらいはある。Linux ディストリビューションのユーザーランドをアプリケーションとくっつけて配布するとか、考えると結構な力技だ。

こうやって色々列挙すると、それなりに新しいものにふれないといけないのが「完成」の難しさというか、毎年の変化にも意味はあるんですよ、というのを示しているとも思う。2005年だったら、例えば Rust は個人プロジェクトですらないし、CAP_BPF もないわけで。でも、もうちょっと壊れないでいてほしいというか、プログラマがぽちぽち直してくのは、結局「運用でカバー」よなあ。

そういえば今週はオフサイトの週で、普段はシアトルじゃないところで働いているひとがシアトルに集まって、ミーティングをしたり Q&A をしたり、飲み会をしたり脱出ゲームをしたりしている。私も結構オフィスに通勤している。

オフィスにきて顔をあわせるとわかる感じはあるし、隣の人に詰まっているところについて話したりするの、やっぱりリモートではやりづらいよなあと思う。

一方で、日本では RubyKaigi, ダブリンでは Linux Plumbers Conference がやっているのもあって、オフィスにひとが集まるのはいわばオフ会で、たまにやるから楽しいんじゃないの、とも思う。

あと、私はプログラマ仕事10年ごえ、いまの会社も10年ごえのなかで、子育ては初心者なので、家で子育てがんばるのがいいんじゃない、というのはある。シニアエンジニアは初心者なので、会社にきて後進の指導をがんばりなさい、というのは一理あるけれど、でもまあ子供で手一杯よなあ。