2020-08-10

重要そうだけど興味のないことを頑張っても大していいことなかった話

時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。

10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinux カーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。

ところがこれが大失敗。本を読んだりラズパイを買ったりしてみたものの大して熱がこもらず大した知見が得られないままに時間を浪費するというありさまでした。ここで何がまずかったのかを振り返ってみたところ、一番の原因は「ARM,もっというとCPUのアーキテクチャに大して興味がない」ことと、「好きなこと、やらないといけないことしかできない」という自分の特性の強さをあなどっていたということでした。気づいてしまえは当たり前で、やる前に気付けよといったところですが、当時は焦りからか非常に視野が狭くなっていたのでしょう。

この後は考え方を変えて、次のようにバッサリと割り切りました。

今持っている技術が陳腐化しそうになったら、その時はその時、追い詰められたら奮起する能力は持っているのでなんとかなるだろう
一番興味があるものから順番に学んでいれば将来それらに活路が見いだせるかもしれない
無理して頑張っても、楽しく学んでいる人にはどのみちかなわない

この変心が正解というつもりはまったくないですが、将来の来るかどうかわからない危機に対して確実でもなんでもない備えを苦痛に耐えながらやり続けるよりも、楽しいと思えることを効率よく学べている今のほうが幸せだとは思います。

この文書がわたしと似た特性を持つ人に参考になれば幸いです。おわり。

2020-08-01

DeepLで論文を邦訳して読んだ

以前日本からはDeepLは課金できなかったんですが、少し前にできるようになりました。

satoru-takeuchi.hatenablog.com

その記念といってはなんですが、Webブラウザのテキストボックスに入れた文書を訳すのではなく"Translate whole files"というファイルを丸ごと翻訳する機能を使ってみました*1。

私が今回この機能を試す際に使ったのは"Decoupling Cores, Kernels, and Operating Systems"という未読の英語論文です。

www.usenix.org

なぜもっと一般的な文書ではなくわざわざ論文なのかというと、理由は2つあります。1つは単に他に別に読みたいものが無かったこと、もう一つは、未読の英語論文を計算機が邦訳したものをどれだけ理解できるかに興味があったからです。

さて、この論文はpdfとして公開されているのですが、残念ながらこの機能で現在訳せるのはwordのファイル、powerpointのファイル、そしてテキストファイルだけでした。しょうがないので次の方法を使いました。

pdfをgoogle docsに食わせる
docxにexportする
docxをDeepLに食わせる

で、それっぽい日本語が出てきたので喜び勇んで読み始めたら、何を書いているか全然わかりませんでした。文法的に日本語として成立しているけれども何が書いてあるかはわからない、といったところでしょうか*2。技術カンファレンスにおける技術者ではない翻訳のプロによる同時通訳くらいのものを思い浮かべてもらうといいかもしれません。

「これで英語理解できなくても英語論文が読める！」なんというのにはほど遠いですが、翻訳ソフトはここまでできるようになったのか、と感心してしまいました。すごい。

最後になりますが、たぶん専門用語が少ない文書ならもっといいのが出てくると思います。

*1:無料版でも使えるんですが、文字数が限られるらしいです

*2:その後英語で一ページ目を読んだらちゃんと理解できる内容だったので、読解に必要な能力不足というわけではないはず

2020-07-22

github sponsorでスポンサー募集することにしました

以前よりわたしはOSS、とくにLinux カーネルなどのハードウェアに近い部分のものについての普及活動にライフワークとして取り組んできました。そのうちの一部は書籍として販売して印税を受け取ったり、雑誌に掲載してもらって原稿料を受け取ったりしてきましたが、ほとんどのものは無償で公開しています。この無償で公開している部分についてgithub sponsorsを使ってスポンサーを募ることにしました。

github.com

github sponsorsで支援を受ける人といえばOSSのコードやドキュメントへの貢献者というイメージがあるでしょうが、私はOSSおよびその関連技術についての普及活動をする人、として登録しました。なぜこういうことをするかというと、理由は大きく2つあります。

1つ目は単純に「お金ほしい」です。お金をもらわなければ活動をやめなければいけないといった切羽詰まった話では全然ないのですが、趣味とはいえ限りある可処分時間*1を費やして人のためになるであろうコンテンツを提供しているので、可能であれば対価を受け取りたいと思っています。

2つ目は私の好むお金の流れを作れないかなという実験です。私は常々、お金は余裕のある人や年長者から余裕のない人、若者によどみなく流れていくのがよいと思っています。この考えをもとに、私が提供するコンテンツが後進のために有用だと思ってくださるかたに支援していただき、コンテンツを必要としているかたがたに無償で提供する、というような流れが作れればと思っています。

スポンサーが増えたらどうなるかというと額にもよるのでなんともいえませんが、たとえば次のような展開が考えられます。

コンテンツの更新頻度が増える
いままで有償で公開しようと思っていたものを無償公開することが増える
コンテンツの英訳をする(現在はほとんどが日本語)

2022/10/11追記上のリストには、もともと"- youtube動画コンテンツを収益化しない(つまり広告を出さない)。現在は収益化条件を満たしていないので広告は出ませんが、いまのところ条件を満たせば収益化する予定でいます"という文書がありましたが、いまいち何言ってるかわかりづらいし、そもそも誤解に基づいた記述だった(実は今は収益化してなかろうと広告が出る)ので消しました。

どうなるのかよくわかりませんが、わたしがやっていることに賛同してくださるかたはぜひご支援いただけたらと思います。

以下、いままでやってきたことリストです。

書籍(有償)

www.amazon.co.jp

技術同人誌(有償): 以下URLのうち著者名が「武内覚」のもの

windhole.booth.pm

youtube動画

www.youtube.com

記事の一部(はてなブログのものは検索性が悪いのでいずれgithub上にコピーする予定です)

employment.en-japan.com

Software Design 2018年5月号～2020年8月号に連載された「Linuxのしくみ」

satoru-takeuchi.hatenablog.com

*1:具体的なことをいうと私は週の時間のうち3/4は所属している会社の仕事に、残り1/4をこの活動に充てています

2020-07-18

色々できるとおもわれがちな人ができないこと

はじめに

以下記事の続きです。実例編といってもいいかもしれません。

satoru-takeuchi.hatenablog.com

完璧超人とまではいかないでしょうが、わたしも次の理由によりSNSなどでは「いろいろできるすごい人」「低レイヤに詳しい人」と思われがちです。

Linux カーネルに詳しい。カーネルに詳しい人は無条件でなんでもわかっていると誤解されることが多々ある
自分あるいは自分が所属している組織の成果をよく宣伝する。このため、そういうことを好まない人に比べて「何かできる人」という印象がつきやすい
twitter上でそれなりに認知されている、かつ、twitter上で様々なすごい人とよく話している。「すごい人と話しているとすごい」と思われがち。

本記事の趣旨は、その私が世の中で想像されるほどいろいろできるわけではない、できることは限られているということを書いてみようということです。自分の弱みをわざわざさらけ出すと商品価値を下げることになりはしないかとも思いましたが、できないことをできると思われても困るので試しにやってみることにしました。

あまり多くの分野について話してしまうと焦点がボケるので、わたしが主戦場としているいわゆる低レイヤ技術について、さらにその中の独断と偏見で選んだ数個のものに絞って話します。

OSカーネルについて

Linux カーネルについては、プロセススケジューラはだいたいわかる、ブロックデバイス、一部ファイルシステムについてはそこそこわかる、といったところです。このあたりは過去に開発、サポート経験がたくさんありますので、upstreamのLinux カーネルの開発をゴリゴリやることもできますし、トラブルが起きても半分以上は一日以内で解決できる自信があります。それ以外の部分についてはかなりの濃淡がありますが詳細は省きます。

明確に苦手というところについても書いておきます。たとえばTCP/IPなどのネットワークに関するところは、そもそもカーネルどうこう言う前にネットワーク技術に関する経験が浅いので、よくわかりません。ハードウェアに近いところについても明るくないです。デバイスドライバについてはまともに書いたことがないです。

Linux以外のOSのカーネルについてはOSSであれば参考に見ることはありますが、これらのコードを読み解いてupstreamに取り込まれるコードを書けるレベルではまったくないです。

自作OSについて

過去にOSカーネルは二回実装したことがありますが、どれもオモチャといっていいレベルです。カーネルの上にUNIXライクなシステムを載せられるような本格的なものを作ったことは無いです。あくまでハードウェアおよびOSカーネルについての最低限の知識を得るための手段としてやっただけです。

OS自作を趣味としてやっている人を横目に見て凄いな、楽しそうだなと思う一方で、わたし個人としては特別な思い入れはないです。

バイナリアンかどうか

バイナリを直接扱う能力は持ち合わせていません。ここでは16進ダンプを見て必要な情報を見つけ出す、いわゆる目grepの能力について述べます。目grepについては次の2つの記事が詳しいので、知らない人は一読ください。

satoru-takeuchi.hatenablog.com

note.com

2つ目の自分で書いた記事にも書いていますが、わたしはこの手のことが息をするようにできるわけではありません。訓練によって一部についてはできることがある、という程度です。

コンパイラが書けるかどうか

まともなコンパイラは書いたことがないです。最近興味が出てきたので、以下ruiさん本で勉強中です。

www.sigbus.info

構文解析や字句解析については上記ruiさん本や、UNIXプログラミング環境に記載のhocの章に書いてあること以上の知識は持ち合わせていません。

アセンブリ言語が扱えるかどうか

読むほうはx86_64ならば簡単なものなら読めます。しかしカーネル内に出てこない浮動小数点演算についてのコードはマニュアルを見ながらでないと読めないです。最近のCPUに追加されたようなかっこいい命令は全然わかりません。書くほうについては必要に迫られて書くことは稀にありますが、苦手、かつ、遅いです。「アセンブリ言語が苦手なのにLinux カーネル屋さん？」と思われるかもしれませんが、Linux カーネルのほとんどはC言語で書かれている、かつ、わたしが得意とするのはハードウェアから遠い部分なので、さほど困らないのです。

好き嫌いの話をすると、あんまり好きではありません。コード量が多くなりがちなことと、および、実現したいロジックだけではないCPUの実装の都合によって追加で考えなくてはいけないパズル的要素が多いのがその理由です。

おわりに

本記事を読むことによって、わたしはできるところはすごくできるけれども、それ以外は別にそうでないことがある程度わかっていただけたのではないかと思います。とくに、いままで私を過大評価をしてくださっていたかたにこれを読んでいただいて、「なんでもできると思っていた人が実はそうではないんだ」や「低レイヤですごいっていうのは雑なくくりだった」などと認識をあらたにしていただければ嬉しい限りです。それとともに、完璧超人と戦って疲弊している人の心を少しでも軽くできれば、とも思います。

2020-07-11

sleepコマンドの足し算機能

GNU coreutilsに入っているsleepコマンドにはマニアックな機能がいくつかあって、そのうちの一つが「引数を2つ以上指定できて、それらの引数をすべて足した秒数だけ待つ」という謎機能です。以下Ubuntu 18.04のman sleepより抜粋

SLEEP(1)                                                       User Commands                                                       SLEEP(1)

NAME
       sleep - delay for a specified amount of time

SYNOPSIS
       sleep NUMBER[SUFFIX]...
       sleep OPTION

DESCRIPTION
       Pause for NUMBER seconds.  SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days.  Unlike most
       implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.  Given two or  more  argu‐
       ments, pause for the amount of time specified by the sum of their values.

何に使うのかよくわかりませんでしたが、足し算に使えるそうなことがわかりましたので、やりかたを書いておきます。たとえば「1+5+2の答えは一体なんだったっけ…まったく思い出せない」という場合に以下のコマンドを使えばたちどころに答えが得られるというわけです。

$ time sleep 1 5 2

real    0m8.002s           # 答えは8!
user    0m0.001s
sys     0m0.000s

仕組みは簡単で、引数を足した値sleepしてくれるということは、timeコマンドを使ってsleepを実行すると、実行にかかった経過時間(real)は引数の値をすべて足したものに若干のオーバーヘッドを加えたものになるだろう、という話です。

本日公開した動画で「sleepコマンドは指定した秒数のぴったり後に終了するわけではないよ」と主張した舌の根も乾かぬうちにこういうのを書くのもどうかと思いましたが、まあ、細かいことはいいんです。

youtu.be

なお、知ってる人は知ってると思いますが、このネタは一時期話題になったsleep sortのパクりです。

www.geeksforgeeks.org

まじめなことを書くと、これについてtwitterでつぶやいていたら以下のようなご意見をちょうだいしました。

単に数値の足し算をするときではなく秒を示す"s"などのsuffixを付けて*1"sleep 4m 33s"と書くような場合に便利
浮動小数点数の計算をsleep内でやってくれると便利かも(bashは整数演算しかできない)
"sleep <ベースの値> <乱数>"のようにスリープ時間にゆらぎを持たせたいときに便利そう
複数の乱数を組み合わせて正規表現分布する時間スリープしたいことがあるかも

みなさんすごいですね。わたしは足し算しか思いつかなかったです。

*1:これもGNU 拡張機能

2020-07-05

チャンスをつかむということ

はじめに

「幸運の女神には前髪しかない」という言葉があります。女神(チャンス)が目の前にあらわれたときにつかんでおくべきで、過ぎ去った後に「やっぱりちょっと待って」と掴もうとしても掴むところがないのでもう遅い、というような意味です。うまいこといいますね。今日は人生において目の前のチャンスをダボハゼのようにつかみつづけてきた自分の過去の一つの経験談をもとに、チャンスについての話をします。まずは自分語りからはじめて、その後に、そこから得られた教訓について話します。

自分の過去の経験

話はわたしの最初の就職、いわゆる新卒入社についてのものです。当時大学院生だった私は色々あって「なんとしてでもLinux カーネルの開発を仕事にする」と意気込んでいました。その動機については本筋ではないので省略します。幸運にも当時は国内サーバベンダが「Linuxサーバやるぞ！」と意気込んでいた時期でしたので、その手の仕事も存在していました。

しかし、ここで一つ大きな問題がありました。当時のわたしはコンピュータを扱う学科には在籍しておらず、材料工学を学んでいました。この状態で何も考えずに応募しても、私にをカーネル開発の能力、あるいはそれができるようになるためのポテンシャルを持っているか、面接官から見ると極めて疑わしいことは明白でした。なんとかならないかと考えていた時、友人から「インターンというものがある」と聞きました。今でこそインターンは当たり前ですが、当時は今ほど誰でも行くようなものではなく、かつ、わたしはそういうものがあることすら知らなかったのです。幸運にもわたしが受けたかった会社のLinuxを開発している部署はインターンを募集していました。

当時プログラミングの経験はあったものの、学科内にはそのような友人はおらず、コンピュータ関連の学科にも知り合いはいなかったため、自分の能力がどの程度のものかがわかりませんでした。ここも現在と違っていて、twitterなどのSNSや勉強会を通じて同志に出会うというのはなかなか困難でした。「応募したとして私には先方に求める能力があるのか」「何もできなくて大恥かいたらどうしよう」「そもそも畑違いの私が受かるのか」など、応募するかどうかは相当ためらいましたが、最終的には「自分のできることと熱意を精一杯書き連ねて応募するしかない、自分はこれをどうしてもやりたかったんだからやらない理由はない、落ちてもダメージは無い、あとは知らん」と、応募しました。

余談ですが、応募用紙には自分のできることはおろか、かなり盛ったものを書きました。当時の面接官であり、その後の上司でもあった皆様、今謝ってっておきます。すいません。

閑話休題、その後インターンに行ってみると私は幸運にも大きな成果を出し、その後無事に希望の会社、希望の部署に就職できました。つかんだチャンスを見事モノにしたというわけです。ここまでが自分語りです。

経験から得られた教訓

前節で述べたことから私が言いたいのは、「俺はできる人だ」という自慢ではなく、そういう人であっても、一歩足を踏み出してチャンスをつかまないと、そもそも勝負にならないということです。当時インターンに応募しておらず、かつ、後になって「やっぱりあきらめきれない、応募しよう」となっても、かなり困難な道が待ち受けていたでしょう。

もう一点、わたしが大きな成果を出せたのは「Linux カーネル開発者になりたい」という思いを実現するために大学の勉強や研究そっちのけで(当時の先生方、今謝っておきます、本当に申し訳ありませんでした)関連知識を身に着けるという準備をひたすらやっていたからです。チャンスは目の前にあらわれたときにつかむだけではなく、つかんだあとに成功に結び付けるための下準備をしておく必要があるのです。

ここで「それはあなたの頭がいいからできたんでしょう？」というかたがいるでしょう。しかしながら、少なくとも私は学校の勉強と言う意味では劣等生であることが多かったです。実際材料工学を学んでいた理由も大学受験でコンピュータを扱う学科に落ちたからです。「コンピュータには適正があったからでしょう？」といわれるかもしれません。これは実際にそうだと思います。ただ、これもやってみなければわからなかったことです。やる前からあきらめるのは得策ではありません。

おわりに

チャンスを何も考えずに全部つかもうとすると大失敗してひどいめにあうこともあります。実際わたしも明らかに実力不足だったにもかかわらず無理してチャンスをつかもうとしてひどいめにあったことも多々あります。なので「チャンスは絶対つかむべき」などということは言いません。しかしながら、いったんつかんでみて、失敗してもたいしたダメージが無いのであれば、どんどんやってみていいのではないでしょうか。というのをtwitterで未踏やらセキュキャンやらGSocやらに応募するかしないかで悩んでいる学生さんなどを見て書いてみたのでした。

2020-07-04

100分de名著を読み始めての感想

数か月前に以下のブログを読んでから100分de名著シリーズを読むようになりました。

anond.hatelabo.jp

なにかしら自分の世界が広がることを期待して、できれば自分が普段絶対に買わないであろう本をあえて狙って買うようにしました。だいたい今50冊くらいを読んだところでの感想を書いておきます。

まずは狙い通り多少なりとも自分の中の世界が変わりました。あるいは変わるきっかけをつかめました。「なるほどこういう考え方もあるのか」「こういうジャンルがあるのか」「こんな人がいるのか」と思うことが多々あり、自分のすき好むものだけに触れているだけでは出会えないものにたくさん出会えたかと思っています。一部については実際に取り扱われている本を買いもしました。もちろんテキストだけ読んでもその本で書かれていることの最深部にたどり着くなんていうのは不可能だとは思いますが、これらの本を手に取るきっかけになるだけでも価値がありました。

その他に興味深かったのは解説者のひととなりがうかがえたこと、および、解説されている本を手に取ってみようかという判断にそれが大きく関与したということです。「この人は本当にこの本が好きなのだな」「とにかく読書が好きなんだな」ということがわかると、解説の熱量におされて解説内容そのものよりも「この人が勧めているのなら一度読んでみよう」という気になったことがよくありました。場合によっては、解説者の成果物を手に取ってみたくなることまでありました。その一方で、「この人は、この本を読んでいる自分が好きなんだな」「本はどうでもよくて自説の御開帳ができればそれでいいんだな」ということもありました。この場合は、解説者はもとより、解説されている本への印象もとばっちりで悪くなってしまったこともありました。私は本に対する読む前の印象が紹介してくれた人への評価によって大きく変わることがわかったのは、とてもよい体験でした。

一冊数十分で読める新書より軽く読めるものなので、今後もゆるゆると読み進めていきたいと思います。