February Photoblogging Challenge. Day 3: Comfort. POV shot of me sitting in a comfortable chair while holidaying in Phillip Island this week.

February Photoblogging Challenge. Day 2: Morning Beverage.

Micro.blog Photo Challenge. Day 1: “Close Up”. Not the best close up but any closer and they would have flown away.

Afternoon in the gardens just south of the Shrine Of Remembrance in Melbourne, taken yesterday.

Well, that’s a little terrifying. Turns out that coronavirus was mutating during Victoria’s second wave last year along similar lines to those variants we’re seeing now. Had it not gone extinct from the lock-down, this “Australian variant” could have been more infectious and possibly more resistant to vaccines.

I’m certainly glad the state government decided to go for zero community spread. As hard as the lock-downs were, I could imagine maintaining suppression of this variant would have been even more difficult, and would have just worn everyone down, not to mention all the additional sickness and death we would have experienced.

I gave Glitch a go for the first time today. I was sceptical that I would find any value in it, but it turns out to be a great environment for whipping up small apps really quickly. It only took a few hours to build a simple Finska Scorecard using Stimulus.

I just spent an hour and a half building what I thought was a simplified version of the R-Tree algorithm, until I came across a test case that completely breaks it. The lesson: don’t take shortcuts and just learn the well-known algorithm first.

In the summer months, if the outside air temperature gets warmer than 40°C, I treat myself to an ice latte as my afternoon beverage, in leau of a regular coffee. Well, it ticked over 40°C about half an hour ago, so…

I was having a discussion with people at work about the approval process of the Covid-19 vaccines here in Australia.

One person was raising questions as to why the Therapeutic Goods Administration, the agency responsible for approving drugs and treatments, was taking its time with approving the vaccine when a number of other countries have already started rolling it out (he had good enough reasons for asking).

There was a bit of a back and forth about the merits of speeding up the approval process vs. giving the TGA time to do a full approval, since the virus has been suppressed moderately successfully here.

The conversation ended about 10 minutes later with the approval of the Pfizer vaccine.

It looks like Twitter’s product design team need some help. Their recent ideas, “inspired” by the features of other companies like Snap (Stories) and Club House (Audio Clips), don’t seem to be setting the world on fire. Well, here’s an idea for them to pursue, free of charge.

A lot of people I follow seem to use Twitter threads for long-form writing. This might be intentional, or it might be because they had a fleeting thought that they developed on the spot. But the end result is a single piece of writing, quantised over a series of tweets, and assembled as a thread.

I’d argue that consuming long-form writing this way is suboptimal. It’s doable: I can read the thread as they’re currently presented in the Twitter app and website. But it would also be nice to read it as a single web page, complete with a link that can be used to reference the thread as a whole.

Now, I don’t see these writers changing their behaviour any time soon. It’s obvious that people see value in producing content this way, otherwise they would do something else. But it’s because of this value that Twitter should lean in to this user behaviour, and make it easier to consume these threads as blog posts. The way they should do this is:

• Offer the author the choice to publish the thread on a single web page, complete with a permalink URL that can be shared, once they have finished writing it. This could be on demand as they’re composing the thread, or it can be done automatically once the thread reaches a certain size.
• Provide the link to this web page on the first tweet of the thread. The reader can follow the link to consume the thread on a single page, or can use the link to reference the thread as a whole.

I know that this is possible now, with things like the Thread Reader app, but there are some benefits for Twitter adding first party support for this. The first being that it keeps user on their “property”, especially if they add this feature to the app as well as the Twitter website. This neutralises the concern of sending the author or reader to another site to consume or publish their content, thereby feeding into the second benefit, which is that it elevates Twitter as a platform for writing long-form writing, in addition to microblogging. If their content can be enjoyed in a nicer reading experience, more writers would use Twitter to write this form of content, keeping users and writers on Twitter. The user benefits, the publisher benefits, and Twitter benefits. Win-win-win all round.

So there you are, Twitter, the next feature for the product backlog. It could be that I’m the only that that wants this, but I personally see more value in this than their other pie-in-the-sky endeavours that Twitter is perusing.

One final thing: I’m a big proponent of the open web and owning your own content, so I don’t endorse this as a way to publish your work. I’m coming at this as a reader of those that choose to use Twitter this way. Just because they’re OK with Twitter owning their content this way doesn’t mean I should have a less-than-adequate reading experience.

Prior to joining Micro.blog, I had a journal in Day One, which was the sole destination for all my personal writing. I still have the journal, mainly for stuff that I keep to myself, but since starting the blog, I always wondered how I could get my posts in there as well. It would be nice to collect everything I’ve written in a single place. In fact, there was a time I was considering building something that used Day One’s email to entry feature, just so I could achieve this.

I’ve since discovered, after reading this blog post, that Day One actually has an IFTTT integration. This means that it’s possible to setup an applet that takes new entries from an RSS feed, and add them as entries into a Day One journal.

I decided to give this a go, and it was quite simple to set up. I’m using the blog’s RSS feed as the source, and a new “Blog Journal” as the destination new entries will be created in. Setting up the integration with Day One was straight forward, however I had to make sure that the encryption mechanism of the new journal was “Standard” instead of “End-to-end”. This is slightly less secure but everything in that journal is going to be public anyway, so I’m not too concerned about that.

The Day One integration allows you to select the journal, any tags, and how the content is to look. This follows something resembling a template and allows the use of placeholders to select elements of the post, like the title and the body. The integration also allows you to specify the location and entry image, although I left that blank. In fact, I ran into trouble trying to set the entry image when a post didn’t have one: journal entries were being created with a generic IFTTT 404 image instead.

So far it’s been working well. I’ve only being writing short posts without a title — this will be the first long post with a title — but they’ve been showing up in Day One without any issues. There are still some unknowns about this integration. For example, I don’t know how images will work. I would hope that even though they’re links that Day One will handle them properly if you wanted to do something like make a physical book. It’s likely I’ll need to make a few tweaks before this is perfect.

But all-in-all, I’m pleased with this setup. It’s nice seeing everything I write show up in a single place now. In fact, I’m wondering if there are other things this integration could be useful for, now that I know that all that needs doing is setting up an RSS feed.

It’s only just now that I realised I no longer need to brace myself whenever I see the headline “The President is tweeting”.

Published two tracks last night: Taxonomy and Hazard. Both of these were made during the depths of the Melbourne Lockdown 2.0, although they’re not about the pandemic. Also, this whole self-promotion thing is new to me so apologies if this post looks a bit weird.

It’s a little bit shocking, the minute you move to a position with a bit more leadership responsibility, how quickly your calendar fills with meeting requests.

That feeling you get when you see a class or struct that was defined in another library that you’re using; and you wish you could change it, but doing so will triple the time it takes to complete your task.

Working on an album cover for some music I’m hoping to publish soon. Who knew that one the skills required for publishing music online is graphic design?

Apart from a small cluster that’s been contained a week ago, there’ve been zero locally acquired cases of Covid-19 in Victoria. That means gyms have dropped the need to book in advanced. I kind of miss it though: being required to book forced me to actually commit to a session.

If you’re looking for a way to edit long-form articles, may I recommend this technique from C.G.P. Grey. I’ve using it a few times for another blog I’m maintaining and while I don’t use Editorial, I do export the articles as PDF and mark them up in GoodNotes with the Apple Pencil.

I’ve found this technique usually results in better posts. It’s probably because of the shift in mode and location: I go from producing the words on my desktop, to deleting or rearranging them by hand on my iPad in a different room. I’ve also found that it is a lot more enjoyable: I actually look forward to editing this way.

Some of these collaborative editing tools, like Google Docs or Atlassian Confluence, have a feature to allow reviewers to add comments to a document, maybe to ask the author a question or to make some changes. There’s usually an action to mark a comment as resolved, which will archive it. But I’m never sure who should be the one to resolve it: the reviewer or the author.

What I tend to do, when a reviewer leaves a comment on something I’m working on, is to make the corrections and then reply to the comment without actually resolving it. My thinking here is that this gives the reviewer an opportunity to acknowledge that they’ve seen the updates, and they indicate this by resolving the comment. This is how I work, but I know of other people that make the changes to the document, then immediately resolve the comment, with or without replying to it first.

What these comment systems need is a separate resolve action for both the author and reviewer. That way, the author can mark the comment as resolved once they believe they have addressed the reviewer’s concerns. Then, once the reviewer has had a chance to look at the changes, they can mark the comment as resolved if no further work is required. At any time, either person can post a reply, thereby keeping the comment open. Only once both parties resolve the comment does the comment get archived.

It’s strange that the IETF, one of the principal foundations responsible for maintaining the standards of the web, are still publishing these standards as if they were intended for a dot-matrix printer.

It’s funny how the casual meandering of your mind can be a source of inspiration. This morning, my mind casually turned to thinking about all the work that Mac developers need to do to get access to privileged APIs — like location, contacts, or the accessibility APIs. My experience of going through the motions to enable these permissions for the apps I use, along with hearing of the lengths developers go through to make this as seamless as they can, reveals to me the clunkiness that this entails. I could imaging this being a huge source of frustration for these developers, not to mention a huge source of support requests.

It’s laudable of Apple to lock-down access to these APIs: the days of assumed access to everything is over, and I believe we are better for it. But I believe it’s worth considering ways to streamline the process of granting these permissions, making it easier to work with them without any sacrifice to the user’s security or privacy.

I’m wondering if one such approach could be to do something similar to how permissions for web pages are managed. In most browsers, clicking on the pad-lock icon just left of the URL brings up a popup listing all the capabilities the website has access to, such as whether they can use the microphone, whether they can show notifications, etc. Within this popup, the user can grant or revoke these permissions, controlling which APIs the JavaScript on the website can use. The web-site itself cannot do anything with this pane: all that can be done is to provide instructions on how enable these permissions, and progressively enabling or disabling features based on whether those permissions are granted.

Maybe something similar would help for macOS apps. What I had pictured in my head is something similar to the following (no mock-ups, sorry; you’ll need to use your imagination):

• The app will disclosed in their Info.plist the privileged APIs that they need access to (they might do this already, I’m really not sure).
• A new “Permissions” menu item will be added by the OS to the application menu. This menu item is beyond the control of the app: it could not be automatically triggered or otherwise controlled.
• Clicking this menu item will bring up a window listing all the permissions that the app has disclosed. Beside each one is a toggle, allowing the user to turn them on and off at will. Like the menu item, this window is managed by the OS itself, not the application, and could require users to enter their admin passwords before enabling the permissions if necessary.

I can see this approach having some benefits to both users and developers. This will reduce the level of friction involved in dealing with permissions, making it easier for the user to enable, and most importantly disable, these permissions when needed. The app developer has an easier time asking the user to enable these permissions: no need to do things like open the Settings app and draw arrows on screen pointing to the accessibility pane. Since this is all managed by the OS, the various setting panes can still exists, but they become secondary avenues to controlling these permissions. Conceptually, the permissions belong to the app, which maintains the wholistic app paradigm that Apple is moving towards, not to mention eliminating the need for the user to context switch when they open the Settings app.

I’m not a Mac developer so I’m not sure how possible this is. I can’t imagine this approach would break any of the existing APIs of AppKit: this will all be stuff that Apple needs to do. I’d be interested in hearing what others think of this approach, so let me know your thoughts on this.

Feedbin, the RSS reader I use, has the ability to add Twitter users as feeds. It works pretty well and has some nice features, like including article linked in the tweet. One thing that they should add is the automatic unrolling of threads.

All these new Substack newsletters that I’m seeing reminds me of my first encounter with GitHub.

Back in 2009, I was checking out the source code of an open-source library we were using. Clicking on the link to the source bought me to this strange, new code-hosting service that I’ve never seen before. As someone who was use to the heaviness that was SourceForge, or the boring uniformity that was Google Code, the experience felt very minimal and slightly unintuitive. It took me a while, for instance, to realise that the version tags were selectable from a drop-down list. I also thought that it was quite restrictive to only offer checking out the source code with this weird SCM client called “git”. The whole experience left me thinking of this website as rather niche, and I never really expected to see it that often, given that Source Forge or Google Code reigned supreme at the time.

I held this believe for a year or two. Then, as I continued to deal with different open-source projects, I started noticing more and more of them showing up on this weird new service. This was infrequent at first: maybe around one in ten projects or so. But the ratio was starting to shift faster and faster, soon becoming one in eight projects, then one in five. Around this time, GitHub was starting to gain momentum in the technological zeitgeist: projects announced that they were moving off SourceForge and migrating their codebase to GitHub. Then, Google Code announce that they were shutting down, and that they were migrating projects over to GitHub. Eventually, a tipping point was reached, and GitHub was the code hosting service for pretty much every project I encountered.

My experience with Substack was similar, except on a much shorter timescale. I remember subscribing to my first Substack newsletter back in 2019. I was already a Stratechy subscriber so the whole email-newsletter thing was familiar to me. But it was another case of being a little unimpressed with the Substack experience — difficult to read on-line, impossible to get it as RSS, weird font choices, etc. — that I was expecting the platform to remain relatively niche. Contrast that to today, where every forth or fifth link I see is to a Substack newsletter, and not a month goes by where a new Substack publication is announced.

There’s no real lesson to this (or if there is, I’m too dense to see it). Just the amusing observation of first encountering something that, to you, seems rather niche and unusual until one day, faster than you can blink, it is the only thing anyone uses.

My understanding is that in Australia the “official” start of the week is Monday, but the iOS internationalisation settings for Australia has it configured to be Sunday. This is a small thing in the grand scheme of things, but I’m feeling some real dissonance over this.

One thing that needs to be clearly disclosed when signing up to anything — be it software, an energy company, or a newspaper — is what they try to do when you wish to close your account. This really needs to be in plain writing and not buried away in the Terms Of Service.

I’m experiencing this now after recently switching my energy provider. Even after the account is closed, they are sending me messages about the special offers I can have, if only I switched back to them.