Autotest, which is part of ZenTest, is a very handy testing application. It runs tests as changes are made to the code. When using it, I would accidentally leave it running and then notice something using up CPU cycles. It would turn out to be the autotest process that was still scanning files for changes every so often. I would then stop autotest only to be bothered to start it up again when I was working on the project again.

Awhile ago, I ran across autotest-fsevent for the Mac. It uses the Mac's FSEvent core service to determine which files have changed (or to be notified when they are). This appears to have really helped the CPU cycles especially when nothing has changed. It is immediately notified when a file has changed.

I would also recommend upgrading to the latest autotest-growl as well. I was using an older version and there have been improvements.

I really like CouchDB and the flexibility it provides. It is currently under heavy development (the last release was an incubating release) and things are changing frequently. Most of the time, this means improvements or new features, but sometimes this leads to breaking backward compatibility. The other night I tried the latest clone of couchrest with this commit. I looked at the breaking changes page (based on the comment on the commit on github). I found the reference to the moved view URLs which was the problem I was having. After reading the discussion on the mailing list, it sounds like it is a good idea and is worth breaking backward compatibility.

To update to the latest version of CouchDB (basically working from the trunk), here are the steps I took:

1. installed couchdb-python using this script
2. dumped each database using the couchdb-python dump.py described in breaking changes
3. shutdown couchdb and make a backup (for example, I tar'ed my /srv/cocuhdb directory)
4. pull down the latest copy for couch from svn or github
5. build and install CouchDB
6. start the new version of CouchDB
7. go into Futon (for example http://localhost:5984/_utils) and create each database
8. load each database with load.py from couchdb-python again described in breaking changes

After upgrading CouchDB, I then had to update my application to use the latest couchrest.

This (home grown) blog is now running on Ruby 1.9. Since I wrote it using Sinatra and couch-rest, it was pretty easy to get working. The only real trick was adding a fake JSON gem to fulfill a dependency on JSON (which is now part of Ruby 1.9). I found this reference on the IsItRuby19 which came in very handy in determining which gems work on Ruby 1.9.

I have updated the look of the blog as well as the underlying blog software. I have also switched from http://outten.net/weblog to http://blog.outten.net. I had been using a customized version of Typo.

The new blog is running my own combination of Sinatra and CouchDB. I have been using Ruby for a few years now (after starting with Rails). I was curious to see what some of the other Ruby frameworks had to offer. I have tried Camping, Ramaze and Merb. All had some really strong points and I started rewriting my blog in each of these, but did not finish with any of them.

When I first looked at Sinatra, I didn't have a great first impression. I went away and looked at some of the other frameworks mentioned. After dabbling in each, I ran across Sinatra again and really dug it. About the same time I had become interested in CouchDB and really wanted to give it a try. That's when I started playing with a Sinatra and CouchDB combination. They seem to be a nice fit even though I could have written the entire blog in Javascript.

I am planning to release the code in the future in case someone else would like to use it.

Features

• multiple blogs hosted by the single instance
  • each blog uses its own CouchDB database
• plug-in for protecting a blog by requiring users to identify themselves
• admin application separated into a different Rack module