This document has now been incorporated into the uWSGI documentation:
http://uwsgi-docs.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
Steps with explanations to set up a server using:
| [global] | |
| default-timeout = 60 | |
| respect-virtualenv = true | |
| download-cache = ~/.pip/cache | |
| log-file = ~/.pip/pip.log | |
| build = ~/.pip/build | |
| [install] | |
| use-mirrors = true |
Unfortunately, the Cisco AnyConnect client for Mac conflicts with Pow. And by "conflicts", I mean it causes a grey-screen-of-death kernel panic anytime you connect to the VPN and Pow is installed.
As an alternative, there is OpenConnect, a command-line client for Cisco's AnyConnect SSL VPN.
Here's how to get it set up on Mac OS X:
OpenConnect can be installed via homebrew:
brew update
brew install openconnect
| var myApp = angular.module('myApp').config(function($httpProvider) { | |
| $httpProvider.defaults.headers.post['X-CSRFToken'] = $('input[name=csrfmiddlewaretoken]').val(); | |
| }); |
| description "uWSGI server for electris CMS" | |
| start on runlevel [2345] # start on all runlevels. | |
| stop on runlevel [!2345] # stop when shutting down. | |
| respawn # respawn if job crashes or is stopped ungracefully. | |
| env DEPLOYMENT_TARGET=production # set any environment variables you like here. | |
| env DJANGO_SETTINGS_FILE=conf/settings.py # more environment variables if you like. | |
| env PYTHONPATH=/home/ubuntu/apps/my_app:/home/ubuntu/.virtualenv/my_app |
| <script type="text/javascript" src="/angular/angular.js"></script> | |
| <script type="text/javascript" src="/angular/angular-cookies.min.js"></script> | |
| // app.js | |
| // inject ngCookies to your app named 'myApp'. | |
| angular.module('myApp', ['ngCookies']); | |
| // controller.js | |
| function MyCtrl($scope, $http, $cookies) { |
Roll your own iPython Notebook server with Amazon Web Services (EC2) using their Free Tier.
| Running migrations for socialaccount: | |
| - Migrating forwards to 0011_auto__chg_field_socialtoken_token. | |
| > socialaccount:0001_initial | |
| Traceback (most recent call last): | |
| File "manage.py", line 10, in <module> | |
| execute_from_command_line(sys.argv) | |
| File "/Users/danielgreenfeld/.envs/cheesely_project/lib/python3.3/site-packages/django/core/management/__init__.py", line 397, in execute_from_command_line | |
| utility.execute() | |
| File "/Users/danielgreenfeld/.envs/cheesely_project/lib/python3.3/site-packages/django/core/management/__init__.py", line 390, in execute | |
| self.fetch_command(subcommand).run_from_argv(self.argv) |
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
| package main | |
| import ( | |
| "bytes" | |
| "fmt" | |
| "io" | |
| "os" | |
| "strings" | |
| ) |