Java-Hello-World-Enterprise-Edition VS urlscan

If you judge productivity by lines of code, absolutely.

https://github.com/Hello-World-EE/Java-Hello-World-Enterpris... is an excellent demonstration of this.

This reminds me of the "enterprise programming" mindset in OOP where people would make factories, strategies, strategy factories etc. just for the sake of it (instead of those solutions serving a real need) and ending up codebases that look like Hello World enterprise edition.

No other language or framework seems to get the same scrutiny as JavaScript.

The Enterprise Java solutions never seem to get as much discussion but we all recognize it also as being equally if not more so absurd[1]. This is true of every language and framework that gains mass adoption and use. Scala projects are crazy complex, the python 2 to python 3 migration was a mess, none of these are problems. They reflect the improvements in every metric to the underlying platforms and systems - end user experience, developer experience, reliability, testability etc.

JavaScript is in a phenomenal place today - we have come "full circle" but with better tooling, new capabilities, improved experiences etc.

There's a lot of keeping up with the jones' - that's partly nice as its job security and partly nice as a reflection of engineers improving our own ecosystem.

[1] https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...

It’s bad, but not as bad as the enterprise edition

Hello World Enterprise Edition - https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition

You might actually have to think about writing longass assembly hello world, but I can spin up fifteen Enterprise Java Hello World APIs in an afternoon.

Haven't written Java in years, but I'd take an enterprise edition program written in it, much like this one: https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition

Well, if it's text, you can use a program like urlscan which extracts URLs from input text and allows you to launch them in your browser of choice.

You all joke that this doesn’t happen in practice, but this literally just happened to me and it took me a few minutes to figure out what was going on.

The article lists Bash as not suffering from the bug, but it actually does if you `set -e`.

I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr.

I use mutt as my email client and urlscan [0] to open URLs inside emails. Urlscan looks at my BROWSER environment variable and thus calls my script to open whatever URL I target. Some time recently, the urlscan author improved the UX by hiding stderr so that it wouldn’t pollute the view, and so attempted to pipe it to `/dev/null`. I guess their original code to do this wasn’t quite correct and it ended up closing the child processes’ stderr.*

I generally use `set -e` because I want my scripts to fail if any command fails (I consider that after a an unhandled failure the scripts behavior is undefined, some other people disagree and say you should never use `set -e` outside of development, but I digress). My BROWSER scripts are no exception.

While my scripts handle non-zero returns for most things that can go wrong, I never considered that writing log messages to stdout or stderr might fail. But it did, and for a few weeks I wasn’t able to use urlscan to open links. I was too lazy to figure out what was wrong, and when I did it took me a while because I looked into every possibility except this one.

Luckily this wasn’t a production app. But I know now it could just as feasibly happen in production, too.

I opened an issue[1] and it was fixed very quickly. I love open source!

*No disrespect to urlscan, it’s an awesome tool and bugs happen to all of us!

[0]: https://github.com/firecat53/urlscan