4 ms·

Wrapping docker/docker-compose with makefiles or bash aliases is an anti-pattern, particularly on team projects. It's a convenience to you, but it's a loss for

Wrapping docker/docker-compose with makefiles or bash aliases is an anti-pattern, particularly on team projects. It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file.

yakshaving_jgt 8y ago
There's really nothing wrong with it. An anti-pattern because beginners won't understand the commands abstracted over? Come on. When I was a beginner I certainly didn't want to learn all the quirks of DOM manipulation in JavaScript, and jQuery held my attention long enough for me to build a career in this industry. If it's your job to build a product, there's not much ROI on memorising the docker and docker-compose flags, which often don't match and are chosen quite arbitrarily. I know what commands I intend to run when I use NixOps, but it doesn't matter. I'll still wrap them in easier-to-remember Make tasks. I'll even use tasks that just delegate to shell scripts. Here's an example from one project I'm working on: .PHONY: deploy-prod deploy-staging cachix build: nix-shell -p nodePackages.npm nodejs --run "npm run build" touch src/Settings/StaticFiles.hs nixops modify -d moneygains services.nix aws.nix deploy-prod: build nixops deploy -d moneygains --include moneygains deploy-staging: build nixops deploy -d moneygains --include staging cachix: ./cachix.sh > It's also a loss to experienced people because you're forcing your own opinions on them Nobody is forced to use those abstractions…
- maccard 8y ago
  You're replacing arbitrary docker commands with arbitrary make commands, you're just moving the goalpost really. > Nobody is forced to use those abstractions… Oh come on. You know that these scripts become canon, and anyone who deviates from them and has an error will just be told to use the build scripts. You're not forced in the same way nobody forced you to use docker, the app just won't work without it.
  - Gigablah 8y ago
    > anyone who deviates from them and has an error will just be told to use the build scripts Good. It's either: - Throw all the commands into the README and force people to copy and paste - Throw all the commands into a bash script and re-implement all the command parsing and prerequisite logic that Makefile syntax provides - Be docker / docker-compose CLI tech support - Write a Makefile
marcus_holmes 8y ago
> It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file. ahh, but you force the newbies to learn MakeFile, and that's a net win imho ;)

yakshaving_jgt 8y ago

There's really nothing wrong with it. An anti-pattern because beginners won't understand the commands abstracted over? Come on. When I was a beginner I certainly didn't want to learn all the quirks of DOM manipulation in JavaScript, and jQuery held my attention long enough for me to build a career in this industry. If it's your job to build a product, there's not much ROI on memorising the docker and docker-compose flags, which often don't match and are chosen quite arbitrarily. I know what commands I intend to run when I use NixOps, but it doesn't matter. I'll still wrap them in easier-to-remember Make tasks. I'll even use tasks that just delegate to shell scripts. Here's an example from one project I'm working on: .PHONY: deploy-prod deploy-staging cachix build: nix-shell -p nodePackages.npm nodejs --run "npm run build" touch src/Settings/StaticFiles.hs nixops modify -d moneygains services.nix aws.nix deploy-prod: build nixops deploy -d moneygains --include moneygains deploy-staging: build nixops deploy -d moneygains --include staging cachix: ./cachix.sh > It's also a loss to experienced people because you're forcing your own opinions on them Nobody is forced to use those abstractions…

maccard 8y ago
You're replacing arbitrary docker commands with arbitrary make commands, you're just moving the goalpost really. > Nobody is forced to use those abstractions… Oh come on. You know that these scripts become canon, and anyone who deviates from them and has an error will just be told to use the build scripts. You're not forced in the same way nobody forced you to use docker, the app just won't work without it.
- Gigablah 8y ago
  > anyone who deviates from them and has an error will just be told to use the build scripts Good. It's either: - Throw all the commands into the README and force people to copy and paste - Throw all the commands into a bash script and re-implement all the command parsing and prerequisite logic that Makefile syntax provides - Be docker / docker-compose CLI tech support - Write a Makefile

marcus_holmes 8y ago

> It's a convenience to you, but it's a loss for newbies because they'll just learn that abstraction only. It's also a loss to experienced people because you're forcing your own opinions on them. I would git ignore that file. ahh, but you force the newbies to learn MakeFile, and that's a net win imho ;)