v0 migration to mkwbHEADmain

4 files changed, 17 insertions, 21 deletions

diff --git a/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md b/src/content/blog/2020/11/07/diy-bugs.adoc
index b1dd117..b1dd117 100644
--- a/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md
+++ b/src/content/blog/2020/11/07/diy-bugs.adoc
diff --git a/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.md b/src/content/blog/2020/11/08/paradigm-shift-review.adoc
index c98c131..c98c131 100644
--- a/_articles/2020-11-08-the-next-paradigm-shift-in-programming-video-review.md
+++ b/src/content/blog/2020/11/08/paradigm-shift-review.adoc
diff --git a/_articles/2020-11-12-durable-persistent-trees-and-parser-combinators-building-a-database.md b/src/content/blog/2020/11/12/database-parsers-trees.adoc
index 05e800e..1870fad 100644
--- a/_articles/2020-11-12-durable-persistent-trees-and-parser-combinators-building-a-database.md
+++ b/src/content/blog/2020/11/12/database-parsers-trees.adoc
@@ -1,6 +1,4 @@
----
-
-title: Durable persistent trees and parser combinators - building a database
+= Durable persistent trees and parser combinators - building a database
 
 date: 2020-11-12
 
@@ -22,7 +20,7 @@ I've made any progress on the database project
 
 There are a few areas where I've made progress, and here's a public post on it.
 
-## Proof-of-concept: DAG log
+== Proof-of-concept: DAG log
 
 The main thing I wanted to validate with a concrete implementation was the
 concept of modeling a DAG on a sequence of datoms.
@@ -80,7 +78,7 @@ This code [already exists][clj-poc], but is yet fairly incomplete:
 [clj-poc-o2-1]: https://euandre.org/git/mediator/tree/src/core/clojure/src/mediator.clj?id=db4a727bc24b54b50158827b34502de21dbf8948#n146
 [clj-poc-o2-2]: https://euandre.org/git/mediator/tree/src/core/clojure/src/mediator.clj?id=db4a727bc24b54b50158827b34502de21dbf8948#n253
 
-## Top-down *and* bottom-up
+== Top-down *and* bottom-up
 
 However, as time passed and I started looking at what the final implementation
 would look like, I started to consider keeping the PoC around.
@@ -94,7 +92,7 @@ The good thing about a reference implementation is that it has no performance of
 resources boundary, so if it ends up being 1000x slower and using 500× more
 memory, it should be find. The code can be also 10x or 100x simpler, too.
 
-## Top-down: durable persistent trees
+== Top-down: durable persistent trees
 
 In promoting the PoC into a reference implementation, this top-down approach now
 needs to go beyond doing everything in memory, and the index data structure now
@@ -120,15 +118,15 @@ what it will look like:
   building a new path from root to the leaf. The upside is that writes a lock
   free, and no coordination is needed between readers and writers, ever;
 
-1. the downside is that a single leaf update means at least `H` new nodes that
+2. the downside is that a single leaf update means at least `H` new nodes that
   will have to be flushed to disk, where `H` is the height of the tree. To avoid
   that, the writer creates these nodes exclusively on the in-memory memtable, to
   avoid flushing to disk on every leaf update;
 
-1. a background job will consolidate the memtable data every time it hits X MB,
+3. a background job will consolidate the memtable data every time it hits X MB,
   and persist it to disk, amortizing the cost of the Copy-on-Write B-Tree;
 
-1. readers than will have the extra job of getting the latest relevant
+4. readers than will have the extra job of getting the latest relevant
   disk-resident value and merge it with the memtable data.
 
 The key difference to existing Copy-on-Write B-Trees is that the new trees
@@ -155,7 +153,7 @@ more[^learn-more-db] and mature it more.
     "[Intro to Database Systems](https://www.youtube.com/playlist?list=PLSE8ODhjZXjbohkNBWQs_otTrBTrjyohi)"
     course and Alex Petrov's "[Database Internals](https://www.databass.dev/)" book.
 
-## Bottom-up: parser combinators and FFI
+== Bottom-up: parser combinators and FFI
 
 I chose Rust as it has the best WebAssembly tooling support.
 
@@ -226,7 +224,7 @@ and property-based testing for libedn.
 [rust-ffi]: https://blog.eqrion.net/future-directions-for-cbindgen/
 [libedn-repo]: https://euandre.org/git/libedn/
 
-## Conclusion
+== Conclusion
 
 I've learned a lot already, and I feel the journey I'm on is worth going
 through.
diff --git a/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md b/src/content/blog/2020/11/14/local-first-review.adoc
index 68ae03c..c24095a 100644
--- a/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md
+++ b/src/content/blog/2020/11/14/local-first-review.adoc
@@ -1,6 +1,4 @@
----
-
-title: "Local-First Software: You Own Your Data, in spite of the Cloud - article review"
+= Local-First Software: You Own Your Data, in spite of the Cloud - article review
 
 date: 2020-11-14
 
@@ -21,7 +19,7 @@ This is a review of the article
 "[Local-First Software: You Own Your Data, in spite of the Cloud][article-pdf]",
 by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan.
 
-### Offline-first, local-first
+== Offline-first, local-first
 
 The "local-first" term they use isn't new, and I have used it myself in the past
 to refer to this types of application, where the data lives primarily on the
@@ -44,7 +42,7 @@ around I think there's a chance people will prefer saying "local-first" in
 [presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides %}
 [article-pdf]: https://martin.kleppmann.com/papers/local-first.pdf
 
-### Software licenses
+== Software licenses
 
 On a footnote of the 7th ideal ("You Retain Ultimate Ownership and Control"),
 the authors say:
@@ -138,7 +136,7 @@ to achieve "The Long Now".
 
 It is less bad, but still not quite there yet.
 
-### Denial of existing solutions
+== Denial of existing solutions
 
 When describing "Existing Data Storage and Sharing Models", on a
 footnote[^devil] the authors say:
@@ -184,7 +182,7 @@ people don't do it already, since Git is built to work like that.
 
 [git-local-first]: https://drewdevault.com/2018/07/23/Git-is-already-distributed.html
 
-### Ditching of web applications
+== Ditching of web applications
 
 The authors put web application in a worse position for building local-first
 application, claiming that:
@@ -216,7 +214,7 @@ applications are possible.
 [pouchdb]: https://pouchdb.com/
 [instant-apps]: https://developer.android.com/topic/google-play-instant
 
-### Costs are underrated
+== Costs are underrated
 
 I think the costs of "old-fashioned apps" over "cloud apps" are underrated,
 mainly regarding storage, and that this costs can vary a lot by application.
@@ -241,7 +239,7 @@ maintain, backup and store their content.
 The dial measuring "cloud apps" and "old-fashioned apps" needs to be specific to
 use-cases.
 
-### Real-time collaboration is optional
+== Real-time collaboration is optional
 
 If I were the one making the list of ideals, I wouldn't focus so much on
 real-time collaboration.
@@ -268,7 +266,7 @@ When discussing "working offline", I'd rather keep this type of person in mind,
 then the subset of people who are offline when on the elevator will naturally be
 included.
 
-### On CRDTs and developer experience
+== On CRDTs and developer experience
 
 When discussing developer experience, the authors bring up some questions to be
 answered further, like: