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.

App Store Dollars Don’t Go Further

So Apple are going to start pulling apps that reward social sharing/other app promotion from the App Store.

I’m pretty disappointed to hear this since the social share for extra cash option in my app Hipster CEO was a pretty popular bit of functionality. In the game, if you levelled up you could earn extra cash by sharing your achievement on Twitter or Facebook.

However, the discussion over on Hacker News has been around the suggestion that Apple should ban consumable in-app purchases completely. This topic  seems to split the community into two camps:

  1. iOS Developers who would be unhappy to see a drop in revenue.
  2. Gamers who loath IAPs as its difficult to tell just how much a game will “really” cost them.

I have written about mobile apps’  pricing problem before but its practically impossible to make & maintain a worthwhile app where the customer lifetime value is $1.99. I’m not saying consumable IAPs are the answer – I hate games that offer me the chance to hurry actions up by paying, they just feel kinda hacky to me. I’m happy to say that Hipster CEO has no IAPs but I sure wish I put them in there. The app has made me back the money it cost to develop but it’s not paying enough for me to maintain it (note: I’m building a new version that I hope will change all that). If you paid just under two quid for a game then you really don’t deserve an experience that lasts longer than it takes to drink a beer.

If you bought a second-hand console game and never played it twice, you wouldn’t complain. If you sank five bucks into a game at the arcade in twenty minutes, you wouldn’t complain. And if you paid over a tenner for a movie that sucked then you probably wouldn’t complain. All of these things cost more than the average app but for some reason, a certain group of people feel their App Store dollars should go that bit further.

That being said, I understand the complaint. I don’t think gamers mind handing over cash – its the lack of transparency that bothers them. If an app is marketed as free/cheap but really costs $50+ to get value out of it then it feels like a bit of swindle. Games like Farmville are a perfect example. However, gamers only have themselves to blame. The only alternative I can thing of over IAPs is subscription based models – games like Ultima Online – and they’re all dying out with World of Warcraft being the exception to the rule.

Maybe there’s a better way to monetise – I don’t know. If you’ve any suggestions then leave a comment.

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!

Consumers vs. App Developers: The Pricing Problem

A common piece of feedback regards my latest app is that it’s too expensive. It costs €2.69 ($2.99); considering the usage customers are getting from it, I (and, more importantly, they) consider it very good value for money.

It’s the first time I’ve really ever had to face the software pricing dilemma and it made me wonder:

“Why is there such a gulf between what an app developer & a consumer thinks their software is worth?”


When it comes to mobile apps, a common pricing comparison is the cup of coffee which generally costs about two bucks. Take the top 20 paid apps in the App Store right now and the average price is €2.10. This makes sense as the average consumer is willing to pay about 99c/€1.99 for an app.

However, once you go above the two quid price range, things get a little more complicated. It seems as though an app priced at €2.59 can no longer be considered an impulse purchase. A developer that decides to charge more than three bucks for their work can often be met with a ferocious anger that is usually more at home at a right-wing BNP rally.

Going back to our cup of coffee comparison, you’re probably happy paying two quid for a quick take-away. Chances are, though, that you won’t mind paying 40-50% extra for something more up-market and it’s here where our comparison breaks down. With mobile apps, we have a consumer expectation chart that looks a little like this:



Perhaps the problem is consistency. You generally know what you’re getting when you pick up your morning mug o’ joe. Apps are different. Their price often doesn’t reflect their true quality. Great apps sell for 99c; pure muck sells for €3.69.

Continue reading

Technology is moving towards fashion

Absolutely fantastic quote from Evan Williams of Twitter (found here):

As happens in most industries, value creation is moving up the stack. That is, companies make money in new technology-driven arenas at first by differentiating on performance, engineering, cost, etc. As industries evolve, core infrastructure gets built and commoditized, and differentiation moves up the hierarchy of needs from basic functionality to non-basic functionality, to design, and even to fashion.

For example, there was a time when chief buying concerns included how well a watch might tell time and how durable a pair of jeans was. There is still plenty of core technology to be built for the Internet, but the fact that you can now be a fairly sizable Internet company without ever needing to own (or even look at) your server hardware means a much bigger proportion of what companies do is add value on top what’s here. And one of the most powerful ways to add value is through design.