Write and Run

it's a simple way, but the only way.

穴を開ける、柱を立てる

これは KOBA789 日記 Advent Calendar 2021 - Adventar 18日目の記事です。

日記

今日は大学の後輩の部屋にツーバイフォー材を立てるのを手伝いました。DIY 大好きマンにはお馴染みのアレです。

ホームセンターに木材を買いに行き、軽トラを借りて持って帰ってくるという、いつものやつをやりました。

プロジェクターを設置したいということだったので、私が引っ越す前に使っていたプロジェクターとその固定金具一式を押しつけました。10年前に買った物体だし、今の部屋にはデカい有機 EL ディスプレイがあるしで、邪魔だったんですよね。

プロジェクターを適当な木ねじだけで吊るすと強度にやや不安があるので、柱に貫通穴を空けてボルトを通しました。引越し前の私が使っていた、実績のある構造です。

今持ってる電動ドリルはちょっと非力なので、マキタのやつとか欲しいですね。まぁ年に数回しか使わないんですけど。ドリルを買いにきた客が本当に欲しいのは穴ではなくマキタ。

終わりに

明日も書く。 久しぶりに暇な日曜日なので新しい DBMS でも作ろうかな。

SWDやCMSIS-DAPとにらめっこした

これは KOBA789 日記 Advent Calendar 2021 - Adventar 17日目の記事です。12月って16日がないらしいです。

日記

SWD や CMSIS-DAP とにらめっこしていました。SWD や CMSIS-DAP というのは、Arm マイコンのデバッグをするときに使うやつです。にらめっこの結果として rust-dap のバグを見つけたので PR を出しました。

rust-dap は CMSIS-DAP v2 に対応してるし実装小さくて移植しやすいしで最高です。実際に手元の bluepill に移植して活用しています。

これは私がやっつけ移植した bluepill 対応版(fork): GitHub - KOBA789/rust-dap: CMSIS-DAP Rust implementation

自分が使うソフトウェアが自分の慣れた言語で書かれている安心感は何物にも代えがたいですね。多少バグってても自力で直せるので身軽です。

そうそう、CMSIS-DAP ではどうやってフラッシュへの書き込みをしているんだろうと思って調べたところ、なんとフラッシュ書き込み用の小さなファームウェアを RAM 上に展開してそれを呼び出して書き込ませるという仕組みでした。その小さなファームウェアのことを Flash Programming Algorithm と呼ぶらしいです。またひとつ賢くなりました。

終わりに

(12月に18日があれば)明日も書く。

ひさしぶりに「データ指向アプリケーションデザイン」を読んだ

これは KOBA789 日記 Advent Calendar 2021 - Adventar 14日目の記事です。

日記を書くには早すぎる時間なんだけれど、久しぶりに「データ指向アプリケーションデザイン」を読んだら気持ちが高まりすぎてしまったので、書く。

データ指向アプリケーションデザインと私

「データ指向アプリケーションデザイン」（以下、本書）は "Designing Data-Intensive Applications" の和訳であり、2019年に発行された書籍です。

原著の方は2017年には発行されていたらしいのだけれど、恥ずかしながら当時は知りませんでした。和訳が出たということで話題になっていたのを見て知り、買って読みました。

初めて読んだときの衝撃といったらすごいものでした。学術的なバックグラウンドがほぼ皆無な私が趣味・業務内の試行錯誤のみから思索してぼんやりと仮説を立てていたものについて、その答えが根拠とともに載っていたのです。

私の感覚は間違っていなかったんだという安堵感と同時に、なぜ文献にあたらずにひとりだけで問題に向き合っていたのかと後悔し、また列挙されている参考文献の多さを見て、私と興味を共有する人々が世界中にはこれほどいるのかと嬉しくなったのを覚えています。

その感動をより多くの人と分かち合いたくて、すぐにその場で追加でもう1冊追加で買い（布教用というやつです）、とりあえず当時の職場の CTO の机の上に置いたりもしました。

ペーパーバック版は大きくて持ち歩きづらいので、友人とのふとした会話の中で参照するには不便です。そのため電子版も買ってスマートフォンに入れてあります。電子版は全文検索が効くので、紙の本をシークするときの索引としても便利ですね。

ひさしぶりに読んだ

そんな本書ですが、今朝2年ぶりくらいに読み直しました。きっかけは若干仕事で必要だったからなんですが、勢いで頭から第Ⅱ部（400ページくらい）まで読みました。思い入れのある1冊の割にはレビュー(?)をしたことがなかったことに気づきました。せっかくなので書きます。

12ページ目くらいで早速 Twitter のタイムラインの話が出てくるあたりで泣きそうになりました（一度読んでるはずなんですけどね）。データシステムに興味があれば、誰しも一度はスケーラブルなタイムライン機能の設計を考えるものです。読者のハートをガッチリ掴んできます。

日常的にデータシステムと向き合っていれば、システムの信頼性を高めるにはどうすべきか、スケーラブルにするにはどうすべきか、という勘が多少なりとも育まれます。しかし、実際に信頼性の低いコードやスケーラブルでない設計を目の当たりにしたときにその問題をわかりやすく説明できるでしょうか。あるいは妥当な修正案を出せるでしょうか。必ずしもそうとは限りません。

本書ではそうした勘を言語化するための強力な武器になります。課題を分解し、概念を定義し、例を交えて読者に整理されたメンタルモデルを与えます。いずれも現場に向き合ったことがあればスッと心に染みる課題ばかりです。課題が分解され整理される様を追いながら解説にうなずき続けることになるでしょう。読者の悩みを読者より雄弁に語ります。

REST と RPC の話が個人的に好きなので一部を引用します。

RESTの魅力の一部は、それ自身がネットワークプロトコルであるという事実を隠そうとしていないことにあります データ指向アプリケーションデザイン P.145

私が今よりもさらに未熟だったころ、RPC に夢を見すぎて実際に本書で指摘されているような RPC の問題に直面したことがあります。本書では、リモートサービスの呼び出しをローカルの関数呼び出しのように見せかけるアイデアには「根本的な問題がある」とすら書かれています。私もそう思います。具体的にどういう問題があるのかは P.144 を参照してください。

関連して、8章の内容も好きです。特に8.2の、非同期パケットネットワークって不便だよね、というあたり。皆さんご存じの通り、IP ネットワークは非同期パケットネットワークの一種です。なのでいろいろ困ったことが起きます（具体的な困りは P.302 あたりを読んでください）。

でも TCP を習う時って信頼性のあるプロトコルだって説明されませんか？　UDP と比較して TCP には順序保証とか到達確認とかがあるってだけなんですが、10年くらい前に勉強したときは、TCP はめっちゃ信頼性がある印象を受けました。信頼性あるなら普通に RPC 乗っければいいって発想になりますよね？　私だけ？　まぁ結論としてはそれは幻想なんですが。

第3章、ストレージの話が grep や tail を用いた素朴なストレージエンジンの実装から始まっているのも感動的です。私の書いた記事ではいきなり B-Tree から始めてしまいましたが、誌面の余裕さえあればシンプルなテーブルヒープから始めた方がわかりやすいし、インデックスのありがたみや意味が実感できるよな、と思ったりします。

ストレージエンジンに（当然）魔法なんかなくて、実にエンジニアリングらしいチマチマしたトレードオフの選択でそれっぽい性能特性が得られてるだけなんですよね。その出発点として、まずは（直感的にダメそうでも）素朴な実装から始めてみるというのは理解に大いに役立ちます。ちなみに直感的にダメそうでも特定ケースでは問題なかったりしますし、現実がそのうまくいく特定ケースにハマることはよくあります。自戒を込めて。

この調子で書いていくといくらでも語れそうなのでこのへんにしておきます。あ、Avro のライターのスキーマ・リーダーのスキーマとかも地味ですがおもしろいですよね。まずい、話が終わらなくなる。

終わりに

明日も書く。

2021-12-13

これは KOBA789 日記 Advent Calendar 2021 - Adventar 13日目の記事です。

冒頭に書くこともなくなってきたし、2021年も消化試合の様相を呈して参りました。

日記

久しぶりに電磁リレー回路 CAD zuse のメンテをしました。

WebGL の足回りに golem というライブラリを使っていたのですが、メンテが止まっているっぽいので依存から外して、その下のレイヤーの glow というライブラリを直接使うように書き換えました。

経験がある人には伝わると思いますが、OpenGL ってやつは API が超 stateful です。WebGL も OpenGL の API デザインをほぼ完全に引きずっているので同様です。

あるオブジェクトを操作するにはまずそのオブジェクトを bind して、そのあとに続く関数呼び出しではその直前に bind したオブジェクトを操作する、みたいなデザインです。

golem というライブラリはこういった面倒な bind 操作をうまく隠蔽してくれていてとても便利だったんですが、作者が力尽きていそうなので仕方なしですね。

メンテのために久しぶりに電磁リレー回路 CAD に触ってみたらまだまだ遊べそうだなと思いました。年末年始の休みで時間とって拡張できたらいいなと考えてます。

終わりに

EKS めんどくさい！！！（心の叫び）

明日も書く。

2021-12-12

これは KOBA789 日記 Advent Calendar 2021 - Adventar 12日目の記事です。

まだ大したこと書いてないのにもう折返しです。

日記

Kindle Unlimited に加入しました。

せっかく61鍵もある大きな MIDI 鍵を買ったので、打ち込みに使うだけじゃなく多少弾けるようにもなりたいなと思って教則本っぽいやつを読んでます。 教則本みたいなやつ、前提知識の量のバラツキもあるし、説明の合う・合わないもあるので立ち読みしてから書いたくなりますが、オンラインだとそうもいきません。

Kindle Unlimited だとそういう心配なく読み漁れるのでいいですね。今のところ一冊目でだいぶしっくり来てるのであまり活かせてませんが。

終わりに

そろそろだいぶめんどくさくなってきたけど明日も書く。

2021-12-08

これは KOBA789 日記 Advent Calendar 2021 - Adventar 8日目の記事です。

ほんとうは2021年音楽反省会とかやろうと思ったんですが、いい動画を見つけてしまったのでその話を書きます。オチはないです。

「教育系YouTuberにならない方がいい7つの理由」

www.youtube.com

まず始めに、この動画を見てめちゃくちゃ救われた気がしました。

私も一応 YouTuber をやっている身です。教育系ど真ん中というわけではありませんが、エンタメというよりは解説系です。胸を張れるほどの本数を上げてませんが、唯一無二な動画を上げている自信はあります。もしよかったら見ていってください。宣伝ここまで。

そういう背景もあって、上記のヨビノリのたくみさんの動画には共感できる点がたくさんありました。「救われた」と表現したのは、その「共感」ですらできる機会が少なく、ずっと孤独を感じていたからです。

今では星の数ほどいるように思える YouTuber ですが、それでもやはり普遍的な活動といえるほど人口が多いわけではなく、教育系・解説系ともなればなおさらです。

悩みやつらさを共有できるという点だけでいえば、普通の会社員ほどラクな活動はないと思います（当然その他の点では苦労するけど）。相談すればとても多くの人が共感してくれますし、自分が黙っていても会社員あるあるエピソードは世界に溢れていますから自分の悩みを相対化して不安を取り除くのは簡単です。

ですが YouTuber だとそうはいきません。そもそもわけわからんジャンルの動画を出しているせいで横の繋がりすら弱いです。私の交友関係が狭いだけという説は十分有力なんですが。

そんな中で、教育系 YouTuber のつらいポイントを言語化し、発信してくれたことに感謝と敬意を表します。こういうのって弱小 YouTuber が言ってもコンテンツにならないどころかただの弱音になってしまいますからね。先行者であり成功者（だと個人的には思います）が表現してくれるところに価値があります。

「撮影がシンプルに辛い」

動画中で上げられているつらいポイントのうちのひとつです。動画中では28:00あたりからです。

無機質なカメラに向かってひとりで喋り続けるつらさや、映像・録画特有の難しさについて触れられています。

私の場合、撮影中に対峙しているものは普通のカメラでこそないですが、なんのリアクションもくれない撮影機材にのみ囲まれているという点では同じです。

噛んで止まれば、途端に静寂が訪れます。ノイズを減らすために環境音を極力減らした空間で撮影しているのだから当たり前です。

どちらかといえば、私もカメラの向こう側にオーディエンスが見えるタイプですが、それでもこの無慈悲な静寂は急速に酔いを覚ましてきます。撮影で一番キツい瞬間です。

そもそもオーディエンスが最初から見えない日もあります。これは練度の不足ですが、こうなるとどうしようもありません。ちなみに、夜中に動画の構成を考えながら散歩した翌日はオーディエンスがよく見えるという経験則があります。

最近ひとりの動画を作れなくなってしまった一番の理由はこれです。撮影や編集の「めんどくささ」を減らすエンジニアリングはしましたが、「つらさ」を減らすのは練習以外に方法がなく、単独でそこをブートストラップするのは現状運に頼り切りです。

それでもやる理由

幸い、動画で紹介されていたその他の点については私はあまり問題に感じていなかった（ロクに活動していないからというのもある）ものの、やはり前述の一点だけでもつらいものはつらいです。

それでもなぜ飽き性な私が放り出さずにチマチマ続けているのかといえば、それはシンプルに正義のためです。使命感と言い換えてもいいかもしれません。

ただ独善的に、インターネットには私が作るような動画があった方が面白いから、という理由で続けています。面白いかどうかはもちろん主観です。

YouTuber を続ける合理的な理由はありません。自身のプレゼンス向上とか、ちやほやされたいからとか、なんらか理由を付けようと思ったことは何度かあるのですが、いずれもしっくりこなかったので却下しています。

（こういうとき、自分用の企画書を書いて振り返ることにしています。飽き性ゆえに、コンセプトや判断根拠を言語化して固定しておくと便利です）

というわけで今後ともよろしくお願いします。年末特番はやりたいなと思っているのでご期待ください。

オチのない話おわり。

終わりに

明日も書く。