Context

We have some artifacts left over in the .git folder that we can clean up to reduce the size of the project from ~70mb to 384K. There was some discussion on Slack about this recently.

Acceptance Criteria

• Tackle after #44
• h/t @sunu for these findings:

$ du -sh .git                             
71M	.git
$ git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch cbv3' --prune-empty -- --all
...
$ git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
$ git reflog expire --expire=now --all
$ git gc --prune=now
$ du -sh .git                                                                         
384K	.git

• Reduced the size of .git folder from 71M to 384K

https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository

Summary

I want to run pip install -r requirements/local.txt while inside the backend_app docker container so that I can install the taggit_serializer module, but I can't get inside it because my containers are continuously restarting.

Recreation of steps

$ docker-compose down
$ docker-compose rm
$ docker-compose up (with no -d)

Result:

From those error messages, I saw that a module taggit_serializer was not installed.

In a non-docker environment, normally I would pip install -r requirements/local.txt (or `pip install -r requirements.txt assuming that defaults to running the local.txt file which is specific to cookiecutter) while I am inside a virtualenv.

But because I am running docker, I'll have to run that command inside a container.

From https://stackoverflow.com/questions/56904783/how-to-install-a-python-library-to-a-pulled-docker-image, I found that I could run:

$ docker ps #check for the container ID
$ docker exec -it container_id bash

So I tried this:

But I keep getting the message that the container is restarting on the backend_manage and backend_app containers.

Am looking at https://stackoverflow.com/questions/37471929/docker-container-keeps-on-restarting-again-on-again next for hints on what I can do to solve the "container is always restarting" problem 😅

Context

h/t @billglover who pointed out cbv3_django_prototype could probably be renamed to app, now that we've decided on this course.

Acceptance Criteria

We'll need to make sure to rename in the following places

• folder/file structure
• inside the Dockerfile
• other places (??)

Several files were added to the project, probably by Cookiecutter Django, in a sub-directory, such as the LICENSE and .gitignore files. It is conventional to keep these files in the repository root.

It might be simpler to move all of the project files, keeping the sub-structure, to the project root.

Task

• Move all project files under the cbv3_django_prototype directory to the repository root

Related task: #26

Pulled from a PR conversation:

@BethanyG:

Agreed. The classic way to model something like this would be with a many-to-many and a Tags table. This was more a quick nod to the API specs, as well as an experiment with postgres JSONB capabilities. So a bit of a hand-wave.

But as this system grows, I do have a few concerns/caveats with a "simple" many-to-many Tags table:

Tags will most likely be a freeform field on the front end. I don't really see our users choosing from an epic list of tags...and the "common convention" is for users to enter what they see fit. This means writing a bunch of code to search for already existing tags and similar tags, and only add truly new/unique tags to the DB. Even with that, the Tags table will potentially be a mess of overlapping and duplicate data from the get-go. Just mocking up 28 resources for testing data created a "mess" -- and I am only one human.

Learning Paths, Hangouts, Notes and Discussions will also be tagged, I would imagine. So there will be potentially a lot of relations tracing back to the Tags table, each having overlapping, but not necessarily identical topics....so each would have to access the code for searching for existing tags/adding new tags. With virtually everything connecting to the Tags table (and it being updated a lot per user, hangout, note, discussion, etc.), it could become a bottleneck fairly quickly.

Postgres can index JSONB, and perform many of the same queries on JSONB that it can on regular data with small syntax changes. Both autocomplete and recommendations can be done (albeit not at top speed) with documents. But yes - if we are going the RDBMS route, then we shouldn't use JSONB too often, or in too many places.

One option is to use https://github.com/jazzband/django-taggit along with https://github.com/glemmaPaul/django-taggit-serializer, and customize the code so that each model has it's tags. See this for a rundown and some thoughts: https://medium.com/sthzg/a-short-exploration-of-django-taggit-bb869ea5051f.

And all that being said, I don't like how the Tags field adds an extra level right now, so I'm going to look at re-writing the serializer to omit that, and do some more digging on how Tags are implemented in other systems to see some more options. Do you have a go-to model/resource you can share?? That would be great.

@brylie:
We ended up using a lot of JSONB where I work, and it has been a bit of a wrestling match. The main take-away, from a senior developer colleague of mine, is to only use JSONB for specific optimizations and to default to using a relational model with Postgres.

As mentioned, we can use an auto-complete widget along with the django-taggit package to improve consistency and avoid bespoke tagging code.

To expand a little bit, JSONB is good to used when we need 'data locality', in effect avoiding a second query or JOIN to get a related entity.

In general, Tags are used to show related content, e.g. "resources tagged Python". I believe that it will be desirable to use these tags to create views showing similar items, resources, etc.

The performance penalty comes when we try to search within the JSONB column (even with an index) for a tag string in the name property, and then join related documents together.

For these reasons, JSONB does not seem like a good approach for tagging, particularly when the django taggit package makes a proper M2M tagging approach very straightforward.

Please excuse my directness, but I strongly recommend we use the django-taggit approach here or to omit the tagging feature from this pull request.

If we are going to require Black for coding standards, we need to write some documentation on how to install, configure, and use Black for our project.

Currently, this project is defining some Django apps in the cbv3_django_prototype/cbv3_django_prototype sub-directory. The project_name/project__name sub-directory is conventionally used for project-wide configuration. The Cookiecutter Django project may recommend a different file structure, but it is not apparent from a quick search of the documentation. However, running python manage.py startapp app_name in the project root creates the app in the project root, which is a fairly conventional project structure. This is a small mistake that is easy to fix.

Task

• Consider reorganizing the project, so that apps are created in the project root (rather than in the nested directory)
• Move all existing apps (namely, resources and users) to the project root

Reference

• Django docs - Projects and applications

Currently, Codebuddies README says it is necessary to install PostgreSQL in order to develop the project. This may prove as an unnecessary barrier to entry, particularly for the prototypal nature of the project in its current state. Until this project is more mature (and possibly deployed at some staging server), we should allow local development to proceed with a simple SQLite database.

Task

• Create an optional environment variable approach to allow developers to use SQLite instead of PostgreSQL

Guide: https://www.django-rest-framework.org/tutorial/quickstart/

When trying to run initial migrations, I get the following error:

ModuleNotFoundError: No module named 'vine'

This may be related to a pinned dependency version for celery < 5.0:

celery/celery#3547

I've noticed a couple of contributors using Postman to test calls to the APIs exposed as part of the CodeBuddies backend. I would like to explore the idea of a shared Postman collection.

Why? By sharing a Postman (or equivalent) collection we should hope to see a couple of potential benefits. We would gain the ability to consistently call the API making it easier to reproduce observed behaviour. We should also expect to see new contributors finding it easier to make calls to the API.

Why now? Contributors have already started building up personal Postman collections. These get harder to merge as the collections grow.

Cost of doing nothing? If we don't adopt a shared collection we would leave it up to contributors to put together a method for making API requests. These could be documented as part of API documentation, or something as simple as a list of cURL commands.

We don't yet have a production deployment of the CodeBuddies backend. We should have one.

Why?:
Deploying a publicly accessible version of the CodeBuddies backend will allow us to get feedback from the CodeBuddies community.

Why now?:
The earlier we get feedback, the easier it is to address. We have functionality that is very close to being ready for user testing. It would be good to have an environment to deploy to in time for release.

What if we don't implement?:
User testing will require users to stand up their own environments. This makes it less likely that a user will use features to accomplish real tasks.

Acceptance

• publicly accessible deployment of the CB backend
• publicly accessible deployment of the CB frontend
• tagged changes to backend/master trigger a deployment of the CB backend

Edit: Removed frontend from the acceptance criteria as that is being deployed differently.

Related to #3

The README currently says to run pip install -r requirements.txt. However, this by default will install all packages in the global Python namespace. It is more common to use a virtual environment to prevent package conflicts. Since we are not in consensus about using any higher-level Python dependency management library, let's just add instructions for using the default Python venv module.

Task

• add instructions to README describing how to use the standard Python venv module to create a project virtual environment
• make sure common virtual environment paths (such as .venv) are added to .gitignore

Resource model and serializer changes needed to support taggit.

• Remove JSONB field from Resources model
• Alter Resource model to include taggit manager as show here & here
• Customize through model to support the non-int (UUID) PK for Resources now using an int for pk in addition to the UUID4 as a guid.
• Alter Admin interface to properly display taglist as shown here
• Add https://github.com/glemmaPaul/django-taggit-serializer or something similar to installed packages for tag serialization Lib only returns a list, wrote custom serializer to return a list of slug:name pairs.
• Alter the ResourceSerializer as needed to support tags
• Alter the ResourceView as needed to support tags as nested elements.
• Change any settings needed to support tags
• Update test cases as needed
• Add new tests as needed to support tags
• Add/alter fixtures to support tags (remove extra fields and other cleanup)
• Create fixture/load db with initial set of tags to "tag" resources with as POC.
• Tag existing resources so that they can be used in dev.

Additional related SO posts and others for reference/tips:

• https://stackoverflow.com/questions/52695298/using-django-taggit-and-django-taggit-serializer-with-issue
• https://stackoverflow.com/questions/57068139/cant-get-queryset-to-return-list-of-objects-that-is-descending-by-tag-matches
• https://stackoverflow.com/questions/57120364/django-taggit-how-to-record-id-of-user-that-added-tag
• https://stackoverflow.com/questions/21563726/using-django-taggit-with-django-rest-framework-im-not-able-to-save-my-tags

So right now we have the split between frontend and backend, would it make sense to explicitly delete templates and defer frontend work to codebuddies/react-concept?

Referring to #12 and #3.

On Fedora 30, I'm having issues using command from hackernoon article references in #12.

Ran docker run --rm --name pg-docker -e POSTGRES_PASSWORD=docker -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data postgres

Resulted in a hash. No container present when I used the docker ps command.

(source)
If I modify the command to: docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres, I get a working container of Postgres.

Going back to the article above, I then use the command psql -h localhost -U postgres -d postgres , I get this message:

psql -h localhost -U postgres -d postgres psql: /usr/pgsql-11/lib/libpq.so.5: no version information available (required by psql) psql: /usr/pgsql-11/lib/libpq.so.5: no version information available (required by psql) psql: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?

I suspect this is an issue with my Fedora setup, but anyone with Linux experience would be greatly appreciated for insights.

The Test Workflow currently starts two optional applications during testing. Neither Mailhog or Adminer are required. Starting them during the workflow consumes unnecessary resources and may slow down execution.

Acceptance:

• Only required services started during Test Workflow: web, app, db
• Testing continues to execute and results remain visible

It may be helpful to use Pipenv rather than just pip for dependency management. This is namely because project dependency updating is made simpler by Pipenv, along with a few other niceties like automatically initializing environment variables when activating the virtual environment.

The current resource POST (create) api will take any int value POSTed for the user field. This means, effectively, that one authorized user can "impersonate" another when it comes to creating a resource in the DB.

We don't want this to happen. Instead, the user field should be pulled from and populated by the 'username' field from the JWT token.

See this Stack Overflow Post for information on how this can be accomplished.

see DRF: Generic Views perform_create() under Save and deletion hooks for additional context.

We need to create a /resources/{resource_id} endpoint that accepts the following body:

{
"id": "7e08e0b0-da77-11e9-95c3-d20089b01401"
}

Making a DELETE request to resources/{resource_id} should result in the resource being deleted.

GitHub Actions provides the ability to automate development workflows including: linting, building, testing, releasing and deploying. Automation of these tasks helps reduce the workload for maintainers, but also helps ensure some consistency to workflows. It can also provide a degree of confidence to contributors that their changes won't have unintended consequences.

This issue is to set up GitHub Actions to execute tests for PRs raised by contributors.

Acceptance Criteria

• GitHub Action workflow is triggered when a new PR is raised
• The workflow executes manage.py test against the PR commit
• The results of tests are visible to both contributor and maintainer

Since we followed a link from the DRF docs and a related tutorial directly to PyPI (where the status is not listed), we missed that https://github.com/jpadilla/django-rest-framework-jwt is unmaintained a of 8/2019. See issue jpadilla/django-rest-framework-jwt#484. We will now need to replace it.

One recommended route is to use https://github.com/davesque/django-rest-framework-simplejwt. The two libraries look similar at first glance, so the hope is the replacement will be fairly straightforward.

Using: "drop-in fork" at https://github.com/Styria-Digital/django-rest-framework-jwt.

I'm running across an issue contributing to Bill's contributing to this project (his fork: https://github.com/billglover/django-concept). This to help complete issue #44 .

I've attempted to fork his fork, but realize that GitHub considers it part of the same repository (I think), and so even after renaming my current fork of the official CB repo, GitHub still won't let me fork Bill's fork of this repo (sorry for all the spamming of fork and repo!).

This made me realize that using a feature branch for things like our development setup and then sub-branches for docker-compose setups would make group contributions easier.

As a user, I'll be like:
1/ "I want to learn Python!"
2/ Search for all resources tagged python
3/ Filter resources by paid/level
4/ Bookmark the ones that look interesting
5/ Click into a group and find ideas of hangout pairing proposals. Also be able to start a discussion thread for the group.
6/ See list of other users who joined that group, and their timezones
7/ See all the resources listed under that group (we need to figure out: who has permissions to move resources under a group??)
8/ Leave notes (either private or public) about a particular resource, and see other public notes about it.
9/ Start a discussion thread around a resource.
9/ Look at a calendar of upcoming public hangouts in the group
10/ Resource page will also show upcoming hangouts within groups the resource belongs to
11/ Have a study paths profile-y page where I can see my study path and also edit my profile info containing things like my CB Connect info, timezone, and availability this week

Set up JWT authorization on the DRF backend & test to make sure it's implemented correctly. This includes:

• Installing the necessary components & updating the requirements.txt file.
• Changing base.py settings to add DRF permission classes, CORS origin whitelist entries, and JWT_AUTH parameters.
• Creating a auth endpoint for requesting JWT tokens with a username and PW
• Creating new userauth app for user authorization, with current_user and UserList views.
• Adding new routes to support signup, auth, and authorized users
• Adding new serializers for decoding JWTs and for requesting a JWT on registration
• Adding new JWT response handler in utils.py
• Adding an appropriate auth views for returning user info based on their JWT, and for returning a JWT from a new user registration.
• Adding appropriate tests to verify the new feature additions

Context

A couple of people (@bengineerdavis, @d3vild06) have brought up/asked about docker-izing the entire app with docker-compose. My take was that I didn't think it was necessary, unless the benefits (easier setup) is very clear. @billglover explored it, and recorded a screencast of it here: https://codebuddies.slack.com/archives/C04BRN86J/p1578770421053800. @kennethlove offered some suggestions to tweak the approach.

Acceptance Criteria

[ ] Explore a dockerized Django, Postgres, Mailhog, and Adminer (for viewing the DB). (Re: Mailhog -- that's fine! I expect at some point we'll be building out the transactional emails features)
[ ] Write a draft of instructions that users (like me) could test to set up the dev environment. Instructions should be friendly for those who've never used Docker before.

Context

In a hangout last week, @bengineerdavis and I discussed documenting some Linux-specific setup instructions for this project, assuming setting up postgres in a docker container is doable.

Acceptance Criteria

• Add to the README.md a section re: Linux-specific instructions for getting the Django app running and a Docker Postgres instance running.

Actions

• Confirm that repo size reduces with by adding db_data to .gitignore file. gitignore already ignores db_data

• Confirm that leaving the volume undefined in docker-compose.yaml doesn't produce any side effects and maintains the functionality of the app.

• Seek more feedback on whether to continue pursuing this issue.

Notes

• When running git rm --cached db_data I get:

fatal: pathspec 'db_data' did not match any files

After eliminating local Postgres volume, current repo size seems primarily derived from these directories within the django project directory:
./resources ./users ./templates

Overview

Over on slack, we noticed that the current repo is about 73mb, which seems considerably larger than the amount of data we've put into the app.

Steps

1. I first searched for venv in .git, which didn't return anything.

2. Then I searched recursively for the largest sized directories/files in our repo and with sudo ls -lR | sudo du -ah | sort -n -r | head -n 30

The results:

964K ./cbv3_django_prototype
736K ./.git/objects/pack/pack-af3bbc530aded22c05b12ddc6bd8e00d44bef547.idx
680K ./cbv3_django_prototype/cbv3_django_prototype
608K ./db_data/base/16384/1255
608K ./db_data/base/13117/1255
608K ./db_data/base/13116/1255
608K ./db_data/base/1/1255
584K ./db_data/global
496K ./db_data/base/16384/1249
472K ./db_data/base/16384/2608
448K ./db_data/base/13117/2608
448K ./db_data/base/13116/2608
448K ./db_data/base/1/2608
408K ./db_data/base/16384/2838
408K ./db_data/base/13117/2838
408K ./db_data/base/13116/2838
408K ./db_data/base/1/2838
400K ./db_data/base/16384/2674
392K ./db_data/base/13117/1249
392K ./db_data/base/13116/1249
392K ./db_data/base/1/1249
368K ./db_data/base/13117/2674
368K ./db_data/base/13116/2674
368K ./db_data/base/1/2674
360K ./db_data/base/16384/2673
328K ./db_data/base/16384/2609
328K ./db_data/base/13117/2673
328K ./db_data/base/13117/2609
328K ./db_data/base/13116/2673
328K ./db_data/base/13116/2609

I had to run sudo because db_data is the local volume associated with our db Postgres container, which will always made modifications to files with privileged access. I spoke with @BethanyG and @angelocordon, and we agreed that this volume should never be in the git-versioned files.

Machine

Fedora 30 (Linux)

Options

.gitignore da_data

However, this is more of a bandaid, since the volume is still in the project directory.

Let docker-compose abstract the local volume setup

This will make access to the volume files trickier, but can remove a manual config step that we might not need to worry about anyway.

Formerly named:

• credit, referrer

Add:

    # specific URL of resource
    url = models.URLField(max_length=300)

    # the URL of the referring/source site.  e.g. URL of tweet, if it was tweeted.
    referring_url = models.URLField(blank=True, max_length=300)

    # names of persons who suggest this resource to the user
    referring_user = models.CharField(max_length=100)

The current Application tests load Fixture data for JWT and Resource testing. These should now be re-written to use Factory Boy (or Model Mommy), so that they are not dependent on static or moldy data.

We have some User and Resource data files (fixtures in Django-speak) that can help with populating dev dbs with some starter sample data. We needs some instructions for new contributors on how to load these files after setting up the environment.

Create the initial Resource model and register it with the Django Admin.

Some of my notes from when I set it up locally (with @BethanyG's help):

- Set up postgres: https://wiki.postgresql.org/wiki/First_steps
- https://gist.github.com/ibraheem4/ce5ccd3e4d7a65589ce84f2a3b7c23a3
- createuser --interactive --pwprompt
- createdb cbv3

I'll need to double check exactly what I did. Luckily I still have the recording of it!

Context

base.txt seems to hold some artifacts of a pip freeze at the moment, including a pkg-resources=0.0.0 package that needs to be removed.

Acceptance criteria

[ ] Remove the pkg-resources=0.0.0 package
[ ] Clean up base.txt

We need to provide documentation for new users on how to manage things like DB connection information and passwords through ENV variables, since the next version of the prototype will have them.

Currently, api/v1/resources/ uses filters.SearchFilter as its filter_backend. This particular filter does a search on all fields for the requested parameters, which is not granular enough for our search needs.

As in this article: https://medium.com/better-programming/how-to-make-search-fields-dynamic-in-django-rest-framework-72922bfa1543? we need to make this api endpoint more dynamically searchable by implementing a custom filter_backend.

New developers will typically want some dummy content, so they can test API calls, etc. Django makes it fairly easy to define project fixtures.

Task

• Generate fixtures for existing project models

Requests that result in an HTTP 500 Internal Server Error status code return HTML even if the client is expecting to receive a JSON response. A standard JSON error response format should be adopted to be sympathetic to client error handling code.

Why?
When the server returns an error, the client (React front end, mobile app, CLI, etc.) will want to parse that error and take appropriate action. In some cases this will be displaying a message to the user, in other it may be retrying the request or logging the error. If the client is expecting to parse a JSON response and it receives HTML it will fail to parse details of the error.

Why now?
If we introduce inconsistencies in the way the server responds with errors, we make it difficult to write clients. Clients become increasingly complex to handle these inconsistencies and it gets harder to retrofit consistency.

Cost of doing nothing?
In the case of a HTTP 500 Internal Server Error clients could look at the HTTP status code in the response and decide not to parse the response body. This workaround would avoid the need for complex error handling logic, but would reduce the information that clients could determine about the cause of the error.

The proposal is that we rename this repository to backend.

Why: Now that we have decided to use Django as the back-end for future versions of CodeBuddies, it no longer makes sense to retain the django-concept name. Calling this backend will make it clearer to contributors what the role of the repository is.

Why now: We have just force pushed a solution to #53 causing disruption to anyone who had forked the repository. Renaming the repository is disruptive and doing so now will ensure we minimise disruption to anyone working with remote or forked copies of the repo.

What if we don't do anything: If we don't make this change, we will either retain the confusing repository name or we will have to perform this disruptive change in the future when it risks being disruptive to more contributors.

If we're going to require Black, we need to set up a configuration for it that contributors can install and use.

We need a resources/{resource_id} endpoint that accepts the following JSON body:

{
      "id": "7e08e0b0-da77-11e9-95c3-d20089b01401",
      "title": "The Road to Learn React",
      "description": "This Book is your personal start of learning React and its ecosystem. You will learn plain React, transition from JavaScript ES5 to ES6, and build an application along the way. Afterward you are able to build your own applications and you are prepared to dive into the React ecosystem.",
      "url": "https://leanpub.com/the-road-to-learn-react",
      "referrer": "https://roadtoreact.com/",
      "credit": "Lynnea Sauvage ([email protected])",
      "date_published": "2019-09-18T17:50:36-07:00",
      "created": "2019-09-18T17:50:36.198968-07:00",
      "modified": "2019-09-18T17:50:36-07:00",
      "media_type": "Book",
      "paid": true,
      "tags": [
        {
          "id": "a1167632-abb8-4ce1-b090-b84e79c94c7f",
          "name": "JavaScript"
        },
        {
          "id": "66cc3539-6705-45ee-b15d-644d5fb90c41",
          "name": "ES6"
        },
        {
          "id": "8b99bcd9-a9a5-4455-b2da-fed06051d502",
          "name": "React"
        }
      ]
    }

Making a PATCH to this endpoint should result in the resource that was IDed being updated.

We need a resources/create endpoint that accepts the following JSON body:

{
      "id": "7e08e0b0-da77-11e9-95c3-d20089b01401",
      "title": "The Road to Learn React",
      "description": "This Book is your personal start of learning React and its ecosystem. You will learn plain React, transition from JavaScript ES5 to ES6, and build an application along the way. Afterward you are able to build your own applications and you are prepared to dive into the React ecosystem.",
      "url": "https://leanpub.com/the-road-to-learn-react",
      "referrer": "https://roadtoreact.com/",
      "credit": "Lynnea Sauvage ([email protected])",
      "date_published": "2019-09-18T17:50:36-07:00",
      "created": "2019-09-18T17:50:36.198968-07:00",
      "modified": "2019-09-18T17:50:36-07:00",
      "media_type": "Book",
      "paid": true,
      "tags": [
        {
          "id": "a1167632-abb8-4ce1-b090-b84e79c94c7f",
          "name": "JavaScript"
        },
        {
          "id": "66cc3539-6705-45ee-b15d-644d5fb90c41",
          "name": "ES6"
        },
        {
          "id": "8b99bcd9-a9a5-4455-b2da-fed06051d502",
          "name": "React"
        }
      ]
    }

POSTing to resources/create should result in new resource being created.

Django REST Framework (DRF) will auto-generate a browsable API portal for developers to quickly try out API endpoints. This API UI helps developers to quickly experiment with the API.

Task

• Enable DRF browsable API UI

There are some everyday things to put in a .gitignore file for a Python project. So, GitHub offers a default template.

Task

• Add the default GitHub .gitignore file to this project

There is a folder in the repository root called "cbv3". It appears to be a local Python virtual environment. The virtual environment was likely checked in by accident, as it is unconventional to keep Python virtual environments under revision control.

Task

• Remove the "cbv3" Python environment from the repository

Putting this here for discussion. As currently modeled, our Resources have a JSON field with tags that have a UUID and a text string. We may decide to change this, but for now that is the model. The current UUIDs are below. Should we continue in this pattern, or should we not assign UUIDs to tags?

Context

@d3vild06 noted that the first screen users see after getting the dev environment set up (either with docker-compose up, which is being reviewed in the PR for #44 right now, or manually) is this:

We could add some tips to that home page content to help contributors to the Django API about how to get started.

Acceptance Criteria

(Coming soon as I figure this out too)
Initially:

• http://127.0.0.1:8000/api/v1/resources/ #browse the API for resources
• http://127.0.0.1:8000/admin #login using superuser credentials
• docker-compose run --rm manage createsuperuser # how to create a superuser
• docker-compose run --rm manage test # how to create a superuser
• docker-compose run --rm manage makemigrations # how to make migrations
• docker-compose run --rm manage migrate # how to migrate the migrations
• http://127.0.0.1:8000/auth/obtain_token/ #get a token
• http://127.0.0.1:8000/auth/users/ #create a user