Chris Oliver

That last bit is basically just saying that it can't find a running Postgres server on that IP address. Make sure it's running on your server and that you've got the right IP. If you are running Postgres on the same server as Rails, you can use 127.0.0.1 instead of the server's IP address so it can just connect locally.

Just press ENTER when it asks you where to save the file instead of typing "cat" and a filename. It will default to the correct location for you. You can then use the "cat" command to grab the public key after it is finished. Make sense?

That's a fantastic topic. I can definitely do that soon!

Can you paste the full logs? For #2, you are probably using something that uses an old YAML parser. Maybe need to update gems or something for it to get fixed.

Yeah my mistake there. Hashie is great.

Agreed with Twitter's API. They want to control that information which is unfortunate. In that case, you can generate a fake email if you don't want to ask the user for it, or you can send them to a form to fill out that information. Neither is ideal, but it gets the job done.

I think your second post outlines a pretty good storage mechanism. You obviously want to actually make that a database backed model with a company_id on it so you don't have to make up the metric and initialize methods since ActiveRecord takes care of that for you.

The trouble will be that if you want to actually query these things efficiently, you'll struggle. Each different datatype will be best stored as a string, because you can always convert things to and from the string type. However that means you can't query against these by data. Only the metadata columns will be useful for sorting and filtering the metric entries. There will be a good amount of Ruby processing to convert from string to date, decimal, int, etc.

If you need to, you could store these as separate tables, one for each datatype, so that you can store native datatypes in the database. Obviously, this is a case where a SQL database isn't ideal.

I'm a fan of cocoon and have used it in many applications. If ActiveForm really does look like it might join Rails core, I'd be really curious about how well it works. Safe answer: cocoon. Adventurous answer: ActiveForm. :)

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.