Month: August 2008

ruby, Technology

Flex Remoting in Ruby? Easy Choice.

Posted on by rkischuk

I’ve had a rocky relationship with Adobe Flex.  An awkward attempt to migrate an existing app to Flex caused several strong reactions and cost a good bit of developer goodwill.  The details of that decision are messy and irrelevant.  The experience sucked.

On the other hand, I could not have built the FeatureFrame technology without Flex.  There’s no simpler way to build a widgetized video player with embedded applications.  The same pains of horrible documentation, irrational design decisions, insidious bugs, and painful workarounds remain, but the things it makes easier pale in comparison to the obstacles of any other approach.

And of course in building a virtual world such as Elf Island, Flex is an obvious choice if you want to play it in the browser and build maintainable code (binary Flash files make a poor foundation for a sustainable product).

For most languages you might want to build a Flex app in, free, open options are available.  I had a recent need to prototype a solution that might also turn into a test fixture for our vendors to use in producing Flash apps, so Rails seemed the natural solution for simplicity of deployment and prototyping speed.

The main choices to support Flex Remoting calls in Ruby are RubyAMF and WebORB.

In trying to decide, I encountered a very useful comment in this thread:

"The biggest difference between what WEBorb provides and what RubyAMF(only
AMF alternative I am aware of) provides is workflow.  Weborb is a great
product written by guys who do java primarily.  So it follows the patterns
of having a Service layer that connects you to your application.

RubyAMF is written by a ruby developer."

Immediately, I know what my choice is.  WebORB is obviously the trap of over-architecture and suffering that pervades “correct” Java development.  A quick search on how to use RubyAMF (in a controller) confirmed my suspicions:


respond_to do |format|
format.html # index.rhtml
format.xml { render :xml => @people.to_xml }
format.amf { render :amf => @people }
end

When I see code like this and compare it to the WebORB or GraniteDS implementations, I just can’t imagine choosing those other paths.

Rails + RubyAMF is concise, clean and obvious in what it’s doing.  Yes, please.

Advertisement
3
Java, Technology

Outsource the Scaffolding

Posted on by rkischuk

Just today, I twittered a link to an insightful blog post, “Here’s the Deadliest Catch: Hiring an Agency to Build Your Startup”.  The title is largely self-explanatory, and I may blog my own riff on it at a later date.  Digg is often raised as a counter-example to outsourcing development of a startup, with version one developed for $200.  So how do you decide what the right balance is for you?

Ruby on Rails has this concept of “scaffolding“, which makes it trivial to get a simple web application running to perform create/read/update/delete operations on a simple business object.  So if you wanted to build a basic address book, Rails could basically create that application with a one line scaffold generate script.  It produces a simple web interface, and handles all of the database calls for you.  Java code to accomplish the same task is typically more verbose, but even if you wrote it from scratch in any language, it would be fairly intuitive for an experienced developer with no knowledge of your business to immediately understand the app and how to extend and maintain it.

At some point, almost any app becomes more complex.  The current version of Digg could not be developed for $200, and I dare say it would be foolish for someone like Digg to build an application of its current complexity completely contracted out.

I’ve been in startups all along the continuum, and made transitions between different mixes of internal versus external product development and infrastructure.  My current opinion is to outsource the scaffolding.  If you’re deploying a java/tomcat/MySQL app on a plain vanilla linux distribution, you can probably have a contract sys admin put that together for you – any other competent admin can look at how it’s configured and fix your problems.  When you start depending on all sorts of custom extensions, configurations, replication, huge scale, and/or DB sharding, it’s probably time to hire some admins that can own that custom knowledge you depend on.

The same thing goes for product development.  Are you building out a marketing web site?  An app that could be built with Rails scaffolding?  Contract it out – good contractors will realize how easy it is and crank it out for cheap (though maybe more than $200).  Most capable software developers you would hire or have hired don’t want to build or maintain that stuff anyhow.  Save internal development for the custom, proprietary stuff you need to spend time on, the meat and potatoes code that differentiates your application from everybody else’s.  The stuff that will take even a good developer more than a couple of hours to really comprehend.  Start throwing the switch to internal resources when it starts to get complicated – you’ll be much happier.  Trying to insource knowledge of a complex application that’s already been written by someone else is doable, but quite a challenge.

5