I was part of the original development team that wrote “The Daily” for News Corp.

When “The Daily” was released, we expected some issues with it. Every developer should expect issues with a 1.0 release. We knew that it was written under a tight deadline and that there were most certainly sharp edges that we had not identified. The application was about as well received as we could expect from the user base. Some people do not like Rupert Murdoch. Some people do not like his teams slant on the news. That was expected. He is good at polarizing his readership.

The response we got from the developer community was a complete surprise.

Back In The Day

One of the things that originally attracted me to being a Mac/Cocoa developer was the community. I remember, fondly, watching two direct competitors sitting across a table from one another trading code solutions. Both knew that the other person was going to add it to their code base and they shared that information anyway. Both developers knew that it was the other developer that was driving them to make a better product. There can be no first place without a second place. Having a close competitor helps drive us forward.

Likewise, going to a CocoaHeads meeting you would see senior developers, developers who have been doing this for decades, sitting next to developers who are just now wrapping their heads around retain/release. They weren’t pained but instead looking upon the younger developer with the fondness of remembering what it was like when they started. Perhaps a bit of envy of all the exciting things this new young developer is about to learn.

Introducing The iPhone

When the iPhone was introduced we were all very excited to start working with it. Cocoa on a mobile platform! We could not wait to get our hands on it. The community embraced it immediately.

At first you had to hack your phone to write code for it but we quickly got an SDK. The community consumed that SDK with a hunger. The forums were active, the boards were active, the blogs were hot. Everyone wanted to share the new cool thing they learned or share the pain they just went through so that, hopefully, no one else had to go through that pain. The community was alive and prosperous.

I do remember many conversations about what would happen to the community with this sudden influx of developers. Many conversations started over what to do about these developers invading our platform. When I was involved in those discussions my response was always the same; we would welcome them to the community and teach them how we work. We would show them how great it is over here and that we share our toys. We would welcome them knowing that they would become part of us; not the other way around.

For the most part that is what happened. A large portion of these developers joined us. They shared; many new blogs started up, new books were written and our NSCoder nights and CocoaHeads meetings grew. The community became stronger with this influx of new developers.

A Disturbing Trend

More recently, perhaps within the last year, there has been a disturbing trend in the community. Surprisingly, sadly, this trend has not come from the new developers but from some of the older grey beards. There has been a trend to “piss on” things written by other developers. A new app comes out, good or bad, and the claws come out. People are quick to blast it; the more press it gets, the more it gets blasted.

A new photo sharing idea that got a lot of VC money? Blast it!

A new game concept? Kill it!

An old idea rehashed in a new way? Destroy it! Burn them!

He got more press than me? He must die in a fire!

I would almost expect this from new developers who just joined the community. However it is not the new members of this community that are all aflame. Most likely they are looking at these ideas and seeing how they can apply them or if there is anything to learn from them.

Sadly though, it is the older, established, members of the community that are turning so hostile. Gone is the sharing and the live/let live attitude that once made this community so great. Quite a few members are just full of piss and vinegar.

You can say what you want about me. I do not hold myself above others and know that my code sucks more often than not. I tend to share that opinion of my code often. I do not share what I have learned to gain glory but to just enjoy the act of sharing. Sharing makes me feel good.

What saddens me is this new desire to attack things that are either new or just in the media. Does the application suck? Maybe. But to curse the developers who wrote it? Not cool.

We as developer must remember that we are not the target for 99% of the software that is written. We are not the final judge on what will or will not work. If anything, we are the last people that should have an opinion on what is good or bad. We should be the ones that step back and watch what the “normals” do with it. They determine the success or failure; not us.

Some Thoughts From The Trenches

Not everyone who reads this blog is an independent developer. Not everyone who reads this blog writes code to fit someone else’s goals so I would like to share a few points from someone who is an independent developer and writes code to meet the expectations from others.

Deadlines are a bitch

Rarely do I have the opportunity to set my own deadlines. Companies who hire development shops almost always have a deadline in mind before the first line of code is ever written. More often than not, they have a deadline in mind before they have all of the requirements defined.

We, as developers, do not get to move those deadlines without massive and dire consequences. Usually our only opportunity to move them is at the beginning and then by saying “No, Thank You” to the project. Moving a deadline mid project usually has financial consequences.

Non-Developers Think This Is Easy

Non-developers see that one new feature as trivial. They see that crash as obvious and do not understand what the hell is taking so long. Business people are non-developers. The people who sign checks are business people.

To go along with my point about deadlines, getting paid involves meeting the requirements of the project within the deadline. These are almost always at odds with each other. The requirements are far greater than can be fit within the deadline. The response from the business team is “add more people, make it happen”. We as developers know that adding more people will actually slow things down.

The First 90% Is Easy

Developers frequently look at a problem and in their first blush say “oh I see how that works, that is simple“. That is a trap my friends. Everything looks easy at first. My favorite recent example is the carousel of The Daily. It is trivial right? No, there are a huge number of dependencies and features and bells and whistle and edge cases that all work their way into that piece of the application. The core of moving images around on the screen is trivial. Anyone can do it in a couple of hours. However to complete all of the requirements? Months of work. Personally I am still not completely happy with it. Maybe with 6 more months of polish it will get to where I would like to see it.

Never underestimate the requirements that go into a piece of functionality. Don’t assume that the developers are incompetent if it doesn’t work or perform the way you expect it to. Chances are that there are requirements that you as a user are unaware of.

Software Development Is Not The Only Cost

This is my one hostile point in this post. Whoever thought the iOS developers got paid $30 Million on “The Daily” is a moron.

“The Daily” is a lot bigger than just writing iOS code. There is a huge editorial staff, there is a server team, there is office space, hardware, travel, the list goes on and on. The actual iOS code was a small fraction of the huge effort that was put into creating a digital only daily newspaper; the first of its kind by the way.

Doing Something First Sucks

Unless you are trying to get into some record book, the person who does something first is rarely remembered. He who does it best is often remembered fondly. When you are the first to do something you rarely are the best at it. This is just a simple fact of life. When you are the first to do something you are making shit up as you go along. You are guessing. You have no clue what is going to happen when you release. The first MP3 player? Shit. First Tablet? Horrible.

Being first means that you are going to be superseded. Either by improving on your design or by being replaced by another team that took your idea and ran with it. The iPod blew away the first MP3 player. The iPad blew away the first Tablet. I look forward to seeing who becomes the greatest digital only daily newspaper on a tablet. Maybe that will be The Daily via iteration or maybe it will be someone else.

Conclusion

“Be excellent to each other” — Bill & Ted’s Excellent Adventure

This should be the guiding principal of the Cocoa Developer Community in my not-so-humble opinion. It is one of the things that make it great. New people are welcomed and the older members are honored.

There is no reason to hate other development efforts. It does not matter if that developer is better or worse than you. It does not matter what that developer wrote. There is plenty of room for all of us.

Be excited by his or her success. His or her spotlight does not put you in darkness.

I look forward to seeing each of you next week in San Francisco. If you see me please feel free to say hi.

WWDC is once again upon us; be excellent to each other.

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.