For setting up a Mac, I can't recommend a .osx file highly enough. Dot files in general make setting up a new computer really easy, especially when combined with homebrew's cask. I've been able to setup a familiar dev environment on a new machine in less than 15 min because I've maintained dotfiles. It's a relatively small time investment upfront and the payoff can be massive, especially if anything ever goes wrong on your main machine.
I use something similar, along with dotbot (https://github.com/anishathalye/dotbot) to wire up other application’s settings files. There’s lots of good examples around to steal and tweak.
Mackup (https://github.com/lra/mackup) is a great tool for this. Beware, however, that it creates symlinks in place of your existing files. So if you decide you don't like it, run the uninstall command before removing the Mackup folder or bad things will happen (I learned from experience).
Not to nitpick but TextMate and VS Code aren't even 'real' IDEs. They're text editors. The IDE aspect is added by installing plugins which a) mostly depend on the the needs of the user, and b) she didn't showed.
The one shipped by Apple on OS X 10.11.6 is 2.7.4, which was released in March this year. That's hardly "way outdated".
> Better off install the latest version using homebrew.
The Git project provides package to install binaries for OSX. Homebrew's name would be more accurate to the reality of the product if it's name was bathtub-whiskey.
Note that Git ships with Xcode, not part of OS X itself. Xcode 7.3.1 updated Git to v2.7.4. Xcode 8, likely to GM in the next month or two, includes Git v2.8.4.
As others have said, blinding executing a ruby script directly out of a GH repo is risky (to put it mildly). Sure, you have to have some trust in the whole infrastructure at some point, but the number of times I've seen this type of thing blindly posted and followed boggles my mind. Here is a post talking about the issue and pointing out non-malicious issues: https://www.seancassidy.me/dont-pipe-to-your-shell.html
I like homebrew-bundle [1]. It lets me list all of the apps I use in a text file and install them with a single command.
You can also run `brew bundle --cleanup` to purge your system of apps that you no longer need (as long as you installed them with homebrew/homebrew-bundle in the first place).
Step one is to install Xcode or the Xcode command line tools. These are necessary for brew to build from source.
Once brew and clang are working it's mostly a matter of installing packages as on a normal Unix system. Definitely want to install command-line git.
Of course what this guide is missing is how to set up the runtime for whatever environment/framework you're using. For Rails you'll want rvm/rbenv; for Node, nvm. You also may wish to test everything in a Linux VM that mirrors prod, in which case configuring your Mac to transfer or share the code jn your src directory with the VM is necessary.
Getting the actual dependencies of your code up and running is generally the most crucial -- and most difficult -- part of prepping any new dev box.
Using Docker, one could have various images made for whichever runtime environments you require. This way, no dependencies for running/compiling code need to be installed on a dev machine other than Docker and can be easily used from any machine with Docker, avoiding the hassle of setting up all of these dependencies.
But the problem ranted about above doesn't just apply to Macs. One of the most common things I see on our support system is the dev team who've built their app on Windows + XAMPP then wonder why stuff doesn't work the same when they deploy to their production CentOS box.
If you're writing any server side code you should be developing on a machine (or VM) that closely matches your production targets. Then there's no surprises.
37 comments
[ 4.8 ms ] story [ 74.6 ms ] threadI use something similar, along with dotbot (https://github.com/anishathalye/dotbot) to wire up other application’s settings files. There’s lots of good examples around to steal and tweak.
> ...
> Github — The essential version control system
git is the VCS. GitHub is a service ( website ) that provides git repositories.
OP, If you are looking at this, learn that GitHub Desktop is supposed to provide a graphical UI for some basic git operations (such as git clone).
You can install and use git without installing GitHub Desktop.
> Better off install the latest version using homebrew.
The Git project provides package to install binaries for OSX. Homebrew's name would be more accurate to the reality of the product if it's name was bathtub-whiskey.
http://rachelbythebay.com/w/2016/04/17/unprotected/
http://rachelbythebay.com/w/2016/05/05/xcode/
> Open a fresh terminal and enter this command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...
That said, I do it all the time like everyone else. :)
But anyway I got your point.
This is a good rant tho' https://medium.com/my-name-is-midori/software-development-is...
You can also run `brew bundle --cleanup` to purge your system of apps that you no longer need (as long as you installed them with homebrew/homebrew-bundle in the first place).
- [1] https://github.com/Homebrew/homebrew-bundle
Once brew and clang are working it's mostly a matter of installing packages as on a normal Unix system. Definitely want to install command-line git.
Of course what this guide is missing is how to set up the runtime for whatever environment/framework you're using. For Rails you'll want rvm/rbenv; for Node, nvm. You also may wish to test everything in a Linux VM that mirrors prod, in which case configuring your Mac to transfer or share the code jn your src directory with the VM is necessary.
Getting the actual dependencies of your code up and running is generally the most crucial -- and most difficult -- part of prepping any new dev box.
http://widgetsandshit.com/teddziuba/2011/03/osx-unsuitable-w...
But the problem ranted about above doesn't just apply to Macs. One of the most common things I see on our support system is the dev team who've built their app on Windows + XAMPP then wonder why stuff doesn't work the same when they deploy to their production CentOS box.
If you're writing any server side code you should be developing on a machine (or VM) that closely matches your production targets. Then there's no surprises.
https://github.com/thoughtbot/laptop
https://github.com/asuh/front-end-osx