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!

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.

'./your_wordpress_database/wp_comments' is marked as crashed and should be repaired.

Uh oh. That doesn’t seem good. I went to one of my blog posts and it said the same thing. OK no need to panic. I run my own WordPress on a virtual private server and also administer my own MySQL databases.

The solution is remarkably simple:

1. Run the mysql client. mysql -u your_wordpress_user -p
2. Switch to your WordPress database. use your_wordpress_database
3. Issue the command repair table wp_comments

As usual, there was the good practical technical meat from JRuby to testing to DSLs. You can find a links to the speakers and the Ruby frameworks and tools that they mentioned at my links pages (which I took with my Mac bookmarking app Webnote) to post it to both delicious and ma.gnolia.

delicious: http://delicious.com/tag/rubynation

magnolia: http://ma.gnolia.com/tags/rubynation

But, what I found more interesting is the philosophy of programming. Neal Ford who gave the opening keynote related how Ruby helps you capture the essence of your problem while avoiding the ceremony that other languages like Java make you perform and that we should learn the lore of programming. Glenn Vandenberg reminded us that we really should try to fit the tools to the problem and that there is always a benefit and cost to each. Rich Kilmer noted that Ruby is becoming mainstream and that is has grown organically (to our benefit.)

Finally, Stu wrapped up with how Ruby is good overall, but that there are some bad practices / parts of the language that could come back to bite us later especially as Ruby adoption grows. He called out: class attributes (use instance attributes on eigenclasses instead), constants (you can’t change them unlike almost everything else in Ruby), accessing instance variables directly (use accessors), and how procs are treated (he likes Giles’ L alias for lambda but solving the ugliness of using more than one block will likely need change at the VM level.)

As a programmer who lives in both the Ruby and Objective-C worlds, I had the additional takeaway of how much the Objective-C community can learn from Ruby practices. Things like testing, mocking and DSLs are under-utilized but I think have the potential for improving our apps.

Going further and thus wrapping back to Neal’s talk about the lore of programming, I think we owe it to ourselves as programmers to learn other languages, especially the “root” languages like Smalltalk and Lisp and to read “the classics”. Neal mentioned The Mythical Man-Month, Smalltalk Best Practice Patterns, and The Pragmatic Programmer. To that list, I would add Refactoring.

Thanks for everyone who spoke, attended and organized RubyNation 2008! We’ll be having another one in June 2009.

I missed last weeks but that’s because I was getting ready for RubyNation. Part of that was making a new Mac OS X app that I’m calling Prizes.app. It lets meeting organizers who are having raffles / contests enter in a list of people’s names and then randomly pick one from the list. All in a stylish way of course. It uses Core Animation to make it more suspenseful and interesting to watch. It worked well at the RubyNation conference. So I’ll be demoing that tonight in addition to our usual group discussion of Aaron Hillegass’s Cocoa Programming for Mac OS X book.

delicious: http://delicious.com/tag/rubynation

magnolia: http://ma.gnolia.com/tags/rubynation

BTW, for the uninitiated, RubyNation is the Washington DC Area Ruby conference.

The basic usage of a random number generator is something like this:

1. Seed (initialize) the random number generator
2. Generate a random number
3. Modulo the random number against your maximum number to get a number from 0 to your maximum number - 1.

Alright, first off I looked for Objective-C libraries. You know, maybe there was an NSRandom or something like that. There isn’t really one, so I went to look for C functions instead.

Digging into my memory banks, I remembered from my early C days that the standard C library call is srand() with a seed to initialize and then rand() to get the random number. So I looked up srand in the Apple Developer Connection (also known as ADC)
and came up with the laughable description:

rand, rand_r, srand, sranddev — bad random number generator
…
These interfaces are obsoleted by random(3).

Alright, so onto random. I looked up random in the ADC to see its Mac OS X Manual page. Alright, so it can generate numbers from 0 to (2**31) - 1. You can seed it with srandom() - which could be useful because the same seed will generate the same sequence of random numbers - useful for replaying a game sequence. A better seeding is to use srandomdev() which creates a state array which can’t be guessed by attackers and effectively uses the /dev/random device.

OK that seemed pretty good, but I read on and found this intriguing line:

Applications requiring cryptographic quality randomness should use arc4random(3).

Alright, so now I look up arc4random on ADC. arc4random uses the Alleged RC4 cipher, hence the ARC4. It has a range of 0 to (2**32 - 1), which is twice the range of random. It uses the /dev/urandom device. And best of all, in my opinion, it doesn’t require seeding/initializing since it initializes itself.

So the winner in my book for generating random numbers in Cocoa (really any Objective-C or C program on Mac OS X) is arc4random.

Tonight we’re discussing Chapter 5 of Cocoa Programming for Mac OSX Third Edition by Aaron Hillegass.

We meet at La Madeleine Bethesda, MD.

And more info:
7607 Old Georgetown Road, Bethesda 20814
Old Georgetown & Commerce
TEL: 301-215-9142
Mon. - Thu. 6:30 AM - 10:00 PM
Fri. - Sat. 6:30 AM - 11:00 PM
Sun. 7:00 AM - 10:00 PM

And parking info:
Go past La Madeleine and either turn right onto Old Georgetown Road or
continue onto Georgetown Road.
Turn left onto Woodmont Ave.
Make a left turn into the parking garage.
Take the elevator up to the ground floor.
Cross the street and there is La Madeleine.

And don’t forget to validate your parking ticket with La Madeleine -
they’ll pay for the first hour.

We’re going to go through Chapter 2 of Programming Erlang by Joe Armstrong. If you’re interested in Erlang, click over to the group link for more details and to RSVP.

Here’s a brief description of the group:

Thoughts on the makeup of the group include obtaining (however you want) a book,
working through the book 1 chapter per week on one night of that week with a group of
like minded individuals. For the first one, my company Iterative Designs will sponsor it (not sure what that means just yet) and we can go from there.

It will mean meeting up and having a group to ask questions about the language we are learning and they aren’t going to give you the snub nose responses of “Don’t you know that — you n00b” that you might get in an IRC chat room.

I am thinking the first language should be something out there but semi-applicable (like an Erlang, Smalltalk, or even Lisp). Unless everyone in the group has a Mac (or can borrow one) and we can learn Cocoa/Obj-C — which would be fun given the iPhone SDK availability.

- Chris Williams

Personally, I’d be happy to learn Erlang. Chad’s been talking about it for awhile now and I got really excited about the potential of it while at MountainWest RubyConf where I saw some good presentations about it.

I’d also be interested in going through Cocoa/Objective-C. I already know it, but its always good to go back through the basics and practice, practice, practice. Plus, it’s also good to share your knowledge with others - teaching is sometimes the best way to deeply ingrain something into your brain. However, we’re already planning to go through the Cocoa Programming for Mac OS X, 3rd ed book in our NSCoder DC Night group.

Thanks to Chris Williams for setting this up!