New Ruby Project Support in Sprouts

[Loren Norman]

Hey guys!

I was on Github the other day and I noticed this commit message on
Project Sprouts: "Started work on a Ruby Project generator", which I
promptly commented on to inquire about!

I'm highly curious about the direction and philosophy you're going for
here. It sounds like this is going to be more than just a Ruby-
oriented extension to the project, but will actually result in changes
to the way AS3/Flex Sprout developers work. Both sound great.

Suffice to say, I'm highly interested in this! If I could get a quick
overview of what is planned I'd be very grateful.

Thanks guys! Keep up the good work,
-Loren

[Luke Bayes]

Hey Loren,

Thanks for following up here!

There are definitely some major changes and simplifications coming in terms of how we think about Sprouts.

This latest build has come about primarily as an effort to simplify and open up Sprouts to external contributions.

In order to accept contributions with confidence, I decided to delete and then test-drive the existing code base back into existence - starting from scratch, but bringing in functionality one feature at a time.

It was during this process that every single feature became simpler, more encapsulated and more elegant.

Two of the most-changed areas are related to Executables and Generators.

With the upcoming release, Sprouts provides the world's cleanest mechanism for describing Executables - whether you intend to implement a new executable directly in Ruby, or delegate to an external process from Ruby (or Rake).

Here's an example Executable from our test fixtures (This is one of the most complicated executable applications - mxmlc):

    http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures/executable/mxmlc.rb

Here's a very simple example Generator from our test fixtures:

    http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures/generators/song_generator.rb

And it's Template:

    http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures/generators/templates/Song.txt

And here's a more complex Generator (For creating new Sprout Tools):

    http://github.com/lukebayes/project-sprouts/tree/master/lib/sprout/generators/tool/

And here is it's executable wrapper:

    http://github.com/lukebayes/project-sprouts/blob/master/bin/sprout-tool

You may have noticed that Generators-are-Executables. We had to leave Rubigen behind since it relies on globals and creates code that's difficult to test effectively.

All that said, Sprouts is much more modular now. It's tighter and cleaner, and actually has nothing to do with ActionScript, Flex or AIR. 

It's a highly-cohesive, loosely-coupled collection of features that try to take some of the suck of programming - regardless of what language or environment we're working in.

We almost have our Continuous Integration environment set up, and we're still lacking in getting-started documentation. 

Once we have these two issues resolved, we'll be ready to take more contributions from a wider group of folks.

Thanks,

Luke

[Loren Norman]

Thanks for the write-up, Luke!

Well, it certainly looks a lot better than before. And I don't lament
the removal of Rubigen: it always seemed too narrowly-targeted for
general usage (just felt like we were hacking it to make it work for
us). Globals and untestability only make it more obvious.

I am still trying to figure out where Sprouts will fit in for other
languages and environments, though. I'm a long-time Rubyist, and I've
always appreciated Sprouts as sort of the "Rubification of Flash/Flex
projects", which roughly means injecting all of the great process and
workflow we commonly see in Ruby projects (git, gems, rake, CLI
interface, etc) into an environment that sorely needs it (dreadful,
proprietary IDEs and Ant tasks that only do exactly what they do and
afford little flexibility).

Would you say that Sprout now seeks to be the "Rubification of X
projects" where X is any given language or environment? I guess the
case where X = Ruby is the most interesting, since, by and large, the
community already HAS all of the best practices in use and would
(perhaps?) be slowed by the existence of an intermediate tool.

That said, it also seems as though you're building a meta-tool.
Codifying the way we create new tools is clearly valuable!

Anyway, still just trying to get my head around the direction and
philosophy. I'm pretty interested in helping out if it all makes sense
and I'm able to reasonably scratch some itches while I do it. Looking
forward to those getting started docs and some more answers here!

Thanks again Luke, et al,
-Loren

On Jun 20, 5:13 pm, Luke Bayes <lba...@patternpark.com> wrote:
> Hey Loren,
>
> Thanks for following up here!
>
> There are definitely some major changes and simplifications coming in terms
> of how we think about Sprouts.
>
> This latest build has come about primarily as an effort to simplify and open
> up Sprouts to external contributions.
>
> In order to accept contributions with confidence, I decided to delete and
> then test-drive the existing code base back into existence - starting from
> scratch, but bringing in functionality one feature at a time.
>
> It was during this process that every single feature became simpler, more
> encapsulated and more elegant.
>
> Two of the most-changed areas are related to Executables and Generators.
>
> With the upcoming release, Sprouts provides the world's cleanest mechanism
> for describing Executables - whether you intend to implement a new
> executable directly in Ruby, or delegate to an external process from Ruby
> (or Rake).
>
> Here's an example Executable from our test fixtures (This is one of the most
> complicated executable applications - mxmlc):
>

> http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures...

>
> Here's a very simple example Generator from our test fixtures:
>

> http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures...
>
> And it's Template:
>
> http://github.com/lukebayes/project-sprouts/blob/master/test/fixtures...

>
> And here's a more complex Generator (For creating new Sprout Tools):
>

> http://github.com/lukebayes/project-sprouts/tree/master/lib/sprout/ge...

[Luke Bayes]

Hey Loren,

Some comments inline below:

On Sun, Jun 20, 2010 at 9:14 PM, Loren Norman <loren...@gmail.com> wrote:

Thanks for the write-up, Luke!

Well, it certainly looks a lot better than before. And I don't lament
the removal of Rubigen: it always seemed too narrowly-targeted for
general usage (just felt like we were hacking it to make it work for
us). Globals and untestability only make it more obvious.

I am still trying to figure out where Sprouts will fit in for other
languages and environments, though. I'm a long-time Rubyist, and I've
always appreciated Sprouts as sort of the "Rubification of Flash/Flex
projects", which roughly means injecting all of the great process and
workflow we commonly see in Ruby projects (git, gems, rake, CLI
interface, etc) into an environment that sorely needs it (dreadful,
proprietary IDEs and Ant tasks that only do exactly what they do and
afford little flexibility).

I'm still doing mostly ActionScript/Flex work day-to-day, so the initial implementations and integrations of Sprouts will continue to be Flash-centric. With that said - it was during this rewrite that it finally became crystal clear to me that Sprouts doesn't have anything to do with Flash and it could prove useful in many other environments. I'm thinking obvious environments like Haxe, Objective-C, HTML/CSS (static-ish sites), and even Java.

As far as Ruby tools go, I'm as frustrated by hoe and newgem as I am by Rubigen (and for similar reasons), so I could see Sprouts providing some benefits there. 

I have also found Ruby to be sorely lacking in clean, simple support for cross platform, distributed code. As it stands today, Ruby does not even come close to making applications work seamlessly across mac, win and *nix. This version of Sprouts goes a long way toward finishing the cross-platform Ruby story in a way where developers won't have to even think about it.

 

Would you say that Sprout now seeks to be the "Rubification of X
projects" where X is any given language or environment? I guess the
case where X = Ruby is the most interesting, since, by and large, the
community already HAS all of the best practices in use and would
(perhaps?) be slowed by the existence of an intermediate tool.

I think there's a big difference between Rails and Ruby, and I think that while the Rails camp seems to have a strong sense of best practices and whatnot, there's a dearth of directions for non-Rails work out there.... When I think of Sprouts for Ruby, I'm mainly thinking about something akin to newgem and some simple class/test/spec generators. Obviously, we can use RubyGems as-is for Ruby libraries. :-)

That said, it also seems as though you're building a meta-tool.
Codifying the way we create new tools is clearly valuable!

 

That's the idea that's still swirling a bit. I'm trying to create an interface around tools and it's kind of mind-numbing. The idea (as it stands today) is that tool developers can use Sprouts to create support for whatever executables, libraries and generators they want. The interface I'm providing should allow them to do this quickly, painlessly and without (much) concern for cross-platform support.

 

Anyway, still just trying to get my head around the direction and
philosophy. I'm pretty interested in helping out if it all makes sense
and I'm able to reasonably scratch some itches while I do it. Looking
forward to those getting started docs and some more answers here!

Any help will definitely be appreciated. We're just wrapping up the fluid/creative phases of work and getting down to nuts and bolts. Every new implementation turns up more details that need to be implemented, but it's no longer high-risk slow stuff - it's just jamming from here on out.

I'll be focusing on documentation over the coming weeks with the idea that once that's done, we can start pulling in more contributors.

Thank You!

Luke

--
You received this message because you are subscribed to the Google Groups "ProjectSprouts" group.
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to projectsprout...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/projectsprouts?hl=en

For other info you can visit our project at: http://projectsprouts.org, or on Github at: http://github.com/lukebayes/project-sprouts

[Matt Garland]

I'm having a bad morning, trying to get a Flash Builder project to
compile both flas and sprite files. Anyway, I think I've had it with
Flex/Flash Builder. The code editing is great, but the project
structure is constricting and, to me, mysterious even after years of
use.

I'm not interested in a general ruby project tool, but I do have some
burning desires for my AS projects. Apropos of nothing, here are some:

1. Easily set up compiles for any type of file (mxml, as, fla)
2. Compiled files are anywhere in the project...or even outside of it.
3. Parameterizable calls to jsfl (via some kind of hidden
preprocessing)
4. Calls to ANT tasks
5. Some kind of natural-language-based test tool like Rspec.
6. A white unicorn.
7. Some kind of Rake gui or command-line support from within Eclipse.
(Not sure I can go without Flash Builder completely).

Maybe Sprouts offers some of these already--I couldn't tell. I'm
looking into it. Just wanted to express my frustration with existing
tools for AS projects, especially non-Flex ones.

[Luke Bayes]

Hey Matt,

Thanks for posting here!

I'm not sure if Sprouts is exactly what you're looking for, but it could represent an improvement over what you're experiencing elsewhere....

Some comments inline below:

On Wed, Jun 23, 2010 at 10:03 AM, Matt Garland <mattjg...@gmail.com> wrote:

I'm having a bad morning,

Sorry to hear that - I'm finally having my first pleasant morning in quite some time!

 

trying to get a Flash Builder project to
compile both flas and sprite files.

We've pretty much run away from FLAs to the extent possible, so we don't have any existing support... BUT - if you have JSFL that you can call from the command line, you can definitely use Rake to trigger it. Here's a fantastic article that describes Rake and why we use it.

http://martinfowler.com/articles/rake.html

 

Anyway, I think I've had it with
Flex/Flash Builder. The code editing is great, but the project
structure is constricting and, to me, mysterious even after years of
use.

I'd caution you against violating their prescribed project structure. Sprouts will definitely facilitate this, but it will limit your (and your team's) freedom to choose their tools in the future....

 

I'm not interested in a general ruby project tool, but I do have some
burning desires for my AS projects. Apropos of nothing, here are some:

Yeah - the Ruby project support is really just for folks that are adding new features (bundles, generators libraries, etc.) to Sprouts.

1. Easily set up compiles for any type of file (mxml, as, fla)

Done-ish. No FLA, but we do have:

sprout -n as3 SomeProject

sprout -n mxml OtherProject

sprout -n air AnotherProject

 

2. Compiled files are anywhere in the project...or even outside of it.

That should work today - you may need to muck around with the mxmlc task's assumptions about your source path. Please hit me up on this list if you run into trouble with this.

 

3. Parameterizable calls to jsfl (via some kind of hidden
preprocessing)

This would be done with simple Rake tasks - they might look something like:

file 'bin/SwfFromAFla.swf' do

   sh "./path_to_jsfl_file.jsfl --arg1=#{value1} --arg2=#{value2}"

end

desc :compile_poopy_fla => 'bin/SwfFromAFla.swf'

# call with: rake compile_poopy_fla

 

4. Calls to ANT tasks

While this is technically possible, I can't in good conscience condone this kind of behavior. While you're out there writing those ANT tasks, just keep in mind that the creator of ANT has apologized publicly for unleashing such a monstrosity on the rest of us.

 

5. Some kind of natural-language-based test tool like Rspec.

This sounds great. I know there are a couple attempts out there, but I haven't used any of them yet. This library will be orthogonal to what Sprouts attempts to accomplish, but if it's an itch you'd like to scratch - check out the asunit4 stuff, it's a clean foundation for just such a thing....

http://github.com/patternpark/asunit/tree/master/asunit-4.0/

 

6. A white unicorn.

Sadly, we have only rainbow unicorns...

 

7. Some kind of Rake gui or command-line support from within Eclipse.
(Not sure I can go without Flash Builder completely).

Yeah - there's been talk of GUI wrappers and I'm interested in such a thing. The upcoming version 1.0 release has features that will finally make the round-trip between Rakefile and GUI possible - but I can't even speculate on when that kind of work might be complete.

Maybe Sprouts offers some of these already--I couldn't tell. I'm
looking into it. Just wanted to express my frustration with existing
tools for AS projects, especially non-Flex ones.

It's just this frustration that led to the creation of Sprouts, and it's the frustrations that Sprouts itself caused me (and others) that has led to the v1 rebuild...

I think we're finally approaching the kind of foundation that I've been dreaming about and definitely appreciate ongoing feedback - and of course - contributions.

[Luke Bayes]

Quick correction - this line:

desc :compile_poopy_fla => 'bin/SwfFromAFla.swf'

Should be:

desc "Compile Description"

task :compile_poopy_fla => 'bin/SwfFromAFla.swf'

Thanks,

Luke

[Matt Garland]

Thanks for the response Luke. I have been getting into Rake and enjoying it, so I think I'll go full Rake. I imagine that there is an "ANT Window"-equivalent gui for rake in the Eclipse-o-sphere, so I'll look there first. 

I think FLA compilation should not be an afterthought. Unless you are doing Flex (and even if you do, sometimes), there's going to be fla-compiling somewhere in your build process, whether you embed symbols or whole swfs. Of course, if you don't have to work closely with designers, you are a lucky man, you can draw with code, or do layout with code or configuration...but how many of us in the AS-project business are that lucky? My designer-dev co-workers bucked at the painful round trip with Flex. They won't even try Catalyst, and I don't blame them.

FYI Googlers: Rake can run jsfl like this (at least on OS X):

task :compile_src_flas do

 %x{open compileSRCFlas.jsfl}

end

%x[my command line code]--this is equivalent to ANT exec.

Matt Garland
ma...@pet-theory.com
pet-theory.com

[Luke Bayes]

Hey Matt,

Thanks for the thoughts!

I agree with you about supporting Fla-based workflows, and I'll be looking forward to contributions of Rake tasks that support them. 

Sprouts has mostly grown out of itches that I needed to scratch and as it turns out, we've generally checked our Symbol-SWFs into version control and let the designers manage that side of things. This is especially important when setting up a Continuous Integration server, b/c they are usually on Linux boxes that can't run Authoring.

As far as your task goes though - here are some adjustments:

file "skins/SomeSkin.fla"

file "bin/SomeSkin.swf" => "skins/SomeSkin.fla" do

   sh "open skins/CompileSomeSkin.jsfl"

end

The differences here are:

1) We've created two Rake File Tasks - one for our input, and one for our output.

2) Rake will compare the updated timestamps of the input and output files and only call the provided block IF the input file (fla) is newer than the output file (swf) OR if the output file doesn't exist.

3) With Rake, we can shell out with less ceremony using the 'sh' command

(Optional): I usually like to add a 'puts' statement to the blocks in my File Tasks so that I know for sure when it runs and when it doesn't, but I can't remember if the 'sh' command automatically does that, so if it doesn't, I'd do something more like:

file "bin/SomeSkin.swf" => "skins/SomeSkin.fla" do

  cmd = "open skins/CompileSomeSkin.jsfl"

  puts cmd

  sh cmd

end

Thanks!

Luke

--

[Stray]

Hey Matt / Luke

Re Fla based workflows - which mine is, in that designers produce assets / animations etc and I embed them via a stylesheet... 

Fraid there's no way around the Flash IDE part in my mind. I usually have to rename their randomly titled stage assets, or at least give them export class names in the library etc.

So - I can't see how just compiling the skin is going to be enough. It would be lovely to ditch the Flash IDE but I've never worked with a designer who was organised enough for me to just use their Fla without editing it!

Just chipping that in incase it has been overlooked and the rainbow unicorn of Fla compilation turns out to be a very good looking donkey. Your mileage my vary etc.

Stray

[Luke Bayes]

Hey Stray,

Thanks for pitching in!

Just to clarify, I don't mean to say that I never open Authoring when working with designers, I just mean to say that - for those assets, we've historically checked the SWFs into version control - which essentially means their compilation step is manual and doesn't wind up in our Rakefile....

The upcoming Sprouts release will include much simpler support for folks to contribute Rake tasks (and other features), so I'm definitely looking forward to seeing contributions around Fla-based workflows.

Thanks,

Luke

[Stray]

Cheers Luke - yes, I think manual compilation of Swfs is here to stay.

Very good news about the simpler rake tasks :)

Sx