Chris Oliver

I would probably just install the Heroku CLI on Windows as well to solve that problem. Then you can access that from Windows until it's finally stable to run on the Linux subsystem.

Hey Robert,

When Stripe tells you that the customer doesn't have a card to charge, that means that your form probably hasn't submitted the stripeToken param to attach to the user. You'll want to make sure that's getting passed over.

Yep, like I mentioned in the course, the new Stripe Elements code is the newest version of the Stripe Javascript. The old code is there for reference, but you can just use the Stripe Elements version and you will be all set. 👍

Let me know if you run into any troubles!

Hey TL,

That's definitely a great suggestion and you're right, those recommendations engines aren't trivial.

I'd probably check out this gem first: https://github.com/davidcelis/recommendable

And if that didn't work out, I'd try building my own implementation. It seems most of these gems aren't too well maintained.

Congrats Bijan! Thanks for your work on that! :D

You've probably got two options here:

1. Build your own custom markdown parser so you can add in new features. You could use html-pipeline for this in Rails. That's what Github uses for their commenting. You'd have to come up with your own syntax for features like highlighting.
2. Use an HTML editor like Trix, etc and build your own features out there. These typically have full HTML support so you're free to write as complicated of features as you want and you're not stuck with some simple formatting like Markdown. I would imagine an HTML editor would provide you with a whole lot more flexiblity going forward.

In either case, I'm sure you'll have to build custom plugins for your editor to pull off all the features you want. The thing I would recommend is to pick a complex feature or two and try it with both. Which solution makes it easiest and which do you see being most flexible for the inevitable changes in the future?

Hey Sanjay,

At the moment, there isn't any monitoring but that's something that's on the todo list. Any specific monitoring you'd like to see?

First, keep it exactly the same. You want to make sure that every adjustment you make is going to be fine in production, so don't make any significant changes.

If it's minor versions of Ruby that are different, that's fine. They don't have to be perfectly the same. Gem versions matter a lot more.

Watch the next episode in the series: https://gorails.com/episode...

Probably doing something like these solutions would work: https://stackoverflow.com/q...

Hey Travis,

In this situation, I'd connect to the server and pull down a copy of the code that's currently running as soon as possible. Create a new git repo and add all the code there so you've got it safely stored away on Github, etc.

You'll probably also want to make a copy of the production database and save it locally. If you import it to your local database, you'll have a copy of production data that you can use to get up and running probably a bit quicker. Just keep in mind that you'll want to make sure you don't email or charge customers from your local copy, so it would probably be good to sanitize emails and other information.

I would probably then try to setup an actual deployment process, either using something like Hatch, Heroku, or a tool like Capistrano to make sure you can deploy it safely to a separate server or something. That way you can verify that deployments work without affecting the production app.

At that point, you can try doing a deployment over the existing codebase or you may want to deploy to a new directory and point the webserver to the new directory on the same server.

So in general:

1. Create a git repo with all the code
2. Backup the database
3. Setup deployments the way you'd want it going forward
4. Do a test deployment (include a small change so you can see if it worked)
5. Verify that code is running correctly on the server (run it on a different port)
6. Swap the production webserver to the new deployment

I might be forgetting some things, so anyone else with ideas, please jump in. 👍

I don't think so, just use the administrate generator to create the administrate files. You don't need to create any folders yourself.

Yeah you should never edit a gem's source code. Install the administrate assets into your app using the generator and edit those to include trix.

1. The admin compiles separate css and JS files. Your regular users will never have access to the admin, so it doesn't make sense to give them all your admin css and js.

2. They will be compiled automatically. Administrate already configures your app to have separate admin js and css files that are compiled via the normal asset pipeline. The asset pipeline can compile more than one file as output, but we don't generally do that so the user only has to download a minimal set of files. We only do here because sending those regular users the admin style and functionality doesn't make sense.

Use the Heroku Scheduler.

Should work for that too, since the JS is agnostic to any backend storage you might want to use. Direct uploads to S3 etc will work as well.

Really really easy. You need to add the JS and CSS to administrate's versions. Then you can create a custom field. I made one called FormattedText and just added the editor to the form.html.erb view for the field.

<div class="field-unitlabel">
  <%= f.label field.attribute %>
</div>
<div class="field-unit_field">
  <%= f.hidden_field field.attribute, id: field.attribute %>
  <trix-editor input="&lt;%= field.attribute %&gt;"></trix-editor>
</div>

Yep, just swap out the Shrine code on the Photos model and you're set.

Cron jobs are good for multi-server setups too. Just have one server run cron jobs and your background jobs. They'll all share the same database anyways so there's nothing server-specific.

The downside of scheduling jobs is that they're very hard to cancel and manage if you need to ever do that. I find that generally outweighs a nightly cron by a lot and almost never go with the jobs route for a situation like this.