Dev Post #5 – 10/3/2016 to 10/7/2016

Finishing Up The New Location Service

At the end of last week I was at a point with this task where I just needed to do some quick testing in all the places I implemented this new service layer. I poked around the website a little bit and then submitted a pull request for my changes. During code review, we decided that the tests I had written seemed a little unruly – I was basically trying to emulate the actual workflow of the application using fake repositories. I repeatedly ran into issues trying to get data in-sync across all the test repositories, so we opted to take some time to build out a service layer for our integration test project that would allow us to abstract all the complicated logic for creating a person in each different state of our the application. For instance, as I’ve gotten into more acceptance level testing, I consistently want to create a person who is checked in to a room, or assigned to a room but not checked into it, or who has completed their room report but not checked out yet, or is in the middle of a room change (actually creating the scenario this service was originally made to handle). You get the idea – it was a lot of work that routinely gets repeated every time I want to test some functionality related to this.

Building the new testing service took a bit of work (about a day after it was all said and done) because I had to rewrite several older tests due to the way some of our fake repositories changed. While working through these changes we actually found a bug in the way the location service was working, so it ended up being highly beneficial. Honestly, a lot of the work was confusing…I’m glad I had my boss to pair with because the building the test service requires keeping how pretty much the entire application works in your head at once. I’m confident that moving forward, testing will be much easier with this new test service so I’m really glad we took the time to build it.

Update Registration Enhancements

Finally! Those cards I mentioned about two weeks ago were able to be discussed and officially put on the board to complete. Most of these changes were relatively trivial.

The first was removing the contact information fields from the page – we already know about the student’s email address simply by knowing the student we are updating the registration for, so the email contact field is made redundant. Basically I just deleted the form fields and then updated the end point the form submits to to build the email information from the other passed data (namely the student ID) rather than getting the email from the form submission itself. I was able to delete a good amount of random other JS validation from the page as well.

The next two tasks for this page ended up kind of morphing into a single card. We wanted to have the group lists on this page sorted alphabetically, and to make sure that groups were correctly being displayed to the user based on their permission level. I should preface the next bit of this by saying that there’s a lot of code in this codebase that we’ve worked to try and hide. We’re gradually making it better, but by and large our solution has been to build layers of abstraction over the gross stuff so it’s easier to work with, and to fix it as it becomes necessary. This card ended up dealing directly with some of this gross code. The issue stemmed from the fact that the group lists were being set correctly in some places, but not others – I ended up refactoring the logic for determining what group list to get based on the current user permission to it’s own function and then modifying all the relevant places to use it. Once I had this new function in place, adding a simple sort to it was really easy.

I submitted a pull request, did code review with minimal changes, and finished the card.

Authentication Errors Everywhere

The way our authentication is set up currently, we end up getting a ton of errors when a user tries to log in. The framework the application initially was built on (that we have been working really hard to gradually move away from completely) just throws errors like crazy and uses those errors to see if the user is allowed to log in (as far as I understand how it works). Aside from other glaring issues with this, the major problem we have is that any other error messages we get are lost in the sea of authentication errors. So the first step was fixing the authentication logic to basically use the current solution as little as possible.

The next step to this was to go through and remove the majority of the try-catch statements from the controllers. In addition to having too many authentication errors, our application was swallowing any actual errors we were getting – we want these errors to be logged so we can actually see when something is going wrong. Inevitably this led to me going overboard and refactoring as much code as I reasonably could as I combed through these files. I made them all marginally better – reduced redundancies and complexity, and deleted things we decided as a team we did not want in the application anymore. By and large these were things that were full of lies and didn’t actually do anything to begin with, but a few of them had useful functionality that were poorly implemented – if we ever want some of these features back, it would be relatively easy to re-implement them…correctly this time.

After about a day of work, I submitted a pull request and merged the changes. With all these cards done toward the end of the week, we merged the develop branch into our QA branch for testing.

Starting Damages Billing

The end of my week was pulling down the Damages Billing project and trying to understand how it works. The code base is terrible. No obvious project organization, files that are several 1000 lines long…I shudder thinking about having to look through the code more. My dive into the codebase wasn’t very helpful – most of my time was spent working with my boss going over our plan of action for the next week. We’re going to need to update our tablet, send data to the housing application (the application I normally work on), and then from there process it and send that to the damages service.

It’s going to be a lot of work, but I’m looking forward to the challenge and really get my hands dirty with it next week.