I’m fairly new to the Ruby on Rails web application framework. I just started learning it about eight months ago when I started developing my web app.
I’ll share a story with you about my experience with Rails, and maybe you’ll be intrigued enough to try it out for yourself.
About My Web App
CompVersions is a web application that allows designers to upload multiple versions of their designs so that their clients can easily give them a thumbs up or a thumbs down as well as provide comments as necessary.
Here are some images of the app:
The idea for the app comes from my previous experiences working with multiple designers. I have, at various points in the past, worked on projects where I was either project lead or project manager and I had to coordinate designs and feedback from multiple designers and stakeholders.
Getting and forwarding emails with PDF files as attachments and notes specifying the line and page number in the PDF was not cutting it anymore.
I tried the popular project management app, Basecamp (also built on top of Rails, by the way), but it wasn’t designed for this problem, so it didn’t work the way I needed it to.
I decided to build my own solution.
A friend of mine (Hector) is on a similar journey (building a web app/site while still learning about the framework), but he is in "Microsoft Land" — .Net, IIS servers, MSDN — the whole nine yards.
I was explaining to him why I love Ruby on Rails (RoR for short), and how it completely abstracts the pain of doing things like database queries (although, if you want to work with them, you surely can).
I was trying to find a real-world example of what I meant, but all I found were the regular "build a blog in 15 minutes" tutorials and articles that take you through the entire app development process.
I didn’t want that, so I started looking through my code and realized that I have the perfect use case to highlight how wonderful it is to use Rails.
He appreciated the example, and understood what I meant by way of a practical, real-world example that’s actually in use.
I figured I would share to you that example I showed Hector.
Rails Business Logic
Rails is known for allowing the developer to focus more on the business logic of the application, rather than the technical, behind-the-scenes stuff.
What does that even mean? Here is an example: I was hooking up the email functionality for CompVersions so that once a designer registers, they get an email from the app.
I used a Rails gem (similar to what a plugin is for WordPress or a prewritten class in PHP) called Devise that makes it relatively easy to get up and running with an authentication solution. It handles users logging in and out: Registering, forgotten passwords, resetting passwords, and so forth. Locking and unlocking an account — say if your application requires high security where you only allow a certain number of login attempts — was baked right in, no need to code it. It had a bunch of other awesome features that solve everyday web app development problems.
That’s right, you get all that functionality from one Rails gem. All done to industry standard design patterns, e.g., when a user forgets their password, a unique link is sent where they can reset their password.
So the first question I was faced with was, How do I format the email? Not, How do I programmatically tackle something like this? or Can I write code to send out emails?
Do I say "Hi John!"? But what if there is no first name, how do I fallback to their username (sexyjohn79) and then subsequently their email (email@example.com)?
That’s business logic.
Writing the Business Logic
The registration form for CompVersions has input fields for first name, last name, username and email address. A user can log in with either their username or email address. But I haven’t decided whether or not I’m going to let first and last names be required form fields. Most likely, I will, but I wanted to implement it to gracefully handle the situations when a user doesn’t provide one or the other.
Rails uses what’s called an MVC structure. Model, View, Controller. Rails encourages you to put all of your business logic in the Model portion of your app.
In my User model (which is where Rails handles all the business logic related to the users of the app), I created a method called pretty_name that handles the business logic.
This is how my pretty_name method looks:
def pretty_name f_name || username || email end
The first line is the definition of the method. The method is what I will invoke to print out the designer’s name in the email.
The method translated in plain English: "If the value
f_name exists, return that value, if not, try
username, and if that doesn’t exist, then try
|| means OR.
The assumption here is that a username must exist because the user will be getting this message through email. Ruby executes left-to-right.
That’s it. That’s the business logic.
Applying the Business Logic to the View
In my template for the actual email — the View in MVC — this is what the first few lines look like:
<p>Hi <%= @resource.pretty_name %>!</p> <p>Thank you for registering with CompVersions.</p>
The template prints ‘Hi ‘ and then it invokes the pretty_name method on the object called
@resource is an object that is used to refer to the current user account and then returns the best value.
So if the person’s first name is John and it’s available (i.e., the value is not
nil), the email will say ‘Hi John’.
If there is no first name, it will use the username (e.g., ‘Hi sexyjohn79’).
If there is no username, it will say something like ‘Hi firstname.lastname@example.org’, falling back to the user’s email address.
Here is an example of how the email looks.
Some Parting Thoughts
So is Rails really a walk in the park for non-developers?
I don’t want you to misinterpret what I’ve said. I’m not implying that getting from nothing to a full SaaS web app with no Ruby and/or Rails knowledge is effortless. It’s not that easy.
But as a general rule when using Rails, the things you will be struggling with (once you get the basics down) are related to how the app will function (business logic) rather than the minutia, set up, coding syntax, and the writing of common web app methods and functions. The focus will be on the logic of the app rather than missing semi-colons, setting up a code project, and errant SQL queries.
Like all web development frameworks, Rails has its quirks. Rails has a set of conventions that make sense and force you to develop a certain way, which makes it especially tricky for those immutably set in their processes.
I hope this helps encourage you to try Rails and to consider it for your next web app project. There are many awesome tutorials out there. For starters, I would recommend Rails for Zombies.