<commit_before>\section{Mistakes and new Experiences}
A big part of projects like this is reflecting back and see which mistakes were made throughout
the project lifetime. We can then learn why these mistakes happened and develop strategies to
prevent them from happening in future projects. This section describes the various pitfalls and
mistakes that were made throughout the project and what we have learned from these.

\subsection{Establishing project requirements}
A lot of time was lost by prematurely starting the design and planning phase before the
requirements were properly understood and established. This was also caused by the shifting 
requirements that the customer had every meeting. We should have properly established a list of
requirements and agreed with the customer that these were the final requirements. In addition we
should have not started major planning, like setting up resource management before the requirements
were properly set after a few meetings with the customer.

\subsection{Hardware problems}
There were various issues with the hardware for our prototypes. A big one was the large delay
from when we initially ordered the hardware and until we received them. It took just over two months for
some of the necessary hardware to arrive, resulting in a delay in our integration and testing process.
This was a major setback to our plans and this time was mostly spent writing documentation, planning
and testing the libraries for bugs. Due to miscommunication within the project group some of the 
hardware we received was either wrong or not quite optimal for our specifications. In addition we had 
not ordered backup or spare parts, so when for example the LCD screen broke, we had to find other 
workarounds to solve this issue. In hindsight we should have made sure that the list of hardware orders 
were correct and ordered additional spare parts in case something broke or malfunctioned.

\subsection{Group meetings}
A chronic problem inside the group was late attendance to internal team meetings. For various reasons members of
the group would meet hours later than the agreed or planned time. This was somewhat mitigated by having 
the meetings later in the day and working into the late hours of the night.

\subsection{Limiting project scope}
A problem caused by an early design choice was the level of portability. Initially we coded our libraries to support as a wide range of platforms as possible (PC, Android, iOS, etc.). This caused various generalizations and concepts that didn't work to well with the Android platform. One prevalent example was callbacks and threads inside the Android system. While our library was based on multi-threading and callbacks through an observer pattern, this does not work on Android Java the same way one would expect on a PC. Since every prototype and testing software we coded was based on the Android platform this caused major problems and we had to spend a lot of time rewriting and redesigning libraries. So our choice of portability caused many problems considering the customer explicitly stated that we only needed to support Android. While portability is usually a good thing, the product quality should not suffer if it is not a high priority requirement.

\section{Further Work}
This section describes ideas, code and features we did not have time or resources to
finish at the project deadline. The section can also describe various interesting concepts 
that we visualized, which we could have explored given more time.

\subsection{Supporting more communication technologies in ComLib}
Currently the ComLib only supports Bluetooth connections. Further work would be
to add support for additional communication technologies such as WiFi and Near Field 
Communication (NFC). The ComLib has been implemented so that this work should
be as easy as possible. Simply extend the Protocol class and implement the input and
output communication and the implementation should be fully forward and backwards
compatible with other versions of the ComLib.

\subsection{Supporting additional Social networks}
The SocialLib currently supports Twitter and Facebook. Support for additional social
networks like Google Plus, LinkedIn or MySpace was planned as future work. The
SocialLib has also been implemented to accommodate this process as simple as possible
for the developer.

\subsection{Multi-Platform}
The Bluetooth part of the ComLib has been implemented using Android SDK. This means that 
the Bluetooth part of the library will only run on an Android platform. The ComLib protocol
itself however, has been designed to support any type of platform. This means the ComLib
could be expanded to support other types of platform such as Bluetooth on iOS. This
should preferably be implemented as a common interface, so that the developer only has to use
Bluetooth, and the ComLib itself figures out if it is to use the Android version or the iOS version of
the Bluetooth Protocol.

\subsection{Security}
Currently the ComLib offers no level of security. Anyone with the mac address can connect
and have access to the full functionality of each prototype device. A future possibility could
be to define a security standard in the ComLib protocol like authentication with a password.

\subsection{ComLib's size parameter}
The ComLib was altered the last week before a presentation to support larger packages. This was to properly
be able to retrieve all metadata from the arduino. This was suggested to be done by asking for the metadata
in several packages, and then merging those packages to get all the metadata. We did not revert the changes
as this was not prioritized in the small amount of time we had left in the project

\section{Conclusion}
The final scope of the project was much bigger than we originally planned and envisioned. This large scope
was mainly caused because of all the different prototypes we had to implement. Originally we had planned
to implement one prototype with accompanying application, but ended up creating two developer libraries
along with 3 prototypes and 6 different Android applications in addition to a webpage for distribution of oSNAP
compatible software. While challenging this was also a lot of fun, since we had a lot of freedom in developing
these products in the way we liked.

The weekly meetings with the customer proved to be very valuable and
a good way for the customer to keep track of progress. We showed the fruits of our work from the earlier
week to the customer, and he could steer us in the direction he desired and comment on the results.<commit_msg>herpaderp<commit_after>\section{Mistakes and new Experiences}
A big part of projects like this is reflecting back and see which mistakes were made throughout
the project lifetime. We can then learn why these mistakes happened and develop strategies to
prevent them from happening in future projects. This section describes the various pitfalls and
mistakes that were made throughout the project and what we have learned from these.

\subsection{Establishing project requirements}
A lot of time was lost by prematurely starting the design and planning phase before the
requirements were properly understood and established. This was also caused by the shifting 
requirements that the customer had every meeting. We should have properly established a list of
requirements and agreed with the customer that these were the final requirements. In addition we
should have not started major planning, like setting up resource management before the requirements
were properly set after a few meetings with the customer.

\subsection{Hardware problems}
There were various issues with the hardware for our prototypes. A big one was the large delay
from when we initially ordered the hardware and until we received them. It took just over two months for
some of the necessary hardware to arrive, resulting in a delay in our integration and testing process.
This was a major setback to our plans and this time was mostly spent writing documentation, planning
and testing the libraries for bugs. Due to miscommunication within the project group some of the 
hardware we received was either wrong or not quite optimal for our specifications. In addition we had 
not ordered backup or spare parts, so when for example the LCD screen broke, we had to find other 
workarounds to solve this issue. In hindsight we should have made sure that the list of hardware orders 
were correct and ordered additional spare parts in case something broke or malfunctioned.

\subsection{Group meetings}
A chronic problem inside the group was late attendance to internal team meetings. For various reasons members of
the group would meet hours later than the agreed or planned time. This was somewhat mitigated by having 
the meetings later in the day and working into the late hours of the night.

\subsection{Limiting project scope}
A problem caused by an early design choice was the level of portability. Initially we coded our libraries to support as a wide range of platforms as possible (PC, Android, iOS, etc.). This caused various generalizations and concepts that didn't work to well with the Android platform. One prevalent example was callbacks and threads inside the Android system. While our library was based on multi-threading and callbacks through an observer pattern, this does not work on Android Java the same way one would expect on a PC. Since every prototype and testing software we coded was based on the Android platform this caused major problems and we had to spend a lot of time rewriting and redesigning libraries. So our choice of portability caused many problems considering the customer explicitly stated that we only needed to support Android. While portability is usually a good thing, the product quality should not suffer if it is not a high priority requirement.

\section{Further Work}
This section describes ideas, code and features we did not have time or resources to
finish at the project deadline. The section can also describe various interesting concepts 
that we visualized, which we could have explored given more time.

\subsection{Supporting more communication technologies in ComLib}
Currently the ComLib only supports Bluetooth connections. Further work would be
to add support for additional communication technologies such as WiFi and Near Field 
Communication (NFC). The ComLib has been implemented so that this work should
be as easy as possible. Simply extend the Protocol class and implement the input and
output communication and the implementation should be fully forward and backwards
compatible with other versions of the ComLib.

\subsection{Supporting additional Social networks}
The SocialLib currently supports Twitter and Facebook. Support for additional social
networks like Google Plus, LinkedIn or MySpace was planned as future work. The
SocialLib has also been implemented to accommodate this process as simple as possible
for the developer.

\subsection{Multi-Platform}
The Bluetooth part of the ComLib has been implemented using Android SDK. This means that 
the Bluetooth part of the library will only run on an Android platform. The ComLib protocol
itself however, has been designed to support any type of platform. This means the ComLib
could be expanded to support other types of platform such as Bluetooth on iOS. This
should preferably be implemented as a common interface, so that the developer only has to use
Bluetooth, and the ComLib itself figures out if it is to use the Android version or the iOS version of
the Bluetooth Protocol.

\subsection{Security}
Currently the ComLib offers no level of security. Anyone with the mac address can connect
and have access to the full functionality of each prototype device. A future possibility could
be to define a security standard in the ComLib protocol like authentication with a password.

\subsection{ComLib's size parameter}
The ComLib was altered the last week before a presentation to support larger packages. This was to properly
be able to retrieve all metadata from the Arduino. A suggested solution was to ask for the metadata
in several packages, and then merge those packages to get all the metadata. We did not revert the changes
as this was not prioritized in the small amount of time we had left in the project.

\section{Conclusion}
The final scope of the project was much bigger than we originally planned and envisioned. This large scope
was mainly caused because of all the different prototypes we had to implement. Originally we had planned
to implement one prototype with accompanying application, but ended up creating two developer libraries
along with 3 prototypes and 6 different Android applications in addition to a webpage for distribution of oSNAP
compatible software. While challenging this was also a lot of fun, since we had a lot of freedom in developing
these products in the way we liked.

The weekly meetings with the customer proved to be very valuable and
a good way for the customer to keep track of progress. We showed the fruits of our work from the earlier
week to the customer, and he could steer us in the direction he desired and comment on the results.
{'fraction_non_alphanumeric': 0.018112921561197422, 'fraction_numerical': 0.00030314513073133765, 'mean_word_length': 4.802990325417766, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '514646', 'n_tokens_mistral': 2769, 'n_tokens_neox': 2685, 'n_words': 2099}