Posted Fri, 03 Feb 2006 22:16:00 GMT
As luck had it, I’ve recently had to extend a number of old J2EE systems with new functionality. Which made me think about extensibility. Now, we all strive for that, don’t we? Some of the systems (or parts of them) were actually written by me. I remember extensibility being top of my agenda when I was developing them. So, how come now when I actually have to extend them, I hate myself for writing them that way.
Hm….. It turns out, they are not simple. I need to spend hours trying to figure out what exactly I meant, and why I built in all these layers of indirection and factory classes and methods and uncountable number of configurable properties. The thing is, after all these months, despite the help of all the bulky documentation, I just can’t understand what I or the guy who wrote it, meant there, and why he did it in this outrageously complicated way.
What I came to realise was this: As a programmer, I am good at programming. I am not so good at writing proprietary property files and configuring systems, even if they were written by me. And I’m not very good at guessing what will have to change in the future, or put simply - my crystal ball is starting to falter.
It turns out that what I intended as an aid to extensibility is now taking me ages to unravel and untangle.
I can’t believe I have coded software which looks up a property in order to figure out which property to look up in order to figure out which template to use for applying a rule to an object.
So it slowly sunk in - the best aid to extensibility is simplicity. Simple software is easy to undersrtand and easy to refactor. By creating processes for a certain change, you allow that change, but set in stone the process for change. Which means that all change that does not fit the process you envisaged at the time is prohibitively expensive.
Simple software seems therefore to be supple software.
no comments
Posted Thu, 02 Feb 2006 18:43:00 GMT
It’s bit unfashionable to write about Struts now, what with all the JSF, Tapestry, etc frameworks, but most projects I’ve seen still use Struts, and I often end up having to re-invent how to deal with the dates and other non-standard fields in the forms. So this time I’ll write it down. Especially as this time it seems relatively neat and simple.
So here’s how you do it:
The form bean
Say we’ve got the following date fields:
private Date dob;
private Date memorableDate;
public Date getDob() { return dob; }
public void setDob(Date dob) {
this.dob = dob ; }
...
Struts can’t populate these fields. One option is to keep your dates as String, but have a go and you’ll see why that’s awkward.
So what we do is
Read more...
Posted in Tips and Hints | no comments
Posted Mon, 30 Jan 2006 18:29:00 GMT
I used to hate this - you are handed an old crappy system and you’re told: “Look, we have this system and it works just fine, but we now have this new requirement. Can you please implement it”.
It’s so much nicer to be working a new shiny project with all the fuss being about you and all the fancy start-up do’s and the senior management and sponsors and all the analyst and all the brouhaha…
Well, I’ve just recently found out that it’s not all so bad, actually. In fact the shittier the system is, the more fun you can extract out of changing it. I observerd the following:
At the time this was written, people (perhaps including me) had somewhat different ideas of how to make good software.
After a system has been in production for some time, it has accumulated a lot of quick fixes, many of which are just hacks and some quite dangerous.
The people who had to re-work the system before me had little or no motivation (after all, they had been handed a crappy system, yeah?) and often were not qualified for the job (where do you find a good programmer for a quick job in an old system?)
Read more...
no comments
Posted Mon, 30 Jan 2006 13:21:00 GMT
I’d just finished a small, very simple build file, which for the moment does not do a full build but only a small portion of it (generate environment specific property files).
After a short think of what the default target should be, I decided that a wanted projecthelp to be invoked by default, cause I didn’t really have a good candidate at the moment.
So I did a quick search in Google and this came up from this website:
“Never have the help target as the default target - it just guarantees that every use of the build file will be more complex than necessary.”
Hm…. Is that really so? I’d never thought about this before, but then I always had an obvious default target - either dist or compile.
So what does the average person expect when he runs an ant script? I’ve never considered this too closely, but I reckon before I run an ant script, I always check what the default target is anyway….
no comments
Posted Tue, 24 Jan 2006 09:04:00 GMT
It's become a bit of a sport now to slag off EJBs. Not a day passes without somebody explaining at length how heavyweight/useless/just-generally-bad they are. Well, since many people are just doing it habitually or because everybody does it, it would be nice of them to consider this:
Scenario one: imagine you are writing a component, which will be used in many products in your organisation and may be outside as well. It accesses a database and sends a couple of messages to a queue. Some of the apps will require this to be part of their transaction, others not. What do you do?
Scenario two: You download a component from the web. It does some cheavy computation, which you can not implement yourself. It uses a lot of memory and you have limited resources. You only want to run 2 instances, but you want to be able to run more later when you buy more kit. How do you do that then?
A, well, these are exceptions, are they?? No, they are not! This is exactly what EJBs are useful for. This is exactly the kind of thing they were invented to supply. The fact that hundreds and thousands of "architects" caught the buzzword and "designed" and "architected" systems with layers upon layers upon even more layers of the buggers which clogged up everything is not EJB's fault, it's the users' fault.
There are other legitimate uses for EJBs, which become apparent once you read the documentation.
Well, I suppose with the exception of Entity beans which seem to be indeed useless rubbish...
PS: Without doubt, most of these issues have a resolution in DI frameworks like Spring, so if you use those, then I suppose you're ok. But sadly most of the people who unconditionaly reject EJBs have not even heard of those....
no comments
