As web developers, one of the most under-appreciated pieces of software in our arsenal is the web server software that answers the calls from the masses of visitors that want nothing more than to pour over every word and image that we put on our sites. Ok, “masses” and “pour over” may be a bit of an over characterization, but you get my point. Without that critical piece of the developer’s toolbox, getting to all the sweet, whiz-bang stuff that we develop on a daily basis wouldn’t be nearly as simple as it is today. Yet, many developers don’t understand how to make their web server software go from an afterthought to an integral part of making your development process more efficient.

There are two main web server packages that developers use in their development environments today–IIS and Apache. Since I’m a Mac guy, Apache is the only one of those two options available for me. Apache gives me the ability to run multiple local web sites through what they call “virtual hosts”. As a consultant that works on many different projects over the course of a year, this feature is critical in cutting down on the time spent moving from one project to another. Before I switched to the Mac platform, I used IIS on Windows XP. With that version of IIS, you could have as many virtual hosts configured as you wanted, but only one of them could be “active”, or browsed to, at any time. I’ve heard that with the advent of the new version of IIS included in Windows Vista, this restriction has been lifted, but I don’t have any experience with Vista to confirm or deny that. Regardless, even if you use the Windows platform for your development, you can still take advantage of Apache as it will run on nearly every platform out there that you might be developing on.

Apache stores its configuration in an easy-to-edit standard text file called httpd.conf located in the /conf folder under your install location. Many folks used to point-and-click configuration of their web server are initially put off at having to wade through the sea of configuration directives that live in that file. Honestly, it can be daunting to attempt a full configuration from a base install so it is generally best to “nibble” at the configuration changes and test incrementally.

As of right now, I’m running Apache version 2.2.6. Version 2.2 brought several features, but there is one in particular that convinced me I needed to upgrade from the 1.3.x release I was running before–the ability to separate portions of your configuration file into other files and have them loaded into Apache at startup. Why was that a killer feature for me you might ask? Remember how I said that I run several local sites at any given time? This feature gives me the ability to create a .conf file for each individual site instead of having to search through a potentially 1000+ line config file if I need to make a change to how that site is configured. It also gives me the ability to script the creation of those files when I set up a new project which saves me time and means that I don’t forget something.

I set up all my web roots under the /Sites folder in my home directory. I have a specific folder structure that I’ve come to like over the last few years of doing development locally. Your situation may or may not call for all these, but this is what seems to work best for me at the moment. Notice I said “at the moment”. Like a lot of things, I’ve been through several iterations and have distilled this down each time to get to what works best for me. My specific folder structure is shown in the figure below.

Web Root Folder Heirarchy

I’ll quickly go over why I’ve configured my sites this way and what each of these folders is for.Each project has it’s own root under a folder for the particular client it belongs to. I’ve chosen to use the reverse domain notation as a naming scheme for my project roots because it helps me keep things organized (and not just because the Java guys do it). Under each project root I create 3 folders:

  • /dev – This is where I write and test my code. The contents of /trunk in my Subversion repository are checked out to this folder (more on Subversion later in the series). It’s also the root of the project that I set up in Eclipse (more on that later too).
    • /html is the “document root” for the Apache virtual host for this site (named www.sitename1.local.conf). I typically create an entry in my hosts file as www.sitename1.local to point to the local web server. Doing this is a little more typing when you’re firing up the site in a browser, but it helps keep track of what local site goes with what project.
    • /lib is used to put any external JAR files or other third-party components that might be required by the Ant build process. I don’t specifically cover Ant in this series, but there is a ton of information on using Ant to make your development life more productive.

2 thoughts on “My Local Web Development Environment Overhaul Pt. 2 – Web Server

  1. David Stamm

    Thanks for this excellent series!

    My little shop is working on standarding our dev environments (Apache on Windows). We’ve been using .htaccess to keep configuration portable, but I’d never heard of this “.conf” file until reading your post.

    I’d love to know more about it, but I can’t find anything about on Apache’s site or by Googling. The leading dot gets chopped, and many things Apache involve the word “conf”. :)

    Can you point a brother CF developer in the right direction?

  2. @David

    Thanks for the kind words about the series. A good starting point for the overall development environment is the ACME Guide by Stephen Collins.

    As for Apache specific information, you need to read up on Apache’s VHOSTS features. Here is the direct link into that section of the Apache docs.

    I use the “named virtual host” method that they mention there. I give a site an address something like projectName.local and create an entry in my hosts file to point projectName.local to 127.0.0.1. That way, when I browse to it, the request gets sent to my local Apache install.

    Then I set up an entry for the virtual host in the httpd.conf file similar to the code below :

    <VirtualHost *>
    ServerAdmin someone@somewhere.com
    DocumentRoot “/Users/username/Sites/companyName/projectName/dev/html”
    ServerName projectName.local
    ErrorLog “logs/projectName-error_log”
    CustomLog “logs/projectName-access_log” common

    <Directory “/Users/username/Sites/companyName/projectName/dev/html”>
    Options Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
    </Directory>

    JRunConfig Serverstore /opt/JRun4/lib/wsconfig/1/jrunserver.store
    JRunConfig Bootstrap 127.0.0.1:51020

    </VirtualHost>

    In your case, the path would be something like “C:/path/to/my/web/root” (notice the forward slashes. Those are important to Apache and it won’t work if you use the normal Windows backslashes (or at least it didn’t used to when I used to run Windows on previous versions of Apache).

    In my particular case, I create a separate file for each of these virtual hosts config files and they get included into the main httpd.conf Apache config file when Apache starts up. In my scheme, this one would be named projectName.local.conf so that I can easily keep up with what config file matches what project.

    There may be some other slight differences in the directives that you can put inside the VirtualHost tag for Windows than for my Mac setup, but that should be pretty close.

    Hope that puts you on the right track. Like I said above, where I am now is the result of redoing my entire environment 2 or 3 times over the last few years and refining things.

Leave a Reply

Your email address will not be published. Required fields are marked *

*