[turba] Re: turba Digest, Vol 410, Issue 1

[Eric S. Johansson]

turba-request at lists.horde.org wrote:
> Message: 4
> Date: Tue, 28 Oct 2003 15:38:47 -0600
> From: Eric Rostetter <eric.rostetter at physics.utexas.edu>
> Subject: Re: [turba] horde db shortcomings
> To: turba at lists.horde.org
> Message-ID: <1067377127.3zgm43721v5s at mail.ph.utexas.edu>
> Content-Type: text/plain; charset="ISO-8859-1"
> 
> Quoting "Eric S. Johansson" <esj at harvee.org>:
> 
> 
>>If you read what I wrote, you would see that I had a read all the
>>documentation pertaining to the horde suite.  I have been reluctantly
>>using Horde for about two years.  It has always impressed me that how a
>>project with such promise can be crippled by such poor documentation.
> 
> 
> Then why not contribute to it?

see previous posting where I said yes and included a sample of my notes

> 
>>so, if I included a database in one of my projects, I would give
>>instance implementers complete instructions on how to set up the
>>database completely because it is a bad assumption to assume that the
>>user of your project gives a care about databases.
> 
> 
> What is missing from our instructions that would make them complete in
> your opinion?

in my notes, I outlined a series of details that would not be obvious to 
someone well versed in the failings of an application.  It's a common 
problem when folks, who are too close, try to write documentation.  You 
need the bruised and bloodied experience of a novice to the program to 
really show you what is right and what is wrong.

> Nope, not so.  If a tool is hard to use, it should only be discarded if
> a better option exists and is feasible for the user.  Otherwise, you should
> still use the tool.  If there is nothing better, and it is hard to use,
> and you don't like that it is hard to use then you should either improve it
> or work with the manufacturer to improve it.

another option is to walk away entirely as I may be doing with horde.  I 
did a quick survey of a few folks in my circle and most of them agreed 
that using Horde is a last resort application.  If IT professionals have 
this attitude from their experience, the project can do what it wants 
but it does have a problem that is driving people away.


>>when you look at the actual instructions for setting up turba, they are
>>for the most part sufficient if you're into fiddling.  It is not what I
>>would consider adequate for a production environment.
> 
> 
> What would you consider "adequate" (sic)?  Why are they not sufficient without
> "fiddling?"  What kind of "fiddling" did you need to do?

adequate is the set of instructions that give a 90 percent success rate 
when followed by an administrator with a couple of years experience.  Do 
I make this all the time?  No.  But it is the goal.

the fiddling was I needed to use a completely different command line 
switch set from what was given inside of the documentation and I had to 
guess that what user I needed to be when running the scripts.  Yes, I 
could piece together.  Yes, I eventually learned that I could ignore the 
connect error warning but this begs the question of why should anyone 
have to.

> Which instructions are those?

  /var/www/html/horde/turba/scripts/drivers/pgsql_create.sql

the file says:
-- Run as:
--
-- $ psql -d pgsql_create.sql

and I have documented the results and fixes in other messages.

>> There is no explanation is no description of what the final
>>result should be in terms of tables, entries, permissions, or ownership.
> 
> 
> The scripts themselves document that.

they do after a fashion.  But that's one of my main points against 
databases as implemented.  In order to use calendaring, you need to 
become a DBA.  That makes me extremely uncomfortable.  I could not make 
a recommendation to any customer to take on that kind of risk unless 
they already had a DBA on staff who was underutilized.  And even then, I 
would recommend they think twice about that.


>>  You have no precondition or post condition documentation.  you have no
>>metric to tell the implementer how to know when they are done.
> 
> 
> When the script finishes running without error you are done.  What more
> do you want to know?

if all the scripts run without error then fine.  you need this 
additional detail for when things don't go without error.

> I got it running, and was no expert in postgresql.  In fact, I installed
> postgresql for the first time to run horde/imp.  No problems.  So I'm not
> sure where your problems are, or how to fix them, since you provide no
> specifics, no patches, no suggestions, etc.

I have posted the failures so many times, it got kind of redundant.  But 
since you asked...

Notice: Undefined index: businesscategory in 
/var/www/html/horde/turba/templates/browse/search.inc on line 14

Notice: Undefined index: homephone in 
/var/www/html/horde/turba/templates/browse/search.inc on line 14

Notice: Undefined index: workphone in 
/var/www/html/horde/turba/templates/browse/search.inc on line 14

Notice: Undefined index: cellphone in 
/var/www/html/horde/turba/templates/browse/search.inc on line 14

I'm currently heading down the rathole of figuring out how to turn on 
logging.  I've managed to stump the very helpful people on the 
postgresql novice list.  According to them, everything right and I'm 
looking in the right place but it just doesn't work.

>> is this some kind of IT jobs program?
> 
> 
> No.  It is a bunch of busy people.  It is open source, meaning if you want
> something changed, you have to put some effort into it.  Complaining will
> not fix anything.  Making constructive comments, submitting patches or
> additions, subscribing to the docs mailing list and discussing things in
> a non-antagonistic method, etc. on the other hand will fix problems.

I apologize for my sharpness.  It was a combination of frustration and 
coming down with the flu.  I do not say this as an excuse but as an 
explanation.

> Well, once a mind is closed by prejudice...

I probably deserve that.  I will tell you that in the past 20 years I 
have not seen a single database intertwined project do anything but fail 
in some way shape or form.  I am open to positive examples but I haven't 
seen any.

> 
> You have shown no interesting yet in helping us.  It is open source.
> Please help.  But vague comments like you have made are of no help.
> Saying "the docs are bad" does not help in any real way.  You need to
> be specific.  Until then, don't blame us, blame yourself and the other
> users who are not trying to help in the spirit of open source projects.

again, I refer you to the archives.  I have posted more constructive 
commentary and if my project is not killed, I will continue to expand my 
notes about documentation shortcomings and provide then to the project 
to do with as they see fit.

...

>>Hats off, Eric.  Well said.
> 
> 
> No, poorly said.

it may have been poorly said but the emperor still has no clothes.

If you consider the dynamics of mailing lists and the strong reaction 
anyone gets when a project is criticized, the fact that Lee spoke up in 
reaction to my post, is an indicator not unlike the canary in the coal 
mine.  The issue is there.  The indicators are there.  The question is 
how you choose to respond?


> Message: 6
> Date: Tue, 28 Oct 2003 16:09:15 -0600
> From: Eric Rostetter <eric.rostetter at physics.utexas.edu>

>  But DB programs change over time, and if
> the scripts don't, then they break.  In many cases, the psql code used
> to work with older postgresql code, and is broken with newer code.  In some
> cases, people have changed the code so as to break it with some versions.

seems to me the obvious solution would be to keep two versions of the 
code.  The current rev and the previous rev.


>>otherwise no database scripts should be supplied in the user should be
>>left to enter what ever schema was required manually.  supplying scripts
>>that cannot work right is actually worse than the second option.
> 
> 
> Your assumption that they "cannot work right" is flawed.

actually no.  If a given script has a bug in which keeps it from 
functioning, then it cannot work right.  I contend that the scripts 
setting up the database is flawed in at least one instance on the 
command line instructions and commonly in terms of context of execution 
(i.e. run as root?  Run as postgres?).  One can make a reasonable guess 
but then you are operating on the basis of superstition because without 
becoming a fully knowledgeable DBA, you probably won't know why the 
reasonable guess is right.


>>>If you don't want to do this setup, I'm sure you can find a consultancy
>>>outfit more than willing to assemble it for you for a modest fee.
>>
>>it's never a modest fee.
> 
> 
> Thanks for insulting a whole (though small) sector of consultancy outfits
> based on your flawed belief.

not a problem.  I have billed and I have been billed for consulting 
services and if it is modest, you probably lost money on the project. 
It also, of course, depends on your definition of modest.  In most IT 
shops, modest is under roughly $70 per hour.  People that charge that 
little are either not very experienced or imported talent.

postgresql per incident support is 199$/hr which I think we both can 
agree is outside the realm of modest.


> So? Have someone teach you, then teach them.

I've been trying.  And I've been stumping them.

>>consultancy that sees this kind of task as a one shot job instead of a
>>lifetime meal ticket.
> 
> 
> Yes, it may be rare, but it does exist, contrary to your above statements.

see apology above for inconsistency reasons.  I agree that it is rare 
and I know of at least one instance where it exists.  and am always 
fighting for my clients to make them aware of the meal ticket organizations.


>>It's like the rent-an-IT-department outfits.  As
>>a rule, they will sell solutions that maximize their billable hours
>>instead of what's right for the customer because they live or die by the
> 
> 
> That is a separate issue.

not exactly.  People are motivated by economic need.  Not solely but 
heavily.  Consultants like to find and develop long-term relationships 
with a customer so they can maintain a long-term revenue stream.  This 
minimizes sales cycle overhead and risk.

Unfortunately, some consultants don't always behave in the customer's 
best interest and create a jobs program for themselves or their 
organization which keeps the billable hours going.  Whenever you are 
purchasing consulting or selling consulting, you must always be 
cognizant of that relationship trap.

my experience shows that databases are one of those job program risks. 
They are very high maintenance pieces of software that run beautifully 
for awhile and then fail for no apparent reason if they are not swept, 
vacuumed or some other high touch operation on a regular basis.  If you 
do not bring the knowledge in-house, you are at risk for funding a 
consultants jobs program.

Now the trick is, something like horde didn't need to use a database the 
first place.  But since it did, it has now created a money sink for any 
organization that uses it.  That's one of the risk factors you have to 
advise your customer when using horde


>>billable hour.  Notice what OS and applications they tend to use. ;-)
> 
> 
> Linux?  Okay, I know what you mean, but I assure you there are low cost,
> linux based, reputable, "one shot" consultants out there that would have
> done this job for you (maybe not any more since you've insulted them
> multiple times now).

I am sure they have heard worse and can get over it.  I know I have.  I 
don't need them to do the job for me.  I need is someone I can ask 
questions of and figure out why the &%^%&*@# the database doesn't work 
and won't tell me anything in the logs.

maybe I should just go to mysql.

---eric

-- 
Speech recognition in use.  Incorrect endings, words, and case is
closer than it appears