PHP Programming

Joel writes:

"The biggest surprise was how much work it took so that every user sees things in their own time zone."

Oh yeah, I hear you. Now imagine that your software has to do that not because you are hosting it for your clients all over the world, but because your clients all over the world are hosting it themselves, but on boxes controlled by someone else, in a different part of the world to where they are. Also imagine that these hosting companies refuse to set up the box in the timezone of the client.

Now, try and get your software to work in five different versions of PHP, with major differences in how timezones work. Deal with the fact that the hosting companies haven't configured the PHP timezone correctly for the server's timezone either.

And then throw in some bugs as well.

Joel has it easy.

I can't sleep, so I figured I'd wade into the inline documentation debate.

Travis states that programming languages are declarative, so code, along with associated unit tests are enough to define what the code does, as well as provide examples of how to use the code.

Well, I agree with that.

However, that doesn't mean that inline documentation is therefore a "bad thing". Tobias has pointed out a couple of reasons why that's the case. I can think of a couple more, too.

I was extending the Openads database abstraction layer last night, to ensure that creation of databases works correctly. I'm no PostgreSQL expert, but it seems that it won't let you issue DDL/DML commands unless you have connected to a database first - so if you want to create a database, you have to connect to a different, already existing database first.

Luckily, the PEAR::MDB2 library will connect you to the "default" database for a database server if you specify no database name in the DSN. (For PostgreSQL, this is the "template1" database.)

This was all well and good, until I tried to then connect to my newly created database, and all I'd get back was the previous connection to "template1". It turns out that the MDB2::singleton() method compared the DSN array of the database you want to connect to with any DSN arrays of previous connections it has made by using the array_diff() function.

Alas, when creating a connection with no database name results in the DSN having the boolean false for the database name field - and because other items in the new DSN array were also false in my case (for example, the "mode" of the connection" was false), the array_diff() function returned no differences. Oops!

Changing to the array_diff_assoc() function solved the problem.

It's been all systems go at Openads central this year. One of the big jobs we've been taking on is dealing with our database schema. Managing database schemata is actually a tough job, if you want to do it in a agile way. (No one actaully designs their database schema up front any more, right?) There are several great books on the subject, though, and based on those ideas, we've produced a white paper outlining a system we're writing for managing database schemata for PHP, in the same vein as Rail's Migrations.

As part of this project, we've decided to use PEAR::MDB2 and PEAR::MDB2_Schema to manage the jobs of reading in our existing database schemata from existing databases, to then be stored in XML files, The same two PEAR packages will then be used to prepare the SQL DDL/DML commands required to create new databases when installing Openads, or to modify an existing Openads database when upgrading. Of course, the DDL/DML created will all be based on XML schemata files.

If you've ever used PEAR::MDB2, you may be aware that it works by storing database schemata information in an "internal" MDB2 datatype. This datatype needs to be converted into database-specific commands when talking to a database, obviously. But if you're reverse engineering a schema from an existing database, you also need to be able to convert an existing database "nativetype" into the appropriate MDB2 datatype.

However, this is where we've run into a few issues.

Oh yeah. A new version of PEAR::MDB2 is out.

I'm planning on updating my blog software "soon", and I'll put up a detailed run down on some of the new features in MDB2 as soon as I can get code syntax highlighting working...

Along with all programmers out there, I'd know how to change what I do during the day to meet performance goals if my pay depended on it. Sure, I wouldn't be happy that I was spending my day faking it just to get paid - I'd much rather be working on something useful and interesting. But if the boss wants performance targets met, the boss will get performance targets met. That's why setting targets won't make things better.

(No, work hasn't done anything crazy like setting performance targets! )

Of course, I've never thought the phenomenon of performance goals reducing performance would be limited to situations where people are sitting in a office. Inspector Gadget writes:

"Chief Inspector at the briefing: 'I don’t want any further arrests for Section 5 of the Public Order Act in this town. This offence gets counted as a violent crime, and we are over our targets for violent crime. Just get in between them and push them apart if they start fighting.'"

Yep, that sounds exactly like what happens when you set performance targets to me.

One of the Max Media Manager users reported that s/he could not use Zend Studio's built in SVN to checkout the trunk of our repository.

I've got a bee in my bonnet at the moment about Zend, and so I'm on their case these days about making sure Zend does what it says on the tin, so, I reported it as a bug.

I've posted a modified version of their workaround back on the Max forum.

(Yes, I'm back from the dead! Huzzah!)

Rob points out, with regards to the problem with Zend Studio apparently ignoring your php.ini file when using the "internal" debugger, that Zend Studio comes with it's own pre-compiled versions of PHP, which it uses when debugging.

So, if your php.ini file isn't in /usr/local/lib (and mine isn't, it's in /usr/local/php4/lib, as a result of a dual PHP4/PHP5 setup), then the internal debugger won't see your php.ini file at all; and that's why it seems to ignore your settings.

Did you know that Zend Studio, when you use "Internal" debugging (as opposed to using the Zend Platform), appears to completely ignore your php.ini file?

I can't even begin to comprehend how it manages to do this, given that the Zend site indicates that internal debugging works by sitting on top of your local PHP install.

All I know is that this makes it incredibly hard to debug those big PHP scripts that use more than 8Mb of RAM, because you can't adjust the memory_limit value in your php.ini file. (Well, you can, but it doesn't seem to have any effect inside of Zend.)

You have to resort to configuring Apache and installing the Zend Platform to make it all work -- which is a pain when you're in a rush.

I'm sure that Luis will appreciate the humour in this.

No, it's not that the title "Five common PHP design patterns" is funny - even though programmers knows that there's no such thing as a "PHP design pattern", because design patterns aren't language specific (although, obviously, many patterns have an OO language in mind). After all, the author's audience is the PHP "programmer" (and I use the term loosely) who thinks that patterns have nothing to do with PHP.

It's more that the author's first example is the "Factory" pattern. It must be at least once a week that Luis and I share a joke about someone who is talking about this "pattern", and then wonder musingly if they are talking about the "Factory Method" or "Abstract Factory" pattern, which are, of course, two different beasts.

Sure, you can figure it out, but in that case, why bother to have standardised names for design patterns at all?