The grand finale

After two semesters of work, this project comes to an end. Unfortunately we were not able to achieve world domination. But that’s ok, we learned a lot trying…

Jokes aside, this project helped us to gain a lot of knowledge and experience in the used frameworks and systems. Unfortunatley we were not able to implement everything we wished for but this experience will help us with the next project.

So for the final we hereby present to you our stuff:

Documents

You can find the slides and demo video of our final here.

The slides for our Midterm here.

Project Management

As you can see in one of our blogposts did we utilize function points to calculate an estimation of the needed time to implement the new use cases in the second half of our project. These estimations were unfortunately a bit too optimistic and we were not able to accomplish everything we wanted. In the following you can see which use cases we were able to finish and how much time we spent on each use case in comparison to the estimation.

As you can see our estimations were only for one use case right and we didn’t have the chance to work on two at all. The yellow use case marks, that we were able to complete this but needed much more time than expected. We were not able to complete the red use case but also spent much time on this one.
We think one reason for our miscalculation is that we are unexperienced with using function points as a metric and probably did a few mistakes in our calculations. On the other hand underestimated we generally the complexity and work that had to be done to fulfuill these use cases.

Here is also a chart that breaks down how much time every one of us spent on the project in general. The time is measured in minutes.

Quality

  • Automated Testing
    We already set the foundation for automated testing, but did not implement it in our daily business yet. You can find further information on our fifth blogpost about our feature files.
  • Automated Deployment
    Our whole deployment is already automated. Further information on this topic can be find in our SAD.

Blog posts

We hope you guys also had fun working on your projects and see you next semester!

Plotly dash beginners guide

This is a guide how to get your own simple dashboard running locally. You will need a computer and an internet connection, but given that you are readig this you already have both.

Since dash is a python framework we need to install python first. If you are using Linux it will most likley be already installed (check by typing python in your terminal). Otherwise you can download python here. For Linux you might also have to install pip, you can find instructions here.

Now we have to install dash. For Linux open a terminal and run the command ‘python -m pip install dash pandas’. For Windows open CMD or Powershell and run ‘py -m pip install dash pandas’. Now we can use dash and pandas. Pandas in a library to handle datasources.

Open up the editor or IDE of your choice and a terminal session in your source folder.

First of all we need to import all needed packages:

import dash
import dash_core_components as dcc
import dash_html_components as html
import plotly.graph_objects as go

from dash.dependencies import Input, Output

import math
import random

import pandas as pd

Now lets get the data from a csv file:

df = pd.read_csv('https://raw.githubusercontent.com/plotly/datasets/master/2014_apple_stock.csv')

And create the layout of our dashboard:

app = dash.Dash(__name__)

app.layout = html.Div(children=[
    html.H1(children='Hello Dash'),

    html.Div(children='Hello there'),

    dcc.Interval('interval', interval=1000),

    dcc.Graph(id='scatter'),

    dcc.Graph(
        id='line',
        figure=go.Figure(
            go.Scatter(
                x = df['AAPL_x'],
                y = df['AAPL_y'],
                name='Share Prices (in USD)',
            )
        )
    ),
])

Now to make the dashboard a little bit more interesting, lets add a callback:

@app.callback(
    Output(component_id='scatter', component_property='figure'),
    [Input(component_id='interval', component_property='n_intervals'),]
)
def update_scatter(input):
    if(input is None):
        return dash.no_update

    data = go.Scatter(
        x=[random.randint(0, 100) for i in range(0, 100)],
        y=[random.randint(0, 100) for i in range(0, 100)],
        mode='markers',
    )
    layout = dict(
        title='Scatter',
        height=600,
        width=600,
    )

    return go.Figure(data=data, layout=layout)

And finally run it!

if __name__ == '__main__':
    app.run_server(debug=True)

Now switch to your open terminal and run the server:
Linux -> ‘python3 dashboard.py’
WIndows -> ‘py dashboard.py’

You will see some output with information about the server, like the adress where you can reach it.

If you enable the debug optiption, you will see debug information on the dashboard and the code will be ‘interactive’ so when you change something and save the file it will auto restart the server which is super useful. Just make sure there are no errors : )

You can find the example with a bit more happening here.
Head over here to see all the graphs or inputs available.

Now you are ready to tinker around on your own and create beautiful dashboards.

Installation of our services

Today we want to show you how you can install our systems on your own machine.

Prerequisites: docker, android phone

Step 1: setup api and webservice

Note: we are storing all container data under /docker/*service* you may edit this path to your liking.

Api webservice and database will need to share a network:
docker network create web

For the api you will need a postgres database, we are using the following docker-compose file: https://gitlab.maphynn.de/snippets/1

In pgadmin create the role “api” with all rights and create a new database called ‘maphynn’ and initialize it with this sql script.

Then you have to login to our registry:
docker login https://registry.maphynn.de

The api stores some config in a .env file with the following content:

PGHOST=postgres
PGUSER=api
PGDATABASE=maphynn
PGPASSWORD=PASSWD
PGPORT=5432
JWT_TOKEN_SECRET=WOW
APP_NAME=Maphynn
APP_VERSION=0.0.1
PORT=1234
BACKDOOR_HASH_KEY=YAY

The JWT_TOKEN_SECRET is a password that is used to encrypt the JWT that is responsible for verifying requests. You can use any password you like, but we recommend a minimum length of 16 characters.

The BACKDOOR_HASH_KEY is a Bcrypt Hash which you can create here, just enter any password for Encrypt and leave the rounds at 12. Enter the hashed key as BACKDOOR_HASH_KEY. This password is used for secure communication between webservices and the api.

And run the image:

docker run --restart unless-stopped -d --name maphynn_api --net=web -v /docker/.env:/usr/src/app/.env -v /docker/api/images/profile_pictures:/usr/src/app/static/images/profile_pictures -p 8083:1234 registry.maphynn.de/maphynn/api:development

The webservice also has a .env:

PORT=1234
API_ADDRESS=your adress
LOCAL_KEY=WOW

In the LOCAL_KEY, enter the clear password which you have encrypted with Bcrypt.

and can be started with this command:

docker run --restart unless-stopped -d --name maphynn_webservice --net=web -v /docker/.webenv:/usr/src/app/.env -p 8082:1234 registry.maphynn.de/maphynn/webservice:development

Now we can start the website:

docker run --restart unless-stopped -d --name maphynn_website -p 8081:80 registry.maphynn.de/maphynn/website:development

To run the App go to https://app.maphynn.de/#/app/ and download the latest development.apk and install in on an Android phone. You have to allow installation from an unknown source first.

Metrics (e.g. a bunch of numbers and graphs that look cool (hopefully))

Ladies and gentleman, today I want to introduce you to our metrics system. We are using Sonarqube to analyse where our code lacks attention. Sonarqube is quickly set up inside a docker container (maphynn_sonarqube) and provides support for several languages. As such, typescript wich is used by our backend. But plugins can also provide metrics for other languages. We used this plugin for our frontend which uses flutter and dart. The sonar-scanners are run during the ci/ce pipline on gitlab for the dev branches. The analysis of the website is currently not working because we do not have any unittests and the sonar-scanner expects test and coverage outputs.

Now lets take a look at how metrics improved our code. I will take the app for an example. First there were approx. 900 code smells ?! What in the world have I done? … well maybe it isn’t entirely my fault… so I think the plugin for dart enables EVERY dartanalyzer rule. Some of the even are contradictory -> Use final modifier for variables that are only assigned once. OK did that, but hey don’t do it for variabels in methods… but you told me to … anyway. It also desn’t like JSON strings no idea why… Anyway after a bit of work we are down to 400ish. And I will from now on use final and write some comments.

Decreasing number of code smells (and bugs).
The use of the modifier final was probably the biggest concern

The following is an example where I decided not to change anything:

I don’t see why I wouldn’t want do that. Sure the name of the variable implies the type but it also doesn’t hurt.

For the Api there were security issues which turned out to be the ‘hardcoded’ passwords for the api documentation so nothing to worry about.

So this is our metrics system. Hope you find this interesting and see you guys next week!

P.S. if anybody also uses sonarqube and has sucessfully activated the authentification using their gitlab, please tell me how. Somehow gitlab appends a “/gitlab” to the end of the redirecion url and it doesn’t work.

P.S.P.S. I think it might be better to set up metrics earlier when you have less code. It might be a lot of set-up in the beginning, but you won’t be overrun by things you did wrong the last year.

Hello there!

Welcome back for semester two. Team MAPHYNN is back and ready to tackle the oncoming months of work despite the corona virus. So speaking of the team, since our friend Niklas left the team (F) Team MAPHYNN are now:

  • Tim: website
  • Felix: backend -> matchmaking
  • Clemens: backend -> api
  • Marvin: app

Last semester we created a basic website and app with working login and friendlist. For this semester we plan to implement a chat mechanic and the heart of our project: the matchmaking algorithm.

Our goals are therefore defined by these use cases marked in orange:

https://gitlab.maphynn.de/maphynn/maphynn/-/blob/master/documents/img/UseCaseDiagram.png

Database and class diagrams

In this week we present to you our database as well as our class diagrams.

We created the ERM for the database using draw.io:

For the api which is written in typescript we used tplant to generate a PlantUML diagram:

The website is written with angular dart and we used dcdg to generate a PlantUML diagram:

For the app we also used dcpg since it is written wich flutter and dart:

Since we used command line tool to generate these diagrams we plan to add a stage to our CI pipeline that generates and adds the PlantUML to your markdown documentation.

Unfortunatley the PlantUML renderer provides not possibility to set a width constraint and since there are no connections between the classes the generated images are quite wide. When rendering to png you can’t see everything but svg works. Unfortunatley the GitLab markdown integration of PlantUML defaults to png …

The very first Post

Hello! On our way to world domination, we need an army. Thus we plan to unite gamers all around the globe, to play their most favorite games together.

The main components of this system in general will be as follows: App, Website and the required Backend.

The idea is to create an App for universal match making. Users will be able to create an account, where they can list their favorite games. When they don’t want to play alone, they can search for other gamers with similar interests and skill level. Then they can exchange account names to play together.

If you don’t like to use an App, you will be able to use our website, which will provide the same functionality.

The technologies we think fit best for this project are:

  • Website: Dart, Over_React
  • App: Dart, Flutter
  • Backend: TypeScript, node.js, REST Api