Some links about blogging that I found helpful.
Posts in "Long Form Posts"
Pixel Phones Are Not Dog-food, and That's a Problem
John Gruber on the Pixel 8 launch event:
It’s also impossible not to comment on just how much less interest there is in Google’s Pixel ecosystem. […] On the one hand I’m tempted to say the difference is just commensurate with how much better at hardware Apple is than Google. But I think there’s more to it than that. There’s something ineffable about it. There are aspects of marketshare traction — in any market — that can’t be explained by side-by-side product comparisons alone.
Your Dev Environment is Not Your Production Environment
There will be certain things you’re going to need to do in your development environments that you should never do in production. That’s pretty much a given: playing around with user’s data or potentially doing something that will cause an incident is generally not a good idea.
But there are things you shouldn’t do in prod that you may need to do in dev. And make no mistake, there may be a legitimate need to do these things.
Electrification of Melbourne Suburban Railways Plaque
Found this plaque while passing through Southern Cross station this morning.
I didn’t have time to read it, and the subject matter looks really interesting to me (Trains? Power Lines? What’s not to love? 😀). I also don’t know how long it’ll be up for, and I’ve been burned in the past of not capturing something when I had the chance.
So I’m posting photos of it here for posterity reasons.
Alternative Day Four Photo
I had an alternative idea for today’s photo challenge, which is “orange”. I was hoping to post a photo of something related to Melbourne’s busses.
You see, PTV has designated different colour for different modes of transport. Blue for metro trains, purple for regional trains, green for trams, and orange for busses. And from my experience using the service, they’re pretty consistent with adhering to this design language:
Anyway, they’re doing train works along my rail line over the past few weeks and this morning I noticed this sign (forgive the lighting, it was before dawn):
Mainboard Mayhem
Project update on Mainboard Mayhem, my Chip’s Challenge fan game. I didn’t get it finished in time for the release deadline, which was last weekend. I blame work for that. We’re going through a bit of a crunch at the moment, and there was a need to work on the weekend.
The good news is that there wasn’t much left to do, and after a few more evenings, I’m please to say that it’s done.
Early Version of This Blog
I was looking for something in GitHub the other day when I found the repository for the first iteration of this blog. I was curious as to how it looked and I’d thought that I’d boot it up and post a few screenshots of it.1
It started life as a Hugo site. There a two reasons for that, with the first being that I didn’t have the patients to style a website from scratch, and Hugo came with some pretty nice templates.
On Tools and Automation
The thing about building tools to automate your work is that it’s hard to justify doing so when you’re in the thick of it. Easy to see all the time you save in the aggregate, but when you’re faced with the task in your day to day, you’re just as likely to say “I can build a tool which will let me do this task in a couple of seconds, but it’ll take me an hour to build it verses the 5 minutes it’ll take for me to just do the task.
🔗 XML is the future - Bite code!
I wanted to write something about fads in the software development industry when the post about Amazon Prime Video moving away from micro-services back to monoliths was making the rounds. A lot of the motivation towards micro-services can be traced back to Amazon’s preaching about them being the best way to architect scalable software. Having a team from Amazon saying “micro-services didn’t work; we went back to a monolith and it was more scalable and cheaper to run” is, frankly, a bit like the Pope renouncing his Catholic faith.
I didn’t say anything at the time as doing so seemed like jumping on the fad wagon along with everyone else, but I have to agree with this article that this following along with the crowd is quite pervasive in the circuits I travel in. I did witness the tail end of the XML fad when I first started working. My first job had all the good stuff: XML for data and configuration, XSLT to render HTML and to ingest HL71, XForms for customisable forms. We may have used XSD somewhere as well. Good thing we stopped short of SOAP.
The whole feeling that XML was the answer to any problem was quite pervasive, and with only a few evangelists, it was enough to drive the team in a particular direction. And I wish I could say that I was above it all, but that would be a lie. I drank the cool-aid like many others about the virtues of XML.
But here lies the seductive thing about these technology fads: they’re not without their merits. There were cases where XML was the answer, just like there are cases where micro-services are. The trap is assuming that just because it worked before, it would work again, 100% of the time in fact, even if the problem is different. After all, Amazon or whatever is using it, and they’re successful. And you do want to see this project succeed, right? Especially when we’re pouring all this money into it and your job is on the line, hmm?
Thus, teams are using micro-services, Kubernetes, 50 different middleware and sidecar containers, and pages and pages of configuration to build a service where the total amount of data can be loaded into an SQLite3 database2. And so it goes.
So we’ll see what would come of it all. I hope there is a move away from micro-services back to simpler forms of software designs; one where the architecture can fit entirely in one’s head. Of course, just as this article says, they’ll probably be an overcorrection, and a whole set of new problems arise when micro-services are ditched in favour of monoliths. I only hope that, should teams decide to do this, they do so with both eyes open and avoid the pitfalls these fads can lay for them.
Code First, Tests After
Still doing the code first, tests after at work and I’m really starting to see the benefits from it. Test driven development is fine, but most of our recent issues — excess logging or errors that are false positives — have nothing to do with buggy business logic. It’s true that you can catch these in unit tests (although I find them to be the worst possible tests to write) but I think you gain a lot more just from launching the application and seeing it run.