We recently got a question on the Sprouts Group about Continuous Integration (CI) and I thought I’d try to give it a quick explanation here.

The idea behind Continuous Integration is that you have a machine somewhere on the network that will check out, compile and test your application after almost every check-in. Whenever failures are encountered anywhere in that process, the entire team is notified. This helps us discover unexpected regressions or injections early which helps us pinpoint and address their root causes more efficiently.

This process can be useful in any project, but is especially helpful when working with teams that are all checking into different components of a larger project.

There are essentially three major problems when attempting to introduce ActionScript or Flex applications to typical CI systems:

• The Flash Player requires a visual window manager to execute your test harness (Usually X-Windows on Linux)

• The Flash Player does not give us the ability to capture all runtime exceptions, and when an uncaught runtime exception is encountered in the Debug Flash Player, a GUI dialog box is presented that must be manually clicked with a mouse in order to continue or abort execution. This can hang a typical CI set up, and result in an unhelpful “execution timeout” failure.

• It can be challenging to get a Linux machine properly configured to compile your ActionScript or Flex application, run your test harness, and collect trace output and error messages.

Today brings a major set of improvements to the Sprouts ActionScript 3 bundle (and related gems).

We have introduced three major features that you can retrieve by opening a terminal and entering:

I just got a question about using the Flex 4 SDK with Sprouts and figured I’d share the answer with anyone else that may be interested…

Being insanely flexible does often have it’s downsides, but in this case life is good.

To use the latest Flex 4 SDK with the latest release of Sprouts, you can simply update your project_model by specifying the compiler_gem_name as follows:

1
2
3
4
5
6
7
8

project_model :model do |m|
  m.project_name            = 'SomeProject'
  m.language                = 'mxml'
  m.background_color        = '#FFFFFF'
  m.width                   = 970
  m.height                  = 550
  m.compiler_gem_name       = 'sprout-flex4sdk-tool'
end

Then run rake.

Fits like it grew there!

Just getting a quick note out to everyone in the San Francisco Bay Area.

There’s been a last minute setup of the Silicon Valley Flash User Group (Silvafug) and I’ve been asked to present Sprouts.

Of course I’ll be giving the now-traditional 5 minute ‘up-n-running’ demo that everyone is probably sick of seeing, but afterward I’ll be getting into some nuts and bolts of how Sprouts works in my own Test-First development process.

Paul Robertson is speaking for the first half of the evening on “AIR: Windows, Menus, and the System Tray.” which I’m really looking forward to!

At the time this post went to press, the Silvafug website hadn’t yet been updated, but according to this email, the event is scheduled to go from 5:30pm to 9:30ish at the San Francisco Adobe building (601 Townsend Street).

For those of you that don’t know, this means that we’ll be at the Mars bar from about 9:30-ish onward!

Hope to see you there.

As Sprouts starts to pick up momentum, we’re starting to get questions about creating custom generators. So I thought I’d throw a quick post up to share the info more broadly.

I’m actively working on the ‘developer’ gem so that you will eventually be able to stub new sprout gems for tools, libraries, bundles, tasks and generators. Unfortunately that gem isn’t quite ready yet so for the time being, you’ll have to build your generators manually.

If you’re looking for code generators within the context of an existing project, here’s how to do it: