edudobay

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.

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.

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.

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.

Code review is not about perfection – it is about peer review, much like in science, recognizing that a single person might have overlooked a lot of important stuff, and recognizing that collaboration usually leads to higher quality work.

Of course the desired level of quality will be different at each company/team, and each team should adjust for its own reality.

In the same team there can be times for throwaway code with low standards, and times for high quality code with strict standards. It is part of the developers' responsibility to tell them apart and make contextualised choices.

I can't tell if the previous comment was ironic, but it seems to me that developers seeing things that way is a sign of immaturity or unprofessionalism.

Why must developers write and ship code? To deliver a certain goal / feature / business value. If all they're willing to do is writing and shipping code without considering how will that software work in the future, what problems it might have, how hard it will be to make changes to it, they're not being responsible enough about their work.

Software in general (except for throwaway code) is not supposed to work only NOW — it is expected to work for a long time, with an acceptable degree of quality, and with changing requirements.

If, to build a wall, it takes longer than just laying some bricks, it is because a solid wall serves many more purposes than some layers of bricks.

For me, proper handling and distinction of Unicode vs. binary data was a game changer. I don't know if that's related to my first language being non-English, but I remember it being really important to me and a strong reason why I made the switch years ago.

Cool idea! Clear and nicely organized too :)

Wouldn’t it be more readable and less error-prone to have separate commands for turning hex mode on and off? Such as `hex on` and `hex off`?

Regarding Python, there _is_ a solution for the 3.x, <3.5 world. I would suggest the itertools.chain approach as noted in the "Chain items" section here: http://treyhunner.com/2016/02/how-to-merge-dictionaries-in-p...