michalc

You could even say you never knew what you were… MISSING ;-)

Agreed!

There’s a bit of an assumption that the branching _has_ to exist, but so often it doesn’t.

To be fair, the article does suggest other techniques: hinting at separating pure/impure code for example, which I would say often results in a “net” cyclomatic complexity reduction. But I would disagree with “extract method” as the most effective… yes very effective in reducing cyclomatic complexity, but that ignores downsides, especially if the code needs to be thought about as a whole.

I’ve been liking keeping sensitive config outside of the repo directory altogether, and instead putting it into a dotted folder in my home directory, so something like

~/.project-name/local.env

And then referring to that location in the repo, say from a docker compose file.

Works well so far

I would say it's only really a burden if you fight it, or don't expect to have to do it and right at the end someone asks "er... does this work without JavaScript?". My attitude is that it's a combination of freeing and a challenge: "we can and should make it simple, even boring"

Automatic enforcement for all services is tricky, because you _can_ depend on JavaScript if the user needs justify it.

Most sites/apps I work on are progressively enhanced (https://www.gov.uk/service-manual/technology/using-progressi...)

So far I've used a little bit of htmx (2) for one of them, and I really love it. Just a few attributes and we get some very reasonable progressively enhanced client/server interactive elements without full page loads.

Not sure I would choose if I had to make a SPA - it's partially from ignorance, but right not not sure how to avoid spaghetti. But I think it makes me even more strongly consider _not_ making a SPA

Reminds me of another “slow client”-related bug in gunicorn: https://github.com/benoitc/gunicorn/issues/3334

The GOV.UK Design System summary list component is a description list https://design-system.service.gov.uk/components/summary-list...

And... it also uses the wrapper div for styling

> the rest will soon follow

If you’re looking for requests ;-), I would love an ECS (and specifically Fargate) emulator that actually ran Docker containers locally as though they were in ECS

Submitted to Unicode yesterday (so please be gentle!)

I think I can understand why this wasn’t addressed for so long: in the vast majority of cases if your db is exposed on a network level to untrusted sources, then you probably have far bigger problems?

So my definition of big data was data so big it cannot be processed on a single machine in a reasonable amount of time.

I guess they’re using a different definition?

Hmmm... depends on the project / phase of the project?

I am particularly not a fan of doing unnecessary work/over engineering, e.g. see https://charemza.name/blog/posts/agile/over-engineering/not-..., but even I think that sometimes things _are_ worth it

Short answer is no, not as far as I am aware/can reason about it

In more detail: so by my understanding there are two techniques in making zip bombs…

Firstly nested ZIPs that leverage the fact that some unZIP programs recursively extract member files. stream-unzip doesn’t do this (Although you could probably use stream-unzip as a component in a vulnerable recursive ZIP parser if you really wanted to… but that I would argue is not the responsibility of stream-unzip)

The second technique is overlapping member files, but this depends on them overlapping as defined by the central directory at the end of the ZIP, which stream-unzip does not use

But if you are accepting files from an untrusted source, then you should validate the size of the uncompressed data as you unZIP (which you can do as you validate along with any other properties of the data)

> Beyond that, I've grown fond of 'sticking to the defaults' over the years.

This resonates with me! Both in terms of things I use and things I make - I want them to "just work"

> without regard for the maintenance burden 1, 2, 5, 10 years down the road.

To me software craftsmanship isn't just about the code, it's about engineering use of time.

In general shouldn't knowingly make choices that would result in pain in the future, but if you're increasing the chance of the project not making it to the future, then is that really the right choice to make? Finding out enough information to make the judgement call between long term/far future pain and short term benefits is all part of the craftsmanship.

> I don't blame agile. But I do kind of blame Agile™

(Loving the phrasing here! I think I'm right on board, especially if we're talking Scrum/Scum-ish)

> why not remind people of the purpose?

To answer this, I suspect that trying to change what certain words/phrases mean to people en-masse is extremely difficult, to the point of impossibility in most cases. However, we each have the power to be clearer in the words we use so they are understood by the people we're communicating with.

> engineering quality matters

But also, this to me suggests that there is some sort of absolute definition of quality, but it's much more nuanced. Nothing is inherently "bad quality", but instead has certain consequences, which may or may not happen or may or may not be acceptable in certain circumstances, and you might not even know what these are until the future. This I think is the point I'm trying to make - there is no absolute definition of engineering quality, and I suspect the term "technical debt" all too often suggests there is.

Have to admit the lazy thing threw me, but I can see how the “doing less” I’m arguing for could be taken that way. The “less” is not about avoiding handling edge cases that are possible now, but about avoiding putting in layers of code to handle cases possible only in some future versions of the code (with some limited exceptions that I mention at the bottom of the post)

In fact, it’s crossing my mind that people might not want to be accused of being lazy, and that is a motivation to over-engineer solutions.

You’re very welcome!

Have to admit I am curious: what’s the context / how has it helped you more specifically?

Very much agree.

It was a few years ago, and very AngularJS focused, but I posted something along these lines: https://charemza.name/blog/posts/angularjs/e2e/consider-not-...

In summary: having thing look cleaner at a glance is not helping if you’re (almost) always going to need to do more than glancing

> real mastery often involves learning when to do less, not more

Really love and agree with this, and (shameless plug?) I think really aligns with a way of working I (and some colleagues) have been working on: https://delivervaluedaily.dev/