Image Image Image Image Image Image Image Image Image Image

Iceni Magazine | April 16, 2024

Scroll to top

Top

Celebrating Code Collaboration

Excited businessman with arms up cheering

It’s no secret. One of the most frustrating things about errors occurring in an application is the process of logging into the server and checking the logs to find whatever might have caused the problem. This usually involves ssh’ing into the server using a key, tailing the logs and refreshing the page, then searching through the logs until you find your problem. This is inevitably going to happen in any development process. When things do go wrong, spending a lengthy amount of time finding the problem just adds to the time it takes to fix it.

This is what myself and Tom’s (a student here for work experience) latest project aims to solve. The goal was to create a web application that accepts server logs in the form of a RabbitMQ message and posts them to the browser, in real time. The concept is simple enough. We want a place where all of our log messages can be stored (a database) that we can query, as well as seeing new logs come in when things happen in our application.

There are a lot of components that go into this type of solution. You need a messaging service (RabbitMQ) to send and receive messages, you need a database (DynamoDB) to store the logs, you need an application’s front end to deal with displaying the messages (Spring Boot), you need server sent events to push the messages to the browser in real time and you need to be able to easily configure each application you wish to receive logs from. If we take all of this into account and put it in a diagram, we get the following:

lewis-blog

At the beginning of this project it’s safe to say I was apprehensive. The entire project is built in Java, a language I have very little experience in, so that in and of itself was a cause for concern for me personally. I think that this project definitely identified the benefits of pair programming to me, and having the ability to talk through ideas with someone else in a slower-paced environment allowed me to look at things more closely and learn how things worked faster.

The project is by no means finished, but with a working prototype, collecting logs and displaying them in the browser already, I’m very happy with the progress that Tom and I have made this week.

My main points to take away from this are to collaborate, ask questions and don’t be afraid to take steps backward in order to understand things better. It will help you move forward quicker in the long-run.

Words by Lewis

Visit Us On TwitterVisit Us On FacebookVisit Us On InstagramCheck Our FeedVisit Us On Pinterest