Inspired by a recent popular post on HN about a guy who’s about to turn 30 and laments the lack of actually doing anything in his life…

Ideas

Some people regret the fact that they can come up with lots of great ideas, but cannot execute them. Others are frustrated that they can execute well, but cannot come up with an idea that is original or noteworthy. I personally find myself in the latter – but either way, people are going to be upset that they find themselves on one side of the balance and lack the ability to do the other.

I used to think that ‘ideas are nothing, execution is everything’. I think this idea has been spread wide and far by people who find themselves on the former side of the aforementioned scale, thinking: ‘I’ve got lots of ideas but haven’t prospered – therefore ideas must be worthless’.

Nowadays, I’ve come to the conclusion that ideas are just as valuable as an execution skillset. I’ve spend the last year executing well – i’ve come up with 10 original iPhone app ideas, and executed and shipped all of them in my spare time (and they’re not just “fart apps” – they are useful utilities). So by any measure, i think i can safely claim to be good at execution.

But here’s the rub – 2 of my apps are the only ones that have done well. And, to me, these were among the most poorly executed of my apps – they certainly didn’t take more than a couple weeks each to develop, with no marketing whatsoever. So, i’ve come to conclude that the ideas behind these apps, in terms of creating something that people actually want to buy, have made them successful.

For an opposing example, let’s pick on my first app, which allows you to enter your 20 favourite recipes. It will then choose a week’s worth of dinners at random, and compile a combined shopping list for you, and let you tick off the items as you purchase them. Now the market has decided that this idea isn’t worth paying $1 for. Hey, what gives? I executed pretty well – its not an awful app, why won’t people buy it? I can only conclude – the idea sucked.

So, if you’re what we call in Australia an ‘Ideas Man’, don’t be too upset – the world needs your great ideas just as much as it needs people like me who can execute on them.

Growing

And who’s to say you’re at one end of the scale or the other? Who’s to say that i’m good with ideas, therefore i must be awful at execution? Who’s to say that if i’m good at grinding out the work and getting things done, I mustn’t be very creative?

The two skills aren’t mutually exclusive. There’s no reason you can’t be good at both. If you’re great at one, there’s no reason you can’t grow to become good at the other. People can grow and change, if they believe they can. I mean, i’m sure you’re better at a lot of things than you were 10 years ago.

Becoming an Ideas Man

This part is for me: how to get better at ideas. James Altucher talks a lot about your ‘Idea Muscle’ – basically his idea is that the creative part of your brain is plastic, and if you practice enough, it will get better at coming up with ideas.

So his exercise is to spend 10 mins each day coming up with ideas. Just get a post it note, and scribble down 10 ideas each morning, to get the juices flowing. Start with writing down terrible ideas, just so long as you’re coming up with any ideas you’ll be working out your brain. And inevitably the ideas will improve with practice.

It’s worth a try – i’ll see how I go with it. If nothing else, it’ll provide me with, on average, as poor ideas as I already have – but due to the volume, there’ll surely be a couple of gems in there that’ll be worth executing on.

(And ladies, the reason I don’t say ‘Ideas Person’ is because in Australia, ‘Ideas Man’ is a bit of an amusing meme.)

Become an Execution Man

How to get better at ‘getting things done’? Well, for me, i’ve found the key is to start small. Recognise that you have a set ‘attention span’ and work on projects that fit into that span. And each time you ‘ship’, your confidence and thus your ‘attention span’ will bump up a notch.

For instance, my attention span for any project is about a month. If anything takes longer than that, i’ll become demotivated, disinterested, and bored – it simply won’t get done. So the key is – when starting a project, i think ‘can i do this in less than a month?’. If so, i’m golden – i’m confident i can get through it with my motivation intact.

If you bite off more than you can chew, you’ll end up with a string of large projects that you only got ½ way through and abandoned them. Don’t be tempted to take on those large projects – if it’s ego, or ambition making you do it, well swallow your pride and try biting off something a bit more ‘bite sized’.

Babies start with small spoonfulls of smooshy stuff: if you feed them too much they’ll spit it out. You’re like that – start with small smooshy projects, and as you personally grow in your ability to execute, work your way up to a massive steak of a project.

The key is to start small, and take on bigger projects as your capacity grows bigger. Just be sure to take on projects that you can finish – because each time you finish, your confidence will grow. Don’t take on projects that you can’t finish – because when you fail, you’ll shrink. As you stick to achievable projects, your confidence, attention span, and motivation will grow.

Keep growing :)

This is a small library designed to make it extremely simple for you to sync your iOS app’s ‘Documents’ folder’s files and subfolders to a folder on Dropbox.

Recently Dropbox brought out ‘sandbox’ api keys, which mean that your app only gets access to a single folder such as Dropbox/Apps/MyAppName. The idea is that this library is to be used with that setup.

Unfortunately the normal Dropbox API only gives primitive methods for getting metadata, uploading and downloading specific files – it doesn’t give you the simple ‘sync this folder now please’ functionality that you’re probably used to in the desktop variant. So this library hopes to deal with that.

It’s been extracted from an app I’ve been writing to help keep track of your cars' oil changes. You can see the app on http://apps.splinter.com.au. If you find this library useful, please buy my app, it may also be useful! Unless you live in appsterdam, sorry but I don’t have any apps for keeping track of the oil changes on your bicycle ;)

Where to get it

github.com/chrishulbert/CHDropboxSync

How to use

The idea is that in one view controller of your app, you’ll have a ‘sync’ button. In this controller, you’ll want a retain property to keep the syncer object alive. And this controller will be a delegate of the syncer, so it’ll know when to dealloc the syncer by nilling out the property.

Eg, in your view controller:

#import "CHDropboxSync.h"
@property(retain) CHDropboxSync* syncer;
@synthesize syncer;

// Do the dropbox sync. This takes care of all user alerts
- (void)mySyncButtonWasTapped {
    self.syncer = $new(CHDropboxSync);
    self.syncer.delegate = self;
    [self.syncer doSync];
}

// Delegate callback from the syncer. You can dealloc it now.
- (void)syncComplete {
    self.syncer = nil;
}

- (void)dealloc {
    self.syncer = nil; // Probably a good idea to do this
    ...
    [super dealloc];
}

Note that it is up to you to handle the normal Dropbox linking process.

Sync strategy

You may choose to write your own syncer, eg you may wish it to be a background process instead of modal which i’ve chosen to. Or you may be curious about the two-way sync strategy. It’s very simple algorithm, so I wouldn’t recommend it for life-critical apps, but it does work well for my app:

• After each synchronisation, make a note of all files/folders in the local documents folder, and their last modified dates, and store it for use in the next sync. This is called the previous sync status.
• When syncing, it compares files and folders locally vs remotely.
• If a file exists in both places but the last modified dates are different, it syncs to use the newer one
• If a file/folder only exists in one place, it uses the previous sync status to determine if the file was deleted or added since the last sync.
• If the item was deleted in one place since the last sync, it will be deleted in the other place.
• If the item was added since the last sync, it will be uploaded/downloaded to the other place.
• The code is intentionally clear (not concise) so you should be able to read it to get how this works.

Dependencies

• ConciseKit
• DropboxSDK v1.0+

Other options

• There is also jessegrosjean’s DropboxSync, however it does not work with the latest Dropbox API. You should check it out if you’re not happy with CHDropboxSync.

License

MIT license – no warranties!

I found out the hard way, after lots of time wasted then a bit of googling, that NSFileManager’s enumeratorAtURL crashes! Don’t use it.

So if you need to recursively search a folder in objective-c (on the iPhone, in my case), grabbing all the attributes of the files (such as last-modified date), here’s an alternative way to do it. Please note this example uses ConciseKit:

NSMutableSet* pathsToSearch = $mset($.documentPath);
while (pathsToSearch.count) {
    // Pop a path to search
    NSString* pathToSearch = [pathsToSearch anyObject];
    [pathsToSearch removeObject:pathToSearch];

    // Scan it
    NSArray* contents = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:pathToSearch error:nil];
    for (NSString* item in contents) {
        // Item is a file or a folder
        NSString* itemPath = [pathToSearch stringByAppendingPathComponent:item]; // Get the full path for it

        // Get the attributes
        NSDictionary* attribs = [[NSFileManager defaultManager] attributesOfItemAtPath:itemPath error:nil];
        BOOL isDirectory = $eql([attribs $for:NSFileType], NSFileTypeDirectory);
        BOOL isFile = $eql([attribs $for:NSFileType], NSFileTypeRegular);
        NSDate* modified = [attribs $for:NSFileModificationDate];

        // Recurse if its a folder
        if (isDirectory) {
            [pathsToSearch addObject:itemPath];
        }

        // Do something with it
        NSLog(@"%@; %@", itemPath, modified);
    }
}

Here’s how to get the start of a day in Objective-C:

- (NSDate*)startOf:(NSDate*)date {
    int comps = NSYearCalendarUnit | 
        NSMonthCalendarUnit | NSDayCalendarUnit;
    NSDateComponents* dc = [[NSCalendar currentCalendar]
        components:comps fromDate:date];
    return [[NSCalendar currentCalendar] dateFromComponents:dc];
}

This document is for one day in the future, if I find myself with a team of iOS devs and i need to get them to follow some ‘best practices’ when it comes to manual memory management, or hopefully some others out there in the world will find it useful.

Principles

• Keep memory management code to a minimum
• Avoid writing retain or release yourself
• Use properties instead
• Use autoreleased static constructors, eg: [NSArray array]
• If you have to use alloc/init, autorelease on the same line
• Use ARC for any new projects

Properties

Use properties for everything you need your Here’s how I suggest you declare properties, in your header:

@interface MyClass
@property(retain) NSMutableArray* myArrayProperty;
@end

Notice I don’t bother with ‘nonatomic’ properties. I don’t see any value in typing that unless you’ve got high-performance-critical code, in which case you should probably be re-thinking your algorithm or dropping down to C. Keep the typing to a minimum so we don’t all have RSI when we’re old.

And in your class, lay things out like this:

@implementation MyClass
@synthesize myArrayProperty;

- (void)dealloc {
    self.myArrayProperty = nil;
    [super dealloc];
}

Notice how the dealloc is directly underneath the synthesize declarations: this is so that whenever i create a property, i’m reminded to nil it out in the dealloc. Setting the properties to nil gets the synthesized setter to release any value if necessary. Important: if you don’t use the ‘self.’ then the synthesized setter won’t be used.

One thing worth noting, is that if you’ve got Key-Value Observers, they’ll be notified as you set these properties to nil and be passed a half-dealloced object, which will probably cause crashes. So if you’re using KVO, do the following instead: [myArrayProperty release]; myArrayProperty=nil;. Having said that, I’ve never found a need for KVO, and recommend against it for this issue. I personally prefer NSNotificationCentre.

If it’s a controller, I don’t really worry about how this exposes all my properties publicly. However, for business logic classes, it’s probably worth declaring the properties in a private category in the .M file instead of in the .H, so that they’re not externally accessible:

// Privates
@interface MyClass()
@property(retain) NSMutableDictionary* someProperty;
@end

@implementation MyClass
@synthesize someProperty;

- (void)dealloc {
    self.someProperty = nil;
    [super dealloc];
}

One more thing to keep in mind is that, for simplicity’s sakes, I exclusively use synthesized properties. I’ve simply seen too many bugs in hand-coded getters/setters.

Static constructors

Any static constructors, eg ‘NSArray array’ will return for you an autoreleased object. I always use these in preference to an [[[ABC alloc] init] autorelease], because generally they are cleaner and involve less typing. Plus you don’t have to think about when the value can be released, it’ll just get picked up by the autorelease pool after your function is done with it.

If you want to keep the value around for the duration of your class instance’s existence, do something like this:

self.myProperty = [NSArray arrayWithObjects:a, b, c, nil];

Alloc / init

As the saying goes: ‘if you init you own it’. Some classes don’t have static constructors, and you’ll have to resort to allocing/initing instances yourself. In these situations, I always recommend autoreleasing immediately after init'ing, that way i can treat them the same way as I do the static constructor instances. Also, if they’re on the same line, i don’t need to look down the code to see where it is autoreleased.

If you want to keep the value around for the duration of your class instance’s existence, do something like this:

self.myProperty = [[[Something alloc] init] autorelease];

IBOutlets

For any IBOutlet properties, I recommend usually using ‘assign’ properties, for these reasons:

• You don’t need to worry about releasing them if the view gets unloaded and reloaded due to low memory
• You won’t need to release them in your dealloc
• The view will retain them for you so you won’t need to retain them

Although it has been pointed out to me that in the following cases, you may wish to make them ‘retain’ properties:

• Some IBOutlets may not be views, and thus not retained by their superview
• If you ever access an outlet property when the view is unloaded, you’ll have a dangling pointer crash

If you decide you need to make them retain properties, you’ll have to nil them out in both the dealloc and the viewDidUnload methods.

ARC

For new projects, ARC is definitely the way to go. Some libraries that you wish to include won’t be ARC-compatible yet, which is fine: you can disable ARC on a file-by-file basis for those.

To do this, open up your project node in the project navigator, select your target, go into the build phases tab, then expand the ‘Compile Sources’ section. Select all the files you need to disable ARC for, then press enter, and type -fno-objc-arc into the box that appears.

Summary

If you follow these principles, you should be able to keep your memory-management code to a minimum, and focus on the task at hand. If you ever see a ‘retain’ or ‘release’ anywhere, you’re probably making more work for yourself than you need to. Keep it simple!