Say you have a Deer struct:

type Deer struct {  
    Hooves []Hoof
}

Deer have four hooves, so the above representation seems faithful in terms of memory allocation - hooves belong in the deer, they're a part of it.

Now let's consider the case where we'd like to determine whether the deer is currently hopping. We define a hop as any point in time where the deer has two or more hooves in the air.

For the sake of my example, instead of simply counting how many hooves are mid-air, I will want to do more things with those hooves later, so I want to take that subset into a separate array. Since memory has already been allocated previously for the Hooves (when the Deer was adorably constructed), I would prefer to not allocate it again, meaning I will use an array of Hoof pointers: []*Hoof

Here's what this code would look like:

func (deer *Deer) GetMidAirHooves() []*Hoof {  
    midAirHooves := []*Hoof{}

    for _, hoof := range deer.Hooves {
        if hoof.MidAir() {

            // append the hoof's address
            midAirHooves = append(midAirHooves, &hoof)
        }
    }

    return midAirHooves
}

This is where it may get confusing: when you range over an array of structs, and then reference the current struct's address (&hoof in our example), you're referencing the address of the memory allocated for the iteration itself. This memory has the iterated structs copied into it one after the other, and once the iteration ends, any reference to it will only give you the last struct in the array. The de-facto result is that midAirHooves will contain as many pointers as there are hooves in the air, all of them pointing to the fourth hoof.

The implications is that if you still want to produce a pointer array from a struct array, you'll need to use the index to correctly point to the struct. In our case the loop would look as such:

    for i, hoof := range deer.Hooves {
        if hoof.MidAir() {

            // append the real hoof's address
            midAirHooves = append(midAirHooves, &(deer.Hooves[i]))
        }
    }

Watch out for this tricky behavior when writing your code!

"Docker's vision has always been scalability, scalability and scalability. We are going to build a new headquarters up in the Cloud, we truly believe that's where our innovation will be the most secure and we've always been about security, security, security."

What's in the future for Docker? "Well, obviously we're going to do a bunch of Dockers, that is the company's name and we're really all about that at the end of the day. But we're committed to bring new cutting-edge technologies to everyone, and today I'm excited to announce our very own integrated Big Data containers - Bonkers. You can think of Bonkers as your Dockers in the Cloud with Big Data. We're bringing everything to an intuitive UI - you name it, we support it. There's Hadoop, Cassandra and even good ol' MySQL. And yes - we can scale your cluster", and with a very suggestive gawk he added, "and we will."

So now, equipped with my very own .io domain name, and an extreme thirst for angryface pun-haters, I embark on a fresh journey of having absolutely no fucking idea what I am doing. With lots and lots of Docker, as I hear that is quite popular nowadays.

Architecture

Setting this stack up was relatively simple, especially for a complete web-moron such as myself. This blog runs on Ghost, an open-source blogging platform running on NodeJS. It's hosted on a DigitalOcean Ubuntu server, and runs on top of Docker containers (one per service, so one for this blog and another one with nginx for the main area, currently).

In addition to that, a main nginx server runs directly on top of the server, and it acts as the gateway to everything. It reverse-proxies requests by their subdomain to their appropriate Docker container's port:

main_nginx  
    ------> omri.io, www.omri.io -> http://localhost:6000
    ------> blog.omri.io -> http://localhost:6001

In order to keep the docker containers volatile and non-important, their relevant data directories are volumes originating from the server's filesystem.

Keep in mind: doing this isn't enough on its own and you'll also need to create A-records in your domain's DNS settings, for every subdomain that you wish to reach your server.

Should I decide to write any real code and actually do something with this virtual space, it'll be made available in my GitHub repository that I opened for this project.

Conclusion

But for now, hello there! And thanks for checking me out, blogboys. I, for one, am excited and also a bit disappointed that we made it so far without any puns. It's only fun if they pun.