Task Breakdown (revised):

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.

Task Breakdown:

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.

Task Breakdown:

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”.

Task breakdown:

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.