Why it is just lazy to bad-mouth Ruby on Rails

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

It’s inevitable these days: we will see an article proclaiming the demise of Ruby on Rails every once in a while. It’s the easiest click bait, like this one from TNW.Now, you may say “another Ruby fanboy.” That’s fair, but a terrible argument, as it’s a poor and common argumentum ad hominem. And on the subject of fallacies, the click-bait article above is wrong exactly because it falls for a blatantly Post hoc ergo propter hoc fallacy plus some more confirmation bias which we are all guilty of falling for all the time.

I’m not saying that the author wrote fallacies on purpose. Unfortunately, it’s just too easy to fall for fallacies. Especially when everybody has an intrinsic desire to confirm one’s biases. Even trying to be careful, I end up doing that as well…

Rails is f*cking boring! I love it.

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Together with a friend I recently built Dropshare Cloud. We offer online storage for the file and screenshot sharing app Dropshare for macOS/iOS. After trying out Django for getting started (we both had some experience using Django) I decided to rewrite the codebase in Rails. My past experience developing in Rails made the process quick — and boring…

Too Ruby

Ruby, a programming language of which I’m quite fond, is well-known for it’s readability and ease of comprehension, among about thirty-seven other wonderful features.

I rediscovered quite how readable the language is when I genuinely ended up writing the following method last week:

# On saving, updates the #Shift counters if the #ExperienceLevel of this
# #Volunteer has been changed
def update_counters_if_experience_level_changed
  update_counters if experience_level_changed?
end

For the benefit of those of you who aren’t programmers, I’ll point out that which is obvious to those of us who are: the body of the method (that’s the line that’s indented) is almost identical to the method name (the line that starts with “def”).

This is the equivalent of going to WikiHow and looking up the article on, say, How to Make a Tie Dyed Cake, only to discover that the text of the article simply says, “Choose what colours you want, and then make a cake in those colours”… and you understand perfectly and go and make the cake, because you’ve got that good an understanding. In this metaphor, you’re the Ruby interpreter, by the way. And the cake is delicious.

Okay, I cheated a little: the experience_level_changed? method was provided for me by the Rails framework. And I had to write the update_counters method myself (although it, too, contains only one line of code in its body). But the point is still the same: writing Ruby, and thinking in a Rubyish way, produces beautifully readable, logical code.

HttpOnly Session Cookies using ActiveRecordStore in Rails 2.2

If you’re using CookieStore to manage sessions in your Ruby on Rails application, Rails 2.2 provides the great feature that you’re now able to use HTTPOnly cookies. These are a great benefit because, for compatible web browsers, they dramatically reduce the risk of a Cross Site Scripting (XSS) attack being able to be used to hijack your users’ sessions, which is particularly important on sites displaying user-generated content. You simply have to adjust your environment.rb file with something like:

config.action_controller.session = {
:session_key => ‘_session_id’,
:session_http_only => true,
:secret      => ‘your-secret’
}
config.action_controller.session_store = :cookie_store

Unfortunately, the Rails developers didn’t see fit to extend HTTPOnly cookies to those of us using ActiveRecordStore, where the XSS risk is still just as real. To fill this gap, I’ve produced a very simple and only slightly-hackish plugin which overrides the functionality of Rails’ CGI::Cookie to force all cookies produced by Rails to be HTTPOnly, regardless of the session store being used.

To use it, download this file and exract it into your application’s vendor/plugins directory, and restart your application server. You can test that it’s working using Tamper Data, FireCookie, or whatever your favourite cookie sniffing tool is.

SSL Client Certificate Authentication In Ruby On Rails

I’ve been playing with using client-side SSL certificates (installed into your web browser) as a means to authenticate against a Ruby on Rails-powered application. This subject is geeky and of limited interest even to the people who read this blog (with the possible exception of Ruth, who may find herself doing exactly this as part of her Masters dissertation), so rather than write about it all here, I’ve written a howto/article: SSL Client Certificate Authentication In Ruby On Rails. If you’re at all interested in the topic, you’re welcome to have a read and give me any feedback.