Long Form Posts

    Weekend In Mansfield

    Over the weekend, I had the opportunity to spend some time with my parents who were staying in Mansfield, in regional Victoria. We were staying in a small cottage located on a hill, which meant some pretty stunning views, especially in the evening light.

    The cottage in the late evening light View from the balcony

    We didn’t do a heap during our trip, although we did manage to do the The Paps trail on Saturday, which involved a 700 metre climb.

    Annotated image of The Paps

    (Apologies for the photo, I had another one that was zoomed in a bit more but the photo turned out quite muddy. Might need to consider another phone or camera.)

    It was a bit of a challenge ā€” the trail was quite steep at times ā€” and there were a few instances when we considered turning back. But we did eventually reached the summit, and got some spectacular views of Lake Eldon, which was quite full thanks to all the rainfall we got over the last few months.

    One the path Approaching the summit View of the lake Another view of the lake View up the highway towards Bonni Doon The summit

    This was followed by a pub lunch at the Bonni Doon Hotel. The place was chokers, probably with people eager to get out of the city at the end of lockdown (likewise for the cottage we stayed at, which has been booked solid for the next couple of months). But the food (and beer) was good and it was perfect weather to be dining outside, with the sun shining and temperature in the low 20’s Celsius.

    All in all it was good to get out of the city, and out of my weekend routine, for a spell.

    Cookie Disclosure Popups Should be Handled by the Browser

    I really dislike the cookie disclosure popups that appear on websites. Ideally I shouldn’t be seeing them at all ā€” I know that the EU requires it, but I’m not a citizen of the EU so the regulation should not apply to me. But I’m pragmatic enough to know that not every web developer can or will selectively show this disclosure popup based on the geographic region of the visitor.

    That’s why I’m wondering if these disclosure popups would be better handled by the browser.

    The way I see this working is that when a website tries to set a cookie, either through a response header or within JavaScript, and the user is located in a jurisdiction that requires them to be aware of this, the browser would be responsible for telling them. They could show it as a permission request popup, much like the ones you see already when the site wants to use your microphone or get your location. The user can then choose to “accept”, in which case the cookie would be saved; or they can choose to “deny”, in which case the cookie would be silently dropped or an error will be returned.

    This has some major advantages over the system we have now:

    • It would save the website dev from building the disclosure popup themselves. I’ve seen some real creative ways in which websites show this disclosure, but honestly it would just be simpler not to do it. It would also cover those web developers that forget (or “forget”) to disclose the presence of cookies when they need to.
    • The website does not need to know where the user is browsing from. Privacy issues aside, it’s just a hassle to lookup the jurisdiction of the originator based on their IP address. Which is probably why no-one does it, and why even non-EU citizens see these disclosure popups. This is not a problem for the browser, which I’d imagine would have the necessary OS privileges to get the users’ current location. This would be especially true for browsers bundled with the OS like Safari and Edge.
    • When the user chooses an option, their choice can be remembered. The irony of this whole thing is that I rarely see websites use cookies to save the my preferences for allowing cookies. These sites seem to just show the popup again the next time I visit. Of course for a user chooses to deny the use of cookies, it wouldn’t be possible for the site to use cookies to record this fact. If the browser is managing this preference, it can be saved alongside all the other site permissions like microphone access, thereby sitting outside what the site can make use of.
    • Most important of all to me: those outside the jurisdiction don’t even need to see the disclosure popup. Websites that I visit could simply save cookies as they have been for 25 years now. This can be an option in the browser, so that users that prefer to see the disclosure prompt can do so. This option could come in handy for those EU citizens that prefer to just allow (or deny) cookies across the board, so they don’t have to see the disclosure popup either (I don’t know if this is possible in the regulation).

    Of course the actual details of this would need to be ironed out, like how a website would know whether the user has denied cookie storage. That’s something for standards committee to work out. But it seems to me that this feature is a no-brainer.

    My Impressions of GitHub Codespaces

    The GitHub Universe 2021 conference started a few days ago and one of the features touted in the day one keynote was GitHub Codespaces. This is a development environment that is accessible from within your web browser. Itā€™s based on VSCode, which is a popular and well-designed IDE that is already written in JavaScript1, and also provides access to a Linux shell running in the cloud, allowing you to do various things like build and test your code.

    After playing around with Codespaces during the beta, and seeing the feature develop into something that is available for everyone, I’d thought I’d say a few words on how I use it and what I think of it.

    First, I should probably say that I’m not a heavy Codespaces user. The keynote seemed to be touting the features of Codespaces that makes it useful as a dev environment for collaborative coding. This is something I have no personal use for since it’s mainly just me working on repos I use with Codespaces, so I haven’t really explored these features myself.

    The main use I have for Codespaces is making changes to repos on a machine that is not my own. There are times when I need to add a new feature or fix a bug on a tool I use, and for various reasons I cannot (or choose not to) setup a dev environment on the machine I’m working on to make the change. A case like this would have me look at one of the alternatives, or even make use of the GitHub web-editor. The web-editor works but doesn’t really offer much when it comes to building and testing your changes (I’ll talk more about the alternatives later).

    I should say that this doesn’t happen very often. Most of my time I’m on my own machine, and I have no need for a web-based dev environment as I can just use the environment I have. But when that’s not possible, being able to spin up and make the change in Codespaces, complete with a Linux environment which you have sudo access to, is quite useful.

    Codespaces is also pretty nice in terms of a coding environment. This is no real surprise since itā€™s based on VSCode, but compared to the alternatives, the little things like keystroke performance and doing things quickly in the editor make a huge difference. Iā€™ve tried a bunch of alternatives in the past like Cloud9 and CodeAnywhere, and Codespaces is by far the most polished.

    Another advantage Codespaces have over the comparison is that it seems suited to throw-away development environments. It might be possible to keep an environment around for an extended period of time, but I tend to spin up temporary workspace when I need them. The alternatives tend to prefer a more long-lived environment, which involves a lot setup for something that is kept around. This feels like splitting your dev environments in two, and I always feel the need to select one as the “definitive workspace” for that particular project going forward. I don’t feel that with Codespaces: I can quickly spin up a new environment, which has most of what I need already installed, and make the change I need with the full knowledge that once I no longer need it, it will be teared down (pro-tip: always push your changes to origin once you’re done making your changes in Codespaces). It helps that spinning up a new environment is quite fast.

    So, that’s my impression of GitHub Codespaces. I’m not sure who has access to it: you may need to be on a paid plan, for example. But if it’s enable for your account, and you find yourself needing a temporary, cloud-based dev environment to do your work in, I’d suggest giving it a try.


    1. Itā€™s actually TypeScript ↩︎

    Two People

    There are two people, and each one has the same problem that they want to get solved.

    The first person chooses the option to pay $10 a month, and all they have to do is sign up to a service that will solve the problem for them. The service they sign up for takes care of the rest.

    The second person chooses the option to pay $15 a month, 20 hours of work to get something built, and an ongoing commitment to keep it maintained.

    Guess which person I am today.

    (Hyper)critical Acclaim

    There were a couple of events that led me to writing this post. I’m sure part of it was seeing the posts on the 10 year anniversary of Steve Jobs, although such an event would probably not have been sufficient in itself. What tipped it over the edge was seeing the Ars Technica review of iOS showing up in my RSS feed on the same day. Pretty soon I’m expecting the MacOS review to drop as well.

    The quality of the reviews are still quite good, and I try to read them when I have the time. But sadly they do not grab me the way the Siracusa reviews did.

    It’s usually around this time of year I would start expecting them, waiting for the featured article to show up on Ars’ homepage. Once they came out, I would read them from cover to cover. I wouldn’t rush it either, taking my time with them over a period of about a week, reading them slowly and methodically as one would sip a nice glass of wine.

    Thinking back on them now, what grabbed me about these pieces was the level of detail. It was clear from the writing that a lot of effort was put into them: every pixel of the new OS was looked at methodically with a fine eye to detail. This level of study made to the design of the OS release, trying to find the underlying theme running through the decisions made, was something that was not found in any of the other OS reviews on Ars or any other tech site. I’m sure it was in no small part the reason why I eventually move to Apple for my computing needs.

    Eventually, the Siracusa reviews stopped. But by then I was well down the rabbit hole of Apple tech-nerd podcasts like the Talk Show and ATP. Now a regular listener to these shows, I still enjoy getting my fix of software technologies critical review, albeit in audio form. I eventually discovered the Hypercitical podcast, well after it finished, and I still occasionally listen to old episodes when there’s nothing new.

    Incidentally, there is one episode that I haven’t listen to yet. Episode 37, recorded on 8th October 2021, just after the death of Steve Jobs. Here, on the 10 year anniversary of his death, it might be a good time to have a listen.

    On Choosing the Hard Way Forward

    This is about work, so the usual disclaimers about opinions being my own, etc. apply here.

    I have an interesting problem in front of me at the moment: I’ve need to come up with a way to be notified when a user connects to, or disconnects from, a PostgreSQL database. This is not something that’s supported by PostgreSQL out of the box1, so my options are limited to building something that sits outside the database. I can think of two ways that I can do this: have something that sits in front of the database which acts as a proxy, or have something that sits behind the database and generates the notifications by parsing the server log.

    A database proxy is probably the better option in the long run. Not only will it allow us to know exactly when a user connects or disconnects ā€” since they will be connecting to the proxy itself ā€” it could potentially allow us to do a few other things that have been discussed, such as IP address whitelisting. It might be a fair bit of work to do, and would require us to know the PostgreSQL wire protocol, but given how widespread PostgreSQL is, I’m suspecting that this could be done once and not need many changes going forward.

    Despite these advantages, I find myself considering the log parsing approach as the recommended solution. It’s probably a more fragile solution ā€” unlike the wire protocol, there’s nothing stopping the PostgresSQL devs from changing a log message whenever they like ā€” and it would not allow us to do all the other stuff that we’d like it to do. But it will be faster to build, and would involve less “hard programming” than the alternative. It can be knocked out quite quickly with a couple of regular expressions.

    Weighing the two options, I find myself wondering why I’m preferring the latter. Why go for the quick and easy solution when the alternative, despite requiring more work, would give us the greatest level of flexibility? It’s not like we couldn’t do it: I’m pretty confident anyone on the team would be able to put this proxy service together. It’s not even like my employer is requiring one particular solution over another (they haven’t yet received any of the suggestions I’m planning to propose, so they haven’t given a preference one way or the other). So what’s giving me pause from recommending it?

    No decision is completely made in a vacuum, and this is especially true in the mind of the decider. There are forces that sit outside the immediate problem that weigh on the decision itself: personal experience mixed with the prevailing zeitgeist of the industry expressed as opinions of “best practice”. Getting something that works out quickly vs. taking the time to build something more correct; a sense that taking on something this large would also result in a fair amount of support and maintenance (at the very least, we would need to be aware of changes in the wire protocol); and just a sense that going for the proxy option would mean we’re building something this is “not part of our core business”.

    Ah, yes, the old “core business” argument. I get the sense that a lot of people treat this one as a binary decision: either it’s something that we as a business does, or it’s not. But I wonder if it’s more of a continuum. After all, if we need to block users based on their IP address, is it not in our interest that we have something that does this? At what point does the lost opportunity of not having this outweigh the cost of taking on the development work now to build it? If we build the easy thing now, and later on we find ourselves needing the thing we don’t have, would we regret it?

    This is a bit of a rambling post, but I guess I’m a little conflicted about the prevailing approach within the tech industry of building less. It’s even said that part of the job is not only know what to build, but when NOT to build. I imagine no-one wants to go to the bad old days where everyone and their dog was building their own proprietary database from scratch. I definitely don’t want that either, but I sometimes wonder whether we’ve overcorrected in the other direction somewhat.


    1. I didn’t look at whether this is doable with hooks or extensions. ↩︎

    Some Notes About the Covid-19 Situation

    Now that the vaccines are here and are (slowly) being rolled out, and that Covid zero is no longer achievable in any realistic sense, the pandemic seems to be taking on a bit of a different vibe at the moment. I am no longer religiously watching the daily press conferences as I did in the past. Theyā€™re still occurring as far as I know, and I do appreciate that the authorities are showing up every day once again to brief the public.

    But Iā€™m starting to get the sense that people are generally loosing interest in it now. Well, maybe ā€œloosing interestā€ is the wrong way to say it. Itā€™s not like itā€™s something that could be ignored: if you donā€™t get affected yourself, youā€™re still bound by the current restrictions in some way. Maybe itā€™s more like itā€™s starting to slip into the background somewhat.

    Slowly the weā€™re-all-in-this-together collectivism is morphing into one of personal responsibility. Except for the need to keep the medical systems from being overwhelmed, itā€™s now up to the individual to take care of themselves, whether itā€™s by masking up and social distancing, or by getting vaccinated. Everyone that I love has done just this: theyā€™re got their shots when they could and are generally being very careful. But there are people out there that are not. Even some of my friends parents are hesitant to get the vaccine, either waiting for Pfizer (theyā€™ll be waiting a while) or just being suspect of the vaccine at all.

    I also think that the success of the lockdowns before the delta variant has lulled people into a sense of security that is no longer present anymore. The latest lockdown has largely failed, and now itā€™s immunity from the vaccines that will have to protect us. I hope these people that are not taking this seriously realise that the protection that comes from collective actions will no longer be around when the virus comes for them.

    On Confluence

    I’m sorry. I know the saying about someone complaining about their tools. But this has been brewing for a little while and I need to get it off my chest.

    It’s becoming a huge pain using Atlassian Confluence WISIWIG editor to create wiki pages. Trying to use Confluence to write out something that is non-trivial, with tables and diagrams, so that it is clear to everyone in the team (including yourself) is so annoying to do now I find myself wishing for alternatives. It seems like the editor is actively resisting you in your efforts to get something down on paper.

    For one thing, there’s no way to type something that begins with [ or {. Doing so will switch modes for adding links or macros. This actively breaks my train of thought. The rude surprise that comes from this shunts me out of my current thought to one that tries to remember the proper way to back out of this unwanted mode change, which is not easy to do. There’s no easy way to get out of the new mode, and simply leave the brace as you typed it. It seems to be that the only way to disable this is to turn off all auto-formatting. I never need to create new macros by typing them out, but I do use h3. to create a new headings and * to bold text all the time. In order to actually type out an opening brace, I have to turn these niceties off.

    The second issue is that it’s soooo sloooow. For a large page, characters take around a second to appear on the screen after being typed. This does not help when you’re trying to get your thoughts down on the page as quickly as they come to you. You find yourself pausing and waiting for the words to catch up, which just slows your thinking down. And I won’t mention the number of errors that show up because of this (to be fair, I’m not the best typer in the world, but I find myself typing out fewer errors in an editor with faster feedback than the one that Confluence uses).

    I appreciate the thinking behind moving from a plain text editor to a WISIWIG one: it does make it more approachable to users not comfortable working with a markup language (although I also believe this is something that could be learnt, and that these users will eventually get comfortable with it and appreciate the speed at which they could type things out). It’s just a shame that there’s no alternative to those who need an interface that is fast and will just get out of the way.

    On Apple's Media Release Gymnastics

    I started listening to the latest Talk Show, where John Gruber and MG Siegler discuss Apple’s media release of the class action settlement. Releasing it to the major media outlets in such a way as to spin the guideline clarification as a concession to developers, even though nothing has actually change, is genius if true. I imagine that’s why Apple’s PR department get the big bucks.

    But I wonder if Apple has considered the potential blowback of this approach. I might be naive here, but I can’t help wonder whether these media outlets publishing that Apple hasn’t actually conceded anything will eventually realised that they have been had. Would that affect the relationship between the two in any way? Say Apple wants to publish some good news and expect these outlets to maintain the favourable air of their release. Would they do it?

    Then again, it’s most likely that nothing will really change. There’s little trust lost between the two anyway, and if this gymnastics actually happened, Apple knows it. Also, it sounds like Apple’s media release has had the desired effect of reaching those in the US government applying anti-trust pressure on the company. They probably think it’s worth the credibility they have burned with these outlets, if any1.

    One thing that seems clear though: this is doing no favours in addressing the trust lost between Apple and their developers, no matter how much clarifying this release does.


    1. I realise that I’m probably so far removed from how much the general zeitgeist knows or cares about the relationship between Apple and their developers, so even expecting that these outlets know that they have been had is a huge assumption. ↩︎

    Post Of Little Consequence

    I’m wouldn’t call myself a regular poster on this blog. I don’t have a goal of writing a post a day or something. But I do want to keep it up with some frequency, and post at least one item a week. I realised today that it’s been a week since my last post.

    However, due to the current lockdown, very little of note has happened over the last week. Apart from work, TV, reading, and doing a few personal projects on the side, there really isn’t much going on. So it was hard to come up with something that was interesting to write about.

    So I’m playing my post-about-how-difficult-it-is-to-post post, which is what you are reading now. In short: there’s nothing spectacular that’s going on at the moment.

    That said, I did start three drafts that I thought about publishing. It felt a little strange posting them individually, so here they are as bullet points:

    • I’m completely recovered from the side effects of the vaccine now. I did have a sore arm for about a week, and actually saw to the doctor about it, but he said that it took him about a week to get over it as well, so nothing to worry about here. Incidentally, this was a day after seeing the same doctor about renewing a prescription, making it the first time in my life I went to the doctors two days in a row, which I guess is something. Now just need to wait 11 more weeks for my next dose.
    • I’ve got a research task at work today, meaning no podcast listening at work today.
    • Related, I find it relatively easy to listen to music and podcasts at the same time I’m writing code, but as soon as I need to write prose (documentation, copy, or writing a blog post), I have to turn the music off. I guess my mind needs complete focus when writing English sentences, probably because it’s an area that has been underdeveloped somewhat.

    Anyway, that’s what’s happing at the moment. Hope I didn’t waste too much of your time šŸ™‚

    Six Weeks Off Twitter

    Itā€™s been roughly six weeks since Iā€™ve stopped using Twitter on a daily basis. I initially took a break to stay away from some anxiety inducing news, and I was initially going to return to daily use once that passed. But after hearing others on Micro.blog post about their experience closing their Twitter account, I decided to see how long I can go staying off Twitter myself.

    I wouldnā€™t say that I am a big Twitter user. I donā€™t have a Twitter audience (I think my follower count is in the single digits), I hardly ever tweet or reply, and although I have a few friends and family on there, I have other means of communicating with them that I tend to use more often. The only thing I would miss are the occasional interesting or amusing tweets from those that I follow, something that is not guaranteed in any particular reading session.

    In those six weeks, I notice my reading patterns have change. Iā€™m reading a lot more books and blog posts now. I found that having something to read during the time youā€™re usually browsing Twitter helps a great deal, so thereā€™s always some long form written piece that I can turn to when Iā€™ve caught up with everything else. And although I wouldnā€™t say my anxiety has gone, I do think that itā€™s lower than it was. Itā€™s calming to know that there are no shocking/depressing items that can jump out of me during a particular reading session. I think that mechanic has a lot to do with the addictiveness of Twitter and itā€™s ilk.

    Iā€™m not quite at the point where I will completely close my Twitter account, and there are some users that I may move over to Feedbin (I havenā€™t done that yet, so Iā€™m not sure how interested in them I really am). But, all in all, I think this break from daily use of Twitter has been good for me, and I found myself having no real urge to going back.

    Seeking Out Bad News

    Sometimes I wonder if Iā€™m just going out of the way to seek bad news. Maybe itā€™s because I think that if I donā€™t, then a problem will go unaddressed as no-one else is aware of it.

    Thereā€™s probably some evolutionary trait to this. Being the one that hears a predator, and reacts to it before anyone else, is an advantage. But in this day and age, many of the problems that I have anxiety about is pretty much known by everyone, and addressing it in any meaningful way is beyond my direct control.

    So in the interest for my own mental health, I should cut down on seeking out these stories, do what I can to help with the problem, and just hope that someone who does have the ability to do something substantial knows about it, and can address it in some way.

    While total ignorance is probably not ideal, being up to speed with the woes of the world is probably not healthy either.

    A Year On Micro.blog

    It’s been a year since I’ve signed up to Micro.blog and written my first post, and the only regret I have is that I didn’t do it sooner.

    The reason for joining was to write more; to focus less on the blogging engine and more on the blog itself. At the time I have only posted seven times over a period of 9 months. In the last year, that post count has risen to 222. I guess I can call that objective achieved.

    But the biggest reason for staying, and one I wish I knew sooner, is the fantastic community here. Having such a great bunch of people online is quite rare now, and this has quickly been my favourite place on the internet. We truly have something special here.

    Thank you all for being such awesome people.

    Working On The Weekend

    Iā€™ve saw a Tweets last night saying that the best thing a young person can do to help their career is to work on the weekend. The implication there is that being the one that ā€œputs in the extra hoursā€ can seem, in the eyes of your employer, like youā€™re the hardest worker there, that youā€™re committed to the project and the job. This could lead to bonuses, promotions, perks, a reputation, you name it.

    Iā€™m always sceptical when I see advice like that. Coming in on the weekend on a voluntary bases might be good for your career, but is it actually good for you? Are you doing yourself any favours spending two additional days a week creating value for someone else?

    What about the things that will create value for you? That can help you be a more rounded person? Things like learning a new skill, starting a new side project, socialising, taking up a hobby. When will you have time for that? Not to mention just fricken resting, which is really not as valued as it should be.

    My feeling is that you already work for someone else 5 out of 7 days a week. By all means work on the weekend if you want to, but make sure youā€™re doing it for yourself.

    Stumbling Into the Concept of Narrating Your Work

    About a week ago, we had a retro. One of the things that was brought up was the sense that management felt that the team was not delivering as much as we could be. There are a number of reasons for this. For one, the higher ups work in Perth, a good 3,452 KM away from Melbourne. Another was that a lot of the work the team deals with is experimental in nature: more R&D vs. product development (a large portion of it involves dealing with a lot of barely supported, and completely undocumented APIs for MacOS).

    Nevertheless, it was a bit of a downer that management felt this way. A solution proposed by a team member was to maintain a work log. Doing so would give the product owner, who works in Perth, the ammunition needed to push back on the notion that the team was just sitting on their hands. Prior to the pandemic, I started keeping a bullet journal, which helped me keep on top of things that I needed to do. But this would been different: it would essentially be keeping a log of what I did, and how I did it.

    Last week I started to do this. I took a silly little web-app that I built for maintaining a “now” page (which I never used), and started to use it a bit more like a journal. I added it as a web panel in Vivaldi so that I could open it whenever I was in the browser. Every so often while I’m working on a task, I would quickly jot down a paragraph of what I just did. If I got stuck, I would write down what the problem is and my thoughts on how I can get out of it. I originally thought about setting up a reminder to do this like once every 30 minutes, but I found that simply journalling the thoughts as they come work quote well. At the end of the day I usually had at-least 3 bullet points on what I was working on (the record was 12) and at the beginning of the next day, I cut-and-pasted these bullet points into the Jira work log.

    It’s too early to say whether this would help dispel the notion that the team is not delivering; we may get an update from the product owner when the next retro comes around. But I’ve found the process actually quite useful for myself. I’ve forgotten how beneficial it is to write my thoughts down as they come, and I’ve never used a process like this before: everything up to date has been simply todo items or scrawls of the next task to look at.

    I learnt this morning that this is not a new concept. Dave Winer wrote a blog post about this in 2009, called Narrate Your Work which talks about how he adopted this practice at UserLand. I guess the same thing could be helpful here. After all, you could probably say the place I work at is distributed in nature, given that there exist a whole continent between the two offices.

    It’s only been a week so the habit has not fully settled in but I hope to continue to do this.

    On the Souring Relationship Between Apple and its Developers

    Listening to episode #430 of ATP yesterday, it was kind of shocking to hear the loss of good will experienced by the hosts towards Apple and their developer relations. I canā€™t say that I blame them though. Although Johnā€™s point about lawyers making the case for Apple is a good one, I do get the same feeling that Marco does about Apples opinion about developers, which is not a positive one.

    It feels a lot like Apple believes that developers building on their platform owe them everything to them, and that without Apple none of these businesses would exist at all. It does feel a lot like they are entitled to a cut of everything that is happening on their platform. It does feel a lot like they think a developer releasing their app for free on the App Store is an ungrateful free-loader, that is taking advantage of all their hard work building the platforms and developer toolkits. This is not just from whatā€™s coming up during the Epic-Apple lawsuit discovery. Remember what happened to Basecamp last year, when tried to release a new version of their Hey iOS app.

    None of these is accurate in the remotest sense. Although it is true that some of these business may not be around if iOS was ever invented, itā€™s not to say that these developers wouldnā€™t be doing something else. Also, these developers DO pay for the privilege to build on their platform. Letā€™s not forget the $99.00 USD ($149.00 AUD) that these developers pay yearly, not to mention all the hardware they buy to run XCode and these other tools. And itā€™s not like any of these tools wouldnā€™t exist at all if these devs were free to use another IAP provider. Apple, I assume, would like something like XCode to exist so that they can build their own apps.

    I hope people in Apple are listening to this. Anti-trust regulation aside, they are doing themselves a massive disservice by treating their developers like this. These people are their biggest evangelists. Iā€™m not sure it will come to the point where they will abandon the iOS platform, at least not at this stage. But I could foresee these developers being hesitant to adopt any new app platforms that Apple release, say a future AR platform that will feature hardware devices.

    Podcast Roll 2021

    Yesterday, @Munish had the courage to share his podcast subscriptions1. Sensing an opportunity to talk about with what I’m currently listening to, even though it may reveal more about myself that I’m usually comfortable with, I’m taking up his dare and sharing mine.

    So, here is my podcast roll as of early May 2021:

    Podcast subscriptions 2021

    The shows above can roughly be divided up into the following categories:

    Technology: This is a topic that I’m very interested in so there are fair few of these. A lot of them are Apple centric, but this is more of an accident than by design. The second podcast that I started regularly listening to was The Talk Show since I was a casual reader of Daring Fireball at the time (and I still am). That opened me up to ATP, which led to a bunch of Relay.fm shows.

    Business: These could probably be lumped into technology, but are focused more on the business side of things rather than product development. Ben Thompson shows up a lot here, with Exponent, Dithering, and the Stratechery daily update my regular gotos. The release of that last one helped set some new routines while I was working from home last year. There’s a decent collection of shows from indy developers here as well.

    Science, History, and Philosophy: These are where the real heavy podcast listening comes in, the shows that are 2 to 4 hours long and go deep into a particular topic or event. I have to be in the right kind of mood for these one. Key drivers here are Making Sense, Mindscape and Hardcore History.

    Politics and Society: I am somewhat interested in US politics, which could explain the shows that appear in this category. Deep State Radio is one that I still listen to occasionally. Also of note is the NPR Planet Money podcast, which was the first podcast that I’ve ever subscribed to. A recent addition is the ABC Coronacast which provides a decent briefing of the coronavirus pandemic in Australia.

    Popular Culture: This is probably where all the Incomparable shows come in, when I’m in the mood for something lighthearted and funny. My usual goto’s there are the Incomparable Game Show, Robot or Not and Pants in the Boot. One or two Relay.fm shows fall in here as well, including Reconcilable Differences, which is a favourite of mine.

    Micro.blog: The final category is more-or-less podcasts that I’ve subscribed to while spending time on Micro.blog. This includes shows like the Micro Monday podcast, but also shows from those on Micro.blog like Core Intuition and Hemispheric Views.

    So that’s it. There are a fair few subscriptions listed above, not all of them I regularly listen to. I guess I should probably unsubscribe from those that I haven’t listen to for a while. I probably keep them around for the same reason why I keep RSS feeds around: just in case something worth listening to pops up in there.


    1. Or “follows”, which is I guess the new term for it. ↩︎

    On Basecamp

    I’ve been thinking about the incident at Basecamp for most of the week. I wanted to write something about it earlier, after hearing about the policy changes on Tuesday, but I’d figure that it would probably be best to wait a bit and learn more about the issue first. The last thing I wanted to do is add one more knee-jerk reaction to the mix during the heat of the moment.

    But it is something that I want to comment on. I’ve only recently started following the writing of DHH and Jason Fried but I am aware of their reputation in both their approach to business and their dealings in the open-source community. To hear of a scandal form a business founded by these two took me aback. That’s probably why I’m writing this post at all. Hearing news like this from companies as large as Facebook or Google, with tens of thousands of employees, doesn’t surprise me as much as something arising from a company of about sixty people.

    The thing about being on the outside looking in is that you have an imperfect picture of the whole incident. And even after reading the open letter, the report from Casey Newton, and the response from DHH, it’s still not the full picture, as you cannot be inside the head of those involved. You can only work with what you read, and how it shapes your view of the principal actors that lives inside your head. This, along with the current environment that this event occurred in, makes it difficult for me to comment on the matter.

    But I do see a few things that are regrettable. It’s regrettable that such a thing like the Best Customer Names list exists. Far be it from me to be above making light of those that I deal with on a day-to-day basis, that such a list exited seemed like a step too far, particularly when it deals with those that you are being paid to serve. I can understand if this was a small startup with a handful of employees working hard to get it off the ground, and there was a need to vent. But for a company of sixty, especially one that thinks highly about how they operate they write blog posts about, it strikes me as unprofessional, and it does them no credit.

    It’s also regrettable that this matter could not be have been dealt with internally.
    One thing that struck me was how long the build up to this policy change was. It did not happen overnight; clearly something was brewing in Basecamp for a little while. And although I recognise that there were attempts to settle the matter internally, with the list removed and an apology from the founders, I also recognise that we are dealing with people with very strong personalities that are not afraid to air their opinions. So I wonder whether or not it could have remained an internal matter at all. Nevertheless, it’s in the public now, with the associated backlash and loss of credibility.

    Which brings me to the third regrettable thing, which is the ban on political discussion. In the abstract, this is not something that I personally support; a company does not operate in a vacuum after all. Maybe for a company like Basecamp it could act as bit of a circuit breaker if deployed for a little while; I get the sense that the founders thought similar. But it is a shame that it got to that level, and I do hope that they reverse it once things settle down. I think it’s good of Basecamp to offer severance packages to those employees that disagree with this measure, and wish to find work elsewhere. That indicates that they are willing to back their employees decision to leave, rather than leave their employees with a bit of a Sophies’s choice situation.

    So, what will I be doing going forward? I’ll probably continue to read posts from Jayson and DHH, and continue to use their open-source frameworks.
    I’m not a paying customer of Basecamp, although I do use their free offering, and I’m planning to continue doing so. Of course, I can understand if others choose a different course of action. Although I’m not a fan of making decisions in the heat of the moment, I can understand and respect the decisions made now, given that more on the incident has surface. I will be interested in seeing how Basecamp operates going forward. An event like this could have a lasting impact on a company, it’s founders, and it’s employees, and it would be interesting in seeing how to move on from it.

    Some thoughts on Apple Subscription Podcasts offering

    Youā€™ve probably seen the blog post outlining the details of Appleā€™s new Podcast Subscription offering. The latest post from Daring Fireball has a link to it if you havenā€™t seen it on Twitter already.

    After reading this, Iā€™m not sure who would choose to go with Appleā€™s Podcast hosting. Money aside, it looks like another case of Apple mediating the relationship between host and listener, not to mention keeping subscriber content exclusively on Appleā€™s app.

    The easy money doesnā€™t sound like itā€™s worth the cost of independence that comes from publishing shows on the existing open podcast ecosystem. Sure it would be harder ā€” youā€™ll have to build your audience yourself, and it will likely take some time before you can get sponsors or a membership program ā€” but the benefits that come from independence sound to me like it would be worth it. And once you have the audience, the support will follow: just look at Dithering, ATP, and Relay.

    I hope podcasterā€™s realise this. Thereā€™s a good thing here: podcasters connecting directly to listeners via the open web. I donā€™t want one more large company coming in to wreck that.

    Surmounting The Hill

    Sometimes adding features to software is like cycling on a hilly road.

    You start off at the bottom of the hill, a little unsure of the hight and gradient, and how well you’ll be able to tackle it. You start the uphill climb, writing new code, adding tests, trying an approach that may not work, backtracking and starting again. This uphill climb is starting to tire you out. You’re making forward progress, even thought it may not feel like it, but it’s slow and you’re not sure how much longer you can keep cycling for.

    Eventually, you reach the top: you have a solution that does what it needs to do with decent test coverage, but it’s ugly as sin. There’s an approach there that works, but it’s hidden underneath all the attempts that didn’t. You’re tired, but you’ve got a sense of accomplishment.

    Now the downhill coast begins. You begin hacking and slashing, deleting code that you no longer need, and generally simplifying the solution, every time running tests to make sure you haven’t removed too much. Travelling further along the road gets easier with each file deleted and each model refactored, until you have something that actually looks good. Eventually you level out, and you’ll need to start peddling again, as you tidy up and add documentation in preparation for the pull request.

    The feature is built, the hill is behind you, and you are further along the road, ready to tackle the next hill.

ā† Newer Posts Older Posts ā†’