25 Matching Annotations
  1. Jul 2022
    1. The major benefit of foreign keys is that they guarantee referential integrity. For example, say you have customers in one table that may refer to a number of invoices in another. Without foreign keys, you could delete a customer, but forget to remove its invoices, thereby leaving a bunch of orphaned invoices that reference an customer that’s gone.

      Note that GH doesn't use FK (at least back in 2016) https://github.com/github/gh-ost/issues/331#issuecomment-266027731 due to: * MySQL doesn't support it on partitioned tables * Performance impact. * FKs don't work well with online schema migrations

      From Postgres has foreign keys to be fully compatible with partitioned tables since 12. But still it's not that commonly used for larger DBs.

    2. If an operator ever queries the database directly they’re even more likely to forget deleted_at because normally the ORM does the work for them.

      This happens relatively often, especially for 1) engineers that run SQL queries directly against the DB for analysis or triaging production issues, and 2) data scientists that do not use the same programming language as the enginners

    1. If you are starting without previous knowledge about any framework, you're gonna have a bad time. Just go with what you know if there are no real reasons to choose something else.

      programming truths

  2. Jan 2022
    1. When a product manager trusts that the engineers on the team have the interest of the product at heart, they also trust the engineer’s judgment when adding technical tasks to the backlog and prioritizing them. This enables the balanced mix of feature and technical work that we’re aiming for.

      Why is it so common for engineering teams to be mistrusted by other parts of the business?

      Part of that is definitely on engineers: chasing the new shiny, over-engineering, etc.

      That seems unlikely to account for all of it, though.

  3. Aug 2021
    1. An interesting directory of personal blogs on software and security.

      While it aggregates from various sources and allows people to submit directly to it, it also calculates a quality score/metric by using a total number of Hacker News points earned by the raw URL

      Apparently uses a query like: https://news.ycombinator.com/from?site=example.com to view all posts from HN.

  4. Apr 2021
    1. Coordination: More environments require more coordination. Teams need to track which feature is deployed to which environment. Bugs need to be associated with environments. Every environment represents a particular ‘state’ of the codebase, and this has to be tracked somewhere to make sure that customers & stakeholders are seeing the right things;

      Try to remember the last time you heard one of the following phrases:

      • "Oh, I deployed it in the X environment"
      • "It was working in the stage environment"
  5. Mar 2021
    1. Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).
  6. Feb 2021
    1. “Functional programming language” is not a clearly defined term. From the various properties that are typically associated with functional programming I only want to focus on one: “Immutability” and referential transparency.

      I mean not clearly defined seems wrong, there are common accepted characteristics that make a language functional.

  7. Nov 2020
  8. Oct 2020
    1. One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.
  9. Jun 2020
    1. An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.
    2. A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.
    3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
    4. patterns are considered to be a way of putting building blocks into context
    5. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others"
  10. Feb 2019
    1. INVEST

      According to this checklist, a User Story should be:

      Indepedent (of all others)

      Negociable (not a specific contract for features)

      Valuable (or vertical)

      Estimable (to a good approximation)

      Small (so as to fit within an iteration)

      Testable (in principle, even if there isn't a test for it yet)

      Source(s):

      1. Glossary: INVEST - Agile Alliance
      2. INVEST at XP 1-2-3 by Bill Wake
  11. Jan 2017
  12. Nov 2016
  13. May 2016
    1. As such, scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly, to respond to emerging requirements and to adapt to evolving technologies and changes in market conditions.

      算法开发工作就有这种特点

  14. Apr 2016
    1. the study of innovation shows that everything hinges on the hard work of taking a promising idea and making it work — technically, legally, financially, culturally, ecologically. Constraints are great enablers of innovation.
    2. But there’s a downside to the hackathon hype, and our research on designing workplace projects for innovation and learning reveals why. Innovation is usually a lurching journey of discovery and problem solving. Innovation is an iterative, often slow-moving process that requires patience and discipline. Hackathons, with their feverish pace, lack of parameters and winner-take-all culture, discourage this process. We could find few examples of hackathons that have directly led to market success.
    3. what if projects were designed to combine a hacking mindset with rigorous examination of the data and experience they glean? This would reward smart failures that reveal new insights and equip leaders with the information needed to rescale, pivot or axe their projects.

      Sounds somewhat like agile devlopment.

  15. Feb 2016
    1. In summary, teams which are "fairer", in two senses, tend to be more effective:

      • Those where members speak and contribute in roughly the same proportion (albeit possibly in quite different ways)
      • Those where members have an above-average sensitivity to what others are thinking and feeling