So why the big fanfare now? Well I’m happy enough with it now to let other people look at and use it and also I’ve submitted it to the PEAR Pepr process, and the grilling that entails, so it can be included in the PEAR repository.

And if this pushes more people to using Openstreetmap (or PEAR for that matter) all the better!

So now, along with having the mysql prompt defined as prompt=’\h@\u (\d) > ‘ in the [mysql] section of my ~/.my.cnf file (so host, username and database name are included in the prompt), I have also installed rlwrap and set up an alias in my .bashrc:


if [ -x /usr/bin/rlwrap ]; then
alias mysql='/usr/bin/rlwrap -a -pGREEN /usr/bin/mysql'
fi


This displays the mysql prompt in green, after checking that rlwrap is available, which I have configured for my development environment only – now I just need to train myself to be extra careful for when the prompt isn’t coloured.

I’ve also been slowly working my way through the bugs of orphaned PEAR packages – as any PEAR QA Team member ought to!

Unlike the Date_Holidays packages, these are PEAR packages that are no longer actively maintained – if you want to take over any of those you should read Till’s blog post on taking over PEAR packages and follow on from there.

Specifically, this person wanted advice on installing the six or so PEAR packages on which this software depends; eight if you include the optional ones.

Foreseeing a number of people wanting similar help, I thought it would be best to create a metapackage to bundle these PEAR packages together – at the least it would mean only one “pear install” command would be required and it would reduce the number of potential mistakes that could be made.

Following my own instructions in the “Dependency Tracking (Meta Packages) with PEAR” section in the PEAR documentation, I quickly came up with Statusnet_Statusnet-0.1.1.tgz.

Install it via “$pear install http://short.ie/statusnettgz” for the moment – as the location of where it’s being hosted may change during the week.

Update 2010-08-10: This article has been translated to Belorussian by Patricia Clausnitzer and is available here.

Jamie says that “The Validation::postal() method that comes with CakePHP 1.2 is good in that it can handle a number of different country formats, but the problem is you can only validate your data against one country. What if you want to accept, say, either Canadian or US postal/zip code formats? I ran into this problem earlier today, and decided to write my own postal() function that can take either a string as the country, just like Validation::postal(), or an array of countries.”

I’m probably going to have to wait for Jamie to wake up before my comment on that blog-post is approved, but the crux of it is “Don’t”. Don’t write your own code to validate user input, unless of course the input data is specific to a problem domain that others haven’t catered for yet.

I drew attention to two things. The first is that there are Validation packages in PEAR, including the main Validate class and all the Validate_xx subclasses such as Validate_US, Validate_CA and some 22 others).

The second item I drew Jamie’s attention to is that his validation code counts a zip code of “00000″ as valid, when the USPS zip code look up tool correctly (and they should know!) identifies that code as invalid.

Why spend time writing and debugging regular expressions, compiling lists of valid data and so on when other people have already done this work? Especially when it comes down to such things as validating data input which is crucial when you need to guard against cross site scripting vulnerabilities.

Focus on what you need to do rather than reimplementing what others have already done.

Honestly, this probably should be subtitled – “Stop the NIH craziness, please” – though to be fair Jamie might not have known of the solutions already out there.

jQuery 1.3 with PHP

This is the first book sent to me from Packt where I wasn’t left dizzy from trying to understand just what it is the author was trying to get across. It looks like their proof-reader was awake for this one – totally awesome.

jQuery, as the vast majority of us already know, is a JavaScript library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. In other words it does all the heavy lifting and takes care of cross-browser compatibility issues so you don’t have to and thus allows you to focus on the work that you need to do without all those distractions.

“jQuery 1.3 with PHP” is aimed “for PHP application developers who want to improve their user interfaces through jQuery’s capabilities and responsiveness”. Over the course of ten chapters Verens starts the off with an introduction, then a series of ‘Quick Tricks’ that almost immediately help you add some measure of “Web 2.0″ functionality to what I’d term a “web 0.2 application” rather sharply.
The book ends with a chapter on Optimization – some of which you are bound to already know and some which are complete gems.

In the middle are chapters with mini-projects on tabs and accordians, forms and form validation, file management, calendars (and how to make your own google-calendar-like application), image manipulation, drag and drop and data tables.
In each case, projects are analysed and the required steps for each are outlined in the simplest terms – no extraneous buzzwords are used or are the projects over-analysed for the sake of pedantry.

I was a little surprised in some places where, for example, the json encoded output was not created via json_encode; but then thought not everyone is going to have PHP 5.2 or greater installed. Thumb forward a few pages and this is mentioned. So all’s o k.

It was good to see Kae suggesting use of the PEAR Validate package (or similar) in the Forms and Forms Validation chapter (chapter 4). I had to wonder if there was a PEAR package for creating and shunting down jQuery validation rules to the client – and found that there isn’t. That’s something to consider for later on, I guess.

The rest of the book is similarly both easy to read and easy to understand – my first port of call for learning how to do something that I’d almost term exotic with jQuery and with PHP in the background is usually Google but that is going to change (actually it already has).

Honestly, I wouldn’t be surprised if this books working title was “JQuery and PHP: The HowTo” – it is that good.
Now, this book is not for learning jQuery – that is not within its remit, but I would heartily recomend “jQuery 1.3 with PHP” by Kae Verens to anyone wanting to utilise jQuery from a PHP background.

These were fixed and new versions released immediately – further details are available on the Official PEAR Blog.

A few weeks ago I received a copy of “PHP Team Development” from Packt.
Split into seven chapters, all equally sprinkled with phrases that are disjointly written and that don’t get a point across, and some that make you think the book was written using some speech-to-text software (“Vendor locking” anybody?) , this book which “is for PHP developers who work in teams on complex projects” has given me an aversion to seeing three little words printed alongside each other (“the PHP code”).
If you have read this book you too will develop this aversion. I think Lorna Jane Mitchell and Brandon Savage who both bravely reviewed this book before me might be inclined to agree.

Published only in September of this year, I found it surprising that its section on coding standards and best practices does not suggest the use of phpCodeSniffer (for checking the adherence to coding standards, and which, incidentally, has been available in one form or the next for the last three years). Nor does Samisa suggest the use of phpUnit or SimpleTest for unit testing (Actually, nothing is mentioned for unit testing – the concept isn’t even described, nor is Test Driven Development). These tools have been around for a very long time and I was honestly startled by their ommission.

In a way that’s fine – these are only tools and the book is about team development – not about listing and reviewing each and every tool that could be used to help team members make more efficient use of their time.
But I’d rather use these tools during peer review to help highlight what a team member may be doing wrong in an efficient use of my time, than have to analyse the code myself.

So, moving on, there’s a section explaining that frameworks should also be assessed on the basis of the various open source licenses they are distributed under but the author doesn’t really explain why this is important – or discuss what the prevalent FLOSS licences are (MIT, BSD, GPL etc), or what issues they each attempt to address and what they are best suited for.

The NIH (Not Invented Here) Syndrome is mentioned and to be fair the author does give a long list of frameworks to be considered; probably the one detailed list in the book, to be honest.

PEAR had been mentioned in passing elsewhere in the book so I was expecting it to be listed in the frameworks section too, as I was expecting ezComponents to be referenced somewhere as well – but then, these are a component framework/libraries so perhaps he thought it did not belong in such a list.

To be honest, I think that is part of the problem. The book focuses on what the author thinks and his thoughts on the subject are written in such a manner, that once you put in the immense effort in trying to understand what he is attempting to communicate, that you are left with the impression that
there are no alternatives; that X & Y & Z are the true and tested ways of doing things in PHP and there are no two ways about it.

This is a complete shame.

Some other observances about this book;

• Continuous Integration is mentioned; but CruiseControl and PHP-Under-Control are not.
• Source Code Control is mentioned, and here Subversion and GIT are covered. CVS is mentioned elsewhere, under a section, and chapter, far-far-away. Mercurial, bazaar and others don’t even get a look-in.
• There is no mention of how approaches to Team Development might vary depending on whether some team members might be working remotely, Pair Programming is barely mentioned let alone suggested as one way of ensuring that each team member is learning from the other and reviewing the code that his partner has written.
• Under issue- or bug-tracking, jira and bugzilla are mentioned as two popular bug tracking tools, and although Abeysinghe states “there are numerous tools that are available, both opensource and commercial for bug tracking”, no others are listed. Fogbugz, Mantis, RT, Trac, and plenty others get left by the wayside.
  Actually, I’m wrong. Sorry. Trac is mentioned – at the other end of the book; though not in the glossary or index.

I honestly considered giving up on reading this book and not writing this review. The book truly is that bad. The thought of someone paying out close to thirty euro for a book that I’d call poorly researched, badly proof-read, woefully incomplete, badly structured at worst and self-opinionated at best did force me to reconsider.

Nobody should spend close to thirty euro on a book and get so little in return.

So my oneliner opinion of PHP Team Development by Samisa Abeysinghe?
I’d seriously suggest you give it a miss – do something more meaningful with the money and buy bread to bring your team on a duck-feeding-mission.

As most of you will probably know OSM is to printed atlases from AA, Ordnance Survery etc, as wikipedia is to encyclopedias. People can contribute data to the project through a variety of activities: going out and actually mapping an area with a sat nav or gps unit [even a mobile phone with GPS in it such as an iphone, nokia n95 or whatever], tracing data off Yahoo [and other] aerial imagery, filing bugs on the openstreetbugs website or literally drawing in information via the walking papers map making website. And better again, this is about providing free geographic data such as street maps to anyone who wants them.

Anyway…I mentioned how the OpenStreetMap map of Nenagh is more complete than even the latest commercially available maps for Garmin and Google Maps and listed off a few ways how OSM could be used commercially: by real estate agents, courier companies, how being able to pin-point where all the amenities are would be useful for tourists, and so on.

Compare the Open Street Map of Nenagh with the Google Map of the area – as you can see, there’s still quite a bit of work to be done – Millers Brook needs to be marked as such along with the various groves, avenues etc that comprise that estate. Plus all the amenities, shops [perhaps even their opening hours] and the Shannon Development Industrial Centre still need to be added – as I’m sure are some other small portions of the town that I’ve unknowingly neglected.

It’s fair to say that this will never be finished – existing housing estates will be extended, there will always be urban development plans that when implemented would also need to be included on the map.

It would also be cool to have the new “Nenagh Cycling Hub” rendered on the opencyclemap.org website.

I discovered the OpenStreetBrowser site to be a great test of the data that myself and others have entered – it’s also a great way of demonstrating just what can be done with OSM data.

If you happen to spot something that I’ve missed please either drop me a comment or use the openstreetbugs website.

On a related note: it would be good to see a PEAR/PHP based client/component for interfacing with the OpenStreetMap server so that interesting apps utilising that data could be implemented on the LAMP stack – something to go alongside the Services_GeoNames package from pear