|
|
06.18.2004 |
|
||||||||||
| Thoughtful Consideration better than any Pattern | ||||||||||||
I've been a computer geek since a boy, and thoughts related to computers and software engineering get dropped here for the benefit of humanity and my own hubris.
|
I was reading the latest issue of Java Performance Tuning and noticed an interview with Bill Lynch and Matt Tucker, who founded Jive Software, and they make some interesting points in regards to design considerations and performance. What struck me the most was their “thoughtful consideration” of all aspects of their programs. For instance, even though their requirements stated that they needed to be scalable across clusters, they didn’t just choose EJBs— they answered the requirement. They also just didn’t use standard caching software since they could see their own usage patterns and could gain significant performance improvements by rolling their own. This is the balance that we all need… between building upon more generalized code (for quicker development and that has usually been better-tested) and creating unique, specialized solutions for performance reasons. It just goes to show that thoughtful consideration is better than the thoughtless application of any design or architectural pattern. Still looking for a rule? Try this one for size… start with general building-blocks but keep things transparent and your components loosely coupled. Then start looking for usage patterns, bottlenecks, and better implementations and start re-factoring. I also think that there is a business case for this approach. Your customer gets what they want on time (since you built your code upon the shoulders of other software) and they are willing to pay for performance improvements. Thought originally posted on Friday, 18 June 2004
© 2004-2005, Howard Abrams • Except where otherwise noted, all original content is licensed under a Creative Commons License (see details). A comment to this from Howard the Author
Jive Software has released a Jabber API for Java into the public domain. It is called Smack and one thing that struck me was that this library doesn’t depend on any other XML library. In other words, they rolled their own XML parser. Normally, I wouldn’t recommend that, as what you loose in performance considerations with dealing with XML in the first place you gain in development time by using already built parsers. However, in this case, Jabber… er XMPP, is kind of strange in that it doesn’t transfer XML documents but XML streams. Sure, this clearly means that DOM is not a good approach, but why isn’t SAX? While I haven’t talked to the Smack developers, my guess is that Jabber has some obvious use cases that could be optimized by parsing it directly instead of using the SAX approach. BTW: This Smack looks pretty slick over all of the other Jabber APIs that I’ve used. I think I’m going to have to play with it. Comment posted on Saturday, 10 July 2004 |
|||||||||||
|
||||||||||||