What Thrashed Around In Chris' Brain This Past Weekend

(The blog experiment continues: 1 post every weekday in November and I think I only skipped one, but made up for it with a Saturday post)

Node.js is something I want to use, but I do not know what for
For those who don't know, Node is a "toolkit for writing extremely high performance non-blocking event driven network servers in JavaScript". In other words, it's for writing server-side Javascript with an emphasis on providing concurrency. Damn you Tim Bray, I cannot avoid seeing concurrency everywhere since you started your Concur.next series on your blog. It fascinates me, and I don't even do any kind of work where I need to worry about concurrency. Not yet anyway.

Simon Wilson (someone I follow from the Django community) has a great article explaining why Node.js is genuinely exciting to him, and my old CakePHP landsmann Felix shows how to handling streaming file uploads in node.js. Like so many new technologies, Node.js starts out as a solution looking for a problem but as I become more familiar with concurrency it all becomes a little clearer.

I had been experiencing a problem with Vim. Well, two problems. The first big one was weird behaviour involving the
AutoClose plugin. It would spit out brackets and quotes at the weirdest time, and I found myself doing a lot of unnecessary keystrokes (and toggling in and out of insert mode) to get things done. So I deleted it. Enough of that crap. Same goes with my attempts to use the Project plugin. I just could not get it to work properly. DELETED.

Vim's ability to be ultracustomizable ALSO makes it easy to dump stuff when you no longer what to use it. Heck, I even see some stuff in my .vimrc that I am not using any more. Mappings I did to accomplish some specific tasks. Those were deleted too.

Understanding the concept of callbacks opens your mind to all sorts of possibilities
While callbacks are related to my use of Javascript (jQuery uses them to great success) I also find myself digging into the documentation in Django on signals, which are callbacks by another name: functionality that is executed when certain events happen.

Django uses them all over the place, and CakePHP uses them as well. When I look at the CodeIgniter code that powers Sportso, I often ruminate about what programming techniques or design patterns could help me reduce the amount of code that has actually been written. CodeIgniter doesn't really support callbacks except in the form of allowing you to define custom functions for validation purposes. It's a start I get. I wonder what the code would look like if I could define more code that is triggered when specific events happen? Any time I find myself typing the same block of code over and over again, it is only natural that I seek to reduce how often I need to do it.