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

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

Comments URL: https://news.ycombinator.com/item?id=47790058

Points: 4

# Comments: 1

I guess they’re using a different definition?

Comments URL: https://news.ycombinator.com/item?id=47340473

Points: 1

# Comments: 0

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

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)

Comments URL: https://news.ycombinator.com/item?id=46586901

Points: 8

# Comments: 2

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

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 better option? 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)

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.

Comments URL: https://news.ycombinator.com/item?id=46486280

Points: 4

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=45637780

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45625615

Points: 1

# Comments: 0

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.

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

Comments URL: https://news.ycombinator.com/item?id=45473126

Points: 52

# Comments: 58

Comments URL: https://news.ycombinator.com/item?id=45460235

Points: 2

# Comments: 0