East Coast Cocoa Conferences

I’ve been thinking about upcoming Cocoa (Mac and iPhone) conferences for the past week, ever since the last NSCoderNightDC.  Daniel posted his big uber list of Fall Conferences, so I won’t repeat that.  Instead, I’ll focus on East Coast Cocoa Conferences.  Actually I’ll expand it out to be the whole Eastern US.

First up is Voices That Matter in Philly, PA on October 16-17.  Early bird pricing runs until September 10th.  Daniel’s got a nice coupon / discount code that’s worth another $100 in savings I think.

I’m probably going to head up there.  Never been to a VTM before but I’ve heard they’re good.  They’re held twice a year I think and I missed the last one in Seattle, which was right after the iPad DC conference we had earlier this year.

Second, I hear that rising up from the ashes of C4 is SecondConf in Chicago, IL from October 22-24.  That is the next week right after VTM.  Not too many details yet, but they are having BlitzTalks (aka Lightning Talks with an awesome Blitz app to drive it.)

Third, there’ll hopefully be at least two if not more Apple Tech Talks.  I went to one in December last year in New York City.  It’d be even better if there was one further south, say in Washington DC, Baltimore or Philadelphia.

There’s three other conferences too, but they’re all in the West and I’m trying to stay closer to home since we had a new addition to the family in the past few months.

Update: There is a Fourth east coast Cocoa conference: Cocoa Camp in Atlanta, GA on September 25th.

C4[3] Blitz Talks and MacRuby

I just came back from C4[3] – an Independent Mac and iPhone Developer Conference in Chicago. Wolf and Victoria host it and I saw Daniel Jalkut helping out along with a few other folks. In case you’re not hip to the zero numbering scheme, this is actually the 4th iteration of the conference. I went last year to C4[2] and this year was even better in my opinion.

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.

Getting Sparkle from source (using bzr as compared with svn and git)

A few notes about getting Sparkle, the widely used framework for updating Mac OS X apps, from source:

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.

Three things I learned at WWDC 2009

I went to WWDC 2009 last week and I learned 100 things. Unfortunately, 97 of them are under NDA, so I’ll just share with you three things that aren’t secret.

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.

How to use TouchJSON in your iPhone Apps

I gave a presentation at NSCoderNightDC a week ago on “How to use TouchJSON in your iPhone Apps.” It was great fun and we had a little iChat Screen Sharing session going on with Rob aka @capttaco so that everyone could see.
TouchJSON Presentation First Slide

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!

Pitfalls That You May Encounter when Running iPhone Unit Tests and How to Overcome Them

We have come to the last part of this series on iPhone Unit Testing. In this post we will cover pitfalls that you may encounter when running iPhone unit test and how to overcome each of them.

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.

Getting Started Writing iPhone Unit Tests

Alright, well hopefully you have read the first two parts of this series. If not, then go back and read Is iPhone Unit Testing Possible? and How to Create an iPhone Project in Xcode That Can Run Unit Tests.

Make sure that you have an iPhone Project that is already set up for unit testing. You can either follow the steps in those last two posts or you can download a pre-made “example1” iPhone Project that can run unit tests that I uploaded to GitHub.

In this tutorial, I will be showing you, the iPhone Developer, how to get started writing unit tests for your iPhone App. I will be doing this in the TDD style – where TDD == Test-Driven Development. In other words, we will write the tests first. You don’t have to do it this way, but I thought I’d show it to you since it is a nice practice that was ingrained in me from the Ruby on Rails community. This is not to say that it started in Rails – it really started back in the Smalltalk days with Kent Beck and the other original XPers (eXtreme Programming). But being involved in the Smalltalk, Java, Objective-C and Ruby communities in my career since 1995, I haven’t been seen such testing dedication as I have in the Ruby on Rails community. I hope it is something that really spreads in iPhone community as well.

So, how do we get started? Or in TDD-speak, how do we write our first failing test? You write failing tests first as sort of a TODO to yourself as a programmer. When you get it to pass, then you can mark off your TODO, but in a nice programmatic way.

You will need to create a Test Class. Then you’ll add a Test Method. This should reference a non-existent Class, which you’ll then proceed to flesh out. This is the classic Test Driven-Development (TDD) way of testing.

Create a new group with Project > New Group. Name this new group “Tests”.

Create a new Test Class with File > New File… and choose Cocoa Touch Classes / NSObject subclass.

Name your class “FooTest.m”. Make sure that it is only a member of the Tests target.

Run the tests now by pressing the Build button. Make sure that the “Tests” target is selected in the Active Target dropdown and “Simulator” is chosen a the Active SDK. Notice that the Test Class isn’t being included yet:

Test Suite '/Users/louie/builds/Debug-iphonesimulator/Tests.app' started at 2009-02-19 14:43:32 -0500
Test Suite 'SenTestCase' started at 2009-02-19 14:43:32 -0500
Test Suite 'SenTestCase' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'GTMTestCase' started at 2009-02-19 14:43:32 -0500
Test Suite 'GTMTestCase' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite '/Users/louie/builds/Debug-iphonesimulator/Tests.app' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds

This Test Class doesn’t know it is supposed to contain tests yet. Let us change that.

Change the import statements to include “GTMSenTestCase.h” This is the Google Toolbox for Mac version of SenTestCase. This enables your test cases to be found by the GTM RunIPhoneUnitTest script. It also adds some additional capabilities we will cover later.

Change the superclass to be “SenTestCase.”

Your class header FooTest.h should now look like:

#import "GTMSenTestCase.h"

@interface FooTest : SenTestCase {



If you run the tests now, you’ll see that FooTest is now being included:

Test Suite '/Users/louie/builds/Debug-iphonesimulator/Tests.app' started at 2009-02-19 14:44:30 -0500
Test Suite 'SenTestCase' started at 2009-02-19 14:44:30 -0500
Test Suite 'SenTestCase' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'FooTest' started at 2009-02-19 14:44:30 -0500
Test Suite 'FooTest' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'GTMTestCase' started at 2009-02-19 14:44:30 -0500
Test Suite 'GTMTestCase' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite '/Users/louie/builds/Debug-iphonesimulator/Tests.app' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.002 (0.002) seconds

However, with 0 tests, FooTest is pretty boring. Let’s spice up FooTest. Switch over to FooTest.m. You can quickly do this with the keyboard shortcut Command + Option + up arrow.

Now add a Test Method. Test Methods are where the work happens with testing. They must start with “test” and the first character of “test” must be a lowercase “t” in order to be found by the test runner script.

Add this piece of code:

- (void)testBar {
	Foo *instance = [[[Foo alloc] init] autorelease];
	STAssertEquals(@"bar", [instance bar], nil);

Try to Build. You’ll get 3 errors. They all relate to Foo not being declared in FooTest. This actually is good! Well, in the classic TDD sense. What we have done is written what we want to happen when a client calls Foo and what the client expects back when it calls the bar method of Foo. Specifically, we want it to return the NSString @”bar”. This can also serve as good documentation for future programmers who are inspecting this code to see an example of how to use Foo.

Now let us fix these errors:

Select the Classes group.
Create a new Class with File > New File… and choose Cocoa Touch Classes / NSObject subclass. Yes, this is just like how we created a new Test Class. They are the same because we haven’t created a new template for a Test Class.

Name your new class “Foo”.

Make sure that it is a member of both of the targets “example1” and “Tests”. The reason we want this is because Foo should exist in the main application but also should be available for testing. Going back, we can see that FooTest was only in the Tests target because we don’t want to ship our tests with the application. This will make it lighter and thus quicker to download when a user decides to purchase it from the App Store. Quicker downloads should mean a quicker path to riches! :)

Now try building again. Still 3 errors? Yes, because we need to make Foo known to FooTest.

Go to FooTest.h and add the line:

#import "Foo.h"

Now build again. You should have two errors now and four warnings.

Now Xcode tells you that “warning: ‘Foo’ may not respond to ‘-bar’.” Again this seems wrong, but this is actually a good thing with classic TDD. This just means that we need to declare the method bar. So let us do just that.

Go to Foo.h.

Add the method declaration:

- (NSString *)bar;

Go to Foo.m.

Add the method implementation:

- (NSString *)bar {
	return @"bar";

Now build and you have success! This is known in TDD-speak as “green bar.” When you had failures due to errors/warnings, that was “red bar.” This had to do with the graphical indicators of the tools at the dawn of TDD. We can just call them “success” and “having test failures.”

This method is what I’ve used over the past year to help ensure good code quality in that iPhone apps I have built for my consulting clients. At this point, you know enough to be able to write unit tests, the iPhone way with the help of Google Toolbox for Mac. You can start to use more generic unit testing techniques that you may have used in other languages. There are also some iPhone-specific testing techniques that I will cover in the future if people are interested.

Is iPhone Unit Testing Possible?

Lessons Learned: Unit Testing iPhone Apps

This is the first part of a four part series on How to do iPhone Unit Testing. You could also call it Lessons Learned from Unit Testing iPhone Apps. I’ve learned a lot of lessons over the past year doing iPhone Consulting and I want to share them with everyone.

Here is the schedule for this series:

  1. Is iPhone Unit Testing Possible?
  2. How to Create an iPhone Project in Xcode That Can Run Unit Tests
  3. Getting Started Writing iPhone Unit Tests
  4. Pitfalls That You May Encounter when Running iPhone Unit Tests and How to Overcome Them

This is targeted at iPhone Developers, especially those who have done unit testing in other languages and frameworks.

A bit of backstory: My name is Luis de la Rosa and I am an iPhone Consultant. I have been making iPhone applications for clients the past year through my company Happy Apps LLC. I have also been developing Mac OS X apps and Rails apps for the past 3 1/2 years and in other languages for 14+ years now.

To start off, you might ask: Is iPhone Unit Testing even possible? I don’t see it as an option when creating a New Target in Xcode like I can with Mac OS X applications.

Apple says it is not possible. In the “Xcode Unit Testing Guide”, it says

“iPhone OS Unit Testing Support: Unit tests are not supported for iPhone applications.” 

But what this really means is that Unit Test Bundles, which are dynamic, are not allowed on iPhone because dynamic bundles of all kinds are not allowed on iPhone. So the normal way of adding Unit Tests to an Xcode project is not available to you. (iPhone projects are Xcode projects.)

However, there is a way to add unit tests to an iPhone project!

To understand why, you need to understand the two types of targets available to an iPhone project. These two are:

  1. Application
  2. Static Library

To put it another way: the normal Unit Test Bundle target for Mac OS X applications is not available because there are no Dynamic Bundle targets. A Static Library target cannot be executed and we need some sort of execution in order to run the tests. So we need to somehow use an Application target to run our unit tests.

The Application target will need to do the following things:

  1. Find all the unit tests in your Project
  2. Run all the unit tests
  3. Report the results of running the unit tests. This should include the number of successes and failures overall and also the results of each individual test.

You could do this from scratch, but fortunately there are already some diligent and ingenious engineers out there who have already done the work for you.

In tomorrow’s segment: How to create an iPhone Project in Xcode that can run unit tests.

If you found this helpful and/or interesting (hopefully both), please leave a comment.

NSCoderNightDC is going to be studying iPhone SDK Development

NSCoderNight DC is going to be switching gears tonight and starting to study the new Beta Book from the Pragmatic Programmers titled iPhone SDK Development. Why the switch? Because the NDA has been lifted.

It is the first book of its kind that I know of. I ran into one of the authors, Marcel – who I also knew and respected from the Rails world, at C4[2] and he told me about the book.

So if you are in the Washington DC area and interested in learning about iPhone development, we’ll be having weekly meetings starting at 7pm every Tuesday at:
La Madeleine – Bethesda, MD
7607 Old Georgetown Rd
Bethesda, MD 20814
(301) 215-9139‎

More detailed driving / parking directions to La Madeleine – Bethesda, MD

See you there!

10 Things I Learned from C4[2]

I went to C4[2] last month. For the uninitiated, C4[2] is the third (yes we count from zero) conference of its kind, a conference for independent-minded Mac and now iPhone developers, held annually in Chicago, Illinois. It is run by Jonathan “Wolf” Rentzsch, who is an independent Mac / WebObjects consultant.

It was a great gathering and I look forward to going to C4[3] if I have the opportunity. So I thought I’d share my top 10 things that I learned at the conference:

1. Getting like-minded developers together at one place generates a lot of energy, enthusiasm and knowledge sharing.

I think it’d be great if we could replicate what has been happening in the Ruby community and start to have Regional Objective-C conferences. This has started to happen with the iPhone Dev Camps already, but it’d be great to have combined Mac / iPhone Regional conferences, so devs that can’t afford to travel to Chicago and San Francisco can still get involved and interact with each other in Washington D.C., New York, Seattle, Denver, and wherever else we all are.

2. iPhone development has really come into its own, but its knowledge continues to be restrained by the NDA.

We started off with a presentation by Craig Hockenberry of how iPhone has changed the way humans interact with computers in much the same way the mouse did. We ended with a programming contest called Iron Coder (a play off of Iron Chef) which traditionally has been with Mac OS X APIs but this time was on iPhone with an iPhone API. I finally participated (after helping with past Iron Coders by providing licenses of WebnoteHappy as prizes), collaborating with Joe Pezzillo to produce CoreParanoia and also contributed a tiny bit to Jose Vazquez‘s 2nd place Tipster.

The rest of the presentations were not iPhone focused, but there were mentions of it throughout. And it seemed like having an iPhone was part of the requirements for attendance. I personally got a live demo from Tim Burks of his iPhone app Masyu which is a pretty fun puzzle game.

The problem however was that the NDA on iPhone development stifled a lot of the conversation. This generated a lot of complaints and even a t-shirt that rebelled against it.

3. Security is scary, but not as scary as not succeeding.

There was a wild presentation on security that said: don’t pretend to be a security expert. Stick to using the Keychain or bcrypt for passwords, use openssl or gpg. Don’t use installers or open up listeners on ports. Don’t write directly into the DOM. But all of that doesn’t matter if your business doesn’t succeed if you don’t have a nice looking application and it is unstable or slow. Also, filter user-supplied content and write a fuzzer for the content you accept. Make sure you have a security contact, use a crash reporter, and use auto-update securely. Finally, turn off Java in your web browser to prevent against some of the newer, crazier attacks like GIFAR.

4. Mac users really care about user experience (as if you already didn’t know that.)

To reiterate what we all sort of know but sometimes overlook since we are so deep in our code, Mike Lee presented “Pimp My App.” The basics: Use real artists, don’t skimp on your art budget, watch real users use your app, solve a specific problem, and cut as many features as you can.

He also offered some iPhone specific UI tips: start as fast you can, the start-up screen should not be used as a splash screen but more like the real app, restore the state of your app instead of just restarting, don’t block the UI, and think about the user’s first experience carefully.

5. Contractors / consultants are Indies too.

I’ve made applications and I’ve done consulting. Both qualify you to be an Indie, meaning independent from another company. There was a presentation by Andy Finnell on this and it mostly reiterated what I knew but it was nice to hear it from someone else. Basically: make sure you have good contracts, these will help you get paid properly and avoid constraints your future development. I’d add to this that if you can be choosy, it is good to figure out what kind of clients you want to work for and what kind of projects you want to work on and then only choose those to work on, even if it means taking some time off between projects.

6. Pricing sends a message

Rich Siegel of Bare Bones gave a presentation on lessons learned over his career. One of the key ones is that pricing: is a marketing message and shows how you feel about your product. It also needs to consider how much your overall costs are. It also positions you among competitors. That being said, your product / service definitely needs to be differentiated to justify a premium.

7. Warnings should be fixed

This is probably also a no-brainer but I’ve been at a few companies / projects where warnings are tolerated. Mentioned by both Rich and Mike, warnings can be the cause of run-time errors down the road. Its best to generate the most warnings possible and fix them as they come up. You may find it also advantageous to treat warnings as errors, but either way way, fix them.

8. Mac programmers really care about fonts

Minor but revealing tidbit: the fonts at C4 are carefully chosen. Compared to other conferences I have been to, I think this shows that Mac programmers care about design more than other programmers.

9. Twitter is the preferred method of communication in the Mac / iPhone developer community

When I wanted to see what was going on and what people were thinking, I checked Twitter. At other conferences, sometimes we would have IRC back-channels. Using twitter makes the back-channels more open. Also, we voted for Iron Coder via Twitter.

10. Do the simplest thing possible

Mentioned by Craig, Buzz Andersen, and Mike, doing the simplest thing possible, getting feedback and then iterating on that is a good technique when developing products. I knew this before, but many of us are perfectionists and so we have to keep reminding ourselves of this in order to combat the tendency to either add more features or to keep trying to perfect a certain specific part of our app.