1. Often times in Ruby you'll see one or two line methods. This can be useful. In fact,
user_signed_in? could be as simple as
User.find(session[:user_id]). If it finds a user, you're signed in and it should return true. If it throws an exception because it can't find the record, you're not and it should return false.
But this is just one way of handling it. You may not choose to pull the record out of the database to verify they are signed in. It seems wise to both verify the user_id in the session AND load the user.
The merits of writing a method called
user_signed_in? are such that you no longer have to care how the verification works. You just simply trust that it does its job and go about your business. In fact, I would venture to guess that a large amount of people haven't even contemplated how
user_signed_in? works if they have never tried building an authentication system from scratch.
2. Related to point #1, your method names should be as concise as possible while still conveying clarity. We could have methods named
check_if_user_is_signed_in but far too dramatic.
The way you describe the code in words out loud to a coworker often give insight into how the code should ideally be written. If you tell a programmer "okay, so we want this to happen if the user is signed in" translates almost directly to:
I think the closest thing to a metric I can give is how similar your code is to the way you speak. The closer your code reads to what you speak means that understanding can be conveyed at higher bandwidth.
There are no hard and fast rules to this as it changes between industries, environments, and even countries that you live and work in. Culture affects this strongly.
The way to learn this is to begin reading LOTS of source code for large, well-established, and well known projects like Sinatra, Jekyll, and Rails. See how they go about their naming schemes and find the style that's most appealing to you that also provides clarity.
As you see examples in other projects, you will be able to pick up on the subtle nuances that make the difference between directly naming something and naming with an added dash of clarity.
current/ gets symlinked at a point in the deploy process that it may not have gotten done. It will operate in the releases/ folder for most of the deploy process before switching the new release over and replacing the live one. The first time you go through the process, the current/ symlink won't exist till the end.
Does that make sense?
I imagine that it's trying to run migrations and the database.yml would be required for that. You can hop on to the server and create that file if you don't have it in your repo. Setup a
production section with the right credentials.
Good idea, but those are more for production environments. The Deploy Rails tutorial is more geared for setting up a server and covers Nginx + Passenger. This tutorial is for your development environment.
Got it, thanks!
Great question. It covers both Ruby 2.0+ and Rails 4.0+.
You're right, I'll switch it over to the Trusty repo. Eventually when PostgreSQL's official repo is available for trusty I'll switch it back because you're always guaranteed to get the latest version on their repo. The Ubuntu repositories tend to lag behind the official releases so I lean towards using the postgres provided ones if I can.
Anytime, glad to help! :)
Ah cool. You're safe to upgrade to p451 then. That part denotes the "patch level" which basically means they fixed some bugs inside Ruby (including some security fixes usually). It shouldn't affect you at all and I'd recommend always trying to use the latest patch level of whichever version of Ruby you use.
From what I read, it sounds like the next releases of Ruby will include patches for it and you have to do this for the time being. Pretty annoying and I hope they have a better solution in the future.
I'm curious, why do you need p247 and not the latest 2.0.0? Isn't everything fully compatible between the two?
Much cleaner, thanks!
You can run the following command if you'd like to install Ruby 2.0.0-p451 instead of 2.1.1:
curl -fsSL https://gist.github.com/LeonB/10503374/raw | rbenv install --patch 2.0.0-p451
It requires a different patch than 2.1.1 does.
That error/warning is just to make sure you know you're connecting to a computer that you've never talked to before. Glad everything is working well!
No worries! There is a application called Terminal that you want to type these commands in. Open up that and type them in there and you should be fine.
It is in the works! First we're waiting on the passenger package to get updated for 14.04. I'm going to try it with an older version, but we'll see.
Hey Eduardo, I believe that is rvm telling you that you don't have all the necessary to compile from source so it is looking for a binary instead. Double check that you installed all the packages with
apt-get and the other parts of the tutorial before that.
Okay cool, so make sure you're inside the rails application when you run that command.
Hey Rico, there should be a Rakefile automatically generated when you create your rails app. What command were you running that gave this error?
Maryam, that sounds like an internet connection problem. You might try visiting rubygems.org and making sure you don't have any trouble with that.
Just redesigned the blog, forgot to add it in. :)