Rewriting a (large) PHP application in Rails, part 2

Posted by andy

In my previous post on this topic I described the method we used to convert a legacy MySQL PHP database to a Rails conformant PostgreSQL hosted version. In this article I will tell a bit about how we converted the HTML of the application to Rails layout templates and partials.

Extracting HTML from Firefox DOM

We first started out with attempting to rewrite the table heavy design to CSS. We soon realised that this was a project on itself so we decided to work with what we have. Since most of the HTML code is intermingled with PHP logic it was really not an option to examine the numerous .php files and cut ‘n paste what we needed. We basically used the excellent Firefox View Formatted Source extension to take snapshots of the DOM tree of rendered pages (look here if you’re on FF2).

Getting the HTML from the Firefox DOM meant we had properly balanced HTML! The real work was to extract layout templates and to identify the partials. This turned out to relatively easy. The really hard part was to get the code to display properly in Internet Explorer, which unfortunately still makes up about 70% of all traffic to the site.

Writing down business logic

The original project never had functional or technical specifications so I scheduled 3 sessions spread over 2 weeks with the (back-end) users of the system. We identified the business logic and rules of the system as best as we could during these (1-2 hour) sessions. The whole business logic was then written again from scratch in Ruby. I figured it would have take much longer if I had examined the PHP code myself. This might not be an option for you though. Anyway, during these 2 weeks at the end of each day a small number of functionalities would be delivered for testing. In practice the user(s) would only test functionality and provide feedback every 3-4 days (busy schedules on both sides, so noone enforced this). Could have been better.

TDD, or rather WTAD (Write Test After Developing)

It was really really hard to bring up the discipline of writing the Test code before Developing the functionality. In practice tests were only written after something was seen working already. What do you do, honestly? :)

The final part will contain details about the deployment (Mongrels, W00t!) and also some interesting statistics on how many lines were left after the rewrite. Stay tuned..

Comments

Leave a response

  1. Jim – December 20, 2006 @ 06:53 AM
    "I figured it would have take much longer if I had examined the PHP code myself. " way to be the analyst who doesn't even know the code he wants to change. Lazy bones jones.
  2. Bob – December 20, 2006 @ 08:22 AM
    You really should check out the original code. Usually that's where you'll find the exceptions to the business rules you had the meetings about. :-) I've been through a few of these now and I might not know _exactly_ what I'm looking at, but I'll write down enough info that when I say "It looks like in October something happens with [insert product/service]" that I'll get a few "Oh yeahs!" or sometimes a "we don't have to do that anymore." It's better than October rolling around and the customer wondering why action "fubar" didn't take place in the new system (of course, they'll forget the parts of the meeting where you repeatedly asked "is that it?").
  3. andy – December 20, 2006 @ 11:12 AM
    Since I had access to the current and future users of the system and they knew most the business rules, not to mention new rules that were not even in the PHP application I tought it was best to talk to them directly instead of go hunting for rules in gazillion of files. Remember, the original application was not MVC so there was no single place to look for all the logic.

    Of course they did forgot some things and a specific part of the moderating backend was actually built to moderate on totally different conditions than was intended. But by now we were in Rails land so refactoring (both the code and the database) took only a couple of hours. But as I said, sometimes you might not be lucky enough to be able to pick the brains of the user. In that case mining the legacy (PHP) application becomes inevitable.

    @Bob: spot on :-)

    -andy
  4. Joseph Scott – December 20, 2006 @ 07:13 PM
    Andy - I think the comments on looking at the code were intended as an addition to meeting with users, not an instead of. During a conversion earlier this year at work we reviewed the existing code and interviewed users. Found both to be very helpful.
  5. Vincent – March 29, 2007 @ 03:58 PM
    Great addition! Unfortunately it seems to not work with umlauts & other special characters...
  6. shakira – April 17, 2007 @ 09:10 AM
    Fantastic article covering some points I really needed some good usability info for. Best regards from Poland
  7. JP – May 14, 2007 @ 12:50 PM
    Nice work, I have to say it's pretty handy...