DMRI Placement - February 2018


Post Date: 03/03/2018

This month I did work on both The Competition Platform and MWoosh, alongside this work we also had couple of people join the technical team. Which involved me teaching them some stuff about our systems.

There were 2 things that I did on MWoosh this month, they were: referral summary and limiting promotions
I’ll talk about the referral summary first. So MWoosh has a referral scheme where if you get people to sign up using a specific link you sent out, you’ll get some extra MWoosh Marks (these have no use yet). What I was tasked with was creating a page where you could see details about user’s who have used referral links, has anybody signed up using those links? (If so, display info about those users) and what type of referral was it? E.g facebook, twitter, or normal link (which they would anywhere). I decided to display this info using a table. But rather than creating my own custom table for this I used the DataTables JS plugin. This meant I could basically give it some JSON data and the plugin will spit out a table with all the columns and rows. But the above description of what needed to be displayed meant I would need some sort of grouping to group user’s with a link/user they signed up with. But surprisingly, for possibly the first time ever in my coding experience, I found a bit of code, changed some stuff around to accommodate for my code, refreshed and it worked. First time. UPDATE FROM May: The way each referral link was grouped with the users who signed up didn’t look very good and wasn’t very clear, so I went back and redid using a new plugin I found called Bootstrap Table which allowed for collapsible rows/groups and overall looked a lot more clear.

The second thing I did on MWoosh was adding the ability to limit certain promotions to a select group of people. Doing this involved me having to amend pre-existing, working code. This is something that makes me a bit nervous because if you don’t fully understand the coding you're adding, you can easily introduce bugs. (Especially if it’s where there is a bug, there will be big implications). In this instance, the implications weren’t that but I did end up introducing a bug. Fortunately, though, the bug meant that no promotions would show if certain conditions were met.
Anyway, back to the feature itself. What was wanted is that we would choose a promotion, then select certain people to be allowed access to this promotion. I created a new table for which would store a promotion and user id; this information will be used to find which user have access to promotions. I also added a new column to the promotion table which will state whether it is a limited promotion (i.e only select people access). The front-end I did for it was quite neat. First, the user will choose a promotion they want to limit, then they will search for a user. This was a live search and would look for names or email that contained what the user entered. They would then click on a name and it will create a new row below with the name and email, and also an X button which can be used to remove that person from the selected people.

We also had 2 new people start on the technical team (UPDATE: One of them is no longer here now). Even though I was still a junior myself, I did have knowledge of our systems that needed be passed onto them and potentially some programming knowledge. And whenever I was called upon, I helped them to the best of my ability. And surprisingly, I found it enjoyable teaching them.