Chris Oliver

ElasticSearch definitely lost a good gem with Tire. It really seems like the new ElasticSearch-rails gem isn't anywhere near as friendly. There were a few other good ones that I can't seem to find.

From my reasonably limited understanding of search, you'll want to index Products and include the benefits inside of the Product record. That way when you do a search, the match on Benefit will return the Product.

Not sure if that helps you at all, but maybe it's a start?

I would think that you could loop through all the existing records you have and try doing Apartment::Tenant.create('tenant_name') on them, replacing tenant_name with the subdomain obviously.

It does sound like the teachers aren't sequestered appropriately yet. I don't quite know how to move records between the global tenant and a specific one, but that is probably what you need to do so they are stored separately.

Curious what you come up with to solve these problems. Keep me posted!

You're always calling PostPolicy.new but Pundit provides a helper that creates the new policy and sends in those objects.

Since we inherited from ApplicationPolicy, the initialize method there is the one that sets the user and record variables. We created that, not Pundit so you have full control there.

When you call "authorize @post" it looks at the @post.class which is Post. Then it makes that a string, adds "Policy" on the end and looks up that class which would be "PostPolicy". That's how it knows to grab the right policy.

Definitely plan on doing more Javascript / CoffeeScript soon.

That's a great idea. I'll add it to my list!

Yep! All your classes are available inside your POROs like you would expect. The things you won't have access to are things like "params" that come from inheriting ApplicationController. You'll have to pass those in.

Yes!! I'm definitely planning on doing a "Rails-from-scratch" series so you can see exactly how all this comes together from just regular old Ruby. Really looking forward to it but need to get it all mapped out beforehand.

Are you able to go back and retroactively create those tenants for records that already exist?

Sounds like you've got issues with apt-get running. Other people have had the same issue it looks like so you'll want to make sure that you can run "sudo apt-get update" successfully it seems.

http://stackoverflow.com/qu...

I'm sure you could. You probably need to switch the tenants manually in this case. If you didn't need the company in the URL, you could also have it switch tenants in a before_action on every request based upon the user that is signed in and the tenant they are associated with.

This is definitely an important thing to decide upon. If you do this poorly, you could end up with a really complex set of reports that are a real pain to do maintenance on.

It sounds like you might be able to structure these reports to hit search and then your reports could simply cache a copy of what the query looks like and maybe you can build configurable views for them that you could simply configure in JSON or YAML somewhere.

Do you have an example of a few reports you might want? I'm trying to get an idea of how they might be alike or different and then extrapolate from there on ideas to whittle it down.

Cancan makes a good amount of assumptions that you are doing the normal Rails lookups here. There are a handful of different ways to make them work together, but the best one I've seen is to not use the load_resource and to authorize in the action instead: https://github.com/norman/f...

Awesome!

The only difference is to deploy your other apps to separate folders, create their dbs, and add another server config to nginx so it knows to serve it up on a different domain/subdomain.

Thanks! I appreciate that a lot! :)

Should it be locals: {pin: @pin} instead? I'm assuming you are just missing sending the pin from the controller.

For more database-related things, a transaction is good because it gives you the ability to do multiple changes to the data without them partially being finished.

With APIs it is a bit harder since you cannot roll back the execution of the API request. In this case, you basically want to log something immediately after the API request is finished denoting that this part of the job has been completed.

In the case of sending an email, you will need to make sure that your code after a successful send is very simple. Immediately after sending, you will want to write a record on the user that the email was sent. At this point, if the job died and was retried, you would be able to check if that email was sent and then cancel this job.

So creating the database and creating the tables are separate. The migrations are what tells the database which tables and columns to add and the database is just the one place to store everything. You'll want to make sure the migrations run on the server.

You should be able to do that with cap deploy:migrate

Well, the issue isn't that the packages aren't maintained properly. It's that the software doesn't get upgraded to be compatible with the latest Ruby releases always. Sometimes you have code that works on specific versions of Ruby and that means you will need to install that version specifically on your server. That's why everyone recommends using a Ruby version manager of some kind like rbenv to handle this. Once you get the hang of it, it goes smoothly, but at first it can be daunting and a bit of a pain to set up.

Hmm, not sure what's wrong exactly. Also you could just create the db after getting into the psql console by doing CREATE DATABASE your_database_name. Then you need to grant all privileges to that user on the new db.

Great reference for this stuff:
http://www.cyberciti.biz/faq/howto-add-postgresql-user-account/