We have code that creates one master sequence then replaces every sequence in the testdb with that master sequence, so all tables pull from the same sequence. That way you can never accidentally swap two id's in an api response and have the tests pass because you coincidentally both had id 5 or whatever. We can run the tests either way (with sequences swapped out or not). We almost always leave the master sequence in place because the id-swap bug is very common and the alternative (bug caused by two id's being the same on different tables) basically never comes up.

I've experimented (see below) with TEMPLATE dbs and such in Python (with inspiration from this library). IMHO the "around 100ms" mark is pretty slow for a big test suite. Interestingly, pg_restore is only twice as slow as TEMPLATEs.

https://github.com/leontrolski/postgresql-testing

I'd be interested about how all this compares to snapshotting the postrgres dir with ZFS and restoring to that, but don't have a Linux box to hand.

As that comment mentions:

> 5 years ago [...] Python packaging was a big mess.

> Today [...] I think Python's packaging story has never been stronger.

Poetry, & later Uv, are essential & invaluable milestones in that revolutionary story; Pip is terrible software & should be left in the past.

The comparison to other programs is missing the point of why pip is terrible. For that matter, last I checked Poetry relied on either vendored pip or something very much like it to do the actual package installation.

If you like workflows dictated by all-in-one tools, go for it. Don't force it on me. Some of us still see great value in the Unix philosophy.

The real problem is that pip doesn't even do a good job of its "one thing" (the actual package installation). It barely understands caching, has insecure and confusing default behaviours stemming from nigh-unfixable legacy issues, doesn't know how to inspect the installation environment properly (therefore relying on ugly hacks to install cross-environment at all), vendors a bunch of stuff it barely uses and often doesn't really need, and is overall horribly architected.

You've summarised many of pip's internally problems well - there's also the lack of any attempt at proper manifest management. This is partially an ecosystem problem (pre-PEP518), but the tools inform the specs as much as the specs inform the tools.

I think there's also a reasonable argument to be made that uv only does one thing, & that the big problems in this space before was that python required using 3 tools to awkwardly collaborate to get one thing done. That one thing is dependency management: pip to pull them, venv to load them, pyenv to pull & load one of them (the interpreter).

The other thing I don't like is having tens of megs of opaque compiled binary (that doesn't provide a useful library) when properly designed Python would perform more than acceptably for common use cases (tons of this is I/O-bound; a proper cache lets you just recursively hardlink a directory tree instead of unpacking an archive file; the bytecode compilation is implemented in C and could be parallelized with `multiprocess` as long as you don't require binary-level reproducibility for Python bytecode; etc.)

https://leontrolski.github.io/interpreter.html

I'm trying to compress recipes into little schematics https://leontrolski.github.io/recipes.html

For a while I expected there could be a good return on a good implementation of this, but now as soon as a strong interface itself is created it seems easy to copy.

I imagine in domains you are skilled at you'd also prefer high level instructions than a step-by-step tutorial.

I agree that doesn't help the beginner, or someone who doesn't cook regularly, or someone cooking something new and I think most recipe writers are just following the established structure without thinking about what they and others really need.

— Carl Sagan

FWIW though most recipes are basically ~10 steps long so a simple list suffice.

Still it could be an interesting experiment as I imagine that precisely recipes that are less sequential are (on average, with as challenging steps, e.g. excluding making caramel which has a high chance of burning) perceived as more complex.

Your tables remind me of recipes in Modernist Cuisine. They all have ingredients grouped by the procedures together with weight, sometimes volume, and ratio.

Example: https://modernistcuisine.com/wp-content/uploads/2013/01/Mac-...

And I don't know why, but "Beans (green)" is really tickling my funny bone.

This would help coordinate two cooks to make prepping more independent.

I’m trying to figure out if an landscape Ipad, with interactive elements for extra details if needed, would be a good UI for this.

-

Edit: Showed it to my non-Engineer wife and she said ”this is horrible” after staring at it for 10 seconds. Maybe not for everyone…

"peeling carrot" (process) consumes "washed carrot" (object)

"peeling carrot" (process) yields "peeled carrot" (object)

"peeling carrot" (process) yields "carrot peel" (object)

"finely dicing carrot" (process) consumes "peeled carrot" (object)

"finely dicing carrot" (process) yields "finely diced carrot" (object)

"prepare mirepoix" (process) consumes "finely diced carrot" (object)

"prepare mirepoix" (process) consumes "finely diced celery" (object)

"prepare mirepoix" (process) consumes "finely diced onion" (object)

"prepare mirepoix" (process) consumes "butter" (object)

"prepare mirepoix" (process) yields "mirepoix" (object)

The advantage of OPM is alignment of graphical and textual representations.

The downside of such approach is you soon discover how many millions of objects may exist in recipes--unwashed carrot, washed carrot, orange carrot, purple carrot, yellow carrot, white carrot, peeled carrot, coarsely diced carrot, finely diced carrot, julienned carrot... and purple julienned carrot vs. yellow julienned carrot. And that's just basic preparation complexity well before any contemplation of cooking or plating up elements. To go further you then discover a lack of useful labels such as "mirepoix" or "soffrito", if for example, you wanted to substitute sweet potato in place of carrot in the recipe.

Then there is SysML 2[2] which is kind of like OPM if you ever wanted to write a recipe in 35,000 lines of code, including possibly all the complexity of mathematical modelling of the Maillard reaction for purple carrots vs. yellow carrots using either extra virgin olive oil or butter. Probably best suited for the largest food processing companies such as Nestle, Unilever, Modelez, etc and even then, inherent complexity of their food products rarely would reach the level of a fine dining dish prepared by a chef.

[1] https://en.wikipedia.org/wiki/Object_Process_Methodology

[2] https://www.omg.org/spec/SysML/2.0/Language/PDF

It's similar concept to OPM with some modelling basics already built on top for player movement throughout a world, player interaction with objects (looking at, lifting, moving), and many other primitives needed to write interactive fiction. And relevant to this thread, Inform 7 of course has modelling basics for a player eating food, drinking potions, etc.

[1] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la...

[2] https://ganelson.github.io/inform-website/book/RB_9_1.html

Also useful to watch Dr. Stone anime.

This is inspiring. Cooking is this sort of an activity that is simple enough to not be overwhelming but also complex enough to be very interesting.

Both in practice and in modelling :-)

Great job!

    cat = Cat(age=3)
    l = [1, [2, cat], 4]
    alt l[1][1].age.=9

    [1, [2, Cat(age=9)], 4]

    l = [1, [2, cat], 4]

    {-# LANGUAGE TemplateHaskell #-}
    
    import Control.Lens
    
    data Cat = Cat { _age :: Int }
      deriving Show
    makeLenses ''Cat
    
    data Item
      = I Int
      | L [Item]
      | C Cat
      deriving Show
    
    makePrisms ''Item
    
    cat :: Cat
    cat = Cat 3
    
    l :: [Item]
    l = [I 1, L [I 2, C cat], I 4]
    
    l' :: [Item]
    l' = set (ix 1 . _L . ix 1 . _C . age) 9 l
    

    ghci> l'
    [I 1,L [I 2,C (Cat {_age = 9})],I 4]

  l[1][1].age:9
  # (1,(2,{"age":9}),4)

  {"age":9}

  l_inner = l[1][1]
  l_inner.age:9

    l_inner:l[1][1]
    # {"age":3}
    l_inner.age:9
    # {"age":9}
    l_inner
    # {"age":9}
    l
    # (1,(2,{"age":3}),4)

    (1,(list 2,list ().age:5),4)[1][1].age:99
    # (1,(2,{"age":99}),4)

Currently it feels a bit like everyone is talking about what new editor they're using. I don't care about that type of developer tooling very much. AI isn't coming up with some exciting new database, type system, etc etc.

"Look at how I'm able to web dev x% faster" because of LLMs is boring.