Ok, so what’s a favicon? Possibly my new favourite little bit of code, favicons are the images that display in browser tabs.

You probably recognise most of those icons, right? They’re a quick and easy visual way for a user to orient herself while using the browser.

So I present to you my guide to adding a favicon to a Rails app.

Step 1:
Find the image or logo you want to use as a favicon. Save it to your rails project’s public folder.

Step 2:
Go to your favourite favicon generator online — I quite like Favicomatic. Upload your image and save it as favicomatic.zip (or whatever yours is called) to your public folder. (I already had a favicomatic.zip folder, which is why mine has the (2)).

Step 3:
Grab the HTML code from the website (there are two sizes to choose from) and paste it to your application.html.erb file, just under the title.

Step 4:
Open the favicon folder (here renamed from favicomatic(2) to favicon.zip) in the finder so you can unzip it. It’ll appear as an unzipped folder in your project. Delete the zipped version. Note that the folder MUST be called favicon for Rails to find it.

Step 5:
Refresh your browser and admire your favicon!

PS Hawk-eyed readers will notice that I named this ‘starfleet logo’ in Step 1. Apparently I am unable to tell Star Trek and NASA apart.

I’ve been writing up a lot of little Node projects recently and there’s a few npm packages I’ve come to rely on for code quality. I figured I’d write them up so others can use them. I’d also love to hear from you about the packages you consider essential for npm, so please leave a comment!

Pre-commit hook

A pre-commit hook is essential to enforce your code standards before committing. While CI tools mean you can and should run your checks on the build, it’s best practice to run before commit — vastly lessening the chances of errors making it into your repo.

I’ve used pre-commit very happily in my projects, although there are other tools as well.

I have configured it to run my code coverage tool (see below) and eslint. I deliberately removed some of the test coverage, and tried to run git commit -m ‘pre-commit demo’.

Commit failed since my test coverage was not high enough.
Proof that the commit failed — latest commit is not the one I tried.


At first, eslint is the biggest pain in the ***. But with a little bit of configuration and patience, you’ll find that it does way more than make your code cleaner: its rules about the code itself mean you will learn so much about JavaScript, particularly if you are new to ES6. Configure it to run on your pre-commit hook to get the full benefit.

Note `unusedVar` on line 7.
We get these errors.

The first few times you use it, you’ll find it slows you down. However, the benefits become apparent pretty quickly.

You can also configure it pretty easily as needed, and even choose a popular style guide so you don’t have to spend too much time yourself. Run eslint — — init to kick off the configuration.

Recommended Resources:

AirBnB’s style guide for eslint — really interesting reading.

JSJ 336: “The Origin of ESLint” with Nicholas Zakas — great podcast

NYC — code coverage tool

Why a code coverage tool? First of all, to enforce test coverage. I have it set to 95% and I can’t make a commit if I don’t have that amount of coverage. However, it’s also super useful when refactoring tests to make sure you haven’t accidentally removed the only test covering a particular line of code.

Message from NYC.

As you can see, the messages are very helpful, particularly which lines are uncovered. I can pinpoint exactly where I need to sort out the tests. Make sure to tell it to exclude the test files so you don’t get stuck in an infinite loop of coveage errors!

Recommended Resources:

NYC npm package


Automate whatever you can, including your code quality tools. It’ll drive you up the wall at first but it’s worth it. If you want to see these tools in action, check out my CocoaJavaScript repo (currently a work in progress to create parameterised testing in JS/Mocha).