David Kimura PRO
Joined 7/18/2015
Drifting Ruby Owner
Ruby Rogues Panelist
David Kimura PRO said 9 days ago on Nested Comments from Scratch :
  AhmedNadar It looks like your instance variable commentable got set to a Comment instance instead of an Item. Do you have the app set up for a comment to receive a comment? And when you set the commentable, you should likely be passing in the Item instead of the Comment.

David Kimura PRO said 8 days ago on Diving into Hotwire :
  ternggio95 Have a look at the source https://github.com/hotwired/turbo-rails/blob/main/app/models/concerns/turbo/broadcastable.rb on the broadcast methods. At the top, there is a bit where they show a callback to then trigger a broadcast.

after_create_commit :broadcast_later


def broadcast_later
  broadcast_prepend_later_to examiner.identity, :clearances

Since you will want to update a count, you would likely want to replace instead of prepend. The broadcast_replace_to would likely be what you would want. However, if there are a lot of users, you may want to do this in a background job with broadcast_replace_later_to instead. It looks like this allows you to specify a partial as well as the local variables which in your case would be the product count..

# Replace this broadcastable model in the dom for subscribers of the stream name identified by the passed
# <tt>streamables</tt>. The rendering parameters can be set by appending named arguments to the call. Examples:
#   # Sends <turbo-stream action="replace" target="clearance_5"><template><div id="clearance_5">My Clearance</div></template></turbo-stream>
#   # to the stream named "identity:2:clearances"
#   clearance.broadcast_replace_to examiner.identity, :clearances
#   # Sends <turbo-stream action="replace" target="clearance_5"><template><div id="clearance_5">Other partial</div></template></turbo-stream>
#   # to the stream named "identity:2:clearances"
#   clearance.broadcast_replace_to examiner.identity, :clearances, partial: "clearances/other_partial", locals: { a: 1 }
def broadcast_replace_to(*streamables, **rendering)
  Turbo::StreamsChannel.broadcast_replace_to *streamables, target: self, **broadcast_rendering_with_defaults(rendering)

David Kimura PRO said 4 days ago on 10 Tips and Tricks :
Nice   Andrey Ilyunin ! That is definitely a more Convention over Configuration way to handle loading configs. Love it!

I think the episode example is useful for non-rails apps (ruby scripts or other frameworks), but I would definitely prefer config_for in Rails apps.

David Kimura PRO said 3 days ago on SOLID - Liskov Substitution Principle :

Interface Segregation Principle - ISP
(source - https://www.honeybadger.io/blog/ruby-solid-design-principles/)

The interface segregation principle is applicable to static languages, and since Ruby is a dynamic language, there is no concept of interfaces. Interfaces define the abstraction rules between classes.

The Principle states,

Clients should not be forced to depend upon interfaces that they don't use. - Robert C. Martin

What this means is that it is better to have many interfaces than a generalized interface that any class can use. If we define a generalized interface, the class has to depend on a definition that it does not use.

Dependency Inversion Principle - DIP

I think that Thoughtbot has the best explanation for this. https://thoughtbot.com/blog/back-to-basics-solid#dependency-inversion-principle

The Dependency Inversion Principle has to do with high-level (think business logic) objects not depending on low-level (think database querying and IO) implementation details. This can be achieved with duck typing and the Dependency Inversion Principle. Often this pattern is used to achieve the Open/Closed Principle...

David Kimura PRO said 23 minutes ago on Authentication from Scratch :
  rebuilt you are essentially putting a pause on that thread so it is not ideal. However, I think that it must be weighed given the situation with potentially leaking exposing customer emails. This was more of an illustration of one of the things that a developer may not think of that a bad actor may.

I am not sure about Heroku default app servers. I typically would use the Procfile to specify booting up Puma, so that would probably be a non issue. Their documentation does have a recommendation for using Puma as well. https://devcenter.heroku.com/articles/ruby-default-web-server#production-web-server