Amazon

Sunday, June 15, 2008

Tidy Stylesheets, Take Two

Back in February I wrote about a nifty way to have fine-grained control over styles in Rails.

As I was looking at it again, I realized something: The way it was implemented (and the way I adopted it) violates the separation of concerns principle.

That implementation called for a filter in the ApplicationController base class to scan and collect an array of stylesheet file paths in an instance variable. Then the layout used will pull in stylesheets from the said collection.

With that realization, I came up with an alternate approach that moves the code to collect stylesheets into the ApplicationHelper module.

Now, the concern of styles rest squarely with views, and controllers know nothing of them. A clean separation!

Another subtle difference here is that the original version collected the stylesheets whether they are pulled in by the layout or not. The new implementation will collect stylesheets only if the layout decides to use them.

The relevant code snippets are as follows:

ApplicationHelper.rb
  def get_stylesheets
stylesheets = [] unless stylesheets
["#{controller.controller_path}/_controller",
"#{controller.controller_path}/#{controller.action_name}"].each do |ss|
stylesheets << ss if File.exists? "#{Dir.pwd}/public/stylesheets/#{ss}.css"
end
stylesheets
end
some_layout.html.erb
  <%= stylesheet_link_tag(*get_stylesheets) %>
Enjoy!

Friday, June 13, 2008

Offline Translates Into Higher Productivity

I have been doing some work from home.

On one such day, my Internet access was down. Troubleshooting with the provider was no help. It will be 24 hours before they can send out a technician.

This means no E-mail, no web, no IM, not even telephone, since I am with Vonage. My means of connectivity with the outside world boiled down to a cell phone. Sure, I can walk/drive and go somewhere. But I am supposed to be working.

Great. What to do?

I had been meaning to write better tests for a Rails application. You know? The whole test-driven thing. But, that's like boring work. I mean, it is a lot more interesting to whip together a mash-up using any number of Web 2.0 APIs, reading reviews about them online, browsing through documentation and cool demos. These work great, assuming you are connected to the Internet. Which I wasn't. Oh well. Writing tests it is.

A couple of hours went by. I was done with a good suite of unit tests and a basic suite of functional tests. While everything seemed okay with my unit tests, the functional test uncovered a couple of bugs. And I think I uncovered a flaw/weakness in Rails 2.1's fixtures.

Wait a minute. I had been struggling to get this stuff done for a few days now. I would start, then move on to something else. Come back. Stare at the code and not being too productive, think of something else I need to do, and hop on that one.

But now, a couple of hours without Internet access, and it is done! All right, time to move on to integration tests. I reached over and picked up the AWDR book to refresh my memory about them.

In doing so, I glanced at my modem. The online light is solid. I quickly Cmd-Tab'd over to Mail and clicked Get new mail. It works. Woohoo! I am back online.

It hit me. I had been rather productive while I was offline. Sure, I moped at first, wondering what to do. Then I called customer support. Then I moped some more. But then, I got to work, and was productive. I focused well, by default, because there was nothing else to do.

Boy, gotta tell someone about this. Are my friends on IM? Let me go online and look!

Tuesday, June 3, 2008

Connect to Microsoft SQL Server from Rails ActiveRecord -- a Moving Target?

Some time ago, I approached my boss regarding doing some internal R&D work using Ruby on Rails. I gave a demo.

It was received well, except when he found out that the preferred deployment system for Rails applications is not Windows, and that the preferred database backend is not Microsoft's SQL Server.

He recommended that I look into at least getting Rails (ActiveRecord, specifically) to talk to Microsoft SQL Server. I said that I would, but inside I cringed. From the research I had done then, it was clear to me that Microsoft SQL Server support was not considered a first-class citizen within portions of the Rails community.

Some other stuff came along, and the whole thing got derailed (no pun intended).

Fast forward to May (last Thursday/Friday to be exact), and I find myself returning to the topic of getting ActiveRecord to talk to Microsoft SQL Server. I found that the Wiki entry titled "HowtoConnectToMicrosoftSQLServer" had been updated for Rails 2.x. Nice.

So I followed the instructions and got FreeTDS 0.82 installed on my Mac via MacPorts. I even found instructions on how to get Mac OS X's ODBC Administrator to talk to FreeTDS, as well as installed the activerecord-sqlserver-adapter gem. When I wrapped up my work week, all that was left undone was to manually install the lib/dbd/ADO.rb file from the Ruby-DBI project.

Today, I found out that Rails 2.1 had been released over the weekend, containing some cool enhancements. But, to my dismay, the activerecord-sqlserver-adapter gem has disappeared from http://gems.rubyonrails.org. Hmm...

A bit more sleuthing revealed to me the existence of activerecord-odbc-adapter gem, which offers support for SQL Server. I guess I will have to shift gears and pursue it from this angle. Instead of FreeTDS, I will need to install the rb-odbc port. Thank goodness for MacPorts!

So, as of Rails 2.1, SQL Server connectivity is still second-class, and this exercise has been frustrating.

Is it supposed to be this hard?