4 ms·

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're suppos

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was certainly easier than managing them with Let's Encrypt, which has a lot of gotchas, requires tooling, knowledge and can suddenly break your website if something is off. > Concurrency, with async/await (in several languages) async/await usage is literally the main reason why my recent project is written in Go instead of C#. I like C#. I don't like Go. But dealing with all the gotchas of .NET Core async/await APIs drove me away. Moreover, Erlang had a much more sane and powerful parallelism model way before async/await. > Centering in CSS, with flexbox/grid Again, like with SSL, this is technically correct, but generally incorrect. Centering in CSS has gotten much easier with flexbox/grid. However, centering in HTML only became hard because tables were abandoned as the layout mechanism. Sure, they're not "semantic". But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. > Configuring cloud infrastructure, with Terraform Again, there used to be no Cloud infrastructure to configure. Personally, I find Terrafrom annoying more than anything else. > Setting up a dev environment, with Docker As opposed to doing what? Keeping my dev environment simple is a constant battle and most of the time Docker is the weapon used by the other side. In 00s my dev environment was a text editor and some upload tool. I haven't used PHP in well over a decade, but for my latest personal project I've decided to brush up on PHP 8.1. Despite awful syntax, I can do stuff by writing a handful of lines of code in a text editor. It's very refreshing. 100% focus on the outcome rather than tooling.

tele_ski 5y ago
I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is absolutely required now. You're absolutely right that it is a hoop to jump through, but its a hoop I find very necessary.
- taeric 5y ago
  Oddly, my experience is a mixed bag here. Teams I've been on that went for rigid standardization with docker have largely been much harder to upgrade than those that allow local dev however the dev wants. This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.
- tsm 5y ago
  I've worked on Rails, Node, and Clojure teams where Docker was optional and was always glad I avoided it. There has never been something important in my dev environment[1] that couldn't be responsibly managed by rbenv and bundler (or their equivalents for other languages). [1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.
- nirvdrum 5y ago
  How did you handle differences in macOS/Windows and Linux? The last team I was on that tried to do all local development in Docker kept running into breakages. To allow the devs to use whatever editor or IDE they wanted, the source code was stored in the host system and mounted as a Docker volume. While that sounds simple, it's amazing how many times things broke depending on who set it up. By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root. Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS. All of our Dockerfiles ended up with something like: ARG app_user_uid=61000 ARG app_user_gid=61000 ENV APP_USER="app" RUN groupadd -g $app_user_gid -o $APP_USER RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER And needed to be built on Linux with: docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ... While macOS users used the simpler: docker-compose build ... This all took quite some time to figure out. The person working on it would get things working, think it was all good, push it up, and only find out later that it wouldn't work on another dev's system. CI couldn't catch everything. The point of using Docker was to ensure there weren't inconsistencies against dev environments and that dev matched production. That seems like a fairly common use case, but we couldn't find anything on how to simplify this setup for teams other than mandating every user run the same exact system configuration. I have to believe we were doing something wrong, but we really couldn't find anything on the topic. I'd love to hear how you solved the problem. [0] -- https://docs.docker.com/develop/dev-best-practices/ https://docs.docker.com/develop/dev-best-practices/
mwcampbell 5y ago
> But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance). I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doesn't directly affect many of us so we tend to ignore it.
- taeric 5y ago
  Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult. I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder. And this is ignoring the explosion in nested divs that most modern sites have.
  - kalensh 5y ago
    It really depends. If table cell order happens to conform with a logical reading order, yeah, screen readers generally figured out when to ignore table semantics. But if the reading order does not make sense going row by row, then they are terribly broken. Nested divs aren't that bad. (Ignoring overall performance considerations. And even then I'd suspect that's less a concern than download and running all these JS libraries.) Nested divs with a mish-mash of poorly applied ARIA can get pretty bad though! Table layouts are also terrible for anyone who is not viewing the site at the browser width you designed it for. Accessibility is more than screen readers, and the ability to zoom or adjust browser width or display on a different device (hello mobile) is incredibly valuable for a lot of people. And I'd argue that the "ease" of using table layouts disappears as soon as you try to accommodate for any of that.
    - taeric 5y ago
      Right, my complaint in nested divs is more when they are a giant mix of different levels with no real discernable logic at the markup level. I think my memory is more from the garbage we made in early 2000s, though. I haven't tried to look at any modern page markup lately.
UglyToad 5y ago
Out of curiosity what were the > [...] gotchas of .NET Core async/await APIs drove me away. I kind of lost track of the framework to core changes but I think it became simpler with the removal of synchronization contexts?
MaXtreeM 5y ago
Async/await is not for parallelism.
- dehrmann 5y ago
  The article actually said "concurrency." In the case of the article, it's being oversold because it's not that much better than the old one thread per request model. Cross-request interactions are rare, so you're more or less writing the same code, only with async, you have to be careful not to accidentally do something CPU-intensive for 50ms, and if your runtime supports multiple cores (so not Ruby or Python), you still have to be careful with race conditions and locks. Writing parallel code that isn't clearly a divide and conquer variant is hard. Async doesn't help with that at all; it gives you more efficient context switches. I personally find threaded code easier to reason about because there can be a context switch anywhere, so you always need to think about locks and coordination. With aysnc code, a block of code without locks and be correct...until you add an await in the middle, and this isn't always obvious.
BenoitEssiambre 5y ago
Yeah I may be the only one, but I still think async/await was a huge missed opportunity to get rid of promises like I proposed here for javascript: https://es.discourse.group/t/callback-based-simplified-async-await/343 https://es.discourse.group/t/callback-based-simplified-async... It seems quite inneficient to me to wrap every function call in a caching layer and state machine that pretty much goes unused in the context of async/await and makes things unecessarily hard to undertand for new programmers.

tele_ski 5y ago

I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is absolutely required now. You're absolutely right that it is a hoop to jump through, but its a hoop I find very necessary.

taeric 5y ago
Oddly, my experience is a mixed bag here. Teams I've been on that went for rigid standardization with docker have largely been much harder to upgrade than those that allow local dev however the dev wants. This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.
tsm 5y ago
I've worked on Rails, Node, and Clojure teams where Docker was optional and was always glad I avoided it. There has never been something important in my dev environment[1] that couldn't be responsibly managed by rbenv and bundler (or their equivalents for other languages). [1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.
nirvdrum 5y ago
How did you handle differences in macOS/Windows and Linux? The last team I was on that tried to do all local development in Docker kept running into breakages. To allow the devs to use whatever editor or IDE they wanted, the source code was stored in the host system and mounted as a Docker volume. While that sounds simple, it's amazing how many times things broke depending on who set it up. By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root. Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS. All of our Dockerfiles ended up with something like: ARG app_user_uid=61000 ARG app_user_gid=61000 ENV APP_USER="app" RUN groupadd -g $app_user_gid -o $APP_USER RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER And needed to be built on Linux with: docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ... While macOS users used the simpler: docker-compose build ... This all took quite some time to figure out. The person working on it would get things working, think it was all good, push it up, and only find out later that it wouldn't work on another dev's system. CI couldn't catch everything. The point of using Docker was to ensure there weren't inconsistencies against dev environments and that dev matched production. That seems like a fairly common use case, but we couldn't find anything on how to simplify this setup for teams other than mandating every user run the same exact system configuration. I have to believe we were doing something wrong, but we really couldn't find anything on the topic. I'd love to hear how you solved the problem. [0] -- https://docs.docker.com/develop/dev-best-practices/ https://docs.docker.com/develop/dev-best-practices/

mwcampbell 5y ago

> But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc. Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance). I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doesn't directly affect many of us so we tend to ignore it.

taeric 5y ago
Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult. I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder. And this is ignoring the explosion in nested divs that most modern sites have.
- kalensh 5y ago
  It really depends. If table cell order happens to conform with a logical reading order, yeah, screen readers generally figured out when to ignore table semantics. But if the reading order does not make sense going row by row, then they are terribly broken. Nested divs aren't that bad. (Ignoring overall performance considerations. And even then I'd suspect that's less a concern than download and running all these JS libraries.) Nested divs with a mish-mash of poorly applied ARIA can get pretty bad though! Table layouts are also terrible for anyone who is not viewing the site at the browser width you designed it for. Accessibility is more than screen readers, and the ability to zoom or adjust browser width or display on a different device (hello mobile) is incredibly valuable for a lot of people. And I'd argue that the "ease" of using table layouts disappears as soon as you try to accommodate for any of that.
  - taeric 5y ago
    Right, my complaint in nested divs is more when they are a giant mix of different levels with no real discernable logic at the markup level. I think my memory is more from the garbage we made in early 2000s, though. I haven't tried to look at any modern page markup lately.

UglyToad 5y ago

Out of curiosity what were the > [...] gotchas of .NET Core async/await APIs drove me away. I kind of lost track of the framework to core changes but I think it became simpler with the removal of synchronization contexts?

MaXtreeM 5y ago

Async/await is not for parallelism.

dehrmann 5y ago
The article actually said "concurrency." In the case of the article, it's being oversold because it's not that much better than the old one thread per request model. Cross-request interactions are rare, so you're more or less writing the same code, only with async, you have to be careful not to accidentally do something CPU-intensive for 50ms, and if your runtime supports multiple cores (so not Ruby or Python), you still have to be careful with race conditions and locks. Writing parallel code that isn't clearly a divide and conquer variant is hard. Async doesn't help with that at all; it gives you more efficient context switches. I personally find threaded code easier to reason about because there can be a context switch anywhere, so you always need to think about locks and coordination. With aysnc code, a block of code without locks and be correct...until you add an await in the middle, and this isn't always obvious.

BenoitEssiambre 5y ago

Yeah I may be the only one, but I still think async/await was a huge missed opportunity to get rid of promises like I proposed here for javascript: https://es.discourse.group/t/callback-based-simplified-async-await/343 https://es.discourse.group/t/callback-based-simplified-async... It seems quite inneficient to me to wrap every function call in a caching layer and state machine that pretty much goes unused in the context of async/await and makes things unecessarily hard to undertand for new programmers.