Disclaimer: The following is obviously a spur of the moment tirade of sarcastic commentary and lots of (probably bad) humour. A lot of it refers to events from two years ago (that’s around ZF 0.8!). Ancient history . Mostly. In any case, I have to rant about something once a year related to the Zend Framework. It’s traditional. Park any attempt to take this too seriously at the door. I get a bit dramatic at times…

In certain places, I do sometimes get a reputation of being a crazy person. Usually it happens shortly after I find myself going down a road that leads somewhere truly undesireable (or when I throw in a weird blog post like this one). I had one of those moments today that served as a flashback to such a point in time from 2007. It’s not the first time, but it will be the last since I’ll ignore it completely from now on. Believe it or not, I do get a bit upset at myself when I let these times get to me. They are completely unimportant and silly – but when I have to relive them I will react in a pretty irritated fashion (ed: that should be kneejerk incendiary fashion).

This one started in 2007, right about the time I was first starting to write proposals for the Zend Framework. I felt pretty great at the time. I had lots of ideas, plenty of motivation, and then it all seemed to go downhill from there. The turning point was in June 2007, when after three months of work I felt I had enough done to propose OpenID support for the framework. Obviously a worthy cause, and also one which shouldn’t cause much grief since the ZF keeps advertising its wicked web service support. Before long, that boat was scuttled with news that Zend itself had been working on just such a proposal. Okay, that was disappointing. Zend had somehow managed to completely miss a three month effort on OpenID. Just another day on the farm. Next step? Collaborate? So I waited a few days and Zend’s code for what would become Zend_OpenId appeared in my inbox. Let the review commence! Okay, that ended a bit abruptly…it’s a bit short. Almost like it’s missing stuff and was written in a handful of days as a prototype. Talking went on and off for a while, and eventually my interest in collaborating petered out. Like any open source contributor, I participate to scratch an itch. My OpenID itch was well and truly scratched by now with my own source code, and continuing to throw time at another OpenID solution based on a different paradigm with a different ideology, little of which I agreed with, when I already had one functional was pretty pointless compared to something that still needed scratching like the Zend_View Enhanced proposal (and I really needed that shepherded through). So Zend_OpenId continued without my assistance, with something for Yadis persisting in the Incubator as an orphaned proposal. It still persists waiting that one final patch and call to the trunk… One day…

This all sounds reasonable and a bit dry, but in reality I found it all intolerable. A self-professed OpenID expert who is a member of an OpenID Foundation decides to add OpenID support to the Zend Framework after working on it for three months and who has actual code to prove it, is then told about the other proposal which just happens to be coming at the same time, and has code…of course. Well, a bit of code. If I were a real nut…I’d have a field day. Collaborate? I’d already finished this twice. I’m supposed to go for round three? Yeah, I admit, I was getting pissed off very quickly back then. I was close to constructing an elaborate conspiracy between Zend, George W. Bush and the Illuminati (how could you NOT have the Illuminati ). What was nagging me from the start was the obvious – I should have told someone to stuff that proposal somewhere and forged ahead with my own. Of course I didn’t. I was new, and had green stuff growing out of my ears, and it was Zend. The Zend. Silly me…

The summer of 2007 left me wishing the Zend Framework Proposal Process would shrivel, die and get gobbled down by Orcses (I was hoping for Gollum but he’s a hotshot movie star now). It remains the single worst open source experience I have had since I joined the open source gig in 1995. Not only was it discouraging, it was demoralising. There were points when I was driven to contemplate whether my input was even wanted. Which is probably why I remain so overly sensitive about it – I can understand the new guy is immediately suspect. But not like this. In September 2007 I finally wrote the blog post “How a proposal process could work – if retaining contributors is a goal” out of frustration. As the title suggested, and others guessed, I was borderline on taking a hike from contributing. Some months later I gave some ground, and deleted Zend_Yaml as a proposal. Waiting for a review, or challenging non-existent reviews, or noticing the distinct lack of communication between people gets tiresome eventually. I have a spectacular tendency to vanish for months on projects, but not a whole year. Also, using it as a condition when reviewing another proposal was just fucking stupid. After a few bouts of initial enthusiasm, Zend_Service_Yadis joined it for any worthwhile purpose. That is my fault of course – my motivation to finish a library already released on PEAR had simply evaporated. That scratch your itch thing again – it was scratched on PEAR already. By now Yadis had been in use for over a year in production in other forms, and Zend_OpenId wasn’t going anywhere.

Thankfully, since mid-2008, that horrible system seems to have mostly vanished for good. The change in topics may have helped too. Not many people have considered reimplementing Zend_Feed, and for a change, nobody had been busy on any secret OAuth components. It’s taken roughly a year, but these are finding themselves in the trunk and Incubator respectively and should see ZF 1.9 and ZF 1.10 in turn. Hurrah, I committed actual finished code for once…;). I’ve also dropped any pretense at applying Agile methods to proposals. When I propose something, it will have backing code, class skeletons and use cases (basically the entire integration test suite). It won’t be complete, but it will be sufficiently functional. Overall, I haven’t been irritated in months (well, before today).

But why, why does the whole Zend_OpenId episode still carry weight? It hit me today, when I was scanning my email and I spotted a note about some Zend Framework libraries showing their age and lack of maintenance. Perfectly normal for something the size of Zend Framework – code rot is persistent anywhere. It can be difficult to diagnose though unless you are a regular user or the maintainer, so I shot off a reply adding that the same applies to Zend_OpenId. It was only intended as a supportive example, something I’m personally familiar with since I’m the guy with “Zend Framework” and “OpenID Europe Foundation Representative” written all over their email signatures, so apparently this makes me an expert on the topic. I field a lot of questions about Zend_OpenId at times. As anyone using it knows, Zend_OpenId just doesn’t work at the moment depending on the Provider. It’s woefully outdated.

However, it appears that…I am the Zend_OpenId maintainer! Really? Huh? Wait a minute… WTF?

Que 2007 flashback… Que obligatory irritated kneejerk response disavowing all alleged responsibility for afore mentioned proposal I have never contributed any code to…

I know where this started. At some point in 2008 I did agree to look into OpenID 2.0 support. It was one of those goodwill moments, where you know you’ll get around to it…eventually…after A, B, C and probably D. And you really mean it too, until you’re dragged into someone’s office and told about E. Then the mysterious Z pops by for a few months with a couple of mates. Anyway…it never went further. No proposals, no code, no discussions, no nothing. I only vaguely remember the email even. I imagine I forgot about it within a week until I was reminded about it today, and am apparently being held to it by superglue and ISP records of the email (just joking about the ISP records). God help me. Why are you laughing? This is fucking serious!

Now, being the apparent Zend_OpenId maintainer and therefore responsible for all issues filed since Spring/Summer 2008…I resign, effective immediately. It’s bad for my heart, and my irritation levels. More so now that I know about it. Now that I have resigned, I can see something of the funny side. If I complain about Zend_OpenId – it really is all my fault. Even if I was unaware of it. Allegedly.

Seeing a funny side, and having the benefit of hindsight, I can recognise where it all went off the rails back in 2007. Back in 2007 I should have been more of an ass. Yessir, I should done a Hugh Laurie on someone! Instead I retreated into politeness, followed by disinterest. I should have done exactly what I did with Zend_View Enhanced – write the bloody thing to death in a multi-part monologue that would have directed my legion of rag wearing subjects (er…readers) to assault the edifice of Zend Technologies Inc. until they caved and decided proper OpenID support was popular enough to warrant some real attention, i.e. raise bloody murder. If nobody listens in private, then shout it from the rooftops. But I didn’t. And Zend_OpenId is broken. And the OpenID Community is all the poorer for it. So it really truly is all my fault. I wasn’t a big enough ass. I will try to endeavour to be a bigger asshole in the future. May god have mercy on all your souls.

Now that we’ve established blame, and didn’t even need svn to do it (since I’m not listed there…aha), can we update a few records? In the maintainer field, right on the table called Zend_OpenId, can we change that to NULL or “Zend” since they actually wrote it so presumably are responsible also for its maintenance? While we’re at it, can we make it a new rule that the ex-proposer of features later proposed by a completely different party, not be held responsible for the completely different party’s screwups? Thanks.

This years “Paddy Rants About Something In The Zend Framework You Couldn’t Care Less About” was brought to you by…well…me.

I am such a torment. Cancelled negotiations with a publisher over disagreements on a book format? Check. Said no to taking down a free book startup and enter a publishing contract? Check. Lambasted multiple publishers for releasing PHP 6 books which do not teach anything PHP 6 specific? Check. Next month I expose which publishing companies are secretly building weapons of mass destruction in their basements. Reverse that, I can’t afford a libel suit…

In “The Art Of Deception Or Publishing PHP6 Books” I aired my unflattering opinions about publishers who have been selling “PHP 6″ books. PHP 6, last I checked, was a bit like Leprechauns (Hey, I’m Irish! The use is legal!). You love them, you have lots of ideas about what to expect from them – but has anyone every really seen one (other than my great uncle)? PHP 6 exists in CVS – it’s never had a release other than the usual CVS snapshots. It’s certainly not complete and stable, and its future feature list remains a bit flexible. You could see PHP 5.4 in 2011 before PHP 6 is finished…guessing here. As its developers would say – it’ll be ready when it’s ready. One day. Maybe.

In response to the blog post, Wrox Press picked up on the problem on Twitter via Davey Shafik (@dshafik). Everyone knows Davey. If you don’t, you must have been living under a rock, or a ruby, for a really long time. I have to say, Wrox responded in a wholly unpredicted way I have to admire. It’s not everyday you find yourself hiding in a cave in Antrim (it’s nice…a little damp though) after seeing something you wrote persuade a publisher to pull back a book destined for the printers, and work on fixing it so it deserves its title.

Here’s the full text of the comment posted to “The Art Of Deception…” earlier today by Jim Minatel (Associate Publisher – Wrox). Jim is mostly the person sitting behind @wrox over on Twitter where he’s been quite proactive in getting to the bottom of my PHP 6 Book complaints.

Pádraic:

Thanks for taking the time to discuss this with me on Twitter last night. I’m the Associate Publisher for Wrox, I’m the person usually behind @wrox on twitter.

After meeting with the editor who ran the PHP list for us, you’re right. The titles of these PHP6 books, some of the references to PHP6 in the books, what isn’t covered in the books, all prove we made a mistake, something went wrong. But how, why?

Elizabeth (and thanks for her measured response) is correct in part of her assessment that books take a long time to write and publish. I’m sure that when the editor and authors started these books in Spring 2008, they’re thinking was that 6.0 would indeed be a stable release by early 2009 (if not sooner) and they were aiming for that. But clearly along the way we dropped the ball on checking references to things like the non-existent “6.0.0 stable.”

In the Beginning PHP6, MySQL, Apache book, I can actually understand the rationale not to cover Unicode there. Given that Unicode is primarily valuable to someone internationalizing a site or localizing it for multiple languages – topics that I wouldn’t consider “Beginning” level – I can see why it wasn’t covered. (Before becoming associate publisher, I was actually our ASP.NET editor for most of the last 5 years and we don’t for example cover internationalization/localization in our Beginning ASP.NET 3.5.) So we want to have a book that Beginning level customers understand will work with PHP6 if that’s the version they’re using, but we didn’t communicate right what that meant in this context where there weren’t major new v6 features at the level we thought a beginner would need.

The professional book stumps me more. It’s hard for me to understand how that book doesn’t have a chapter on Unicode. It looks like an oversight by everyone involved in the book.

So where do we go from here and get better than this to eventually prove we’re worthy of better than when @bicatu says “That reminds me why I’ve never bought a Wrox book?”

First, I’ve asked the team involved with Beginning PHP6 scheduled to ship to the printer this week to pull that book back, to read your post and the subsequent twitter discussion and to make sure we aren’t making the same mistake a third time. I want the author and editors to provide a level of confidence that the PHP6 features that should be covered are, that the discussion of the current state of PHP6 is accurate, and the that the title, subtitle, and marketing copy on the book and online accurately reflects what is and isn’t covered.

Second, publishing the right books depends on having the right team, including a large number of well placed community experts on the topics who serve as authors, freelance/contract technical editors. There’s always room for a team to improve, through learning and through recruiting. I hope this discussion helps our current team in PHP (and MySQL and LAMP in general) and I hope it helps us attract people like you who have ideas on what we can do better. I’d like to invite you and everyone who’s commented on this post so far (and I’ll post the invite on twitter too) to get involved. We’ve got a PHP Design Patterns book scheduled to publish in August (not specific to any version) I’d like to start by offering you all a preview of that. If you see any red flags, tell us. If you like it, if you see issues and help us make it better, at a minimum we’ll send you a free copy. If you get involved more extensively, you can discuss with the editor contract work. DM me in twitter with your email addresses if you want to get involved. Or email me at the address below.

Thanks for caring enough to get our attention. I promise, we’re listening.

Jim Minatel
Associate Publisher – Wrox
jminatel at w I l e y d o t c o m

On a side note, Jim spelled my name correctly. Class. I called Jim, “John”, on Twitter. Fail.

Rather impressed with Wrox right now.

If I have a remaining concern it would be that with PHP 6 unreleased and in flux, it still seems dangerous to title books using that version number. The most current updated PHP version from next Tuesday will be PHP 5.3 which is itself a pretty giant leap over PHP 5.2. PHP 6 is conceivably years away – its release date isn’t set in stone (I don’t know if anyone has even estimated it recently).

Long story short. I lost my job, had some medical issues, struck gold on a new contract, contract ended (with a nice bonus), need to find another contract in July, turned 30 (and got a tiny bit depressed that I can no longer validly refer to myself as “young”), lost more hair (I estimate the total baldness effect to be a few years away), spent an hour convincing my dad that if his leg could hang at that angle I was calling the bloody ambulance no matter how many phobias he has about hospitals (he broke it in two places, got a massive plate put in, now complains about not being able to walk for a few months), played lots of Eve Online, discovered Empire: Total War ran for a maximum of 40mins before crashing (Asus MBs suck even if great to overclock), wrote three chapters in a semi-serious attempt to write a funny fantasy novel for fun, avoided being drunk for three months straight much to the horror of the locals (It’s a stereotype, but many Irish really do drink way too much), reinstalled Vista after the SP2 update fucked up, witnessed the return of a real Summer to Ireland for the first time in 3 years, realised that 3 years of little sun left me inexperienced with its effects and spent a week with both arms itching like crazy and covered in tiony blisters (stupid, stupid ), had my cat train me not to leave any windows open since he excels at unwanted infiltration, learned the redundancy toll at my previous employer was up to 15% of staff (happy I got out earlier), became reacquainted with the frequent headaches my sensitive eyes induce when exposed to the sun (I almost forgot it was up there for the past few years), …

Enough of that.

Being in a more stable point in this god awful recession, I’m edging back onto the PHP scene. My last post quickly became a total washout with my best intentions failing so miserably it was pathetic. What can I say? Recessions suck. Hospitals suck. Dads who break their legs every year especially suck (the leg breaking, not the person ).

To recapture some of my excitied and sorely disappointed readers, I’ll get those two ZF book chapters up shortly and get cracking on more. I’m actually on a few weeks of freedom so no excuses. If someone breaks a leg next week I may have a breakdown.

My profuse apologies for the misleading post in April – obviously since it’s now June it’s been a turbulant few months since it was posted.

Filling in the blanks over my absence .

Effective from today, I am a free agent. Free of the binds of employment that is. Well, until I find another position… Welcome to redundancy…meh. On the flip side, it was expected pretty much as it happened and I get a surprisingly generous redundancy payment out of it – which was not expected but much appreciated. As for expectations, I preempted the whole redundancy thing since I saw it coming given the activity in the market. So I’m in an entirely unsurprising predicament I have planned for.

As I suggested in the past couple of months, I am scouting for new work but the slow economy which was probably just blown apart by the new Irish Budget (increase taxes since nobody at Government level is able to reduce costs effectively…bunch of worthless gits) only emphasised by the amount of money I saved buying some items across the border at the weekend (Ireland raises VAT, UK…decreases VAT…and Sterling rates are really good right now – hillarious) is just that – slow. Apparently a CV is now taking several weeks to reach the interview shortlist so it’s become a mind numbing exercise in patience. I’m quite patience, but I can’t avoid getting a bit bored with sitting at home and I’m not looking forward to it that much.

Nevertheless, my hopes are high that a good job is around the corner and I have been in discussions with some contacts, and my weirdly niche skillset (programmer, financial specialist, etc. with lots of nice abbreviations after my name) simply requires that I show a bit of patience until a suitable opportunity appears – which is inevitable since my niche area is actually fairly solid even in the midst of a depression. The redundancy was over other areas of the sector underperforming, and other people needing to…well…borrow my work to keep themselves busy. I don’t begrudge them – and I won’t be there to see the mess they have already started to create plugging my specialist role .

Playing the waiting game is something I’m good at – I have practically zero stress levels which is one part of my personality makeup I rather enjoy. Nervous at interviews? Piffle. Insecure in my abilities? Laughable. Hatez my job? I love my line of work – I’m good at it, I enjoy it, and I get paid extremely well for it.

But God, is job hunting slow this year! I’ve already heard of colleagues turning down jobs merely because the salary expectations have decreased so substantially. Some people just can’t take the hint to be more conservative in salary bases. Has nobody realised we are in a recession, and it’s time to accept a “hit” for a few years until the upswing (and our chances for career advancement) are improved? A stable job in a recession is not something to get all depressed and about because it pays 5k less than you expected – wake the fuck up! You’d swear the nation never had a recession before! I remember the 80s and 90s – especially the 80s since my Dad was seriously struggling in those days and it left an impression in my childhood memories.

In any case, this is why I’ve been largely offline the past few weeks – too busy wrapping up outstanding private projects, getting my CV nailed down, holding the usual pep talk meetings where recruiters swear blind to be your best friend (they are suffering too from the slow job market), working my contacts, and tracking down rumours of possible top-secret jobs not being openly advertised. I estimate at least a month until I am secured in a new office with a team of overly eager underlings (er…highly skilled professionals) to bend to my will (ahem…motivate, train and supervise). I could grab something short term, but I’d prefer to dig around for something and take a breather for a few weeks.

The downside is, obviously, weeks of freedom. I’m going to get pretty bored very fast, but should make more headway on the ZF book after this minor side adventure. Usually I’d scout around and grab a short term contract with a side dish of consulting, but I feel like enjoying my unemployed state for a few weeks to recharge and work up some enthusiasm for my next position. That I can afford to do so is frightening, but I have been lucky in that I escaped the equity market long before it seriously collapsed putting me in the weird position of waiting for the markets to recover so I can enter the market again and make a modest sum. I’m usually not egotistical (lies! lies!), but I saw it coming when the housing markets here in Ireland started to falter. Anyone curious can look at a graph of the ISEQ Index and fall down laughing at how it performed.

I think I fell off topic somewhere? Oh well, been a while since I blogged so endure the long post . If you feel like offering moral support, send a large ISK donation to “Maugrim McFiriba” in Eve Online – I’ll need more ships to pass the time in Eve I think . I’ve been enjoying the game for a while now, and it’s a nice diversion when the writing peters off and I’m not in the mood for relaxing with a good book.

Disclaimer: This entry offers a personal political opinion on the current state of the economy of Ireland under the incompetent leadership of Brian Cowen and Brian Lenihan. Sourced from a post on politics.ie.

COWEN IS MY SHEPHERD, I SHALL NOT WORK.

HE LEADETH ME BESIDE STILL FACTORIES.

HE RESTORETH MY FAITH IN THE FINE GAEL.

HE GUIDETH ME TO THE PATH OF UNEMPLOYMENT.

YEA, THOUGH I WAIT FOR MY DOLE,

I OWN THE BANK THAT REFUSES ME.

COWEN HAS ANOINTED MY INCOME WITH TAXES,

MY EXPENSES RUNNETH OVER MY INCOME,

SURELY, POVERTY AND HARD LIVING WILL FOLLOW ME ALL THE DAYS OF HIS
TERM.

FROM HENCE FORTH WE WILL LIVE ALL THE DAYS OF OUR LIVES IN A RENTED
HOME WITH AN OVERSEAS LANDLORD.

I AM GLAD I AM IRISH,

I AM GLAD THAT I AM FREE.

BUT I WISH I WAS A DOG

AND COWEN WAS A TREE.

In my last post I touched on the topic of multiple assertions in a unit test and linked it somewhat harshly to being a factor in “lazy” or shallow testing. I actually didn’t intend on linking them at all, but the truth is that unit testing isn’t a series of mutually exclusive practices – they are all linked to varying degrees. I’m sure I have at least a degree of laziness myself in testing .

The Basic Idea

As a recap, the idea is that every unit test should only have one single assertion. It’s a fairly well known method to combat a range of problems evident in assertion loaded tests where the numerous assertions obscure the meaning of the test, and where a failed test does not tell you the specific assertions which failed (since tests traditionally fail after any assertion failure, the remaining assertions are never executed thus leaving you blind to whether they would have passed or failed). There are other problems with the approach as well – which is why I do not like seeing multiple assertions in a single test. I’m not the only one – I think. And just as there are problems, there are also exceptions when multiple assertions might prove necessary – personally I think this scenario is pretty rare however. After my years of unit testing, I certainly have not encountered all that many.

These effects by themselves make me fairly comfortable in enforcing Single Assertions in tests as a rule, not a guideline. Guidelines are broken easily, but with rules you can at least strike back and make certain you don’t run aground on someone else’s inexperience or ill fated experiments in making testing “easier”. It’s also extremely easy to detect . PHPUnit, for example, reports the number of both tests and assertions executed – so you can calculate a quick ratio of assertions to tests in mere seconds. I’m going to start calling it the Obscurity Ratio! Obviously, a ratio of 1:1 would be perfect – but I’m sure we can accept some multiple assertions within a tolerance level. A ratio of more than 1.1:1 would indicate creeping obscurity (a signal it’s time for me to intervene, refactor, and do some mutation testing for extra assurance). A ratio of 2:1 indicates a lost cause. Anything higher and God help you all.

This Sounds Like A Bad Idea!

In watching the reactions to my original post (and not just the comments here), I’ve noticed that the excuses are generally similar. People have leaned towards justifying using multiple assertions for complex return values, or pointed out that my example was too simple (since that really really shows its a Bad Idea™ ), or that all the mini-tests would take too long to write, and even longer to execute, or that the world will end since Peter Petrelli thinks this is all a Bad Idea™ and everyone knows Sylar invented it anyway.

Not to completely oppose all the opinions (it really was a simple example), but people are spending too much time looking at the end result, and not enough at the process behind it all. And it’s by missing the process that you are missing the point.

Now let me disclaim a little – I’m really really sure there are times multiple assertions are needed. So my main point is not that this is an absolute rule with no possible exceptions so help me God, rather that it should be a rule unless you are literally forced to tackle an exception to it.

Why It’s A Good Idea…

Unit Testing has various interpretations. It’s original genesis promoted the verification of source code, a means of making sure code worked. It was not long before the obvious flaws in that thinking emerged – how do you verify the verified? You already know the code works before you write the test, so what value does it really bring to the table? Does it really promote code quality and rapid development – or just create a horrible task some low ranking developer will be landed with?

This sparked a revolution – Test Driven Design (TDD). In TDD, tests stepped back from verifying, and entered a role as specifications. Before you wrote the source code, you first wrote a test which specified the behaviour you intended on adding. Once you had the behaviour specified, you then wrote just enough source code to make that test pass. The result was a process of simple steps – and here’s where I diverge from others. A simple example works – because all half decent source code is nothing more than an amalgamation of simple examples – in fact, I dare anyone to prove otherwise. Then I can show you the PHP manual and you can explain how the hell you made PHP that complex .

In TDD we back away from testing complex highly involved code after the fact (too late then!), to preemptively writing tests to produce simpler straightforward code produced in steps. Simpler is better – always. The differences can be startling. Try writing two identical libraries both ways and you’ll see how.

It’s this notion of complexity that is often used to justify multiple assertions – if you break it down into the simple components that that complexity was built out of, multiple assertions don’t have a leg to stand on (just the rare instances out of your control because they absolutely must be done). The most common (just to preempt you all) scenarios for complexity in testing assertions boil down to BIG stuff – deeply nested stuff. Arrays and XML are the most common ones. Mathematical equations for relativity are simpler than those!

But let’s pass on through to the other benefits instead of obsessing over just one.

If your tests double as your specification to describe how a class should behave (and yes, I’m robbing the definition list in Behaviour-Driven Development, or BDD, blind) or documentation – you’re doing nothing wrong. Tests should document behaviour. This is why test method names are important – they summarise the behaviour the test is verifying.

Now add another little rule: every test only verifies one single behaviour. When we make that connection we realise something even more startling…

1 Behaviour == 1 Assertion

Now we’re into the meat of my madness, the gritty reality of the one assertion per test rule. Any behaviour is, by its very nature, both specific and unique. It does not require multiple assertions. Either it does one single thing, or it doesn’t do it at all. It’s black and white. The only danger is that you get so smart, you think in terms of big behaviours which are really just lots of little behaviours bundled together. Enjoy applying TDD in that case…it will sink you faster than you can say “Peter Petrelli Is Depressing” and you’ll end up back in the land of writing tests AFTER the code. Anyone going to admit to doing that? We all know who we are (yes, I do it too now and again).

That’s why Test-Driven Design is so effective. It enforces a habit (once you actually understand the damn practice which is almost designed to hide the behaviour facet!) of specifying class behaviour by behaviour, assertion by assertion. It breaks down the complex overall purpose of any class into discrete simple steps, a series of tiny goals you can easily achieve.

Simple, tiny, discrete – like individual assertions. It’s THAT simple.

That’s why the one assertion per test is a good idea – because it’s obvious in TDD. It’s what works, and it ensures your tests do exactly what they’re suppossed to be doing – verifying discrete behaviour, and documenting that behaviour to make other developer’s lives a bit easier (and saner).

The Spontaneous Test Population Explosion Myth

This is the one myth everyone knows targets the one assertion per test rule. The question is whether it’s a myth, or whether something else is. The idea is that by requiring one assertion per test, you end up with more tests, more code, higher execution times, etc. Which is to say…more behaviours. Which is to say – where the hell did the new behaviours come from?

Unwittingly, the excuse reveals itself to be the myth. If you have tests, and they can survive as multiple tests – you pretty much admitted your original tests were collections of behaviours. Welcome to the land of Obscure Tests – they test many things, and nobody can figure out just what.

Tests are documentation. Like any form of writing, you can block together ideas into a monologue or use properly formatted paragraphs and bullet points to break things down into a more digestable form for reading. It comes with a cost, but discrete tests are more helpful as documentation.

As for execution times, I really don’t understand why people find this a problem. PHPUnit let’s you run any test class in isolation, and you can group test suites in any shape or form. If your tests are running slow, treat them like any other code – use XDebug to locate the bottlenecks and slow tests and do something about them. Use more efficient code, refactor them to hell and back, isolate the slow tests – we can all do performance optimisation.

The other alternative is to let tests run in the background and use a notification system to report failures while you go away and write another test or two. I do this myself – see what notification apps you can hook into from PHP or some other test enviroment tool. I had working Snarl code for a PHP extension working under Windows somewhere if you can use a compiler and really need it.

Attitude Counts

Another compelling reason to adopt one assertion per test is your ego. Look at me – I have an ego, I write stuff because I enjoy doing it and am motivated by other people reading it and thinking it’s the best thing ever written . We all have egos. My ego has me writing free books (though the prospect of a new Macbook Pro is another motive…hehehe).

Unfortunately our ego is also a major enemy in unit testing. If you find yourself saying you prefer multiple assertions because it works for you, and you can understand them, and they make perfect sense to you, and hey, your code works with 200% code coverage – then count how many “you” words you just used (or “I” if writing first person!).

It’s not about you!

Other developers have to read your tests eventually, unless it’s a top secret project only you will ever work on. Don’t saddle the rest of the world with the product of your ego. Everyone finds simpler tests easier to work with. The general rule of thumb is pretty simple – if you give someone a copy of your tests, and nothing else, could they ever write the code to fit those tests in a reasonable time from scratch without begging you for assistance?

Conclusion

More food for thought . No pretty code to look at for this one so if you haven’t read the last post yet, go read it now.

Until next time…when I find something else to moan about.

Continued from Part 3…

Let’s make two more changes to complete the process. Here’s the new Controller from earlier where we set the tag “entries” on any Actions where blog entries are displayed or listed.

[geshi lang=php]

class EntryController extends Zend_Controller_Action
{

public function init()
{
$this->_helper->cache(array(‘index’), array(‘tag1′,’entries’,'tag3′));
$this->_helper->cache->useCleaner(‘entry’, array(‘process’,'delete’));
}

public function indexAction()
{
// show some entries, page should be cached
}

public function processAction()
{

// store the blog entry by whatever means necessary
}

public function deleteAction()
{
// delete one or more entries
}

}[/geshi]

Based on the tags being used, we can now simplify our previously nightmarish Cleaner to a single line!

[geshi lang=php]

class ZFExt_Cache_Cleaner_Abstract
{

protected $_cache = null;

public function __construct()
{
// Needing the Action Helper here may suggest the need to extract the
// functionality common to Helpers and Cleaners into it's own
// class for sharing
// Being an article, let's skip the obvious refactoring need before this
// becomes another book...
if (Zend_Controller_Action_HelperBroker::hasHelper('cache')) {
$this->_cache = Zend_Controller_Action_HelperBroker::getExistingHelper(‘cache’);
}
$this->_cache = Zend_Controller_Action_HelperBroker::getStaticHelper(‘cache’);
}

}

class EntryCleaner extends ZFExt_Cache_Cleaner_Abstract
{

public function afterProcess()
{
$this->_cache->removeTaggedPageCache(array(‘entries’));
}

public function afterDelete()
{
$this->_cache->removeTaggedPageCache(array(‘entries’));
}

}[/geshi]

I think we’ll stop here for now!

Conclusion

Over the last three (well, four if you count I ran out of space on Part 2 and needed a 2b ) parts of this weekend series I’ve covered page caching with a focus on caching output to static HTML files to offload work from Apache and PHP.

This caching strategy allows the webserver to avoid PHP completely, or alternatively for a frontend nginx/lighty reverse proxy to avoid Apache completely. Either way, it results in a very fast and efficient caching mechanism for entire pages which can be linked to Tags and Cleaners so they are updated only when the data they were originally generated from has changed.

It should be noted that while static HTML caching is one of the fastest possible caching mechanisms, it is not the most flexible. It is best suited to standalone, or small 2-3 unit scaled solutions, where filesystem operations can be unified with a frontend HTTP server. Trying to sync this style of caching across servers is to be avoided. It is also not suitable for highly dynamic pages which continually update or are specific to each visitor. In these cases the more expensive caching methods are often needed, though if the dynamic portions are small enough it might be worth delegating the generation of those dynamic portions to AJAX requests from the statically cached page, so that at least the bulk of any page is cached.

Additionally, once you do reach the point where static caching cannot be used, you should of course examine other caching options across the parts of the application impacted. Remember that you can cache database results, individual template output (even partials), CPU or memory intensive operations, etc.

In closing, I hope this series has offered a few good ideas .

Continuing from Part 2!

Check out the direct() and preDispatch() methods – using these we can setup what to cache, start caching, and all without needing regular expressions since our Static backend is driven by the current REQUEST URI.

Given all the above changes, it’s no surprise the Static Backend has had a few updates!

[geshi lang=php]

class ZFExt_Cache_Backend_Static extends Zend_Cache_Backend implements Zend_Cache_Backend_Interface
{

const DEBUG_HEADER = 'DEBUG HEADER : This is a cached page !';

// Available options
protected $_options = array(
'public_dir' => null,
‘file_extension’ => ‘.html’,
‘index_filename’ => ‘index’,
‘file_locking’ => true,
‘cache_file_umask’ => 0600,
‘debug_header’ => false
);

// Test if a cache is available for the given id and (if yes) return it
// (false else)
// $id should be the REQUEST_URI whose static file is to be deleted
public function load($id, $doNotTestCacheValidity = false)
{
$id = $this->_decodeId($id);
if (empty($id) || $id == ‘_’) {
$id = $this->_detectId();
}
if (!$this->_verifyPath($id)) {
Zend_Cache::throwException(‘Invalid cache id: does not match expected public_dir path’);
}
if ($doNotTestCacheValidity) {
$this->_log(“ZFExt_Cache_Backend_Static::load() : \$doNotTestCacheValidity=true is unsupported by the Static backend”);
}
$fileName = basename($id);
if (empty($fileName)) {
$fileName = $this->_options['index_filename'];
}
$pathName = $this->_options['public_dir'] . dirname($id);
$file = $pathName . ‘/’ . $fileName . $this->_options['file_extension'];
if (file_exists($file)) {
$content = file_get_contents($file);
// move debug header to Frontend to prevent these gymnastics
return str_replace(self::DEBUG_HEADER, ”, $content);
}
return false;
}

// Test if a cache is available or not
// $id should be the REQUEST_URI whose static file is to be deleted
public function test($id)
{
$id = $this->_decodeId($id);
if (!$this->_verifyPath($id)) {
Zend_Cache::throwException(‘Invalid cache id: does not match expected public_dir path’);
}
$fileName = basename($id);
if (empty($fileName)) {
$fileName = $this->_options['index_filename'];
}
$pathName = $this->_options['public_dir'] . dirname($id);
$file = $pathName . ‘/’ . $fileName . $this->_options['file_extension'];
if (file_exists($file)) {
return true;
}
return false;
}

// Save content to a static content file in /public directory
// Note: We’re ignoring the ID as its not required.
public function save($data, $id, $tags = array(), $specificLifetime = false)
{
clearstatcache();
$requestUri = $this->_detectId();
$fileName = basename($requestUri);
if (empty($fileName)) {
$fileName = $this->_options['index_filename'];
}
$pathName = $this->_options['public_dir'] . dirname($requestUri);
if (!file_exists($pathName)) {
mkdir($pathName, $this->_options['cache_file_umask'], true);
}
if ($id !== ‘_’) { // empty ID since a Capture
$dataUnserialized = unserialize($data);
} else {
$dataUnserialized = array();
$dataUnserialized['data'] = $data;
}
if ($this->_options['debug_header']) {
$dataUnserialized['data'] =
self::DEBUG_HEADER . $dataUnserialized['data'];
}
$file = $pathName . ‘/’ . $fileName . $this->_options['file_extension'];
if ($this->_options['file_locking']) {
$result = file_put_contents($file, $dataUnserialized['data'], LOCK_EX);
} else {
$result = file_put_contents($file, $dataUnserialized['data']);
}
@chmod($file, $this->_options['cache_file_umask']);
if (count($tags) > 0) {
$this->_log(self::TAGS_UNSUPPORTED_BY_SAVE_OF_STATIC_BACKEND);
}
return (bool) $result;
}

// Remove a cache record
// $id should be the REQUEST_URI whose static file is to be deleted
public function remove($id)
{
$id = $this->_decodeId($id);
if (!$this->_verifyPath($id)) {
Zend_Cache::throwException(‘Invalid cache id: does not match expected public_dir path’);
}
$fileName = basename($id);
if (empty($fileName)) {
$fileName = $this->_options['index_filename'];
}
$pathName = $this->_options['public_dir'] . dirname($id);
$file = $pathName . ‘/’ . $fileName . $this->_options['file_extension'];
if (!file_exists($file)) {
return true;
}
return unlink($file);
}

// Remove a cache record recursively (i.e. the file AND matching directory)
// it ain’t perfect – there may be no file matching the directory name
// (but you get the point I’m sure!)
// $id should be the REQUEST_URI whose static file & dir tree is to be deleted
public function removeRecursively($id)
{
$id = $this->_decodeId($id);
if (!$this->_verifyPath($id)) {
Zend_Cache::throwException(‘Invalid cache id: does not match expected public_dir path’);
}
$fileName = basename($id);
if (empty($fileName)) {
$fileName = $this->_options['index_filename'];
}
$pathName = $this->_options['public_dir'] . dirname($id);
$file = $pathName . ‘/’ . $fileName . $this->_options['file_extension'];
$directory = $pathName . ‘/’ . $fileName;
if (file_exists($directory)) {
if (!is_writable($directory)) {
return false;
}
foreach (new DirectoryIterator($directory) as $file) {
if (true === $file->isFile()) {
if (false === unlink($file->getPathName())) {
return false;
}
}
}
rmdir(dirname($path));
}
if (file_exists($file)) {
if (!is_writable($file)) {
return false;
}
return unlink($file);
}
}

// Clean some cache records
// Not implemented here since we would need a backend tagging system given
// that static files themselves cannot be tagged in the filename.
public function clean($mode = Zend_Cache::CLEANING_MODE_ALL, $tags = array())
{
switch ($mode) {
case Zend_Cache::CLEANING_MODE_ALL:
case Zend_Cache::CLEANING_MODE_OLD:
case Zend_Cache::CLEANING_MODE_MATCHING_TAG:
case Zend_Cache::CLEANING_MODE_NOT_MATCHING_TAG:
case Zend_Cache::CLEANING_MODE_MATCHING_ANY_TAG:
$this->_log(“ZFExt_Cache_Backend_Static : Cleaning Modes Currently Unsupported By This Backend”);
break;
default:
Zend_Cache::throwException(‘Invalid mode for clean() method’);
break;
}
}

// Encoded by ZFExt_Cache_Backend_Static_Adapter
protected function _decodeId($id)
{
// another workaround since Zend_Cache_Core prevents
// empty or null IDs which we’ll have when Capturing
// and before the REQUEST_URI is checked
if ($id == ‘_’) {
return ”;
}
return pack(‘H*’, $id);
}

// “Danger, Will Robinson!”
// Sanity check to ascertain whether path is within the configured
// public_dir path
protected function _verifyPath($path)
{
$path = realpath($path);
$base = realpath($this->_options['public_dir']);
return strncmp($path, $base, strlen($base)) !== 0;
}

protected function _detectId()
{
// should strip query strings in future
// along with other fragments
return $_SERVER['REQUEST_URI'];
}

}[/geshi]

Two more source code listings remain – here’s the revised Bootstrap fragment:

[geshi lang=php]class ZFExt_Bootstrap
{

// …

public function run()
{
$this->setupEnvironment();
// Implement Page Caching at Bootstrap level before any
// MVC operations so these operations can be completely
// avoided when a valid cache exists
$this->usePageCache();
// If a valid cache exists, execution exits!
$this->prepare();
$response = self::$frontController->dispatch();
$this->sendResponse($response);
}

public function usePageCache()
{
$frontend = new ZFExt_Cache_Frontend_Capture();
$backendOptions = array(
‘debug_header’ => true,
‘public_dir’ => self::$root . ‘/public’
);
$backend = new ZFExt_Cache_Backend_Static($backendOptions);
// use our Adapter to deal with the Core’s private validation
$cache = new ZFExt_Cache_Backend_Static_Adapter(
Zend_Cache::factory($frontend, $backend)
);
// Add the new cache to the Cache Control Action Helper
Zend_Controller_Action_HelperBroker::addPrefix(‘ZFExt_Controller_Action_Helper’);
Zend_Controller_Action_HelperBroker::getStaticHelper(‘Cache’)->addCache(‘page’, $cache);
// Assume all caching initiated by Controllers (need to detect OB otherwise)
}
}[/geshi]

After all of that…our Controller has morphed into the following:

[geshi lang=php]

class EntryController extends Zend_Controller_Action
{

public function init()
{
$this->_helper->cache(array(‘index’));
$this->_helper->cache->useCleaner(‘entry’, array(‘process’,'delete’));
}

public function indexAction()
{
// show some entries, page should be cached
}

public function processAction()
{
// store the blog entry by whatever means necessary
}

public function deleteAction()
{
// delete one or more entries
}

}[/geshi]

Conclusion

Part 3 will start to address some of the weakness in the system so far (like track who has cached what and where ), but for now the system, in its prototype format, is operational. We can now statically cache HTML output on the fly from our controllers and implement Cleaners to clear that cache as actions dictate. We’ve even established the beginnings of a cache management system which favours Controller based instructions over regular expression url definitions. It’s still not fluid enough to be configurable, but we’re very close to that level.

Part 3 tomorrow!

Thanks to Rob Allen, I’ve been tagged in this chained blog posting phenomenon so here’s my 7×7 to preserve my good fortunes for this coming year and stave off bankruptcy or whatever could happen if I don’t .

Seven random/weird things about me:

- I don’t have a formal Computer Science degree, in fact I studied Commerce originally (Honors!) and Computer Science as a sideline.
- My first programming experience was copying BASIC code from adventure books typed into a Commodore 64k a few centuries ago. I still have the Commodore – and it’s still operational!
- My first frequent activity on a real PC was playing Duke Nukem 3D.
- My most recent physical defect is a scarcity of hair which started during 2008. I blame Dad. I hear he blames his Dad. Pretty sure that goes back a ways .
- I write sci-fi/fantasy short stories in some of my free time.
- Contrary to the Irish stereotype, I am not frequently intoxicated as some have suggested. That’s just a vile rumour with absolutely no concrete evidence anyone who wishes to continue living can produce.
- I first learned PHP to contribute to a game called Solar Empire in 1998.

To avenge my own tagging, I’m taking out my ire on the following victims:

- Travis Swicegood since he wrote the first published GIT book and made me pay cash to read it
- Jurrien Stutterheim for volunteering to assist developing Zend_Feed_Reader (no good deed goes unpunished!)
- Tobias Gies for smugly pointing out spelling errors on my new online book!
- Bill Karwin whose contributions to Phing power the Docbook automation of the book
- Thomas Weidner who lets me safely use Gaelic characters in my ZF applications and insulate us all from the Anglic hordes.
- Jani Hartikainen since he said nice things on Twitter, and that surely can’t pass without punishment!
- D.J. Capelis who I just reconnected with over Twitter – been years since we were active members of the old Solar Empire browser game developer community.

The rules according to Mr. Allen:

* Link your original tagger(s), and list these rules on your blog.
* Share seven facts about yourself in the post – some random, some wierd.
* Tag seven people at the end of your post by leaving their names and the links to their blogs.
* Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

Many twists and turns have been encountered since the Summer, but the online version of Zend Framework: Surviving The Deep End has escaped into the wild with the release of Chapter 1. The online book is hosted at http://www.survivethedeepend.com.

Chapter 1, the Introduction, is first on the menu to open the new year. The next chapter should turn up within a few days and then we’ll see about scheduling regular chapter releases. It should be noted the new website is still a work in progress and I have a few features in testing to bring it to completion and fix some final design wishes I had, but the main feature I’m pleased to have added is an inline comment system. You may now comment on (or complain about) each paragraph individually using the jQuery powered comment system. Every paragraph has an unobstrusive link next to it showing the current number of comments for that paragraph – clicking the link shows all existing comments for that paragraph and a comment form to add another.

As many of you know, the book is available online without charge. If you are feeling generous in the coming weeks I am accepting donations. I promise that Steve Jobs will appreciate the gesture when I buy that new Macbook Pro . Obviously a chunk of any donations will also vanish into the coffers of Slicehost.com where the book is being hosted on their excellent VPS offering.

Let me know your thoughts, and post any general comments or questions on the book or website here. I’ll be adding a general end-of-page comment system to the mix during the next day or two so posting general comments here is a temporary stopgap.

Huge thanks to all my readers and PHP acquaintances who kept me motivated .