While I was working near Oxford I attended the Oxtremists meetings. They do a monthly meetings to discuss vaguely agile related books and drink beer.
Of course I only write about it here after I leave
Although I guess not having the next meeting on Feb 14th might have been a clever idea
Since Ovid has sort of tagged me here are five things you probably don't know about me:
Off to catch the train to Brum in a couple of hours. Made more interesting by trashing my hard drive early this morning. Thank goodness for backups!
Say hi if you're there. I'm the big fat bloke with the sideburns and the pony tail
What's the Bulldog Award I hear you cry? It's an occasional award for "outstanding personal contributions to the philosophy and dissemination of the Unicode Standard".
There's a really geeky part of me that loves the fact that this has been awarded 13 times since 1997.
Since there aren't comments on his blog I'm gonna take a mild poke at Artistotle's recent Dependency Injection post here
He asks, in relation to Fowler's DI article:
Why do the design patterns people come up with such ridiculously elaborate conceptualisations of perfectly trivial ideas?
First off, I'd disagree that these ideas are trivial. If it's trivial why do I see so much code with tightly coupled external dependencies? Why am I so often faced with applications where I have to mock up half the fardling world before I can test a single module?
The DI pattern might not be difficult to understand or apply - but the problems it can help solve are not trivial.
Now, I do agree that Fowler's exposition isn't an example of his best writing. It's a bit of a mish-mash article which is trying to cover at least four different things (what DI is, why it's useful to separate it from inversion of control, why it can be better than things like service locators, how this relates to the J2EE complexity backlash, etc.)
However it did do one hugely useful thing. It named Dependency Injection and separated it out from the more general Inversion Of Control.
I read and reread the definition, examined the flimsy code snippets carefully, stared at the nearly tautologic diagrams for roughly 10 minutes, trying to grasp the deeply profound idea but failing. It finally dawned on me, after investing much effort, that it was right there – only banal enough that it was obscured by the heaps of pontification. It turns out the concept is so trite I've used it more times than I can remember, without ever having thought of it as any kind of dinstinct idea.
That last sentence is a doosy.
The whole point of patterns is to describe and name common design strategies - and thank god for that.
If you don't have DI in your head as a distinct concept - something you can name and describe - then it becomes really hard to communicate that idea. Judging from the code I regularly encounter it's an idea that could do with a bit more communication
Now Fowler has done the work of naming DI and separating it out from the more general inversion of control pattern I've been given the gift of a beautiful new communication tool.
My coding partner can say things to me like "Hmm... the fact that this code is pulling all it's configuration information out of these singletons is making testing a pain in the arse, maybe refactor it so it uses dependency injection?"
Think about how much information is in that question. Try communicating that intent without naming the design patterns "singleton" and "dependency injection" and see how long it takes.
I do think that part of the reason the descriptions of DI seem so clumsy to us Perl folk, is that it's a harder concept to put into code with languages like Java.
DI is pretty darn easy in dynamic languages like Perl, Ruby and Lisp. We can also do really neat things at runtime that mean we can solve the problems that DI solves with considerably less effort than Java folk.
Jim Weirich's nice OSCON presentation Dependency Injection: Vitally Important or Completely Irrelevant? does a nice job of highlighting this (and does a better job of describing DI too.)
% find . -name \*.pm | xargs wc -l | tail -1
% find . -name \*.t | xargs wc -l | tail -1
This one hit my inbox yesterday.
Our client is a leading engineering technology provider, undertaking research, design, development and strategic services to the world's automotive manufacturers. THE ROLE: To work in Tokyo for 3 - 6 months to assist on a website design project The work is 5 days per week but 50+ hours per week, so dedication and flexibility are vital.
Does anybody else think that the sort of organisation that starts with a plan involving 3-6 months of 50+ hour weeks is going to end up with something considerably worse?
Can anybody else say Death March?
(Incidentally I just noticed today that I've not watched any television for about three weeks. Zip. Nada. Not through any virtuousness on my part - there has just been nothing on that I've wanted to watch.)