21 Matching Annotations
  1. Sep 2020
  2. Aug 2020
    1. As a web designer, I hate that "log in" creates a visual space between the words. If you line up "Log In Register" - is that three links or two? This creates a Gestalt problem, meaning you have to really fiddle with spacing to get the word groupings right, without using pipe characters.

      Sure, you can try to solve that problem by using a one-word alternative for any multi-word phrase, but that's not always possible: there isn't always a single word that can be used for every possible phrase you may have.

      Adjusting the letter-spacing and margin between items in your list isn't that hard and would be better in the long run since it gives you a scalable, general solution.

      "Log in" is the only correct way to spell the verb, and the only way to be consistent with 1000s of other phrasal verbs that are spelled with a space in them.

      We don't need nor want an exception to the general rule just for "login" just because so many people have made that mistake.

  3. Jul 2020
    1. JSON parsing is always pain in ass. If the input is not as expected it throws an error and crashes what you are doing. You can use the following tiny function to safely parse your input. It always turns an object even if the input is not valid or is already an object which is better for most cases.

      It would be nicer if the parse method provided an option to do it safely and always fall back to returning an object instead of raising exception if it couldn't parse the input.

  4. May 2020
  5. developer.mozilla.org developer.mozilla.org
    1. in the absence of an immediate need, it is simpler to leave out error handling until a final .catch() statement.
    2. Handling a rejected promise too early has consequences further down the promise chain.   Sometimes there is no choice, because an error must be handled immediately.
  6. Apr 2020
  7. Mar 2020
    1. To be just a bit polemic, your first instinct was not to do that. And you probably wouldn't think of that in your unit tests either (the holy grail of dynamic langs). So someday it would blow up at runtime, and THEN you'd add that safeguard.
    2. I want to raise errors with more context
    3. As many would guess: ... catch StandardError => e raise $! ... raises the same error referenced by $!, the same as simply calling: ... catch StandardError => e raise ... but probably not for the reasons one might think. In this case, the call to raise is NOT just raising the object in $!...it raises the result of $!.exception(nil), which in this case happens to be $!.
    1. It is recommended that a library should have one subclass of StandardError or RuntimeError and have specific exception types inherit from it. This allows the user to rescue a generic exception type to catch all exceptions the library may raise even if future versions of the library add new exception subclasses.
    1. The pattern below has become exceptionally useful for me (pun intended). It's clean, can be easily modularized, and the errors are expressive. Within my class I define new errors that inherit from StandardError, and I raise them with messages (for example, the object associated with the error).
  8. Dec 2019
  9. Mar 2019
    1. Você consegue visualizar a saúde da sua aplicação?

      Ainda que aqui os tópicos da certificação não cubram exatamente esse assunto, monitorar a saúde de um sistema e suas aplicações é missão do profissional DevOps. Atente para os tópicos:

      701 Software Engineering 701.1 Modern Software Development (weight: 6)

      e

      705.2 Log Management and Analysis (weight: 4)

  10. May 2018
    1. hi there we have came up with the newly launched Procedural Query in PL sql with Oracle 12 c so please check this out For detailed Description on the Pl Sql from the scratch to advance level:-

      https://www.youtube.com/watch?v=phvcwekT9ZA