Posts tagged ‘PHP’

February 21, 2011

QA Teams, Truth or Myth?

This article was originally published in php|architect in May 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better.

In the last couple of years, there seems to be a growing trend in the PHP world where application and library developers put out claims that their piece of code is high-quality and thoroughly tested. Indeed, often this is true, but how can you really guarantee quality like this?

Quality Assurance, What Is It All About?

You might wonder, what is Quality Assurance (QA) all about? Is it something you might want to start utilizing for your project?

I don’t want to go too deep into this topic since this is a mere short article but QA can be so many different things depending on who you ask. I’m going to take the plunge and attempt to give my thoughts on QA teams and hopefully enlighten you in one way or another along the way.

The QA Team

So what is the QA team? They are the keepers of quality, those who aid the developers in maintaining the balance between productivity and chaos, these are the people who strive for perfection – The QA Team *cue theme song for “The A team”* Modern day heroes.

From my perspective, the responsibilities that a QA team would take on range from monitoring the ticket system, gathering more accurate information for tickets, verifying tickets, and making sure developers are upholding the coding standards, and any other standards, the project is employing, just to name a few.

One important purpose of QA teams is to think up new ways to make it easier for developers to adhere to the standards, to make it really easy for end users to report issues and to find information they need to reduce duplicate reports or invalid ones. To create a better end-user experience usually requires the QA team to bother the developers to write proper API documentation and harass the documentation team to produce a proper user manual. In many projects, the QA team will also deal with the tests – Writing user stories based on the specifications (if they are so lucky to have such a thing) so that the developers can write accurate functional and unit tests. This will also allow the QA team to do proper verification before releases and sprint closures.

QA teams are an impartial third-party, they have an outside perspective on the application. The problem with developers is that they don’t make good users due to how close they are to the product. They know what can be done and what can’t be done and are thus less likely to be as creative as end users when it comes to using/testing the product, QA is the bridge between the two.

QA will point out things that work but are not as clear or obvious as they could be, e.g. obscure error messages, unintuitive interface (be it user interface or API design) or finding fragile code where something is a little off and ends up blowing up in your face.

This is just the tip of the iceberg and, as you may have noticed, QA teams need to able to touch every aspect of the product, know it inside out, and play nicely with everyone inside the project. They are indeed the most powerful weapon a project manager can have in his/her arsenal, and if used correctly, the entire team will be more productive and produce higher-quality products on time … Well that’s the general idea, at least. ;-)

They Are Around – Even When You Think They Aren’t!

More often than not, projects will have a QA team, or at least QA people, without anyone involved even knowing about it!

Just think for a moment about all of those projects that you have come across that are high-quality and are well-managed, yet have no official QA team nor any mention of QA anywhere.

This scenario tends to happen when you have smaller companies or smaller development teams within companies. They become their own QA team, usually without appointing someone to take care of the bug system, with no one doing proper bug triage sessions and with verification simply happening when someone tries to fix the bug and ends up chasing down the person that filed the report just to get enough information to be able to actually fix the problem. This is all highly inefficient but still displays an effort to maintain a certain amount of quality.


A good 7 years ago, the PEAR QA efforts fell into the category: “It is around, even when you think it isn’t.” The project had a QA mailing list where there were some people around that did the occasional poking about and kept the project in decent shape. Quality was by no means bad, but as the project grew in size, the demand on high-quality code rose and since PEAR had some standards in place already, it became evident – A QA team would have to be formed to take on this challenge in a more official and more efficient way.

With that in mind, an RFC was written by Lukas Smith and yours truly ( on various things in regards to operating the PEAR QA team. The RFC was accepted and became the QA team’s modus operandi which still holds true to this day.

Sadly, as is often the case with open source projects and indeed even companies, resources and man power are scarce, and as such, a QA team may not be in place from day one or it’s just too overwhelming for the team at hand and things start piling up, which was the case for PEAR.

Bug reports as old as 6 or 7 years were still open and unattended, something not acceptable by a project claiming high standards, and so in 2008, after brainstorming, we decided to attempt a bug triage bimonthly in the spirit of the Mozilla-run bug days, where end users and developers come together on a specific day and go through old bugs or a specific part of the system(s) decided upon in advance, verify reports, write test cases and fix code.

I ran the first couple myself with a small group of people attending. Finding myself lacking time, Daniel O’Conner stepped up to take over my role, and he has done it so well that PEAR has never before been in such a good state quality-wise!

This is just one example of how an active QA team can make a difference for a project, another excellent example would be the Test Fest the PHP team put together for 2008, which was all about involving the user groups and communities to help write new test cases and get the coverage up for PHP itself. As a result of the first Test Fest, PHP received over 158 new tests, a truly great effort to combine test writing and community involvement.

The moral of the story is this: A QA team can bring a lot to your project and is an important part of the development process – Do not only think about delivering quickly, think about quality for the sake of your end users.

Tags: , ,
February 18, 2011

Backwards Compatibility

This article was originally published in php|architect in April 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better and updated a few year references.

Just remember, this article was written a while ago and any references to PHP 4 reflect that, take it with a pinch of salt :-)

In my last blog post, I went on a little rant about version naming standards and how that standard has helped PEAR, and other projects, to deal with their version naming and what users and developers can expect from the naming rules (e.g. seeing Foo- 0.5.0beta5 = A backwards compatibility break could happen) and so on. A version naming standard is a positive thing, but now I’m going to focus on something that is both a positive and at the same time a negative side effect of the version naming standard we keep in PEAR, something people have both praised and condemned PEAR for. Yes people, it is backwards compatibility.

read more »

February 16, 2011

Version Naming

This article was originally published in php|architect in February 2009 and I published it mostly as it appeared in the magazine shy of the odd formatting to fit the blog format better.

Standards evolve all the time but this specific standard has not changed much at all since I wrote my article but as always for something written a year or two ago, take it with a pinch of salt :-)

PEAR has been around for many, many years, and thus has accumulated a lot of knowledge on how to run a large-scale project.

PEAR has run into countless hurdles along the way that had to be solved in one way or another. As a result of getting over these hurdles, we have produced good things that affect the whole PHP community and also things that well…let’s face it, didn’t help PEAR or PHP a whole lot.

read more »

December 28, 2009

PHP Advent

With Christmas over it also means the annual PHP Advent calendar has been concluded. As with previous years, there is a good bunch of authors with a great choice of articles, worth reading if you haven’t done so already. You can also read 2008.

I find the idea of article driven advent calendars absolutely fantastic, as it gives authors an interesting venue to write for and readers new quality material to read every day for 24 days. With a lot of my TV shows going on a break in December, I cherish the opportunity queue up a few quality article and putting aside an hour or two to read through, with hot chocolate. PHP Advent is not the only one I read, two other advents I’ve been keeping tabs on is the Web Design Advent and the Performance Advent, and you should as well.

read more »

October 28, 2009

ZendCon, the aftermath.

Now that ZendCon 2009 is over and I’m back home safely, albeit tired, in London after a whole week of giving presentations and meeting old friends and making new, I have an itch to reflect a little bit on the trip, reminisce if you like.

First I would like to mention the talks I gave at ZendCon and make my slides available, as I have been asked quite a few times so far to publish them but have no yet had much time to deal with it.
If anyone wants the originals they can contact me directly and I will be more than happy to oblige :-)

read more »

February 23, 2009

Changing Jobs

As the title suggests, I will be changing jobs very soon. I have decided to leave Ibuildings UK and my last day will be Friday the 13th of March, scary isn’t it ? :-)

I have accepted a job at echolibre, a company based in Ireland, where I will be heading up R&D, among other things, in addition of taking up part ownership, where I will be working along side great people like David Coallier and Eamon Leonard. If you are looking for a great company to take care of all your PHP needs, then contact us to get further information ;-) </shamelessplug>

I look forward to this opportunity and am very excited since I will be able to spend a whole lot more time on my open source projects than I have for the past 6 months, as well having more time for other side projects, such as writing columns and articles for php|a, a book and other exciting new things on the horizon (Keep tuned on this blog!). This new position will not mean a decrease in my conference attendance, so fret not – I will still come to the usual conferences and spread my joy all over the place and paint the town red!

I got a great office space in Soho, London for when I start at echolibre, so if any of you web people are located in the area, DM me (@h) or drop me an email if you’d like to talk business over drinks or just general farting about.

I would like to thank all my co-workers at Ibuildings for a great time the last couple of months and all the best in the future.

A co-worker of mine of Ibuildings UK Arpad Ray decided to leave at a similar time as my self to venture back into the contracting business, so congratulations are in order ! If anyone needs good developer than contact Arpad

December 12, 2008

PEAR installer / channel and other articles

I sometimes get people coming to me and asking “How do I take my X code base and package it up PEAR style” or “So I have packaged up my awesome library, I want to have my own PEAR channel, how do I do that ?” so in the end I decided I’d just write articles on the subject :-)

If you look for the Nov and Dec issues of PHP Architect then you’ll see said articles in all it’s glory! I know people already have access to the Nov mag via PDF and I’ve gotten good feedback on it thus far, I’m happy.

I also published a little piece in the PHP Advent calendar for Chris and Sean called Coping with the Holiday Shopping Spree and in my opinion it turned out quite well, at least I’ve been getting reallllly good feedback from people. It’s a subject that people don’t touch on enough.

On top of this whole thing I will be starting a PEAR column in PHP Architect in February that will run on monhtly basis, where I will try to write something intelligent about PEAR and hopefully stay away from writing tutorials and how to’s for X and Y popular package but we’ll see how things progress, email me requests if you have a specific topic in mind ;-)

Tags: , , ,
November 6, 2008

The secret sauce to Obamas success is …

Now that Obama has finally won I think it is time to reveal the secret sauce in his campaign – PHP & PEAR – according to this article a LAMP stack was used to create the Obama site where PEAR was extensively used, makes me feel all warm and fuzzy inside, ohh and really proud :-)

This just goes to show the Obama campaign picks the right tools for the job, and further they pick tools that no corporation controls, which quite reflects what Obama is all about – at least the little I glanced over the whole presidential election thing. The same can not be said about MaCain (read the article)

Tags: , ,
October 3, 2008

Ohloh providing download services for your OSS project

I was just informed that Ohloh is now providing open source projects with a download service. While I haven’t tried it just looking over their FAQ seems like this could be really helpful to many smaller projects, well even bigger ones I think!

CDNs, ability to access the access logs, cli uploads as well as web interface – Really cool stuff in my opinion, not something we can use for projects like PEAR but I know countless projects that could make use of it!

Thanks to Scott Collison from Ohloh for informing me, I need to try this out as soon as possible to see if it actually works as nicely as it sounds.

Tags: , ,
September 27, 2008

PHP Barcelona 2008 – Wrap up

Now the PHP Barcelona 2008 conference is almost over, I am sitting in the last keynote of the day – Derick is talking about XDebug.

PHP Barcelona 2008 is a user group run conference, costing only 20 Euros for people to attend and it managed to garnish around 200 – 300 people, which shows that the PHP Spain scene is quite vibrant and alive. The conference was run really well and the venue is truly amazing, given people paid 20 euros to enter, everyone went wow as to the quality given the payment ratio.

This is a conference to look out for in the future and I for sure am gonna attend next year if possible.

I gave my Deploying website with the pear installer talk:, I’ve updated it a bit and changed it, the talk it self went really well – ran 5 mins over, people seemed somewhat confused but I had really good feedback, both on pear and the talk it self … How I can improve them and in general good questions.

So hopefully they will have another conference next year, this one was too well run to not do it again. See ya there!