…I have tendancies to be an architecture astronaut. I came up with this really great OOified, XMLdriven, App Server hosted persistant singleton cache architecture for a web program thingy I’m trying to do.
It turns out that I use the XML as a configuration file, which dosn’t leverage any of the advantages of XML. I have one object which exports a horrendous interface of an array of hash tables and the cache is not in an app server as I’ve not had time to play with mod_perl.
I’m moving towards my design; but slowly so. I really need to think about how a user would want to use the system, which is what Dave always says.
I think the problem here is that its far more fun to plan the system, and think of all the new technologies and buzzwords you’ll get to play with than it is to actually sit down and ask the age old questions
1) What is the purpose of this system
2) Who will be using it
3) How can I best satisfy the people(2) in doing what(1) they want to do.
Ultimately, the end user doesn’t give a flying fuck if its ruby/python/rails/j2ee/XSL/XML/EJB or any other popular acronym. Does it do what it says on the tin? Can I use it? If so then great, if not then stuff your technologies up your ass they didn’t help you here. Thats end users for you!
It reminds of a time when Tom was offering a final year project on research literature organisation tool (or something). You shitcanned the PHP and MySQL design, offering XML/XSL as a better one.
Ultimately, a working application is far more important than a well designed broken one. If writing this “App Server hosted persistant singleton cache architecture for a web program” in PHP is what it takes to get it up and running, then by PHP is the right choice
(much as it kills me to say it).
To be fair. I didn’t shitcan the project. I actively helped by testing the project. And my idea was for something totally different: a program that let me merge bibliographies from different users.
Anyway, you’re right. The user dosn’t care how it does stuff…unless the user is a developer or the product is supposed to be well designed as it’s an example to students.
Oh yeah…I was talking shit when I made up that sentance that has all the buzzwords.
I know you didn’t shitcan the project architecture, I was being slightly facetious. I think it boils down to a few things
a) Choosing the first set up that comes to mind isn’t usually a good idea ( i.e. L.A.M.P )
b) Just because a set up is complicated it doesn’t mean its good.
c) Just because a setup uses very new technologies ( e.g. Ruby-on-Rails) doesn’t mean its good.
.
.
.
y) If a set up works well, then its better than one that doesn’t.
z) The end user doesn’t really care what the set up is.
The only reason you would ensure a set up is fantastically modular/clean/component based/
is if
a) You will be working with it/maintaing/upgrading it regularily
b) Its an O.S.S project , and you want to encourage people to join in.
$.02c
testcomment961