I spent some time playing with Hotwire (for HTML Over The Wire) framework, mostly because it promised building a web application with minimal Javascript. As someone who’s largely a back-end developer and general Javascript non-enthusiast, that fact right there made Hotwire very appealing. Hotwire has absolutely delivered on its minimal Javascrip promise – in fact, I think it’s going to be my first choice for front-end development.
It’s really popular to say we’re writing web services, built on top of RESTful APIs, but the reality is what most of us are really doing is writing web applications that make REST calls back to that app’s server for data, not actually calling a generalized web service with multiple sets of users. That’s fine – I use web applications almost all day just like everyone else. Occasionally we need to actually get some data from another team’s data store, and it’s cool, they have an endpoint you can hit and get it. See? Web services with RESTful APIs. The problem is there’s a difference between, “There’s an endpoint that can give us that data” and running a service who’s purpose is to be used by anyone other than the team that wrote it. Continue reading »
We all screw up, it’s part of life. What’s important that we learn from it all. I’ve found it’s generally better to document the learning, both to help internalize it, and to share it with who I can. I recently worked an issue stemming from automated API call retries that didn’t go nearly as well as it probably should have, and I wanted to take a little time to post-mortem on how everything went, and how it could have gone better. A lot of this is fairly specific to what I was doing with that particular problem, but there’s hopefully some general lessons that can be drawn from the whole ordeal.
We’re all used to dealing with different environments in our code. On the surface, this just means that we need to make sure our code runs fine in all of our environments. But what about the other services that your code is consuming? If your reaction is that it’s the responsibility of the team writing and running that code to make sure that it’s up and running, you’re living in a fantasy. At some point, you have to write (and maintain) your side of the connection to those services, and if something goes wrong, you have to be able to show the issue isn’t on your end. Oh, this is assuming an exact 1-1 match between your environment and their environment (for example, your dev to their dev, your QA to their QA). Even if the external environment doesn’t use the same naming conventions as you, having each of your environments connect to 1 (and only 1) environment of an external service simplifies things exponentially. If people are asking that you update your code to point to other environments of your dependencies, your life gets complicated fast.
Not too long ago, my friend Warren tweeted a link to Atkin’s Laws of Spacecraft Design. That in turn got me thinking about Peter’s Laws: The Creed For The Sociopathic Obssessive Compulsive (which I had in poster form for the better part of a decade), and that inspired me to think of truisms I’ve learned about software development over the years. I may not have enough to fill a full 20+ (or even 40+) item list, but maybe I’ll update and add to it over the years. So without further ado, I present to you, Hydrick’s Laws For Software Development.
During some recent performance testing at work, we noticed an endpoint showing slower than usual response times. Digging into the calls, we found that on slow responses, virtually all the time was spent on waiting for a specific lambda function to return data. Digging into that function we found several calls that appeared to be timing out, and many others that were taking 9-10 seconds. This lead to a day or 2 spent reading up on the workings of AWS lambdas and how they work with Java. What was probably most striking is that while the solution to our problem was eventually findable with some Googling – and the “fix” involved practices that are mentioned in the official AWS documentation – they’re almost mentioned in passing, and don’t call out the performance impacts they have on your billed runtime.
Anyone remember back when companies would try to be “cool” by advertising that they were looking for a “ninja” or “rock-start” software engineer? Thankfully, those days really are just memories (hopefully the days of the “10X egnineer” will go extinct soon, too). These terms were stupid as job titles because they had no bearing on what you actually did for a living. A “rock star” means that you spent some amount of time being playing in the Silver Bullet Band. And if people know that you’re a ninja, then you were really bad at it. I suppose these job titles stemmed from words people used to describe some the better developers where they worked, but there’s a difference between internal compliments and an actual role at a company. That said, the most useful role within any company is probably the programming equivalent of a plumber.
Few things are as annoying as when you have a device that tries to be helpful and is completely, and utterly, wrong. Not only are you not gaining any convenience, because you still have to go back and fix it, but psychologically it feels worse because instead of making things better and doing things automatically for you, you’re having to go back and do it yourself anyways. If these were settings users can easily change, then it’s a minor inconvenience because we can update a configuration and be done with it. Sadly, that’s not the case, especially with devices that are supposed to be “smart” and thus figure it our without us having to do anything, or software that doesn’t expose these settings to users.
1 of the most iconic components to running software in production are consoles full of graphs and metrics about how that software’s performing. Generally, they’re called “dashboards,” but in my experience you want something that provides the ability to act on the data being shown on the console as opposed to a dashboard which is generally read-only. That action could take the form of filtering or drilling down on the data being shown, or triggering some administrative task. Like with everything else in life, 1 size, or in this case 1 administrative console, doesn’t fit all. If you group the different types of users who have a need for an administrative console, you’ll find they fall into 3 general personas.
For some reason, I’ve been seeing a lot of people piping in and saying and/or predicting that monolithic software architecture is going to be making a comeback starting this year. It probably doesn’t help that once I started reading the first article about companies moving from services to monoliths, Google kept highlighting more, but I think the impetus of this was Kelsey Hightower’s unpopular opinion segment arguing that most companies that switch to service-oriented architectures end up creating “distributed monoliths” that are the worst of both worlds. By the way, you’ve likely noted that I’m just using the term “service-oriented architecture” (OK, “SOAs”, because I’m lazy) for both service-oriented architectures and microservices – that’s just to make my life easier – as far as I’m concerned a microservice is just an SOA service with a very small scope.
Continue reading »