v0 migration to mkwbHEADmain

2 files changed, 609 insertions, 0 deletions

diff --git a/src/content/slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides b/src/content/slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides
new file mode 100644
index 0000000..22770e6
--- /dev/null
+++ b/src/content/slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides
@@ -0,0 +1,343 @@
+---
+
+title: Rollout, feature flag, experiment, operational toggle
+
+date: 2020-10-19
+
+layout: slides
+
+lang: en
+
+ref: rollout-feature-flag-experiment-operational-toggle
+
+article: _articles/2020-10-19-feature-flags-differences-between-backend-frontend-and-mobile.md
+
+---
+
+# Rollout, feature flag, experiment, operational toggle
+Different use cases for **backend**, **frontend** and **mobile**
+
+---
+
+"Feature flags" tend to come up when talking about **continuous deployment**
+
+???
+
+I'm using "quotes" because I'm mixing up different meanings of "rollout"
+
+---
+
+# CI
+continuous integration
+
+# CD
+continuous delivery
+
+# CD
+**continuous deployment**
+
+???
+
+Background: build vocabulary, why are feature flags related to CD
+
+CI solves: manual integration of long-lived branches
+
+CD solves: automation of deployment process
+
+CD solves: releases as frequent as possible
+
+That's where the "GoCD" name comes from
+
+---
+
+# Types:
+1. rollout
+2. feature flag
+3. experiment
+4. operational toggle
+
+---
+
+# rollout
+## For *rolling out* a new version of software
+
+**Short-lived** using **percentages**
+
+- a [new deployment of k8s][k8s]
+- new [APK released to the Play Store][apk]
+
+[k8s]: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment
+[apk]: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en
+
+???
+
+Relevant as long as the new code is deployed
+
+---
+
+# feature flag
+## For turning a feature *on* or *off*
+
+**Medium-lived** using **allow list**, **A/B test**, **percentage**,
+**app version**, *etc*.
+
+- `:new-chargeback-flow`
+- `:new-debit-card-activation-screen`
+
+???
+
+Relevant as long as the new code is being developed
+
+---
+
+# experiment
+## For analyzing behaviour
+
+**Medium-lived** using **allow list** and **A/B test**
+
+- `:debit-withdrawal-test`
+
+---
+
+# operational toggle
+## For disabling features in `#crash`-like situations
+
+**Long-lived** using **percentage**
+
+- `:bank-barcode-payment`
+- `:savings-bank-barcode-query-provider`
+
+???
+
+Lives for as long as the code is in production.
+
+It feels like a system-level circuit breaker.
+
+---
+
+We now know about the types
+
+## But they have different relevance for **backend**, **frontend** and **mobile**
+
+---
+
+# backend
+
+1. **rollout**: k8s blue/green, canary and ~`common-rollout`~ `common-xp`
+2. **feature flag**: ~`common-rollout`~ `common-xp` and datasets
+3. **experiment**: `common-xp`
+4. **operational toggle**: ~`common-rollout`~ `common-xp`
+
+???
+
+This is a bit why common-rollout isn't called *common-feature-flag*: it was
+initially designed with backend usage of mostly *rollouts* in mind, and just a
+bit *feature flags*.
+
+Avoid using configuration for doing operational toggles: it is less dynamic, so
+it defeats the purpose.
+
+---
+
+# frontend
+
+1. **rollout**: CDN and page refreshes
+2. **feature flag**: percentages and maybe IPs (no `:customer/id` on the website)
+3. **experiment**: via dynamic backend control
+4. **operational toggle**: via dynamic backend control
+
+---
+
+# mobile
+
+1. **rollout**: app stores
+2. **feature flag**: via dynamic backend control
+3. **experiment**: via dynamic backend control
+4. **operational toggle**: via dynamic backend control
+
+---
+
+Key differentiator is
+## How much **control** we have over the **environment**
+
+---
+
+## **backend**
+
+# Full control
+🎉
+
+???
+
+Can edit, update and even delete rollouts as desired.
+
+Mix and match at will!
+
+---
+
+## **frontend**
+
+# Partial control
+
+When choose when to make a new version available
+
+???
+
+We can control when a new version is available, partially when someone will
+upgrade it.
+
+But it is easy to fallback to "reload the page and try again".
+
+---
+
+## **mobile**
+
+# Very limited control
+
+- app stores can restrict updates (worse for iOS)
+- customers still have to download new versions
+
+---
+
+# Costs
+
+- more complex code
+- compatibility with old app versions
+- nesting is exponential
+
+---
+
+# Benefits
+
+- dynamicity
+
+---
+
+## Weighting costs × benefits
+
+The less control we have, the more we value dynamicity
+
+---
+
+## Weighting costs × benefits
+
+- backend: sometimes worth the cost
+- frontend: almost always worth cost
+- mobile: **always** worth cost
+
+---
+
+# Best practices
+
+---
+
+## Dynamic content > feature flag
+
+Always true for **mobile**, almost always for **frontend**
+
+---
+
+## Use `:include-list` for named groups
+
+Always true for **backend**, **frontend** and **mobile**
+
+{% raw %}
+```clojure [2-3]
+{:rules
+ #{{:type    :include-list
+    :content {:filename "debit-team-members.txt"}}}}
+```
+{% endraw %}
+
+---
+
+## Always use `:app-version`
+
+only for **mobile**
+
+{% raw %}
+```clojure [2]
+{:rules
+ #{{:type    :app-version
+    :content {:min-version #{{:platform :android
+                              :code     1000000}
+                             {:platform :ios
+                              :code     2000000}}}}}}
+```
+{% endraw %}
+
+---
+
+## Extend ~`common-rollout`~ `common-xp` if required
+
+That's how `:include-list`, `:app-version`, *etc.* were born
+
+---
+
+## Beware of many nested feature flags
+
+True for **backend**, **frontend** and **mobile**
+
+???
+
+Exponential growth of combinations
+
+---
+
+## Don't delete app-facing feature flags
+
+True for **mobile**
+
+???
+
+This could break old app versions, only do this intentionally
+
+We don't have (yet) a strategy for dealing with LTS of the app, and we just say:
+"we'll support every app version out there".
+
+---
+
+## Include a feature flag on the whiteboarding phase
+
+---
+
+## Include deleting/retiring the feature flag at the end
+
+---
+
+## Avoid renaming a feature flag
+
+Use `:app-version` with `:min-version` instead
+
+---
+
+# And most importantly...
+
+---
+
+# ***Always*** rely on a feature flag on the app
+
+Never do a hot fix, avoid expedited releases at all costs
+
+???
+
+The app is where we have less control, so the feature flag is how we get some of
+that control back.
+
+This doesn't mean you'll need 1 feature flag per PR
+
+There's not such thing as:
+"This is such a small thing, it doesn't need a feature flag"
+
+You should ask yourself:
+"It this crashes the app, am I OK with waiting for the next release train?"
+
+---
+
+## Thank you!
+
+References:
+
+1. "[Feature Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html)", by Pete Hodgson
+1. "[Continuous integration vs. continuous delivery vs. continuous deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)", by Sten Pittet
+1. [Accelerate](https://itrevolution.com/book/accelerate/), by N. Forsgren, J. Humble and G. Kim
diff --git a/src/content/slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides b/src/content/slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
new file mode 100644
index 0000000..33fc239
--- /dev/null
+++ b/src/content/slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
@@ -0,0 +1,266 @@
+---
+
+title: 'On "local-first": beyond the CRDT silver bullet'
+
+date: 2020-11-14
+
+layout: slides
+
+lang: en
+
+ref: on-local-first-beyond-the-crdt-silver-bullet
+
+article: _articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md
+
+---
+
+# On local-first
+
+Beyond the CRDT silver bullet
+
+---
+
+# Part 1
+
+Exposition
+
+---
+
+## "cloud apps" vs "old-fashioned apps"
+
+---
+
+## Target
+
+- documents
+- files
+- personal data repositories
+
+Not: banking services, e-commerce, social networking, ride-sharing, *etc*.
+
+---
+
+## 7 Ideals for local-first software
+
+---
+
+### 1 - No Spinners: Your Work at Your Fingertips
+
+---
+
+### 2 - Your Work Is Not Trapped on One Device
+
+---
+
+### 3 - The Network Is Optional
+
+---
+
+### 4 - Seamless Collaboration with Your Colleagues
+
+---
+
+### 5 - The Long Now
+
+---
+
+### 6 - Security and Privacy by Default
+
+---
+
+### 7 - You Retain Ultimate Ownership and Control
+
+---
+
+## Towards a Better Future
+
+CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology
+
+---
+
+### Use case
+
+```
+# in node A and node B
+s = "Hello, World"
+
+# in node A
+s = "Hello, Alice"
+
+# in node B
+s = "Hello, Bob"
+```
+
+How to reconcile those?
+- `Hello, ABloibce`
+- `Hello, AliceBob`
+- `Hello, BobAlice`
+- `Hello, Alice`
+- `Hello, Bob`
+
+---
+
+Existing CRDTs differ:
+- performance
+- storage
+- compression
+- metadata overhead
+
+---
+
+Hint towards the "automerge" CRDT
+
+---
+
+*show comparison table, page 9*
+
+---
+
+# Part 2
+
+Critique
+
+---
+
+### Software license
+
+> In our opinion, maintaining control and ownership of data does not mean that
+> the software must necessarily be open source.
+
+---
+
+#### Example 1 - intentional restriction
+
+```bash
+#!/bin/sh
+
+TODAY=$(date +%s)
+LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)
+
+if [ $TODAY -ge $LICENSE_EXPIRATION ]; then
+  echo 'License expired!'
+  exit 1
+fi
+
+echo $((2 + 2))
+```
+
+```bash
+# today
+$ ./useful-adder.sh
+4
+# tomorrow
+$ ./useful-adder.sh
+License expired!
+```
+
+---
+
+#### Example 2 - unintentional restriction
+
+```bash
+# today
+$ useful-program
+# ...useful output...
+
+# tomorrow, with more data
+$ useful-program
+ERROR: Panic! Stack overflow!
+```
+---
+
+### local-first **requires** free software
+
+Otherwise "The Long Now" (ideal nº5) is lost
+
+---
+
+### Denial of existing solutions
+
+> In principle it is possible to collaborate without a repository service,
+> e.g. by sending patch files by email, but the majority of Git users rely
+> on GitHub.
+
+Solution: either  GitHub+CRDTs or `git` **`send-email`**
+
+---
+
+### Plain text formats
+
+> Git is highly optimized for code and similar line-based text file
+
+It even pulls software to the plain text direction, e.g.:
+- delivery-templates
+- `common-core.protocols.config`
+
+Why not exploit that more?
+
+---
+
+### Ditching of web applications
+
+> The architecture of web apps remains fundamentally server-centric
+
+Disagree. Contrast [PouchDB][pouchdb] with Android [Instant Apps][instant-apps]
+
+[pouchdb]: https://pouchdb.com/
+[instant-apps]: https://developer.android.com/topic/google-play-instant
+
+???
+
+Talk on dynamic content
+
+---
+
+### Costs are underrated
+
+- storage
+- backups
+- maintenance
+
+Example: blog vs vlog
+
+---
+
+### Real-time collaboration a bit overrated
+
+It is only possible on the presence of reliable, medium-quality network
+connection
+
+> X also works when inside an elevator, subway or plane!
+
+<!-- 🤦‍ -->
+
+---
+
+### On CRDTs and developer experience
+
+> For an app developer, how does the use of a CRDT-based data layer compare to
+> existing storage layers like a SQL database, a filesystem, or CoreData? Is a
+> distributed system harder to write software for?
+
+Yes.
+
+See "[A Note on Distributed Computing][note-dist-comp]"
+
+[note-dist-comp]: https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf
+
+---
+
+## Conclusion
+
+Why this is a "paper I love": it took offline-first and ran with it.
+
+But a pinch of CRDT won't make the world local-first.
+
+The tricky part is the end of the sentence: "**in spite of the Cloud**".
+
+---
+
+## Thank you!
+
+References:
+
+1. "[Local-First Software: You Own Your Data, in spite of the Cloud](https://martin.kleppmann.com/papers/local-first.pdf)", by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan
+1. [The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-software/) article
+1. "[A Note on Distributed Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)", by J. Waldo, G. Wyant, A. Wollrath and S Kendall