This year I’ve actually made an effort to try to blog on a reasonably regular schedule. I started off attempting it monthly, but it slipped over the summer. Expect me to get back to maybe… bi-monthly? I think I’ll start with something I know I can handle. So bi-monthly sounds good.

This was a big year of change… but not all for the better. I often change things just to see if there is something better somewhere else. I always say, “you can’t knock it till you try it!” But I do it in ways where I can test the waters a little on the other side and still come back if I need to. I’ve done a bit of “coming back” this year.

I was doing Rails freelance work at the beginning of the year on some products I helped build so I knew the code bases well. I stopped freelancing in April to focus on just my day job (a change). Turns out I think I need to be doing more than one thing at a time (coming back). I wanted to focus on only Smalltalk this year (a change). I’m now just as annoyed by Smalltalk’s shortcomings in production as I am with Ruby’s (coming back… sort of; mostly just irritated).

I switched to Ubuntu exclusively in May and stopped using OS X (a change). Turns out I still get annoyed by Linux’s small little broken things here and there just like I did a decade ago. I’m in the process of switching back to OS X over the next month or so just because day to day usage is easier for me (coming back). All of the software I need is more of a pain to install on OS X than Ubuntu, but that happens less often than Ubuntu’s daily irritations. Its truly been “death by a thousand paper-cuts” for me. But Linux is still second-to-none on the server.

I started up freelance work on Rails again. Its good to be back! Changing to Ruby 1.9 & Rails 3 really alleviates some pain points that drove me away. However, impolite monkey-patching by library writers still infuriates me. It will be the death of Ruby, and the Refinements feature proposed for Ruby 2.0 can’t be finished — and back ported — soon enough!

Over the summer I switched our Smalltalk app from using the Magma OODB (written in Smalltalk) to CouchDB (a change). This was definitely a change for the better. Every time I get to work with CouchDB I’m happy. It really is great to work with (see my previous posts about it). So this change is a win! I’m even starting a few Rails projects on CouchDB. However I am predictably unhappy with what’s out there for CouchDB integration with Rails 3. I guess I’m just getting old and cranky, or its just NIH.

I did a project in Scheme for work about 5 years ago, and I’ve started to get back into some more Lisps (a change). I can already tell that a Lisp (Clojure or Common Lisp, not sure yet) will be my favorite language of choice! Scheme just didn’t do it for me. But a good Common Lisp environment in Emacs is my favorite over any Smalltalk, or any commercial IDE money can buy. Clojure in Emacs isn’t quite as smooth, but still really good. I’ve really been enjoying working through Land of Lisp, and can’t wait for the final version of Joy of Clojure. I also have some Lisp projects (also on CouchDB) that I’m excited to put more time into next year. One may even make it to see the light of the public!

Something that always bothers me in a programming language is how hard it is to increase the levels of abstraction. Most languages can only go so far. Ruby breaks down because of its open classes and lack of macros (though evaling interpreted strings is… sort of a hack that works at times). Smalltalk breaks down because everything is message sends to an instance of a class. You can’t abstract above an instance of a class. I know there is more to it but practically this is what happens. There is no easy way to abstract a pattern of a collection of interacting class for example.

Lisp on the other hand has macros. Common Lisp’s macros are awesome. They’re messy and you can shoot yourself in the foot with them and they need to be used sparingly… but there is absolutely no better way to make yourself a nice little DSL than macros in Common Lisp. I’ve made a few mini-DSLs in Smalltalk and Ruby and the code that runs them behind the scenes is really ugly. There is a visual shift between using the DSL and implementing it in code.

But the implementation is just as easy to read in Lisp as the usage because of its syntax. Yes… I love all of those parenthesis. Once you realize what they let you do you will too. But you absolutely need an editor that balances them for you.

So lots of things changed, some things went back to the old ways. Expect more exciting posts next year about your favorite (or not) programming languages or goofy web technologies here! Happy New Year’s!

I've been migrating some of the database of a project here at work to CouchDB.  The first great thing about CouchDB is that since it is all HTTP, the "driver" to interface with it is dead simple.  All you need is a JSON parser and something to tack on HTTP headers and send the string to the socket.  Or just a HTTP library, yeah, thats how most people do it (but a "HTTP client library" isn't much more than some URL encoder and some string concatenation).

I'm using a great little package, SCouchDB in Pharo Smalltalk for my work, which is the former and works great and is pretty fast.  Anyway I just wanted to post about a few surprising things I've already started doing after using CouchDB for only a week.

1. Some of the data didn't get migrated correctly (it was an error in my code in object initialization overwriting some instance variables).  I just needed one attribute from every object in the old database copied over to CouchDB.  Since I didn't need to copy the entirety of every object, I just created a new document in the database with a JSON array of id -> value pairs so my code could suck in the array and update the attribute with the value on all documents with the id.

The cool part is that in CouchDB 1.0 (really > 0.11) you can replicate individual documents.  So I just have an SSH tunnel to the CouchDB on the server, replicate the document and suck in the data on the server.  This is great because I can replicate the server database to my laptop, mess around with the data locally without fear of losing any of it, then replicate only what is needed back up to the server.  I deleted the document when i was done with it.

2. In order to replicate the production database back to my dev. environment I've had to delete my local data occasionally because I've deleted documents locally that are still on the server (and I want to have them on my machine again).  However I have some design documents in my local database that I still want to keep.  So I just replicate the design documents I want to keep into another local database, delete the local db entirely, replicate the server db to my local db then replicate the design docs back to the working local db.

The replication is so easy and trivial that I've started using it for things other than just replicating data like I outlined above.  It is literally easier for me to replicate a document from one CouchDB to another than it is to export the data to a file and copy the file around.

CouchDB is a wonderful product to work with because of its simplicity.  It works in obvious ways and is just the right mixture of features to be incredibly useful yet simple and reliable.  It reminds me of the feeling when I first discovered Ruby years ago.  The principle of least surprise is a refreshing thing to have in a database for the web, sorry, of the web.

P.S. To those who might suggest I use MongoDB instead: I chose CouchDB because of its reliability (append-only file storage) with one server running and some things I'll do with it later to improve page-load times, like generating HTML snippets in the database for example.  Also, you can't argue with the simplicity of interfacing via HTTP!