you just need to have a way to deploy docker containers. You don't need to have an artisanal deployment methodology for each application. CI tools like CircleCI support runners for AMD64 and ARM64, so you can even run your test suite on both architectures for additional confidence, if needed.įor me, Docker containers have always been about reproducibility of builds (which some people will argue about, but it does a good job 99% of the time) and consistency in deployment. These days, Docker supports multiarch images, so it's fairly trivial to build one image that supports with AMD64 and ARM64 transparently. If you're not careful, you can end up compiling binaries that work on your machine, but don't work in production, all on AMD64. or any number of the small variations of AMD64 that exist. Their local machine might not have AVX-512 instructions, but the production machine might. In most cases, I would say developers have been working with Docker locally on a different processor architecture than what they deploy to in production. I am quite happy.ĭocker's promise was never about processor architecture. I still had to navigate around some specific dependencies but the fully native M1 development flow is so smooth compared to my previous Intel MacBook. I was happy to see that major blockages improved in some months and for some lagging dependencies I was pushing some fixes myself.Īt this moment almost 1.5 years later everything works smoothly. (Felt that the slowdown was extra painful for JIT like languages) Also for Docker it meant waiting for some months to have something that would work properly but luckily I could manage without at the start. Same issues with the JVM to find something able to run smoothly. Sometimes there were Arm fixes committed for things like NodeJS but they were not yet released so I needed to build my own version.
I was almost starting to regret my choice. It meant for me that in the beginning IDEs, Java and things like node ran all in Rosetta mode and were very slow.
It was a big gamble but I am the kind of early adopter guy that did not want to miss out on this new CPU fun. I was losing my previous provided laptop by leaving my previous job and needed to buy one to join a startup program.
APPLE JAVA 8 ASSESSMENT TEST PRO
I got the MacBook Pro M1 16GB when it was launched in November 2020. You can always tell a project that I work on because there's a bash script in there that fires up tmux with docker-compose, all services under nodemon, ngrok, etc.
APPLE JAVA 8 ASSESSMENT TEST CODE
That said, on code inside containers is pretty awful, in my experience, and I'd much rather use docker-compose with something like Traefik to route outside Docker so I can run my service locally and everything works as I expect it. (Used to use chef-zero, but that got really crusty.) As far as new machines go, I have a shell script that I share with new folks (and my own version for a new machine) that just gets things done.
APPLE JAVA 8 ASSESSMENT TEST MAC
But pretty much everything I touch (Node, Java, Ruby, dotnet-core) ends up being solved with asdf, a Brewfile for the Mac users and yum-and-xargs for the Fedora folks (me), in very short order. I can't speak to Python beyond the fairly minimal touch points I have with our projects, but Python anecdotally seems much rougher than it should be in many respects.
0 kommentar(er)
