Crossfit Kalmar - Lnu.seorion.lnu.se/pub/education/course/1DV611/vt17/Slutrap...Crossfit Kalmar but it was not fully operated and was put on ice due to work that took a lot of time

Crossfit Kalmar

Crosstag

Client: Johan Roth, Crossfit Kalmar Product owner: Johan Lundström Project Group: Kristoffer Svensson, Adam Österlund, Eric Sjöström Jennerstrand, Kevin Amilund, Kim Nilsson, Filip Rydberg, Patrik Erlandsson, Linus Anderson Course: Web Project 1, 1DV411

Abstract This report discusses our work process and the development techniques that has been used in this 10 week long project. We have learned to work in a larger group of 8 people, to work with a customer, but also to work with and towards a product owner. The customer, Crossfit Kalmar, had a problem with managing all their members in an excel file. They wanted some kind of tag system that handled tag events from the members when they arrive to work out, mostly to see some statistics on how often people work out and at what time. The project's goal was to find a solution to their problems with the member management and solving a stylish yet convenient way to receive tag events and show it to both the customer and the members. We were asked to continue developing the product Crosstag that were already started and implemented, but not fully developed, at Crossfit Kalmar, and had been put on ice for 2 years. Crosstag is a small, lightweight, RFID tagin system for a gym and created by Johan Lundström who became our product owner but also a mentor in this project.

Autistic 8 Linnaeus University, Kalmar

1

Table of contents 1. Introduction

1.1 Background……………………………………………………………………...3

1.2 Project goals and objectives…………………………………………………....3

1.3 Project group description……………………………………………………….4

2. Implementation 2.1 Methodology and Technology………………………………………………….5

2.2 Additional functionality……………………………………………………….....6

2.3 Deviation………………………………………………………………………...6

2.4 Testing…………………………………………………………………………...8

2.5 Results…………………………………………………………………………..9

3. Conclusion

3.1 Conclusions……………………………………………………………………..12

3.2 Group and project overview……………………………………………………13

3.3 Further development…………………………………………………………...15


2

Introduction

Background

Crossfit Kalmar is a Crossfit gym who has been stationed in Kalmar for a few years. The owners, Johan Roth and Stefan Håkansson Aleborn, had a desire to find out how often members train and at what times. They also had a desire to get a better solution to their member management since they used an excel file to handle all members locally. At this point they had contact with Johan Lundström who trained at Crossfit Kalmar but did not live in Kalmar, so they came up with a solution that both parties would benefit from. Johan Lundström, who was a programmer would develop a simple system for Crossfit Kalmar in exchange for free training when he was visiting Kalmar. He created Crosstag, a small simple tagin system, on his spare time and launched it at Crossfit Kalmar but it was not fully operated and was put on ice due to work that took a lot of time. It was at this stage we were asked to continue developing Crosstag, not only for Crossfit Kalmar but also for Johan Lundströms OpenSource project. Project goals and purpose

The project's goal and purpose is to keep developing Crosstag and to deliver a small and lightweight RFID tagin system for Crossfit Kalmar. The system shall include an easier solution for their membership management. Instead of an Excel file, we will deliver a simpler local database. The memberinformation is retrieved from Fortnox and added into the database. The additional information on membership status and when membership expires is added manually by the owners. Another feature to be shipped is a page that displays statistics for the owners. The statistics are based on their needs and desires but the ideas we have had in mind is to show tag events per month, week and day. Even the member information such as gender and tag events by gender is something we think can be included.


3

For the members, which is one of the users of the system, we want to ship a static page that will display information about the specific member who tags in. The page displays the information for a while and then disappear. Another feature of the static page is to display statistics about the top 5 of those who exercise the most at Crossfit Kalmar. This is a motivation for them to tag in when they come and maybe give them a boost to practice more. We will also develop a user friendly admin page for the owners. On the admin page they will be able to sync their local database with their Fortnox account. They will be able to edit users on the local database but also on their Fortnox account. This will make it easier for them to manage their members, to tie a tag to a member as an example. The statistic page will also be part of the admin page. In addition to the goal of developing Crosstag we aim to learn how to work in a larger group and to get more insight on how to work with a customer . Other goals are to learn new techniques since Crosstag is written in Python and will run on a Raspberry Pi with Ubuntu installed. Project group description

In the project group we see us as equal and everyone is pulling their weight . Everyone in the group complement each other with their skills and contribute with different characteristics and responsibilities. Everyone will help with everything and if someone needs any help, there is always one who can help to solve the problem. At the beginning of the project we set up different responsibilities to make the project work easier and more structured. Project leaders: Kristoffer Svensson & Eric Sjöström Jennerstrand Account manager: Patrik Erlandsson & Linus Anderson Technical manager: Filip Rydberg & Kim Nilsson Git & deploy manager: Adam Österlund Test manager: Kevin Amilund Nilsson


4

Implementation

Methodology and Technology

We have been following an iterative developmentprocess where we have had meetings every monday with our supervisor, and standup meetings every day with our product owner. We decided to have specific work hours where we would meet every day at 11:00 except for mondays when we have our supervisor meetings at 10.30. At 13:00 we had our standup meetings and we worked to atleast 15:00 every day. We tried to deliver to our customer every friday but sometimes complications came in the way of the delivery, such as hardware problems. For example when our RFIDreader burned up. In such cases we would just postpone our delivery to the next week. To get more organized and to split up our tasks more efficiently we used the Kanban method which helped us significantly during the project, we used two small whiteboards and postits to achieve this. We also did a lot of pair/mobprogramming, which means that we were 23 persons on one computer and solved problems together. This is something we usually decided at the standup meetings we had every day. The hardware, software and notable languages and frameworks.

● Python 3 ● Flask

Framework for Python. ● SQLITE

Lightweight Database. ● Fortnox API

Fortnox is a swedish billing service that Crossfit Kalmar uses, we use their API to fetch all information about their customers.

● Javascript ● HTML/CSS ● Raspberry Pi

A small singleboard computer. It handles our whole application. ● Ubuntu (Linux) ● RFIDReader

Reads RFIDtags within five centimeters. We use it for our tagsystem.


5

Additional functionality

The program contains some additional functionality beyond the original demands to make the system more user friendly and easy to use. There is a function where you can find the last tagins to see who are in the gym right now. If someone wants to take a drink or something else that they have to pay for and noone are around to accept the payment, it’s possible to add a debt in the system to give the owner a notice that a member have a debt to the gym. We have worked a lot with statistics and presenting it for the gym, it’s possible to show statistics from a certain day, month or year. It’s also possible to see how many men and women are members of the gym and which gender is most active. When a member tags into the gym, a screen will present the members information like name, expire date, join date, etc. The screen at the entrance of the gym also displays a top 5 list of the members who have trained most this month. The integration with Fortnox is an interesting extra feature, it allows the gym owners to edit member information directly from the Crosstag interface without having to change the same information on Fortnoxs website. It allows the system to take all the members the gym have in Fortnox and download them to the local system.

Deviation

Wheezy/Jessie for python3.4 Our first real problem arose when we tried to do our first deploy to the raspberry pi at the gym, at around 3 weeks into the project (week 6). Our product owner, Johan Lundström, had recently ported his application from python 2.7.x to python 3.4.x. When we tried to install the necessary modules and external dependencies (including python 3.4.x) we noticed that the OS installed on the RPi was an older version (Wheezy) that was incompatible with python 3.4. This meant we had to wipe the memory card clean and reinstall the OS and different modules needed to run the application from scratch. Having previously no experience working in linux this proved quite a challenge and a big time sink. For starters, we had to buy a new SD card for it since Jessie requires close to 4gb, which was the total size of our current one. With Jessie installed and up and running, we could finally run the application. The most time consuming part of this process was figuring out why python 3.4.x didn’t run, a process of many hours and googling before we finally found out why this happened.


6

RFIDreader burning The RFIDreader we were supposed to use was quite slow to respond to tags. We figured this was normal and didn’t think much about it. However we noticed after a reboot it worked much better for a few brief moments, so we thought it could be some faulty hardware and we suspected the usb to miniusb cable since it was brazed by one of the members at the gym. Therefore we decided to buy a new usb to miniusb cable and see if this fixed our problems with the slow reader. Sadly, we could quickly smell burning plastic and saw smoke rise from the RFIDreader and this was the end of this reader. Even though our product owner quickly sent a new RFIDreader on its way, this set us back many days since we couldn’t deliver anything worthwhile to our customer without the tagging functionality. In retrospect we know that there are two different USB to MiniUSB cables, type A and type B. Fortnox API In the inceptionphase we thought that we would fetch all the customers from Crossfit’s local Exceldocument, but it was too unorganized to handle. So we had to try to retrieve them from the Fortnox database. We spent almost an iteration to fix this issue due to problems with accessing the API. Most of the time were spent on finding out how to get the accesstoken which were really annoying but when we got access to Fortnox we could start testing the Fortnox API. We had a test account on Fortnox with full admin rights where we could easily gain access to the keys needed to call and fetch the data from their API. The real Fortnox account our customers used did not have any of these admin rights however, so several days went by without us being able to proceed with storing their members to our local database. Also a setback that made us lose out on an opportunity to deliver something meaningful to the customer. Scalability SQLITE We had set up a static page to display a more userfriendly interface for the gym members tagging in. We had also prepared functionality to show some statistics on the top 5 users (based on the amount of tagins the current month) on this page as well, updating each time someone tags in. The algorithms for fetching and handling the data ran fine on our laptops, but once deployed onto the Raspberry Pi we noticed the processing powers of a first generation Raspberry Pi wasn’t up to par with our laptops and the whole server froze completely. We noticed this very late in production (20160309 to be precise) which caused some panic among the group. Now we had some issues, since the amount of data we tested with was around 200 active users and 50100 tagins, a very small amount of tagins compared to what we’d have running in the real version. We now had to redo parts of the application to be able to update the statistics each time someone tags without completely killing our Raspberry Pi. Our


7

previous solution was fetching all active users and all tagevents into two separate arrays, using a nestled loop over the two arrays to fetch the amount of tags. This proved to be extremely inefficient as the time it will take grows exponentially with the amount of data growing larger. So, we had to scrap this idea and come up with a way to store and fetch data for statistics faster. Happily we were able to solve it by changing some tables in the database for better use of SQL queries, and now the time it takes to fetch and show the data will only grow linearly with the amount of users, something that will be maintainable looking at a realistic amount of gym members. Setting up Raspberry Pi As mentioned at the start of this section we had to upgrade the Raspberry Pi to “Jessie” for the use of python 3.4, which the Crosstag software had earlier been updated to. This also meant reinstalling all the different packages and repositories we needed for the project. Not only packages such as “python3” and “Flask”, but also stuff like “pip” which is a package handler that we needed to install all other packages for the project. This is something we didn’t really think about at first and had us stuck for a few days. Browser on boot with Raspberry Pi One thing that we decided ourselves to implement was to make sure the RPi boots to a web browser showing the static tagin page, in the event of a complete power shortage we didn’t want our customer and gym members to stare at a terminal. We thought this would be a simple task but it turned out to be a massive time sink. There were tutorials but none of them seemed to work for us and we did not know why. Eventually we figured out that the rc.local we ran our startup commands from is ran before a user (pi) is logged in, basically it ran the commands as the root user. It happily started up servers and ran scripts but opening a browser was apparently not possible. After many failed attempts we spoke to our product owner who looked into this. He (allegedly, most likely to make us feel better) also had problems getting this to run properly, but eventually it was solved. However trivial this might seem this took us a good chunk of hours to get working.

Testing

For testing we have only used manual tests. We created test cases out of our requirements which were not only basic requirements, but also requirements that were developed over time. One example of a test cases are “Link a member to last used tag”. We did manual tests to see if the function really works by starting the reader in a terminal and send a tagnumber. Then we went to a user and clicked the button “Link user to last tag” to see if this user gets the correct tagnumber. If the user got the correct tagnumber the test was a pass, and if something went wrong it was a fail and we had to redo the test after fixing the code.


8

To test the hardware version we took an actual physical tag, held it up against the RFIDreader and tested the static page which the members will see, to see all the changes that we made worked and were correct. We also gave Johan and Stefan (the gym owners) their own tags so they could test the tagin page to see if everything were correct and looked the way they wanted and displayed everything necessary. We did some manual stress testing were we took several tags appointed to different members and registered them after each other with minimal time between and analyzed the outcome.

Results

The final product which will be delivered to CrossFit Kalmar includes the following:

● A Raspberry Pi with the program and a memberdatabase ● A RFIDreader connected to the Raspberry Pi and a computerscreen ● A weekly automatic email with a list of members who haven’t made a tagin in two

weeks. ● A daily automatic sync with the database and fortnox. ● An easyaccessible web admininterface with seven mainfunctions search user, all

users, last tagins, statistics, latecomers, debts and sync. ○ Search user Displays a searchform for finding a specific member. A search

can be made by name, email, phone, fortnoxid or index.


9

○ All users Displays all members in the database. The active members are shown by default but there is functionality for filtering by the other statuses as well (inactive, frozen, free and special).

○ Last tagins Displays the ten most recent tagins and the members connected to them.


10

○ Statistics Displays statistics based on tagins as well as data from the memberdatabase. Specific days can be chosen.


11

○ Latecomers Displays a list of all members who haven’t made a tagin in two weeks.

○ Debts Displays a list of all created debts and the members connected to them.

○ Sync Manually syncing the database and fortnox.

Conclusion Conclusions

This project has really been a great experience for all of us as programmers. Not only due to that we have been exposed to a large variety of new techniques but also by having real demands from a customer to work towards while also having the productowner with us on an almost day to day basis. In the early stage of the project everything was brand new to us. The code, the hardware, the dependencies, and even the whole operative system. We didn’t really know what to do or where to begin. From there on we have only gained more and more understanding for the product and everything around it, and we have also received important knowledge in areas which we didn’t even consider when the project started, such as how demands from a customer easily can change or be misunderstood, and how important an early deployment really is for discovering potential errors and bugs in the development phase.


12

We also stumbled upon problems with scalability. Having little or no previous experience working with larger amounts of data we didn’t structure the application to be scalable. This caused us to have to redo parts of the application very late in the development process. Doing this we had to rethink the algorithms of how the application handled data which was a valuable experience.

Group and project overview

We think it was a good idea that we put up a working environment at Crossfit Kalmar. That way we worked close to our customer and could easily have a communication on different aspects of the project. This created a good connection and information flow between the group and the customer. We could live up to the customers demand and basic requirement. This also made the deliveries to our customer rather naturally. We tried to deliver to our customer every friday, but if we couldn’t make it because of some deviation, that was not a problem since we were there every day. We could then just do the delivery on the following workday. This gave us feedback quick and early which is good since that would affect the final product positively in the long term. We didn’t really discussed technical terms and solutions with our customer since they aren’t technically inclined. Instead we agreed in our group how to go about the problems and requirements that were submerged during the project. As Johan Lundstöm would say: “They want a faster horse, we give them a car!”. As a group we worked really well together. There were never any conflicts and we were always able to discuss and compromise with each other if there were any obscurities or problems. We even had some teambuilding were we went out one night and had a buffé and some drinks together, and we also played some pool from time to time. We think it was this group dynamic that made us wanting to do pair/mob programming. The time schedule was at first kind of difficult to estimate and follow, probably because in the beginning we didn’t really know how much content there was in this project. After one or two weeks when we got into the whole project process and finally got working on the actual Crosstag project, the time became easier to estimate. We think this is because we got routines and when we knew our routines, for example when we knew how many hours of meetings and standup we were going to have, it all just came together. Talking about meetings, it was really good that the supervisor meetings held place in the beginning of each week. This way we could recap the last weeks work and kind of set up a new preliminary plan for the week to come. Sherief, the tutor/supervisor was good at what he did and genuinely seemed interested in what we were doing which helped a lot since he, an


13

outsider, put a lot of enthusiasm into the project. He also helped with some guidelines and gave us some advice about our different solutions. The standup meetings we had every day also helped a lot. They clarified any unclear task and it was here we decided what to do on the specific day. It was here we decided if and with whom everyone would be pair programming. After the standup a discussion would usually follow to discuss any problem that had occurred. Also, it was usually at the standups the tasks would be put up on the kanban board. These standup meetings were Johan Lundstöm’s (product owner) idea which we liked really much. When it comes to testing our product we haven't used unit testing or anything like that. We only used manual testing and our test cases are rather specific. We looked at a test case, tried it manually and wrote a test report for that test case whether it failed or passed. We mainly did this for when we tested the application on our computers, but we also have some test cases for the Raspberry Pi. Now that we are done with our product we feel safe to say that we trust our product and are happy to do our final delivery to our customer. We didn’t however start with testing until later in the project and we did our first deploy to the Raspberry Pi rather late. This was the reason we didn’t find out the statistics and other pages were slow on the raspberry. Thanks to this we hit a “bump on the road” in our project since this meant we had to rewrite some code and/or change tables in the database. Now afterwards, we feel that we should’ve done tests with the hardware earlier to discover these “bumps” to be able to adjust these problems in time without stress. To sum things up, we think we did a good job on this project! The customer is happy, we are happy and we learned a lot. We think we solved our problems rather quick and we worked good as a group. However, it was kind of a small project to be eight persons, but thanks to the pair programming we could divide the work amongst us. We are satisfied with our optimization of our code, the admin interface and the static page for the users to see. What we could’ve done different is that we could’ve tried the hardware earlier, deployed to the hardware more often and made a better timelog with more structure in it. The documentation part felt a little enforced. It felt like we just did it because the course management wanted it from us, not because we needed it. The only things we feel helped us in the documentation is the requirement specification, the test specification and the plans of iterations, the rest we could’ve managed without. Although we see the use of documentation we felt that it drew some focus away from the actual product development sometimes.


14

Summary of what we have learned:

● Working in a larger group. ● Git workflow with branches. ● Linux environment. ● Python programming. ● Working with real customer demands. ● Working with a real product owner. ● Working towards a Raspberry Pi. ● Dependencies such as: Flask, SqlAlchemy, WTForms, etc... ● Kanban as developmentprocess with daily standups. ● Considering scalability as a factor in development.

Further development

The productowner Johan Lundström has a vision to make Crosstag an easyinstalled, cheaper alternative for smaller gyms who’s budget often can’t allow for a well established, more expensive solution. In the near future there are also plans on moving Crosstag to the “cloud”, which probably will be done by one or two people from this developingteam. By moving Crosstag to the cloud it will make the admin interface alot easier to install in new gyms. The new gym will only need an account and everything will work and the Raspberry Pi will only need to run the RFIDreader and send the information to the cloud. This will also help make the system alot safer. Right now, anyone with connection to the gyms wifi can access the admin interface, but if Crosstag is moved to the cloud it will make it alot safer. Other further development is to make Crosstag a pip package, a pip package is a way to download code directly from the terminal. If Crosstag is a pip package, new gyms can open a terminal and download the system and have everything it need directly. Something else Crosstag needs is if Fortnox is down it would be good to have some type of local storage to save the changes that the gym owners do offline and then send them when Fortnox is back online.


15

Documents

Crossfit Kalmar - Lnu.seorion.lnu.se/pub/education/course/1DV611/vt17/Slutrap...Crossfit Kalmar but it was not fully operated and was put on ice due to work that took a lot of time