覚書スマートフォン用の表示で見る覚書2020-02-17実体の無い完璧超人と戦っていた過去の失敗談かつての失敗談。いった初めたばかりのころにはまった次のような悪い循環です。すごい人をたくさんフォローするすごい人達がすごいこと言ったりやったりするそれに比べて自分は大したことできないと自信喪失する何もしなくなるフォローする人が多くなればなるほどこの傾向は加速していきました。いうと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。次のような3人をフォローしたとします。特定のプログラミング言語にめちゃくちゃ詳しい人ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした。彼らは実際にはそれぞれに得意分野があって、そこから遠い分野の技術はほとんどの場合は苦手、あるいは全然知らなかったのです*1。これを知ったときは妙に安心したことを覚えています。それに加えて、私が上記のような罠に陥っているのではないかと指摘してくれる人もいました。今思えば、彼らも過去に似たような罠にはまっていたのかもしれません。その後、「自分もここなら詳しい」という部分ができてきたこともあって、徐々に自信を取り戻してきて、今に繋がっていきます。今同じような罠にはまっている人がいるとしたら上記のことを参考にして、少なくとも実在すらしない謎の超人と戦うのはやめるだけで、かなり心が楽になるのではないかと思います。*1:たまーに本当に何でもできる完璧超人もいたのですが、それはそれ。18:55実体の無い完璧超人と戦っていた過去の失敗談Tweet広告を非表示にするもっと読むコメントを書く2020-01-16プログラミングでつまづいてきたことプログラミング初心者に対してどういう情報が役立つのかをぼんやり考えていると、そこそこコードを書けるベテランが、いつ、どういうことにつまづいてきたのかを書くとけっこう有益なのではないかと思ったので書きました。これを読むと直接プログラミング能力が上がるわけではないですが、「ああ、こういうところでつまづいてもいっぱしのプログラマになれている人もいるのだな」と思ってもらうのが目的です。成功談よりも失敗談のほうが役立つとよく言われますが、それと少し似ているのかもしれません。全段落で「いっぱしのプログラマ」とか言った手前、自分のことを書いておきます。18歳ごろから20年くらい前からプログラミングをしていて、主に有名どころのOSSに向けてコードを書いてきました。昔はLinuxカーネルを10年少々やっていて、ここ最近はCephオーケストレータであるRookの開発とかをしています。プログラマとしてはスーパー優秀とは言えませんが、そこそこは書けます。長ったらしく文書にはせずに、ずらっと列挙します。だいたい上が古くて下が新しいです。後から思いだしたら追記するかもしれません。ポインタが理解できなかった(18歳ごろ?)。メモリのイメージがまったく頭に無かったので参考書を見ても何が書いてあるのがわからなかった。クロージャ、メモ化が理解できなかった(20歳ごろ?)。大学に入ってLISPというのがあるらしいと知って書店でSICPを買って読み始めたら何もかもわからずに絶望した。紙に状態遷移図を書きまくってようやく理解した。「オブジェクト」の意味が多いので混乱した(20歳ごろ?)。具体的にはコードのかたまりであるオブジェクト(ファイル)とオブジェクト指向言語のオブジェクト。何冊か本を読むとようやく別物だと理解できるようになった「スタック」の意味が多いので混乱した(20歳ごろ?)。具体的にはデータ構造としてのスタックとメモリ上のスタック領域。上記と同様、何冊か本を読んでようやく理解した。「ヒープ」の意味が多いので混乱した(20歳ごろ?)。具体的には動的メモリ領域としてのヒープとヒープソートのヒープ。これは気にしないでおこうと思って放置していたら、数年後に全然別物と知った。アセンブリ言語がわからない(22歳ごろ?)。レジスタとメモリの違いがわからなかったし、関数呼び出し規約を知らなかったので、いつ何を使っていいかがわからなかった。アセンブリ言語プログラミングの本を数冊読んでやっと理解したなんでも(OOPLという意味での)オブジェクトで表現すべきと思い込んで四苦八苦した挙句プログラミングが楽しくなくなった(23歳ごろ?)。その後、よくわからないうちに飽きたので自縛から解けた。C++の演算子オーバーロードとテンプレートを使うとかっこいいという思いがあって無意味に使っていた(23歳ごろ?)。「一体何をやってるんだろう」という気分になってきてやめたわたしが主にC言語などの高級とはいいがたい言語を中心に使ってきたこともあって最近プログラミングを始めた人にとってはピンと来ない言葉もあるかもしれませんが、そのへんは無視してもらっていいです。最後になりますが、プログラミング初心者は何かにつまづくと「それくらい知っていて当然」とか「これが理解できない奴はセンス無い」とかいう暴言が飛んできがちですが、狂犬が吠えていると思って無視しましょう。先日qiitaのサポートに自分の記事がガイドラインに沿っているかどうか確認しましたので、その結果について書きます。qiitaに記事を書いていたりこれから書こうとしているかたに本記事が事例の一つとして参考になればうれしいです。本記事ではガイドラインにグレーゾーンがあること、およびその運用方法の是非についての話はしていません。qiitaにはコミュニティガイドラインというものがあります。雑な書き方をすると、これに沿ったものが適切な記事、沿わないものは不適切な記事であり、後者は場合によっては限定公開になったり削除されたりする可能性があります。前者の典型的な例はプログラミング技術についてのみ書いたもの、後者の典型的な例はダイエットに抜群の効果があると謳った謎サプリメントの宣伝文書などでしょうか*1。help.qiita.comわたしはこれまで50本近くqiitaに記事を投稿してきました。どれもわたしの解釈では上記ガイドラインに沿ったものでした。ガイドラインに沿っているという解釈もできる記事が限定公開になったり非公開になったりする例を過去に何度も見てきたので、自分の過去記事の中からグレーゾーンにある以下のものについてガイドライン違反をしていないかどうか、サポートに問い合わせてみました。qiita.comqiita.comqiita.comこれらをグレーと判断した理由は、コードが一行もないなど直接プログラミングの話をしていないからです(以下ガイドラインからの引用)。私たちの認識としては、技術的な内容が記事の主目的である限りは、「プログラミングに関係ある」記事だと考えています。「厳密にプログラミングとは言えない記事」「プログラマーのライフスタイルに関する記事」など判断に迷う場合は、「技術的な内容が主目的かどうか」を基準として考えています。問い合わせの結果、幸いにも数日のうちに以下の通り問題ないという回答を得ました。ご提示いただいたsatoru_takeuchi様の記事は、いずれもコミュニティガイドラインに違反しないと弊社は考えます。)は、「プログラミングに関係ある記事」と考えております。おかげで気持ちもすっきりしたし、既存記事を自分のブログなどに移動させる必要がなくなったので助かりました。18:12qiitaにある自分の記事がガイドラインに沿っているかどうか確認した話Tweet広告を非表示にするもっと読むコメントを書く2019-12-27一年の振り返り年末なので手短に一年間の振り返りをします。会社の仕事はぼちぼちでした。夏までは色々あって当初想定していたほどプロジェクトに貢献できなくて苦労しましたが、それ以降はOSSコミュニティ活動がはじまったので自分の持ち味を最大限に活用できるようになりました。来年はさらに飛躍をしたいなと。めざせRookメンテナ。個人事業主としては少し広がりました。Designの連載「Linuxのしくみ」も12月原稿を落とさずにやりとげました。去年出した前記連載と同名の書籍が一年を通してじりじりと売れ続けたのはとてもうれしかったです。それ以外には単発の仕事としてWeb上に「いま知っておきたLinux」という記事を書きました。これはたくさんの人に読んでもらって、かつ、想定読者に刺さったようなのでよかったです。書籍の次回作も仕込みをはじめたので、来年以降うまく原稿を完成させて発売にこぎつけられればと思います。私的な出来事としてはソフトウェア開発とは関係のない趣味が広がりました。具体的にいうと次の二つです。ミラーレス一眼を買いました。息子や風景、動植物などを撮りまくっています。レンズもあれよあれよというまに5本生えました。レンズってほんとに生えるんですね。コーヒーを豆から挽いて淹れる。カップをはじめとして自動ミル、手動見る、サーバー、携帯用のドリッパーやケトルなど、いろいろ揃えました。在宅ワーカーなので日々の楽しみが増えてとても幸せです。これまで頭の疲れない趣味を探しては失敗し続けていたのでとうとう手に入れた、という思いです。その他にはノイズキャンセリングヘッドホンを買ったのがとてもよかったです。詳細は以下の記事を参照。satoru-takeuchi.hatenablog.com来年も無理せずできる範囲でやれることをやります。IaaSでは(仮想)ハードウェアを含め多種多様なサービスを組み合わせて使えるようになっているが、VMMレベルのサービスはそうではなく、通常はベンダ提供の単一のものを使う。多種多様なVMMレベルのサービスを同時に複数使いたいとすると、次のような方法を使う必要がある。実現できる機能に限りがある。ページマッピングやVCPUのスケジューリングなどの低レベルの機能を提供するのが難しい。ネストが深ければ深いほど性能劣化が激しい。それに加えて、あるVMMから見てguestまでのレイヤが厚ければ厚いほどguestから得られる情報が減る。メモリのコンテンツなど。各L1にguestの物理メモリ上の任意の領域を割り当てられる。全CPU上の全VCPUは単一のL1によって制御できる。個々のguest上の個々のI/Oデバイスはそれぞれ単一のL1によって制御できる。introspectionサービスを実現できた。intensiveなものでは劣化が激しいという予想通りのもの。感想ハードウェアの機能を活かした曲芸のオンパレードで非常に面白かった。流し読み(実装詳細は見てない)にもかかわらず読むのにめちゃくちゃ時間がかかってしまった多種多様なサービスの組み合わせをspanとnestedで性能比較した結果が見たイ。3個以上のサービスを提供する場合。Services」Tweet広告を非表示にするもっと読むコメントを書く2019-10-20べつにQiita使ってもいいんじゃないのQiitaは悪く言われがちです。聞く理由は次のようなものです。記事の品質が低い低品質なものが検索上位に来るので邪魔これらからのコピペばっかでプログラミングしてるやつらが嫌いこれらはごもっともだなあと思う反面、そこから一歩先に進んで「Qiita見んな」「見てるやつはエンジニア失格」とか言われるとちょっと違うかなあと思います。ここには良い記事もけっこう転がっているので、やりかたさえ気を付ければとても便利なサイトだと思っていますし、実際けっこう参照しています。気を付けているのは次のようなことです。文字列検索では、なるべく具体的、かつ、ひっかかる数が少なそうなものにする「kubernetesについて検索したけどk8sの入門記事しか出てこない!クソだ!」と言ってる人を見ると「検索エンジンにそこまで期待しなくても...」と思ってしまう最初から書いた人で絞り込む。過去の経験をもとに信用できる人のリストを作っておけば「この人こういう記事書いてないかな」と探せる。信頼できる人がいいねを付けている記事もポイント高し記事の内容の利用前には必ず自分で裏を取る&理解する。公式ドキュメントに書いてようと業界の大家が書いてようと、これをやらずに鵜呑みにしてはいけない「最初から公式ドキュメント見たほうが近道」「公式以外は信用できない」といわれることもあります。自分の知りたいことすべてが公式ドキュメントに載っているわけではないので、隣の席の人に「ちょっとこれ知らない?」と聞く感覚でこの手のサイトを見るのは別にいいんじゃないかと。自分が嫌いなのは別にいいんだけど、右も左もわからない人たちに頭ごなしにダメだのクソだの言って委縮させたり選択肢を狭めたりするのは、あんまりよくないとおもうんですよ。2019で発表される予定の論文。品川先生のブログで見かけたので読んでみた。utshina.hatenablog.jphttps://www.pdl.cmu.edu/PDL-FTP/Storage/ceph-exp-sosp19.pdf実際の所要時間30分。土地勘がある分野なのではじめて30分で読めたぞ!前提知識Cephはたくさんのノード上にたくさん刺さったストレージを束ねてファイルシステムやブロックデバイスやオブジェクトストレージを提供する分散ストレージシステム各ノード上ではOSDという単位でローカルストレージを管理している。SSDだと多対一対応。ファイルシステムやブロックデバイスなどのユーザに見せるインターフェースによらず、裏側ではRADOSというオブジェクトストレージが存在していて、すべてのデータはRADOSのオブジェクトのかたまりとして表現されるもうちょっと詳しいことは少し前に書いた課題OSDは従来XFSなどのファイルシステム上をバックエンドとしたFileStoreというものだった。それだといろいろ問題があったトランザクションのしくみをファイルシステムの上に独自実装する必要があって、これの性能が悪かったメタデータアクセスのレイテンシのほとんどがFileStoreのものだった。具体的には次のような問題があった1オブジェクト1ファイルでファイル名がオブジェクトを一意に識別するハッシュ値、というものだったがディレクトリ走査がファイル名順に並んでいないオブジェクト数が増えるとディレクトリに分けられるのだが、階層が深くなるほどアクセスコストが高くなると、ここまで書いたけれどもCeph...というかRADOSを実現するためには別にディレクトリ構造なんていらない新しいデバイスが出てもファイルシステムが対応してないとかいう理由で対応できなかった解決方法概要OSDをファイルシステムに乗せるFileStoreじゃなくて生のブロックデバイスに乗せるBlueStoreにするメタデータの管理には順序付きKVSを使う解決方法詳細4節にけっこう詳しく書いてる。効果レイテンシもスループットもすごく改善した。読み物としてとてもおもしろい。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。