After the Facebook / Cambridge Analytica catastrophe and recent Twitter news (and retraction) about support for 3rd party clients, I found myself wondering about again, after hearing about it on Kickstarter a little over a year ago.

On the surface, it’s an indie Twitter-like app, in the vein of the now-defunct, but whereas was a Twitter clone – a silo where all interaction took place within the platform – is more like a bit of glue to create a social app out of the larger web. (Brent Simmons has an excellent post about the differences.) You can pay $5 a month to get them to host your microblog, but by adopting some web standards like RSS and webmentions, you can host your microblog on your own site. If you’re on WordPress you can publish to your site using the Microblog iOS and Mac apps. Replies are a bit of a bugbear, though: they’re handled entirely within if initiated using the app’s Reply functionality, or threaded in properly if you post from your own site with the proper webmention URL.

It sounds a lot like a social RSS reader.

At the same time I was considering all this, I came across another post by Brent Simmons talking about the “IndieWeb”.


The IndieWeb is a people-focused alternative to the “corporate web”.

Even the IndieWeb website doesn’t do a great job of explaining what it is, or what it means to “join the IndieWeb”. As far as I can tell, it’s a collection of practices and technologies that connects independent blog-type websites together into a quasi social network. Sound familiar?

There’s a lot of overlap between and IndieWeb (webmentions being the most significant commonality), and IndieWeb isn’t one monolithic thing. It’s a collection of independent-but-related stuff like IndieAuth (for authenticating yourself online based on your website) and microformats (a feed like RSS, but using HTML classes on your site instead of data on a separate URL). There’s also an overarching philosophy – which I’m not sure I entirely subscribe to – of community, owning your own content, and nostalgia for what I think they’d call the pre-siloed web.

JSON Writes

I’ve recently moved this blog from my own Concussion blog engine to WordPress. Concussion was getting annoying to write for1 and there were a few things I wanted to try out that wouldn’t work well on a non-CMS-based system.

I’ve got it all set up for and a bunch of IndieWeb stuff. (You can find me at Anything I post here automatically gets mirrored to and Twitter, and replies in either location get routed back to my site as comments.2

It’s interesting stuff, and it was fun to re-implement my site as a WordPress theme, but I feel like some things are missing. For instance, if someone replies to a post on Twitter, the reply gets sent back here as a comment. However if I reply here to that comment, it doesn’t get sent back to Twitter. Alternatively, I could write a brand-new post using the Twitter reply as a “reply-to” URL, and that would correctly be sent back to Twitter, but then the conversation as visible here would be scattered and hard to follow. I’m going to be experimenting with some other WordPress plugins to try to apply some finesse.

So: so far, so good. It does feel a little odd, as someone whose friends aren’t on these platforms, and who’s not a prolific blogger or “content producer”. We’ll see how it goes. If nothing else, it was a fun experiment!3

In the meantime, if your RSS subscription is including my title-less micro posts, and you don’t want that, check out the links on the Feeds page.

  1. I had to add new posts using git, without a way to preview how they would be rendered; my article parsing regex was also failing on a new post I was writing, and for the life of me I couldn’t figure out why. 

  2. I’ve got commenting turned off for now while I try things out. 

  3. And a little PHP refresher. (Yes I know that’s a dumb example, but it’s funny.) 

Google, Diversity, and Hiring

Your hiring process tells people what you care about.

Note: thanks to my friend and QA extraordinaire Natalie Owen who helped me make sure this added to the conversation and didn’t distract from other important issues brought up by the recent Googler’s document.

I want to share some brief thoughts on the latest bit of evidence of the deplorable state of diversity in the tech industry, the screed written by a Googler about how women and minorities are supposedly inferior engineers and how he feels persecuted as a person who holds this and other self-described right wing beliefs.

Others have done a much better job than I can of addressing the actual document and its misguided arguments, but I wanted to quickly touch on one of the reasons I think we end up with these outcomes: a company’s approach to hiring.

None of this is particularly original or new, but I thought it might be useful to attach it to the current situation.

I don’t want to suggest that lack of diversity and the kind of toxic culture that it perpetuates is not an industry-wide problem by focusing only on Google (it unequivocally is industry-wide). And there are both wonderful and awful people working at any large technology company. But is it any surprise that a company that hires based purely on algorithmic puzzle solving ends up with people so lacking in empathy? That ends up with a culture where this guy felt comfortable writing and sharing this bullshit, directly telling his female and minority coworkers that they are less-than?

As others have said over and over, it’s not a pipeline problem1 that women and minorities are so woefully under-represented in our field, but it is a hiring problem, and on many levels. To focus at the level of the interview: when you select for IQ at the exclusion of EI2, when you trust your full day of academic tests over a person’s work history or references, when you ask questions about obscure APIs instead of how the candidate has handled situations where they’ve had a disagreement with their colleagues, you send a signal about the things that you care about and the things that you don’t. Certain people won’t even consider applying. And those people who hold toxic beliefs, who espouse gender exceptionalism and individual power, but who happen to be brilliant programmers, they are who you hire. And the cycle continues.

  1. It’s not a pipeline problem in the sense that “there aren’t enough women or minority developers out there.” (There are.) It is a pipeline problem in that companies exclude these groups at every step of the pipeline. Several of the articles linked from this post go into this in more detail. 

  2. Emotional intelligence 

There was a lot of negativity in response to the new MacBook Pro announcement on October 27. I don’t subscribe to many of those ideas (some of the more cataclysmic responses were a little over the top), but I am disappointed enough that after more than a decade of owning Macs, I’m switching back to Windows.

I want to be clear: Apple’s new laptops are excellent, they will sell well, and this is not some sort of death knell for the Mac. However, for these machines to excel in the ways that they do, certain compromises had to be made, and those particular compromises matter a lot more to me than the improvements do. (That is, I value high-performance graphics in a 15″ pro computer over the admittedly impressive strides Apple has made in size and weight.)

I will miss the incredible screen, the best trackpad in the industry, macOS’s UNIX underpinnings1, and the ability to connect power, display, and additional USB ports all through a single cable.

Most of all, though, I’ll miss the incredible 3rd party software available for macOS. As far as I know, there is no high-quality equivalent on Windows to TweetBot, Alfred, or Keyboard Maestro2, let alone pro apps like those from Panic or The Omni Group. And good luck finding a solid RSS reader like ReadKit or Reeder.


There have long been accusations that there is an “Apple Tax” – the idea that Apple products are overpriced compared to their PC (or Android, or whatever) brethren. This myth hasn’t been true (at least in the Intel era3), but it has endured. With the introduction of the Touch Bar4 and the significant price increases it entails, I think the “Apple Tax” complaints are ready to see a revival.

The Windows Option

I’m an iOS developer at work, so I will continue using and enjoying Macs.

At home I primarily use my computer for regular putzing around, and playing games. Last time I bought one in 2011 I went for the top-of-the-line 2015 MacBook Pro because it had a solid discrete GPU. I was planning on doing the same this time, but the very best GPU that Apple offers for its new machines is underpowered, and goes for around the same price as much more powerful mobile GPUs. Here’s a quick comparison of the new MacBook Pro and the most MacBook-like Windows laptop5, the Razer Blade.

MacBook Pro, mostly upgraded.

  • 2.7 GHz Core i7
  • 1 TB SSD
  • 16 GB RAM
  • Radeon Pro 460 (4 GB VRAM)
  • CAD $4,099.00

Razer Blade, fully upgraded.

  • 2.6 GHz Core i7
  • 1 TB SSD
  • 16 GB RAM
  • GeForce GTX 1060 (6 GB VRAM)
  • CAD $3,899.99

I’ve had a hard time finding comparisons between these GPUs since they’re both brand new, but this not-quite-apples-to-apples comparison suggests the Razer Blade’s GPU is 2-3x faster in most measurements, and the computer it comes in is two hundred (Canadian) dollars cheaper.

More than double the performance for less money, in a package that more or less exactly matches the last-gen MacBook Pro6?

Sign me up!

  1. Although, I’ve been trying Windows 10’s new support for running bash natively, and it works really well. More on that another time. 

  2. Luckily the folks at Smile now have a Windows TextExpander app

  3. The reason I bought my first Mac in 2006 (a 13″ white plastic MacBook) was because it was the only laptop on the market that was a) reasonably small; b) reasonably powerful; and c) reasonably priced. I fully intended on wiping it immediately and installing Ubuntu or something. This was the time when PC folks like myself were still convinced Macs were Fisher-Price toys for people who didn’t understand computers. How condescending we were. 

  4. On the subject of the Touch Bar: I think it is an interesting innovation. I don’t agree that it’s a solution in search of a problem. I do think that it’s been added to the wrong product, at least given the way Apple is explaining it to us. It seems like a great tool for people who watch their hands as they type, and who aren’t comfortable with keyboard shortcuts; I think it should be on the MacBook. (Yes, I’m certain we will see awesome “pro” applications of the technology, too.) 

  5. Read: not hideous, enormous, or heavy. 

  6. Meaning the one released in 2015. The new Razer Blade is the same thickness as that older model at 0.7″, lighter at 4.16 lb vs 4.49 lb, and has a higher-density screen with (according to a review on YouTube I can no longer find) full coverage of sRGB. Admittedly, battery life is not nearly as good. The new MacBook Pros beat the Razer Blade on each of these counts, but in my estimation the older machines were fine in these respects. 

I wrote last year about Swift protocol extensions. If you define a method in a protocol extension that isn’t defined as a protocol requirement, it is dispatched statically, whereas methods defined as protocol requirements are dispatched dynamically. (See the original article for a detailed explanation.)

In March, there was an update – an acknowledgement by the Swift team of this shortcoming and a possibility for a change in behaviour.

Now Ole Begemann writes about Kevin Ballard’s post on swift-evolution explaining very nicely why this limitation exists in the first place:

So essentially, while protocols have a virtual function table, protocol extensions do not, and cannot easily have one because a type adopting the protocol won’t necessarily know about all extensions at compile time and therefore cannot add the extension methods to its own vtable. Opinions may vary whether dispatching protocols dynamically all the time would be a viable alternative, but it’s clearly not what the Swift team has in mind for the language.

Kevin’s post is very informative and worth reading in its entirety.

I wrote in August of last year about some potential confusion coming out of the decision to statically dispatch calls to methods defined in a protocol extension that were not defined in the protocol itself. (Whereas calls to methods defined in the protocol are always dynamically dispatched.) This allowed the protocol / extension designer to differentiate between customization points (methods defined in the protocol) and non-customizable code (methods not defined in the protocol, but implemented in an extension).

It looks like Apple’s received some feedback around this, and Doug Gregor acknowledges this is his “Completing Generics” Manifesto. (Update May 5: Austin Zheng has created a formatted version of the manifesto, available on GitHub.) However I’m not optimistic that this will get changed in future versions of Swift, as he puts it in his “Maybe” section:


There are a number of features that get discussed from time-to-time, while they could fit into Swift’s generics system, it’s not clear that they belong in Swift at all. The important question for any feature in this category is not “can it be done” or “are there cool things we can express”, but “how can everyday Swift developers benefit from the addition of such a feature?”. Without strong motivating examples, none of these “maybes” will move further along.

Dynamic dispatch for members of protocol extensions

Only the requirements of protocols currently use dynamic dispatch, which can lead
to surprises:

protocol P {
  func foo()
extension P {
  func foo() { print(“”)
  func bar() { print(“”)
struct X : P {
  func foo() { print(“”)
  func bar() { print(“”)
let x = X() // //
let p: P = X() // //

Swift could adopt a model where members of protocol extensions are dynamically dispatched.

Fingers crossed, but I think the ship has probably sailed on this – I wonder if the change of behaviour would result in more confusing bugs than this quirk of the language did in the first place.