べつに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分といわずじっくり時間をかけて読みたいし、参考文献も掘っていきたい
  • おまけ(論文そのものとは関係なく単にわたしが知ってることの紹介)

ポイントカードとか電子マネーがめんどくさい

世の中にはポイントカードや電子マネーが大量にありますけどわたしは前者はスマホアプリを使うものを含め数個だけ、後者はモバイルSUICAだけを使っています。なんでそうしてるんだっけと整理したくなったのでつらつらと書きます。初めに断っておくと別に他の考え方を否定するつもりはないですし同意を求めるものでもないです。

要約すると「細かいことで頭と時間を使いたくない」です。

まずポイントカード。利点はカードによってさまざまあるものの、雑に書くと数%程度割引されるということです。それに対する欠点は、会計時にカードケースから該当するカードを出す手間がめんどくさいこと、および、かさばることです。これはカードの数が増えれば増えるほど、カードを使う頻度が高ければ高いほど顕著になります。これより単価も総額も安めになりがちな日用品を扱う店のカードは欠点のほうがかなり目立つので一枚も持たないことにしています。それに対して単価が高く、かつ、めったに買わないものを扱う店のカードは一回あたりの割引額が大きいので2,3個だけ持ってます。最近はスマホのアプリにポイントを貯められるものがありますが、そのためにいちいちアプリを入れたり使うときにアプリを起動したりする手間が嫌いです。このため、こちらも比較的高額な商品を扱うもののみ数個アプリを入れています。

続いて電子マネー。カードをなるべく持ちたくないというすでに述べた理由によって、物理的なカードが必要になるものは一つにおさえるか、あるいはまったく持ちたくないです。この条件に合うものの中から一番使える場所が多いものとなるとモバイルSUICAかなあと思ってこれを使っています。最近は昔ながらの(?)NFCを使ったものではなくてバーコード決済のものも増えてきました。これらを使わない一番の理由は、NFCに比べてバーコード決済のものはアプリをインストールしたり立ち上げたりするのがめんどくさいとことです。さてバーコード決済といえばめちゃくちゃ割引率が高いことがたまにあるので一見利点が大きそうです。しかしそれに同期して値上げする店があったりするので、実質どれだけ得するのかがいまいちわかりにくいですし、それを確認するコストも払いたくないです。

めんどくさいの嫌い。

コードの写経中にやってること

ソフトウェアのプログラミングの文脈でソースコードの写経と呼ばれるものがあります。簡単に言うとソースコードの読み書き技術の上達のために既存のソースコードを手元で入力する作業です。最近ではgithubなどでOSSが大量に公開されているのでいくらでもできます。

写経は明確に定義がある言葉ではないので、ただ無心に写すという人もいるでしょうし、写しながらその他のことをする人もいるでしょう。ここでは私が「(ソースコードの)写経をする」といったときに何をしているのかを、だれかの参考になるかもしれないので書いておきます。なお、別にこれが唯一絶対とかいうつもりは毛頭ないです。

  • (とくに不慣れな分野、言語において)何をしたいときにどういうライブラリを使うか、どういうコードを書くかというパターンを覚える、およびそれを体に叩き込む
  • コードを書いたときの作者のお気持ちを推測する
  • 実際に書かれているコードと自分ならこう書くであろうコードを比較して、どちらがよさそうかを考える
  • よさそうだとして単に好みの問題なのか、変更するに値するものなのかを考える
  • 変更に値するのならば何をすればupstreamに受け入れられるだろうかと考える

すぐに思いつく限りではこんなものです。ついでに言うと写経の後の話ですが、変更に値するものがあって、かつ、自分の時間に余裕があればupstreamにPR送るということもたまにします。

みなさんはどんなこと考えながら写経してますかね。コメント欄とかに生やしたりして教えてくれると嬉しいです。

iOS上のssh/moshアプリ、BlinkでC-mショートカットが効かない問題が解消

以下の問題はiOS 13.1.1では解消していました。

satoru-takeuchi.hatenablog.com

13betaで治ったという報告があったのでたぶん行けるだろうと思ってましたが、いけました。やったぜ

github.com

30分で論文流し読みシリーズ6「Gleaner: Mitigating the Blocked-Waiter Wakeup Problem for Virtualized Multicore Applications」

https://www.usenix.org/system/files/conference/atc14/atc14-paper-ding.pdf

実際の所要時間: 1時間

課題 - VMにおいて頻繁にvCPUがidleになるワークロードのnative環境に比べての性能劣化が激しい - 理由はvCPUがアイドルになる処理、およびその後再びidleが解除される処理がpCPUに比べてとても遅い。理由は次の通り - idle化: pCPUは「何もすることが無い」->「省電力状態にするための特殊な命令を実行」->「アイドル」だが、vCPUの場合は「何もすることがない」->「特殊な命令を実行」->「VMMに制御が移ってなんやかんや」、と、手番が多いから - idleからの復帰: pCPUは「割り込みないしIPI食らって起きる」->「動作の再開」だが、vCPUの場合は「VMMが割り込みないしIPIをvCPUに送る」->「vCPUプロセス起こす」->「vCPUプロセスが起床」->「動作の再開」と、手番が多いから

解決方法概要 - vCPUをなるべくidle状態にしない

解決方法詳細 - idleになろうとするときに省電力状態にするための特殊な命令を実行せずにspin loopする、あるいはguestから直接物理CPUを省電力状態にできる命令を実行 - delayed scheduling: vCPU1上のプロセスAがアイドルなvCPU2上のプロセスBを起こす場合、通常プロセスBをvCPU2上で起こすが、あえてvCPU1上で起こす。これによってidleから非idleへの状態遷移を減らせる - imbalanced scheduling: runnableなプロセスをなるべく特定のvCPUに固めて、その他のvCPUをidle状態にとどめることによって、idleと非idleの状態遷移を減らす

効果 - 時間切れで見られなかった

感想 - imbalanced schedulingは現在省電力のためによく使われているやつ。このアイデアは組み込み用途かVM用途か、どちらが先に考えられたのだろうか

「イベント無線LAN完全自壊マニュアル vol. 1」を読んだ

大規模イベントにおいて参加者に提供する無線LANサービスを構築するノウハウについて書いた本です。著者のえぬかねさんに献本いただいたときは「この全く知見が無い分野の本をいただいたが理解できるだろうか」と心配していましたが、案の定専門的なところは全く理解できませんでした。しかし、わからないならわからないなりに、本書はわたしにはとても楽しめる本でした。筆者の簡潔明快な文体、血と汗の臭いがする具体的な話の数々、大量のデータ、どれもこれもわたしの好みのど真ん中でした。こういうのもっと読みたい。