Tag: Invent And Simplify

My Kingdom For A Streak

My Kingdom For A Streak

By | | Comments 1 comment

Because I’m a LeBron fan, when it comes to Wordle, I care more about longevity of sustained greatness (i.e. my perfect streak of winning games) than I do about having epic individual performances (i.e. having a lot games where I’ve won in 2 or 3 guesses). That means I need a way to keep my statistics even if I move between devices or need to replace one.

Almost to quadruple 100!

It turns out (at least as of this writing, who knows if the NYT will change it) that statistics are stored in a simple JSON object in browser local storage. On a laptop this storage is easily manipulated using DevTools, and on mobile it’s a bit tougher but still not too bad, at least on Android.

Both of the above, however, rely on GUIs. It got me thinking if there was a scriptable approach. First, I found a Python library (natch) that can speak the Chrome DevTools protocol. Then I had to figure out how to use it to read and write to local storage. That wasn’t too hard (even though the example here is in Node, the technique was portable). Finally I needed to make the library connect to both a laptop-based browser (easy), and my Android phone via adb (not so easy). Luckily I stumbled on the correct magical incantation in this post. Put it all together, and boom, I can now backup my Wordle streak, and easily transfer it between devices, using a script:

import chrome_local_storage

laptop_storage = chrome_local_storage.ChromeLocalStorage(port=9222)
phone_storage = chrome_local_storage.ChromeLocalStorage(port=9223)

wordle_stats = laptop_storage.get('games/wordle', 'nyt-wordle-statistics')
phone_storage.set('games/wordle', 'nyt-wordle-statistics', wordle_stats)

Want to see how I did it? Well, you’re in luck, because I packaged up my implementation and published it on PyPI. The source code is also on Github. Enjoy!

Put A Bow On It

Put A Bow On It

By | | Comments 0 Comment

Despite writing a bit about CDK nearly two years ago, it’s taken me some time to get a chance to really lean into it. Having now built out a couple real projects, I can confidently say that like it has its rough edges, like any technology, but overall it’s both powerful and fun.

If you’re so inclined, feel free to check out my most recent creation, a construct for deploying a Hyperledger Fabric network on Amazon Managed Blockchain. 

# Easy as pie!
HyperledgerFabricNetwork(
    self, 'MyNetwork',
    network_name='MyNetwork',
    member_name='MyMember',
)

For my next trick post I’ll go through one of the aforementioned rough edges I discovered, and how it can hopefully be fixed.

A Number Of Numbers

A Number Of Numbers

By | | Comments 0 Comment

Back in my math major days in college, I was introduced to the Online Journal of Integer Sequences. It’s exactly what it says on the tin. As part of a class we were encouraged to contribute, which I did.

A few weeks ago I had another idea for a submission, and to my surprise no one else had added it, so once again I had opportunity to contribute a little piece of Internet history.

Here’s a complete list of the sequences I’ve authored over the years:

If the above isn’t enough online notoriety, check out my only published mathematical work, A Probabilistic View of Certain Weighted Fibonacci Sums. I was only a mild contributor, but still got an authorial credit, which is pretty cool.

Putting Pen To Paper

Putting Pen To Paper

By | | Comments 0 Comment

I spent some time today chatting with an early career colleague who’s looking towards a future career in the dark arts software development. Being the kind of person that enjoys the sound of my own voice, I enjoy these opportunities to pontificate. One piece of advice I routinely give is that good engineers write well, and developing this skill will pay itself back with copious dividends.

However, that shouldn’t be read to mean that quantity trumps quality. Far from it, keeping things brief is usually more difficult than not (I know I’m bad at rambling, kinda like I am now). Which is why I found this little article on the value of the humble readme such valuable advice.

The other day I published a blockchain solution on Github, and while I’m pretty proud of the code, the readme is in bad shape (as of today at least). For my next project (a refactoring of the core of this solution into a reusable CDK construct) I think I’m going to write the readme first, as the above article suggests. We’ll see how it goes!

Hodgepodge Advice

Hodgepodge Advice

By | | Comments 0 Comment

I’m a sucker for lists that contain pithy nuggets of truth. Here’s two great ones I found this week:

Some of my favorite statements, in no particular order:

If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

Every system eventually sucks, get over it

Software engineers should write regularly

Always strive to build a smaller system

KISS, don’t be afraid, and boring > cool

The bottleneck is almost always the database

Doomed To Repeat It

Doomed To Repeat It

By | | Comments 0 Comment

Technologists are particularly susceptible to recency bias. It’s one reason why I try to read older computer science literature from time to time (especially work from the 60s and 70s). The Mythical Man-Month is my canonical example; it should be required reading for everyone who works with technology. The Psychology of Computer Programming contains timeless truths of what it takes to lead a team of software engineers. Donald Knuth’s The Art of Computer Programming is a dense, three volume work, but much treasure lies within. I’ve only finished the first book, but I came away with tremendous respect for the geniuses that paved the way for us fortunate souls who have IDEs, fast compilers, and gigabytes of RAM.

Today I read On the Criteria To Be Used in Decomposing Systems into Modules, a research paper by D.L. Parnas of Carnegie-Mellon University, published in 1972. While the details of the middle section weren’t terribly interesting, it’s the bookends of introduction and conclusion that impressed me. The benefits of two-pizza teams were clearly understood fifty years ago, for example (“separate groups would work on each module with little need for communication”) and the paper lays out a novel approach to decomposition (to me, at least):

“We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”

The above resonates with prior posts I’ve written on abstractions, especially Out of Sight, Out of Mind. If the goal of abstraction is to hide difficult detail, we ought to modularize with that goal front-and-center.

There’s Gold In Them Thar Hills

There’s Gold In Them Thar Hills

By | | Comments 0 Comment

In my conversations with fellow engineers, git comes up quite a bit. I find myself regularly giving advice both tactical and strategic on its effective use. Learning it in detail is a force multiplier, but few people do. Part of the problem is that training materials are all over the map.

Which is why I was so pleased to discover Git from the inside out. Without question the best introduction to git I’ve come across. It perfectly balances teaching basic commands while also explaining what’s actually happening. Despite having used git at a fairly advanced level for 10 years, I still learned some new things, for example that each git add creates an immutable blob object that is retained for a while even if you git add the same file again, and even if you never commit it. Also that it’s pretty easy to decode raw git objects should you ever need to; here’s a script I wrote to do just that, if you’re curious.

I’ve said before that abstractions are valuable, but they’re not excuses to avoid learning internals, because critical information lies beneath the surface. At the risk of pretentiously quoting myself:

When things go wrong, the engineer must descend into the particulars, and an inability to minimally reason about, if not fully grasp, what lies beneath an abstraction can prove fatal to the debugging process.

I didn’t write the above with version control in mind, but I surely could have. Engineering organizations are full of developers who run stuck the moment a git command fails. You don’t have to be that developer!

Turduckens Everywhere

Turduckens Everywhere

By | | Comments 0 Comment

Did you know you can implement a CPU in Minecraft or write arbitrary computer programs using Magic: the Gathering cards? Computing is powerfully weird, and hidden structures and capabilities can arise from all sorts of odd places.

I read a theory a while back that the Internet was, in some meaningful sense, intelligently conscious, though we may never be able to interact with such an intelligence. The analogy was to human consciousness arising from the cells of the brain in a way that no individual cell could ever comprehend it, but despite that it being no less real. The notion of Turing-complete computers being buried inside all manner of languages and tools has a similar vibe to it.

Can’t Unsee It

Can’t Unsee It

By | | Comments 0 Comment

On the plus side, she writes her people-searching algorithms in Python. But c’mon Wonder Woman, you need to work on your variable naming!

I’m pretty sure this function could be further simplified with some basic mathematics; it’s far too long and complicated. Reminds me of the film I captured it from.