feature flag article: proofreading

2 files changed, 21 insertions, 19 deletions

diff --git a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
index 4cc41e9..8b3b97a 100644
--- a/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
+++ b/_articles/2020-10-14-feature-flags-differences-between-backend-frontent-and-mobile.md
@@ -45,11 +45,11 @@ distilled trade-off analysis:
 It is true that you can make the management of feature flags as
 straightforward as possible, but having no feature flags is simpler than having
 any. What you get in return is the ability to parameterize the behaviour of the
-application in runtime, without doing any code changes.
+application at runtime, without doing any code changes.
 
 Sometimes this added complexity may tilt the balance towards not using a feature
-flag, and sometimes the flexibility of changing behaviour on runtime absolutely
-is worth the added complexity. This can vary a lot by code base, feature, but
+flag, and sometimes the flexibility of changing behaviour at runtime is
+absolutely worth the added complexity. This can vary a lot by code base, feature, but
 fundamentally by environment: its much cheaper to deploy a new version of a
 service than to release a new version of an app.
 
@@ -78,7 +78,7 @@ with similar characteristics: desktop applications, command-line programs,
 On **mobile** you have even less control: app stores need to allow your app to
 be updated, which could bite you when least desired. Theoretically you could
 make you APK available on third party stores like [F-Droid][f-droid], or even
-make the APK itself available for direct download, which you give the same
+make the APK itself available for direct download, which would give you the same
 characteristics of a frontend application, but that happens less often.
 
 On iOS you can't even do that. You have to get Apple's blessing on every single
@@ -92,11 +92,13 @@ having a dynamic flag on the backend may or may not be worth it since you could
 always update the code immediately after, but on iOS it is basically always
 worth it.
 
+[f-droid]: https://f-droid.org/
 [^force]: Technically you could force a reload with JavaScript using
     `window.location.reload()`, but that not only is invasive and impolite, but
     also gives you the illusion that you have control over the client when you
     actually don't: clients with disabled JavaScript would be immune to such
     tactics.
+
 [apple]: http://www.paulgraham.com/apple.html
 
 ## Rollout
@@ -139,9 +141,9 @@ and client version.
 
 On the **backend**, those are useful for things that have a long development
 cycle, or that needs to done by steps. Consider loading the feature flag rules
-in memory when the application starts, so that you avoid querying the database
-or an external service for applying a feature flag rule to avoid intermittent
-network failures.
+in memory when the application starts, so that you avoid querying a database
+or an external service for applying a feature flag rule and avoid flakiness on
+the result due to intermittent network failures.
 
 Since on the **frontend** you don't control when to update the client software,
 you're left with applying the feature flag rule on the server, and exposing the
@@ -150,14 +152,14 @@ itself, and fallback to a "just refresh the page"/"just update to the latest
 version" strategy for less dynamic scenarios.
 
 On **mobile** you can't even rely on a "just update to the latest version"
-strategy, since the code for the app could be updated to a new feature but it
-can't get through the store. Those cases aren't recurrent, but you should always
-assume the store will deny updates on critical moments so you don't find
-yourself with no cards to play. That means the only control you actually have is
-remote via the backend, and parameterize the runtime of the application using
-the API. In practice, you should always have a feature flag to control any relevant
-piece of code. There is no such thing as "too small code change for a feature
-flag". What you should ask yourself is:
+strategy, since the code for the app could be updated to a new feature and be
+blocked on the store. Those cases aren't recurrent, but you should always assume
+the store will deny updates on critical moments so you don't find yourself with
+no cards to play. That means the only control you actually have is via
+the backend, by parameterizing the runtime of the application using the API. In
+practice, you should always have a feature flag to control any relevant piece of
+code. There is no such thing as "too small code change for a feature flag". What
+you should ask yourself is:
 
 > If the code I'm writing breaks and stays broken for around a month, do I care?
 
@@ -169,13 +171,12 @@ filesystem/database changes, *etc*.
 ## Experiment
 
 An experiment is a feature flag where you care about analytical value of the
-flag, and how it might impact user's behaviour. Like a feature flag with
-analytics.
+flag, and how it might impact user's behaviour. A feature flag with analytics.
 
 They are also usually medium-lived, being relevant as long as the new code is
 being developed. The most common rule is A/B test.
 
-On the **backend**, experiment rely on an analytical environment that will
+On the **backend**, an experiment rely on an analytical environment that will
 pick the A/B test groups and distributions, which means those can't be held in
 memory easily. That also means that you'll need a fallback value in case
 fetching the group for a given customer fails.
@@ -185,7 +186,7 @@ On the **frontend** and on **mobile** they are no different from feature flags.
 ## Operational toggle
 
 An operational toggle is like a system-level manual circuit breaker, where you
-turn on/off a feature, or fail over the load to a different server. They are
+turn on/off a feature, fail over the load to a different server, *etc*. They are
 useful switches to have during an incident.
 
 They are usually long-lived, being relevant as long as the code is in
diff --git a/scripts/spelling/en.txt b/scripts/spelling/en.txt
index f7128b1..89af62d 100644
--- a/scripts/spelling/en.txt
+++ b/scripts/spelling/en.txt
@@ -25,6 +25,7 @@ filesystems
 isn
 maintainence
 oday
+parameterizing
 portuguese
 portuguse
 pre