Docker instead of an Elixir version manager (split thread)

Chat / Discussions
,
21

Thanks for proving my point by pointing me at that repo :slightly_smiling_face:

This is indeed much simpler than the ~10 lines Iā€™ve added to a ~100 line Chef zero config to set things up natively (https://github.com/cdegroot/chef-zero-laptop-setup). And I donā€™t have to run stuff in a browser, i can just fullscreen emacs and get a clutter-free native experience.

YMMV, everyone to their own, TIMTOWDI, but yeah, Iā€™ll stick with the error of my ways and keep it simple.

2 Likes
22

?? I added 5 lines to an existing xml + only answered a practical question (I did not read the rhetorical part). The whole repo may be large and not quite KISS when you consider all the code (different glued open source projects), but in my experience (about a year) it is not unstable. I prefer a GUI as editor.

23

I get it that having exact same versions of any software on your dev machine as the production machines is important. I get it that this would allow you to uncover some WTFs during manual or automated testing on your machine. I fully understand the need for consistency. That being saidā€¦

  1. Most of the bugs related to differencing versions of software in my 16 year long career stemmed from different configurations and not the versions themselves. Having Postgres 10.4 on your machine and 10.2 on your live servers is honestly an overblown danger unless you have 500M+ records and dozens of indices and materialized views. But you wouldnā€™t catch the problem locally anyway because in the cases of such DBs you wonā€™t have their dumps available to you as a developer (not always, Iā€™ll concede that). However, when somebody conveniently made Postgresā€™s caching mechanisms very aggressive by delaying disk flushes ā€“ and had their buffers set to 16GB of RAM because they have 32 ā€“ and then they claim the very inefficient DB queries they put in the code are actually efficient due to their very specific local setup, then we have a problem.
  2. I tried working with remote Linux machines through ā€œthin clientsā€ many times. Not once have I achieved the level of smoothness and responsiveness of my Emacs directly on my host machine (or local VM) as when connecting to a remote instance ā€“ even if that instance is in a VM on my machine. I might be stupid but having to wait 0.5 secs after everything I do simply drags me out of my creative zone. I am open to change my mind here but I am pretty sure over the years I tried at least 5 different Emacs plugins and builtin methods. And I wonā€™t ever work in browser. Maybe I just had a streak of bad luck because I heard many people claiming that you can start your VM headless and work without any lag in your Windows or macOS Emacs.
  3. I agree that playing with different versions is important but again, itā€™s an overblown argument. I am not the sysadmin or Ops team that will monitor the deployed app; in the eyes of the people paying my wage I am wasting my time needlessly tinkering with minutia and this time I actually agree with them.
  4. I had problems on live servers coming from differencing versions between my machine and the server of course ā€“ who didnā€™t? Longest fight with that was an hourā€¦ 6 years agoā€¦ with PHP. Sorry, itā€™s not that important. Spending so much creative energy on arcane Docker setups is wasting time; when I do the math, the time I spent on Docker over only 2 weekends (a year ago) vastly exceeds the time I had to fight with different software versions over the last 10 years. I know this will be seen as anecdotal but in my eyes itā€™s not at all worth it. And the peace of mind is only theoretical; Docker setups break for many other reasons, mostly wrong virtual network setups and storage volume problems. So one set of problems is replaced by another. Whereā€™s the win?
  5. The OS being in a more pristine condition I mostly agree with however. Still, rarely it has been a problem for me. Snapshot my Linux VM before some extra tinkering is done and I can sleep well. That doesnā€™t apply to my secondary setup though ā€“ the MacBook Pro. So here I am in agreement.

That, my friend, is a really bad comparison. If we compare with Docker, the engineers of the first moon probe didnā€™t only invent the thrusters and the outer shell; they invented and checked every single piece of the craft and accounted for any possible events. Thatā€™s why the first moon landing was successful. If they were to use one laser-focused technology then they would have to fit it together with everything else and I doubt the outcome would have been that good. They did the whole thing as one cohesive whole. Docker does the opposite ā€“ ā€œhereā€™s a containerization tech guys, oh sorry, youā€™ll have to deal with setting that up in terms of network, storage and everything else but the container, okay thanks byeā€.

Furthermore, using other peopleā€™s Docker files isnā€™t okay with me. I donā€™t even know what exactly do the official images contain. Why are they seen as trusted? My friend sysadmins assemble core images themselves and I fully agree with them. I donā€™t doubt the credibility of anyone around here but everybody can make a mistake.

I prefer getting my hands dirty and only having myself to blame down the road.

Finally, developing on a Mac is a joy in many ways. Please donā€™t forget that many of us wear glasses and their eyes arenā€™t in a perfect condition. Mac displays are much more merciful on my eyes even compared to the gaming monitor I use on my Windows 10 host (with Linux VMs); and that thing has 144Hz refresh rate and the best configurable panel I ever used. Windows and Linux font rendering is simply not that good compared to macOS, plain and simple (even after heavy tinkering, changing antialiasing mode, DPI etc.) Furthermore, brew is extremely convenient and it also allows moving between package versions (this is limited of course; in the example of databases you donā€™t have much freedom there). Itā€™s quite enough for my needs and everybody else I asked in the past. You can work with zsh on your Mac (and Linux) and that definitely improves your life as well.

Sorry to be seemingly disagreeing with everybody around here but you guys are overblowing the dangers, are overplaying the positives, and arenā€™t accounting for practical usage of time. Docker is more like this really favourite toy that the community REALLY wants to find a valid use for in development. A solution looking for a problem.

Itā€™s a very good tool in production but thatā€™s it.

3 Likes
24

FWIW, my point is not about version matches - youā€™re right there, itā€™s hardly ever an issue (and when it is, itā€™ll be found your CI environment which does run the same versions, doesnā€™t it? ;-)). MacOS X is just lacking in too many respects to be a nice development platform, IMO, YMMV, etcetera. Itā€™s been half a year since I rage-installed Ubuntu on my MacBooks, and a lot of issues suddenly just disappeared (mostly with random Brew crap breaking around MacOS upgrade time).

Iā€™m running Linux on a couple of Macbooks (one old 1440x900, one retina, both 15") and I donā€™t find the font rendering that much worse. The retina one is attached to a 4k monitor, not even a high end gaming one, and I find Linux HiDPI support just fine. There was a time where Apple had the secret sauce to antialiasing, subpixel hinting, and HiDPI rendering but to me it feels like thatā€™s in the past. And yes, Iā€™m wearing some impressively thick presciption glasses :wink:

25

Yeah, itā€™s always the configuration differences for me, too. Especially when itā€™s something like X-Accell-Redirect or LOAD DATA INFILE where specific directories need to exist and have the right permissions to work.

Between a Docker compose setup, which works on all OSs*, and writing stuff like an SELinux policy, plus whatever Iā€™d have to do to get it working on Mac or Windows, prefer Docker.

* itā€™s a BYOB company, plus we need to do cross-browser testing anyway.