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.
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.
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 'https://rubygems.org' gem 'nokogiri' gem 'rails', '3.0.0.beta3' gem 'rack', '>=1.0' gem 'thin', '~>1.1'
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
Gems are installed using a program called Bundler.
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:
GEM remote: https://rubygems.org/ specs: 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) PLATFORMS ruby DEPENDENCIES bootsnap (>= 1.1.0) byebug capybara (>= 2.15) chromedriver-helper coffee-rails (~> 4.2) jbuilder (~> 2.5) listen (>= 3.0.5, < 3.2) puma (~> 3.11) rails (~> 5.2.1) rspec-rails RUBY VERSION ruby 2.5.1p57 BUNDLED WITH 1.16.3
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 –
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.
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
$ git init
Create repo on Github
Click new repo
Get address of Git
Get SSH address (with colon after github.com)
$ git remote add origin firstname.lastname@example.org:makersacademy/gitname.git
echo "some text" >> README.md git init git add README.md git commit -m "first commit" git remote add origin email@example.com:makersacademy/gitname.git git push -u origin master
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.
Install all tools from here.
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
cd ~/Projects mkdir nameofproject cd nameofproject git init gem install rspec
Copyright 2021. All Rights Reserved. Adam Patel