Brendan Baldwin Dot Com

This year I went to RailsConf in Portland Oregon and had a good time, but the whole time I was there I thought I should be doing my own dang presentation.  So I submitted a proposal for the upcoming RailsConf 2008.  For the curious, here is the proposal. Hopefully they’ll bite, because I think everyone walked away from RailsConf 2007 wishing there were more in-depth technical topics discussed.

HyperExtending ActiveRecord Internals

Description

While ActiveRecord gives us so much power right out of the box, it doesn’t have to stop where the Rails core team leaves off. This set of code walkthroughs will explore several production-tested techniques for extending the internal machinery of ActiveRecord to allow richer dynamic finders, scope conditions, association proxies, access-control, and more. Guaranteed to give you real super powers.

Session type: 45 minute conference session

Abstract

I love ActiveRecord. Its an extremely handy set of code that does a lot for me and I’m grateful for it every day. However, as a developer, whenever I get a taste of a good thing, it just makes me hungry for more. What if I could represent associations in my finder conditions? I could get a list of all Customers who had Purchases from the Chicago store with simple finders:

Customer.find(:all,:conditions=>{:purchases=>{:store=>‘Chicago’}})
Customer.find_all_by_purchases_having_store(‘Chicago’)

What if I could declare scopes and chain them together to filter my finder results? I could define a scope using an association between users and their sessions, call it ‘logged_in’, and use it as a filter on an association proxy to find all my friends who are currently logged in:

@user.friends.logged_in.find(:all)

What if I could leverage the elegant combinatorial power of symbolic expressions to represent conditions without the need for embedded SQL in strings? What if I could automatically limit the records retrieved based on a User’s rights? What if I could build a has_many :through that bridged another has_many :through?

I’ll cover how to do all of these using source code walkthroughs and impart some advice and techniques for writing your own ActiveRecord extensions along the way.

Tags: ruby, rails, railsconf

I’ve been really enjoying the work resulting from switching my programming language focus for the past year+ over to Ruby and/on Rails. Ruby has really widened the range of possibilities in terms of what kinds of systems I can build and concepts I can employ in doing so.

However, having done a lot of metaprogramming on the edges of what is possible in pure Ruby, I’m finding myself craving more. While there are ways to add more to Ruby with C libraries like ParseTree and RubyInline, the time has come for me to start planning learning my next language.

As part of my self-education, for the past two years I’ve watched and re-watched countless times, the free online MIT Video lectures from 1986 entitled Structure and Interpretation of Computer Programs. These videos are an amazing treasure-trove of insight for anyone in the field of software engineering and computer science. They cover so many different styles of architecture and techniques for program and language design, yet the course is taught all in a single language: LISP

Why would LISP still be relevant? Probably the most important reason is that as languages go, LISP doesn’t set any specific limitations on what LISP can do. You can use LISP to write in pure functional style, or use objects with multiple-inheritance, multi-methods, modules, logic-programming… In terms of pure functionality, LISP makes the possibilities feel truly limitless.

From the outside looking it at least… So why doesn’t everyone just use LISP? My guess is that it’s partly because it looks very arcane. Most of its built-in functions and reserved words are just scarily obscure, and programs appear to have endless nested series of parentheses which tend to make even basic constructs appear intimidating:

But the thing is, once you get past the surface, there is a lot of inherent power in this basic structure. Since everything in LISP is a symbolic expression that can be interpeted by LISP code, LISP code can read itself and write itself without needing to do the naive and opaque string evaluations of other scripting languages, and can even interpret the same code differently, as desired, in different contexts. I think LISP is still the sleeping giant of the software world. And if it isn’t sleeping its at least the stealthiest language out there (at least when you compare it to C, C++, Ruby, PHP, Java, Perl, Python, or LOLCODE!)

At the moment, the technology I use at my day job is still powered pretty much 100% by Ruby on Rails, and its likely to stay that way for a while. I will probably continue to do a lot Ruby work in my spare time as well, but I am going to try and get in at least 30 minutes of LISPery into my schedule daily until it starts to gel. I am looking forward to seeing where it takes me.