179 Matching Annotations
  1. Apr 2025
    1. In simple words, the database client and the server prove and convince each other that they know the password without exchanging the password or the password hash. Yes, it is possible by doing a Salted Challenge and Responses, SCRAM-SHA-256, as specified by RFC 7677. This way of storing, communicating, and verifying passwords makes it very hard to break a password.

      Interesting!

  2. Mar 2025
  3. Oct 2024
  4. Sep 2024
  5. Jun 2024
  6. May 2024
  7. Jan 2024
  8. Dec 2023
    1. && nil

      first sighting: I don't think I've seen someone write exactly && nil before.

      Apparently to avoid having the return value from errors.add — which should be done solely for its side effect, not to get a return value -- inadvertently being used as a return value for user. It wouldn't make sense to return from user. That should only return a User or nil. And more statically typed languages would allow that to be expressed/enforced from type annotations alone, which would have caught the mistake of returning errors.add if someone had accidentally attempted to return that.

      Having user (and therefore call) return nil is key to the unless @current_user working.

    1. A personalized button gives users a quick indication of the session status, both on Google's side and on your website, before they click the button. This is especially helpful to end users who visit your website only occasionally. They may forget whether an account has been created or not, and in which way. A personalized button reminds them that Sign In With Google has been used before. Thus, it helps to prevent unnecessary duplicate account creation on your website.

      first sighting: sign-in: problem: forgetting whether an account has been created or not, and in which way

  9. Nov 2023
  10. Sep 2023
  11. Jul 2023
  12. Jun 2023
  13. Apr 2023
  14. Mar 2023
  15. Jan 2023
  16. Nov 2022
  17. Oct 2022
  18. Sep 2022
  19. Aug 2022
  20. Jun 2022
  21. Apr 2022
  22. Mar 2022
  23. Jan 2022
  24. Nov 2021
  25. Oct 2021
  26. Sep 2021
    1. first sighting: A Forward link at bottom of an e-mail, which takes you here, which has a link to a preview (which is basically a web version of the e-mail that was sent).

      In some ways, this seems preferable over forwarding the original e-mail that you received using your e-mail client's forward feature. In particular:

      • It doesn't inadvertently include your personalized unsubscribe link, allowing the forwarded-to person to maliciously unsubscribe you without your consent.
  27. Aug 2021
  28. Jul 2021
  29. Jun 2021
  30. May 2021
  31. Apr 2021
  32. Mar 2021
    1. data = {}.extend XKeys::Auto # Vs ::Hash, uses arrays for int keys data[:users, 0, :name] # nil data[:users, 0, :name, :raise => true] # KeyError data[:users, :[], :name] = 'Matz' # :[] is next index, 0 in this case # {:users=>[{:name=>"Matz"}]} pick = [:users, 0, :name] data[*pick] # Matz data[:users, 0, :accesses, :else => 0] += 1 # {:users=>[{:name=>"Matz", :accesses=>1}]}
    1. My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

      first sighting: That <template>/<slot> is part of HTML standard and the reason Svelte uses similar/same syntax is probably because it was trying to make it match / based on that syntax (as they did with other areas of the syntax, some of it even JS/JSX-like, but more leaning towards HTML-like) so that it's familiar and consistent across platforms.

  33. Feb 2021
    1. URI::MailTo::EMAIL_REGEXP

      First time I've seen someone create a validator by simply matching against URI::MailTo::EMAIL_REGEXP from std lib. More often you see people copying and pasting some really long regex that they don't understand and is probably not loose enough. It's much better, though, to simply reuse a standard one from a library — by reference, rather than copying and pasting!!

  34. Jan 2021
  35. Dec 2020
  36. Nov 2020
  37. Oct 2020
    1. first sighting: use of superscripts like this

      I like it. Nice and concise and understandable.

      • s¹  critical
      • s²  important
      • s³  nice to have
      • s⁴  low
      • s⁵  inconvenient

      But in other cases, the abbreviation is quite unclear and ambiguity:

      Like, what does "pr" mean in these cases?

      priority? Doubt it.

      • pr¹  chore
      • pr²  docs
      • pr³  feature
      • pr⁴  fix
      • pr⁵  performance
      • pr⁶  refactor
      • pr⁷  style

      Pull Request? Doubt it. But maybe?


      For axes that are quantifiable, like severity, using a number makes sense. But what benefit is there in including a number in these (platform?) labels?:

      • p¹ ⋅ browser
      • p² ⋅ linux
      • p³ ⋅ mac
      • p⁴ ⋅ windows

      I think this would have been better and clearer (in that fewer people would be like huh? and wonder what it means):

      • platform: browser
      • platform: linux
      • platform: mac
      • platform: windows
  38. Sep 2020
  39. Aug 2020
  40. Jul 2020
  41. May 2020
  42. Apr 2020
  43. Mar 2020
    1. On top of standard Markdown blockquotes, which require prepending > to quoted lines, GFM supports multiline blockquotes fenced by >>>:

      First sighting of this >>>. I like it! It's always a pain to paste in a quote and then have to manually prefix every line with >, esp. if there are many lines.

      I also like that it very nicely parallels the multilne code block delimeter syntax.

  44. Feb 2020
  45. Jan 2020
  46. Dec 2019
  47. Nov 2019
  48. Oct 2019
  49. Sep 2019
  50. Aug 2019