This post was first sent to my newsletter on August 20th, 2021.
You really ought to subscribe :)
Welcome to August’s work letter :)
As usual, click the headings to wander off to the original articles
A couple of my own posts
I wrote about my thoughts on my Kindle Oasis …
I got it.
I used it.
And decided within a day, that I was not going back to a Paperwhite, ever.
I realised that the Oasis, to me, is not a “premium” device.
This is what was totally new about the ARPANET. The ICCC demonstration didn’t just involve a human communicating with a distant computer. It wasn’t just a demonstration of remote I/O. It was a demonstration of software remotely communicating with other software, something nobody had seen before.
So what I’m trying to drive home here is that there is an important distinction between statement A, “the ARPANET connected people in different locations via computers for the first time,” and statement B, “the ARPANET connected computer systems to each other for the first time.” That might seem like splitting hairs, but statement A elides some illuminating history in a way that statement B does not.
In a section with the belabored title, “Technical Aspects of the Effort Which Were Successful and Aspects of the Effort Which Did Not Materialize as Originally Envisaged,” the authors wrote:
Possibly the most difficult task undertaken in the development of the ARPANET was the attempt—which proved successful—to make a number of independent host computer systems of varying manufacture, and varying operating systems within a single manufactured type, communicate with each other despite their diverse characteristics.
There you have it from no less a source than the federal government of the United States.
Long, random passwords just aren’t convenient. If you need to enter 45 randomly-generated characters on another device often enough, you’ll inevitably change that password to something like password123 because it’s easy to type and remember. It’s also - you got it - not strong.
While a lengthy, unintelligible password may appear stronger than a smart one, it’s mainly illusion. Pronounceable syllables make a smart password look human generated and, therefore, weaker. But a human-generated password could never be chosen uniformly and, therefore, can’t be accurately assessed for entropy.
We’ve made a compromise of sorts. We’ve sacrificed a few bits of (theoretical) entropy, that don’t affect real-world security, to gain a whole lot of convenience, compatibility, and accessibility — and those certainly are real world, which is what really matters.
We realized that CI is more sensitive than most users for most of the site. So we focused in on testing the highest impact code. What’s high-impact? 1) the code that fails most visibly and 2) the code that’s hardest to retry. You can build an inventory of high-impact code in under a week by looking at traffic stats, batch job schedules, and asking your support staff.
And it really is important to develop close ties with your support team. Embedded in our strategy above was that CI is much more sensitive than a real user. While perfection is tempting, it’s not unrealistic to ask a bit of patience from an enterprise user, provided your support team is prepared. Sync with them weekly so surprise is minimized. If they’re feeling ambitious, you can teach them some Sentry basics, too.
My main lessons from Mahmoud’s post …
- Everyone has a plan ’till they get punched in the mouth. — Mike Tyson
- Prioritise work, on what actually matters. Perfection can wait.
- People and their feedback comes first. Matters a lot more than data driven decisions. After all, software is used by and for people.
Until the next letter, folks … :)