I find a bit infuriating that the official docs for pattern matching are the PEPs. Maybe that will change at the next pattern matching lang change, and I think PEPs and language docs each have their separate purposes, but on the other hand it's nice that the PEP is good (and current) enough as usage documentation.

What kind of Python information were you having trouble finding?

I do have this problem as well, I've just started a job with Ruby and it took too many searches until I could find the official docs for some kind of syntax.

For Python I feel it's easy to find stdlib docs, but can be hard to find some specific things about the language itself in the official docs - sometimes it's too technical and I wish there was a more pragmatic middle ground.

For ruby, you need a good book, and be good at reading references docs.

The first thing I bought at my last job was the Oreilly Ruby book. I can't remember what it's called.

fucking... all of it

the other day, the example that made this top-of-mind, was looking up the python string formatting options. Google found https://docs.python.org/3/library/string.html which is a giant wall of text that I should not have to read all of just to find a reference. Plus it has the fucking formal grammar--who cares!? I just want a lookup table. But this is my experience every time I try to do anything. I always end up going back to https://learnxinyminutes.com/python/ because at least it just lists all the information I want! Of course if I programmed Python every day, which I haven't in a while, then a lot of this would be preloaded in my mind... but seriously, just make a damn reference, it's not hard. Python seems to constantly conflate "full technical specification" with "quick reference materials". Which, fine, if time and energy were no limitations, would be equivalent. But sometimes you just want to know the answer to a simple question in less than 30 minutes.

Out of curiosity, how does `--user` fall in your use case? It got me confused because this flag makes it install to a central location within the user home directory and not to a virtual environment.

I've recently used Hurl to create a test suite for migrating a complex Nginx configuration to Caddy and it was a great choice!

I ran Caddy replacing the upstreams with mockbin-like services (don't remember which one I used) so it would respond with information about the request made by the proxy, so Hurl could make assertions on that.

Considering Brazil and the Spanish-speaking people whom I've worked with, it's common for English coding to be the norm for the company/project, but many people are far from being proficient in English, so we end up with funny names that are often confusing or nonsense - I've seen an "evaluation service" that is actually a "rating service" (both could translate to the same in Portuguese). They often translate to false cognates too.

There are some business concepts that are very unique to a place (country-specific or even company-specific) with no precise translation to the English-speaking world, and so I sometimes prefer to keep them in their native language.

Yes, this is the counterpoint I'd make to "resist the urge to make every corner of the codebase nicer than the rest of it": in an inconsistent codebase, maybe we should prioritize making it consistent where possible, and reducing unnecessary duplication is one way to reduce future change costs.

I think the analogy is clear when I think of it as: - Orchestration brings the idea of a conductor, who is the main reference for "what should we do" among orchestra players. - Choreography brings the idea of dancers in sync without the need of a central conductor.

> Choreography brings the idea of dancers in sync without the need of a central conductor.

Try that and let me know how it works.

In reality, the dancers are of course synced by the music, dependent on the same conductor as the orchestra.

And on top of that, orchestration isn't the conductor's job. It's the composer's (or arranger's) job, putting it exactly parallel to choreography. The orchestrator, like the choreographer, determines who does what and when they do it, and he does it in advance. Most typically, years or centuries in advance. The conductor determines how fast the clock runs.

Interesting. A counter example, WWE (wrestling) is choreographed. The wrestlers react to the cues of the other wrestlers. It's not necessarily based on time or music, but instead a pre-agreed sequence.

I think the catch is that not all cues need to be time based and that is the distinction. In orchestration, there is one source for cues - the orchestrator.

The difference I think speaks to orchestration where the players get their cues from one source, while choreography has different source(s) for cues (time/tempo perhaps being one of them)

> In orchestration, there is one source for cues - the orchestrator.

Just to be clear, everyone's talking about the conductor, who keeps time for the orchestra, but conductors don't do orchestration. The orchestrator is the person who wrote the score.

Good point, for the analogy, I should have written conductor instead of orchestrator. The point remains though that the difference is in the source of synchronization.

Nice, will give it a try!

There is a similar tool that I've been using for years: https://github.com/mthenw/frontail/

I feel that what the author has described is the very opposite of agile.

This article has some fair points on bloated companies, useless meetings and rituals, guesswork-based products, and I wouldn't dare to estimate how many companies could fit into this description, but agile proposes just the opposite (I'd call that "conscious agile").

Even if you read the Scrum guide, you'll see that it does not prescribe most of the things that are commonly attributed to it. Many of these canned practices come from taking things out of context, or from a misunderstanding of the reasoning behind the Agile or Scrum principles.

Isn't that the problem though? Every discussion about problems with Agile are met with retorts like "but that's not real Agile!"

At this point, I believe the common understand of Agile, warts and all, is Agile. It doesn't matter what was in the manifesto. Agile is daily standups. Sprints. Retrospectives. Jira. Scrum. Overpaid and incompetent consultants or "coaches". Meeting "facilitators". Development phases. Release cycles. Jira plugins. PHBs. Bill Lumbergh.

It means that but it also means the opposite. There isnt really a common understanding there are several.

The problem is that it was always a vague pseudoreligious thing that would help the consultants sell their wares. If they'd been specific about what they meant that would have made it harder for everybody to project their desires on to it.

Those communist regimes weren't communist at all!

It's true, though. If the tenet is "keep customer/user feedback cycles small and frequent," then some side-effects are "frequent meetings, small deliverables, and dedicated task management roles." Corporate structures then eat that stuff up. It has nothing to do with the tenet.

Similarly, (and I'm reaching here) if the tenet is "centrally shared resources and profits," then some side-effects are "a few people (can) control the administration that owns everything." Despotic structures then eat that stuff up.

Though we cannot force PHP to interpret keys as strings if they also represent valid integers. I just had a case of an (associative) array of numeric codes — those which start with a '0' are treated as string keys, all others being treated as numeric. This doesn't matter so much at runtime, but I had to suppress some type checker (Psalm) errors.