• When a user account is registered, both a Pal and Member account are created for it, since the requirements suggest that Members may double as Pals and can earn extra Visit time by fulfilling appointments for other Members
• Members have an ephemeral monthly allowance of plan_minutes, which turn over at the beginning of each month
  • NOTE this was not one of the requirements in the instructions - it was an aspect of the description of Papa which I had internalized
  • Despite the complexity it adds to the code, I decided to keep it because I felt like it was exactly the sort of complication which comes up in feature work... and because it was a useful thought experiment :)
• "Banked" minutes are tracked via MinuteLedger
  • Both credits and debits live together in the table as positive and negative amounts, respectively
  • Entries are linked to the underlying User account, since each User has both a Member and Pal account
  • A Member's plan_minutes are not included in the table as a credit since they do not carry over at the end of the month (see visits.model.Member.minutes_available() for the details on how banked minutes are calculated)
• When a Member requests a Visit, a debit is added to their MinuteLedger
• When a Pal accepts a Visit, a Fulfillment is created
• Cancelling a Visit will also cancel any associated Fulfillments and MinuteLedgers
• Cancelling a Fulfillment makes the Visit visible again to other Pals for scheduling
• When a Pal completes a Fulfillment, a credit is added to their MinuteLedger, less our 15% cut

• Python and Django are (in theory) fairly readable, even for non-pythonistas
• User accounts are managed with Django's built in authentication system
• Bootstrap is easy to set up and familiar enough that using it for a simple UI reduces the number of variables in building this project

• Python3 (aliased to python in example commands below)
• sqlite3 (django defaults to sqlite for simple dev setup)

$ python -m pip install Django django-crispy-forms

$ git clone https://github.com/sysread/not-papa.git
$ cd not-papa
$ python manage.py migrate

$ python manage.py runserver

$ python manage.py test visits

$ python manage.py test -v2

$ python manage.py test --parallel=4

/admin provides a fairly full-featured CRUD for a django app's database. In order to log into it, you will need a superuser account.

python manage.py createsuperuser --username=someone [email protected]

Django provides some easy mechanisms for viewing the SQL generated by the ORM for a query as well as the query's execution plan.

Wherever you see a query, e.g.:

# From visits.views.list_visits()
query = request.user.member.visit_set.order_by("-when").filter(cancelled=False)

You can print the generated SQL out to view in the server log output:

print(query.query)

As well as the execution plan:

print(query.explain())

• Monthly roll-ups of the MinuteLedger to make calculation of banked minutes simpler and more efficient
• Users' time zones should be detected and used to control the display of dates and times on relevant pages
• "Request a Visit" form should have a usable date/time picker widget
• Members' address would be needed to schedule and make an actual Visit
• Insurance Plan model that includes the number of plan minutes
• All the kinds of security required to make account registration safe
• On the Member's Visits list, convert individual forms into a FormSet so we don't lose error messages on failed cancelations
• Paginate the list of completed Visits when displaying a Member's Visits
• Segregate list of Visits by status, with incomplete Visits in ascending order, but completed Visits in descending order
• Profile page with transaction history and minutes balances
• Cron job to cancel Visits which never get accepted by a Pal and notify the Member
• Visits show names when Pal has Visited the Member in the past
• Validation to ensure the same account does not fulfill its own Visits
• Browser tests (e.g., selenium)