Leon Mika

Christmas Eve spent hiking around Macedon and Trentham in regional Victoria.

Macedon walking track

Macedon walking track

Old telegraph pole alongside walking track in Trentham

Today is the last day of work for the year, and although I haven’t got much planned for the break, it would be good to have some time off.

I wonder if Tim Berners-Lee ever imagined that we would be using the web as a replacement for things like phones, radios, and televisions.

Follow up from yesterday’s post about my non-reading habits, a colleague of mine shared this article about the topic. It looks like the condition I have is tsundoku, which is “a Japanese term used to describe a person who owns a lot of unread literature.”

I don’t know if it’s just me, but I’ve got this annoying habit of seeing an article that looks interesting, and I decide to… just not read it. Instead I “save it for later”. The result: I end up never reading the article at all.

Vivaldi - My Recommended Alternative to Chrome

I’m seeing a few people on Micro.blog post about how Chrome Is Bad. Instead of replying to each one with my recommendations, I figured it would be better just to post my story here.

I became unhappy with Chrome about two years ago. I can’t remember exactly why, but I know it was because Google was doing something that I found distasteful. I was also getting concerned about how much data I was making available to Google in general. I can prove nothing, but something about using a browser offered for free by an advertising company made me feel uneasy.

So I started looking for alternatives. The type of browser I was looking for needed the following attributes:

  • It had to use the Blink rendering engine: I liked how Chrome rendered web pages.
  • It had to offer the same developer tools as Chrome: in my opinion, they are the best in the business.
  • It had to run Chrome plugins.
  • It had to be a bit more customisable than Chrome was: I was getting a little bored with the Chrome’s minimalist aesthetic, and there were a few niggling things that I wanted to change.
  • It had to have my interests at hand: so no sneaky business like observing my web browsing habits.

I heard about the Vivialdi browser from an Ars Technica article and I decided to give it a try. The ambition of the project intrigued me: building a browser based on Chromium but with a level of customisation that can make the browser yours. I use a browser every day so the ability to tailor the experience to my needs was appealing. I decided to download it and give it a try. First impressions were mixed: the UI is not a polished as Chrome’s, and seeing various controls everywhere was quite a shock compared to the minimalism that Chrome offered. But I eventually set it as my default browser, and over time I grew to really like it.

I’m now using Vivialdi on all my machines, and my Android phone as well. It feels just like Chrome, but offers so much more. I came to appreciate the nice little utilities that the developers added; like the note taking panel which comes in really handy for writing Jira comments that survive when Jira decides to crash. It’s not as stable as Chrome; it feels a tad slower, and it does occasionally crash — this is one of those browsers that need to be closed at the end of the day. But other than that, I’m a huge fan.

So for those looking for an alternative to Chrome that feels a lot like Chrome, I recommend giving Vivialdi a try.

Revisiting the decision to build a CMS

It’s been almost a month since I wrote about my decision to write a CMS for a blog that I was planning. I figured it might be time for an update.

In short, and for the second time this year, I’ve come to the conclusion that maintaining a CMS is not a good use of my time. The largest issue was the amount of effort that would have been needed in order to work on the things that don’t relate to content, such as styling. I’m not a web designer, so building the style from scratch would have taken a fair amount of time, which would have eaten into the amount of time I would have spent actually writing content. A close second was the need to add additional features to the CMS that were missing, like the ability to add extra pages, and a RSS feed. If I were to do this properly without taking any shortcuts, this too would have resulted in less time spent on content.

The final issue is that the solutions that I was trying to optimise for turned out not to be as big a deal as I first thought, such as the “theoretical ability to blog from anywhere”. I’ve tried using the CMS on the iPad a few times, and although it worked, the writing experience was far from ideal, and making it so would have meant more effort put into the CMS. In addition to this, I’ve discovered that I prefer working on the blog using my desktop, as I’ll more likely be in the state of mind to do so. Since my desktop already has tools like Git, I already had what I needed to theoretically blog from anywhere, and it was no longer necessary to recreate this requirement within the CMS itself.

So I’ve switched to a statically generated Hugo site served using GitHub Pages. I’m writing blog posts using Nova, which is actually a pretty decent tool for writing prose. To deploy, I simply generate the site using Hugo’s command line tool, and commit it all to Git. GitHub Pages does the rest.

After working this way for a week and a half, it turns out that I actually prefer the simplicity of this approach. At this stage both the CMS, and the blog it would have powered, has been in the works for about a month. The result is zero published posts, and it will probably not be launched at all1. Using the new approach, the new blog is public right now and I have already written 5 posts on it within the last 11 days, which I consider a good start.

We’ll see how far I’ll go with this new approach before I consider a custom CMS again, but I think it’s one that I’ve managed to get some traction now, particularly since it actually resulted in something. I think it’s also an approach I will adopt for new blogs going forward.


  1. This is not wholly because of the CMS: the focus of the blog would have been a bit narrower than I’d would have liked; but the custom CMS did has some bearing over this decision. [return]

It’s a shame that more and more bloggers are moving to email newsletters in leau of RSS. Even for bloggers that don’t charge for their content, I’m seeing more blogs that are encouraging readers to sign up to an email newsletter, instead of providing a link to an RSS feed.

I can see why they do this. Email addresses are valuable, and sites like Stratechery and services like Substack show that it’s possible to have a viable business writing a daily newsletter to people willing to pay for it. But one thing Ben Thompson offers that Substack doesn’t is a private RSS feed for subscribers, so they can read the daily updates within a feed reader. This is how I use to consume Stratechery, before the release of the daily update podcast.

So email subscriptions makes sense for those writing for a living, but I’m not sure it makes sense for those maintaining a free blog. If your content is available without charge, then it makes sense to me to offer an RSS feed to those that prefer to read your content within a feed reader. The reading experience in NetNewsWire is preferable to the one offered by my email client, and I don’t need to see all the emails that I’m trying to avoid. By all means offer email subscriptions as well, but don’t require one just so that I can see your latest updates.

Some uninformed thoughts about Salesforce acquiring Slack

John Gruber raised an interesting point about the future of Slack after being purchased by Salesforce:

First, my take presupposes that the point of Slack is to be a genuinely good service and experience. […] To succeed by appealing to people who care about quality. Slack, as a public company, has been under immense pressure to do whatever it takes to make its stock price go up in the face of competition from Microsoft’s Teams.

[…]

Slack, it seems to me, has been pulled apart. What they ought to be entirely focused on is making Slack great in Slack-like ways. Perhaps Salesforce sees that Slack gives them an offering competitive to Teams, and if they just let Slack be Slack, their offering will be better — be designed for users, better integrated for developers.

When I first heard the rumour of Salesforce was buying Slack, I really had no idea why they would. The only similarity between the markets the two operate in is that they are things businesses buy, and I saw no points of synergy between the two products that would make this acquisition worth it.

I’m starting to come round to the thinking that the acquisition is not to integrate the two products, at least not to the degree I was fearing. I think Gruber’s line of thinking is the correct one: that Salesforce recognises that it’s in their interest to act as Slack’s benefactor to ensure that they can continue to build a good product. Given that Salesforce has bought Tableau and Heroku and more-or-less left them alone, there’s evidence that the company can do this.

As to what Salesforce gets out of it, Jason Calacanis raises a few good reasons in his Emergency Pod on the topic around markets and competition. Rather than attempt to explain them, I recommend that you take a listen and hear them from him.

I love the idea of events like Microblogvember to help reinforce the act of writing frequently. I will admit it was difficult at times, but I definitely find it beneficial participating in these events when they come around. #mbnov

It’s interesting how the activities that would have seen quite pedestrian before the lock-down, like going to a cafe, are quite novel after the lock-down. #mbnov

It’s surprising how quickly you can get use to a mask outside when you’re required to wear one, and then get use to not wearing one outside when you’re not. #mbnov

My dilemma for today is whether to buy a blender, and which one would work for me. Something suitable for smoothies and that is easy to clean are features that I’m looking for. I’m also considering a coffee grinder. #mbnov

Passed by what I think is a Norfolk Island Pine tree. Incidentally, Norfolk Island is one of the few places outside the US to celebrate Thanksgiving.

I’ve just setup a subscription to Climeworks, which is a startup building plants for capturing and storing CO2 underground. I could argue about the price, but I think we need to adjust our thinking about these things if we’re ever going to mitigate this climate crisis. #mbnov

Even in these Covid times when I’m home 95% of the time, deciding whether and when to go for a walk such that I’ll be home to receive a delivery is still a surprisingly tricky call to make. #mbnov

Several years ago, I had the opportunity to work at a federal government agency. There was a lot to like about the experience, but one negative was the time it took to provision a virtual machine for us to run our code. The record for longest wait was about a year. #mbnov

Sunset over the suburbs, taken 2 weeks ago. You can get some pretty nice sunsets around this time of year. It’s a shame my camera and photo-taking skills are not good enough to capture how nice the light was that evening. #mbnov

During the second coronavirus wave in Melbourne, a “ring of steel” was imposed, encircling the metropolitan in an attempt to contain the outbreak. That border dropped a few weeks ago, and today we crossed it for the first time since June. #mbnov

One feature of living in the Southern Hemisphere is that you get to see winter decorations in shopping centres twice a year. First when it’s actually winter, and the second around this time of year, with the lead up to Christmas. #mbnov

It’s getting harder to go on lunchtime walks without having to slap on sunscreen or a hat. I may need to move to evening walks, when the intensity of the sunlight starts to fade. #mbnov (Today’s was a tricky one).

After dealing with Apple Developer Certificates and Provisioning Profiles for a single app for work, I feel for all the macOS and iOS developers out there that need to deal with this on a regular basis.

I don’t know if it’s just me, but I find all these online services that push you these A.I. driven “recommendations” of things to follow, watch, read, etc. really distasteful. I wish it was possible to turn some of these off. #mbnov

Why I'm Considering Building A Blogging CMS

I’m planning to start a new blog about Go development and one of the things that I’m currently torn on is how to host it. The choice look to be either using a service like blot.im or micro.blog or some other hosting service, using a static site generation tool like Hugo, or building my own CMS for it. I know that one of the things people tell you about blogging is that building your CMS is not worth your time: I myself even described it as “second cardinal sin of programming” on my first post to micro.blog.

Nevertheless, I think at this stage I will actually do just that. Despite the effort that comes from building a CMS I see some advantages in doing so:

  1. The (theoretical) ability to blog from anywhere: This is one of the weaknesses of static site hosting that I’ve run into when trying this approach before. I tend to work on different machines throughout the week, which generally means that when I find inspiration, I don’t have the source files on hand to work on them. The source files are kept in source control and are hosted on GitHub, but I’ve find that I tend to be quite lax with making sure I have the correct version checked out and that any committed changes are pushed. This is one of the reasons why I like micro.blog: having a service with a web interface that I can just log into, and that will have all the posts there, means that I can work on them as long as I have an internet connection.
  2. Full control over the appearance and workflow: Many of the other services provide the means for adjusting the appearance of the web-page, so this is only a minor reason for taking on this effort. But one thing that I would find useful is to have some control over is the blogging workflow itself. There are some ideas that I might like to include, like displaying summaries in the main page, or sharing review links for posts prior to publishing them. Being able to easily do that in a codebase that I’m familiar with would help.
  3. Good practice of my skills: As someone who tends to work on backend systems for his day-to-day job, some of my development and operational experience are a little rusty. Building, hosting and operating a site would provide an opportunity to exercise these muscles, and may also come in handy if I were to choose to build something for others to use (something that I’ve been contemplating for a while).

Note that price is not one of these reasons. In fact it might actually cost me a little more to put together a site like this. But I think the experience and control that I hope to get out of this endeavour might be worth it.

I am also aware of some of the risks of this approach. Here is how I plan to mitigate them:

  1. Security and stability: This is something that comes for free from a blogging platform that I’ll need to take on myself. There’s always a risk with putting a new system onto the internet, and having a web site with remote administration is an invitation for others to abuse it. To me this is another area of development I believe I need to work on. Although I don’t intend to store any personal information but my own, I do have to be mindful of the risks of putting anything online, and making sure that the appropriate mitigations are in place to prevent that. I’ll also have to make sure that I’m maintaining proper backups of the content, and periodically exercising them to make sure they work. The fact that my work is at stake is a good incentive to keep on top of this.
  2. Distractions: Yeah, this is a classic problem with me: I use something that I build, I find a small problem or something that can be improved, then instead of actually finishing the task, I actually work on the code for the service. This may have to be something that only gets addressed with discipline. It may help using the CMS on a machine that doesn’t have the source code.

I will also have to be aware of the amount of time I put into this. I actually started working on a CMS several months ago so I’m not starting completely from scratch, but I’ve learnt with too many other of my personal projects that maintaining something like this is for the long term. It might be fine to occasionally tinker with it, but I cannot spend too much effort working on the system at the expense of actually writing content.

So this is what I might do. I might give myself the rest of the month to do what I need to do to get it up to scratch, then I will start measuring how much time I spend working on it, vs. the amount of time I actually use it to write content. If the time I spend working on the code base is more than 50% of time I use it to write content, then it will indicate to me that it’s a distraction and I will abandon it for an alternative setup. To keep myself honest, I’ll post the outcomes of this on my micro blog (if I remember).

A few other minor points:

  • Will this delay publishing of the blog? No. The CMS is functionally complete but there are some rough edges that I’d like to smooth out. I hope to actually start publishing this new blog very shortly.
  • Will I be moving the hosting of this blog onto the new CMS? No, far from it. The services here works great for how I want to maintain this blog, and the community aspects are fantastic. The CMS also lacks the IndiWeb features that micro.blog offers and it may be some time before they get built.

I’ll be interested if anyone has any thoughts on this so feel free to reply to this post on micro.blog.

Update: I’ve posted a follow-up on this decision about a month after writing this.

I have to keep reminding myself, when I’m building personal software projects, the costs of adding dependence to external modules. It’s one of those balances that I struggle with, along with the perennial one of building something vs. using something off the shelf. #mbnov