Chris Oliver

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

If you're doing recurring donations, you'll need to store a User model of some sort so they can come back in and cancel it. You may not need passwords in that case, a secret token that you log them in with via email would work. You could make it work similar to a password reset token basically so they could manage their monthly donation via email.

You can generate a scaffold for it just like you did with the posts in the Rails class. You'll possibly want different fields, but you can create it the same way.

Those would be flags for bash, not cron itself. -l helps make sure your command for runs in a login shell so everything runs as expected and -c just says "hey we're passing the command through as an argument instead of running a script.

You shouldn't ever have to use sudo for this. If you do, you're going to end up with permissions errors later on. Homebrew might in order to change permissions for some of its own folders where you install apps from, but the rest of it shouldn't ever use sudo.

I can! In the meantime, check out Ryan Bates' episode on it: http://railscasts.com/episodes/406-public-activity A little old, but the gem hasn't changed much.

Yep that's it!

You can just associate all the records with the user_id. The only time you need Apartment is if the data should be kept private in their own databases for security reasons. You should be fine associating them to the user and making sure you don't load the other users's records.

Yeah, so you could have one Rails app that responds to all those domains and looks up the store like that. This would be easy to implement and manage (basically how Shopify works). I think you may possibly still need some sort of SSO in order to have the user logged in on the separate domains, but the code can all live in the single app.

Yep, that should basically be it, but the last step with the redirect, there will be something like a token that gets sent back that is verified.

The reason for that is because separate domains can only set cookies for their own. Subdomains can be included but not different domains which would be a security issue. Browsers won't let you set cookies between separate domains.

You'll have to get a token back that you can verify and set a cookie on the other domain as well to know that you're logged in on the other site. Basically you're making a microservice for authentication.

Not entirely sure what you'll need to do with the analytics, but that's definitely no fun.