Saturday 18 November 2006

Thoughts .. Moving away from the DB

This is often the topic of an OO developer. How do I distance myself from the database platform, but not lose, and only gain, as would be the goal.

So I want to not have to rely on a DBA.. I mean, whay have two models. One for the database and one for the code.

The problems I still see are

- Invested expertise in DB coding (SQL sprocs etc)

- Speed of Batch processing. (one of these days Im going to bench mark some hardcore processing and see how I can get the same performance from a platform)


Client requirements, speed, experience dictate that we are tied to the RDBMS, Oracle, DB2, Sybase, SQL Server, great platforms. I myself have extensive experience in knowing how to get the diamonds out of the Sybase Parser, but not practising that black art any more I often wonder what my next "personal" project architecture would be.

James Strachan mentioned to me the other day how cool it would be to have XPath (Xquery) on top of Jaxb2. That is a cool thought.

The XML Content repository JSR-170 is a good read if anyone ever thinks of an XML database :-) that is essentially what it is.. I will certainly look at it again as a thought.

Wednesday 6 September 2006

SOA, SOAP, RMI, TLA, FLA and Horses


Picking that horse. I'm not a betting man at all, never been trackside, but some describe technology like betting a horse.
Do your homework and choose, then hope it wins, maybe needing a good relationship with your bookie (I am not sure who the bookie is in this analogy).

My own take is technology far much more than betting, (and the punters would say the same about horses).
But in fairness, some people get burnt, myself included, when then chose the wrong horse.



So taking some pages from anyones book, do your research, and, if your're
at the other end when the horse is scrapped, don't give up and move on.




My point is, a technology, platform can be chosen which ensures you don't have to worry, too much, about what is going to
come up against if you follow a few simple guide lines.



Ramon's Tech Tip #1 - Horses will be scrapped



What do you do when the horse you backed is scrapped ? Same as you do in business, learn from it.
It may have been the best horse when you started, and sure, it got you to now.




Ramon's Tech Tip #2 - Choose the Horse, Jockey, Race History and the Silks


You trusted your instinct and your fellow peers, but something went wrong.


The way I apprach a choice area is to talk to people who would agree with me, easy. I also
get opinions from people who I know won't like it, two outcomes come from that approach, (1) I will learn something, like that
they are definitely wrong and I am right, or that they actually have a valid point. (2) They show I am wrong and in fact they
do like it anyway.



The other approach I do is to research the other technology camps to find out where they are heading. In this I mean .NET, LAMP, Java,
bright people with bright ideas working in another language, what do they see the future in X area to be ?


Silks ? Well, go with what you like, at the end of the day you will have to be the decider.




Ramon's Tech Tip #3 - Think of the future bets



All good and well when you have to decide for a short term item (1 - 2 years), but what about choosing a
direction when you yourself won't even be looking after it.



A well guided decision that will impact others beyond you must be well thought out and planned. Don't rush into
any decision lightly (Sub tip #3a). I have recently been involved in the decision making process that will see a platform
being used well into the next 3 - 4 years. I can be good and say I will be around in that time, most likely I will, but what if I am not?
I need to be considerate of the fact that the choices we make now, take us that far into the future, expecting that things will change.

Ramon's Tech Tip #4 - Follow the Jockey



If you don't get too friendly and passionate about Mega-Deployed Platform AlphaX, you will be happy to change to Simple-Deployed Platform AlphaX
when you need to. My tip here, make the choices such that each component is not interdependent on another, don't couple things so tightly
that it means cutting off when all you wanted to do was change cars



Ramon's Tech Tip #5 - Horses fall over



Expect it to change. In all our dealings with IT, the one thing that is guaranteed is that something will change.
Be it that it will become obsoleted or improved.



I have just been involved in a project where the first cut of our product was available for no more than 9 months
and then we saw a radical change in how it should be offered to clients.
One key component to the easing of this transition is that it was well engineered from the onset to cope with the change.
So the best way to describe this is, write it so it can be changed, but write it to last. Loosely coupled.

in the .NET land I have seen comments that interfaces should be removed, but in the land of dependency injection. Interfaces
are king. Sure interfaces may change and need to be redrawn but so will a tightly coupled system. I can tell you
that IoC Frameworks are becoming King, and, bottom line, they save money. and I don't mean small cost cutting here
and there. I mean in the order of weeks of work for teams of developers. Relating to $1k's to $10k's for large projects.
Prove me in this and I'll be quiet, but they really work and are not just some Astronaut engineering Oxygenless fad.




Ramon's Tech Tip #6 - Don't sweat when you lose



Let's face it, and that's it, you will have to face it one time or another.
Horses collapse, decisions made may die. It may not have been a bad horse, it may not have been a mistake.
It could have been due to external factors such as another horse on the track destroying yours, or a big comet
taking out the whole race.
In any case, accept it and move on. The person that hangs on to the, "oh but it was good" and doesn't learn from it
doesn't learn. Sometimes things were good and there are hard factors that caused them to fail, such as humans.
So .. learn from it, analyse what you did wrong and choose another horse.



Ramon's Tech Tip #7 - You're betting for someone else



I once had a colleague that, when I asked him what he wanted to be doing in 3 - 5 years time, said, "I don't want to be doing the 'next IT project' which just involves another set of requirements and tasks". He wanted to get out.
Now sure, that's valid, and he probably needed to move on. My take on IT and the next project similar to the last
is that I am pleasing a client. The client is always right, and IT forgets that. Sadly there has been this thing that the techy dude,
sys admin, software engineer, whoever, knows better than business person X because they know something. Knowledge is king, sharing it with someone else and letting them make a decision is power to the king.



It's always said, and often in retail. The client is always right. Well that is also so true in IT. IT department, make the client the person that pays your wage. Software guys, the client is the one who is funding the project.



IT from it's onset has always been around to "solve" a problem, make a buck, help someone do task X. The key thread in all these is that there is a client, and there is the problem they want solved.
They are the ones that will dictate what needs to be done, how much to spend and the cut off point at
which foobar-option-ABC is implemented using pure methodology Reverse Vegemite Toast.

Current 5 booksmarks @ del.icio.us/pefdus