Chris Oliver

The simplest way is to replace it with my code and change the git repo, app name, and deploy path to match your app. After that you should be pretty much done.

There should be an existing file there already because Nginx has a default web page it renders. You'd just be overriding it. Maybe a typo in the filename?

Nano works great. I personally use vim.

That's correct and you do want to do this on your local machine. Capistrano is how your local machine tells the server to deploy your code so it needs to be setup locally.

Hey Jinu, your Gemfile should be in the top folder of your Rails app. This is what defines your version of Rails and other gems that you use. You want to edit the Gemfile on your computer first (not on the server) to add Capistrano.

I believe, if you run rbenv rehash after installing the capistrano gem, the executable should become available without having to run bundle exec. I could be wrong, but that's also the same way that gets the rails command available.

You should have sqlite3 installed if you followed all the steps. And to generate a Rails app with Sqlite, just skip the -d option and use rails new myapp

I'll add a comment to the last part to make that more clear. Thanks!

It just generates an HTML table, so there are no CSS styles applied by default. That's up to you. Here's a screenshot of it using Bootstrap. http://cl.ly/VYjp and an older version in use here at www.seattleastro.org/events...

Ah yes, great points! I like that as a subquery and definitely need the distinct for my example as well.

Doh! I'll get on that. My markdown parser sure didn't like that video.

Glad you got it working and you're welcome! :)

Sounds like the download got interrupted. You probably should delete the file they mention (assuming they tell you which one didn't finish) and try again.

This is fixed now in the latest versions of 2.1 and 2.0 that were released yesterday!

This is hard to talk about in the abstract, so here's an example from an app I built recently. We have a Campaign object that, depending on its type, has multiple ways to be "expired".

def expired?
  published? && ( (timer? && expires_at < Time.zone.now) || (quantity? && subscribers.shared.count >= quantity) )
end

Now in the current iteration, I've already abstracted out published? to handle the logic for how publishing works. The other pieces of logic are dependent upon the type of Campaign.

The simplest approach is to simply dump in the logic as you see here.

The better solution is to refactor it into other methods.

def expired?
  published? && (timer_expired? || quantity_expired?)
end

def timer_expired?
  timer? && expires_at < Time.zone.now
end

def quantity_expired?
  quantity? && subscribers.shared.count >= quantity
end

You should be able to instantly see the benefits in clarity.

Campaigns can only have their timer expired if they are a timer based campaign and the time has elapsed. expired? encompasses a higher level definition of what being expired means. It's very clear now that an expired campaign has a few paths to their "expiration" and also allows for easy modification of individual expiration methods. You can also add new types with relative easy without adding much confusion.

Is that a better example?

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:

if user_signed_in?
  the_thing_we_want_to_happen
end

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.