Leon Mika

Long Form Posts

Dec 30, 2023 ∞

Day One Waffling

Thinking about my journalling in Day One recently and I’m wondering if it’s time to move it off to something else, maybe Markdown files in a Git repository. Still mulling it over but every time I weigh the two options in my mind, the simpler Markdown approach always wins out.

Plain old Markdown files are just way more versatile and portable than what Day One offers. I can put them in a private Hugo (or Eleventy) site and browse them in a web browser, with the backing of a full HTML renderer that offers, amongst other things, figures with captions (yes, I want them that badly). Making them into a book will be more involved than what Day One offers, but I’ve been a little unhappy with how books from Day One are laid out anyway. Doing it from Markdown files will be pricier and more involved, but at least I’ll have a bit more control over how it looks.¹

I’ll miss the writing experience from Day One though, especially things like recording the current location and weather for each entry. I’m still wondering what the best substitute for it will be.

I’m toying around with a web-app I whipped up yesterday. A web-app will be fine for those times I’m online, but how would it work if I’m in an aeroplane? I’m also a little worried about trying it for a while, then abandoning it and leaving it to rot. I guess one thing going for it is that at-least it won’t lock me out of any entries, since they’ll just be Markdown files in Git.

I’m also considering iA Writer. I haven’t tried it yet but from my understanding, it’ll just write Markdown files to a directory, which is the goal. But I’m not sure how I can get the posts and media from there to a Git repo.

Anyway, that’s the current thinking. Will keep you posted on what happens.

---

1. Of course, the challenge there will be to overcome the friction involved in doing this work to actually get the book made. ↩︎

Dec 29, 2023 ∞

First Impressions of Eleventy

I tend to use Hugo whenever I need a static site. But my magpie tendencies have driven me to take a look at Eleventy, and I can definitely see the appeal.

Going through the Eleventy quick-start guide, I’m quite impressed with how easy it was to setup a bespoke layout for a single site. I’ve done similar things in a few Hugo sites and while I wouldn’t describe it as “hard”, it’s certainly more involved. Hugo’s decent, but it feels quite… engineered. That’s not necessarily a bad thing: putting together something using one of the pre-built themes is quite straightforward. But going beyond a few theme customisations involves a fair bit of work compare to Eleventy.

There’s still much more I’ve got to learn, like how Eleventy handles resource bundling (I like how Hugo handles this directly in the template) and configuration (how Eleventy does this is very Node-esk, which is not my preferred approach). But it’s definitely something I’ll keep in my toolkit.

Dec 24, 2023 ∞

2023 Song of The Year

Well, believe it or not, my standing Christmas Eve Mass organ gig has come around once more¹, so it’s time to decide on this year’s Song of The Year. This is the second post in this series, so please see last year’s post on what this nonsense is all about.

This year’s nominees are (not too many this year):

• Wooden Ship, from Antarctica — Suit for guitar and orchestra by Nigel Westlake.
• Penguin Ballet, from Antarctica — Suit for guitar and orchestra by Nigel Westlake. Not really a new track for me, but I’m including it here anyway as it’s been many years since I last heard it².

And the winner is: Wooden Ship by Nigel Westlake 👏



Specifically, the version played by the Tasmanian Symphony Orchestra and released by the ABC. This has been quite a special song for me this year and was pretty certain to be the winner for most of the year. Well, since first hearing it in May, there hasn’t been another one to top it. So bravo!

But that’s not to say there weren’t other tracks discovered this year. The honourable mentions:

• The Last Place on Earth, from Antarctica — Suit for guitar and orchestra by Nigel Westlake. A good song, but a little too complex for me.
• “Extremes”, from Music From the Private Life of Plants by Richard Grassby Lewis. Really wish I had a recent link to this (the only one I know of that works is one to a defunct music store, picked up by the Wayback Machine, that previously sold this album).
• The Knight, from the Tunic OST by Lifeformed & Janice Kwan. Not a completely new album to me, but until now, I tended to skip this track.
• Epic Grandpa, by Izioq.

---

1. It’s the only gig on my calendar actually. ↩︎

2. And to have at least one other nominee with what was ultimately going to be the winning song this whole year. ↩︎

Dec 7, 2023 ∞

Test Creek: A Test Story With Evergreen.ink

Had a play with Evergreen.ink this afternoon. It was pretty fun. Made myself a test story called Test Creek which you can try out (the story was written by me but all the images were done using DALL-E).

The experience was quite intuitive. I’ve yet to try out the advanced features, like the Sapling scripting engine, but the basics are really approachable for anyone not interested with any of that.



I would recommend not writing too much on a single card. Keep it to maybe two or three paragraphs. Otherwise the text will start to flow over the image, like it does on one of the cards in this story. Evergreen.ink does keep the text legible with a translucent background. But still, it’s just too much text.

I should also say that the preview, to the right of the editor, is interactive, meaning that you can use it to jump to cards backed by the options. While I was playing around, I was wondering why there wasn’t a quick way to do this. It wasn’t until I started writing this post that I actually tried the option in the preview, and it worked.

As for the app itself, if I could make one improvement, it would be something like an image picker which would allow me to reuse images already attached to other cards. I’m not sure how best to use images in these types of stories, but the way I was going for was more to accent the story instead of simply illustrating what’s going on in the prose. So I wanted to reuse images over a series of related cards, and in order to do that I had to upload duplicates.

But really, this is quite a minor quibble. On the whole I was quite impress by how well the experience was. It’s not easy trying to express something as complex as an interactive story, and I think Evergreen.ink did a pretty decent job.

So yeah, give it a try. It was quite fun putting this interactive story together. I haven’t got any other ideas lined up, but it would be good to make another one down the line.

Edit: One other thing to be aware of is that the link given to you when you try to share a story requires a login. So if you want to avoid that, you’ll need to choose the Zip option, which basically bundles the story as a static website. You can deploy it to Netlify quite easily (just check the permissions of the files first, I had to chmod 666 them). Thank-you Robb for letting me know.

Also, thank-you to omg.lol for the Switchboard feature. It saved my tale dealing with the new redirect.

Nov 25, 2023 ∞
Best, First, Favourite
On Reconcilable Difference #221, Merlin and John introduced the concept of “Best, First, Favourite”. For a particular category, which would you consider the best (i.e. closest to a perfect representation of that category, in however you define it), which would you recommend someone who’s interested in starting should experience first, and which one is your favourite.
I thought it was a fun idea, so I’ve put together a few of my own.
It was hard coming up with categories for this one, particularly when considering “best” and “favourite”. You need to have had enough experience to know what makes a good “thing”, in order to judge it against all the others and come up with a “best” one. It also helps to have enough experience to avoid picking your favourite as the best as well. I tried picking categories in which my favourite is different than what I consider the “best”. And it might be that I lack variety in my life, but the list of categories that I managed to come up with was relatively short.
Nonetheless, here they are:
Category: Mike Oldfield music
• Best: Tubular Bells 3. Oldfield was in his element here. A balanced helping of both accoustic and electronic, slow and moving, and very consistent in it’s theming.
• First: Tubular Bells 2. It may seem that Tubular Bells should be the album to goto for a taste of Mike Oldfield, and it certainty has the Oldfield signature sound. But I’d suggest considering going with this album first, as it’s a bit more refined while having the same basic structure. It’s also the album that grabbed me.
• Favourite: Crises; The Songs of Distant Earth. I’d probably put TB3 here as well, but in lieu of choosing something that I also consider the best, these two are probably my next favourite. Or it could just be the positive associations I have of them: Songs of Distant Earth reminding me of faraway places, Crises reminding me of home.
Category: Episodes of Seinfield
• Best: The Parking Garage. A refinement of The Chinese Resturant, which was groundbreaking in it’s own right. Honourable mention: The Parking Space.
• First: The Conversion. I think anything in Season 5 or Season 6 would work here. I’ve chosen this one as I wanted an episode which showcases all the character’s traits without having too many supporting character (that also features George’s parents). Honourable mention: The Bris.
• Favourite: The Busboy. This is a series 2 episode, while they were still finding their feet. But it’s one of the first where the writers manage to have multiple plot threads all wrapped up together in a cohesive whole by the end, an attribute of the writing that I absolutely love. Honourable mention: The Dinner Party.
Category: Programming text editors (for MacOS)
• Best: VS Code. I’m not a user of this myself but I can’t deny the amount of effort (and that sweet, sweet Microsoft cash) that’s going to this project. Certainly it’s the most capable out there for pretty much any language you need to work in.
• First: Nova, depending on which language you’re working in. Obviously if you’re doing anything Apple related, it’s probably best to go with XCode or something. But I think for anything else, Nova is a pretty decent text editor, and definitely one worth trying for anyone starting out.
• Favourite: Anything from JetBrains. When you feel like moving into something a little more integrated, especially for languages considered “complicated”, I can definitely recommend the IDEs from JetBrains. I use Goland in my day-to-day, with the occaional WebStorm for anything frontend that is considered large. Others include IntelliJ and Android Studios.
Category: Apple-related Tech Podcasts for anyone that has never heard a podcast before
• Best: Upgrade. I’m not much of a listener of this one anymore, but it’s still a very well-produced show, and Jason really knows his stuff.
• First: The Talk Show. I think having something a little more off-the-cuff is the way to get into the medium. You have to warm yourself into it, like you’re having a conversation with friends, and starting with something a little “produced” can leave you feeling as if you’re just another listener (which, I guess, you are but you shouldn’t want that feeling). I think the Talk Show fits the mould here. It did for me.
• Favourite: Accidental Tech Podcast. Hands down. Informative and enjoyable to listen to. This is one that I do my best to catch every episode they release.
Category: Walks in and around greater Melbourne
• Best: Sherbrooke Falls, Mt. Dandenong. This is not the longest, nor the most challenging, but it’s by far the prettiest. Walking amongst the great Mountain Ash is quite a moving experience. Be sure to have the soundtrack of the Atterborough documentary series The Private Life of Plants playing while you do.
• First: The Domino Trail, Trentham This is about an 1.5 hours out of Melbourne but a nice easy rail-trail going through the lovely forest around the Domino Creek.
• Favourite: Bushrangers Bay to Cape Shank Lighthouse: A two hour return walk that is moderately challenging with lovely scenes of Bass Strait. Don’t be surprised to run into a kangaroo or two (plus the occasional snake; look out for those).
Category: Pubs in and around greater Melbourne that make a decent parma
• Best: The Panton Hill Pub, Panton Hill. This is a good 30 km out of Melboune area, in the green-wedge in a little town called Panton Hill. There’s not much there: a few houses, maybe a shop or two, and this pub. But they do a pretty solid parma there. Good fillet, decent balance of cheese and ham, and a good portion of chips and salid. It’s been a while since I’ve been there, so things may have change.
• First: The Turf Bar, Queens St. If you’re visiting Melbourne for the first time, and you’d like to try a pretty decent parma, then I’d probably suggest trying out the Turf. It’s probably not the best pub in town: it’s more of a sports bar and can be pretty load when city-workers go there for Friday lunch or drinks. But I’ve been pretty impressed by the quality of their parmas. Be prepared to wait a little while for them.
• Favourite: The Old England Hotel, Heidelberg. This is not the best parma out there, but they’re pretty consistent. One thing going for this place is that it’s easy to get to.
Nov 19, 2023 ∞

Idea For Mainboard Mayhem: A Remote Pickup

Sort of in-between projects at the moment so I’m doing a bit of light stuff on Mainboard Mayhem. I had an idea for a new element: a remote control which, when picked up, will allow the player to toggle walls and tanks using the keyboard, much like the green and blue buttons.

I used ChatGGT to come up with some artwork, and it produced something that was pretty decent.



Only issue was that the image was huge — 1024 x 1024 — and the tiles in Mainboard Mayhem were only 32 x 32.

I tried shrinking it down in Acorn, using various scaling algorithms. The closest that worked was bringing it down slowly to about 128 x 128 using Nearest Neighbour, than trying to go all the way down to 32 x 32 using Lanczos. That worked, but it required true 32 bit colour to be recognisable, and I wanted to preserve the 16 colour palette used by the original Chips Challenge.

So using the original image as a reference, I bit the bullet and drew my own in Acorn. You can see it here in this test level:



It turn out okay. At least it’s recognisable. Anyway, I coded it up and gave it a bit of a try:

Yeah, it works well. When the player has the appropriate colour remote, they can hit either Z or X to toggle the green walls or blue tanks respectively. I really should add some indicators in the status bar to show which button to press.

Not sure what I’ll do after this. The fun part was coming up with the element. But I guess I’ll have to come up with a few puzzles that use it.

Nov 16, 2023 ∞

A Few Thoughts On Using iA Presenter

Well the “big presentation” was today, the one I thought would be a good canditate for trying out iA Presenter. And after spending the last couple of weeks preparing for it, I’d thought it would be good time to give my thoughts on how it worked for me.

First, I must say that I can appreciate using an app that is opinionated. This is not a drop-in replacement for Keynote¹: the app really does try and steer you towards a particular presenting style. They’re quite upfront with this: the example shown on first launch outlines how to prepare the slides and why writing out the entire presentation in full, while leaving slides as the role of accenting your points, makes for better presentation.

I knew this going in, so it wasn’t a big shock to me. Plus it’s easy to like an opinionated piece of software when you share that opinion yourself.

This flows naturally into the second thing that I like about iA Presentation, which is the Markdown support. Using Markdown to prepare the slides is wonderful, especially when you compare it to the point-and-click content-by-bullet-point interaction style you’d find in Keynote. That WYSIWYG styles is not for me, particularly when it comes to correcting style and alignment issues that only affects one slide that sticks out like a sore thumb when giving the presentation. Markdown only means iA Presenter is left to handle the layout, and that’s fine with me.

Now, it would be nice to have even more control over the slide layout and styling. iA Presentation has very limited support for this, and while I was preparing the slides, I kept finding myself wishing that I could do more of the finer things, like adjust the font size of a code block to avoid line-wraps.

There are some things you can do, such as choose whether elements should appear below or beside each other. This is done through the use of new-lines — or lack there-of — which is a style that didn’t really gel with me. It seemed like a concept that was a little undercooked. It also didn’t help that there wa no way to actually force a new line, to do something like space out content vertically.

I don’t know how this could be improved. Maybe having a way to specify a layout or styling that is separate from the implicit styling from the Markdown, sort of like slide-specific front-matter, maybe? If done in such a way as to avoid complicating things too much, it’ll probably be welcomed.

One other thing that would be good is to have more control over separating the layout of the slides from that of the exported speaker notes. You’re essentially writing long-form content, complete with headers that’ll appear on the slide. But putting a H2 header over a H1 header to start a section would look strange in a PDF export. It’ll look fine on the slide, but that’s becasue you’re stuck using header levels (h1, h2) to control text size. Because the content on the slide is interleaved with the speech itself, the order of elements that make sense on the presentation may note for the exported PDFs.

Although I guess the solution there would be just to open the presentation in a regular Markdown editor and export to PDF. But having a one-stop solution to that would be nice. So, I don’t know: having a way to separate the symantics of the header from the size they appear on the slide would work? (Maybe all I want is just HTML, 🤷)

So, what’s the verdect? Would I use iA Presenter again? Hmm, maybe. If I’m working on a presentation with a small number of slides containing simple visual elements designed to emphasise something, such things you’d find at TED talks or an Apple keynote, then yeah, I’d probably use it again. It’s a style of presentation that the app is clearly optimised for, and it does a good job for that. If I needed slides that were a little more informative in their own right, I’d probably consider something else. Probably not Keynote, but I’d consider one of the JS+HTML options.

But it’s a really nice app² and a pleasure to use, so it’s probably worth checking out for your next presentation.

---

1. Not to single out Keynote here. You can easily use Powerpoint or Google Slides as a drop-in replacement for this post. ↩︎

2. I didn’t talk about the UI as I wanted to focus on the preparation aspects, but the UI is delightful. They put a lot of care into it, and despite being “just a text editor”, seeing the little things like having the highlight or carrat colour match the slide background colour is a really nice touch. Dare I say, almost whimsical. ↩︎

Nov 12, 2023 ∞

Resurrecting Untraveller And Finishing The RA-V Mission Posts

It’s been 10 years to the day when I had the opportunity to tour the Pacific as part of my job at the Bureau of Meteorology, the so call “RA-V Missions”. This last month or so, I’ve been writing about them in my journal, trying to get it all down before I forget. I had grand plans of publishing them on a travel blog, which I shelved a couple of months ago.

But while I was updating my journal, I was wondering if anyone else would find it interesting. Probably not, really: I don’t know if people enjoy reading about other peoples work trips (I can go either way, myself).

But in the off-chance that someone out there will find this story intriguing, I decided to resurrect my travel blog and publish these (moderately edited) journal entries.

If this ends up being your cup of tea, I hope you enjoy it. I may add some other trips to the site down the line (including the ones that were on the old one). I’ll let you know here if I do.

Nov 4, 2023 ∞

Defaults

I see that Gabz, Robb, and Manique — along with many others — have posted their defaults after listening to Hemispheric Views 097 - Duel of the Defaults!, which was a really fun episode. I thought I’d do the same.

• Mail Client: Fastmail. Web-app on the desktop and app on mobile
• Mail Server: Fastmail
• Notes: Obsidian for work. It was Obsidian for personal use but I’m trying out Notion at the moment.
• To-Do: Obsidian/Notion (todos go in as notes)
• Photo Shooting: Android camera app
• Photo Management: Google Photos
• Calendar: Google Calendar
• Cloud file storage: Google Drive
• RSS: Feedbin. I mainly read it with NetNewsWire but I also use the web-app.
• Contacts: Android contacts app.
• Browser: Safari, Vivaldi
• Chat: Mainly still use Android Messanger for SMS but started using WhatsApp more
• Bookmarks: Linkding running on Pikapods.
• Read It Later: None, but if I were to start, I’d probably try out Feedbin’s RIL service.
• Word Processing: n/a
• Spreadsheets: Google Sheets, Numbers (I don’t do a lot of spreadsheeting)
• Presentations: Keynote, but giving iA Presenter a try at the moment.
• Shopping Lists: Google Keep
• Meal Planning: n/a
• Budgeting & Personal Finance: n/a
• News: ABC¹ News, in a web-browser
• Music: Alto (my own music app), Spotify
• Podcasts: Pocketcasts
• Password Management: 1Password
• Photo Editing: Google Photo
• Weather: Bureau of Meterology website.
• Social Clients: Tusky (Mastodon)
• Code Editor: GoLand (Jetbrains in general), Android Studios, or XCode
• Text Editor: Nova
• Hard Quiz Expert Subject: Probably the music of Mike Oldfield.

Scored myself based on the rules of the game and came up with 44 points. It was a little tricky as I’ve got both feet in separate ecosystems.

---

1. Australian Broadcasting Cooperation ↩︎

Oct 30, 2023 ∞

Why I Like Go

This question was posed to me in the Hemispheric Views Discord the other day. It’s a bit notable that I didn’t have an answer written down for this already, seeing that I do have pretty concrete reasons for why I really like Go. So I figured it was time to write them out.

I should preface this by saying that by liking Go it doesn’t mean I don’t use or like any other languages. I don’t fully understand those that need to dislike other languages like they’re football teams. “Right tool for the job” and all that. But I do have a soft-spot for Go and it tends to be my go-to language for any new projects or scripting tasks.

So here it is: the reasons why I like Go.

First, it’s simplicity. Go is not a large language, and a large majority of it you can keep in your working memory. This makes Go easy to write and, more importantly, easy to read.

It might seam that a small feature set makes the language quite limiting. Well, it does, to a degree, but I’d argue that’s not a bad thing. If there are only a couple of ways to do something, it makes it way easier to predict what code you’re expecting to see. It’s sort of like knowing what the next sentence will be in a novel: you know a piece of logic will require some dependant behaviour, and you start thinking to yourself “how would I do that?” If the answer space is small, you’re more likely to see what you expect in the actual code.

But just because Go is a deliberately small language doesn’t mean that it’s a stagnant language. There have been some pretty significant features added to it recently, and there are more plans for smoothing out the remaining rough edges. It’s just that the dev team are very deliberate in how they approach these additions. They consider forward compatibility as much as they do about backwards compatibility, being careful not to paint themselves into a corner with every new feature.

Type parameters are a great example of this. There were calls for type parameters since Go 1.0, but the dev team pushed back until they came up with a design that worked well for the language. It wasn’t the first design either. I remember one featuring some new constraint-based constructs that did about 80% what interfaces were doing already. If that were shipped it would’ve meant a lot of extra complexity just for type parameters. What was shipped isn’t perfect, and it doesn’t cover every use case type parameters could theoretically support. But it made sense: type parameters built on interfaces, a construct that already existed and was understood.

This, I think, is where C++ fails to a huge degree. The language is massive. It was massive 30 years ago, and they’ve been adding features to the language every few year since, making it larger still. I see Apple doing something similar with Swift, and I’m not sure that’s good for the language. It’s already quite a bit larger than Go, and I think Apple really should curb their desire for adding features to the language unless there’s a good reason for doing so.

The drive for simplicity also extends to deployments. Go is compiled to a static binary, one that is extremely portable and could be easily deployed or package as you so desire. No need to fluff about with dependencies. This is where I found Go having a leg-up over scripting languages, like Python and Ruby. Not because Go is compiled (although that helps) but that you have less need to think about packaging dependencies during a deploy. I wrote a lot of Ruby before looking at Go, and dealing with gems and Bundle was a pain. I’m not a huge Python expert to comment on the various ways that language deals with dependencies, but hearing about the various ways to setup virtual environments doesn’t fill me with confidence that it’s simple.

And I will admit that Go’s approach to this isn’t perfect either. For a long while Go didn’t even have a way to manage versioned dependencies: they were all lumped into a single repository. The approach with modules is better, but not without some annoyances themselves. Any dependency that goes beyond version 1 requires you to change the import statement to include a vX, an unnecessary measure if the version change is backwards compatible. That’s not even considering packages that avoid this, and are forever on version 1 (or 0).

But since moving to modules my encounters with package dependencies issues remains quite rare, and once you’ve got the build sorted out, that’s it. No need to deal with packaging after that.

And I’d argue that Go rides that sweet-spot between a scripting language like Python and Ruby, and a compiled language like C (maybe Rust, but I know very little of that language to comment on it). It’s type safe, but type inferences make it easy to write concise code without excessive annotations everywhere. It’s compiled to an executable, yet memory is managed for you. I won’t talk about how Go does concurrency, but after dealing with Java threads for several years, using them are a joy.

I should probably balance the scale a bit and talk about areas where I think Go could be made better. The big one is error handling. While I do like the principals — that errors are values and can be handled as such — it does mean a lot of boilerplate like this:

foo, err := doThis()
if err != nil {
  return err
}

bar, err := doThat(foo)
if err != nil {
  return err
}

baz, err := doAnotherThing(bar)
if err != nil {
  return err
}

To the Go teams credit, the are looking at improving this. And I think there’s enough prior art out there for a solution that’ll look pretty nice without having to resort to exceptions. Maybe something like Swift’s guard statement, that can be used in an expression.

And yeah, other areas of Go, like it’s support for mobile or GUI-style programming and lacking a bit. That could probably be plugged with third-party modules to a degree, although I think because Go is not an object-orientated language, the seals won’t be perfect (take a look at Go’s implementation of QT to see how imperfect Go maps to a toolkit that assumes objects). And some gaps need to be plugged by Google themselves, like with mobile support (they do have something here, but I’m not sure to what degree they’re being maintained).

But I’m sure most of these issues are surmountable. And no language is perfect. If Go doesn’t work for a situation, I’ll use Java or Swift or something else. “Right tool for the job” and all that.

So these are the reasons why I like Go. And I think it all boils down to trying to keep the language simple while still being useful. And as far as my experience with Go is concerned, those maintaining it are doing a pretty stellar job.

Oct 24, 2023 ∞

Work Email Spam

Opened my work email this morning and received a greeting from the following spam messages:

• Webinar to “overcome the fear of public speaking” from some HR Training mob
• A training course on “accelerating innovation in data science an ML” (there’re a few emails about AI here)
• Webinars from Stripe, Slack, and Cloudflare about how other companies are using them
• Weekly updates about what’s happening on our Confluence wiki (this probably could be useful… maybe? But our wiki is so large that most updates are about things other teams are working on)
• A training course on some legal mandates about hiring (honestly, my email must’ve appeared on some mailing list for HR professionals)
• Another webinar from the first training mob about dealing with “employees from hell”

Marked all as read, closed email, and opened Slack.

Oct 6, 2023 ∞

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.

Can’t speak for the market but as a Pixel 6 Pro owner I can give you my opinion. You don’t need to watch the keynote to get that sense of disinterest. You can get it just by using the phone.

For the last few months¹ I’ve been experiencing a bug with the calendar widget. If you have nothing on your calendar for the next two weeks, it completely blanks out:



I doubt that this is intentional as the plus button doesn’t work either. Tapping it does nothing at all.

For comparison, here’s how it’s meant to look:



Now, bugs in software happen — they certainly happen in mine — and there’s no reason why Google would be immune to this, so I can forgive them for this bug showing up in a shipped version of Android. My problem is that it’s been like this for months now. This is a widget built by Google, included in Google’s Calendar app running on Google’s OS and Google’s hardware, and it’s been broken for this long. I would’ve expected this to be fixed in a few weeks, but for it to take this long?

I can’t see how anyone with an Android phone using this widget would not notice this. And the only reason I can come up with is that no-one in Google has noticed this. They simply don’t use Android, the OS that they build, in their day-to-day. Maybe some of them do, but obviously not enough of them to drive change. If there was, they would’ve found this problem and fix it by now. To quote Linus, “given enough eyeballs, all bugs are shallow,” and those eyeballs are obviously looking elsewhere.

Now this theory may be far fetched, but after reading Gruber’s piece, it seems like I’m not alone in thinking this. As he says later in the same article:

I’d wager that more Google employees carry an iPhone than carry a Pixel.

It shows.

---

1. I can’t remember when I first saw this, but I think it was in July. ↩︎

Oct 3, 2023 ∞

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. Using Auth0 and only have a limited number of emails available for your test environment? You may need a way to quickly reset a user. Support billing in multiple countries and need to do a test in one of them? You’ll need a way to change the user’s countries.

And I think that’s fine. Not every environment needs to be a reflection of production. As long you’ve got a staging or pre-prod environment where you can do things like rehearse deployments. But everything else should be skewed towards ease of development, which will mean making these drastic options available and easy to use.

Sep 27, 2023 ∞
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. Enjoy.

Sep 4, 2023 ∞

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):



It’s not the first time I saw this sign, but I had orange on my mind and the fact that it mentioned busses got me thinking, “how cleaver, they’re maintaining the design language through and through, using an orange sign to reference the bus service that would be replacing the trains.” Or so I thought, until I saw this sign:



Ah, that blew that theory out of the water. And also the opportunity to use it as today’s photo. I mean, I could’ve still used it — it’s still orange after all — but it doesn’t have the neat adherence to the design language that I was hoping it did.

Aug 30, 2023 ∞
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. The game is finish, and ready for release.
So here it is: Mainboard Mayhem: A Chip’s Challenge fan game (and yes, that’s its full title).

At the moment it’s only available for MacOS. It should work on both Intel and Apple Silicon Macs, although I’ve only tested on my M2 Mac Mini running Ventura.
It’s good to finally see this project done. It’s been in development for about last ten years, and I spent half of that time wondering whether it was worth getting it finished it at all. Not committing to anything meant any work I did do on it was pretty aimless, and I always felt like I was wasting my time. Giving myself three weeks to either kill it, or release it helped a lot. I’ll start making deadlines for all the other unfinished projects I’m working on.
As to what that next project will be, I not sure at this stage. Part of me wants to wait until this crunch time ends, but I suspect I’ll get antsy before then and start work on something else. I’ll keep you posted one way or the other.
But for now, if you happen to give it a try, thank you and I hope you enjoy it.

Aug 12, 2023 ∞

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.¹

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. I chose the Vienna template, which seems to have fallen out date: many of the template variables no longer work with a modern version of Hugo. I’m also please to see that I did end up customising the header image — a photo taken in Macedon of the train line to Bendigo — although that’s pretty much all I customised.



Believe it or not, I feel a little nostelgic for it. Such simple innocence in trying to summon up the courage to write stuff on the internet. Although don’t let the article count fool you: I think there were a total of 10 posts, with half of those being unfinished drafts. I was still trying to work out whether I’d like to write mainly about software technology, or simply talk about my day. But one thing’s for sure, I was under the impression that “real” blogs required posts with a title and at-least 300 words of content. That’s probably why I only had 5 posts finished in 8 months.

The second reason why I went with Hugo was that I’d have no excuse to tinker with a CMS. I’d figure that, given that I wasn’t using one, I’d be force to focus on the content. Well, that level of self-discipline didn’t last long. About in the middle of 2020, I started building a CMS for the blog using Buffalo. I was thinking of launching it with the name “72k” (72k.co), named after the milepost the header photo was taken at.



I got reasonably far with building this CMS but it still lacked a lot, like uploads and an RSS feed. It also involved a really annoying workflow: in order to publish something, you needed to choose a “post type” (whether it’s a long-form post; a link post; or a note), the “stream” the post will appear in, write a summary, and then “review” it. Once all that’s good, you’re free to publish it. This was in service of building this up into a popular, wizz-bang blog with a well-engineered navigation and category-specific feeds (I think that’s what “streams” were). Yeah, these grand plans got the better of me and really crippled the usability of the CMS². I never launched it, opting instead to move to Micro.blog.

So that’s what this blog looked like, back in the day. I probably won’t look at these projects again. It’s only been four years and already bit-rot is settling in: it took me all morning trying to hack these into a state where I can open them in a browser. But it’s good to look back at what it was.

Still really happy I moved it over to Micro.blog.

---

1. I don’t deny that part of this is procrastination of other things I should be finishing. ↩︎

2. To be honest, I think part of this lengthy workflow was to satisfy the “resistance”: self-imposed roadblocks to stop me from publishing anything at all. ↩︎

Aug 2, 2023 ∞

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.”

So you just “do the task.” And the next time you get that task, you face the same dilemma.

Of course the alternative is spending the hour to automate it, and then never running that tool again (or investing more time than you save keeping it up to date l).

I’m not sure what the best answer is. Maybe tracking times where you wish you had that tool you didn’t build somewhere? Then, when you’ve done it at least 3 times for the same thing, you have supporting evidence that it’s worth automating. Maybe include the time it took to do it manually as well, so you can compare it to how long it might take to build the automation.

Might be worth a try.

Jul 15, 2023 ∞

🔗 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 HL7¹, 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 database². 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.

---

1. HL7 is a non-XML format used in the medical industry. We mapped it to XML and passed it through an XSLT to extract patient information. Yes, we really use XSLT to do this! ↩︎

2. Ok, this is a bit of an exaggeration, but not by much. ↩︎

Jul 7, 2023 ∞

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.

Now granted, it’s not always possible to do this with micro-services. There’s always some dependency you need, and setting all these up is a bit of a pain. That’s probably why I deferred all my manual testing to the end, when I’ve pushed my changes to get them reviewed and deployed it to the environment. Do a quick cursory test from the frontend just to make sure it hasn’t broken anything, then move on to the next task.

I think this way of working was a mistake. This is something frontend developments get right: you need to run your software while you’re working on it. It’s so important to see not just how well it works, but how it feels to work¹: what goes to the log, how fast it performs, etc. You don’t get this feeling from just depending on unit tests.

Plus, there’s always a nice buzz to see the thing you’re working on run for the first time. That magic seems to decay the further you are from where it’s running. It just becomes another cog in the system. And maybe that’s what it’s destined to be, but it doesn’t need to be this way while you’re working on it.

---

1. I don’t know of a better way to say this other than “how it feels to work”. I suppose I could use boring words like “tight iteration loop” but there are too many boring words on the blog already. ↩︎