How To Safeguard Your CSS Layouts

Yesterday evening, I left my laptop unattended with a stylesheet I’d been playing with open on the screen. This stylesheet is several months old and contains more than 500 lines of code. When I got back to the desk, I must have just saved, closed and moved on with my evening. The problem? Did I mention I have cats?

This morning, when I loaded the page, I realised it was slightly uglier than I remembered. Furthermore, there seemed to be changes in lots of places that just looked less refined than they had before. It irritated me. And my only conclusion is that one of the cats walked over the keyboard. I have seen this happen many times so I know it’s possible.

I have checked over the code by eye and cannot find any of the usual hallmarks of cat footprints in the code. Things like


So what now?

Fixing something like this is difficult by sight. Especially when we consider that some of the divs in play, themselves contain multiple other divs.

This is when I thought about a CSS testing framework. My time at Makers recently has taught me about things like Rspec and Jasmine for Ruby and Javascript. Maybe there’s one for CSS?

A google search uncovered BackstopJS, which I think does exactly this – makes sure CSS requirements remain satisfied when your pesky cat walks across the keyboard and can tell you where in the file the problems are when they don’t.

I may write more about this as I figure out how to use it.

What Is A Ruby Gemfile?


What Is A Ruby Gemfile?

A Gemfile is a file we create which is used for describing gem dependencies for Ruby programs. A gem is a collection of Ruby code that we can extract into a “collection” which we can call later. It lets you specify which gems you want to use, and which versions of these gems to use.

Simple example of a gemfile:

source ''
gem 'nokogiri'
gem 'rails', '3.0.0.beta3'
gem 'rack',  '>=1.0'
gem 'thin',  '~>1.1'

Where Do You Put A Gemfile?

Place the Gemfile in the root of the directory containing the associated code. For instance, in a Rails application, place the Gemfile in the same directory as the Rakefile.

Gems are installed using a program called Bundler.


The Gemfile.lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.lock and install the exact same versions, rather than just using the Gemfile and installing the most recent versions.

Bundler provides a consistent environment for Rubyprojects by tracking and installing the exact gems and versions that are needed. Bundler is an exit from dependency hell, and ensures that the gems you need are present in development, staging, and production. Starting work on a project is as simple as bundle install .

Running different versions on different machines could lead to broken tests, etc. Never directly edit the lock file.

Exmple of Gemfile.lock:

    actioncable (5.2.1)
      actionpack (= 5.2.1)
      nio4r (~> 2.0)
      websocket-driver (>= 0.6.1)
    actionmailer (5.2.1)
      actionpack (= 5.2.1)
      actionview (= 5.2.1)
      activejob (= 5.2.1)
      mail (~> 2.5, >= 2.5.4)
      rails-dom-testing (~> 2.0)
    actionpack (5.2.1)
      actionview (= 5.2.1)
      activesupport (= 5.2.1)
      rack (~> 2.0)
      rack-test (>= 0.6.3)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.2)
    actionview (5.2.1)
      activesupport (= 5.2.1)
      builder (~> 3.1)
      erubi (~> 1.4)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.3)
    activejob (5.2.1)
      activesupport (= 5.2.1)
      globalid (>= 0.3.6)
    activemodel (5.2.1)
      activesupport (= 5.2.1)
    activerecord (5.2.1)
      activemodel (= 5.2.1)
      activesupport (= 5.2.1)
      arel (>= 9.0)
    activestorage (5.2.1)
      actionpack (= 5.2.1)
      activerecord (= 5.2.1)
      marcel (~> 0.3.1)


  bootsnap (>= 1.1.0)
  capybara (>= 2.15)
  coffee-rails (~> 4.2)
  jbuilder (~> 2.5)
  listen (>= 3.0.5, < 3.2)
  puma (~> 3.11)
  rails (~> 5.2.1)

   ruby 2.5.1p57




Most of this post is lifted directly from Gemfile & Gemfile.lock in Ruby by David Pargal, because I found it to be a very good and comprehensive article for beginners. Why copy it? Simply because the Internet is a dynamic place and for the benefit of my learning, I’d hate for the original source to disappear from the Internet, which, of course, I have no control over.

Other bits –

The Command Line: A Love Hate Relationship

So, since Week 1 of Makers, my feelings towards the command line are changing. In week 1, I likened it to a printer – often doesn’t do what you want or expect of it, but never actually tells you in plain English what’s wrong with it, either giving you a cryptic message or more often preferring to remain completely silent.

Now, I’d say, you just have to know how to use it. It’s like one of those old cars that the piston-head owner is completely in love with, while most normal people think it is primitive and temperamental.

I can completely see why PCs never really took off until Microsoft and IBM found a solution to the problems of the direct operating system. I just feel like it could do with giving more feedback. I want to know when I’m on the right track without having to constantly ask.

The rule seems to be that if it doesn’t issue you with an error message, then the computer is happy. But that doesn’t mean I will necessarily be happy? It’s like speaking to somebody in a foreign country: I know I said something in their language but I swear the train station is the other way!?

But while all that is true, for a lot of things, it’s extremely nifty.

For everything the mouse did for graphical interfaces, ultimately making computing accessible to the masses, it still introduced the irritation of having to point a cursor into a text area, for example, and then moving your hand to the keyboard to type in it.

If you master the command line, a lot of that goes away. The only catch is that you do need a good command of shell script so that you can tell it exactly what you want it to do, and accuracy is vitally important.

I guess what I’m trying to say is that I’ve grown used to the command line under certain circumstances – maybe even developed an admiration for it. And that’s probably a good thing, because from what I’ve learned so far, as a software engineer, I’ll be spending a lot of time with it whether it annoys me or not.


How To Setup A Git Repository

Every new project should be connected to a remote git repository for a number of reasons including protection from loss and version control.

Create project folder on local computer from command line

$ cd ~/Projects
$ mkdir nameit
$ cd nameit

Make git

$ git init

Create repo on Github

Click new repo

Get address of Git

Get SSH address (with colon after

Create remote

$ git remote add origin

In summary…

echo "some text" >>
git init
git add
git commit -m "first commit"
git remote add origin
git push -u origin master

Dev Tools: How To Setup A Development Environment

I thought it might be an idea, mainly for personal use, to keep notes on my system setup for my development environment.

Undoubtedly, at some point in the future, there will be a time when the laptop on which I’m writing this dies – probably suddenly and without warning – and I’m required to replicate the setup on a new machine.

Essential tools

Install all tools from here.

GitHub commands

To push to repo, line one puts file in staging area, line 2 commits it, line 3 sends it to the repo.

$ git add file
$ git commit -m "message here"
$ git push -u origin master

RSpec – for testing code. Rspec should be installed in the root directory of any given project.

$ gem install rspec

In Summary

cd ~/Projects
mkdir nameofproject
cd nameofproject
git init
gem install rspec

Copyright 2021. All Rights Reserved. Adam Patel