3 ms·

TL;DR Use cloud based development environments to avoid machine (developer) specific, non reproducible problems, and increase productivity (speculatively) Prob

TL;DR Use cloud based development environments to avoid machine (developer) specific, non reproducible problems, and increase productivity (speculatively) Probably ok for certain needs, but not something I would use. My productivity comes from a localised and personalised setup. Issues with the local or remote environments IMHO, indicate a problems that 1) others may also encounter. 2) should at least, if possible be understood/ documented. 3) represent opportunities for greater understanding of the environments in question (assuming you have time to dig).

buscoquadnary 4y ago
Isn't that what the promise of Docker was, you can distribute the docker image and everyone is running and building the same thing?
- drunkenmagician 4y ago
  I would have thought so too ... ¯\_(ツ)_/¯
- quickthrower2 4y ago
  Yeah but what is the debugging experience like? Does that work? I think it adds a layer of complication. Also images can take a while to build. Although most would be cached hopefully with just copying your code changing. Maybe a snappy startup can fix?
  - KronisLV 4y ago
    > Yeah but what is the debugging experience like? Does that work? Sort of. In certain stacks, you essentially set up remote debugging like you would for an app running in a remote environment (which is your local container with an exposed port) and your IDE just works. It's relatively carefree when it works as expected, but a bit of a pain to set up sometimes. Admittedly, something like CPU flame graphs or tools like VisualVM that let you easily select from locally running Java processes to instrument might be harder to work with. But even then, you can have issues with file system permissions and any bind mounts that you might need (e.g. files in a PHP container, where you want to keep developing and testing your app after page reloads, without rebuilding the entire container). I wrote a bit more about it here: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'm still a proponent of using containers for making applications more consistently managed (configuration, resource limits, port bindings, storage), self-contained (dependencies, running different/multiple versions in parallel) and easier to launch (e.g. Docker Compose file or a fancier variation of YAML instead of Ansible + systemd services), but they definitely can be a leaky abstraction if you don't have *nix as your development machine OS.
deleted 4y ago
[deleted]

buscoquadnary 4y ago

Isn't that what the promise of Docker was, you can distribute the docker image and everyone is running and building the same thing?

drunkenmagician 4y ago
I would have thought so too ... ¯\_(ツ)_/¯
quickthrower2 4y ago
Yeah but what is the debugging experience like? Does that work? I think it adds a layer of complication. Also images can take a while to build. Although most would be cached hopefully with just copying your code changing. Maybe a snappy startup can fix?
- KronisLV 4y ago
  > Yeah but what is the debugging experience like? Does that work? Sort of. In certain stacks, you essentially set up remote debugging like you would for an app running in a remote environment (which is your local container with an exposed port) and your IDE just works. It's relatively carefree when it works as expected, but a bit of a pain to set up sometimes. Admittedly, something like CPU flame graphs or tools like VisualVM that let you easily select from locally running Java processes to instrument might be harder to work with. But even then, you can have issues with file system permissions and any bind mounts that you might need (e.g. files in a PHP container, where you want to keep developing and testing your app after page reloads, without rebuilding the entire container). I wrote a bit more about it here: https://blog.kronis.dev/everything%20is%20broken/containers-are-broken https://blog.kronis.dev/everything%20is%20broken/containers-... I'm still a proponent of using containers for making applications more consistently managed (configuration, resource limits, port bindings, storage), self-contained (dependencies, running different/multiple versions in parallel) and easier to launch (e.g. Docker Compose file or a fancier variation of YAML instead of Ansible + systemd services), but they definitely can be a leaky abstraction if you don't have *nix as your development machine OS.

deleted 4y ago

[deleted]