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.

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

In terms of programming, I’ve been mostly doing Objective-C the past few months. I’m still doing Ruby on Rails, but Cocoa and Cocoa Touch are my main focuses. I actually did get paid to do some Erlang as well. Finally I joined an open source project that I’ve used on most of my iPhone projects. So there’s lots to talk about in the near future.

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.

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.

It’s been pretty motivating to meet up with other Cocoa Mac and iPhone developers. I think we’re going to be discussing Cocoa Programming with Mac OS X by Aaron Hillegass soon, working our way through the chapters. I was privileged to have the experience of doing technical review on that book and I’ll have a full review of it on this blog soon. Short review: if you have the 1st or 2nd edition, it will help you get caught up to the newer Cocoa APIs and so its worth getting. If you don’t, then you definitely need this book to help you with your Cocoa programming. Big Nerd Ranch uses it as a text book for their Cocoa Bootcamps!

Cocoa / Washington DC Trivia: Aaron Hillegass grew up in Northern Virginia. We actually attended the same high school, Thomas Jefferson High School for Science and Technology, though at different times.

In 2007, I was self-employed as the sole member of Happy Apps LLC. So being in charge of the training budget (well actually the entire budget), I went to six training events:

1. Rails Edge in Reston, VA
2. Advanced Rails in Chicago, IL
3. WWDC in San Francisco, CA
4. RailsConf in Portland, OR
5. Advanced Ruby in Reston, VA
6. RubyConf in Charlotte, NC

So that’s 2 Ruby conferences, 3 Rails conferences, and one Cocoa conference. I actually was scheduled to go to another Cocoa conference, C4[1] over in Chicago, but had to cancel due to personal reasons.

So which ones were good and which ones were bad? I think they were all quite good. Obviously, if you want to make Mac applications like I do with WebnoteHappy, you’ll want to go WWDC.

In terms of being a good Ruby on Rails developer, I’d have to say that assuming that you already have a good background in object-oriented programming and web development, have worked through a beginning Rails book like Agile Web Development with Rails, then you really should take both the Advanced Ruby course by Pragmatic Studio, followed by the Advanced Rails course. Both taught me quite a lot of things that I hadn’t known before.

Once you’ve got that though, I think its important to keep up with the latest in techniques and also be involved in your programming community. I think The Rails Edge Conference is top notch in keeping up with what’s new in the Rails world. I hope that a date is announced soon though – I don’t see one for 2008 as of today.

RailsConf is also good for keeping up with Rails, but I think is maybe even better for just being involved in the Rails community. There were a lot of opportunities, scheduled and unscheduled, to get together with fellow RoR developers and you could sense that Rails is really changing the way that web development is being done.

RubyConf on the other hand reminded me that Ruby is not just about Rails. There’s certainly been a lot of growth of Ruby use because of Rails, but there is a deep and wide pool of talent that has fallen in love with Ruby. It was interesting to see all the different uses that people have made of Ruby. And it was definitely an honor and a pleasure to meet Matz in person. In the end, it does seem like most people who are doing Ruby full-time are making their money with Rails.

I’m trying to plan out my training in 2008 now. So I’m curious to hear what good conferences or classes other people went to in 2007. Also if there were any bad ones.