On the Path

Cool kids don't store plain-text

or How I simplified database.yml to avoid storing sensitive passwords in plain-text

Nobody likes putting important passwords in a plain text config file. So what are your options?

1) Use a one-time, throw-away password
I typically do this for most Rails projects that I work on (e.g. user: "acme", pass: "acme")

2) Prompt for the password
Unfortunately there are times when access is tied to a real password. On my current project, the DB password is the same as my email password (served via LDAP).

Prompting in a config file? Yes, this is available by default in Rails, and can be done easily in other Ruby projects. This is all you need to get a command-line password prompt when loading database.yml:

  # Within config/database.yml or your custom config file...
    <%
      # Cool kids don't store plaintext
      require 'highline/import'
      def prompt_for_password
        @passwd ||= ask("DB password: ") { |q| q.echo = false }
      end
    %>
  development:
    host: somehost.example.com
    username: arild.shirazi@example.com
    password: <%= prompt_for_password %>

If you are not using Rails, you will need to evaluate ERB within your config file whenever you load it:

  # If loading your own yaml outside of Rails
  config_erb = ERB.new(IO.read config_file)
  YAML::load config_erb.result

BONUS: When using this method, your checked-in config/database-example.yml could be setup to work for all users out-of-the box. Just add some ERB to determine the correct mysql socket to use (<% system(mysql_config --socket) %>), and create a rake dependency that copies database-example.yml to database.yml when needed and you're good to go.

NOTE: Feel free to roll your own prompts:

  stty -echo; pass = gets.chomp; stty echo

But using the highline library really improves readability. Also, using highline is a great way to promt from inside rake scritps.

CSS Frameworks and CSS Systems

Several years ago I wrote a blog entry entitled YUI Stylesheets are Awesome! I stand by their original awesomeness in saving me from the perils of IE6 hell, but this tradeoff is ugly. In using a grid system with positional CSS, you lose all the semantic meaning CSS can bring. The short term gain, in practice, just led to other long term maintenance problems. There is a better solution, and I want to show it to you.

There are a lot of these frameworks now - YUI, Blueprint, 960gs, and umpteen others that follow the same basic ideas. These CSS Frameworks are all about positioning... splitting the page up into a number of columns and letting you lay out <div>s on the page. As a newcomer to CSS they get you up and running fast, but miss a much bigger picture. In the end, they are nothing but ways of 'tricking' CSS into acting more like tables than semantic markup.

Semantic Markup? You Keep Saying That...

Lets figure that out by looking at the role of the HTML writer.

Imagine I'm writing a website for a new coffee shop. I'm going to design the page for the menu. Like most menus, items are grouped according to types. Maybe "Hot Drinks", "Cold Drinks", "Desserts and Pastries", "Sandwiches", and so on. That HTML writer, using a CSS framework that is all about positioning, might have a page structure that looks like this (any html tags beyond structure are omitted for clarity):

<div class="columns_12" id=menu">
  <div class="columns_6 alpha" id="hot_drinks">
  </div>
  <div class="columns_6 omega" id="cold_drinks">
  </div>
  <div class="columns_10 alpha" id="deserts_n_pastries">
  </div>
  <div class="columns_2 omega" id="dessert_pic_holder">
  </div>
  <div class="columns_2 alpha" id="sandwich_pic_holder">
  </div>
  <div class="columns_10 omega" id="sandwiches">
  </div>
</div>

So we have IDs that represent the real content, but the classes denote something about the positioning within the page. In this case we have a 12 column container named 'menu', and that contains a series of divs that all add up to 12 columns, with 'alpha' indicating it is the first, and 'omega' indicating it is the last. For the most part, minus some bells and whistles, this is how these stylesheet frameworks work.

So why is this a problem?

Imagine the poor html designer when the coffee shop redesigns their menu. At first, some simple positional changes are easy to make... "Move this picture over there... put the hot drinks on the other side..." and so on. But over time, these changes begin to ripple across more and more pages ("Move the logo from the left side to the right side" becomes an edit on a lot of pages). The client asks for things that can't easily fit within the grid system, and that html designer is now left writing CSS that now has to interact with the framework well. Reading the CSS, it never says how to style a MENU.

Enter Semantic CSS - the "CSS Systems" approach.

Why include all that column stuff in your html? After all, we already have these nice IDs that indicate what each section is... furthermore, I might want to use classes to indicate exactly what something is too (I could see a CSS class that wraps every drink as a <div class="hot_drink">, for example, leaving the ID as something that Javascript could uniquely identify the drink by).

Somebody has already explained this better than I can. This presentation by Natalie Downe is well worth the time to view it.

The Best of Both Worlds

I sure like the idea of a semantic CSS system, but shucks - I sure like relying on all that nice CSS that is tested and takes away all the cross-browser pain for me. Is there a way to have my CSS and uh, eat it too? Yes, there is. Take the hour and watch this intro video to Compass, a great CSS editing and composition tool.

The author of Compass has turned many of these grid frameworks into 'mixins' so you can still use the grid system and tested CSS, but you can eaily turn it into a semantic CSS system specific to your project. Want to move around the page contents? The HTML doesn't have to change! VOILA! All the benefits of CSS back in your hands. This can make a BIG difference when the bulk of your html is generated by something like php or Ruby on Rails. Your generated HTML stays the same - no code changes!

A side benefit of using Compass is the use of SASS, a language for writing stylesheets that lets you do all kinds of cool stuff in a syntax a lot nicer than CSS. Again, the screencast shows that.

Puzzle Pieces that Fit Together Nicely

Are you a Rails developer? I knew you were. Guess what? All this fits together with Rails like perfect little puzzle pieces. Inside of erb, the templating mechanism behind Rails' html pages, we can say things like:

<%= div_for(@hot_drink) %>

and get back html that looks like:

<div id="hot_drink_43" class="hot_drink">

Seems kinda trivial, until you realize that now you can have CSS class definitions that match your domain model, which goes a long way towards that "CSS System" ideal. Further, you get a unique ID that represents the object in the div, which you can now use Javascript and the DOM magic of Prototype or JQuery to do Ajaxy-type effects on your page contacts. When your CSS is driven in large part by the display of your domain model, the CSS itself becomes clean, clear, and it is easier to find 'dead' CSS.

Wow.

Rails 2.x Changes to Separator Parameter on render_partial_collection

I recently upgraded a good sized Rails 1.2.6 app to Rails 2.3.4. Peter Marklund's excellent upgrade notes were an incredible help and for the most part the upgrade was fairly straight forward. During the upgrade, I changed many calls of: 

  render_partial_collection

to:

  render :partial=>'', :collection=>''

The one piece of documentation I had a hard time finding was what became of the separator parameter on the now deprecated render_partial_collection. After quite a bit of digging, I found that it's now called :spacer_template. So,

<%= render_partial_collection "category", @post.get_category_hierarchy, 'bar_separater' %>

Became:
<%= render :partial=>"category",
           :collection=>@post.get_category_hierarchy,
           :spacer_template=>'bar_separater' %>


Hope this helps anyone else in the same boat!