Docker multi-stage builds with Docker Compose

When defining a multi service environment with Docker and Docker Compose, the usual way was to use a Dockerfile for each service, starting with the base image and adding all custom needs:


FROM php:7.2-fpm-alpine3.7

RUN docker-php-ext-install opcache


FROM nginx:1.15-alpine

ADD virtual-host.conf /etc/nginx/conf.d/default.conf

Then you could compose all services.


version: '3'

      context: ./env/php
      - ./:/app
    working_dir: /app
    restart: unless-stopped
      context: ./env/nginx
      - ./:/app
      - "80:80"
    restart: unless-stopped

Then Docker 17.05 introduced multi-stage builds, allowing to use one Dockerfile. Continue reading Docker multi-stage builds with Docker Compose

PHP performance increase from 5.6 to 7.2

I remember when PHP 7 was released. The first thing I did was a simple performance test. I don’t remember the script exactly, but it was similar to this:


$time = microtime(true);

$array = [];
for ($i = 0; $i < 10000; $i++) {
    if (!array_key_exists($i, $array)) {
        $array[$i] = [];
    for ($j = 0; $j < 1000; $j++) {
        if (!array_key_exists($j, $array[$i])) {
            $array[$i][$j] = true;

echo sprintf(
    "Execution time: %f seconds\nMemory usage: %f MB\n\n",
    microtime(true) - $time,
    memory_get_usage(true) / 1042 / 1042

The results made me really happy. Continue reading PHP performance increase from 5.6 to 7.2

Apixu Go: A Golang package for Apixu weather service

Not long ago I’ve mentioned Apixu in a post about handling errors. I’ve find out about this service on DevForum, a development discussions platform I visit daily. What I like the most about Apixu is that they have various languages libraries for consuming their API. Not great libraries and not all of them are complete, but they try to offer as much variations as they can for their service.

I noticed they were missing a Go library and I was missing an idea to learn new things on. And I just started writing the code until it got to a full package which covers all API methods with error handling, both JSON and XML formats, unit tested, versioned.

It has a simple interface which clearly defines the API methods with their input parameters and responses. And it can be extended for custom needs.

Some  important things I learned from the process are simplicity, segregation and isolation, specific errors, memory management, and creating custom marshalers.

Check it out on Github. See documentation for the package and for the API.

Report for GoDoc for

In the end, they adopted my package among their official ones.

Unit testing and interfaces

  • Good code needs tests
  • Tests require good design
  • Good design implies decoupling
  • Interfaces help decouple
  • Decoupling lets you write tests
  • Tests help having good code

Good code and unit testing come hand in hand, and sometimes the bridge between them are interfaces. When you have an interface, you can easily “hide” any implementation behind it, even a mock for a unit test.

An important subject of unit testing is managing external dependencies. The tests should directly cover the unit while using fake replacements (mocks) for the dependencies.

I was given the following code and asked to write tests for it:

package mail

import (

func ValidateHost(email string) (err error) {
   mx, err := net.LookupMX(host(email))
   if err != nil {
      return err

   client, err := smtp.Dial(fmt.Sprintf("%s:%d", mx[0].Host, 25))
   if err != nil {
      return err

   defer func() {
      if er := client.Close(); er != nil {
         err = er

   if err = client.Hello(""); err != nil {
      return err
   if err = client.Mail(""); err != nil {
      return err
   return client.Rcpt(email)

func host(email string) (host string) {
   i := strings.LastIndexByte(email, '@')
   return email[i+1:]

The first steps were to identify test cases and dependencies: Continue reading Unit testing and interfaces