I’m really sick of talking about Bulk Register at this point…I’m glad that the start of this week really finished the heavy lifting on this module. It was a lot of work, but I like frequently working on new tasks because it keeps things interesting, provides new problems to solve. The start of this week was code review on those Bulk Register enhancements I did last week – there were some minor changes to make with regards to the error/success messages (I had two models that were identical, so we just got rid of one them and renamed the other it to be more general).
As I mentioned last week, the Reporting Filters task got pushed back again. This week it was put indefinitely on the back burner so we can get through cards leading up to the next big feature implementation – Damages Billing (for sending invoices to students using our damaged item tracking system). That’s something I’ll probably get to next week – I had to complete a card to fix a bug with our check in queue and do a couple small enhancements (one of which is a blocked task I think I mentioned in a previous post) to the Update Registration page first.
The Housing Location Service
The bug I had to fix in the Check In Queue was the same bug I’ve mentioned previously (lots of that this post it seems). It’s the issue with a student who has done a room change – the two databases we rely on become out of sync and if we rely on the wrong one, we display the wrong data for where the student is currently living. I’ve solved this bug twice now. With this in mind, I sat with my boss and we worked through the best way to just solve this problem once and for all.
Instead of just solving the issue in this one place again, we decided we’d build a service that would handle all this logic. It expands the scope of this card immensely, but in the end I think the effort will be worth it because we’ll have something solid to rely on that we know always correctly gets the place a student is living.
Integration testing is still something I’m working on getting better at. I understand at a high level what I want to do, but actually implementing the tests correctly…I’m actively trying to get better at it. That said, I did not build up my service around tests – I wrote all my new code and then built up tests for all the known cases. Writing the new service took about a day – I had the logic for what the code needed to do in other parts of the application where I had previous fixed this bug.
The only real difference with this implementation is that I built a domain level of abstraction to mitigate interaction with our database layer models. Unfortunately, up until this point the application I’m working on made no real differentiation between a database and domain layer – I hope by gradually introducing this separation we can move away from using database models for anything other than database operations.
Anyway…once I had the code for the service done, I spent a good portion of the rest of the week meticulously testing it. I had to sit with my boss for a good amount of time to work through all the test cases we had because while the code itself isn’t that complicated, the service has to be able to handle a lot of different cases, and we need to be certain it is doing its job correctly 100% of the time it is being used. We wrote the tests to be as straightforward as possible, but they were testing things that are actually really complicated, so I’m glad I was able to pair during the process of writing them – we were able to bounce ideas off of one another and probably ended up writing better code than if we had done it alone.
By Friday I was done writing all the tests and was very confident that everything worked correctly. With this confidence, I was able to finally implement the new service to fix the bug in the check in queue that initially spawned this card, but also in all the places where I had previously fixed the same bug. All that was left was to actually go through the site and check all the places the new service was being used to verify it was all working as intended (which it all should be thanks to all the tests I wrote).
New Graduate Student Joins the Office
I’m actually pretty excited about the new addition to our office. She seems smart and eager to learn. I spent the last couple hours of my day on Friday pairing with her on a programming exercise we gave her to gauge her coding ability (the same one we’ve been giving to our student developer applicants). It was pretty enjoyable and I look forward to working with her in the future when our schedules overlap.
The Blog of Mike Zrimsek 