In California specifically, Labor Code Section 2870 limits an employer's claim over inventions or products created a) outside of work hours, b) without using company resources like your work laptop, and c) not related to/competitive with the company's business.
Even outside of California, it's extremely rare for companies to try to claim ownership of side projects that check all of the boxes above. Legal action is expensive and bad PR unless the employee is clearly infringing or building something competitive.
Hey, co-founder here - we think we've fixed this message delivery issue for Australia. Could you try again and let me know if you're still having issues? Sorry about that!
Regarding stock options expiring 3 months after leaving the company, it doesn't have to be this way and a lot of startups are moving in the direction of 10 year exercise periods.
For smaller projects, I'd wholly recommend Flask over Pylons or web.py: http://flask.pocoo.org/
I'd even say consider Flask for larger projects if you have patience, a good head for package/module layouts, and are after a really "no fluff" framework.
Having spoken to foreign iPhone owners on a number of occasions and asked them about this (generally European countries where English is somewhat widely spoken):
Not having a native language version wouldn't necessarily dissuade them from the purchase of the app, but it's certainly appreciated if it has been translated. If anything, it just makes them feel like the developer cares about them and their market.
They would almost certainly choose a localised version of the same or similar app if it became available, over the English version (so it might be worth doing so for competitive reasons).
Many of the people I've spoken to said that they would generally not recommend an app to their non-English speaking friends if it were not localised, even if it was reasonably simple to learn how to use.
I've only spoken to a couple people, and they were pretty tech-headed, so it might be worth speaking to others.
Yikes! if socket.gethostname() == 'your.domain.com': DEBUG = False ? This is just bad advice.
I prefer to be explicit in the settings for each environment, and create a settings package, with the following modules:
- common
- development
- staging
- production
Then in each of the non-common modules import the common variables, and set your DJANGO_SETTINGS_MODULE depending on the environment. virtualenv makes this particularly easy.
Here's a writeup by Zachary Voase, who I've had the pleasure of working with more than once: