Skip navigation.

Moving Legacy PHP4 apps to PHP 5.1 #

Today, started to test moving some of our PHP4 apps to PHP5.1.1. Some of this code was written for PHP 4.0.6, over 3 years ago. The migration so far has been relatively painless. Here are some of the problems we encountered.

  • We use code generators a lot, and some of the generated PHP4 code gives us the infamous "Only variable references should be returned by reference" warning. This warning is because of a memory corruption problem that can occur in all versions of PHP (4 and 5 included). When we analysed the problem, we realised that the amount of code we would have to correct would be massive, so at the moment we are disabling these warnings by setting error_reporting(E_ALL-E_NOTICE). Not the correct solution perhaps, but given the size of our code-base, it's a pragmatic one, as we have not crashed due to these memory corruptions in PHP4. If PHP5 starts to crash in weird places, then we'll look into fixing this.


    For fresh PHP5 code we write, we do set error_reporting(E_ALL), and fix all notices. We do not use the E_STRICT compatibility check because of the ridiculous warnings that arise, such as the warning that the VAR statement is now obsolete; it isn't, VAR will still be supported in PHP6, and this VAR warning will apparently go away in 6 too.

  • Some of the oldest code continues to use the old super-globals format $HTTP_POST_VARS and $HTTP_GET_VARS. We had to enable in php.ini the setting register_long_arrays = On to set these variables.

  • We use some PEAR libraries, and did encounter a few errors, mainly because we are using an older version. These were fixed by upgrading the relevant modules.

  • Apart from these issues, it was a stroll in the park. Everything worked fine. Partly because the core libraries that we use (eg. ADOdb and phpLens) are continiously tested against the latest versions of PHP. The PHP Internals Developers did a really good job maintaining backward compatibility, though the number of E_NOTICE and E_STRICT warnings you get is too alarming...

  • The main issue still preventing PHP 5 migration for us is the lack of a reliable open source opcode cache for Windows. Some customers use Unix, but others are more comfortable with Windows. I have hopes for eAccelerator, which apparently is in final beta.

  • Once everything stabilises in PHP 5.1 and eAccelerator, I will get our software developers to look into setting up a parallel development environment on our Windows and Linux servers for both legacy PHP4 apps and newer PHP5 ones. And then I will start looking into creating a PHP5 version of the EasyWindows installer, a full-featured PHP installer for IIS that includes fast-cgi support.

PHP 5.1: The Bazaar Is Sometimes Bizarre #

Well PHP 5.1.0 is out. This is a monumental piece of work, and congratulations to the PHP 5 internals team for all the hard work. However it feels rushed through the door. Apparently there are compatibility problems (with typecasting when parameter passing, the prototype date class, and possibly other stuff.) Wait for the patches.

Update

Later that day... I stumbled on this quote by Dave Winer:

It seems the computer industry hasn't gotten to the stage yet where it can really deliver delight to users. Maybe we spend too much time trying to fuck up the user experience. I think of that when I see pages with fifteen different formats that all do the same thing. Why? There's no need for it. How many of those types of battles were fought inside Apple that resulted in the super-shitty experience I had and Jeremy had. Maybe we need to take a step back and start thinking a bit about how this kind of bullshit keeps us from growing.

I haven't been reading the PHP internals mailing lists since August this year, but because of the rumored PHP 5.1 mishaps, I did. The in-fighting and name-calling is surprisingly heated. Open source is certainly great, the price-point is good, you can fix things yourself (if you have the skill), but the meandering directions that PHP takes can be frustrating. Some people want a more advanced programming language to keep up with the Rubies and Pythons; others (like me), want 100% backward compatibility. The Bazaar (and perhaps all software development for that matter) is sometimes too bizarre.

PS: There is a way to achieve 100% backward compatibility.

The Fine Art of Programming #

Here's a list of excellent online programming guides that i am compiling. I will add more links as time permits. The best guides also outline how to deal with people outside the cloistered priesthood of programmers.

  • How to be a Programmer: A Short, Comprehensive, and Personal Summary, Robert L Read
    Not short, but excellent distillation of one man's programming wisdom. Covers handling difficult colleagues, management, coding, optimizing and the difficult task of debugging.

  • The Art of Unix Programming, Eric Raymond
    More than just a programming guide, an exposition of a design philosophy -- the Unix way. Encyclopaedic in ambition and scope.

  • Producing Open Source Software, Karl Fogel
    A guide on how to run a successful open source software project. I like his introduction: "Most free software projects fail. We tend not to hear very much about the failures. Only successful projects attract attention, and there are so many free software projects in total that even though only a small percentage succeed, the result is still a lot of visible projects. We also don't hear about the failures because failure is not an event. There is no single moment when a project ceases to be viable; people just sort of drift away and stop working on it.".

  • Worse is Better, Richard Gabriel
    Still provocative and topical. The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Further debates on "worse is better".

  • Being A Better Programmer, Danny Burbol
    Advice written from a game programmers perspective. I don't quite agree with his opinions on documentation (I think you need to think of documentation as teaching, not making notes; in a large project, there should be some programming overviews and tutorials so people can kickstart without bugging you), but overall it's good advice.

  • Little Nybbles of Development Wisdom, Terence Parr
    What one man learnt over the course of a 3 year software odyssey - a bit too preachy for me (some of the advice seems specific to his project) but still interesting.

  • How To Write Unmaintainable Code, Roedy Green
    Roedy is a dangerous man :)

  • The archives of Joel On Software are a good read.

  • Alan Cox, Linux coding master, on writing better software.

Software Methodologies

A methodology provides a framework for software development. That's all. Never forget that within the framework, you have to keep everyone working towards a common goal, get the people motivated, the work coordinated, the participants properly briefed, and the bugs minimized.

Don't be fooled, the methodologies freely steal from each other, often doing similar things under a different guise; the key thing is listen to what is being offered by each methodology, then use common sense. Also methodologies only work on fertile soil -- make sure it suits the scope and scale of the project, and the natural working style of the key participants.

Some of the programming articles could have been placed under software methodologies too.

Software Economics