Archive for ‘PEAR’

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.

QA and PEAR

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 (http://pear.php.net/pepr/pepr-proposal-show.php?id=60) 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 »

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 »

August 11, 2008

PEAR installer updating its PHP deps

So the title says it all, kinda …

For the next alpha release of PEAR that will happen in 2 – 4 weeks we’ll have a min dep of PHP 4.4 and 5.1.6, so basically excluding 5.0.0 – 5.1.5 Now why am I going to do that ?

As any decent PHP developer know, PHP 4 is dead so to at least stay in the latest PHP 4 release I decided it wouldn’t be worth the hassle to maintain support for 4.3 anymore (It’s also the case with PHP 4.4 but I kinda dislike abandoning people altogether) and well 5.0 nobody uses except for crazy people and everyone in the 5.1 series should be up to 5.1.6 anyway since RHEL uses that and most of the LTS distros out there.

So yeah I’m doing this so I don’t have to test on so many PHP versions as well as hopefully nudge users to upgrade their PHP if they wish to use PEAR anymore … kinda … a little known secret is that the installer still works fine on 4.3 and 5.0 – 5,1.5, you just need to do pear upgrade -f pear if you want to keep on using those old ugly PHP versions but be warned, I’ll bogus any reports that has those numbers and I can’t properly reproduce any of the newer versions of PHP.

Now some people might be wondering things like: why didn’t you put PHP 5+ dep and rewrite the damn installer to proper PHP bla bla bla bla, well we’re already doing that and it’s called Pyrus and will be PHP 5.3+, the work I’m doing on the PEAR installer is because people will take some time to upgrade from PEAR installer to Pyrus once Pyrus is stable so I think it’s important we try to maintain the old installer for a bit longer and to make that easier for us the PHP version reduction was important, for us and I believe the community.

I’m mostly making this post so people know about this beforehand and can react accordingly on their own servers when the time comes.

Also does anyone have a beef with me excluding those PHP versions ? :-) If so comment here or email me at helgi _at_ php _dot_ net and explain to me why that is.

Tags: ,
May 22, 2008

Return early and simplified if else

Lukas posted a very interesting post yesterday, http://pooteeweet.org/blog/0/1107#m1107 on early returns in code which is a subject he and I have talked about couple of times before and I’m still not sure why we haven’t pushed for it into the PEAR standard.

Returning early is a thing I simply love, it can make your code so much more readable with very little effort at all and the flow feels a lot more normal e.g. check for errors and return if found, kinda like airport checks, they check if you are legit at the checkin board and then at the security gate and each time they throw you away if you are not legit.

I’ve been battling with a lot of PEAR code to return early because some of the code can look like a maze, the PEAR installer for example, go see the blog post by Lukas to see couple of examples but here’s a big pet peeve of mine that I try to correct every single time:

 function bar() 
 {
     if ($foo) {
         a lot of fun code         
         return $somethingUseful;     
     } else {
         return false;
     } 
 }

Obviously this is a very minute example but it can be turned into:

 function bar() 
 {     
     if ($foo) {         
         a lot of fun code         
         return $somethingUseful;     
     }     
     
     return false; 
 }

this is what I call shit mixing but still makes it more readable but this way I prefer which is the way Lukas portrays

 function bar() 
 {     
     if (!$foo) {         
         return false;     
     }     

     a lot of fun code     
     return $somethingUseful; 
 }

Think I will try to push this into the PEAR manual one of these days if possible, makes things so much better.

August 12, 2007

GSoC 2007 Mentor

For those that don’t know already, I’m a Google Summer of Code 2007 mentor for one Igor Feghali on this project.

I must say I just totally forgot to blog about it so bare with me ;-)

Anyway this project is a pretty exciting one for couple of reasons, one thing being that I use MDB2_Schema in just about everything I do at the moment and I was a little involved in the whole thing when Lukas Smith was heading it or so I like to believe *crosses fingers*, another is that I’ve always enjoyed working with Igor, a feisty young fellow he is and constantly has some new ideas and another major factor is that the DBAL in ezc uses the XML format MDB2_Schema has as well as a project called Doctrine (well at least it did use the MDB2 code as base so I’m hoping they also used MDB2_Schema) and I do hope at least ezc will sync with these Forgein Key additions :-)

Since I’m blogging about this so late in the game then I think it would take me all night to jot down everything Igor has done so instead I encourage everyone to just head over to his blog and read about it there even tho recently he was added to planet-php, Igor has done a terrific job of keeping me up to date via his blog as well via emails/IM but the gist of it and the important things are on the blog anyway.

Looks like we made a good decision about picking Igor and it seems that he will manage to finish his project second year in a row! :-) Hopefully he’s up for a hat trick next year ;-)

June 8, 2007

PEAR Installer 1.6.0 and XDebug code coverage

One thing I’ve always missed in phpt is code coverage reports, not lcov since I’m talking about testing userland code, kinda like we have in PHPUnit so I decided to implement it in pear run-tests so that I could check out how much code I’ve made tests for in PEAR and other projects where I utilize the phpt format.

So the first thing I had to figure out was the RunTest code in PEAR, it’s a old port of php run-tests and hadn’t really been updated to any real extent, mostly just adding features here and there, so what I did was to split it up into multiple functions so that it would be easier to understand the beast, run() was 700+ lines IIRC and in this process I managed to find a good amount of redundant code that we could throw out, yay! :) So the next step was to figure out how to make XDebug only provide coverage reports for only the tests and the code they run and not to include the RunTest code in the equation with out me having to filter it out, and then a very ugly solution dawned on me, I’d have to inject the XDebug start / stop / get coverage code into RunTest, OH MY GOD! :-/

But for those that understand how we execute tests this will make a lot of sense, because each test gets it’s own php process, we use proc_* for that, and why might one ask and the answer is simple, mainly to test PHP fatal errors and code that uses exit/die as well as being able to define our own ini options that the process will use (enable safe mode, disable magic quote and things like that) … There might be some other reasons but these are the most important IMHO.

Tho the first two reasons caused me some headache, since of course fetching the coverage info and throwing it into a file won’t work if a PHP Fatal error occurs or if a die/exit get processed in the test since it’s done at the end of each test, so I had a little chat with Derick to see if we could find some proper solution for that challenge and he said he was going to look into it for XDebug 2.1, yay for Derick :-D So to sum up a little I take the FILE part, detect the first and inject the start / get coverage / stop XDebug code as well as var_export($xdebug, true); and write that to a file in the same dir as the test with the file ending .xdebug (name can change, just seemed the most straight forward at the time :P) and hurray we have a file that contains a valid PHP array with the coverage info! :D

This isn’t a silver bullet, it needs some more work and a renderer package to make those pretty graphs and progress bars, like we have at gcov.php.net or similar but at least it’s progressing into the right direction and I’m pretty happy if it becomes useful to only handful of people, if more use it then I’ll be thrilled.

So anyone up to helping with the renderer package ? :-)

Tags: , , ,
April 21, 2005

Require Source Version Control in PEAR ?

Before reading this, do note that nothing has been agreed in regards to those actions described below are only my thoughts on this matter :-) Have fun reading!

NOTE All comments were lost due to a move from s9y to dotClear back in 2005, just look at the pear-dev archives from 2005 :P

Until now the PEAR project hasn’t required developers to use a SVC for their code (CVS, SVN and etc.) which has led to couple of problems and short comings for us, for example, maintainers just disappear and we are left only with the code in a .tgz form, possibly a very outdated version … HDD crashes (at the developers computer) and the most recent code that hasn’t been released is just *poof* gone … We have a difficult time monitoring the development that could led to spotting problems sooner and also we have a harder time running automate QA tasks.

This issue was discussed a bit on pear-dev and everyone seemed to agree that requiring people to use SVC isn’t too much to ask.

read more »

Tags: , , , ,
March 23, 2005

The saga begins :-) && PEAR::Validate

So finally “finished” the layout of this blog and actually _wrote_ a blog post so now you guys can “enjoy” this blog ;) Jibby!

As some of you might know, I’ve been splitting Validate into smaller packages, so called subpackages, now why am I doing it you might be asking ? Well simply put, why should you need to download the whole freaking thing with US validation stuff and more when you only email validation ? :-)

We’ll try to release these great changes (hey we also have bugfixes and a lot of BC breaks! ;)) as soon as we can, but at the moment we’re kinda stuck because of time issues, Pierre is working at PHP 5.1 stuff and I\’m busy with other things like the “rewrite” of the PEAR Tree package, some LiveUser work and a lot of other stuff not needed to be mentioned here, plus we both have a real life … For real, I’m not lying O:-)

read more »

Tags: ,