Kartones Blog

Be the change you want to see in this world

Book Review: It's Not How Good You Are. It's How Good You Want To Be


It's Not How Good You Are. It's How Good You Want To Be

Title: It's Not How Good You Are. It's How Good You Want To Be

Author: Paul Arden

Quick read (~120 pages) of provocative advices, mostly oriented to business people. Some of them are good, radical, different, challenging... but some to me feel either stupid or wrongly exposed: Getting fired because you have radical ideas might not be bad, but exalting you've been fired 5 times? Or the wrong wording "not getting good grades at school is ok" (instead of saying something like "school grades are not everything")? Some of the messages give the impression of being a survivorship bias: "this is what took me to success so you don't need anything else" and forget that it takes some time to be in a position where your school grades, or your "raw CV" doesn't matter as much as your past successes and mistakes.

That said, not a bad read, especially the creativity part is great and the general tone of "you can do it" is good as self-help and can open your mind.


I had this book forgotten and decided to read it before gifting it out. I don't even remember why I bought it, but definitely I didn't read it was more oriented to raw business than a generic creativity book.

I also found I have the second part ("Whatever you think, think the opposite") so another review will follow very soon.

Course Review: The Complete Splunk Beginner Course (Udemy)

I sometimes have to use Splunk at work and the truth is that, excepting some basic queries I had no clue how it works, so after a colleague mentioned he was going to go through Udemy's The Complete Splunk Beginner Course I also decided to give it a try.

The results are not bad: It covers all fundamentals and basic pillars like setting it up, querying and visualizing data, so you get to know how it gathers the data, why maybe some field is not being displayed correctly, and other informational bits that can come handy. My main focus was on searching, reporting and visualizing and, while some examples are gone through so quickly I had to watch them twice or pause the video to properly read the search query or terms used, it covers much of the options, from pipelining queries into commands, generating tables or charts, and specific examples of dealing with time series (one of the most common use cases).

The examples are not bad, although I'd have preferred to see a sample of ingesting and parsing an Nginx log than Windows security audit logs, which yes, include some relevant fields but also huge by default useless XML chunks, but on the other side the author provides a "homework dataset" of useful CSV sample data to ingest and play with.

It is a complete course, a bit short (3 hours), but clearly stated with the "beginner" word on the title and covering quite some ground, so a good intro to learn this monitoring tool.

Course Review: Perfect English Pronunciation: British English (Udemy)

I was searching for a course about improving pronunciation, when I found that the Perfect English Pronunciation: British English course has been added to the Udemy for Business catalog, so I took it and recently completed it.

It is exactly what I wanted: around four hours of examples, with minimal pairs or trios of similar sounding words that you should learn how to speak differently and correctly. For once, I'll show a screenshot of one pair so you can judge by yourself:

Perfect English Pronunciation: British English course sample screenshot

The pairs/trios are also grouped by two big categories, vowel sounds and consonant sounds. You get plenty of examples, precise instructions on how to vocalize the sounds (including mouth close-ups), and a few repetitions of each.

Totally recommended.

When to Feature Flag new code

A few days ago a colleague asked me the question of "when I consider that new code/logic should go behind a feature flag". I gave a short answer but truth is that using feature flags, or feature toggles is very common these days and taken for granted you know how to use them, but it is not always explained when to use them.

What follows is my humble opinion and experience, feel free to ignore it.

The single, most important fact that is usually forgotten and perverted is that feature flags are meant to be temporal, they should always be removed once fully rolled out (or replaced by a system switch, more on this later).

When to use Feature Flags

  • New features. It is a fact that online complex systems will always have bugs, so having a flip switch to quickly "rollback" your new feature is a must. Also most non/trivial feature flag systems allow for gradual roll-outs, canary releases, role-based, entity-id based and other conditions.
  • Experimental features. To me, the same scenario as previous point.
  • Breaking changes. Many times should actually be something like a parallel change
  • Code that changes storage data (format or manipulation). Data corruption can be so dangerous that I'd consider it almost like a breaking change scenario.
  • Code that modifies input/output. Except if new I/O parameters/fields/things are optional.
  • Code that raises new potentially unhandled exceptions. Extending your validation logic with new scenarios? Cover with a FF the new validation until all upper layers/callers have been revised and handle the new errors.
  • Complex refactors or rewrites. If you have a really high code coverage might not need it, but we all know what usually happens with code coverage as codebases grow.
  • Untested or poorly tested code. Your change might look tiny, but tiny changes in complex systems can wreak havoc in unfortunate situations.
  • Code changes that might have potential performance hits. From adding a new data manipulation library to modifying an apparently innocuous ORM query, monitoring will alert you of performance degradations but if you can easily switch back to the old version while you ensure everything is fine, the better.
  • Simple A/B testing. As in "one control group and one experiment group".

When NOT to use Feature Flags

  • To disable system components. While the mechanics are the same, those uses are for System Switches, Ops Toggles or whatever you want to call them, but do not mix with feature flags, because it sends the wrong message of a feature flag being long term, when they shouldn't be.
  • For permanent versioned features. Example: If you have versioned API endpoints, the Feature flag should disappear as soon as the new version is stable and you should have routing-based versioning (or user-based or any other solution except a feature flag).
  • Complex A/B testing. There are better solutions than feature flag systems for A/B testing so use one instead.

Miscellaneous closing tips

Feature Flags are to be used by developers and product, while System Switches are for Systems, DevOps, SREs and the like.

When coding the feature flag check and forking logic, there are two accepted paths: The first one allows to just delete the lines in the future without any further changes:

if not feature_flags.enabled(feature_flags.constants.NEW_SHINY_FEATURE):
    # old path  (don't forget to return to avoid executing also new logic!)

# new logic

And the more commonly found, which just needs code re-indentation when removing the flag:

if feature_flags.enabled(feature_flags.constants.NEW_SHINY_FEATURE):
    # new logic
    # old logic

If you want to know more about what are Feature Flags, this article is quite detailed.

Micro-Frontends (and self-contained systems)

The topic of the past weeks has been Micro-Frontends, due to this ThoughtWorks article about them (if you haven't read it, stop, go read it, then come back and continue). It has caused some discussions, mostly because there seems to be a trend now towards going mono-repo with Javascript, uniting all the things to build an easier path to update dependencies for all your FE pieces.

I know very little about current frontend development, tooling and best practices, so I'm not going to judge how good or bad is a mono-repo approach on itself. I just question how fast can it be, both from experience and personal intuition, because it means that yes, you update React once and every single Javascript piece of your system is updated, but at the same time we all know that updates are often harder and full of unforseen problems, so it could become a bottleneck as it is a somewhat all-or-nothing action.

Anyway, what I really wanted was to add to that really interesting article some related links around the topic, as in the past at TheMotion our idea was to move towards Self-Contained Systems, and at Ticketea the new checkout frontend was a "by the book" example of a micro-frontend (including iframe-based injection on the main website).

If you're interested, check the following resources:

Previous entries