Bill Clementson's Blog

SLIME Web Development Workflow

Thursday, September 1, 2005

Marco Baringer's UCW "Hello World" and SLIME Tutorial movies intrigued a lot of people. It wasn't just the content that he was presenting, it was the "development workflow" that he demo'ed that was different [and appealing] to many people.

Well, it turns out that Marco described his "development workflow" a few months back in a post on c.l.l. when Trent Buck kicked off a discussion thread by asking "has anyone written up a thorough description of their (personal, Lisp) development workflow?". Marco's reply post makes a good accompaniment to his movies (I've slightly edited the post):

"I work with web apps, so this influences my development workflow quite a bit.

1. I startup emacs. I'm using a recent CVS build of Emacs on Mac OS X 10.3. [I generally restart Emacs a couple times a week].


2. I open up a terminal and decide what Lisp image I need to mess with.
   
   I generally work locally so I just go the directory containing the development branch of whatever application I'm interested in and load its startup script. This script loads whatever systems (using ASDF), performs any DB initialization and, finally, creates a slime-server.
   
   A couple times a week (though this varies a lot) I need to patch/debug the production images. In this case everything is already setup so all I need to do is setup the SSH tunnel which will allow me to connect to the remote SLIME server.


3. From within Emacs: M-x slime-connect RET RET


4. If I'm patching a running image, I'll generally have created a file somewhere containing whatever update code I need. This will generally be class/method definitions and some code to update the existing DB or objects. Sometimes it's easier to just re-load and re-compile everything so I'll simply perform whatever shutdown is needed and quit the image (and then go back to step 2).
   
   If I'm debugging a running image, most of my time will be spent jumping back and forth between the inspector (C-c I or M-x slime-inspect), a browser window and various SLDB buffers. I use the slime-inspector a LOT and I've recently started using slime-edit-value (C-c E) quite a bit. I've hacked my local SLIME to allow me to edit things from within the inspector and I've hacked slime-edit-value to allow me to put unreadable objects in it.
   
   Once I've figured out what the problem is, I may fix it immediately (if it's a trivial change) or I'll disconnect from the remote server and attempt to reproduce and fix the bug locally.
   
   If, as is normally the case, I'm performing active development I'll just open up whatever files I'm interested in and start editing. The first things i usually do are:

   , RET !d RET 

   since I usually start the Lisp in a directory which isn't the source code directory. Then I use:

   , RET !p RET 

   to switch into the system's package.
   
   I don't like writing code directly in the REPL, so I always keep a slime-scratch buffer open (M-x slime-scratch) and perform my test there. I've patched my SLIME to save slime-scratch buffers, this is as much due to my habit to hit C-x C-s as it is to a real need to save scratch buffers.



5. I've gotten into the habit of using "structured editing," I've put up my comments at (this has been edited/improved by so many people that's it's hardly "my" guide anymore):
   
   http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs


6. I use a modified version of osx-itunes to control iTunes. If my dog hadn't eaten them I'd be wearing a nice pair of Sennheiser headphones.


7. I live and die with slime-complete-symbol. I use it so much that I've setup Emacs so that hiting the \ twice runs slime-complete-symbol and C-c TAB runs slime-complete-form (which i don't use very often).


8. I tend to create lots of small files and use M-. and M-, to move through them. I use C-x r SPC (point-to-register) and C-x r j (jump-to-register) occasionally.


9. I contemplate exiting, so I've no particular advice to give."