DMRI Placement - May/June 2018

 

Post Date: 30/06/2018

First off, it’s currently June and I’m going to be merging May and June into one post as halfway through May I started exclusively on the auto invoice for the competitions. This happened because there was still much to do on it and it needed to be as perfect as possible as obviously, we don’t want things to wrong when it comes to our revenue.
My first tasks after coming back off holiday were to put the MWoosh user search and the auto invoicing live. It didn’t go very well

I had been working on MWoosh user search for about a month and I was very nervous about putting it live - especially since I’d just back off holiday. Unfortunately, my nerves proved right as I ended up bringing the site down when it live… The cause? This quote `. In JavaScript, you use that quote on strings to allow it to span multiple lines, it was used for nothing more than just a visual ease and it ended up taking the site down when webpack tried to compile it. For some reason no errors showed up on my dev machine so I had no reason to doubt it, but yeah once that was found we removed it worked.
When we got the new contract sorted (this month) I was told to put the auto invoicing live, but when I went to test it just seem to have broken. I figured out it was because of the wrapper I used had been updated and so had to change my code to reflect the update. Once this was fixed I put the auto invoice changes live, after it had been sitting there for several months. And literally, not to my surprise (I was saying to myself, I’m gonna end up breaking it), I brought the site down… I can’t remember what broke but we found the problem pretty quickly.

Before talking about the auto invoicing I just want to mention about the invoicing form where the users enter their invoice details. When I first did it struggled to get proper front-end validation on the form, so I ended up with a makeshift, very manual validation - which involved removing and adding an error class to the HTML element dependent on a set of rules. This was didn’t work very well I was getting constant complaints that users couldn’t get through the validation. One day I decided to just put everything aside and put all of my efforts into trying to get validation on there. (By proper validation I mean jQuery validate). And low and behold, I managed to get it working! It felt so good to finally this bit of code that’s been the bane of me to work properly!

Once it was live and after our accountant had seemed some actual invoices come through he brought up quite a lot of issues which showed there was still a lot of work to be done. We also discussed when we should send the invoice to Xero, which as of then was been sent out on competition creation. But we decided it would be better to send the invoice on approval of the competition, that way we or the PRs could make any changes before been invoices. To do I would create a page to approve the comp, preview the invoice and amend any costs (in case people wanted to remove or add features). For the invoice preview, I created a table which would look like an invoice on Xero, it would also allow adding additional line items and changes the cost of each line. And if you did change the costs, the final totals would be dynamically changed so you could see what the final invoice would like. Doing this dynamically involved a lot of jQuery (and probably some bad practices) but after a lot of work I managed to get it working and it’s something I’m quite proud of. One other thing I added to this page was a checkbox list of extra features and what they cost. This bit came about because I also created a report page where you could a month and site and it would give you break down of revenue earned for each feature. (E.g £1200 for data capture, £1500 for links etc). In order to this, I created new columns in the invoice table for each feature to show the cost. With this information, I can just add up the totals for each feature for each month. This was easy to set up on the initial creation of the invoice as I had access to each cost of the features taken, but there was no way to add a feature on the approval page. So this is where the checkbox list came in. This would be a list of each feature, and if you checked that feature it would ask you to enter how much that feature costs. (The invoice preview will also update to reflect this). So having created this approval page and doing all the hard parts, I actually had code in the approval of the competition. Simple implementation set the approval column to 1. Boom done. Put live, fix bugs that come in. One day, we get “Why isn’t this comp showing on the site, it is showing as approved…?” After some back and forth we checked the XMLs, the approval flag wasn’t 1. That’s weird, “Where did you approve it? On the comp platform”. I didn’t refresh the competition XML when I set the approve flag to 1, we had about 20 competitions that were approved using the new system and only 2 that was live, fortunately. So we had to refresh the XML of each competition and after about half an hour all was fine and I added the line to refresh the XML on approval. The reason I didn’t catch this problem was that, even though a competition is suspended, it will still show on the competition grid and you’ll not know it’s suspended until you view the comp and you’re logged in. I totally forgot about this and thought the approval is fine because my list of about 10 test comps was appearing on the site. Combine this with also forgetting to handle network comps on approval and that if the same comp is running on multiple sites, we combine the invoice for that comp into 1 invoice with multiple line items. I learned why it a good idea to design first, code second. I’ve always gone by getting stuck into coding as soon and design as you go, but I’ve now found out this isn’t the best way to go about things. Because I went with this philosophy for this big project I ended up having retroactively fixed my code to work with previous updates of the project. Designing first will also help you with coming up with all the use cases for a project. Working out all use cases will also help mitigate surprising bugs from showing up as you would have probably thought of whatever has happened to happen. I’ve also learned that a good testing framework will help with mitigating bugs even further as I feel with at least some unit testing, the code I made would have been less buggy.
Another issue that was brought about the invoices was that , One other issue that was brought was the invoice sometimes needed additional people to be added to invoice contact. I initially thought that this wasn’t possible - only because I hadn’t fully read the documentation. When I went back and fully read it though I did see that there was a way to do this and it wasn’t too complicated. This is also something I need to work is fully reading documentation/tutorials as back in school I’ve messed up exam questions over not fully reading some questions and I nearly ended up not doing something here as I didn’t think it was possible. I just need to remember to read documentation/tutorials rather than just skim over it searching for relevant information.