Slides from a presentation at the first Indy.js meetup on March 16th.  Thanks everybody who showed up!

Note: this was a show & tell style presentation, so these slides might not make a whole lot of sense without my babbling on with incessant explanations for each slide.  However the cat picture is just to ensure my presentation didn't suck.

There are however some good links at the end of the presentation, as well as some basic good/bad bullet points about node.js & CouchDB if you're trying to sell either to your manager.

As I alluded to in my wrap-up post for 2010, I'm now working with Ruby
more frequently than I was a year ago.
One of my main frustrations with Ruby used to be how slow it was.  Now
with Ruby 1.9 & rvm I'm much happier using it. The way that rvm
manages gem sets for you and setting a per-directory .rvmrc file
really makes switching between various rubies & gems for various
projects really easy.

I'm working on two projects right now that both use Ruby 1.8.7, but
all my new Ruby development is done in Ruby 1.9 as well as migrating
said 1.8 projects to 1.9.
Another change is that digging into Lisp lately combined with my year
and a half of Smalltalk has given me a new appreciation for Ruby's
meta-programming abilities, each for different reasons.

The Ruby code that drives meta stuff might be ugly, but at least its
easy to write & understand.  Ruby doesn't have macros in the same way
Lisp does, but after working in Smalltalk what Ruby has is good
enough.
I'm pretty tired of everything being a "pattern" in Smalltalk.
Metaprogramming can be done with Smalltalk but its more tedious than
Ruby because there is no good way to explicitly show the logic you're
using, and you need a class for everything.  But that'll be in another
post soon.

I once again enjoy development in Rails because of the changes in
Rails 3 too.  I still get perpetually annoyed by the occasional gem
that just decides to monkey-patch code at will, but if you use gems &
plugins judiciously and read their code its not too bad.

Also, the Lisp code I've been writing for fun has given me a new
appreciation for code-as-data.  Ruby can't do that easily, but you can
go the other way and use data structures to generate code.  Rails uses
this a little to its advantage, but I've been using that style more
lately for my code too.

Instead of writing a collection of small methods to assemble a larger
method, I've been writing more generalized methods that use various
parameters to dynamically look up method & classes (as one example).

This results in a Lisp-like coding style where I write a "mini-DSL"
that concisely states the logic then implement the code to drive that.

In the end I'm thankful for the ambitious community behind Ruby, and
Rails and all of the great work everyone is doing. It's good to see
problems getting fixed and the technology continually improving. It's
also nice to actually have people living near me who also work with
this stuff daily. I can't say that for Smalltalk or Common Lisp!

In my next post I'll outline my qualitative experiences using Common
Lisp vs. (Pharo) Smalltalk.

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!

The only thing the Cr48 has been good for so far: checking weather, e-mail & twitter. Not a big surprise I suppose.

I haven’t used it much other than that, nor have I really been motivated to. Even sitting in front of the television, if I have a laptop I also have Emacs or Pharo Smalltalk open and I’m hacking on something (for work or fun). I do use GMail and Chrome on my main computer, however most of my work happens outside of those applications.

However so far the Cr48 has been great to leave lying around for other people to use on a whim. Yesterday the wife got on it to check for school closings. We also have an iPad which is used exactly the same way… but there are other things on the iPad to distract. Not to mention that the kids come running when they hear the iPad unlock like cats to a can opener. Not having any good games and an intimidating keyboard actually helps the Cr48 in this situation.

I tried to find an easy way to install emacs… or even gcc on it in dev mode without loading a new OS image on it. I didn’t see an easy way (even compiling from source would be “easy” in this case). I suppose it’d be nice to have someone make a binary package of gcc available thats compiled with the proper targets on Chrome OS. It’d be nice if Google made a “dev tools” installation a la OS X, where one could just install a package and start compiling programs.

I understand that that is counter to their intent of the OS though… no local data. As a developer… I guess I need local data. At least a little bit, even if it is synced from “the cloud” somewhere.

Personally I’m not ever going to take a stock Cr48 to a coffee shop or travelling. I always need Emacs (most of my notes are in Org-mode files). I tried Ymacs … but the keybindings are all conflicted with Chrome.

So if I were to embrace this “no local data” thing… I’d need a web app that behaves like Emacs on Chrome OS. I’d upload my files I’m working on (or just push my changes using a SCM), login to the app and use a Ymacs-like web UI to edit files. So thats my idea… you can have it. You’re welcome :)

(I also know of Skywriter (formerly Bespin) from Mozilla Labs. They have a “Skywriter Server” that I might look into as well that does pretty much what I just said).

So I filled out the form to get a Google Chrome Notebook (Cr48). The company I work for uses a Rails app. for the main part of their business (and I've ensured pretty much all other functionality has a web-based counterpart). We have some employees in the field and I've outfitted one of them with a cheap Asus netbook runing Ubuntu Netbook Edition to try to provide a minimal UI with only our web apps. available.

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! 

Why Parents Hate Parenting
http://nymag.com/news/features/67024/

This one will be short as I stopped programming momentarily to write this.

One more reason (of many) I enjoy developing with Seaside vs. Rails is that caching is much easier and is "built-in" in a Smalltalk environment. This difference is primarily from the way Rails is structured. When a request comes in to Rails, the Dispatcher initializes new instances of your controller which then pulls in models from the DB, which also get instantiated in memory, and when the request is over this is all thrown away to start over again in the next request/response cycle.

Because of the image-based nature of Smalltalk, your model instances are always there in memory. This can change depending on your persistence strategy, but for the simple cases you usually arrange to have them in the image at all times. Sometimes they get instantiated at image start-up, other times on-demand (but this is slow, just like Rails!). Incidentally this makes Seaside much faster for the same relative level of optimization work because it skips ActiveRecord's step of instantiating your model objects on-demand. Seaside's rendering times are faster out of the box because your object instances are already there in memory ready to go.

Anyway... my point is that I needed some simple caching of a method's results to help a page load a little faster in Seaside. All I did was add a new instance variable to my model instance that lazy-loaded the result of the calculation. I then added a few more places where this "cache" gets invalidated from other method calls, and I'm done.

I didn't have to install gems, configure a new server like memcache, read docs on a gem's interface to memcache, etc. I simply leveraged the tools available in Smalltalk, and built a simple thing that just works. I don't have to worry about persisting it as its lazy-loaded. Which really is how memcache is usually used with Rails, as a place to temporarily store the results of an expensive computation.

There is nothing stopping one from doing this same thing in Rails, but it doesn't go with-the-grain of the way Rails is built and you are expected to use it. Rails is "opinionated software" after all, and I've worked on many Rails projects where one piece or another has to violate the opinions and work on it becomes painful.

For whatever reason solutions in Smalltalk end up much simpler and therefore lend themselves to easy extension and expansion.

I like to get something simple working first so I can work as fast as possible. The simplicity of my "first version" or "rough draft" is largely dictated by how difficult it is to change the code at a later date. As soon as I finish typing a line of code I have to work really hard to not delete it and write a better line. I'm the same way with writing. My mind starts whirring with all of the possible ways to improve. More succinct. Easier to read (which is usually less succinct). Less tightly coupled. Smaller methods. Larger methods (add a parameter). The list can literally be infinite. 

So I write a line of code. Then I say, "Stop! It works, move on and come back later!" Then another line which seems to geometrically increase the realm of possibilities. However if there is even the slightest inkling that it will be difficult to change this code later, or that I may not have time to do it later then I'll typically stop and think through one or two iterations of the code before even typing it. Then the code will typically go through another few iterations before being commited and then in successive commits before reaching QA/staging.

When thinking about the design of a system one factor I consider is how easy it is to change the code itself. With Ruby and Smalltalk, code is so easy to change that I typically leave designs very simple for quite some time until the last possible moment to complicate them with extra parameters and behaviors. At times it is obvious how a design could have a plugin class or user setting or something that would make it seem flexible to imagined future changes. But I resist this urge because I know from past experience that it is nigh-impossible to predict how users will want their flexibility and I also know the code itself will be easy to change and mold.

The interesting thing I've observed about the differences in my work with Smalltalk and with Ruby stems from their environments, not necessarily the code. I've found it easier to refactor Smalltalk than Ruby, but its not just because Smalltalks have great refactoring tools. The difference is in image-based persistence.

I started a project last year in Squeak Smalltalk and later moved it to Pharo Smalltalk. This was the first time I've ever seen image-based persistance. I'm always entertained when I tell other non-Smalltalkers that the Smalltalk I use "has no files." The first response is usually, "Well where does the code come from?" I'll save a detailed comparison of image-based vs. file-based development for a later post, but the image-based way is one less layer of abstraction to deal with when changing things.

I will always rename a class when I find a better name for what it does (I'm a big fan of Domain-Driven Design: Tackling Complexity in the Heart of Software) so I'm a stickler for keeping class names in lock-step with their external representation (if they have one). I worked on a Rails project a few years ago where we changed the name of a class 4 separate times in different production releases. This required renaming the class's name in the code, the file name for the model, the database table name (and requisite migration), the fixture file name, the test file & code name, the controller file & code name, and also the view directory name (I said I'm a stickler!). That is 9 discrete places off the top of my head to change for one model class name change.

I really like how Rails has embraced "convention over configuration", but it still has a long way to go. And in the end you still have to deal with the fact that Ruby code is held in files on the filesystem. These files are dumb containers for the program code, yet their names are significant to Rails. There are IDE's out there that make this sort of thing relatively easy, but the impedance mismatch is still there.

In an image-based Smalltalk (most of them are), you select "rename" from a context menu for the class. That's it. Classes are not represented as anything different in a Smalltalk system. The class definition is an object itself that has various properties, one of them being the class's name.

This may seem like a trivial distinction, but the difference is noticeable when you're developing. I no longer stop to think, "Hmm... is this a really good name? I mean, really good? Because I know its a pain to change it later." I just name it and start adding functionality. If I want to change it later I have confidence that the Smalltalk system will find all places where it is referenced and change them for me. I realize a good IDE will do this in any language (I started using RubyMine and never looked back 6 months ago). But when this sort of thing is integrated into the very system that executes your program, the difference is astounding and it actually frees your mind just a little bit.

I've been using Rails since 2004, and some of its' libraries before that (I setup a local Instiki that, AFAIK, is still running at my old employer). Once I started using Rails at my then job at a radio station group (designing/managing the websites), I decided that Rails was a superior development experience. So I started looking for a way to use Rails as a full-time job. I've since enjoyed most of the long hours I've spent developing various things with Rails for various companies.

My current full-time job still includes maintaining a Rails application (one that I built in late 2005 on a contract), and I still enjoy it. I get to make the technology choices at my current company, so in early summer of 2009 I was tasked with separating some functionality of the existing Rails app out into a stand-alone application. I initially wanted to go the route of some sort of NoSQL database with a JS only (or mostly JS) front-end (some sort of combination of CouchDB, Rails & jQuery).

However, I've also had my eye on Smalltalk ever since hearing about it from a co-worker in 2004 (around the same time I discovered Rails). I did some investigation and spent some late nights with a few quality online tutorials. I started with "Seaside Tutorial" , as well as "Learning Web Development with Seaside". Now there is the much more detailed and up-to-date book "Dynamic Web Development with Seaside". Anyway, I basically learned Smalltalk and Seaside at the same time, and decided to build the new app in Seaside.

So now almost a year later I much prefer developing with Smalltalk & Seaside than Ruby & Ruby on Rails. I use Pharo Smalltalk exclusively for development and the server deployment (I used Squeak 3.10 until Pharo went beta). The database I use is SandstoneDB from Ramon Leon, which is basically an Object Database that just persists the objects as text files (it's essentially Prevayler with an Active Record style API). Once this app needs to scale, I'll probably move it to Gemstone/S (the people behind Maglev for you Ruby folks).  For business applications, I'm currently of the opinion that nothing beats a web application in a dynamic language on top of an object database.

I still switch back and forth between Smalltalk and Ruby, and will be doing so for the foreseeable future. Most days I'm using both, sometimes inside the same hour! 

I'll be giving a talk about Seaside & Smalltalk at the February Indy.rb meetup. The similarities between Smalltalk and Ruby are pretty interesting, and now I know what people mean when they say that "Smalltalk isn't dead, it survives in most languages used today!" You can find language features inspired by, or stolen from Smalltalk in Java, Ruby, Javascript and many other languages in common use today.

I already have 3 posts I'm ready to write comparing the two languages and frameworks from a development perspective, so expect to see those over the coming months. I also have some thoughts I'm going to share about development environments. I used to be completely anti-IDE. I used to only use TextMate to edit my code, and the command line for all of the tools. Then I moved to GNU Emacs and loved it. Now I get frustrated and bogged-down in a text-editor only setup. I use RubyMine for Rails work, and Smalltalk has awesome development tools (even in the "under-developed" open source versions). The modern IDE has its roots in Smalltalk and Lisp, and once you use an IDE that actually IS "integrated" as the acronym suggests, you will never turn back.