Chris Oliver

Good catch! At a point, it becomes second nature and I forget to mention things like that being required. :)

Good question. I'm not sure about NodeSource, but I'd say as long as Chris Lea keeps updating his repo (and he seems to quite consistently), you're fine with that. Feel free to try out NodeSource and let me know how it goes.

I think it came in Chrome beta a month or two ago. It's so useful to separate out your Google accounts between windows.

And I've uploaded the repo for this app to Github for you. :) It's the last link in the resources list.

Depends on what you're backing up, but for example, you can restore a mysql database with a sql file like this: http://stackoverflow.com/a/...

Pysch is a YAML parser. Have you checked your .yml files to make sure you don't have any syntax errors in them?

Glad you got it working! :) You may need to change the link_to to go to a different url. My example assumed you weren't doing nested resources for PDFs. I'd guess you probably want to use the nested routes here for it.

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.