Thursday, March 30, 2017

Simple effective way to take Docker backups

The title might seem contradictory for Docker noobs - backup Docker? What the..? While most people use Docker to achieve an immutable infrastructure there are many reasons why you would still need to backup your docker containers.

Let's say you are running MySQL on a docker container for instance. And let's also say that you are running a custom docker image and you are not using any docker repository to store this image. Furthermore, I will presume that your data volume is not ephemeral and you want to back it up as well.

The following code will backup the docker container and save it as an image for later reuse:

If you want to restore this docker image you can follow these steps:

What about data volumes? To list data volume mounts of a running docker container:

This means that /mysql_data inside container is mounted on the host's /var/mysql and we can simply backup this directory from the host.

Monday, March 20, 2017

Best way for effective Postgresql database backups

Unfortunately the Internet is littered with ineffective methods of backing up your precious PostgreSQL database. Most methods use the pg_dumpall technique - this is inherently faulty for mission critical databases as it only creates plain text backups which would limit the restore options.

A better way is to use custom format backups coupled with global data backups (such as user accounts, permissions, etc):


Friday, March 03, 2017

Deploying Apps on Github Pages

While CodePen.io is a great way to simulate web applications while in development, I find it more convenient to eventually deploy the Free Code Camp challenges to Github Pages. Examples of web applications I have deployed so far:
  1. Wikipedia Viewer
  2. JS Calculator
  3. Tic Tac Toe Game
  4. Pomodoro Clock
It’s really simple. Once you create a github pages account and create a new repository, just follow these steps to deploy the app on github pages:

Traverse JSON trees

I believe that knowing how to traverse JSON trees is an important skill to master, particularly when designing applications that consume complex JSON structures through API requests.

When I recently started playing around the epynomous Wikipedia Viewer challenge on Free Code Camp, traversing the wikipedia API tree was an important first step. While there are many techniques, I decided to go for a recursive function approach. Pay attention however as Javascript creates a stack for each recursive call...

The way this works is straightforward:

  1. For each JSON object determine whether it is a defined (bang bang!!) object.
  2. If it is an object, recursively call the function to traverse it.
  3. If it is not an object (example: array, string, value), then it must be a leaf node!

Take the Wikipedia API JSON tree as an example which looks like this:


The traverse function will iterate through each object, but for the sake of this example, scanning through the first object of the Pages object will look like this:



Thursday, February 09, 2017

How I fixed the OSX Sierra battery drain issue

tl;dr Boot to safe mode, restart after some minutes and you should be back to normal!

So a couple of days ago I decided to upgrade my flawless El Capital setup to Sierra OSX 10.12.3. You may say "Aren't you too late for the party?" and that is normally true if it were for other tech upgrades. However since I run on an old hardware (on a MBP 2010 with SSD drives and 4GB RAM) you would definitely emphatise with my conservative approach.

Direct upgrade was plain sailing and to be honest I thought Wow! I should have not been afraid of doing it earlier. But I soon realised that my battery was draining fast. Really fast. Usually I can squeeze between 2 - 3 hours on WiFi and document editing and browsing Safari, and perhaps a couple of days if on sleep mode. Now, after upgrading to Sierra, I was barely getting 45 minutes, and it was not sleeping well.

I tried the usual suspects, namely a PRAM and SMC restart to no avail. After hours of scouring all forums possible, I realised that I was not alone with this issue. Some suggested to go back to El Capitan while others even suggested to take a look at the Activity Monitor and turn off resource hungry apps. The latter did not make sense at all - I would imagine that native apps would be more optimised on a new OSX installation.

... That was until I came across a very unorthodox suggestion to boot into safe mode, use the system for a couple of minutes and then restart. I have an idea as to why, but it worked. I got my previous battery capacity back. These are some theories that I made that could have explained this resolution:

1. Orphan processes that were draining the battery were removed after booting to safe mode.
2. Orphan legacy drivers that were also draining the battery were either removed or fix following a safe boot.
3.  Pure coincidence and may have been a combination of resetting the PRAM/SMC and turning off transparency and the usual exotic display features.

What do you think?