I’m messing around with Sprout still, and looking onto windows compatability.

win32-open3 0.2.5 is required for sprout, but the latest is win32-open3 0.2.6

The main difference I see in the changelog is:

Fixed RubyForge bug #20455 (closed IO stream)

[by the way, is there anyway to search Rubyforge for a bug by ID?]

So I’m looking to see how many file handles I can open in one (ruby) process on Windows, and seeing it it matches up with the 170 listed in the bug.

Anyway, while I’m investigating that, I found a really cool tool that is essentially lsof for windows.  The command line version is “handle” but there’s a cool GUI version called “Process Explorer“.

Just thought I’d share in case anyone else is looking for something like it (most likely meaning “me” at some point in the future.)

In the spirit of clarity/specificity in naming, and because I just had a conversation at work about this, I thought I’d write about it here.

A defect (or feature) describes the system.
A ticket (or task) describes work to be done on the system.

There is a tendency to conflate the two, and try to shoehorn inappropriate properties into one or the other. This is usually based on whether you happen to be using a ticketing tool or a defect tracking tool.

It is easy to want to combine the two, because after all, fixing a defect requires work (often not just developer work either, if for example, the defect is caused by a network configuration issue that requires system engineering work), has an assignee, and states such as open/closed, etc.

I’m not arguing against tracking both in the same tool, but I’m arguing for a clearer separation. For instance, if someone is assigned a bug, they become the owner of it. They then create a task to fix the bug. When the task is complete the change the status of the bug to resolved (or verify, or whatever your workflow specifies)

Now, if you have two separate tools, it gets pretty tedious. Thus the urge to combine them.

Defects have state, they do not have dynamic components. In one sense, I’m arguing against object orientedness, in the OOP sense, though a defect has accessors and mutators, a defect does not perform actions.

If you’re a development organization, you probably think of things in terms of defects and features. Because when all the defects and features are implemented, your work is done. However, if you’re in an operational organization, you probably think of things in terms of work and requests.

Work may be done to fix a defect, and a feature may be requested, but that ‘s a semantic blurring between describing a feature and describing what needs to be done to implement it.

I’d argue that integration between tools is desirable. A ticket should be able to reference a defect, and a task should be created to work on a defect. This can be on the same form and handled seamlessly, but I think it’s better to help everyone think about the separate terms.

I’ve been looking a little closer at Sprouts, and think I have a bit better handle on what it is and what it does. After reading through all the links and associated comments in my previous post, and particularly the Sprouts RDocs helped.

As with many things that seem more complex than they are, part of the difficulty lies in naming. Sprouts is an application, but it does several different things. So conceptually, it’s difficult to describe it by what it does. I feel a similarity to describing Java. What is it — a programming language, a compiler, an execution environment — all of the above.

Similarly sprouts is a build tool, a project generator, a dependency resolver/ package manager, and a download, installation, and configuration tool. It helps me to think of it in terms of analogies with other tools, but I’m sure that fails. But learning by analogy is as good a method as any, and maybe I’ll get some corrections.

One thing Sprouts does is set up a Flex/ActionScript development environment. At the core, Sprouts is a series of tasks, and one tedious and error prone task is downloading, installing, and configuring your
development environment. The idea is that installing Ruby (and Rubygems) is easier than finding all your tools separately. A variety of tools have been built that do this: RPM/apt/yum, CPAN, easy_install, gem. Maven can do this too, but most likely because of the complexity of the Java ecosystem, it tends to get ugly.

I’m a bit worried about Sprouts falling into this trap. And the trap is in the download. There’s no easy way to ensure compatibility other than eternal vigilance. CPAN and RPM have bitten me before as well. Yum and Apt alleviate this problem by just not asking. So does gem, which is what the Sprouts installer users. Most of the time this works — as long as you’re staying bleeding edge. I don’t like that the LibraryTask installs for you. Maybe there’s a flag to disable it. Hopefully there’s at least a prompt. (I haven’t actually used Sprouts yet.) I don’t (always) want my build tool to download a library off the internet (or fail to do so), I’d rather it fail and say “libary X isn’t available. I really like the way the Ruby Enterprise/Phusion Passenger installer does this.

But I’m getting ahead of myself. The next thing Sprouts does is Build your application. It does this by wrapping the Flex SDK commands like ‘mxmlc’ into Rake tasks. I don’t know if it calls the ant tasks
or goes to the command line.

Back to the environment setup. Sprout can download, install, and configure the Flex SDK, the Flash debug player (can this run headless, e.g., without a GUI, on my build server?), set up trace logging (which apparently can be painful) and other configuration issues with the flash player, download other tools (and libraries) like a trace log viewer, and a unit test framework (ASUnit or FlexUnit).

Sprouts then gets into other magic like creating a test harness (I’m not sure what that means, possibly inspecting your code for classes and generating associated test and test suite scaffolding?) and setting up a project environment. I’m envisoning Rails Generators, and in fact, it looks like the same thing with script/generate.rb MyFlexProject. It uses Rubigen, which was extracted from Rails.

It mentions IDE integration and continuous integration, which I’m guessing mean setting up libraries in the IDE, and creating ant or rake tasks to build/deploy/test. Cruisecontrol and (especially Cruisecontrol.rb) are mentioned.

Here are some typical tasks:

ZipTask, SFTPTask, LibraryTask, MXMLCTask, CompcTask, AsUnitTask, AsDocTask.

The Sprouts model looks like this:

Tools
Libraries
Bundles
Generators
Tasks
Sprout

“Tools, Libraries and Bundles are distributed as RubyGems”

Sprout is the application, including the CLI (is there a GUI or web interface?)

A task is a Rake task. So I’m assuming I can make my own custom tasks.

I also assume I can make my own generators, all I need is to learn to use Rubigen.

Gem, Rake, and Rubigen seem to be the core components.

As I said, Sprouts is task oriented. There are ToolTasks and LibraryTasks. I’m a little confused, but I would break tasks down into specific categories like download, install, configure, build, package, deploy, test, etc. While sftp and zip could get double duty for download/deploy and install/package, I’d want to keep distinct, even if they call the same underlying tasks. I’d like to be aware of what its doing, and not implicitly step outside the scope of it’s activity. For example, if you’re building, don’t jump out of the build scope into the install or configure scope unless explicitly granted permission, which I’d think you’d only want in a bootstrap phase.

Anyway, sprouts looks like an exciting tool and I can’t wait to delve deeper into it, and actually use it.

Sprouts looks interesting

Sprouts is an open-source, cross-platform project generation and configuration tool for ActionScript 2, ActionScript 3, Adobe AIR and Flex projects.

So it looks like it uses Ruby (and Gem) to set up a project like Rails and resolve dependencies a la Maven (but Ivy might be a better comparision), and provides some missing glue in the form of ant (rake?) tasks for continuous integration.

Here’s a link about the alternative using Maven.
http://www.mindtheflex.com/?p=19

A note about Sprouts and a Flex Maven plugin (see the comments):

http://flexonrails.net/?cat=43

— it sounds here that Sprouts is really geared towards a project jumpstarter.  The comment by Luke Bayes talks about finding, download, and installing the Flex SDK, Flash Debug Player, a trace log reader, asunit or flexunit, and any other project dependency libraries.  It then creates a project directory structure, and apparently has integration with CI tools, (especially) CruiseControl.rb.

Another post on Sprouts

http://joshua.almirun.com/tech/flex/sprouts-son-of-asproject

Retrospectiva is another bug tracking / project management tool. It’s got an intersting approach that I’m interested in. From their home page:

Retrospectiva is an open source, web-based, project management and bug-tracking tool. It is intended to assist the collaborative aspect of work carried out by software development teams through the use of blogs, a wiki and tickets.

Users open tickets to track bugs, and request enhancements. Administrators set targets for the team through milestones. A milestone is considered completed when all tickets assigned to it are closed. The wiki is used for the documentation of the project, whilst the blog logs ongoing progress. When used in conjunction, these tools provide a helpful framework for developing and maintaining source code. The generated code can be browsed directly in Retrospectiva, and changesets record updates made to the source repository.

It’s built with Ruby on Rails.  I really like their workflow, and the UI’s not half bad either.