2013-05-17 | ruby
Ruby 1.9 introduced a nice addition to the Base64 module:
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
2013-02-12 | rspec, vim
When a spec file is open in the current buffer I can do the following:
|Run the example the includes the current line, e.g., |
|Run the entire spec file, e.g., |
|Run all the spec files in the current spec file’s directory, e.g., |
|Run the entire spec suite, e.g., |
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.
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.
Copyright © 2013 John Parker, Urgetopunt Technologies LLC.