Software Remodeling in Practice: Build an Addition

schedule 10:00 AM - 10:45 AM place Tiered Classroom

Working on a legacy project is a lot like working on a house. We'll explore this metaphor further by taking a Software Remodeling approach to adding new functionality to an existing web application, but using a different language and framework than the original. A great discussion on how to mix newer technologies into older apps.

 
1 favorite thumb_down thumb_up 1 comment visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Example:
Blog site
old: Rails 3.2 app (Ruby 1.9.2)
new: Node app

Setting:
* About 6 months ago, organization made the decision to start all new projects in Node.
* Improvements need to be made to a Rails application that the team built several years ago.
* An additional admin feature is needed to make it possible to manage comments on the blog site. This should be available from `/admin/comments`.

Problems:
* Enthusiasm for Rails and Ruby have started to wane on the team.
* The Rails app hasn't been kept up-to-date and there's concern that it's going to be hard to work with as a result.
* None of the team members have their development environment setup to run the app
* There are very few tests for the older Rails app.

Approach:
* Write some acceptance tests to cover the important bits of functionality
* addresses the problem of there being very few tests
* Scenarios to cover:
* logging in
* viewing a blog post with its comments
* Write the acceptance test suite so that it can be run against any url
* Write the first two scenarios against the production version of the application
* Setup docker-compose to manage the development environment
* addresses the problem of setting up a development environment
* Create a `db` container for hosting the database
* Create a `blog` container for running the older Rails app
* Run the acceptance tests from earlier against the dockerized version
* Write additional acceptance tests scenarios against the dockerized version of the application
* adding a blog post
* making a comment on a blog post
* Create a failing acceptance test for the new feature
* addresses the problem of giving us a way to know when we're done
* Scenarios to cover
* Ensure that both applications are using the same database
* Ensure that the Node app can only be accessed after logging into the Rails app
* Create a new Node application inside of a Docker container

* addresses the problem of the team wanting to use Node for new work
* Create a `blog-comments` container for hosting the new Node app
* Create a nginx container to act as a proxy for both apps
* addresses the problem of needing to send `/admin/comments` to the new Node app and all other requests to the old Rails app
* Have the proxy send all traffic that's directed at `/admin/comments` to the Node app

* Review benefits to approach

Learning Outcome

Attendees will walk away with a strategy that they can apply to their own projects that will allow them to introduce new technologies onto their projects without having to do a full rewrite.

Target Audience

Anyone who works on code someone else wrote

Prerequisite

Some familiarity with web applications will be best.

schedule Submitted 1 month ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • George Dinwiddie
    By George Dinwiddie  ~  3 weeks ago
    reply Reply

    Scott,

    I think you could make the abstract more enticing to your intended audience.