Chris Oliver

Likely some configuration issue. I'm not entirely sure what causes that, but it's definitely fine to run on localhost. Probably like this guy where you've got a mistake somewhere causing their JS to run incorrectly: http://stackoverflow.com/a/...

You should just copy and paste each line into your terminal and run each one. Make sure that your copy/paste didn't mess up the command during the paste. I'm not sure what's causing you guys to get malformed commands.

Your ~/.bash_profile should just have one line that is that same as what's in the single quotes on that first line.

if which rbenv > /dev/null; then eval "$(rbenv init -)"

Looks like he had accidentally combined those two commands to run on accident.

Pretty simple. You'd need to basically listen for the subscription cancellation webhook to come across and then in there you can just move the user's plan over. The webhook will be your way of knowing that the last payment attempt failed and the user's paid subscription canceled. It'll just send a notification to your server and as long as you're listening for it, you can run the code to downgrade to the free plan. Make sense?

Check out this episode on the webhook stuff if you haven't already: https://gorails.com/episode...

Always happy to help. :)

Hey Lauro,

link_to requires two parameters, first the name, second the URL you want to point to. You've only passed in the name, so it's not going to link correctly for you. Try passing in a second parameter to get that working:

  <h3> <%= link_to like.post.title, like.post %></h3>

You can do str += n.to_s if str.empty? instead because it's an integer and needs to be converted to a string before you can add those together.

I would just create one notification record for each user you want to send it to. You need to do that anyways so you can mark when each user read their notification if you want to add that feature in the future. So normally you would just do a loop, find all the users you want to notify, and then create a Notification record for each user.

Yeah that's going to be an interesting one. Presumably you'll end up needing to build a cluster of dedicated actioncable servers and maybe you connect 100 users to each at a maximum. At some point as well, you'll probably run into Redis pubsub scaling problems, but that hopefully isn't a bottleneck right away.

Oh you know what, I probably had access to ActiveSupport while I was doing that.

Add this line at the beginning if you have the active_support gem installed.

require 'active_support/core_ext'

The blank? method doesn't come from Ruby but most of my work being in Rails I'm so used to having it around. :)

I'm not sure, but compare your code against the source code of mine that's linked in the episode notes. I'm sure you'll figure it out! :)

No, you don't need to because it will check for the action's json.jbuilder template. Just make sure you created that file and it's index.json.jbuilder in the app/views/notifications folder.

I've been realizing I need to make that transition soon anyways just because there are way too many screencasts to keep track of at this point. :)

I'll probably be migrating to a bunch of small series over the next few weeks!

👍🎉

Awesome! You're welcome! :D

Hmm, I was hoping it wasn't. Usually it's just that the user isn't signed in. Otherwise...I'm not entirely sure. There aren't a whole lot of places to go check to make sure things are correct aside from that.

Possibly just a typo in your comment, but make sure you've got:

@comment.user_id = current_user.id

If you specify user_id, then you need to specify ID on the user, or you can just assign the object to the association alternatively:

@comment.user = current_user

Is the user not currently signed in by chance when you submit a comment?

Just ignore that part and add the order and limit functions to your call when you retrieve comments. That's the important bit there.

You could change it to the following:

<% commentable.comments.order(created_at: :desc).limit(5).each do |comment| %>

You can use this approach still the exact same way with ActionCable if you want to preload some data in the view before the Websocket connection gets initialized.

For the most part, with websocket stuff, I imagine in most cases you will want to just display a loading spinner instead while the connection gets setup. They'll happily work together though with no problem. The only difference is that you change the mechanism to update the data from AJAX to Websockets.