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.
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.
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:
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.
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).
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 else: # old logic
If you want to know more about what are Feature Flags, this article is quite detailed.
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: