Table or Booth?

SOA, May You REST in Pieces.

Save your valuable time and don't watch this attempt to pump blood into a cadaver: http://www.infoq.com/presentations/Reincarnation-SOA-Anne-Thomas-Manes.  This presentation was so staggeringly ineffective and useless that I felt moved to write yet another SOA epitaph.

I believed in SOA at first.  That was until I had to get small web-based applications built, quickly.  That was until I tried to integrate one of them with Amazon Web Services and went with Amazon's RESTful version (as did an overwhelming majority of all other mash-up developers).

On planet earth, SOA was a vendor-driven monster the best of us eventually ran from.  To survive it, we protected our sanity with a bit of HTTP armor and plenty of REST.

It was about this time that I fell in love with Ruby and eventually, Rails.  Rails, in case you've been living in a SOA catacomb, is a RESTful framework from the smallest brick, on up.

But hang on, buzzword vultures.  Even Rails, at the time of this writing, isn't even cutting hype-edge anymore.  'Cloud', whatever that really means, is all the rage.

And yet, technology hype cycles, no matter how overblown, do have real value.  Planted in the compost pile of rotting buzz are vibrant seeds of truth.

If nothing else, hype cycles force us to take sides.  Sometimes these sides form around the best way to grow a seed of truth.

In fairness to SOA, we were confronted with the idea that standardized system to system interaction over HTTP (with XML and XML Schema) could be an effective building block for highly interoperable systems. 

Fair enough.  So where did it go wrong?

As I see it, SOA architect-astronauts described the wrong environment for growth of standardized system to system interaction over HTTP.  Specifically:

• In reality, there were too many non-standard vendor implementations of WS-* (WS-Death*) which led to ...
• WS-* required wholesale vendor buy-in to expensive tools and software infrastructure.  Startups not welcome!
• SOAP didn't effectively reuse aspects of HTTP.  It ignored three other useful HTTP verbs completely, missing a huge opportunity to make web services really simple.
• SOA required massive up-front thinking to be even partially useful.  Despite SOA evangelists' insistance in top-down/bottom-up agnosticism, SOA was not a bottom-up/organic way of thinking.  And, more than we'd like, 'organically' is typically how we must go about building systems.

Sometimes you see a presentation that is so vapid and useless that you're moved to do something about it.  Or, just moved to throw up.  This was one of those for me.

OK, OK.  Being positive ... 

A little reminiscing from time to time does help you think about how you got to where you are and the little disasters that, with God's grace, you navigated along the way.   For that I'll be forever grateful.

*Organs play ...*

RIAs - The New Web UI

SproutCore is slick; has a RoR + Apple pedigree & leverages Javascript very nicely.  MobileMe integrates it.  Apple contributes heavily to the project.  Silverlight, AIR, and Google Gears compete.  Silverlight and GG require browser plug-ins.  Only GGs is open-source.  Here's a good overview: http://rapidappsgroup.com/content/desktop-web-applications-using-sproutcore/

RailsConf 2008

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

The Rails Edge, 2006 - Day 1

In this post and the two that follow, I highlight interesting talks at The Rails Edge, 2006.  I do it for Google searching posterity and for my admittedly selfish desire to reinforce key concepts presented. 

Rails Load Path Resolution Tip

Nothing ground breaking in this post.  I write it only because the existing documentation for this behavior is weak or nonexistent. 

Have you ever seen the following message while testing your Rails app?

NameError: uninitialized constant ... blah, blah

Why Ruby?

Several people I know have asked me this recently.  Without just pointing straight to Bruce Tate, here's what I've come up with.

<short_answer>
* Ruby is an order of magnitude more powerful and less bloated than Java
* Ruby has Rails and an explosion of new libraries being built with or for Ruby
* Ruby will make you look good to your customers by developing more efficiently, making you more money
* Ruby is hot
</short_answer>