tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Thu, 14 Feb 2013 16:59:01 GMT
Hash: SHA256


On 2/14/13 1:23 AM, Terence M. Bandoian wrote:
> I probably should have said there is a "potential for lost 
> knowledge".  Here are a couple of anecdotal examples that I hope
> will help illustrate what I mean.
> - I was told recently by a person in a software architect position
> that they use Hibernate because it prevents SQL injection.


So, it doesn't support custom WHERE clauses? Sounds like a
deal-breaker for me. If it does support custom WHERE clauses, then
it's open to SQL Injection because programmers can still suck.

> - A JavaScript programmer told me not too long ago that you really
> have to use a JavaScript library (e.g. jQuery) if you're going to
> use AJAX in an interface because it's just too complicated.  Is
> instantiating and using an XMLHttpRequest object really that
> difficult?

No, but if you've ever done your own AJAX work (and not just something
silly like sending a ping to the server or trading a 2-line XML
document), you'll know that using a support library makes your life
soooo much easier, especially when you have to support multiple

Good news is that you can mix-and-match: if jQuery (et al) doesn't
support some feature, you can write it yourself and (probably) not

> Still another says that one of the reasons their organization uses
> a full-blown framework is that their programmers can't develop
> cross-browser compatible JavaScript.

It *is* very difficult: when you can leverage the work others are
doing, I think everybody wins. Let the jQuery folks figure out how to
make XML parsing and call-backs work on both MSIE 6 and NCSA Mosaic:
NMFP. ;)

> What I'm saying is there should be a good reason (really good) to
> add significant complexity, performance overhead, memory
> requirements and megabytes of code to an application.

Leverage is a powerful thing.

>> In my experience, by far the biggest time waster is trying to
>> deal with code that is (or has become) unmaintainable. Re-writing
>> just because a piece of code has become out-of-touch with current
>> standards or because nobody understands how it works is entirely
>> wasted effort. We have lots of places in our code where we have
>> been spending - literally - years recording from bad decisions in
>> the past.
> Granted.  Reading other people's code is a learned skill and can
> be problematic.  Isn't that where design and code reviews and
> coding standards come into play?  Also, apples and oranges.  Energy
> is precious resource that deserves special consideration.  I'm just
> blue-skying here and don't have the answers but how much
> electricity is wasted by inefficient programming?  We may have to
> factor that in some day.

Future-proofing is not possible, but it is a reasonable goal. All
software rots, even if it's great software. Take Java code: anything
written before generics were introduced and uses a lot of collections,
etc. will now be a PITA to work with. I have code like this: we are
updating it as we have to edit it for other reasons (e.g. we aren't
going on a S&D mission for non-generic-y code just to "fix" it), but
it does represent some technical dept that does need to be paid at
some point. Maybe the existing code is so good that it never needs to
be edited, so it sits there and rots, and there are more things
"wrong" with the code but it works perfectly well. It becomes
something that irritates everyone but everyone tolerates because it's
"good" code.

If you can make some code someone else's problem, I think that's a
win. It's very cynical, but having grown-up in the Java world before
any "good" libraries were available (other than the standard Java API,
which is great by any standard IMO), I've been party to a lot of time
and energy spent just doing simple things like trashing some cowboy's
home-grown logging API, O-R mapper, and (yes, true story) XML
transformation engine.

"Not invented here" is a pesky disease and it's really okay to
leverage other people's code. There are always exceptions (I've
written my own rules engine from scratch when DROOLS, JESS, etc.
already existed) but you (not YOU) are a fool if you don't consider
using something off-the-shelf -- especially if that shelf contains
lots of great OSS and you can help support it.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message