—

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.

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.

The Good, the Bad, the Ugly

As I mentioned, people have praised us for our stance on backwards compatibility and people have told us that we are idiots for it. Let’s look at the “issue” from both sides, shall we.

The good thing about keeping backwards compatibility (or as it is better known, BC) religiously is that if I, as a company or a project, decide to use library X from Y repository and said library is in a stable state, then I can rest assured that my application will still run as intended even if library X gets upgraded from 1.1.0 → 1.3.0 → 1.20.0. This is very important for me as an end-user because I can sleep at night, and it makes my development efforts a lot easier.

The bad thing about backwards compatibility is that you have to, well … maintain backwards compatibility, a bit of a circle reference there, huh ? ;-) As a library / API maintainer, I feel absolutely horrified about keeping BC in my code. I need to make sure that function foo() will stay the same, return the same, and accept the same parameters, even if I refactor the internals of the code. The fact is that sometimes you release something which you believe to have awesome code as well as the most superb API design ever made, but then some new requirements, new features, or unexpected bugs happen which directly or indirectly mean you need to alter the API. Now, you need to make a decision: try to preserve backwards compatibility and thus cause more coding and headache for you or release a new major version that breaks backwards compatibility and means that you will be supporting two code bases until the majority of your users have moved over allowing you to finally put the old code base to rest (a good library maintainer would try to maintain both ;-) ).

Having heard about the good, the bad, and the ugly of backwards compatibility, how does this really affect PEAR and other big projects? Simply put, it has caused PEAR to accumulate a good amount of PHP 4 code that can not really be turned into PHP 5+ only code unless a completely new release is done under a new version number with a changed class name, 2 appended or similar. And for this reason, we have gotten some nasty stamps from people for being too conservative, holding on to PHP 4, not supporting the adoption on PHP 5, and some people have even gone so far as to say that PEAR died many years ago.

Excuses, Excuses, Excuses

To answer those “stamps”, I have to go on the defensive a bit, but for a good reason. What we did in regards to backwards compatibility has kept many companies extremely happy because we have not broken stable code out of the blue.

First off, I’d like to say this: PEAR has only accepted new packages that have PHP 5 dependency for 4 – 5 years so if anything, PEAR has been very pro PHP 5 for a long time. Plus, we have made sure all of our PHP 4 packages work just fine on PHP 5. As part of being a high quality repository of code, PEAR developers have tried to ensure that old packages do not fall into a Siberian no man’s land, so sometimes this can also be perceived as holding on to the past.

Another thing PEAR did back in the days when PHP 5 was taking its baby steps was to make sure people did not propose a package as PHP 5 only if it was just going to use sugar features like public / protected / private, or ppp if you like, because, at the time, PHP 4 was going strong. Of course we allowed PHP 5 only packages if people actually used PHP 5 specific features. Hindsight is always a great thing and we probably shouldn’t have pushed the matter so hard, oh well!

One thing to consider about promising people backwards compatibility: it will strain your development resources heavily, especially because it will mean maintaining two or more branches of similar/same code base. This resource strain is one of the reasons why PEAR developers sometimes opt for maintaining PHP 4 code that also works on PHP 5 instead of maintaining two copies of the code, PHP 4 code that works on PHP 5 and then also a PHP 5 only version. It’s open source, and you only have so much time on your hands. :-)

As you can see, these are a bunch of excuses, but to me they are fairly valid reasons because often we were putting our standards to work, enforcing them were needed, and thinking about our end users, something too few projects do, be it in PHP, C or whatever language. One excellent example is ffmpeg, a very good library to handle videos and similar formats, but they don’t believe in backwards compatibility. They, in fact, constantly break their API, don’t do any official releases to speak of, and just tell people to stuff it (just go read the Download page on their website – http://www.ffmpeg.org/download.html). This has caused many people to move away from a very good library to other alternatives because they don’t want to fix their code every other day because said library maintainers are not playing ball with their end users.

Hopefully, this was useful to people who have wondered about backwards compatibility, as well as projects/companies that are either going to role out their own libraries to the public/customers or intend on picking a library or five to use in their own projects.

Think long and hard about it: do you have the resources to use a library that doesn’t have any backwards compatibility rules in place or do you have the resources to maintain a library that has backwards compatibility rules and everything that encompasses.

Put your thinking hats on ladies and gentlemen, and, until the next time, cheerio.

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.

But, how do we bring that experience from the knowledge bank of PEAR and give it back to the community, so other projects can learn from us and steer clear of what we did wrong and embrace what PEAR did right.

One of the things that really makes PEAR what it is today are the standards we have evolved for the past couple of years. A lot of other projects and even companies have embraced large chunks of those standards as their de facto standard for PHP userland code.

Just to name a few standards:

• Distribution system (channels, packages, package.xml)
• Coding Standards
• Version naming
• Directory layout
• Backwards Compatibility and what that entails
• And many others

If you want to read about the distribution system, you can grab the 2009 November and December issues of php|architect where I wrote about it in good detail, or you can wait for me to publish those on my blog.

Version Naming

Let’s start by talking about the version naming standard and why it’s important.

Now don’t get me wrong, it’s not like PEAR invented the need for version naming, be it for PHP projects or the software world at large, but the fact is that PEAR was one of the first, if not the first, large-scale PHP project that had more than one concurrent release at a time. This fact required a proper standard in the end.

So, almost 5 years ago today, the PEAR group at the time went ahead and formalized a standard to keep the version naming more consistent, yet still working with the version_compare function.

The document they produced can be accessed from http://pear.php.net/group/docs/20040226-vn.php, but I will attempt to simplify it a bit.

First, it’s important to understand that there is a difference between version numbers and version state and how they interact. Let’s look at how the basics of the version numbering system work. Consider x.y.z for a second, now let’s translate that into something human readable.

• x = Major release number
• y = Minor, used for feature additions
• z = patch level number, used when it’s purely

only a bug fix release

Now let’s have a quick look at the states, dev, alpha, beta, RC or stable (listed in the order of code maturity). So what you end up with is x.y.zstate (Note the lack of space there) except when you have a stable release. In PEAR, you might see version namings like so: 0.5.6alpha1, 0.12.0beta3, 1.0.0RC4, 1.2.0 and so on. With this system in mind, we need to see what each state and number incrementation really means for you and your project.

Quite often, I see people do their first release, and for some unknown reason, they decide that 0.0.1 is the best version, swear by it even. In the version naming standard we have in PEAR, that is not allowed because when you are releasing the first release you are not fixing bugs, you are adding new features, so the first release should always be 0.1.0, at the very least.

Something that happens fairly often as well is that people do their first release as 1.0.0 with a stable state, even though their project doesn’t truly have a stable API, such as, or even a stable product in general. Perhaps it’s because they believe they managed to get it very stable, but the fact is, no matter how stable you think your product is for the first release, always release the first one lower than 1.0.0 stable.

Keep in mind, when you go stable, stay stable! Don’t start messing up the API in a way that people will have to alter their applications, this tends to be called BC, or backwards compatibility.

Backwards Compatibility

Now what is backwards compatibility? In short, it is when I, as an application developer, pick library X to use in my application and pick release 1.2.0 to start utilizing the API of library X. Even though I don’t follow the development of library X, if they follow a proper, no-BC-breaking approach, then I should be able to upgrade the lib from 1.2.0 to 1.6.0 without having to change a single line

in my code. If a BC break would have occurred between 1.2.0 and 1.6.0, then there is a good chance that my application would stop working with such an upgrade. So BC breaks should only happen below stable, preferably only in the alpha state, if possible.

Food for Thought

So, I perhaps didn’t cover all that much of the version naming standard, but I do believe I got my point across and those interested in learning more can go to the link I supplied above to get a better idea of how this all works together beautifully.

A prime example of why it’s good to have a set standard on the version naming would be when Matthew Weier O’Phinney of Zend Framework fame contacted me in late 2008 to determine whether PEAR had this kind of standard. The Zend Framework team was having internal discussions in regards to version naming, especially for their preview releases, better known by other folks as alpha releases, where new api changes are introduced but still not considered stable or that an API could possibly break before the final release.

In the end, Matthew managed to convince them to use alpha/beta states on the package level while allowing them to use PR (Preview Release) for the website and announcements. This allows people to use version_compare on Zend Framework for future releases, potentially use a PEAR channel for distribution and to have proper stability states for what the release is supposed to reflect.

I felt like this was a very good example showing how using a well-established naming convention benefits the whole community and makes things a lot clearer for those familiar with said standards.

Hopefully this is as useful to you as it was to me and the projects of which I have been a part. It has, at least, been highly successful to PEAR and numerous other projects.

On the subject on online publications, last December I wrote an article called First-Class APIs for the PHP Advent Calendar – A topic I enjoyed a lot writing about. But I wanted to take a minute to thank my two good friends Sean and Chris for taking their personal time to bring the whole thing together. Editing articles, cat herding writers and generally being awesome for helping the PHP community to be even beter. If you have never read any of the articles that get published on PHP Advent then head over there right now and read up on them! I’ve been privileged enough to have an article up there the past 3 years and hope I get to write for them again this year :-)

Seems they don’t have any way on the website it self to go back years so here you go: 2010 – 2009 – 2008

Anyway, I just wanted to get my blog rolling for 2011 and here’s hoping I can keep up a real blogging schedule at least for the first part of the year! :-)

One of the Analog guys, Andrei Zmievski wrote a very inspiring blog post about the journey the co-op went on, from idea to reality. There was one point in the post which caught my attention, where Andrei talks about claiming back simple, honest phrases like web sites and web developer. As Andrei puts it

They are precise and descriptive despite having been shunned or dismissed by people in favor of things like web application, front-end/back-end engineer, and other seemingly sexier nomenclature meant to sound more important.

Simple, yet a good point none the less. But lets not dismiss a completely valid term such as front-end engineer just yet.

Now what is a web developer then? For me it is a person works with anything web related, be it on the front-end, back-end or in-between. If we compared it against another profession — Lets take teachers, saying “I’m a teacher” is very general and broad but a teacher can also say “I’m a high school English teacher” to further clarify their role. To me, the same thing applies to web developers, it is the umbrella role where front-end/back-end engineer and similar roles are subsets of. It is true that there are people out there making up roles such as “Social Media Expert” and other non-sense roles, only to sound more appealing and important.

I applaud Andrei for attempting to make web developer once again a commonly used phrase, and I feel like I can proudly say “I’m a web developer!” but I also feel like we shouldn’t dismiss valid job titles within the web developer umbrella, but leading with web developer whenever we can is a great idea. I might be a bit bias on the subject since I recently wrote about Designers versus Developers for phpadvent where I touch on what front-end engineers are, the role they play among designers and developers (web developers even).

Simple and pure is good when applied correctly. I can see where Andrei is coming from if we factor in the Iceland trip he mentions in his blog post, which I incidentally was on as well. There were a lot of moments during the trip where clarity and amazement dawned on us over the beautiful scenery we saw, yet at the same time it was simple — I can see the appeal of bringing that into business, to take us back to the basics and claim back simple phrases/approaches — Clearly something they are striving for at Analog.

And with that I will leave you all with a picture of the most profound moment of the trip along with the tweets we sent out at the time. A big turning point in all of our lives.

Photo by Chris Shiflett, taken the summer 2009, 2am, Iceland.

Reset my spirit underneath the midnight sun at Stykkishólmur. Feeling refreshed and renewed.

— Chris Shiflett

To echo @shiflett, watching tonight’s sunset in Stykkishólmur was the point of reset and restart in my life.

— Andrei Zmievski

The sunset outside of my old home town was amazing. Tranquility. Makes you think. I will be making changes in my life.

— Helgi Þormar Þorbjörnsson

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.

I would like to applaud both Chris Shiflett (@shiflett) and Sean Coates (@coates) for starting PHP Advent and keeping it going. They do a lot of work that goes unnoticed, ranging from finding authors way ahead of time, to cat herding the authors and making sure everyone is on time, over to doing copy writing on our scribbles to make us sound at least mildly coherent, at least they did for me :-)

They are the men behind the scenes, so please show them your appreciation and drop them a line and say thanks, since we all want this to keep on going next year. Chris & Sean, I take my hat off for you for spending countless hours making this happen, especially during those evenings in December where you slaved over copy writing articles and making sure everything ran smoothly.

I would like to point out that I’ve been an author for PHP Advent for the past 2 years, so I’m fairly bias about it being so great :-)
Also a shameless self plug, here are my articles of last 2 years:  Coping with the Holiday Shopping Spree (2008) and Designers versus Developers (2009). I hope you have as much fun reading them as I had writing them.

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 :-)

The first talk I gave was about frontend caching and how you can get the most speed out of your website by optimizing the various bits of the frontend.
This is a talk I really enjoy giving and have but a good amount of work in preparing for, and didn’t spoil it that I got a full room for that one where people were very engaging and keen on learning about the topic.
All in all it was a huge success and I got a lot of good feedback from people, both in terms of how I can tweak the presentation and people just generally interested in knowing more, both of which makes it worth it spending time on making a good presentation! :-)

Here is the slide deck for the caching talk: http://www.slideshare.net/helgith/frontend-caching-the-new-frontier

My other talk was about PEAR2 and Pyrus and what’s upcoming with both of those initiatives, this one I was asked to give at a very short notice but I’m very ecstatic how it turned out, especially given the time constraints I had on various fronts.
My crowed was small, mostly due to the fact that Elizabeth Smith was giving her famous SPL talk, but I didn’t mind as I had a very good group of people and I toned it down into a more of a personal approach where I gave each person more attention and it gave people the opportunity to more freely bring up their questions and control the flow of my talk, a very nice change of pace.

The slides are available at http://www.slideshare.net/helgith/pear2-pyrus-the-look-ahead

PEAR2 and Pyrus are definitely something for everyone to look at as soon as they can and something they will use in the future.
The future is here! Reach out and embrace it ;-)

Now with a big conference like ZendCon there are many aspects to the conference it self and how one can measure the conferences success, ranging from the speaker experience to the attendee experience all the way over to the social aspect of the conference and in between.
With ZendCon as far as I could see, most of those went over stellar! As a speaker I really enjoyed the conference and I heard very good feedback from people about the conference in general.
It didn’t hurt that Keith Casey organized a unconference for ZendCon this year and man oh man it was a success, a lot of quality talks and panels came out of it and it was to a point where some people attended more uncon sessions than actual conference sessions! Now if that is not success then I don’t know what is!

On the social side of things there were fewer conference organized social events than most other conferences that I usually attend and the open bars were a fair amount of joke, I’m sorry Zend but you get a minus point there :-/
But fear not, that’s where the whole social aspect comes in, the people around you will make it bearable and you will feel more inclined to chat with a random person just to make up for the lack of alcohol.
But as with any other PHP conference there were a couple of self organized social events in various bits of San Jose and San Francisco, where speakers and attendees likewise get up and figure out a plan to entertain them self, usually involving alcohol, and the outcome – A great social event with drinks at hand and great people to get to know and catch up with old friends.

In relation to the social portion above, among other things, I feel like I should make a special mention of Microsoft and the people they had at ZendCon this year.
Josh Holmes and Paul Treichler were the Microsoft guys that stand out head and shoulders above the rest.  Not only was it enjoyable to talk to them about the way and the world, but they were just as adapt and prepared to discuss what Microsoft were doing right and what they were doing wrong, in addition to talk about Microsofts competitors (One could say that in some cases they knew the competitors tech just as well, if not better than Microsofts, but you didn’t hear that from me! ;-)) on top of being socially capable and just fitting right into the crowed with us, be it at the bar of at the conference – This kind of diversity is something very few, but in increasing numbers, Microsoft employees poses and they are the kind of people that are slowly building up the trust and reputation of Microsoft with open source nutbags like my self, the reason being, they get us!

If Microsoft continues sending people like Josh and Paul to conference to interface with people then I’m sure that Microsoft will start gaining grounds again and lose their “We are all bad and horrible people” stamp they have.

And now to tie in Microsoft and the social bit properly!
While ZendCon was happening then Microsoft was holding Bing party up in San Francisco (remember, ZendCon was in San Jose) – And in an classic example of self organized social, John Coggeshall and Scott MacVicar caught wind of the event and started organizing for people to register for it and to find a way to get everyone there.  After a lot of pondering it was decided to get a Party Bus! to the event and back to our hotel.
One thing led to another and we ended up with a big group of people going up there and as it turned out, Josh made sure that everyone got into the event at Ruby Skye (The Bing party) and that Microsoft pitched in on the bus and also made sure everyone had a night to remember! The night was LEGENDARY.
So on behalf of everyone that attended that party from ZendCon, I would like to than John, Scott and Josh for making things happen!

I can just now hear people start thinking “Microsoft is just buying your loyalty!” and my simple response is, no, no they are not – This is just a case of a changed mindset at the company which helps facility for me and other reconsidering previous ideas we had about the company, its employees and more importantly its products – With the right attitude and directional change, anything can be achieved.

Anyway! So all in all, I would like to thank the organizers of the conference, especially Eli White! for a great conference, unconf people, the attendants and old / new friends for making it such an enjoyable experience and Microsoft to throw such a fun Bing party!
Now to hope there will be a ZendCon 2010!

Just as a final plug, a lot of people asked me where I work and what we do, so I’m just going to plug my companies website to simplify things! :-)

http://www.echolibre.com/ and our blog is located at http://blog.echolibre.com/
If you want amazing work done, contact me directly or any of the contacts details on the company website.

I will be presenting Frontend Caching – The “new” frontier, which is all about how to squeeze the most performance out of your frontend and I will also give PEAR2 & Pyrus, the look ahead where I will talk about where PEAR2 stands currently and how the new PEAR installer is progressing (e.g. Pyrus) and how it will revolutionize your life.

Both of those talks I have given before on couple of occasions, where they have gotten good feedback from the crowed and I have been tweaking them along the way, so I hope everything will be in tip top shape for the ZendCon crowed! :-)

I would link directly to the descriptions of my talks but apparently S&S do not know how to make websites that are usable so I can’t without digging in deeper than I want to bother with! Sorry!  Just go to http://www.zendcon.com/ and browse the agenda to see the descriptions of my talks and many other great talks.

I hope to see you guys there!

Update:

As Chris of the phpdeveloper.org and joind.in fame pointed out, you guys can see the description for my talks at joind.in :)

http://joind.in/talk/view/893
http://joind.in/talk/view/955

Also you can use that to give me feedback and rate the talk after I have given it, I would very much so appreciate that.

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

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 ;-)

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)

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.

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: http://www.slideshare.net/helgith/website-releases-made-easy-with-the-pear-installer-barcelona-2008-presentation/, 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!

So do come by to the conference, by the really small fee about 20 euros, fill up the conference and have a beer or 10 with us afterwards!
Looking forward to seeing everyone there!

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.

Zeev’s keynote was kinda like what Andi went on about back in Chicago – Saw the same slides in some case, history of PHP, where we are going and fun things like that, I know some people liked it but I must admit I was not impressed per se, maybe because I have seen Andi do most of this before ? Who knows.

Anyway on stage came Marco Tabini, a person I’ve never seen talk before and he had a interesting keynote title, Software and the taste of mayo, and I must say I was really happy with seeing how it turned out. Marco managed to pull off being his usual funny self and still get his point across, he talked about how software and services get over engineered, bloated and simply poorly written, for comparision he used mayo – real mayo is made out of three ingredients where as for example hunts mayo is made out of 50 or so ingredients which can more often than not be reflected to software and how they are handled. A good talk.

Next up was Derick with his eZc talk where he went on to explain what the whole concept is, introduced what I like to call their better components and show example but 45 mins didn’t make it justice, Ivo make the talks longer next year! And add another conf day :) This talk convinced me to look deeper into ez components and use more components than I already am.

PHP Security by Johann, I was expecting something different than what he talked about – It ended up being more like, not sure what to call it, a very dry university professor lecture, a lot of stats about why people are exploiting web apps, now and 5 years ago – names of some ways to run a security audit and basics about how you should do them. It didn’t catch my attention and I was really bored in there but people around me seemed very happy with it and thus I must deem it a success even tho I felt I was in 101 class.

The last talk I attended was Ivo Jansch session about Enterprise PHP Development. In there he used a nice metaphor about blocks to build a house in accordance to development , I must say I enjoyed the talk since he was talking about this I tend to ponder on a lot in projects I’m involved in but I was quite surprised that people in the talk seemed to find some of the topics Ivo touched on to be new to them. Good thing Ivo just published a book about it at PHP Arch.

I was going to end this blog post with something along the lines of “make the topic more advanced for next year around” but evidentally that should not happen since in many of the talks I looked into people seemed generally puzzled but I did hear the random “I felt I was back in pre-school”, so my advice to the conf holders, do a mix of both, add a extra conf day and everyone will be happy.

Terry Chay had his usual closting keynote, I was not all that satisfied how less explicit it has gotten recently, we need to get him drunk before these keynotes – Or he has to make a new one since he might be getting bored of this one but I still enjoy it :)

That night we went out for drinks and fun and stayed out for a looooong time, basic after conf stuff really but it meant we were a bit woobly the day after when we went sightseeing in Amsterdam, where we went on the canal bus and saw a lot of Amsterdam – Really beautiful and after that we went for a good stroll in this amazingggggg weather, wow I almost extended my stay just because of it – thankfully the weather was good in London too when I came back :)

Anyway this is a rather short wrap up but should give a good idea that I really liked this conference, good to see we still have a decent conference in Europe (unconfs not included in this statement :P they always rock) and I’m going again next year, hands down and so should you!

I wrote parts of this blog post during the talk so some of it talks about the session parts as they are in the future, I’m way too lazy to fix it but I do expect everyone that reads my blog is smart enough to just go with the flow on this one ;-)

Another reason why this session is interesting to me is because I’ve been dabbling in phpt all my life, everytime I’ve come across PHPUnit in a software where I have some say in it, I convert it to phpt BUT those are usually PHPUnit v1 which is well … not pretty – I used to use it in some PEAR packages, felt a bit over the top.
Having only touched on v3 a weeeee bit so I’m hoping Sebastian will bring some new light on this and make my mind a bit more open for v3 and v4. Quite funny tho when I was writing the above sentence that Sebastian was talking about that unit tests should be easy to write, I’ve always found the barrier to be higher for PHPUnit than for phpt, maybe it’s just me ? I have always believed that one file per test, it feels like PHPUnit encourages putting many tests in one file which kinda feels … messy, maybe it’s done because people don’t want to be extending some class all the time and fun fun things like that.

Tho as Sebastian points out, phpt is more of a standard and it’s not a unit test framework but in my experience it’s pretty easy to throw in most of the basic functions that people will use in PHPUnit, that’s something we did in pearweb – mock DB, assert funcs and all that but no doubt it doesn’t even start to touch on what PHPUnit does but most of the times you are only playing with the basic features, I’m a bit bias about phpt tho.

While showing how important tests are while refactoring Sebastian showed people how to solve code smells, a term coined by Martin Fowler but he added a little bit that I didn’t know about it, while Martin was writing it he had a new born baby in the household and his wife kept telling him “if it smells, change it” and so he went on to adopt it for coding.

A nice feature I wasn’t aware of in PHPUnit is tagging X many tests as a certain group and then having the ability to execute a group of tests in one file (kinda makes the many tests in one file sound nicer) or across multiple files, or so I believe from what Sebastian said.

Couple of other really nice features were mentioned like: DB_Unit – port of jUnit database stuff to PHPUnit, uses PDO only atm Selenium, cool as always phpUnderControl

DB_Unit and phpUnderControl are two things I have not tried out yet but I will for sure, phpUnderControl just looks awesome and I like the whole idea behind CruiseControl just never gave my self the time to look at it even if Sebastian has been talking about it for …. ever :-)

A bit of a funny tidbit, apparently there was a smallish bug in the html output from PHPUnit and Sebastian told us that this part of PHPUnit is nigh impossible to test – or maybe even PHPUnit it self as whole, didn’t really hear it properly and he’ll shout at me if he ever reads this and wants to correct me :)

The later parts of the post might look a bit … rushed … they are, I’m sitting here in a hotel in London trying to grab it all from memory :-) Mid through Sebastians session I became distracted with fixing bugs and other food related things and thus missed out on parts of the session, which was a pity, good session, really good.

I’m definently going to give PHPUnit another chance after this session but I’m still going to follow the PHPT.info development since it might become something really useful, after all it was born from the pear run test suite (which was born from the original test runner in PHP it self, so that we have the facts right, IIRC hehe)

a note to Derick, arrange a full day workshop of xdebug next time around! I had a real hard time picking if PHPUnit or Xdebug would be the session I wanted to see, then I noticed the xdebug one was a half day one … fail …

All in all, a good day – The evening was a lot of fun, Dutch won the France people, the town LIT up – Fun times

I had my usual train problem in Amsterdam since I always forget what to pick when I’m buying a ticket to RAI, rather weird not having it as an option in the ticket buying machine, oh well … Then I forgot to print out a map so I could walk from the RAI train station to the hotel …. I ended up taking the scenic route … something some of my fellow conference people should be familiar with, it’s a the technical term for getting lost :-P But I got to see some nice looking places in Amsterdam and the weather was really good outside so I didn’t mind really … Seems they finally finished the renovations they were doing around RAI btw, everything looked … different.

When I walked paste the convention center I noticed couple of signs, really cool:

Now I’m just waiting for some other people to arrive so we can grab dinner, I love the hotel location, smack in the middle of a lot of restaurants and what not.

Tutorial day is tomorrow, still haven’t decided which one I’ll be attending so my blog post tomorrow will be a mystery :D

I’ve been trying to find a legit reason to go to Amsterdam yet again (previously went in 2005 for the International PHP Conference – IPC) and finally decided that the Dutch PHP Conference would be the reason, not only because I liked the city but also because the schedule looks damn good, ranging from Derick R., Sebastian B., Marco T and over to guys like Ivo and the infamous Terry terror (cheesy ? yes ? no ? yeah probably is) and oodles of people I’ve never seen give a talk but sure have interesting topics, I’ve already pin pointed a one or two new talks I’m going to attend.

I really like the fact that the conference is held at the RAI convention center, maybe it’s just me but I liked the place and the location, not too far from downtown and not too far from the airport either and this is coming from someone where the capital (Reykjavík) consists of mere 120.000 people.
Nota bene, I do think the IPC made a false move by going over to Germany with both their conference events so I’d not be surprised by the fact that the Dutch conference is almost full so if you haven’t already then you should go ahead and get a ticket! It’s cheap and you’ll get bang for your buck, there’s not question about it … Now if you can’t attend this year then you should mark your calendar to watch out for next years which will hopefully be a 2 day conference event with a tutorial day (common Ivo, it will make it twice as fun! :-))

I will try to post more blogs about the conference when I get there and hopefully I can also do another community coverage like for Tek, I have a feeling the EU crowed might be a tad different than the one we saw at Tek, that coupled with some notes on the sessions.

Should make for an interesting read later on, so stay tuned! :-P