v0 migration to mkwbHEADmain

2 files changed, 0 insertions, 609 deletions

diff --git a/_slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides b/_slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides
deleted file mode 100644
index 22770e6..0000000
--- a/_slides/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides
+++ /dev/null
@@ -1,343 +0,0 @@
----
-
-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/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides b/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
deleted file mode 100644
index 33fc239..0000000
--- a/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
+++ /dev/null
@@ -1,266 +0,0 @@
----
-
-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