2021-12-31

2021年の振り返り

年末恒例、今年の自分の振り返りをやっていく。
普段は避けているやや政治的な意見にも踏み込むので苦手な方はブラウザバックを推奨。
またお約束ではあるが、個人の見解であり、所属する団体を代表するものではない。

今年の成果

自作OSに関する成果については以前の記事にまとめた

Rustでの低レイヤープログラミング 2021

ブログ記事などのアウトプット

今年はこのブログにこの記事を除いて4本、Zennのほうに3本の記事を投稿した。
これは去年よりも少ないことになるのだが、代わりに技術書展において去年執筆した自作OSドキュメントを改訂して同人誌として販売した

Rustで始める自作組込みOS入門：己の不学を恥じる

組込みデバイス向けのOSをRustでつくってみませんか？ Wio Terminalを題材にOS自作への第一歩を解説します。

また、技術評論社刊「ソフトウェアデザイン 2021年9月号」にて、Rustのメモリ管理についての記事を寄稿した。
こちらの記事は一部改訂して前回のブログ記事とした。

その他、Kernel/VM探検隊などのオンラインLT会での発表もいくつか行った。

と、総合すれば去年と同じくらいアウトプットを達成したのではなかろうか。
ありがたいことにTwitterでのフォロワー数も900人代まで増えているので、自分の発信している情報が有益だと思ってくださっている方が増えてきている（と信じたい）。

また、これは他の場所では何回か言っているが、自作OS本を商業誌として出すように現在ブラッシュアップ中である。やや作業停滞気味なので年明けからは本気出す。

Rust雑談会（仮）

Twitter Spacesを主に利用してRust雑談会という企画をdorayakiさんと一緒にやり始めた。
Rustに関する話題をゆるく雑談するというポッドキャストもどきのような企画で、大体視聴者は10人前後いる程度には反響がある。
内容についてはまだまだ手探り状態で、大きなテーマを用意してそれにそって話すこともあれば、小さい最近の話題を細かく話すこともある。
アーカイブもYouTubeに上げているので興味のある方はどうぞ

正直、どういうスタイルの方が需要があるのかよくわかっていないので、フィードバックをもらえると助かります。
あと、アーカイブを聞き返すと自分のトークスキルがまだまだだなあと痛感させられてつらい

来年以降の方針

アウトプットの機会は保てたと思うが、まだまだ質・量を増やしたいと思っている。
また、アウトプットの方向性もちょっと変えていきたいと思っている。
今までは内容重視でどう発信するのかについてはあまり真剣にやってこなかった。
が、これからはもうちょっと注目されやすい方法にも手を出してみようと思っている。
具体的には、技術ブログをこちらのブログで主に出していたが、これからはZennのほうに移していこうと思っている。
ZennはGithub連携により手元に記事のソースを残しつつホストできるので運営の一存で記事が抹消されたりといったリスクも少なく、いざというとき他のプラットフォームに移行しやすい。
自前のブログでホストし続けるよりかは、Zennというプラットフォームにのっかるほうがアクセスされやすくなるので、こちらに移行していく。

Rust雑談会のようなTwitter Spaces等を利用したライブコンテンツも積極的に取り組みたい。
Twitterで単発で情報を発信するよりかは、誰かとしゃべりながらやったほうがいろいろと知見を深めやすいし、アクセスする側も手軽でいいといいと思っている。

こういう情報発信にもっと力を入れたいというのはいくつか理由がある。1つは単に自分が楽しいから。
もう1つは自分の能力をきちんと示すためである。残念ながら僕はコンテストの受賞歴のようなかっこいい経歴はない。
とりあえず今の会社には評価してもらって働けているが、他の会社・組織ではどうだろうか。社内での成果はアピールしづらく、さらに自分は自己アピールが苦手である。
こう考えると、目に見える形で何かしらの成果を残しておかないと、評価を得るのは難しい。もちろん、きちんと能力を身に着けるのも大事ではあるが、世の中誰もが純粋に能力を見抜いて評価してくれるほど甘くない。
若手という肩書もそろそろ厳しくなってくる中、アウトプットの質・量だけでなく方法も変えて、評価を得ることに欲を出し始めても良いころでは、という考えがある。
もう1つは情報科学全体への貢献という観点である。自分はプライベートでも仕事でもOSSなどの広く開かれたリソースに助けられながら情報科学を身に着けてきた。
そういう開かれたリソースへの恩返しとして、自分も開かれたリソースというものを可能な限り出して情報科学への敷居を下げていきたいという思いがあったりする。

Github Sponsorsもやっているので、もし活動に賛同していただける方がいらしたら支援をお願いします。

Sponsor @garasubo on GitHub Sponsors

Support garasubo’s open source work

コンテスト

ISUCON、ICFPC、SECCONに参加した。ISUCONは予選敗退、ICFPCは去年よりは順位のいい11位、SECCONは久々の参加でありwarm up問題すら苦戦してふるわなかった。

AtCoder系の競技プログラミングは過去問を週に1，2本解く程度になってしまった。水diff程度は解けるが青diffになるとかなり解くのがつらくなってしまう。
最近、コーディングの瞬発力の衰えを感じているので、定期的に解いて行きたい。

自作PC

実は今まで性能の微妙なIntel NUCをメインの開発機としてプライベートでは開発していた。
最近、ファンの音がうるさくなってきたり、ディスクの空き容量がカツカツになったりと怪しくなってきたので思い切って今まで手を出してこなかった自作PCに手を出してみた。

初めての自作PCでノウハウが全くなかったので秋葉原のTSUKUMOに行き、店員さんの言われるがままにパーツを購入し組み立てた。
Ryzen 7+Geforce RTX 2060+メモリ32GB+PCIe 4.0 SSD 1TBでおおよそ20万円ほど。Linuxのビルドとかも視野に入れてSSDの入出力速度は重視し、コアもそこそこ強めのを選んだ。
GPUはNVIDIA Broadcastに興味があったのでそれが動く最低限のものを選んだ。

Windows+Ubuntuのデュアルブートにして、ある程度運用できているがトラブルもいくつかある。まず、Ubuntu側特有の問題として、動画や音声を再生するときノイズが入ったり音がズレたりする。
Pulse Audioを再起動すれば治ることが多いのだが、対処方法がよくわかっていなくてそこそこ困る。

致命的なのはSSDがすでに2回も謎の故障をしていることである。一回目は突然SSDとして認識されなくなり、初期不良として交換品をもらったのだが、交換品も全く同じように壊れてしまった。
一応、故障前に起動時に中に入っているOSを読み取れず起動失敗になる現象がたまに起きるという前兆があるにはあったが、2回ともそこから突然機能停止になってしまった。
店員さんにも相談したのだが、別に使っているSSDの型番やマザーボードでの故障報告が頻発しているというわけではなく、原因が未だに不明のままである。
交換品の到着にしばらく時間がかかるとのことだったので、別のメーカーのSSDを新たに購入し現在運用中で今のところ故障する気配はないが果たして…

自作PCはやはりトラブルが発生することは多く、コストパフォーマンスでいっても特別安くなったわけではない。
とはいっても、部品を選んでカスタマイズして組み立てるのは僕は楽しいと思うので、そういうのが好きな人にはおススメではある。

考えたこととか

競技プログラミング

今年の4月ごろ、競技プログラミングに関する批判の記事があり、これに関して議論が盛り上がった。

Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3

はじめに「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を…

これに対して自分の知り合いの知り合いくらいの観測範囲でものすごくこの記事をほめたたえている人も少なくなかった。
しかし、自分は当時Twitterでも軽く言及した通り全く賛同できず、なぜここまで持ち上げられるのか理解に苦しんだ。

この記事は要するに競技プログラミングではコンピューター科学の一部分しか学ぶことができなくて、Googleなどのトップ企業に入る能力を身に着けるには悪影響すらありえるということを主張している。
競技プログラミングが万能でない点については同意するが、このような議論は僕の周りの競技プログラミングをやっている人からすると「月刊競技プログラミングは役に立たない」と揶揄されるくらい度々指摘されてきた話で、
なぜ今更になってここまで盛り上がるのかが理解できない話であった。

確かに、最近はAtCoder社を中心に競技プログラミングを利用した採用だったりエンジニア教育が注目されている。そのため、競技プログラミングがこんなにも役に立った、という話題がクローズアップされやすくなってきたのかなと感じる。
が、僕らが就職活動などを控えていた2010年代前半くらいの空気感だと、そもそも競技プログラミングの知名度が低く、レッドコーダーと言われてもピンとこない、採用でも特に有利にならないということが珍しくなかった。
そのため、僕の周りのレッドコーダークラスの人間も自分の能力は業務で役に立つのだろうかと疑問を持つ人間の方が多いように感じた。
そういう疑念の反証として、こうした競技プログラミングは役に立つ、といった話が持ち上げられたという空気を僕は感じていた。

ただ、それは僕の観測範囲内だけの話であった可能性はある。
実際、AtCoder社の社長であるchokudai氏が、かなり競技プログラミングを持ち上げるような発言を連発しているイメージがあり、そういう発言に感化されて競技プログラミングに対する幻想を抱く人間が一定数いた可能性はあり、
記事の著者がそういう人たちを観測してああいう記事を書いた可能性はある。が、記事を書くきっかけになった人物として名指しされている@drken1215さんは僕も競技プログラミング関連で何度か名前を見た人だし、多分僕と同じような空気を感じていた人ではないだろうか…

議論が古いというのは観測範囲の違いとかでしかたなかったとしても、現在の競技プログラミングのあり方についての記述もかなり疑問な部分が多い。
しかも、そういう思い込みに基づいて「ホラー」だとか「カーゴ・カルト」などという形容をしているのはいかがなものであろうか。

これに対して、恐らく批判の矛先になっていたであろうAtCoder社の社長のchokudai氏が反論記事を書いている。
chokudai氏自身も競技プログラミングの限界など承知であり、そのうえで競技プログラミングにどういう価値があるかという考えをまとめているという記事になっている。
やや反論としてはズレているのではと思う箇所もあるのだが、競技プログラミングの意義・限界については納得できる内容になっていると思う。

競技プログラミングの在り方　～「競技プログラミングを我々が終わらせる」を受けて～ - chokudaiのブログ

nuc.hatenadiary.org 競技プログラミングについての言及があったのですが、バズってる＋競技プログラミングについて、納得がいかない記述がかなり多く見受けられたので、反論記事を書きました。

個人的には競技プログラミングをきっかけにコンピューター科学に興味を持ち始めて、情報科学を大学で学び、Googleやそれに並ぶような企業で働く知人を何人も観測しているので、競技プログラミングという文化そのものは非常に有意義なものであると思っている。
競技プログラミングは確かにコンピューター科学の一部分でしかないものの、その一分野の敷居を下げたAtCoderの取り組みは素晴らしいものだと思っているし、現に自分もトレーニングとしてAtCoderで出題された問題を解くことがある。
確かに競技プログラミングをやりこんだ人たちは知識が偏っていたり独特の思考に染まっていて驚くことは少なくはないのだが、それは単に入口が違うからでしかたないことだと思うし、「終わらせる」などという強い言葉でコミュニティを否定するのは違うでしょう。

正直、あの記事はchokudai氏やその周辺コミュニティへの個人的な嫉妬・嫌悪感にそれっぽい理由をつけただけのものではないだろうかとすら感じた（本人は別の記事で否定しているが、矛盾だらけの弁明に感じた）。
絶賛している人も競技プログラミングからは遠い人がメインだったし、そういうネガティブな感情から来るものという側面もあったのではなかろうか。

プログラマになるまでのルート

あの記事は主に競技プログラミングを中心にプログラマ、それもGoogleクラスのトップ企業で通用する、になるにはというものを論じていたが、それ以外にもプログラマに必要な能力は何か・どうやったら身につくのかという話題は定期的にTwitterで観測した。

自分は具体的な社名は伏せるが、一応それなりの規模をもつサービスを展開する外資系のウェブ企業に所属してウェブサービスの開発を本業としている。主にフロントエンド寄りの仕事が多い。
大学では情報科学科に入りコンピューター科学の基礎は一通り学び、競技プログラミングも嗜む程度には取り組んだ。
そこで感じるのは、必ずしも競技プログラミングのような高度なアルゴリズムを構築するような能力が必要とされる場面は限らていて、さらに言えばコンピューター科学の知識が直接役に立つ場面というのもあんまりない。
フロントエンド開発はユーザーのアクションに対してAPIリクエストをバックエンドに投げ、そのJSONのレスポンスに対応してUIをデザイナーの指示通りに表示させるようなロジックを組むのが主な仕事になる。
これを「JSONに色を付ける作業」とかジョークで言われたりするように、そこに数学的な知識とか高度なコンピューター科学の知識はそこまで役に立たない。
バックエンドのほうも、フロントエンド開発に近い領域だとデータベースや他のマイクロサービスなどからの応答をいい感じにJSONに加工して返すだけの場面が多く、こちらは「gRPCの詰め替え作業」とかジョークで言われたりする。こちらもコンピューター科学の知識は直接は役に立たない。
問題となるのは、これらの実装をいかに効率的に実現するかであるが、計算量的な効率化ではなく、機能の拡張性であったり設計の見通しの良さといった効率性がポイントとなる。
こういうところで必要になるのは、プログラミング言語やそのドメインに特化したライブラリやツールの使い方のような知識だったり、設計のベストプラクティスのようなものがメインになる。
こういうものは実際に業務での開発経験や、そのドメインの最新情報をブログや勉強会などでキャッチアップすることが多い。コンピューター科学の基礎的な勉強とはかなり距離がある。

じゃあ、競技プログラミングやコンピューター科学の勉強は無意味であったかというとそうではない。機会は少ないといったが、変なところ（ライブラリ内のバグ・インフラの故障）でトラブルが起きた場合に役に立つのはコンピューター科学の知識だったりする。
また、ドメイン知識の習得を下支えするのは基礎能力やコンピューター科学の知識であるとは感じる。
競技プログラミングが一定以上できる人間は、一度知識さえ身に着ければそこそこのスピードでこれらの業務をこなしてくれる。
こういうのを考えると、ある程度のプログラマであれば必ずしもコンピューター科学の知識を身に着ける必要はないかもしれないが、Googleなどのトップクラスを狙うのであれば無関心でいるというのは厳しいのではないか、と考えている。

他にも数学能力の必要性も議論されたりする。確かに自分のウェブフロントエンドの領域に限って言えば直接役に立たない場面が多い。
が、やはり下支えしているのは数学的な能力ではないのかなあと思っている。
前述の記事では東大理Ⅲ出身の医者をGoogleに入れたとあったが、東大理Ⅲ出身ともなればかなり数学の訓練は積んでいるはずである。
また、知り合いでGoogleなどの企業に入るなど高いプログラミング能力の人たちは、プログラミングを始めたのは大学からという人も結構いる。
昨今、年齢の若い内のプログラミング教育がよく話題になるが、個人的には本人のある領域があればどんどんプログラミングの世界に踏み入れるのは大賛成であるが、
焦ってプログラミングを始めてドメイン知識の習得に努めなくてもいいのではないかなあと思うし、数学教育のような基礎の重要性は変わらないと思う。
また、もともと数学（高校レベルあたりを想定）が苦手でさっぱりという人間が社会人になってからプログラミングで頭角を表す、みたいなのは厳しいのではないかなあとか思う。

数学力やコンピューター科学の知識は下支えになるとは言ったが、やっぱり最後は実践経験を積んで強くなるしかないとは思う。
その実践経験を積む方法として、会社に入る以外の方法だと、競技プログラミングは一つの選択肢になるとは思う。
AtCoder系のショートコンテストだと書くコードは非常に短く、問われるのはアルゴリズム寄りの知識がメインとなり偏ってしまうが、他にもプログラミングコンテストはいくつもある。
ISUCONだとウェブ系のドメイン知識が必要になり、競技時間も長くデバッグ能力・問題分析能力なども実践を通して問われる。
ICFPCの場合、多くのチームが問題専用の各種ツールを用意することが多く、そういうツールの開発を通じて得るものも多いだろう。
SECCONなどのCTFではセキュリティや低レイヤーの知識を問われることが多く、それらを手を動かして試す絶好の機会になるだろう。
その他、最近は自作OSや自作CPUなどの自作〇〇が流行っている（気がする）。これらの書籍・ドキュメントを入門として実際に自作〇〇をすると、今まで本で読んだだけの部分の理解がグンと深まる。
自分の例で言うと、自作ハイパーバイザをつくったときにメモリ管理ユニットの仕様書を読みながらコードを書いたのだかが、ページングのCPUの提供している機能を生で触ることができて、授業で習ったこととリンクして非常によい経験になった。
OSSへの貢献、ウェブサービスを自分で開発してみるなど他にも実践の機会はそこら中にあり、無料でアクセスできるリソースも多い。
僕はコンピューター科学は実践してなんぼ、と信じているのでやはり手を動かすというのはなんだかんだ大事だと思うし、その過程でコンピューター科学への理解も大事にしてほしいなと思う。

コインハイブ裁判

地裁で無罪判決が出てから高裁で逆転有罪となっていた所謂コインハイブ裁判が最高裁での審理が始まった

PC無断利用し暗号資産獲得最高裁で有罪判決見直しの可能性も | NHKニュース

【NHK】サイトを閲覧した人のパソコンを無断で利用していわゆる仮想通貨＝暗号資産を獲得するプログラムが違法かどうかが争われ、1審は…

以前も何回か主張してはいるが、このコインハイブ利用による検挙と高裁での有罪判決にはかなり疑問を持っている。
とはいうものの、自分は法律関係の知識は高校とかでの一般知識程度に留まっていて、法律の観点からどこが問題かを正しく解釈できているかに100%の自信はない。
また、コインハイブ裁判に関わらず、この手のプログラマを標的（？）とした検挙というのはよく話題になったり、またプログラミングに関わらないが日常のひょっとしたことから警察のお世話になってしまう話なども流れてくる。

そういったトラブルへの備えと、そのような法律に関する知識をもとに自分の考えをまとめたいという思いから、最近法律系の本を読んだりしている。

現在読み進めているのは「法解釈講義」という法学部生の教科書としても使われている本だ。内容が濃く理解するのはやや大変だが、これといった専門知識もなく読むことができおもしろい

法解釈講義（POD版） - 東京大学出版会

また、「Wizard Bible事件から考えるサイバーセキュリティ」のほうも購入した。
こちらは近年の疑問視されたセキュリティ関連の裁判の総まとめとなっていて、とてもおもしろいのだが、警察・検察の理不尽な取り調べの部分は読んでいて不快感が強い。将来警察・検察とは縁がないことを願いたい。

Wizard Bible事件から考えるサイバーセキュリティ - PEAKS

法律と技術の関係はたびたび問題になるにも関わらず、なかなか改善の兆しはない。司法側の問題もいろいろあると思うが、近年だとウェブ開発側の倫理を問われることも多く、欧米では各種規制が進んでいるが日本ではなかなか進んでいない。
自分もウェブ開発でお金を稼ぐ身としてはきちんと自分の意見を持って、邪悪な開発に手を染めないようにはしたい。

最後に

新型コロナの流行以来制限の多い生活が続き、今年もなかなかに息苦しい一年であった。
確かにワクチン接種が進み、流行も一時期落ち着いたりして制限がゆるくなってきた分野もあった。
自分は商業誌への寄稿といった新しいチャンスを得ることもあり、恵まれているほうなのであろう。
とはいっても、つらいものはつらく、在宅勤務でのパフォーマンス低下は以前はそこまででもなかったが最近はかなり集中するのが難しくなってきたように感じられる。
YouTubeやらTwitterやらをなんとなく眺めて時間をだらだらと過ごすことも多くなってきてしまった。
生活リズムもかなり乱れ始めていたりして、これらはなんとか改善したい。

年齢的にも若手を名乗るのには厳しくなってきているので、もっと貪欲に新しいことに手を出したり成果を形にすることに注力したいと思う。

と、雑にいろんなことを書き殴ったが、来年もいろいろとやっていきたいので、何卒宜しくお願い致します。