Codemotion

From their website:

Codemotion is a platform devoted to developers that connects IT professionals, tech communities, and IT companies. As we’re a hub of innovation, we share the latest tech information and best practices among the tech community worldwide.

Codemotion first took place in Italy 5 years ago, and has since grown to hosting its events across Europe. The event works in two dimensions: different companies give talks on their areas of expertise in relation to current trends on one side (this year’s were mostly about micro-services and machine learning), and companies looking to recruit man stands on the other. With the opening keynote speeches given by big names in the industry such as Google, Cisco and Facebook, the standard for Codemotion 2017 was set high.

Our participation

Caffeina has been a Codemotion sponsor for the past few years and this year was no different.

Aside from supporting innovation and the dissemination of new ideas in tech, sponsoring the event gives us the opportunity to have a stand, giving us more visibility to those looking for their next career step.

We are always looking for new people to join our team. I remember when I joined a little over a year ago, 36th member of the team: we welcomed our 74th member only last week.

With that in mind, we had to create something eye-catching to attract people.

The project

From our experience at the past events, we knew developers were attracted to two things: code and challenges. Our challenge was to find a way to put these two things together while also showing what we do at Caffeina.

This made us think of a Pong game, but for developers. There needed to be two players at all times and they would challenge each other’s knowledge. A ball in the background would move from one player to the other. Once the two players were connected, they would be presented a question with 4 possible answers, one player at a time. The ball in the background would go towards the answering player and when they answered, it would change direction and go towards the other one. We would calculate the points for each player from the time it took them to answer and the difficulty of the question.

Development time

We started discussing the project about two months prior to the event. Once the idea was clear, we estimated the time we needed to develop it. The operations team managed to squeeze a couple hours dedicated to the project in our daily plan.

Overall, I think it took us 2 to 3 weeks to develop it.

Technologies we used

So the project was simple enough: two clients would communicate to each other and share a session. It could be achieved simply by using a web browser and managing two browser windows from the same client code. But we decided to make it more difficult and challenge ourselves: we wanted to make it possible to put the project online one day, so we thought about adding a backend to it.

Server-side

We started setting up the project, starting with a server that had to communicate with two (or more clients) continuously. The obvious choice here was socket.io. That was kind of a constraint on the backend development as we couldn’t use php for the backend if we wanted to use socket.io. In the end we used Javascript for the server-side development, therefore NodeJS as a web-server.

This wasn’t complex enough though. While discussing the project, we thought it would be a great idea to abstract the game logic from the system so we could change the game logic and have a completely different game. This resulted in two things: firstly, the server side software would be designed in a modular way to allow it to be extended through a predefined interface.

At this point the server side would need two APIs to be implemented, one API for the game logic and one for the client-server communication through the socket events. With everything being dynamic, the last decision to make was what kind of database to use. It couldn’t be MySQL (the traditional server-side DBMS) as it needed to be as dynamic as the data we were going to save on it, so a NoSQL database was necessary. Our choice was MongoDB.

We used a packaged micro-services stack based on Docker for easier deployment and testing.

Client-side

We’re a team that loves Javascript, so we took advantage of the occasion and wrote the application without using any frameworks.

We started with the development of the following parts:

• A custom Router that would allow us to manage page transitions in a simple way
• Then we created a SocketManager to handle all the communication to and from the server from a single component.
• Lastly, we developed a SceneManager that exposed some APIs to control the 3D world and the animations in it.

We don’t like it when things are too easy, so again we made it a challenge for ourselves by introducing interaction through gamepads. This required the development of a GamepadManager that would handle the controllers’ state and the events efficiently (we can control when to activate and deactivate the execution of each of the functions that are attached to the gamepad buttons).

The only Javascript libraries we decided to use are these:

• Three.js for the creation of the 3D world
• Tween.js to animate the camera and the ball in the 3D environment
• Socket.io to communicate with the server
• underscore.js to render the html components

This approach allowed us to minimise the javascript footprint for the project, making it possible to put it online. In fact, the base code weighs only 260 kilobytes. The whole code including the libraries weighs around 800 kilobytes (Three.js is 511Kb)

Involvement

The project saw the involvement of many people in the company, not just from the tech department. As I mentioned earlier, the operations team made sure we had the time necessary to develop the project. The UI/UX director and the team of designers helped us with a distinctive design, making the game drift away slightly from the Pong idea to have its own identity. The administration which gave us their support on logistics and on providing the equipment needed for the stand. Lastly the brand management team helped by taking care of everything else, from the tickets and providing us the gadgets for prizes, to promoting the project and our stand throughout the event itself.

The project was a perfect example of what can be achieved through a fully integrated collaboration of a talented tech department.

The frontend, backend and mobile teams all worked together to make sure the user experience would be flawless, going over and over the code many times testing and improving it.

This wasn’t all. Once the project was developed, we had to create questions. We started to create questions manually, but with the date of the event approaching fast and a high number of questions needed to guarantee their randomisation, this process needed to be automated.

Contributed: Flavio De Stefano, Michael Genesini, Andrea Longo, Vito Famiglietti, Gabriele Diener, Filippo M. Mangione, Riccardo Canella, Andrea Jonus

Project coordinators & Developers: Ani Sinanaj, Alberto La Volpe
Designer: Luca Lombardi
CTO: Stefano Azzolini

Automation

Flavio De Stefano had the brilliant idea of taking the manual of a certain technology (i.e. php) and going through it one definition at a time (with the help of software, of course). For each definition, we then found the 3 most similar definitions using the Levenshtein algorithm.

The format of the question would be something like “What does the function array_column do?” with 4 possible answers, e.g.

• Return the values from a single column in the input array (correct one)
• Return all the values of an array
• Creates an array by using one array for keys and another for its values
• Pop the element off the end of array

The server would then randomise all the questions making sure to show them all the same number of times, and also randomise all the answers each time a question was shown.

Engagement and feedback

We were among the few sponsors at Codemotion that had developed their own game, and the effort paid off: our challenge drew a significant crowd throughout the day, with attendees even waiting in line to play.

We did some user-testing within the agency, but that didn’t reveal all the flaws. For example, it wasn’t clear at the event that the game was meant to be a duel until it was seen in action.

We had also decided not to show the correct answer if a player selected the wrong one, but most of the time they wanted to know which one it was.

Overall, the result was very satisfying and I’m proud of it and of the whole team. More than 200 people played the game and some even returned to play more than once, many of whom were impressed to learn that we had developed the game ourselves.

The project proved to be a great success with regards to our goal of creating a compelling coding challenge which also showcased what we can do at Caffeina. The added bonus of its widespread popularity meant that we also met many different people from all walks of tech, from company speakers to high school students.

Data gathered

From the game, we saved the player’s name or github nickname (depending on whichever they chose to use), and their total score. This enables us to have a record of the number of people that interacted with the stand and gives us a way to get in touch with the ones with the highest scores.

Thanks for reading. Stay tuned for more :)
Want to join our team? Check out the open positions here