Linters are used to highlight syntax and style errors in your source code. It is very useful to have when writing python, js, css, YAML, etc.
To enable linting in Sublime text 3, a few things need to be installed to get it working.
1) Install Sublime Linter first. This is a framework rather than an actual linter that can inspect your code. When we install other linters, they will depend on this framework. Thus, it is important to install this 'mother base' first.
2) Install pep8 and pyflake. These python libraries will be used by the linters installed in the next step. Open up a console window, and install them by:
NOTE: make sure you are not installing these packages while using virtualenv. This is the mistake that I made. These pacakges need to be available system wide.
- open up package control, cmd+shift+p on Mac OS X, ctrl+shift+p on Linux/Windows
- type 'install' and select 'Package Control: Install Packages'
- type 'pep8' and find 'SublimeLinter-pep8'
- type 'pyflakes' and find 'SublimeLinter-pyflakes'
4) After everything has been installed, restart sublime text 3
5) Now you should see error highlights in the gutter and around the code. To set when linting should be active, right click anywhere in Sublime Text 3 and select 'SublimeLinter' > 'Lint Mode'
6) It is very likely that pep8 will point out a few styling errors. It is anonying to fix them by hand. We can use another plugin to autoformat python code for us. Install Python PEP8 Autoformat via package control.
After this is installed, press 'ctrl + shift + r' to perform auto format.
7) pep8 linter is likely to complain about using 4 spaces instead of tabs when writing Python code. You can change this in Sublime's setting File. Go to 'Sublime Text > Preferences > Settings - User', add the following lines:
Now, when the tab key is pressed, 4 spaces are inserted instead.
“If you don’t design your own life plan, chances are you’ll fall into someone else’s plan. And guess what they have planned for you? Not much.” — Jim Rohn
When trying to access either the MEDIA_URL or STATIC_URL in the template, it is important to add the following to the template context processor in settings.py:
Setting the MEDIA_URL or the STATIC_URL in settings.py is not enough.
Sometimes, we need to dump a database from production server and import it into development machine for testing purpose, to do that:
- use the following command to dump the database first:
For instance, if I have a database called note, I would dump it as (this is done in shell not in psql):
Before importing note.db.bak into your local postgres, a few things need to be taken care of first:
1) You have to have the same list of users on your local machine as on your server. Use \du inside psql to list users on your server. Then, recreate them on your local machine in psql
Users created on your local machine do not have to mirror the same privileges they have on the server.
2) Create the database that you want to import the backup into. In psql,
Now, you can import the data with the following command in shell:
Note that the option after psql is 'dash one' not 'dash L'. This option means while importing, everything will be wrapped in a transaction so that if the import fails, nothing will be stored in note_server_bak, in other words, note_server_bak stays clean.
If you don't use -1 and an error occurs during importing, all of the data before the error will be imported into the database, which leaves your database with incomplete data. When you import the next time, you are going to see even more errors because of this.
I was running a Django server on Ubuntu 12.04 and saw a lot of errors logged in gunicorn's error log file:
One line of the error messages caught my eye, send_mail. Gunicorn is trying to send my the error message via the send_mail() function but failed. I realized that I didn't setup the email settings in settings.py.
I searched online for a solution and found two:
- send email via Gmail's smtp
- setup your mail server
Option 1 seems like a quick and dirty way to get things done, but it has a few drawbacks:
- Sending email via Gmail's smtp means the FROM field will be your Gmail address rather than your company or whatever email address you want it to be.
- To access Gmail, you need to provide your username and password. This means you have to store your gmail password either in the settings.py file or to be more discreet in an environment variable.
- You have to allow less secured app to access your gmail. This is a setting in your gmail's account.
I decided to setup my own mail server because I don't want to use my personal email for contacting clients. To do that, I googled and found that there are two mail servers that I can use:
Since postfix is newer and easier to config, I decided to use it.
- Install postfix and Find main.cf
Note: main.cf is the config for postfix mail server
Great, it is already installed. Then, I went to /etc/postfix/ to find main.cf and it is not there! Weird, so I tried to reinstall postfix:
After installation, I saw a message:
I see. So, I followed the instruction and copied the main.cf file to /etc/postfix/:
Add the following lines to main.cf:
Then, reload this config file:
Now, let's test to see if we can send an email to our mailbox via telnet:
Once connected, enter the following line by line:
If everything works out, you sould see a comfirmation message resemables this:
It is guaranteed that this email will end up in the spam box if you use Gmail. So take a look at your spam inbox to see if you received the test mail (it may take a minute to show up).
If you recevied the test email, then it means postfix is working properly. Now, let's config Django to send email via postfix.
First, I added the following line to my settings.py file:
Then, I opened up Django shell to test it:
Again, check your spam inbox. If you received this mail, then it means Django can send email via postfix, DONE!
There are times when you are not worried about user authentication but still want to have each user sees only his/her stuff. Then you need a way to login a user without password, here is the solution posted on stackoverflow
Normally, when logging a user with password, authenticate() has to be called before login():
What authenticate does is to add an attribute called backend with the value of the authentication backend, take a look at the line of the source code. The solution is to add this attribute yourself:
When a user request a page view from a website (powered by Django), a cookie is returned along with the requested page. Inside this cookie, a key/value pair is presented:
This id is used to uniquely identify who's who by the server. User A's id is different from User B's etc. This id is not only stored in the cookie on the user's computer, it is also stored in the database on the server (assuming you are using the default session engine). By default, after running
./manage.py migrate, a table named django_session is created in the database. It has three columns:
The value stored in the session_key column matches the value stored in the cookie received by the user.
Let's say this user decides to login to the web service. Upon successfully logged into the system, a new sessionid is assigned to him/her and a different session_data is stored in the database:
*I made up this example to use numbers and usernames instead of hash strings. For security reasons, these are all hash strings in reality.
As we can see here, a new session_key has been assigned to this user and we now know that this user is 'John'. Form now on, John's session_key will not change even if he closes the browser and visit this server again. Thus, when John comes back the next day, he does not need to login again.
Django provides a setting to let developers to specify this behaviour, in settings.py, a variable named SESSION_SAVE_EVERY_REQUEST can be set:
If this is set to True, then John is forced to login everytime he visits this website.
Since saving and retrieving session data from the database can be slow, we can store session data in memory by:
The advantage of this approach is that session store/retrival will be faster. But the downside is if the server crashes, all session data is lost.
A mix of cache & database storage is:
According to django's documentation:
every write to the cache will also be written to the database. Session reads only use the database if the data is not already in the cache.
This approach is slower than a pure cache solution but faster than a purse db solution.
Django's offical document did warn to not use local-memory cache as it doesn't retain data long enough to be a good choice.
By default the session data for a logged in user lasts two weeks in Django, users have to log back in after the session expires. This time period can be adjusted by setting the SESSION_COOKIE_AGE variable.
I had to deploy a django project on CentOS 6.5 and here are the steps to set up Python and then Django. The problem with CentOS 6.5 is that it comes with python 2.6.6 and it's package installer yum relies on it.
Although we can install python 2.7.x and soft link 2.7.x as the system default, it will break yum and who knows what else relies on 2.6.6. Thus, I am installing python 2.7.x via pyenv, which is suggested by this blog post.
This solution is cleaner as it does not temper with the OS default python 2.6.6.
- Update all of yum's package
- Install pyenv, which works like rbenv:
Put the following lines into your .bashrc file:
Then, reload bashrc:
This will enable the pyenv command in bash.
- Install these packages before installing python:
- Use this command to list all of the 2.7.x version of python (grep 3.x for python 3):
- Install the python version you prefer:
- Use the newly installed version of python:
You can list all python versions abailable to pyenv by:
- Update pip to its latest version:
Now, we have everything setup and ready to go. The natural thing to do next is to install virtualenv and virtualenvwrapper:
Installing virtualenv and virtualenvwrapper
WARNING: DO NOT install virtualenv and virtualenvwrapper !!!
Let me tell you what happend after I installed both via pip. I put the following lines in .bashrc
Then, I was disconnected from the cloud server with the following warning:
It doesn't matter what I try, I cannot connect to the cloud server anymore because every time I login successfully, I get disconnected from the server with the same error above. I cannot even login using the VNC connection provided by the cloud service provider. The only option I had was to reinstall the image on the cloud server...
I cannot find the cause of this issue on Google, but from the look of it, I messed out the path to bash so everytime I logged in, cannot find bash -> disconnect
Don't worry you can still use virtualenv
If you look under the .pyenv/plugins directory, you can see a directory named pyenv-virtualenv. This is what we can use to create virtual environments.
To create a test environment:
Since we have already set our local version of python to be 2.7.10, this test env inherits from that. But if you did not set the local version, the test env will inherit from the system version of python which may not be what you want. (Note: while running the command above, the 'virtualenv' package is installed to your local version of python)
You can also specify which version of python to use (by putting a version number after 'pyenv virutalenv'):
Once the test environment has been setup, you can verify it by:
You should see something similar to this:
You can switch to the test env by:
To list virtualenvs:
To delete existing virtualenvs:
If you have seen pyenv-virtualenv's github page, you have probably noticed something named pyenv-virtualenvwrapper. Don't install it unless you know what it is. I don't have the time to figure out what it is ATM. But it is definitely NOT the virtualenv + virtualenvwrapper combination you are familiar with. So be cautious!
安装成功后, 编辑你的.bash_profile文件, 将一下两行命令添加在文件的最后:
I had the following code:
When the code above runs, an error is thrown:
There are two solutions to this problem, solution one:
According to Django's document, reverse_lazy should be used instead of reverse when your project's URLConf is not loaded. The documentation specifically points out that reverse_lazy should be used in the following situation:
providing a reversed URL as the url attribute of a generic class-based view. (this is the situation I encountered)
providing a reversed URL to a decorator (such as the login_url argument for the django.contrib.auth.decorators.permission_required() decorator).
providing a reversed URL as a default value for a parameter in a function’s signature.
It is unclear when URLConf is loaded. At least I cannot find the documentation on this topic. So if the above error occurs again, try reverse_lazy