top 49 comments

sorted by: hot top controversial new old
[–] 66 points 1 year ago (14 children)

10 years ago this meme said "compiling" shows how much docker has made things more "efficient"

  • source
  • hideshow 14 child comments
  • [–] 15 points 1 year ago (3 children)

    We've created this hell for ourselves

  • source
  • parent
  • hideshow 3 child comments
  • [–] 10 points 1 year ago (2 children)

    For me, Docker has been amazing. It’s probably my single most favorite tool in my tool belt. It has made my life so much easier over the years. It’s far from hell for me! 🐳

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago

    Same. Now, it is complete shit on Windows, though supposedly it is better on W11, and that is a no go. However, on Mac, it is a dream. On Linux it is a dream. Pgadmin, postgres, mqtt, redis, all the arrs, qbittorrent, jellyfin, and whatever else I want to try and throw away if I don't like it.

  • source
  • parent
  • [–] 17 points 1 year ago (9 children)

    Tbh, all of web development has become this... efficient. I remember the days where I could create a website in PHP and have it done in a couple of hours (per page), and now the only way I can do that would be using AI and going full on "vibe coding" mode.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 1 point 1 year ago (4 children)

    What do you mean? You can just make some react/typescript template and fastapi server thing, or any of dozens of equivalents, extremely quickly. I'm by no means an expert on web stuff as I develop software for controlling machines, but we used the above for some internal services in my last job and I could get a clean and functional site running in a day with no prior experience. I get that for public facing stuff you'll have some higher requirements but I couldn't imagine those wouldn't apply just because you're coding in PHP...

  • source
  • parent
  • hideshow 4 child comments
  • [–] 9 points 1 year ago

    a clean and functional site

    But the specs no longer call for a clean, functional site. Today's "professional" web development specs call for user tracking, customized content per user per platform per locality the page is being served to. Then there's the backend dashboard services showing the overlords user behavior patterns and how they change based on tweaks made to their ui, I wouldn't be surprised if the algorithms auto-tune presentation to optimize behavior.

  • source
  • parent
  • [–] 2 points 1 year ago (2 children)

    It's all the extra requirements, all the extra engineering that needs to be added that is IMO ruining web applications. Sure, they have huge benefits, but I hate when the application is simple but the backend is so overly engineered that it takes a week to completely build a fully fleshed out application. You have to organize your components, add styled-components.js, make sure it's compatible with mui.js, create test cases for each component, setup a DB and integrate it to hold all copy as well as any input from the customer, make sure that it's accessible (this part I admit that it's important), make sure your test cases always pass, setup routing tables, add analytics, add pixel campaign api, squash git conflicts, integrate some other weirdo apis that marketing and leadership pulled from some obscure service no one has ever heard off, debug some weird edge case error caused by a node dependency 3 levels down, present the finished website to leadership only to be destroyed and now you have to redo 75% of the site with leadership changes... rinse and repeat.

    It's a good thing I fucking love my job 🙃

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 1 year ago (3 children)
  • [–] 19 points 1 year ago (2 children)
  • [–] 7 points 1 year ago (5 children)

    Someone doesn’t know how to leverage Docker BuildKit

  • source
  • hideshow 5 child comments
  • [–] 3 points 1 year ago (4 children)

    Is there more to it than using multistage builds when appropriate?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 1 year ago (2 children)

    Oh yeah there is a lot you can implement to really get the most out of your architecture via docker and minimize your build times.

    One is using BuildKit with BuildX and Docker Build Cache.

    BuildX is the one I highly recommend getting familiar with as it’s essentially an extension of BuildKit.

    I’m a solutions architect so I was literally building with these tools 15 minutes ago lol. Send any other questions my way if you have any!

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 1 year ago (1 child)

    Ah thanks, I do have another question actually! So aside from speeding up builds by parallelizing different stages, so that

    FROM alpine AS two
    RUN sleep 5 && touch /a
    FROM alpine AS one
    RUN sleep 5 && touch /b
    FROM alpine AS three
    COPY --from=two /a /a
    COPY --from=one /b /b
    

    takes 5 iso 10 seconds, are there any other ways buildkit speeds up builds?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 1 year ago

    Yeah! So the first thing that BuildKit provides that greatly improves build time is that it will detect and run the two stages (one, two) in parallel so the wall-clock time for your example is 5s (excluding any overhead). Without BuildKit, these would be built serially resulting in a wall-clock time of 10s (excluding any overhead).

    Additionally, BuildKit uses a content-based cache rather than a step-by-step key cache used by classical Docker. This content-based cache is intelligently reused across different builds and even re-ordered instructions. If you were to build then rebuild your example, the sleep steps would be skipped entirely as those steps are fully completed and unchanged in the content-based cache from the previous build. It will detect changes and re-build accordingly.

    Lastly, (albiet not a BuildKit feature directly) is to leverage inline build caching for things such as dependencies so they are persisted to your filesystem and mounted during build time such that you don't have to fetch them constantly. This isn't really necessary if leveraging BuildKit fully since the content-based cache will also handle the dependencies and only pull if changed. i.e:

    RUN --mount=type=cache,target=/root/.cache \
        your-build-command
    
  • source
  • parent
  • [–] 6 points 1 year ago (1 child)

    I’ll give it a pass as parody, but you really should include the source material.

    xkcd 303

  • source
  • hideshow 1 child comment
  • [–] 4 points 1 year ago (2 children)

    I was going to watch a tuto on how to be more efficient but YouTube is still buffering

  • source
  • hideshow 2 child comments
  • [+] -24 points 1 year ago (20 children)
  • [–] 23 points 1 year ago (7 children)

    Why not? Why doesn't the programmer want to test a container?

  • source
  • parent
  • hideshow 7 child comments
  • [–] 15 points 1 year ago (6 children)

    True. Nothing beats running your unit tests in the actual container image that will be run in production.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 9 points 1 year ago* (2 children)

    Race condition that only happens on the much faster production hardware: Allow me to introduce myself

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago

    Unit tests can’t win ’em all. That’s where things like integration tests, staging environments, and load testing come in.

    The final layer of protection is the deployment strategy, be it rolling, canary, or blue-geen.

  • source
  • parent
  • [–] 1 point 1 year ago

    Unit tests? No matter where you run them, and normally this is done by CI in a prebuilt container image, so you don't have to wait for "docker building". Acceptance tests must be run in an environment as close to production as possible, but that's definitely not a programmer's job.

  • source
  • parent
  • [–] 21 points 1 year ago (3 children)

    I wonder what the dev part of devops means.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago

    At my previous job, we had a "Devops" team. We even outsourced some ops to a third party in the worst possible way (I'm talking "oh you want to set up an alert for something related to your service? Send us an email and we'll look into it" and so on). All the pre-devops pain magnified by an order of magnitude. Sometimes devs would do their own ops (I know, big shock!), and they would call it "shadow devops". Nearly fell off my chair when I first heard it. Kinda glad I'm not with them anymore.

  • source
  • parent
  • 3 comments in c/programmer_humor@programming.dev view that post
    [–] 16 points 1 year ago

    Nah we're past this. Now it's "The AI is reasoning"

  • source
  • [–] 7 points 1 year ago

    Cant be understaffed there, if my is building i have lots of other problems/mails/projects/planning i can do

  • source
  • [–] 3 points 1 year ago

    At my office always waiting for gitlab runners and kubernetes to get my instances up, takes sooooo long

  • source