Rails Environments For Lisp

The facility of Ruby on Rails' test, development and production environments is one of those features that goes almost unremarked, but which makes using rails more pleasant. No doubt everyone has their own solution for this in other environments, and while I am sure Common Lisp is not lacking in examples, I have not seen an idiomatic implementation. In developing cl-blog-generator I came up with the following solution.

Configuration in Common Lisp usually depends on using special variables, which can be rebound across any block of code. I started by putting the configuration of my blog into s-expressions in files, but got tired of specifying the file names for different blogs. Instead, I created an association list for each configuration, and registered each using a symbol as key. I can now switch to a given environment by specifying the symbol for the environment.

The implementation (in src/configure.lisp under the GitHub repository) consists of two functions and a special variable. SET-ENVIRONMENT is used to register an environment, and CONFIGURE is used to make an environment active. The environments are stored in ENVIRONMENTS special as an association list. An example of setting up the configurations can be seen in the config.lisp file. In creating the configurations I drop the '*' from the special names.

I'm relatively new to CL, so let me now if I have overlooked anything. Writing this post makes me think I am missing a WITH-ENVIRONMENT macro ...

Discuss this post here.

Published: 2009-04-07

Frameworks and Productivity

Yesterday was frustrating; I spent far too long trying to debug some problems in a Rails application I am writing. Rails, and frameworks in general, are supposed to give us improved productivity by hiding the complexity and mechanics of the task at hand. This is great as long as the framework behaves as expected, but invariably causes problems when things go wrong.

The missing field

My application uses associations, and I had a belongsto association that was supposed to be populated in a beforevalidationoncreate callback. In my tests I noticed that the linked model was not being instantiated. After much searching, it turns out I had forgotten to create the foreign key field. Unfortunately Rails was silent on this issue and the belongs_to association code seemed to execute quite happily without the field.

Can't dup NilClass

My models also use has_many associations, which I could populate with no problems. When I tried to access the association though, I kept getting Can't dup NilClass errors. This one turned out to be an issue with the generated collection.build method. As noted in the documentation by the somewhat cryptic Note: This only works if an associated object already exists, not if it‘s nil!, the method fails if the collection is empty (at least that's what I think it means). Explicitly instantiating the associated model and then adding it to the collection fixed the problem.

Bad choice of name

In my application I had a model named Target, which meant that models that associate with Target, such as my TargetProfile model, have a target attribute.

Unfortunately the target attribute in TargetProfile always returned the instance of TargetProfile - not quite what is expected. The problem was caused by the fact that ActiveRecord's AssociationProxy, used to implement associations between models, has a target attribute. The documentation contains another warning Don‘t create associations that have the same name as instance methods of ActiveRecord::Base, but mentions nothing of AssociationProxy, which isn't even part of the documented api. I call this broken encapsulation.

The Rails Way

Rails heavily promotes testing and Test Driven Development (TDD), which is linked to the "fail early, fail fast" paradigm. It seems strange that known issues (as partially documented) are allowed to persist and cause silent failures. All the issues above could have been flagged by Rails.

Conclusion

I am not picking on Rails, however, as these type of issues seem to occur in many frameworks. No software is bug free, and a framework has to work hard to hide the complexity and mechanics of its domain. When things go wrong, we are always left questioning whether the issue is in the framework or in our application and we invariably end up getting to know the implementation details of the framework, which does little for our productivity.

Discuss this post here.

Published: 2009-03-20

Parsing YAML Dates in Rails Gives Surprising Results

Today's surprise was that "2009-01-01" and "2009-1-1" get parsed differently by the YAML parser in Rails. The former gets converted to a Date, while the latter becomes a String. It confused me for a while, as the problem only showed up when I wanted to send the dates to a Flot chart. Looking at the standard, it's conforming behaviour. Must be me that is non-conforming then...

Discuss this post here.

Published: 2009-03-07

Archive