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.
> 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.
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.
> 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.
> > 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.
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
On Jan 15, 2008 9:21 AM, Tony Hillerson <tony.hiller...@gmail.com> wrote:
> > > 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.
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
On Jan 7, 9:47 pm, Tony Hillerson <tony.hiller...@gmail.com> wrote:
> 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.
> 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
> On Jan 7, 9:47 pm, Tony Hillerson <tony.hiller...@gmail.com> wrote:> (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.
