CSS Improved

For a while now there has been SASS, which allows you to write CSS-like files that get translated into CSS. The advantage is that you can now use things like nested rules, variables, mixins, and more. The markup is similar to CSS so the learning curve is minimal. On top of that, there is Compass, which adds some of the popular CSS frameworks as mixins. Now it is easy to mixin the styles of the frameworks to your semantic classes in the CSS without adding all of the extra framework specific classes to your HTML markup.

What I did not like about SASS and Compass was the dependency on HAML. I have tried to make the switch form ERB to HAML and I know that you can use SASS and Compass without using HAML in your templates. But it always seemed like an extra unneeded dependency in my apps.

Less CSS

I recently came across LESS, a Ruby gem similar to SASS. The idea is that you can write .less files that are CSS-like and they will be translated into CSS. The advantage, as I see it, is that you can use existing .css files as .less files since the syntax is so similar. In addition to the standard CSS syntax, you also get nested rules, variables, and mixins, just like SASS, but without the extra dependency. You can also import other CSS files as-is, like the CSS frameworks, and mix those styles into your semantic styles. This eliminates the need for Compass to provide the SASS-ified version of the framework.

The gem itself is not specific to Rails and can be used on any project. You just need to run the LESS compiler to translate the .less file into a .css file. There is a Rails plugin that make it easy to start using LESS in your Rails projects.

LESS In Action

So what does it all look like? I will leave you with an example of how it all fits together.

@import 'blueprint/screen.css';

#content {
  .container;
  .clearfix;
  #main {
    .column;
    .span-18;
  }
  #sidebar {
    .column;
    .span-6;
    .last;
  }
}

#footer {
  .container;
  text-align: center;
  font-size: .75em;
  color: #666;
}

You can see more in my Basejumper, a starter Rails application.

Some of the criteria I had for choosing the charting solution included: ease of use (it is microapp, of course), compatible with shared hosting environment, fast, easy to customize.

Some of the libraries I looked at included: flot with jquery, gruff, scruffy, sparklines, and googlecharts. I settled on the googlecharts library because I didn’t need the interactive features of flot and I didn’t want to worry about RMagick needed for gruff, scruffy, or sparklines.

Google Charts API

The Google Charts API is an interesting tool that lets you dynamically generate charts using a “simple” URL scheme. The usage policy is very generous too: “There’s no limit to the number of calls per day you can make to the Google Chart API.”

This would allow me to offload the image generation to Google (who supposedly has quite a bit of computing power) and let my application, in a shared hosting environment, focus on collecting votes.

Enter googlecharts

The challenge with the Google Charts API “simple” url scheme is that it would very tedious to have generate it by concatenating the strings together. Fortunately, Matt Aimonetti built the googlecharts gem for Ruby. You can get it from Rubyforge (gem install googlecharts) or Github (gem install mattetti-googlecharts).

Installing googlecharts in my Rails App

With googlecharts installed on my machine I could start using it, by adding it to my config/environment.rb file.

Rails::Initializer.run do |config|
  config.gem "googlecharts", :lib => "gchart"
end

Since the file we need to include is named “gchart”, not “googlecharts”, we have to specify the :lib => "gchart" option.

I also didn’t want to worry about installing in on the deployment machine, so I unpacked it to the vendor/gems folder using rake gems:unpack.

Now to the Charts

Once all that was in place the challenge was getting the data into a format that would be easy to pass to the library. It turns out, that wasn’t too challenging either.

The Helper

In my view helper module I created a method that would collect the data needed for the chart.

  def pie_chart poll
    @pie_chart ||= {
      :data => poll.choices.collect(&:votes_count),
      :colors => poll.choices.collect {|c| c.winner? ? "264409" : "8A1F11" }
    }
  end

This just loops over the choices and collects the needed data and puts it in an easy to use Hash.

The View

    <%= Gchart.pie :size => '240x160',
                   :title => 'Vote split',
                   :data => pie_chart(@poll)[:data],
                   :bar_colors => pie_chart(@poll)[:colors],
                   :format => 'image_tag' %>

Using googlecharts Gchart made it easy to build the “simple” url needed for a pie chart using the Google Charts API (also supports line, scatter, venn, sparklines, and meter charts) I didn’t even have to add the tag because I could pass the :format => 'image_tag' and one was generated for me.

Conclusion

I was extremely happy with how quick and easy it was to get some simple charts into my application (check them out at UnscientificPolls.com). The response time from Google seems to be as fast as if the images were stored locally. It also saved me the headache of installing with RMagick. This is definitely a good fit for simple graphs and charts in a Rails application.

Hopefully this gives a little insight into what I do.

I presented on RSpec 1.1 tonight at the Dallas.rb. I don’t claim to be an expert, I just love my specs (and now stories).

Feel free to take a look at the slides.

Last night I recieved my very own copy of “Nobody Knows Shoes” by why the lucky stiff. Shoes, in case you are wondering, is a small framework for writing GUI applications that can run on multiple OS’s (Windows, Mac, Linux). “Nobody Knows Shoes” is the API documentation for the framework presented in the form of… well… comic book/ short stories/ examples… and that doesn’t even do it justice. I played around with Shoes and decided to get the book to see what it was all about. It is well worth the cost (less than $15, including shipping), if not for the pure entertainment value. It is also a good reference, as well.

If you haven’t experienced why or any of his code, you should definitely take a look. You will be entertained and enlightened.

So I came across Dan Manges Fixture Factory as a way to relieve myself of the pain of fixtures for testing. I don’t mind fixtures that much, but when I have to start setting up so many different combinations, it gets a little challenging. In reading through the comments I found that Scott Taylor had implemented it as a plugin. Now I get all that goodness for my specs.

The other day I wanted to play with some things using script/console, but was feeling too lazy to set up all of the data I was going to need to do what I wanted. Sure enough after looking at the documentation for fixture_replacement, I can use it there too:

  % script/console
  >> include FixtureReplacement
  >> cause = create_cause
  >> user = create_user
  >> cause.users << user 

It is really useful for easily setting up your test data in the spec (or test) that you are writing. Instead of having to go off to the fixture files and add new fixtures (and try to remember to set up all of the dependent fixtures that are needed), you can use new_xxx or create_xxx to get an object to test in a valid state with all its dependent data.

Take a look at the FixtureReplacement plugin now.

So now I urge you to go and vote for Chris and MileMeter.

Last night, Adam Keys and I did a little ping pong pairing for the Dallas.rb meeting. It was fun. Of course it highlighted how much I have to jump back to the Ruby docs to get much done. But I don’t see that as a problem, since it leaves more room in my head for other things. It also showed my lack of regex-fu.

Here is the code we worked on. We were trying to solve the Ruby Quiz Credit Card problem, and got most of the way through. The fun part about pairing was bouncing ideas off of each other. Others in attendance were also helpful with their suggestions. It was especially interesting as we looked back over the code and discussed even more ways to clean it up.

Would I do it again? You bet. But I think next time, I would like to work on something that I am more comfortable with, like a Rails related app. I love writing specs for that.

We are doing lightning talks at this month’s dallas.rb meeting. I decided to give the group some choice of what I would present.

I will do a short one on “Why Firefox Makes Me Look Good” or “Better Web App Development using Firefox and a Buttload of Extensions”

I can also do one “JQuery: I Don’t Know Much, But I Know I Love You ”

And since neither of those are Ruby related, I will throw another one out there: “Tighter Abs: XML Situps Made Easy With Ruby”

I’ll let everyone decide which ones you want to hear more about.

Update

I only did the JQuery presentation and here are the slides (although they were much more interesting in person).

After my last post, I thought I would share what I use for developing on Ubuntu.

Editor

I have always been a hands-on kinda guy, so I don’t use any of the fancy IDEs. Right now, I am using SciTE for two reasons. It feels lightweight and it is available for Linux and Windows. Since my laptop does not have a lot of memory, a lightweight editor is a must. I tried Eclipse, but it chewed up all my memory and slowed things to a crawl. So SciTE with some additional plugins (and information on getting them going) powers the development at McKinney Station.

Ruby and Rails

I am using the latest Ruby and Rails for all new development. For testing I am using RSpec, which seems a lot more intuitive to me. Other gems I have installed include:

• FasterCSV – parsing CSV files
• starfish – simple Ruby Map/Reduce
• mongrel – lightweight Ruby web server
• hpricot – Ruby HTML parser

Database

I love starting all of my development projects with SQLite. It is so easy to get up and running. As the project matures, I am able to quickly switch development over to a MySQL database with a change in the application’s database configuration and a quick rake db:migrate.

Version Control

All source code versioning is done with Subversion. With this quick little script, I can get a Rails project committed and started in minutes.

Conclusion

I am always looking for ways to speed up my development process, but so far this is working for me. And it is very enjoyable.