diff options
Diffstat (limited to 'src/content/en/slide/2020')
| -rw-r--r-- | src/content/en/slide/2020/10/19/feature-flags.adoc | 234 | ||||
| -rw-r--r-- | src/content/en/slide/2020/10/19/feature-flags.eslaides | 235 | ||||
| -rw-r--r-- | src/content/en/slide/2020/11/14/local-first-hype.adoc | 208 | ||||
| -rw-r--r-- | src/content/en/slide/2020/11/14/local-first-hype.eslaides | 232 |
4 files changed, 481 insertions, 428 deletions
diff --git a/src/content/en/slide/2020/10/19/feature-flags.adoc b/src/content/en/slide/2020/10/19/feature-flags.adoc index 553cf4c..1035903 100644 --- a/src/content/en/slide/2020/10/19/feature-flags.adoc +++ b/src/content/en/slide/2020/10/19/feature-flags.adoc @@ -1,230 +1,10 @@ ---- -# Rollout, feature flag, experiment, operational toggle += Rollout, feature flag, experiment, operational toggle +:deck: feature-flags.pdf +:article: link:../../../../blog/2020/10/19/feature-flags.html -@Different use cases for backend, frontend and mobile +Different use cases for backend, frontend and mobile. ---- -. -. -. -# "Feature flags" tend to come up when talking about continuous deployment +link:{deck}[See the PDF]. ---- -. -. -. -. -@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 +_The prose version of this presentation is the article +{article}[Feature flags: differences between backend, frontend and mobile]._ diff --git a/src/content/en/slide/2020/10/19/feature-flags.eslaides b/src/content/en/slide/2020/10/19/feature-flags.eslaides new file mode 100644 index 0000000..3392e3e --- /dev/null +++ b/src/content/en/slide/2020/10/19/feature-flags.eslaides @@ -0,0 +1,235 @@ += 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 + +<<< + +[.lead] +CI: continuous integration +[.lead] +CD: continuous delivery +[.lead] +CD: continuous deployment + +<<< + +== Types +. rollout +. feature flag +. experiment +. 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 + +<<< + +[.lead] +We know know about the types +== But they have different relevance for backend, frontend and mobile + +<<< + +== backend +. rollout: k8s blue/green, canary and [.line-through]#common-rollout# common-xp +. feature flag: [.line-through]#common-rollout# common-xp and datasets +. experiment: common-xp +. operational toggle: [.line-through]#common-rollout# common-xp + +<<< + +== frontend +. rollout: CDN and page refreshes +. feature flag: percentages and maybe IPs (no :customer/id on the website) +. experiment: via dynamic backend control +. operational toggle: via dynamic backend control + +<<< + +== backend +. rollout: app stores +. feature flag: via dynamic backend control +. experiment: via dynamic backend control +. operational toggle: via dynamic backend control + +<<< + +[.lead] +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 [.line-through]#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 +. "Feature Toggles (aka Feature Flags)", by Pete Hodgson +. "Continuous integration vs. delivery vs. deployment", by Sten Pittet +. Accelerate, by N. Forsgren, J. Humble and G. Kim +. these slides: euandre.org/slide/ +. prose version of this presentation +. 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 index fd83115..2aeaf3f 100644 --- a/src/content/en/slide/2020/11/14/local-first-hype.adoc +++ b/src/content/en/slide/2020/11/14/local-first-hype.adoc @@ -1,204 +1,10 @@ -# On "local-first" += On local-first +:deck: local-first-hype.pdf +:article: link:../../../../blog/2020/11/14/local-first-review.html -@Beyond the CRDT silver bullet +Beyond the CRDT silver bullet. ---- -## Part 1 -# Exposition +link:{deck}[See the PDF]. ---- -## 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 +_The prose version of this presentation is the article +{article}[Local-First Software: article review]._ diff --git a/src/content/en/slide/2020/11/14/local-first-hype.eslaides b/src/content/en/slide/2020/11/14/local-first-hype.eslaides new file mode 100644 index 0000000..8f44ad2 --- /dev/null +++ b/src/content/en/slide/2020/11/14/local-first-hype.eslaides @@ -0,0 +1,232 @@ += 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 +.... +[.lead] +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 + +<<< + +...... +[.lead] +@show comparison table, page 9 + +<<< + +== Part 2 +=== Critique + +<<< + +== Software license +... +[.lead] +@"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 +.. +[.lead] +@"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 +[.lead] +@"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 +.. +[.lead] +@"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 +.. +[.lead] +@"X also works when inside an elevator, subway or plane!" + +<<< + +== On CRDTs and developer experience +[.lead] +@"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? +[.lead] +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 +. "Local-First Software: You Own Your Data, in spite of the Cloud", by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan +. The Morning Paper article +. "A Note on Distributed Compiting", by J. Waldo, G. Wyant, A. Wollrath and S. Kendall +. these slides: euandre.org/slide/ +. prose version of this presentation +. view source |