RJHarrison.org

just read a post by Michael Kismal about PHP certification and it hit me that taking the Zend Certification in 2006 was actually one of those pivotal moments in my life - A real “butterfly flaps its wings and causes a storm” thing.

I took the exam back then because I felt my CV was weak (having really just worked on my own projects/startup before then). Shortly afterwards, I got a job with a small UK firm (Llama Digital), where I worked with a developer named Anto Heley. The ZCE was definitely something Llama were interested in and I’ve no doubts that it helped me get the job. Whilst there, I also worked alongside the guys from Sugarcane Studio (who later go on to do my branding for Pluggable).

After 6 months at Llama I got poached by “Zend UK” (who merged with iBuildings.nl last year). They tapped me up through the ZCE Yellow Pages - a direct result of me taking the certification. I moved to London and started going to PHPLondon meets and met a bunch of really cool PHP people, including Paul Morgan who organised this year’s PHPConference.co.uk. Through the job I met and worked with some interesting/high-profile people and clients.

After 6 months at Zend UK (september ‘07) I left to start up Pluggable. Around that time, my old colleague Anto got in touch to say he’d moved jobs and his new employer needed some PHP help, and they became my first Pluggable client; a few more months after that, a company I worked with whilst at Zend UK became my second Pluggable client. These two relationships have since become the biggest % of my work in the last 6 months, and the work for one of them inspired my article for PHP Architect.

At PHPConference.co.uk, I volunteered to help out Paul, and also managed to do a little branding stunt by exchanging elePHPants for business cards, which helped me make me a few more contacts, friends and hopefully clients. I had also suggested the “PHP Framework Throwdown” talk to Paul and he asked me to chair the discussion: that led to me blagging along a spot to the speakers’ dinner and having the pleasure of meeting some “Famous PHP People”.

So looking back over the last two years, all of my career paths, the cool PHP stuff I’ve done and people I’ve met can be traced back to a single causal event: taking the Zend Certification. I know this is a little bit cheesey but I honestly can’t imagine what my life today would be like had I not taken it - and I really like where I’m at right now.

$125 was money well spent

Yay me! I wrote an article for PHP Architect (http://phparch.com/c/magazine/issue/73)

A few months ago I had a problem that stream filters would solve nicely, but couldn’t find any examples online about how to write your own filters with PHP code. I hacked together a solution after digging around in the source code and doing some trial-and-error, and decided that it would be worthwhile to write up my experience.

The article started off as a blog post but then my ego got involved, “I reckon I could get this published in PHP Architect!”. A couple of emails with Steph Fox later and it was on; although my initial excitement was doused when I loaded my almost-finished blog post into Word to see how many words I’d written: a mere 1500 with the article requiring ~4,000. Ugh.

I was a surprised how much harder it was to write an article of that length compared to a quick’n'dirty blog post. There was also an interesting shift in how much I cared about the article. When you write for you own blog post, you’re really writing for yourself and answerable to yourself; but when you write for someone else’s publication it feels like there’s more responsibility - you’ve got to live up to their expectations/their readers’, and there’s a little bit more pressure on you not to cock it up. I felt relieved when it was over.

I’m glad I did it though. There’s definitely a feeling of achievement about “being published in a magazine” (even if it’s too obscure for Have I Got News For You); I’m a writer!

I experienced another funny emotion today when the article got published. It’s a weird mix of nervous embaressment, crossed with excitement. It’s like “Yay it got published…. oooooh noes! people are going read what I wrote! /cringe”.

As a fun thing to do overall, I’d recommend others to give it a go: unleash the power! Get your own 15 minutes of fame.

[Disclaimer: O'Reily sent me a copy of the book to review]

Programming Amazon Web Services (O’Reilly, March 2008) authored by James Murty.

This book provides a gentler and more accessible introduction to the Amazon web-services than the official documentation. It holds your hand and takes longer to explain some of the concepts and offers some “big picture” perspectives.
Five of the Amazon APIs are covered (S3, EC2, SQS, SimpleDB and FPS). Each API is broken down into a couple of “technical” chapters, followed by a chapter showcasing some real-world, example applications (both hypothetical and/or actual case studies).

You can (pretty much) read the book “out of sequence”, so you can jump to the EC2 section without learning about S3 first. This is important because there is a lot of information here, and I doubt many people will sit down and read it cover-to-cover. It’s more the type of book where you read about one API, go away and play with it, and then come back for another when needed.

The first thing that struct me is that the book deals exclusively with the REST/Query version of the APIs – there’s not a hint of SOAP in sight! I think this is a really good decision as it boils the web-services down into something all web-developers should be familiar with: HTTP requests and responses.

The example code is written in Ruby, and speaking as someone who has never written a single line of Ruby, I had no problems understanding it! Typically the examples involve building up an HTTP request and then parsing XML from the reponse – things that should be easily transferable into your language of choice.

Unfortunately, as is probably the case in many technical books, even though the book was recently published (March 2008) by April 2008 it had become outdated! Amazon have announced a number of new bits and pieces which are either missing from the book or that the book contradicts (like saying Amazon do not provide premium support, which they now do). Overall, this isn’t a big deal as the book covers the core concepts well, but it’s definitely worth checking Amazon for the latest functionality and API changes.

I came to the book familiar with a couple of Amazon’s services, but I still got value from it, particularly with the APIs I had not looked into. I would recommend this book for intermediate developers upwards, who are interested in any of the APIs that it covers.

Programming Amazon Web Services.

Zend just announced their bundling the Dojo javascript library with Zend Framework (http://andigutmans.blogspot.com/2008/05/dojo-and-zend-framework-partnership.html).

That’s the last nail in ZF’s coffin as far as I’m concerned. I used to be a ZF evangelist: I loved the way you could “pick and choose” components and I definitely viewed it as a “glue” framework. Over time, I’ve grown to hate using ZF’s Controller/Views, which for web apps is a big problem; I’ve stopped recommending it to people but I would still suggest they evaluate it. Now, I think I’d actually recommend against using it.

Why? Because I feel this is the wrong direction for a PHP framework to take. I think a server-side, PHP framework, is no place to bundle a client-side, Javascript library: I am totally missing the benefits that this is supposed to provide.

In my eyes, client-side “behaviour” (ie Javascript) is completely independent from the server-side. When I develop Javascript I mentally block out the backend and am focused on DOM and the UI; if I need to send AJAX requests I see blackboxes (URLs to get/post). Likewise, when I’m writing PHP I don’t even think about Javascript: my PHP runs some logic and (probably) builds some HTML to output: it doesn’t care about Javascript.

I can see ZF heading towards being a PRADO-style framework (based on .NET ideas). I totally wouldn’t be surprised if we start to see some sort of integration with Zend_View and Dojo - like adding onClick events to <elements> from within PHP, with the onClick callback being a PHP function, executed using JSON-RPC. I don’t understand this: if you want to write component-based, event-driven web apps that look like .NET, then why don’t you just use .NET in the first place?

Mixing the server-side and client-side is a bad idea in my opinion and it moves down the “let’s abstract HTTP” path. Mike Naberezny (and Paul Jones) published some thoughts about this a couple of years back (http://mikenaberezny.com/2006/04/26/request-response-or-bust/).

Also, this reeks of corporate interference. I might have this wrong, but don’t remember seeing the ZF community desperately calling for the bundling of a JS framework? Where was the debate over which JS library should be bundled? I think it’s a joke to read Andi say “this still needs to go through the proposal process -no shortcuts!”: the CTO of Zend just announced a partnership with SitePen/Dojo - he didn’t just announce new ZF proposal.

I’ll end on a comment, from the first paragraph of Andi Gutman’s announcement (the emphasis is mine):-

“This is mainly targeted at users who rely on us to provide them with a best practice and an out-of-the-box experience for Ajax and don’t want to have to deal with evaluating a solution“

Morons, then?

This evening I kicked off coding my new project (codename: April) which at its core is an HTTP Client library for PHP5.

Prior to starting writing code, I’ve done a fair bit of research into the other options that are out there, including analysing their source code to see how they do things. I don’t think I’ve ever looked at 3-4 different libraries side-by-side like this and compared in depth how they do essentially the same thing. It’s very interesting to see the different approaches the authors take as well as the bigger picture of their frameworks.

Of the libraries that I’m using for reference (Zend_Http_Client, Solar_Http, PEAR::HTTP_Request and PECL::HTTP) only Pecl::HTTP fully separates Request/Response/Client. The others take a 2-component approach and have a Response object plus either the Request built into the Client (Zend) or the Client built into the Request (PEAR & Solar). I personally think it’s important to separate each of the three components: the input, the output, and the bit in the middle to gain maximum flexibility and code reuse.

Another area I looked at today was how URLs are handled and validated (or not!). Solar and Zend both have URI objects and PEAR has Net_Url(2). Solar and PEAR both use parse_url(), PEAR validates the parts using regexes but Solar does no validation checking (using whatever parse_url() spits back). The Zend guys clearly don’t trust parse_url and their implementation has lots of regexes to split the URI and validate it. None of them use PHP’s Input Filter, which conveniently has sanitizing and filtering calls for URLs (it could be that it’s for URLs and not URIs).

That reminds me - I spent about an hour of my coding session researching and arguing with myself whether I should be using URL or URI terminology. My conclusion was I prefered URL (an URL specifies a location of the resource, which is implicit in an HTTP request); but also that URI was valid because in the context of an HTTP Client one should assume that the URI was a URL (there’s no way it could be a URN - just doesn’t make sense). Time well spent I think :-).

So, after lots of reading and thinking I wrote some test cases for April_Http_Request and put pen to paper to write her first function: setUrl() (and associated alias, setUri()). It took me 4hrs and it’s only one function but I think I’ve given it my fullest attention! I want this project to use the best bits from my reference libraries and I’m quite happy to spend time learning how they tick. I’m also going to use their tests (both Solar and Zend [and April] use PHPUnit) so my code should at least cover the same “gotchas” as they do. This worked amazingly well for testing my setUrl() method: I managed to reuse almost all the tests for Zend_Uri_Http and after a few failures I tweaked my code to pass - setUrl() is now covered by 25 or so tests (without me having to write them).

Fingers firmly crossed I can continue doing this, as that’s a lot of brainwork that I can reuse (under the New BSD license).

Of the current JS frameworks, I’m most familiar with Prototype.js. This is purely because it was the first one I tried out and is not due to a real preference.

I prototyped a current project using Prototype.js but have since learned that the client wishes to use jQuery as their base library. My work doesn’t extensively exploit Prototype.js (I tried to write as much agnostic code as possible) so I figured it’d be easy to port it to jQuery… and in the most part it has been!

However, jQuery doesn’t (so far as I can see) have the facility to pass the scope of a callback function, implicitly or otherwise. This is what Prototype.js’s “bind()” extension does: it binds the function to a given object.

var obj = {
    name : 'Richard'
}

var sayName = function(){
    alert(this.name);
}

var eg = sayName.bind(obj);
eg();

This example would alert “Richard”, because when sayName() is executed it’s bound to obj: it’s like calling obj.sayName();. This is REALLY useful when using callback functions - in my opinion it’s a necessary extension, otherwise you either scrap handling the callback scope or have to deal with passing two parameters (function, scope) for every callback.

So, as it’s something I can’t live without and because the client wants jQuery, I’ve extracted Prototype.js’s bind() extension into bind.js:-

/**
 * The "bind()" function extension from Prototype.js, extracted for general use
 *
 * @author Richard Harrison, http://www.pluggable.co.uk
 * @author Sam Stephenson (Modified from Prototype Javascript framework)
 * @license MIT-style license @see http://www.prototypejs.org/
 */
Function.prototype.bind = function(){
    // http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions:arguments
    var _$A = function(a){return Array.prototype.slice.call(a);}

    if(arguments.length < 2 && (typeof arguments[0] == “undefined”)) return this;

    var __method = this, args = _$A(arguments), object = args.shift();

    return function() {
      return __method.apply(object, args.concat(_$A(arguments)));
    }
}

This will now complement jQuery and allow me to continue using .bind() when passing functions around.

I’m writing this to justify a project to myself (sometimes I find it useful to put pen-to-paper and gather my thoughts). The comments also let anyone else feedback (please do).

Proposal (the what)

1. Write a generic “HTTP library” for PHP that would include,

a) HTTP_Request - represents a single HTTP request
b) HTTP_Response - represents a single HTTP response
c) HTTP_Client - a client that would be able to send HTTP_Request and receive back an HTTP_Response

2. Use this library as the foundation for implementations of REST (and REST-like) services to immediately include,

a) Amazon S3
b) Amazon EC2

(this scratches a personal itch but these APIs also lack implementations, particularly EC2)

3. Evaluate whether this could be the beginning of a “RESTful Implementation Library” for PHP.

This is my big picture: a central collection of API implementations all based on the same foundation (#1). This would be a little like a niche version of PEAR but for implementations of RESTful web services.

Motivation (the why)

1. Frameworks keep reinventing this wheel.

I don’t really care that frameworks reinvent wheels, except that in this case it causes a definite problem when it comes to the implementation of 3rd-party APIs.

If you’re writing an implementation of the S3 API, what do you use to represent the request, response and client? Do you use an existing framework, extension, or write your own code?

If you use a framework package (like Zend_HTTP_Client) then you tie your API implementation to that framework. This sucks; I did this recently and started coding adaptors for different frameworks: that’s so dumb, having to abstract frameworks to make my library work!

The other alternative is to handle it yourself: you write your own request/response/client bits - perhaps even bundling them into the one class (not uncommon). Some of this type of implementation requirire cURL, which as an extension, may not be available in every environment (and certainly as a developer it isn’t the most friendly interface to use).

When you end up with disparate implementations I think you’re asking for trouble. You’ve got a lot different code solving the same problem; they probably behave differently and code-quality / testing is a big concern.

The bottom line is that there isn’t a core foundation for writing implementations of RESTful web services.

2. I like the general idea of a “one-stop-shop” for PHP web-service implementations.

Firstly it would rock for providers of APIs / implementors: they have a foundation to write their own implementation, taking care of the boring HTTP stuff, as well as potentially exposure to an existing audience. If you ignore the HTTP stuff, most APIs are pretty simple to implement.

Secondly, it would rock for developers using the APIs. They’re assured that the quality and behaviour of the HTTP part is consistent and they have a single resource to grab lots of different API implementations.

3. It solves a secondary problem

I personally feel PHP lacks HTTP request/response objects for the “current request”.

A lot of the current frameworks have some implementation of request/response and I think it’s generally a good idea. For some small projects I just use these objects from a framework: I use their request object, do some processing on it, create a response object, and then evaluate the response object (send headers + content).

It’d be nice to have an option for this in a “non-big-framework” way.

4. It scratches a personal itch.

I’m currently implementing Amazon EC2+S3 APIs and I need this sort of basic functionality. As I was coding I thought “why don’t I make this more generic so that I can reuse for other APIs?

Yes I know - existing solutions exist

Please don’t flame me!

I’m aware of PEAR::HTTP_Request, PECL::HTTP and the numerous implementations in existing frameworks. In fact I really like the ones in Zend and Solar.

I’m a lazy developer and I’ve got no itention of writing something from scratch or learning the gotchas first-hand. I intend to use the existing implementations as inspiration (subject to their licenses, which may even mean blatent copying) and also to keep in line with expected usage.

So, thoughts?