9 Matching Annotations
  1. Jul 2020
  2. Jun 2020
    1. This means you no longer have to declare inverse_of on two associations which have good names.

      ... which have good names.

      This implies that those names where the inverse_of cannot automatically be inferred are bad names. I disagree that a "good name" is at all related/dependent on that ability.

      What they should say here instead is:

      ... which have names that allow the relationship to be easily inferred.

      Or refer to these names as the "default" or "Rails conventional" names for these associations.

      But it is not necessarily a better name. A better name is, quite often, one that is more descriptive and specific.

      For example, just because by default if you use rails generate with a User model, it might (I don't remember; can it even generate associations?) create a belongs_to :user association doesn't mean that's the best name for it. belongs_to :author or belongs_to :owner, for example, being more specific, are likely better names. The model still needs a generic name like User because it may be used in various relationships, but the relationships themselves should pretty much never be called user because there's almost always a more specific name that better reveals/describes the relationship.

    1. I know you acknowledged your response was late and you're just trying to help but please don't resurrect very old threads.

      This is better than creating a duplicate new thread.

      There is no better place to respond to an existing topic than in the existing thread for that topic.

    1. This is a poor solution

      What's so bad about this solution? If it works, it works. And it only requires wrapping in 1 additional block. Pretty simple.

  3. May 2020
    1. A real-world example of this would be an e-commerce site that allows users to “hold” items in their cart while they’re using the site or for the duration of a session. In this scenario, the technical cookies are both necessary for the functioning of the purchasing service and are explicitly requested by the user when they indicate that they would like to add the item to the cart. Do note, however, that these session-based technical cookies are not tracking cookies.

      I'm not sure I agree with this:

      [the technical cookies] are explicitly requested by the user when they indicate that they would like to add the item to the cart.

      The only thing they requested was that the item be held in a cart for them. They didn't explicitly request that cookies be used to store information about items in the cart. They most likely don't understand all of the options for how to store data like this, and certainly wouldn't know or expect specifically that cookies be used for this.

      In fact, localStorage could be used instead. If it's a single-page app, then even that would be necessary; it could all be kept in page-local variables until they checked out (all on the same page); such that reloading the page would cause the cart data held in those variables to be lost.

    1. Motion Picture Association of America Chairman Chris Dodd stated that the coordinated shutdown was "an abuse of power given the freedoms these companies enjoy in the marketplace today."

      It's not an abuse of power. It's free speech. It's protesting against an awful proposed law.

  4. Mar 2020
    1. Instead of re-opening Ruby classes like that (I get involuntary twitches), for our little exercise we are going to invent another name

      IMHO, re-opening classes is okay. Certainly better than duplicating an entire core Ruby class and giving it a silly, less-meaningful name. (Though I'm not sure he actually intended people to use Lax instead of Lazy. I think he was just showing how easy it is to implement Lazy from scratch in Ruby.)