PHP Created This Monster

June 8th, 2015

PHP turns 20 years old today. What was once a collection of libraries created by a Danish-Canadian programmer to make creating web sites easier is now powering a ridiculously high percentage of the internet. To all the PHP haters I say "CHECK THE SCOREBOARD".

I first encountered PHP either in 1997 or 1998. I literally cannot remember when I first used it. All I do remember is that I needed to find something that was free to use because the company I was working for at the time did not want to pay for licenses for using ASP.

I built my first PHP application -- a web site that allowed you to enter the name of an artist or song title and see if it existed in the MySQL database I set up using CSV dumps from a Microsoft Access database.

I had no idea that the decision to use PHP would end up being the thing that built a career that is now 18 years long and counting.

I quickly figured out there were other people using PHP -- my early searches using AltaVista revealed a whole world of other people stumbling around trying to figure out how to get PHP to do things. In retrospect it's surprising that PHP is still essentially a collection of wrappers around C libraries that are used to pull information out of databases and display them on a web page.

That led me to figure out a way to go to my first PHP conference back in 2005 in Toronto at the Holiday Inn across from the Yorkdale shopping centre. I harassed my manager to go, even offering to do a talk when I get back on the interesting things that I discovered. I think they eventually gave in just to shut me up, and two other colleagues of mine joined me for that conference.

True story -- I happened to walk into the hotel lobby at the same time as Derick Rethans and he mistook me for someone that he knew. Of course, I didn't know who he was at the time but I quickly figured it out. Brush with greatness!

That was also the first time I got to see Rasmus speak at a conference. His talks haven't really changed that much over the past 10 years -- same sort of slides, and he just keeps showing us more and more why PHP is still one of the best tools for building web applications.

Once I went to that conference, I was hooked. I wanted to be part of this bigger community. I think watching people give presentations flipped the bits in my brain related to teaching. As the son of a high school teacher I suppose the potential was always lurking in there. I spoke at a conference for the first time in 2006 (I spoke about what PHP folks could learn from the success of Ruby on Rails) and I decided I never wanted to stop doing it.

Speaking gave me the confidence to experiment and try and do things that I really wanted to do. I got involved in an open source project (CakePHP) and perfected my trolling skills on the mailing list. I tried to find other people who thought that automated tests would save their future selves from their current selves. All the while trying to get more involved in the PHP community.

This led to more talks, and books, and videos, and still more talks, and a PHP user group, and even more talks, and flying to Europe to speak, and more books, and even helping to organize a PHP conference.

The awesome career (and I know it is the height of ego to suggest that you have an awesome career, but I do not think you can look at what I have done objectively and not say it's turned out really, really well) I have is 100% because of PHP.

At times when I worried more about making money than being happy I thought about switching away from PHP. In fact, back in 2005 I turned down a job with a friend of mine where I would've morphed into a very early Ruby on Rails adopter. I have no idea what would've happened, but somehow I think that you could do 's/PHP/Ruby/g' in my life and it would've been pretty close.

One person's creation has ended up powering the careers of thousand and thousands of people. Thanks Rasmus for helping me unlock my potential and create a PHP monster who has shared his thoughts on Twitter more than 70000 times.

Stop Telling Me To Refactor

December 14th, 2014

I got an email from Daniele earlier this morning about the post I did talking about how web acceptance tools suck and they were kind enough to share their thoughts on how they felt I was (to use their words) "facing the problem in the wrong way".

They went on to describe how I should just separate the front-end from the back-end to make testing the app as a whole easier. They shared a link to a project where they had done that so go take a look.

I don't find much wrong with that approach but it has a hole in it big enough to throw my ego through without scraping the sides. Daniele, this has nothing to do with you and everything to do with a mind set that continually comes up in our industry.

The incredible casualness with which we tell people that the solution to all their problems is to refactor things.

Just stop it. Stop telling me that. Stop telling other people that. It reflects that you have given no thought to the other person's situation. Do they have the time to refactor? Do they have permission to refactor? Are they even skilled enough to refactor the app in such a way to make it better? These are all legitimate questions. Blindly recommending refactoring isn't the solution.

In my case for my current work-related activities, there is zero chance we will be doing the kind of refactoring that Daniele is very-helpfully recommending. Why? The application in question works and brings in money. So the app in it's current form needs to stay up and keep working. So that means I need to find the least-invasive way possible to test the application's UI.

There are other refactorings I am doing (moving the app from ZF1 to ZF2 is among them) but those take time and have to ensure the existing application doesn't crash and burn due to those changes. I suspect I may be ending up buying a bunch of over-worked QA people in Kiev a nice thank-you present when they finish the extensive testing I need them to do.

Send me your thoughts and ideas on Twitter or to

Web Acceptance Tools Suck

October 31st, 2014

Wow. Almost a whole year since I posted something. Time to change that.

It is not a coincidence that I write this blog post on Halloween 2014. Because I want to talk about something that should make your skin crawl and want to turn all the lights on in the location where you are reading this.

I am talking, of course, about writing automated web acceptance tests.

At ZendCon2014 I did a talk about how to use Behat and Mink to write some automated acceptance tests for your web sites. You know, the type of thing where you drive a browser using some code and it pretends to click on things...and you lie to yourself about what value all this work is giving you.

I also made the classic mistake of waiting too long to go over my slides for this talk and realized I was using versions of these tools that were extremely out of date. I then spent 6 hours updating the code, instead of watching my friends give awesome talks about PHP and complementary technologies.

This sucked. Sucked big time.

As far as I can tell, we are currently at the point in the PHP community with these tools like unit testing tools were 10 years ago when I first decided I needed to find ways to never work 120 hours of overtime in 6 weeks leading up to Christmas ever again.

Behat and Mink are both very powerful tools, but their documentation is lacking and the code samples review what I think is a very large disconnect between how the creators of these tools use them and how the rest of us use them. I have no idea if there is even any blame to be handed out, unless you subscribe to the theory that shitty documentation is the fault of the people who created the projects in question.

I am not diminishing the work of those who created these things. They are great programmers, and I am just a grumpy guy who wants things to work a certain way and not act like obstacles. I like my tools to be complementary and easy to figure out how to bend to my will.

But when I look at how brittle these things are, and how slow they are, it makes me wonder if I wasted my time learning how to use them.

For those who don't understand what I am getting at, or think I am acting like the drama queen they secretly hope I am, consider this -- the best way to identify elements on a web page is to use tools that expect you to either fully understand CSS and also how XPath works.

Folks, this is a shit show.

Now, it is entirely possible I am simply Doing It Wrong, and will be happy to be corrected. Take a look at the code in this repo AND DESPAIR. This code is brittle, has to maintain state between test steps manually, and the tests take forever to run because you have the overhead of starting up a browser and painfully crawling through the DOM to find things.

(By the way, who is the person that decided the DOM was the best way to internally represent elements on a web page? If it was Tim Berners-Lee, well, it strikes me as a decision that is biting us in the ass now but was probably totally logical at the time)

I am hopeful that someone out there is working on a better set of abstractions and tools that will make the types of things we are asking Behat and Mink and Page Objects and PhantomJS to do a lot better.

Send me your thoughts and ideas on Twitter or to and I will do a follow-up post.