The tags webapp lists tags and stores more tags.
It displays an image based on info in a config file.
It knows about development, uat, and production environments.
It uses a SQLite database.
It uses a simple ORM called Peewee.
This edition has also been refactored to be somewhat Django-looking.
This app is so barebones and unfinished that it begs for changes. Using git, you will collaborate with your team to make it better.
-
You have a Python3 installed that is recent enough to have the "-m" option for configuring virtual environments.
-
You have a GitHub account.
Run these commands in a Terminal session (for best results, I recommend starting Terminal.app separately, rather than running a terminal session within your IDE). You should be able to copy/paste pretty much verbatim, except that you need to replace <yourlogin> with your own login.
$ cd # Start from your home directory
$ mkdir -p src
$ cd src # Or cd to wherever you keep code projects
$ git clone https://github.com/<yourlogin>/tags # Clone your fork
# Or use ssh protocol... $ git clone git@github.com:<yourlogin>/tags
$ cd tags
$ mkdir ../shared # In case you want to share config across releases
$ cp config.yml.sample ../shared/config.yml
$ python3 -m venv venv # Use the "venv" module to create a virtual env in the "venv" directory
$ source venv/bin/activate # Enter your python3 virtual env
$ pip install -r requirements.txt # Populate current virtual env with packages
$ python bin/load_schema.py # Init your DB structure. Assumes FLASK_ENV=development
$ python bin/seed.py # Add data to your DB. Assumes FLASK_ENV=development
$ bin/run-flask-webserver.sh # Assumes FLASK_ENV=development
Now visit Your LocalHost{:target="_blank"} in your browser.
To stop the app: At your shell prompt, hold down the Ctrl key and press 'c'.
To exit your virtualenv: In the terminal, type 'deactivate'.
Goal: Your team will exercise your new-found knowledge of git by making changes to this code base. Below are some suggested tasks, solutions, hints for viewing diffs, and a typical task workflow. As your team begins to deliver completed tasks, you will experience the typical challenges associated with working in parallel on a code base--and practice using git to solve them. To help keep things simple, feel free to use the sample solutions (see below), rather than coming up with an original implementation; the goal is not primarily to learn new code, but to gain experience using git for team collaboration.
The master
branch has a working version of the app, runnable as described above.
Objective: Keep the app working as you deliver each change to master
. Don't "break the build"!
- For each task below, a sample solution lives on a corresponding branch. Feel free to look at the solution branch (or just use it) for accomplishing the task. For instance, you can view the "Add a config parameter ..." solution by git-diff'ing its
more_config
solution branch against master:
$ git checkout more_config
$ git diff master
- Because (a) all the sample solutions branch from the same point on master, and (b) master will be moving as changes come in, you may want to create a branch to use as a label purely for diff'ing purposes:
$ git checkout master
$ git branch master-mark
$ git checkout view_template
$ git diff master-mark
- For some branch comparisons, you may desire to exclude one or more files from the
git diff
output. For instance, no need to see the entire jquery file when looking atbetter_delete_route
...)
$ git checkout better_delete_route
$ git diff master -- . ':(exclude)*jquery*.js'
- Consider using
git show
if you just want to see a single commit's worth of diffs. You can do that from any branch in any state--no need to (for instance) get your workspace to a clean state, checkout a particular branch locally and git diff.
$ git show origin/view_template
Note that git show
only shows diffs for the commit you specify--not for the whole branch.
Both Round One and Round Two solutions are branched from the initial master
branch. However, you may want to tackle the more-complex Round Two tasks after you've completed Round One.
Making changes: You can view the solutions as described above and then make the changes to your workspace "manually" by typing or copy-pasting, or you may find it simpler to merge the solution branch over to the branch you're on.
- Someone on your team - Fork this repo and grant read/write access to the rest of the team, who will each clone to their local machine. NOTE: Just to keep things simple and focused on git (as opposed to github), we will not be using any Github workflow operations apart from the one fork operation.
- Whole Team - Take a look at the Round One tasks below, and decide who will tackle each task. It will be useful to
git diff
the branches with sample solutions, as demonstrated above. - Each Member - Begin implementing your assigned task. You may want to work on a non-master branch.
- Each Member - As you finish a task, merge it to
master
andgit push
. (NOTE: Before merging to master, it's a good idea to Do agit pull
ofmaster
first, just in case changes have been delivered since you last branched frommaster
. In that case, you will need to merge before delivering!) Oh, and after delivering tomaster
, and before pushing to the shared team repo, don't forget to make sure the website still works.
view_template
- Move the HTML into a Jinja2 templatestylesheet
- Move CSS into a stylesheettag_input_first
- Move the tag input above the tag listmore_config
- Add a config parameter to set title to 'Hello Sol!'delete_route
- Add a delete route, to where clicking on a tag deletes itabout_page_with_nav
- Add an "about" page, with navigation menu
layout
- Add a Jinja layoutbetter_delete_route
- Use a DELETE method (and some Javascript/jQuery) to delete tags
git checkout master
- The branch where your team will rendezvous with changes.git pull origin master
- Catch your local master up with latest changes from your team.git checkout -b mytask
- Create and go to a new task branch from master.git merge origin/stylesheet
- Merge a solution (e.g. stylesheet) over tomytask
(resolving any conflicts).git checkout master
- Go to master in prep for bringing your stuff in.git pull origin master
(in case more changes have been pushed by teammates).- (If there are more changes, go back to mytask and merge 'em in. Then tell your team to hold off now, it's your turn!).
git merge mytask
- Assuming you're back on master at this point.git push origin master
- Share your scintillating creativity with your team.