6 ms·

I'm probably in the minority here but I would never run this if given the option. Most of the stuff in here has nothing to do with development as is just person

I'm probably in the minority here but I would never run this if given the option. Most of the stuff in here has nothing to do with development as is just personal preference. Like what are you hoping to accomplish by dropping `ag` on my PATH? It's just not a tool I use. The stuff that's specific to development -- go, node, npm, etc. -- sure that makes sense, but installing that stuff via brew is vastly inferior to versioning it as a dependency within your build system. And I'm not saying you have to use bazel or something. Pin your versions, install them by script in the context of your build tools and leave it at that. I'd reckon the reason you don't see this sort of thing often is because it's not actually useful or necessary. I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful. It's like showing up to a job and them saying "hey we've preconfigured emacs for you." I'm a professional and take pride in knowing my tools. I can set up my development environment myself. I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers. I'm sure others will find this useful, and there's certainly nothing harmful about this, but it's certainly not for me, and I'm certain there's a better way to go about handling all these things.

chidog12 5y ago
it's more of just a script a newer company will use to do the initial setup for laptops. Great starting point if you have security and preferred software before the new hire's first day.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
joelkesler 5y ago
Author here: For sure! I can understand that. For people who don’t want to use the script, I also included a list of what is installed in the README. Experienced dev's can manually install and configure what they need. We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them, and others who just want to start quick. Update: clarifications
- onion2k 5y ago
  We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them... Removing an ideal opportunity to learn doesn't sound particularly helpful. In fact, it sounds like you want them to "get up to speed quickly" and "hit the ground running" rather than be onboarded in a way that makes them useful, long term members of the team. This approach is practically the opposite of how I think you should treat a new graduate on your team. They're new to the company, the tools, the operating system, even to the world of just having a dev job in some cases. They need time to be able to learn how to work well. I get that you want to remove a barrier and make life easier, but overcoming that barrier yourself is useful, even if you need a bit of hand-holding to do it. Whose idea was this? I can't help but think this is the work of a senior who doesn't want to mentor or help juniors, and they've automated their problem of being asked 'dumb' questions away. If someone brought this script to my company I would fight against its adoption. Edit: I just saw this comment https://news.ycombinator.com/item?id=29535498 https://news.ycombinator.com/item?id=29535498. In your position I'd delete the script and work on updating your on-boarding documentation, because you're fixing the wrong problem, and also realise that 2 - 5 days to onboard in a new role is normal and perfectly acceptable. Just understanding a new codebase takes longer than that.
  - deleted 5y ago
    [deleted]
  - Brian_K_White 5y ago
    "Removing an ideal opportunity to learn" A script like this is also a reference, a known state, which is valuable, even necessary, all by itself regardless if you agree with what it does or the state it produces or the value of being forced to do it all wrong and discover and file off all the edges yourself over time.
- harryvederci 5y ago
  You can't just share something for free on the internet and expect people not to be mad. Consider this a learning experience.
rgoulter 5y ago
> I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers. I think this makes "is this worth using" an entirely different question. OP's setup script is better than just a "here's your macbook, take some time to get your computer set up". A tool like Nix is high-effort-high-reward. If everyone's familiar with Nix, it's surely better to use Nix than to use OP's setup script. If not, whether Nix is the better way to do things is arguable.
- unbanned 5y ago
  Is it high reward? I don't think so, not really anyway
  - rgoulter 5y ago
    IMO, what makes it high reward: With Nix, you can programmatically describe an installation of packages (including how they're built). This then allows having multiple versions of the same package installed, easily patch (or vary build arguments) of package dependencies, an easy way to distribute or install these same sets of packages in whatever distribution of Linux (or on macOS), development shells which load the required build tools, a saner build language than Dockerfile's. With NixOS, the configuration of services can be managed from a single source. I think for any particular task, it's more difficult to bother with Nix compared to just using some convenient solution. (e.g. using Dockerfiles to build Docker images, or using cloud-init to configure a VM setup). -- So, it's harder to say "is Nix better than <this> for <this problem>?".
    - interactivecode 5y ago
      I don’t get it, what’s the difference between nix and other dependency or package managers?
      - rgoulter 5y ago
        Nix does more things than other package managers. Compared to other package managers: You could use Nix to install packages, in the same way you would with other package managers. An advantage to this is you'll get the same version of the package regardless of which distribution you use. (Whereas with, say, Ubuntu you might need to add a PPA to get versions as bleeding-edge as what Arch would offer). Nix's tooling is also broader in scope: e.g. with nix-shell, you can have a shell which has a Go-lang compiler (or whatever) in that shell, but without needing the Go-lang compiler installed on the computer. This is comparable to e.g. asdf, or to running your toolchain in a Docker container (like what VSCode Remote Containers offers). -- i.e. Nix can be useful for development. NixOS takes the same Nix declarative language, and allows describing the configuration of the whole OS setup with it. Just as Terraform declares an orchestration of cloud infrastructure, NixOS allows declaring how the OS is setup. (Here, Nix is comparable to e.g. cloud-init or Ansible). -- i.e. Nix can be useful for deployment.
aledalgrande 5y ago
I'd rather provide a docker image, if you want something prebuilt for a developer. And yes, I wouldn't run a script like that on any machine I use, but I do understand how it could be useful for someone starting out.
johnwheeler 5y ago
Exactly. I’d be really bummed if I started a new job and was expected to run this script. It’s like they’re saying they’ve found and encapsulated the most productive development experience you could ask for and they’re going to shove it down your throat. You should give your hires the respect they deserve and treat them like professionals letting them use their own tools. Just give them a mac and let them do their thing.
- TomatoTomato 5y ago
  Or maybe it's a test. Give this script to a new hire and see if they run it without question or whether they actually read the script and pick and choose what they need or question what they don't understand.
- heleninboodler 5y ago
  Many companies have required sets of tools in order to do things like follow ops runbooks. Sure, you're a professional, but if you're following the team runbooks, you need to be doing it in exactly the prescribed way, meaning having your ssh access configured properly and the right version of python on your path, and any dependencies the shell scripts have, and rather than have you find and fix those one by one, a standard setup can save a lot of wasted time. Nobody's saying you can't use your own tools the way you want to, but you better be able to cope with having some team-specific tools and configs "shoved down your throat" or you really aren't a professional.
IgorPartola 5y ago
I am 100% with you. I did some consulting work for a startup that had this kind of thing. “Oh you are having trouble with our dev environment? We have a small script that will get you going.” Script turns out to install shit like Zoom, VS Code, Slack, reconfiguring paths, fucking up my dot files, installing and configuring Docker, etc. It was a mess and there was no reason for most of it and the parts that were needed were already broken. Even homebrew is a little too opinionated for me. If I could run some specific bits of Mac software on Linux I would never leave Ubuntu. apt is a joy to use by comparison to all this BS.
- aspenmayer 5y ago
  It’s fine to virtualize macOS on Apple hardware, so you could in theory run both via a hypervisor or boot Linux and virtualize macOS, or containerize macOS with Docker.
- sirn 5y ago
  I've worked on a project where its build script is reliant on the existence of Homebrew when a simple command -v would suffice. They have library paths, and everything hard-coded to Homebrew prefix. It has been such a colossal pain to modify all these scripts that I ended up installing macOS in a VM to build the project.
- theodric 5y ago
  MacPorts is based on apt. You might enjoy using that more than brew.
  - hardlianotion 5y ago
    I think macports is based on bsd ports. One difference between macports and apt is that macports compiles everything from source, whereas apt gives you ready brewed binaries.
    - sirn 5y ago
      MacPorts has been doing binary packages since MacPorts 2.0 (2011). It will compile from source when binary package is unavailable (e.g., non-default variant or newer OS release).
LudwigNagasena 5y ago
> I'm a professional and take pride in knowing my tools. But some people aren’t professionals. They may be hobbyists or people who just entered the field. And the barrier to entry is becoming higher and higher with the rising importance of devops. It’s very daunting to try to get into a new tech stack and follow the best practices without much guidance.
- unbanned 5y ago
  Install vscode and away you go. I had an intern building a Java project in minutes with zero prior exposure.
  - LudwigNagasena 5y ago
    I wonder how much time he would need to set up npm+typescript+Babel+webpack workflow for a fullstack development with shared modules between the FE and the BE without copying someone’s repository.
    - unbanned 5y ago
      Probably quicker than someone panicking trying to remember which key chord combination to press to disable some esoteric function which conflicts with another required plugin to satisfy their "leet coding keyboard only" dev env. Vscode does practically everything out of the box and prompts you to install context appropriate plugins which do everything.
  - bryanrasmussen 5y ago
    I gotta admit I'm freaking out a bit at this statement.
    - drchickensalad 5y ago
      Why?
fmakunbound 5y ago
> and them saying "hey we've preconfigured emacs for you." Good god, that’s like wearing someone else’s dirty underwear.
solatic 5y ago
Really, it depends on what kind of company you're working for. If you're a BYOD place then sure, let people use their own tools, you have bigger fish to fry. If you're the place where your auditors require you to deliver proof that all your developers have antivirus installed then it's a different story. The minute you need to take away local administration rights from developers, the value of a standard development environment is immense. No more complaints about not having local administration rights. Plus, the value of hey, my laptop just broke, I ran down to IT, they swapped me out, go back to my desk, log in, and bam, my environment is right like how I left it is huge. Ultimately - professionals never blame their tools. The hammer handle might not have an ivory handle and tungsten head, but so what? This isn't what bottlenecks you in organizations. And if you really seethe at the thought of emacs being taken away from you, well, switch jobs. The vast majority of the engineering labor force doesn't even know what emacs is.
- saagarjha 5y ago
  Putting me in an environment I don’t want to use is easily going to make me several times less productive. I’m not going to blame those tools for reducing my effort, because I’ll put in the same amount, but I can absolutely blame them for not letting me work more productively.
  - bottled_poe 5y ago
    This isn’t meant to be directed at you personally. Don’t be a vigilante. Either lead, follow or get out of the way. Most people just prefer to complain than create positive change though, because it’s less effort.
    - saagarjha 5y ago
      I'm not entirely sure what you mean?
      - dagw 5y ago
        When developers end up "in an environment (they) don’t want to use" they often have one of 4 different responses: 1) Say "I'm really sorry, but I cannot do my best work in this environment", and hand in their resignation. 2) Learn to work within the constraints given and find ways to be productive anyway. 3) Take on the responsibility of trying to work within the system and improve things. 4) Bitch and moan, get all passive aggressive, start working slower (to prove their point) and generally piss off their surroundings, spread negativity and tank morale. The point is that you should always pick some combination of 1-3, rather than 4. However 4 is by far the easiest and makes most people feel better about themselves so that is the one they tend to go for. It is also by far the most unprofessional, and reflects rather badly on you. Full disclosure: I may have done nr. 4 at some point in my career.
stephenr 5y ago
I would certainly consider anything that auto-installs Brew, a bunch of Electron apps, and Google app(s) to be harmful.
frereubu 5y ago
Mathias Byens' dotfiles repo is a bit like this - https://github.com/mathiasbynens/dotfiles https://github.com/mathiasbynens/dotfiles. It's highly opinionated, but I found it extremely useful as a starting point for setting up my own dotfiles. This repo seems simliar to me - the point is the sharing, not necessarily that you'd blindly run it without reading through it.
throwaddzuzxd 5y ago
> I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful. I rewrote the onboarding documentation of my team and asked myself if I should script the tooling installation. I came with the same conclusion and just gave a list of tools to absolutely install (with a suggestion of how to install it, but do as you please) and recommended tools and extensions (+ why they're cool). I think this approach is especially useful for newbies who don't necessarily know the tools or how to install them. If anybody has an issue with their custom installation though, I redirect them to the onboarding recommendations.

chidog12 5y ago

it's more of just a script a newer company will use to do the initial setup for laptops. Great starting point if you have security and preferred software before the new hire's first day.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

joelkesler 5y ago

Author here: For sure! I can understand that. For people who don’t want to use the script, I also included a list of what is installed in the README. Experienced dev's can manually install and configure what they need. We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them, and others who just want to start quick. Update: clarifications

onion2k 5y ago
We have many devs who are fresh out of university or used to windows, so not all are experts with the Linux/Mac command-line. This is helpful for them... Removing an ideal opportunity to learn doesn't sound particularly helpful. In fact, it sounds like you want them to "get up to speed quickly" and "hit the ground running" rather than be onboarded in a way that makes them useful, long term members of the team. This approach is practically the opposite of how I think you should treat a new graduate on your team. They're new to the company, the tools, the operating system, even to the world of just having a dev job in some cases. They need time to be able to learn how to work well. I get that you want to remove a barrier and make life easier, but overcoming that barrier yourself is useful, even if you need a bit of hand-holding to do it. Whose idea was this? I can't help but think this is the work of a senior who doesn't want to mentor or help juniors, and they've automated their problem of being asked 'dumb' questions away. If someone brought this script to my company I would fight against its adoption. Edit: I just saw this comment https://news.ycombinator.com/item?id=29535498 https://news.ycombinator.com/item?id=29535498. In your position I'd delete the script and work on updating your on-boarding documentation, because you're fixing the wrong problem, and also realise that 2 - 5 days to onboard in a new role is normal and perfectly acceptable. Just understanding a new codebase takes longer than that.
- deleted 5y ago
  [deleted]
- Brian_K_White 5y ago
  "Removing an ideal opportunity to learn" A script like this is also a reference, a known state, which is valuable, even necessary, all by itself regardless if you agree with what it does or the state it produces or the value of being forced to do it all wrong and discover and file off all the edges yourself over time.
harryvederci 5y ago
You can't just share something for free on the internet and expect people not to be mad. Consider this a learning experience.

rgoulter 5y ago

> I use Nix where possible and tend to avoid homebrew. Half of these things I have in my dotfiles or nix configs already, as do most of my peers. I think this makes "is this worth using" an entirely different question. OP's setup script is better than just a "here's your macbook, take some time to get your computer set up". A tool like Nix is high-effort-high-reward. If everyone's familiar with Nix, it's surely better to use Nix than to use OP's setup script. If not, whether Nix is the better way to do things is arguable.

unbanned 5y ago
Is it high reward? I don't think so, not really anyway
- rgoulter 5y ago
  IMO, what makes it high reward: With Nix, you can programmatically describe an installation of packages (including how they're built). This then allows having multiple versions of the same package installed, easily patch (or vary build arguments) of package dependencies, an easy way to distribute or install these same sets of packages in whatever distribution of Linux (or on macOS), development shells which load the required build tools, a saner build language than Dockerfile's. With NixOS, the configuration of services can be managed from a single source. I think for any particular task, it's more difficult to bother with Nix compared to just using some convenient solution. (e.g. using Dockerfiles to build Docker images, or using cloud-init to configure a VM setup). -- So, it's harder to say "is Nix better than <this> for <this problem>?".
  - interactivecode 5y ago
    I don’t get it, what’s the difference between nix and other dependency or package managers?
    - rgoulter 5y ago
      Nix does more things than other package managers. Compared to other package managers: You could use Nix to install packages, in the same way you would with other package managers. An advantage to this is you'll get the same version of the package regardless of which distribution you use. (Whereas with, say, Ubuntu you might need to add a PPA to get versions as bleeding-edge as what Arch would offer). Nix's tooling is also broader in scope: e.g. with nix-shell, you can have a shell which has a Go-lang compiler (or whatever) in that shell, but without needing the Go-lang compiler installed on the computer. This is comparable to e.g. asdf, or to running your toolchain in a Docker container (like what VSCode Remote Containers offers). -- i.e. Nix can be useful for development. NixOS takes the same Nix declarative language, and allows describing the configuration of the whole OS setup with it. Just as Terraform declares an orchestration of cloud infrastructure, NixOS allows declaring how the OS is setup. (Here, Nix is comparable to e.g. cloud-init or Ansible). -- i.e. Nix can be useful for deployment.

aledalgrande 5y ago

I'd rather provide a docker image, if you want something prebuilt for a developer. And yes, I wouldn't run a script like that on any machine I use, but I do understand how it could be useful for someone starting out.

johnwheeler 5y ago

Exactly. I’d be really bummed if I started a new job and was expected to run this script. It’s like they’re saying they’ve found and encapsulated the most productive development experience you could ask for and they’re going to shove it down your throat. You should give your hires the respect they deserve and treat them like professionals letting them use their own tools. Just give them a mac and let them do their thing.

TomatoTomato 5y ago
Or maybe it's a test. Give this script to a new hire and see if they run it without question or whether they actually read the script and pick and choose what they need or question what they don't understand.
heleninboodler 5y ago
Many companies have required sets of tools in order to do things like follow ops runbooks. Sure, you're a professional, but if you're following the team runbooks, you need to be doing it in exactly the prescribed way, meaning having your ssh access configured properly and the right version of python on your path, and any dependencies the shell scripts have, and rather than have you find and fix those one by one, a standard setup can save a lot of wasted time. Nobody's saying you can't use your own tools the way you want to, but you better be able to cope with having some team-specific tools and configs "shoved down your throat" or you really aren't a professional.

IgorPartola 5y ago

I am 100% with you. I did some consulting work for a startup that had this kind of thing. “Oh you are having trouble with our dev environment? We have a small script that will get you going.” Script turns out to install shit like Zoom, VS Code, Slack, reconfiguring paths, fucking up my dot files, installing and configuring Docker, etc. It was a mess and there was no reason for most of it and the parts that were needed were already broken. Even homebrew is a little too opinionated for me. If I could run some specific bits of Mac software on Linux I would never leave Ubuntu. apt is a joy to use by comparison to all this BS.

aspenmayer 5y ago
It’s fine to virtualize macOS on Apple hardware, so you could in theory run both via a hypervisor or boot Linux and virtualize macOS, or containerize macOS with Docker.
sirn 5y ago
I've worked on a project where its build script is reliant on the existence of Homebrew when a simple command -v would suffice. They have library paths, and everything hard-coded to Homebrew prefix. It has been such a colossal pain to modify all these scripts that I ended up installing macOS in a VM to build the project.
theodric 5y ago
MacPorts is based on apt. You might enjoy using that more than brew.
- hardlianotion 5y ago
  I think macports is based on bsd ports. One difference between macports and apt is that macports compiles everything from source, whereas apt gives you ready brewed binaries.
  - sirn 5y ago
    MacPorts has been doing binary packages since MacPorts 2.0 (2011). It will compile from source when binary package is unavailable (e.g., non-default variant or newer OS release).

LudwigNagasena 5y ago

> I'm a professional and take pride in knowing my tools. But some people aren’t professionals. They may be hobbyists or people who just entered the field. And the barrier to entry is becoming higher and higher with the rising importance of devops. It’s very daunting to try to get into a new tech stack and follow the best practices without much guidance.

unbanned 5y ago
Install vscode and away you go. I had an intern building a Java project in minutes with zero prior exposure.
- LudwigNagasena 5y ago
  I wonder how much time he would need to set up npm+typescript+Babel+webpack workflow for a fullstack development with shared modules between the FE and the BE without copying someone’s repository.
  - unbanned 5y ago
    Probably quicker than someone panicking trying to remember which key chord combination to press to disable some esoteric function which conflicts with another required plugin to satisfy their "leet coding keyboard only" dev env. Vscode does practically everything out of the box and prompts you to install context appropriate plugins which do everything.
- bryanrasmussen 5y ago
  I gotta admit I'm freaking out a bit at this statement.
  - drchickensalad 5y ago
    Why?

fmakunbound 5y ago

> and them saying "hey we've preconfigured emacs for you." Good god, that’s like wearing someone else’s dirty underwear.

solatic 5y ago

Really, it depends on what kind of company you're working for. If you're a BYOD place then sure, let people use their own tools, you have bigger fish to fry. If you're the place where your auditors require you to deliver proof that all your developers have antivirus installed then it's a different story. The minute you need to take away local administration rights from developers, the value of a standard development environment is immense. No more complaints about not having local administration rights. Plus, the value of hey, my laptop just broke, I ran down to IT, they swapped me out, go back to my desk, log in, and bam, my environment is right like how I left it is huge. Ultimately - professionals never blame their tools. The hammer handle might not have an ivory handle and tungsten head, but so what? This isn't what bottlenecks you in organizations. And if you really seethe at the thought of emacs being taken away from you, well, switch jobs. The vast majority of the engineering labor force doesn't even know what emacs is.

saagarjha 5y ago
Putting me in an environment I don’t want to use is easily going to make me several times less productive. I’m not going to blame those tools for reducing my effort, because I’ll put in the same amount, but I can absolutely blame them for not letting me work more productively.
- bottled_poe 5y ago
  This isn’t meant to be directed at you personally. Don’t be a vigilante. Either lead, follow or get out of the way. Most people just prefer to complain than create positive change though, because it’s less effort.
  - saagarjha 5y ago
    I'm not entirely sure what you mean?
    - dagw 5y ago
      When developers end up "in an environment (they) don’t want to use" they often have one of 4 different responses: 1) Say "I'm really sorry, but I cannot do my best work in this environment", and hand in their resignation. 2) Learn to work within the constraints given and find ways to be productive anyway. 3) Take on the responsibility of trying to work within the system and improve things. 4) Bitch and moan, get all passive aggressive, start working slower (to prove their point) and generally piss off their surroundings, spread negativity and tank morale. The point is that you should always pick some combination of 1-3, rather than 4. However 4 is by far the easiest and makes most people feel better about themselves so that is the one they tend to go for. It is also by far the most unprofessional, and reflects rather badly on you. Full disclosure: I may have done nr. 4 at some point in my career.

stephenr 5y ago

I would certainly consider anything that auto-installs Brew, a bunch of Electron apps, and Google app(s) to be harmful.

frereubu 5y ago

Mathias Byens' dotfiles repo is a bit like this - https://github.com/mathiasbynens/dotfiles https://github.com/mathiasbynens/dotfiles. It's highly opinionated, but I found it extremely useful as a starting point for setting up my own dotfiles. This repo seems simliar to me - the point is the sharing, not necessarily that you'd blindly run it without reading through it.

throwaddzuzxd 5y ago

> I'd rather follow steps in a document somewhere so I can ignore the steps I don't care about and share steps I find useful. I rewrote the onboarding documentation of my team and asked myself if I should script the tooling installation. I came with the same conclusion and just gave a list of tools to absolutely install (with a suggestion of how to install it, but do as you please) and recommended tools and extensions (+ why they're cool). I think this approach is especially useful for newbies who don't necessarily know the tools or how to install them. If anybody has an issue with their custom installation though, I redirect them to the onboarding recommendations.