Here’s the entire source:
alias dim="git diff | mate"

It should automatically pick the “Diff” language for you, but if not, then just pick it from the chooser at the bottom of the window to get the nice highlighting where deleted lines are in red, added lines are in green and markers are in blue.

There’s too many things to write about so I’ll just focus on two things that stick out in my mind: Blitz Talks and MacRuby.

I go to NSCoderNightDC and we have a nice core group of Mac and iPhone Devs who show up every week and eat Strawberry Napoleons. We also code and talk about design. Well 3 of the guys proposed Blitz Talks and got accepted.

Rob hit it out of the park with his Briefs iPhone prototyping tool. Jose actually created a Brief on the way from the airport to the hotel. He was kinda nervous beforehand in the hotel room but he practiced his presentation a few times on me and was really well prepared. His slides were top-notch but I think the idea is what really captivates people. I’m personally a big fan of fake-powered prototypes - prototypes powered by objects that return canned responses, but I’m definitely going to try out Briefs on upcoming iPhone engagements.

Jose did well with his presentation about the different types of contexts that an iPhone user would use different apps in. I’ve seen him give this talk before so it was interesting to see how he pared it down to fit in the much tighter 5 minute time frame.

Mark gave an interesting talk about how to do video right for Mac and iPhone screencasts and demos. I have a lot to learn about this and I’m hoping to work with Mark on a screencast sometime in the near future for Webnote.

There were many other Blitz Talks and I think they really were a nice Change of Pace that I haven’t seen in other conferences. Wolf amped it up even further by providing an animated radar / pie that kept filling up as the talk progressed.

MacRuby was the other big surprise for me. I had been tracking RubyCocoa and had seen the early MacRuby demo at RubyConf 2007. I’m a former Smalltalker and current Rubyist. I do all my automated build processes in Ruby and I’ve also created various non-Rails Ruby server-side components for clients. Plus I did Ruby on Rails for a few years. So I’ve been wanting to make Mac apps with Ruby, except one thing kept holding me back: I don’t want to show everyone my source.

Obfuscation is not a problem with server-side Ruby. The users only see what you expose via the web or other ports. They only see what’s rendered to them or the API that you expose.

Client-side Ruby is another world altogether. Users learn that they can peek inside application packages and if you’re writing Ruby, they can see your source. I’ve asked this question at WWDCs in the past and the answer was usually that its not a big deal and that you should just keep innovating. But we don’t just leave our Objective-C sources lying around, do we?

MacRuby will soon solve that, or I hope it will, with his AOT (Ahead Of Time) compiler. Or as it is known in the C/C++/Objective-C world: a compiler. LOL. So with the AOT, we will be able to write Cocoa apps in Ruby, compile them and run them on Mac. (And maybe iPhone - the jury is still out on that.) Which means that people can’t just look at your Ruby source. Even better, there is the HotCocoa project which provides useful macros / shortcuts for common Cocoa idioms.

Why use Ruby to write Cocoa apps? Ruby can be more concise, there are more libraries to choose from and the testing/mocking frameworks are better. On the other hand, the debugging story is still hazy.

I’ll be trying out MacRuby soon and I’ll post what I find. They’re currently at 0.4 with a 0.5 on the horizon, with nightlies for Snow Leopard available and the latest source available in both Subversion and Git.

1. Get a branch. This is similar to “svn checkout” or “git clone”.
bzr branch lp:sparkle

I admit it is kind of cool to have such a short name here like “lp:sparkle” due to bzr’s integration with Launchpad, which is sort of like SourceForge or GitHub.

2. Later on, you might need to get the latest version. This is similar to “svn update” or “git pull”.
bzr pull

3. To make sure you have the latest, you can check what version you have. This is similar to “svn info”. The closest to this in git is “git log –max-count=1″
bzr version-info

You can compare that version to the latest one in the main Sparkle branch.

iPhoneDevCampDC is going to be the evening of July 31st and then all day August 1st. We are looking for sponsors for the event, so if you are looking to get your company in front of iPhone developers, please contact us.

We will be limiting the number of attendees this year to 50. Ticket registration will start next week around the beginning of July. This is a BarCamp-style conference, where the attendees present the sessions, so if you’re planning to attend, start thinking of what session you could present. We won’t have time for everyone to present, but if everyone comes ready, then we’ll have great topics for everyone to choose from.

There’s a website for iPhoneDevCampDC with some more details and we’ve also started tweeting at @iphonedevcampdc, where we’ll publish news about the event (like when registration starts.)

1. When in doubt, file a bug.
Mac OS X and iPhone to some extent are a democracy, where bugs count as votes. Apple uses your bug filings to see which things should get fixed and which things should get implemented. I’d say at least half of the Q&A could be summed up by: “Please file a bug.”

At first it seems like the Apple Engineers are just passing the buck, but really what they’re saying is either:
a. “Yes that seems like a good idea, but I need you to file a bug so I can justify working on this, be it a bug or a new feature, to my manager.” or
b. “I’m not sure about that, but file a bug and if we get enough of those, we’ll work on it.”

BTW here’s how to file a bug in Apple’s Radar bug database.

2. Instruments is as important as Xcode and Interface Builder.
Every Mac and iPhone Developer is familiar with Xcode and Interface Builder. But Instruments is just as important, especially with the relatively limited hardware of the 1st gen/3G iPhone and 1st gen iPod Touch. There were a lot of good sessions that featured Instruments that are worth watching when the session videos come out.

Even on Mac OS X, profiling your application to improve its performance and memory usage is important to do with Instruments.

Another interesting tool to delve into is dtrace. Its the technology that underlies some of the instruments in Instruments.

Also I heard a new phrase “There’s an Instrument for that.” If you have access to the Snow Leopard betas (and you should get it via ADC), then check out the new ones that are available. If you don’t see one that fits your needs, you might consider filing a bug requesting it.

3. WWDC 2010 will hopefully occur in a bigger venue.
WWDC 2009 sold out the fastest as I’ve seen any (and perhaps the fastest ever?) 60% of attendees were new attendees. So there’s still another 3000 or so people who were at WWDC 2008 and previously that might have attended if they had purchased their tickets sooner. Add to that another 2000 or so developers that see the market growing due to the $99 iPhone and you’re over 10,000 developers that could be attending WWDC 2010. That’s roughly double the attendance.

OK I admit that I don’t really like lines and such, but the keynote line ran completely around the block back to the front! Moscone West was just overflowing with Mac and iPhone developers this year. I’m hoping that next year’s WWDC 2010 will be say in Moscone South or Moscone North. It might not be as cozy but it should give some breathing space and allow for more developers (including those who have longer purchasing cycles) to attend.

The schedule looks pretty cool and it is being sponsored by Viget Labs and Relevance. I’ll probably be dropping by.

To workaround this, I was tediously moving the akismet directory or the plugins directory to login and then moving it back afterwards.

I finally fixed it by looking in the plugins/akismet/ directory and found an akismet_mmddyyyy.cache file and deleted it.

Lesson learned: Delete *.cache files in your plugins/akismet/ directory whenever you upgrade your Wordpress blog.

UPDATE (2009-06-18): This problem happened again and I solved it by deleting any .* files in the plugins/akismet/ directory. Specifically, I found .akismet.bak.php and .readme.cache.php.

If you missed it, you can still get the slides: “How to use TouchJSON in your iPhone Apps“.
As an added bonus, I also uploaded the sample iPhone project which shows how to search Twitter using TouchJSON!

I went to login and it didn’t let me in. I had this problem before so I renamed my wp-content/plugins directory. I logged in and there were 0 comments in the system! Yikes! All my Wordpress comments had disappeared!

I went into the wordpress MySQL database and when I typed in “select * from wp_comments;” it replied back with the ominous but helpful: “table wp_comments marked as crashed.” Alright, I think we can fix that. I typed in “repair table wp_comments;” and it reported that all was well again.

I went back into my Comments admin and found that there were 10,445 spam comments! 10,445 - spam is bad but I didn’t realize it could crash your Wordpress comments bad.

Alright so after verifying that all my approved comments were back, I had lunch. I came back two hours later and found I had 100 emails - all for pending spam comments. Oops - I had disabled the Akismet spam filter when I renamed my plugins directory earlier.

OK so to make sure this doesn’t happen again in the future:

1. I went to Plugins / Akismet Configuration and checked the box “Automatically discard spam comments on posts older than a month.”

2. I went to Comments / Spam and pressed the button “Delete All Spam”. That should tidy up the wp_comments table and the entire Wordpress database quite a bit.

Pitfall: You may get this message in the Build Results: “Couldn’t register PurpleSystemEventPort with the bootstrap server. Error: unknown error code.

Overcome it by: This generally means that another instance of this process was already running or is hung in the debugger.”
If you get this, it just means that the iPhone Simulator is already running. Quit the Simulator and then run your tests again.

Pitfall: You get the error “Unable to send CPDistributedMessagingCenter message named SBRemoteNotificationClientStartedMessage to com.apple.remotenotification.server: (ipc/send) invalid destination port”.

Open up the “Tests” target by double-clicking on it, go to the Properties tab and clear out the Main Nib File text field.

Pitfall: XCode is not executing any of your unit tests. Instead it hangs at the line: “Running 1 of 1 custom shell scripts…”

Open up your Tests target, go to the Properties tab and clear out the Main Nib field. Do a Clean All. Then Build and your tests should run.

Since we discussed clearing out the Main Nib text field twice here, I think we should discuss why this would work. It will give us insight into how the Google Toolbox for Mac unit testing framework operates.

What I think it is related to is the Main Nib loading and that Nib having an App Delegate which implements applicationDidFinishLaunching. This sometimes causes everything to not work because GTMIPhoneUnitTestDelegate’s applicationDidFinishLaunching not to get called - and this is what runs the tests. Clearing out the Main Nib field will cause this potential collision to not occur and GTMIPhoneUnitTestDelegate will function properly by finding and running your unit tests.

Have you had run into any other pitfalls while doing iPhone Unit Testing? If so, feel free to leave a comment here. I also encourage you to visit the Google Toolbox for Mac discussion group on Google.