Write and Run

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

MIDI 鍵盤を買いました

……という記事を書いたのに操作ミスで全部消えた!

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

記事が消えました。悲しい。日記なので同じ内容を後日思い出して書く、ということはありません。それ日記じゃないしね。夏休みの宿題で書かされるやつを除けば。

MIDI 鍵盤を買いました、また無駄遣いしました、って内容がここには書いてありました。読者のみなさんにおかれましては行間から適切にもとの内容を復元して読み取っていただければと思います。想いは伝わる。

いっそのこと、ほんとは書いてなかったことを捏造してもいいかもしれない。たとえば、実は私の音楽観について書いてあったということにしましょう。書くのめんどいし角が立つのでそういうことは絶対書かないんだけど、書いてあったことにしたら誰かが勝手に感じ取ってくれるかもしれない。どうですか? 読めます?











念のため大きめに余白空けときます。その方が見えやすいと思うので。
















見えてきました?











元はだいたい1000文字くらいありました。電車に乗りながらスマホで打ったにしてはまぁまぁな分量でした。この半分くらいしか文字数のない記事からそれくらいの分量をなんとか読み取ってください。











終わりに

明日も書く。

無職から復帰して3ヶ月が経った

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

日記です。

今の会社(株式会社アークエッジ・スペース) に就職してちょうど3ヶ月立ちました。

就職して1ヶ月くらいで書いた記事はこちら。その節はたくさんの応援コメントをありがとうございました。

diary.hatenablog.jp

従業員として

まずはざっくりとした話。

2ヶ月前に上記記事を書いたときから多くのことがありました。

GitLab から GitHub Enterprise Cloud に移行したり、私がチームのマネジメントを始めたり。

細かな社内ツールも充実してきて着実により働きやすい環境になってきました。

この辺はパートタイムで働いている id:sksat の活躍も無視できない部分です。自動化などに気持ちがあるので私がサボってる細かいところをたくさん拾ってもらっています。

働き方以外の部分、つまり何作ってるかみたいなのはまだ言えないのがもどかしいですが、いずれ言えるようになるのでお楽しみに。

KOBA789 個人として

半年無職を謳歌したあとにいきなり成長期のスタートアップに飛び込むのは、緊張感の高低差が大きいという点で少々心配がありました。

スケジュールを意識することがまったくなかった無職期間と比較すると睡眠の質は悪くなりましたが、緊張感という意味では無職期間も大差なかったような気がします。

自発的になにかをしなければただ無為に時間が過ぎていく無職期間よりは、焦りや不安は少ないとさえ言えます。

自分のモチベーションが一時的に低下していても、すぐ同僚の仕事に刺激を受けられて回復できる環境です。モチベーション管理の面では無職よりラクです。

意外にも時間には比較的余裕があり(サボってるだけかもしれませんが)、趣味の YouTuber 業なども少しずつではありますが続けられています。土日もちゃんと休めますしね。

趣味よりも仕事の方が明らかにおもしろい課題を解いているので、平日はあまり趣味の開発をやらなくなってしまいました。

ひとりで取り組める課題なんてのはたかが知れているので(私の課題発見能力が不十分という視点もあります)、おもしろい課題が湧く泉としての事業ってやつは便利だなぁと思います。

前職を辞めたひとつの理由に、「ひとりでどこまでできるのか知る」というのがあったんですが、割とすぐ近くに限界があるということを再確認したということでもあります。これがわかっただけでも無職をした意味がありました。私はひとりだと弱い。

おわりに

明日も書く。

ハンバーグを食べました

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

12月は毎日日記を書くことにします。さすがに三日坊主未満はダメだろうと思って3日目までは枠を予約しています。

それ以降はどうなるかわかりませんが、25日間も3日間も広い視点(例えば宇宙誕生から今までとか)で見れば大して変わらないのでどちらでもいいでしょう。

仕事

守秘義務等があるので書けることと書けないことがありますが、今日は(今のところ)あまり働いていません。昨日と一昨日で頑張りすぎたのでその反動ですね。

ただまぁここ数日やってた内容は安全に公開できる内容だと思うのでいずれ公開したいですね。同僚が会社公式ブログの準備をやってくれているのでそれ待ちかな。

仕事以外

フライングガーデンにハンバーグを食べに行きました。期間限定で「超大型爆弾ハンバーグ」というメニューがあり、450g のハンバーグが食べられます。

フライングガーデンでは、ハンバーグはテーブルにサーブされた際に店員が目の前でカットしてくれます。

このとき、どのソースをかけるか聞かれますが、ポイントはカットされたそれぞれの半バーグ(カットされる前は全バーグです)に別々のソースをかけるように頼むことです。

順番が前後しますが、オーダーの際にわさびクリームソースも注文しておくといいでしょう。追加で100円払う価値はあります。

せっかく100円払ったので片方にわさびクリームソースをかけるのは当然だとして、もう片方にどのソースをかけるか悩むかもしれません。

標準で付いてくるソースには和風ソースとガーリックソースの2種類がありますが、和風ソースは焦がした方が美味しいので鉄板が熱いうちにかけてもらうのは和風がおすすめです。

ガーリックソースは後ほど好きなタイミングで自分でかければよいでしょう。まぁ個人の好みが最優先なので好きなようにやるといいです。

その他

明日も書く。

DDJ-400に6.3mm標準ジャックのヘッドホン出力を付ける

KOBA789 です。実は DJ が趣味です。

わたしと DDJ-400

ライトなアマチュア DJ に大人気な PC DJ コントローラーに、Pioneer DJ の DDJ-400 という大ヒット商品があります。

この DDJ-400 は天下の Pioneer DJ 製であり、(当然ながら)標準で rekordbox dj にバッチリ対応しているのにも関わらず3万円程度で買えてしまうという最高な機材です。

DDJ-400 がいかにゲームチェンジャーだったのかというのは語り始めるとキリがないんですが、しかしそれでも不満がないわけではありません。

私の不満のひとつは、ヘッドホン出力が6.3mmの標準ジャックではなく、3.5mmのミニジャックであるという点です。しかもそのジャックは天板ではなく手前側の側面に付いています。まぁ、3.5mm を天板に刺したらヘッドホンケーブルにかかるテンションで折れると思うので妥当な設計だと思います。3万円の機材に求めすぎてはいけません。

しかし、大好きな音楽でノリノリになって操作していると、手前に飛び出しているジャックに身体が接触することがあるのです。私がもっと落ち着きのある人だったらよかったんですが、あいにくそうではないのでボキッと折ってしまいそうでヒヤヒヤします。

ということで、DDJ-400 を改造して天板に標準ジャックを増設することにしました。DJM とほとんど同じような位置に取り付けることを目標にします。

改造計画

※今から紹介する分解・改造行為を真似する場合はすべて自己責任で行ってください。メーカー保証はまず間違いなく受けられなくなるでしょう。うっかり破壊してしまっても私は一切の責任を負えません。

お決まりの文句を赤字にしたところで初めていきます。まずは分解して様子を確認します。

f:id:koba789:20210516015415j:plain

日本の家電みたいな中身です。量産技術でコストと品質を両立させている努力が感じられる美しさです。

さて。

f:id:koba789:20210610184449j:plain

この小さな基板がモニターヘッドホンへの出力部分です。その奥には標準ジャックがギリギリ収まりそうな空間があります。

サイズを計測したところ、秋月電子で購入できるこのジャックなら取り付けられそうなことがわかりました。

akizukidenshi.com

とはいえギリギリです。実際に加工して現物合わせしてみないことにはわかりません。

1個70円ですし、無理矢理収めるためにいろいろ削って試行錯誤するかもしれないし、最悪いくつかは実験用に壊してしまってもいいように3個くらいシュッと買いました。

いざ改造

標準ジャックを取り付けるにあたって、まずこの赤枠で囲った部分の出っ張りが邪魔です。

f:id:koba789:20210610184450j:plain

ので、この部分を適当に切除します。これは横フェーダーを支える基板なので横フェの剛性に多少影響が出そうですが、私は横フェを使わないので気にしないことにしました。

紙エポキシなのでカッターでキズつけておけばニッパーで衝撃を与えるだけでいい感じになります。

f:id:koba789:20211105021259j:plain:h300f:id:koba789:20211105021307j:plain:h300

そこにジャックを仮置きしてみます。穴はまだ空けてません。

f:id:koba789:20211105021424j:plain

だいたいいい感じです。

いけそうな気がしてきたので天板に穴を空けていきます。もう引き返せません。 

f:id:koba789:20211105021541j:plain:w320f:id:koba789:20211105021548j:plain:w320

穴が空いてしまいました。あーあ。

穴の位置を現物合わせで確認しましょう。影で位置を見誤るのでいろんな位置から光を当てて確認するのがコツです。

f:id:koba789:20211105021654j:plain

だいたいよさそうです。ガバガバ工作の割にはうまくいきましたね。

あとはジャックが取り付けられる大きさまで穴を大きくしていくだけです。

f:id:koba789:20211105021950j:plain:w320f:id:koba789:20211105021959j:plain:w320

そしてリーマー登場!

f:id:koba789:20211105022044j:plain

無事取り付けられました。

f:id:koba789:20211105022150j:plain

切粉で汚いのはゆるして。

切削・穴開け加工は成功したので、お次は電気的な接続です。お手元にはんだごてをご用意ください。

f:id:koba789:20211105022326j:plain

好きな色のリード線を3本用意しまして、ジャックの端子にはんだづけします。

大きい端子は熱容量が大きいのでしっかり加熱しましょう。ただしプラパーツは溶かさぬように注意。

f:id:koba789:20211105022441j:plain

はんだ不足は接触不良や断線の原因になりますが、今回はスペースがギリギリなので、はんだを盛りすぎるとケースと干渉して取り付けできなくなります。

ジャック側のはんだづけができたら、もう一方を基板側にはんだづけします。LR を逆にしないように注意します。不安なときはテスターで計りましょう。

f:id:koba789:20211105022658j:plain

f:id:koba789:20211105022706j:plain

いい感じです。Great!

完成

こうして私の DDJ-400 には標準ジャックが刺さるようになりました。

f:id:koba789:20211105022816j:plain f:id:koba789:20211105022827j:plain

これで身体がジャックに当たってボキッとやる心配はなくなりました。

みなさんもよき DDJ-400 ライフを!

無職に飽きたので人工衛星のソフトウェアをRustで作っています

KOBA789 です。

今年2月末に前職を退職してからここ半年ほど無職をしていたのですが、いよいよもって無職に飽きてきたので人工衛星を作ることにしました。

実は9月頭から働いています。

株式会社アークエッジ・スペース

次の職場は株式会社アークエッジ・スペースです。東大の研究室発のスタートアップで、衛星バス開発を得意としている会社です。

衛星バスというのは、言ってしまえば人工衛星の OS に相当するものです。
OS に喩えましたが、もちろんそれは単なるソフトウェアではなく物理的な実体を伴うハードウェアとその中で動作するソフトウェアの集合体です。
ちなみにユーザーランドに相当する部分はミッション機器と呼ばれます。

まだまだ人数の少ない会社ですが、業界の土地勘や人脈に富んだ CEO や、人工衛星開発の経験があるエンジニアが揃っており、スタートアップとしては超実力派です。

ArkEdge Space Inc.

ソフトウェアエンジニアができること

私はソフトウェアエンジニアです。しかも一番得意なのはウェブ技術です。人工衛星開発の経験があるわけでもなければ、メカの設計ができるわけでも姿勢制御に詳しいわけでもありません。
(一応趣味レベルの電気電子の知識と回路設計の経験はありますが)

私もオファーを頂いたときは、まさか(ウェブ系の)ソフトウェアエンジニアが役に立てることがあるなんて、と思っていました。

しかし、面談のなかで現在の人工衛星開発の現場の課題について聞いていくと、ソフトウェア技術で解決できそうな問題が山ほどあることがわかりました。
ソフトウェアエンジニアばかりの職場・エコシステムでは解決されていて当然の課題が、ほぼそのまま転がっているのです。ウェブ系の会社ではありえないことです。
そして同時に、世間で "DX" がこれだけ注目されている理由を本当の意味で理解しました。ソフトウェアエンジニア中心の集団以外では、2021年になった現代でも計算機を十分に使い潰せていないのです。本当に。

私は計算機が好きです。そして特にソフトウェア技術の力を信じています。ソフトウェア技術を味方に付ければ、あらゆる人がもっと多くのことを成せるようになると確信しています。
人工衛星開発というエンジニアリングの最先端でソフトウェア技術を役立てられることを私は誇りに思いました。

具体的にやっていること・やること

とりあえず入社即 Kubernetes クラスタ構築 & ArgoCD で GitOps、AWS のリソースは全部 terraform で管理、という感じにしたりしました。
まぁ、これらについてはただの手癖ですし普通の仕事なので特段おもしろい話はありません。

また、Issue ベースでのコミュニケーションの方法の啓蒙をやったり、データベース勉強会を開いたりといった、「ソフトウェア業界から来た人」業をしています。
現代的な組織であれば、あらゆる人が SQL を書けてほしいし、あらゆる人が SQL を書くメリットを感じられるデータ基盤があるべきですよね、やっぱり。

より人工衛星っぽい仕事としては、オンボードコンピュータ(OBC)のハードウェアとソフトウェア両面の開発をしています。
OBC は名前の通り、人工衛星に搭載されているコンピュータで、接続されている各コンポーネントと通信しながら人工衛星の機能を維持します。 地上にテレメトリを送信したり、地上からのコマンドを解釈してコンポーネントを制御したりもします。
ウェブの技術でいうとまさに API サーバーみたいな感じです。

人工衛星では利用できる電力が限られています。空気の対流もないので放熱も一苦労です。というわけであまり潤沢な計算リソースは使えません。
また打ち上げたら最後、二度と人間の手の届かない場所にデプロイされてしまうため、バグって黙り込んでしまったりするとどうにもなりません。
しかも、たとえソフトウェアがバグっていなくても宇宙線でハードウェアが異常を起こしたりもするので始末に負えません。

そういうわけでかなり特殊なコンピュータが必要なので、ハードウェア・ソフトウェア両面から課題に取り組んでいます。
ソフトウェアのみならずコンピュータ全体が興味範囲の私としては、これほどエキサイティングな仕事は他にありません。

みなさん気になっているのはそのソフトウェアの開発言語だと思うんですが、Rust で開発しています。
実行効率と安全性と生産性に優れている Rust は人工衛星のフライトソフトウェアを書くのにぴったりです。 それに、やっぱり軌道上に Rust 製のソフトウェアをデプロイしてみたいですよね。 しかし Rust での組み込みソフトウェア開発は地上でもまだまだ例が少なく、エミュレータやデバッガなどの開発環境や、デバイスドライバをはじめとするハードウェア固有のコード資産などは C 言語ほど充実していません。
これらの課題をクリアしながら Rust で開発するメリットを最大限活かせるようになるにはたくさんのチャレンジが必要です。

気になる方はぜひ一緒に人工衛星を開発しましょう。

ISUCON11予選に今年もRubyで出場して敗退した

KOBA789 です。

今年もチーム「ソレイユ(osyoyu, koba789, s4ichi)」で ISUCON に Ruby で出場し、敗退しました。

まずは我々の戦法や秘密兵器の紹介から。

伝統と信頼のサーバーサイドプログラミング

ISUCON7 くらいのときから続けている手法で、競技用のサーバーに開発環境を構築し、3人とも同じホストに SSH でログインして同じファイルシステム上のソースコードを書き換えます。

他人の変更をリアルタイムに確認できることや後述するようにソースコードのバージョン管理が不要なことなどがメリットです。

SSH 時に WATASHI という環境変数で自分の名前を渡すことで、同じ isucon ユーザーへのログインであっても各個人の普段使いの dotfiles がロードされるようになっています。

これは「実家システム」と呼ばれており、チームの生産性に大きく貢献しています。

あいかわらず git ほぼ禁止

全員で同じコードベースを編集しているため、分散バージョン管理は必要ありません。 とはいえ分散しないバージョン管理は便利なため、リモートリポジトリなしで git を使っています。

また、ISUCON のような切羽詰まった環境では merge ミスなどで時間を浪費するという考えから、branch を使うことも禁止です。 常に歴史が master 一本になるように運用しています。

mamiya2020

お手製の最強デプロイスクリプト。名前は sora_h パイセンの mamiya にあやかっています。

初めて mamiya と名の付くデプロイスクリプトを用意したのは ISUCON7 のときで、そのときは競技時間中に osyoyu が書いてくれたのですが、この mamiya2020 は私が昨年 ISUCON10 に向けて開発したものです。

この mamiya2020 は、webapp/ruby 以下のアプリケーションのソースコードは当然のこと、/etc/nginx.conf/etc/my.cnf などもデプロイしてくれるというスグレモノ。 しかも .gitignore を考慮して配布ファイルをフィルタしてくれるので不要なログファイルなどを転送してしまう無駄もなし。

ちなみに、deploy などという名前を使わず、わざわざこんなふざけた命名をしているのかといえば、Ruby で優勝した sora_h パイセンへの憧れを忘れずにいようとかそういうことはなく、まぁ単にふざけただけです。

それでも今となってはチーム内の大切なユビキタス言語となっており、競技終了間際では「ベンチ前にマミって!」「マミった!」「ベンチ回します!!」という声が響いています。

isukekka

たぶん詳細は初公開。チーム「ソレイユ」の秘密兵器のひとつ。

ベンチマーク走行終了後、ベンチマーク走行中のログを自動で集計・分析し、結果を通知してくれるというもの。 これも私、KOBA789 作。

ざっくり言うと、/initialize のリクエストハンドラ内で各種ログをローテート、別プロセスで sleep 75 を開始して、75秒後に溜まったログを分析するために alppt-query-digest を起動するということになっています。

alppt-query-digest の出力は autoindex on な nginx でサーブされており、以下のようにアクセスできます。

f:id:koba789:20210822164852p:plain
isukekka が吐き出したファイル

同時にチームの GitHub リポジトリにも上記ファイルへのリンクが書かれた Issue が作られ、その通知が Slack に流れます。

f:id:koba789:20210822165013p:plain

この isukekka により、「Slack の通知が来たらそれを見てプロファイリングすればいい」というワークフローが完成しています。

isukit

環境構築便利ツール集。Itamae レシピの集合体。 ISUCON 9 のときに s4ichi と osyoyu が整備してくれたのが発端。 今回は無職時間を有効活用して私がだいぶメンテしました。

我々は前述のとおりサーバーサイドプログラミング戦法を採用しているわけですが、そのためにはいつも使っている様々なコマンドラインツールが揃っていないと不便です。 それらをチマチマインストールしたり設定していたりしては時間がもったいないので、すべて自動化しています。

また MySQL 8 に強い執着のある我々のために MySQL 公式の mysql-server パッケージをインストールするためのレシピもほぼ自動化されています。 このおかげで、ISUCON11 予選でもなんの迷いもなく MariaDB 10.3 から MySQL 8 に乗り換えることができました。

そういえば元々は Itamae レシピの集合体だったのだけれど、最近はそれらを含む秘密兵器セット全体を指すようになってる、気がする。

osyoyu/stackprof と speedscope

osyoyu/stackprof はその名の通り、osyoyu が改造した stackprof。 speedscope は各種プロファイラの flamegraph をかなりいい感じに可視化してくれるビジュアライザ。

osyoyu/stackprof の詳細は本人が書いてくれる、と思うのだけれど、speedscope での可視化の結果はかなり映えるので貼っておく。

f:id:koba789:20210822170312p:plain
映えるspeedscope。Ruby のプロファイリングができる

yalp

SQL で再実装された alp。KOBA789 作。

本家 alp は非常に手軽に一方で、集計条件などの細かい設定はできない(またはやりづらい)という特徴があります。

KOBA789 は SQL が得意なため、だったら SQL で書きゃいいじゃんということで書き直しました。再実装をすると、alp の集計内容の筋の良さがよくわかります。

SQL で書き直したことで、 「ユニークユーザー数のカラムも欲しい」みたいな要望にすぐ対応できるようになりました。

うちのチームで「alp」と言った場合、この yalp を指します。

たたかいのきろく

あくまで KOBA789 の視点です。見えてないところでも他のメンバーはなんかやってた。

  • 10:00 競技開始
    • koba789: CFn スタックを作る
    • koba789: マニュアルを音読しはじめる
  • 10:20
    • koba789: マニュアルの通読が終わる
    • osyoyu&s4ichi: アプリケーション仕様の理解のための議論開始
    • koba789: インフラ構築開始
  • 10:21 頃
    • koba789: ubuntu-cloud-image のデフォルトパッケージとの差分をとり、MariaDB に気づく
  • 10:28
    • koba789: 2台目のサーバーに実家環境構築完了
      • 他の2名がいつものエディタでコードを読める環境ができた
  • 10:46
    • koba789: 1台目のサーバーで完全な開発環境の構築完了
      • MariaDBMySQL 8 に移行された
      • 上記秘密兵器がすべて利用可能な状態になった
  • 11:04
    • koba789: すべてのサーバーで完全な環境の構築が完了
      • 1台目のサーバーのコード・設定を他の2台に mamiya で配れるようになった
      • いつでもトラフィックを分散可能になった
  • 11:10 頃
    • koba789: osyoyu&s4ichi から読解したアプリケーション仕様の申し送りを受ける
  • 11:30 頃
    • koba789: ISU のメトリクスの write heavy であることに気づく
    • koba789: 構造の抜本的な改善ができるか考えるため、read エンドポイントのロジックを読み解き始める
  • 12:30 頃
    • koba789: graph のロジックに完全に頭をやられる
    • osyoyu: icon を DB から降ろそうとして盛大にバグらせはじめる
  • 13:00 頃
    • koba789: icon 周りのバグは nginx の try_files のミスであることを指摘
    • osyoyu: なお icon 周りでバグが出て悩む
  • 13:30 頃
    • koba789: icon のバグは認証の不備であること指摘。X-Accel-Redirect を提案
    • koba789: graph の読解を諦める
    • koba789: s4ichi に /api/trend は SQL の LATERAL JOIN で解けると提案
  • 14:00 頃
    • s4ichi: /api/trend を非同期化
      • 非同期化というか、別デーモン化(loop do; sleep; end)
      • 定期的に JSON をファイルに吐いて nginx に配らせることに
      • 勝手に E-Tag も付いて便利最高
  • 15:00 頃
    • koba789: 適当にインデックスを貼る
  • 15:30 頃
    • koba789: 2台目・3台目も活用する構成にする
      • ようやく2万点
    • s4ichi: calculate_condition_level 消さないと速くならんよと指摘
    • このへんで mysql2 gem がめっちゃマルチスレッド絡みっぽいエラーを出し始めた
    • s4ichi: puma から unicorn へ切り替え
  • 16:10 頃
    • koba789: is_dirty, is_overweight, is_broken を各カラムに分離、generated column で condition_level を埋めた isu_condition2 テーブルを作成
  • 16:30 頃
    • osyoyu&s4ichi&koba789: isu_condition2 テーブルを使うようにすべてのクエリを書き換え完了
  • 17:00 頃
    • osyoyu: GET /api/isu がめっちゃバグる
      • koba789 の提案に従って LATERAL JOIN を使ったが、LEFT OUTER にならなくて悩む
  • 17:15 頃
    • ベンチマーカー(ポータル)が落ちる
  • 17:30 頃
    • koba789: 冷静になるチャンスをもらったと前向きになる
  • 17:54
    • koba789: 冷静さを取り戻す前に闇雲に apt install redis-server
  • 18:05 頃
    • ベンチマーカーが復活
  • 18:10 頃
    • koba789: 冷静になった末、isu_condition2 テーブルの DB 分割を決断
      • 他のメンバーに LATERAL JOIN 使えとか言っておきながら JOIN が使えないインフラ構成への変更を強行(なお競技終了35分前)
  • 18:39
    • s4ichi: 分割された isu_condition2 テーブルへの対応を完了
    • 過去最高スコアを記録
  • 18:45 競技終了
    • 最後に見たスコアは 83520

まとめ

Ruby で出場すると準備含めてやることがたくさんあって楽しい!!!!!

Ruby で戦っているチームだからこそ見える Go の優位性があり、それが見えるからこその戦法とツール開発があります。

たぶんまた来年も Ruby で出ます。

WEB+DB PRESS Vol.122に特集「Rustで実装!作って学ぶRDBMSのしくみ」を書いた

f:id:koba789:20210408181437p:plain:w735

KOBA789 です。

時が経つのは早いもので、気づけば2月末に無職になってから1ヶ月以上が過ぎていました。

その間に何をしていたのかといえば、表題の特集記事の執筆をしていました。

宣伝

このブログ記事は WEB+DB PRESS Vol.122 を読みたくなるためのものです。ぜひ買ってね。買ったらちゃんと読んでね。

gihyo.jp

使用言語は Rust だし、RDBMS はそもそも難しいトピックだしで結構重めの内容ですが、まずは読み物として寝転びながらでもいいので読んでみてほしいです。

ゴールデンウィーク*1の自由研究のお供にもどうぞ。たぶんちょうどいい分量なんじゃないかなぁ。ゴールデンウィーク明けは自作 RDBMS を友人・同僚に自慢しましょう。

内容

タイトルのとおり、Rust で RDBMS を自作します。といっても主眼は RDBMS 自作ではなく、RDBMS の仕組みを知ることです。

作ろうとすると仕組みを知らざるをえないので、学びたいなら作りゃいいじゃんという理屈です。

実際の内容は下記目次を見てください。知ってる人が見ると「あれがない」「これがない」となりそうな目次ですが、まさか full-featured な RDBMS を学習目的で作るわけにはいかないのでご容赦ください。

目次: WEB+DB PRESS Vol.122|技術評論社

きっかけ

以下自分語り。

当ブログの以下の記事を見つけた WEB+DB PRESS の編集の方からお誘いの連絡をいただきました。些細なことでもブログに書いておくもんですね。

diary.hatenablog.jp

ちなみに、WEB+DB PRESS の特集記事で扱っている題材の RDBMS は、上記ブログ記事で取り上げている実装 qp とは別物です。

いくらかコードは流用していますが、WEB+DB PRESS 用に新規で書き下ろしています。発売に合わせてリポジトリを公開します。公開したらここにも追記しておきます。

追記: 先行販売にあわせてリポジトリを公開しました。

github.com

執筆

執筆は想像以上に大変で、想像より楽しかったです*2

実はこの規模の文章の執筆経験というのはあまりなく、しかも特集丸々ひとつを一人で考えて書かなきゃいけなかったので大変でした。

ある程度分量があると1日では書き切れないので作業が日を跨ぎます。するとモチベーションのコントロールが必要で、しかしこれは一人でやってるとどうにも難しい。

執筆自体は楽しくて、いつものノリで早口オタクを繰り広げたやつを文字にするだけでした。バーッと吐き出して、余計だなぁと思ったところを切り取るといった感じです。

吐き出すのはすごく楽しいですが、切り取るのは楽しくないですね。編集の方にいろいろ手伝ってもらいながらなんとか整えました。

感想

機会に恵まれたなぁと思います。私自身は極めて怠惰なので自発的に何かを成し遂げるということがなく、だいたいは大見得切ったばっかりに引くに引けなくなって最後までやることになるパターンです。

今回のように大見得切るチャンスをいただけると、自発的にはできないようなことを(結果的に)成せるのでありがたいです。

そういえば、かつて青木峰郎(前職の上司、って表現でいいのかな)に「ふつうの RDBMS」って本書いてくださいよ、と言ったことがありました。

結局未だに書いてくれてないんですが、どうしても読みたいので少しくらいは自分で書かないとダメかなと思って今回書いたみたいな経緯があります。

今後

発売めでたいハイ終わり、でもいいんですが、DBMS オタクとしてはまだまだ語り足りないことも多いのでどこかでまた吐き出せたらいいなと思っています。

DBMS フレンズがあまりいないので話したいことが溜まってるんですよね。無職になって一番困ってるのは DBMS の話をできる人間が近くにいなくなったことですし。

とにもかくにも飽き性なのですっかり忘れてるってこともありえますが、もし覚えてたらやっていきます。よろしくどうぞ。

追記2: YouTube にサンプルコードのデモを含む紹介動画を投稿しました。ゴールデンウィーク中は何本か追加で解説動画を公開していきます。こちらもよろしくどうぞ。 www.youtube.com

*1:無職は毎日ゴールデンウィークです

*2:編集の方には大変ご迷惑をおかけしました……