as I said I have done several interviews in the last 2 months. One of these was with BBC. The interview was divided into 2 parts: the first was a project, then there was the face-to-face in their offices in Oxford Cyrcus, the centre of London. In this post I will speak about the project (you can find my solution on github). So, there were lot of things written in the document for the code challenge, but I can explain them briefly here. The core of the project was expressed with a scenario:
“As a BBC television presenter I want to see the counts for candidates within a given time frame so that I can announce the winner of the competition”
I am mainly a backend developer, but having a bit of experience as full stack I wanted to create a fully working web application. Not all by hand, obviously, considering that we were allowed to use any 3rd party library. Even if I have never worked before with Play Framework or Akka, I thought it was the best moment to start. Play has nice features, and with Activator it is easy to have the stub of a web application in few seconds. I used the “Play 2.4 Scala Seed” so that I could have all the files needed and the first basic controller. Obviously I immediately update the
The really first thing to do was to design the database: I was used, because I used it in several projects, to work with SQLite for the day to day small projects. But SQLite is not a good choice for concurrency, so I decided to try the H2 database (that is also the default for Play). Some databases, like SQLite, create the db file if it doesn’t exist in the path you setup in the configuration; unfortunately it seems that with Play this feature is not available, so the JDBC driver is not creating the db file and it expects to find it in the location you configure. So I had to generate a H2 database by using the Platform independent ZIP file and by connecting to the same path I was using in the config file. Not finding the db, the application generated an empty one and so I used this as basis for my development.
Next step was to create the tables in the database. Play has this concept of Evolutions, SQL scripts that Play runs automatically if the application is started in DEV mode and the database has not run all the previous db scripts. It is enough to add in the build.sbt the dependency to the library (evolutions). Eventually you can enable or disable it through the configuration, but as default it is enabled. When it is ready you must only put a directory evolutions.<nameofyourdb> and inside you can put your SQL files with name <number>.sql, starting from 1 and incrementing it each time you want to change the schema of your db. The file uses comments to know which part is the evolution of the schema and which the part to run when this evolution should be removed. You can see it in my project and it will be much clearer.
I needed four tables: Events that stores the events for which you open a vote, Candidates in which you have the candidates for the event (with a foreign key to the event) and Votes with all the votes that users has sent (this because one of the requirements was to not allow more than 3 votes per user). The fourth table I called it Cache because it keeps the results without recomputing it starting from votes. In the evolution 1.sql you can find the SQL used to create the db. Please consider that the db in the repository is completely empty, so when you launch the application in dev mode and you open your browser to display it, Play will ask you to run the sql script.
For this post it is enough, let’s wait the next one to speak about the rest of the application.