18 Matching Annotations
  1. Last 7 days
    1. As a result, there is a natural tendency for people to prefer private channels of communication. The intentions are good, as people are looking to reduce noise for others, but this can lead to the same problems as described elsewhere on this page
    2. Avoid Private Messages When using Slack for work-related purposes, please avoid private messages.
    1. Use the simplest and most boring solution for a problem, and remember that “boring” should not be conflated with “bad” or “technical debt.” The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.
  2. Dec 2019
    1. It's confusing whether one should put things in gemspec development_dependencies or in Gemfile or in both.

      Duplication is bad since the lists could get out of sync. And the gemspec's development_dependencies should be a complete list. Therefore, my opinion is that that should be the canonical list and therefore the only list.

      Actually, what good is gemspec's development_dependencies? A contributor should clone the repo, run bundle, and get the dev dependencies that way. Therefore development_dependencies is unneeded and you should only list them in Gemfile.

      It is simpler to just use Gemfile, since it is a more familiar format. You can copy and paste content into it. For example, if you extract a gem out of an app, you may wan to copy/move some gems from app's Gemfile into new gem's Gemfile. It also generates a Gemfile.lock (which you shouldn't add to git).

  3. Nov 2019
    1. It’s not enough to check the stuff that is suspicious: if you apply your investigations selectively, you’ve already lost the battle.

      This made me reflection on biases. If our research methodology is biased from the very beginning, then everything that comes after will also be biased.

    1. The chosen approach pushes a lot of complexity out of the core. As a result it might take more code to achieve certain functionalities. This is the price of flexibility. And that's the primary design goal of Reactabular.
    1. it doesn't even render in-file components. For example, the <Fade /> component we have above is an implementation detail of the <HiddenMessage /> component, but because we're shallow rendering <Fade /> isn't rendered so changes to that component could break our application but not our test. That's a major issue in my mind and is evidence to me that we're testing implementation details.
    2. The reason this kind of test fails those considerations is because it's testing irrelevant implementation details. The user doesn't care one bit what things are called. In fact, that test doesn't even verify that the message is hidden properly when the show state is false or shown when the show state is true. So not only does the test not do a great job keeping us safe from breakages, it's also flakey and doesn't actually test the reason the component exists in the first place.
    3. I could rename toggle to handleButtonClick (and update the corresponding onClick reference). My test breaks despite this being a refactor.
    4. I could mistakenly set onClick of the button to this.tgogle instead of this.toggle. My test continues to work, but my component is broken.
    5. Will this test break when there's a mistake that would break the component in production?Will this test continue to work when there's a fully backward compatible refactor of the component?
    1. Why is testing implementation details bad?There are two distinct reasons that it's important to avoid testing implementation details. Tests which test implementation details:Can break when you refactor application code. False negativesMay not fail when you break application code. False positives
    1. But far too often, I see tests which are testing implementation details (read this before continuing if you haven't already). When you do this, you introduce a third user. The developer user and the end user are really all that matters for this component. So long as it serves those two, then it has a reason to exist. And when you're maintaining the component you need to keep those two users in mind to make sure that if you break the contract with them, you do something to handle that change.But as soon as you start testing things which your developer user and end user don't know or care about (implementation details), you add a third testing user, you're now having to keep that third user in your head and make sure you account for changes that affect the testing user as well.
    1. You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.
  4. Sep 2013
    1. It may be said that every individual man and all men in common aim at a certain end which determines what they choose and what they avoid.

      What is left out is as important to shaping the argument and what is chosen.