7 Matching Annotations
  1. Last 7 days
    1. Every commit should be runnable, that is we should be able to git checkout any commit and get a functional code base. This means no “WIP” commits or commit chains that only restore functionality at the end. This is important so that we can revert or rollback to any commit if things go sideways.

      I feel this is somewhat impractical, I may loose to much time trying to build the perfect history when I can make small PRs and stash commits (from the PR) into one

    1. First, try to avoid making career decisions while in a bad mental place. Take a two week vacation. Get out of your house a few times if you’ve been living and working at home for the last eighteen months. Try to restart something you loved but have stopped due to pandemic concerns. You don’t need to find a sustainable long-term solution, just enough of a break to find some space to reflect before making life-altering changes.The second piece of advice I offer is that great careers are often presented as linear growth stories, but if you dig deeply enough they often have a number of lulls embedded inside them. When you’re high energy, these lulls are opportunities to learn and accelerate your trajectory. When you’re low energy, they are a ripe opportunity to rest. It’s easy to forget about these pockets in retrospect, and I recently realized I’ve gotten so practiced at narrating my own career in a particular way that I’ve forgotten my own lulls that have made the faster periods sustainable.
  2. Jul 2021
  3. Jun 2021
    1. Worse still is the issue of “service” layers requiring you to basically build your own ORM. To really do a backend-agnostic service layer on top of the Django ORM, you need to replace or abstract away some of its most fundamental and convenient abstractions. For example, most of the commonly-used ORM query methods return either instances of your model classes, or instances of Django’s QuerySet class (which is a kind of chained-API results wrapper around a query). In order to avoid tightly coupling to the structure and API of those Django-specific objects, your service layer needs to translate them into something else — likely generic iterables to replace QuerySet, and some type of “business object” instance to replace model-class instances. Which is a non-trivial amount of work even in patterns like Data Mapper that are designed for this, and even more difficult to do in an Active Record ORM that isn’t.

      I see what this guy means and he has a point. However, I don't think about reimplementing these things when talking about services on Django. I want a centralized place to store business logic (not glue queries) and avoid multiple developers writing the same query multiple times in multiple places. The name "service" here sucks.

    2. A second problem is that when you decide to go the “service” route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use “frameworks” and never will: what they actually mean, whether they realize it or not, is “we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is”. And adopting the service approach essentially means that, whatever your business was previously, now your business is that plus developing and maintaining something close to your own private ORM.

      I don't think these two things are even close to be the same thing. Django's ORM is not replaced by services, from what I know services are the ORM with the difference that they are concentrated in a module.

    1. This isn't about writing boilerplate setter properties for each field in the model, but rather about writing methods that encapsulate the point of interaction with the database layer. View code can still inspect any field on the model and perform logic based on that, but it should not modify that data directly. We're ensuring that there is a layer at which we can enforce application-level integrity constraints that exist on top of the integrity constraints that the database provides for us.

      Addresses the issue raise on this tweet. We are not writing getters and setters out of obligation or convention.

  4. May 2021
    1. That’s how blogging is complimentary to other forms of more serious work: when you’ve done enough of it, you can get entire essays, speeches, stories, novels, spontaneously appearing in a state of near-completeness, ready to be written.

      This sounds a lot like the Zettelkasten method. If writing is your default mode, writing complex pieces is just making concrete an organization of things that were already formalized in your mind