onekay

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.

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.

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/

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.

• XDebug is an awesome PECL extension which gives you a bunch of debugging and profile tools - it takes a lot less setup than PHP for Eclipse or the ZDE debugger/profiler too

• Waterproof Softwares phpCodeBeautifier is pretty handy for tidying up that incredibly messy code you’ve just inherited.

• My choice of (nearly) free windows text editor goes to Edit+, which is pretty neat for all sorts of code stuff - it has regex support too which is neat. For the most part I use the Zend Development Environment though.

• Savant is one of the most sensible PHP templating systems availiable - as it uses PHP as a templating language, instead of some ugly pseudo code PoS. Its pretty lightweight, and distributed as a PEAR package. It’s even being reworked for PHP5 now too.

• My final PHP tool is written in Python. Trac is just about the best issue tracking/wiki/project management/repository browsing tool availiable. If you havent moved to Subversion yet - then Horde’s Chora project is an acceptable repository browser, but doesn’t have half the neat stuff trac has.

Hope these tools help you as much as they have helped me

Saw this article about a forum in Rails. It all looks very pretty and everything.

The thing that caught my eye is the text ‘under 500 lines of code’, I brought the domain onekay.com with the original intention of writing publicly availiable code that did cool stuff, in under 1000 lines (onekay, 1K, geddit?). I changed my mind because of the following reasons:

• Obscure code
  In order to get down to the required number of code, clarity can get thrown out of the window - nicely written commented blocks of code become horrendous one liners that cryptographers would have trouble deciphering.
• Included librarys
  It doesn’t mean a thing if your script only has 500 lines, if it needs another 500k lines of code in its required class librarys/framework/whatever in order to execute.
• Arbitary restriction
  Unless you’re intending to have your piece of software run on a coffee maker or a C64, the number of lines of code your software has, just doesn’t matter. It doesn’t make it any more portable, scalable, or useful.
• Feature loss
  You’re not writing the best software you can when you attempt to write code with unnecessary restrictions in place - what features are you not implementing? What features are you implementing incompletly?

While I am sure that Beast is clever, well written software, and not all of the above apply here but ‘Under 500 lines of code’ is a gimmicky marketing ploy that seems to work every time.

…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.