Chris Oliver

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.

My suggestion would be to make a pricing page that have links to the checkout page and you put a "plan" in the URL with the ID of the plan to sign them up with. That way you can store the plan_id in a hidden field in the form nicely.

Basically you're wanting to build a nested form, where you have one main item (the Order) and many nested items underneath it (the OrderItems). Cocoon is a cool little library that lets you dynamically add those nested items to the form. It might do what you're looking for: https://github.com/nathanvda/cocoon

You'll want to probably use an if statement there to send it without the subdomain option. I know you can include helpers into the mailers so that could be a nice place to put the logic for the subdomain option.

I saw that recently and haven't had a chance to use it yet, but it seems like a wonderful option. I think that'll be the way to go especially if it's a seamless experience. The one question I have is how database migrations are handled between promotions. The code's the easy part, but the db migrations can cause some trouble.

Sure, just transform the params submitted and make the headers and content of the CSV dynamic then.

Thanks! :)

You would probably want to do this on the Rack level. What you're basically attempting is a rate limiting / throttling algorithm for the API. This is best done in Rack because it will be faster than going all the way through the Rails stack. Something like this is a good starting point. https://github.com/bendiken...

I'm not sure that it supports the leaky bucket algorithm that shopify does, but it's a good starting point.

Yep! That's exactly right. You can get notifications of all the subscription events and keep that in sync and send out any emails you need to when they get canceled.

The main benefit is that rails-assets just generates a gem based upon the original source code. It's nothing special but easily updated. The custom gems like bootstrap-sass sometimes lose the maintainer and don't get updated making it hard to use when newer versions come out. That said, I still usually prefer the custom maintained gem because I've had trouble with rails-assets a handful of times and can at least maintain the custom gems myself.

It's really personal preference. Not a huge benefit either way, just different takes on it.

Great idea! I think this would be important. There's a lot that goes into orchestrating a good deploy like that especially when database migrations are involved.

I would definitely recommend checking out Heroku's Preboot feature in the meantime. https://devcenter.heroku.com/articles/preboot