Links 2018-01-14

Legends of the Ancient Web – Maciej Cegłowski

Maciej, more commonly known as Pinboard on Twitter (the name of his bookmarking service that I use for these weekly links), is my internet hero. His talk on the history of radio, from anarchic beginnings as a peer-to-peer medium, through to centralisation and exploitation by astute political propagandists, offers relevant lessons for the future of today’s internet.

In less than four decades, radio had completed the journey from fledgeling technology, to nerdy hobby, to big business, to potent political weapon.

This trajectory must have come as a shock to its pioneers.

At its birth, it seemed like radio would only be a force for good. How could something that connects people together be anything but beneficial?

But radio waves are just oscillating electromagnetic fields. They really don’t care how we use them. All they want is to go places at the speed of light.

It is hard to accept that good people, working on technology that benefits so many, with nothing but good intentions, could end up building a powerful tool for the wicked.

But we can’t afford to re-learn this lesson every time.

Good Luck Spending Your KodakCoins – Matt Levine – Bloomberg

A friend sent this on – if you’re feeling weary about the incessant hype around the blockchain, this will depress you even further but at least the great writing will cheer you up. Levine starts with the whole silly KodakCoin business but makes a wider point that maybe nobody really believes in this stuff: like other pump-and-dump scams everyone knows it’s a scam, people just think they can make a quick buck before selling on to a greater fool.

The Good War – Mike Dawson and Chris Hayes – The Nib

I don’t know what to call this – a ‘graphic essay’? It’s a ‘graphic novel’ treatment by Mike Dawson of an essay by Chris Hayes identifying some of the origins of the Iraq and Afghanistan wars in the sugary nostalgia for World War II that broke out in the US in the late 1990s. Both are well worth a read.


A useful and very comprehensive collection of resources for naming things. Lovely typography too.

Birdcage Liners – Joel on Software

The article I wish I wrote about quitting social media. Joel Spolsky muses on why Twitter and Facebook make us unhappy, and how “when you design software, you create the future”.

I’m deleting my Facebook account tomorrow- Thomas Bibby

Yours truly with a much less eloquent ragequit of Facebook.

Softwear: How an Underground Fashion Label for Nerds Got Cool – Wired

I love articles about industries I know nothing about, like this one on mens fashion. Some interesting insights into the state of the modern fashion industry.

The Strange Brands in Your Instagram Feed – The Atlantic

Another article that starts with mens fashion, but takes a fascinating diversion into the world of generic brands, drop shipping and Instagram. Also starring a 17 year-old YouTube star from Ratoath, Co. Meath (Ratoath!) who is a leading light in this business, posting his video updates to his thousands of followers on how to get rich quick.

The Making of Apple’s Emoji: How designing these tiny icons changed my life – Angela Guzman

A sweet story on the design of the iPhone’s first emoji, from an intern who worked at Apple. Don’t read if you’re particularly fond of the ice cream emoji ;-]

I’m deleting my Facebook account tomorrow

I’m about to lose touch with a lot of people. Tomorrow I will ‘unfriend’ all my contacts on Facebook, delete all my content, and finally remove my account. Not that Facebook will actually remove my account, they’ll keep all my data in case I have a change of heart, and they will continue to monitor my online movements in the service of their creepy advertising system, even though I’ve asked them not to. I’m not the first to do this, and indeed many before me have written posts like this one. As such there’s nothing new in this post. But I still think it’s important to outline the reasons why I feel Facebook has become such a negative thing in my life.

The dopamine hit

Facebook’s service is obsessively engineered by some of the best software engineers and designers in the world to be addictive. The algorithm used to order items on your timeline, the notifications you get, the specific animation you see when you ‘like’ something – it’s all designed to keep you on the site and looking at ads. What I’ve noticed is that this addictiveness often makes me feel tremendously unhappy after an hour or two on the service and I’m not the only one – I’ve had many conversations with friends that centred around the fact that Facebook was making them unhappy.

Creepy behaviour

All those ‘like’ buttons on almost all websites I visit these days are not there primarily to allow me to share content on Facebook (that’s just an added bonus) – they’re present so that Facebook can track what I’m looking at even when I’m not logged in to Facebook. The company is proud of its ability to collect information on its users allowing advertisers to ‘target’ their ads to my interests and behaviour.

Facebook has become a force for bad in the world

Even if I was happy to trade the creepiness and the addictiveness of Facebook for the ability to keep in touch with lots of wonderful people – there’s still the undeniable fact that Facebook is enabling poisonous ideologies and repressive regimes to spread. Dark ads, fake news and other things that I don’t want to be a part of anymore.

Alternatives exist

Thankfully the internet is still (just about) designed to be open. I’ve had my phone number, email address and location of my house online for the past 15 years. I publish articles like this one on my own site that I control. Recently I set up a ‘microblog’ that I also control. I’m still on Twitter for the moment (although that platform’s role as a harassment vehicle is giving me second thoughts) but now I publish all my status updates on my own site first. There is a new service,, that I joined recently which simply shows me a list of updates from people that I follow, in time order, with no ads. They even charge for the service so I can be more confident that I’m a customer of the service, not a product of it. Hopefully I’ll still get to be ‘social’ on the internet, but without the downsides.

Links 2018-01-07

The surprising thing Google learned about its employees — and what it means for today’s students – Washington Post

I’m not sure about the implications for education mentioned in this article but this is a great summary of Google’s Oxygen and Aristotle projects – where they found that the skills that most highly correlated with successful software engineers were soft interpersonal skills (e.g. being a good coach; listening) and not hard skills like algorithms or data structures. The stereotype of the socially toxic yet brilliant programmer needs to die.

My Internet Mea Culpa – Rick Webb

As a GenX tech worker, this piece struck close to home. Rick Webb says sorry for his tech utopianism (and by implication, the rest of we GenXers who thought that information wanted to be free) that resulted in the terrordrome of awfulness that is today’s web.

The Smart, the Stupid, and the Catastrophically Scary: An Interview with an Anonymous Data Scientist – Logic Magazine

A long anonymous interview with a data scientist, who maintains that data science, machine learning artificial intelligence fields are so full of stupid marketing that close to nobody actually knows what they’re talking about anymore.

China’s Selfie Obsession – New Yorker

An article about beauty, celebrity culture, photo filters and plastic surgery in China.

The Objective-C Runtime & Swift Dynamism – Roy Marmelstein – Realm

A transcript of a 2016 talk. I love deep dives like this into the Objective-C runtime – in particular how simple things like classes are implemented in Objective-C.

An epic treatise on scheduling, bug tracking, and triage – apenwarr

This is a gloriously meandering take on the state of modern software development. It should be required reading for programmers, project managers, and anyone who ever wondered why software is late.

SQL Keys in depth – Joe Nelson

I learnt loads from this article, not just about databases, but about uniqueness and the abstractions we use to represent the real world in our programs.

Links 2017-12-31

Note: this is a new experiment I’m running – posting a weekly list of links that I enjoyed. Feedback welcome – also if anyone would like these in their inbox, let me know and I’ll add a subscription option.

Computer latency: 1977-2017 – Dan Luu

A wonderful article detailing how our computing devices have been getting less responsive over the years, and how complexity makes it worse.  There are good reasons why a 34 year-old Apple IIe  is top of Dan’s responsiveness charts, but that doesn’t mean we should be proud of it.

From inboxing to thought showers: how business bullshit took over – The Guardian

A glorious rant against business speak, with a shout-out to one of my favourite TV series, W1A, which skewers this practice wonderfully.

Dozens of Companies Are Using Facebook to Exclude Older Workers From Job Ads – ProPublica

Discrimination of any kind is awful of course, but what’s baffling about this particular case is that companies are hurting themselves by excluding potentially brilliant employees. And this doesn’t just go for older people – the lack of diversity in tech is a directly result of tech companies using stupid hiring practices and then wondering why it’s so hard to get good people.

Decomposing Emoji –

An illustration of how Swift, Javascript, Ruby and Python all have different answers to the question of “how long is this string”, and how they’re all right. It feels like since Unicode, strings are the new dates – representations of real-world things that most programmers get wrong.

How Facebook’s Political Unit Enables the Dark Art of Digital Propaganda

It’s not shocking that Facebook are making money from rich people looking to change peoples’ minds, but it is shocking how blatant they are about it. I’m expecting Facebook ads paid for by people and organisations outside Ireland to play a big role in Ireland’s abortion referendum next year.

How to scam $200,000 per month and get 67,882 all 5 Star reviews on the app store – reddit

A nice bit of digging on fake reviews on the App Store. My biggest complaint about the App Store – it’s not the 30% cut, or the stringent review criteria, those things I’m happy to put up with. My complaint is that the scammers still win. If the scammers are vanquished and good apps will naturally rise to the top of the sales charts I’d be a much happier app developer. This article shows how much work Apple need to do to fix the App Store and remove the rubbish.

Rust in 2017: what we achieved –

I’ve not tried out Rust yet – but this is a pretty good example of how to grow a community round your project. I enjoy these “year in review” posts so much, I’m surprised that more people don’t do them (and just to show it’s not just for programmers, I enjoyed Candy Japan’s 2017 review post too)

On the front lines of the GOP’s civil war – Esquire

An interesting account of Republicans in the US trying to take their party back.

Chrome is Not the Standard – Chris Kycho

It still baffles me how Chrome managed to get such market share, especially amongst developers. I’ve only came across a few sites that were Chrome-only – mostly complicated web apps – and I hope that this trend doesn’t continue.

Ask HN: Is it too late to find a mentor after 30 for a software developer? – Hacker News

A Hacker News discussion thread that reminds me of a business idea I have – create a remote part-time version of Recurse Center – pair people up with a remote mentor, charge a subscription fee where most of the money goes to the mentor, to a maximum of x hours a month. Like most of my business ideas, I really just want this service to exist, because I’d definitely pay for it.

The Only McLaren F1 Technician in North America – Road And Track Magazine

I’m mostly bored about cars these days, but I still remember the excitement when the McLaren F1 came out, and this article is a lovely tribute to a truly ground-breaking machine.

To Serve Man, with Software – Jeff Atwood

An eloquent post on the need for software engineers to recognise the responsibility that comes with our increasing power.

Eight opinionated tips for people learning Swift

I was talking to two Objective-C iOS developers recently who told me that they were starting to learn Swift. This got me thinking: what did I wish I knew when I was learning Swift? Here are eight tips that are opinionated: they are not designed to help you learn Swift, but they might help you to work with the language instead of against it.

1. Avoid force unwrapping and force casting

I’ve written about this before – and it annoys me that Xcode sometimes recommends force unwrapping Optionals as a fix-it. Force unwrapping with ! and force casting with as! will bite you in the end – don’t do it. (Possible exception – objects from Storyboards and interface builder files, as their types are defined at runtime).

2. Prefer guard let over if let

You’ll learn that the classical way to unwrap an Optional is to use if let. The problem with if let is that it can cause pyramids of doom of closing braces in your functions. Consider this example:

if let processedString = funcThatReturnsAnOptionalString("parameter") {
    if let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") {
        if !processedString.isEmpty && !secondProcessedString.isEmpty {
            //do stuff
} // yuk

Solution: use guard let introduced in Swift 2:

guard let processedString = funcThatReturnsAnOptionalString("parameter") else {
    //you may want to perform error handling here
guard let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") {
    //handle error if necessary
if !processedString.isEmpty && !secondProcessedString.isEmpty {
    //do stuff
} //goodbye pyramid of doom

This gives you a fail early pattern and allows you to avoid unnecessary indentation.

3. Unwrap multiple things at once

You’ll run in to another problem once you start using guard let: you’ll find your functions compress horizontally (less indentation) but will expand vertically (more lines of code). Solution: unwrap multiple things at once. Consider the example above compared with:

guard let processedString = funcThatReturnsAnOptionalString("parameter"), let secondProcessedString = funcThatReturnsAnOptionalString("another parameter") else {
    //handle error if necessary
if !processedString.isEmpty && !secondProcessedString.isEmpty {
    //do stuff

Caveat: I find that if I’m unwrapping more than three things at once, it’s a code smell and I need to refactor. Also: it’s possible to combine guard let with traditional guard statements with conditional clauses: although I’m on the fence whether this is a good idea or impedes readability, I do find that it works as long as I restrict it to conditionals that answer the question “is this thing valid enough for me to work on?”. This would be achieved with the following (make your own mind up if this is taking things too far):

guard let processedString = funcThatReturnsAnOptionalString("parameter"), let secondProcessedString = funcThatReturnsAnOptionalString("another parameter"), !processedString.isEmpty, !secondProcessedString.isEmpty else {
    //handle error if necessary
//do stuff

4. Understand that optionals may cause your app to fail differently

To be fair this is less of a problem for Objective-C developers, who are used to the paradigm “sending a message to nil is grand, at least if you’re expecting an object in return, because you’ll just get nil back”. But for developers coming from object-oriented languages such as C++, Java, C#, etc. it might be a bit of a surprise that you get far fewer crashes in Swift apps if you don’t force unwrap, because the language can eliminate a whole class of “null pointer exception” crashes if you use it correctly. This is not the same as eliminating bugs due to unexpected input! Instead of bug reports “the app crashes when I tried to do this”, you’ll start to get reports of “nothing happened when I tried to do this”. Prepare accordingly.

5. Use structs (when you can)

Although Swift supports object-oriented programming with classes, it brings a new more powerful paradigm: protocol oriented programming. This works best with the value types struct and enum and also gets you extra benefits: default initialisers, thread safety, and a way out of the sometimes baroque structures that class inheritance can encourage. But there’s a caveat: note that the two popular object persistence methods used in Swift (Core Data and Realm) use classes. And at the UI layer, UIKit on iOS and AppKit on macOS are all class-based. So your potential for using structs may actually be quite limiting (which can be a bit confusing because most introductions to Swift focus on structs, not classes, which leaves you with a mismatch between learning the language and using it). That said, do try and use structs where you can, especially in the intermediate layers between your view controllers and your model objects.

6. Enum all the things

That’s the title of a talk given by Dave Sims at the Limerick iOS Developer meetup that was so good he famously ended up giving the talk at other meetups in Ireland and the US. Enums are first-class (pardon the pun) value types in Swift that can have functions, properties, and most of the things that structs can have, as well as associated types. They are a tremendously powerful tool when writing swift apps.

7. Avoid AnyObject, and start to think about protocols and generics

Say you have two UITableViews in your app, which are mostly similar – you might be tempted to write one UITableViewController to avoid code duplication. What do you use as your datasource? One way might be to use an array of AnyObjects (AnyObject is a special type which means an instance of any class). Any time you’re relying on run-time type checking is a good prompt to think about protocol orientated programming. At its simplest, create a protocol and make your two types conform to it (they can even be blank). Add any common properties to allow the Swift compiler to check the validity of your code. Generics offer another powerful way of avoiding code duplication and increasing compile time safety. You can even create generic protocols using Protocols with Associated Types.

8. Add defaults to function parameters

Finally a quick one – if a function you’ve written almost solves your current problem, but needs an extra parameter, add it to the existing function with a default value instead of creating a new function. The default value will mean that existing calls to that function won’t break. I’ve often found that making the parameter an Optional type and setting its default value to nil allows an if let in the function body to neatly deal with the extra parameter.


Swift is still a young language, and best practices are by no means settled. To take an example from Erica Sadun’s excellent book Swift Style: An Opinionated Guide to an Opinionated Language, the Swift Standard library team prefer a space either side of a colon in declarations:

class userDetailViewController : UIViewController {

where the Apple developer docs team prefer left-hugging colons almost everywhere:

class userDetailViewController: UIViewController {

(for what it’s worth I prefer the second approach). I don’t even follow all the recommendations listed in this article all of the time in my own code. What’s important is that as you learn the language, you’re aware of working with the language and its opinions, rather than against it.

Starting to break out from the walled garden

The AOL walled garden in the late 90’s. Image from

When I was at college, I had a night job in a call centre, providing tech support to AOL’s UK customers. It was the late nineties, and although AOL was never as popular in Europe as it was in North America, the company’s vision of a proprietary walled garden giving an ‘internet-like’ experience was still a compelling option for many.

Of course AOL’s influence waned over the years, causing many of us to think that “the internet wants to be free” and that any attempts by a large corporation to supplant the internet was doomed to failure, confirmed by the quick rise and fall of services like Bebo and MySpace.

Now I’m not so sure.

The 2010s have seen the aggressive expansion of social networks such as Twitter and Facebook. When you sign up to these services, you feel like you’re a new customer but of course you’re not, you’re a product. Sophisticated algorithms suck you in to spend more time on these sites, ‘engaging’ more so that you will provide more information to be targeted by ever-more tailored (and profitable) ads.

And the effects have become even more chilling as the algorithms that social networks use spill over into society and politics, encouraging us all to become more polarised, more aggressive and more needy.

There is an alternative, and thankfully there are some very smart people working on it. A return to the open web, where we share for the simple joy of sharing, without profit-maximising algorithms getting in the way.

Host your own content

The basic idea of hosting your own content is not that you pretend that social networks don’t exist, but rather that you take control of your own content, under a domain name that you control, and choose what you share with other services.

I’ve hosted my own content on this site for the past twelve years but for shorter ‘status updates’ I have occasionally used social networks for this purpose.

I’ve created my own ‘microblog’ at that I will use for short pieces of content, originating from my own site. I will use a new service called to share my posts to twitter and (maybe) facebook, but the content will always originate from my own site. If you don’t want to create your own site, can do it for you – yes it costs money ($5/month) but if we are to take back control of the web, we need to start thinking like customers, not products. The service is still invite-only at the moment, but I have a few invite codes if anyone would like to check it out.

I’m grateful that there are people working on products that can help us liberate ourselves from the walled garden, and I’m hopeful there will always be a place for independence on the web, away from the toxic profit-maximising behaviour of commercial social networks.

Make our street great again

To the project team in charge of redesigning Limerick’s main street:

Please remove through traffic from O’Connell Street.

Expecting people to compete with 1 tonne+ hunks of metal dashing from one side of the city to the other is a recipe for disaster. Let’s admit that “shared space” is the “sorry/not sorry” of urban design when it facilitates traffic throughput.

Let’s be ambitious for our city centre: O’Connell Street has enough room for green spaces, playgrounds, exhibition areas, and much much more.

To attract the best to live, work and learn in our city centre requires a city centre worthy of the best.

I genuinely appreciate the effort that the project team have made to consult the public. I know we share the same hopes and dreams for our city, and I hope you can revise your plans to remove through traffic and centre our great street around our city’s most important asset: our people.

Sent as a submission to the O’Connell St project design team, 29th June 2017.

Don’t use the Force, Luke

(tl;dr: force unwrapping in Swift with ! is bad)

At our last iOS Developer meetup in Limerick, my Worst Case Scenario podcast co-host Dave Sims gave an excellent talk on Optionals in Swift. I’m hoping that Dave will put the content online some day as he really managed to provide a simple yet powerful overview of what Optionals are. He also ended up being invited to give his talk to the CocoaHeads meetup in Indianapolis via Skype – check out Worst Case Scenario Episode 36 for the details about how that came about.

Dave mentioned in his talk that force unwrapping Optionals is generally a bad idea. Xcode doesn’t help the matter though by actually encouraging programmers to force-unwrap optionals:

This is terrible advice for programmers new (or not-so-new…) to Swift. Force unwrapping a nil optional will cause a runtime crash. The whole point of optionals is you make a whole class of bug, where a nil creeps in and causes havoc down the line, impossible. Force-unwrapping throws all of this away with the dubious upside of saving a line or two (and shutting up the compiler). You can argue that the Apple documentation is pretty clear about force unwrapping being a bad idea, but I feel the tools should be encouraging best behaviour. Dave mentioned three common unwrapping techniques:

  1. if let
  2. guard let
  3. The ?? nil coalescing operator to provide a default value

Dave also mentioned Chris Lattner’s recent appearance on Accidental Tech Podcast where Swift’s creator talked about the purpose of the guard statement was to allow early exit (Overcast link that jumps directly to that segment), a style which he is personally in favour of. I also like this style – it reduces the indentation for the main bit of the code. You just have to remember to actually exit the block, either by asserting or returning a default value.

Moving on

For nearly five years I’ve been running my startup Reg Point of Sale. Last week I sent an email round to all my customers to tell them that I’m shutting the business down.

Fortunately, due to the architecture of the system we developed, our customers will still be able to use their systems for the foreseeable future.

It was a tough decision to make. We didn’t take any outside investment, and we don’t owe money to anyone, but it’s still tough to shut down what really was a labour of love.

At some stage I’d like to write up a more detailed retrospective about what went right, and what went wrong. But for now, if you’re interested in more background, I did talk a bit more in detail about this on the latest episode of the Worst Case Scenario podcast that I host with David Sims and Baz Taylor. The relevant section starts about 33’40” in.

Hey Siri, turn the Christmas lights on

My fellow podcast hosts on Worst Case Scenario had both got smart home gear for Christmas. I was feeling a bit left out so I wanted to hack together a low-budget version. Here it is in action:

Now I can use Siri (or the iOS Home app) to turn on my Christmas lights from anywhere!


  • Raspberry Pi
  • Relay shield from the gear we bought for the hackathon last year (it’s marked FE_SR1y)
  • Christmas lights

The relay shield has a transistor and a diode built in, so I didn’t need to do any fandaglement with a circuit, just hooked up the + to 5v on the Pi, – to Ground, and the switching pin to one of the GPIO pins.

On the Pi, I installed the excellent Homebridge which allowed me to create a HomeKit accessory that Siri can talk to. I used the homebridge-gpio-wpi plugin to talk to the GPIO pins.

It’s obviously super fast on my home wifi network but it’s also surprisingly speedy going through the phone network: iPhone -> phone network -> Apple’s servers -> Apple TV -> Raspberry Pi -> lights takes about 1.3 seconds.

I am toying with the idea of creating a low-budget connected home using 433MHz RF remote controlled sockets which I could control from the Pi with a transmitter board. The other two lads on Worst Case Scenario are also expanding their systems based on the Amazon Echo – subscribe and keep up to date with how we’re getting on!