Friday: Mapping Rails To Legacy Systems

By Stephen Becker IV & Devon Jones

rails at vonage

  • subscribe system
  • metrics mole
  • restful services
  • vfax
  • numerous other existing apps
  • multiple rails projects in development

key strategic elements

  • change gradually and consistently
  • small programs and projects
  • transparent interaces

small projects succeed

Change gradually and consistently

  • people fear change
  • small projects are low risk projects
  • adjust course rapidly
  • show success early and often

small programs

  • break up business logic into atomic chunks
  • small scopes – create small and simple services that do their job and interface with others well

transparent interfaces

  • design for visibility to make consumption, inspection and debugging easy
  • output in a predictable and dependable way
  • allows for easy re-use

Rails tactics for legacy

active record in legacy databases

  • database degredation
  • documentation
  • a non standard database schema
    • 8 different ways to represent false
    • date as a varchar

User interface integration

  • transparent proxy
    • noodle
    • transproxy and squid
  • single sign-on keys

did it work?

  • quick time to market
  • maintainability
  • testing
  • reduced lines of code
  • repurposing old data
    • maps
    • metric
    • project tracking
    • testing

where does rails fit

  • rapid prototyping
  • mission typical tasks (non business critical)
  • cost analysis
    • development time vs. hardware

is it ready?

  • greater focus on rails in apache (not on, in, think mod_php, etc.)
  • rubyvm
    • jruby, yarv, parrot
  • user commented docs
  • cookie-less sessions
  • composite keys


Sorry, comments are closed for this article to ease the burden of pruning spam.


Authored by John Nunemaker (Noo-neh-maker), a programmer who has fallen deeply in love with Ruby. Learn More.


Release your software more often with fewer problems.
Flip your features.