Setting up Homebrew, Node, Bower, Grunt & more

We use a variety of Homebrew, Node, NPM, Bower, Grunt and Compass in the majority of our web-apps to aid us with managing our packages and dependencies. From having messed this process up on my machine numerous times now, I am going to document this process so that it may help others in the future, as the Internet was not the most useful of places when I was trying to sort this out by myself. Luckily a colleague has saved the day for me numerous times, so to avoid annoying him further, here is our process 🙂

Note: This process is just to set up a clean install on our machines – I will explain further in another post how to get all of this working within a specific project.


Step 1 – Install Homebrew

$ ruby -e “$(curl -fsSL”

Homebrew installs packages and then links their files for you. It is very important that you do this step before anything else so that you can then install packages through Brew, to save having symlink problems later on due to duplicate versions being installed. Install Brew wherever you like.

Step 2 – Install node

$ brew install node

Node.js is a platform built on Javascript’s runtime, great for building real-time applications. When you install node, it comes with npm, its package manager. Npm is great – through this we can install bower, grunt as well as many others that may be needed for future applications.

$ node -v

$ npm -v

Run these commands just to check that your current versions are up to date.

Step 3 – Install Bower

$ npm install -g bower

Bower is another package manager that manages your libraries, frameworks etc. This command will install Bower into your node_modules. Use  a bower.json file to list your packages and the versions that you want – Bower will take care of the rest.

Step 4 – Install Grunt

$ npm install -g grunt-cli

Grunt is a js task runner. Configure a gruntfile.js to automate your tasks using the many plugins available. This makes unit testing, real-time changes and minification so much easier. This task also installs the grunt command line interface.

Step 5 – Install rvm

RVM manages your rubies and shows which ruby your current shell points to. This step may vary for different people. You may need to install gpg (this verifies signatures and publishers) as Mac OSX doesn’t do this for you. If this is the case install it through brew:

$ brew install gnupg gnupg2

Once you have this verification step set up, you need to install this public key necessary for rvm:

$ gpg –keyserver hkp:// –recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

Then you can run the command for installing rvm. If the above steps are already configures, you can skip straight to this:

$ \curl -sSL | bash

To start using rvm, when the last command has finished running, you should see something like “* To start using RVM you need to run `source /Users/UserName/.rvm/scripts/rvm` in all your open shell windows, in rare cases you need to reopen all shell windows.” so run:

$ source /Users/UserName/.rvm/scripts/rvm

Now we need to install some rubies, as we currently will only have the OSX ruby, which requires sudo (NEVER do a sudo – if you need to sudo, something is wrong with your setup). To see available rubies:

$ rvm list

And no rubies should be installed yet.

$ rvm install ruby

To install your rubies.

$ which ruby

Shows your installed rubies – should show rubies in your user path. Now that there is an rvm ruby installed, you own it and can ‘gem-‘ install things without needing to sudo. If these steps hadn’t been done, you would have got an error saying you didn’t have access when trying to gem- install things.

Step 6 – Install compass

$ gem install compass

Installs a gem for compass.

$ npm install compass

Installs compass using npm into your node_modules.

Step 7 – Install selenium

$ brew install selenium-server-standalone

Selenium is needed for automating your web browsers for when you run your tests. If you don’t have tests or think you don’t need this, then wrong – write some tests for your code!

Step 8 – Install chromedriver

$ npm install chromedriver

A wrapper for selenium – also needed for running your tests.

Step 9 – Install Protractor

$ npm install -g protractor

We use Angular, so this is needed for running our end to end tests in the browser. If you don’t user Angular, you won’t need this. Highly recommend using Angular though – it’s awesome. This will install cl protractor and webdriver-manager.

$ webdriver-manager update

Download the binaries to get selenium running.

$ webdriver-manager start

Start up a selenium web server. You may get a pop-up requesting that you download a Java JDK to use the cli. Do this if you haven’t already done so.

Will update some more later to show how to link all this up to your projects to get them running, if you can’t figure it out yourselves 🙂


Merge Conflicts From Branch To Branch On Github

Occasionally, there will be a time when you are merging one branch into another on Github (in our case, develop into staging, as our branch hierarchy goes newBranch(es) -> develop -> staging -> master *) and although it may seem scary when that grey box appears, it isn’t difficult to fix. In the example below, we are pushing to develop from staging:

git checkout develop
git pull origin develop
git checkout staging
git status (all should be up to date).
git merge develop
git mergetool (then press 'enter', fix the conflict using the mergetool, save and close, then type 'y' when prompted).
git status (should show you the changed file ready for committing. There may be a '.orig' file duplicated of the file with the conflict - this can be deleted).
git commit -m "Fixed merge conflicts"
git push origin head

This should solve any problems, unless you’ve got a complicated merge on your hands.

* our branch structure is this way not only to avoid merge conflicts and issues, but to fit in with stakeholders’ features. Each branch has to be merged into develop then deleted. Each contributor will be pulling from develop just in case there are any changes. After develop is ready to be shown to stakeholders and test users, with stakeholder warning and approval, develop is pushed into staging. Only after the stakeholder has approved of the changes in staging can staging go into production (master). The main thing we have to be careful of with this is possible problems when the stakeholder doesn’t like a feature in staging, when someone has already pushed another new feature into develop. To avoid this, all contributors have their own branches to work on, and only push to develop when a staging feature has been approved and is being pushed to develop. All the while that they are working on their features, they are pulling from develop to stay up to date.