I got a few questions today about my slides, so I thought I’d do a quick writeup on how they’re made.
There’s a package called showoff which allows you to write your slides in Markdown and style them with CSS. Then it hosts a local web service on localhost:9090 by default by just running showoff serve. Your slides are there, and you can just click through them for your presentation.
You can include code examples, images, incremental bullets, etc — all by just writing some markdown.
I’ve been using this for my talks for about a year and a half now, and I find it perfectly flexible to handle everything I want. Its amazing how gracefully it can transition from an outline into a presentation.
Check out my markup on my CICONF slides, or go directly to the README for showoff!
Sometimes when programming, we trick our minds into thinking something is somethat it clearly isn’t. One really good case of this is Ruby ||=. We like to think of it as “set something if it doesn’t have a value” – which is certainly not what it means (and not what it should mean).
Slow your mind down and consider this gotcha that will getcha every time:
1.9.2 > a = false => false 1.9.2 > a ||= nil => nil 1.9.2 > a => nil
And its cousin:
1.9.2 > a = false => false 1.9.2 > a || true => true
Try tracking that one down! Being explicit can be really helpful, as well as not letting your mind hold onto too many shortcuts for common patterns.
There’s a really fun video that went around a few days ago called Wat?. If you haven’t seen it yet, go do that now. I’ll wait..
One of the examples I find really fun(ny) is this one from Ruby:
1.9.2 :001 > a NameError: undefined local variable or method `a' for main:Object from (irb):1 from /usr/local/rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>' 1.9.2 :002 > a = a => nil
Wat? :) Before I explain, let me do a few others I think are cool too (and are directly related). Each of these is executed in a fresh new IRB session. First, a simple one:
1.9.2 :001 > a = b NameError: undefined local variable or method `b' for main:Object from (irb):1 from /usr/local/rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>' 1.9.2 :002 > a => nil # Wat..
Another I like:
1.9.2 :001 > c = 1 if c == 1 => nil # WAT? No error? 1.9.2p290 :002 > c => nil # Wat?
A meaningful variation on the previous one:
1.9.2 :001 > if c == 1; c = 1; end NameError: undefined local variable or method `c' for main:Object from (irb):1 from /usr/local/rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `<main>' 1.9.2p290 :002 > c => nil # WAT?
And my personal favorite:
1.9.2 :001 > a = a.nil? => true
To explain, this is all due to how Ruby’s parser tears things apart. It actually creates a variable on the left hand side of an assignment before it evaluates the right hand side. Probably will never affect you, but definitely cool to know!
Ripper is really fun to dig around in, especially when having syntax problems or (more geekily) wanting to know how the ASTs are put together. Another post on that soon!
A common sight in Ruby code is ||=:
What’s that you say?
||= is used for conditional assignment:
a = nil a ||= 25 # Set a since it was nil a ||= 24 # Don't set a since it is 25
One caveat is that the implementation of ||= is conditional on whether a is eithernil or false, so…
a = nil a ||= false # set to false a ||= true # set to true
If it helps to think of it this way, the closest easy approximation would be a || a = 24.
Another far less used, but pretty cool one is &&=, as you can imagine, its the reverse. It will assign only if there is a non-nil, non-false value present:
a = 24 a &&= nil # a becomes nil a &&= 25 # a stays as nil
I find it really useful to use a coverage tool when writing code. I don’t depend on it, but I do like to see what percentage of lines are covered, so I can at least catch any glaring misses.
In Ruby 1.8, we had rcov, which was (and is) a really great tool. In Ruby 1.9, I’ve been depending on SimpleCov. I really enjoy their reporter interface, and the usage is very similar to rcov. In your spec_helper, before you include the thing you’re testing, just start up SimpleCov. I prefer to write it like:
begin require 'simplecov' SimpleCov.start rescue LoadError puts 'Coverage disabled, enable by installing simplecov' end require 'your_library' # your library require 'config/environment.rb' # rails?
Some features I really like:
Most times, I want to be able to see coverage for one test really clearly. For the past few weeks, I’ve been using something like this to accomplish it in my Rails projects:
filter = if ENV['COV'] == '*'
lambda do |source|
source.filename.start_with? File.join(Rails.root, 'spec/')
end
else
paths = ENV['COV'].split(',').map do |rel|
File.join(Rails.root, rel)
end
lambda do |source|
!paths.include?(source.filename)
end
end
# Apply
SimpleCov.start do
add_filter(&filter)
end
That way, when starting rspec (or spork, which I highly recommend), I can say what files I want to see coverage for. Another way to accomplish this which may suite you better is to create groups for things specified in COV.
If you’re not currently using SimpleCov, try it out!