The RunCodeRun Blog

Saying Goodbye to RunCodeRun

It is unfortunately time to close the doors, turn out the lights, and shut off the servers at RunCodeRun. After nearly a year and a half of builds, thousands of awesome projects, a tremendous amount of effort, and quite a bit of learning, we’re ready to say that RunCodeRun has run its course. As of April 15th, RunCodeRun will be no more — not for paying customers, and not for open source users.

We’ve never felt the need to be cagey about our service, or our intent. We won’t start now. We can honestly report that we’ve been unable to find the right monetization strategy, one that allows for us to provide the level of service that our users require. For our paying customers, the grand majority ended up at a price point that was barely above hosting cost, leaving very little on the margin for the level of support required. Our open source users need far less support, but they still require it, and of course there is no margin on free. But it would be an incomplete truth to lay our decision solely at the feet of money.

In the end, what we have built is simply a commodity, but without the simplicity. Consuming RunCodeRun is a commodity, with the pricing, support requirements, and need for consistent, uninterrupted service that it entails. But providing RunCodeRun is anything but a commodity, requiring a lot of specialized support and custom effort. There is a negative price arbitrage built into such an arrangement, but worse, a negative emotional one as well. Large scale hosted continuous integration is consumed as a commodity but built as a craft, and the rewards, both emotional and financial, are insufficient to support the effort.

Our team is dedicated to building great systems that solve our customers’ needs, provide real, measurable value for them, and satisfy our urge to make. RunCodeRun is an imbalanced example of that; one whose users are made most happy when the application is quietest, and one whose aspiration and goals no longer rise to match our own. It is best to say proudly but sadly that it is time to focus our resources on the next great project. We bid a fond farewell to RunCodeRun.

We urge you to keep on testing your code and doing so continuously; we can highly recommend the following tools:

• Hudson (available standalone or as an EC2-ready VM via CI in a Box)
• CI Joe

Thanks to everyone who shared their code with us; keep kicking ass and writing excellent code.

—

Note: If your company or organization is interested in taking over hosting and support for RunCodeRun and making the necessary changes for it to be consumable as an open source project, please contact us directly.

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.