So here’s the scoop. Aryk Grosz from MixBook contacted me about using RubyAMF and some experiences he was having. RubyAMF would start to slow down with large complex data structures even slower than WebORB depending on the size, Yikes! Aryk had put time into optimizing RubyAMF and you would not believe the results we’re getting.

I went down to Mixbook in San Jose on Sunday and spent a little time with Aryk ripping apart RubyAMF. So we’ve pretty much re-written RubyAMF, here’s a brief rundown of what’s going on.

First let’s talk restructure. We ripped out 60% of the code base which was legacy from RAMFL. I won’t go into the gory details but we’ve re-arranged a lot, changed a lot of names. For example ValueObjects are now ClassMappings. Which is more appropriate because RAMF has full class mapping support. We’ve also put an init.rb file in the plugin so all the requires get done on application startup.

There are a couple other features we’ve added to class mapping definitions, such as the :associations, :attributes, and :ignore_fields properties. The :ignore_fields is just like it sounds, for a specific class mapping you can ignore specific properties on it. You can also define a global ignore fields like so: ClassMappings.ignore_fields.

The :associations and :attributes are for performance reasons. You aren’t required to use them, but if you do it speeds up the serializer even more. We’ve also change the names of :incoming / :map_to / utgoing to :actionscript / :ruby.

Performance! This thing is about 5x faster. As an example, a data structure of about 1500 objects that’s used in Mixbook takes around 35 seconds with WebORB. RAMF averages 2.4 seconds. Sweet! You can even see the speed increase on one object. It’s that much faster.

We also decreased the size of the data transfer. As an example, let’s say an AMF message was 250K, it would now be about 100K. That’s a huge difference.

That’s just a small preview of what’s going on. Sorry for the inconvenience of not getting 1.3.4 done last week, but as soon as we started these changes and optimizations – 1.3.4 was obsolete.

So hats off to Aryk for the help, he did a most of the speed optimizations and has been refactoring and writing a ton for RubyAMF. Thanks for the help!

And to top it all off, RubyAMF will have it’s first “in production” customer over at MixBook. They’re working on re-factoring their rails app to use RubyAMF. Awesome!

-Aaron

First I’d like to officially welcome Seth Tenenbaum to RubyAMF. He started helping quite a bit and his efforts are so much appreciated.

Next is some project maintenance and installing some software to work better for future developers and community. I’ll be moving SVN over to my dedicated server. The SVN move is for a new Trac install.

I changed the forum install to phpBB. And of course the wiki is being neglected for work on RubyAMF. You can still access the old wiki here.

And I’m sure some are wondering about the next release. We’ve got a pretty short bug list, but the bugs are critical. Once those are all fixed 1.3.4 will be released. Seth, Tony, and myself are working on bug fixes and feature additions.

Hang in everyone! I’ll officially be back from vacation on the 8th to release 1.3.4 and gear up for the next dev tasks. Additionally I don’t see any major conflicts with RubyAMF and Rails 2, as there is only one entry point into Rails (aside from the rubyamf controller).

RubyAMF is getting to the point where it’s a great experience tying it in with Rails (and of course with Lite) – the fact that it works with scaffolding and in your controller with render :amf makes it a winner for me. But if people don’t use it because they can’t read the site then it’s time for an update. I love working on RubyAMF so I want everyone to have a great experience with it. Maybe this sounds weird – but I LOVE remoting. The first project I did with remoting was with MercuryCloud and Patrick Mineault. Ever since then it’s been a key part of almost every project I build. So I’m not trying to be pushy about RubyAMF at all, just know that everything I put into RubyAMF is pretty carefully thought out for performance factor and ease of use.

What do you think, time for a re-skin or color update?

Here’s the session description:

Learn how to integrate your Flex applications with a Ruby on Rails back end. Topics include remoting, using ActiveRecords in Flex, and the Flex/RoR SDK. Finally, learn how to deploy your Flex application to Adobe Integrated Runtime (AIR).

RubyAMF exposure will be limited, but thanks goes to Tony for even considering RubyAMF to be part of his presentation. Thanks Tony!

• Any objects properties whether it be a basic object, or value object get merged into the params hash. ONLY the first parameter gets merged though.
• Any incoming value object also gets put into params[:classtype]. So if an incoming VO is of the type “vo.Event”, it will be put in params[:event]. This will enable you to fully use scaffolding without adding is_amf conditionals.

So what does this mean? If you send parameters correctly from Flash, there are only a few updates to get everything working correctly on the rails side. Here’s a generic example that should translate to a real working example.

RAILS:

class MyService < ActionController
  def update
    user = User.find(params[:id])
    if is_amf
      u = user.update_attributes(:name => params[:name], :email => params[:email])
    else
      user = User.find(:id)
    end
    if u
      render :amf => true
    end
  end

  def create
   if is_amf
     user = User.new({:name => params[:name], :email => params[:email]})
   else
     user = User.new(params[:user])
   end
   if user.save
     render :amf => true
   end
  end

  def destroy
   user = User.find(params[:id])
   user.destroy
   render :amf => true
  end
end

So in this example the destroy method works without having to mix in the is_amf variable. The create and update method has to mix in the is_amf variable because we’re not passing value objects back and forth.

Here is the corresponding AS3 to call these methods correctly.

AS3

function createUser():void
{
  myservice.create([{name:'asdfasdf',email:'aaron'}], onResult,onFault);
}

function updateUser(user:Object):void
{
   //user should be  => {id:1, name:'Aaron', email:'aaron@something.com'}
   myservice.update([user],onResult,onFault);
}

function destroyUser(id:Number):void
{
  myservice.destroy([{id:id}],onResult,onFault);
}

So what do we do to update the create and update methods so they don’t have to use is_amf? Value objects or _explicitType. These are two options to help you map everything the way you want. Here’s how they both work.

Value objects are simple. They boil down to a generic object with one extra piece of information – the class type. In our case. A ‘User’ class. So when you instantiate a value object, and send it over to RubyAMF, all your properties come over in a generic object, but it also sends the class type. Pretty simple. On the RubyAMF side your class type is caught and a Value Object of the same type is instantiated in Ruby / Rails. So if your value object is a User class, it is in turned mapped to params[:user].

So do we absolutely need value objects to get the params[:user] hash to be the correct object? No. RubyAMF uses a special property to handle value objects on the server side. _explicitType. If you send a generic object with the _explicitType property, it will be turned into a corresponding value object for you. It just so happens that the _explicitType is used to map a value object class to params[:classtype]. So we can use this to map our generic object to the params[:user].

Let’s look at how we can update methods so we don’t need to use is_amf.

Rails:

def create
  user = User.new(params[:user])
  if user.save
    render :amf => user.as_single!
  end
end

def update
  user = User.find(params[:id])
  if user.update_attributes(params[:user])
    render :amf => true
  end
end

AS3

function createUser():void
{
  myservice.create([{_explicitType:'user', name:'Aaron', email:'aaron@something.com'}],onResult,onFault);
}
function updateUser(user):void
{
  //uyser should be => {id:1, _explicitType:'user', name:"Aaron", email:"myemail"}
  myservice.update([user],onResult,onFault)
}

So by specifying the _explicitType property, it’s going to put an active record update_hash in params[:user]. Pretty cool. Now I’m not suggesting you use _explicitType at all times as it’s kind of a hack. You should use value objects instead. But hey, you’ll probably benefit from knowing more about RubyAMF.

Please let me know if there are any questions or suggestions for making it better.

Rant is a mashup of ANT and Ruby for the best of both worlds. Ant is useful for a lot of little tasks – setting up hierarchal chains of execution, executing scripts, moving files, generate templates etc. But then there are times when I wish I could just script parts of the build process. Now you can with Rant. As mentioned, it’s a mashup of ant and ruby. During the build process, an entry point into a ruby file is made that allows you to execute commands, which can be whatever you think of in ruby.

Rant is an all around build tool for those developing projects in Flash or Flex, but don’t want to use Flash IDE or Flex Builder.

Currently I’ve only been able to test this on a Mac, and am looking for some eyes to make sure this works in Windows / FlashDevelop. Give it a shot! Download it here.

Please check out the readme file as well. This is a great place to start.
See the readme file.