tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <tere...@tmbsw.com>
Subject Re: [Seriously OT] Help in diagnosing server unresponsiveness
Date Thu, 21 Feb 2013 20:09:15 GMT
On 2/12/2013 9:36 AM, Christopher Schultz wrote:
>>
>>> On 2/11/13 4:30 PM, Terence M. Bandoian wrote:
>>>
>>> I understand the considerations above and they are a part of the
>>> prevailing thinking. However, one underlying assumption of the
>>> supporting argument appears to be that today's programmers are not
>>> capable of developing maintainable code which I don't believe is
>>> true. As I understand it, programmer productivity is one of the
>>> most significant factors in the decision making process and it is a
>>> valid concern. IF (that's a big if) an application can be developed
>>> in half the time using a generalized solution, then that approach
>>> has to be considered along with a host of other concerns including
>>> the end product and the effect on the organization. I say reliance
>>> on generalized solutions is short-sighted because knowledge of the
>>> underlying technologies is lost, or never gained, along with the
>>> skills to work in those spheres.
>> Are you suggesting that people who program using Java are oblivious to
>> the innards of hardware architecture and are remain ignorant of these
>> important details? That's the logical conclusion to your argument.
>>
>> I'm not saying you're wrong, but you have to admit that a Java
>> programmer (of which I'm one) saying that using a generalized solution
>> makes you ignorant is a bit like the pot calling the kettle black.
>
>
> Not at all.  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.  I'll give 
> them the benefit of the doubt and assume they have other motivations 
> but still, is escaping the input strings to a query really advanced 
> knowledge?  Think about that from the perspective of a junior or 
> mid-level programmer who has only ever used an ORM. What happens when 
> something goes wrong or performance has to be optimized.  For that 
> matter, what does happen?  Now you have to know SQL, the DBMS, and HQL 
> and understand Hibernate behavior. Double the complexity?
>
> Disclaimer:  I don't have anything against Hibernate or JPA.  I worked 
> with an early implementation of JDO for a short time and am beginning 
> some work with Hibernate.
>
> - 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?  What about those programmers who have only ever used a 
> JavaScript library?  Another developer says he tells clients that they 
> shouldn't consider a feature if it isn't supported by jQuery. 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.
>
> Disclaimer:  I think jQuery is a wonderful library and, if you plan to 
> make good use of the features available, it should definitely be 
> considered.
>
> 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.
>
>
>>> Efficiency, flexibility, repairability, extensibility and
>>> reliability are all components of software quality and all are
>>> affected by complexity. Less complex systems are easier to
>>> maintain.
>>>
>>> To continue the aside, wasted energy is wasted energy and it may
>>> become a factor in software development at some point. I think
>>> decision makers should be taught that there is more to the bottom
>>> line than dollars and cents.
>> 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.
>
> -Terence
>

 From Christopher Shultz 2/14/2013 (comments inline):

Terrence,

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
browsers/versions/etc.

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
interfere.

 > 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.


------------------------------------------------------------------------------------------------
The generics problem doesn't seem like that big a deal.  Add types to 
your declarations and remove the casts.  If the software already works 
without generics, the hard part is done.  Converting is purely 
mechanical and the compiler will pinpoint the lines that should be 
changed for you.  Also, if you can make the changes in the course of 
some other modification, they really don't represent a lot of 
programming overhead (or technical debt as you call it).  In some cases, 
you might not even want to convert.
------------------------------------------------------------------------------------------------


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.


------------------------------------------------------------------------------------------------
If you recall, I said there should be a really good reason to add 
significant complexity, performance overhead, memory requirements and 
megabytes of code to an application.  I didn't say there weren't any.  
And I never advocated eliminating "off-the-shelf" software as a 
consideration.

-Terence
------------------------------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message