avaleske / SharkEyes

NVS Development Project
2 stars 3 forks source link

Seacast.org

(formerly Project Sharkeyes)

This project has been moved to the repository at github.com/seacast/SharkEyes

About

Seacast.org is a Django site created by students at Oregon State University for the College of Earth, Oceanic, and Atmospheric Sciences. It takes oceanic models and uses Matplotlib, Basemap, and Celery to plot them as Google Maps overlays, with the goal of helping Oregon's coastal fisherman find fish more easily.

We just deployed a staging server at staging.seacast.org, and we've deployed to production at seacast.org.

Mobile:

Desktop:

Setup

Installing prereqs:

All these requirements should be cross platform. If you're on Windows, I like using the Git Bash for these over Command Prompt, but that's just me. Also, throughout these steps I mention the project directory, which is the directory that you clone from GitHub that contains manage.py and the hidden .git directory.

Bringing the virtual machine online:

To configure the VM:

Ok, so you've got the vagrant vm up and running. Great! We use fabric to provision the VM and set it up with everything we need. This will take awhile to download and compile everything we need, so you can leave it for a bit, but unfortunately it'll need some babysitting at the end.

Setup passwords:

We store the passwords in a separate file that we keep out of source control. Make some up now. You'll need them later in setup, but you can always reference the file you're about to create.

Setup everything else:

Ok, awesome, vagrant works and you have passwords setup. Now to run the setup script. We use fabric to do this.

To configure PyCharm:

Test things:

For any of the urls below, you can go to the terminal window where celery is running to watch the tasks go by, even after the pageload times out. Everything is saved to the media/ directory that's at the same level as your project directory. All of the functions that these urls call can also be called from the django console. Careful to ensure you're calling them as celery tasks (Do it the ways it's done in the corresponding views.py file) rather than a normal function, or else you'll lose any concurrency benefits and won't be able to monitor progress with celery.

Notes

The celery console won't give you a prompt back, so you'll have to open a new terminal tab or place it in the background. In Linux, a task may be placed in the background by regaining the command prompt (Ctrl-Z), and typing bg %<task number>. If you watch it, it'll tell you what it's doing with the tasks.

If you change a task, you have to restart celery or it won't see it. This was really confusing for awhile when I had swapped the order of the return arguments of something, but didn't restart celery

If you're using sqlite (and if you followed the above instuctions you're not - it should be an option again soon) you can run sqlite3 db.sqlite3 to get a sql promp and see the database. .tables gets you a list of tables, .headers on turns on headers for the output when you run a query, and .mode column columnates the output so it's actually usable.

For MySQL, from in the vm it's just mysql --user=<username> -p.

Sometimes you'll try to start the runserver and the port will be in use. There's likely a runserver instance running that got lost. In the VM, do sudo ps aux | grep -i manage and kill the runserver process. Just restarting the VM can fix this too.

If you try to run a fabric command and get an ssh key error, and also recently destroyed your vm and are trying to build a new one, it's likely because fabric is expecting the old ssh key. Run ssh-keygen -R [127.0.0.1]:2222 to fix it. Type that exactly. Unlike convention the brackets don't mean to replace their contents.

Git Organization

We have structured the project Git repository so that any major feature development is done in a specific feature branch, and the feature branches are merged into the develop branch when they're complete. Then, when a set of features is ready for release and develop is in a stable state, develop is merged into master, and master is what is checked out in production. This ensures that master is always the same as what is running in production. If a hot-fix is necessary, a branch for the hot-fix is created from master, and then, when it is completed, it is merged into both master and develop.

DB Schema

For netcdf files it's pretty straightforward. Information about when they were downloaded and such is in the DataFile model.

For Overlays, there's Overlays, OverlayDefinitions, and Parameters. An OverlayDefinition knows everything about the type, the name, the function that it needs to call to run it, and whether it's one of the base overlays that are automatically run. (Any overlay someone makes custom won't be a base overlay.)

Parameters will be a way to list the custom parameters that an overlay uses when building it, like temperature range, number of gradient levels, etc. These act like a dictionary, with the OverlayDefinition as the containing object (hence the foreign key.)

An Overlay, then, is an instance of an OverlayDefinition, and knows when it was created, where it's stuff is, and what datetime it applies at.