onekay

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

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.

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.

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.