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
: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?
So it may be safe to say that an asset is either a
.js file (typically, there can be many files of both roots), and the asset pipeline concatenates each of these files into a
.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.
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.
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.
has_many relationships on line:7 & line:8 shows that the classes
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
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
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
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.
Attendance class has no attributes or methods, and only defines it’s relation to the
User class. The belongs_to specifies that
Attendance will be created through each event and a user can have one attendance per event.
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
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!
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.