It goes without saying that good login and registration forms are essential to providing a great user experience.

However, more often than not, various implementations trade-off good UX for security assumptions that are out of place.

Let’s take a look at 3 easy steps to improve your authentication UX and comment on how to tweak the defaults set in Devise, the most popular out-of-the-box authentication solution in Rails.

Usually, login forms show the same error message upon a failed login attempt, regardless of whether you’ve mistyped the email or the password:

I’ve personally changed multiple emails through the last couple of years so sometimes I don’t know which email I’ve used on a certain service (mostly on services I haven’t used for some time or don’t have them in my LastPass vault yet). The process of getting the right email and password combination can get downright irritating, so oftentimes I resort to trying to send myself a password reset email to the right email address.

A better approach for websites would be to say which of the two is actually wrong:

– An account with the given email address does not exist.

– The given password mismatches the one stored for that particular user.

If the security skeptic inside you now thinks this is a obvious security issue since the internet villains could easily find out which emails are in use and which are not, you’re somewhat wrong:

You probably have a user registration form, so it’s really easy to find out if an email is in use by trying to register with that email address.

If you still think that this approach is wrong, some of the best-known sites in the world use it – check out how Google, Netflix, Facebook, Pinterest or Eventbrite handle invalid login attempts.

Devise hands out an easy way to tweak these messages with the I18n internationalization and localization framework, and it’s a configurable YAML file:

It’s good practice to link back to the registration form after an unsuccessful login occurs due to the email not existing in the database.

Your user conversion rate is proportional to the simplicity of your registration form. Some of the simplest registration forms (excluding social logins with Facebook, Twitter, etc.) only contain three fields: an email, password, and a password confirmation field.

Can it get any simpler than that? Sure it can, ditch the password confirmation.

When was the last time your password and password confirmation field mismatched? I think I never actually got that error. And if your users manage to mistype their password, it’s easy for them to reset their password since Devise offers that functionality out-of-the-box.

This one’s even easier to accomplish – just remove the password confirmation field from your HTML form (views/devise/registration/new.html.erb) and Devise will automatically ignore it since it’s nil (unlike when you submit a blank confirmation field through the form, then it’s an empty string).

Regardless of whether the email address exists or not, some websites show the same message after requesting a password reset:

The security implication behind this ambiguous message is that we don’t want to show nosy people whether an email is used on our website or not. The reason to ditch this behavior is the same as before – people can still use the registration form to find which emails were already used.

By default, Devise shows whether the email address exists or not, so there’s nothing to do here.

Showing whether an email address exists on login and forgot password forms isn’t a security risk if you have a registration form showing the exact same thing. However, you might have an invitation-based system and no registration form. In that case, you’re not exposing the user’s email, so the same security assumption doesn’t imply.

If you want to prevent malicious attacks, don’t try doing it through ambiguous error messages. Instead, use 2FA (devise-two-factor) or throttle your requests with Rack Attack.

These are three easy wins. If you’ve got any similar ones up your sleeve, feel free to share your comments below.

Quite often when writing Rails applications we need to do some kind of user input sanitization. We usually end up doing some dull checks across multiple lines. Have a look at this hidden ActiveSupport #presence_in method that provides a convenient way to do whitelisting in just one line.

Let’s say your app presents a list of articles and offers multiple ways of sorting them: by upload date, by the number of upvotes and number of comments. One of the possible techniques to support this behavior is defining three types of scopes on your Article model:

You’ll want to call those scopes depending on the query parameter passed to your controller, e.g. /articles?sort_by=newest.

The easiest way to implement this in our controller would be:

However, you don’t want to send those user inputs directly to your model because you would leave yourself vulnerable to remote code execution. An evildoer could send you a request such as /articles?sort_by=destroy_all and destroy your records.

As a responsible developer, you sanitize that input:

Although this code provides safety, it’s still not very nice. I’ve written similar code many times and have never felt happy about it because I believed it could be shorter.

That’s where the lesser-known method from the ActiveSupport module called Object#presence_in comes in.

Returns the receiver if it’s included in the argument. Otherwise, it returns nil. The argument has to be any object which responds to #include?.

With the presence_in method we can write our sorting_technique method with a nice one-liner:

Its usage doesn’t stop here, but I’ve found it to be most useful when sanitizing user input.

Have you ever had to write a nicely indented multiline string in Ruby? If you have, you already know that Ruby doesn’t have a nice out-of-the-box solution for this problem. At least it hadn’t until a week ago when the squiggly heredoc was introduced…

To be honest, I actually rarely need to use multiline strings, but when I do, it really gets on my nerves that Ruby lacks an upfront way to do them. Every time I need to write a multiline string, I google it and hope that someone has found a way to write it without performing ugly ‘hacks’ that can be found in this Stack Overflow post.

The first thing that comes to mind when doing multiline strings is using the HEREDOC syntax.

Unfortunately, the string inside the heredoc is going to be output with 6 leading spaces, and so far that’s never been the expected behavior for me:

One solution for this would be to indent the string to the left margin, but that leaves our code looking really ugly and badly indented:

Other ways like removing multiple leading whitespace characters with #gsub, appending multiple strings to each other and so on can be found in the above mentioned Stack Overflow post. There isn’t a nice way to do this in pure Ruby, however Rails does have a ’patch’ to support this behavior with the #strip_heredoc method, but it’s one method call too much to support a simple behavior like this.

Besides numerous new features in Ruby 2.3, such as the safe navigation operator or Hash#dig (read more about new features in Ruby 2.3 in this post), there will be a new and improved HEREDOC syntax called the squiggly HEREDOC that does what I’ve always expected the regular HEREDOC syntax to do – it strips the leading whitespace (similar to the #strip_heredoc method in Rails)

It looks quite similar to HEREDOC, except instead of writing <<-HEREDOC, you will substitute the hyphen with a tilda: <<~HEREDOC.

We can finally write our multiline strings in a nice manner with a minimal change (squint hard, you can barely notice it):

The rule for stripping enough whitespace:

This feature was suggested by Sikachu 2 years ago, merged to Ruby on December 7th, and you can read more about it in this pull request by Ben Miller and this commit by Nobu, the mysterious No. 1 committer to the Ruby core.

You can check out all the new features in Ruby 2.3 by installing ruby 2.3.0preview2, or simply wait until Christmas when the new official minor version will be released.

The Rails Rumble is the biggest international Rails hackathon and it’s organized once a year – over 500 teams distributed across the globe, each with 4 members fabricating an awesome Rails app in 48 hours. The best part is that everyone can join, everybody’s in it for the fun. The next one is on the 7th and 8th of November!

Last year, the three of us from Infinum entered the Rails Rumble for the first time. We had no troubles coming up with the idea of what to create – at that time we were in between switching our apps from MySQL to Postgres and were having problems finding a slick desktop client for Postgres. We got spoiled by using SequelPro for MySQL and the Postgres alternatives weren’t as nearly as nice.

Since this was a Rails hackathon, we decided to create a Postgres manipulation client built as a Rails engine. We called it Pancakes. Since we’ve managed to learn a lot from the whole experience, here are some protips to help you perform best on the big day.

One of the few things you are allowed to do before the hackathon is to agree on an idea. The four of us had met at a bar 2 days before the hackathon to decide what we would do. However, we hadn’t completely ironed-out the implementation and we felt this during the hackathon.

Try to do the architecture of the whole system before the beginning; write user scenarios, draw up a class diagram or an ER diagram of your database – the only rule is that you don’t write any code before Saturday!

Once you start rumbling, it’s easy to take a whiteboard to list and assign all tasks:

The Rails Rumble starts on Saturday at 00:00 UTC and finishes exactly 48 hours later. We live in Zagreb (UTC+2), so that means we could’ve started on Saturday at 2 am, but we decided to start with the hackathon 4 hours later – somewhere around 6 am. Even though that made the hackathon 4 hours shorter for us from the beginning, at least we got a good night’s sleep and kicked the first day off quite fresh. I think I’ll let myself sleep until 8 am for the next one and be even fresher.

We decided to meet at our office and hack our way through 48 hours from there. It’s really better for everyone to be in one place to share ideas and have fun together.

Another recommendation would be to dress like you’re at home – bring your sweats and some comfy shirts – no one wants to wear jeans for 48 hours.

One other thing we did that helped minimize time wasting and keep the team morale high was sleeping at our office. If we had went home, we would have lost at least 4 hours more to regroup back at the office and risked more outside distractions.

Thinking back, it’s a good idea to make your sleep as comfy as possible. If you have couches in your office – bring your own pillow and blanket. If not, maybe bring/borrow a sleeping bag and a sleeping pad (the thingie you put under the bag to put something between the bag and the floor). Did someone mention camping?

Before entering the Rumble, agree with the rest of your teammates on the versions of Ruby and Rails you’re going to use. In reality it doesn’t matter which versions you use, just pick some and send an email saying: `We’re going to use Ruby 2.2.3 and Rails 4.2.3, please install it’. We had some short debugging sessions while using different minor versions of Ruby inside the team. If you could skip that, it would be awesome.

Also, agree on which database you’re going to use, and make sure everybody has it installed. Same goes for extra services such as Elasticsearch, Redis or whatever. You don’t want somebody wasting time during the hackathon.

Try to create a minimalistic app with only a few basic features and do them really well – it’s better to create an app with one or two impressive features than have 10 sloppy features.

Participants are also the jury and every participant needs to go through all the applications and judge them – no one has the time to check out dozens of features. If you finish before the deadline, it’s better to polish your UX than to add extra functions.

Also, try to make your app understandable to everyone. If you can’t pitch it in a sentence or two on your homepage, it’s probably too complicated and no one will have the time to try to figure out what it does.

To be honest, no one wants to see an app that’s designed by a Rails developer, and you’re more likely to create a better app with a really good designer. Although the hackathon is called the Rails Rumble, you’ll probably be better off with a good design than with a clean codebase. Check out the awesome design from last year’s winners:

Besides designing the system’s architecture, you can have your design finished before the hackathon begins. That will also force you to keep track of all of your goals.

Once again, despite the event name, you’ll probably be better off with a good front-end developer than a back-end developer hacking through your CSS. In most cases, the first will be faster and better.

Since we did an app with a heavy back end, we thought it would be okay for all of us to be Rails developers. In the end, we would’ve been faster if we had had a front-end developer.

Two rules:

We created a slack organization (it’s free) and it was really useful:

The three of us remember this as an excellent experience and still tell stories from those two days – tired dementia conversations, weird stuff going on when hyped on Red Bulls and what not. We’ve bonded more than before and just had pure, clean fun.

Lastly, take a day off on Monday – you’re gonna need it ?

Refactoring is the craft of improving the design of an existing code without changing its external behavior. Just like with everything else, you get better at it with practice and continuous learning.
Check out a couple of talks given by some of the best Ruby developers that point out common mistakes and how to deal with them.

I’ve curated five of my favorite talks on code refactoring taking into consideration the information presented, the quality of examples and the quality of the presentation itself.
Some of the talks are closely tied to Ruby on Rails, but most refactoring techniques are often language agnostic, so even if you’re not in the Ruby world, don’t hesitate to watch them.

Sandi Metz gave this talk at multiple conferences this year and it gained a lot of traction – and for a reason – it’s awesome! The first half of the talk is more oriented on her animosity towards conditionals, the dirtiness of nil checks and advocating the use of the Null Object pattern.

The second part is a real life example of the misleading usage of inheritance (used for shared behavior instead of specialization) and a step-by-step explanation on how to refactor the given code using composition with dependency injection.

If you like this talk, be sure to check out Sandi’s All the little things from Railsconf 2014, where Sandi explains on a real world example how to thoroughly refactor a stale and procedural code.

Bryan Helmkamp, the CEO of Code Climate, gave this talk at the Ruby Conference in 2013, where he explained how to run from the methodology of Thin Controllers, Fat Models and presented other options such as Form Objects, Service Objects, Decorators, etc. There is also an associated blogpost if you’re not up for watching the video.

There are some gems that Bryan doesn’t mention that can come quite in handy when implementing these patterns in Rails:

Thoughtbot’s Ben Orenstein kicked ass with this talk at the Aloha Ruby Conf in 2012. If you want to know the basics of patterns such as the single responsibility principle, the tell don’t ask principle, the null object pattern or anti-patterns like Shotgun surgery, this is the talk for you.

This is a talk that Avdi Grimm gave back in 2011 at Ruby Midwest. It’s an excellent talk on how to construct methods and separate them into 4 parts:

There are examples of each part of a method, common mistakes that are usually made and how to fix them: embracing duck typing instead of using class checks, refactoring case equality statements with type coercion, using Hash#fetch for easier debugging, the Black Hole NilObject Pattern, etc.

If you want to find out more about the stuff he’s been talking about beyond this video, check out his book called Confident Ruby.

Knowing your design patterns is the mother of all refactoring. Aja talks about design patterns you might actually use in Ruby. She goes fast through the examples in a sarcastic manner and wastes no time covering the following patterns: template, strategy, composite, command and decorators. For each, she gives real world examples and hands out code snippets.

She mentions how the Gang Of Four book is always lying around her office and recommends Rubyists to read a more applicable book on design patterns by Russ Olsen. Doug Yun from Dockyard covered most of them well in a series of blog posts on design patterns.

Keeping your code clean and organized while developing a large Rails application can be quite a challenge, even for an experienced developer. Fortunately, there is a whole category of gems that make this job much easier.

For most people, dead/inefficient code will build up over time. Others will find themselves in a similar predicament when they take over someone else’s project.

Actually, my own experience with code cleaning/polishing gems stems from having to optimize someone else’s Rails application. Considering its size and complexity, manual code refactoring was bound to be tedious and time consuming, so I decided to help myself as much I could with third-party tools.

If you want to keep your code maintainable, secure and optimized, take a look at some gems that have been doing the job for me:

Traceroute is a route cleaning tool for Rails applications. It provides a simple rake task for checking which routes are mapped to non existing controller actions, and finds out which controller actions are not reachable.

You will also be required to keep your controller helper methods and various before/after filters private, since they shouldn’t be a part of the public API. It sometimes has problems with showing false positives on mountable engines, but they can be easily overlooked.

This is a nice tool used for finding bottlenecks of your applications. It does a live speed analysis of how long it took for the request to be processed and how much of that time it was doing various renderings, database queries and DOM loading. Just plug it into your Gemfile and you’ll get a small window in the upper left corner of your page, showing you all of these information.

This one particularly blew my mind. The bullet gem helps you kill all the N+1 queries, as well as unnecessarily eager loaded relations. Once you install it and start visiting various routes in development, alert boxes with warnings indicating database queries that need to be optimized will pop out. It works right out of the box and is extremely helpful for optimizing your application.

A security analysis tool for your Rails applications. It scans through your application and outputs a nicely formatted table of possible vulnerabilities. Security warnings are grouped according to their severity (High, Medium and Low). You can learn more about their meanings on brakeman’s list of warnings.

Note that even if you end up not having any warnings, it doesn’t mean that your app is secure, since brakeman sometimes overlooks some basic security pitfalls.

Security-wise, there is also a gem called bundler-audit, used for checking vulnerable versions of gems in your Gemfile.lock.

Deadweight is used for cleaning unused CSS selectors. You have to hand out a set of your application’s style sheets and HTML pages, and it will report which CSS selectors are safe to remove.

The gem won’t work out of the box in Rails, since most pages have dynamic content, but Jason Morrison from Thoughtbot wrote a blog post on how to create a Rack Middleware and integrate it into your test suite to collect all the HTML content in one place.

If you’re using precompilers such as Sass or Less, you should compile all of your style sheets and hand them out as simple CSS files to the deadweight task. It is recommended that you remove all the vendor/third-party css files (such as Bootstrap files and similar) since they will end up clogging your output.

Static code analyzer for finding Rails specific code smells. It offers a variety of suggestions; use scope access, restrict auto-generated routes, add database indexes, etc. For a full list of suggestions, check out the rails-best-pratices official page.
Unfortunately, sometimes it reports lots of false positives, such as unused methods. Nevertheless, it contains lots of nice suggestions that will give you a better perspective on how to refactor your code and learn some best practices.

If you like the suggestions that rails best practices gives, you also might find Sandi Metz’s rules for developers quite interesting. You can check if your code complies to Sandi’s standards with the sandi_meter gem.

A Ruby static code analyzer which you can use to check if your code complies with the Ruby community code guidelines. The gem reports style violations through the command line, with lots of useful code refactoring goodies such as useless variable assignment, redundant use of Object#to_s in interpolation or even unused method argument.

A good thing is that it’s highly configurable, since the analyzer can be quite irritating if you’re not following the Ruby style guide 100% (i.e. you have lots of trailing whitespaces or you double quote your strings even when not interpolating, etc.).

It’s divided into 4 sub-analyzers (called cops): Style, Lint, Metrics and Rails. You can define which cops to use, as well as which files to exclude/include and tweak various other configuration options in a .rubocop.yml file.

A relatively new gem that wraps around three static analysis gems – Reek (ruby code smells), Flay (code duplication detection) and Flog (ABC metrics). It creates nicely structured HTML files so you can browse through your smelly code and start refactoring. Out of all of the mentioned static code analysis tools, because of it’s nice output, it’s most convenient to overview and comment with your colleagues.

If you’re working on an open source project or can afford to automate the process of running all of these static code analyzers on every commit, I would suggest using the code climate service. In case you decide to go down this route, I suggest reading “A Ruby on Rails Continuous Integration process using Github, Semaphore, CodeClimate and HipChat”, a blog post written by my colleague, Jan Varljen.

Most of the functionalities that the listed static code analyzers can offer you is already wrapped inside it. Besides code quality reports, there is an optional code coverage report (basically what simplecov does).

One thing to note is that you shouldn’t take each warning issued by these static code analyzers too seriously. Most of them will throw lots of stuff at you that you will probably never refactor because it will take you forever, and for some you just shouldn’t care (such as final newline missing or spruceing up your auto generated schema.rb). Sometimes they can generate lots of rubbish, but that can be prevented by doing code reviews on a regular basis and by tweaking their configuration options.

When your client asks for some copy editing on their website, does it take too much of your time? Or maybe you’re the client and every time you ask your devs to change one sentence on your website, it takes them a week?

You’ve all probably been there – you’re creating a simple website, a couple of pages, mostly HTML and CSS, maybe a marketing site/one-pager for a product or service. You feel a full-fledged Ruby on Rails Content management system would be more of a distraction than it would provide real business value to the client, but manually editing the code is a waste of your time and money.

Phrasing is an inline live content editing library that can be installed to any website so anyone can manage content and get a preview of what those changes will look like in real time.

Take a look at this short intro video below:

The name Phrasing originated from Archer, a popular animated comedy series.

We build all of our websites using Ruby on Rails, so we created a gem to solve this problem. In the Ruby world, a gem is the name for a reusable library which can easily be installed to any application.

If you are thinking by now that a micro CMS does the same thing, you’re not far off.

The gem is open sourced on Github, so anyone can use it. The setup process is very quick and straightforward – it shouldn’t take you more than 3 minutes to get it up and running.

After a short initial setup where you include some code and configure who will be able to edit phrases, you can start placing phrases all over your website. Just mark each editable region (phrase) with a key (such as post-title or about-us-description) in the HTML and set an initial value later.

Finally, you can show your client the website and enjoy them patting you on the back.

There’s a floating status window in the bottom right corner of the web page. Here you can track whether all the changes you’ve made are saved, and also switch from edit mode to read-only mode. The read-only mode shows you what the page looks like to a regular user.

Alongside the basics I describe here, Phrasing has a couple of other features:

Since Phrasing is built on two other libraries called Copycat and ZenPen, I want to thank all of the authors and contributors of both libraries for making them awesome, well documented and open sourced!

If you are interested in using the Phrasing gem in your own application, just follow the instructions on this page. In a couple of minutes, your clients will be able to edit content, and you can get back to doing productive work.