The Truth About Integrating Rails In The Enterprise

Ruby on Rails is a great RAD framework. We use it all the time. But one place Rails loses its magic–while not the fault of the framework itself–is with external integrations to legacy systems.

First of all, soap4r sucks. Everyone I’ve seen try to pick it up has gotten frustrated and angry at how awkward it is to write a SOAP client in Ruby compared to Java and .Net tools, which can do the same thing in a matter of minutes. Since RoR IDEs aren’t exactly 1337 yet, we need to put some serious love here as a community to prevent larger companies with heavy SOA leanings from running away screaming.

For some reason, many people seem to think that pouring t3h Rails int3rn3ts into an infrastructure will suddenly trim 75%+ off all development and maintenance costs, complete with rounded corners and shrink-wrapped buttons. Wrong. Many of the development tasks will take significantly shorter times to develop under timeframe expectations relative to Java and .Net, yes, but you can’t avoid costs associated with migrating legacy data and integrating with retarded external systems such as your ghetto-ass SOAP services. Nor should you avoid design activities such as usability analysis or proper testing practices. 

So if you have a web project that lives in complete isolation and does not have any legacy issues with which to deal, OpenRain can bust out that web project in a heartbeat. But if you have unresolved data management and integration issues, there is no acts_as_silver_bullet plugin which can save you the burden of having to actually think about and address those problems. Rails isn’t the cold bucket of water for your data nightmares.

Speaking Twice At ABLEconf: Saturday, September 20th, 2008

I’ll be giving two sessions this Saturday, September 20th, 2008 at ABLEconf: Arizona Business and Liberty Experience hosted at the University of Advancing Technology. The first will be a ~50 minute getting-started-with-ruby-on-rails type session aimed at developers similar to the one I’m giving this Wednesday for Joe Developer. The second will be a plug-heavy talk over how OpenRain does F/OSS-friendly web development in the commercial space using F/OSS software and tools, targeted for a business-minded crowd.

ABLEconf is a new event so I’m not sure what to expect, though I’d put my money on a lot of systems-level event content since much of the participation seems to be from local Linux groups.

Speaking At Joe Developer: Wednesday, September 17th, 2008

This Wednesday evening, OpenRain will be hosting and providing food for Phoenix’s East-valley Joe Developer group. I’ll be giving a getting-started-with-ruby-on-rails type demo, after which I’m sure there’ll be good conversation and fun. Attendance and food are free. Food will be hot at 6PM. [Venue] [Google Group]

Debugging JavaScript With Safari

I usually use FireBug and other FireFox-based tools for troubleshooting JavaScript issues, but never found a solid way to approach it in Safari, my primary browser. It turns out that the nightly builds of WebKit (Safari’s core) also come with a great utility called Drosera.app, which allows you to attach to a running WebKit process and get funky with a JavaScript console.

w00t l00ps! drosera.png

Rails 2.0: selenium-on-rails routes.rb fix

When I updated a few projects to Rails 2.0 last year, selenium-on-rails stopped working … some issue with routing and the lame way selenium-on-rails adds its routes. I didn’t spend the time to figure out exactly what the routing problem was, but did manage to hack a quick fix into routes.rb. This feels like the Wrong Way for an ultimate fix but it at least solves the immediate problem. Shove these rules into your routes.rb and the /selenium path should start resolving again…

Continue reading Rails 2.0: selenium-on-rails routes.rb fix