Less is More

(or how I stopped blindly including shit in my composer.json)

I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I’ve had a terrible day and I’m hoping that the process of just getting this off my chest will be therapeutic in some way.

It started with a hydrator…

At work here at AdSpruce I’ve finally managed to start coding some, at least for part of our week. Our JavaScript SDK has scaled beyond our wildest dreams,  and we hit a daily high this week with just under 10m SDKs delivered. Obviously, this raises problems of scale, and we’ve finally cleared a decent chunk of time to re-write and refactor our SDK with scalability, maintainability and responsiveness in mind. This should go down as a big win.

So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker. “No problem”, I thought. I’ve used Zend Framework 2 a lot (and as an aside, I’m now a ZFCA – woo hoo!), Zend\StdLib includes a set of hydrators that are specifically designed to cleanly solve this problem.

A quick look on packagist tells me that this component has no dependencies on any other component inside or outside of ZF2. That’s a win for reusable code, so I added it to my composer.json.

But wait!

Running my tests gave an unexpected error: Test Error It appears that Zend\StdLib\Hydrator\ClassMethods (at least) has an undeclared dependency on Zend\Filter. A quick conversation in IRC later and I find it also has an undeclared dependency on Zend\ServiceManager.

At this point I feel I should apologise to Marco – having a very bad morning is no excuse for being a fuckwit in IRC and rage-quitting when your opinions are questioned.

I also want to make it clear that my beef here isn’t with the undeclared dependencies in this component, that can be easily fixed and then the choice on whether to use it or not can be an informed one. My concern is over the number of people who would willingly and happily add the extra dependencies to their project in order to use this component. Zend\ServiceManager is currently 2,511 lines of code, and Zend\Filter is 7,351 lines of code. As far as I can tell (and don’t quote me here please, its a token guess based on 10 seconds of looking at code), the hydrator only needs the Word filters which are around 100 lines of code. So, using my amazing rounding techniques to make something look simpler that it is, by my maths, Zend\StdLib\Hydrator\ClassMethods imports 10,000 lines of code to make use of 100 lines. That’s 1% of the lines of code imported that are actually needed.

Yeah Yeah

So, this is where the contention happens. I can almost feel the overwhelming weight of apathy barrelling towards me as the literally tens of people reading this blog shrug in indifference. And that’s fine.

“Disk space isn’t a problem any more”

“So what?”

“You are a stupid idiot”

These are just some of the  responses that I’ve got when moaning about this on IRC and on Twitter, and that’s perfectly fine. If you’re happy to let Composer pull in many and unknown dependencies so that you can use one or two classes out of the hundreds it installs, that’s completely fine. It’s your project after all. But I’m actually starting to sway away from this unchecked use of Composer.

Simplify All The Things

Around a year ago I first came across Ed Finkler‘s MicroPHP Manifesto. Of course, being a big advocate of the Zend Framework I immediately discounted it. But over the intervening months I’ve started to move further and further away from the full stack framework in some cases.

Of course, for some cases full stack is still my prefered framework of choice. Our client and admin back-end still leverages the power of ZF2; for one it makes user entry with Zend\Form (among other components) much, much easier. But when we rebuilt version 1.5 of our SDK, and now, with the forthcoming version 2 I want some of our sites to be as lean and lightweight as possible. This is where I am starting to really buy into the less-is-more ideals laid out so succinctly in the MicroPHP Manifesto.

I don’t want to have to maintain several packages for the sake of a small amount of code that I actually use in my project. I don’t want to have to worry about what versions of packages I’m running on my server or what versions of components are being pulled in as dependencies of my dependencies. And I don’t feel that this is a trivial as some others do. I don’t have the time to keep up with the changelog of all the components I have blindly installed to check if there are security fixes and I should update.

Composer Isn’t The Problem

Some people on Twitter saw my rant and wrongly interpreted it as a rant against Composer. It’s not. Composer is an awesome tool that in my mind has been responsible for a renaissance in PHP in the last 18 months. Composer has been the tool that has allowed me to blindly pull in multiple dependencies, but it’s not Composers fault. It’s my fault and the fault of the all the developers who have encouraged a community of thoughtlessly including code in projects.

So there it is.

The rambling rant of an annoyed man. In future, I’ll be thinking long and hard before including any dependencies in my composer.json, and I think you should to.

FIN

ZF2 for the ZF1 Developer – The Webinar

I know lots of people have been waiting a long time for Part 3 of this series, I can only apologies for the delay, and hope that this post somehow makes up for the wait!

In February I gave a talk on behalf of Zend which compiled parts one and two of this series, plus the non-written part
three into a spoken talk that included code examples. The video is included here for all your viewing pleasure:

Continue reading

ZendOAuth2Client maybe?

Recently I’ve been working a lot on trying to get OAuth2 support into beta 4 of Zend Framework 2, and there were a few challenges. Allowing the client to consume the variety of  providers out there proved to be the first.  There have been several drafts of the OAuth2 specification, and providers have implemented a variety of the drafts. As each of the drafts have subtle differences, the client needs to be able to have a default configuration that can be over-ridden on a per-provider basis.

Continue reading