1+1 Readme¶ ↑

The following contains:

• Instructions on how to run and use the app

• What design decisions were made

• How the app was tested

Instructions¶ ↑

1. Clone the repository to your system

2. Run bundle to install the app’s gems and their dependencies

3. Startup postgresql on your system, and create a local db

4. Run rake db:schema:load to load the db schema

5. Run rails console, and create yourself a user (requires a name, email, password, and password_confirmation)

6. Run rails s to start the server, and then login and begin adding teams/people

(Details about the weekly pairing emails are in the “Design Decisions” section below)

Design Decisions¶ ↑

As it turns out, the week I was given this assignment ended up being the busiest two-week span of my year so far. Therefore, I wasn’t able to give the project the sort of time and attention that I would’ve liked to give it, but I gave it my best.

The basic functionality of the app was straightforward to implement (add people, add teams, delete people, delete teams, etc.).

More thought had to be put into modeling the pairing relationship between people on teams.

I ended up using a has many through relationship between people and a partnership model. I chose that for its flexibility, and as it happens, ultimately ended up adding another column to the partnerships table…so I’m glad I went that route.

Each person has many partners through the partnerships model. The partnerships table consists mainly of two columns: one for a partner ID, and one for a person ID (each attribute belongs to a person).

That was the model that was at the core of making the weekly pairings work properly.

Weekly pairings are created in the create_weekly_pairings rake task. My thinking there was to first grab all the people in the app, and sort them by their number of potential partners. That way, folks who were less likely to find a partner went before others who were more likely to find one (because they were on multiple teams for example, or had a larger team).

I then iterated through these people, first checking for folks with whom they had never before partnered.

If they already partnered with everyone that they could possibly partner with, I then iterated through their least recent partners (an array of partner IDs, sorted from least recent partnership to most recent), and double-checked that they hadn’t partnered with that person the week prior before creating a new partnership.

I originally passed entire person objects around for these processes, but ended up refactoring most of the person model methods to return only person IDs. I did this refactoring as a result of tracking down a bug, and didn’t have enough time to think about whether it made sense to change the methods back to returning entire objects. Part of me likes the lightweight nature of returning only IDs. Another part of me likes the flexibility of having an entire object to process/manipulate.

I also used a rake task for sending out the weekly emails. I thought that Heroku’s scheduler had a weekly scheduling option to run rake tasks, but I just found out that that is not in fact the case.

So, I had to implement a quick workaround about which I’m not very happy: I set the scheduler to run the rake tasks everyday, and I check within each rake task for whether the day is Friday before allowing it to continue running to the “meat” of the task. If it is Friday, the tasks will run fully. If it’s any other day, they won’t. I would’ve pursued more elegant options if I had more time.

I used Twitter Bootstrap for styling, but again, if I had more time I would’ve liked to play around with some of my own design work.

How The App Was Tested¶ ↑

I would’ve liked to use TDD. However, as I’m still quite new to TDD, I didn’t want to waste time learning/applying it on an already compressed schedule.

So, I did a lot of manual testing. A lot of clearing the db data, reseeding it with new data, rerunning rake tasks, and so on.

If you navigate to oneplusone.herokuapp.com/partnerships on the Heroku site (while you’re signed in), you’ll see the view that I used to confirm that the weekly pairings were adhering to the rules set out in the gist.

I originally was working with a bunch more teams, and a bunch more people, but ended up just using the basic data from the gist.

I tested email functionality by manually running the rake tasks locally, and on my Heroku console. First, the create_weekly_pairings task. Then, the send_weekly_pairing_emails task.

I entered all the people listed on the gist, and gave them an email in the format of frank+{insert their name}@mydomain.org. I set up an email account ifttt@mydomain.org, and configured the app to use that account to send emails.

Since my domain uses google apps, the + syntax essentially gets ignored, but allows me to confirm that the messages did in fact get sent to the right recipients (and contained the right partners for the next week).

For example, for Vinny, I set his email as frank+vinny@mydomain.org. The email came into my regular inbox, but it had frank+vinny in it when I viewed the details of the email. The contents for that particular email were addressed to Vinny, and contained Vinny’s partner for the next week.

I ran the rake tasks a number of times to confirm that partners were allocated correctly each “week”.

Other Notes¶ ↑

My apologies for having some rather large commits in the project. I don’t usually like doing blanket “WIP” commits, and prefer committing in small bits as I go along. My git best practices took a temporary back seat while I hustled to try to get pairing functionality to work.

Thank you for the opportunity to complete this project for you, and for IFTTT! I look forward to hearing back about potential next steps.

Best,

Frank