From SOA is a Business-Driven Architectural Style:
"It means that for SOA to be successful, it must be a 'top-down' approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure. "
I will go a bit further and say that any architecture that isn't bent on solving a particular problem is a recipe for failure.
Tuesday, March 22, 2005
Monday, March 21, 2005
Searching Google for Books
I had heard about Google Print a while back.
I hadn't realized that the Google Library project would mean that public domain books, like Huckleberry Finn, would now be searchable via Google.
You just enter "book" followed by the book title in Google.
I hadn't realized that the Google Library project would mean that public domain books, like Huckleberry Finn, would now be searchable via Google.
You just enter "book" followed by the book title in Google.
Wednesday, March 02, 2005
Being Careful Is Not The Solution
Sometimes, when you touch a piece of code, or a build script, or a configuration file, you might feel the urge to be very careful, because your change might break the overnight build, or result in a subtle bug.
Being careful is not the solution. You cannot be careful all the time. Sooner or later, you will let you guard down and make a mistake. It is inevitable. If you are lucky, this mistake will occur when you have loads of time to diagnose it. If you are unlucky, you'll get a bad build at the 11th hour.
When you find that you need to be careful, you should ask yourself, how can I change this situation so that mistakes are either impossible to make or discovered immediately after making them?
If you think about it, you probably already know a few strategies for achieving this right now:
Being careful is not the solution. You cannot be careful all the time. Sooner or later, you will let you guard down and make a mistake. It is inevitable. If you are lucky, this mistake will occur when you have loads of time to diagnose it. If you are unlucky, you'll get a bad build at the 11th hour.
When you find that you need to be careful, you should ask yourself, how can I change this situation so that mistakes are either impossible to make or discovered immediately after making them?
If you think about it, you probably already know a few strategies for achieving this right now:
- Unit tests insure that your classes behave as you expect them to.
- Asserts (Design by Contract) achieve the same thing from a different direction.
- Code generation eliminates duplication, so that you only have to make a change in one place.
- Static type checking catches mistakes at compile time.
Subscribe to:
Posts (Atom)