I know roughly 0 people have read any of these posts, but for anyone who cares in the future this will almost definitely be my last post here for a while…at least in regards to what I’m doing at work. I’ll likely continue to make tech and programming related posts, but they will probably live on my Medium page rather than here.
Finishing the Damages Billing Endpoint
Last week I finished writing all the code and was in the process of testing everything to make sure my new helper functions worked correctly. In one case the ORM we use in Damages Billing doesn’t accept “true” or “false” for bool parameters and instead has to take in 0 or 1…pretty genius if I do say so myself. Why would I ever want to select from the database based on a boolean column with actual boolean values?!
In another instance I realized my test cleanup helper wasn’t actually deleting test objects from the database because it was trying to select items to delete on the incorrect column, and this ORM doesn’t do any kind of verification to make sure the value I’m trying to select on is the same type as the value I’m passing into to select with. Like I said before SubSonic is the freaking best and I’m so glad I’ve gotten to learn how it works!
After fixing these small issues I put in a pull request to do some code review. Upon beginning code review I realized that I had forgotten to fix the hardcoded values that are littered throughout some of the code used in the new endpoint code. Originally I had been using these hardcoded values because I needed to simulate what data for new damages actually looked like and these were simply the values I found when I first started working on this part of the application. With that said, the rest of the application utilizes the configuration files to determine these values so I followed suit in the new stuff I wrote, even if I think this practice is pretty questionable – we should be pulling these values from the database in my opinion.
As I was working on fixing the hardcoded stuff, it was also suggested that I do a couple end-to-end tests to simulate actually sending data all the way from the tablet to the Damages Billing database. This ended up being a great call because as I worked through these tests I realized that I had approached a couple aspects of this process in a completely wrong way. First, I was passing in the percentage share for each damaged item from the tablet – what we want to do is calculate this value based on the number of people marked to be billed for that item. Lastly, I realized I was billing all the people for all the items. That is to say I was passing in a list of people to build on the top level object – this is wrong because we need each damaged item to have its own distinct list of people to bill.
With all these changes done and my tests passing we were now very confident all the new additions were correct and the pull request was merged after some quick code review. Next week is finals week so I don’t think I’ll have much time in the office, but when I am there I’ll be working on finally connecting the housing and damages billing applications with hopes of having something to hand to our product owners some time in early January before the next semester begins.