Re: [OT]Maybe there should be a tomcat connectors list?

[Mark Eggers <it...@yahoo.com>]

Kevin,

I am going to disagree with almost every point in your
mail message.

1. I personally think that Microsoft documentation is
some of the worst I have ever read.  While it enables
me to bring systems up, it gives me no real
understanding of the software.  For that, I have to
rely on third party books, personal experience, and
usenet.  Or very expensive training . . . .

2. Many of the open software packages now have third
party companies willing to support them (for a price).
 Choosing support from these companies depends on your
in-house expertise and comfort levels.

3. I agree, the documentation quality of many open
source software packages remains challenged.  Then
again, the documentation for something like Perl is
completely beyond most anything I have seen for
commercial products.

However, I think this is also a perception in that the
documentation from commercial companies is slickly
produced and marketed, whereas the open source
documentation is not as nice looking.  Hopefully
Apache projects like Forrest will change that.

That being said, I think a different approach needs to
be taken when working with open software projects than
with commercial projects.

1. Proceed methodically
In other words, walk before you run.  I know, with
deadlines approaching and complex software to
configure / run the temptation is to just 'slam it in
there'.  With commecial software, this often works,
but you're left with a less than optimal environment. 
With open source software, this often doesn't work.

2. Assume that the basic installation and test
procedures work.

I know, assumptions make . . . . However, most open
software packages do at least install and test OK
(caveats for the CVS checkouts).  If the install and
test procedures are not successful, then a more
deliberate (see step 1) reading of the instructions is
probably warranted.

3. Learn something about compilation

You do not have to be a coding wizard in
C/C++/Java/XML in order to understand the output of a
make command.  Being able to read the output and see
that you're missing a required library or file,
wondering why you need a jar file to compile C code,
or that paths seem to be off by a level go a long way
in solving most build and install problems.

4. Document

I've gotten into the habit of either doing my builds
in emacs to keep a text record of everything I do, or
having a text editor open where I can take notes. 
Once I am successful, I clean up my notes so that if
I'm run over by a truck (surprisingly likely since I
bike a lot), other people will not have to recreate
the wheel.

These are my opinions and experiences only.  Your
mileage (especially with your executive management)
may differ.

HTH
/mde/
just my two cents . . . .

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

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