I’ve been using the new-ish Rails feature named_scope for a couple days now, and I love it.  The expressiveness was something I really missed jumping from OpenACS, a “framework” where you’re encouraged to write powerful queries in raw SQL.  So you get the best of both worlds: modular business logic and (relatively) powerful queries.  I wish Rails had more features to enable INNER JOINs using finders in a way that still allows the pre-fetching of associated objects, but that’s another matter entirely.  Some observations, though:

Naming named_scopes

I’ve now come to the conclusion that all objects in the titles of named_scopes should be singular (unless there’s a complex case I haven’t encountered yet where it makes sense).  So CourseMembership#in_sections_of_term should be CourseMembership#in_section_of_term, etc, even if the named_scope might return multiple rows — in fact, most do.  My reasoning is that you’ll typically be operating on something singular (a model class), and you’re really describing a criterion, not the result set.  Also named_scopes should never be nouns or they may collide with attribute or association names.  They should be adjectives or predicates (in the grammar sense), like:

Car#red (obviously a Car doesn’t belong_to or has_one Red: it probably has an attribute named “color”)
Course#live (Live is an adjective. Course doesn’t have a Live: it has a belongs_to association to CourseItem which in turn has a live_revision_id attribute)
User#is_student (This is tricky: i was tempted to call it User#student, but the User might well have a Student – though I don’t know how that might be defined)

Moral of the story is that named_scopes need to be named carefully so they don’t confuse the programmer into thinking that they’re calling an association or attribute instead.  named_scopes return proxies to arrays of the class in question where obviously associations and attributes return proxies to arrays or objects of different classes.

named_scopes on associated objects

The one thing that is preventing named_scopes from being as DRY as possible is that you can define all these fancy named_scopes on your models, but then there is no way to talk to the named_scope of an associated object in order to scope your own object.

For instance: at Berklee’s online extension school we’ve got Sections (of courses).  Each one has a starts_on date, ends_on date, closes_on date (after which you can’t post anymore), and archived_until date (after which you can’t see the course).  So I’ve got a bunch of named scopes on the Section class, including current (between start and end), open (between start and close), archived (between close and archived_until).  They work great.  But there’s a possiblity that these implementations might actually need to become more complicated, so it’s critical that this code be DRY.

So the kicker is that I need to be able to find enrollments based on those criteria.  There’s even a comment in the HasFinder blog post (HasFinder is the progenitor of named_scope) requesting something along these lines.  But I consider that to be a bit of a special case of the general problem.  I see there being two ways to grapple with it.  Either find() needs a way of letting you specify named_scopes to fire on :included associations (which is very powerful but gets away from the uber-fancy named_scope compositions that are currently allowed), or perhaps there is an even more sugary solution: What if there were an alternate form of named_scope that let you steal and alias named_scopes from associated classes?  For example, in the Enrollment class we could have:

named_scope :in_current_section, :inherit_from => :section, :scope_name => :current

Then I could find all the enrollments in Music Theory 101 by calling:

Enrollment.in_current_section.in_section_of_course(Course.live.find_by_title(“Music Theory 101″).course_item)

Sugary and DRY like Cap’n Crunch.

My gut is that you’d want both the finder enhancement and the aliasing options because there may be some objects that you need to scope a ton of ways based on inherited named_scopes, and you wouldn’t want to have to name all of them if they’re used relatively few times each.  Also, the semantics of the finder vs. aliasing approach would be different.  The aliased scope would additionally require that the association_table.primary_key be NOT NULL so that the scoping will actually have an effect on the result set of the primary object (or maybe this would be an additional boolean parameter to the named_scope call), whereas from the finder you might geniuinely want to return an unscoped set of objects, but have a pre-scoped set of children available to play with without hitting the database again.

But the only solution I currently have to get my Oracle calendar data onto my iPhone is to manually export it in iCalendar format – a format that existed before iCal but has since been conflated with the Apple product, even in Google’s own usage: “If you know the address to a calendar (in iCal format), you can type in the address here.“

Exporting iCalendar files into iCal to get a one-time dump of upcoming meetings works fine, but it’s not exactly clean and easy (especially in contrast to Spanning Sync). My obsession with elegant solutions (or some might say fundamental laziness) prevents me from accepting this in the long term.

So, what to do? Well, as I mentioned, Oracle Calendar offers SyncML synchronization. So if I could theoretically get a SyncML frontend for iCal, I’d be golden, but that appears not to exist. Just to taunt me, recent iterations of iSync apparently support SyncML in order to talk with various SmartPhones that have standardized on the protocol. But that’s SyncML over USB or SyncML over Bluetooth, and instead of implementing a SyncML client, iSync is implementing the server end of the transaction.

But, seriously, I don’t have much need for bidirectional sync with my Oracle calendar. I rarely have to stuff a meeting into my calendar when I’m not sitting at my laptop — I’m at my desk all day long. I would just like to be able to glance at what’s coming up when I’m on the go. So what about a SyncML client that dumps its results to iCalendar format? Better yet, in web app form (perhaps with caching so that it doesn’t completely kill the Oracle server every time you hit it), so that the iCalendar feed can have a URL? Then I could get my Oracle data via Google or iCal (both support remote iCalendar feeds).

So it looks like there are a few libs out there that might help. I downloaded libsyncml (which is not to be confused with this defunct libsyncml project), and compiled it. To my immediate and utter joy, I discovered the lib came with a few utility/demo applications. One was called syncml-http-client. It is completely undocumented save for the –help output, which it seems to share with syncml-http-server and syncml-obex-client. Some of the features seem like they’d be more relevant to a server than a client. And as far as I can tell, syncml-http-client completely ignores the rather important issue of authenticating itself. The library seems to be tailored more for acting as a single-user server or client than as a client of a major multiuser application. Ethereal dumps of the SyncML conversations seem to indicate that syncml-http-client and Oracle are indeed speaking the same language, but syncml-http-client is completely confused when asked by Oracle to authenticate itself.

So I’m going to dust off my previously meager and now practically nonexistent C chops and see what can be done about it. Luckily SyncML is an open protocol, so the only limitation is my own ineptitude.

Would that all Oracle calendar instances did out-of-the-box what Case Western’s does…

So I held out when the big launch came. I probably read more of the iPhone hype on Wired.com than the people who actually bought them. Being a UNIX geek, the greed welled up within me when I learned that people had been successful at installing an SSH server and standard set of command line utilities on the phone. And this wasn’t like reflashing your iPod to run Linux, thereby throwing out all of the excellent software that it came with, making the device less useful. Nope, the iPhone ran a full multitasking protected-memory Darwin kernel. Jobs hadn’t been overstating the fact that the phone ran OS X (which I half snorted at when I heard it last year).

Then came the price drop. I still held firm for another two weeks, but ultimately my resolve crumbled. I had to have it.

So I’m not going to give you a review, or a how-to. There are many sites that have done a much better job on those subjects. But I will say, having tried out some of the command line tools, they’re not quite as rock solid as you might dream. I suppose that shouldn’t come as a surprise since they’re entirely unauthorized ports written for a hardware/software platform that, while made up of some standard bits (an ARM processor and Darwin kernel) is wholly undocumented.

The one nagging problem with the iPhone (besides its inability to synchronize directly with my Oracle calendar at work) is that it doesn’t have a phone-as-modem mode. For all its networking prowess with built-in Wifi and (pokey but reasonably reliable) 2.5G EDGE network connection, it wouldn’t share its good fortune with my lowly laptop. Luckily, clever iPhoners had discovered long before I picked mine up how to compile srelay, an open source SOCKS proxy, for the device. Naturally it was the first thing I installed after getting the usual command line tools. I mean, what is a UNIX system without grep and vim?

I really didn’t know anything about SOCKS. Proxies in general have always seemed like a really awkward idea to me. If you’ve got the ability to do NAT and stateful packet inspection in a firewall, why break the abstraction on the client side? In fact, I’m not really sure what about the routing details inside of the iPhone’s network stack prevent somebody from installing a proper DHCP server and NATing router on it. But nonetheless, in this case I’ll take whatever I can get, ’cause I haven’t got a clue how to set up gcc to cross compile for Darwin on ARM, let alone write network subsystem code for it. So it turns out SOCKS can proxy just about any service if you give it enough loving. It seems it would be a lot more convenient if the SOCKS client were implemented at the OS level then. In OS X, it sort of is. There is an OS global SOCKS configuration, but it seems that it’s only an FYI for applications that can choose to implement SOCKS client features on their own. Basically, that means that Safari is about the only thing that pays attention to the setting. Of course I use Firefox, so I’m pretty much hosed. If I want to switch back and forth it’s not as simple as changing Networking locations, but rather changing my Firefox config and whatever else.

Also, ssh (or any other command line tool for that matter) isn’t down with SOCKS. But this is where tsocks comes in, or so I thought. But, it turns out that wrapping ssh in tsocks is a sure fire way to lock up my iPhone. I’m not sure if it’s a memory issue, or what. But it sure ain’t happy.

Of course it’s not strictly necessary since I can just ssh to the iPhone and then out from there to wherever I’ve got to go. Dropbear, the iPhone’s SSH server claims to even support X11 forwarding, though I’ve yet to get that to work. So, overall, the phone-as-modem support works in a pinch. And as an added benefit, if you just have to use the web, the phone’s built-in browser is really an amazing thing. It almost doesn’t suck to use.