The PHP London user group just announced PHP London 2007 conference. Tickets are just £50, and speakers are Rasmus Lerdorf, Cal Evans, the editor of Zend DevZone, Kevlin Henney and Simon Laws, the lead on PHP’s new SCA_SDO extension.
Looks like it should be a good conference and I hope to see you there (-:
My copy of php|arch’s Zend PHP 5 Certification Guide by Davey Shafik/Ben Ramsay arrived yesterday, which rather means I should get around to booking the test. The book itself does an excellent job of covering PHP’s many nuances, and would (IMO) be a good guide for any competant programmers using PHP for the first time. I brought the book to make sure that my knowledge was sufficient to take the test before I spent $125 on the voucher, with the intention of ebaying the book once I’d finished, however, having read most of the book last night, I think it would be a good addition to my bookshelf, especially to lend to other developers on my team.
The book is essentially divided into the different subjects that the Zend exam tests: Basics, Functions, Arrays etc, up to Streams, Security and XML & Webservices. Each is presented in bitesized chapters that concisely cover the subject matter, rather than providing an in depth view. Things get a little wierd when database programming is covered, as no PHP is really discussed in this chapter but a rudimentary knowledge of SQL is required for most people writting PHP so it makes sence to cover the subject. Throughout the book there are information points which contain tidbits of advice about the subject – which I assume are things which might not be tested directly in the exam, but are handy things to know, these are pretty neat.
My only real complaint is that the book spine is printed upside down. Seriously though – if you’re studying for the exam, or at least just thinking about taking it and want to make sure that your knoweledge of PHP is sufficient, or you’re already a competant developer, but you’re thinking of dabbling in PHP and want a quick guide to the syntax and nuances of the language, then this would be a great place to start.
There have been a few blog posts floating around about a talk Tim Bray delivered at the International PHP Conference 2006. I wasn’t at the conference, nor have I heard the talk or seen slides, I’ve just read what Tobias Schlitt said about it. The other day Jeff Moore raised an interesting question – Why is PHP Code Considered Hard to Maintain?
Jeff suggests that its not PHP itself that is hard to maintain, but the programs that make it so popular, wordpress, phpMyAdmin, phpBB… those sort of things, and to a certian extent I agree. Some of the most popular php programs are a mess, and would be hard to maintain, PHP does make it easy to write code that is hard to maintain. Thats not to say it makes it hard to code ‘easy-to-maintain’ code, just that it can be easy to write sloppy PHP.
Writing maintanable code takes a degree of disipline, but it isn’t hard and it certianly has its rewards.
Comment on numeric data, if a number represents a length or distance, comment what units it is in (meters, miles, hours etc.)
Comments should be used to identify missing functionality or unresolved (known) issues in the code. PHPDoc has a @todo tag specifically for this. If a block of code is commented, an explanation should be given for why it is commented, and by whom – even if it is just a temporary hack.
There you go – you have a codebase that you can come back to at any time and understand – or let a competent developer loose upon without being hugely embarrassed. \o/
Justin Silverton has a list up of his top 5 PHP tools and the comments on his page are quite disparaging.
I thought I’d just drop my current favourite 5 PHP tools.
Hope these tools help you as much as they have helped me 
At webgains we’re finally making the move from CVS to Subversion now and it seems to have a whole lot of benefits with it – cheap (time and space) branching is by far the biggest improvement – suddenly merging branches doesn’t seem like such a daunting task anymore. This move comes at a time when we’re preparing the system for internationalisation, so having a smoother version control (and with it, better deployment management) is going to be a big help.
There are a number of things you can do with your version control to make sure that your teams development and deployment goes as smoothly as possible:
Keep a stable release branch, and work on an unstable trunk
If your developers can commit to the trunk, without fear of messing up the live system, then they will be able to commit more often. If they can commit more often thier work is backed up to the repository, and the team will have to deal with less conflicts. If you have a stable build of the site/software on a branch, then you can merge the selected changes to it in order to do a release, rather than upload the bleeding edge trunk straight to the live system.
Have a staging ‘test’ area to test a release before it is put on the stable branch.
This means keeping a copy of your software or site somewhere that people dont make changes to – its not a sandbox development area, its a test environment as close as you can get to the live system where you can test and benchmark your stuff before the code goes live.
Review code before it is commited to the testing branch
Once the code is in a testing or live environment, its too late to refactor or rewrite code, so a code review isn’t all that useful here. Review _before_ it is merged to the live or testing branch, because this is the best opportunity you have before its sitting on a live website being tested for real. Dont look at code reviews as a huge formal organisational administrative thing that you’d love to have the time in your team to do – it doesn’t need to be more than another developer looking through the code, making some notes and informally talking through it with the coder.
Have a release number
It can seem strange to have release numbers for an in house website or other similar projects, where there is no distributed application, and it can be difficult to apply some of the principles of software engineering to a project like that – it tends to grow organically and features and bugs are introduced on an ad hoc basis. This isn’t always a bad thing, but the bigger your project becomes, and the more developers you have working on it – the harder it will be to manage well. Having a release or version number makes a website build/maintanance seem a bit more like a software development – and makes it easier to see how to apply software engineering principles (like version control, code reviews, unit testing and software modelling) to your project.
Obviously these all take a bit of dicipline and hard work, but thats what being a good developer is all about.
I’m pretty excited about this release, there is bunch of stuff that I want to get my hands on (the Filter extention and the DateTime objects being noteworthy) but probably the most immediate change of importance to me is the fix to the magical __toString() method.
Up till 5.2 __toString() was only called when the object was sent to echo or a print() – now you can throw the object around anywhere that would cast the object to a string, and have it call the __toString() method:
[code]
// concatenation
$string = 'foo'.$barObject;
// casting
$string = (string) $object;
// functions & language constructs
// which take strings as arguments
try
{
$foo = new Foo();
echo htmlentities($foo);
}
catch (FooException $e)
{
die($e);
}
[/code]
even the echo shortcut should work!
Thanks guys – and keep up the hard work!
Davey Shafik is reporting that he has taken (and passed – congratulations!) the beta Zend PHP 5 certification exam. I’m planning on taking his once its generally availiable, and I’m glad to hear that the general concerns about the PHP4 exam have been addressed. Davey says its got better questions, with less syntax error stuff.
I never took the PHP4 exam because it all seemed to rest on being able to regurgitate the php manual. Hopfully this has changed. Looking forward to seeing study guides and things appearing on Amazon too.
My copy of Sara Goleman’s ‘Extending and Embedding PHP‘ arrived today from amazon \o/
Been looking forward to getting hold of this book for some time. Increasing the functionality of PHP through extensions is one of the coolest things you can do with PHP, and its also one of the most important – for the further development and continual improvement of PHP.
I know that I’m not alone in the wait for this book
I’ve been dealing with some large (Gb+) CSV files, taking existing csv files, parsing them, combining fields from each and then serving them. Problem is, I wasn’t writing the resulting CSV to another file, I needed to serve it straight away.
Rather than implode array fields or iterate through each field in each row building strings, I was able to make use of the little used php://output wrapper and pretend I was writing to a file:
[php]
$data = array('field1',
'field2, now with commas',
'field three, with commas and "quotes"'
);
$fp = fopen('php://output', 'a');
header("Content-type: application/csv");
fputcsv($fp, $data);
fclose($fp);
?>[/php]
I didn’t have to write anything to implode fields or escape quotes and the end user can start downloading the file straight away. Nifty.
…with a list of things that I don’t like about PHP!
I really, really like PHP, and I have a whole lot to say about how great it is and everything else – but some little part of me says: “Hey, who are you to talk about how great PHP is, without first knowing whats bad about it.” and so thats what this first post is about.
PHP attracts a lot of critisism, and some of it is well earned. Much of the critism can be attributed to haters, Java developers, sysadmins burnt by bad coders and recently Ruby fanbois, however if you listen to the PHP community, as well as the more reasonable burnt sysadmins, Ruby fanbois and Java devs, there is certianly a lot there that PHP developers should be aware of.
Piss poor portability
Portability is what PHP does worst. Thankfully I’m an in-house developer working on a system that will, for the most part, never have to run on an unknown PHP config, but I can just imagine the seven circles of hell that developers must have to jump through to get some application to run on the majority of PHP installs. Each version upgrade seems to bring new incompatabilities with the default install – let alone when you consider all the tweaks and configs that different environments might have – PEAR classes, PECL extensions, custom php.ini’s and so on and so forth. I have enough difficulty just trying to keep my development environment the same as my production one!
This is a real issue, as the longer it continues, the slower the uptake of the newer versions of PHP will be. The core developers seem to be taking a lot of care with PHP6 to make sure new stuff is backwards compatible, which is really great but it might be too little too late when you consider how much forum, blog, wiki and CMS there is out there running on PHP4
Namespaces & naming conventions
The lack of namespaces in PHP I could live with, if I never had to use any 3rd party code and never wanted to produce PHP code for others to use. Unfortunatly I do need to use 3rd party code, and occassionally I do have to write something others are going to use or I dont want to add to my collection of EventCategory, FeatureCategory and CommentCategory objects, it would be bliss just to be able to ensure there were going to be no clashes.
PHP’s (lack of) naming conventions are an oft voiced complaint about PHP, and righty so – some of them are hefty namespace kludges (simplexml_element_registerxpathnamespace which can’t decide whether it wants camel caps or underscores) and some of them are just a plain and stupid lack of convention (strpos vs str_replace or nl2br vs strtolower). For the most part this sort of thing doesn’t matter at all, and we can all work with the whacky function names, but it is still a valid critisism.
Low barrier to entry
Catch 22, PHP’s best aspect is also its worst, its easy to write bad code, but its just as easy to write good code too, whats hard is reworking bad code into good code and there is plenty of bad code out there. Thats nothing to complain about, after all, it keeps me in work… but there are some appauling programming practices out there, not because PHP is bad, but because PHP is an easy scripting language to learn, easy to hack something out and get it working, or easy to ‘voodoo’ code some new feature into an existing application.
Anyone with a halfway decent book on PHP & MySQL can create a web application, which is great, and there is a whole lot of example code out there, help and advice on a thousand forums, as well as the inline user contributed notes in the PHP manual.
Eeek!!! What am I saying?
There is a whole world of crappy code out there (and as Theo Schlossnagle pointed out recently, a whole bunch of it is in the PHP manual) and it seems that everyone is an expert, even me nowadays. Unfortunately there isn’t a way of testing to see whether someones advice is good or not and it can be quite difficult to apply an academic Computer Science education to PHP, and a lot of people picking up PHP manuals dont have a traditional CompSci background, and there is a genuine lack of good resources out there for compitent programmers who are new to PHP – so new developers will often learn through trial and error, rather than by applying good practices from the beginning. Its up to those in the PHP community that do know thier stuff to sound off, and make themselves heard above the background noise.
Lack of Unicode support
So many string manipulation functions, and so little support for character encoding. For a scripting language which started out as a viable replacement for perl CGI, PHP does a fantastic job of not giving a damn about how a string is encoded before it goes to work. If you didn’t know, its coming in PHP6, and it can’t come soon enough.
Until then, building support for internationalisation into your apps might be a horrible, painful experience.
Its not all bad, some of PHP’s weaknesses are also some of its biggest strengths, and I’ll go into that in another post soon.
Twitter / marcgear