14 Matching Annotations
  1. Dec 2021
    1. At last a git workflow site that makes sense for the 21st century!

    1. it is best to limit the number and scope of branches in your repository. Most implementations suggest that developers commit directly to the main branch or merge changes from their local branches in at least once a day.

      Actually this is the "agile" motto - release early, so no long feature-branches.

    2. discovering failures as early as possible is important to minimize the resources devoted to problematic builds. To achieve this, prioritize and run your fastest tests first. Save complex, long-running tests until after you’ve validated the build with smaller, quick-running tests.

      Build articulated jobs to identify early low-hanging spoiled fruits.

    3. When making these significant decisions, make sure you understand and document the trade-offs you are making.

      Leave a coherent trail about the decisions behind the CI machinery.

    1. So while running “all tests” in all builds would be ideal, reality dictates that we prioritize testing and run certain types of tests in certain stages of the dev/test cycle. There are a few ways to achieve prioritized testing:Having one automated build process that runs only the basic set of tests, and trigger additional tests manually.Having several build configurations: one for a basic set of tests, one including some more tests, up to the full production build which includes all tests. These sets of tests create numerous builds that are using almost the same artifacts, creating duplication and room for error. Not to mention maintenance-hell. Also, this approach limits flexibility to some extent. For example, what if a developer wants to execute a specific automated UI test to see if a change broke the interface? That will have to wait for later in the dev/test cycle.

      Describe the need for flexibility to select one out of multiple build/test configurations.

      Not really providing practical advises.

  2. Nov 2021
    1. Here are the impressive detailed statistics from their repository as of 2015, for which more recent data is challenging to obtain.

      Interesting statistics (mostly inside diagrams) from 2015 on Google's big [[monorepo]] (which is NOT git).

  3. Jul 2021
    1. ‘Programs are meant to be read by humans and only incidentally for computers to execute.’

      Donald Knuth's famous insight that we use code to communicate to other humans, first.

    1. Give the same task to a junior developer, and they might code it faster because they do not think twice while reading a requirement. Their approach is more like converting English to Java (or whatever programming language they use).

      Indeed, not only younger programmers are thinking faster, they have much less mental burden when programming.

  4. Jun 2021
  5. Mar 2021
    1. Interesting journal on issues like:

      • Source Code Analysis and Manipulation
      • Software Engineering for Trustworthy Cyber-Physical Systems
      • Software and Systems Reuse in the Big Data Era
      • Machine Learning Techniques for Software Quality Evaluation
    1. If a Thrive employee sends an e-mail to a colleague who is on vacation, the sender receives a note that the colleague is away and the message is automatically deleted.

      Completely delete received messages during vacation, while extreme, does work!

    2. oving past the paradigm of associating e-mail addresses with individuals. When an address is instead assigned to a specific client, or to a specific type of request, and monitored by multiple different employees, it can go a long way to relieving the deeply-ingrained anxiety that we are ignoring those who need us.

      Multiple assignees in a project relieve pressure on individuals!

  6. Feb 2021