Brian Maher

software developer

Read this first

Monitoring tools for *nix

There are many tools available on *nix for monitoring network traffic and system resources. Personally, I prefer ones with a bit of a graphical flavour; here are a couple of my favourites:

slurm
network monitoring

$ sudo apt-get install slurm
$ slurm -i eth0

slurm.png

htop
system resource monitoring

$ sudo apt-get install htop
$ htop

N.B. if running on OSX, you’ll need to use sudo htop

htop.png

Continue reading →


Bugs & Scrum

Bugs, those pesky errors that you didn’t foresee.

As defined by Wikipedia, a bug is:

… an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
– Wikipedia

Scrum, the process we all know and (some) love.

As defined by the the creators, Scrum is:

… a simple framework for effective team collaboration on complex software projects.
– scrum.org

What isn’t so well defined is when and how to document a bug whilst working in Scrum.
Most people will agree that bugs should be documented somewhere; the simplest being on a piece of paper, the more advanced being in an issue management system such as Bugzilla or JIRA.
Should you then document every bug you find during a sprint? I don’t think so, in fact I think doing so can be detrimental to your team.

Let’s look at the definition of a bug

Continue reading →


Cleanup after Docker

I often find myself in a situation where I have several redundant Docker containers and/or images; usually after development of a new container/image and forgetting to use a flag like run --rm.

Unfortunately, Docker doesn’t provide a built-in command to cleanup after itself.

Instead, one must call Docker’s remove commands with the output of Docker’s list commands.

To remove all containers:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

To remove all ‘untagged’ images:

docker rmi $(docker images | grep "^<none>" | awk "{print $3}")

Continue reading →