Ljubljana, Slovenia

Docker Maze: the benefit of coding competitions

Coding competitions are a good way to test and improve your skills. Some of the skills you might already have just by the nature of the engineering job itself - you have to set up your development environments, trouble-shoot connectivity issues, and solve problems when they occur. I don’t need to tell you that it’s better to learn these skills in a controlled environment, and perhaps not while watching your production systems fail. And in case that does happen - you don’t want to be the one who’s just looking at whatever metrics you have and pray for some kind of miracle. But, putting a time limit on a competition - it keeps some pressure on you, just like the real thing.

About the challenge

The DockerMaze was a competition at Dockercon 2015, created by Schibsted Media Group. They created the “DockerMaze Reloaded” challenge in 2016, which they announced on April 28, for their meetup in Betahaus Barcelona. The challenge sets a futuristic backstory, where you’re left with a malfunctioning robot which you need to repair. The robot is constructed using several docker images, and you have to fix each one of them, with code or configuration, to “repair” the damage caused to your Dockerbot. These are some of the lines from the thematic description of your tasks ahead:

The radiation hasn’t been fair to your Dockerbot, most parts have either suffered corruption or have automatically reverted to previous working versions due to it. […] With little time to waste, […] prepare yourself for a race for survival against the clock and the unknown dangers that may await you outside. How much of the robot will you be able to put together? Can its powers be a match for whatever futuristic foes inhabit this world?

You can find the complete information on the challenge page - and you can still try your hand at fixing the maze. The results are frozen however, and that shiny RaspberryPI 3 which was given as a reward is not available anymore. But it seems that the challenge will be repeated in the future. Keep an eye out for that.

Challenge tasks

There are a number of problems you need to resolve using the provided setup.

  1. You have to develop a friend/foe image recognition in Golang with 100% accuracy,
  2. You have to actually write assembly code to complete one of the challenges,
  3. You have to fix/develop an optimal maze solving algorithm in Python,
  4. You have to fix connectivity issues between components,
  5. I have no idea what I’m supposed to do with the “arms” of the robot

Sounds interesting? It is. I just had no idea what I was getting myself into. But it demonstrated the exact value competitions like this have for the programmers who are taking part in them. I’m going to review my thoughts about individual sections, and see if I can make sense of the benefits which I experienced.

Assembly - the radio module

I haven’t written a line of assembly in something like 15 years or more. Even back then, I was cautiously using it for very performance intensive pieces of code - things that you could actually improve by writing your own assembler code. I remember pipelines, which allow you to execute two different assembly commands in one cycle instead of two. Using your mind, you could reach significant goals taking advantage of this.

As for me, the task was not the hardest - it was just the matter of refreshing my memory - what is heap, what is stack, which register I can use for an 8 bit value, how to read an 8 bit value from a memory address, and if I actually had the correct memory address. Seriously, it’s much more complicated for a person who never saw assembler code, and I’m surprised about 50% of people managed to finish this one.

Golang - the weapon module

The goal of the weapon module is to use Golang to recognize friendly robots. You should spare them, and destroy the evil, red robots. Since I did write API foundations in Go I didn’t have a problem with the language itself, and I just added some logic to check the images. Before I knew it, I was at 100%. I have chosen to compare the pervasiveness of the red color in the image itself, and penalized robots which had twice the amount of red over blue, green or both channels combined.

Applications like this break you out of your common thought patterns - make you solve new problems in creative ways. Since the science here is more of an approximation, it just comes down to tweaking the solution until it fixes the problem.

Bash - the arms module

I totally failed here. I did learn that linux/bash supports /dev/tcp, and that such a thing exist from somewhere since 2012. I had no idea how to fix the issues of the program itself. If it was just the name of the pipe, I haven’t figured out how to fix it.

exec 7<>/dev/tcp/head/7777

I did even try to run strace on the command, but at that time I wasted hours on solving the problem with the legs module. I left this one behind, mainly because the information about the problem itself was scarce, and I was going nowhere with it.

Docker - the heart module*

Very much central to the whole “making it work” thing is to provide connectivity between containers. Most of it was done by just throwing out the custom networks defined in the docker compose file, and adding a DNS server in case head/legs/whatever didn’t resolve the hostnames.

Logic problem - the legs module

This one was hard. I mean really, really hard. It’s a simple logic problem, but it’s in a domain I’m not familiar with (python). I did however learn that in Python, everything is a reference. It took me a few hours, and I already wrote a recursive maze solver algorythm by that point. Of course, I’m still penalized for finding unoptimal paths - you see, I chose to move the peice towards the right, bottom, left and top - in that order. Since the vertical parts of the maze is two characters wide, your path will meet the opposite wall, giving you an extra step or two you need to solve the maze path. I had enough at that point.

I even went so far to mark my path with X’s in the mazes provided.

SOLUTION:
+--+--+--+--+--+--+--+--+
XXX| XXXXXXXXXXXXXXXXXXX|
+ X+XX+--+--+--+  +--+ X+
| X|XX|     |     | XXXX|
+ X+XX+--+  +  +--+ X+--+
| X|XXXX |  |  |  | XXXX|
+ X+--+XX+  +  +  +--+ X+
| XXXXXXX   |     |    XX
+--+--+--+--+--+--+--+--+

I think that deserves some extra effort. You can see the problem with the right/down/left/top bias which I’ve mentioned. Some of it I could correct after with a few string replacements, but there are still edge cases which I haven’t caught. I would just need to think of a better way to travel the maze when going around corners. I was close.

I really hated this challenge. Logic problems are one thing, but finding out how unfamiliar a programming language can be is really daunting. I haven’t had issues where I’d be dealing with reference hell for such a long time, that I imagined that, perhaps, other people have it as good as me. You know, that any language would deal with this …

>>> a=[1];
>>> b=a
>>> b.append(2);
>>> print a
[1, 2]

… along with that all function arguments are passed by reference. I still have a headache, days after.

The value of competitions

It’s a great way to practice! I’m pretty sure I googled a few things about docker-compose, python, ruby, golang and assembly in general to find out a few things which I didn’t know or remember from before. Having problems you’re not dealing with in your day to day allows you to practice problem solving on something else than a NoSQL datastore.

You learn to think. Sure it might be a bit of a trial and error, but eventually you find out what works and what doesn’t. You remember mostly your mistakes - ones you might not be likely to repeat in the same scenario at a later time. When you will face a similar problem in the future, you will already have groundwork that might help you start closer to what works.

Edit: As a fun fact - I was one of the people that won the competition. I never win anything, and this time, the random number generator was on my side, and I’m getting a RaspberryPI 3 in the post. But I got much more than I expected already - mainly, that I never want to touch Python again.

While I have you here...

It would be great if you buy one of my books:

I promise you'll learn a lot more if you buy one. Buying a copy supports me writing more about similar topics. Say thank you and buy my books.

Feel free to send me an email if you want to book my time for consultancy/freelance services. I'm great at APIs, Go, Docker, VueJS and scaling services, among many other things.