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!
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.
Usage: 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’.
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.
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.
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!