Takapelastin is the Java ☕ back-end for my solution to Reaktor's PROJECT BIRDNEST assignment. Java was chosen because of its excellent library support for reading XML and JSON, which were the data formats used in the problem statement. Additionally, I'm quite knowledgeable of Java, so it seemed like the natural choice.

There's an online Javadoc that's a good place for high-level information regarding the solution. Still, the best documentation is the code itself. Maybe look around in the project package?

With Java installed:

1. Get the .JAR file from the latest nightly artifact or by compiling it yourself.
2. Run java -jar <PATH TO .JAR FILE>
3. Navigate to http:https://localhost:8002/.

With Maven downloaded and installed:

1. Navigate to the project directory
2. Run mvn clean package
3. Get the resulting .JAR from target/Takapelastin.jar

1. I had a rough idea of the goals of the assignment.

   The assignment's intent was to evaluate capability to work with complex environments serving data in a myriad of different formats. Can the applicant model the problem effectively and create a coherent, high-quality solution?

2. I knew a back-end server was necessary for the solution.

   I initially thought of writing a client-side-only application, but quickly realised this was not possible. The client needs to know the state of drones from up to ten minutes before the user visits the website, which is impossible without aggregating that data beforehand and serving it from elsewhere.

3. The back-end server did not need a database.

   Since even the aggregated data was relatively short-lived (ten minutes!), and the problem statement mentioned that we didn't need to handle server downtimes, we didn't really need a database to keep track of violations. Adding one would have created needless complexity, so I opted for in-memory aggregation instead.

• Modelling the problem was easy.
• Making the model consistent was hard.
  • Much of the data provided by the Reaktor API endpoints is wholly unused. For example, drone reports contain information about the equipment monitoring the drone (within a <report>), but this information is not needed for the solution. Currently, the back-end server completely ignores this data silently.
  • For parsing to work properly, the structure of the in-memory problem model (blue.lhf.takapelastin.model) MUST match the structure of the input data.
  • Should the structure also match for output data, even though information has been discarded, and the structure COULD be flattened into a simpler format?
    • I opted to flatten the output data. This can be seen in JSONCheckerSerializer: the serialized output flattens the nested Report > Capture > Drones structure into just a list of drones.
• Some parsing libraries are outdated.
  • JAXB was used to convert XML data into Java objects.
  • JAXB is old and doesn't support record classes.
  • JAXB is also very poorly documented.
  • This is why Drone is not a record class.
  • GSON is amazing. I love GSON.
    • I wish it could marshal Instants, though.
    • I had to write the serializer myself. Stupid boilerplate :(