onekay

I mentioned earlier today that I am at that I am at the PHP London Conference. And I just found out something new about PHP that I wanted to share.

Apparently PHP has quality assurance. That is to say, there are a team of contributers dedicated to QA for PHP. One of the members, Zoe Slattery from IBM gave a talk here today with the superb name “test||die”.

Anyone who has compiled PHP from source should be aware that there is a test suite for PHP, but fewer are likley to know that it is actively maintained.

All the tests use standard PHP, so if you know PHP, you can contribute tests. Check out qa.php.net for more information. (I didn’t even know that website existed).

Today I am at the PHP Conference London 2008, with about 300 other developers. We’ve all listened to Ivo Jansch in his “PHP Enterprise” talk, which is a good discussion of software engineering for php developers.

I’m currently listening to Stefan Esser’s”Binary PHP Analysis” talk which is a really useful insight into php security auditing.

Just spotted that the online docs for PHP have changed - and looking at the PHP-DOC mailing list there is an announcement from Hannes Magnusson that the PhD builds are now online.

PhD is the [PH]P based [D]ocBook renderer which the documentation team have been working on for ages, and it sparked my interest after hearing quite a bit about it on the Pro PHP Podcast - so congrats!

The improved builds of the docs have been live on http://docs.php.net/ for some time but it looks like they are now pushed through to all the mirrors, which is excellent stuff.

I blogged recently about passing the Zend PHP5 Certification recently. One of the ‘rewards’ offered for passing the test is inclusion into the Yellow Pages for PHP Professionals and there are various functions available for people who have passed the exam to edit their details, post a picture etc. However my profile doesn’t seem to be linked to my Zend account, despite using the same email address, and I cannot edit any of these details.

As this resource is one of the main selling points used by Zend to push the exam and since its a pretty handy place for recruiters to look for qualified PHP developers (I’ve already received recruitment emails through it) - I would expect this to work properly and for me to be able to edit my details. The lack of any additional information on my profile reflects badly on me, as it could easily be taken as a lack of interest from me by anyone looking at my details.

So far Zend haven’t even responded to emails that I’ve sent through their website to them which is appalling customer service.

Update (6 Nov): Beth at Zend sorted this all out for me today and I can now update the profile.  David and Howard also contacted me about the issue - thanks guys, much appreciated!

Three pieces of zend news today:

Firstly - I passed my Zend PHP5 Certification exam yesterday (\o/). I’ve been thinking of taking the exam for some time, and finally got round to it when my employer offered to pay for the test. It was rather more difficult than I expected - but there were very few questions that required arcane knowledge of the order of arguments to PHP functions (which I use the manual and Zend Studio’s auto-complete for). It does focus quite a lot on SOAP and webservices, but the php|arch certification guide I bought warned me about that.

Secondly, I’ve given up with Zend Studio Neon - it has a huge amount of useful stuff that Eclipse PDT doesn’t - like get/setter generation, code formatting, PHPUnit support, and the other stuff listed here. However - I just can’t get on with the ‘project’ system. All I want is to be able to browse the file system in the LHS pane - and that doesn’t seem to be something its willing to let me do. I don’t want to individually add files & folders to my project, or manage include paths, or have .kpf files dotted around that I have to tell subversion to ignore. So I’m back to Zend Studio 5.5 pro, which doesn’t have this annoyance. I normally on windows with with a VM or separate development hardware sharing my home directory through samba and then mapping that as a drive in Windows. I then browse this mapped network drive with my editor/IDE. If anyone knows how to get this to work in PDT or Neon (or Komodo, which I had the same issue with) I’d love to hear from you.

Finally, because I’m not above a bit of gratuitous plugging, in an effort to win a book, and because I needed a third Zend related topic for this post. If you haven’t listened to PHP Abstract yet, then you might want to add it to your list of things to listen to - its worth it alone for Cal Evans‘ cheesy intro and post script. The latest episode is an interview Cal did with Sean Coates of php|architect (and one of the hosts of the other php podcast). PHP Abstract is much more frequent than the other podcast, and with considerably less rambling - each episode lasts about 10 minutes and is given by a range of people from the PHP community. Cal’s own ‘How to kill a software project’ is very funny.

Got an email today from Zend about their new Zend Studio beta. I’m interested to see this, because I use Zend Studio at work, and I like it, its just quite expensive. I’ve been trialing different IDEs at home for a while now, but I havent got on very well with either Komodo nor PDT as I find that I am just not as productive when using them - neither are particularly PHP orientated and I feel I have to work in the prescribed way, rather than how I am comfortable.

This new beta is Zend Studio for Eclipse (codename Neon), so I’m not sure how different it will be to PDT (or the vanilla Zend Studio for that matter) but I figure its worth a look.

and if anyone has any recommendations for any other (win32 or linux) IDEs that are worth trialling, I’d love to hear from you.

I have a lot of debates about this with people. One of the most common reasons given for why PHP is so popular is because you can’t swing a cat without hitting a PHP developer. I say thats crap, and that you can swing a whole lot of cats before you hit a halfway decent PHP developer. Good developers who know and want to work in PHP are hard to come by. Consider that perhaps PHP is so popular because it does some jobs really well.
Terry Chay recently made an extremly funny and quite insightful post about Ruby (on Rails) in which he mentions:

“look at the top 100 websites on the internet: about 40% of them are written in PHP and 0% of them are written in Rails.”

Which is pretty interesting. To me, it says that PHP is a pretty good scripting language to be getting stuck into, that its something that you should be using if you want to develop web applications that are used by hundreds of thousands of users across the world.

I’ve met developers who consider PHP to be second-rate and who are ‘embarassed’ to admit competance in it on thier CV. Developers who just plain dont want to do PHP because it would ‘damage’ their career prospects to have used such a poor quality language for too long. I say this is crazy-talk and that the sort of numbers that Terry mentions (which I appreciate may not be accurate to three decimal places) just shows that PHP is a language that is being used in environments that other more traditional OO scripting languages are too delicate for. I wonder what sort of percentage of the top 1000 traffiked sites use PHP, or the top 100,000?

To me, PHP seems like its a stronger career prospect than ever.

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.

• Have coding standards. And stick to them. Every developer has thier own preferences, but reach a compromise with everyone on the team and agree on a set of standards that will help you keep all your code looking similar. It should be easy to scan, and will look neat. There are plenty of places to start - take a look at the PEAR standards as a starting point for your project. Dont be a nazi about your coding standards though concentrate on keeping code readable rather than strictly adhering to the standards doc.
• Organize your files. Firstly keep anything that isn’t supposed to be reached through a URL out of the webroot - templates, include files, configs, class files, log files, backups, cron scripts etc. This stuff shouldn’t be browsable. You can hide it in folders with ‘Deny from all’ directives in a .htaccess file - but its better to sit it below the webroot.Then look at your web visible file structure - put images in img/, stylesheets in styles/ and so on. Once your web visible structure is in order, then think about what you have below your webroot.Your filename conventions are also important. I normally start each class with a capital letter - so files like Template.php and Model_Abstract.class are classes, anything else is normally lowercase, underscore separated and with an extra extension if they are included files: main_header.tpl.php, global.inc.php, default_style.css default_style_print.css
• Separate your presentation logic from your page logic. Everyone says do this, but no one really explains _why_ you should do it. Separating these things allows you to re-use your presentation code elsewhere. It means your designers can play with the design _without_ ever breaking the application behind it. Remember that separation of code isn’t the same as separation of logic, for instance, alternating table row colours is presentation logic, and should be done in that layer, while checking users are logged in and have access to the specific page is page logic, and shouldn’t be done in the display layer. Savant is an excellent place to start.

• Use less code. This is obvious - the less code you write, the less you have to maintain. Re-use code wherever you can, and dont write anything you dont need. Refactor code as you go to make it as streamlined as possible. Remember to remove redundant code too.

• Documentation. Documentation. Documentation. These have got to be the three most important things to remember when it comes to maintainable code. Document your code as you write it - explain what everything does and why you’re doing it that way. This will help when you, or someone else comes to revisit the code in six months time and has to work out what it does. As a rule of thumb document anything that you can’t understand with a quick glance.You should try and comment all variable declarations, especially if the name doesn’t describe the variable too well.Each file should contain a file level docblock describing the use of the file, If a script takes _GET parameters or ARGV arguments (command line) a docblock containing a usage example should be written in the file level docblock. A usage example should be given for any classes that are not normally initiated using the constructor (eg factory classes)

  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.

• Obey the OO principles you learnt at school. Encapsulate what varies, use inheritance but favour composition, depend on abstractions not concrete implementations, strive for loosly coupled objects, program to an interface not an implementation, keep classes open for extension, closed for modification yadda yadda yadda. There are enough resources online about this stuff

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/