Task Breakdown:

Task Breakdown:

Task Breakdown:

Task Breakdown:

Task Breakdown:

Task Breakdown:

Weekly meeting takeaway:

This period of time was a bit less productive due to most of the group, including myself, having a robotics assignment imminently due. However from the meetings we were able to get a bit of general progress towards setting up for integration week done.

Task breakdown:

Weekly meeting takeaway:

From this we got an idea of where the group was with the design spec and organised the date for the review meeting.

Design spec review meeting:

I’ve pretty much done my part of this, except the small things mentioned in the task breakdown. I’ll divert my attention to other parts of the project that need working on. Since we’re now in the Easter break, this post will be updated with all the things that I end up doing in that time.

Task breakdown:

Weekly meeting takeaway:

Not much to say here this week, the main purpose of the meeting was to check up on progress for the design spec. Overall, we now all roughly have an idea of what we need to do and will go into more depth in a review meeting later this week.

Significant data structures work:

Additional progress was made on this, at this point it’s basically finished bar an object diagram.

Small data structures meeting:

In this meeting I fed back critical information, specifically to the UI team on how the system I’ve designed for handling data works, so they can accommodate this in all of their documentation and design going forwards.

Timers work:

This was handled by Edd, I’ll go and bug check this / write more tests for it later.

Task Breakdown:

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.

Programmer meeting:

This never ended up happening as nothing was scheduled by anyone – my week was a little rough so it slipped my mind until too late, we’ll do that next week as a priority.

Significant data structures work:

I spent a decent chunk of time working out what might be required for the system. It was a little difficult due to issues getting in contact with other members of the group but I was able to create a good description of how it works for the backend at least, as well as all that needs to be stored and it’s data type, as well as how everything links together. Diagrams still need to be produced but as the frontend part is still missing I can’t go forward with this yet.

Crying:

I had other assignments to finish this week, so my time was a bit restricted, sorry about that.

Also it was brought to my attention that extra functionality is needed for the timers, I’ll implement that next week.

Task Breakdown:

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!