Archives For Ruby

In my previous post, Ruby Version Manager (RVM) Overview for Rails Newbs, I outline RVM’s architecture and fundamental features. That post is also very focused on RVMs role when running rails new.

BeforeAfterToday, I’d like to cover a few more common scenarios Rails developers will encounter after the initial install of RVM. More to the point though, we’ll be focused on how RVM can be used to optimize workflow in these scenarios.

1.  USE A DISTINCT GEMSET FOR EACH PROJECT
In my own development journey, it wasn’t initially clear to me when I should be creating new gemsets. If you too have pondered this question, here’s my suggested answer…create a new gemset for every project you are working on. This approach is not only clean and orderly but more importantly reduces the chance that gem dependency errors sidetrack your work.

As a refresher, here’s the necessary commands to create and use a new gemset:

$ rvm gemset create new_gemset_name

$ rvm gemset use new_gemset_name

Hopefully you’re starting to get some clarity on the use-cases for global, default, and custom gemsets. Basically, global and default are largely used to influence what you get from rails new. Custom gemsets are then used to manage all gems related to a project from that point forward.

RVM_architecture

2.  AUTOMATICALLY CHANGE RUBY VERSION AND RUBY GEMSETS WHEN MOVING BETWEEN PROJECTS
Like all devs, I’ve got lots of active projects in various stages on maturity on my machine.  Before I came across this little nugget of knowledge (just keep reading!), I was frequently running:

$ rvm use ruby_version_here

and then

$ rvm gemset use gemset_name_here

It worked pretty well, but when moving between projects in my command line I often got gem-related errors when trying to run rails s or rails c. The problem was that if I forgot to tell RVM to change gemsets when I moved across projects in my command line, the gems that project expected to be available weren’t there.

Before I get to the solution here, humor me with a quick aside…

In a previous life, I was an Excel junky. I really loved Excel and what it could do. Just like development, it offers an incredible combination of logic and creativity. Also like development, the mouse is not necessarily your friend. Learning to do things without leaving the keyboard can be a HUGE time saver. People who were more mouse-dependent would sometimes look over my shoulder as I worked and say, “dude, you need to teach a class on Excel!”. It was a nice compliment and while I was interested in sharing both my love of Excel as well as its features, I would often respond with,

“if you are ever working in Excel and thinking ‘there has to be a better way to do this’. There is. You just need to figure it out.”

The point is that even though I espoused awareness of this phenomena in the context of Excel, I lamely continued with my error-prone use of RVM for some weeks. It wasn’t until my good friend @megharastogi noticed what I was doing and said, “why don’t you use an .rvmrc file?”.

Eureka! An .rvmrc file sits at the root level of your application and basically tells RVM which Ruby version and gemset to use. RVM is smart and interprets these files as you navigate project folders in the command line.

Below is an actual .rvmrc file in one of my apps. It’s stored at your_project_name/.rvmrc or in the below case social-playlist/.rvmrc.

Screen Shot 2013-08-26 at 8.15.50 AM

Your .rvmrc file should be in the same location as your .gitignore, Gemfile, and README.

Boom! No more gem-related errors. Time saved. Happy dev.

3.  CREATE AND USE A NEW GEMSET WHEN RUNNING GIT CLONE
If you haven’t yet, at some point you’ll clone an existing repo. After doing so, likely your first task is to ensure you can get the app running locally in your development environment. For a Rails app, having the required gems present locally is a critical step in the process.

While you’ve cloned the repo, the repo likely doesn’t contain the actual gems. It merely contains a statement of what gems are necessary, via the Gemfile.

Here’s my recommended order of operations:

1. Review the repo’s README file.

2.  Check the Gemfile of the target repo to see if a Ruby version and or gemset name is explicitly stated. (If it’s a Rails app, a Rails version will surely be stated).

3. Check the target repo for a .rvmrc file at project_directory/.rvmrc. If yes, this often also tell you which version of Ruby as well as the gemset name being used.

NOTE:  As per the Typical RVM Project Workflow, other potential locations where Ruby version and/or gemset dependencies may be stated include files named: .versions.conf, .ruby-version.

4. If a Ruby version is explicitly stated, ensure that Ruby version is installed locally on your machine with $ rvm list

a. If that version is already installed locally on your machine, make it active with $ rvm use ruby_version_here and go to step 5.
b. If that version is not installed locally on your machine, get it with $ rvm install ruby_version_name                                       c. If no version of Ruby is explicity stated, I recommend using the latest stable version.
d. Make the target version of Ruby active with  make it active with $ rvm use ruby_version_here

5. Run $ git clone target_repo_location_here

Note: Both of the above commands clone the same repo, they just use different security protocols. For the truly adventurous reader, here’s a deep dive on the hows and whys of each protocol.

6. $ cd newly_created_directory_name

7. $ rvm gemset create new_gemset_name

Note: If the repo already contained a .rvmrc file with a gemset name, consider naming your local gemset the same as what’s being used by the other dev(s) pushing to the repo.

8. $ rvm gemset use new_gemset_name

9. $ bundle install

If no .rvmrc file is already present in the app, create one! It’s up to you if you include the .rvmrc in the .gitignore (I strongly suggest you do not! This as an important file for ensuring consistency across collaborators).

While not RVM specific, for good measure I’ll also offer up the other following steps to get the newly cloned app running locally.

10. $ rake db:create

11. $ rake db:migrate

12. $ rake db:seed (optional – only run if seeds.rb contains seed data).

Unless there’s database or server specific requirements, that should suffice to get the app running locally with rails s.

Looping back to the big picture before closing out on this topic. Now we have a distinct gemset just for this project (meeting the objectives of best practice #1) – and automated instructions for RVM to use this gemset whenever this project is active (meeting the objectives of best practice #2) in the command line. And we can be confident we are mirroring the Ruby and Ruby gem configuration of the other devs on the project.

4.  CREATE A “RAILS 4 SCAFFOLD APP” FOR QUICK REFERENCE
In my other post, Reading Rails 4: MVC and Scaffolding for Rails Newbs, I go deep on some of the code generated when running rails generate scaffold.

My original title and concept for the post was not Rails-version specific. I thought it would mostly be about MVC and scaffolding – but be agnostic of Rails version. However, by reviewing the output of rails new and rails scaffold (while having RVM use Rails 4), I quickly and easily learned a lot about Rails 4 versus the Rails 3 versions I was more familiar with.

The point here is that RVM (combined with rails generators), is your assistant in having multiple boilerplate/clean versions of working Rails apps side-by-side on your machine. This makes it easy to access, evaluate, compare, and understand fundamental changes in Rails versions. Personally, I found reviewing the output of a Rails 4 scaffold more educational on mass-assignment in Rails 4 than any online documentation.

If helpful, here’s specifically what I’m suggesting. Say you’ve been hesitating getting onto the Rails 4 bandwagon because you are up and running and proficient in Rails 3. Maybe you feel too busy right now to slow down and learn the “gotchas” in Rails 4. Well, I think 5 minutes spent on the following will probably get you past that hurdle

  1. Create a new gemset called “rails4scaffold” with $ rvm gemset create rails4scaffold
  2. Make the new gemset active with $ rvm gemset use rails4scaffold
  3. Install Rails 4 in that gemset by running $ gem install rails 4
  4. Create a new app by running $ rails new rails4scaffoldapp
  5. Scaffold a basic MVC in that app with rails generate scaffold books title author
  6. Run rake db:migrate
  7. Now go inspect key files like app/controllers/books_controller.rb and run $ rake routes to see how Rails 4 handles basic CRUD.

If you haven’t yet, consider moving Rails 4 into your default gemset!

SUMMARY
As always, I really appreciate you reading my post. I hope it’s been useful for you in getting more value out of RVM. Your comments and feedback are welcomed.

One other quick point is that there are other tools and approaches for doing what RVM does (quite well in my opinion). However my goal is not to promote RVM, but to promote knowledgeable, confident, and satisfying development experiences. As such, I want to share a post titled “Vendor Everything” Still Applies by Ryan McGreary. In it, he makes some interesting and compelling arguments for an alternative approach to gemsets and gem management.

I’m personally still using RVM, but that doesn’t mean I will forever.

Truth fears no questions.
-Napoleon Bonaparte

Reading between the lines of Mr McGreary’s post as well as some of the comments, I think the main point is that consistency in approach to gemset management within a collaborating group is critical to developer happiness and productivity.

Here’s some of my other posts you might like:

Peace.

In my previous post Top 10 Gems for new Rails Devs, I covered both the Devise and Twitter Bootstrap gems. Each of these gems is great at what they respectively do (authentication, design/styling). In this post, I’ll bring @plataformatec and @seyhunak‘s gifts together and easily put Devise sign-in and sign-up forms into Twitter Bootstrap modals.

defaults

What is a modal? If you aren’t familiar with modals, they are basically “pop-ups” or “prompts” that take a priority position in the user experience. If you’re interested in more theory regarding when and how to use modals, check out this post.

Getting sign-in and sign-up modals working in your application is not only a great introduction to using modals, but I think this feature creates a quality “first impression” for site visitors as well.

Want to see this code in a working repo? I’ll be orienting this post around a working implementation of this feature at www.social-playlist.com. This is a site I built with my good friend @lostincode. The project is open-source, so if you want to see everything in-context you can do so at https://github.com/lostincode/social-playlist.

Okay, let’s get started…

STEP 1:  BUILD THE MODAL PARTIALS
Partials are basically re-usable pieces of code falling into the the View portion of MVC. (For a Rails 4-specific explanation for MVC, check out my other post Reading Rails 4: MVC and Scaffolding for Rails Newbs.

Partials in Rails are easily identifiable based on the preceding underscores _ in file names (Example: _partial.html.erb). If you’ve ever run a rails g scaffold, you’ve created a partial named _form.html.erb. This single form is used in both the new and edit views for your scaffolded model. Whether you are creating a new record in the database or editing an existing record, you likely want access to all the same fields. Given the overlap, a single partial can serve in both conditions.

Okay, now let’s build modal partials for today’s feature…

We’re going to need to create some new files and there’s no hard requirements about where they go in your app. I think you definitely want them somewhere in your app/views/ hierarchy, but exactly where after that is up to you.

In many of my projects I use a “welcome controller” and associated views for things like the home page or “about us” page. As such, I think app/views/welcome/ makes a great spot for the below two files.

_login_modal.html.erb

_sign_up_modal.html.erb

Here’s a copy-paste of what I place into each file:

app/views/welcome/_login_modal.html.erb

<div class="modal hide fade in" id="login">

<div class="modal-header">

<button class="close" data-dismiss="modal">x</button>

<h2>Sign in</h2>

</div>

<div class="modal-body">

<%= form_for(resource, :as => resource_name, :url => session_path(resource_name)) do |f| %>

<div><%= f.label :email %><br />

<%= f.email_field :email, :autofocus => true %></div>

<div><%= f.label :password %><br />

<%= f.password_field :password %></div>

<% if devise_mapping.rememberable? -%>

<div><%= f.check_box :remember_me %> <%= f.label :remember_me %></div>

<% end -%>

<%= f.submit "Sign in", :class => 'btn btn-small btn-success' %>

<% end %>

</div>

<div class="modal-footer">

<%= render "devise/shared/links" %>

</div>

</div>

Newb Note! The studious reader will have identified a sub-partial embedded within the partial we just created. Inspect the following statement:

<%= render "devise/shared/links" %>

That’s calling a partial into our partial! Don’t worry if you don’t fully understand just yet, it will all get clearer before we’re done.

Let’s get back to building our own partials. The second and final file we’ll need to create is:

app/views/welcome/_sign_up_modal.html.erb

<div class="modal hide fade in" id="sign_up">

<div class="modal-header">

<button class="close" data-dismiss="modal">x</button>

<h2>Sign Up</h2>

</div>

<div class="modal-body">

<%= form_for(resource, :as => resource_name, :url => registration_path(resource_name)) do |f| %>

<%= devise_error_messages! %>

<div><%= f.label :email %><br />

<%= f.email_field :email, :autofocus => true %></div>

<div><%= f.label :password %><br />

<%= f.password_field :password %></div>

<div><%= f.label :password_confirmation %><br />

<%= f.password_field :password_confirmation %></div>

</div>

<div class="modal-footer">

<p><div><%= f.submit "Sign up", :class => 'btn btn-small btn-success' %></div></p>

<p><a href="#" class="btn btn-small" data-dismiss="modal">Close</a></p>

</div>

<% end %>

</div>

NEWB NOTE! When creating modals in Twitter Bootstrap, make sure to use their built in classes for header, body, and footer. These control margins/padding that help things look just right.

Okay, back to business. Let’s get those partials working for us.

STEP 2: RENDER THE PARTIALS INTO APPLICATION LAYOUT
Remember above when I highlighted the partial-within-a-partial? The sub-partial was invoked using:

<%= render "devise/shared/links" %>

The reason I belabor the point is to establish a universal trend – and here it is…To render any partial, simply call render along with the location of the partial.

In our case, we have sign-in and sign-up buttons in the navbar on every page of our web site. As is the Rails way, we place app-wide View content in app/views/layouts/application.html.erb. Similarly, we want our new pop-up modals available (visible or not) on every page of our site. Accordingly, we put the below code into app/views/layouts/application.html.erb also:

<%= render "welcome/login_modal" %>

<%= render "welcome/sign_up_modal" %>

Newb Note! You might be thinking, “hey, that looks like a typo…aren’t partials pre-fixed with an underscore like _partial.html.erb ?” That’s not a typo, that’s simply the Rails convention for refering to partial location. Also, we do not need to supply the app/views/ elements of the directory path when refering to the location of partials. Rails confidently expects them to be in the V of MVC!

Where exactly should this render code be placed in app/views/layouts/application.hmtl.erb? Again, there’s not much of a hard and fast rule. Personally, I put mine immediately under the  <body> open div.

STEP 3: UPDATE YOUR LINK_TOs
We’re not leaving app/views/layout/application.html.erb yet. Now we need to update our sign-in and sign-up buttons to engage our newly created modals as opposed to their historical forms. We can do this by simply changing the relevant link_to‘s to look like the below.

<%= link_to "Login", "#login", "data-toggle" => "modal", :class => 'btn btn-small' %>

<%= link_to "Sign up", "#sign_up", "data-toggle" => "modal", :class => 'btn btn-small btn-success' %>

Newb Note! The first time I implemented this feature, I placed the above code next to the existing link_to‘s. I did this to make sure everything was working with the new before getting rid of the old way.

One of the critical pieces of any link_to is the second argument – in our case, #login and #sign_up. The values provided here must match the id in the parent <div> of the associated partials. To make sure I’m clear, the relevant code from the parent <div>s are shown here again.

<div class="modal hide fade in" id="login">

<div class="modal hide fade in" id="sign_up">

STEP 4: ADD SOME JAVASCRIPT MAGIC
Everything is just about ready to rock. When I first got this working in my app, I was disappointed that while the modals were popping up, they were dark like the subordinated background. Luckily, this StackOverflow post suggested adding the below into app/views/layouts/application.html.erb

<script type="text/javascript"> $(function ()

{ $("#myModal").modal({show:false }); </script>

If you’re like me, you’re thinking “where exactly should I put that code?”. Kindly the SO post also suggests putting it “right before the </head >” close tag.

STEP 5: UPDATE YOUR APPLICATION HELPER
Okay, so we’ve forms that users want to see. We’ve established a call to render them on every page of our application – next we need to make sure a new resource (the Devise term for user) is instantiated when our modal is engaged.

Thankfully the esteemed Pablo who originally wrote this entry (the birthplace of some succinctly powerful methods and now hosted on the official Devise wiki), provides us the below helper methods to place in app/helpers/application_helpers.rb.

def resource_name

:user

end

def resource

@resource ||= User.new

end

def devise_mapping

@devise_mapping ||= Devise.mappings[:user]

end

STEP 6: ENJOY!
You’re done! Fire up a rails s and check it out in the browser before you git push.

Hopefully you’ve enjoyed and found value in this post. If so, drop me a comment or a tweet @mxstrand! Also, here’s a few other posts you might like:

Thanks for reading.

imagesIn my previous blog post Easy Does IT: Top 10 Gems for Rails Newbs, I highlighted the Brakeman gem for its ability to easily identify, interpret, and resolve security issues in a Rails app. Today I want to offer a few more security best practices for the new Rails developer. Here goes…

STEP 1:  IDENTIFY SENSITIVE INFORMATION
Depending on the feature set, your application might leverage any one of hundreds of internet-based services. Below is a list of some of the most commonly encountered by new Rails developers.

For your rails application to interact with any of these services, a set of credentials (username, password, developer key) must be accessible to your code base.

When I first started working with these tools, I foolishly didn’t consider that I was putting sensitive information on the public internet with every git push. That said, I know I’m not alone. It’s easy to find StackOverflow posts where newer devs are publishing their credentials for the whole internet to see.

One additional sensitive piece of information that is auto-generated during rails new and necessary for every Rails app to function is its secret_token (also known as “secret_key_base”), which can be found at app/config/initializers/secret_token.rb. What is a secret_token? Well, looking into the file’s own comments we see:

# Your secret key is used for verifying the integrity of signed cookies.
# If you change this key, all old signed cookies will become invalid!
# Make sure the secret is at least 30 characters and all random,
# no regular words or you'll be exposed to dictionary attacks.
# You can use `rake secret` to generate a secure secret key.
# Make sure your secret_key_base is kept private
# if you're sharing your code publicly.

Okay, that’s enough discussion – let’s get into some code and discuss how to make it secure. Here’s an example of what I commonly include in app/config/environments/development.rb to configure ActionMailer to leverage Gmail for sending email in dev to see things like the Devise confirmable or Devise_Invitable (a separate gem – check it out!) working before pushing to production.

config.action_mailer.raise_delivery_errors = true
config.action_mailer.default_url_options = { :host => 'localhost:3000' }
config.action_mailer.perform_deliveries = true
config.action_mailer.default :charset => "utf-8"

ActionMailer::Base.delivery_method = :smtp

ActionMailer::Base.smtp_settings = {

:address => "smtp.gmail.com",
:port => 587,
:authentication => "plain",
:user_name => "my_actual_username@gmail.com",
:password => "my_actual_password" }

Now this code works, but I definitely don’t want to be sharing my Gmail credentials with the world. Let’s talk about what to do.

STEP 2:  MOVE SENSITIVE INFO TO A .YML FILE
Before we can move our sensitive info to it, we need to create a new file at app/config/application.yml. Inside that file, we’ll declare our “environment variables” with the following styling.

GMAIL_USERNAME: "my_actual_username@gmail.com"

GMAIL_PASSWORD: "my_actual_password"

If you’re interested, here’s the Wikipedia page about the .yml file history and purpose.

Moving on, now we can move our credentials out of the app/config/environments/development.rb file by revising the last 2 lines of the code block below:

config.action_mailer.raise_delivery_errors = true
config.action_mailer.default_url_options = { :host => 'localhost:3000' }
config.action_mailer.perform_deliveries = true
config.action_mailer.default :charset => "utf-8"

ActionMailer::Base.delivery_method = :smtp

ActionMailer::Base.smtp_settings = {

:address => "smtp.gmail.com",
:port => 587,
:authentication => "plain",
:user_name => ENV["GMAIL_USERNAME"],

:password => ENV["GMAIL_PASSWORD"] }

Newb Note! It’s standard practice to use ALL CAPS for environment variable naming.

Starting to feel more secure? You should! But we aren’t done yet.

STEP 3:  LOAD DEVELOPMENT ENVIRONMENT VARIABLES
Now, we need to tell Rails to load the locally-stored environment variables during application start-up. We can do this in app/config/application.rb with:

if Rails.env.development?

ENV.update YAML.load(File.read(File.expand_path('../application.yml', __FILE__)))

end

That’s it for step 3!

STEP 4: EXCLUDE YOUR .YML FILE FROM YOUR REPO
Next, we need to put the project’s app/.gitignore file to good use. Let’s go ahead and add the following lines to it:

# Ignore environment variable during "git push"
/config/environments/application.yml

If you haven’t noticed or used the .gitignore file before, it does just what the name implies. It tells Git, what files not to push to the remote repository.

Newb Note! Because you are not pushing your app/config/environments/application.yml file into your repository, should you or another developer ever git clone the repo, the clone will not include the necessary environment variables for the application to function properly. This is of course “by-design”, but can be an area of confusion for newbs trying to get a cloned app up and running.

STEP 5:  CORRECT PAST MISTAKES
So we’re secure moving forward, but what if you’ve already pushed a commit to a public GitHub repository that included sensitive info? Here’s a few options in order of complexity.

  • Change your sensitive info (like passwords or secret_tokens) after implementing the best practices outlined above. While the old credentials may still be visible, they’ll no longer work
  • Clone the repo to a new directory, change your sensitive info, implement these best practices, and delete the original repo.
  • If you are wondering if you can delete a commit, the answer is sort of. Here’s more details for the adventurous.

STEP 6:  MANAGE PRODUCTION ENVIRONMENT VARIABLES
Everything discussed above has been focused on environment variables for development. Because the .yml file containing these values is stored locally on your machine, your app can read them. But Heroku (a.k.a production) doesn’t have access to that .yml file on your machine. Don’t worry, setting environment variables with Heroku is easy.

Say for instance we want to set our secret_token with Heroku. When can do so via:

heroku config:set SECRET_TOKEN=123456789012345678901234567890

Or maybe we’re interacting with the Twitter API. In this case we need to set both:

heroku config:set TWITTER_CONSUMER_KEY=1234567890

heroku config:set TWITTER_CONSUMER_SECRET=1234567890

Obviously you can see the pattern. Basically, anything you are storing in your .yml file that your application depends on needs to be configured at Heroku as well.

For a complete description of how to manage environment variables with Heroku, check out this article.

Newb Note! As with all common Rails scenarios, you can probably guess a gem or two is out there to help. In the case of environment variables, I recommend checking out both the Dotenv gem and the Figaro gem.

STEP 7:  SECURE YOUR STAGING ENVIRONMENT (if you have one)
By default, Rails will give you test, development, and production environments. While it’s generally safe to assume that what works in development will also work on the internet (production), for mission critical applications you will likely want to set up a 4th environment called “staging”. Staging is intended to be a mirror of production (also on the public internet) – it’s just not actually open to the public. By first determining that things are working as intended in this production-like environment, you can have a much higher confidence that changes will not negatively impact your end users.

Newb Note! Staging environments are also a great place to do performance testing and reproducing customer-reported issues without actually impacting production services.

So we’ve discussed the importance of staging, but specifically how do you put something on the public internet, but not have it public?

Rails to the rescue again! Rails has a nice, little built-in method that you can drop right into your application_controller.rb. Here it is:

before_filter :http_authenticate if Rails.env.staging?

def http_authenticate

authenticate_or_request_with_http_basic do |username, password|

username == "some_username" && password == "secret_password"

end

end

Oops! Did you notice what I did there? Once again, I’ve got my sensitive information embedded in my code and being pushed to the repo. Thankfully, I know how to move these values to an environment variable – leveraging a .yml file for development and/or setting them directly with Heroku through the command line.  Here’s the revised code.

before_filter :http_authenticate if Rails.env.staging?

def http_authenticate

authenticate_or_request_with_http_basic do |username, password|

username == ENV["STAGING_USERNAME"] && password == ENV["STAGING_PASSWORD"]

end

end

Don’t forget to add the actual values to the app/config/application.yml file!

Now, any visitors to your staging URL will be prompted for credentials before being allowed to even see the home page.

As it’s outside the scope of this post, I’ll forgo instructions on how to set up a staging environment. And an even better reason not to cover the topic here is because this Heroku article explains the steps quite nicely. (Should you decide to you’d like to run a local staging environment, Mr. Bates has developed a great RailsCast on the subject here.)

STEP 8:  LEVERAGE PRIVATE REPOSITORIES (when appropriate)
GitHub is a great resource and heavily used by the Rails community. While they do offer private repositories, they are not free. Another option to check out is BitBucket. BitBucket offers free, private repos – allowing up to 5 collaborators on each repo.

As a bonus, if you invite new users to BitBucket and they use the service, you can earn privileges for more than 5 collaborators on your repos.

Newb Note! Once you’ve got your first freelance gig, consider having your client create their own repo at BitBucket and make you a collaborator. This way, they “own” the source code – if that’s how your contract is structured.

One final word of wisdom to the Rails newb regarding private repos. While BitBucket is a great security solution and arguably removes the need to concern yourself with some of the “overhead” like .yml files described above – don’t rush to move all your projects there. As a new developer, potential employers will want to see that you are an active “commiter” – and most employers will look to GitHub for such evidence.

STEP 9:  KEEP LEARNING
If you’ve got your arms around everything covered here – you are off to a great start. But like all rabbit holes, this one goes deeper. A great resource for continuing your security education, is a free, one month email course on securing your Ruby apps provided by Code Climate. To sign up, you’ll want to hit http://railssecurity.com.

So once again, thanks for reading! Security may not be sexy, but good developers are. If you haven’t checked them out, here’s some of my other posts you might like:

If there’s a topic you’d like me to cover in a future blog post, don’t hesitate to add a comment.

babydev

Whatever your reasons are for choosing to learn Ruby on Rails, they were the right ones! Rails is an excellent framework for quickly building feature-rich, scalable, and secure web apps.

In the forward of The Rails 3 Way (required reading for all new Rails devs) Mr. Fernandez states,

 …Rails frees you to kick off your project with a bang, getting a working prototype out the door quickly. This makes it possible to build an application with some meat on its bones in a few weekends, making Rails the web framework of choice for people with a great idea and a full time job.

Whether you are building a prototype or an enterprise-level application; whether you are a full-time dev or a weekend hacker, the key message is that you can get a QUALITY Rails app up FAST. Gems are a cornerstone of this fact.

In my other post, Ruby Version Manager (RVM) for Rails Newbs, I discuss how Rails itself is a Ruby gem. While Rails is the king of gems, there are many more the Rails newb should get acquainted with early in their career.

The purpose of this post is to introduce the Rails newb to a handful of gems offering low cost (time) and high return (features!). Another important characteristic of all the below gems is their licensing terms. These gems can be used freely – including commercial use.

Newb Note! The “Ease of Implementation” guidance given below is not intended to be exhaustive. It’s intended to highlight the  ease with which a given gem’s base functionality can be enabled. Many of these gems have a rich capability set that requires further reading to completely unlock. This post will get you started and give you some perspective, but plan to read the source docs to get the most from the gem.

Knowing all that, let’s talk gems. Here’s a table of contents for this post if you’d like to jump to a particular gem.

    1. Devise
    2. Twitter Bootstrap
    3. PostgreSQL
    4. Pry Debugger
    5. Better Errors
    6. Launchy
    7. Rails ERD
    8. Brakeman
    9. Faker
    10. Font Awesome

1. DEVISE     (source code)

What does it do? Any modern web app, must have user “authentication” – meaning users can create credentials (e-mail and password) and have those credentials stored in the application’s database for future use. Given the importance of authentication, it’s included first in our list.

Ease of Implementation: Beyond the usual Gemfile inclusion and bundle install, Devise requires just a bit of configuration to get running. The good news is that these instructions are well documented in the README.

Environments: Place it at the root level of your gem file so it’s available across dev, test, and production.

Newb Note! Devise’s default configuration is good, but you can make it great by turning on some additional built-in features. For example, you might want to add a “username” field (the default for sign-in is e-mail + password). Or you might want to use the “confirmable” option so users are required to confirm ownership of their provided e-mail address by clicking a link in a system generated e-mail. These options too are well documented.

Recommended Resources:


2. TWITTER BOOTSTRAP     (source code)

What does it do? Twitter Bootstrap provides clean, modern, and professional CSS styling for a number of common web app elements like navigation bars, buttons, icons, fonts, and much more.

Ease of Implementation: Installation and base configuration are quite easy and well documented in the README. Depending on your familiarity with HTML and CSS, the harder (but not hard) part is choosing which elements to use and getting them properly embedded in your Views. If you are confused by that statement regarding “Views” have a read of my post Reading Rails: MVC and Scaffolding for Rails Newbs.

Environments: In Rails 3, you’ll want to place Twitter Bootstrap in the “asset” group in your gemfile. In Rails 4, there is no asset group so go ahead and place it at the root level so it’s available in all environments.

Newb Note! I’m embarrassed to admit this, but in my own newb-ness at first I was confused about how to implement Bootstrap’s examples in my own projects. I followed the gem instructions, but then what? Where was my beautiful carousel and navigation? One of my first, very patient Rails mentors @lostincode told me to just right click and “View Source” on the target example’s web page. Then just copy the relevant code and drop it into your Rails app. After you’ve done this a few times, you have a library and favorite code that you can move between projects.

Recommended Resources:


3. PG also known as POSTGRESQL     (source code)

What does it do? Just about any web app you build needs to ultimately move off your development machine and onto the internet. Thankfully for Rails newbs, Heroku makes this very easy and free. Heroku’s only requirement is that you run a PostgreSQL database in production instead of Rails’ default of SQLite. The PG gem is the ticket.

Ease of Implementation: It’s really quite easy to set your production DB to PostgreSQL via the gemfile. Instead of the gem’s own README, I suggest having a read of Heroku’s guidance at Getting Started with Rails on Heroku.

Environments: You’re definitely going to want it in your group :production do  group if deploying to Heroku. Whether you also use it in dev or test, is up to you.

Newb Note! While purists will argue you should run PostgreSQL locally in development to ensure a mirror with production, many (not all!) Rails app scenarios will handle SQLite in dev and PG in production just fine. It’s acceptable for newbs to start with this approach and as you get further along in your Rails journey, then you can go about getting PostgreSQL running locally via instructions like these. Once you have PG running locally, when creating future Rails apps (that you plan to deploy to Heroku) I recommend telling Rails that you want a PG database from the get go. Here’s how to modify your $ rails new accordingly:

$ rails new myapp --database=postgresql

Recommended Resources:


4. PRY-DEBUGGER     (source code)

What does it do? Pry-Debugger can be used in both development and test environments to “pause” your application mid-stream at a point you specify. Once paused, you can interrogate and evaluate variables or params. For example, if you want to see what information is being passed from a view’s form into your controller, pause the app in the controller action triggered by the form submit button.

Ease of Implementation: It’s so, so easy to install and requires effectively no configuration. After including in your gemfile and running bundle install, simply drop binding.pry into your codebase (likely in your Controller or Model) just after code you want to evaluate after the application “pauses”. Then, trigger the target action in your browser (or via your test spec) . When the application hits your binding.pry, go to your terminal/console and go crazy!

Environments: I recommend creating a gem group for both dev and test with something like group :development, :test do. Pry-Debugger should go here.

Newb Note!  Pry-Debugger is built upon the original Pry but also includes some additional commands such as step, next, finish, and continue. Check out the README for a quick explanation of these commands.

Recommended Resources:


5. BETTER ERRORS     (source code)

What does it do? No matter what, your app is going to puke from time to time. The least you can do for yourself is to have easy-to-clean-up puke. This is where Better Errors comes in. It provides cleanly formatted errors with log details in the browser just a click-away.

Ease of Implementation: So easy, there’s really no excuses not to use it. Put it in your gemfile and bundle install. That’s it.

Environments: I recommend group :development do for Better Errors.

Newb Note! As per the README, make sure to check out the complementary gem “binding_of_caller“, which gives you functionality similar to Pry-Debugger (described above) – but this functionality is inside your web browser when a better_errors’ error is thrown.

Recommended Resources:


6. LAUNCHY     (source code)

What does it do? Sometimes when your test specs are failing, the error messages just aren’t informative enough – you need to see what the test is seeing in the browser. This can be especially maddening when everything appears to be fine in the browser in the development environment, but your tests are failing. Here comes Launchy to the rescue!

Ease of Implementation: Put it in your gemfile, bundle install, and include save_and_open_page inside your test spec where you want to browser to open.

Environments: As per the description, you only need Launchy in your group :test do block.

Newb Note! Dont’ forget to remove save_and_open_page after you’ve resolved your issue.

Recommended Resources:


7. RAILS-ERD     (source code)

What does it do? Rails-ERD generates a visual representation of your database schema – including tables, fields, and relationships. Personally, there’s a few scenarios where I like to use this gem.

    1. Getting up to speed on an existing project when I’m a new team member
    2. When I want to get another dev up to speed one of my existing projects
    3. For planning purposes when I know I need to change my database architecture in a material way
    4. To facilitate design discussions with more-technical clients and project decision makers
    5. Returning to project that may have been dormant for some time

Ease of Implementation: In addition to the requisite inclusion in your gemfile and bundle install – you’ll need to install Graphviz. It’s all quite easy and laid out here. After setup, you can run rake erd at any time to generate an up-to-date diagram.

Environments: I put Rails-ERD in my group :development do block.

Newb Note! Personally, I like to use this gem once my project is up and running and the schema starts to get more complicated. However, a related best-practice that I recommend is to use a similar tool to create a draft of your intended schema before you write a single line of code. Personally, I’ve been mostly pleased with the Sea Quail Database Diagram Tool. What it lacks in features, it makes up for in ease of use. I don’t have deep experience with the multitude of options that are just a search engine away. Please comment on this post if you recommendations for other ERD design tools!

Recommended Resources:


8. BRAKEMAN     (source code)

What does it do? I’m no security expert, so I really appreciate a tool that helps me easily identify, interpret, and resolve security issues in my Rails app. Enter Brakeman.

Ease of Implementation: In addition to the requisite inclusion in your gemfile and bundle install – you just put brakeman into your command line from the application root directory.

Environments: I put Brakeman my group :development do block.

Newb Note! As per the README, don’t forget to include :require => false in your gemfile when inserting Brakeman. Also, if you’d like to go deeper on Rails security, check out my other post Security is a Feature: 9 Newb-Friendly Steps to Securing Your Rails Apps

Recommended Resources:


9. FAKER     (source code)

What does it do? Sometimes having a robust set of data in your development database makes the testing and development process go much smoother. Entering it through the browser is a fool’s errand (and it’s retained if you reset your DB). Seeds.rb files are a big help, but you still have to come up with the actual values to be entered. Not anymore with Faker. Faker provides random values for names, cities, addresses (physical and internet) – even lorem ipsum text.

Ease of Implementation: You know the drill – put it in your gemfile and run bundle install. Next, incorporate the Faker syntax in either your seeds.rb or a rake tasks. Here’s some sample Faker syntax so you can see just how easy it is.

Faker::Name.name #=> “Christophe Bartell”

Faker::Internet.email #=> “kirsten.greenholt@corkeryfisher.info”

Environments: I recommend creating a gem group for gems used in both dev and test with something like group :development, :test do. Faker should go here (you can use Faker in in your tests!).

Newb Note! Check out the README for a full inventory of the fields Faker provides.

Recommended Resources:


10. FONT-AWESOME     (source code)

What does it do? These guys take icons really seriously. They use them stand-alone, but also embed them with buttons, navbars, and form inputs.  Remember,

a picture is worth a thousand words

Ease of Implementation: Just like Twitter Bootstrap, just add Font Awesome to your gem file, run bundle install, and start embedding the syntax for the desired icons and styling into your html.erb Views.

Environments: Place it at the root level of your gem file so it’s available across dev, test, and production.

Newb Note! Font Awesome plays well with Twitter Bootstrap (#2 in our gem list). Use the two together to build a highly polished product!

Recommended Resources:


SUMMARY
As with most of my posts, if you’ve gotten this far – congratulations and thank you! If I’ve left out any low cost, high benefit gems of note – please comment!

Here’s a few other posts of mine you might like:

LEARNING RAILS: A DICHOTOMY OF EMOTION
Even with all the great, often free resources on the web for open source developers, I know from personal experience that sometimes it can all be a little overwhelming  and confusing for newbs. While the information is meant to help, there’s so much of it! It’s sometimes hard to intuit the connections between the different pieces of the puzzle. I wrote my last post, Ruby Version Manager (RVM) for Rails Newbs to help in the first few hours of being a Rails dev. I’ve written this post in the hopes that it helps Rails newbs in their first week as a Rails dev.

Screen Shot 2013-08-24 at 2.04.51 AMHaving begun my journey as a Rails web developer only a few months ago, I remember the dichotomy of emotion I felt while working through tutorials like RailsCasts (Bates), Ruby on Rails Tutorial (Hartl) or Rails in Action (Biggs, Katz).  On one hand I was proud that I could mostly complete the exercises with working code, but on the other hand I felt like a fraud as I only understood 20% of what I was typing.  More experienced devs told me that this was the process and that I was learning even if it didn’t always feel like it.  In retrospect, I now know that was true – but it was painful at times.

Don’t misunderstand me, my learning journey isn’t over. I’ve quickly come to see this rabbit-hole may have no end. Depending on the topic, I still often only understand 20% of what I’m reading or typing. The good news is that I’ve become more comfortable in this state. I no longer feel like a fraud. I feel like what I am – someone on a learning path.

“Life is a journey, not a destination.” -Ralph Waldo Emerson

Okay, with that prologue out of my system – the point is that if you are similarly finding yourself in the early stages of your Rails journey, I wanted to offer up my own newb-inspired, highly simplified, explanation of MVC and some of the basic code provided in a Rails scaffold.  Here we go!

WHAT IS A RAILS WEB APP?
Think of a Rails web app as a database of information that sits on the internet. If you allow them, anyone with internet access and a web browser can visit your database to perform 2 tasks:

  1. Look at the information in the database
  2. Put additional information in the database

That’s it. That’s the whole enchilada. But of course, let’s break that down further.

WHAT’S THE BIG DEAL WITH MVC?
Newbs can think of Model – View – Controller (MVC) as a commonly-agreed best practice in how to organize web application logic. This means code performing certain functions go in the Model, code of an alternate purpose goes in the Controller…you get the idea. Each of the components is described below.

Newb Note! MVC is not a Rails-specific practice. Learning it in the context of Rails will provide a foundation to accelerate your learning of other frameworks like iOS.

Model:  The model defines the architecture and logic of the “database on the internet” described above. Assuming a classical relational database, the newb can think of a database as one or more “tables”, each table looking like a spreadsheet – a matrix formed by columns and rows. For example, let’s consider a table containing a list of books. In this list, for each book we store it’s title and author. As such, title is one column and author is another column.  Because it’s a database, we also assign each book in the list a unique numerical identifier (this is commonly known a “primary key”).  So we’ve got three columns: numerical ID, title, and author.  Each row in the list is called a “record”. In summary, the Model defines the database characteristics – but it is not the actual data. Because the database is clearly defined in the Model, its data is accessible to the Controller (the “C” in MVC). But before we talk about Controllers, let’s discuss the View.

View: So we’ve got a database on the internet, but databases aren’t built for their looks. Databases are just raw information. Take our books list example. Maybe the user only wants to see a list of books by John Grisham. If they went to our single database table, they’d have to figure out a way to ignore all the books not by John Grisham. In a long list, this could be a pain. Even while this might meet their needs one time, I doubt our database would be their favorite place to look at book information. Users deserve better. As such, we use “Views” to create a friendly and intuitive way for people to both look at and put information in the database.

Controller: In my opinion, M-V-C should be changed to M-C-V.  Why? Well, because the “C” or the “Controller” conceptually sits between the Model and the View. Remember what was said in the Model description above,

Because the database is clearly defined in the Model, it’s data is accessible to the Controller.

The controller translates the different types of the user’s 2 main instructions communicated through the View (reminder on those instructions below) into something the database understands.

  1. Show me some information from the database
  2. Put additional information in the database

Conversely, when appropriate and the database provides the controller raw data in response to the user’s request, the controller readies the data for presentation in the View.

Okay, this all sounds simple enough.  Let’s get into some code.

SCAFFOLDING IN RAILS
Screen Shot 2013-08-25 at 11.49.01 AMPart of the power of Rails comes from its “generators“. Because Rails is built on the below premise,

“most web apps are simply a database sitting on the internet waiting for anyone with a web browser to come look at the information in the database or put additional information in the database”

Rails gives web developers “generators” to create a lot of free code supporting the above scenario.  The newb will likely not be surprised to hear that there are generators for each component of the MVC.  For example:

$ rails generate model will create a skeleton for a database table and it’s attributes (aka columns)

$ rails generate controller will create a skeleton of a controller as well as corresponding views

Newbs can check out the full suite of generators here, but in this post I’ll focus on the mother of all generators, the rails generate scaffold. As you might guess, rails generate scaffold generates a full working MVC with just a couple of keystrokes!

Returning to our book list example, we could get that up and running quite quickly with the following statements in our command line:

$ rails new booksapp #create a new Rails app called booksapp

$ cd booksapp #navigate into your newly created app

$ rails generate scaffold book title author #create a book model with a title attribute and an author attribute. Both attributes will default to string type.

This second instruction of six simple words has Rails generate 19 separate files in your app.  In the next section, we’ll take a look at 4 highly relevant (and instructional) files in the 19.

Newb Note! The below example is based on Rails 4.0.0.  If you want to replicate these steps and unsure how to manage which version of Rails your project will be built with, have of read of my other post Ruby Version Manager (RVM) for Rails Newbs.

READING RAILS
Below is a line-by-line explanation of the code appearing in 4 key files created by the rails scaffold command.

db/migrate/20130726235142_create_books.rb:  As the directory and file naming implies (note “db” for database), this file represents instructions for how the  book “model” should be built. The newb will recall from our description above, the model defines the structure of our database.  With this in mind, let’s take a look at this file’s contents.

class CreateBooks < ActiveRecord::Migration
Create a new class called Books, and this class will inherit from ActiveRecord::Migration. As such, some of the following methods are defined by ActiveRecord::Migration.

def change
Create a method called “change”.

create_table :books do |t|
When the change method runs, run a secondary method to create a database table called “books” and then perform the following block of actions. Each distinct action will follow the letter “t”.

t.string :title
In the books table, create a column called “title”.This column will store strings (letters, words).

t.string :author
Create a column called “author”. This column will store strings (letters, words).

t.timestamps
Create 2 columns. Each will store date and time formatted information. One column will contain the date and time of day that a new table record is first created. The second column will contain the date and time of day that a table record was last updated.

end
No further instructions relating to the “create_table” method.

end
No further instructions relating to the “change” method.

end
No further instructions relating to the “create a new Class” method.

Remember, this is a migration file. Migrations contain instructions to Rails for how we want our database to change. As outlined above in alarmingly laborious detail, this particular migration instructs Rails to create a table called “Books” and put some stated columns in it.

Next, assuming this all looks good, we tell Rails to execute the migration with a rake db:migrate from the console.

Newb Note!  All table creation migrations will always generate an indexed “ID” column which will contain an incrementing integer of unique value. This is the “primary key” described in the Model earlier.  While this column doesn’t appear in the migration file (or the resulting schema.rb file) Rails will always create it – unless explicitly instructed not to.

With our migration run, let’s look at another file.

app/models/book.rb: As the directory structure and file naming implies, this file represents the book “model”. As we know, the model defines our database architecture and logic. With this in mind, let’s take a look at this file’s contents.

class Book < ActiveRecord::Base
The book class inherits from ActiveRecord::Base.

end
End of class

This file might seem sparse, but inheriting from ActiveRecord::Base is like being Superman’s child. You get all his special powers and a chance to define your own.

Newb Note! If you’ve run a scaffold under Rails 3, you might have expected to see attr_accessible :title, :author here in support of attribute mass-assignment. While Rails 4 still requires explicit statement of mass-assignable attributes, it does so in the Controller – which we’ll cover a few paragraphs below.

app/views/books/index.html.erb:  As the directory structure and file naming implies, this file represents the book “view” for the index page. The newb will recall from our description above, views serve as a friendly and intuitive way for people to both look at and put information in the database.

<h1>Listing books</h1>
Using “header 1” HMTL styling, put the words “Listing books” on the page.

<table>
Let’s create a well formatted table of information in HMTL.

<thead>
Our table should have a clearly formatted header of column names.

<tr>
Get ready for a list of those column names.  <tr> is HTML for “table row”. The header with column names is technically just the first row of the table.

<th>Title</th>
Column one should be labeled “Title”.

<th>Author</th>
Column two should be labeled “Author”.

<th></th>
There is a 3rd column, but don’t give it a label.

<th></th>
There is a 4th column, but don’t give it a label.

<th></th>
There is a 5th column, but don’t give it a label.

</tr>
No more columns.

</thead>
No more instructions regarding the table header.

<tbody>
Let’s begin to format the table body.

<% @books.each do |book| %>
You’ll note this line looks a little different. The % after the open tag < means some “embedded Ruby” is going to follow. Try to remember this line because it will be important when we move to the Controller. To spill the beans a bit however, @books represents a list of all the books in our database. The list is being passed into the View with this line. .each do instructs Ruby to iterate through each book in the list (in computer science-speak the full list is stored as an “array” of “hashes“) and “do” something with each instance.

<tr>
For each hash in the array, create a row in our table and put the following in each column:

<td><%= book.title %></td>
In the first column of each row, print the book’s title into the view. Here the newb should note the use of <%= again. As before this means, Ruby will be embedded in the HTML. The difference here from the previous example is the =, which means the Ruby results should be printed in the view (as opposed to just executed without being printed).

<td><%= book.author %></td>
In the second column of each row, print the book’s author into the view.

<td><%= link_to 'Show', book %></td>
In the 3rd column of each row, put the word “Show” on the page as a click-able link for each book. When the link is clicked, look up the book_path helper route for instructions of what to do. In a scaffold scenario, we know this route will redirect the user to localhost:3000/books/[id] where [id] is the primary key of the book in the row where this link has been clicked.

<td><%= link_to 'Edit', edit_book_path(book) %></td>
In the 4th column of each row, put the word “Edit” on the page as a click-able link for each book listed. When the link is clicked, look up the edit_book_path helper route for instructions of what to do. In a scaffold scenario, we know this route will redirect the user to localhost:3000/books/[id]/edit where [id] is the primary key of the book in the row where this link has been clicked.

<td><%= link_to 'Destroy', book, method: :delete, data: { confirm: 'Are you sure?' } %></td>
In the 5th column of each row, put the word “Destroy” on the page as a click-able link. When the link is clicked, present the user with a pop-up prompt asking if they are sure about their desire to delete the specified book from the database. If they answer yes, well – you know what happens.

</tr>
No more table column/row instructions.

<% end %>
End the.each do embedded Ruby block. Here the newb should take note that the full Ruby block spans multiple lines interspersed with the HTML.

</tbody>
No further table body information.

</table>
No further table information.

<br>
Put a little vertical spacing on the page.

<%= link_to 'New Book', new_book_path %>
Put the words “New Book” once at the bottom of the page as a click-able link. When clicked, go to localhost:3000/books/new and engage the new method on the books controller.

app/controllers/books_controller.rb:  As the directory structure and file naming implies, this file represents the book “controller”. The newb will recall from our description above, the “controller” acts as the translator and go-between for the model and the view.  With this is mind, let’s look at the file’s contents.

class BooksController < ApplicationController
The books controller inherits from the application controller. Just like inheritance in the Model, our books controller get’s lots of valuable abilities because of who it’s parent is.

before_action :set_book, only: [:show, :edit, :update, :destroy]
This is a Rails “callback“. This particular callback is telling the controller to run a method called “set book” before running the show, edit, update, and destroy methods. The actual logic of the set_book method is defined a little lower down in the file. Hang tight on that.

def index
Let’s define a method called “index”. Now it’s no accident that this method is named exactly like the app/views/books/index.html.erb file we reviewed above. This method is executed every time a user visits the URL localhost:3000/books. Now it’s not actually the word “index” that links the URL and the controller method. The Rails scaffold does that mainly for logical readability. In fact it’s the app/config/routes.rb file that contains the logic of association web pages and controller actions.

@books = Book.all
This short line is doing quite a lot. Hopefully the @books looks familiar. We saw this in the app/views/books/index.html.erb file. There we said that @books represents a list of all the books in our database. @books represents that precisely because of this line. The right hand side of this equation is telling Rails to look in the books model and pass a copy of all the book records into an “instance variable” called @books. This feels like an appropriate place to quickly mention that instance variables in Rails are always preceded with the @ symbol. The power of an instance variable (as opposed to a “local variables” which are generally all lowercase and lack a preceding @) is that instance variables are available to Views. Local variables are only used inside the controller itself. This is a basic, but important, example of variable scoping.

end
No more instructions for the index method.

private
The “private” declaration here is another example of scoping. Just above we talked about variable scoping, here we are managing method scoping. Here’s a thorough write-up on method visibility for interested readers.

def set_book
Here we define the set_book method that was referenced in our callback at the top of the file.

@book = Book.find(params[:id])
Just like Book.all returns all the books in the database in the index method, this line extracts a single book record out of the database based on it’s “ID”. Remember that “primary key” value we discussed in the Model section? Here it is being used to go a find a specific book in the database. While params is a powerful piece of Rails that deserves its own blog post, here I’ll just offer the generality that params is the mechanism by which a user can pass information into Rails.

end
This is the end of the set_book method.

def book_params
Let’s define a method called book_params

params.require(:book).permit(:title, :author)
Along with the working code, the scaffold includes the following comment right into the controller text,

Never trust parameters from the scary internet, only allow the white list through

Basically, this method is the Rails 4 way of handling attribute mass-assignment. Mass-assignment is a security feature in Rails that requires the application developer to explicitly state which columns in the database can be updated en-masse. Without this, a user filling out a form intended to be saved in the database could only submit one piece of information at a time. Image having to fill out your first name and then hit “submit”. After the page refreshes, then you can fill out your last name and then hit “submit”. So on, and so on. You get the idea. Equally important is that we are telling our Model not to accept any user-driven inputs as it relates to the ID field or the timestamp fields discussed previously. These fields are only allowed to be populated by the system itself.

end
No more instructions for the book_params method.

end
No more instructions for the books controller!

As a closing note on the controller code above, I intentionally omitted some important methods relating to showing, creating, editing, updating, and deleting records in the database (as well as the associated Views). This was done for brevity, but I hope the detail that has been provided here empowers Rails newbs to more easily interpret those other methods on their own.

CHECK IT OUT IN THE BROWSER
So we’ve got a bunch of code here, but let’s see it in action.

$ rails server #start up your local Rails server

Open your favorite browser and go to localhost:3000/books

SUMMARY
If you’ve made it this far, you really deserve congratulations and my sincere thanks. As mentioned in the introduction, I remember often only understanding about 20% of the code I was reading. While the tutorials were doing their best to provide the necessary explanation and context to surround the actual code, I felt strongly that a line-by-line explanation of nearly every word would be useful. Now a few months further into my own Rails journey, here it is. I hope it has been of use to you.

I can tell you that writing it mirrored a different kind of emotional dichotomy – this time vacillating between confidence that this blog would serve a purpose and a fear that this work was the equivalent of a dissertation on brushing your teeth. I welcome your feedback on where it fell on that spectrum for you.

RVM Overview and Installationbabydev

In someone’s first few hours as a Ruby on Rails developer, they will likely be encouraged to install Ruby Version Manager (commonly known as RVM). RVM is a free, powerful tool for creating and easily moving between Ruby and Ruby Gem combinations.

It’s important for the newb to understand that you want to get RVM configured correctly before running rails new. It’s your RVM settings that will control just what kind of Ruby on Rails app gets generated. Confused? No problem, just keep reading.

As per the RVM installation instructions, by simply entering the below short statement into your command line, you can begin unlocking the power of Ruby and Rails!

$ \curl -L https://get.rvm.io | bash -s stable --rails

Let’s talk about what this is doing. Besides installing the RVM tool itself, this command will also install the newest, stable version of both Ruby and Rails.

That’s great right? The newest, stable version is probably what any new Rails dev wants to be running right? Probably. Let me explain about why I hesitate.

Rails Is a Moving Target

As Rails issues are continuously being found and resolved, the open source code changes over time. The Rails 3.2.13 gem (yes, Rails is just a gem) was released in March 2013 and the Rails 4.0.0 gem released 3 months later in June 2013.

As Rails evolves, syntax that worked in a previous version may no longer work in a newer version. For this reason, the Rails Guide’s own guidance states:

“Before attempting to upgrade an existing application, you should be sure you have a good reason to upgrade.”

The main point for the newb is that pro-actively understanding and choosing which version of Rails they will use to build any app is an important decision.

Note: The syntax retirement described above is specific to Rails (not Ruby).  As such, it’s unlikely a newb will have a reason to run an older version of Ruby. However, it is plausible a newb may have reason to run an older version of Rails (as explained below).

Explain It To Me Like I’m 3 Years Old

In addition to RVM, another common ingredient in a new Rails developer’s kitchen will be one of the great tutorials like Ruby on Rails Tutorial (Hartl) or Rails in Action (Biggs, Katz). These cookbooks have multiple editions as they are generally refreshed when Rails is refreshed. If a newb is using a tutorial predicated on a different (possibly earlier) version of Rails than what RVM has installed by default, headaches will ensue.

One more probable Rails newb scenario is installing a newer version of either Ruby or Rails when one is released after RVM was originally installed.  Both of these scenarios will be addressed below.

This Sounds Like It Could Be Me. How Do I Avoid Headaches?

It really quite easy, and in fact this is what RVM was built to do! But before we dive into more command line stuff, let’s revisit the following statement,

“RVM is a free, powerful tool for creating and easily moving between Ruby and Ruby Gem combinations.”

26FALDIYou can think of RVM as your food pantry for Ruby and Ruby Gems. Maybe you’re feeling old school and want a little Ruby 2.0.0 with a dash of Rails 3.2.13. Or maybe you’re feeling modern and want to run Ruby 2.0.0 with a sprinkle of Rails 4.0.0.   No matter the combination, RVM can have these ingredients ready to grab off the shelf and even mix together with a few simple keystrokes before you run rails new.

Filling Your Pantry with Rubies

Note: It’s unlikely a newb will have a reason to run an older version of Ruby. However, the following instructions are provided for completeness and apply for newbs wanting to install a newer version of Ruby (if one has been released since the original RVM install).

So you’ve got the defaults RVM gave you, but let’s put some other flavors of Ruby into our pantry. Getting additional versions of Ruby is easy enough. Simply drop the below into your terminal.

$ rvm install ruby_version_here

Here’s an example:

$ rvm install 1.9.3

Depending on your needs, feel free to change “1.9.3” for any other (possibly newer) version of Ruby desired. For a list of all available versions, run:

$ rvm list known

Now to see all locally installed versions of Ruby on your machine go ahead and run:

$ rvm list

This returns a nice list of Ruby versions on your machine – as well as indicators of the “default” version and the “current” version.

If you want to change your current version (which you might want to do before running rails new, you can simply enter:

$ rvm use full_ruby_version_name

Here’s an example:

$ rvm use ruby-1.9.3-p392

Note: It’s unlikely a newb will have a reason to run an older version of Ruby. However, a newb may decide to run a newer version of Ruby should one be released after the newb’s original RVM installation.

Navigating and Naming Gemsets in RVM

Okay, so we’ve got multiple Ruby versions that we can quickly move between. But what about Rails? As already stated, Rails is a gem and RVM stores gems in groups – called “gemsets”.

Gemsets in RVM are isolated in that they are only available to a single version of Ruby (this is a common area of confusion for newbs).  When a version of Ruby is installed via RVM, 2 associated (empty) gemsets will be created simultaneously. One is called “global” and one is called “default”.

Global Gemset: Any gems installed into the “global” gemset will be included whenever rails new is run while the associated version of Ruby is active or in use.

Default or User Generated Gemsets: Gems installed into “default” (or a user created gemset), will only be included when rails new is run if that gemset is active or in use.

For example, if you want to be able to run Rails 3.2.13 and Rails 4.0.0 with Ruby 2.0.0, you’ll need 2 separate gemsets and you’ll need to install a different version of Rails into each one.

To bring these points home, possibly a visual will help. Here it is.

RVM_architecture


icon@58Note! I recently released an iPhone app and would appreciate it if you would give it a try. It’s free and called smoov. smoov is a text messaging assistant for gents.

You can download it here or search for it by name in the App Store.


Similar to seeing all locally available Ruby versions, we can see all locally available gemsets (associated with the currently active version of Ruby) via the below command.

$ rvm gemset list

Moving on, to see all gems in the current gemset, just run:

$ gem list

If you want to see what gems are inside of a different gemset, simply move to that gemset with:

$ rvm gemset use gemset_name

For example:

$ rvm gemset use default

or

$ rvm gemset use global

and then,

$ gem list

Great, so we’ve got multiple versions of Ruby, multiple gemsets, and understand the gems inside those gem sets.

A Note About Gemset Naming:

A common area of confusion for newbs with multliple versions of Ruby is that they have multiple gemsets named “global” and “default”.  $ rvm gemset list will return the “global”, “default”, and any other gemsets subordinate to that specific Ruby instance.  If the newb changes their active Ruby version with $ rvm use full_ruby_version_name and then reruns $ rvm gemset list, they will again see “global” and “default” gemsets, but these are not the same gemsets seen just moments earlier.

Due to this approach by RVM, I suggest including the Ruby version number when creating new gemsets.  For example:  rvm gemset create ruby2rails3 or rvm gemset create ruby2rails4.

Filling Your Pantry with Ruby Gems

So we know what we have for existing gemsets and their included gems, what if we want to create a new gemset? No problem, first just make sure you are “using” the version of Ruby that you want the gemset to be associated with. We already learned how to navigate between Ruby versions with:

$ rvm use full_ruby_version_name

Here’s an example:

$ rvm use ruby-2.0.0-p0

Now just tell RVM to create a new gemset and what to name it, using:

$ rvm gemset create my_new_gemset

Here’s two examples:

$ gem gemset create ruby2rails3 or $ gem gemset create ruby2rails4

Next, we need to “use” the newly created gemset by running:

$ rvm gemset use my_new_gemset

or in our example

$ rvm gemset use ruby2rails3

Once we are “using” or inside the target gemset, we can begin installing gems to our hearts content with:

$ gem install gem_name

Here’s an example:

$ gem install rails -v 3.2.13

Finally, to see a complete list of all Rails releases, go to RubyGems.org. Another quick way to get educated on great gems, is to check out Easy Does IT: Top 10 Gems for Rails Newbs.

Changing Default Settings

defaultsAs stated earlier, RVM is going to set your initial Ruby and Gemset defaults to the latest, stable version of Ruby and Rails. If you woud like to change these default settings you can do so with:

$ rvm use ruby_version@gemset_name --default

Here’s an example:

$ rvm use ruby-2.0.0-p0@ruby2rails3 --default

Summary

All if this information is shared so a new Rails developer can consider and have confidence in  knowing what version of Rails they want to be use when running the rails new command.

Conceptually, the newb should now be able to easily:

  • See all locally install versions of Ruby with: $ rvm list
  • Move between locally installed versions of Ruby with: $ rvm use ruby_version_here
  • Install additional versions of Ruby with: $ rvm install ruby_version_here
  • See all locally existing gemsets for a specific version of Ruby with: $ rvm gemset list
  • Move between gemsets with: $ rvm gemset use gemset_name_here
  • Create new gemsets with: $ rvm gemset create my_new_gemset
  • Install new gems in the current gemset with: $ gem install gem_name_here
  • Change their default Ruby and Gemset with: $ rvm use ruby_version@gemset_name --default

newbFull disclosure:  This was the first blog post I’ve written as a Rails dev.  In short, I’m a newb too.

If you’ve found this post useful, consider reading my other newb-centric posts:

I welcome your comments and feedback.