A note on NSManagedObjectContextId

Like a lot of iOS Devs I’m used to working with my domain objects across various different threads.

As you may know, when you decide to work with an object on a different thread, you need to retrieve that object from that thread’s NSManagedObjectContext. This is normally done like so:

[myNewContext objectWithID:recordFromADifferentContext.objectID]

The record’s objectId is a universal identifier and you can find out more information from the Apple Docs on it.

However, I was recently having trouble with saving an object in one thread and then retrieving it in another thread. It was throwing an exception when I tried to use the object on the second thread.

The problem is that the initial objectId on a record is a temporary one. Therefore, when we hop onto a different thread, we can’t do a lookup on it.

The solution? Simply make the following call on your original managedObjectContext like so

[recordInFirstContext.managedObjectContext obtainPermanentIDsForObjects:@[recordInFirstContext] error:&error];

This will force the record to create a permanent objectId which can then be retrieved on another thread.

Screw stereotypes

A recent tweet by Marc Andreessen got me thinking about our culture:

“Silicon Valley is nerd culture, and we are the bro’s natural enemy.”

It got me thinking: what is nerd culture?

An interest in programming? Computers in general? Does it exist anymore? As a guy who could most certainly be viewed as a nerd (I started programming on a Commodore 64 as a kid and I could probably give you the rundown of every single game released in the N64/Playstation era), the whole ‘nerd culture’ thing always kinda jarred with me.

There are cultures around music, sport, film etc. Nerd culture is different to these in that its viewed as an exclusive membership. If you liked computers then you spent Friday nights at home playing Dungeons and Dragons, not out catching a game of ball.

When people learnt you had interest in computers they quickly assumed you didn’t have any interest in pursuits outside of technology.

This is understandable. Computers have only had widespread adoption in the past two or three decades. Tech culture is super young in the grand scheme of things. “Outsiders” built stereotypes due to a lack of understanding.

But my issue isn’t with outsiders pigeon-holing us. That happens for every culture eg. Football fans being seen as yobs, art fans seen as snobs etc. My problem is when we start viewing it this way ourselves.

If we ourselves start labelling each other as either “geeks”, “brogrammers” or whatever then we do a disservice to ourselves, to the person we’re labelling and to our industry.

Why? Because nobody is just one thing. I know plenty of people who are crazy sport fans who make great coders and I know plenty of self-proclaimed super-nerdy types who can’t hack for shit.

Here’s why it’s important to kill off these stereotypes now: because we’re at an important changing point in our industry and our culture. A career in tech is possible for more people (and more types of people) than ever before. The vast, vast majority of people considering a career in tech won’t fit into the nerd/brogrammer archetype.

For some people that won’t matter but for others it will make them reconsider pursuing an interest in which they have a very real passion.

Caricaturing the roles in our industry will reduce diversity and will mean that we’ll miss out on some really talented people who could do special things in technology.

What you can do

1. Realise that stereotypes add nothing positive to anything and try to wipe them from your mind.

2. Don’t fit yourself around a stereotype. Are you a programmer with bad social skills? Well then work on it – becoming a good conversationalist isn’t that hard. Are you a sales guy who just “doesn’t get” tech? Work on it. Again, it isn’t that hard.

3. Encourage as many people as you can towards our industry. The days of programmers being almost exclusively neck-bearded white males are coming to an end, people. This is a good thing.

Screw the stereotypes. Encourage people to code. Watch our industry blossom.

A word about inheritance and enums in Rails 4

Enums are a great feature in Rails 4 – ActiveRecord’s native adoption of them is nearly worth the upgrade alone. However, I want to share a gotcha I came across today on a project I’m working on (the new version of tech startup simulator Hipster CEO if you must know).

I have a model Task in my schema that functions as an assignable piece of work to a member of staff. I’ve used the acts_as_relation gem to create a multi-table inheritance structure with things like TechTask, MarketingTask etc to assign to different departments. Each one of these subtasks will have a specific type (eg. frontend work, security analysis, testing etc. for a TechTask).

Therefore, each subtask will be of a specific type but these will vary from subtask to subtask. For example, you can’t create a TechTask with a type of “online_marketing”. Since this attribute is shared (admittedly with different key/value pairs) I thought it would be good practice to move it up to the parent Task model and then define the individual keys in the subclasses. And that’s precisely when things went wrong.

In order for the parent class Task to use the enums, they need to be defined in the parent class itself. Otherwise, when you create a subclass object, it will fail when you try to set the enum. Moving all the enums up a level pretty much defeats the purpose of having these subclasses, since they would be so tightly coupled.

In the end, I had to create an identical attribute on each subclass of Task and wrote generic helper methods for retrieval/inspection etc.

Of course, it’s debatable that inheriting enums is a correct approach at all (from my research online there was plenty of people strongly against it) but this does feel like a valid use case.

In summary, don’t inherit enums in Rails 4 because you’re gonna have a bad time.

UPDATE: Moving the enum down to the sub-class table means you can’t (AFAIK) create a composite index on the enum and whatever data you have in the parent table (in my case, it was an association id). Not the end of the world, but something to bear in mind all the same.

RMMapView not deallocating memory in iOS? This could be the problem

I’m working with Mapbox at the moment – it’s a great tool for bundling offline maps into your apps. I recently noticed that my RMMapView’s weren’t deallocating as expected. These map views used by Mapbox, I’m not sure if they’re open source or not. Anyway, long story short, this was leading to a memory leak and I spent about a day trying to figure out why. The fix is pretty simple, just remember to set the “showsUserLocation” flag to false when you destroy the parent view. Something like:

- (void)viewWillDisappear:(BOOL)animated {
    if ([self isMovingFromParentViewController]) {
        _mapView.showsUserLocation = NO;
    [super viewWillDisappear:animated];

Hope this helps save someone a lot of time someday!

Attention Programming Lecturers: Let The Boys Play!

Coach Carter

Do you remember your first week of woodwork in school? It was pretty fun right? You probably made some ugly piece of nothing that had cracked joints and, despite being smothered in woodglue, you made your mother put it on the mantelpiece right next to her Twin Aynsley Swans. My masterpiece of a spicerack (with eyecatching clockface artistically installed just off centre) stood tall in our kitchen for many months. Its disappearance, still a mystery.

Can you remember your first week of programming lectures? I don’t, and I’d be surprised if you did.

Programming lectures for budding coders in their first two years are pointless. Its like taking a bunch of 13 and 14 year old woodworkers and talking to them about the benefits of a dovetail joint versus a tongue and groove.

Okay, so practical subjects (even sports training) have a level of theory involved but in my college experience, the theory outweighed the practical by a long way.

I love coding but it took me a while to realise I did. I can forgive students for having doubts about a career in programming when they’re stuck in a room with a lecturer going through some mind-numbingly boring progam, line by line by line. Add x to y. Now create a pointer to x. Deallocate memory from y. What happens to y? Where is y? Why is y?

This is not programming in The Real World.

There is no information, no technique or theory that a lecture can transfer more efficiently than a practical lab.

Programming can be discussed (and is fun to discuss!) when those involved have a good understanding of the subject and have their own views, and experiences, to speak of.

Coders want to code, let them. Or, in the words of Coach Carter, let the boys play!