Today, I hit a little bump along the road of having a nice, simple checkout/run path in the Rails project I’m working on. The problem occurs when you don’t have a gem installed on the system, instead unpacking it into vendor/gems. In order for those to be included in the environment, you need to add everything underneath vendor/gems to the load_paths, something like this:

  config.load_paths += Dir["#{RAILS_ROOT}/vendor/gems/**"].map do |dir|
    File.directory?(lib = "#{dir}/lib") ? lib : dir

Unfortunately, the Rakefile only requires boot.rb and the load_paths aren’t updated. Since we are using Rcov, it was bombing out because the Rake task couldn’t be found. I had to add an additional line in the Rakefile, require(File.join(File.dirname(__FILE__), ‘config’, ‘environment’)) After that, everything worked just fine.

Joe Gregorio has an awesome post detailing the work needed to create a Web framework with some very nice conventions.

They key point of adding ‘conventions’ is to take a load off the user. You need to actually remove two kinds of load, cognitive and manual. Cognitive load is the number of concepts you need to hold in your head. The fewer the number of concepts, and the more uniformly they are applied, the easier the system will be to use. Manual load is just the amount of manual stuff, like typing, that you need to do. Why should I have to manually create a directory structure when a computer is capable of doing that?

I think this is a great blueprint for any investigation one could do in building something new for the Web, no matter the language. Much has been said about frameworks like Rails and Django but they are not the end of development or at least they shouldn’t be looked at that way. There is always room for innovation and improvement, for new and different ideas to take hold. Look at the attention Seaside is getting for an example of that.

What Joe has done is show the way any language can building something with constraints. I think you could easily use this post as a way of improving your skills in the language of your choice.

Here’s a few Ruby / Rails things I’ve seen around the Web the last few days. All are pretty cool…

Evan Weaver shows off some MySQL configurations for Rails.

Ilya Grigorik creates a simple RSS aggregator in 26 lines of Ruby code.

Here’s a custom Mongrel handler to create an XML-RPC server. I’ve been digging a bit more into Mongrel and custom handlers. I have some ideas for simple servers at work which might benefit from this sort of thing instead of the monstrosity that is JBoss.

And finally, splatter that array.

Technorati Tags:
rss, rubyonrails, mongrel, custom+mongrel+handlers

I’ve had Dave Thomas’ post about REST and the RADAR architecture open in one of my tabs since it was published a few weeks ago. I kept meaning to blog about it since it seemed very insightful with regards to the uses of REST as well as challenges ahead.

One issue that needs to be examined is that not all applications will follow a CRUD-style architecture so those will not map easily to some of the current Rails / REST services. I mention Rails only because the new REST routing and ActiveResource will enforce specific implementations which might or might not be the best choice for an application.

Dave talked a bit about RADAR (RESTful Application, Dumb-Ass Recipient) during some of the discussions last week at the Advanced Rails training. As an aside, if you ever get the chance to attend anything put on by the Pragmatic Studio, do so without hesitation. They really do an incredible job.

Ok, back to RADAR, the idea is simple, browsers are dumb and only understand two HTTP verbs (GET and POST). We can do things within URLs to help with the other verbs but really that’s just big hack. Why not just have your REST server separate? Then have the View application interact with that behind the scenes. The browser will be talking with the View, not knowing any better.

By doing this, I believe you will see an increase of small, individual apps which just have one job. They could be things like authentication or preferences or maybe even logging. This will increase your network traffic but for some things that won’t be a problem. The apps can be focused and reused by other View applications.

Technorati Tags:
rest, rubyonrails, RADAR