Developmental Deployment
Building a desktop/GUI/CLI/whatever app has a very nice avantage over web-based development: the app usually runs locally. And you can usually include running the app as part of the script orchestrating your build process. So the Build-Compile-Run cycle can be very fast. Very, very fast. Web-based apps don’t allow this. In order to run the app, it has to be on a server and you have to send requests to that server to get the app to run (those requests are usually sent by your browser). This bugs me, because I miss the old days of THINK Pascal. It was wonderful, I’d be typing away in a window, hit ⌘R, and a dialog would pop up with a progress bar and then the App would run. It was great.
With web programming, the low end of the scale sucks. You have a copy of the site on you local machine, and a copy on the server. You edit files on the local copy, then use an FTP (or similar) program to upload the files to the server at which point you move to the browser and test the changes. What was once ⌘R is now a large process involving switching programs (twice), selecting files and so on. It breaks my concentration to have to switch to a task completely outside the development in order to move from editing to running. The solution appears simple: streamline the Upload portion as much as Make and it’s ilk have streamlined the Compile potion of E-C-R. But, alas, it’s not so simple. The beauty of ⌘R was that saving the file, compiling the file and running the app happened as one atomic activity as far as I was concerned. No matter how streamlined the Upload portion gets, I’m still going to be waiting for the upload to finish before I can switch to the browser and hit (by happy coincidence) ⌘R to refresh the page.
While not ideal, the streamlined-Upload system does work. With Transmit uploading the changed files is just a matter of clicking the Synchronize button and hitting the enter key. Then I can switch to the browser, wait for the Transmit icon to start bouncing and hut refresh. Which is simple, but there are frustrations. Foremost of which is that Transmit will only upload files if the server’s copy is over a minute older than the local. This great for cushioning clock skew, but not so great if you forgot a semicolon or a parenthesis, because now you have to wait for the minute hand to advance to the next spot before you can save the file and hit Synchronize. The other problem is that it’s a pattern of action-wait-action. Having to wait between actions drives me nuts. I’m fine with waiting, but I want to be able to lump all of my actions together, preferably in some sort of script. I could probably automate all of this with an AppleScript that I can launch from BBEdit (I could even assign it the ⌘R keystroke if I wanted to), but that wouldn’t fix the 60-second delay problem.
BBEdit has the capability to edit files on remote servers via SFTP/FTP but I want the ability to move things around on the local command line, because it can be quicker to less the file than open it in BBEdit and it makes using svk easier, and, well, various other reasons.
An Alternative solution is to make the server the client. That is, run Apache on the development box itself. This has a really nice advantage: when you hit ⌘S in the editor, the change is immediately reflected on the server. And, since ⌘S is pretty much an automatic action for me after each line of code, running the app is just a matter of ⌘tab, ⌘R. So it’s nice and quick. In theory. The problem is that running Apache, MySQL, BBEdit, Safari and the usual background apps tends to run up against the machine’s limits and everything slows down. Which sucks.
So, the final solution seems obvious: make the copy of the site on the server available on the local machine. But I really don’t want to set up an NFS server, or AFP or Samba for that matter. It’s extra hassle, more ports to open, config files to edit. It’s a headache I want to avoid. Luckily, I already have mod_dav installed in Apache to handle my SVn repository. And, Mac OS X can seamlessly mount a DAV share. So this seems ideal. On the LAN, the lag is unnoticeable and remotely it’s not that bad. And, as a bonus, I get remote access via the normal port 80 that I already had open. So this is what I’m trying, the DAV share is a local svk checkout dir, so that I can check in changes easily and I can keep a normal working set of documents in BBEdit. And, at the same time, everything is actually stored on the server which eliminates the delay in transferring changes. I’m hoping this works out because enabling the DAV share is a matter of adding a symbolic link on the server and putting an extra pair of Directory and Location tags in the servers Apache config file.
