Straylight Run

Well, it only took me 18 months, but I finally got around to cleaning up and publishing the Phing filters we use to automatically transform a static site into one that implements many of Yahoo’s Exceptional Performance Rules.  These filters, together with the Apache configurations in the README, implement the process outlined in this talk from php|works 2008:

To see it in action, first create an VirtualHost pointing to the mysite directory in the project as the web root.  Then run:

% phing optimize

which creates a parallel site in a build directory.  Point your VirtualHost to the new build directory to see the same site with the performance transformations.

You could run this Phing task in a continuous integration process as part of deployment.  You could run it at production deployment time, but it’s probably a good idea to run it at staging time in case it flubs on some CSS or HTML syntax that it is not expecting.

Note that there are other miscellaneous Phing tasks in that github project.  I threw these in there in case they could be of use to other Phing users.

If we are to do unit testing, then it would be nice to have a simple way to run all the tests at once.  And seeing the results in a command line is fine, but it would be nice to be able to generate some pretty reports I could view in a browser.  And running coverage tools from the command line to see exactly what we’re testing is fine, but it would be nice to be able to generate coverage reports I could view in a browser. It would be nice to be able to do all these things with one simple command.

The command: phing.

If you’re familiar with Ant for Java, phing is functionally identical to ant.  With a very simple build script, I can run all the unit tests, and generate test result reports and coverage reports in HTML automatically. Then I can fire up my browser and see if any tests failed, or whether we need new tests.

The following are examples of test results reports and coverage reports.

Phing currently requires PHPUnit for unit testing and xdebug for coverage. Someone would have to write a task to use other frameworks such as SimpleTest.

The phing build file is a first step towards automating builds with a build server. A build server can periodically check the project for changes. If new code exists, it will run tests and generate reports for tests, coverage, lint, anything. It can put all this on the web for easy inspection. It can keep versions of the whole project that be can be readily deployed.  So if we have a staging and production server, and we stick to deploying ONLY bundles from the build server, it can make deployment and maintenance easier.

I’ve been around offshoring for quite a while now, and I’ve heard people tout the benefit of the 24-hour development cycle many times.  The idea is that when your developers in the Western Hemisphere are going to sleep, your developers in the Easter Hemisphere are waking up.  When those developers go to sleep, the cycle begins again.  Voilá!  24×5 coding effort.

But it never made sense to me.  It was like there were two people building a house, and claiming that if one person worked on the house during the day, and one person worked at night, it would be faster than if both people worked during the day.  At best, it would be equal effort.  It may even be a little worse because if two people work on it together, they can re-use tools and such, and they each have someone to keep them company.

Looking for some literature on using agile methods with offshore teams a while ago, I finally found someone had put the same thought in writing.

Another benefit of offshore that’s coming up is the use of 24 hour development to reduce time to market. The benefit that touted is that by putting hands on the code base at all hours of the day, functionality gets written faster. Frankly I think this is a totally bogus argument, since I don’t see what adding people does in India that it wouldn’t do by adding them to the onshore team. If I need to add people, it’s more efficient to do it while minimizing the communication difficulties.

Martin Fowler, "Using an Agile Software Process with Offshore Development"

Slides from php|works 2008 in Atlanta, GA.  If the Sliderocket version below is problematic, here is the more popular Slideshare version.

Slides from php|works 2008 in Atlanta, GA.