diff options
Diffstat (limited to 'src/content/en/slide')
4 files changed, 434 insertions, 609 deletions
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..553cf4c --- /dev/null +++ b/src/content/en/slide/2020/10/19/feature-flags.adoc @@ -0,0 +1,230 @@ +--- +# 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 + +--- +. +. +. +. +@CI: continuous integration +. +@CD: continuous delivery +. +@CD: continuous deployment + +--- +## Types +. +. +. +1. rollout +2. feature flag +3. experiment +4. operational toggle + +% {favicon.svg} +--- +## Rollout + +# For *rolling out* a new version of software + +Short-lived using percentages + +% FIXME: links +- a new deployment of kubernetes +- new APK released to the Play Store + +--- +## 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 + +--- +## Experiment + +# For analysing 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 + +--- +. +. +@We know 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 + +--- +## 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 + +--- +## backend +. +. +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 +% FIXME: emoji +% 🎉 + +--- +## frontend +# partial control +We choose when to make a new version available + +--- +## 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 the cost +- mobile: *always* worth the 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 + + {:rules + #{{:types :include-list + :content {:filename "debit-team-members.txt"}}}} + +--- +# Always use :app-version +Only for mobile + + {:rules + #{{:types :app-version + :content {:min-version #{{:platform :android + :code 1000000} + {:platform :ios + :code 2000000}}}}}} + +--- +# 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 + +--- +# Don't delete app-facing feature flags +True for mobile + +--- +. +. +. +# 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 hotfix, avoid expedited releases at all costs + +--- +## References +. +% FIXME: links +1. "Feature Toggles (aka Feature Flags)", by Pete Hodgson +2. "Continuous integration vs. delivery vs. deployment", by Sten Pittet +3. Accelerate, by N. Forsgren, J. Humble and G. Kim +4. these slides: euandre.org/slide/ +5. prose version of this presentation +6. view source 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..fd83115 --- /dev/null +++ b/src/content/en/slide/2020/11/14/local-first-hype.adoc @@ -0,0 +1,204 @@ +# On "local-first" + +@Beyond the CRDT silver bullet + +--- +## Part 1 +# Exposition + +--- +## 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 +\... + +--- +# 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 +. + #!/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)) +. + # today + $ ./useful-adder.sh + 4 + + # tomorrow + $ ./useful-adder.sh + License expired! +--- +## Example 2 - unintentional restriction +. + # 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 directtion, 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 +. +% FIXME: links +Disagree. Contrast PouchDB with Android Instant Apps + +--- +## 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. +. +% FIXME: link +See "A Note on Distributed Computing" + +--- +## 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". + +--- +## References +. +% FIXME: links +1. "Local-First Software: You Own Your Data, in spite of the Cloud", by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan +2. The Morning Paper article +3. "A Note on Distributed Compiting", by J. Waldo, G. Wyant, A. Wollrath and S. Kendall +4. these slides: euandre.org/slide/ +5. prose version of this presentation +6. view source |