実体の無い完璧超人と戦っていた過去の失敗談

かつての失敗談。ついった初めたばかりのころにはまった次のような悪い循環です。

  1. すごい人をたくさんフォローする
  2. すごい人達がすごいこと言ったりやったりする
  3. それに比べて自分は大したことできないと自信喪失する
  4. 何もしなくなる

フォローする人が多くなればなるほどこの傾向は加速していきました。なぜかというと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。

たとえば次のような3人をフォローしたとします。

  1. RDBにめちゃくちゃ詳しい人
  2. カーネルめちゃくちゃ詳しい人
  3. 特定のプログラミング言語にめちゃくちゃ詳しい人

ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。

この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした。彼らは実際にはそれぞれに得意分野があって、そこから遠い分野の技術はほとんどの場合は苦手、あるいは全然知らなかったのです*1。これを知ったときは妙に安心したことを覚えています。それに加えて、私が上記のような罠に陥っているのではないかと指摘してくれる人もいました。今思えば、彼らも過去に似たような罠にはまっていたのかもしれません。

その後、「自分もここなら詳しい」という部分ができてきたこともあって、徐々に自信を取り戻してきて、今に繋がっていきます。

今同じような罠にはまっている人がいるとしたら上記のことを参考にして、少なくとも実在すらしない謎の超人と戦うのはやめるだけで、かなり心が楽になるのではないかと思います。

*1:たまーに本当に何でもできる完璧超人もいたのですが、それはそれ。見なかったことに…

プログラミングでつまづいてきたこと

プログラミング初心者に対してどういう情報が役立つのかをぼんやり考えていると、そこそこコードを書けるベテランが、いつ、どういうことにつまづいてきたのかを書くとけっこう有益なのではないかと思ったので書きました。これを読むと直接プログラミング能力が上がるわけではないですが、「ああ、こういうところでつまづいてもいっぱしのプログラマになれている人もいるのだな」と思ってもらうのが目的です。成功談よりも失敗談のほうが役立つとよく言われますが、それと少し似ているのかもしれません。

全段落で「いっぱしのプログラマ」とか言った手前、自分のことを書いておきます。18歳ごろから20年くらい前からプログラミングをしていて、主に有名どころのOSSに向けてコードを書いてきました。昔はLinuxカーネルを10年少々やっていて、ここ最近はCephオーケストレータであるRookの開発とかをしています。プログラマとしてはスーパー優秀とは言えませんが、そこそこは書けます。

では、本題。長ったらしく文書にはせずに、ずらっと列挙します。だいたい上が古くて下が新しいです。後から思いだしたら追記するかもしれません。

  • ポインタが理解できなかった(18歳ごろ?)。メモリのイメージがまったく頭に無かったので参考書を見ても何が書いてあるのがわからなかった。printfで変数のアドレスやポインタの値、それを加減した値などを出力しまくって理解した。
  • 再帰、末尾再帰クロージャ、メモ化が理解できなかった(20歳ごろ?)。大学に入ってLISPというのがあるらしいと知って書店でSICPを買って読み始めたら何もかもわからずに絶望した。紙に状態遷移図を書きまくってようやく理解した。
  • 「オブジェクト」の意味が多いので混乱した(20歳ごろ?)。具体的にはコードのかたまりであるオブジェクト(ファイル)とオブジェクト指向言語のオブジェクト。何冊か本を読むとようやく別物だと理解できるようになった
  • 「スタック」の意味が多いので混乱した(20歳ごろ?)。具体的にはデータ構造としてのスタックとメモリ上のスタック領域。上記と同様、何冊か本を読んでようやく理解した。
  • 「ヒープ」の意味が多いので混乱した(20歳ごろ?)。具体的には動的メモリ領域としてのヒープとヒープソートのヒープ。これは気にしないでおこうと思って放置していたら、数年後に全然別物と知った。
  • アセンブリ言語がわからない(22歳ごろ?)。レジスタとメモリの違いがわからなかったし、関数呼び出し規約を知らなかったので、いつ何を使っていいかがわからなかった。アセンブリ言語プログラミングの本を数冊読んでやっと理解した
  • なんでも(OOPLという意味での)オブジェクトで表現すべきと思い込んで四苦八苦した挙句プログラミングが楽しくなくなった(23歳ごろ?)。その後、よくわからないうちに飽きたので自縛から解けた。
  • C++演算子オーバーロードとテンプレートを使うとかっこいいという思いがあって無意味に使っていた(23歳ごろ?)。「一体何をやってるんだろう」という気分になってきてやめた

わたしが主にC言語などの高級とはいいがたい言語を中心に使ってきたこともあって最近プログラミングを始めた人にとってはピンと来ない言葉もあるかもしれませんが、そのへんは無視してもらっていいです。

最後になりますが、プログラミング初心者は何かにつまづくと「それくらい知っていて当然」とか「これが理解できない奴はセンス無い」とかいう暴言が飛んできがちですが、狂犬が吠えていると思って無視しましょう。

qiitaにある自分の記事がガイドラインに沿っているかどうか確認した話

先日qiitaのサポートに自分の記事がガイドラインに沿っているかどうか確認しましたので、その結果について書きます。すでにqiitaに記事を書いていたりこれから書こうとしているかたに本記事が事例の一つとして参考になればうれしいです。なお、本記事ではガイドラインにグレーゾーンがあること、およびその運用方法の是非についての話はしていません。

qiitaにはコミュニティガイドラインというものがあります。雑な書き方をすると、これに沿ったものが適切な記事、沿わないものは不適切な記事であり、後者は場合によっては限定公開になったり削除されたりする可能性があります。前者の典型的な例はプログラミング技術についてのみ書いたもの、後者の典型的な例はダイエットに抜群の効果があると謳った謎サプリメントの宣伝文書などでしょうか*1

help.qiita.com

わたしはこれまで50本近くqiitaに記事を投稿してきました。どれもわたしの解釈では上記ガイドラインに沿ったものでした。しかし、ガイドラインに沿っているという解釈もできる記事が限定公開になったり非公開になったりする例を過去に何度も見てきたので、自分の過去記事の中からグレーゾーンにある以下のものについてガイドライン違反をしていないかどうか、サポートに問い合わせてみました。

qiita.com

qiita.com

qiita.com

これらをグレーと判断した理由は、コードが一行もないなど直接プログラミングの話をしていないからです(以下ガイドラインからの引用)。

私たちの認識としては、技術的な内容が記事の主目的である限りは、「プログラミングに関係ある」記事だと考えています。

例えば「厳密にプログラミングとは言えない記事」「プログラマーのライフスタイルに関する記事」など判断に迷う場合は、「技術的な内容が主目的かどうか」を基準として考えています。

問い合わせの結果、幸いにも数日のうちに以下の通り問題ないという回答を得ました。

ご提示いただいたsatoru_takeuchi様の記事は、いずれもコミュニティガイドラインに違反しないと弊社は考えます。

単純に 「コードがない = プログラミングに関する記事とは言えない」 とはしておらず、
技術的な内容が記事の主目的である限り(プログラミングを行う上で必要になる考え方や
成功事例・失敗事例など)は、「プログラミングに関係ある記事」と考えております。

おかげで気持ちもすっきりしたし、既存記事を自分のブログなどに移動させる必要がなくなったので助かりました。よかったよかった。

*1:「プログラミング以外の内容は投稿しない」と「宣伝や販売を主目的とした記事は投稿しない」に違反

一年の振り返り

年末なので手短に一年間の振り返りをします。

会社の仕事はぼちぼちでした。夏までは色々あって当初想定していたほどプロジェクトに貢献できなくて苦労しましたが、それ以降はOSSコミュニティ活動がはじまったので自分の持ち味を最大限に活用できるようになりました。来年はさらに飛躍をしたいなと。めざせRookメンテナ。

個人事業主としては少し広がりました。まずは例年通り、春と秋の技術書典に新刊を出し、Software Designの連載「Linuxのしくみ」も12月原稿を落とさずにやりとげました。去年出した前記連載と同名の書籍が一年を通してじりじりと売れ続けたのはとてもうれしかったです。それ以外には単発の仕事としてWeb上に「いま知っておきたLinux」という記事を書きました。これはたくさんの人に読んでもらって、かつ、想定読者に刺さったようなのでよかったです。書籍の次回作も仕込みをはじめたので、来年以降うまく原稿を完成させて発売にこぎつけられればと思います。

私的な出来事としてはソフトウェア開発とは関係のない趣味が広がりました。具体的にいうと次の二つです。

  • ミラーレス一眼を買いました。おもに息子や風景、動植物などを撮りまくっています。レンズもあれよあれよというまに5本生えました。レンズってほんとに生えるんですね。
  • コーヒーを豆から挽いて淹れる。カップをはじめとして自動ミル、手動見る、サーバー、携帯用のドリッパーやケトルなど、いろいろ揃えました。在宅ワーカーなので日々の楽しみが増えてとても幸せです。

これまで頭の疲れない趣味を探しては失敗し続けていたのでとうとう手に入れた、という思いです。

その他にはノイズキャンセリングヘッドホンを買ったのがとてもよかったです。詳細は以下の記事を参照。

satoru-takeuchi.hatenablog.com

来年も無理せずできる範囲でやれることをやります。

30分で論文流し読みシリーズ 8「Multi-hypervisor Virtual Machines: Enabling an Ecosystem of Hypervisor-level Services」

https://www.usenix.org/system/files/conference/atc17/atc17-gopalan.pdf

  • 実際の所要時間

    • 二時間
  • 課題

    • IaaSでは(仮想)ハードウェアを含め多種多様なサービスを組み合わせて使えるようになっているが、VMMレベルのサービスはそうではなく、通常はベンダ提供の単一のものを使う。
    • 多種多様なVMMレベルのサービスを同時に複数使いたいとすると、次のような方法を使う必要がある。
      • 必要なだけ機能を詰め込んだVMMを作る: VMMが大きすぎることがセキュリティリスクになる
      • メインVMMからモジュール形式でサービスを提供する方法: 実現できる機能に限りがある。ページマッピングやVCPUのスケジューリングなどの低レベルの機能を提供するのが難しい。
      • VMMを好きなだけネストする: ネストが深ければ深いほど性能劣化が激しい。それに加えて、あるVMMから見てguestまでのレイヤが厚ければ厚いほどguestから得られる情報が減る。たとえばメモリのコンテンツなど。
  • 解決方法概要

    • Span-virtualizationという新アーキテクチャを採用したVMMを使う
      • 無改変のguestに対して、より細かいVMMサービスを提供できる
      • 個々のguestに対して別のサービスを提供できる
  • 解決方法詳細
    • メインVMM(L0)を用意して、その上にguestおよび各種サービス用のVMM(L1)を任意の数だけ配置する
    • guestはL0上に直接乗っているので、L0から見えるguestのメモリはすべてL0を介してL1に見せられる
    • L1が制御できるリソースはメモリ、VCPU、I/Oデバイスの3つ   - メモリ: 各L1にguestの物理メモリ上の任意の領域を割り当てられる。guestの物理メモリに対して所定のイベントが発生すると、イベントが発生したメモリ領域に対応するL1にその旨通知する
      • VCPU: 全CPU上の全VCPUは単一のL1によって制御できる。VCPUのイベントが発生するとL0は対応するL1にその旨を通知する
      • I/Oデバイス: 個々のguest上の個々のI/Oデバイスはそれぞれ単一のL1によって制御できる。guestにI/Oイベントが発生するとL0は対応するL1にその旨を通知する
    • あるリソースを制御するL1はL0から自由に切り替えられる
  • 効果
    • ネットワークモニタリングとVM introspectionサービスを実現できた。それに加えてゲストミラーリングVM introspectionが実現できた
    • 性能インパクト: 全体的にはCPU intensiveなワークロードでは性能劣化がそれほどないがI/O intensiveなものでは劣化が激しいという予想通りのもの。詳細は8節を参照
  • 感想
    • ハードウェアの機能を活かした曲芸のオンパレードで非常に面白かった。が、流し読み(実装詳細は見てない)にもかかわらず読むのにめちゃくちゃ時間がかかってしまった
    • 多種多様なサービスの組み合わせをspanとnestedで性能比較した結果が見たイ。とくに3個以上のサービスを提供する場合。
    • table2のspanについてのL2って明に書いてないけどguestのことと考えてよい?
    • 上記のメインVMMからモジュール形式でサービスを提供する方法についての論文が読みたくなった

べつにQiita使ってもいいんじゃないの

Qiitaは悪く言われがちです。よく聞く理由は次のようなものです。

  • 記事の品質が低い
  • 低品質なものが検索上位に来るので邪魔
  • これらからのコピペばっかでプログラミングしてるやつらが嫌い

これらはごもっともだなあと思う反面、そこから一歩先に進んで「Qiita見んな」「見てるやつはエンジニア失格」とか言われるとちょっと違うかなあと思います。ここには良い記事もけっこう転がっているので、やりかたさえ気を付ければとても便利なサイトだと思っていますし、実際けっこう参照しています。

気を付けているのは次のようなことです。

  • 記事の品質の問題
    • タイトルがそれっぽいものはとりあえず斜め読みしてみる
    • 中身がスカスカだったり論旨が不明瞭だったり煽りっぽかったりする人は容赦なくブロック
  • 検索の問題
    • 文字列検索では、なるべく具体的、かつ、ひっかかる数が少なそうなものにする「kubernetesについて検索したけどk8sの入門記事しか出てこない!クソだ!」と言ってる人を見ると「検索エンジンにそこまで期待しなくても…」と思ってしまう
    • 最初から書いた人で絞り込む。過去の経験をもとに信用できる人のリストを作っておけば「この人こういう記事書いてないかな」と探せる。信頼できる人がいいねを付けている記事もポイント高し
  • 記事の内容の利用前には必ず自分で裏を取る&理解する。たぶんこれが一番大事。公式ドキュメントに書いてようと業界の大家が書いてようと、これをやらずに鵜呑みにしてはいけない

「最初から公式ドキュメント見たほうが近道」「公式以外は信用できない」といわれることもあります。しかしながら自分の知りたいことすべてが公式ドキュメントに載っているわけではないので、隣の席の人に「ちょっとこれ知らない?」と聞く感覚でこの手のサイトを見るのは別にいいんじゃないかと。

自分が嫌いなのは別にいいんだけど、右も左もわからない人たちに頭ごなしにダメだのクソだの言って委縮させたり選択肢を狭めたりするのは、あんまりよくないとおもうんですよ。

30分で論文流し読みシリーズ 7「File Systems Unfit as Distributed Storage Backends: Lessons from 10 Years of Ceph Evolution」

SOSP 2019で発表される予定の論文。品川先生のブログで見かけたので読んでみた。

utshina.hatenablog.jp

https://www.pdl.cmu.edu/PDL-FTP/Storage/ceph-exp-sosp19.pdf

  • 実際の所要時間

    • 30分。土地勘がある分野なのではじめて30分で読めたぞ!
  • 前提知識

    • Cephはたくさんのノード上にたくさん刺さったストレージを束ねてファイルシステムやブロックデバイスやオブジェクトストレージを提供する分散ストレージシステム
    • 各ノード上ではOSDという単位でローカルストレージを管理している。HDDとかだとOSDとHDDが一対一対応、並列アクセス性能が高いNVMe SSDだと多対一対応。
    • ファイルシステムやブロックデバイスなどのユーザに見せるインターフェースによらず、裏側ではRADOSというオブジェクトストレージが存在していて、すべてのデータはRADOSのオブジェクトのかたまりとして表現される
    • もうちょっと詳しいことは少し前に書いた
  • 課題

    • OSDは従来XFSなどのファイルシステム上をバックエンドとしたFileStoreというものだった。それだといろいろ問題があった
      • トランザクションのしくみをファイルシステムの上に独自実装する必要があって、これの性能が悪かった
      • メタデータアクセスのレイテンシのほとんどがFileStoreのものだった。具体的には次のような問題があった
        • 1オブジェクト1ファイルでファイル名がオブジェクトを一意に識別するハッシュ値、というものだったがディレクトリ走査がファイル名順に並んでいない
        • オブジェクト数が増えるとディレクトリに分けられるのだが、階層が深くなるほどアクセスコストが高くなる
        • と、ここまで書いたけれどもCeph…というかRADOSを実現するためには別にディレクトリ構造なんていらない
      • 新しいデバイスが出てもファイルシステムが対応してないとかいう理由で対応できなかった
  • 解決方法概要

  • 解決方法詳細

    • 4節にけっこう詳しく書いてる。ここで細かいこと書いてもしょうがないので省略
  • 効果

    • レイテンシもスループットもすごく改善した。概要は図3,4,7~11をざっと眺めるとわかる
  • そのほか

    • Cephのデータストアの変遷が2.3にさらっとまとまっている
    • 新規作成されたストレージバックエンドという非常にドラスティックな変更だが、すでにかなり多くの人がBlueStoreを使っている
  • 感想

    • 読み物としてとてもおもしろい。引き続き30分といわずじっくり時間をかけて読みたいし、参考文献も掘っていきたい
  • おまけ(論文そのものとは関係なく単にわたしが知ってることの紹介)