Sandi Metz's Rules
In episode 87 of the fantastic Ruby Rogues podcast, Sandi Metz shares these programming rules:
- Your class can be no longer than 100 lines of code.
- Your methods can be no longer than four, maybe five lines of code.
- You can pass no more than four parameters and you can’t just make it one big hash.
- Your Rails . . .
The classic behavior mocking dilemma
We would like our tests to not inappropriately cross over layers of the system (such as accessing the database), and we would like our tests to not be dependent on implementation. Unfortunately, these two concerns are often at odds with one another.
Let's say you are testing this method:
class Foo
def bar
Bar.find( . . .Putting your rbenv-managed bundler-specified executables in your PATH (more) securely
There have been a smattering of solutions offered over the years for getting rid of bundle exec. To me they all have drawbacks -- they either solve the problem at the wrong layer, involve remembering an extra step, require a manually-managed whitelist, or are messy for some other reason.
Why it's a good idea to put a newline at the end of every file
I will today settle one of the great issues of our time: whether or not to always put a newline at the end of a file.There are two reasons why it's a good idea, and zero reasons why it's a bad idea.
Let's consider these files:
https://gist.github.com/4010011
The first reason: when using various command . . .
better_timeout: a replacement for Ruby's standard library Timeout
Ruby's Timeout library had a serious problems before 1.9: it would sometimes not timeout. This was solved by system-timer(see the readme for more background). But in 1.9, we finally have a Timeout thatreliablytimes out, joy. However, it still has some problems.
As some quick background, here is the basic usage:
require . . .The somewhat peculiar behavior of Ruby's Thread#raise
Here's something that's perhaps not entirely obvious: when you call Thread#raise, the exception will be raised at whatever point of execution that thread happens to be at.
require 'thread'
t = Thread.new{
sleep 0.1
sleep 0.1
sleep 0.1
sleep 0.1
sleep 0.1
}
sleep rand(4) * 0.1 . . .Ruby Thread#kill and ensure blocks
Here's something interesting in Ruby: If a thread is killed and the portion of code that was running has a corresponding ensure block, that block will be executed before the thread is killed. This is nice in that the utility of ensure is maintained (IO objects will be closed, etc.), but it's perhaps unintuitive that the semantics of . . .