Good software is 'orthogonal', that is, if you make a change to a component you shouldn't have to change other components. We all learn the basic concept of loose coupling when doing Comp Sci at Uni, but Andy Hunt and Dave Thomas in The Pragmatic Programmer (1999) were the first (that I had read) to express the concept in terms of orthogonality.
Orthogonal is just a fancy way to describe two planes being at right angles. For example, If you imagine a graph with x and y axes, for x and y to remain orthogonal any increase to x must leave y unaffected.
It's a nice way to consider component coupling, if you change one, it shouldn't impact others.
So what can this look like in the real world? This afternoon I came across a method that has a line looking a little like this:
$val = $state->getGeoModel()->getMetadata()->getBoundingBox();
Now, never mind the mind boggling number of assumptions this line makes (e.g. that each call *will* return an initialised object), it means that one method in one component needs to know how three different components work.
This code knows that a state object has a getGeoModel() method that in turn returns an object with a getMetadata() method. If we change the getGeoModel() method, we have to update this code. If we change the behaviour and values of the geomodel object itself, we have to update this code. If we change the metadata object, again, we have to update this code.
This increases the entropy risk by a factor of three.
A smarter approach, and one suggested in The Pragmatic Programmer, is to simply expose a getBoundingBox() method in $state. This way, we move the problem to the state object and reduce coupling in our implementation.
This will add complexity to the $state class, however we can apply the same principal up the chain as applied here.
Stefan Priebsch’s Anti-patterns talk followed Josh in the main auditorium and his style for me was a welcome contrast. He said he wasn’t going to be funny, but any self-deprecating German is going to find easy chuckles in front of a largely English crowd.
There was a rather amusing moment towards the end of his talk as Marcus Baker tried to hurry him along. The irony of an Englishman prompting a German on timekeeping was delicious.
The subject material is probably fuel for another blog, but I think Stefan’s talk highlighted the fundamental problem I have with Anti-patterns. If a design pattern is a generally held ‘good way’ to solve a common problem, an anti-pattern must then be a generally considered ‘bad way’ to solve a common problem.
The issue is twofold. One, not everyone agrees on what constitutes an Anti-pattern – i.e. what is bad. And two, if an Anti-pattern is a common (albeit bad) solution to a common problem, there must be a ‘good’ alternative right? Well, that’s the thing, the answer is not always a clear yes.
We are regularly cautioned on the evil of Singletons, or of the pitfalls of Globalitis. Rarely though, are we shown a ‘good-way’ to avoid these patterns and solve our problem easily. If we go back to the late 90s, early 00s, bearded boffins at Sun Microsystems gave us things like RMI and Enterprise Javabeans. These technologies employed what were considered good practices, but were too cumbersome to actually use in the real world. It’s very easy to say xxx is real bad. It’s a lot harder to say how to do it better without significantly more effort.
Stefan’s talk fell a little bit in to this trap. He showed us serious cases of Globalitis, but failed, I think, to argue convincingly why class constants, for example, were such an awful, abominable thing. We heard again about the evils of Singletons. But Singletons have their place and used sparingly can be a powerful solution to application design problems.
All this said, Anti-patterns are a fun subject. They have much cooler names than regular design patterns. Give me the ‘Magic Hammer’ over a ‘Table Data Gateway’ anyday. So in summary, I enjoyed Stefan’s presentation and it was one of the most thought provoking of the day. I found he covered a fair bit of ground, introduced enough vocabulary for the uninitiated and enough detail for everyone else. The tone and pitch seemed appropriate for the audience too.
Well this was my fourth PHP London Conference, and I feel, by a fair ways, the best yet.
I remember writing last year, a little bit about my disappointment at the event. This year though was a marked improvement. I still rather fondly remember the very first conference at Southbank. That though, was a far smaller, less ambitious event than the one organisers delivered Friday.
Registration was quick and easy and Johanna Cherry was tremendously warm in welcoming guests. It is a small thing, having someone warmly and apparently genuinely welcome you to an event. But it makes a big impact, and it starts the day on the right foot.
The venue is the best we've gone to yet. Getting to and from the conference was straight forward. The staff were polite, prompt and unobtrusive. There was enough space over two floors for people to spread out and the food was of a good standard. If there is one criticism, it is of the toilets. They were not sufficient for the number of guests, by the end of the day they were not clean, and they were damn near impossible to find, squirrelled away in some recess you needed a GPS to navigate.
The first talk, Josh Holmes' 'The lost art of simplicity' didn't really knock it out of the park for me. The material itself was fine, if a little rote now (a theme, sadly, that ran through a number of the talks). It seemed to me, almost like a rehashing of Agile development with some nice slides. Harsh, but there was little to take away from it that we haven't heard in some shape or form before in the past 3 years. Maybe it is me too, or maybe it is a cultural thing, but I don't really take to the 'big' style of presenting. Aral Balkan last year, was really off-putting. And Josh was similar. When I say 'big', I mean loud and over-energentic. It's like they are trying to deliver a performance, rather than a talk. I want to hear intelligent people speak intelligently. Not channel Anthony Robbins.
I could listen all day to someone speaking in the style of Chris Shifflet or Ian Barber this year. Understated authority. But I seriously cannot deal with the forced hyperactivity of Aral or Josh.
I accept some people like 'performances'. At a gathering of developers, I don't.
Summing up though, Josh's talk was perfectly fine. I think 2011 should aim a bit higher, maybe take a risk and go with a keynote that really puts 'something' out there and makes a statement about PHP in the UK?
In the next part I'll talk about Antipatterns, Database Optimisation and 'understanding your audience'.
In Zend Framework controllers, to output something other than html you will want to disable ViewHelper defaults along with some of the other magic ZF typically weaves.
In Magento, the same thing applies when doing a controller redirect.
I noticed on PHP 5.2 a redirect seemed to be ignored whereas my Macports 5.3 setup it worked. Turns out I was missing a trick, and so a proper redirect in Magento is done as follows:
In MyPackage/MyModule/controllers/MyController.php ...
$this->_redirectUrl($this->getUrl('http://www.someurl.com/someresource'));
$this->setFlag('', self::FLAG_NO_DISPATCH, true);
return $this;
Without the setFlag call, your redirect will be ignored. The return call stops any further code execution and sees your redirect get actioned.