Everything comes to an end. It’s inevitable, but there is a feeling of sadness when things are left abandoned without any closure.

It’s been 12 years since I started this blog, and shy of 5 years since I haven’t updated it, after my role at work evolved to be more managerial, my free time reduced dramatically, and the topics I became interested in drifted away from programming, thus were not really a good fit for this blog. Burnmind was a great experience; I met lots of people — which led to amazing opportunities, I expressed my creativity, and I learned so many things while working on it.

I always had at the back of my mind that I’ll resume writing here at some point, but it was not meant to be. I feel the need to write, but instead of pivoting this blog into a new direction, I’ll let it go, and start fresh on a new blog section on my personal site. I’ll keep Burnmind online though, since it’s an important part of my journey.

Farewell, my good friend!

Photo by Peter Bardell

The other day, I took a sip from a carbonated lemonade drink. While taking that sip, just for a split second, it was summertime and I was again a little boy in the small village where my grandparents lived, drinking a lemonade that my grandmother gave me. And I could feel everything. The taste, the sun, the wind, the presence of my grandmother…

Thanks brain! :-)

This story was originally published as part of my newsletter’s editorial and was also published on medium.

Comic strip by Lunarbaboon.

Phaser has a built-in function (i.e. setDragLock) that restricts a sprite’s drag movement only on a given axis (i.e. either horizontal or vertical). There are cases though that you want to allow a sprite to move both horizontally and vertically, but not allow movement to any other directions.

I ran into a situation like that a few days ago, while building -just for fun- a match-3 type game (like Bejeweled and Candy Crush Saga). Although I ended up making the tiles clickable instead of draggable, I managed to find a workaround that would restrict movement to both axis.

Before we dive into the code, have a look at this demo to understand what we are about to build. All four squares are draggable; square 1 can be dragged freely in all directions; square 2’s movement is restricted to the horizontal axis; square 3’s to the vertical axis; and finally square 4’s to both axis.

The HTML/CSS part is very simple, therefore I’ll omit it; you can always have a look at the source code. Since what we’re going to build is a small proof of concept, we will use a very simple Phaser setup without different states, etc. Let’s start by initialising Phaser and the basic functions we’ll use.

window.onload = function() {
    //Initialise Phaser
    var game = new Phaser.Game(800, 600, Phaser.AUTO, 'gameContainer', {
        init: init,
        preload: preload,
        create: create
    });

    //Set some configuration values
    function init() {
        this.input.maxPointers = 1;
        this.stage.disableVisibilityChange = true;
        this.scale.scaleMode = Phaser.ScaleManager.SHOW_ALL;
        this.scale.maxWidth = 800;
        this.scale.maxHeight = 600;
        this.scale.windowConstraints.bottom = "visual";
        this.scale.pageAlignHorizontally = true;
    }

    //Preload assets
    function preload() {
        this.load.image('square_1', 'images/square-1.jpg');
        this.load.image('square_2', 'images/square-2.jpg');
        this.load.image('square_3', 'images/square-3.jpg');
        this.load.image('square_4', 'images/square-4.jpg');
    }

    //Add assets to the game
    function create() {}
};

In the init function, we set some configuration values for the game, i.e. its maximum height and width, its scale mode, etc., and in the preload function we load the assets we’ll use in the demo. In the create function we’ll add the assets in the game, but we’ll get to that towards the end of the tutorial.

To make things easier, we’ll include all the logic for a square in a class-like function called Square. Note that functions/variables which are declared using the var keyword in front of them are only accessible within the Square function.

function Square(newOptions) {
    var options = {};
    var defaultOptions = {
        phaser: null, //an instance of Phaser
        assetKey: '', //the asset's key
        x: 0, //x position
        y: 0, //y position
        dragType: '', //type of drag movement allowed
        bounds: null //an instance of a Phaser Rectangle
    };

    var extend = function(out) {
        //source: http://youmightnotneedjquery.com/#extend
    };
    options = extend({}, defaultOptions, newOptions);

    var square = null;
    var initCursorPositionX = null;
    var initCursorPositionY = null;
    var lockedAxis = false;

    this.init = function() {}
    var dragUpdate = function() {}
    var dragStop = function() {}
}

We have a set of default options stored in the defaultOptions object. We combine those with the newOptions object that we pass when we create a new Square object. To merge them giving “priority” to any values stored in newOptions, we use the extend function. Its functionality is identical to jQuery’s extend function and was taken from here, just to avoid loading jQuery solely for one function.

this.init function will be called from Phaser’s create function (thus the declaration using this) to initialise the square. dragUpdate and dragStop will be called based on the square’s drag events. The four variables will be used inside those functions (we’ll see how while we discuss them). Let’s start with this.init:

this.init = function() {
    //create the sprite
    square = options.phaser.add.sprite(options.x, options.y, options.assetKey);

    //enable input
    square.inputEnabled = true;

    //change the cursor to the hand version on hover
    square.input.useHandCursor = true;

    //enable drag
    square.input.enableDrag(false, true);

    //restrict dragging within the Phaser rectangle (in our case it covers the whole visible screen)
    square.input.boundsRect = options.bounds;

    //restrict dragging movement based on selected drag type
    switch (options.dragType) {
        case 'horizontal':
            square.input.setDragLock(true, false);
            break;
        case 'vertical':
            square.input.setDragLock(false, true);
            break;
        case 'both':
            square.events.onDragUpdate.add(dragUpdate, this);
            square.events.onDragStop.add(dragStop, this);
            break;
    }
}

Most of the function is pretty basic; we create the sprite, enable dragging, and restrict its dragging bounds. That part is common for all of our squares. Their difference lies in the value of options.dragType.

When there is no dragType selected (that will be the case for square 1), no restrictions will be placed and the square can be dragged freely within the bounds; note that we don’t have a default case in our switch statement. In horizontal and vertical cases, we utilise Phaser’s build-in setDragLock function to restrict movement to either axis.

To be able to restrict the dragging movement to both axis (based on the position we started dragging from), we apply two events on our sprite; onDragUpdate which will be constantly fired while the sprite is being dragged, and onDragStop which will be fired once when the dragging stops.

The idea is that we want to allow the player to move the sprite to any direction for a few pixels, just enough to allow us to determine the axis she wants to move the sprite on. As soon as we do, we will lock the movement to that axis using Phaser’s setDragLock function.

var dragUpdate = function() {
    //if we already locked to either axis, then exit
    if(lockedAxis) {
        return false;
    }

    //if we don't have a record of the initial cursor's position when it started dragging, grab one and exit
    if(initCursorPositionX === null || initCursorPositionY === null) {
        initCursorPositionX = options.phaser.input.x;
        initCursorPositionY = options.phaser.input.y;
        return false;
    }

    //calculate the absolute difference between the initial cursor position and the current one for both axis
    var differenceX = Math.abs(initCursorPositionX - options.phaser.input.x);
    var differenceY = Math.abs(initCursorPositionY - options.phaser.input.y);

    //allow at least one of the axis to move 5 pixels before restricting movement to either
    if(differenceX < 5 && differenceY < 5) {
        return false;
    }

    //if the cursor moved a greater distance in X-axis than in Y-axis, then restrict dragging horizontally
    if(differenceX > differenceY) {
        square.y = options.y;
        square.input.setDragLock(true, false);
        lockedAxis = true;
        return false;
    }

    //alternatively, restrict dragging vertically
    square.x = options.x;
    square.input.setDragLock(false, true);
    lockedAxis = true;
};

//reset values and store new X & Y coordinates
var dragStop = function() {
    initCursorPositionX = null;
    initCursorPositionY = null;
    options.x = square.x;
    options.y = square.y;
    lockedAxis = false;
};

As the dragUpdate function will be constantly called during the dragging, we want to keep some values outside of it; this is where lockedAxis, initCursorPositionX, and initCursorPositionY variables are used. The first thing to do in the function is to determine if we already locked the movement to either axis. If that’s the case, then there is nothing else to do, and we exit. If we ​haven’t locked the movement, we check if we have stored the initial X & Y coordinates of the cursor. If we haven’t stored the coordinates already, we store them and exit.

As soon as we have that information, we calculate the absolute difference between the initial cursor position and the current one for both axis. We wait until one of those values is at least 5 pixels, and then we determine which one is greater than the other. If the cursor has covered more distance on the X-axis, we restrict dragging horizontally, alternatively we restrict dragging vertically.

Finally, in the dragStop function we reset the cursor position and lockedAxis values and we store the new X & Y coordinates of the sprite so we can be ready for the next drag action. The only thing left to do is to create and initialise our squares. Let’s do that in our create function:

function create() {
    //this is used to restrict dragging within the visible screen
    var bounds = new Phaser.Rectangle(0, 0, 800, 600);

    var square1 = new Square({
        phaser: this,
        assetKey: 'square_1',
        x: 96,
        y: 56,
        bounds: bounds
    });

    var square2 = new Square({
        phaser: this,
        assetKey: 'square_2',
        x: 272,
        y: 192,
        dragType: 'horizontal',
        bounds: bounds
    });

    var square3 = new Square({
        phaser: this,
        assetKey: 'square_3',
        x: 448,
        y: 328,
        dragType: 'vertical',
        bounds: bounds
    });

    var square4 = new Square({
        phaser: this,
        assetKey: 'square_4',
        x: 624,
        y: 464,
        dragType: 'both',
        bounds: bounds
    });

    square1.init();
    square2.init();
    square3.init();
    square4.init();
}

We’re done! Here’s what we’ve just built. You can download the source code of this tutorial from this Gist.

Podcasts became popular again in recent years, and there are some really great ones out there. I compiled a list which contains some of the podcasts I regularly listen to. Without further ado, and in no particular order (well, they are actually in the order they were featured in my newsletter), here’s the list:

Bootstrapped →

As the title suggests, it is a podcast about bootstrapped startups, where its hosts (Ian Landsman and Andrey Butov) discuss about their startup adventures. Just to warn you, during their discussions, they sometimes go off-track (e.g. talking about movies), but that helps the show to develop its own unique character.

Freelancers’ Show →

Initially called “The Ruby Freelancers Show”, it later rebranded to a more generalised resource for freelancers. The podcast features discussions between freelancers on the topics of running a business, finding clients, marketing, etc. Also, at the end of each show, the panellists pick items that they enjoy or that make freelancing easier.

Giant Robots Smashing Into Other Giant Robots →

The Giant Robots Smashing into Other Giant Robots podcast is a weekly technical podcast discussing development, design, and the business of software development.

Seth Godin’s Startup School →

A few years ago, Seth Godin hosted a small startup school spending a few days with a number of startup founders, discussing startup-related topics. He recorded these discussions and released a selection of them in the form of an extremely interesting fifteen episode podcast.

Chasing Product →

Chasing Product is a podcast which aims to help freelancers and consultants transition from client work to launching bootstrapped software products.

Bootstrapped Web →

As its title suggests, Bootstrapped Web is a podcast focusing on (existing or aspiring) founders of bootstrapped online businesses, covering most of the topics you would expect from such a podcast.

Launch →

Launch is a two hour audio documentary which follows the two creators (Rob Walling and Derrick Reimer) of their startup (which is called Drip) “from its first days of inception through the agonizing months of writing code, talking to customers, and the never-ending uncertainty of whether anyone will ever use what they are building”.

The Five-Minute Geek Show →

The Five-Minute Geek Show is “a twice-weekly show about web development and everything around it. It’s one topic per episode about front-end, back-end, mobile, project management, design, entrepreneurship… Whatever; if it’s geeky, it fits!”

I really like this podcast. Its episodes are between 5 and 10 minutes, so they are short and easy digestible, and I find most of the topics so far quite interesting. I discovered it around episode 25 and I listened to all of the available episodes at that point within a couple of days.

Full Stack Radio →

Full Stack Radio is a podcast for developers interested in building great software products. In each episode, Adam Wathan (the show’s host), talks to people in the software industry about everything from user experience and product design to unit testing and system administration.

The Laravel Podcast →

The Laravel Podcast brings you Laravel and PHP development news and discussion. The podcast is hosted by Matt Stauffer (host of the Five Minute Geek Show) and its regular guests include Taylor Otwell (the creator of Laravel) and Jeffrey Way.

The Consulting Pipeline Podcast →

The Consulting Pipeline Podcast, is hosted by Philip Morgan and is focused on building your consulting pipeline through positioning, education-based content marketing, and marketing automation.

Laravel News Podcast →

The Laravel News Podcast brings you all the latest news and events related to Laravel. You can think of it at an audio version of the Laravel News newsletter.

Want more?

A few years ago, I published a similar list of podcasts. Check it out; some of them are still active. You should also subscribe to Equilibrium, my monthly newsletter, where I regularly feature other interesting podcasts.

Photo by Brian Steele.

If you have been participating in any kind of community, you most likely encountered or even took part in a flame war regarding which tool to use for a specific thing. Code editors, frameworks, image manipulation tools, you name it.

Although I’m guilty of participating in such discussions in the past, I consciously stay out of them for several years now. That decision mostly stems from my belief that the best tool for a job is usually quite subjective.

I do like to mention the tools I use (as I occasionally do in this blog or on my newsletter) and read what other people prefer to use, but I don’t get dragged into arguments about which one is better.

This is what I tell people when I find myself involved in such discussions:

Use whatever you feel comfortable with. When you want to experiment, do it by all means, but don’t feel bad and obliged to use the new “hot” thing in the industry if you still can do the job quickly, efficiently, and with the same quality with the tools you are already familiar with.

In the bottom line, tools only matter to us, the engineers. The end users have no idea of the mechanics of how something was built and they don’t care about them; they only perceive the end result.

This story was originally published as part of my newsletter’s editorial.

Photo by Rudolf Vlček.

I recently launched a new web app called PriceAlert, which is a service that provides price tracking and price history charts for some of the most popular e-commerce stores operating in Greece.

Its UI is written in Greek, so I believe that unfortunately most of you won’t be able to navigate through it. Therefore, here’s a direct link to a product I chose randomly so you can see how a product page looks like. At the bottom of it, you can find the price history chart.

Why?

Around two and a half years ago, I needed to buy something from Greece. Being a camelcamelcamel (a price tracker for Amazon) user for years, I searched for a similar service focused on Greek e-shops, but I couldn’t find one. So, as an interesting side-project, I decided to build an automated system which would track the price of specified products and it would notify me when they reached a certain threshold.

I quickly decided that I wanted to share it with other people, so I created a basic UI, bought the domain, installed the system to a server, and decided that after some changes that wouldn’t take more than a few days I would release it.

Those few days quickly became weeks, then months, and eventually years. I never considered it as one of these projects that I would let go though, so it might have taken a while, but a few months ago I decided to spend some time on it so it could be released to the public, which happened on November 1st.

How?

Moving to the technical side, the back-end code that powers everything related to the user’s interaction with the site is still part of the original code built in mid-2013 using CodeIgniter. As a login system, it uses my own PasswordLessLogin library.

The system which automatically handles -among other tasks- the product updates, price changes, and email notifications though, is a Laravel 5.1 application. All transactional emails are sent through Mandrill.

Most of the front-end code is dated, since it was built using Bootstrap 2.3.2 (yeap, that was the most recent stable version back then), and the Flat UI and Font Awesome versions that it supported. The price history charts are generated using Highcharts; I also used Responsive-Lightbox in a few places.

Finally, PriceAlert is deployed on a DigitalOcean* server, managed by Laravel Forge. The CodeIgniter and Laravel apps are deployed as different domains, which share the same database.

*If you want to try DigitalOcean out, sign up using this link and you’ll get $10 in credit for free.

This small tutorial covers the task of creating a shell script that will automatically backup a MySQL database to a set of AWS S3 buckets.

The backup plan

For my project’s needs, I needed three sets of complete database backups (i.e. without excluding any table), running on different frequencies: daily, weekly, and monthly.

At any given point of time, I need to have access to the latest 7 daily, 4 weekly, and 12 monthly backups.

The idea is to create a shell script that will run on regular intervals (i.e. daily, weekly, and monthly) using cron jobs which will create database backups saving them in a set of local folders, which will then be synchronised to the relevant S3 buckets.

Amazon S3 setup

Obviously, you need to have an AWS account. You also need to create an IAM user (remember to store the credentials) that will have access to the S3 service.

Then, you need to create one or more S3 buckets to store the backups. I decided to store each type of backup in a separate S3 bucket, so I created the following three buckets:

1. projectname-daily-db-backup
2. projectname-weekly-db-backup
3. projectname-monthly-db-backup

Server Setup

Moving to your own server now (by the way, my server runs on Ubuntu 14.04), you need a way for our server to communicate with S3, so install the AWS Command Line Interface and then run aws configure to set up the credentials of the user you just created. You can verify that you have access to your S3 account by running aws s3 ls, which should show you a list of your S3 buckets.

After you are done with that, you need to create some folders where the backups will be saved. For my needs, I created the following set of folders:

1. /usr/database_backups/daily
2. /usr/database_backups/weekly
3. /usr/database_backups/monthly

Remember to change the owner of the folders to the user/group who will run the scripts. For my setup, the user/group is called forge, so I run the following command:

sudo chown -R forge:forge /usr/database_backups

Shell script

Create a file, give it a name of your preference (e.g. db_backup.sh), and paste the following commands. Don’t forget to add your database name and credentials in the appropriate variables, as well as to modify the paths based on your server and AWS setup. Also, remember to make it executable: chmod +x db_backup.sh

#!/bin/sh

DB_NAME=""
DB_USERNAME=""
DB_PASSWORD=""
BACKUP_DATE=`date +%d%m%y%H%M`

case $1 in
"daily")
    DAYS_TO_DELETE=7;;
"weekly")
    DAYS_TO_DELETE=31;;
"monthly")
    DAYS_TO_DELETE=365;;
*)
    exit 0;;
esac

# export database
mysqldump -u ${DB_USERNAME} -p${DB_PASSWORD} ${DB_NAME} | gzip > /usr/database_backups/${1}/db_backup_${DB_NAME}_${BACKUP_DATE}.sql.gz

# remove local backups older than $DAYS_TO_DELETE days
find /usr/database_backups/${1}/db* -mtime +${DAYS_TO_DELETE} -exec rm {} \;

# synchronise relevant AWS S3 bucket
/usr/local/bin/aws s3 sync /usr/database_backups/${1} s3://projectname-${1}-db-backup --delete

The script accepts a single argument, which can be one of the following: daily, weekly, or monthly. Example of usage: ./db_backup.sh daily

Photo by Dominik Deobald

Before I begin with the tutorial, I want to highlight that I’m talking specifically about a logo and not a generic image, since logos usually don’t come with a background, or more specifically they come either with a transparent, or a solid colour background (which -as you’ll see in a bit- is a requirement for what we want to accomplish).

To begin with, we will use a package called Intervention Image. You can easily install it using composer (it’s also easily integrated with Laravel if that’s your framework of choice). For the rest of the tutorial I’ll assume that you have it installed and configured.

To be able to test what we’re building, let’s create a simple form which will allow us to upload a logo:

Let’s put that in a file which we’ll call logo-resize.php (place it at the root of our project), which will also load composer’s autoload file, and for now let’s put just a simple placeholder check that will help us deal with the uploaded logo.

We’ll have to do a few things to accomplish the resize that we want, so to make things cleaner and reusable, we’ll wrap all our logic into a new class which we’ll call LogoResizer and store it in the LogoResizer.php file (place it under /src/LogoResizer/ folder).

namespace LogoResizer;

use Intervention\Image\ImageManagerStatic as Image;

class LogoResizer {

    private $desired_width;
    private $desired_height;
    private $desired_aspect_ratio;
    private $source_logo;
    private $resized_logo;

    public function __construct($desired_width = 300, $desired_height = 200) {
        $this->desired_width = $desired_width;
        $this->desired_height = $desired_height;
        $this->desired_aspect_ratio = $this->get_aspect_ratio($desired_width, $desired_height);
    }

    public function set_source_logo($source_image) {
        $this->source_logo = $source_image;
    }

    public function is_source_logo_valid() {
        $details = getimagesize($this->source_logo['tmp_name']);

        if($details === false) {
            return false;
        }

        return true;
    }

    public function get_resized_logo() {
        return $this->resized_logo;
    }

    public function resize_logo() {

    }

    private function get_aspect_ratio($width, $height) {
        return $width / $height;
    }
}

Let’s walk through the above code. Initially, we added a namespace, we created an alias (i.e. Image) for Intervention’s ImageManagerStatic, and created a constructor, a few functions, and a few private variables that will help us along the way.

The constructor is pretty straightforward; the two required variables are the desired width and height of the resulting logo (i.e. the one after the resize of the original). We also calculate the desired aspect ratio based on these values, using the get_aspect_ratio function.

The set_source_logo function is just a setter which accepts the uploaded logo. We could have that in the constructor as well, but it makes the class easier to reuse (without having to initialise it again). In the same manner, we could also have setters for the desired width and height, but I’ll omit them in this tutorial.

In the is_source_logo_valid function, we can add checks that will make sure that the logo is exactly what we need. In the above implementation, I just added a check to make sure that the logo is actually an image, but you can do whatever you want; e.g. check its MIME type, etc.

Another way to implement that, is to incorporate these checks to the set_source_logo function and make it either return true if the logo is ok, or false in case there is anything wrong with it.

We also added a getter function (i.e. get_resized_logo) which will return the resized logo. In a proper implementation, it will probably make sense to also add a save_resized_logo function that will save the logo in the file system, but in this tutorial, we’ll just show the resized logo (as soon as it’s done), so we will omit that.

Finally, we added a resize_logo function which -for now- is just a placeholder for the function which will hold our main logic.

Let’s move back to our logo-resize.php file and modify it (I will omit the HTML code; it will stay the same for the rest of the tutorial) to use this class.

require_once('vendor/autoload.php');

use LogoResizer\LogoResizer;

function get_resized_logo($logo) {
    $resizer = new LogoResizer(300, 200);
    $resizer->set_source_logo($logo);

    if(!$resizer->is_source_logo_valid()) {
        return false;
    }

    $logo_resized = $resizer->rezise_logo();

    if(!$logo_resized) {
        return false;
    }

    return $resizer->get_resized_logo();
}

if(isset($_FILES['logo'])) {
    $resized_logo = get_resized_logo($_FILES['logo']);

    if($resized_logo === false) {
        //show error
    } else {
        echo $resized_logo->response('jpg', 70);
        die();
    }
}

The get_resized_logo function initialises an object of our LogoResizer class, sets the uploaded logo as the source logo, checks if the source logo is valid, instructs our class to resize the logo, and finally -if the resize was performed successfully- returns the resized logo. In case of any error, it returns false. That’s enough for this tutorial, but in a real implementation you might want to return relevant error messages to let the user know what happened in case of an error.

So, if the user uploads a logo, we call the get_resized_logo to resize the original and get the resized logo back. In case of an error, we deal with it, and if the image came back correctly, we just display it to the user and kill the script. We do that using Intervention’s response function.

By the way, you might have noticed that although we use our LogoResizer class, we don’t include the path to it somewhere in the logo-resize.php file (like we do with composer’s autoload.php). Instead, we are auto-loading the class using composer. To do that, modify your composer.json file to look similar to the following:

{
    "require": {
        "intervention/image": "~2.1"
    },
    "autoload": {
        "psr-0": {
            "LogoResizer": "src/"
        }
    }
}

Obviously, what we did so far won’t work for now, since we have not yet implemented the resize_logo function of our LogoResizer class. Let’s do that now.

public function resize_logo() {
    try {
        $logo = Image::make($this->source_logo['tmp_name']);

         if($logo->width() === $this->desired_width && $logo->height() === $this->desired_height) {
            $this->resized_logo = $logo;
            return true;
        }

        $logo_aspect_ratio = $this->get_aspect_ratio($logo->width(), $logo->height());

        if($this->desired_aspect_ratio === $logo_aspect_ratio) {
            $logo = $this->resize($logo, $this->desired_width, $this->desired_height);
            $this->resized_logo = $logo;
            return true;
        }

        $background_colour = $logo->pickColor(0, 0, 'hex');

        if($this->desired_aspect_ratio > $logo_aspect_ratio) {
            $logo = $this->resize($logo, null, $this->desired_height);
        } else {
            $logo = $this->resize($logo, $this->desired_width, null);
        }

        $logo->resizeCanvas($this->desired_width, $this->desired_height, 'center', false, $background_colour);

        $this->resized_logo = $logo;
        return true;

    } catch (Exception $e) {
        return false;
    }
}

private function resize($logo, $width, $height) {
    $logo->resize($width, $height, function ($constraint) {
        $constraint->aspectRatio();
    });

    return $logo;
}

The first step in our resize_logo function is to initialise an instance of Intervention using the source logo. Then, we check if the logo has already the desired dimensions. If so, we copy it to the $resized_logo variable (so we can grab it using our relevant getter) and stop the process returning true; we wrap everything we do in this function in a try catch statement, returning false if an exception is thrown and true in case of a success.

The next step is to calculate the aspect ratio of the source logo, and compare it to the desired ratio.

The easy case is when the two ratios are equal, where we just have to resize the logo to the required dimensions using our resize function (which is basically a wrapper for Intervention’s homonymous function) and stop the process.

If they are different, we will resize the logo only specifying either the new -desired- height in case the desired aspect ratio is larger than the ratio of the source logo, or the desired width if it’s the other way around. As you may have noticed, our resize function resizes the logo keeping the aspect ratio, so by doing what we just described we will end up with a logo which has only one of its dimensions set correctly.

To fix that, we will just need to resize the logo canvas to the desired with and height, set all the content that we already have to its centre, and use colour of the top left corner (0x0 pixels) of the logo as the background colour of the canvas.

To further understand why we needed to do that, let me give you a quick visual example. Let’s assume that we will use the following image as a logo (its original dimensions are 1022×766 pixels):

The desired aspect ratio (of 300×200 pixels) is 1.5 and the aspect ratio of the uploaded image is ~1.33, so based on our code we will resize the logo specifying that the new height should be 200px, but leaving the width to be calculated automatically so we can keep the aspect ratio intact. That will result in a 267×200 pixels logo.

Then, we will resize the canvas of our logo to 300×200 pixels, and put our 267×200 logo at its centre. Have a look at the following image to visualise why.

Finally, we just have to set the background colour of the canvas to #e1ecb4, so it will blend nicely with the rest of the logo.

You can download the source code of this tutorial from this Gist.

Although many years have passed since then, I’m pretty sure it was 2003 when I read Kevin Mitnick’s book The Art of Deception. In it, he describes several real and hypothetical “hacking” cases, illustrating that humans are the weakest link in any secure system, thus a very good target for such attacks. The whole concept is called social engineering.

During that period, I was an undergraduate student. One afternoon, while we were hanging out at my apartment with some friends, we started talking about Mitnick’s book that I was reading these days, so I explained the concept of social engineering to them.

The conversation was interrupted by another friend of ours, who came into the apartment frustrated. He was coming from his travel agent -located just a few minutes from my home- where he went to get his plane ticket. When he arrived there, he discovered that the agent’s internet connection was down, therefore couldn’t retrieve the ticket information and print it, so he had to wait until that was fixed.

By the way, although DSL connections existed, the most common internet connections at that time in Greece were PSTN (remember their sound?) & ISDN. The travel agent had an ISDN connection. How we knew that?

They told my friend something along the lines of “we are waiting for the ISDN guy of company X to come back; he was here about an hour ago and said he had to go and check something at the exchange”.

I’m sure that a lot of you would have the exact same idea! :)

I quickly fired up my own ISDN connection, found the agent’s details and gave them a call.

Me: Hi, I’m calling from company X; you’re still having issues with your ISDN connection, right?

A: Sure (…)

After thanking and telling him that I would run some tests and call him straight back, I tried his credentials using my ISDN modem. They worked. A few minutes later, I called him back and explained that I was actually a student doing some research on security, found a good excuse about how I knew he had a problem with his internet connection, told him that I was sorry for wasting a few minutes of his day and advised him not to give sensitive information over the phone, to change his username & password, etc.

Of course, I immediately threw away the credentials (I did the whole thing just to try out if that whole thing worked) and never used them again — I never even tried them again just to test if he actually changed them, but that taught all of us a very important lesson. To always keep in mind that no matter how secure a computing system is, there is always a human available to screw it up!

The book might be old, Mitnick hacking days might be older, but such attacks still exist. The latest example that comes to mind is an attack against eBay, where the attackers stole “a database containing encrypted passwords and other non-financial data” (still a lot of personal data though).

How the attack was performed? “Cyberattackers compromised a small number of employee log-in credentials, allowing unauthorized access to eBay’s corporate network”.

They never had to hack eBay itself; they just had to hack some of its employees!

This story was originally published as part of my newsletter’s editorial and was also published on medium.

Images by mustified, wikipedia, and Ward Jenkins

The quite spacious store was almost empty of customers and a lot of sales people were wandering around doing nothing. Before going to pick up my order, I decided to have a quick look at some laptops they had on display.

While heading to the laptops section, a salesman stopped me and asked me if I needed help with anything. I didn’t. While checking out a few laptops, two other salesmen asked me the same. I still didn’t. After a few minutes, I tried to find out where I could pick my item from. There was no sign indicating where I had to go, so I asked a salesman who was not very sure, but showed me a queue of 5–6 people. It was the “customer services” desk.

I quickly noticed that everyone in that queue had items they had a problem with and wanted to return or fix. There were only two people serving that queue, so it was moving extremely slowly. After a few minutes, I asked a saleswoman if I was standing in the right queue for what I came for. She asked me what kind of item I reserved, and assured me that I was waiting in the right place (since they had to bring it from the warehouse).

After about 20 more minutes which felt like a couple of hours, ​it was finally my turn to be served. After explaining what I was waiting for and that the sales staff told me to wait there, the guy on the desk just turned me away, telling me that they only deal with “large items” and I should go to one of the checkout tills… ​Since he didn’t even apologise for the delay, ​​I ​expressed how unhappy I was since I had been waiting 20–25 minutes without any reason​, and headed for the till.

After waiting there for a little bit and after I was told that I should have gone to the customer services desk (no further comments on that), they ended up finding my order and sent someone to the warehouse to pick it up. I paid and left, but forgot to ask if any bags were included in the package. I went back (with the item in hand) and asked about it at the same till.

The person there assured me that it did, since (quoting her) “the features list of the vacuum mentions bags, so that means that it has bags inside”. I decided not to explain to her that this is not what it means, so I just went to my car opened the box there, confirmed that there were no bags in it, and went back to buy some.

When I went to pay, there were 6–7 people waiting in the only open till at that point. I looked around and noticed that most of the sales persons were sitting idle in random corridors, waiting for the next customer to appear; probably they were not allowed (or trained) to operate a till. The process in the tills was too slow that literally two of the people in front of me in the queue left the stuff they had decided to buy and left the store.

I paid and left, praying that the vacuum cleaner won’t break within its warranty period, and I won’t have to go back to that place ever again!

This story was originally published on my newsletter and is also published on medium.

Photo by Alex Segre; Cartoon by Dilbert