「[作って学ぶ] ブラウザのしくみ」を読んだ

「[作って学ぶ] ブラウザのしくみ」という本を技術評論社から恵贈いただいたのでレビューを書きました。なお、作って学ぶ本なのに、わたしはまだコードを読んだだけで書き写してはいません。そういう人が書いた感想だということはご承知おきください。

［作って学ぶ］ブラウザのしくみ──HTTP、HTML、CSS、JavaScriptの裏側 WEB+DB PRESS plus

本書はWebブラウザのしくみを、自分で作ることによって理解しようという意欲作です。眼にした瞬間に「デカ！」と思った程度には大きく、400ページ以上あります。しかし、読後感は「たったこれだけのページ数に、よくぞこれだけの内容を詰め込んだものだ」でした。わたしはWebブラウザを作ったことがないし、関連技術に明るくもないこともあって、大変ためになりました。

昨今のWebブラウザは非常に多機能かつ複雑で、ソフトウェア技術の総合芸術のようになっています。作るのには膨大な知識が必要ですし、コード量も尋常ではなく多いです(著者いわく、Chromeは2024年7月現在3000万行を超える)。本書はこのようなWebブラウザのうち、ごく一部のエッセンスとなる機能のみを扱っています。それら機能を作るにあたって必要な技術、仕様の説明もしてくれていて、至れり尽くせりなところがとてもよかったです。何かを作る系の本で、「こういう機能はこう書く」というだけではなく「どういう理由でなぜこのようなことを書かなければいけないのか」を説明してくれているものはなかなか無いのです。

前の段落で書いた「エッセンスとなる機能」とは、表紙にも書いているHTTP、HTML、CSS、Javascriptのサブセットです。タイトルだけ見た時は「HTMLのタグを何個か解釈して、それを画面上にレンダリングするところまで書く本なんだろうな」と思っていましたが、それだけではなくCSSによる装飾やJavascriptによるコードの実行までが、一部にせよできるようになっています。これが意味するところは、本書に書かれていることをすべてマスターした読者は、「字句解析」、「構文解析」、「解析結果をもとにした画面へのレンダリング、およびコードの実行*1」というプログラム技術を会得できるということです。これらはWebブラウザに限らず他のところでいくらでも応用が利く技術なので、身に着けておいて損はないと思います。

続いてソースコードについて。コードは素直な書き方をしていて、とくに難解なことはしていません。ここで超絶技巧を凝らされると「作っても学べない」になるので、とても良かったです。また、この手の本には珍しく、テストが存在しており、かつ、それを書籍の中で紹介しているのに好感を持ちました。テストは大事です。

本書は説明が丁寧でコードが平易なことを考慮しても、読む難易度が高い本だと思いました。本書の前書きには「普段からブラウザを使用していて、その裏側に少しでも興味を持った方を対象としています。」と書かれています。私見では、さらに以下のような人が読むのに適していると感じました。

• なんらかの言語でプログラミングをしたことがある。本書のコードはRustで書かれているので、Rustの経験があればなお好ましい。
• OSと仮想マシンという概念について薄くでもいいので知識がある。とくに仮想マシンについては自分で動かしたことがある。

もちろん上記のことができなければ読んではいけないということは全くありません。「なんとなく興味を持つ」というのは重要で、あらゆる困難を跳ね返す力となります。ぜひ情熱をもって読み進めて、自作ブラウザを作ってほしいと思います。

これまで褒めてばかりでしたが、難点も3つ挙げておきます。1つ目は、HTTP3、およびその裏側にあるQUICをはじめとした新しめの技術について、それなりのページ数を割いて説明しているものの、それらは本書では実装しないということです。ある程度知識が無いと、説明された技術と、これから自分が実装するものの対応付けに戸惑うのではないかと思いました。本文では実装するものと直接関係することだけを説明して、それ以外はコラムかなにかに分けて書いてあるとよさそうだと思いました。

2つ目は、本書を読むにはOSと仮想マシンという概念について知識があるとよさそう…と書いたことに関係しています。本書で作成するWebブラウザは、関連書で説明される予定の独自OS上で動作します。また、Webブラウザの動作確認時に、そのOSをQEMUというハイパーバイザ上で動作させます。これらのことについて本書は少しだけしか説明をしていないので、OSや仮想マシンについての知識がまったく無いと、環境構築段階で一体何のことかわからず挫折しかねないと思いました。

3つ目は、たびたび出てくる関連書籍「[作って学ぶ]OSのしくみ」が本書執筆直後の現時点(2024/11/13)では存在しないことと、いつから存在するようになるのかが不明なことです。技術評論社のサイトを見ても、以下のように書いているだけです。

別冊で解説・実装している自作OSの上で動かすことによって，ブラウザと更にその裏側を理解していきます。

このことについては、前書きか何かでことわりを入れておくべきだったと思いました。

最後になりましたが、本書はよい本なので、Webブラウザに興味のあるかたは是非読んでほしいなと思いました。また、「[作って学ぶ] OSのしくみ」は、来年(2025年)に出る予定らしいと聞いたことがあるので、2冊を並べて読むのを楽しみにしています。

*1:本書ではバイトコードへの翻訳はせずにソースコードを読んで逐次実行している

「絵で見てわかるLinuxカーネルの仕組み」という本の宣伝

本日10/23発売の「絵で見てわかるLinuxカーネルの仕組み」という本を自分含め6人で書きましたので、宣伝します。

絵で見てわかるLinuxカーネルの仕組み

本書はIT技術のさまざまな分野について視覚的に理解するための翔泳社の「絵で見てわかる」シリーズの中の一冊です。

www.shoeisha.co.jp

このシリーズは、これまでに「ITインフラの仕組み」、「Webアプリ開発の仕組み」、「マイクロサービスの仕組み」など、さまざまなものを扱ってきました。本書は「Linuxカーネル*1の仕組み」を扱います。Linuxカーネルを絵から理解するというコンセプトの本です。

Linuxカーネルは Red Hat Enterprise LinuxやUbuntuといったLinuxディストリビューションの核(カーネル)となるソフトウェアです。いかなるLinuxディストリビューションもLinuxカーネル無しでは動きません。Linuxカーネルはまたスマートフォンのオペレーティングシステムとして知られるAndroidのカーネルでもあります。いかなるAndroid端末もLinuxカーネル無しでは動きません。本書はそんなソフトウェアを題材としています。

想定読者は、本書の前書きから抜粋すると「Linuxをある程度は使えるようになって、次のステップとしてカーネルについて学習したいと思われた方」です。もう少し言葉を足すと、「Linuxのコマンドは普段から実行しているけれどもカーネルは聞いたことがある」、あるいは「Linuxカーネルの概念は知っているが詳しくは知らない」、というくらいの人です。これに加えて、「Linuxカーネルの役割をある程度知っているけれども、ここ5年、10年の間に追加された機能についてはよく知らないな」といった人も対象となるでしょう。なぜならば、本書は個々の機能について深掘りはしないものの、扱う範囲は広く、かつ、最新機能もたくさん紹介しているからです。

本書の著者陣は全員が業務で日常的にLinuxカーネルを扱っているため、本書はLinuxカーネルの内部を知る人々が生きた知識をもとに書いたものです。書籍内で紹介されている様々な機能がどういうものかに加えて、著者陣がそれらについてどのような見方をしているかという観点で読むのも面白いかもしれません。

本書の特長の一つに、マシンリソースが限られる組み込み機器でよく使われる機能についての説明が手厚いことが挙げられます。著者陣のなかに、組み込みLinuxの分野に明るい人が多いことがその理由でしょう。わたしはLinuxカーネルについてはそれなりに詳しいですが、サーバOSとしてのLinux以外はほとんど知らなかったので、本書の中には新たな発見がたくさんありました。

本書の目次は以下の通りです。

第1章 Linuxカーネルの基本
第2章 プロセススケジューラ
第3章 メモリ管理
第4章 ファイルシステム
第5章 ブロックI/O
第6章 デバイスマッパ
第7章 LVM
第8章 ネットワーク
第9章 セキュリティ
第10章 ハイパーバイザと仮想化
第11章 コンテナ型仮想化
第12章 トラブルシューティング／デバッグ概要

第1章では本書を読むにあたっての基礎的な知識に加えて、カーネルのバージョンはどういう意味を持つか、どのようにビルドオプションを設定するのか、どのようにカーネルパラメタを設定するかといった様々な知識を学べます。

第2章から第5章、第8章は世間のOSカーネルについての本でよく扱われる、カーネルの基本機能を紹介しています。これまで書籍ではあまり触れられてこなかったプロセススケジューラの1つであるデッドラインスケジューラを紹介したり、Linuxカーネルの比較的新しい機能であるXDPというネットワーク機能を紹介していたりといった特色があります。

第6章、第7章は第5章の延長戦のようなものです。ディスクに1対1で直接対応するブロックデバイスとは異なり、スナップショットをとる、試験のために仮想的にエラーを発生させる、といった高度な機能を持つブロックデバイスを紹介しています。

第9章が扱うセキュリティは、セキュリティ脆弱性を突いた攻撃が日々世間を賑わせている現代では注目のトピックといえるでしょう。セキュリティ技術についてある程度詳しい人でも、OSカーネルのレイヤでのセキュリティ技術については、知っている人はそれほど多くないのではないでしょうか。

第10章、第11章はKVMなどによる仮想マシン、Dockerコンテナ、コンテナオーケストレーションKubernetesといった文脈で注目を集めている仮想化、コンテナ技術について説明しています。これらの技術とは切っても切り離せない関係である、リソース管理のためのcgroup,namespaceという機能も説明しています。

締めの第12章では、実務でLinuxカーネルを扱っている筆者陣が使っている、カーネルレイヤで実現するトラブルシューティング、デバッグ技法を紹介しています。「カーネルについての本なのでカーネル開発者用の機能なのでは？」と思われるかもしれませんが、そうではありません。ここで紹介するのは、カーネルの機能を使って実現するユーザ空間プログラム用の機能の紹介です。とっつきにくいですが、覚えてしまえば大きな力になってくれるでしょう。

上記の説明を見て興味が出た方はぜひ手に取ってご覧ください。おわり。

*1:正式名称は"Linux"ですが、ここでは"Linuxディストリビューション"と区別するために"Linuxカーネル"と明に書いています

一人前のエンジニアになれたと感じたとき

よく聞かれるのでタイトル通りのことを書こうと思ったわけですが、さて実際のところどうだったかとなると、なかなか思い出すのが難しいです。少なくとも「最初からできた」ではなかったです。そして「俺は全然駄目だ」な状態から「いける」という状態に、あるときを境にフラグが立ってそうなるというようなものでもなかったです。いくつかの出来事によって、ようやくそう思えたと感じたと記憶しています。本記事ではこれらの出来事について紹介いたします。

本記事の主な対象読者は、社会人一年生を含む経験が浅いソフトウェア技術者で、かつ、「一人前になれてないなあ」と日々悩む人々です。「一人前とは何か」という疑問もありますが、これは先輩方から逐一指導されて仕事をするジュニアエンジニアから、それなりに独立して仕事ができるようになるミドルエンジニアへの脱皮までの道と考えてもらえればいいかと思います。みなさん取り組んでいる業務は恐らく当時のわたしと全然違うと思いますが、汎用的を目指して変に抽象的な書き方にしても何も得ることが無いと思いと思うので、それなりに具体的に書きます。

まず、わたしが社会人一年生のころに、どの程度の能力だったのかを紹介します。わたしはサーバベンダに就職し、Linux開発サポート部門に配属されました。配属当時はプログラミングの経験は数千行程度のトイプログラムを書る程度でした。OSカーネルについての本をいくつか読んで専門的なことを理解できる、かつ、Linuxカーネルの改造経験が少々あったので雇われました。ここから開発者としてプロダクション向けのコードを書けるようになるまでは滅茶苦茶大変だったのですが、大変なのは開発業務だけではありません。

わたしがもっともつまずいたのはサポート業務でしょう。そのときのサポート業務で必要なものは沢山ありましたが、ここでは以下の2点を挙げます。

1. 専門的な技術についての知識
2. 目の前の問題を理解し、迅速に調査して回答する能力。

以下、それぞれについて、最初のほうにうまくいかなかったことと、その問題がどのように解決していったか、どの段階で「ここはできるようになった」と感じられるようになったかを書きます。

まずはaからです。前述したように私は配属される前にある程度OSカーネルについて知識がありました。Linuxカーネルも少し読んだことがありました。自分で言うのもなんですが、こう言うことを知っている人はかなり稀少です。ただ、この程度ではプロフェショナルとしては戦えません。ただの「ちょっと珍しい知識に詳しいアマチュア」です。就職後に取り組んだのは、「ある程度」知識があったり「少し」読んだことがある程度の生兵法では太刀打ちできない仕事ばかりでした。基本的には先輩方の指導を受けながら知識を蓄えていくわけですが、自分の好きなタイミングで勉強できるわけでは当然なく、お客様の問題を解決するために期限を切られてやるため、楽しいながらもなかなかにつらかったと記憶しています。

飛躍のきっかけになったのは、ある日、先輩からかけられた「明日から君はブロックデバイスの専門家だ」という言葉です。その先輩は千尋の谷から愛する部下を叩き落とすタイプだったので、その次の日からLinuxのブロックデバイスについての話はすべて私が主として受け持つことになりました*1。一か月後くらいには一人で出張して別部署の人に説明、といったこともやりました。なかなかに無茶だったと思いますが、最終的にはかなり知見を蓄えて海千山千の猛者たちが自分に話を聞きに来るようになりました。このときに自分が信頼されたな、確固たる居場所ができたなと感じるようになりました。

続いてbについて。最初は一次サポートからの質問が何であろうと鵜呑みにして闇雲に「それ、そういう問題じゃないよ」「それは何のための調査なの？こっちのほうが効率よくない？」と注意されたことが多々ありました。回答についても「それは問題解決になっていない」「回答が遅い」と注意されることがよくありました。しかし、調査を数十回と重ねていく段々コツがわかってきて、自分なりの型ができてきたころには注意される数が劇的に減っていきました。

場数を踏むだけではなく、「この問題について考えたことを次に生かすにはどうする?」と考えるようになり、チーム内に提案するようになったことで、さらに成長できたと感じました。その後、後輩ができて彼に指導するようになったり、先輩から頻繁に進捗を尋ねられることがなくなったり、ものによっては他の人がわたしの見解を聞きに来るようになったときに、ようやく信頼された、みんなと同じ土俵に立てたなと感じました。

まとめると、わたしは周りと同程度の仕事をこなせるようになったり、自分に強みが生まれて頼られたりした結果、一人前になったと感じたようです。みなさんも、まずは「チーム全員が最低限できること」をできるようになり、かつ、「チームの誰よりも強いところを作る」ところを目指して、「そうなるにはどうすれば」と考え、必死にくらいついていくのがいいかなと個人的には思います。3年経ったら自動的に仕事するようになるわけではありません。3年後にどうなっていたいか考えて、それに向かって日々行動するのです。

最後に一言。新卒社員が「期待の新人、あるいは若手」でいられるのは新人のときから長くて2,3年でしょう。教えてもらってヒントをもらってのんびりやっているだけだと、2,3年後には「かつて期待されていた、現在は若手じゃない人」のできあがりです。こうならないようにするのはもちろん重要なのですが、すでにこうなってしまった場合はマネージャに相談して今後どうしようと相談するのも一つの手かと思います。事態の改善に動くために動くよい時期は常に今です。

*1:彼は叩き落とした後に去るわけではなく後ろに隠れて陰に陽に助けてくれました

問題解決より深掘りを優先する人が困っていたこと

何らかの問題を解決しなくてはならなくなった時に、解決よりも深掘りを優先してしまう特性の人がいます。 たとえば問題に対する短期的な対策を考えることをおろそかにして、根本原因究明と根本対策方法をじっくり考え込んでしまうような人が該当します。他人事のように言ってますが、筆者もそうです。本記事は、そういう筆者が過去に仕事で困っていたこと、ある時から状況によって取り組み方を変えられるようになったという話をします。

上記のような特性の人は、調査のたびに深い知識が得られ、血肉となっていきます。それゆえ技術に明るい人とみなされることもあります。その一方で、困ることもあります。とくにそれは発生した問題が自分ではなく他の誰かのものだった場合、かつ、急ぎ問題解決が必要な場合です。業務ではこのような場面が非常に多いです。

この場合、問題の深掘りを最優先にしてしまうと仕事が遅くなりがちです。みなさんも、「あの人、技術のことにやたら詳しいのに成果はいまいち出ないよね」という人に心当たりがあるかもしれません。ご自身がそうかも知れません。またしても他人事のように言っていますが、社会人になりたての筆者もそうでした。

筆者は過去に何やかんやと苦労していたんですが、様々な理由によって、今では上記のような困りごとがかなり減っています。主だったものを以下に列挙します。

1. 迅速な問題解決の対価として給与をもらっているのに、課題設定を間違えて業務を怠っていることに気づいたこと。
2. aによって自分だけではなく問題を抱えている人も、自分の尻拭いをしている人も困っていると気づいたこと。
3. 深掘りをするのは問題解決の後でもできると気づいたこと。

どれも一見して当たり前のことですし、先輩方からもよく注意されていましたが、腑に落ちたのは自分の首が目一杯締まった後でした。自分をサポートしてくれていた、お世話になっている人々の首も程よく締まっていました。過去の筆者と似たような境遇の人は、ぜひとも首が絞まり切る前に「こいつみたいになりたくないなあ」と、必要に応じて行動を変えられるようになって欲しいなと思います。

最後になりますが、筆者は問題の深掘りをしたくなる性質そのものは否定していません。むしろこれは美徳だと思っています。とことん突き詰めても自分含め誰も困る人はいなければ、好きにすればいいと思います。仕事でも元の問題を解決した後、かつ、余裕がある時にじっくりと深掘りすれば、成果を上げつつ深い知見も得られて良い循環になると思います。といったところで、おわります。

Binary Hacks Rebootedを読んだ

Binary Hacks Rebootという本を著者のかたから恵贈いただいたのでレビューを書きます。著者や寄稿者のうちの何人かは知り合いだったり、本が恵贈いただいたものだったりでバイアスがかかっている可能性がありますが、ご容赦ください。

Binary Hacks Rebooted —低レイヤの世界を探検するテクニック89選

どんな本か

本書はいわゆる低レイヤと呼ばれるバイナリがいっぱい出てくるような技術について小ネタを山盛り、Hacksなので89(ハック)個、詰め込んだ本です。

扱う分野は以下のように多岐にわたっています。

• ELF(Linuxなどで使われる実行ファイル、共有ライブラリを保存するファイルの形式)
• OS、とくにLinuxについてのもの
• コンテナ技術
• デバッガ・トレーサ
• セキュリティ
• 数値表現とデータ処理
• 言語処理系
• その他

読むと良さそうな人

このコンテンツに魅力を感じるかたがたは、すでにある程度知識があっても、どこかには「知らなかった！」となるようなハックがあると思うので、読むと良いと思いました。わたしもOSカーネルの開発を過去に10年以上やっていましたが、全く知らなかったこと、名前だけは知っていたが詳細は知らなかったものがたくさんあり、よい読後感がありました。

興味があるもののあんまり前提知識がない、というかたは、読むのにかなりの根気がいるとは思いますが、サンプルコードを参照しつつ、関連用語の意味を調査しつつ読めば、時間はかかるものの、なんとか読めるとは思います。読後には一皮むけていることでしょう。

サンプルコードが主にアセンブリ言語とC(ごく一部、Rustもある)なので、これら言語を読み書きしたことがないかたは面食らうと思います。最初は文書だけ読んで、あとから掘り下げてみたいと思った場合は気合を切れて調査をしつつコードを読むというやり方でもいいと思います。

前作Bainry Hacksとの関係

本書は20年近く前に出版されたBinary Hacksという本の続編です。

Binary Hacks ―ハッカー秘伝のテクニック100選

前作を読んだ人に本書を読む価値があるのかという問いへの、過去に読んだことがある私の意見は、「読む価値は十分にある」です。

第一に、前作と内容にほとんど重複がありません。コンセプトが同じであるまったく別の本と認識すると良いと思います。第二にカバーする範囲がかなり広がっています。前作に比べて本作は悪意のあるユーザに攻撃されるケースを想定した技術が数多く紹介されています。とくに新規追加されたセキュリティの章は(当然ながら)そのようなハックの宝庫です。低レイヤの世界で生きてきたもののセキュリティは強くないというかたは読んでみると新たな発見があると思います。

おすすめの読みかた

かなり分厚い本で、合計600ページを超えます。それぞれのHackの難易度もそれなりに高いです。このため、最初から最後までサンプルコードを実行しながら精読するのはかなり骨が折れるでしょう。そういう読みかたをすると高い確率で、途中で挫折するのではないかと思います。

本書は前から順番に読むのではなく、全体をぺらぺらとめくってみて、興味のありそうなところ、理解できそうなハックからつまみ読みすると気楽でいいかなと思います。個々のハックについても、上述したように最初から完全理解を狙うのではなく、最初は斜め読みして、さらに興味が出たら後から精読するというのがいいと思います。

業務での実用性

職業IT技術者にとっての実用性はどうでしょうか。これについては「人による」という回答になります。読み手が置かれた状況によって何が役立つかは変わってきます。たとえば私は現在物理データセンター上に構築されたストレージシステムの開発という、比較的低レイヤの仕事をしています。私にとっては主にOS、コンテナ技術、デバッガ・トレーサ、セキュリティあたりの章が役立つでしょう。しかしながら、業務としてそんなことをしている人は全体から見ると少数派だと思います。

正直なところ、本書に書かれているハックを理解しても直接すぐに役立つという人は少ないのではないかと推測していますが、それでも本書によってコンピュータ技術のうち、OSやライブラリ、ミドルウェアを介さない、生に近いレイヤのものを理解することは、きっと長いコンピュータ技術者人生のどこかで何かの形で役立つと思います。業務での実用性だけが技術書の価値ではありません。

一押しHack

わたしが本書を読んで一番気に入ったハックはHack19,20,21のDWARFについてのものです。あんまり詳しく書くとネタバレになってしまうので、概要だけ説明します。

DWARFというのはプログラムのデバッグ情報を保存するためのデータフォーマットです。DWARF形式のファイルの中のバイトコードをDWARF上のVM(インタプリタと言ってもいいかもしれません)上で動かせるという興味深い機能があります。これらのHacksでは、DWARFを設計者の意図通り使っていれば絶対やらないようなことをDWARFのVM上でたくさんしています。

これらHackを見た後の「そう来たか」という面白度や「何故これをやろうとしたのか」という困惑度は極めて高かったです。実用性が無い度も本書の中ではトップクラスですが、そんなのはいいんです。前述したように技術書は実用性だけあればいいというものではないです。「面白い！」と感じて、「わたしもなんかやりたい！」と好奇心を刺激してくれるコンテンツも素晴らしいものだと思います。

おわりに

本書そのものについての感想ではなく、おまけとして、ちょっとメタな話をします。

Binary HacksとBinary Hacks Rebootedでは著者陣が全員入れ替わっています。前作の一部のかたが今作で寄稿者になっていたりというケースはありますが、それでもほとんどのメンバーは入れ替わっているといってよいでしょう。

低レイヤ技術というのはマイナーな分野ですが、前作から20年近く経った今でも興味を持っている人や生業にしている人がいて、さらにまったく著者陣を入れ替えても本が書けるほどの人数がまだいるという事実を見て、一人の低レイヤ愛好家として非常にうれしく思いました。

いい本を見せてもらいました。著者、寄稿者のかたがたに感謝いたします。

健康第一、インプットやアウトプットは後。持続可能な生き方を

世の中たくさんのインプット、アウトプットの機会があります。勉強会に参加したり、そこで発表したり、記事や本を読んだり書いたり…などなど。 SNSを見ると世間の多くの人はこういうことをしているように見えます。「自分もやらなきゃ」という気になってきます。 これらは自分のスキルを高めたり、同士を見つけたり、生きがいを見つけたりするよい手段だと思います。自分だけが嬉しいのではなく、 価値あるコンテンツを提供したり勉強会の運営を手伝ったりすれば、自分だけではなく周りの人もうれしいこともあります。 ただし、こういうことは、やればやるだけよいというわけではないと私は思っています。

人間は意図的に休んだり寝たりしていない限り、疲れます。いくら楽しくても心身ともに消耗します。なのでインプットやアウトプットは 自分が健康を保った上で、プラスアルファとしてやる程度といいと私は思っています。疲れてるときは、仕事が忙しいときはやらなくってもいいんです。 またできるときになって再開したらいいんです。沢山頑張りすぎて健康を害したり、業務に支障が出たりしては元も子もありません。

と…言っている私も、これについて手痛い失敗をしています。過去に勉強会の主催やら記事、書籍の執筆などを「自分がやらねば誰がやる」の精神で 頑張り過ぎた結果、体調が微妙になって方々に迷惑をかけた経験があります。その後しばらくは「これはまずい」と本業以外は何もしない時期を 数か月設けたのですが、あれは英断でした。何かに追われるような感覚がなくなってホッとして、体調はすぎに良くなりました。 記事や書籍の執筆はネタの性質上、数か月発表が遅れようが世間的に大して影響はありませんでした。勉強会は他のメンバーが沢山名乗り出て主催をしてくれて、 わたし一人がいなくてもどうにでもなっていました。「自分がいなければ」という意識はただの自惚れでした。

この後に「義務でもないことに人生を賭けなくてもいい、それでも燃え尽きてはしょうがない、できる範囲でやろう」と意識が変わったと記憶しております。 さらに「自分ひとり主催者をやらなくなって回る組織なのであったら、それは持続不可能な組織であり潰れるべくして潰れたということなんだろう」と考え方が変わりました。

長々と書いてきましたが、一番言いたかったのは、インプットやアウトプットによる成長や世のためになることを目指すばかりに、 それを活かす前提となる健康を害しても何にもならないよ、できる範囲で持続可能にやろう。ということでした。

わたしの私用PCの開発環境

わたしに声をかけてくれるIT技術者、とくに経験が浅い人に私用PCの開発環境は何を使っているかということをよく聞かれます。なにかの役に立つかもしれないので、環境を紹介しつつ、どういう思いでそうしているのかについても書きます。

私のバックグラウンドを説明しておくと、会社員として15年ちょっとLinuxカーネルの開発、サポート業務をしていました。その後6年くらい別のSaaS企業で自社インフラ用の分散ストレージの開発をしています。このストレージはLinux上で動作します。趣味ではLinuxカーネルやその周辺領域についての技術書を出したり記事を書いたり、YouTubeの動画を公開したりしています。つまりLinuxに非常に縁が深いです。

わたしはPCを2台持っています。一つめは普段使いのモバイルノートPC、もう一つはミニタワーのデスクトップPCです。ノートPCはVAIO Zで、スペックを盛れるだけ盛りました。結構高かったですけどスペックが低くて困ることは今までなかったしバッテリもよくもつので、なかなか良い買い物だったのではないかと思っています。このマシンを買った理由はPCをそろそろ買うかというときに「なんか衝動買いしたい」と思ったからです。今思えばここまでのスペックは必要ではなかったかも、と思いました。あとディスプレイを4Kにしたのですが14インチで4Kはそんなにうれしくないなと気づいたので、次はもうちょっと低い解像度にしようと思ってます。そのほうがバッテリのもちもよくなるし。

ノートPCにはWindowsがインストールされています。これはけっこう意外に思われます。なぜなら私は前述の通りLinuxに縁が深く、仕事ではLinuxばかりを扱っているからです。ではなぜかというと、Linuxデスクトップの使い勝手があまり良くないと思っていることと、使いたいソフトウェアの一部がWindowsかMacでしか動かないからです。Linuxを愛してはいますが、Windowsが嫌いというわけではないのでWindowsを使っています。いいOSだと思います。Linuxデスクトップの使い勝手云々はUbuntu 18.04にプリインストールされていたものが気に入らなかっただけなので、今は全然違うかもしれません。ただし、可能であれば物理マシン上にLinux環境を用意したいという強い思いは無いので、そのままにしています。また、オープンソースを愛していますが、身の回りのものをオープンソースで固めたいという思いもとくにないです。

「LinuxはArchとかGentooでなくてUbuntuなんだ」と言われることもあります。なんかこう、吊るしのパッケージが嫌とか、いろいろチューニングしたいなどのこだわりがあるのかと思っていた、という意味で驚かれるようです。ただ私は可能な限り環境構築で躓きたくないという思いがとても強いので、ユーザが多く、何もせずにだいたい動き、トラブったときも事例がいっぱいでてくる傾向にあるUbuntuを「楽そうだから」という理由で使っています。昔はいろいろこだわりがありましたが、数年後にめんどくさくなってやめました。

Macにしない理由は、わたしの使うものの中にMacでは動くがWindowsでは動かないというものが無いからです。昔Macbook Airを持っていたけれども、私にとってはいまいち使い勝手が良くなかったというのも理由です。音楽性の違いというやつでしょうか、あんまり深い理由ではないです。MacのCPUアーキテクチャがx86からARMになった後はバッテリが化け物のように持続するという話を聞いたのでちょっと欲しいなとも思っていますが、すごく欲しいわけではないです。あとVM上にインストールするUbuntuは作業の都合上、なるべくx86アーキテクチャのものにしたいという理由もあります。

Linuxが必要な開発はほとんどはHyper-V上で動作するUbuntu環境上でやっています。それであまり困らないのと、再起動などのマシンをどうこうする処理が楽にできるからです。さきほど使いたいソフトウェアの一部がLinux上でしか動かないというようなことを書きましたが、わたしがPCを立ち上げている時間のうちのほとんどはWebブラウジングしているか、あるいはUbuntu VMにssh接続ないし後述するVSCodeのremote development機能を使って何らかの作業をしているだけです。そう考えるとWindowsは私にとってほとんどハイパーバイザなのではという気もします。

ノートPCは自宅では1枚のデカい4Kディスプレイにつないでいます。画面がデカいほうが仕事がはかどるからです。とくにテキストを読みながら作業するときに左側にテキスト、右側に開発環境を表示するとすごくよいです。2枚以上持たない理由はとくになくて、今のところ必要と思っていないから持っていないだけです。人から「すごくいいよ」と勧められたら買うかもしれません。

LinuxでVMでは都合が悪いような、物理マシン上のLinuxでしか試せないことをすることがあります。カーネルの特定の機能を使う場合、VMか物理マシンかで大きく結果が変わるベンチマークをとるような場合に必要になります。このようなときは、もう一台のPCを使います。こちらは普段はディスプレイやキーボード、マウスは接続していないちっちゃいデスクトップPCで、Ubuntuがインストールされています。物理マシンがどうしても欲しいというのは珍しいので普段は電源を切っていて、必要なときだけ電源を入れてsshあるいはVSCodeから接続します。このマシンのCPUはAMDのRyzenですが、とくにIntelに比べてAMDが好きとかではなく、安かったからという理由だけです。

テキストエディタはVSCodeです。理由は使うのが楽だと思うからです。とくにremote development機能はWindows上のVSCodeからUbuntu VMを、まるでローカル環境のように扱えるので気に入っています。過去に比べて次第にプラグインが増えたり似たようなものが乱立したりして扱いづらくなってきていると感じますが、今のところ他の何かに乗り換えるつもりはありません。昔はEmacsを主に使っていたのですが、.emacsに色々書いたりメンテしたりするのが面倒になって、同僚が勧めていたVSCodeに乗り換えました。Vimも「VSCodeを立ち上げるにはちょっと大げさかな」というような設定ファイルをちょっと書き換えるとか、あるいは書き捨てスクリプトを作るときに使います。

最後になりますが、私が使っている環境は誰かにおすすめするものではりません。私は私なりの思いがあってこの環境にしていて、いまのところそこそこ気に入っているというだけです。みなさまも個々人の思いに従って好きなのを使えばいいと思います。