A while back I blogged about Pivotal's internal CI aggregator, which we use to display the status and history of the builds of all the different projects we're working on. In additional to our internal instance, we have another instance of it running at ci.pivotallabs.com that shows the status of various open-source projects that we maintain or depend on.

We got a lot of interest from people who wanted to run an instance of this CI aggregator app, which we call "Pulse", at their own company. Well, we've now done the work to open-source the application. You can access it here:

git://github.com/pivotal/pulse.git

There's documentation on that page that describes how to install and use the app.

Pulse's CI is here and it's shown, of course, on an instance of itself at http://ci.pivotallabs.com.

The public Pivotal Tracker project for Pulse is here.

Please let us know your feedback!

Yesterday we held a TUG over lunchtime at our San Francisco offices. The subject was "Tracker 101". Thanks to all those who came; some good questions came up, and we hope you found it useful!

We've moved JsUnit from SourceForge (where it's been hosted for over 8 years) to GitHub, under Pivotal's account:

http://github.com/pivotal/jsunit

The motivation is (1) to bring JsUnit development more officially in-house at Pivotal Labs, where it has a better chance of getting more attention than it has historically, and (2) to more easily allow the wider community to contribute.

Fork away!

JsUnit has a public Tracker project here and CI here.

Next Tuesday, July 14, at 10pm PST, Chris Sepulveda from Pivotal Labs will be broadcasting an O'Reilly WebCast on automated unit testing with the Palm Mojo SDK. Developer testing is at the heart of Pivotal Labs's development practices, and we're excited to be involved in bringing testing to Mojo development. The WebCast will cover the following:

• Introduce BDD & Jasmine
• Installing Jasmine & add related code to the app to support BDD
• Discuss how to write a failing test first, then add functionality to make a test pass
• Develop a simple webOS application test first, with the Mojo SDK

There's more information about the WebCast on webOSHelp.net.

Date: Tuesday, July 14th at 10 am PT
Price: Free
Duration: Approximately 60 minutes
To register: http://oreilly.com/go/palmmojo

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