Project Ramon

A learning journey from a Ruby noob perspective – What I’ve Learned So Far


I’m ramping up this week and next to begin my next project with AirPair. I wanted to write about my past two projects during this coming week and share the technologies used, and what I’ve learned from all of the expert mentors.

Today I’ll be covering my first project, it’s called eventorchid. Event orchid is a social activity site where people can come together to enjoy different venues as a group. This is definately good for someone who has just moved into a new area, but provides benefits for those of us who are wanting to expand our social circle based upon our interests and not necessarily our work, church, neighborhood, or family social circles.

Lets get started by showing off the different gems I used for this project.



I, like most people in the Ruby world, use the bundler gem to manage my application’s dependencies in one nifty Gemfile. Heroku requires us to specify the Ruby version we are using in our Gemfile, I’ve also used the gem 'thin' webserver so that I won’t have to use the alternative WEBrick server when looking at Heroku logs for debugging.

gem 'devise' is an authentication API that provides robust options such as offering a reset password strategy, password limit, and among other things, some template starters such as login/logout hyperlinks for our view files.

You can find out what each of the gems do in the above illustration by googling the name in single quotes (no need to include versioning numbers), and adding github to the end of your search.

Another thing you probably have noticed are the two separate group blocks named :assets and :test. The gems inside of the :assets block sort of give away a strong hint as to what an asset in Rails really is. Here is a well-said snippet from the Rails guides:

What is the Asset Pipeline?
The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.

So it may be safe to say that an asset is either a .css or .js file (typically, there can be many files of both roots), and the asset pipeline concatenates each of these files into a .css or .js master file that is placed into the public/assets folder upon issuing the RAILS_ENV=production bundle exec rake assets:precompile at the command line before deploying your application code to Heroku. You can read more about what I’ve learned about the Rails’ Asset Pipeline here, and here.

Data Modeling

Rails, like most web development frameworks follow an MVC pattern. The main benefit of patterns such as MVC is the separation of concerns. M stands for Model, which is where the data for the application gets placed into and pulled out of. Its used to talk to the database through an Object Relational Mapper, in the case of Rails, typically Active Record. There are two other places where we place our application concerns, View and Controller, which we will cover in just a bit.

In Event orchid, I have 6 modest models. Models in Rails are just Ruby classes, filled with attributes which are properties of an object (like name, degree, age, etc..). A Rails model will also usually contain instance methods which are capabilities that each object created by said class can perform. Think of them as the verbs, for instance here’s a method defined as full_name thats composed of a first_name attribute and a last_name attribute like so:

Here are some illustrations of my models in Event orchid. I’ll provide a short description of how these classes work with one another shortly.





The User model includes some attributes from devise in line:4 & line:5. These lines as well as line:3 show some of the options that we have when using this gem as our authentication choice. Next on line:7 I am setting a white list of attributes for mass assignment. I could also have done attr_protected to deny access for mass assignment for some or all of the above mentioned attributes.

The two has_many relationships on line:7 & line:8 shows that the classes Attendance and Event belongs_to a User. What this essentially means is that a user_id will be expected in each creation of a new event and a new attendance. The reason why we see (again in lines: 7 & 8) plural forms of the models Attendance and Event is that a User will have an ability to create an infinite number of these, and each of them will be associated with a specific user_id.

Finally, on lines: 13 to 16 we are seeing some form validations. This is to ensure that we receive valid data within some defined parameters. Line:13 validates that an email is in a certain format. This one is saying that from the start of a user’s entered string, any letter, number, or underscore plus an @ symbol followed by any single character from a-z is valid. And that this email valid string check is also case insensitive.

On line: 14 we validate the attribute named :email and include that the presence of user data upon object creation is required. Then we ensure our format with a hash that includes our email regular expression checker, and a link with a max character limit of 50.

Finally on line:16 we validate the attribute :password and create a rule that a user’s password needs to be at least 6 characters in size.

The Attendance class has no attributes or methods, and only defines it’s relation to the Event and User class. The belongs_to specifies that Attendance will be created through each event and a user can have one attendance per event.

In Event, after our list of attributes white listed for mass assignment, we see that a :venue will control the creation of an event, and there will be many attendances. The meaning of line: 7 has_many :users, through: :attendances means that the attendees will be considered users. So each user, if they are interested in said event at a specific venue, will be considered one attendance.

And moving beyond the basic validations in lines: 12 through 16, we have a wrapper method from the Attendance model. This used to be something that stumped me quite frequently, but thanks to a host of AirPair mentorship, and a couple of friends I’ve met through AirPair, Russell Baker, and Marek Publicewicz. I’ve finally learned to stop over thinking this beautifully simple way to delegate properly.

Lets slow down a bit so I can show you some notes that Russell sent me to help me better grasp and understand.


A closely related thing is happening in Event orchid. First let me highlight the code I’m referring to:

Since we have defined a relationship in both Event on line:6 and in Attendance on line:2, we can now refer to Attendance as attendances because of how we named the has_many :attendances. You can look up what the dependent: :destroy means here in the Rails Guides (it’s their fourth illustrative box from the top).


Here’s another excerpt from the Rails Guides to share the purpose of a controller in an MVC web application:

For most conventional RESTful applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that’s not a problem, this is just the most common way for a controller to work.

A controller can thus be thought of as a middle man between models and views. It makes the model data available to the view so it can display that data to the user, and it saves or updates data from the user to the model.

Here is an illustration of one of my controllers.


If you’d like an overview of my efforts in learning about controllers, you can check out My first refactor with AirPair mentor Adam Cuppy.

Basically, there are 4 HTTP verbs that map to 7 controller action methods. The four HTTP verbs are as follows:


And the seven controller actions are:


Although create, update and destroy don’t have representations in our rails application’s file tree (there are no folders for these actions). An explanation of the other four action methods will help to clarify.

Index will use the HTTP verb GET to retrieve a list of all resource representations from the database. The new controller action method will present a blank form to a user for them to enter data into. Once the data has been properly entered (remember our validations in our Model from earlier?), and the submit button has been clicked, the data entered into the empty form presented to the user with new will be sent to the create action where the HTTP verb POST will commit the data into our database as a resource.

Show will use the HTTP verb GET again, but instead of pulling out all the resource representations like our index action did, the show action controller method will use a resource identifier to pull only the information associated. If the user has the appropriate privileges then they will be able to edit this resource. Once a user has edited whatever thing they needed to, and hit the submit button. The update action takes over and will use HTTP PUT to update any old data.

The same thing goes for destroy. A user will first see a record (unless they’re in a Rails console session), or a list of records, and upon selection of a delete/destroy/remove button, will be guided to confirm a deletion was the desired effect. Once this delete confirmation (i.e. ‘You sure you wanna delete me?’) has been made, then the record is no longer in the application’s database.


I could go in a similar level of detail with views in Rails as I did with the Model and Controller layers. The beauty of saving views for last is that, really we’re just creating a visual representation of a resource. There are view files that are created to receive data to commit to the database, and there are view files that display data from the database. I haven’t had a chance to use any fancy template tools as of yet (i.e. Haml), but when I do, I’ll be sure to write a post or two about my experience using it.

Here is a short list of some links pertaining to improving your view code if you’re a beginner like myself. Feel free to add to this list in the comments!


    Integrating Twitter Bootstrap

    This session about understanding server logs with John Davis really helped open my eyes and boost my confidence to debug my own issues.

I hope that this post wasn’t too long-winded for any of you, if you have any suggestions on how to make my next post which covers what I’ve learned while building Sevendaysports, please feel free to comment.

Stay tuned!


Categories: AirPair, Newbie, Ruby on rails

Tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s