Codecamp 2016: The experience in pictures

Last Thursday, we moved our “office” to Denmark again for four days at Heine Bartsch's estate in Sallingen on Funen. Once again, a very special kind of change of scenery: In the impressive Heine manor house, lots of antique furniture and art exhibits are on display for sale. The majority of the 16 CAP3lers who traveled with them already knew the location from last year.
·
28.09.2016
Das Anwesen von Heine Bartsch in Sallingen auf Fünen.

Of course, CodeCamp is about working on self-determined, interesting topics, trying out new technologies and thus gaining new know-how together. It is at least as important to have a really good time in the team. We made good use of that again this year. To give you an insight into what you've experienced, here is a small selection of what made CodeCamp a special experience this year.

Cap3 team and Emmy, the Wäller dog from Bettual, in front of the estate on the island of Funen
Marcel (Meeting & eating) and Jeremy took care of our physical well-being over the four days. It's amazing how the two of them managed to prepare such feasts in the very small kitchen. Respect and thank you very much!
QuEUING FOR DELICIOUS FOOD - WHEN THE WEATHER IS GOOD
Concentrated team work
Freshly hatched - Heine raised two little chicks in his kitchen that simply delighted everyone
Ben, Sören, Marian and Ole playing FIFA
Campfire romance in the evening
Hustle and bustle in the house
Results presentation on the last evening

And here is a small excerpt from the projects that were carried out:

Time recording tool with Scala.JS, AKKA and event sourcing

For CodeCamp 2016, we have set ourselves the goal of implementing a project with Scala, Scala.js and Akka using the event sourcing pattern.

The project idea

A few years ago, we at Cap3 developed a tool for time recording and then used it in projects for a while. Ole and I are still of the opinion that having our own time recording tool is cool. We have therefore decided to redesign the time recording tool as a web backend in combination with a single-page application.

A concept and good designs from Moritz Schönfeld They already existed, so there was no need to reinvent the wheel here.

Briefly about the background of the time recording tool: In order to keep track of the expenses for our projects, every developer tracks the time they work on a project. Expenses for project management or design services are also recorded in this way. The time recording should be perfectly tailored to our needs with just a few clicks (as easy as possible).

Pinnwand mit Brainstorming-Ideen

On the first day of CodeCamp, together with Nicolas, we held a short event storming session for the time recording tool. As a result, we were able to quickly identify the core features that we wanted to implement in a short period of time. We were also able to use the events directly in the implementation of the backend.

Technical details

Scala.js offers the option to write the complete code of a web-based front end in Scala. Compared to JavaScript, we believe that using Scala offers many advantages, such as static typing, better IDE support, better maintainability, less code. But even compared to TypeScript, Scala.js offers further advantages, including: Strong typing, a larger standard library, code is optimized by compilers.

In combination with a backend, which is also implemented with Scala, code can also be shared between frontend and backend. This means, for example, that you get a typical communication interface between frontend and backend, which is always up to date in the code. Many errors that can result from changes to the interface are already found during compilation.

Of course, there are also disadvantages, including the size of the compiler being at least 45kB.

Einblicke in die Programmierung

On the frontend, we have React and diode (library inspired by Flux, Elm and Redux) used. We implemented the backend using the Play framework and Akka/Akka Persistence/Akka Persistence Query using the event sourcing pattern. Contrary to traditional data storage in a relational schema, the application state is recorded as a sequence of events (cf. martinfowler.com “Event Sourcing”). A technology with many advantages that we would like to use in a customer project.

Emerging development issues

Overall, the use of the new technology went surprisingly smoothly. However, one notable problem still arose: We had to the library at the start of the project Autowire set. Autowire offers means to automatically generate the code required for network transfer between front and backend. First, using the library saved us time and we were able to implement the application logic directly. But when it got into the details, we realized that we didn't have enough control over communication. For example, it was not possible to influence the HTTP status code that was returned. But the main problem was that Autowire didn't interact with our dependency injection approach. After we had decided not to use the library, the missing communication layer followed suit in just under two hours.

Our Conclusion

We are very satisfied with the outcome of the project. The knowledge gained has further encouraged us to rely on Scala. The expectations of Scala.js, which were the focus on, have been met in full: Scala.js offers very good opportunities to develop a high-quality web application.

Appointment booking system using domain-driven design techniques

For CodeCamp, Frederic and I have decided to implement an appointment booking app for “our chef” Marcel. Marcel has been preparing delicious vegetarian dishes for us every Thursday at Cap3 for many months (https://www.facebook.com/Mittagshoch).

So that he has an estimate of how many hungry CAP3 people would like lunch, we are currently using a doodle list. Marcel's vision is to target local companies and their employees with his business model and to offer a networking platform through healthy and seasonal eating at work. This involves receiving binding promises from participants and, at best, obtaining electronic payment in advance. Marcel pitched his lunch booking system with us before CodeCamp and was able to recruit a team to implement his idea as a prototype.

Among other things, we used this project to practice a Domain-Driven Design methodology — the Storming event by Alberto Brandolini. First, we defined all domain events in the context of the idea (one orange post-it for each event) and then group them into aggregates. We then defined external systems — in our case payment via PayPal (purple Post-it) — and processes and interactions (blue Post-its) for future users of the app. This worked pretty well so far and the discussions that arose during the event storming were definitely very informative.

Die Teammitglieder brainstormen ihre Ideen
The development

Frederic and I use the resulting picture to try our hand at event sourcing after a brief briefing from Nicolas. Event sourcing describes a software development methodology in which every change in the system state is saved as an event.

As a result, in contrast to systems that only keep the current state, the complete history of all changes is always available, so that virtually any state of the (sub) system can be restored at any time. Especially for systems where the availability of the history of data is essential (e.g. Finance IT), the use of event sourcing usually makes sense.

Due to the availability of the history, certain queries can also be made to the system at a later date (e.g. how many customers deleted goods from the shopping cart 5 minutes before ordering?).

Due to the different type of persistence, this methodology was initially unfamiliar to us and required a different way of thinking. By using the “Scala” programming language and “Akka-Persistence” — a framework that enables event sourcing — we were able to quickly achieve initial success. So while we started programming, our user interface designer Ben outlined the individual views of the app together with Felix and Kira based on the documentation and then set about implementing the specific designs.

Ein Flowchart für die App in der Entwicklungsphase

Back to Frederics and my development: We didn't really start the implementation until Friday afternoon, which means we only had about 1.5 days left for further implementation. Unfortunately a bit too little time for a complete development of the system. What we were able to set up, however, is the basic system with event sourcing, so that further development can be carried out later without much further effort.

Zwei Teammitglieder konzentriert am coden.
conclusion

We are satisfied with the outcome of the project, although we would have liked to have a little more time to delve even deeper into the topic. Through this project, we have gained the insight that software systems can benefit from an event sourcing architecture. Event sourcing will also be used in customer projects at Cap3 in the future.

Tower defense with .NET Core

For our CodeCamp, Basti, Ben and I got together to develop a simple game using .NET Core. We chose a tower defense game on a hex grid because of the relatively easy implementation.

The rules of Tower Defense are easy to explain: Each hexagon represents a position on the playing field. Each player has their base on the field, which must be defended from the other's attackers. For defense, towers are placed on the playing field to repel the attackers. The path of the attackers is defined by the spaces between the towers. A path must therefore always remain open between the towers.

The development

The special thing about our development was the use of a Redux architecture, which we normally use for our web apps in the frontend. For the game, we wanted to use them in a distributed scenario for the first time. The server should be considered a “single source of truth” and manage the state of the game. The only task of the game clients was to display the current state and send players' actions to the server.

The development of the server component with the completely new .NET Core 1.0 I chose it as a task. It was important to me to learn as much as possible from the new.NET, which is why I did not use a ready-made server library. To display the game, Basti has implemented a JavaScript-based client with Phaser.io. Phaser offers many features to implement a 2D game and has been on Basti's “I want to do something with” list for a long time.

In addition to programming, the design of a game is particularly important. We were initially inspired by Google's Material Design Guidelines, but Ben quickly made something his own out of them.

Eine kurze Demo der Animationen
conclusion

Something really playable could not be achieved in a short period of time. Especially because we've tested new technologies. However, the attempt to apply the Redux architecture to a multiplayer game completely convinced me. The biggest advantage of such an architecture is that you hardly need any distributed logic anymore. All upcoming events are processed centrally on the server and the new game state created as a result is sent back to all connected players via the network. This also makes developing the client correspondingly easy, as it is not responsible for much more than rendering.

The use of .NET Core was more of a brake at this early stage so shortly after the release. The core is finished and can be developed very well with it, but the many libraries that you are otherwise used to using are still missing for the most part. You should therefore wait a bit before using .NET Core productively. I suspect that it will be worth switching over the course of the next year.

Project creator for new software projects at Cap3

Setting up a new software project takes time. At Cap3, we use separate tools for project management, time recording, source code version management and automated software construction. It can take just a few hours before everything is set up.

The vast majority of projects also require a test environment for both developers and customers. In addition, databases and web servers must be set up and documented accordingly, which can quickly cost a day or more.

The project idea

Because we see potential here to make our processes more efficient, but also in terms of knowledge transfer at Cap3 (which systems, frameworks and libraries do we work with?) Marc, Bettual, Jan and I were immediately very impressed by Paul's idea for CodeCamp to automate the initial project setup for a new software development. The desired result should be that the entire infrastructure is automatically set up using a simple input mask for the project name and project type, so that a developer can start his actual work directly.

In addition to setting up the services, a central location for documentation should also be created, where links to the relevant services such as project management, time recording, etc. are listed, but also, for example, login data for the databases used. Some people even dream of a dashboard that can directly show us the information from the services, including work items, git commits, build results and server status.

Der erste Entwurf für den Project Creator
Technical details and background

The declared goal for CodeCamp 2016 was therefore to develop a website that could be used to make the settings. In the background, the tool then uses the existing APIs of the applications we work with at Cap3. In order to keep the complexity of the project within feasible limits, given the short time, we first focused on creating a web project with Scala and the following services:

  • GitLab for the source code
  • TeamCity as build server (for continuous integration)
  • YouTrack as our issue tracking/project management system

We also developed the front end ourselves with Scala. Bettual and Marc were given the opportunity to try out the new technology for them, supported by Paul and me. Jan, Cap3 intern, took care of the web interface.

One of the content challenges was to define an achievable goal from the almost infinite number of ideas at the beginning. That's why we sat down on Friday and collected all ideas and prioritized them based on feasibility and immediate benefit. Even though this task sounds like dry work, it has helped us not to lose focus on the essentials.

What was technically interesting for us was the need to address the various APIs asynchronously and provide the user with continuous feedback on the status. While setting up the project management is relatively quick, it takes a bit longer for source code management, as we make a checkout here to add initial files (.gitignore, readme). Using the Akka framework, we were able to write API-specific actuators that perform the work steps in the background. On the frontend, we keep the user informed using a dynamic Ajax view.

What we have achieved

Anyone who takes a look at Paul's project list in our source code management, continuous integration software, or project manager will easily see: It works! Projects such as “Testpaul1" to “Testpaul23" prove that we now have the Gitlab, TeamCity and YouTrack APIs under control. The foundation for further development has therefore been laid. In the future, we want to add more functions and establish Project Creator as the standard for new software projects at Cap3.

Your Ideas are in
good hands.