I came across an article titled “Devs don’t want to do ops” that started with the premise that developers managing their own production infrastructure is stressful (it is), questioned whether development and operations should be separated again, and settled on declaring “DevOps is dead,” and that platform engineering is the future. It was quite a ride. It also raised some good questions about DevOps, and the ideal approach to building and running code. Is DevOps really dead? Is platform engineering really the future? What does it mean to “own your own code in production?”
If you see any sort of headlines about CEOs and remote work, then you likely heard that Malcolm Gladwell does not like remote work. I had some thoughts on why I think his position (and others like it) is stupid. My position is hardly uncommon – most of the arguments for returning to the office revolve around saying either a) people can’t collaborate unless they’re in the same room (the fact that team-based jobs kept up just fine since Covid happened thoroughly disproved that), b) we need it for the “culture” (“culture” has nothing to do with physical proximity, and isn’t as valued as some people think it is – although looking at that meme makes me miss the days when we at least got cubicles), or c) people aren’t productive working from home (they weren’t productive in the office either, you just thought they were because you saw them sitting at a desk). In my tweet thread, I brought up a personal hypothesis that you can group most people into 1 of 2 groups, “true believers” and “mercenaries,” that I thought warranted more details than you can get on Twitter.
I’ve been thinking a decent bit about architecting services lately, and kept finding myself going to the topic of how useful it would be to make “general infrastructure” services (like an offline job processor, or gateway for capturing client events from your web application) shared resources versus making teams deploy and manage their own instances of those services in the broader context of their own work. Re-using existing services has a lot of appeal, but it’s really something that needs specific conditions to succeed. That said, advances in cloud provider functionality would have made implementing a lot of services easier, and my general approach to building applications has changed as a result. Continue reading »
I wrote recently about how what most of us build as back-ends aren’t really APIs, but just a back-end that provides data to your Javascript. I’ve emphasized the fact that a basic RESTful back-end is not, in fact, an API, and that there are differences between how you build and run the 2. However, there are also very important similarities to REST back-ends and APIs that you need to remember.
I’ve been sitting down and spending some more time with the Hotwire framework after building an initial proof-of-concept and moving towards a simple 0.1 version of something. I still really like the framework, mostly because it simplifies a lot of development, without feeling like I’m sacrificing anything. Not only am I not doing as much work in the front-end, but the advantage of server-side rendering means there’s little to no state to manage in the front-end, which seems to be a huge part of front-end development. Moving from the “standard” way of writing a static webpage and populating it based on JSON data to rendering the page on the server-side is a change in how back-end development gets approached, but really it’s not as much as you may think. I stand by my comments in my original post – Hotwire is my first choice for a front-end framework.
So a (semi-) local coding boot camp is going to be trying something that I really hope works out – partnering with a local company to sponsor and ultimately hire the graduates. I love this idea because of the way it shifts the financial risks in training people for future careers, the direct contrast it puts colleges in, and the fact that a set up like this is inherently designed to make the “graduating class” more successful, and not just because a higher percentage of them got their first job quickly.
Something broke with our approach to disagreements. We went from simply arguing with people who were wrong on the Internet to to demands that people be deplatformed because they’re wrong, according to people who seem to be right equally rarely. Thanks to the aggregation of content onto a few major platforms, a few people have the arbitrary ability to make other people vanish from public discourse. At this point, it’s impossible to tell who’s right, who’s wrong, and who’s been disappeared for having views deemed “unacceptable” by people who have no business making that determination. It’s starting to seem like the reason you can’t trust just anything you see online has moved from “anybody can post anything on the Internet” to “because publishing anything too contrarian will get you kicked off.” That’s not good.
I was working on hotfix that turned hotter than I wanted during the deployment, all because we missed an important test case that left us scrambling to resolve an issue during the deployment that we should have caught earlier. We got lucky and fixed it during the deployment, but we shouldn’t have been in that position because the scenario that failed was a known requirement, which means we should have tested it. So what happened? Well, point blank, we forgot a test case.
So I was working through an issue where I’m having to put together a multi-table query that gets run as part of a scheduled job, and as I’m taking a break after finding the XML file and getting this query (and resulting data mapping) added to said XML file, I come across this tweet, and it described exactly what I was feeling. Why was I shoving queries into an XML file shunted away in my resources
directory instead of just building it in the code? Surely there are better ways to construct SQL queries, right? Well, maybe, but in the end, what I was doing was probably better than I thought it was at the time.
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.