git checkout and see

If you use git, you’re running git checkout $BRANCH all the time. Everyone likes a fast checkout at the grocery store. How about making your git checkouts fast, too? Since I do it so often, I want it to go as fast as possible, and I bet you do too.

Are you … hot blooded?!

git checkout - (that’s git checkout followed by a dash) is the bee’s knees. It switches back to the branch you were on previously. If you run it again, you’re toggled back to the first branch. A useful comparison is cd -, which as you may know takes you back to your most recent directory. Here’s an example:

$ git branch
  alternate
* master
$ git checkout alternate
$ git branch
* alternate
  master
$ git checkout -
# Now we're back to master! 
$ git branch
  alternate
* master 

What are your favorite git tips and tricks?

How To Use Arguments In a Rake Task

I came across this today. You can write Rake tasks that accept arguments, called like this:

rake tweets:send[cpytel]

You define the rask task like this:

namespace :tweets do
  desc 'Send some tweets to a user'
  task :send, [:username] => [:environment] do |t, args|
    Tweet.send(args[:username])
  end
end

Unfortunately, zsh can’t parse the call to the rake task correctly, so you’ll see the error:

zsh: no matches found: tweets:send[cpytel]

So you’ll need to run it like this:

rake tweets:send\[cpytel\]

Or this:

rake 'tweets:send[cpytel]'

Controlling color with Sass color functions

Sass comes with functions that can easily be applied to colors in your CSS properties. These functions, when used correctly, can be incredibly powerful. They take some of the sting out of choosing and manipulating colors. When used with variables, they can speed up development drastically.

Let’s start off with a creating variable for the color that we’re going to manipulate:

$base-color: #AD141E;

This is important for me for two ways:

1. It will allow color changes to be much more fluid and easy
2. Since I can’t be bothered to memorize hex values for each color, it helps me remember colors, eliminating the need to reference a photoshop mock every time I need a color.

Darken & Lighten

These two adjust the Lightness of the color’s HSL values. Sass will parse our hex color variable to hsl, then make the adjustments. You call them on the color with a percentage value between 0 and 100. I usually stay in the range of 3-20%.

darken( $base-color, 10% ) 
lighten( $base-color, 10% )

Saturate, & Desaturate

These will will adjust the Saturation of the colors HSL values, much like Darken and Lighten adjusted the Lightness. Again, you need to give a percentage value to saturate and desaturate. 

saturate( $base-color, 20% ) 
desaturate( $base-color, 20% )

Adjust-hue

This adjusts the hue value of HSL the same way all of the others do. Again, it takes a percentage value for the change.

adjust-hue( $base-color, 20% )

Adding Alpha Transparency

Using our hex color we can do a few things to get it to be a little transparent. We can call hsla, rgba, opacify, and transparentize. All of them accomplish the same thing, just in different ways. I stick to rgba as it comes most naturally to me which takes a color and a value from 0 to 1 for the alpha.

rgba( $base-color, .7 )

Tint & Shade

Our very own Phil LaPier has added to those base color functions. Both of these are accessible in Bourbon. They mix your color with a value of white (tint) and black (shade) and are similar to Darken and Lighten. They take the color and a % value for the change.

tint( $base-color, 10% )
shade( $base-color, 10% )

Getting more advanced

Once you have those down and you are looking for more control you can look into some more advanced color control with adjust-color, scale-color, change-color. These are for multiple changes in one color function. You can easily lighten the color and add some transparency all in one.

Some of the best places to use these color functions are for gradients, borders and shadows. When you need a slightly darker border and a slightly lighter inset shadow just adjust a color variable and let Sass do the rest for you. Buttons provide the perfect place to test out the functions. Check out some of the functions used on the thoughtbot buttons:

border: 1px solid darken($base-color, 20%);
text-shadow: 0 -1px 0 darken($base-color, 10%);
@include box-shadow(inset 0 1px 0 lighten($base-color, 20%));

Learn more about Sass, CSS and HTML during my Advanced HTML & CSS Workshop on December 8th and 9th.

How-To: Quick Rails Benchmarking

This February 6th we are launching a new workshop: Advanced Rails. The workshop draws content from the Scaling Rails and Rails Antipatterns workshops, replacing them and creating best-of-breed content that will take your skill to the next level in creating well-crafted Rails applications that scale.

One of the topics we touch on is profiling and benchmarking your app. There are a number of tools available to achieve this, one of which is baked into Rails itself. Although we do discuss all of the great ways you can perform caching in a Rails app, experience has shown us that caching should be your last resource in your scaling strategy. Remember the two hardest things in computer science: Cache invalidation, naming things and off-by-one errors.

On to benchmarking, say you have identified an expensive method in one of your models that needs to be tuned. One easy and straight-forward way to measure your refactored process is to use the built in benchmarker to run quick tests. To get set up, you need to add the ruby-prof gem to your Gemfile, and have a properly patched ruby interpreter. I’m using the gcdata patch for MRI 1.9.2:

rvm install 1.9.2-p180 --patch gcdata --name gcdata

Now let’s assume the following expensive method in the Account class:

class Account
  def self.expensive_method
    sleep(1)
  end
end

We can now run a quick benchmark on that method by running it 10 times and taking some benchmarking measurements:

bundle exec rails benchmarker --runs 10 'Account.expensive_method'
Loaded suite script/rails
Started
BenchmarkerTest#test_10 (0 ms warmup)
           wall_time: 0 ms
              memory: 0 Bytes
             objects: 0
             gc_runs: 0
             gc_time: 0 ms
BenchmarkerTest#test_user_expensive_method (1.10 sec warmup)
           wall_time: 1.00 sec
              memory: 0 Bytes
             objects: 0
             gc_runs: 0
             gc_time: 0 ms

Finished in 24.933979 seconds.

You can even run a profiler with rails profiler 'Account.expensive_method' 10 flat and get more information on what’s being called and which components in your system are taking longer.

With this quick benchmark, you can now create a second, hopefully optimized, Account.expensive_method_fast and run them side-by-side, allowing you to quickly measure two implementations of the same behavior, and allowing you to quickly iterate to find the best solution.

This is just the tip of the iceberg. If you have some Rails experience and want to take it to the next level to grow your app into a well-factored and scalable system, check out our new Advanced Rails workshop.

Danger, Danger: High Voltage! Use Rails 3.1 for Static Sites

I’m a big fan of Jekyll, but boy do I love SCSS and CoffeeScript. I recently set out to create a static site using Rails 3.1, to take advantage of the lovely Sprockets integration. There are alternatives (like Middleman, and Octopress) but I wanted to use Rails itself instead.

Our homebrewed high_voltage gem allows for static pages, so I wanted to use that to hook up my little static site that will eventually be dynamic. Here’s the process I used.

Fire in the disco

Generate the app:

gem install bundler --pre
gem install rails --no-ri --no-rdoc
rails new danger_danger

Swap out your Gemfile with:

source 'http://rubygems.org'

gem 'rails', '3.1.1'

gem 'flutie'
gem 'high_voltage'
gem 'jquery-rails'
gem 'redcarpet'

gem 'sass-rails',   '~> 3.1.4'
gem 'coffee-rails', '~> 3.1.1'
gem 'uglifier', '>= 1.0.3'

Rebundle and let’s remove some other cruft:

bundle
rm config/database.yml public/index.html
rm -rf app/{helpers,mailers,models} test/ doc/ db/

Rails includes all of the subframeworks (ActiveRecord, ActionMailer, etc) by default. We don’t need those, so at the top of config/application.rb, you can replace require 'rails/all' with:

require 'rails'
require 'action_controller/railtie'

There’s references to ActionMailer in the various config/environments/ files…it’s best to just comment them for now since we may want it back later.

# comment out this in config/environments/development.rb
config.action_mailer.raise_delivery_errors = false

# comment out this in config/environments/test.rb
config.action_mailer.delivery_method = :test

I want to write templates in Markdown, so we’ll need to tell Rails to handle that. Drop this into config/initializers/redcarpet.rb, thanks to this gist. Hopefully in future versions of Rails this will be easier if Tilt is integrated into ActionView.

class ActionView::Template
  class Redcarpet < Handler
    include Handlers::Compilable

    def compile template
      ::Redcarpet.new(template.source).to_html.inspect
    end
  end

  register_template_handler :md, Redcarpet
end

Let’s start with just a homepage. Change vim to your editor of choice!

mkdir app/views/pages
vim app/views/pages/home.html.md

In that file, you can write Markdown as normal:

# Welcome to the home page!

This should say something important.

In your config/routes.rb, point to it:

root :to => 'high_voltage/pages#show', :id => 'home'

Fire up your server, and you should be able to see your home page!

rails server

Awesome! You should now see your home page rendered in markdown. What’s even better is that you can include CoffeeScript and SCSS like you normally would with a Rails app. The Rails Guide on the asset pipeline is a great read for this if you haven’t seen it.

For more static pages, you just need to drop different markdown files into app/views/pages, and high_voltage will render them as normal at /pages/:yourpage, like so:

echo "Fire in the" > app/views/pages/disco.html.md
open http://localhost:3000/pages/disco

I’ve put a repo up on GitHub if you want to check out a working version of this.

Don’t you want to know how we keep starting fires?

Ok sure, this is a lot of setup for a static site. The idea is that eventually I want to be using Rails anyway, so why not just use it to start? If I end up creating another one of these, I may end up making a Rails Template, which makes the legwork of setting this kind of Rails app up way easier. For now, this works great, and I hope it helps you out too!