SQLiteの知られざる物語

xguru · 2021-07-05T10:21:01+09:00

SQLite 開発者 Richard Hipp のインタビューポッドキャスト要約（38分、スクリプトあり）本業はアメリカ海軍の駆逐艦に搭載されるソフトウェアの開発者 → 艦内で使っていた Informix はエラーが多く、サーバーが落ちたり接続が切れたりしていた → 軍艦なので、戦闘中に損傷を受けても「DBに接続できません」というポップアップは出ず、頑丈に動作しなければならなかった。トランザクションも不要で、どんな状況でもデータを RAM に読み込める必要があった → サーバーなしで動く SQL DB エンジンを探したが存在しなかったため、自分で作ることにした SQLite V1（2000年） SQL 文をプログラムとみなし、クエリをコンパイルして実行するバイトコードエンジンを作成実際にはプロジェクトでは使われなかった（顧客が Informix の利用を望んだため）開発用途で使いながらインターネットで公開したところ、人々が使い始めた「Palm Pilot で SQL DB を動かしました」といった声が見られるようになり、人々の注目を集めた。それが作業継続の励みになった。 Motorola 2001〜2002年ごろ、Motorola から新しい携帯電話 OS に SQLite を入れたいと連絡が来た必要な機能をサポートしてくれれば費用を支払うという話だったオープンソースでお金を稼げることを、そのとき初めて知った約 $80,000 で、今から見れば大金ではないかもしれないが、本人にとっては非常に驚くべき額だった。一緒に働いていた3人とともにプロジェクトを進め、それが始まりになった America Online Phones 次に連絡してきたのは AOL だった CD を郵送していた時代で、その CD の中に Database が必要だったつまり CD の中に SQLite を入れたかったのであり、そのための新機能が必要だった Symbian OS と Nokia 感謝祭の時期にロンドンへ行って会議を実施（イギリスには感謝祭がないので） Symbian OS 向けの DB が求められ、他の DB と競争した（オープンソース2つ、商用7つ）他の9つの DB にもチューニングの機会が与えられたが、最終的に SQLite が勝利した Bus Factor [1] とコンソーシアムバスファクターとは、何人がバスにひかれたら開発が止まるかを示す指標本人はフルタイムで複数人と一緒に働いていたが、Symbian 側からバスファクターを高めるべきだという話が出た SQLite コンソーシアムを立ち上げ、プロジェクトに資金を提供し、より多くの人が長期的に参加できるようにしようというものだったすべてのコンソーシアムメンバーに投票権を持たせるという、ある意味で無茶なアイデアを出した Mozilla Foundation の Mitchell Baker がこれをどこかで聞きつけ、電話をかけてきた → 「Richard、あなたは完全に間違っています。コンソーシアムの作り方を教えます」 → 彼女がルール作りを始めた → 「開発者がコントロール権を持つべきです。彼らの決定が最終です。参加しただけで投票権を持つべきではありません」 → 「これを使う企業は資金提供の名誉を得ますが、最終決定はあなたが下すべきです」 → 彼女は非常に断固としており、すべてを整理した。彼女は弁護士でもある Richard が「どうやって人々に参加してもらうんですか？インセンティブは？」と尋ねると、 → 「心配しないでください。彼らは参加します。そして実際、この形なら Mozilla が創設メンバーになります」 Mozilla、Symbian、Adobe の支援を受け、この3社でコンソーシアムを開始 → 最初に Symbian からコンソーシアムが必要だと言われたとき、どうすればいいのかわからなかった。どうして Mitchell Baker がその話を聞いて電話してきたのかはわからないが、すべてが驚くべき旅だった Enter Android：Android の始まりすべてのスマートフォンが SQLite を使っていたため、Richard は初期スマートフォン開発をあらゆる側面から見ることができた 2005年に Android と会議を行った。当時は Android も iPhone もまだ登場前だった上部に小さなディスプレイとフル QWERTY キーボードを備えた BlackBerry のような端末につないで SQLite をデバッグしていた実際に動作している電話網につながった端末で GDB を使ってデバッグするのは驚くべき体験だったその時点では Motorola、Symbian、Nokia の誰もそんなことをしておらず、この時点で Android が巨大になるとわかった Guy, This Is Important：皆さん、これは本当に重要です当時、他社はハードウェアとソフトウェアの更新サイクルが30日ほどと非常に長かったが、Android は実際のネットワークにつながった電話機に1日何度も新しい OS を入れていた。 NDA のもとで受け取ったプロトタイプの Android 端末は 3D プリントしたようなケースだったが、持ち運べる程度にはなっていた。 → 他社のものは大きなブレッドボードやプロトタイプで、ネットワークにもつながっておらず、電話としては使えなかった Motorola や Symbian の人たちに「これは重要だから解決しなければならない」と言いたかったが、NDA のため言えなかった。そしてそれが差になった Testing and Aviation Standards：テストと航空標準 Adam（インタビュアー）：「今の Richard の DB は本当に活気があります。才能ある人たちと有能なチームがいる一方で、すべての Android 端末に入る DB を支えるのは、1〜4人のソフトウェアコンサルティング会社でもあります。開発者たちは DB に非常に真剣で、データに問題が起きるのを嫌います」私たちは素朴にも SQLite にはバグがないと皆に誇っていたが、Android は確実にそれが間違いだと証明した。バグのないソフトウェアを作れると思っていたが、ソフトウェアが数百万台の機器にインストールされると、どれほど多くのバグが起き得るかは驚くほどだった。そのころ、航空電子工学（Avionics）の企業 Rockwell Collins と仕事をしており、彼らが DO-178B [2] の考え方を紹介してくれた。 → DO-178B は安全性が重要な航空製品の品質標準に関するもので、他の品質標準と違って「読める（readable）」 → 数百ドルほどだが薄いので、ぜひ読んでみることを勧める実際に DO-178B のプロセスに従い始め、その1つが 100% MCDC Test Coverage だった MCDC（Modified Condition / Decision Coverage）[3] は、テストが個々の分岐を少なくとも一度は通過することを求めるもの SQLite が MCDC 100% になるまで、週60時間換算で1年かかった。本当に本当に難しく、毎日12時間取り組んで非常に疲れた。 90〜95% のテストカバレッジまでは簡単だが、残りの5%が本当に難しい。しかし1年かけて最終的に100%へ到達すると、Android からバグレポートが来なくなったそこからうまく回り始め、大きな違いを生んだ。その後 8〜9 年間バグがなかった。数十億件のテスト最初のものは TCL（Tool Command Language）で書かれた一般的な開発者向けテストだった最初の TCL テストはいまも保守されており、公開されている。100% ではないが、SQLite の全機能を詳細にテストしている。 MCDC 100% カバレッジは TH3 と呼ばれ、公開していない（proprietary）これを航空会社に売って収益化しようとしたが、1本も売れなかったのでその点では効果はなかった.. しかしこれによって製品を本当に堅牢に保ち、新機能やバグ修正を素早く進められるようになったテスト数を数えるのは難しいが、10万件の個別テストがパラメータ化され、数十億件のテストが実行されるチェックリストがあり、リリース前には最低3日間テストを実施する意図的に複数の OS でテストしている → 今ではほとんどの機器がリトルエンディアンだが、昔はビッグエンディアンも多かった。そのため PowerPC iBook でビッグエンディアンのテストを行った → 32ビットプラットフォーム、ARM と Intel、64 Bit プラットフォーム、Windows、Linux、Mac、OpenBSD など、可能な限りあらゆるプラットフォームと OS でテストしている → 複数の異なるテストスイートがあり、元の TCL もあれば TH3 もある。継続的に実行される Fuzzer（ファジング）もある。 SQL Logic テストもある → 10年前に Shane Harrelson が作った膨大なダミー SQL 文群 → 触れられるあらゆる DB でテストしたところ、すべての DB エンジンが答えを出せず、セグメンテーションフォルトを起こした。SQLite も含めて。ただし Postgres を除く。 → Postgres だけは常に結果を返し、欠点を見つけられなかった。Postgres の開発者たちは、こちらの努力が足りないだけだと言ったが.. Postgres でエラーを出させることは可能だったのかもしれないが、私たちは非常に感銘を受けた → 商用版 Oracle もクラッシュし、DB2 もクラッシュした → 重要なのは、SQLite がこれらすべてのクエリに対して同じ答えを返すようにしたことだ Building From First Principles 最初に書き始めたとき、SQL DB エンジンの作り方について参考資料があるか探したが、なかった。だから自分で作るしかなく、完全に独立した任務だった。多くの理論は MIT、ハーバード、バークレーで生まれていたが、そうした大学に行かなければ、そのような理論が存在することすら知らず、探し方もわからなかった。 Postgres が使う Volcano モデルと SQLite が使う Byte Code モデルを見比べると、私たちは結局同じアイデアへ収束している上から見るとまったく異なる場所から始まっているようでも、どうすればそれを速くできるかという点で同じ領域へ収束するこれは理論的な一種の検証だと思う。2つの独立した開発ラインが同じ答えにたどり着くのだからたとえば、私は Covering Index についてまったく知らなかったが、ドイツで開かれた PHP カンファレンスに参加したとき、MySQL の David Axmark も登壇して講演をしていた → その講演で MySQL がどのように Covering Index を作ったか説明していた → DB のインデックスに複数のカラムがあり、インデックス先頭側のカラムだけでクエリでき、答えが残りのカラムにあるなら、DB は元のテーブルを参照せずインデックスだけで処理できるため高速になる → そこで帰りの飛行機で乗客が少なかったので、ノート PC を開き、大西洋の上空で SQLite の Covering Index を実装した B-Trees and The Art of Computer Programming 多くのものを自分で作らなければならなかった。B Tree を誰かに教わったことはなく、ただ名前を聞いたことがあるだけだった。自分で B ツリーを実装しようとしたとき、本棚に Don Knuth の TAOCP があり、そこで B ツリーを調べると、彼がアルゴリズムを説明してくれていた面白いことに、本には B ツリーの探索と挿入アルゴリズムは詳しく書かれているが、削除アルゴリズムは載っていない。それは章末の練習問題にあり、自分の B ツリーを作る前にその問題を解かなければならなかった。「ありがとう Don、本当にありがとう」現代の人たちも、少なくとも TAOCP を読むか、ざっと目を通すべきだ Freedom to Build It Yourself：自分で作る自由 SQLite は Richard 自身が作ったもの以外には何にも依存していない（C コンパイラと libc を除く）。バージョン管理システムもバグトラッカーも自作した。それが Richard に自由を与える自由（Freedom）とは、自分の面倒を自分で見られることを意味するバックパッカーが必要なものをすべて背負って旅をしながら自由だと言うのは、自分で自分の面倒を見ているからだすべてを自分で作れば、誰かに縛られないので、その中に自由があるもし SQLite 2 のストレージエンジンに Berkeley DB を選んでいたと仮定すると → 当時 Berkeley DB はオープンソースだったが、後に Oracle に買収され、デュアルソースの独占モデルになり、ライセンス費を払わなければ最新版のソースコードを入手できなくなった現在 SQLite の Parser Generator は Yak や Bison を使わず、自作の Lemon を使っている。そのため新しい言語機能が必要なとき、それらに縛られず修正できた 2000年代初頭はどのプロジェクトも CVS を使っていたのでそれを使っていたが、2000年代半ばになると分散バージョン管理というアイデアが出始めた Fossil 構築 Git と Mercurial を見て要件を整理したうえで、自分でバージョン管理システムを開発することにした今では Fossil はうまく動作し、独立したプロジェクトになっている Torvalds は Linux Kernel の開発を支援するために Git を作ったので、Linux Kernel 関連の作業をするなら Git は完璧なバージョン管理システムだ Fossil は SQLite の作業をするためにぴったりのバージョン管理システムだ。自分で作ったので、自分の要件を正確に満たしている自分で開発することで、自分の運命をコントロールし、より大きな自由を持ち、第三者に依存しなくて済む自給自足すること都市を離れ、自分で食料を育てて暮らす人を何と呼ぶだろう？ Survivalist（サバイバリスト）？あるいは Prepper（プレッパー）？「あなたとやり取りしている間にも見えたように、私の Gmail は少しおかしい。メールが何度も返ってきます。だから自分のメールサーバーを作ろうとしています。私たちがこのミーティングをセットアップしている間にも、そのためのメモを書いていました。DB エンジンを書くより難しくはないでしょうが、Gmail に縛られたくないのです。彼らに自分の運命をコントロールされたくない。自分のすべての会話記録を彼らに握られたくない。自分でコントロールしたい。だから苦痛でやることが多くても、自分でコントロールできる解決策を見つけようとしています。クラウドで仮想マシンを借りて動かせば、第三者に依存せずに済みます」誰かがやって来て「あなたの問題を解決してあげます」と言うなら、その人たちはあなたの自由を奪うのだと知るべきだ。「自由でいたいなら、自分でやるべきです」他の人への助言私は、サーバーを必要とせずディスク上で直接読み書きする DB エンジンを作るという、無茶なアイデアから始めました。専門家に聞けば「それは不可能です。絶対に動きません。愚かなアイデアです」と言うでしょう。幸運なことに、私はそういう専門家を知らなかったので、そのままやりました。そしてこうしたことが起きました。専門家の言葉を聞きすぎず、筋の通ったことをやってください。自分の問題を解決してください -- [1] Bus Factor：チームメンバーがバスにひかれてチームが危機に陥る可能性を示すリスク指標。チームメンバー間で情報や機能が共有されていないことで生じうるリスクを表す指標。この指数を高めることで情報共有が進み、特定の個人に業務が集中しにくくなる。 [2] DO-178B：航空機システムおよび装備の認証に関するソフトウェア上の考慮事項（Software Considerations in Airborne Systems and Equipment Certification）米連邦航空局（FAA）により、航空用ソフトウェア認証の適合性を示す方法として採用 [3] MCDC：Modified Condition / Decision Coverage 複数の条件式があるとき、各個別条件式が他の条件式の影響を受けず、全体の条件式の結果に独立して影響するようにテストケースを設計する方法

(corecursive.com)

47 ポイント投稿者 xguru 2021-07-05 | 16件のコメント | WhatsAppで共有

SQLite 開発者 Richard Hipp のインタビューポッドキャスト要約（38分、スクリプトあり）
本業はアメリカ海軍の駆逐艦に搭載されるソフトウェアの開発者
→ 艦内で使っていた Informix はエラーが多く、サーバーが落ちたり接続が切れたりしていた
→ 軍艦なので、戦闘中に損傷を受けても「DBに接続できません」というポップアップは出ず、頑丈に動作しなければならなかった。
トランザクションも不要で、どんな状況でもデータを RAM に読み込める必要があった
→ サーバーなしで動く SQL DB エンジンを探したが存在しなかったため、自分で作ることにした

SQLite V1（2000年）

SQL 文をプログラムとみなし、クエリをコンパイルして実行するバイトコードエンジンを作成
実際にはプロジェクトでは使われなかった（顧客が Informix の利用を望んだため）
開発用途で使いながらインターネットで公開したところ、人々が使い始めた
「Palm Pilot で SQL DB を動かしました」といった声が見られるようになり、人々の注目を集めた。それが作業継続の励みになった。

Motorola

2001〜2002年ごろ、Motorola から新しい携帯電話 OS に SQLite を入れたいと連絡が来た
必要な機能をサポートしてくれれば費用を支払うという話だった
オープンソースでお金を稼げることを、そのとき初めて知った
約 $80,000 で、今から見れば大金ではないかもしれないが、本人にとっては非常に驚くべき額だった。
一緒に働いていた3人とともにプロジェクトを進め、それが始まりになった

America Online Phones

次に連絡してきたのは AOL だった
CD を郵送していた時代で、その CD の中に Database が必要だった
つまり CD の中に SQLite を入れたかったのであり、そのための新機能が必要だった

Symbian OS と Nokia

感謝祭の時期にロンドンへ行って会議を実施（イギリスには感謝祭がないので）
Symbian OS 向けの DB が求められ、他の DB と競争した（オープンソース2つ、商用7つ）
他の9つの DB にもチューニングの機会が与えられたが、最終的に SQLite が勝利した

Bus Factor [1] とコンソーシアム

バスファクターとは、何人がバスにひかれたら開発が止まるかを示す指標
本人はフルタイムで複数人と一緒に働いていたが、Symbian 側からバスファクターを高めるべきだという話が出た
SQLite コンソーシアムを立ち上げ、プロジェクトに資金を提供し、より多くの人が長期的に参加できるようにしようというものだった
すべてのコンソーシアムメンバーに投票権を持たせるという、ある意味で無茶なアイデアを出した
Mozilla Foundation の Mitchell Baker がこれをどこかで聞きつけ、電話をかけてきた
→ 「Richard、あなたは完全に間違っています。コンソーシアムの作り方を教えます」
→ 彼女がルール作りを始めた
→ 「開発者がコントロール権を持つべきです。彼らの決定が最終です。参加しただけで投票権を持つべきではありません」
→ 「これを使う企業は資金提供の名誉を得ますが、最終決定はあなたが下すべきです」
→ 彼女は非常に断固としており、すべてを整理した。彼女は弁護士でもある
Richard が「どうやって人々に参加してもらうんですか？インセンティブは？」と尋ねると、
→ 「心配しないでください。彼らは参加します。そして実際、この形なら Mozilla が創設メンバーになります」
Mozilla、Symbian、Adobe の支援を受け、この3社でコンソーシアムを開始
→ 最初に Symbian からコンソーシアムが必要だと言われたとき、どうすればいいのかわからなかった。どうして Mitchell Baker がその話を聞いて電話してきたのかはわからないが、すべてが驚くべき旅だった

Enter Android：Android の始まり

すべてのスマートフォンが SQLite を使っていたため、Richard は初期スマートフォン開発をあらゆる側面から見ることができた
2005年に Android と会議を行った。当時は Android も iPhone もまだ登場前だった
上部に小さなディスプレイとフル QWERTY キーボードを備えた BlackBerry のような端末につないで SQLite をデバッグしていた
実際に動作している電話網につながった端末で GDB を使ってデバッグするのは驚くべき体験だった
その時点では Motorola、Symbian、Nokia の誰もそんなことをしておらず、この時点で Android が巨大になるとわかった

Guy, This Is Important：皆さん、これは本当に重要です

当時、他社はハードウェアとソフトウェアの更新サイクルが30日ほどと非常に長かったが、Android は実際のネットワークにつながった電話機に1日何度も新しい OS を入れていた。
NDA のもとで受け取ったプロトタイプの Android 端末は 3D プリントしたようなケースだったが、持ち運べる程度にはなっていた。
→ 他社のものは大きなブレッドボードやプロトタイプで、ネットワークにもつながっておらず、電話としては使えなかった
Motorola や Symbian の人たちに「これは重要だから解決しなければならない」と言いたかったが、NDA のため言えなかった。そしてそれが差になった

Testing and Aviation Standards：テストと航空標準

Adam（インタビュアー）：「今の Richard の DB は本当に活気があります。才能ある人たちと有能なチームがいる一方で、すべての Android 端末に入る DB を支えるのは、1〜4人のソフトウェアコンサルティング会社でもあります。開発者たちは DB に非常に真剣で、データに問題が起きるのを嫌います」
私たちは素朴にも SQLite にはバグがないと皆に誇っていたが、Android は確実にそれが間違いだと証明した。
バグのないソフトウェアを作れると思っていたが、ソフトウェアが数百万台の機器にインストールされると、どれほど多くのバグが起き得るかは驚くほどだった。
そのころ、航空電子工学（Avionics）の企業 Rockwell Collins と仕事をしており、彼らが DO-178B [2] の考え方を紹介してくれた。
→ DO-178B は安全性が重要な航空製品の品質標準に関するもので、他の品質標準と違って「読める（readable）」
→ 数百ドルほどだが薄いので、ぜひ読んでみることを勧める
実際に DO-178B のプロセスに従い始め、その1つが 100% MCDC Test Coverage だった
MCDC（Modified Condition / Decision Coverage）[3] は、テストが個々の分岐を少なくとも一度は通過することを求めるもの
SQLite が MCDC 100% になるまで、週60時間換算で1年かかった。本当に本当に難しく、毎日12時間取り組んで非常に疲れた。
90〜95% のテストカバレッジまでは簡単だが、残りの5%が本当に難しい。しかし1年かけて最終的に100%へ到達すると、Android からバグレポートが来なくなった
そこからうまく回り始め、大きな違いを生んだ。その後 8〜9 年間バグがなかった。

数十億件のテスト

最初のものは TCL（Tool Command Language）で書かれた一般的な開発者向けテストだった
最初の TCL テストはいまも保守されており、公開されている。100% ではないが、SQLite の全機能を詳細にテストしている。
MCDC 100% カバレッジは TH3 と呼ばれ、公開していない（proprietary）
これを航空会社に売って収益化しようとしたが、1本も売れなかったのでその点では効果はなかった..
しかしこれによって製品を本当に堅牢に保ち、新機能やバグ修正を素早く進められるようになった
テスト数を数えるのは難しいが、10万件の個別テストがパラメータ化され、数十億件のテストが実行される
チェックリストがあり、リリース前には最低3日間テストを実施する
意図的に複数の OS でテストしている
→ 今ではほとんどの機器がリトルエンディアンだが、昔はビッグエンディアンも多かった。そのため PowerPC iBook でビッグエンディアンのテストを行った
→ 32ビットプラットフォーム、ARM と Intel、64 Bit プラットフォーム、Windows、Linux、Mac、OpenBSD など、可能な限りあらゆるプラットフォームと OS でテストしている
→ 複数の異なるテストスイートがあり、元の TCL もあれば TH3 もある。継続的に実行される Fuzzer（ファジング）もある。
SQL Logic テストもある
→ 10年前に Shane Harrelson が作った膨大なダミー SQL 文群
→ 触れられるあらゆる DB でテストしたところ、すべての DB エンジンが答えを出せず、セグメンテーションフォルトを起こした。SQLite も含めて。ただし Postgres を除く。
→ Postgres だけは常に結果を返し、欠点を見つけられなかった。Postgres の開発者たちは、こちらの努力が足りないだけだと言ったが.. Postgres でエラーを出させることは可能だったのかもしれないが、私たちは非常に感銘を受けた
→ 商用版 Oracle もクラッシュし、DB2 もクラッシュした
→ 重要なのは、SQLite がこれらすべてのクエリに対して同じ答えを返すようにしたことだ

Building From First Principles

最初に書き始めたとき、SQL DB エンジンの作り方について参考資料があるか探したが、なかった。だから自分で作るしかなく、完全に独立した任務だった。
多くの理論は MIT、ハーバード、バークレーで生まれていたが、そうした大学に行かなければ、そのような理論が存在することすら知らず、探し方もわからなかった。
Postgres が使う Volcano モデルと SQLite が使う Byte Code モデルを見比べると、私たちは結局同じアイデアへ収束している
上から見るとまったく異なる場所から始まっているようでも、どうすればそれを速くできるかという点で同じ領域へ収束する
これは理論的な一種の検証だと思う。2つの独立した開発ラインが同じ答えにたどり着くのだから
たとえば、私は Covering Index についてまったく知らなかったが、ドイツで開かれた PHP カンファレンスに参加したとき、MySQL の David Axmark も登壇して講演をしていた
→ その講演で MySQL がどのように Covering Index を作ったか説明していた
→ DB のインデックスに複数のカラムがあり、インデックス先頭側のカラムだけでクエリでき、答えが残りのカラムにあるなら、DB は元のテーブルを参照せずインデックスだけで処理できるため高速になる
→ そこで帰りの飛行機で乗客が少なかったので、ノート PC を開き、大西洋の上空で SQLite の Covering Index を実装した

B-Trees and The Art of Computer Programming

多くのものを自分で作らなければならなかった。B Tree を誰かに教わったことはなく、ただ名前を聞いたことがあるだけだった。
自分で B ツリーを実装しようとしたとき、本棚に Don Knuth の TAOCP があり、そこで B ツリーを調べると、彼がアルゴリズムを説明してくれていた
面白いことに、本には B ツリーの探索と挿入アルゴリズムは詳しく書かれているが、削除アルゴリズムは載っていない。それは章末の練習問題にあり、自分の B ツリーを作る前にその問題を解かなければならなかった。「ありがとう Don、本当にありがとう」
現代の人たちも、少なくとも TAOCP を読むか、ざっと目を通すべきだ

Freedom to Build It Yourself：自分で作る自由

SQLite は Richard 自身が作ったもの以外には何にも依存していない（C コンパイラと libc を除く）。バージョン管理システムもバグトラッカーも自作した。それが Richard に自由を与える
自由（Freedom）とは、自分の面倒を自分で見られることを意味する
バックパッカーが必要なものをすべて背負って旅をしながら自由だと言うのは、自分で自分の面倒を見ているからだ
すべてを自分で作れば、誰かに縛られないので、その中に自由がある
もし SQLite 2 のストレージエンジンに Berkeley DB を選んでいたと仮定すると
→ 当時 Berkeley DB はオープンソースだったが、後に Oracle に買収され、デュアルソースの独占モデルになり、ライセンス費を払わなければ最新版のソースコードを入手できなくなった
現在 SQLite の Parser Generator は Yak や Bison を使わず、自作の Lemon を使っている。そのため新しい言語機能が必要なとき、それらに縛られず修正できた
2000年代初頭はどのプロジェクトも CVS を使っていたのでそれを使っていたが、2000年代半ばになると分散バージョン管理というアイデアが出始めた

Fossil 構築

Git と Mercurial を見て要件を整理したうえで、自分でバージョン管理システムを開発することにした
今では Fossil はうまく動作し、独立したプロジェクトになっている
Torvalds は Linux Kernel の開発を支援するために Git を作ったので、Linux Kernel 関連の作業をするなら Git は完璧なバージョン管理システムだ
Fossil は SQLite の作業をするためにぴったりのバージョン管理システムだ。自分で作ったので、自分の要件を正確に満たしている
自分で開発することで、自分の運命をコントロールし、より大きな自由を持ち、第三者に依存しなくて済む

自給自足すること

都市を離れ、自分で食料を育てて暮らす人を何と呼ぶだろう？ Survivalist（サバイバリスト）？あるいは Prepper（プレッパー）？
「あなたとやり取りしている間にも見えたように、私の Gmail は少しおかしい。メールが何度も返ってきます。だから自分のメールサーバーを作ろうとしています。私たちがこのミーティングをセットアップしている間にも、そのためのメモを書いていました。DB エンジンを書くより難しくはないでしょうが、Gmail に縛られたくないのです。彼らに自分の運命をコントロールされたくない。自分のすべての会話記録を彼らに握られたくない。自分でコントロールしたい。だから苦痛でやることが多くても、自分でコントロールできる解決策を見つけようとしています。クラウドで仮想マシンを借りて動かせば、第三者に依存せずに済みます」
誰かがやって来て「あなたの問題を解決してあげます」と言うなら、その人たちはあなたの自由を奪うのだと知るべきだ。「自由でいたいなら、自分でやるべきです」

他の人への助言

私は、サーバーを必要とせずディスク上で直接読み書きする DB エンジンを作るという、無茶なアイデアから始めました。
専門家に聞けば「それは不可能です。絶対に動きません。愚かなアイデアです」と言うでしょう。
幸運なことに、私はそういう専門家を知らなかったので、そのままやりました。そしてこうしたことが起きました。
専門家の言葉を聞きすぎず、筋の通ったことをやってください。自分の問題を解決してください

[1] Bus Factor：チームメンバーがバスにひかれてチームが危機に陥る可能性を示すリスク指標。

チームメンバー間で情報や機能が共有されていないことで生じうるリスクを表す指標。
この指数を高めることで情報共有が進み、特定の個人に業務が集中しにくくなる。

[2] DO-178B：航空機システムおよび装備の認証に関するソフトウェア上の考慮事項（Software Considerations in Airborne Systems and Equipment Certification）

米連邦航空局（FAA）により、航空用ソフトウェア認証の適合性を示す方法として採用

[3] MCDC：Modified Condition / Decision Coverage

複数の条件式があるとき、各個別条件式が他の条件式の影響を受けず、全体の条件式の結果に独立して影響するようにテストケースを設計する方法

16件のコメント

enowy 2025-08-07

こんなに良い記事があったのですね。翻訳版で読めてよかったです。

mkeasy 2021-07-08

何度も読み返したくなる文章ですね。ありがとうございます。

自由でいたいなら、自分でやることです。

筋の通ることをしなさい。

自分の問題を解決しなさい。

edunga1 2021-07-05

本当に興味深い記事です！

"テストカバレッジ90〜95%までは簡単だが、残りの5%が本当に難しい。だが1年間そうやって最終的に100%に到達すると、Androidからバグレポートが来なくなった"

こんなことがあり得るんですね。

panarch 2021-07-05

よく読みました。ありがとうございます！

jsryu 2021-07-05

とても楽しく読ませていただきました。ありがとうございます

falconer 2021-07-05

興味深く読みました。

gmlwo530 2021-07-05

楽しく読ませていただきました！

kwangyeol 2021-07-05

楽しく読ませていただきました。ありがとうございます。

baeba 2021-07-05

興味深く読みました。

要約して整理するほうが、もっと大変そうですね。

shaichoi 2021-07-05

興味深く読みました。いろいろ考えさせられますね。ありがとうございます :)

fureweb 2021-07-05

よく読みました。ありがとうございます！

kalihman 2021-07-05

よく読みました。

jongpak 2021-07-05

時間が経つのも忘れて読んでしまいました（笑）

単純な組み込みDBだと過小評価していた自分が恥ずかしくなります^^;

sixmen 2021-07-05

ただのシンプルなローカル開発用DBMSくらいに思って使っていたのですが、まったく単純ではなかったんですね!!

nicewook 2021-07-05

とても楽しく読みました。

xguru 2021-07-05

現在、世界中で稼働しているSQLiteは1兆個を超えています。

40億台を超えるすべてのスマートフォン（Android、iOS）
Mac/Windows
FF/Chrome/Safariブラウザー
PHP/Python
Skype/iTunes/Dropbox/Turbotax
ほとんどのセットトップボックスとテレビ
ほとんどの自動車のマルチメディアシステム

https://www.sqlite.org/mostdeployed.html