The RunCodeRun Blog

RunCodeRun Returning to Open Source Only

RunCodeRun originally launched as a free service for open source developers working with Ruby and Rails. Since our initial launch, we’ve expanded to support other development environments, most notably Clojure (and Java, more generally). Our community of developers has grown tremendously, with thousands of people using RunCodeRun to sanity check their code daily.

Along the way, we also introduced support for closed-source, commercial codebases. During this period, we’ve learned a lot about the differences between open- and closed-source projects, about the needs of the two sets of developer communities, and about the costs associated with both.

The most important thing we have learned is that we have been trying to serve two masters: our open source community, and our paying customers. For us, such a situation is untenable in the long term. We have concluded that it is in the best interests of RunCodeRun, Relevance, and the greatest share of our users to return to our roots and simply offer free, no-hassle continuous integration for open source codebases.

Current purchasers of private builds will continue to be able to use the service for 30 days; you will each receive an email explaining the situation, and offering our support in moving your builds to another solution.

We hope that you will continue to view RunCodeRun as a valuable tool in your open source toolchain, and we look forward to seeing your green builds.

Sincerely,

The RunCodeRun Team

Campfire Notifications Updated to use API Token

We have updated our Campfire build notifications to work with the new Campfire API. Any projects previously setup to use the old form of authentication have been disabled and now require an API token. The new API token should be entered in the Campfire notifications screen as seen below.

Note: We recommend setting up a separate “build-only” user and using that API token for Campfire notifications. If you use an actual account that is also used for chatting, the logged in user will not see notifications until they refresh manually in their browser.

The Basic Plan, New Signups, and the Holiday Season

As RunCodeRun matures and as we have continued to gain users, we have reached our current capacity level for the Basic Plan. With the holidays approaching, we are taking the step of temporarily disabling new signups for the Basic Plan. This will allow us to reconfigure our resources for the new year. In the meantime, our Premium and Walk Among the Gods plans are still available and will continue to be. And all of our current users, regardless of plan, will see no changes to the service.

Getting Your RunCodeRun on with Geektool

Are you using GeekTool? If not, download it! It is a very cool tool to help you keep track of what’s going on with your Mac. Now you can combine the power of Geektool with the RunCodeRun API. Head over to Github and checkout Aaron Bedra’s clj-runcoderun-radiator. Give it a shot on the command line by running

./geektool

Notice that you get a list of the Relevance open source projects. There’s an easy remedy for this. Simply open up src/runcoderun/api.clj and change the url to match your RunCodeRun username. Give the command line tool a shot again and make sure that your changes worked.

Now that you have the tools you need it’s time to wire them together. Open up System Preferences and select the GeekTool preference pane. Select the shell icon and drag it onto your desktop. Once you see the preferences appear, select ... next to the Command window to expand the view. Simply copy and paste the following:

cd ~/src/opensource/clj-runcoderun-radiator/
echo "RunCodeRun Status for Relevance"
echo "-------------------------------"
./geektool

and make the necessary changes match your system. Save the changes and watch the magic happen. Set the refresh rate to your liking (60 seconds seems to work well). Make sure to set the font to your liking as well. The screenshot above is using Courier bold 14pt. Enjoy your new RunCodeRun goodies!

Get to Green on Ruby 1.9

These projects have passing test suites on Ruby 1.9. Come and see how your code fares.

Ruby 1.9 is a terrific step forward from 1.8, and it is high time to start looking at moving your code there. (If you’re a Rails developer, you’ve probably heard that Rails 3 won’t just work on Ruby 1.9; it will prefer Ruby 1.9.) Of course, it isn’t just about your own code. What about all those gems and plugins you depend on? Will they work on 1.9? Community feedback, such as that organized at isitruby19.com, is one great way to see what’s working on 1.9.

Another great way is a passing test suite. To that end, we are launching Green on Ruby 1.9: a select listing of projects whose test suites are passing CI builds on Ruby 1.9. If you have a Ruby library that you want to see featured as green on Ruby 1.9, drop us an email.

Behind the scenes of our Green on Ruby 1.9 is a new RunCodeRun enhancement: selectable target platforms for your Ruby builds. When you add a project to RunCodeRun, you can request that the project build on either Ruby 1.8.x, Ruby 1.9.x, or both! Simply edit your project, and check which Ruby runtimes should be used to run your tests.

Building on multiple platforms demonstrates advantages both of continuous integration and of a hosted solution:

• CI takes the pain out of configuration management for testing. It is a Good Idea to run your tests locally before committing, but there are diminishing returns to having a whole development team keep multiple platforms running on their own boxes. Continuous integration provides an easy way to detect regressions on secondary platforms, without headaches@localhost.
• Hosted solutions get better over time by adding new featuers. Homegrown solutions, meanwhile, either bitrot in place or require regular infusions of sysadmin time just to keep them current. Spend your precious time on your passion: writing code, not administering tools.

Remember, RunCodeRun is free for open source projects. Get your code green on Ruby 1.9 today. It has never been easier.

Blue Ridge Pro Tip: Trust the Wiring, Test the Behavior

A Common Problem: Testing jQuery Event Handling

The prevailing style in jQuery is to inline your event handling like:

$(function(){
  $("#some-id").click(function{
    $(this).attr("some-attribute", "some new value");
  });
});

And so, most new users of Screw.Unit (and Blue Ridge) try to write specs like:

//do NOT do this!
it("does something", function(){
  // setup HTML fixture here

  $('#some-id').click();
  expect($('#some-id').attr("some-attribute")).to(equal, "some new value");
});

However, manually invoking the event usually doesn’t work as expected. It often doesn’t work at all. (More on that later.) Most important, though, is that this inline style is not reusable and is difficult to test.

The Solution: Trust the Wiring, Test the Behavior

Because I trust jQuery to handle events properly, I don’t test “wiring” code like the click() function. Instead I do something like this:

var SomeNamespace = {
  doSomething: function(element){
    $(element).attr("some-attribute", "some new value");
  }
};

$(function(){
  $("#some-id").click(function(){ SomeNamespace.doSomething(this) });
});

Now the spec can test the doSomething() function directly. I’d write a spec for doSomething() like:

it("does something", function(){
  // setup HTML fixture here

  SomeNamespace.doSomething("#some-id");
  expect($('#some-id').attr("some-attribute")).to(equal, "some new value");
});

Why Is This Better?

Clearer Intent

The code’s intent is clearer because it separates application-level logic from the event wiring. We focus on the essential logic, and we trust jQuery to do the rest.

Increased Reusability

The doSomething() function is more reusable because it can now work on any element. Note that the #some-id is hard-coded only in the wiring setup, not the function itself. Also, because we’re calling $(element), this function could be passed a selector string, a DOM element, or a jQuery object (that could potentially represent dozens of DOM elements). This style is very jQuery-idiomatic.

Greater Testability

Because the function is now properly named, you don’t have to go through any DOM/event contortions to test it. Also, you can set up several specs with different “fixtures” each highlighting a different aspect of the behavior under test.

Extra Credit: Why doesn’t the click() work?

Okay, technically it does work — if you get the timing of the event setup correctly. Which most folks don’t. It’s non-trivial, and so most developers either unnecessarily use the live() function as a crutch, or, in Blue Ridge, fall back to using the HTML fixture file which is undesirable.

Extra Extra Credit: Setting up HTML fixtures?

In a future blog entry I’ll cover setting up Factory Girl-style HTML fixtures inside your tests. For a few quick examples, though, check out the spec files and spec_helper.js file in the Blue Ridge sample app.

The Big Finish

Manually invoking events is one of the biggest problems new Screw.Unit and Blue Ridge testers face, and they just don’t have to. It’s unnecessary complexity. Trust that jQuery will do the right thing and get the event to your application function, and then all you need to do is test your own JavaScript behavior.

Announcing the RunCodeRun Basic Plan

We are pleased to announce that the RunCodeRun Basic Plan is now available. Targeted at solo developers, the Basic Plan costs $19 per month and supports up to three private projects. Unlike the Premium and Walk Among the Gods plans that provide a dedicated server for each account, Basic Plan private builds run on shared RunCodeRun build resources.

So drop by our list of plans and sign up for the Basic Plan today. Let RunCodeRun manage your continuous integration services, so you can focus on keeping your projects clean and green!

Now, with PostgreSQL support

We’ve been supporting builds on SQLite and MySQL since launch, but we’ve now added support for PostgreSQL (version 8.3) as your build-time data repository. Switching is dead simple: edit your project, and choose PostgreSQL from the “Database” dropdown:

That’s it — no other craziness needed. PostgreSQL at your disposal. Also, check out our knowledgebase article on database configuration for RunCodeRun to learn how we deal with database.yml at build-time.

Now Supporting Campfire Notifications

Because builds can’t fail loudly enough or embarrass you in enough places, RunCodeRun now supports politely alerting you to your FAIL through Campfire. No need to install anything into your build, just tell RunCodeRun “Yes, ma’am, can I have another!”

First, log in and edit your account profile:

Then, click on the “Notifications” tab and fill in your Campfire credentials:

After that, you’ll see notifications like this interrupting your otherwise pleasant Campfire chatting:

Good luck avoiding the Build Bot! It can’t be bargained with, it can’t be reasoned with. It doesn’t feel pity, or remorse, or fear, and it absolutely will not stop. Ever. Until you go green.

RunCodeRun now supports private builds

We are pleased to announce that RunCodeRun is now accepting private builds. This means that you can now connect your private repositories on GitHub to RunCodeRun for your continuous integration needs. You can drop by our list of plans to see which best suits your situation.

We feel it important to note that RunCodeRun remains, as always, free for open source developers. If you are already an open source customer and want to upgrade, just sign in and head to the plans page and pick the option that works for you. You can keep all your open source projects active, now and forever, regardless of which plan you are on. And if you are just interested in getting started with an open source project? That’s easy: just sign up for an open source account. You can always upgrade later if you want to add private builds.

We look forward to seeing your projects clean and green!