Synchronized Web development workflow

It’s been six years since I switched from HomeSite to Eclipse+CFEclipse as my primary ColdFusion development environment. At the time, my switch was primarily driven by my switch to Mac for development, but the desire for integrated support for version control (e.g. Subversion) directly within in the IDE helped with that as well.

One of the things that has long bugged me about developing ColdFusion apps locally on a dev box (i.e. not on a shared network server) is the need to place project files directly in a Web root somewhere – for example, C:\InetPub\wwwroot on Windows/IIS or in C:\ColdFusion9\wwwroot if you use ColdFusion’s built-in Web server. This throws off my game in two ways:

  1. Browsing to where your files live (in Finder/Explorer, or via the command line) inevitably adds an extra step to every task
  2. Placing the project home outside your user space on the OS makes it more likely you’ll lose the files when upgrading/uninstalling/migrating.

Pain point one could be tackled by sprinkling my system with aliases, shortcuts and/or symbolic links. This reeks of configuration, and would be something I’d need to duplicate on any system I use.

Pain point two there is really the kicker. Sure, using version control keeps you from losing your work, but rebuilding the workspace after a system migration can take a long time. I rarely migrate applications when I get a new system; I prefer to just move the user files and reinstall the apps manually. This periodically cleanses the system and keeps me up to date on patches, even on apps I don’t use often.

I tried keeping my actual project files in a workspace somewhere convenient, such as in my home directory or in the root of the drive (e.g. C:\workspace\MyColdFusionApp)  and then copy the files to the server root to test them. I tried both manual copying and even Subversion commands, but I couldn’t keep that up for long. Part of the benefit of developing anything locally on your system is removing the step of uploading your code to a server to test it, and I was basically backsliding towards that kind of process.

But the idea was sound, and I looked around for something that would painlessly synchronize two folders in different parts of the drive – the project files in my workspace, and the files in a folder under the Web root. My last resort would be to use something like rsync, but I looked around for some sort of plugin for Eclipse – something that could keep the preferences as part of the Eclipse project and/or workspace and be easy to migrate and hard to lose.

With a little digging I found FileSync – a plugin which really fit the bill. It’s open source, and if you can look past the, ah, unpolished Web site of its creator the plugin works pretty well. When I save a file in my workspace, it painlessly gets pushed out to the Web server root for testing.

The plugin also appears to work with network drive targets, so you may be able to use it to publish changes out to a preview or QA server automatically, but you should probably be using some sort of version control for that. :)

April 14, 2010Permalink

Unit Testing and Subversion – Where should I put the test classes?

I’m starting a strong push to institute Unit Testing in a relatively new project; I figure it will be easier to really get into the habits in a new project from the start, rather than trying to steer some of our ancient existing projects in that direction right away. But I’ve hit a snag… where should I keep the test classes?

We’ve been using Subversion to manage our project files since shortly after I started here… getting us into source control was one of my first imperatives. So our code is laid out nicely in folders:


Project A
|____ src
|____ lib
|____ docs
|____ db

Project B
|____ src
|____ lib
|____ docs
|____ db

In the src folder, I have things organized in packages like


src/edu.psu.ist.project-a.component-a
src/edu.psu.ist.project-a.component-b

So where do I put the test cases? I could put them in a test package at the root of the project:


src/edu.psu.ist.project-a.test.component-a
src/edu.psu.ist.project-a.test.component-b

But what I’m really leaning toward is mirroring the main folder structure of the package in a test package in the root of the repository, at the same level as the src folder:


src/edu.psu.ist.project-a.component-a
src/edu.psu.ist.project-a.component-b
test/testComponent-a
test/testComponent-b

My thinking is that the classes in the test package would not get deployed with my actual project code, so they shouldn’t be in the real source package tree. But I’m still not sure.

TortoiseSVN Lightning Talk slides

Here are my slides from my Lightning Talk on TortoiseSVN from today’s PSU Web Developers’ Lunch:

Quick and Dirty Change Tracking with TortoiseSVN

The last slide has several links to additional resources.

If you want the longer version, here’s my full 60-minute slide set from the Penn State Web 2006 Conference:

Web File Version Control with Subversion

The slides are in S5 format — an open slide show system based entirely in Web Standards: XHTML, CSS, and JavaScript.