Chris Oliver

Sounds like you checked pretty much everything! That's all the things I can think of (and more) so I wonder what's up with that.

One last thing you might check is this: https://github.com/ruckus/active-record-query-trace which should help you find the query based on the line number. Maybe it was something obvious we're overlooking.

Nothing too much. All you need to do is specify the @q variable so the search form knows what model it's searching. The results will go to your index action so there's nothing much you need to do here.

def show
    @q = Post.ransack(params[:q])
end

Welp, that looks correct as well. Somewhere you've got a query that it's hitting that doesn't seem to be the line in your show action there. Might take some more debugging to find it, but your code looks correct right now.

Ideally it's better to pass in only the ID. If the record was deleted before the job runs, you can safely quit if you can't find the record assuming it was deleted.

Now I believe that if you pass in an ActiveRecord job to ActiveJob, it will transform it to a GlobalID (https://github.com/rails/gl... / http://edgeguides.rubyonrai... which is a representation of the ID and class name so that you don't have to specifically pass the ID.

If you use Sidekiq, etc directly without ActiveJob it is going to try using that object which is why they recommend using the ID specifically.

ActiveJob + Global ID should look up the record once the job starts (you should see this in the logs) which will make running those jobs safe.

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?