Chris Oliver

You can do a SQL ORDER on the created_cat column by adding liked_posts.order(created_at: :desc) or :asc if you want ascending.

I've used At.js in the past and it has worked quite well. http://ichord.github.io/At.js/

Ah yes, that's one of those odd gotchas because it accepts two hashes where as most of these methods accept only one. It's a tag with a whole lot of options, so it kind of makes sense, but seems a bit overly complicated.

Wow so it was as simple as the missing newline character?!

Haha! Actually OSX comes with an older version of Ruby. We use that to install Homebrew so we can make installing a ruby version manager easily.

Hey Wesley,

So you said that this is a form for a new Site? A site has_many models, not many sites. Should your form be for association :sites instead?

Sounds like you didn't insTall Postgres yet. Doing that should fix yOur problem.

Woah, that sounds scary. I've never seen that before. Is it deleting records or something else?

For nested queries like that, I think you can use benefits.id as the field. This might be of some help: http://www.elastic.co/guide/en/elasticsearch/reference/1.4/mapping-nested-type.html

I think I'm following you. The before_create seems like the right place to do this for now. If you're doing this before the record is created, you'll need to reference the in-memory objects through the association.

You might have a simpler time by moving this into the ItemDetail rather than the DetailAction. You'll need some way to match the two DetailActions together based upon the part (like "electric water heater") and then you'll need to separate those two items by the action ("replace" or "maintenance")

Once you have those two DetailActions together, you can first start with the replacement sequence, generate it, and then generate the maintenance one minus the replacement schedule.

If you've got the fields for the part and the action, then you can group these based upon the part field with Ruby's group method. Then you'll just go through each group, find the replacement DetailAction, calculate the replacement sequence first, save it, and then do the same thing for the maintenance.

Does that help at all?

Since you're going to need to do different views (it seems) for the forms on each plot, you may need to create a generic controller and view that can dynamically render the form based upon which report is selected.

If you choose "scatter_plot" in the form, then the next page could render a scatter_plot.html.erb view. And you could also use this param to call a report class.

After submitting, probably having some plain ruby classes that do the logic of taking the data and producing the graph. Setting up a common API on a set of "Report" ruby classes could help a lot here. They could all have an initialize method that accepts the data from the form and parses it as necessary. You can add a render method to each class and then use that for rendering out to the view.

If you have a variable with the name of the graph, you can do graph_name.constantize to grab the Ruby constant for the class. It would help you take something like "scatter_plot" and convert it to ScatterPlot and your code can create a new instance of that class dynamically, pass in the data, and render it out. Obviously, since your reports are all going to be somewhat different, you'll need to create a good amount of these classes, but you can start extracting their shared features to a Report class they could inherit from.

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