customized rants from a PHP dev's viewpoint

Google published a set of tips on how to increase the performance of PHP a while ago under the heading “Let’s make the web faster”. I recently came across the article again, and it’s been changed a lot since last summer when it was published. At that time, a number of the tips were massively criticized – a lot of blog posts were written, comments made, etc. Seemingly, this has led to the article being changed, which is good, as some of the info on it previously was rather misleading. Most of what is left is alright, although one or two of those that have been allowed to stay are still dubious:

Don’t copy variables for no reason

Sometimes PHP novices attempt to make their code “cleaner” by copying predefined variables to variables with shorter names before working with them. What this actually results in is doubled memory consumption (when the variable is altered), and therefore, slow scripts. In the following example, if a user had inserted 512KB worth of characters into a textarea field. This implementation would result in nearly 1MB of memory being used.

Although the above statement is correct (due to the ‘when the variable is altered’ which I’m presuming has been added later) the example that succeeds it does not in any way double the memory used. The example copies a variable and then echoes the copy – which doesn’t amount to a change and hence won’t actually create a copy of the variable. It would be nice to see the whole text revised instead of a bit of extra info inserted in a parenthesis … oh well.

However, that’s not the main point that struck me as odd. No, what got me paying attention is this bit:

Avoid writing naive setters and getters

When writing classes in PHP, you can save time and speed up your scripts by working with object properties directly, rather than writing naive setters and getters. In the following example, thedog class uses the setName() and getName() methods for accessing the name property.

Then follows an example with a class with public(!) properties and get/set methods. And of course the tip of not using getters and setters like that. However, is that really the tip that one should give programmers? What happened to encapsulation? Not to mention: who would ever write getter and setter functions for public properties?

In the theoretical world that people are being taught, you’re told that keeping properties offlimits to the outside world is a good thing: it limits the knowledge the world can possibly have of your object and hence minimizes the chance for tight coupling due to someone figuring out that $obj->property is possible and easier than $obj->getProperty(). Why are people being told this? Because when later down the line you realise that you have to change obj::$property to obj::$some_other_property, you’ll wish you never had the bright idea of making use of public properties. Specifically, going through code in many different places changing $obj->property to $obj->some_other_property really makes you annoyed … there are much better ways to spend your time.

Of course, there’s an alternative to fixing references to obj::$property. It’s called __get(), it’s a magic method, and it’s much slower than setter/getter functions. In other words, using the hint from Google – which is supposed to speed up your apps – you’re implicitly going down the road of tight coupling. Which means that:

Setting and calling the name property directly can run up to 100% faster, as well as cutting down on development time.

is a typical short-term view of things. Sure, development time is shorter if you don’t have to write the ten extra lines of code for getters and setters, but development time is massively extended when you have to refactor your code to not use public properties any more. Not to mention that if you the mitigate that with __get() your code suddenly won’t run up to 100% faster but more likely 100% slower (the code dealing with these properties, that is).

What should you do? You should design your objects properly, is what you should do. If some properties are core to the object and don’t need a check when being set, then obviously you can go without getters and setters. However, if you’re looking at an object that might change in the future or if you’re dealing with properties that should be validated before being set (failing early is often better than failing late) or if you just want to minimize the signature of the object, then use setters and getters.

The OpenSourceDays conference is through now (has been since Sunday, actually, but work has been keeping me very busy) and a quick reflection tells me that it was great to be there. Some of the highlights:

• A good presentation from Signal Digital about ding.TING: a new open source frontend for libraries in Denmark, using Drupal
• Part of a presentation of Groovy on Grails – it definitely piqued my interest (I only got part because the presenter was taken ill half-way through)
• Meeting Typo3 people: Christian Jul Jensen from MOC Systems, Stig Kjeldsen from OpenGate, and Søren Malling from DKM
• Helping out a bit in transforming the site of the Danish Typo3 user group. It currently looks like an ad for washing powder and that’s going to end.
• Meeting a guy with an idea for a site project and agreeing that we should make this happen sometime soon.

So, overall, it was very enjoyable and a bit of an eye-opener (it was my first IT conference). There’s a big chance I’ll be going again next year, that’s for sure – the helping out bit was actually rather fun, especially the second part.

However, this means that the Typo3 Multimedia Cookbook review I’ve mentioned has been moved back about a week or so – it needs a bit of time for reading and fairness.

This is a note to self and any others that may find themselves in a similar situation. Should you happen to one day start your computer, wait for your linux distro to boot up and then see the following message

swap: waiting for UUID=xxxxxxxx-xxxx-xxxx

without anything else happening, then don’t panic! At least not yet. Before you start pulling hair out of your head, try the following:

• boot into recovery mode, using grub, a live-cd or the excellent system rescue cd
• check which UUIDs your disks actually use (and by now, you should have an idea of where this is going)
  • easiest is: ls /dev/disk/by-uuid/ – however, if you have many disks then the output will be unwieldy
  • easy as well: sudo blkid – this will list all disks with extra info
• mount your linux boot partition, then check the fstab file on it
  • if you mounted it on /mnt/disk then do vim /mnt/disk/etc/fstab or nano /mnt/disk/etc/fstab
• check the partition that’s marked as swap – compare the UUID it’s loading by against the list obtained above
• if the UUID matches, go ahead, panic. If the UUID in the fstab file doesn’t match then change the fstab file (either to load the partition by /dev/sda-something or the proper UUID) and then try rebooting.

As I didn’t have access to the above list when this happened, I panicked (after the third or fourth reboot with the same result). Luckily I had access to another computer and could google for solutions – and came across this in a forum which I figured needed to be spread some more.

Why did the UUID of the swap partition suddenly change? I have no idea. Perhaps it wasn’t even the UUID changing, it was something else in the system that suddenly started caring about the mismatch (that’s rather farfetched, but so is the whole situation). My best bet is that it was down to a bootup to Windows and some work there – perhaps trusty old WinXP decided to play nasty and change stuff at random. No matter what, though … the relief when I finally got the thing working was massive (among other things, I have some webdev work to hand in soon).

One thing I’ve completely forgotten to mention here is the fact that I’ll be going to the Open Source Days conference in Copenhagen the 5th and 6th. The schedule looks nice with Friday probably being more along the line of my immediate interests – although the Development aid & eGov activities on Saturdays schedule also look interesting as do the various tutorials.

I’ll be missing out on some stuff, though, as I’ll be working at the conference: my ticket is paid for by two stints in the wardrobe/handing out T-shirts. It’s not going to take away too much, though, especially as part of my goal is to meet some other people at the conference, do a bit of networking if possible (“here’s you jacket, sir, and my card“).

At the end of my recent holiday stay at Gran Canaria, my fiancee and I came across a machine that was designed so poorly, it bordered on the criminal. The machine in question was a small money-changer, placed right next to vending machines (both of which are operated by the company AMFM). The combination of vending machine plus money-changer is a very nice combo for tourists (and pretty much anyone, really) especially in the environment we found it: the airport on Gran Canaria, after going through security. Imagine being in the “secured zone”, with a ten euro note and no small change, needing a bottle of water – a money-changing machine suddenly becomes your best friend (sorry Fido).

How does one turn this scenario from great to awful? One way, of course, is by having an “out of order” sign on the money-changing machine. However, while this would make you somewhat bitter, it’s what can happen – not enough to make you really angry. No, what’s needed for that is that the machine steals your money.

If you look at the picture on the right, you’ll see a machine that does exactly that. It’s designed in a way that makes it steal money every now and then. It’s not that it consistently short-changes you – that would be too much and would probably get them in the spotlight of authorities. No, what the machine does is completely lack proper feedback mechanisms. It seems that the only bit of feedback incorporated into the machine is “I’ve run out of money to hand out to the customer”. In other words, the machine will hand out as much money as it can, up till the amount you put into it.

How does this amount to stealing? In case you hand it €10 and it only has €4, that’s what you get: €4. And a nice blinking message to tell you that it owes you €6. Which you’re not going to get. In other words, the machine is telling you “Sucks to be you, doesn’t it?”.

This in itself is of course so poor design that people should be spanked. The fact that this machine is located in the secured area of an airport just aggravates things: nobody that I talked to would take any responsibility for the machine not working. Instead, the pointed me to the airport authority … the office of which was located outside the secured area. In other words, you need to go through security twice, to be able to contact them about the problem. And your plane leaves when, exactly?

Solution

What should have been done? What would a proper situation look like? First off, a machine like this should never be allowed to accept money if it cannot hand out the proper change. That amounts to a proper feedback mechanism: when change is inserted into the machine, it should count it, and then it should check available funds against its store, before accepting any notes. Secondly, there should be no refusing of responsibility in airports. As is, people are being treated as second-rate citizens in airports. This is just not the way one should do business: treat your customers properly, listen to them.