20 Matching Annotations
  1. Mar 2021
    1. TRAILBLAZER-STORY will follow as it turned out to be inevitable for setting up application state for tests. Instead of fumbling around with factories and traits in your tests, you “tell a story” about what to create in which order, easily customizable, and all written using activities.
    1. It is absolutely advisable to use factory in combination with let. let(:song) { factory( Song::Create, { title: "Timebomb", band: "Rancid" } ) }
    2. You should always use operations as factories in tests.
    3. There are several helpers to deal with operation tests and operations used as factories.
  2. Feb 2021
    1. However, sometimes actions can't be rolled back and it is unfortunately unavoidable. For example, consider when we send emails during the call to process. If we send before saving a record and that record fails to save what do we do? We can't unsend that email.
    2. I typically save everything I can first, and then call the side-effects afterwards. If the side-effects fail I can handle them elsewhere and retry when necessary.
    1. Because of the way the CSS “or” operator works, I wouldn’t be able to mix the retina conditions with other expressions since a (b or c) would be compiled into (a or b) c and not a b or a c.
  3. Nov 2020
    1. Important caveat: in the combined expression, if the middle command has a non-zero exit status, then both the middle and the rightmost command end up getting executed.

      I don't think that is surprising, is it? Since && and || have the same order of precedence. So I think this is more of a clarification than a caveat.

      I think this is just because:

      a && b || c is equivalent to: (a && b) || c (so of course c gets evaluated if (a && b) is false (that if either a or b is false).

      I think they just mean, in this case:

      bedmap && mv || fail
      

      if mv fails, then fail still gets executed.

      Easier to see with a simpler example:

      ⟫ true && false || echo 'fail'
      fail
      
      ⟫ false && true || echo 'fail'
      fail
      

      Better example/explanation here: https://hyp.is/-foxmCVXEeuhnLM-le_R4w/mywiki.wooledge.org/BashPitfalls

      The caveat/mistake here is if you treat it / think that it is equivalent to if a then b else c. That is not the case if b has any chance of failing.

    1. What's not obvious here is how the quotes nest. A C programmer reading this would expect the first and second double-quotes to be grouped together; and then the third and fourth. But that's not the case in Bash. Bash treats the double-quotes inside the command substitution as one pair, and the double-quotes outside the substitution as another pair.

      subshell > quotes

  4. Sep 2020
    1. By default, npx will check whether <command> exists in $PATH, or in the local project binaries, and execute that. Calling npx <command> when <command> isn't already in your $PATH will automatically install a package with that name from the NPM registry for you, and invoke it. When it's done, the installed package won’t be anywhere in your globals, so you won’t have to worry about pollution in the long-term. You can prevent this behaviour by providing --no-install option.
  5. May 2020
    1. At GitLab, we use "ops" to mean operations - any component of the software delivery value stream after a developer commits code.
    1. For convenience, conventions have been developed about the precedence of the logical operators, to avoid the need to write parentheses in some cases. These rules are similar to the order of operations in arithmetic. A common convention is:
    1. Peer must maintain a staffed 24x7 operational center, with knowledge or direct escalation privileges to knowledgable personal to resolve any issues efficiently
  6. Mar 2019