Chris Oliver

In that case, I think your approach is fine. A group by query isn't really going to help you much in SQL because you still need to sort it on the Ruby side. The SQL group by is most useful when you're gathering things like counts or doing joins, not for ordering results.

The Ruby group_by method is actually what you want here to organize your results. I would maybe rename @users to @grouped_users so that it is clear the variable is not an array of users but a grouped array.

Are you trying to implement a search or just sorting into groups? Depending on the goal, I have a few different suggestions.

Fantastic question and I think this is worthy of recording an episode (or two) on asap. One suggestion is the apartment gem but also it's wise to build this from scratch so you can have a good understanding of everything you need to consider when building a multi-tenant / subdomain app.

Hopefully I'll be able to record an episode for this next week!

Really not too much if you want to use something like Wistia for the video hosting. You can control access there and it is about as simple as building a building a blog for the videos, email integration, and file storage somewhere.

Totally ballpark, I'd say depending on how little you could get away with, it might cost $1500 or higher.

If you use the localize method in both places, it will work just fine for translatable strings. You just want to make sure you always keep them the same.

Here you go! I ended up getting to this topic really quickly. :)

https://gorails.com/episodes/forms-with-multiple-submit-buttons

This looks like a reasonable approach to testing your user creation and lookups but it isn't a full example: http://stackoverflow.com/qu...

Good find! I've had to do that a couple times before but I can't remember the exact situation that required setting the env. This is good to note and hopefully helpful for other people running into similar problems.

Updated the post to show the code for those. I'll point you to the Github page for the latest info on the gem though: https://github.com/excid3/s...

Glad you got it working!

That message comes from the Rails 500 error, so you'll want to check your Rails logs to see what's going wrong there.

You want to run gem install bundler to get the appropriate version on your server. apt-get for any ruby related things is bad with this set up because you'll get conflicting things going on (or at least confusing things).

I'd say that's probably a decent solution. What happens if the user doesn't know to press Enter and wants to create another model?

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. :)