Welcome to The Cafes, a new site from Elliotte Rusty Harold for content that’s longer than a blog posting and shorter than a book.
This site is currently alpha at best. While I encourage you to bang on it, please do not expect it to be stable, at least not yet. As The Mythical Man-Month taught us, “Plan to throw one away. You will anyway.” This is the one I plan to throw away. If you post really long, well thought-out comments, please, please, please save your work on your local system first. I make no promises that early comments will be preserved here or even accepted into the database in the first place. The comments system is held together by duct tape and spackle (and PHP, and MySQL, and a few other tools). Even if it actually works for long enough for a comment to be posted, the likelihood I’ll be able to preserve all those comments over a period of years or even weeks is not good. I expect I will need to do major reengineering on the back end sooner rather than later that may involve throwing it out and starting over from scratch.
Given these admitted problems, why roll my own system from scratch rather than use any of the much better engineered open source systems? The answer will be found not in the back end but the front end, which in at least one crucial way is going to be a huge leap forward from any commenting system I’ve ever seen. Of course, after I reveal it to the world, I’m sure somebody’s going to point out that www.somewhere.I’ve.never.seen.org has been doing exactly this for the last six years; but none of the content management systems I explored seemed capable of handling it without major transplant surgery.
Given my known predilection for Java, you may be asking why I implemented this site on top of PHP instead of JSPs and servlets. The short answer is that Tomcat, and everything that sits on top of it, is an almost undocumented, uninstallable, unmaintainable mess. Note that I am not criticizing the servlet APIs or JSPs here. If I were actually confident that I could install Tomcat, integrate it with Apache, keep it running, and successfully deploy servlets and JSPs on top of it, I would be happy to write Java code instead of PHP. However, the fact is I’ve not been able to keep even the simplest, trivial little servlets running for the last two years, and I think Tomcat is largely responsible for that. Programmers and system administrators are users too. Sadly no one pays much attention to the proper design of user interfaces for this class of users, and Tomcat’s a classic example of that. I attribute this about half to poor design of the servlet deployment system and half to inadequate documentation. PHP is just so much simpler to deploy than JSP that I’d rather learn a new language than struggle with Tomcat one more time. In fact, now that I’ve got PHP deployed on this server I think I’ll rip out the few servlets I do have “running” here (actually, they’re down again at the moment and I haven’t yet figured out what went wrong this time) and replace them with PHP when I get a minute.
Not that PHP is without its own problems, of course. I did have to manually edit the autoconf file to get the Tidy extension installing correctly, and the config options should be a lot clearer about which directories one should actually point to for extension libraries, and whether one needs to point to them at all. Nonetheless. even with these problems, installing PHP was an order of magnitude easier than installing Tomcat and at least two orders of magnitude better documented.
Now that I think about it the difficulty of installing Tomcat (and other server side software) is another symptom of the same attitude that led me to write my own comment system. The problem is that the user interface is far too tightly coupled to the back end. Most programmers start by designing the back end. Then the front end has to fit within the back end’s limitations. The best case scenario here is that the front end is designed by a competent user interface designer who does the best job they can within those limitations. The worst case scenario is that the same programmer who does the back end also writes the front end. In that case, the front end matches the back end way too closely, and it exposes details that the end user should never see or care about it. For instance, consider the classic Unix install from source:
$ ./configure $ make $ sudo make install
Why are these three separate steps? Why not just “install”? I understand why these are three separate steps for developers, but end users should not need to go through this rigamarole. Sometimes there’s a Debian package or an rpm that makes this a little easier, but all too often it has unresolvable dependencies or is based on an out of date version, or the wrong architecture, and you have to go back to source.
Many packages then add additional steps, for instance modifying Apache’s httpd.conf file, before anything will work. This should be done automatically. PHP almost figured this out. It added the necessary “
LoadModule php5_module” command to my httpd.conf, but I still had to use vi to add “AddType application/x-httpd-php .php .phtml” to httpd.conf before it would work. Why couldn’t it have done this automatically?
These installation procedures are designed around how the product developers think about installation rather than how the end users think about it. Breaking out configure, compile, and install as three separate steps makes sense for the programmer hacking on the product’s code. It does not make sense to the sysadmin installing a finished product. That user just wants to say “Install this”, and maybe be asked a couple of questions about where to put the product, which options to include, and whether or not to restart the server when the installation is through. If the installation system had been designed up front, by simply sitting down and saying “What do we want the users experience of installing our software?”, without any consideration of what was expected from the back end, then this would have been obvious. Instead installation was left to be hacked together at the last minute on top of a build system the programmers already had lying around, full of extra options no end user should ever actually touch. This is insane troll logic! A build system is not an installer. Build systems, make files, Ant and the like, are all fine tools for programmers; but they are not appropriate tools for end users or system administrators, even if those users and sysadmins are programmers in another life. Installing software requires an installer, not a build tool.
And this is just one small example. There are many other ways in which the user interface gets tied into the developer’s model of how the system works, rather than the end user’s model. If we begin by designing the user interface that allows the user to complete the tasks they need to complete, and only then design the back end to support this, we will at least develop a backend that can support the front end. All the content management systems I looked at were so tied to the what back end expected that I couldn’t even implement my front end without hacking code in the back end. It was impossible to sit my front end requirements on top of their back end.
By the way, this is all very much a Unix problem. The Mac doesn’t have it. One of the products I evaluated and gave up on on Linux (Plone) installed like a charm when I first tested it on my Mac. No muss, no fuss. In fact, I’m seriously considering whether any future servers I buy should be Macs, just for the ease of deployment.
But Mac programmers have always been a weird bunch of ducks, like a few wood ducks mixed in with a flock of mallards. More often than not, Mac programmers do design (and sometimes even code) the user interface first, before they write the back end to support it. In too many other development groups, the user interface is the last thing done rather than the first.