RubyAMF State of the Union

[Tony Hillerson]

(Cross-posted from rubyamf.org blog: http://blog.rubyamf.org/?p=98)

Hello Chums,

I wanted to give everyone an update on where RubyAMF is right now.

Aaron started RubyAMF over a year ago, and he put a lot of long hours
and hard work into it. A few months ago Aryk Grosz from Mixbook.com
helped out with a lot of speed enhancements. We need to give mad props
to these guys for all the work they put in. Also, to everyone else
who's submitted patches or filed bugs, or, like Peter, written about
RubyAMF.

I've spoken with Aaron about where things are going, and he's pretty
burnt out and he's interested in moving on to some other cool projects
he has in mind. It's sad, but he's done a lot, so no one can fault
him.

Where does that leave RubyAMF? Well, in your hands.

I've been interested in RubyAMF for a while, and I've slowly come to
understand how things work, but I'm certainly not as smart as Aaron,
so the best I can do to help RubyAMF is to put out a call to action.

RubyAMF is a going to be a community effort. It's not like we need to
write it from scratch, but there are some important things that need
doing to make sure this project is the best it can be.

Here's what I'd like to propose as the set of values for the plugin
(in order):

Measurable Goals
1.) Stability
2.) Implementation of the AMF specs (AMF3 and AMF0)
3.) Speed

Subjective Goals
4.) Invisibility
5.) Good Development Workflow

The last two are subjective because different people will see these
goals being met differently. Invisibility means that the plugin should
be as easy to use out of the box as possible, while meeting the other
goals. It should also stay out of the way as much as possible during
execution. Offering a good development workflow is a nice to have, and
the lowest priority, but it's still nice to have. Things in that
heading are generators, ease of configuration, and the power to do
more complex things when necessary.

To meet these goals, we need a few things. We need participation from
the community in these areas:

-- Tests
We need testing of all parts of the framework from serialization/
deserialzation to rails integration. Test::Unit? Rspec? Mocks or no
mocks? I don't know. We need these early so that we can measure the
stability of the plugin against patches or enhancements.

-- Benchmarks
Speed is important, especially since we're working with a dynamic
language and a framework like Rails that favors development workflow
over raw speed. We need benchmarks to enable us to have measurable
landmarks for conversations around speed.

-- Bug Fixes
Once we have the above, it becomes a lot easier to accept submissions,
or more importantly reject them with solid reasoning and a goal to
shoot for. Submission breaks a test? it gets rejected. Submission
works but slows us down? try again.

-- QA
Anyone using RubyAMF who finds a bug and files it helps.

-- Development Enhancements
The nice touches that make it easier to work with RubyAMF.

-- Documentation
Of course it should work out of the box, and have good documentation
in the config (it does), but we could use some tutorials, some
walkthroughs, some complex use cases.

Marketing (just kidding)

So, I suggest if you can help in any way post on here. I'm busy too,
but I'll try and help get this effort into shape. I'm not going to say
I have the power to deny anyone into the project, but hopefully
everyone can get into the action. The best community code projects
work when people who put in the time and effort and show good results
surface around areas of the project - in this case around the areas
that I mentioned above. It will take a little time for that to happen,
but until then we can work as a group to discuss the merits of any
descisions that need to be made.

So.. that was a long post, but that's the state of the community. If
anyone interested steps up we can start to talk about where the code
is.

Thanks a lot guys!

-Tony

[vixiom]

Hey Tony,

I'm up for writing documentation/tutorials.

- Alastair

[Cliff Rowley]

We have a couple of patches to contribute, and we're (will be) using
RubyAMF in a production environment. We're pretty early in
development (4th iteration), but we're using it pretty extensively
(our product is an application, not just a simple RIA) so we'll
probably have a few more to come.

Cliff

[Tony Hillerson]

Good to hear, thanks Cliff

[Tony Hillerson]

Sounds good. Let me put a post up here in a while about some tutorials
that are either ready or almost ready. Hint: look in /branches/
examples

[Todd Johnson]

The past couple days I have been putting together a blog post showing how I was using ramf and pureMVC.  I'd be happy to contribute that or anything else I could do for the project.
Todd

[prpht9]

I contacted Aaron on this group a while back about helping out some,
but I've been dragged into work pretty heavily. So, spare time is
hard to come by. I do still intend to come back to this in the next 6
months. Just thought I'd let you know the interest is still out
there.

-Chris

[Tony Hillerson]

Sure. The challenge of a project like this is that we all have day
jobs and other obligations. Help as you're able.