After my dalliance with Typo I am back on Wordpress. I found I was spending too much time fiddling with Typo and not enough time writing (and the fact thta my half assed configuration just stopped working with monotonous regularitywas discouraging).
So here I am back on Wordpress. It was a manual migration so it looks like I wrote a bunch of stuff today.
Lets see if I manage to spout off a little more now eh?
I attended the AYE conference last year part of which was a writers workshop. This was the most memorable of all the sessions for me; partly because it should me what emotional depths one can access, quite unexpectedly, when writing about something one cares about; partly because it was actually useful for me (unlike many writing workshops I have attended). Anyway, lessons learned: * Write about what you care about * Keep writing * Go “meta” when you are stuck How does “going meta” work? Well, if you care about writing and you are stuck then write about why you are stuck. It will fulfil all the three “lessons learned” and might show why you are stuck. The Ramblings category is my “going meta” category so it might appear quite random. I hope readers might gain something from my struggles 
Listening to a development discussion today I was struck by a thought on optimisation. We don’t just optimise software (for speed, size etc), we also optimise it for rate of change. In fact optimisation for improved rate of change is one of the fundamental contributions of the agile movement. After all refactoring , DRY, OAOO are not necessary if you never change your code (well, that’s not strictly true but it is enough of a truth for now). The discussion I was evesdropping on was about building a simple framework verses writing targeted code and I found myself rooting for the targetted code. At another time in the day a different group of developers were arguing about the whether to refactor some code they had just written or not. In both cases I felt that the arguments for refactoring now “It will be easier to change” and the arguments for the framework “it will be easier to incorporate new projects”, while factually true were not winning me over. The point was that the framework and the refactoring were optimising the ability of future developers to change the code. In each case the arguments were not winning me over because I didn’t think those areas would change much in the near future and the changes did add complexity (if only by adding a bit more indirection). So, the arguments were for a premature optimisation of the malleability of the codebase. Now we all know about premature optimisation, but I’m not sure we always think about it in the context of our process, rather than the codebase. So the next time someone want’s to improve the codebase “so it will be easier to change”, wait until you know what the change will be. You never know your luck, you might wait forever.
For a while after moving out of the Big City I felt the only real difference was having a (much) longer commute. However the sights and sounds grow on you (mainly sights, living on a main road the sounds are still pretty metropolitan). This morning we were chatting over a morning coffee we saw three crows mobbing a buzzard. The land to th eback of our house slopes down steeply so the whole event played out at eye level. It was an amazing sight, a really edgy aerial ballet. Eventually the buzzard the buzzard was worn down and headed for the hills but for five to ten minutes we were treated to an entrancing display of aerobatics and a real life drama. Now we didn’t get that in the suburbs!
Well, Here I am on Typo. Still finding my way around and working out the details. I think I am going to have to learn one of the markups soon.
Phil Dawes has an excellent post on problems scaling classic Semantic Web approaches to a moderately sized, messy, real world environment. I have watched him develop his solutions to these problems, the evolution of tag triples and JAM*VAT and it is very impressive. One of the lessons I take away from Phil’s work is that for things to scale in the real world they are necessarily fuzzy. If your system needs everything to work out up-front and will only handle 99.999% of cases then scaling to real world sizes quickly generates far too many problems to cope. As brittle systems (those that require certainty) grow they have to increase their complexity enormously. Building a system that can hold ambiguity without worrying about it until the information is needed means that special cases can be ignored until they have to be dealt with. Which is essentially what Phil has done by leaving the disambiguation to the user of the data rather than the source. What this does mean is that its hard to be certain about the meaning of your data. But that’s just the real world for you.
Thanks go to James Robertson for spotting this… In bytegeist Dermot Hogan argues that “Object Oriented Programming has failed”.
His first example of the massive failure of OO is:
“But let me give you two cases from my own experience. First was the company that was going to build a new OOP banking system. Great idea! Just create a banking class library and use it to build banking applications like cars off a production line; or like shelling peas - or whatever inane simile you want to come up with to disguise the lack of any deep analysis. Or if the truth be known, any analysis at all: this is the world of banking. The problem was (and is, and always will be) that processing dosh does not correspond to an OOP paradigm.”
Now, maybe I’m old fashioned, but my guess is that “the lack of any deep analysis. Or if the truth be known, any analysis at all” probably had something to do with it.
His second example is:
“I was working on fixing a bug in an object oriented Perl system. Yes. Perl can be made object oriented; it isn’t elegant (think of camels dancing) but it does work. I noticed the error low down in the class library and like a good programmer fixed it, got it tested and thought no more about it.” and then after causing trouble for a supposedly unrelated user it hit him: “What I’d done was to modify the behaviour of a base class. And this behaviour had then propagated with effortless ease through the whole damned system. But, with financial systems, this is a no-no. In a typical financial system, all responsible users have to sign off on a change before it goes live. After all this is real money we’re taking about here. Especially if it’s the bank’s own. With this particular system, that sign-off involved users in most of the capitals of Europe!”
Amazing! OO programming techniques now manage impact analysis, regression testing and change management! And I thought they were a way of managing complexity in code.
The sad thing is that there are a lot of developers and development managers out there who really do think that some new technique will eliminate the need for analysis, correct change management process, configuration management and all the other “boring” bits. Well, they haven’t; the “boring” bits are the bits that separate the professionals from the gifted, and not so gifted, amateurs. They can be done, or not, whether you are building with OO, procedural, relational and/or functional technologies. You can do them with lots of, or little, ceremony. They do, however, have to be done.
I had some code accepted into a Ruby project yesterday. Run, don’t walk to SVG::Graph, an SVG graphing package. I am quite pathetically excited about it. Does anyone know of an SVG viewer that runs in Firefox?
I’ve been following the ruby on rails FastCGI vs threads scaling debate and was particularly taken by Cameron Purdy’s comments about Database connections. Which brought me to thinking about the worlds people live in. Cameron, I expect, lives mainly in the high end of “enterprise” (because people only really need his product when they are hitting those walls). Most people don’t, most developers live in the world of one or two databases and a few thousand users. Which leads to two implications:
The gods did not reveal, from the beginning, all things to us,
But in the course of time through seeking we may learn and know things better.
But as for certain truth, no man has known it,
Nor shall he know it, neither of the gods
Nor yet of all things of which I speak.
For even if by chance he were to utter The final truth, he would himself not know it:
For all is but a woven web of guesses.
Xenophanes (translated by K R Popper)