Ruby has some handy Array shorthands, but I always forget which is which, so I thought I should write them down.
%i{foo bar} # => [:foo, :bar]
%w{foo bar} # => ["foo", "bar"]
Both also work with square brackets %w[a b c] or parenthesis %i(a b c)
I use Rails’ present? method constantly, but recently I stumbled across the presence method.
In the past, I have often found myself doing the following because params[:foo] could be nil or a blank string.
foo = params[:foo].present? ? params[:foo] : "something else"
I hate that i have to write params[:foo] twice. But the presence method is handy for this case. It returns nil if the item is nil or a blank string, but otherwise returns the value.
foo = params[:foo].presence || "something-else"
I’m surprised I didn’t already know this, but if you have an ActiveRecord where statement that references an id column, you can just pass in an object and it will pass in the object’s id, not the string representation of the object.
company = Company.find(1)
User.where("users.company_id = ?", company)
# is equal to
User.where("users.company_id = ?", company.id)
So when you create named scopes, you don’t have to do the song-and-dance where you check to see if the object is a model or an integer, as shown below.
scope :by_company, lambda { |company|
...In order for testing to become part of your development workflow, it needs to become a habit. And like any habit, its biggest enemy is neglect. Too often I’ll be in a rush and not add tests to my code for a day, and that turns into a week and then a month, and suddenly I have an app where half of my codebase is untested and the other half has breaking tests. There are many things you can do to help keep this habit (hooking up a CI server immediately comes to mind), but an important one is to make running your tests as quick and easy as possible.
One way I do this is by making my ruby tests (either Rspec or Minitest) extremely easy to run while I’m using Vim (and Tmux). With one quick keystroke, I can run the current test file or individual test in a new Tmux pane.
In a previous post, I went over how to add authentication to your Rails + Angular app using JSON Web Tokens (JWT). This time, I’ll do the same, but using the React ecosystem. But even if you’re using another front-end framework (Angular, Ember, Backbone), this post will be helpful because it fixes some issues with the previous server-side code that broke due to a change in the jwt gem.
In a recent post, I talked about how to generate PDF reports in Rails using Prawn. This approach is great for generating PDF’s with lots of data tables and other variable-length content. But an alternative situation is when you already have a template authored in an application such as Adobe Acrobat and you want to populate it with data from your database. This makes it more difficult to insert variable-length content, but on the plus side, you no longer need to worry about the layout of the document.
I generally hate PDF’s. The file format is complex and designed to mimic physical paper documents, which really has little to do with the web. But unfortunately, PDF’s are still very common and often expected, particularly when working on businesses applications. I have a legacy ruby-on-rails application with a number of PDF reports and I recently took the time to refactor them in a clean and testable manner. Here’s how I went about that process: