Daniel Weaver


4,440 Experience
13 Lessons Completed
2 Questions Solved


Just wondering if it's best to store locally, in my own database, all of the customer's Stripe data or is it better to call for this every time I want to display it?

There's a lot of data and it feels funky to store it all locally and try to keep it all in sync. But on the other hand, calling the Stripe API all the time feels wrong too.

I'm thinking about card brand, card last 4 digits, trial end date, coupon applied, coupon end date, next billing date, etc.

Posted in How would you set up these plans in Stripe?

Bizarrely, Stripe have just introduced some major changes to the way subscriptions are handled. They're now based on Products (marked as 'service') and have functions for tiered and graduated pricing.

Unfortunately, from what I can tell of the docs, none of this helps in my particular situation 😂

Posted in How would you set up these plans in Stripe?

We bill our customers on monthly subscriptions, based on their resource usage in the app. They are private music schools and we charge by the number of students they have.

The ranges are as follows:
1-50 students is $19/month
51-100 students is $49/month
101-250 students is $79/month
251-500 students is $129/month
and then an extra $25 per 100 after that.

Initially I created lots of individual plans in Stripe, one for each range of students. This has a number of issues:

  • If we want to change our prices we have to tear down all the plans and create a whole set of new ones because plan amounts can't be updated. We then have to migrate all schools to the new plans.
  • As we get larger and larger schools onboard, the number of plans continues to grow. We're up into the 1,000s of students now. All the plans also have to be duplicated in Stripe's test mode too.
  • Switching a school between plans is problematic during the month. It's possible to switch plans without prorating, which is what we want, but I don't want a flood of Stripe API hits every time a school's student number changes.

My solution to the last issue is to use the `invoice.created` webhook from Stripe and just check the student number once, right at the point of charging. This works fine but doesn't solve the first two problems.

A possible solution for the first two points (since we're already using the `invoice.created` webhook) is to put each school on the lowest $19/month plan then, at the point of charging, look up the number of students and add an invoice item to adjust the invoice total to the correct amount.

For instance, a school with 150 students should pay $79/month. They would already be on the $19/month so I would add an invoice item of $60, called "150 students", to bring the total to $79. But I'm concerned this will look confusing to the customer.

As you can tell, I've been going around in circles with this so any help or advice would be much appreciated!

I'm happy to pay for a consultation session if there are any Rails/Stripe experts out there willing to jump in! 😉 

Posted in Direct File Uploads to S3: Part 1 Discussion

Great walkthrough of setting up CORS and IAM permissions. I set these up a few years ago for my app by digging through the AWS docs and, honestly, I wasn't sure about anything that I was doing but it all eventually worked. Now I actually understand more of the process! Thanks!

Posted in File Uploads in Rails With Shrine Discussion


Posted in File Uploads in Rails With Shrine Discussion

Great video, thanks. Note that the Shrine Homepage link should be http:// and not https://

Posted in How about an episode on zero-downtime deployment?

Hey Chris, thanks for the link. I also just found out about the new Pipeline feature they have in beta.

It looks perfect for me. Several apps - 'review', 'staging', production' - are all part of a single application pipeline and the build is promoted from one app to the next. So a new feature would go to review for internal checks, then staging for quality, then finally to production.

The beauty of it the pipeline is that it's the compiled slug that's promoted - that means no more long compile times when deploying to live. Just push the slug and restart the app. Sounds great.

Have a look and see what you think :)

Posted in How about an episode on zero-downtime deployment?

I have a Rails app on Heroku running on just 2 web dynos (Standard type).

I'd like to know how best to ensure uninterrupted access to the app for my users while also allowing me to deploy any time I like.

I love the concept of continuous deployment but the reality is that I often wait until the early hours of the morning to deploy in case there are issues. This is never ideal for obvious reasons!

Thanks, Dan.

Posted in Using Purchased Themes with Rails | GoRails - GoRails

Great video, thanks. Lots of quirks to consider when doing this!

Perfect, works like a charm, thanks Chris.

I'd still like to look into a solution that integrates/overrides the standard Rails data-confirm so that I can write standard code in my views then choose whether to use an override library like SweetAlert or just leave it as regular Rails alerts.

In the meantime this solution is working great :)

Chris, I just added your code and it's working great. I think I understand it all - I'm still getting used to CoffeeScript syntax.

How would I pass some data from the view into the JS, like the model class, 'User', so I could show 'Delete this user?' in the dialog?

Thanks Chris, this looks great! I'll give it a try tomorrow.

Have you seen the sweet-alert-confirm gem? It does a similar thing, overriding the default confirm dialog, but it does it using the regular Rails method with data-confirm. Any thoughts on which way is best?


I should also mention that I can get a usual Sweet Alert dialog to show by using sweetAlert('Hi'); - it's just the confirm dialog I'm having difficulty with.

I'm trying to use Sweet Alert to replace the standard Rails confirm dialog. I can get it working in a plain new Rails app but not in my production app.

I'm using the sweet-alert-confirm gem here: https://github.com/mois3x/sweet-alert-rails-confirm

When I hit a Delete link the confirm dialog is skipped entirely and the record is immediately deleted.

<td><%= link_to 'Destroy', user, method: :delete, remote: true, data: { confirm: 'Delete this user?' } %></td>

In a plain Rails app this line works but in my prod app it doesn't. I assume there is something interfering with the JS. The console in Chrome shows nothing unusual and the Rails server log just shows the usual delete action:

Started DELETE "/users/17" for ...
Processing by UsersController#destroy as JS
  Parameters: {"id"=>"17"}
  User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1

My question is: how do I go about tracking down the conflict?

(Chris - you got the behaviour I need in your tutorial episode without using the sweet-alert-confirm gem - how did you do that?)

Chris - how did you add the JS to the delete button in your code?

I'm trying to use sweet-alert-confirm gem to show the new alerts on standard delete links but I can't get the alert to show.

Looks like you don't use the sweet-alert-confirm gem but you're getting the results I want. Can you show the code?

Posted in Sending emails with Mandrill Discussion

How would you catch tests when using the Mandrill API and templates? At the moment I'm just skipping it using something like:

# MyMailer.rb
def new_book(book)
return if Rails.env.test?

logo Created with Sketch.

Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

© 2020 GoRails, LLC. All rights reserved.