From bcb6c83538b3a90d1d8f74e291a11219654f6e4a Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Wed, 30 Apr 2025 11:06:27 -0300 Subject: src/content/en/slide/: Move existing slide files to appropriate location --- ...ature-flag-experiment-operational-toggle.slides | 343 --------------------- ...ocal-first-beyond-the-crdt-silver-bullet.slides | 266 ---------------- src/content/en/slide/2020/10/19/feature-flags.adoc | 329 ++++++++++++++++++++ .../en/slide/2020/11/14/local-first-hype.adoc | 252 +++++++++++++++ 4 files changed, 581 insertions(+), 609 deletions(-) delete mode 100644 src/content/en/slide/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides delete mode 100644 src/content/en/slide/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides create mode 100644 src/content/en/slide/2020/10/19/feature-flags.adoc create mode 100644 src/content/en/slide/2020/11/14/local-first-hype.adoc diff --git a/src/content/en/slide/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides b/src/content/en/slide/2020-10-19-rollout-feature-flag-experiment-operational-toggle.slides deleted file mode 100644 index 22770e6..0000000 --- a/src/content/en/slide/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/src/content/en/slide/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides b/src/content/en/slide/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides deleted file mode 100644 index 8f17982..0000000 --- a/src/content/en/slide/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 diff --git a/src/content/en/slide/2020/10/19/feature-flags.adoc b/src/content/en/slide/2020/10/19/feature-flags.adoc new file mode 100644 index 0000000..3a97621 --- /dev/null +++ b/src/content/en/slide/2020/10/19/feature-flags.adoc @@ -0,0 +1,329 @@ += Rollout, feature flag, experiment, operational toggle + +# 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/en/slide/2020/11/14/local-first-hype.adoc b/src/content/en/slide/2020/11/14/local-first-hype.adoc new file mode 100644 index 0000000..bb27074 --- /dev/null +++ b/src/content/en/slide/2020/11/14/local-first-hype.adoc @@ -0,0 +1,252 @@ += On "local-first": beyond the CRDT silver bullet + +# 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 -- cgit v1.2.3