ポイントカードとか電子マネーがめんどくさい
世の中にはポイントカードや電子マネーが大量にありますけどわたしは前者はスマホアプリを使うものを含め数個だけ、後者はモバイル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で治ったという報告があったのでたぶん行けるだろうと思ってましたが、いけました。やったぜ
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用途か、どちらが先に考えられたのだろうか
「OS Girls 2」を読んだ
技術書典7において販売されていた本の読書感想文です。BOOTHで電子版を販売中です。
「OS GIrls」の続編です。前作の読書感想文はこちら。
satoru-takeuchi.hatenablog.com
わりと真面目な感想文は前回書いているし今回も同様の感想なので省略。今回はその他の感想を主に書きます。
前回同様、相変わらずかっ飛ばしていて、いい意味での突っ込みみどころがたくさんあります。ネタをそのまま書いてしまうと全然面白くなくなるで私の突っ込み部分だけを書いておきます。
- 「この事象からOSの話につなげるのか…」
- 「これは早口で自分の言いたいことをまくしたてるタイプのオタク」
- 「まさか、まさか、この流れ…初級者の前でこの技術に言及するつもりでは………でししたね、ですよね、この子ならそういうこと言っちゃうよね」
続編に期待です。気長に待ってます。
「OpenCVデバッグ探偵記」を読んだ
技術書典7で著者の@tomoaki_teshimaさんに献本いただいた本です。
本書はOpenCVを題材にバグを見つけてからデバッグ、そのあとOpenCVのupstreamに還元するための技術について解説してくれています。このデバッグをする流れを筆者は探偵による調査に見立てています*1。経験豊富なソフトウェア技術者であり、かつ、OpenCVというOSSに幾多の貢献をしてきた筆者による迫力満点なトラブルシューティングは見どころ一杯です。題材は特定のソフトウェアですが、あらゆるトラブルシューティングに通じる内容です。ひたすら解析が続くだけではなく、ときおり箸休めのための余談が入ったり、コラムが入ったりというのもうれしいところです。
本書はこちらから電子版を購入できるようです。わたしが以前書いた以下のOSSトラブルシュート記事を面白いと思うかたであれば本書もきっと気に入るでしょう。
ここで本書を読むのに必要な前提知識について述べておきます。主にC++やアセンブリ言語のソースをもとにした解説なので、これらの言語を知っているのが好ましいと思います。しかし、解説が丁寧なので流し読みするくらいであればなくても大丈夫だと思います。
脱線ですが、なぜ献本いただいたかというと、著者がわたしの過去の活動Ryzen SEGV Battleを気に入ってくれたからだそうです。書籍でも触れてくれています。ご興味のあるかたはごらんください。書籍化もされています。
最後になりますが、もう一度。とてもいい本でした、献本ありがとうございました。
*1:わたしを含め、このたとえは非常に的を射ているのでけっこう使う人が多いです
