Dan's Drivelings » Development Environments

Adding ModelGlue’s event API to ColdFusion Builder’s code insight

Dan Skaggs — Mon, 07 Feb 2011 16:54:23 +0000

For the last year or so, all of my ColdFusion development projects have been built using the Model-Glue MVC framework. Over time, you get to where you know the most commonly used methods that are used to interact with the framework by heart. Sometimes there are lesser-used methods that you have to go look up. All the time (for me at least) I’m trying to find a way to write code faster and with less errors.

ColdFusion Builder has done a very nice job of providing code insight for ColdFusion tags, functions and CFC methods. This is especially true if you have a server configured in the “Servers” panel and mapped to your CF Builder project as it then will provide code insight for your own CFCs that you create on the page. However, when using Model-Glue, the “event” object is created for you and is always there. Because it’s not explicitly created on the page, CF Builder can’t provide code insight when you need to interact with it. However, it only takes a couple of settings in your project to make CF Builder aware of the event object and start providing help for it.

Here’s the process:

Right click on your project and choosing “Properties”.
In the left pane of the window that comes up, click on “ColdFusion Variable Mappings”.
On the right side, click the “New” button and enter the following values into the boxes
- Variable Name: event
- Mapped To: html.ModelGlue.gesture.eventrequest.EventContext
Press the “New” button and enter the following values into the boxes
- Variable Name: arguments.event
- Mapped To: html.ModelGlue.gesture.eventrequest.EventContext
Press the Apply button then the OK button
* Note that the value in the “Mapped To” box is the actual dot-notated path to the EventContext.cfc file from your CF Builder project root. I happen to have my webroot files in a folder named “html” under the project root (see screenshot #1 below).

Once you have those settings saved, any time you type “event.” or “arguments.event.” you’ll get the list of methods contained in the Event object. Of course, this doesn’t only work with Model-Glue. Any CFC that you regularly use the same name with can be configured this same way.

I’ve attached some screenshots for reference. If you have any questions or something isn’t working, feel free to ping me.

Followup to my CFMeetup development environment presentation

Dan Skaggs — Mon, 24 Aug 2009 00:35:50 +0000

Last week I gave a presentation to the CFMeetup group showing how I use Eclipse and Tomcat to develop CFML applications across any of the current CFML engines (if you missed it and are interested, here is the link to the meeting recording). One of the aspects of my environment that we didn’t have time to discuss is the link between the Apache web server and Tomcat. Some people will accurately point out that you don’t really need the Apache web server since Tomcat has a very fast built-in server that you can easily configure to run on port 80 rather than the default 8080. I personally like to try to keep things as close to production configurations as possible so I use the Apache web server when developing locally.

There are a few different methods for sending requests over to Tomcat from Apache. The one that I’ve found most useful uses the Apache module named mod_jk.so. There are 3 steps required to get mod_jk working between Apache and Tomcat:

Install and enable the module in the main Apache configuration file
Create a properties file that tells the module about your Tomcat installation
Modify your host (or virtual host) configuration to tell Apache what kinds of requests should be sent to Tomcat

Installing and enabling the mod_jk module
The first thing that you have to have is the mod_jk.so file located in a place where Apache can find it. Download the pre-built binary for your particular operating system and put it in the folder that contains the other modules for Apache (in my case, on OS X, this folder was /usr/libexec/apache2).

Once the file is in place, you’ll need to edit the Apache config files to tell it how to find and interact with the module. You can put this information in your main config file if you want. Since that main config file tends to be very long anyway, I’ve chosen to put all the mod_jk related configuration in a separate file. I named the file “tomcat.conf” saved in the same folder as the main Apache config file but you can name it whatever makes sense to you. Here are the contents of my tomcat.conf file (change the file system paths as needed for your own setup):

# Load mod_jk module
LoadModule    jk_module  /usr/libexec/apache2/mod_jk.so
 
# Where to find workers.properties
JkWorkersFile /usr/local/apache2/conf/workers.properties
 
# Where to put jk shared memory
JkShmFile     /var/log/httpd/mod_jk.shm
 
# Where to put jk logs
JkLogFile     /var/log/httpd/mod_jk.log
 
# Set the jk log level [debug/error/info]
JkLogLevel    info
 
# Select the timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories -ForwardLocalAddress

This config file tells Apache to load the mod_jk.so module, load the workers.properties file to configure it and then sets some options for how the module will operate. The last line contains some options that are used in URL rewriting that I found on a blog at some point. Since this is a development environment, I’m not sure they’re necessary, but like they say, if it isn’t broken……

Once that is saved, I use the following statement to include this file into my main Apache config file (this is the last statement in my httpd.conf file):

1 2	#Tomcat config Include conf/tomcat.conf

Configuring the module’s properties
You’ll notice the second directive in my tomcat.conf file mentions loading the contents of a workers.properties file. This file contains the information that the module needs to connect to one or more Tomcat server instances. Below is part of the contents of my workers.properties file (with some items made generic):

# Define workers using ajp13
worker.list=server1site1,server2site1,server2site2,server2site3
 
# ----- Server 1 sites -----
worker.server1site1.type=ajp13
worker.server1site1.host=site1.local
worker.server1site1.port=8009
 
# ----- Server 2 sites -----
worker.server2site1.type=ajp13
worker.server2site1.host=site2.local
worker.server2site1.port=8010
 
worker.server2site2.type=ajp13
worker.server2site2.host=site3.local
worker.server2site2.port=8010
 
worker.server2site3.type=ajp13
worker.server2site3.host=site4.local
worker.server2site3.port=8010

This file supports a configuration with 2 different servers set up in Eclipse with different TCP numbers (server1 uses the default Tomcat ports). The server2 config has 3 hosts configured in the server.xml file for that server. The “.host” portion of each configuration matches the entry in each host entry of Tomcat’s server.xml file.

Configure your Apache virtual host
The last step is to configure your Apache virtual host with which types of requests to send through the mod_jk module to Tomcat. I’ve added this entry to my VirtualHost file for the selected vhost:

1 2	JkMount /.cfm server1site1 JkMount /.cfc server1site1

These lines tell Apache to send any requests for cfm or cfc files to the Tomcat instance defined in the worker.properties file as “server1site1″.

Once you’ve got all this in place, you need to restart your Apache server and you should be able to hit your site on the regular port 80 using the URL you set up in your VirtualHost configuration and have the CFML engine running on Tomcat process the CFML code.

Configure FusionDebug 3 Beta for use with Railo 3.1 on Tomcat

Dan Skaggs — Thu, 07 May 2009 13:03:30 +0000

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup. Until tonight that is.

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

Before we get started, I want to detail my particular setup and lay out some assumptions. My environment consists of the following components. Yours might be slightly different, but the basics should be the same.

Apache 2.2.11 web server configured with one virtual host per client site
Tomcat 6 installed into /opt/tomcat
Apache forwards ColdFusion requests to Tomcat via AJP
http://localhost web root is /Users/dskaggs/Sites/localhost/htdocs
WEB-INF folder from exploded Railo 3.1 WAR file resides in the web root folder

Now for some assumptions:

You can browse to a CFML page (either by going directly to Tomcat http://localhost:8080/someContext/test.cfm or through Apache http://localhost/test.cfm )
You’ve installed FusionDebug into Eclipse using the instructions in the “Install FusionDebug into Eclipse” section here
You’ve created a project in Eclipse that points to your site files
You don’t have Tomcat starting as a daemon or Windows service

The first thing that you have to do is tell Tomcat to enable debugging on a specific TCP port. For this example the port number that we’re going to use is 8000 (the same as the documentation on the FusionDebug site). You do this by adding the following line of code to the catalina.sh file in the /bin folder under the Tomcat install directory (in my case /opt/tomcat/bin/catalina.sh). I added it directly under the large comment block at the top of the file.

CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

If you’re on Windows, this file is named catalina.bat and the format is slightly different:

set CATALINA_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Save the file and launch Tomcat. In my case, I launched it in a terminal window so I could see exactly what was going on using the command

cd /opt/tomcat/bin
sudo ./catalina.sh run

If everything worked correctly, you’ll see the following line near the top of the output to the console:

Listening for transport dt_socket at address: 8000

That concludes the configuration necessary on the Tomcat side. Now we need to get FusionDebug configured to connect to that port. In Eclipse, go to Window > Open Perspective > Other and choose FusionDebug from the list that appears in the popup window.

Then you’ll need to open up the Debug Configurations panel by going to Run > Debug Configurations. Find the entry for Fusion Debug in the left side, right click on it and choose “New” from the context menu. Enter a descriptive string in the Name: block at the top of the left side of the screen (I used simply Localhost). Then move to the configuration panel below with the 3 tabs (Connect, Source Code Lookup, and Common).

On the connect tab, enter localhost in the Host: block and 8000 in the Port: block.

On the Source Code Lookup tab, in the drop list that says “”, choose the Eclipse project that contains your files. In the drop list just to the right of the Project select box you just clicked on, choose the folder that corresponds to the web root of your site. Finally, enter the full file system path that corresponds to the folder you just chose and click the Add button. Click the Apply button to save the configuration. You can then click the Debug button at the bottom of the screen to start the debug session. If all goes well, you’ll see “FusionDebug (localhost:8000) (Connected)” in the Debug pane.

Now it’s just a matter of creating a test.cfm file (or using an existing file), setting some breakpoints and browsing to the file and you should see the execution stop at your breakpoint and be able to browse through the list.

Configuring ColdFusion applications on Tomcat with Apache web server

Dan Skaggs — Wed, 25 Feb 2009 17:42:49 +0000

In my last post I mentioned that I had been toying around with using Tomcat as the only servlet container to deploy all my ColdFusion applications to, regardless of what ColdFusion engine you needed to use for a specific project. My goal in trying to get this working was actually 3-fold:

Learn more about how standard JEE servlet containers worked and how to configure them
Remove my dependence on JRun as it is not under active development any more
Be able to have one central place to start/stop each application’s instance as I switch between client projects

So far, I’m 2 for 3 on those goals. What follows is a brief history of what I did in the current iteration, what works well and what I’m still missing to have what I believe is the perfect development environment (at least for my situation). The steps I took here are based on my experiments using Mac OS X, but should be fairly close for Windows users.

Tomcat Setup
The first thing I did was download Apache Tomcat 6 and extract it to /opt/tomcat (any directory will do, that’s just where I wanted it).

At the moment, my Mac uses Java 1.5 as its default JVM (as determined by typing “java -version” into a terminal window). I wanted Tomcat (and by extension, my CF instances) to run on Java 1.6 so I added the following line to /opt/tomcat/bin/catalina.sh just below the large comment block at the top:

JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

The only thing required to start Tomcat is to change to the /opt/tomcat/bin directory and type:

./startup.sh

At this point, you should be able to open a browser and type http://localhost:8080 and see the Tomcat welcome page. This forms the basis of the various attempts that I made to get this set up the way I wanted (and more than once I blew away my /opt/tomcat directory and started afresh).

Host name resolution
Before you can start browsing your site, you’ll need to edit your hosts file (/etc/hosts on OS X, c:\windows\system32\drivers\etc\hosts on Windows) so that the URL you want to use resolves to your local machine. I’m embarrassed to admit how many times I forget this step.

127.0.0.1     siteName.local

Configuring Tomcat to serve your files
The next step I took was to configure a virtual host in Tomcat’s server.xml file (server.xml is located in the /conf directory under your main Tomcat directory). This tells Tomcat to listen for requests on a particular URL (eg sitename.local). Change the file paths below to match the location of the files that you want to serve.

 name="siteName.local" appBase="/Users/userName/Sites/Client/com.projectname.www/" autoDeploy="false" unpackWARs="false" deployOnStartup = "false">
    path="" docBase="/Users/userName/Sites/Client/com.projectname.www/html/" />
>

An important note here is that the appBase value should be one directory level higher than the docBase specified in the Context element. As of Tomcat 6, the documentation suggests alternative ways to specifying the Context element rather than including it in the server.xml. Their reasoning is that including it here requires you to restart Tomcat if there are any changes to the contexts. In my case, since this is my local development machine, that’s not an issue, so I chose to do things the easy way and include it here.

Once this is done, you should be able to browse that same static HTML or image file by using the URL http://siteName.local:8080/.

Apache Web Server Setup
I’m going to assume that you already have your web files configured to be served by the Apache web server and can browse to a static HTML or image file using a local URL (eg. http://siteName.local). In order to be able to browse to your site without specifying the 8080 port number, you have to configure a connection from Apache web server to the Tomcat virtual host we just set up. To do this, I’m using a module for Apache called mod_jk. To get this module loaded by Apache at startup, I added the following code to my httpd.conf file (change the paths to the .so file if needed–mod_jk.dll is the Windows equivalent). Make sure the log directory already exists.

# Load mod_jk module
LoadModule    jk_module  /usr/libexec/apache2/mod_jk.so
 
# Where to find workers.properties
JkWorkersFile /usr/local/apache2/conf/workers.properties
 
# Where to put jk shared memory
JkShmFile     /var/log/httpd/mod_jk.shm
 
# Where to put jk logs
JkLogFile     /var/log/httpd/mod_jk.log
 
# Set the jk log level [debug/error/info]
JkLogLevel    info
 
# Select the timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories -ForwardLocalAddress

You’ll notice that the line that starts “JkWorkersFile” specifies a file named workers.properties file that gets loaded. This file is what tells mod_jk how to connect to the Tomcat server ports.

# Define workers using ajp13
worker.list=siteName
 
# Set properties for workers
worker.localhost.type=ajp13
worker.localhost.host=siteName.local
worker.localhost.port=8009

There’s one more thing we need to do to enable our Apache web server to talk to Tomcat. We need to tell our Apache virtual host what files to send to Tomcat. This is done inside our virtual host block for siteName.local.

JkMount /*.cfm siteName
JkMount /*.cfc siteName

So at this point, we have Apache configured to talk to Tomcat. We also have Tomcat configured to look at the directories where our web files are. However, we haven’t given Tomcat any information on how to handle our ColdFusion requests. The last thing we need to do is to put the contents of the WAR file for our preferred ColdFusion engine (eg Railo).

Configuring Tomcat to Serve ColdFusion Files
This part seems to me to be kind of a hack to me, but it works. I take the Railo (for example) WAR file and drop it into my tomcat/webapps directory. Tomcat will auto deploy and expand the WAR into its own directory. I then grab the files that were auto expanded and copy them to my Apache web root.

Disadvantages
I mentioned that this setup gets me 2 out of 3 of my goals. The only thing that this doesn’t do is give me a central spot to start and stop Tomcat virtual hosts. If you have several projects configured as I do, when you start Tomcat, it automatically starts all those CFML engine instances which can be a drag on your system resources. If anyone has a way around this particular pitfall, I’d LOVE to hear about it.

Hopefully this will help someone. I spent a bunch of hours researching and experimenting with various configurations. In the end, I not only have a stable development environment, but I’ve learned quite a lot on how JEE servers are configured and behave.

To .WAR or not to .WAR?

Dan Skaggs — Mon, 16 Feb 2009 00:22:18 +0000

A week or so ago, Matt Woodward posted a blog entry detailing how to install Railo and Open BlueDragon on Tomcat. Since then I’ve been experimenting with installing not only Railo and Open BlueDragon into Tomcat, but Adobe ColdFusion 8 and MX 7 as well. I’m trying to determine if this configuration is better for me as a consultant that works on a variety of customer projects on various CFML engines. I’ll leave that discussion for a future post as I’ve not decided quite yet what I think.

One thing that this experimenting has me thinking a lot about, however, is the “organization” of the code base for our projects. Here’s the question that I’m working through in my head at the moment. Should we be organizing our application code so that it can be packaged up in a WAR file–whether or not we ever expect to deploy our application as a WAR? I realize that everyone has a different “pet” way they like to organize their project code–I myself have been using a certain standard folder structure that I like for a couple years now. However, my folder structure would not work if you wanted to take my application and package it up as a WAR file that included a specific CFML engine.

As an example, I have been including a /conf directory (for framework XML config files etc) in my project structure that is at the same level as my /html directory (this functions as my web root). Most of us have most likely heard people advocating this structure because it puts the XML files outside of the web root and thereby protects people from being able to browse our XML config files directly to view sensitive configuration data for our applications. This particular organization would break since the context root as defined in the WAR file needs to be the directory that includes my web files (/html in this case). So, I would need to reorganize my project so that any files that need to be deployed via the WAR file would reside under my /html folder.

I’m VERY new to the whole Java servlet container scene, and therefore I obviously don’t know what is possible in the Tomcat configuration files that might address this issue. I suppose it might be possible to use the configuration options in the web.xml or context.xml to modify your project structure, but right now I’m not familiar with how to get this accomplished.

What do most shops do when developing a new application that could be deployed on any given CFML engine? Should we be trying to use the standard Java WAR method or continue to use the methods we’ve all been using to now deploying individual files to a web root on a server?

I’m leaning toward rethinking my project organization to allow deployment via WAR files and using some sort of process in an Ant build script to include a specific runtime depending on what CFML engine is required for the project (or none at all if it is to be deployed as simply files under a web root). Any thoughts or suggestions?

My Local Web Development Environment Overhaul Pt. 6 – Version Control System

Dan Skaggs — Tue, 12 Aug 2008 13:00:48 +0000

If you’ve been doing development very long, chances are you have had at least one “OH CRAP” or maybe even it’s big brother “OH S…” moments when you realized that you’d just deleted something you can’t get back, overwrote some bit of very complex code or done some similar bone-headed thing that wound up causing you a lot of pain. Had you had a good version control system in place and operating, you’d not have needed to uttered either of those phrases.

At their most basic, version control systems are nothing more than a historical record of every change made to the files that are contained in them. Now, most modern systems have many more functions that just that, but at the core, that’s what they are designed to do–make it possible to recover historical versions of various assets.

I’ve used 3 different version control systems in my career so far–Microsoft Visual Source Safe, Concurrent Versioning System (CVS), and Subversion (SVN). By far my favorite and the one I currently use for all the projects I have control over is Subversion. There are others out there including PVCS (a real bear to work with from what I hear), Git (a fairly new entry into the space that is making a lot of heads turn with its new approach to distributed development) and probably others that I don’t know about.

I currently have my Subversion server outsources to CVSDude. I may be changing that in the near future as I was turned onto the Buildix package from ThoughtWorks that includes Subversion, Trac and CruiseControl pre-configured to work with one another. If I have time in the next couple of months, I may set up a new VPS with my VPS host and dedicate it to SVN/Trac/CruiseControl duties.

I won’t go into all the features that Subversion offers here. Suffice it to say that it is robust enough to be used by teams of several hundred developers that interact with massive code bases. However, it’s not just for the “big guys”. Even a single developer can see real benefit from it not only as “OH CRAP” protection but as a means to track build versions and provide a synchronization mechanism for those folks that work across more than one computer–and that’s just to name 2 things off the top of my head.

I made the decision a while ago that I wasn’t going to work on any projects that weren’t housed in Subversion in some fashion. If the client doesn’t have their own in-house SVN server, I create a project on mine. I’ve learned the hard way that it’s better to use my own server resources than to do something stupid and lose hours or days worth of work with no way to undo my mistakes.

As I discussed in my last post, my Subversion client of choice at the moment is Subclipse which is a plugin to the Eclipse framework. I really like having the ability to right click a file, folder or entire project and find the commands for interacting with the SVN repository right there, without ever having to leave the program I use to create my code.

My Local Web Development Environment Overhaul Pt. 5 – IDE

Dan Skaggs — Fri, 08 Aug 2008 13:00:26 +0000

I realize it’s been just over a month since the last post in this series and for that I offer my apologies. Several things, both work-related and personal have kept me very busy over the last month–hence the couple of short posts in the interim. However, I didn’t want to let this series die before it was finished so I’m going to attempt to wrap up the last two parts in the next few days.

This entry in the series is going to focus on my editor-of-choice–features, a gotcha or two, and why I chose to standardize on it.

As I said in the initial post in this series, I made the switch to Eclipse/CFEclipse just about 2 years ago as my main, day-to-day editor. Like a lot of people, I started out with ColdFusion Studio (version 4.5 in my case) and used it almost exclusively until ColdFusion MX came out thanks to the updated extensions that provided support for the new features in ColdFusion 5. From there I actually spent 2 or 3 years doing all my coding in the code view of Dreamweaver (don’t laugh, if you didn’t use all the WYSIWYG features of Dreamweaver, it wasn’t that bad).

About 6 months before I made the switch to CFEclipse permanent, I downloaded it to give it a try. Not understanding all the workspaces and projects concepts that it introduced as a method to managing multiple code bases, my trial didn’t last long and I soon went back to Dreamweaver. Not long after that I began getting interested in doing Flex development with Flex 2. I downloaded the standalone Flex 2 IDE (which is Eclipse based). Not long after that I sat in on a presentation by Charlie Arehart via the CFMeetup group talking about the virtues of step debugging and introducing FusionDebug from Intergral (which was also Eclipse-based).

At that point it began to be a real pain to switch back and forth between Dreamweaver and Eclipse (FusionDebug) so I decided to give CFEclipse another try. I’m not 100% for certain, but I think Mark Drew released at least one new version of CFEclipse in the time since my first trial. Once I figured out how to arrange my workspace and how to correctly set up projects (both stand-alone and from Subversion) I really began to enjoy the fact that all these tools were available in a single application simply by changing “perspectives”.

By the way, that’s the gotcha that I mentioned. If you are considering trying out Eclipse/CFEclipse, do your homework on how your projects should be structured and configured. I’ve probably been guilty of trying 3 or 4 different setups before finding the one that suits how I work. I’ve tried different workspaces for each client (but then you have to replicate all your preferences from one to another and that gets old). I’ve finally settled on putting all the projects in one particular workspace and setting up different “working sets” for each client and including only that client’s projects in the working set. Working sets are quick ways to filter then entire project list down by client.

As I hinted earlier, one of the main reasons I decided to make the switch to Eclipse was the fact that you could run so many kinds of editing tools within the same application. Eclipse at its core is a framework for building IDEs. You add additional language capability to it by installing plugins that are developed by 3rd parties. CFEclipse is one such plugin and is developed by a team of folks lead by Mark Drew. Other plugins I use include Subclipse for access to Subversion repository access, Flex Builder 3 from Adobe for creating Flex applications, XMLBuddy for, you guessed it, XML editing, SQL Explorer for interacting with different kinds of databases and occasionally JSEclipse from Adobe for doing Javascript work.

The other primary reason that I use it is because Mark and company are actively developing on it and adding new features. CF Studio / HomeSite+ isn’t being updated any more and Dreamweaver is a pretty costly piece of software for just editing code. CFEclipse offers all the tag/function insight that we’ve all come to depend on, help files for the tags and functions, snippet support including a centralized snippet repository for teams called SnipEx and more. The fact that it and the majority of the plugins I use (and hundreds more that I haven’t had a need for yet) are free doesn’t hurt either.

If you haven’t given CFEclipse a test drive lately (or at all), you really owe it to yourself to use it for a couple of weeks and form your own opinions. I realize that no editor is going to be the “mac daddy” (pun not intended Apple so don’t sue me) to everyone, but for my time and effort, Eclipse-based editors are just what I need to jam out code on a regular basis.

My Local Web Development Environment Overhaul Pt. 4 – Database Server

Dan Skaggs — Mon, 30 Jun 2008 01:34:54 +0000

This entry in my series detailing how I have my development environment set up will deal with databases. This is going to be a somewhat shorter post than the others simply because there isn’t as much customization to be done in this area as some of the others.

For any client that I have a voice in selecting the database back end for, I generally choose MySQL. There is a myriad of places around the Internet that detail the advantages and disadvantages of MySQL when compared to the other popular database systems, so I won’t go into that here. However, the two main reasons I choose it are price (hard to beat free for the community edition) and its ability to run on nearly any platform. It certainly doesn’t hurt that it scales very well and has several options for graphically managing the schemas and data it contains.

I’ve done a “vanilla” installation of MySQL 5 on OS X 10.5–just downloading the binaries for OS X and following the installation instructions. I have been thinking lately that I need to figure out what I need to do to not have it auto start at system login and use some sort of script to start and stop it like I do my other tools. It’s pretty light-weight when used as a development database, so I don’t think it’s hurting my boot up time much. I’ve also been wondering if there is some way to set up different “environments” to segment my clients’ schemas from each other. Honestly though, I really haven’t had the time lately to research if it’s possible.

I know there are people out there that use PostGRES as their preferred database, and I’m pretty sure that it will run on OS X, but I’ve not had a client to date that uses it. As a result, I’ve not done any research into what it would take to get it installed on OS X and hooked up to ColdFusion via the Administrator.

I have run across a few clients that use Microsoft SQL Server in the last year or so. Obviously, SQL Server won’t install and run directly on OS X. I have BootCamp set up on my Macbook Pro with Windows XP installed on it. I have installed MS SQL Server 2005 Developer Edition on that Windows install. Whenever I need MS SQL Server, I use VMWare Fusion to launch my BootCamp partition as a virtual machine (then promptly minimize it so I don’t have to look at Windows). I have made an entry in my /etc/hosts file to point the hostname “BootCamp” to the IP address that VMWare assigns that VM. Beyond that, it’s easy to create a DSN in ColdFusion administrator in OS X to point to that hostname.

One database engine that I don’t have a good solution for at the moment is Oracle. All the clients I’ve worked for that use Oracle had a dedicated development database set up for developers to use. I have not investigated what options there are for running an Oracle engine locally for development. Maybe one of the two or three of you that read my blog can give me some ideas in the comments.

If any of you have any suggestions of ways that you have done things in the past that worked well, fee free to leave a comment.

My Local Web Development Environment Overhaul Pt. 3 – Application Server

Dan Skaggs — Mon, 16 Jun 2008 14:00:52 +0000

This installment in my series detailing how my local web development environment is set up is going to deal with my application server setup. After visiting with several folks at the cf.Objective() conference this year, I was convinced that I needed to configure my ColdFusion 8 installation in “multi-server” mode.

There are a few advantages to installing ColdFusion in multi-server mode versus stand-alone mode. The main advantage for my situation is that multi-server mode lets me configure an instance of ColdFusion to match each of my clients’ environments. Imagine if you had two clients each with legacy applications that you need to support. If both clients had (as many development shops did at one time) created a ColdFusion mapping called “CustomTags”, you’d have a serious issue on your hands when trying to set up your local environment to work on these applications. Since ColdFusion can only point a mapping to a single folder, if you have installed the stand-alone version of ColdFusion, you’d either have to put all files from every “CustomTags” mapping in one folder, or constantly be updating the directory that mapping points to. Neither are good solutions and would ultimately lead to problems. With multi-server install, you get the ability to create a completely separate ColdFusion environment for each client, and therefore the ability to create a “CustomTags” mapping in each that points to the correct directory. The same applies to datasource connections and all the other settings managed by the ColdFusion administrator.

The typical install location for ColdFusion using the multi-server installation is /Applications/JRun4/servers/cfusion on the Mac and C:\JRun4\servers\cfusion on Windows. I’ve changed the install location on my setup to /opt/JRun4/servers/cfusion to more closely match the configuration when installing into Linux or Unix machines. This also has the advantage of getting the JRun4 directory out of my Applications folder–there is enough stuff in there already as it is.

I also don’t have ColdFusion services start when I boot my laptop. Since I regularly switch clients during any given period between reboots, I manually start all my ColdFusion instances in a terminal session with the command

My Local Web Development Environment Overhaul Pt. 2 – Web Server

Dan Skaggs — Mon, 09 Jun 2008 13:00:47 +0000

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.

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.