The tech industry will be in paroxysms of future shock for some time to come. Many will cling to their January-26th notions of what it takes to get “real work” done; cling to the idea that the computer-based part of it is the “real work.”

It’s not. The Real Work is not formatting the margins, installing the printer driver, uploading the document, finishing the PowerPoint slides, running the software update or reinstalling the OS.

The Real Work is teaching the child, healing the patient, selling the house, logging the road defects, fixing the car at the roadside, capturing the table’s order, designing the house and organizing the party.

Exactly! The iPad is genius and it will revolutionize not just books, magazines, etc., but it will revolutionize computing as we know it. I don’t know about you, but I’ve got the new SDK fired up and ready to start rocking some apps and it is a very exciting new platform!

Firstly, if you think that you only work with yourself and you can handle yourself, have a quick look at the I Am A Moron section of this post or this recent tweet by Kevin Hoctor.

Now a few years ago, I started work on a helpdesk ticketing system called tina. In the early days of tina development, I’d didn’t use any version control. I was frequently confused by my own code. I’d look at a piece of code and wonder, “What was I trying to do here?” or “When did I change this? Wait, did I change this?”. Occasionally, I’d tar-up my code for a historical record and I’m not sure now if I ever referred to those tarballs. When I eventually put the tina code into a Subversion repository I was much happier because of it.

With another project, that I wanted to put under version control, I found I had no less that 3 different versions of the code lying around on my hard drive. It look some investigation with diff in order to find out which one was the most current. Fortunately I didn’t have some files more recent in one copy and others more recent in another copy, but that could have easily happened.

With version control, it’s easy to find out what changed in my code, especially if I write useful commit messages. The most unexpected (and incredibly positive) side effect was that once I started using version control, the quality of my code went up dramatically. By tracking exactly what was changing between revisions, unwanted changes and debug code did not slip into the shipping code.

It’s worth noting that this approach goes hand-in-hand with unit testing. Version control lets you know what is changing and unit testing lets you know that your changes don’t result in regressions. As solo developers without QA teams or even a QA person, using these best practices seriously improves our ability to complete with larger organizations.

So, I recommend version control for any coding project bigger than a few lines of code. I used Subversion for a while and have now moved onto git.

My tips for version control success:

• Make small commits – don’t commit a whole day’s work if you wrote 2 features and fixed 8 bugs. That should be at least 10 commits. For sure, commit every-time you complete something – a bugfix, a feature, fixing a typo, a formatting change. It’s makes it much easier to find regressions and other issues later. Oh, and try not to work on many things at once especially if the changes overlap in the code.
• Compile before commit – each commit represents a known state of your code, so make sure the code compiles correctly without warnings or errors before committing.
• Diff before commit – before each commit, look over the diff of your current code compared with the last commit. Then you’ll know for sure what you are committing. If you don’t like part of the proposed commit, change it, diff it again, repeat until you like it and then commit.
• Write useful messages – When you commit a message is required is usually. Make sure it makes sense to you and to others looking at your repository.

1

UpdateSystemActivity(OverallAct);

The docs explain that you fire this every 30 seconds. On the surface, this looks like a hack and well, I don’t need a Carbon C call for that, I can fake a mouse event every 30 seconds.

This is out for good anyway, given that it doesn’t compile on Snow Leopard on x86_64. Carbon 64-bit will never arrive.

Turns out that the modern way to disable sleep uses IOKit. Apple has a doc for that too. Here is Listing 2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#import <IOKit/pwr_mgt/IOPMLib.h>
 
...
// kIOPMAssertionTypeNoDisplaySleep prevents display sleep,
// kIOPMAssertionTypeNoIdleSleep prevents idle sleep
 
IOPMAssertionID assertionID;
IOReturn success = IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, 
                                    kIOPMAssertionLevelOn, &assertionID); 
if (success == kIOReturnSuccess)
{
 
    //Add the work you need to do without 
    //  the system sleeping here.
 
    success = IOPMAssertionRelease(assertionID);
    //The system will be able to sleep again. 
}

With any sample code that I’m gonna try to use in my apps, I take the time to understand what’s going on, and to read the docs for that with which I’m not familiar. (Don’t you? That’s fine, just throw someone else’s potential garbage in your app. I’m sure it won’t bite until you least expect it.)

I’m getting back an IOPMAssertionID, so I proceed to look that up in the XCode documentation viewer. And there’s nothing to be found. A look in IOPMLib.h tells me it’s a 32-bit unsigned integer and therefore not very interesting.

So, I move on to look up IOPMAssertionCreate() to find that it was introduced in Leopard only to be deprecated in Snow Leopard in favor of IOPMAssertionCreateWithName(). IOPMAssertionCreateWithName() has an extra parameter over IOPMAssertionCreate(), and it’s a name as you might imagine. I don’t care for having deprecated calls in my code so IOPMAssertionCreateWithName() it is. Caveat: IOPMAssertionCreateWithName() is not publicly available in Leopard, so either use IOPMAssertionCreate() in Xcode3.1/Leopard or compile in XCode 3.2/Snow Leopard and IOPMAssertionCreateWithName() will work when run on Leopard.

The sample code from Apple lists two assertion types that you can use: kIOPMAssertionTypeNoDisplaySleep that prevents display sleep, and kIOPMAssertionTypeNoIdleSleep that prevents idle sleep.

My testing indicates that kIOPMAssertionTypeNoDisplaySleep actually prevents both display and idle sleep. The intended use case for this is clearly along the lines of playing a movie or running a presentation.

kIOPMAssertionTypeNoIdleSleep will still allow the display to sleep, but the Mac never sleeps unless it runs out of battery power. Use cases for this fall into the category of ‘computations that may not finish before the computer sleeps’, such as bouncing an mixed audio/video file to disk or rendering a 3D image, etc.

Here is an example project that allows you to test both behaviors. Note: The project uses IOPMAssertionCreate() and not IOPMAssertionCreateWithName() in order to compile on both Leopard and Snow Leopard.

In keeping with good practice, I have filed bug reports with Apple for pieces of the documentation that I see as missing.

With this recent influx of developers, most of whom we have welcomed with open arms, there are some who expect everything to be the same as the platform they came from and without bothering to learn or experiment have proclaimed our development tools to be “prehistoric”. This truly amazes me.

First, welcome to OS X and iPhone development. This is not the same language, platform and API you have been dealing with. Accept that or go home. We are not going to change it to suit you. We like it just the way it is.

We do things differently over here. Accept that or go home.

You have an interest in either OS X or the iPhone. To do a proper application for either one (barring a few edges cases), you need to learn Objective-C and Cocoa. Accept that … well you get the idea.

Objective-C has been around for a long time and it is a well thought out language. It is a runtime focused language and therefore things work differently than you are used to in your more structured environments.

Most of the time when these so called developers complain about Objective-C I simply roll my eyes and walk the other way. It is the sane thing to do. Never wrestle with a pig — you get dirty and the pig likes it. However, one particular “genius” has decided to out himself on his own blog. Of course I speak of none other than Jesse Ezell.

It is clear from this blog post that he has no interest in learning why OS X, Cocoa and Objective-C are different from his beloved Visual Studio but instead cries that it is too hard. I mean, seriously, complaining about NSObject vs Object? Perhaps he did not bother to learn that there is more than one root object in Objective-C? And then go to on and complain about MVC like its the devil’s music? Hopefully he is not the best that .net has to offer us!

But even with all of that, I read his post, chucked and moved on. It was not until he responded to the comments on that post that I decided to respond. It seems, from his perspective, that if a developer cares enough about their development environment to respond to his rant (and try to educate him!) that we are all “rabit elitists” out to get him!

First the word is rabid, not rabit. If you were using OS X you could have seen that it was misspelled and used the dictionary to figure out what the word meant. If you can’t even bother to run a spellchecker why bother writing at all?

Second, we care about our platform. We care about the code that we produce and how our applications look and are presented to the user. I know that is probably an extremely foreign concept where he comes from. But we care!

When developers come over here with preconceptions they do everyone a disservice. If they cannot even be bothered to pick up a book and read about the language to understand its fundamentals and its tools then why bother complaining about it. They are a waste of space. Move over and let someone who is willing to learn step up to the plate.

As for this developer’s ego and contempt for the developers on this platform — shame on him. His arrogance speaks towards his ignorance. He probably has written more lines of code in the past few years than I have. I have found that applications on Windows tends to take ten times as many lines of code as the same application would written on Objective-C and Cocoa. That does not make this developer better — if anything it makes him worse.

My suggestion is this: Pick up a book and read. You can even just read blogs like this one and avoid having to pay any money to learn. If a developer can’t be bothered then go home, we have no interest in you and certainly have no need for you.