Rake tasks are a very important component of our Rails Apps, because we usually use it to do maintenance or data migration jobs over a collection of data.

One of the guys at the office asked me. What things should I keep in mind when writing a rake task and how do I know if my rake task is well written.

The answer is not simple, because most of the time depends on the task you need to accomplish. I have a few rules I use to make my rake task what I consider good rake task.

What Makes a Rake Task a Good Task?

I think a rake task is good if:

• It has a meaningful and simple description.
• It uses namespace to group similar or related tasks.
• Its file structure follows the namespaces structure.
• It’s isolated on a class so we can re use it and test it with ease.
• It displays details about it progress without being too verbose.
• Its has it own log file containing start datetime, end datetime...

Lately I’ve been supporting several legacy projects.

As many of you may know, working on legacy projects sucks most of the time, usually because most of the code is ugly and difficult to understand or read.

I decided to make a list of common bad practices, or what I consider bad practices, and how to improve the code or avoid this bad practices.

Summary

• Using Query Methods Outside Models
• Using Logic Inside The Views
• Using Meaningless Names On Variables Or Methods
• Using Unless Or Negative Expressions On Conditionals
• Not Using Tell, Don’t Ask
• Using Complex Conditionals
• Using “self.” On Models Instace Methods When There’s No Need To
• Using Conditionals And Returning The Condition
• Using Inline CSS In Your Views
• Using JavaScript Inside Your Views
• Passing Method Call As An Argument When Calling A Method
• Not Isolating Rake Tasks Using Classes
• Not Following Sandi Metz’ Rules

Using Query

This week I made my first contribution to a ruby open source project, devise, the well known, flexible authentication solution for Rails with Warden.

When working on open source projects it’s very important to have a well defined git workflow. Having a well defined workflow will help you to indentify changes on your code easily, revert changes without losing your work, test your ideas without putting your main project at risk, be more organized and so.

You may find several guides talking about git workflow and different ways to accomplish what this post tries to explain. Bear in mind that given git’s flexibility you can achieve the same results in different ways.

Summary

1. Fork the project you want to collaborate with
2. Clone your project’s fork to your local drive
3. Add the original project git url to your fork’s remote list
4. Create a new branch and commit your changes
5. Pull the changes...

Ever since I started writing Rails applications, people always told me to use Decorators instead of Helpers.

So what’s a Decorator

Decorator is a design pattern. Its intent to attach additional responsabilities to an object dynamically. One common use of Decorators on Rails is to group view logic of our Models. This way we’ll keep the business logic in our Models separated from our view logic, otherwise will be breaking the Single Reponsability Principle. You can think of it, as a view logic’s wrapper for our Model.

How does it work?

First thing we are going to do, is creating our Decorator class which should inherit from SimpleDelegator class which comes built-in with ruby:

app/decorators/user_decorator.rb
class UserDecorator < SimpleDelegator

end

Inheriting from SimpleDelegator will make that all methods called from our UserDecorator instance will be delegated to the Object...

StrongParameters is a great gem and it comes with Rails 4 by default. Currently, there are two patterns to work with your attributes.

1. Creating a private method on your controller which returns the whitelisted attributes

 app/controllers/people_controller.rb
class PeopleController < ActionController::Base

  def update
    person = current_account.people.find(params[:id])
    person.update_attributes!(person_params)
    redirect_to person
  end

  private

    def person_params
      params.require(:person).permit(:name, :age)
    end
end

Pros

1. If your person_params logic is simple as the example shows. That’s pretty much, just call the method and it will do the job.

Cons

If your person_params logic grows because, let say you want to permit certain params attributes if your user is an admin and another params attributes if it’s just a regular user:

1. You’ll be adding more...