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

Yuta Fujii
Feb 11 · 6 min read

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
Pseudocode

#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.

Take notes about how you thought and wrote the code

You can see a better explanation about this here.

#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 … ).

Define your method here and
Use it inside the view file

#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.

20-line index page is composed of 3 parts (navbar/sidemenu/cards) source

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)).

The more familiar you get, the more concisely you want to handle errors.

#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:

multi-line string looks better

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.

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…

The best Japanese beer for RoR enthusiasts (GIFER)

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 !!!

Building A Web Or Mobile App?

Crowdbotics is the fastest way to build, launch and scale an application.

Developer? Try out the Crowdbotics App Builder to quickly scaffold and deploy apps with a variety of popular frameworks.

Busy or non-technical? Join hundreds of happy teams building software with Crowdbotics PMs and expert developers. Scope timeline and cost with Crowdbotics Managed App Development for free.

Crowdbotics

The fastest way to build your next app.

Yuta Fujii

Written by

Data Scientist(NPL) & Full-stack developer of FinTech. Majored in physics and have 3-year experience in an investment bank( structured finance ). Learn or Die.

Crowdbotics

The fastest way to build your next app.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade