Wyncode Academy Blog Posts
Read about South Florida’s first development bootcamp
Top 5 Most Common Rails Mistakes
Written by wyncode on 15th August 2014, 6:02 PM
Ruby on Rails, otherwise known just as “Rails”, is an open-source framework whose aim is to utilize the Ruby language to make developing web applications easier.
The problem is that same ability to follow conventions can lead to ambiguous statements that can cripple a program that should otherwise work. You might spend hours trying to debug your application, only to find out that it was a an explicit few lines of simple logic that fouled everything up.The best way to prevent this mistakes is to stop them before they happen. Let’s look at the five most common Rails mistakes.
1. Too Much Logic for the Controller
The controller should always have a minimal amount of logic. This makes future additions and debugging easier, as all the real actions behind your code should be segmented to just your models.
When it comes to your controller, try to limit any logic to the following:
- Session and cooking handling
- Model selection
- Managing request parameters
2. Too Much Logic in the View
Repeated code can be one of the more problematic things when it comes to Rails. That’s why one of the main principles is to keep the View as simple as possible.
Imagine a place in your View that tests to see if a user is logged in. Instead of creating elaborate functions to check if they’re logged in at the view, simply make it so that there’s a helper function that returns an input. This way you only need to define an object that returns the user’s name or “Guest”.
The best part is that it’s easy, succinct and reusable.
3. Stuffing Odds and Ends into Helper Classes
Rails functionality should always be divided appropriately between the Model, the View and the Controller. The problem is that sometimes functions don’t always seem to fit into one of these categories.
This leads programmers to create stuffed “helper” classes with functions that are unrelated but necessary.
To avoid this, always ensure that you group your functions together by similar functions and purpose. Creating an entirely new class for one function may seem like a lot of work, but it’s necessary to keep code clean and readable.
4. No Automated Testing
Failure, whether it occurs at the high level of integration with other applications or at the low level with hardware, should always be caught. Automated tests are one of the few ways for this to occur.
The problem is that so many Rails applications are developed without automated testing. Automated testing frameworks that have been integrated into your application as you create it will enable you to catch otherwise fatal errors before they occur, which is why you should always opt to use them.
5. Blocking When Calls to External Services Fail
Most providers of third-party Rails services make it very easy to use gems that encapsulate their API functionality. The problem is that these gems tend to result in blocking when that third-party service is down.
To avoid having your entire application stopped, employ a gem like Delayed Job, Resque or Sidekiq to have your jobs run in a background queue.
If you can’t use background queues or delegate processing just doesn’t make sense for your application, then ensure that your application has enough error testing code to handle any error an external service might return.
Fixing Flaws Before They Turn into Problems
While Rails hides the majority of the ugly details that occur behind the scenes, this doesn’t make any Rails code impervious to pitfalls that can make it slow and unreliable. High-quality Rails applications can only be written when the proper MVC model and conventions are used, as the majority of the mistakes here show.