Software Remodeling in Practice: Build an Addition

schedule Oct 16th 10:00 AM - 10:45 AM place Tiered Classroom people 5 Attending

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 10 months ago

Comments Subscribe to Comments

comment Comment on this Submission
  • George Dinwiddie
    By George Dinwiddie  ~  10 months ago
    reply Reply

    Scott,

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