Laura Thompson has a quick post to her blog explaining one simple fact that all developers (or really anyone even loosely related to computing systems) should remember - all systems suck.

I've been thinking a lot about this idea lately. I've spent a lot of years as an engineer and consultant fixing other people's systems that suck, writing my own systems that suck, and working on legacy systems, that, well, suck. Don't let anyone fool you. All systems suck, to a greater or lesser extent

She presents her "slightly jaded" points of view about legacy systems, current systems and ones yet to be built nothing that, no matter how impressive and well-planned out they are, they'll still suck (some maybe just a bit less than others).

Here's the punchline: sucking is like scaling. You just have to keep on top of it, keep fixing and refactoring and improving and rewriting as you go. Sometimes you can manage the suck in a linear fashion with bug fixes and refactoring, and sometimes you need a phase change where you re-do parts or all of the system to recover from suckiness.

On the Qafoo blog today there's a new article talking about testing the one thing that we as developers can fear the most - legacy code.

Today we know about the benefits of Test Driven Development and normally also start new projects using TDD. Most projects from the last couple of years integrated this method in their daily development process, which often results in in good code coverage results of 90% and above. But what about all the other old projects, you still manage in your daily work?

They offer three possible solutions to the problem with the third being their recommended option - adding tests to the code as we have to change it. This can still lead to a code base with less than ideal coverage numbers so they've developed a new tool, PHP_ChangeCoverage, that creates a new kind of report based on a timeframe rather than an overall codebase coerage. You can see an example of the report here (versus this). Installation instructions are also included.

Matt Curry has posted his review of the recently released "Refactoring Legacy Applications Using CakePHP" book from Chris Hartjes. The book looks to help developers get a better feel for using CakePHP in real-world applications.

Shortly after Chris Hartjes released his new book Refactoring Legacy Applications Using CakePHP he contacted me and asked if I'd be willing to review it. I jumped at the chance and Chris emailed me the DRM free PDF. After posting it to The PirateBay, I settled in and gave it a read.

Overall, Matt found the content of the book good but had a few things he might change - the "too smooth" nature of the update to CakePHP and the inclusion of a "partial refactoring" section (one that talked about only updating part of an application to the framework and integrating it with the rest of the site).

Chris Hartjes, a guru of CakePHP knowledge, is putting together a book - "Refactoring Legacy Applications Using CakePHP".

Some of you may know that I have started writing a e-book about CakePHP. I'm planning on publishing it myself for the low, low price of $7. I thought I'd let people take a sneak peek at how it looks so far by publishing the first two chapters in very rough form.

You can find a rough draft here (pdf). Keep an eye out on Chris' blog for more (possible) preview releases and for the final product once its wrapped.

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

Chris Hartjes has posted the second part of his look at converting legacy applications over to a more structured CakePHP environment. In this new post he looks at working with the database schema.

Now you've decided to convert your legacy app over to CakePHP, you will run into the first serious obstacle: your database schema. To put it bluntly, if your schema does not already account for relationships between multiple tables you are screwed. Given that CakePHP is good at generating the queries you need to pull related records in for you, you NEED that schema to contain relationships.

He talks about the importance of relationships, creating his working models and some things to get well acquainted with - ow relationships work in CakePHP, how to use Containable behavior and some good SQL to back you up should you need it.

Chris Hartjes has started up a new series on his blog about converting legacy applications over to shiny, new CakePHP framework versions.

In my rapidly dwidling spare time I have been working on a project to convert an existing site for a legal services company over to PHP. I'm *this* close to being done, so I thought I'd share what I went through to get to where I am right now. [...] So after giving the code review I was asked to do the rewrite. The client realized that they had some serious maintenance issues on their hands and were in the process of creating a new look-and-feel for the site. Being the framework guy that I am, I indicated that porting the code over to a framework would be the best way to reduce maintenance issues going forward.

The series will document the process he followed to convert the application over. In part two he'll get into the meat of things - reworking the database structure.

In a new post to the Developer Tutorials blog Akash Mehta takes a look at migrating PHP4 applications up to the more recent versions of PHP5.

PHP 5 supports most of the legacy syntax features of PHP 4. Most code written for PHP 4 should function fine under PHP 5, and a comprehensive test suite could check this. However, many of the backwards-incompatible changes in PHP 5 were in regard to language quirks, and quite a few hacks rely on these in order to function.

He points out some of these hacks including changes to the object model and updates to the way variables are handled (breaking many "bad use" cases). He also points out the changes made in the latest Windows binaries as well as some of the new reserved keywords that could conflict with pre-existing code in your application.