A beginners look at RVM: Installs, Upgrades and the rest

January 27, 2015February 25, 2016 neanderslobinstall, ruby, ruby on rails, rvm, update, upgrade1 Comment

One of the most confusing things about learning rails is in dealing with the Ruby Version Manager (RVM). Being a noob myself in the Ruby world, I wanted to give some clarification on stuff that I’d wondered at the outset regarding this tool.

RVM is basically a package manager (like apt for fellow linux users); it upgrades packages, downgrades them, allows you to switch out versions, etc. The big question on my mind was “why doesn’t ruby just use apt!?” Indeed, apt had served me well for php and it seemed to be a needless complication to use some other package manager for this language. “Why was Ruby so special that it needed its own package manager!?” I’m still not entirely sure of the rationale behind this, but my guess is that one of the things that makes Ruby so useful is its “Gems” (Rails is one of them), for which Ruby sort of acts as a package manager in itself. I figure this makes it much more important for users to have a more control over the versions of ruby that they’re using; either way RVM (and a few others like it) are the ways to manage ruby, so here are a few tips to make it work.

Note: These instructions might have an Ubuntu flavor to them here and there, because that’s what I use. For the most part, they’re universal though.

To install RVM:
\curl -sSL https://get.rvm.io | bash -s stable --ruby

To check the version of ruby:
ruby -v

How can I upgrade to the latest version of ruby!?
There is no way to just upgrade ruby to the latest (whatever it happens to be). RVM seems to be all about giving control to YOU; it’s not going to make the choice for you. Here’s how I go about it.
First, I update my list of known stable ruby versions
rvm get master
Then, I check that updated list with:
rvm list known
My output looked like this:

# MRI Rubies [ruby-]1.8.6[-p420] [ruby-]1.8.7[-head] # security released on head [ruby-]1.9.1[-p431] [ruby-]1.9.2[-p330] [ruby-]1.9.3[-p551] [ruby-]2.0.0[-p598] [ruby-]2.1.4 [ruby-]2.1[.5] [ruby-]2.2.0 [ruby-]2.2-head ruby-head # for forks use: rvm install ruby-head- --url https://github.com/github/ruby.git --branch 2.1

The real output was actually a lot longer as it gives you ALL the packages you can get with RVM but I cut it off (we’re not interested in JRuby or anything like that). Anyway, I checked out the list and saw that 2.2.0 was the latest so I entered:
rvm install 2.2.0

Managing installed versions:
RVM also allows a user to have many “Rubies” installed (versions of ruby). To see which ones are installed:
rvm list
Mine looks like this:

rvm rubies

ruby-1.9.2-p320 [ x86_64 ]
* ruby-1.9.3-p392 [ x86_64 ]
=> ruby-2.2.0 [ x86_64 ]

# => – current
# =* – current && default
# * – default

I’m using 2.2.0. If I wanted to use the version of 1.9.3 I have, I would type
rvm use ruby-1.9.3-p392
Also my default was 1.9.3. If I wanted to change the default to 2.2.0, I would enter
rvm --default use 2.2.0

Upgrading RVM:
Every month or so it’s good to upgrade your rvm. To do so:
rvm get stable

Controller Cheat Sheet

January 22, 2015January 22, 2015 neanderslobcheat sheet, cheatsheet, controller, current_user, edit, index, new, posts, rails, ruby on railsLeave a comment

Common in index method

Get all posts and save them to @post, ordered by when they were creating in descending order:

@post = Post.all.order("created_at DESC")

Get all posts by a particular user and save them to @post, ordered by when they were creating in descending order:
@post = current_user.posts("created_at DESC")

Common in new method

Create a new post for the current user when that user has_many posts:

@post = current_user.posts.build

Create a new post for the current user when that user only has_one post:

@post = current_user.build_post

To authorize which users can access what

See my post here.

Rolling your own basic user authorizations with devise

January 22, 2015January 23, 2015 neanderslobauthorizations, devise, roll your own, ruby on rails, users1 Comment

There seems to be very little written about this in the Rails literature out there, so I thought I’d make a contribution. There’s very much posted about using authorization management gems like CanCan (which is well and good) but for those of us creating a small basic app, such gems are overkill. It’s also worth using a filter just to get an understanding of what’s going on if you’re new to rails (like me!)

Goal:

To create a stupid-simple authorization system that makes sure that only admins and the owner of a post can edit that post.

Assumptions:

You are using the devise gem and have set it up
You have created an Admin model (Option 1 in the Devise Wiki)

Proceess

(It’s really short)

To only allow admins and users that own the given post edit authorization, put the following in your post controller:

before_filter :require_permission, only: [:edit, :update, :destroy]

def require_permission if user_signed_in? if current_user != Post.find(params[:id]).user if !admin_signed_in? redirect_to :root, notice: "Access Denied." end end else if !admin_signed_in? authenticate_user! end end end

(Do make your indentation better than the code above; I’m up against wordpress’s auto-correct and don’t feel like fighting with it)

Anyway, that’s it!

The explanation

So why? Let’s start with the top

We’re adding a method, called require_permission which we are defining below to the methods edit, update and destroy. Meaning any users engaging these methods must fit the requirements outlined in require_permission
Next we define require_permission and say that if the current user is NOT the user on file for the given post… proceed.
Then we check if the session user is an admin or, more accurately, if the user is NOT the admin (note the exclamation point). Because user and admin are two different models, devise has defined two different sets of very similar methods when referring to either one. Check them out here. It helps clarify things.
Finally we add the redirect to the homepage with an ominous “ACCESS DENIED” message at the top.

So to recap, if the user is not the owner of the post AND not signed into the admin model, they get booted back to the homepage. Otherwise, they can do whatever they want to the post.

Enjoy!

Managing Administrator accounts with Devise

January 21, 2015 neanderslobaccounts, admin, authorization, devise, ruby on railsLeave a comment

I’ve been using the Devise gem for a couple apps in my recent exploration of Ruby on Rails. It works pretty well and has a lot of great features but the documentation on how to best go about setting up administrators on it is a bit vague. I would write up some notes on how to do it but I’d basically be plagiarizing another post on the matter which really cleared things up for me. Check it out: http://jonallured.com/2011/04/30/using-devise-for-admin-accounts.html

Notes: To import a csv into a heroku table

January 6, 2015January 6, 2015 neanderslobheroku, notes, postgresql1 Comment

if you want to import a csv to a heroku table, execute the following command:

psql `heroku config:get DATABASE_URL -a your_app`?ssl=true -c "\copy your_table FROM '/tmp/rows.csv' WITH CSV;"

Replacing your_table and your_app with the appropriate info

Setting Up Mailer Using Devise For Forgot Password

January 1, 2015January 12, 2015 neanderslobdevise, password, rails, ruby on railsLeave a comment

Really cleared up my confusion about sending email in both development and production environments.

Ruby on Rails Help

In this tutorial I will show you how to set up the mailer for the forgot password feature in Devise. In the tutorial I will be setting up a Gmail account and I will show you how its done using local environment variables. I will also be using Heroku and Foreman to set up environment variables.

I am using Rails 4 and Devise 3 for this tutorial.

Seting Up Development Environment

First we will set up the development mailer for use on your local machine. In “config/environments/development.rb” you should already have included

config.action_mailer.default_url_options = { :host => 'localhost:3000' }

when you installed devise.

Next you should turn on the option to raise an exception if there is an error when sending an email. You can do this by including

config.action_mailer.raise_delivery_errors = true

in the same file. Next we will add the email delivery method. You should leave the values as…

View original post 672 more words

Neanderslob VS Technology

As I stumble through the world of linux, I've decided to log new tricks I learn because I often forget. I decided to share the log because…. eh, why not.

Month: January 2015