With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.

Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.

Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.

I stumbled across “On git and cognitive load” and it got me thinking. That post led me to “Oh shit, git!?!” and that got me thinking further.

But first, a disclaimer: this is a post more about having perspective than providing answers. If I knew a better way, I’d be doing it.

The first blog argues that git is difficult to use. Further, that it was designed with the limitations of the time and that those limitations are no longer valid constraints. A decentralised system was required when poor network connections were the norm. Now we have cloud providers and ridiculous amounts of bandwidth.

I confess that I’ve stolen the title of the post from elsewhere. My objective here is not to detract from that post, which is great, but to build on a few points that I thought it was going to make but didn’t. To make it clear where I’m coming from, here’s a Tweet that I wrote some time before I read that blog:

People who complain that “enterprise” software is too expensive have clearly never come across the bizarre, arbitrary and nonsensical policies and rules these companies have. It’s not unusual to have two customers with contradictory policies.

The problem with “agile development” is that it is both a methodology and a buzzword. What this means in practice is that people who do not understand it implement parts of it without appreciating the whole. This usually results in more overhead but without the benefits.

I’ve come across this multiple times in my career. The usual refrain is “we’re agile so we don’t need documentation.” The “agile” aspect is more often than not, merely the assertion that the project is agile. Or someone says that the code is the documentation.

How do you interview people for developer and technical jobs? This is an enduring question, and one with many angry factions.

It’s too big a subject to tackle in its entirety and I have no intention of trying. Instead, I want to talk about one aspect: should you ask Computer Science questions or not?

In one corner are the people who argue that you never need to implement a linked list or write Quick Sort in real life, so asking you to do that in an interview is unreasonable and excludes good candidates. They argue that there are more important things to consider, such as the use of applications frameworks or design or working with other people.

One of the great things about WordPress is the community and the number of great plugins that can do amazing things with little effort.

But all that code, as any good developer will tell you, is a liability. How do you pick a plugin that not only meets your requirements now, but will both continue to do so? WordPress advances. APIs change. Plugins need love too.

Many moons ago I settled upon Flickr Gallery, a plugin that allows you to import Flickr images just by adding a short-code to posts. I thought there was value in keeping all my public photos in one place and, at that time, WordPress had poor media management facilities. The plugin seemed popular and well supported.

I’m seeing a surprising amount of vitriol aimed at Swift, Apple’s new programming language for iOS and Mac development. I understand that there can be reasoned debate around the features (or lack thereof), syntax and even the necessity of it but there can be little doubt about the outcome: if you want to consider yourself an iOS developer, it’s a language that you will need to learn.

The only variable I can think of is when you learn it.

Last night I did a short presentation about my WSLHTMLEntities open source project at the London iOS Developer Group meeting. You can see the slides here:

One question I got at the end that I was unable to answer is how well it performs compared to other solutions.

As happy as I am with the way that my new app, CameraGPS, a GPS logger application for people who want to geotag their photographs, came out I can’t say that it’s exactly as I envisioned it at the start of the process.

The idea was something like this: many of the GPS logger apps in the App Store require you to either use iTunes file sharing (who connects their iPhone’s to iTunes any more?) or mail yourself the exported document or sign up to some third party fitness or trekking website. Mailing yourself stuff just didn’t feel very slick and I didn’t want to record my trails for fitness purposes.

This took me a while to figure out so I thought it was worth blogging about. The short version: I’m using Core Data with iCloud syncing and it works… mostly. When starting up for the first time — when there is already data in iCloud — none of the data appears in a table view, but restarting the app correctly displays it.

I know what you’re thinking: you’re not merging the updates into the right managed object context. Nope. Sorry. Thinking that was the problem is probably why it took me quite so long to track the real problem down!