Jamie Schembri

No, really, ask yourself the question: “who cares if my app is slow?” or, perhaps more accurately, why do they care? What is the purpose of the code you’re writing? Whom does it impact? And where is the author going with this?

Today I came across a post on social media discussing the benefits of offloading heavy data operations to the database for improved performance. The logic seems sound: databases are highly optimized for data storage and retrieval, and many developers have witnessed how a piece of well-crafted SQL can work wonders in a fraction of the time their application code would take. Fast is good; we like fast!

So it follows that we should leverage the database wherever possible to squeeze out all of those performance gains, right? Well, maybe in some cases. However, the problem with this line of thinking is that it assumes performance is the ultimate goal without considering the broader context.

Our coffee machine is currently at the shop for repair, so we’re stuck drinking instant. It’s not fantastic, but it’s really all right in a pinch. In fact, my parents exclusively drink instant because it’s what they’re used to — seems like a pretty common thing in the UK and is probably a war relic or something (I haven’t looked it up).

For the past handful of years I’d been a happy Rails developer. Happy – or, perhaps more aptly, content – because I knew that that I could effectively build pretty much anything I could dream up in Rails. This contrasted with what, in retrospect, was the more rebellious phase of my career, in which I hungered and scoured for newer, fancier tools with more bells and whistles.

Don’t get me wrong; I’d always kept my ear to the ground: I read newsletters, flicked through subreddits, and subscribed to RSS feeds. I’d see projects go by, maybe throw them a star on GitHub, and file them away in some distant part of my brain for “later”. Many of the projects I’d come across would find a use for me in my day-to-day work, but the more esoteric or not-in-my-ecosystem tools and ideas more often went forgotten.

I thought this was just par for the course in the industry: growing up, if you will, leaves us with less time to waste on distractions.

Having trouble writing an ESXi boot image? Balena Etcher not doing it? No surprise: the image is a collection of voodoo.

Lately I’ve been experimenting with RubyMine. I’ve played around with it in the past, but always ended up back on vim for various reasons. This time I’m making a concerted effort to learn its feature set and make them work for me, and so far I’m thoroughly impressed.

Unfortunately I had some problems setting up Ruby/Rails projects running in Docker containers to work with RubyMine’s debugging features, so I’ve documented how I did it and some of the issues I ran into.