6 Matching Annotations
  1. Jun 2023
    1. If we hand most, if not all responsibility for that exploration to the relatively small number of people who talk at conferences, or have popular blogs, or who tweet a lot, or who maintain these very popular projects and frameworks, then that’s only a very limited perspective compared to the enormous size of the Ruby community.
  2. Sep 2021
  3. May 2021
  4. Nov 2020
    1. Prettier’s printWidth option does not work the same way. It is not the hard upper allowed line length limit. It is a way to say to Prettier roughly how long you’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified printWidth. Remember, computers are dumb. You need to explicitly tell them what to do, while humans can make their own (implicit) judgements, for example on when to break a line. In other words, don’t try to use printWidth as if it was ESLint’s max-len – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.
  5. Sep 2020
    1. Actually just returning the loginDaoCall works fine. I dont really get what's different as it is the looked like it was the same instance, but probably not.

      So the posted answer wasn't necessary/correct? Which part of the answer was incorrect/unneeded?

      I wish this OP comment included the full version of code that worked.

      I don't understand this OP comment. Wasn't OP already returning loginDaoCall? So maybe the only thing they could mean is that they just needed to change it to return loginDaoCall.then(...) instead...

      That would be consistent with what the answer said:

      the promise returned by the further .then() does also get rejected and was not handled.

      So I guess the unnecessary part of the answer was adding the return true/false...

  6. 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.