Week 6: 4th Mar – 11th Mar

Task Breakdown:

TaskDateDuration
Weekly meeting04/03/211 hour
Design meeting07/03/211 hour 30 mins
Programmer meetingprobably 09/03/21to do
Significant data structures workto doto do
Class interface description work to doto do
Crying07/03/21 - 11/03/21104 hours 30 mins
Weekly totalN/Ato do

Weekly meeting takeaway:

The main topic of this week was the design spec. How are we going to approach, it, how is work going to be broken down, what needs to be done when and how. We’ve decided to meet up on Sunday to discuss this, further detail will be added to this page once this happens. Likely I will be part of conceptualizing how things will be built in the program and will feed this back to the members who are in charge of producing the various diagrams. In the meantime, I’ll be sure to read SE.QA.05 to get a rough idea of what is required.

Design meeting takeaway:

There is a lot to do. Too much even. Regardless we’re taking it on as a group effort. Programmers will get together to figure out the details of how things will be linked together later. This info will be fed down to the producers of the UML diagrams. Besides that, we’ll all be contributing to class descriptions. A document intro will be written last. A small program overview will be produced, component diagrams come later.

I specifically need to do the detailed design for complex data structures and contribute to the programmer meeting as well as the class descriptions.

Week 5: 25th Feb – 4th Mar

Task Breakdown:

TaskDateDuration
Weekly meeting25/02/211 hour
Fix timer code with Edd25/02/21, 02/03/21, 03/03/215 hours
Create JUnit tests for timers03/03/213 hours
Move around GitLab stuff02/03/2130 mins
Weekly totalN/A9 hours 30 mins

Weekly meeting takeaway:

In this week’s meting we addressed progress on last week’s items and have devised ways to split work more evenly as well as an investigation to find more potential work to do in the coming weeks.

Personally, last week was a bit rough and scheduling didn’t line up so I’ll get together with Edd to attempt to fix and publish a version 2 of the timers code.

Additionally, I’ll use this code to create some example unit tests with JUnit and also upload this to the repo so the other developers have something to go off of when they inevitably have to construct their own unit tests for the modules they are working on.

Finally the group have now realized things are in the wrong place in the GitLab, so all currently uploaded material is to be moved to appropriate locations on an individual basis.

Fixing timers with Edd:

After some lengthy talking with Edd I was able to get a good idea of the intention behind how the timer is intended to be implemented. To summarize, the timer is intended to be a self contained item that’s callable from anywhere in the program, therefore you don’t have to initialize it as an object. In fact, due to the way it’s made, if you do it’d cause issues with threads, oops!

So then we got to fixing issues. To start, there was a lack of privatization for internal methods and variables – I was able to edit the current running time of the timer from outside by simply calling the variable, it didn’t really like that. After this we did some troubleshooting as the timer broke whenever it was paused and unpaused or simply another timer was started after another ended. This as it happens was actually an issue with overlapping threads. Put simply, if you destroyed and created identical threads too fast then it would stop functioning correctly. The internal methods for pausing actually creates a new timer thread with the remaining time of the first timer whenever you pause and unpause, the same concept applies to when timers ended and started too fast. Fixing this was fortunately fairly simple, if we buffer how fast you can call the method then the JVM has enough time to handle the threads. Unfortunately this does have a worst case scenario of the timer drifting by roughly second over 20 frame perfect pauses and unpauses, but I really don’t think that’ll be an issue in practice.

Update:

After having another look at the code while creating JUnit tests, I managed to crack some of the final bugs and generally cleaned up the code a little. The pause drift has been reduced to 5ms, which is already within margin for error with normal operation, yay!

GitLab move:

This is fairly self explanatory. Draft-docs contains items to be distributed appropriately into docs and dev. As for me, I moved my JSON research and the timers into dev, and then updated the timers to the version 2 that came as a result of mine and Edd’s work.

Later on Thomas was having issues with the GitLab IDE, as it wasn’t allowing him to delete redundant directories without creating a separate branch. I was able to help by just using the cli, this basically didn’t take any time at all really.

Example of JUnit with timers:

After my initial research of JUnit, I’ve implemented some basic functionality tests to ensure that the timers are working. These tests can also serve as a useful example for the other developers in the group to create their own tests for their own modules going forward!

Week 4: 18th Feb – 25th Feb

Task Breakdown (revised):

TaskDateDuration
Team meeting(s)18/02/21, 21/02/212 hours
JUnit Research24/02/212 hours
Check Edd's timer code24/02/215 hours
Weekly TotalN/A9 hours

Weekly meeting takeaway:

In this week’s meeting we had a discussion about more administrative items like deciding project leader roles and QA roles. Additionally, we went through and checked the blogs, I noted that I should be noting the date of each item, so from  now on I’ll add a date column to the task breakdown tables. I also noted that a short description of each task is desirable, with bolded titles for easy identification.

For this week I’ll look into how to use JUnit to create module testing, this will be essential later on during development.
Additionally I’ll check over Edd’s timer code once it’s on the GitLab.

JUnit research:

I spent some time looking into JUnit as a method of constructing unit tests.
Luckily as it would happen, you can add JUnit as a library with maven just like GSON, meaning that there won’t be any issues with getting external libraries in for anyone.

I found that the only key parts of JUnit that we’ll likely need are “Tests” for the basic structure, and “Assertions” for checking correctness. We can combine these with some custom written testing code that uses the actual methods in the real code to execute robust and quickly repeatable unit testing.

However until we have any more concrete code that might be close to what’ll actually be in the final program I can’t really create any good examples, as they typically use the methods of the programs they’re testing, was well as external parts that need to be tailored on a case by case basis.

Checking Edd’s timer code:

I spent an embarrassingly long amount of time looking over Edd’s code, writing out an accompanying class to give the timer a test drive. It… didn’t really work properly? If you instantiate a timer object, you can’t use it. If you don’t then you can… but it stops functioning after a single timer has either finished, been paused or stopped… which is all that can happen to the timer… Upside is that it does run in the background and the timing is fairly accurate on the first pass. Other things to note are the fact that internal variables and methods are left public, whoops!

I conclude that this section of code needs some pretty major redesigning, but at least the core functionality seems to be buried in there somewhere.

Due to a lack of time this week I’ll likely have to get together with Edd next week and we can spend some time fixing it together.

Week 3: 11th Feb – 18th Feb

Task Breakdown:

TaskDuration
Team meeting1 hour 5 mins
Fix GitLab perms + make usage guide20 mins
Role email30 mins
Help specify functional requirements to solidify tests2 hours 30 mins
Weekly total4 hours 25 mins

Meeting takeaway:

In the meeting we discussed a few things about our progress last week. I finished my role as the code works fully but I’m to help with making sure we’re crystal clear on what exactly the functional requirements are so we can make proper tests. I might also help around with any other code based problems if anyone asks.

Before reading the current test document, I read through SEQA6 to get an idea of what I should be looking for with the tests, to give me a better idea of what’s actually required of said tests. In doing so, I discovered that developers have to create module tests as soon as possible in the development process. Doing so requires you to actually know how to write unit tests, so spike work is needed to figure that out, I’ll bring it up in the next meeting.

Read the test document and cross referenced with the requirements document, commented on any potential missing tests for the requirements.
We need to decide on how to implement record keeping in the program, maybe talk to Chris? The spec is unclear.

Week 2: 4th Feb – 11th Feb

Task Breakdown:

TaskDuration
Team meeting2 hours 10 mins
Research and implement JSON storage solution.6 hours
Weekly Total8 hours 10 mins

Meeting takeaway:

From the meeting we determined that for storage, a JSON based solution would be more ideal as a SQL based system could be overkill or unnecessary work due to all the overhead needed to set it up accounting for multiple users that won’t exist in the final program. Besides that it looks like we’ll be doing exercise sets that are customized from a pool of user defined exercises, so the flexibility that this system provides makes it the preferable choice.

Therefore my task is to research how we’d go about implementing that in Java, anything I make will be stored in the draft-documents section of the repository under “JSON-Research”.

Week 1: 28th Jan – 4th Feb

Task breakdown:

TaskDuration
Team meeting 12 hours
GitLab practical1 hour
Reading intro documents30 mins
Setting up blog1 hour
Java persisting data research2 hours
Weekly Total6.5 hours

Elaboration:
The first week of the group project!

This week our main aim was to get everyone to a good level of understanding about what we need to do and what we need to know to be able to achieve what we need to do.
So after the meeting we set about doing the GitLab practical for everyone who could attend (those who couldn’t were added afterwards).
I hosted the repository and Hannah was able to add to it, confirming everything works as intended, including merges.
Afterwards I also added the group meeting mins to the repository as we’ll be using it for project storage going forwards.

Most of the group favoured a google docs solution for their blogs but I’m using WordPress blog as I think it’s a bit of a more elegant solution, as it makes getting to new posts easier for Neal as well as providing good commenting functionality and organisation by recency.

Due to some issues with organisation, I ended up switching tasks for the most part with Edd, so I’m now looking at data storage.

Persisting data in java research:
The first part of the process is to break down the problem to find out what needs to be stored in the program as a whole, this will allow us to get a good idea of the various different possible techniques we could use.

From the requirements, a quick list of items that need to be stored could include: preconfigured exercise routines with associated data (total time, number of exercises, etc), available exercises (with metadata (time, category etc)), exercise guidance (mentioned separately as the medium is different to text potentially) and finally exercise completion records.

The specification states that the program will be a single user system and stored locally on a single device, we don’t have to take portability, access and multiple user data into account.

In theory we want to keep the number of dependencies to a minimum, so we want a solution that will work for as many of the requirements as possible, with as little bloat as possible.

The main two methods of persisting data that I can find is a RDBMS system like SQLite or a NoSQL system like GSON. While it’s most likely possible to make both systems work for our project, we can analyse the specific use case to try and figure out which is preferable.

Looking at the overall problem we’d have three main interlinked components, the exercises, the exercise routines and the exercise completion record.

Exercises can be quite rigid, the only potential variance issue is with different forms of guidance, but that can be avoided if a single method is decided upon for all of them.

As specified in FR5 and FR2, the pool of exercises in a set is not controlled by the user and can be standardized (if not then complications could arise if using a SQL based system).

In conclusion, as far as I can tell, the main concern is this: can the data format be standardized? If yes, then a SQL system is probably preferable, you can create a single database with 3/4 linked tables that control all of the stored data. If no, then a JSON based solution is the way to go, as it’s additional flexibility allows for things like pre-set customized exercise set pools without the headache doing it in SQL would cause.