Chris Oliver

In that case, you want to do two loops. Something like this:

<% @course.sections.each do |section| %>
  <div><%= section.title %></div>
  <% section.pdfs.each do |pdf| %>
    <%= link_to pdf.title, pdf %>
  <% end %>
<% end %>

You can't quite do it that way. You can say a Course has_many :pdfs, through: :sections and then say @course.pdfs instead. That way you can handle that joins properly and display them all on the page. :)

What do you mean by each loop?

That's possible for why it is happening. I know I've done that before.

You may be able to rejig your logs to print out the user ID in them (if available) so you can associate the requests together.

You'll probably want to check the request just before the redirect to see what they were accessing when they got redirected. Feel free to post more of the log.

Okay, so as I thought, for some reason you're sending an already signed in user to the sign_in view. Somewhere you're sending them to that view, but they're already signed in and Devise knows that so it sends them on. It's a before_filter inside the Devise::SessionsController in the gem. Naturally if the user is already signed in, they don't need to be able to sign in again.

Steps to reproduce are probably:

1. Sign in
2. Visit /users/sign_in
3. You will get redirected

Maybe you're redirect a user to a devise URL that is only for users that are signed out, hence the before_filter. If you have the log of the request that triggers the Filter and the one after it, I'd be curious to see them.

The example here shows it being used in a before_filter but I'm guessing you aren't calling it anywhere in your app? Are there other Devise related gems that might be adding it in for you?

Do you have a method called require_no_authentication in your app anywhere?

I wonder how long it takes for Passenger to sleep an app. I haven't noticed it with things like Feedforward.io that I run but rarely use. Maybe there is other traffic to it that I didn't realize or something.

You might be able to set passenger_pool_idle_time to 0 and see if that disables the idle time. https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#PassengerPoolIdleTime

Good tip! This is especially useful for those people who are running a Heroku app on the free tier that gets hung for quite a while if you're not using it.

Only other thing I could think of is setting up something like Pingdom or a similar app that would make the HTTP requests for you. They'd give you the side benefit of alerting you if things go down.

Haha! It's possible there was something accidentally getting cached, but it's hard to say.

Fake it.

Use data tags in your HTML and when one of the options are clicked, Javascript fills out the hidden fields in the form using the data tags on the element that was clicked. Display the data however you want. If you want radio buttons, use it for visual reasons only.

This is a non-standard form you're trying to build. The other, simpler way is to make a set of radio buttons that submit only the factual_id. You can then check the radio button you want, and then have the create action actually go look up the record and save it to the DB. This is almost always my preferred method of doing things. Then this way you can simply display the search results in the HTML however you like with p tags or whatever, you just won't submit that data in this case. You'll simply submit the factual_id.

Definitely a pain in the butt! I think my personal suggestion for most people is to use Rails' secrets.yml and symlink that on deploy just like database.yml. It works just like environment variables more or less and is builtin to Rails.

The SyntaxHighlightFilter depends upon github-linguist that depends upon pygments.rb so behind the scenes you'll be using the same tools. :)

That's up to you to make sure you've got a project that's worth using with it. There are lots of good articles on it that you can check out:

http://java.dzone.com/artic...
http://docs.mongodb.org/eco...
http://www.sarahmei.com/blo...

I'm not really sure how much faster (if any) it is. I do think it's probably going to be faster and it used to be in the tutorial but I'm not sure when it went missing.

I need to experiment with a "submit an improvement" piece to the guides so that people like you can make improvements and I can quickly review the diff and merge them in.

So you'll need a join table between Movies and Users. Something like UserMovie is a standard naming scheme for that. You could also give them a name like Favorite.

In essence you'll do this:

class User < ActiveRecord::Base
  has_many :user_movies
  has_many :movies, through: :user_movies
end

class UserMovie < ActiveRecord::Base
  belongs_to :movie
  belongs_to :user
end

class Movie < ActiveRecord::Base
  has_many :user_movies
  has_many :users, through: :user_movies
end

This lets you access @user.movies to get their movies and you can also get a list of a movie's users (people who favorited it for example) by doing @movie.users

You will need some mechanism to create the join table records, but if you check out the screencast I did on hearts/favoriting/liking, that's pretty much exactly what you'll be doing for that.

It depends on the type of JOIN you do. There's a bunch of different ways to do it, but take a look at this. It's one of the better things out there to explain the different JOINs. http://blog.codinghorror.co...

3 months later isn't bad on the internet these days. ;-)