Since the day I joined Franz Inc. as the new Webmaster, I have been
writing more code than at any previous point in my career. I have
become immersed in Lisp programming, specifically AllegroCL, which I found to be a
stimulating challenge to learn. I discovered that writing Lisp is
sheer joy to anyone who has ever been frustrated out of programming by
the tedium of obligatory declaration of data types, allocation and
de-allocation of memory and the like, or simply by the time they take
to learn. To finalize my education in AllegroCL, I was tasked with
replacing the Franz webserver with AllegroServe. Though I am not a
slow student, I made many mistakes and found that the simplified
testing of code via the AllegroCL debugger and the ability to modify a
program while it is running were indispensable tools both in my
education and software troubleshooting. Making use of these features,
I have found that adding new code to a program is remarkably easy to
do, even when that new code requires making significant structural
changes. In the end, I'm always left with a program which runs as
quickly as any others I use and exhibits enhanced stability and
security features while maintaining a reasonable memory footprint.
Among my first tasks at Franz was familiarizing myself with
Allegro Common Lisp. My interest in Lisp's long, rich and diverse
history was one of the chief reasons I applied for the job, so I was
happy to oblige. I've always found the history of computing to be of
great interest, and Lisp has been there throughout most of the last 50
years (of currently-used languages, only Fortran predates its
nativity), so I find its endurance of especial interest. Lisp has
undergone a process of evolution during its lifetime spawning several
dialects, one of which is Common Lisp; AllegroCL is an implementation
of Common Lisp.
The aspects which I find most satisfying in AllegroCL include
automatic memory management and dynamic typing of data. Both of these
features eliminate a tremendous amount of tedium from coding and allow
me to get more work done in less time. I was never a serious
programmer before I was introduced to Lisp, but now I've found a
passion which outweighs my penchant for computer gaming. In the past,
I would frequently spend much of my free time mastering the newest
reason to own a 3d-accelerated video card, but recently I've found
that I have more to show afterwards if I write code for fun, as
evidenced by the chatroom software I wrote as an educational exercise
which can be seen in production on my server at home, here
(running on AllegroServe). It took a little longer to write the chat
software than it usually takes me to master a new game, but at a total
of 16 hours, it was less than half the time that most games take to
complete. I began working more and producing a tremendously increased
level of output, all without the slightest increase in my stress
level.
After spending a couple of months with Franz, familiarizing
myself with my responsibilities as Webmaster while learning Allegro
Common Lisp, I was tasked with converting the Franz website from Apache webserver to an AllegroServe-based
solution, which entailed writing a webserver which used AllegroServe
at its core and provided all of the features which I found in Apache,
while adding a few site-specific features. AllegroServe's chief
developer, John Foderaro, and I were able to complete this task in
time for the recent release of AllegroCL 6.1. The speed of
development under AllegroCL was due in no small part to the ACL
debugger of which I made prodigious use early-on. The ability to
inspect running code and make modifications at the point of failure
not only made it a simple matter to identify and fix bugs, but it was
also an invaluable educational tool. Initially, I wrote bad code -
lots of bad code - but every mistake I made was immediately obviated
and resolved through liberal application of this handy tool. The
ability to directly interact with data in a running program provided
education that extended beyond the scope of any single programming
language, my ability to visualize software structure and the flow of
data was greatly enhanced.
After a few weeks of use, I began to realize that I wasn't
having more than one bug in my code every few days - needless to say,
I was elated. Until this point, I was working on relatively simple
aspects of the webserver, such as the Franz menu generation, customer
survey, and trial download sections. This accelerated rate of
learning gave me enough positive feedback that I felt comfortable
taking on more ambitious segments of the project. After I progressed
through the header, menu, and footer-wrapping code which provides the
interface to my earlier menu generator's output on Franz' "lhtml"
pages, I came to the logging facility. By far, writing the code to
manage the log handling was the most challenging aspect of the
webserver's design so far. It was at this point that John and I came
to realize that we would need to significantly enhance the
virtual-host capabilities of AllegroServe to provide such services as
separate access and error log streams for each individual virtual
host. Despite the challenge, John managed to implement these changes
in less time than it took me to write the code to handle formatting
the logfiles in a manner compatible with Apache's output, which Franz
especially required to enable the continued use of certain website log
analysis tools. The two of us had completely changed the manner in
which AllegroServe handled logging in a mere two days. John also
eventually added excellent support for running standard CGI programs
which would have their own log streams, and I made use of the added
functionality to support a "cgiroot" which allows the Apache-like
feature of being able to specify a path in which cgi programs will
reside while sending any cgi log output to the vhost error log. I
would encourage any current Apache users who wish to try-out
AllegroServe to make use of this feature when configuring a server, it
makes CGI installation and use a snap. After I'd written the bulk of
my contribution to our system, I hit upon another necessary feature,
the ability to include in-tree access control files akin to
".htaccess" files under Apache. This was a significantly more complex
challenge than the logging and virtual host modifications John and I
had previously added, due to the depth of the AllegroServe feature-set
we would have to make available for modification within these files,
and the associated security concerns. This obstacle took a fair
amount of time to surmount, John made significant changes throughout
AllegroServe, and we went through a great deal of testing to ensure
that no security risks had been created. In the end, we were
satisfied that we had made a very worthwhile addition to the
webserver.
I continued writing interface and configuration code and
enlisted John's expert help whenever I would find a feature
AllegroServe lacked, and we concluded the conversion with a version of
the Franz webserver that has only required minor modifications since.
When I had ironed-out any remaining bugs, of which there were
fortunately very few, John assisted me in profiling our code to assess
its speed bottlenecks. After heavily load-testing the server, we
discovered that the slowest part of the code was that used to check
the timestamps on files for the purposes of updating our cache. This
was greatly satisfying because the speed of this code was so fast that
we could not consider this to be a problem. We also discovered that
there was an excessive memory waste within a few seemingly clean
segments of code, we were using a dynamically-sized string creation
function which relies upon the multiple different data types for the
sake of convenience. We converted this to make use of a large
fixed-size array which would contain the string, even if it grew as
long as it possibly could, and halved the server's memory usage.
Bandwidth load testing showed that we had an extremely fast server -
we were able to utilize around 850-900KB/sec. across a 10 megabit
network when running the system on an Intel Celeron 533.
Additionally, thanks to our prior memory-usage enhancement which
came-up during profiling, we were only using a total of 30MB of RAM
for the webserver, cache and all.
I am very satisfied to have had a hand in such a successful
project, especially successful considering that I was a rank novice
programmer when I began work on it. The speed with which I learned to
program in AllegroCL was an entirely new phenomenon to me, one which
has enriched my computer usage and allowed me to express my ideas for
software in code, something I never had the capability of doing in the
past due to my unwillingness to suffer through the tedium programming
had historically presented me with. When I found myself attaining a
satisfactory level of programming ability, I was struck by the ease of
writing clean and modular code on the first attempt. Augmenting that
ability, the ease of adding and restructuring AllegroCL code to a
running or non-running program, especially with the aid of the ACL
debugger, greatly decreased both my development time and my
frustration while further enhancing my level of programming skill. I
have learned a great deal about Lisp, AllegroCL, and programming in
general over the course of this project, and without it I would not
have had the chance to make such a satisfying acquaintance with
Allegro Common Lisp, which has become my programming language of
choice.