As someone relatively new to Ruby on Rails, I managed to confuse myself on one of my Rails projects recently when I decided to follow some very logical advice in Obie Fernandez’s The Rails Way that said that has_and_belongs_to_many (habtm) relationships were essentially deprecated in Rails, and that has_many :through was the preferred way to handle many-to-many relationships.

With has_many :through, the join table becomes a full-fledged rails model, meaning that you have more flexibility to extend the functionality of that model as your application evolves in the future–a very sensible best practice. So, I decided to convert an existing relationship that I had specified as habtm to has_many :through. I began to see errors that initially confused me, along the lines of NameError: Uninitialized Constant …. I had misnamed my join model and table because I was still thinking from the habtm perspective instead of treating the new model as I would any other model in a has_many…belongs_to relationship.

In Rails documentation and tutorials, there are plenty of examples of how to implement binary associations, but in my searching, I have found no examples of how to implement ternary relationships, a void I hope to now fill. The key will be to make the association tables into full-fledged models and use them in has_many :through declarations to specify the relationships.

I’d like to talk more about what I expect to be doing this year, which as an experienced developer, might be somewhat interesting. Then, I’d simply like to speculate on how things that are already happening might play out.

I seem to be writing a lot of “first impressions” posts lately, and I’ve definitely been using several new tools recently. Its fun and strange at the same time; I am doing a lot of learning, which is fun and horizon expanding, but I am also coding less as a result, and because my knowledge of these new tools is necessarily superficial as a newbie, I know that the code I am writing is probably not very good. This week, I started gathering requirements on a project that I initially expected to be coding in JRuby on Rails, only to find out that eventually, I would be handing off the application to a development group that only wanted to support PHP. OK, I thought, I’ll just use CakePHP, which is a Rails clone and one of the best PHP MVC frameworks offered. I know PHP, and I know Rails, so the transition should be smooth. and overall, it has been so far.

I am starting my first non-trivial Rails application (finally!), and I quickly encountered the common situation in which you want to assign hierarchical subject categories to an entity. I also wanted to do this within the context of using RESTful controllers in Rails. Designing RESTful controllers is a relatively new concept to me, and its a relatively new feature in Rails itself. All in all, implementing this was remarkably fast and smooth, true to Rails’ reputation, although there were a few minor things along the way that weren’t immediately obvious to me. So, because this is probably such a common scenario, I decided to recreate the steps I took to implement this for others like me who are very new to Rails.

In a previous post, I went through my thought process for choosing Aptana/RadRails (on the Eclipse platform) as my Ruby on Rails(RoR) IDE. Well, that didn’t last long.

In a recent episode of This American Life, host Ira Glass suggested that we are now living through a “Golden Age” of television, a time when the major networks are responding to increasing competition with greater experimentation and better quality programming overall. He suggests that we may not recognize that we are living through this era until after it is over, and we are left to ponder fond memories.

I suggest that we are experiencing a similar “Golden Age” of Web application development. I think its been going on for some time now, taking shape in a recognizable form in 2005 and really hitting its stride in 2006. And, I suspect it may have peaked already and that in a few years, some of us may look back on this time and romanticize it.

The core Ruby on Rails development team uses TextMate, a MacOSX (only) programming text editor that is apparently the greatest thing ever. A quick Google search reveals countless blog and forum posts devoted to finding something with similar functionality on Linux and Windows.

I am starting to develop with Ruby on Rails on Ubuntu and three of the suggested alternatives looked attractive to me. If you are planning to develop exclusively in Ruby/Ruby on Rails and want the lightest weight solution that is probably closest to the TextMate experience, Gedit is a good alternative. But if you want a fuller experience, or if you develop in multiple languages, jEdit and Eclipse are (I would argue) the two best options.

So, I’m sitting here learning Ruby and Rails, and a thought starts to emerge: I wonder if I could use things like ActiveRecord separate from Rails for writing command line database maintenance scripts in Ruby, for example? Then I start to see other Rails features that also might be very useful outside of a Web application, and then I start wondering if Rails could be used not just as a Web application framework, but as a general application framework, in the way that some people have used (or at least suggested using) Struts and Spring in the Java world.

I recently began designing a generalized front-end to Fedora, with the goal of allowing domain experts to easily input, share and re-use digital content while at the same time allowing information specialists to design the metadata framework used for those digital objects. In other words, the system can be thought of as a digital asset management system for faculty, facilitated by librarians.

Within the system, digital objects are complex, composed of a set of metadata and one or more files of various types. A digital object can belong to more than one collection, and a basic set of Dublic Core (DC) metadata can be assumed for every digital object, along with one or more metadata profiles, or templates that are defined by collection.

The metadata profiles will be designed by librarians and implemented with the help of developers informed by the needs of the faculty populating the collection. These metadata profiles will be designed to accommodate an arbitrary number of fields of arbitrary types, so the structure of any collection’s metadata can’t be known at (system) design time, as specifying this structure is a function of the system itself. Designing the data model for this aspect of the system began as an interesting puzzle that as I unraveled it, started to look like an increasingly elaborate version of the Entity-Attribute-Value (EAV) model…