DNAinfo Interactive Projects

This repository houses code under development for DNAinfo interactive projects created by NiJeL. These tools were developed using the Django Python Web framework.

Local Development Installation

Note: Do not use this workflow for deploying this tool to production, as this may introduce a number of security concerns. For more information on deploying Django in a production environment, please see the Django deployment checklist To install these interactives on your local machine:

• Clone this repository to your local machine.
• In the directory where you placed the cloned repo, create a virtual environment for Python and project dependencies in a directory called "env":

pip install virtualenv 
virtualenv env

• Activate your virtual environment

source env/bin/activate

• Install Django and all required packages:

pip install -r requirements.txt

• In /dnainfo/dnainfo/ make a copy of dummy_settings.py called settings.py
• In settings.py:
  • Add a SECRET_KEY of 50 randomly generated characters,
  • Replace default database settings with preferred database settings (optional)
  • Add email password to EMAIL_HOST_PASSWORD setting. Contact JD for email password if needed.
• Still in the virtual environment, navigate to /dnainfo/ (you should see manage.py in there) and mirror database schema by running:

python manage.py migrate

• For the Skyline 3D project, you will need to run a few management commands to ingest New York City and Chicago neighborhood lists and permit data (this step may take a few hours):

python manage.py import_nyc_hoods_skyline
python manage.py pull_dob_permit_issuance
python manage.py building_height_dob_permit_link
python manage.py carto_dob_permit_geom_link
python manage.py scan_code_dob_permit_link
python manage.py zoning_pdf_dob_permit_link
python manage.py import_chi_hoods_skyline
python manage.py pull_chicago_dob_permits
python manage.py carto_chicago_dob_permit_geom_link

• Fire up your local webserver:

python manage.py runserver

• In a web browser, go to localhost:8000, and you should see the development site! Please not that the terminal window you are running the development site in must stay open while you are using the site.
• When daily development is complete, terminate the local web server by typing CONTROL + C. Also deactivate the virtual environment:

deactivate

Django project in a local web server

Once installed, it's easy to fire up your local web server to view the development version of this site.

• Navigate to the directory where your virtual environment is installed.
• Activate your virtual environment

source env/bin/activate

• Navigate to /dnainfo/ (again, you should see manage.py in there)
• Fire up your local webserver:

python manage.py runserver

• In a web browser, go to localhost:8000, and you should see the development site!
• When daily development is complete, terminate the local web server by typing CONTROL + C. Also deactivate the virtual environment:

deactivate

Git workflow

Based off of the workflow proposed by Vincent Driessen, we have two main branches -- master and develop, where master is "the main branch where the source code of HEAD always reflects a production-ready state." Develop is the "the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release."

Our workflow begins with deploying supporting branches off of develop for work, which may include branches for "hotfixes" (i.e. urgent bug fixing) or new features.

###Feature Branches When new feature development begins, create a branch off of develop:

git checkout -b adding-new-feature develop

New feature branches can be named anything except for master, develop or prefixed with hotfix-. Once you are done working on your new feature, commit your code and push your branch to the repo:

git commit -m 'made some changes'
git push

Once your branch is pushed up to the repo, navigate to the pull request section on GitHub and create a pull-request from the base of develop to your feature branch. Write any comments that are relevant, tag users or reference issues.

After the pull-request is submitted and the code is reviewed and approved, the feature branch will be merged into develop, and that feature branch will be closed. The can be done on GitHub or via command line:

git pull origin develop
git checkout develop
git merge --no-ff adding-new-feature
git branch -d myfeature
git push origin develop

When develop is ready to be merged into master, it can be merged either via a pull request on GitHub or merged via command line:

git pull origin master
git checkout master
git merge --no-ff develop
git push origin master
git checkout develop

###Hotfix Branches If a critical bug in production needs to be addressed, create a branch off of master prefixed with hotfix-:

git pull origin master
git checkout -b hotfix-some-kind-of-bug master

When the bug is squashed, the hotfix branch needs to be merged into master and develop. first master:

git pull origin master
git checkout master
git merge --no-ff hotfix-some-kind-of-bug
git push origin master

and then develop:

git pull origin develop
git checkout develop
git merge --no-ff hotfix-some-kind-of-bug
git push origin develop

After both master and develop are updated, you can close the hotfix branch:

git branch -d hotfix-some-kind-of-bug