Nice. Software developer, gamer, occasionally 3d printing, coffee lover.

  • 0 Posts
  • 121 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2023

help-circle






  • So far I’ve helped my team of 5 get on them. Some other teams are starting as well. We’ve got Windows, Linux, and Mac OSX that developers are running on their work machine (for now), and the only container specific issue we ever encounter is port conflicts, which are well documented with easy to change environment variables to control.

    The only real caveat right now is we have a bunch of micro services, and so their supporting services (redis, mariadb, etc.) end up running multiple times, so their is some performance loss from that. But they’re all designed to be independent, only talking to each other via their API, so the approach works.


  • Zikeji@programming.devtoProgrammer Humor@programming.devWorks on my machine
    link
    fedilink
    English
    arrow-up
    52
    arrow-down
    4
    ·
    2 months ago

    If this is your take your exposure has been pretty limited. While I agree some devs take it to the extreme, Docker is not a cop out. It (and similar containerization platforms) are invaluable tools.

    Using devcontainers (Docker containers in the IDE, basically) I’m able to get my team developing in a consistent environment in mere minutes, without needing to bother IT.

    Using Docker orchestration I’m able to do a lot in prod, such as automatic scaling, continuous deployment with automated testing, and in worst case near instantaneous reverts to a previously good state.

    And that’s just how I use it as a dev.

    As self hosting enthusiast I can deploy new OSS projects without stepping through a lengthy install guide listing various obscure requirements, and if I did want to skip the container (which I’ve only done a few things) I can simply read the Dockerfile to figure out what I need to do instead of hoping the install guide covers all the bases.

    And if I need to migrate to a new host? A few DNS updates and SCP/rsync later and I’m done.












  • I’ve had bad tinkering break my system before, but never had an update break it irreversibly. The closest would actually be on Silverblue itself, when an update to the kernel was using different signing keys that cause the system not to boot. Fortunately it was simple, I selected the previous deployment and I was in (on a non versioned OS I would have selected the previous kernel which most are configured to retain the last few). A quick Google revealed Ublue had a whole kerfuffle and after verifying it was legit, I enrolled the new certs into my MOK.

    Although one time on Arch I had installed an experimental version of Gnome from one of their repos, and was pleasantly surprised when that version finally released and I removed the experiment repo and did an update absolutely nothing at all broke. Nothing.


  • This consternation is definitely common. It’s hard to apply skills to something with no long term impact of benefit. I’ve improved my skills by finding stuff I can help on in the communities I participate in.

    It’s natural to be overwhelmed, so deciding on a project does scope what you can learn, but a hard part is architecting the foundation of that project.

    Introducing new features to an existing project is a great way to get your feet wet - it has multiple benefits, for one of you do take a position as a developer in the future, you likely won’t be architecting anything initially, primarily improving on existing projects. So participating in OSS projects is a similar mechanism to that - you have to learn their codebase to a degree, you have to learn their style and requirements, etc.

    Even if you don’t ultimately contribute, it’s still a learning experience.