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 ...*

Ruby 1.9.1 RDoc No Memory Error

When running:

gem install wxruby-ruby19

I got the following RDoc error:

Successfully installed wxruby-ruby19-2.0.1-x86-mingw32
1 gem installed
Installing ri documentation for wxruby-ruby19-2.0.1-x86-mingw32...
Updating class cache with 1663 classes...
Installing RDoc documentation for wxruby-ruby19-2.0.1-x86-mingw32...
c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `each': failed to allocate memory (NoMemoryError)
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `grep'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:73:in `binary?'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/parser.rb:90:in `can_parse'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:157:in `block in normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `each'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:185:in `list_files_in_directory'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:166:in `block in normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `each'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:150:in `normalized_file_list'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:197:in `parse_files'
        from c:/ruby19/lib/ruby/1.9.1/rdoc/rdoc.rb:257:in `document'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:177:in `run_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:137:in `install_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/doc_manager.rb:123:in `generate_rdoc'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:152:in `block in execute'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:151:in `each'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:151:in `execute'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command.rb:257:in `invoke'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:132:in `process_args'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:102:in `run'
        from C:/ruby19/lib/ruby/gems/1.9.1/gems/gems/rubygems-update-1.3.5/lib/rubygems/gem_runner.rb:58:in `run'
        from c:/ruby19/bin/gem:21:in `<main>'

For a large gem, RDoc has a loop that begins to chew up available memory.  Ruby's garbage collection utility (GC) can be used to fix this.  To do so edit Ruby's rdoc.rb by inserting:

GC.start

somewhere in the "when directory" switch (see my hacked rdoc.rb).  This will force garbage collection before calling a memory intensive step in the loop.  I was able to install the wxruby plug-in successfully this way.

Groovy 1.5: No Private for You!

Considering Groovy for your next big project?  We did.  All things considered, it figured to be a safe choice given its Java pedigree. From the limited exposure I'd had to Groovy up until that point, it looked and felt remarkably familiar to Ruby (a good thing).  I had even heard you could cut & paste any amount of Java into a .groovy file and it would just work.  Depending on what 'work' actually means, this is mostly true. 

One of the small untruths about Groovy behaving 'just like Java' is worth serious consideration - especially if you want your .groovy code to become API-ready.

RailsConf 2008 Saturday Night Key Note: Kent Beck

I got lazy and didn't blog about DHH's key note last night.  So, before I get on with Kent's salient story-style wisdom, I'll quickly catch up with DHH's.

Continue reading "RailsConf 2008 Saturday Night Key Note: Kent Beck" »

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

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.

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Summary: Dialogue Concerning the Two Chief Modeling Systems

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

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.

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.

Yellow Pages.com Rewrite

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

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.

Ruby Snippet: Shortening Long Strings For Display

Ever had a long string like this:  "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"? 

Here's a little snippet that does just this.  It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.

Resolving Files with TextMate, Subversion, and FileMerge

If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable.  Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.

Note: This post assumes you are on a Mac :^).

Ruby Arrays: select(), collect(), and map()

As a former Java developer and new to the concept of blocks, these API options seem perplexing at first.   They're not.  All three take a block.  How they use the block is what distinguishes them.  You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.