A 10-point checklist for building apps with Ruby on Rails

Here are 10 things I recommend entry-level developers always consider when building an application with Ruby on Rails.

1. Don’t dive into coding first

I know. I’m dying to code. But, there is important groundwork to be done before getting started. There are two reasons for this:

1. Programming is just a tool; not a purpose or a goal.
2. Well-considered structure saves time

The first thing is more like a business issue. Before starting to write code, you must consider,

• What is your app for?
• Who uses this app?
• What is the core user journey?

The second reason is more of an engineering matter:

• Create schema first to achieve the first core user journey
• Draw views for each page, and write HTTP verb(=GET)/ path(route) / controller / method that lead you to that page
• In every link and button in the view, describe HTTP verb/ path(route) / controller / method

The last point is often overlooked

#2 Write pseudocode

Writing pseudocode helps you,

• Organize your ideas
• Give you team helpful context
• Easy for you to catch up when you look it back later

These notes are important because just a few days away from a project, and you can forget why you made some of the decisions you made.

Below is and example of pseudocode (source). What I focus on is,

• Write sentences first and put index when I think it’s done
• No need to make it perfect at the beginning, but revise it regularly

#3 Check the credibility of gem

Ruby is great in that it has a bunch of external libraries but, the more you use them, the more complex dependencies become. Code gets harder to fix when you want to update versions.

When I want to use external libraries (not just Ruby gem) I check

• Number of stars and forks in Github
• Profile of the builder
• Number of contributors (if less, maybe it takes time to solve issues and version dependencies)
• The last update date (is it still actively revised?)

#4 Use service object

Try to put general modules out of a specific controller.

I think it takes a little time to get used to for people who are new t to programming, but this helps you to fix bugs more easily.

Here is an example from when I created an app to visualize a food menu. I split a task using Google Cloud Vision API inside app/services/ folder and tried to keep those features apart from controllers.

You can see a better explanation about this here.

Rails Service Objects: A Comprehensive Guide

Ruby on Rails ships with everything you need to prototype your application quickly, but when your codebase starts growing, you'll run into scenarios where the conventional Fat Model, Skinny Controller mantra breaks. When your business logic can't fit into either a model or a controller, that's when service objects come in and let us separate every business action into its own Ruby object.

#5 Don’t create logic in your view, there is ‘helper’

This is really sort of a corollary to the one above. Don’t put any method-like code in your view.

MVC model stands with the concept to split tasks to make a large application more simple and easier to maintain. View is for outputting some value of the object, so it’s recommended to separate logic, especially when that can be used among multiple files.

This is where helper method comes in. You can write a method inside app/helpers/xxx_helper.rb file and call it directly from .html.erb file. ( Some other code needed in Rails 4)

The sample code shows two ways to output exactly the same thing (the title is shown only first 17 letters, if it exceeds the limit, replaced by … ).

The Beginner's Guide to Rails Helpers

Basically helpers in Rails are used to extract complex logic out of the view so that you can organize your code better. I've seen two benefits for using helpers in my experience so far: Extract some complexity out of the view Make view logic easier to test Let me explain each one of those points.

#6 Partials

You might use “the same” visual templates — components such as navbar, sidebar, cards etc… What does “the same” mean in your source code? Yes, you don’t have to write them twice (or you shouldn’t !). You can pack general html into app/views/shared/ directory and use it from anywhere with render method.

Rails Guide is my first choice as a reference.

#7 Use begin-rescue error handling

The old saying, “there’s no rule without exceptions,” is not only applicable to the business world. Even if you make a list of possible cases all day long, there will always be others . I don’t mean you should address every single possible error (but professionals do). Instead, you’d better decide what to do when errors occur.

Ruby, of course, has a way for exception handling. It’s called begin/rescue (basically the same as try/catch for JavaScript (or C#, Java etc)).

#8 Less transaction to the database

So, what can you do to improve performance? This question is particularly relevant when you deploying for free since resources can be lacking.

One thing you can do is to make fewer queries to the database. Although deciding whether we should make calculations in the app server or database server depends on the case, making queries is an ‘expensive’ action (factor of slow speed).

Write the SQL query first and then execute it. You can get an idea from this example:

ActiveRecord::Base.connection.execute(sql) , ActiveRecord::Base.connection.select_all(sql) would be the choice, but Model.find_by_sql() is the easiest to use.

Bear in mind, you should use an index with columns frequently referenced.

#9 Get used to Git commands

Most of the time you’ll create an app with a team. There you manage all of the members’ progress at the remote. (Using Github is most common. Some of you just use Git with a production server on-premise).

I won’t show you specific code for each action in detail here, but one thing I will say is that before you really push your branch to remote (often when you’re filled with a sense of accomplishment ), rungit fetch origin, then git merge master and resolve any potential MERGE|CONFLICTs.

via GIPHY

It’s always a pleasure to push your work to remote. (GIFTY)

(There’s another way to do that:git pull origin master but some people don’t recommend this way.)

Merge conflicts are not a systematic problem but a communication problem.

#10 DRY, but…

In general, you should keep DRY (Don’t Repeat Yourself). This is the first step for a good programmer from a technical point of view.

However, you have to be careful when you modify your DRY code. Before modifying them, check where that method is used which means the range of effect by modifying. And modify other parts as well so that your app gonna work well.

And later on, I’ll make another post about this — _write a test _!!!