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.

With this new traffic, came some new requests for features. The first was a request for a Google Gadget. I didn’t know much about what I needed to create a Gadget, but after looking it up I realized I could use the CatechizeMe API that came automatically when I built the app. With just a few lines of code, the Daily Question service was created and returning JSON data. You gotta love it when things are this easy.

BEFORE:

  def daily_question
    @question = @catechism.daily_question
    render :template => '/questions/show'
  end

AFTER:

  def daily_question
    @question = @catechism.daily_question
    respond_to do |wants|
      wants.html { render :template => '/questions/show' }
      wants.js { render_json @question.to_json }
    end
  end

So now I get a daily catechism question from the CatechizeMe website or via the Google Gadget using JSON:

You can find the project, Basejumper, at: http://github.com/gdagley/basejumper

What is included?

Blueprint CSS (http://www.bluprintcss.org)

Say what you will about CSS frameworks, but they make my life a lot easier. From the website, it “gives you a solid CSS foundation to build your project on top of, with an easy-to-use grid, sensible typography, and even a stylesheet for printing.” There are official plugins for the framework, like “buttons” and “link-icons”, and other user created ones, like silksprite (http://www.ajaxbestiary.com/Labs/SilkSprite).

Authlogic (http://github.com/binarylogic/authlogic)

The way I think authentication should be done. Instead of copying a lot of authentication logic (encrypting passwords, remember tokens, etc.) into your user model, it is kept in the gem and is easily updatable. It has lots of configuration options to fit with your authentication needs and some really good tutorials.

In app/models/user.rb

class User < ActiveRecord::Base
  acts_as_authentic
end

Configatron (http://github.com/markbates/configatron)

This is great way to store application wide configuration and settings. By adding an initializer to load the config.yml, you can access configuration anywhere in the app.

In config/initializers/load_config.rb:

configatron.configure_from_yaml("config/config.yml", :hash => Rails.env)

And in config/config.yml

development: &local
    property1: value1
    property2: value2

test:
  <<: *local
  value2: test_value2

production:
  <<: *local
  value2: prod_value2

Searchlogic (http://github.com/binarylogic/searchlogic)

From the same folks who brought you Authlogic, there is Searchlogic. You will always need pagination. You may not think so now, but believe me, you will. So just start out with it enabled. What I really, really like about Searchlogic, is not just the pagination support, but how easy it makes building advanced search forms (including searching nested objects). And again, there is a great tutorial

log-buddy (http://github.com/relevance/log_buddy)

For the lazy debugger in all of us. How many times have you typed:

some_var = 'some_value'
logger.debug "some_var = #{some_var}" 

Now try this

some_var = 'some_value'
d { some_var }

which will log

some_var = 'some_value'  

micronaut and micronaut-rails (http://github.com/spicycode/micronaut and http://github.com/spicycode/micronaut-rails)

It just makes more sense to me. Like RSpec, only fewer calories. micronaut is a BDD framework similar to RSpec. In fact it uses all the same RSpec matchers, so there is not a new syntax to learn. And it adds metadata to the loaded examples that is useful for deciding which tests to run, exclude, document, etc. or building additional tools for your example suite.

The application currently has examples (a.k.a. specs) for most of the existing code. Adding new examples, should be quick and easy. To see it all, start with rake examples

beholder treasure map (http://github.com/spicycode/beholder)

I like continuous integration. I work for a company that likes continuous integration. Having continuous testing locally let’s me as soon as I break something.

beholder watches for files to change and then reruns the appropriate tests/specs/examples. Now I don’t have an excuse for not running the example suite, because it is always running for me.

active_form (http://github.com/nesquena/active_form)

Easy ActiveRecord validations for non-AR models (for those Contact Us forms).

comatose (http://github.com/darthapo/comatose)

Inevitably, every project wants to be able to manage the “static” content on the site. Comatose is a very simple CMS plugin. Nothing fancy, but that is great for these small projects. You can even style the admin interface to look more like your application (which I did), but the default styles could work just fine. It is possible to use the content in Comatose as an entire page or a partial across many pages. The app has a migration that creates some default pages and an example partial.

active_scaffold (http://github.com/activescaffold/active_scaffold)

Fastest way to build a super simple admin interface. Or you could use it to build more complex admin. It is really quite flexible with its search, CRUD, and the ability to customize.

display_flash_helper (http://github.com/gdagley/display_flash_helper)

Shameless use of my own plugin to display flash messages. Nothing too fancy.

exception_notification (http://github.com/rails/exception_notification)

Because they happen and I want to know about them.

pretty_buttons (http://github.com/relevance/pretty_buttons)

HTML buttons shouldn’t have to look so bad. This plugin plays nicely with Blueprint CSS buttons plugin, too

semantic_form_builder (http://github.com/nesquena/semantic_form_builder)

HTML forms made easier and semantic. Also makes the forms easier to style.

seo_helper (http://github.com/relevance/seo_helper)

A few useful helpers for SEO purposes. Create page titles (h1) that match the html title (title), support for meta tags and easily add some breadcrumbs to each page.

Conclusion

Like I said before, it is tailored to they way I like things to start out. You can fork it and change it. I may not roll you changes back in, but that’s ok because now you have an starter app just the way you like it.

Finding Shops, Clubs, and Shows on your iPhone

When I built StagingTracks a few years ago, I did it because I was traveling and wanted to easily find the model railroading community wherever I was. As it has grown over the past few years, so has technology. While it was possible to navigate the StagingTracks website using a browser on the phone, it was not optimal. Since this is my little sandbox for experimenting, I wanted to see how difficult it would be to add an optimized iPhone interface.

Native app or Web app?

I spend my daylight hours developing web applications for others, so it made sense that I should reuse the infrastructure that I already had in place. I didn’t want to learn iPhone SDK and all that is involved with that right now and I had recently come across the iUi javascript and css framework. iUI can give web applications a native iPhone application feel, so I just needed to see how to incorporate it into my “legacy” Rails application.

Resources

A quick Google search for iUI and Rails turned up Ben Smith’s excellent iPhone on Rails article.

iPhoney

Reading through the article, I downloaded iPhoney for quick testing without an iPhone. Be sure to use the iPhone User Agent in the iPhoney menu.

Local Subdomain for Testing

I was going to serve the iPhone version from the subdomain iphone.stagingtracks.com, so I needed to setup something similar in my local development environment. Fortunately, this was very easy with the Ruby Ghost gem found via Robby Russell’s Get to know a gem: Ghost.

sudo ghost add iphone.localhost.com

We needed to add the .com so that the call to the request.subdomains will pick out the iphone portion.

iUI Framework

After downloading the iUI framework from the project site, I moved everything into its rightful place.

public
  - stylesheets
    - iui.css
  - javascripts
    - iui.js
  - images
    - iui
      - copy all of the .gif and .png files into here

Because I moved the images into the /images/iui folder, I needed to update the image locations in the iUI css. A quick find/replace and I was ready to go.

Application changes

I won’t go into all the details since Ben’s article hit most of the high points. Here are the few additional bits that I came across as I was adding my iPhone interface.

Basic approach

The basic approach to adding the iphone interface is to update the controller to render the iphone partial without the layout (since everything is AJAX) and then create an iphone template.

In posts_controller.rb change from:

def show
  @post = Post.find(params[:id])
end  

to

UPDATE:: format.html should come before format.iphone. For some reason it was working for browsers that were not IE. Weird.

def show
  @post = Post.find(params[:id])
  respond_to do |format|
    format.html
    format.iphone { render :layout => false }
  end
end  

iphone template posts/show.iphone.erb:

<div class="panel" title="<%= @post.title %>" selected="true">
  <h3><%= @post.title %></h3>
  <%= render :partial => 'post.html.erb', :locals => {:post => @post} %>
</div>  

Search Button

Since one of the more interesing features of StagingTracks is the ability to search for organizations near you, I wanted that to be prominent. By adding a “button” link to the toolbar, it now shows up on every page.

In application.iphone.erb:

<div class="toolbar">
  <h1 id="pageTitle"></h1>
  
  <%= link_to "Search", search_path, :class => 'button' %>
</div>

Dynamically Growing Lists (a.k.a pagination)

Since I already had paging in place for the blog posts, I wanted to be able to reuse that, if possible. Turns out that was pretty easy to add as well. I needed to separate the post_items into a separate partial so that I could return the next page of <li>'s to replace the “More news…” link (notice the target for the “More news…” link is “_replace”).

In posts/index.iphone.erb

<ul title="News" selected="true">
  <%= render :partial => 'post_items', :locals => {:posts => @posts} %>
</ul>

In posts/_post_items.iphone.erb

<% posts.each do |post| %>
  <li><%= link_to post.title, post %></li>
<% end %>
<%= content_tag :li, link_to("More news...", posts_path(:page => posts.next_page), :target => "_replace") if posts.next_page %>

A quick change in the posts_controller.rb from:

def index
  @posts = Post.latest.published.paginate :page => page, :order => 'published_at desc'
end

to:

UPDATE:: Same change to the ordering of format.html and format.iphone.

def index
  @posts = Post.latest.published.paginate :page => page, :order => 'published_at desc'
  respond_to do |format|
    format.html
    format.iphone do
      if page == 1
          render :layout => false
        else
          render :layout => false, :partial => "post_items", :locals => {:posts => @posts}
      end
    end
  end
end

Styling Form Select Inputs

My search form has a dropdown for choosing the country that you want to search. By default, this did not look very nice. Since it didn’t need a label, I just left it out in the form and added some additional CSS.

In search/index.iphone.erb

<% form_tag(search_path, :class => 'panel', :title => 'Search')  do %>
  <h2>Find Local Shops, Clubs, and Shows</h2>

  <%= content_tag :p, flash[:error], :class => 'error' if flash[:error] %>

  <fieldset>
    <div class="row">
      <%= country_select :search, :country, ['United States', 'Canada'], {} %>
    </div>  

    <div class="row">
      <label for='search_city'>City</label>
      <input type="text" value="" name="search[city]" id="search_city"/>
    </div>

    <div class="row">
      <label for='search_state'>State</label>
      <input type="text" value="" name="search[state]" id="search_state"/>
    </div>
  </fieldset>
  <%= link_to "Submit", "#", :class => 'whiteButton', :type => "submit" %>
<% end %>

And in my extra iphone.css (anything else that I needed to add to iui.css)

.row > select {
    box-sizing: border-box;
    -webkit-box-sizing: border-box;
    margin: 0;
    border: none;
    padding: 0;
    height: 42px;
    background: none;
    font-size: 16px;
    width: 100%;
}

.error {
  font-weight: bold;
  color: #8a1f11;
  margin-left: 14px;
}

Conclusion

All told, I probably spent less than eight hours over a couple of nights adding a simple iPhone interface to my existing application. I still want to look in to modifying the CSS more to have it look more like the regular StagingTracks website, but that can come later. This was a fun little experiment.

Recently, the Dallas Relevance folks have been meeting at Panera while we wait for our office space to materialize. Most of the time everything works out nicely: free wifi, decent coffee, plenty of room to spread out. But one thing that doesn’t work correctly while at Panera is tinyurl.com. For some reason, tinyurl is blocked by Panera filters. This would be fine for most, but since my twitter friends insist on using tinyurl to post links in their tweets, it is annoying not being able to see what is going on.

Microapp to the Rescue

So I figured this would be an opportunity for simple little that let me enter the tinyurl, figure out where it was going to redirect to, and go ahead and redirect me there. This way I am never accessing the evil tinyurl.com directly from the Panera network, but instead letting my little app do that for me.

The app was pretty easy to write. I used Sinatra and created one “controller” and one “view”. Within a few minutes, Sinatra had “taken the stage on port 4567″ and my app was working. Locally.

Give the app a home

The next challenge came when I tried to deploy it to my trusty Dreamhost account. I love Dreamhost for playing around with small apps. You get unlimited domains, they have a pretty cool admin control panel, and they support deploying Rails applications with Passenger Phusion. And since Passenger Phusion 2.0 supports Rack enabled Ruby apps, I knew I should be able to deploy this new app to my Dreamhost account. A quick search turned up a useful post with information on deploying to Sinatra apps on Dreamhost. Unfortunately, the first attempt didn’t work.

Always check the logs

So I went to the logs to see what went wrong… wait there weren’t any logs! Fortunately I found this post for logging with Sinatra apps. Unfortunately, the logs didn’t help. Apparently, my problem ran deeper. So like all good debuggers, I started commenting out code and printing out where I was in the app. The first thing I commented out was the called to render the view using ERB. Turns out you can configure where the root of the app is located. Apparently the root path for a Sinatra app running on Dreamhost is not exactly the path where you deployed it. Sinatra::Application.default_options[:root] looked like this:

/home/.machinename/username/app.domain.com/Rack: /home/.machinename/username

Additional configuration needed

Looking through the Sinatra source turned up the needed configuration changes need:

path = "/path/to/app"

Sinatra::Application.default_options.merge!(
  :root => path,
  :views => path + '/views',
  :public => path + '/public',
  :run => false,
  :env => :production
)

A quick deploy later and the application was up and running. Tomorrow we are meeting at Panera and I will get to see what everyone is tweeting about.

Addendum: Deployment too?

Since Sinatra apps are so small, you could just copy everything up to the server manually. But I like have a little Rake task to do that for me. It just touches the tmp/restart.txt that Passenger uses to know when to restart and then uses rsync to copy the files up to the server.

desc 'Deploy to the server using rsync'
task :restart do
  sh "touch tmp/restart.txt"
end

desc 'Deploy to the server using rsync'
task :deploy => :restart do
  cmd = "rsync -ruv * #{USERNAME}@#{DOMAIN}:#{DEPLOY_PATH}"
  sh cmd
end

Take a look at the code

I have posted the code on Github for everyone to take a look at. Enjoy.

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.

<div class="ads vertical_tower">
  <% if RAILS_ENV == 'production' -%>
    <script>... Live Ad Code Goes Here </script>
  <% else -%>
    Ads Go Here
  <% end -%>
</div>

Then I can use my simple ad template CSS to make it standout. Check out the css source on Github

I am back from RailsConf 2008 and two of my favorite talks were “Microapps for Fun and Profit” by Erik Kastner and “23 Hacks” by Nathaniel Talbott. I have recently been toying around with creating small little apps where I can try out new ideas and sharpen my skills.

One of those apps is the Template Generator Pro. It was a really simple little app the generates funny cover letters, two week notices, job postings, and more. Not a lot to it. What did I learn? I deployed it to SliceHost (my previous apps have been deployed to DreamHost) and starting learning more about hosting and system administration. I also had a chance to port the Nonsense Perl script to a Ruby version. That was fun!

Tools of the Trade

What am I using for my microapps? The first ones (CathechizeMe and TemplateGeneratorPro) were small Rails applications. But that is alot of overhead and not a lot of “micro” in that. So for new things I am looking at Sinatra for a framework and Stone or ActiveRecord with SQLite for persistance. I like JQuery for the Javascript and BluePrint CSS helps me make it look pretty fairly easily. Open Source Web Design and Open Web Design help to stimulate the creative aspects of the designs.

Check it Out

You can see some my little hacks being stored on my GitHub account: http://www.github.com/gdagley. I also have some projects from work at http://www.github.com/relevance.

I recently upgraded StagingTracks.com to use Rails 2.0. I was excited about so many of the newest features that it seemed the logical thing to do. I even decided to upgrade RSpec in the process so I would be able to play with some of the new features there too.

Unfortunately, despite extensive local spec’ing, when I deployed the app to Dreamhost, things did not go as planned. I was using piston to manage my Rails in the app and all of my plugins, so I didn’t need to worry about which gems were installed on the server. What I found was that when users tried to submit new information using the forms on the site, nothing would happen. Let me correct that: It would look like something happened, but no data was submitted.

So what was the problem?

I first started by watching the production.log to see if the data was even getting submitted. As expected, nothing was coming through. I then used the Tamper Data plugin for Firefox to see if I if the data was getting out of the browser. It was, but something interesting appeared. I saw a 301 Redirect when the page was submitted. Odd. Especially since the application wasn’t seeing the data and there were no redirects in the production.log.

So I started looking in the http access.log to see why the data wasn’t coming through to the app. What I saw was surprising:

- - [16/Dec/2007:19:24:30 -0800] "POST /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:24:30 -0800] "GET /shops/ HTTP/1.1" 200 319 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

It looked like the POST (which goes to the ‘create’ method using Rails RESTful approach) was being redirected to ‘/shops/’. The browser would then call ‘/shops/ ‘ with a GET (which is the ‘index’ action). And the form submission never got through. Now I was perplexed. Why would the web server being sending the 301 Redirect?

It became a little clearer when I saw this in the logs as well:

- - [16/Dec/2007:19:15:11 -0800] "GET /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:15:11 -0800] "GET /shops/ HTTP/1.1" 200 89174 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

For some reason, the web server was causing 301 Redirects when the trailing slash was missing! Now I had heard of the trailing slash problem, but couldn’t find a suitable solution that would be easy to implement.

So How Do You Fix It?

I am so glad I am surrounded by lots of smart people. A quick conversation with my friend Rob Sanheim turned up the solution.

I added the following to my .htaccess file:

DirectorySlash Off

I added it after the Options +FollowSymLinks +ExecCGI and before the RewriteEngine On

Now things are back to normal again. I am now able to get back to connecting model railroaders.

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