Facebook's presumably a more successful AOL

Back in the late 1990s, AOL tried to create an alternative internet. It was roundly derided, and everyone instead used its sign-up CDs as drink coasters.

As far as I can see, Facebook is now trying very hard to create an alternative internet for its users, one which threatens to be more successful.

Facebook has said publicly that it wants to make the experience of consuming content online more seamless. News articles on Facebook are currently linked to the publisher’s own website, and open in a web browser[…]

In addition to hosting content directly on Facebook, the company is talking with publishers about other technical ways to hasten delivery of their articles.


Facebook has a lot of users, and it’s worrying how many organisations are willing to give up their own identities — online and off — for a perceived share of those. Any company that believes Facebook has anyone’s interests but Facebook’s at heart is a fool. Otherwise its way of making “consuming content online more seamless” would probably not involve putting it into Facebook.

Instead I’m inclined to agree with Dave Pell:

Here’s what tech people are really good at:


Because tech happens to be at the center of a financial and cultural revolution, the people who have been talented and fortunate enough to make to the apex of the industry are perceived as oracles of industry; every industry.

And therefore are no more qualified to tell other industries what to do than the people who tell technology companies what to do from the outside.

Though that coming from someone who’s ceded their writing to Medium is a little comic.

Using Instruments to track down memory leaks

I was prototyping using TMDb for film search in One to Watch to solve the problem of Freebase’s API going away. While doing this I noticed that the memory usage of the app was going up significantly every time I opened a film’s details view.

Using the Allocations tool in Instruments, I could see that the memory was increasing in a staircase like manner. Looking at the memory listing shown in Instruments, it was clear that this stepping was caused by decoded PNG images, used to display the cover art. Each time the details view was shown, another 3MB PNG image appeared in Instruments.

The way displaying a film’s detail works is incredibly simple and standard: the details view, SavedItemDetailsView is pushed onto a UINavigationContoller object’s stack. It’s popped off the stack when the view is dismissed. Why wasn’t the SavedItemDetailsView object getting freed when the details view was popped from the stack maintained by the UINavigationController?

At first I had a classic “blame the compiler” moment: “the UINavigationController must be retaining my view for too long!”. StackOverflow, bless its socks, had a bunch of people having similar issues and leaping to blame UINavigationController too. Of course, it turned out to be my fault. As I assume it did for most of those SO posts.

Thankfully a friend pointed me toward solving the issue by pointing out how to see retain/release calls during the running of the program:

  1. Start a new Allocations session in Instruments.
  2. Before starting your run:
    1. Select the Allocations tool in the top segment of the screen.
    2. Show the right hand side bar (View -> Inspectors -> Show Record Settings).
    3. Enable “Record reference counts”.

Now, start the application running using the “record” button in the top left. Do the thing which is causing memory to increase, in my case showing and hiding the details view. As described above, at first I just saw a lot of PNG memory usage. However, this PNG image just got allocated via ImageIO so didn’t give much away. So my first port of call was the parent view controller; it just seemed a good place to start. So I needed to see the retain/release process for the view controller:

  1. Put the name of the class (SavedItemDetailsView in my case) into the search box next to the inspector sidebar.
  2. Hit the tiny right-arrow that appears when you mouseover the class name for one of the instances.
  3. Hit the tiny right-arrow appearing when hovering over the memory address.

You should get a (potentially very long) list of retain/release calls for your class. In my listing was an obvious unbalanced retain call. Once I found this, I easily tracked down to a delegate that was strong rather than weak. Correcting the property declaration quickly fixed my problem.

One to Watch's film querying at risk

One to Watch, my app to help you remember films you want to watch, uses Freebase when it’s searching for films. Freebase is an amazing database, built on community data. Google bought Freebase a few years ago, and made Freebase into the basis of Knowledge Graph. Up until now, this hasn’t been a problem; Google kept the old Freebase API up and running, albeit at new URLs.

However, by chance when updating some URL handling code in One to Watch, I was checking the Freebase API and noticed:

Warning: The Freebase API will be retired on June 30, 2015.

Oh oh.

On the Freebase blog:

[Before the end of March 2015] We’ll announce a transition plan for the Freebase Search API & Suggest Widget to a Knowledge Graph-based solution

Fingers crossed for anything half so powerful as the Freebase API. Otherwise I’m not sure what One to Watch will use. In addition, Freebase becomes read-only on March 31st, which means there’ll be no new films added.

Slightly worried: I can’t easily tell my users why OtW might just stop working for them — even if I can update the app, users of older versions are going to be upset :(

Careful wording

Moonpig, an online greetings card company suffered a security vulnerability. While the vulnerability was serious, far worse was the company’s deliberately misleading statement in response to the disclosure:

Indeed this tiny subset of information was “safe”. What was leaked was all other personal information held by Moonpig about every customer. Much worse than a password or a credit card that can be easily changed. That the company issues a statement like this indicates how little they care about their customers.

And obviously the fact that the company knew about the problem for 17 months and did nothing.


Slate is a window management tool for OS X. It differs from most because it’s designed to offer customisation over sensible defaults. In short, to use a hackneyed phrase: a programmer’s window manager.

There are two ways to configure Slate: a declarative way and using Javascript. I use JS, and recently uploaded my configuration to Github. I think Slate’s an awesome tool, so I wanted to go through how I use it.

As a warning, if they spoke Javascript in a foreign country, I’d just about be able to order a beer there.

Firstly, I set up five hotkeys, bound in a chaining fashion. The first key combination in the chain is ctrl-space, followed by one of:

  • 1 to fill the left half of the screen with the current window.
  • 2 to fill the right half of the screen with the current window.
  • 3 to fill the screen with the current window.
  • 4 to size the current window to a specific size and location I happen to prefer for text editors.
  • 0 is a magic hotkey. When it’s pressed, I use a script to work out where to place my most commonly used applications.

Hotkeys 1 to 4 are fairly standard. To bind them is simple in Slate:

slate.bind("1:space,ctrl", function(){ 
    var current_window = slate.window();
    var current_screen_size = slate.screen().vrect(); 
    var w = current_screen_size.width; 
    var h = current_screen_size.height;
    position_window(current_window, 0, 22, w/2, h); 

The above, for 1 is hopefully straightforward. The position_window function is a short helper I defined.

However, the main reason I use Slate is for 0. I have three possible screen layouts: laptop + 27”, laptop + 24” and just the laptop. The way Slate uses Javascript allows me to move and size windows based on my current screen layout. In practice, this means whenever I connect or disconnect a screen, I hit Ctrl+space, 0 and have most applications moved to their preferred places.

First, I define window groups using several objects, each of which is added to a sizes array:

var normals = new Object(); 
normals.names = ['Firefox', 'Google Chrome'];
normals.position_27 = [0, 22, 1366, 1019]; 
normals.position_24 = [0, 22, 1366, 1019]; 
normals.position_11 = "full_screen"; 

Hopefully the attributes are straightforward:

  • normals is just a group. I could’ve used browsers in this case.
  • names is the application names to use this group for.
  • The three position_x variables define placements for the different monitor layouts above.

When I hit Ctrl+space, 0, a function is executed which loops over every application. For each application, I look in the sizes array for a group with a matching application name. If a match is found, the code pulls out the appropriate window metrics using the current main screen width and some constants for each of the possible monitors. Then it sets the size of the window:

var p;

if (screen_width === DELL_27) { 
    p = apps.position_27; 
} else if (screen_width === DELL_24) { 
    p = apps.position_24; 
} else if (screen_width === LAPTOP) { 
    p = apps.position_11; 

if (p === "full_screen") {
} else { 
    position_window(win, p[0], p[1], p[2], p[3]); 

The full code is here. There are a few special cases for troublesome applications, but otherwise this is it.

If you’ve wanted to control your windows in a comically precise manner, Slate is for you.