Chris Oliver

Spree is one approach if you want to use something premade.

As far as keeping inventory of things like shirts, you can probably do two separate things:

1. You keep track of new additions to our inventory, maybe call them new stock or something. Record the amount of tshirts added each time you get more inventory added in stock.
2. Keep track of the orders and the quantity of shirts leaving each time.

The total "in stock" inventory will simply be summing up all the times you added new stock and subtracting the sum of all the quantity ordered. You can cache a copy of the current value in stock and update each time you add inventory or have new orders.

You can then get a history of the inventory over time in your store and what's leaving. This will be helpful for seeing and predicting how much inventory it makes sense to keep on hand and can be useful for other things as well.

Nope, but might want to check to see if you've got JS errors or conflicts with Turbolinks.

This probably depends on a lot of things. Are you getting in shipments of new items? Are the products being consumed? (sometimes this might not be the case if you're talking like inventory of trucks for example)

More details on what you're shooting for would be helpful but I'm sure we can come up with a fairly straightforward solution to it.

Well, the params in the routes are used to lookup the ID column in the tables. You're using the same params id to look up two different records which doesn't quite make sense there. I would not set the forum_post in that before_action so that you don't run into weirdness.

So one thing here is your set_forum_thread method is trying to do something that doesn't quite make sense. Your URL has an ID in it and that represents one single record, but you're using it to find two records. Really you want this to

Assuming you're using nested routes, you will have a URL like this: /forum_threads/:forum_thread_id/forum_posts/:id and you want to make sure you use the correct one of those params for looking up the different tables.

def set_forum_thread
  @forum_thread = ForumThread.find(params[:forum_thread_id])
end

It sounds like your forum_post.user.email isn't working. Your forum_post must not have had it's user_id set in the database. It looks like your controller is setting it properly, but you should check it out in the console to make sure it's actually saving it.

Sounds like your JS isn't sending over a token through to the server.

You can use the regular form field helpers like input_tag to make that easier.

Yep! Just like you would with a normal form. This one isn't really much different aside from it taking the credit card fields and handling them specially with JS. The JS will submit the form like normal, so your other fields will get treated just fine.

So ActionView::Template::Error (First argument in form cannot contain nil or be empty) means that when you call your form_for, one of the variables you passed in was nil. That means either forum_thread or forum_post in this was nil <%= form_for [@forum_thread, @forum_post] do |f| %>

It looks like you've got the before_action to set the forum_thread variable, but none on the edit action (or update) to set the forum_post. So most likely the forum_post is nil causing it to throw that error. Set that variable and you should be all set!

That form should work just fine for that. If they're submitting other information, for those fields you'll want to make sure they have the 'name' attribute so they get submitted (unlike the credit card fields). Aside from that, make sure you're permitting those extra params and that should probably do the trick.

It looks like in a couple of your controller actions, you're overwriting the variables incorrectly which might be the issue:

# show
@forum_posts = ForumThread.find(params[:id])
@forum_posts = ForumPost.paginate(:page => params[:page], :per_page => 3)

That first part there should probably be @forum_thread = ForumThread.find(params[:id]) so that you assign it the right name.

Then the second one, you need to reference that @forum_thread in order to use it's associated posts only. It should look like this: @forum_posts = @forum_thread.paginate(:page => params[:page], :per_page => 3)

I think if you get that fixed and any others like that, that should fix your issues with ActiveRecord.

Oh that's a super simple solution for paperclip. I love it!

That's a really great question. Personally, I like to either record example urls and JSON that the frontend devs can work with or I'll give them example code that works already that they can modify. It all kind of depends on the situation and what we're trying to accomplish. A lot of times we'll pair programming at that point to hand make sure we're both on the same page and the integration can work well between the two.

What issues are you guys running into with your approach?

So browser these days try to be helpful and not force downloads by default. The way you can get the old functionality is to set the Content-Disposition header on the request to attachment which will cause the browser to download the file instead of showing it embedded on the page.

I'm not entirely sure how you'll need to go about that, but it looks like you're able to add the header to S3 requests. http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html

The best way is really to load up all the user's likes for those related objects in a single query. Then you can check those post against the likes result with Ruby and that will be 2 queries instead.

You'll have to do some custom SQL to pull off #2, but it's not so bad. Check this out: https://robots.thoughtbot.c...

Looks like they recently renamed these to "Aggregations". The SearchKick readme has some code there, but you'll have to adapt it for the UI. You'll want to render out the aggregation names as links and then pass those into the URL as params so you can pass them into the search query. I'll do an episode on this sometime soon!

Yeah, you could probably do a special route to the notification. It would mark as read and then redirect you to the actual item in the notification. Either that, or you could mark any notifications for the object loaded in the show actions.

Yes! Definitely an awesome topic to cover. Quick outline of what it would look like:

class Notification < ActiveRecord::Base
  belongs_to :user
  def mark_as_read
    update(read_at: Time.zone.now)
  end
end

You can look up the unread notifications for the nav, and send over an AJAX request to the Rails app to mark all those as read.

Hopefully able to do a screencast on this soon!

Check boxes make for great easy additions and you can hide/show them with some javascript based upon the plan that's selected.