Contributing to CocoaPods

If you’re an iOS Developer, you probably have heard of CocoaPods. More and more developers are using it. I’ve personally used it on many projects and I’m not sure I would want to go back to the old manual way of adding in libraries.

A few weekends ago, on March 29th-30th, they had the CocoaPods Bug Bash. I used to work a lot on the weekends when I ran my own iOS/Android consulting business, but now that I’m working at Capital One, my weekends are pretty wide open. Yay for work-life balance! (P.s. We’re hiring iOS Developers, just contact me.) But since I’m kind of nerdy, I thought what better way to spend my new-found free time than by writing some code.

I hopped onto the #cocoapods IRC channel, registered and then asked the CocoaPods bot to assign me a ticket. By the luck of the draw, I got issue #1489.

I set up my development environment by cloning the CocoaPods/CocoaPods repo, then initialized via rake bootstrap and ran the tests via rake spec.

At that point I realized, oh this is all in Ruby! For some reason I had thought it had more Objective-C in it, since it dealt with Xcode so heavily. Fortunately for me, before the iPhone SDK came out, I had made my living for a while creating Ruby on Rails apps. I quickly rediscovered my love for Ruby.

I loved it so much, I spent most of that weekend hacking away on CocoaPods and the weekend afterwards. At the end of it, I had touched not only the main CocoaPods repository, but also the internals of it in CocoaPods/Core and the high level tests in CocoaPods/cocoapods-integration-specs.

I’m now an contributor to all of those repositories and thus the CocoaPods project! I also got into the CHANGELOG twice:


An informative error message is presented when merge conflict is detected in a YAML file.
Luis de la Rosa #69 #100


Generated prefix header file will now have unique prefix_header_contents for Pods with subspecs.
Luis de la Rosa #1449

The most enjoyable aspect for me though is that it is fun to hang out with other developers from around the world. @orta, @irrationalfab and @alloy are pretty cool fellows and they are welcoming and helpful when they are around in IRC. They are definitely not shy about asking you to squash your commits, but they are also quite friendly with their emotes in pull request reviews.

I’m planning on doing some more hacking on CocoaPods. If you’re interested, I can help you get started with it if you’re in the DC area and come to NSCoderNightDC. Another good way to get started is to join the IRC room #cocoapods, set up your development environment and then just ask which issue might be good to work on. You might also want to follow the CocoaPods Twitter account and look for the “Simple open contribution of the day” which highlights simple issues to get you started.

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.

RubyNation 2008 wrap up

I attended RubyNation 2008 last weekend on Friday and Saturday. It was great to meet up with fellow Rubyists in the Washington DC area. It was also my first time helping to organize a conference – I think we did a pretty good job considering that we did it in a short time and the conference was sold out. We do stand on the shoulders of giants though – we had help from fellow Regional Ruby Conf organizers from around the country – Lone Star, Mountain West, etc. I also wrote a nice app (in Objective-C) to pick the prize winners that I’m codenaming Prizes.

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.



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.

New Programming Language Group forming in Northern Virginia

I don’t know what it is about Northern Virginia and programming languages, but we just can’t seem to get enough of them! A new group “novalanguages” has just formed.

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!

RubyNation – a Ruby conference in the Washington, DC area

I’m proud to say that we are going to have our very own Ruby conference here in the Washington, DC area! It is called RubyNation and it will be happening on August 1 – 2, 2008 at the Center of Innovative Technology in Herndon, VA. That’s probably one of the strangest shaped buildings in our area that should be hard to miss – it sort of looks like a squarish ruby with its point up.

We’ve lined up Stu Halloway, Neal Ford, David Bock, and Giles Bowkett as keynote speakers and we’ll have lots of Ruby content. I think it will be single track which is my preferred format – fewer things to think about. Plus, if you’ve got something cool you’ve been working on, you can present them during the lightning talks!

I hope to see you there!

The closing Jimnote at MountainWest RubyConf

Many of us call the opening keynote of WWDC by Steve Jobs the Stevenote. Well I’m dubbing the closing keynote of MountainWest RubyConf the Jimnote in honor of Jim Weirich. But… maybe I’m too late. It was sort of like watching a Mike Tyson fight (back when he was his prime and KOing people in 90 seconds.)

Jim gets up, tells us that this is the most important thing that programmers should know and brings up three slides:


do it


and sits down.

OK – here he comes and more fired up than ever.

A brief tutorial on LISP.

syntax: s-expressions (s-exps), atoms, lists

nil is the same as empty list

functions: car == head, cdr == tail (trivia: car is address register, cdr is decrement register), cons, eq, atom

special forms: cond, lambda

LISP is turing complete with just this small set of rules.

Now we go into a discussion of how Jim solved the problem of showing the same graphics between an 8-bit memory-mapped 8080-based computer and a 16-bit vector-based PDP11. The answer: FORTH.

FORTH “words” (like Ruby methods) were very short and FORTH itself used reverse polish notation (RPN.) Jim learned about factoring properly this way. To port FORTH all Jim needed to do was write some primitive words (aka graphics drivers.) Note that Jim says that Nintendo console games were written in FORTH.

UDFs – now we’re looking at unducted fans engines which has spinning blades which would pull in air into the engine but did not succeed.

But… designing these engines was an interesting gig. It did involved multiple threads that access shared data. Which is a huge headache. Perhaps a way to help with this would be to avoid system locks but this worked out to one chance in a million of failure. Which seems like good chances, but it failed roughly once a day (since it executed roughly 1.5 million times a day). The point is that writing threaded applications is hard especially when accessing shared modifiable data.

Which brings us to Erlang…

There’s four types: Atoms, Variables, Tuples, and Lists. Hmm I think I see how this starts to form a Moebius strip.

You can’t change a variable once its assigned, which is actually pattern matching. I would call this immutable data. I use immutable data when passing objects between threads in my Cocoa apps.

Then we go into a client/server example in Erlang and it starts to remind me of Cocoa’s Distributed Objects.

In Ruby you send messages to objects and in Erlang you send messages to processes.

We’ve come up with really complicated systems. Jim shows a code example with 6 different languages/frameworks in one html snippet that shows HTML, CSS, Java, JSP, taglib, and JavaScript.

Erlang in comparison is simple, powerful and spawns processes quickly. Ockham might have approved.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” – Tony Hoare

We live in a (programming/business/consumer?) society that values complexity. In the Ruby world, we’ve come up with Camping, Merb, and Rubinius.

So in summary: Simplify.

  1. Small core.
  2. Simple rules.
  3. Powerful abstractions.

Follow-up question: Where do you draw the line between simplicity and metaprogramming? Answer: If it solves a problem you’re having, go ahead and metaprogram – as long as its a significant amount (more than one line or so.)

MountainWest RubyConf Day 1

Well we’re 3/4ths of the way through MountainWest RubyConf. It has been a pretty interesting conference so far. Yesterday was jam-packed from 9AM-9PM (with breaks for lunch and dinner – we are human after all.) Today we are doing the same and the afternoon sessions are about to start. I was pretty lax about blogging about RubyConf which was a mistake:

I learn more when I write about what I’ve learned.

Its sort of the same process where you learn more when you teach something to someone else. Except you’re not teaching directly to someone and that someone may be your future self. It may be insane to talk to yourself but googling and then finding a past post that is relevant makes you glad you wrote that down.

Here’s what’s happened on Day 1 of MountainWest RubyConf:

Evan Phoenix gave a talk mostly on how to properly manage an open source project with Rubinius as the example. The key here is encouraging community involvement. Rubinius for the uninitiated is a Ruby VM in the style of the original Smalltalk VM that will prune to the absolute minimum the amount of code that is NOT Ruby. In comparison, MRI which is the default Ruby implementation has a lot of C in the “kernel” portion of the VM.

Watch the video of Evan’s talk.

Ezra gave a good talk about Merb. It seems to me that Merb is emerging as an important counterpart to Rails. In addition, there are other application servers that are also coming up to complement Mongrel, like Evented Mongrel and Tiny. The basic justification to use something like Evented Mongrel + Merb is when you have consistent, short-lived (1-2 seconds) requests like for a webservice. I think that Merb is also still popularly used to handle file uploads in Rails applications.

Two funny yet valid quotes from Ezra I think also illustrates the need for Merb (vs just building out everything in Rails): “Throwing more servers at the problem only goes so far…” and “Premature Optimization is the root of all hosting bills.”

Watch the video of Ezra’s talk.

One interesting note is that EngineYard who is a sponsor of MountainWest RubyConf employs both Evan and Ezra and helps to fund their projects.

Ok… afternoon talks starting – more later.

Update: I added links so you can watch both of these talks in streaming video courtesy of Confreaks.

What to do before you do Ruby on Rails development on Mac OS X Leopard

Apple has a new series about Ruby on Rails development on Mac OS X Leopard. Its a nice article to help get you going. One thing I’d like to reiterate is that it is good to lock down your RubyGems paths. This way you will always that your RubyGems go in the right directories that Apple has set up.

So before you follow the steps in the initial Developing Rails Applications on Mac OS X Leopard article, you should take the following steps:

  1. Open up ~/.bash_profile in your favorite editor (create it if its not already there)
  2. Type in
    export GEM_HOME=/Library/Ruby/Gems/1.8
  3. Type in
    export GEM_PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
  4. Save ~/.bash_profile
  5. Execute
    source ~/.bash_profile

This makes it so that no matter what version of rubygems you have, you have access to the Apple-provided gems in $GEM_PATH and you’re able to install/update new gems in $GEM_HOME.