blog

I’ve successfully neglected touching or updating this blog for (I think) close to two years now, almost all of which I have spent working full time as a software engineer. It’s largely been an enjoyable experience, but I think that what I wrote about in “On the enjoyment of work” has largely turned out to be true.

I’ve found that doing a 40-hour job that is effectively just coding has very much dulled my passion for doing anything with code outside of work. You can see this effect in the slow down of my activity on my GitHub account, on the lack of repositories over on SourceHut, and my lack of blogging about anything, as much of this blog’s content thus far has been coding related.

Instead of having coding as a hobby, a number of other activities have effectively replaced it; singing, cycling and rock climbing (more specifically bouldering). I currently cycle around 3-4 hours a week, sing three times a week for a total of around 8 hours a week, and boulder probably around 10 hours a week. These generally function as nice hobbies to have, that generally work my brain to some extent as well (with the arguable exception of cycling), and all improve parts of my health and well-being in various respects.

Since the last time I wrote a post, I’ve also entirely moved cities!

I moved from Perth (my hometown, though not where I was born), to Sydney. My work is based in Sydney, so although it was difficult to leave my family behind it made sense to move - especially with Sydney being a state with day-light savings, which always did my head in when I was in Perth as we did not have day light savings.

I was originally planning to move a few years ago once I got my job, but, as with many other things, the COVID-19 pandemic effectively put a stop to it for two years. It was a relief to finally move and put an end to the limbo-type situation that had occurred whilst I was in Perth, and although Sydney has only been my home for a few months it has certainly started to feel like home.

A few months ago I started on a project to create a cross-platform podcasting application. I made it all the way through to being able to go through feeds, download and play individual episodes before very much slowing down development. For the most part working on this has been good fun - although as noted above I don’t tend to code in my spare time very much anymore, which is of course quite limiting in terms of what I’m able to do. My main motivation was to have a cross-platform RSS/Atom reader and podcast player that I could keep synced and use between all of my devices. Due to my move to Sydney and thinning down of usable devices some of the motivation for this issue has been assuaged, however I think it may still be something useful to have around as an open source project.

An interesting project that is on a similar trajectory is termusic.

I started on it in Rust, as that tends to be my preferred language for coding at the moment. A major issue that I’ve run into is trying to integrate it into the “Now Playing” centre that most platforms have (on Apple platforms this is literally called Now Playing) - especially on Apple platforms. iOS (and macOS to some extent) require that integration with Apple frameworks is done using Swift, which is a fine language, just one that I’m not at all familiar with. There is a crate called swift-bridge which attempts to solve this issue which I’ve had some limited success with (mostly due to my terrible Swift code), but I think I may still be some way off of getting this working reliably.

As I write this, however, I’ve just discovered a Rust crate called Souvlaki which handles this for you, so hopefully there will be much quicker progress on this front soon.

I don’t think I’ve previously mentioned my faith on this blog at all, partly because I’m always a little bit leery of saying the wrong thing or misrepresenting a view and alienating people. This is particularly complicated by the fact that my particular faith (evangelical Christianity) has a tendency to be particularly maligned these days, particularly as the issue of sexual identity has come into such focus in the last few decades.

I mention this for two reasons; one that is coding related, one that is related to this blog. First, I have been looking into good methods of electronically studying the bible and extra-biblical resources (such as Greek dictionaries, commentaries, historical writings and the like). This is something that is technically available as an existing application, Logos Bible Software, which actually provides a good value offering for what is being delivered. I would - however, like a Linux version (despite not currently having a Linux computer), as well as the have the core of the software be free software. Perhaps there is a system that I could use with something like Calibre, but I’m not familiar enough with it at the moment. Regardless, its something that has been ticking over in the back of my mind.

Second, I would like to start trying to write down some of my opinions on religious things on this blog, perhaps through doing something like an exegetical study of particular passages. I’m likely to try to keep away from any controversial or contested issues as I simply do not have the expertise to wade in, but perhaps pointing to people or books that I found helpful on similar subjects may be useful. This is quite a turn around from my previous position on this (which was effectively “don’t mention or hint it at all), but I think that even if I get things wrong it will be helpful to be able to track how my opinions on these things change over time as I mature as a Christian into the future. Who knows - it may even be a useful resource to someone else in the future.

Being the typical zoomer that I am, dark mode has become an essential component of my digital experience. Over the many years of late-night gaming and the early onset of myopia from staring at too many screens, the blinding effect of the white backgrounds eventually pushed me into more and more dark-themed applications. I'm writing this blog post on a dark-themed computer, running a dark-themed terminal emulator running a dark-themed neovim instance. Even once this post is finished, I'll double check it on my dark-themed browser, before swapping to my dark-themed phone and making sure that things look fine on there.

My love of dark modes has extended into other applications as well. GitHub has its dark-mode set on by default for me, as does Sourcehut and YouTube. DuckDuckGo because my primary search engine partly because it gave me easy access to a dark-mode that I could never get working on Google. I stopped using the Gmail web client last year in favour of terminal-based alternatives partly because I could never get dark-mode to work properly on it.

All of this, and until a little over a week ago, I only had a light theme on my blog. Scandalous.

The theme that I use for this site (which when I finally publish it will be able to be found here) is based on insipx's Ergo theme, which is in turn based on svbtle. It's a lovely minimal theme, but unfortunately it only has a light theme.

As mentioned above, there are a number of websites which I use with dark-mode enabled, and surely I could just pick one and do what they do? Well unfortunately for me (but not unfortunately for this post), most of them require local storage of some form in order to retain your mode between sessions. Changed computers or browsers? That's a revision back to the realm of light-mode for you. Opened up a private browsing window? Better hope they've somehow tracked you through there before your eyes begin to burn.

Even some of my favourite blogs (such as fasterthanlime) which have a dark-mode use local storage to activate it, and it can extremely temperamental between sessions.

Fortunately I can continue to avoid JavaScript on my website thanks to the @media(prefers-color-scheme) feature. As stated on the MSDN, the prefers-color-scheme media feature can be used to detect if the user has requested a light or dark colour scheme, and allows you to override CSS variables accordingly.

This is actually what Sourcehut does to set its colour scheme, and as such I've based my dark theme on theirs. I think the blue accent is much more suited to a dark background than red, and vice-versa for a light background.

So, if you are currently seeing this in what looks like dark-mode and would like to see what it looks like in light-mode or vice-versa, it should change to the other dynamically when you change your device theme. As for me, I'm going to never look at the light theme of my website again, and pray that it never breaks.

I recently started listening to music with my Sennheiser 6XXs after around six months of using nothing but earbuds (Sennheiser Momentums and Momentum True Wirelesses).

Now, I love the sound on my earbuds, especially compared to the many other earbuds that I've tried, something about Sennheiser's audio engineering just works particularly well for my musical tastes. I had found, however, that as time went on I used my earbuds less and less, and was generally more happy to listen to music and podcasts using nothing but the speakers of the device they're playing on. Part of the reason for this is that my Pixel 5 doesn't have a headphone jack (although I do have wireless earbuds) and my experience of bluetooth audio on my desktop and laptop (regardless of operating system) has left a lot to be desired, so the easiest common ground was just the speakers.

Since I've restarted my use of my Sennheiser 6XXs, I've spent the days doing nothing but listening to music for the sake of the audio experience, which I never really did with the various earbuds. The songs I'm listening to I have heard before, but with the better audio quality and dynamic range comes a whole new range of experience that I simply didn't have access to before - and its hard to quantify how much better it is.

I think that's part of the reason that "audio quality" is so difficult to sell - it's an almost unquantifiable metric that is both incredibly subjective and extremely expensive. High quality audio gear sells for thousands of dollars, and the curve of how much more needs to be invested for a substantial difference is such that gear that is "good enough" sells for less than a hundred dollars. How on earth could you convince anyone that hasn't already invested into audio gear that it is worth it?

I'm certainly going to try to start using my headphones more, and that's also going to involve a level of investment and care from me. My house gets extremely dusty (especially in the summer) - which is part of the reason that I put my headphones away in the first place - and so I'll have to figure out a way to make using them both easy and largely dust proof.

I recently transitioned away from the ion shell to zsh, and I figured it might be a good idea to float some of the advantages and disadvantages that I've found during this time.

Advantages

1. Mostly POSIX compliant.
   I'll touch on this more later, but in general the ability have portable scripts that work across systems and shells has been incredibly useful - especially as I expand the number of machines I use and prepare to start working after finishing my masters. For those wondering, ion is explicitly not POSIX compliant.
2. I can reclaim the @ symbol and not worry as much about quoting ssh.
   This is a part of ion's lack of POSIX compliance, and it claims the @ sigil for use in array specific functions and variables. I've generally found throughout my use of ion that I use array variables much less than I do the @ sigil, and getting it back for ssh, git and the like has been a major boon.
   (It isn't so much that I'm against arrays per say, just that I'd prefer that it somehow reused a symbol that's already typically used by shells instead of nomming another character)
3. Its much easier to get setup on new computers.
   I've just put Alpine Linux on a Raspberry Pi 2B, and have begun migrating some recurring tasks to its crontab. Last time I checked, ion still had some issues building on arm-based platforms, so unfortunately I can't quite port my dotfiles to it. I've also recently completed my masters and will begin working in the middle of January. Knowing the company that I'm working for, there's a chance that I might be getting one of the new-fangled Apple Silicon Macs, and at the time of writing this post, there are still issues with porting even just the Rust compiler to the new platform.
4. Completion.
   Oh boy this is a big one. ion "has" completion, in that you can tab complete files and commands. What it doesn't have - however - is the ability to tab-complete arguments (which can be an absolute life-saver) nor other more specific completions such as man pages.

Disadvantages

1. Slower start times.
   I open a lot of shell prompts - anyone who basically lives in the terminal and incessantly uses tmux does. Something that I've definitely noticed is that the time it takes to open a new window or prompt is much lower with ion than it is with zsh - and indeed hyperfine backs this up. An invocation of hyperfine 'zsh -i -c ". ~/.zshrc; exit"' takes around 70ms (with approximately half of that being completion pre-processing), whilst running hyperfine 'ion -i -c "source ~/.config/ion/initrc; exit"' only takes around 20ms. And that's despite my ion config doing more than zsh's as well as not being as well optimised.
2. Visible history completion.
   One of my favourite features of ion is that (similar to fish) it shows you the most recent matching command in your prompt. As of yet, I haven't been able to figure out a way enable a similar behaviour in zsh without loading an extension module, which has me weary due to the potential additional startup latency I might end up with.

Conclusions

I think I'm probably going to stick with zsh until I find a better shell to move to. Something like mrsh seems like a great idea of something to move to eventually, especially as dash will likely never implement any form of completion, whilst imrsh names good completion as one of its goals.

Interestingly, one of ion's major advertised features - its inbuilt data structures - are actually something that I've found myself rarely using, especially whilst actually at the shell. I usually find that should a hashmap or the like be required, then that script should probably be converted to a language like Python, even if only for clarity and the rich inbuilt libraries.

I recently tried using emacs for the first time in many years (the last time I used emacs was back in early 2017, and I moved to using vim later that year). Many of my colleagues at my last internship use emacs - there was even an internal minor mode for editing and using many of the internal tools - and a number of friends at university are also emacs evangelists, so I thought that it'd be a good idea to re-acquaint myself with the editor that I left behind.

Long story short - I've decided to stick with neovim. There's actually a bunch of reasons why (which I can probably go into at a later date), but my brief foray back into the world of emacs showed me an interesting difference in philosophy between emacs and vim packages.

As someone who (of course) wants to use vim bindings in every text editor that I use, I of course installed evil-mode, the vim compatibility layer for emacs. This went along quite swimmingly until I had to install other packages, all because they all automatically overrode keybinds.

This was a pattern that tended to find throughout my emacs experience. Packages create their own major or minor mode, and then provide a number of key-binds within that mode to interface with its functionality - which can cause a lot of problems for me when I've remapped a good number of the keys because I don't use a QWERTY keyboard.

It's become like a game for me. See how many plugins I can find that all try to override the same key-bind.

In my experience, vim packages have the exact opposite approach - although I will fully admit to not using very many packages. coc.nvim, for example, doesn't set any keybinds and instead requires the user to assign their own binds to the functions that it provides. FZF does exactly the same thing, as does vista.vim.

This has actually been really surprising to me, as I would have likely expected the exact opposite. I often hear emacs talked about as being an "elisp interpreter with an editor attached" - which to me suggests that the primary focus of emacs would be on elisp functions - whereas vim's major selling point is its excellent keybindings.

I think that if emacs packages had taken a similar approach to what vim packages seem to - that I'd have expected them to take - then I'd almost certainly switch to emacs for the additional flexibility of having the power of lisp at my fingertips. As it is, however, it would take far too much work every time I install a package for me to want to move.