An old-school blog where I write with uneven frequency on whatever seems interesting or important to me at any given time. Typically these subjects tend to center around:
Welp, the final draft of my book, Mastering Software Architecture has been turned into the publisher. It is the culmination of nearly two years of active writing (~800 hours), countless hours of research, 156 citations, and 25+ years in industry.
Rather than write yet-another distillation of the current state of practice, I have tried to dramatically improve it. The model introduced in this work unifies our fragmented models in a way that solves real problems once thought by many to be intractable.
Microservices architecture has become a buzzword in the tech industry, promising unparalleled agility, scalability, and resilience. Yet, according to Gartner, more than 90% of organizations attempting to adopt microservices will fail. How can you ensure you’re part of the successful 10%?
I haven’t posted much this year as I have spent the majority of my writing time working on my upcoming book, Mastering Software Architecture. I want to share an excerpt in the form of the preface to the book which describes its goals and approach. If this resonates, you can pre-order using the link above or sign-up here for updates and more.
We can’t always control what happens to us, but we get to choose how we respond.
Last night I was flying home from a show and my flight was MASSIVELY delayed (and eventually cancelled). It was frustrating. I had been on the road 12 days out of the last 15, I missed my wife, and I desperately wanted to sleep in my own bed.
I could have vented my anger at a gate-agent who has no more control over the situation than I did. I could have wandered to a bar to drown my sorrows… But instead, I decided to stage an impromptu show for my fellow stranded passengers.
I’m currently in Budapest, HU speaking at and attending a conference. Although the attendees are smart and passionate, the speakers have many valuable things to say, I see the continuation of an alarming trend in the tech industry: The sessions that promise simple answers are wildly popular while the sessions that offer insights on how to improve our thinking and mental models are are relatively sparsely attended. This culture of “don’t make me think, just give me the answers” is crippling our industry.
If you’re reading this there is a better than average chance that you either are an innovator or will be soon. People who regularly attend conferences, read widely, and follow obscure and longwinded blogs tend to skew venturesome; active information-seekers with diverse social groups and information sources, possess breadth of knowledge, are more willing to explore and adopt new ideas, and are able to cope with higher levels of uncertainty. If you are an innovator then, according to current research, you are part of a vanishingly small demographic that makes up just 2.5% of the total population. The unique cognitive and social diversity of this group offers perspective and insight into ideas, opportunities, possibilities, and solutions ahead of the mainstream.
Perhaps you see the solution to a problem right now. Congratulations, you have an idea–an innovation–that just might make a material difference in the lives of a lot of people. How do you get the other 97.5% of the population to adopt your solution? Will your innovation take off by itself on the merits of its benefits? Unlikely. If the best ideas always won, I wouldn’t be writing this. Even when the idea or innovation has clear and obvious advantages, skeptics must be won over. Old, entrenched habits must be abandoned. Innovations must be evaluated, explored and increasingly accepted until they reach critical mass (only then will they take off). This process can take years or may never succeed at all. Your efficacy as an innovator depends on your ability to optimize and streamline this process, influence your peers, and ultimately effect change in the real world. There is an art–and a science–to the diffusion of innovations.
In part I we explored the history and goals of DevOps and the Agile movement and the motivations for maturing your DBOps practice. In other words, part I addresses “mindset.” Let’s now look at this in practice and get into the “how” of DbOps, addressing the remaining “skillset” and “toolset” topics. Most crucially this involves not only understanding the tools you’ll be working with but also understanding the database. Poorly planned database changes have the potential to cause extended unwanted downtime and, if they break compatibility with the previous version of your app, can complicate rollbacks. Knowledge of RDBMS internals is crucial to moving “offline-breaking” database changes (database changes that require downtime and break compatability with previous versions of code) to “online-compatible” changes (database changes that do not introduce downtime and can be remain backward/forward compatible with code changes).
Everyone seems to want agility, and the DevOps movement has provided tools and practices to enable this. While the tools available today are wonderful, there remain unique challenges when it comes to delivering code changes that also include database changes.
I’ve been building database pipelines on-and-off for over 20 years now. The tools have may have changed but the core principles have not. It would be trivial to write a talk, essay or blog post that was just a tour of syntax and an entertaining summarization of the documentation. You don’t need me to read the docs only to regurgitate them for you into prose or PowerPoint. Instead, I’m going to take a holistic approach that encompasses mindset, skillset, and toolset. What I hope will make this work stand apart from similar content out there is I will be writing from the perspective of a (recovering) DBA and share vital insights that are more relevant than ever.
This post picks up from part I which broadly tells the story of where we are currently and how we got here; ultimately introducing HTMX as the “third way.” It serves as the background and context for this post. If you haven’t already read it, go ahead… I’ll wait.
Now that the background is out of the way, let’s look in depth at HTMX. Rather than the usual quickstart or toy examples, we’ll be looking at this in the context of a real production application already in the wild. We’ll modernize a legacy MVC application, examining the UX without and then with HTMX.
