Configurator

This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. It does not describe an actual complete program. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; I have too many other projects of my own.

I do contract work for a living, which could include writing a program such as this. However, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project any way you please.

Consider how much trouble people have configuring complex programs like Tomcat, MySQL, PostgreSQL, Resin, etc. The problem is partly the atrocious documentation. The problem is documentation that treats basics and esoterica alike so you have to read pages and pages of options hardly anyone ever uses to find the meat. The problem is the lack of examples. The problem is documentatation rarely gets down to the nitty gritty about how it interacts with some other package, just some highly abstract hints on how its generic hooks work.

There are several ways you could fix this:

Kidnap the authors of these programs, give them access to professional editors and force them to write proper documentation at gunpoint.
Write tutorials to help people get started in these various packages.
Write configuration wizards to help them get started.

I suggest wizards as the best approach because there is no point in forcing people to learn a skill they will use only once. Wizards can silently incorporate lore without having to burden the user with it.

The Java wizards you are about to write query the user, poke around on their own to find out things, and compose the various configuration files and copy files where they are supposed to go, and warns the user of missing files.

They might even compose skeleton test programs to exercise the configurations to prove they are working.

As you become very familiar with the programs you are configuring, you will be tempted to ask questions that presume your background knowledge. You need a constant supply of virgin testers to make sure you only ask questions that nearly all your users will understand. Think in terms of your mother as end user to help keep you on track. Users are not stupid, just unaware of how how these packages work. You must provide sufficient background to help them answer the questions accurately. Don’t be afraid to use rules of thumb. Fine tuning is not your problem, just getting a working initial configuration. Neither is it your problem to teach all the fine points of configuration to your user. He just wants to get through this step so he can start experimenting.

The biggest problem with this program is that it will go out of date quickly. It should be implemented as a JAWS program so that it stays up to date. It is also concerned with connecting packages written by authors who have never met, e.g. Hibernate and MySQL. This lore will change every time any of the constituent packages change.

If you want to be nominated for sainthood, this project might do it. You will save so much gnashing of teeth.

	Please email your feedback for publication, errors, omissions, broken/redirected link reports and suggestions to improve this page to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
	Your face IP:[38.103.63.17]	The information on this page is for non-military use only.
	You are visitor number 581.	Military use includes use by defence contractors.
	You can get a fresh copy of this page from:	or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
	http://mindprod.com/project/configurator.html	J:\mindprod\project\configurator.html