5 ms·

Author here: This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running. Before this script, it c

Author here: This script helps new developers at my workplace setup their MacBook laptops quick, letting them hit the ground running. Before this script, it could take 2-5 days to install and configure everything, as much of the knowledge needed was either scattered in old docs or passed down verbally from a few senior devs. With this script, new developers can be ready in under 30 min. I have tried to make this script simple and useful. You will want to customize the installation and configuration to match the tools and services you use at your company. Note: it has not been tested on M1 Macs yet. I am still waiting on my M1 and will update when I receive it

nodesocket 5y ago
Seems like Docker + Docker Compose or GitHub Codespaces would simplify things greatly in terms of developer tooling install and setup.
- duped 5y ago
  Has docker performance improved on MacOS recently?
  - nodesocket 5y ago
    I run development and testing Docker workloads on a 16” M1 Max just fine. Runs native Apple Silicon (arm64)
    - duped 5y ago
      I'm more interested in comparative benchmarks. The last I heard MacOS (Intel) running docker was significantly slower than Linux and M1 was just as bad if not worse through Rosetta. My experience in running the odd docker container on a Mac has been that it was painfully slow compared to any Linux machine.
  - Casteil 5y ago
    From an M1 standpoint, the engine has been M1-native for a while - there's also a more recent update that makes the Docker Desktop UI/services M1-native.
    - errcorrectcode 5y ago
      Well the Engine maybe native, but how is it running the necessary x86_64 Linux VM under HyperKit?
      - nodesocket 5y ago
        I don't believe it does, stil get arm64 Docker images. However, there is an experimental mode with Docker Desktop that allows for multiple architecture builds using buildx[1] but I have not tried it. [1] https://docs.docker.com/engine/reference/commandline/buildx/ https://docs.docker.com/engine/reference/commandline/buildx/
        errcorrectcode 5y ago
        That's no bueno. I had hoped Docker, with all their investment $$, would've figured out a way (even QEMU or AOT/JIT recompilation) to run multiple architectures and platforms (i.e., FreeBSD, Linux) by now.
- errcorrectcode 5y ago
  That's one of the main arguments for using Docker: reproduceable environments. It also makes dumping tons of tools into a fresh laptop obsolete. Furthermore, having development and production environments at/near parity is important for troubleshooting.
gumby 5y ago
You are depending on macOS python? It’s going away. There’s no need to chmod your script, just invoke it with sh.
- joelkesler 5y ago
  > You are depending on macOS python? It’s going away. That it is. We still have a few projects running on legacy Google App Engine, and the teams working on those projects use the included Mac Python 2. We are in the process of migrating everything to Go, so the python 2 dependency should be removed in the future.
- zdw 5y ago
  Also, MacPorts or other multi-version python tools are generally better than Homebrew for Python: https://justinmayer.com/posts/homebrew-python-is-not-for-you/ https://justinmayer.com/posts/homebrew-python-is-not-for-you...
  - ggm 5y ago
    Home-brew is possibly better for all other uses. Perhaps the Python dev recipes in home-brew need fixing.
    - andreareina 5y ago
      The problematic behavior is from homebrew, not the recipes. And it's not new behavior: in my system years ago it yanked the readline major version that a bunch of terminal tools (psql, graphviz, ...) were using.
      - ggm 5y ago
        We all have different problems. This isn't one I've suffered. The link farm model is capable of maintaining parallel dependencies back to the home-brew version specific install path. I tend to think somebody didn't do a .rb Formula which preserved this version dependency. It may be clumsy but it's fixable in brew as far as I understand it.
spyke112 5y ago
2-5 days that’s nothing. I once billed a customer an entite months worth of hours because they had a super weird and complex development setup with scripts, proxies, vpn and all that good stuff. But when the AD groups are trash and no one knows what’s going on, well, that was fortunately for me their problem, which they were well aware of, and working hard to replace with a local k8s setup. And lets leave it at that.

nodesocket 5y ago

Seems like Docker + Docker Compose or GitHub Codespaces would simplify things greatly in terms of developer tooling install and setup.

duped 5y ago
Has docker performance improved on MacOS recently?
- nodesocket 5y ago
  I run development and testing Docker workloads on a 16” M1 Max just fine. Runs native Apple Silicon (arm64)
  - duped 5y ago
    I'm more interested in comparative benchmarks. The last I heard MacOS (Intel) running docker was significantly slower than Linux and M1 was just as bad if not worse through Rosetta. My experience in running the odd docker container on a Mac has been that it was painfully slow compared to any Linux machine.
- Casteil 5y ago
  From an M1 standpoint, the engine has been M1-native for a while - there's also a more recent update that makes the Docker Desktop UI/services M1-native.
  - errcorrectcode 5y ago
    Well the Engine maybe native, but how is it running the necessary x86_64 Linux VM under HyperKit?
    - nodesocket 5y ago
      I don't believe it does, stil get arm64 Docker images. However, there is an experimental mode with Docker Desktop that allows for multiple architecture builds using buildx[1] but I have not tried it. [1] https://docs.docker.com/engine/reference/commandline/buildx/ https://docs.docker.com/engine/reference/commandline/buildx/
      - errcorrectcode 5y ago
        That's no bueno. I had hoped Docker, with all their investment $$, would've figured out a way (even QEMU or AOT/JIT recompilation) to run multiple architectures and platforms (i.e., FreeBSD, Linux) by now.
errcorrectcode 5y ago
That's one of the main arguments for using Docker: reproduceable environments. It also makes dumping tons of tools into a fresh laptop obsolete. Furthermore, having development and production environments at/near parity is important for troubleshooting.

gumby 5y ago

You are depending on macOS python? It’s going away. There’s no need to chmod your script, just invoke it with sh.

joelkesler 5y ago
> You are depending on macOS python? It’s going away. That it is. We still have a few projects running on legacy Google App Engine, and the teams working on those projects use the included Mac Python 2. We are in the process of migrating everything to Go, so the python 2 dependency should be removed in the future.
zdw 5y ago
Also, MacPorts or other multi-version python tools are generally better than Homebrew for Python: https://justinmayer.com/posts/homebrew-python-is-not-for-you/ https://justinmayer.com/posts/homebrew-python-is-not-for-you...
- ggm 5y ago
  Home-brew is possibly better for all other uses. Perhaps the Python dev recipes in home-brew need fixing.
  - andreareina 5y ago
    The problematic behavior is from homebrew, not the recipes. And it's not new behavior: in my system years ago it yanked the readline major version that a bunch of terminal tools (psql, graphviz, ...) were using.
    - ggm 5y ago
      We all have different problems. This isn't one I've suffered. The link farm model is capable of maintaining parallel dependencies back to the home-brew version specific install path. I tend to think somebody didn't do a .rb Formula which preserved this version dependency. It may be clumsy but it's fixable in brew as far as I understand it.

spyke112 5y ago

2-5 days that’s nothing. I once billed a customer an entite months worth of hours because they had a super weird and complex development setup with scripts, proxies, vpn and all that good stuff. But when the AD groups are trash and no one knows what’s going on, well, that was fortunately for me their problem, which they were well aware of, and working hard to replace with a local k8s setup. And lets leave it at that.