Base64.strict_encode64

2013-05-17 | ruby

Ruby 1.9 introduced a nice addition to the Base64 module: Base64.strict_encode64. Whereas Base64.encode64 prettifies its output with newlines, Base64.strict_encode64 yields output without any superfluous line feeds.

This is a nice feature if you find yourself in need of RFC 4648-compliant output. You need this, for example, if you are generating policy documents for a form which uploads directly to Amazon S3. In such a scenario, instead of sending #gsub to the output of encode64 to strip out line feeds you can simply call strict_encode64.

Running RSpec Within Vim

2013-02-12 | rspec, vim

Below are a handful of mappings and a function I use to run various incantations of RSpec from within Vim.

When a spec file is open in the current buffer I can do the following:

Mapping	Description
`\rl`	Run the example the includes the current line, e.g., `rspec spec/.../foo_spec.rb -l N`. (If the current line is an `it` block, only that example is run. If the current line is a `describe` block, all examples within the context are run — I’m particularly fond of this feature of RSpec.)
`\rf`	Run the entire spec file, e.g., `rspec spec/.../foo_spec.rb`.
`\rd`	Run all the spec files in the current spec file’s directory, e.g., `rspec spec/...`.
`\rs`	Run the entire spec suite, e.g., `rspec spec`.

The way the mappings are configured the first three mappings run rspec with the documentation format. The last one runs rspec with the progress (dots) format. I find the former nice when I’m running a small number of examples and the latter perferable when I’m running a large number of examples.

Lowering BCrypt cost with has_secure_password

2012-11-29 | rails

One of the strengths of an algorithm like BCrypt for storing encrypted passwords lies in the fact that it is relatively slow and can readily be made slower. This makes brute force attacks time-prohibitive. The bcrypt-ruby gem gives you easy access to this cost factor to slow down encryption as needed. The default cost is 10. This provides good security for encrypting user passwords, but if your Rails application depends on users being signed in, you may find this default cost has a substantial impact on the performance of your integration tests. Both Devise and Authlogic provide hooks into their BCrypt interface which allows you to easily change the cost, and this can come in very handy during testing.

If you’re authentication needs are simple and you have instead opted to use Rails’ SecurePassword, you will find that, at least as of Rails 3.2.9, there is no obvious way to lower the cost factor. However, if you’re willing to live with a little monkey patching, you can achieve the same results.

Is it worth doing? Here are the before and after measurements on an application I’m currently working on. This particular application is an internal application for a client. There are no guest features, which means every single feature depends on a user having first signed in.

Before the change the integration tests run in 43 seconds; after the change the tests run in 27 seconds. That’s roughly a 33 percent speed-up. I’ll take it.