Chris Oliver

Hey Thomas,

It sounds like you might not be skipping the default before_action :set_product for show which would trip this error because the query definitely shows it wants not-deleted records. My guess would be that before_action is being run before it gets to your show action and disabling that would let your code here run which should work great. 👍

Absolutely! You need to do some interesting things for this, but I've built some JS embeds in the past. They're pretty fun.

For the most part you need to build a separate Javascript file (and stylesheet) that the users will embed and pass their custom data into (like your Google Analytics ID for example). The JS will need to run cross-origin which means that it may run on GoRails.com but it's code coming from Google analytics' domain and therefore it must be safe to send data to their domain. You'll need to read up on https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS and https://github.com/cyu/rack-cors in order to make the cross origin stuff work nicely.

They're probably not technically APIs, their more JS libraries you're building, but they will hit URLs in your app, that might be APIs. Since it's all your own JS, it's not really an API because an API is generally for other developers to consume, not yourself. It's a gray area because it's your code running on someone else's website though.

Hey Stan,

I would say either do client side or server side generation of colors. Server side, you could save a "color" attribute on the user that's an RGB version of their username so you only have to generate it when they sign up. You can pass that value over the websocket and use it for rendering of messages

If you went with the client side, you could have it generate the colors on all the existing messages on the page (might need to add a data attribute for the username) and then apply the colors to the existing messages on page load, and then add it to the new messages afterwards. You can just simply store those on the style="" attribute on the span around the username so that it's added directly to the record.

Either approach would work fine. The client side one is more likely to be simpler and less data intensive because it can generate colors on the fly without storing them. I would probably go with this approach personally.

Absolutely. Some WebRTC stuff is on the agenda, but not for a little while. I'm really interested in checking out Twilio's WebRTC functionality. First gotta cover a handful of other topics like APIs, but that'll be coming after those things!

Hey Brian,

For the most part you're going to just want to replace the Post.all and Post.where part with Ransack. You'd ideally pass in the category in to Ransack search instead as q[category_id_eq] in your UI.

Then you can say:

def index
  @q = Post.ransack(params[:q])
  @posts = @q.result(distinct: true).order(created_at: :desc)

  if params[:category].blank?
    @posts=@posts.paginate(:page => params[:page], per_page: 15)
  else
    @posts = @posts.paginate(:page => params[:page], per_page: 5)
  end
end

Just update your UI so that it sends over that category ID inside the q param so that Ransack can handle it correctly. If it's a link, you can change the param name there, or you can use the search form helper if it's a form you want for selecting the category. https://github.com/activerecord-hackery/ransack#ransacks-search_form_for-helper-replaces-form_for-for-creating-the-view-search-form

Right, so you'd have links to the two different delete urls like this:

<%= link_to "Soft Delete", blog_post_path(@blog_post), method: :delete %>
<%= link_to "Permanently Delete", really_destroy_blog_post_path(@blog_post), method: :delete %>

If I get some time this weekend I'll give it a try and see. I would expect that to work, but there might be some gotchas.

Basically you can take let your normal destroy action call the soft delete method. You'll always want to use that by default.

Then, if you want to add a way to permanently delete it, you can add another route like:

resources :blog_posts do
  member do
    delete :really_destroy
  end
end

And then your controller action for this new route can call @blog_post.really_destroy!

Unfortunately a lot of it is still up in the air directly from Rails. https://github.com/rails/ra... Hoping to see this start being more available soon.

Nothing so far unfortunately on sqlite. This is what I'm watching right now: https://github.com/sparklemotion/sqlite3-ruby/issues/195

That's a good question. I'm not sure why. I've setup fonts before like in the tutorial you linked and that works well. It seems pretty common of a feature, but I'm not sure why they don't include that by default.

Then again, there are a lot of people like me that use Google Fonts or TypeKit in order to just include the fonts from somewhere else without actually including them in the app. Maybe that's common enough they don't include the fonts folder.

Great questions. I've only used Elasticsearch in production on Heroku where they take care of the security for you. As for securing your own instance, I don't believe that you need a VPN in order to secure it properly, but you will definitely want the authentication and firewall. There are some other suggestions out there about adding in SSL and some other things as well, for example: https://brudtkuhl.com/secur...

I'm not an expert on this stuff and I've only used their legacy SSL setup, so unfortunately I don't know that I have any advice for you on this one. Hopefully someone else can weigh in here for you or you can check with Heroku support on it!

You basically need to just copy paste the module and class into a file in your app (say config/initializers/receipts.rb) and then override the methods you want to change inside the class. You can also copy and paste the entire file there into your app if you want to modify all of it.

So there aren't really any differences from my videos for individual charges, just that you create a Charge instead of a Subscription object basically.

As for moving code from controller to model, the only thing that changes is the context. On the controller, your variables and things that are available are all the params and controller stuff. When you move it into the model, you're inside the record itself, so you need to pass in the params you're going to use. That's an important difference, but not too significant.

Maybe an idea for figuring this out (and you may have done this already) would be to create a new app, test this stuff out from scratch and then see if you can get a simple version of this working standalone, and then try to take that and apply it to your actual app. I build lots of throwaway apps to prove out ideas like this and it helps when I can't wrap my head around a problem. Start incrementally, only attempt making a charge, then add a quantity to it, and then once you've got that working add it to your app?

Also don't feel like you need to migrate code into the model yet if you're not ready. You can do all this in the controller if it helps wrap your head around it. At the end of the day, a working app is better than anything else.

It shouldn't. They lock your account to whatever was the most recent version of the API when you signed up so that you'll have seamless integrations and their docs will show you what's available from the version you're on as long as you're signed in.

You can upgrade but it won't likely affect anything for you. What's the latest? Have you narrowed down what's going on?

This is coming soon! APIs are the next series after file uploading. I've been doing some work with iOS / Swift and React Native on the side which will tie into the APIs content as well so we can talk about doing native mobile apps but also Turbolinks-iOS and the like. Basically this is just taking some more time to research all the things I want to cover and so I'm filling in with some file uploading, transcoding, video processing things.

Really good question. The main tradeoff going that route is that while you might reduce the number of records at the beginning, you won't in the long run because you'll need to save the read timestamps for each of those users. You'll also complicate the initial query for notifications because you now have to search multiple tables (forum threads, episodes, etc) to figure out which ones you should notify the user about.

So if you're going to be creating those records anyways, why not just save them as a Notification record at the beginning? You can create them in a background job that will speed up creation of them at the beginning without overcomplicating your app just yet. Once you hit massive performance problems, you can optimize it then because you'll know exactly where the bottlenecks are. Trying to optimize before you know where the bottlenecks are is always where engineering problems tend to make things really tough.

Make sure you're using these helpers for your static assets: http://api.rubyonrails.org/...

A bit counterintuitively, that actually makes things more complex if you treat direct messages that way. By doing that you complicate the database significantly because now you can't simply join tables since you're using polymorphic assocations. Plus your direct messages no longer have a Chatroom object meaning all your messaging code on the frontend and backend need to account for the different types and treat them differently.

By treating DMs as a special Chatroom with only 2 users, you can run the exact same Javascript and server-side code without modifications. The only rules you need to set in place (like we did in the episode) are to specify that Direct Message channels are only between two users. That's the only difference between a direct message channel and a public channel making this a lot easier to maintain.