We had a great time at GoGaRuCo yesterday. If you don't know already, we're live-blogging the conference at pivotallabs.com/gogaruco/blog. Follow along again today as we continue documenting the conference!

GoGaRuCo is being held in the Swedish American hall in San Francisco. It's a great venue. Here we are demoing Tracker at lunchtime yesterday.

We had fun during lunch at GoGaRuCo talking to people about Tracker and demoing the app. Especially cool were the awesome Viking chairs we got to sit it.

Thanks to Ryan, David S and Chad for helping out!

The first talk of the conference is by Rich Kilmer on MacRuby & HotCocoa.

He's starting out by talking about the history of Apply and Ruby. The first time a version of Ruby was shipped with OS X was in 2002: Ruby 1.6.7 was shipped with OS X version 10.2. The next big development was in 2007, when Ruby 1.8.6, RubyGems, RubyCocoa and Rails were shipped with OS X version 10.5. Later this year, SnowLeopard will include Ruby 1.8.7, RubyGems, RubyCocoa and Rails 2.2.

Rich is telling us that one of Apple's goals is to make OS X the best platform for Ruby developers. Another is to make Ruby a first-class Cocoa programming language on OS X. He hopes that it will become the best Cocoa programming language - a pretty tall order.

RubyCocoa

Now we're diving into the history of RubyCocoa, by Fujimoto Hisakuni. It first emerged in 2001. It provided a bridge between Ruby and Objective-C. Rich is telling us that the first version of the installer wasn't great - it managed to delete his entire /Library directory. RubyCocoa first shipped with Leopard. Rich is showing us a RubyCocoa Hello World implementation. Wow, it's really long - about 20 lines. It's barely visible to people at the back of the room!

Rich is describing the problems with RubyCocoa. First, it's a bridge. Second, its messaging syntax is different. Third, Ruby uses green threads. Lastly, you ended up with 2 runtimes and 2 garbage collectors, which caused problems. In a nutshell, you could build apps with RubyCocoa, but probably not large, complicated ones.

MacRuby

Then MacRuby hit the scene. MacRuby 0.4 is built on top of Objective-C 2.0 and Ruby 1.9. Every Ruby class/object/method is an Objective-C class/object/method. That's great, because you get the dynamism of Ruby with the runtime and speed of Objective C: much better than a bridge.

Now we're seeing a MacRuby implementation of Hello World. Well, it's still about the same amount of code. There's still a lot of code around wiring things together and configuring things.

HotCocoa

And now, enter HotCocoa. Rich is showing us how to refactor the MacRuby Hello World example into HotCocoa. He's removing lots of code, bit by bit, and looking more and more like plain Ruby. Actually, it's looking a but Rails-y in places (e.g.

win = window :title => 'hello world', :frame => [0, 0, 200, 60]

He's down to 7 lines now of pure Ruby. Rich is telling us how a lot of the excitement around HotCocoa is because of its ability to simplify the configuration of your code.

Installing HotCocoa

Rich is giving us a live demo, using HotConsole (available on GitHub), of HotCocoa. HotConsole is written in HotCocoa. He's running simple Ruby code such as

{}.methods

and how he's also running code such as

w = window :title => 'hello'
b = button :title => 'push me'

Hey presto, a window pops up with a button labeled "push me" on it. Rich gets a round of applause!

MacRuby Experimental

Rich is going on to talk about MacRuby 0.5. Over Christmas break, Laurent stargin building a new VM for MacRuby, based on LLVM. He already has a functioning replacement for YARV. Other parts of Ruby 1.9 are being replaced with Objective-C code also (such as the garbage collector and built-ins). The JIT is actually just generating machine code, which means it's really fast: about 4 to 5 times faster than Ruby 1.9 (the goal is to pass them all). It won't use any libffi for external calls. It's passing many RubySpecs already. Laurent is also going to make it fully re-entrant and implement fully concurrent threading. His goal is to automatically generate Grand Central code.

All this could lead to some exciting developments, such as, in Rich's words, the ability to run Ruby on a "small device that runs OS X on a cellular network" :)

We're out of time for Rich's talk. He's suggesting that you go to macruby.org to learn more.

There's a gig round of applause as Rich leaves the stage. Break time now!

The first Golden Gate Ruby Conference (GoGaRuCo) starts tomorrow in San Francisco. Pivotal Labs is happy to be a sponsor of the event. Pivot David Stevenson will be giving a talk titled "Playing With Fire: Running Uploaded Ruby Code in a Sandbox". We have a booth where you can come by and chat with us; we'll be showing off Pivotal Tracker.

Also, Pivotal Labs will be hosting the live Justin.tv feed of the entire conference at pivotallabs.com/gogaruco. Pivot Chad Woolley will be live-blogging every talk at pivotallabs.com/gogaruco/blog and, when the conference is over, we'll make available videos of all the talks from the conference at pivotallabs.com/gogaruco/talks.

If you're coming to the conference, we're looking forward to seeing you there; otherwise, we hope you'll follow along from home, starting at pivotallabs.com/gogaruco!

At Pivotal Labs we take Continuous Integration (CI) seriously. Every project has a dedicated machine that serves as a CI environment. Each checkin on the project causes a build to be kicked off. A "build" means checking out the code from scratch and running of all the project's tests, which, for a Rails project, means unit and functional tests, JavaScript tests and Selenium tests. For the JavaScript and Selenium tests, we run multiple browsers on multiple OS's (e.g. IE 7 on Windows XP, FF 3 on OS X, etc).

We consider it critically important to keep each project's build green (i.e. successful) at all times. A build is the heartbeat of the project: if it's green, everything is healthy; if it turns red (i.e. fails), the team is encouraged to jump on the problem and get it back to green right away. We want red builds to go away quickly; the longer a build stays red, the longer it takes to track down the problem and the more likely it is that additional tests will be broken (the "broken windows effect").

In order to facilitate this level of discipline, we've learned over the years that making the status of our CI environments obvious and visible to the team is critical. If a team isn't acutely aware of the status of its build, it's unlikely that a red build will get noticed and fixed quickly. You can have the CI server email the team, but that doesn't work very well when the whole team is pairing all day: it might be a few hours before someone notices the email. You can install plugins in your browser or system tray that show build status, which helps, but still, they're not always obvious enough. The best way we've found to keep the team informed is to display the status of the build high on a wall near the team as a big red or green indicator. That way, even when you're busy coding, it's easy to notice the build going red. These days we use 2 wide screen TVs, positioned in the office so that one is easily seen from any developer station.

As Ian just posted, Pivotal Tracker won a Jolt award tonight. Here are some early pictures from the event.

The Jolt award for Pivotal Tracker

Edward with the Jolt award for Pivotal Tracker

Ian with the Jolt award for Pivotal Tracker

Matthais Marschall at AgileWebOperations.com posted an interesting article the other day comparing Pivotal Tracker to Thoughtworks Mingle. He recognizes that the two tools have a very different philosophy when it comes to configurability: Mingle supports a huge number of different configuration options, whereas Tracker is intentionally very simple and more prescriptive about process. His take is that the simplicity of Tracker is fact a good thing. He likes Tracker's backlog management, its simple UI, and the way that the tool fits naturally into the agile process:

Where Mingle is more like an assistant, whom you can tell to put a card on the wall or give you this or that report, Tracker is more like an agile coach, making sure all the administrative tasks like iteration tracking are "simply there".

Chris's recent post called The Tracker Story points out that simplicity and ease-of-use has always been one of Tracker's core design principles:

Tracker embraces simplicity. It should make managing projects easy, rather than make its users slaves to maintaining the plan. It should give every user of the system more information back than they put in. Tracker doesn't have a huge list of features, because it tries to stay true to its core purpose.

Thanks for the post, Matthais, and we're glad you're finding Tracker to be a good fit for your development process.

Kevin Matheny, Senior E-Biz Architect at Best Buy, has an excellent article today on BusinessWeek.com about Best Buy's take on Agile software development and Best Buy's experiences as a client of Pivotal Labs. As he mentions in the article, Pivotal Labs has been helping Best Buy build "Remix", an API for the BestBuy.com product catalog. Kevin describes the agile methods that Pivotal Labs uses and how they've helped with what he calls "Corporate Agility", which he describes as "working components instead of complete solutions, expecting and responding to change instead of trying to eliminate it, and trust rather than control." He also describes how Pivotal Tracker fits into Pivotal's agile process:

For example, I recently added a story to the tracker for Remix that read simply "flag products as new if their start display date is less than 30 days in the past." That's all the up-front documentation needed for Pivotal Labs, a development company that specializes in agile software development, to code that function into Remix. Any additional information can be gathered in the daily 15-minute team meetings or in a longer follow-up if more time is required.

Thanks for the mention, Kevin, and we're very glad that the project is proving to be successful. Pivot Steve Conover is at the helm.

How my outlook on coding in Rails has changed over the past few months!

When I made the switch from Java to Rails a few years back, I, like many of my fellow Pivots making that same well-chronicled transition, delighted in the ease with which we could suddenly knock out a web app. How we cheered when our object-relational mapping took zero lines of code! How we applauded when we declared our model object validations in near-English! How we roared with laughter when convention viciously slapped the face of configuration! And how we shook our heads in dismay when we realized that our new development environment appeared to be from the mid-, if not early, nineties.

For, while we had arrived in a brave new world of minimalist declarative meta-programming, rapid prototyping, and an new-found sense of productivity that made even the most nimble forms of Java development look like wading through a morass of slimy boilerplate code and endless XML, we soon realized that the IDE situation was less than awesome. Our productivity was overall much improved, but we had taken a huge step backwards when it came to the act of writing - and especially changing - code and tests. Overnight, we went from living it up in a paradise of automated refactorings, seamlessly inbuilt test runners and powerful debuggers to roughing it with a text editor that, to our spoilt eyes, appeared to offer barely more than code highlighting and support for homemade macros.

Ian McFarland and I attended a 2-day Development Forum hosted by OpenView Venture Partners last week in Boston. It's the second year that Pivotal Labs has participated in the event. Open View has a portfolio of companies from all over (Europe, Australia, the US), each of which has been working on implementing Scrum over the past year. The engineering staff from 10 portfolio companies attended the event. Jeff Sutherland (amongst other things the co-creator of Scrum) is a Senior Adviser to OpenView; he provides advice and guidance to the portfolio companies as they progress through their Scrum adoption, and he gave a talk at the Forum. Pivotal Labs was invited to speak and lead a discussion of on 2 core topics: Developer Testing and the Principles of Build.