March 30, 2013 - No Comments!

The Rails Code

Here is a few stuff that, I wish I knew, or I forgot along the way when developing asknative’s API. Just know that I didn’t have any previous REST or Rails background before that, so keep that in mind while reading.

Code Structure

  1. Controllers. Its job is to take data from the request pass it to models, then pass leave it to views. So don’t put any thing more than that, not queries not JSON response messages.
  2. Models. Defines your documents(tables in SQL), relations, queries it, and other functions thats needed for the model or controllers. It’s like helpers for Controllers. Most of your coding will be here.
  3. Views. Can be HTML, or JSON. So never define put conditions there nor queries. Thats what are helpers for. Even if you just do simple user.count.
  4. Helpers. Used for handling simple and complex functions that is only needed for the views. If you need something outside views scope, define it in the model. Else go with helpers. This will make your code readable, more easy to change, and accessed by other views.
  5. Gems. Give you extra predefined functionalities without messing your code.

Controllers = Managers (They never do actual work)

First thing to know is to keep your controllers thin, and models fat. Controllers are supposed to connect, and thats it. It manages everyone, so don’t put extra work on it. Because if you did, it would really be hard read or change your code unless you do that.

Use before_filter in controllers to handle repetitive tasks like User.find(params[:id]), and make sure you define who will need this using only and except.

If you have something that takes parameters, and needed in all controllers like limit and skip, you can define it as a protected function in the ApplicationController so that it can be accessed and changed for all the application.

If there is a case that you still don’t want to create a function in the model that handles specific tasks in the model, then create a private function that will be called in your controllers. So that you still have a clean and readable code.

As a general rule, controllers should only call functions, and if conditions that call specific functions for each situation then pass it to views. I can’t stress this enough, but this is the most important place to be readable, when you look at it, you should know what goes where and to whom.

Models are Fat

Models are helpers of the controllers, if you need a query or a function, it should be there. You can use def self.query to use it like this User.query without having to define it first. Which comes in handy for listing queries. But incase you need something simple go with scopes, they are simple and more efficient.

Use model callbacks like after_save, and before_save to handle errands. If you want to notify the user when there is a new post, then put it in after_save method.

Gems are cool

Everyone talks about how bad gems are when you are getting started with Rails, I disagree. I think they are amazing, as they help you see how you can do things correctly. Because when getting started no matter what you do you will mess things up, so I believe don’t try to run before you can walk, don’t get ahead of yourself. Use gems, and when you become strong enough, you can create your own gems that are specifically tailored for you.

Respect for RSPEC

I’m guilty of being scared of testing. I thought it was hard, but it turned out to be a life saver. It is extremely easy, and will get out of your way. You don’t need to open the browser to test a case, and you can’t the whole application in the browser every time you want to deploy.

Whats awesome about testing is that you can test everything, without doing it yourself. You don’t have to remember all the cases which broke your code. You just have to write it down.

For me I started doing this lately, so I still write dump repetitive code, but it works great.

Use watchr while you are refactoring so that it makes sure that nothing breaks, and if it does, you can handle it quickly.

Before deploy just run your test, and save your self some embarrassment after you deploy and find a stupid issue.

If you like this post, stay tuned for mongoid tips post.

Published by: Seif in Development

Leave a Reply