Rivanna Trails Foundation project (SLP 2015-2016)
Team Members: Kyle Bibler, Chase Deets, Trisha Hajela, Elizabeth Kukla, Shane Matthews, Nate Rathjen, John Reagan, Michael Snider
You will need to create a database on your local machine. The easiest way is to have it be the same username and password as is on the server, so that you can use the same database configuration files.
- Start mysql as root:
mysql -u root -p
, and enter the root password (likely 'password') - Create the database:
create database slp_rtf
; - Grant permission for your user to use it:
grant all on slp_rtf.* to 'rtf' identified by 'password'
; Note the .* after the database name (the first 'mst3k') Use the same username and password as was provided on the server - Call that line again, but put a @'localhost' after the userid:
grant all on slp_rtf.* to 'rtf'@'localhost' identified by 'password'
; - Exit mysql
Settings.py is not tracked by the repo because the server and local dev both have different files and this causes auto_deploy to have merge conflicts and therefore not work. When you set up the repo locally you will need to add the following in a new settings.py file in the rts/rtf
directory.
"""
Django settings for rtf project.
For more information on this file, see
https://docs.djangoproject.com/en/1.7/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/1.7/ref/settings/
"""
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.7/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'cp1z9%e@3n-f6h7xkq5r2lt@r%odi32%58**dw-!8hz05ha5m$'
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
TEMPLATE_DEBUG = True
ALLOWED_HOSTS = []
# Application definition
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'rtfapp',
)
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
ROOT_URLCONF = 'rtf.urls'
WSGI_APPLICATION = 'rtf.wsgi.application'
# Database
# https://docs.djangoproject.com/en/1.7/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'slp_rtf',
'USER': 'rtf',
'PASSWORD': 'REPLACE WITH GROUP PASSWORD (in Postem on Collab)',
'HOST': 'localhost',
'PORT': '3306',
}
}
# Internationalization
# https://docs.djangoproject.com/en/1.7/topics/i18n/
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'America/New_York'
USE_I18N = True
USE_L10N = True
USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.7/howto/static-files/
STATIC_URL = '/static/'
For background tasks such as the operation to intersect the trail with parcels, we use Celery.
Starting up a worker instance in an active terminal (not recommended as task can take up to 10 hours)
Navigate to the ~/rtf/rtf
directory
Next, run the following command:
celery -A rtf worker -l info
The worker instance will now run in the current terminal.
- Create
/etc/init.d/celeryd
with this shell script and runsudo chmod 755 /etc/init.d/celeryd
- Create
/etc/default/celeryd
with a Django configuration.# Names of nodes to start # most people will only start one node: CELERYD_NODES="worker1" # but you can also start multiple and configure settings # for each in CELERYD_OPTS (see `celery multi --help` for examples): #CELERYD_NODES="worker1 worker2 worker3" # alternatively, you can specify the number of nodes to start: #CELERYD_NODES=10 # Absolute or relative path to the 'celery' command: CELERY_BIN="/usr/local/bin/celery" #CELERY_BIN="/virtualenvs/def/bin/celery" # App instance to use # comment out this line if you don't use an app CELERY_APP="rtf" # or fully qualified: #CELERY_APP="proj.tasks:app" # Where to chdir at start. CELERYD_CHDIR="/home/student/rtf/rtf/" # Extra command-line arguments to the worker CELERYD_OPTS="-l info" # %N will be replaced with the first part of the nodename. CELERYD_LOG_FILE="/home/student/celery/%N.log" CELERYD_PID_FILE="/home/student/celery/%N.pid" # Workers should run as an unprivileged user. # You need to create this user manually (or you can choose # a user/group combination that already exists, e.g. nobody). CELERYD_USER="student" CELERYD_GROUP="student" # If enabled pid and log directories will be created if missing, # and owned by the userid/group configured. CELERY_CREATE_DIRS=1 export DJANGO_SETTINGS_MODULE="rtf.settings"
Change the user and group to your trusted non-root user and group (such as rtf
or student
on the class VM), replace all absolute paths from /home/student
to your trusted user's home directory, set the Celery project to rtf
, and add export DJANGO_SETTINGS_MODULE="rtf.settings"
. A few other details are changed such as making log files go to the /home/student/celery
directory and finding the project in /home/student/rtf/rtf
(or where every the django manage.py is located) that are needed as well. Specifically, you should give the absolute path to the directories as crontab will run this as the root user. Next, run sudo chmod 640 /etc/default/celeryd
.
3. Create a new bash script by running sudo touch /etc/init.d/rtf_celeryd_status
4. Open the file in a text editor and add the following bash script:
```
#!/bin/bash
sh /etc/init.d/celeryd status
if [ $? = 1 ]; then
echo "Starting celery worker instance..."
sh /etc/init.d/celeryd start
else
echo "Already running a worker instance."
fi
```
sudo crontab -e
to add the following cron job to trigger the bash script every 5 minutes for picking up a worker instance if one is unavailable (logging is an optional, but useful step included in this command):*/5 * * * * /bin/bash /etc/init.d/rtf_celeryd_status > /var/log/rtf.log 2>&1
- Now you can check the status via
/var/log/rtf.log
, view crontab logs via/var/log/syslog
, or manage the worker instance using some of the commands listed below.
Check status (such as if an instance is running):
sudo /etc/init.d/celeryd status
Start an instance:
sudo /etc/init.d/celeryd start
Restart an instance:
sudo /etc/init.d/celeryd restart
Stop an instance (although with crontab, a new one will be shortly started):
sudo /etc/init.d/celeryd stop
Kill an instance:
sudo /etc/init.d/celeryd kill
Edit configurations in /etc/default/celeryd
We use QUnit, Blanket, and PhantomJS to test the javascript files in the project.
cd rtf/jsunit/
- Run the following command:
phantomjs run-qunit.js file://`pwd`/qunit.html\?coverage
- If successful,
rm ../../docs/jscoverage.pdf
and thenmv jscoverage.pdf ../../docs/jscoverage.pdf
- Open the coverage report in
docs/jscoverage.pdf
Write QUnit tests in rtf/jsunit/tests.js
Blanket references the JS files using XMLHttpRequests, which are considered cross origin requests not typically allowed for standalone files.
However, you can set a flag in chrome by starting it from a command line:
google-chrome --allow-file-access-from-files
- Open the qunit page located in
rtf/jsunit/qunit.html
We have to submit out time on the custom management thing, but if you are looking for an easy way to do the actual tracking I highly recommend Toggl. They have web, desktop, and mobile apps that all sync with your account and it makes it really easy to track time on given activities and put them in categories. It will also send you a weekly summary and make pretty graphs you can view in your web dashboard.
adding these to your .bash_profile
will allow you to name your terminal tabs and windows which is super helpful for keeping track of where things are when you are doing a bunch of stuff in your terminal at once.
function tabname {
printf "\e]1;$1\a"
}
function windowname {
printf "\e]2;$1\a"
}
To activate this once you have added it run $ source .bash_profile
to add your current branch to the terminal prompt when in a git repo (SO HELPFUL when you have different branches it's easy to forget if you are on the one you think you are on) add this to your .bash_profile
.
# Git branch in prompt.
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "
run $ source .bash_profile
to activate.
You probably already know about sublime text but if you follow the first part of this doc you can activate the subl
command in terminal which is awesome because it enables you to easily open an entire project in sublime from the terminal.
Sublime is awesome because you can add packages to it. Installing their package manager is both easy and worth it.
Once installed I would suggest installing GitGutter. It is a Sublime plugin that marks which lines are different in your current edit from the remote repo of your current branch. It's basically like a real-time git diff
and really helpful.
our slack channel is slprtf.slack.com