Sunday, June 10, 2012

Django Site in Production with Lighttpd & FastCGI

OS : Ubuntu

Python : 2.7.1

1) Install lighttpd
sudo apt-get, install lighttpd
2) Install django
I want to download it to / var / www installation,
$ Cd / var / www
$ Sudo wget
$ Sudo tar xzvf Django-1.3.1.tar.gz
$ Cd the Django-1.3.1
$ Sudo python install
3) Installed back to / www
cd / var / www
4) Then we have to check the django whether the installation is successful, we first build a new project with
the sudo startproject the portal
the cd the portal
sudo the chmod + the x the
sudo python runserver
Displays the following screen, django has a normal installation
Validating the models ...

0 errors found
Django version 1.3.1, using settings 'portal.settings'
Development server is running at with
Quit the server with CONTROL-C.
5) install flup
This is the WSGI Server, before installation, you must first determine the version of the python in the command line input
$ / Var / www / portal $ python
Python 2.7.1 + (r271: 86832, Apr 11 2011, 18:13:53)
[GCC 4.5.2] on linux2 to
Ubuntu 11.04 Built-in 2.7.1 version? or because I just have the update?? XD So we had to select the development flup-1.0.3 version
$ Cd / var / www
$ Sudo wget # md5 = 
$ Sudo wget
$ Sudo python flup-1.0.3.dev_20110405-py2.7.egg
6)by adding mysite.fcgi
This code is used to tell the server how to deal with the fastcgi program
#! / Usr / bin / python
import sys, os
# Add a custom Python path.
sys.path.insert (0, / var / www ")
# Switch to the directory of your project. (Optional.)
# Os.chdir ("/ home / user / myproject")
# Set the the DJANGO_SETTINGS_MODULE environment variable.
os.environ ['DJANGO_SETTINGS_MODULE'] = "portal.settings"
from django.core.servers.fastcgi import runfastcgi
runfastcgi (["method = threaded", "daemonize = false"])
Above the red part, be especially careful if you look at the django official website files are written is not the same as the official website of
the paper was wrong, or is the older version of the file XD. I later installed a long time, only to find that there are wrong installation should pay
special attention to Oh! Storage of the above file, enter
$ For python mysite.fcgi
There will be a long list of things. Find what you see

It worked!

This script file is correct.
7) edit the lighttpd config
Start the fastcgi mode
$ Sudo lighttpd-enable-mod Fastcgi
Then here to note in the / etc / lighttpd / you will see to lighttpd.conf this profile do not move, which is the default. lighttpd read this default will
go to read the folder conf-enabled profile without charge. The start fastcgi mode, so read the default
lighttpd would automatically go read the conf-enabled inside the profile. Set fastcgi
$ Vim / etc/lighttpd/conf-enabled/10-fastcgi.conf server.modules + = ("mod_fastcgi",

server.modules + = ("mod_rewrite",
Mod_fastcgi under "
$ SERVER ["socket"] == "" {
server.document-root = "/ var / www / portal"
the fastcgi.server = (
Fcgi "=> (
"Localhost" => (
The bin-path = "/ var / www / portal / mysite.fcgi
"Socket" => "/ var / www / portal / mysite.sock",
"Check-local" => "the disable"

alias.url = (
"/ Media" => "/ usr/local/lib/python2.7/dist-packages/django/contrib/admin/media /",

url.rewrite-once = (
"^ (/ Media. *) $" => "$ 1"
^ / The favicon.ico $ "=>" / media / the favicon.ico
"^ (/ *) $" => "/ Mysite.fcgi $ 1"
8)Establish runfastcgi the script
This script is mainly through the the command the specified runfcgi parameter operation, this script will be related to things in
order to facilitate the start Fastcgi the server into a script.
    #! / Bin / bash
    # Replace these three settings.
    PROJDIR = "/ var / www / portal"
    SOCKET = "$ PROJDIR / mysite.sock"

    cd $ PROJDIR
    if [-f $ PIDFILE]; then
    kill `cat - $ PIDFILE`
    rm-f - $ PIDFILE

    the exec / usr / bin / env - \
    PYTHONPATH is = ".. / Python: .." \
    . / runfcgi socket = $ SOCKET pidfile = $ PIDFILE 
9)To remember to to modify runfastcgi execute permissions.
$ Sudo chmod + x runfastcgi
10)Restart lighttpd
$ / Etc / init.d / the lighttpd
11 ) implementation of runfastcgi
$. / Runfastcgi
12 )enter the URL in the browser http:// [yourIP]: 8000
You will able to see start page of your django site.
13 )File permissions
drwxr--xr-x 2 www-data root 4096 2011-09-22 19:42 the portal

portal folder inside the file are as follows:
- Rw-r - r - 1 www-data root 0 2011-09-22 19:16 __
-Rw-r - r - 1 www-data root 124 2011-09-22 19:17 __ init__.pyc
-Rwxrwxrwx 1 www-data root 503 2011-09-22 19:16 the
-Rwxrwxrwx 1 www-data root 401 2011-09-22 7:22 p.m. mysite.fcgi
-Rwxrwxrwx 1 www-data root 334 2011-09-22 19:31 runfastcgi
-Rw-r - r - 1 www-data root 5031 2011-09-22 19:16 your
-Rw-r - r - 1 www-data root 2652 2011-09-22 19:17 settings.pyc
-Rw-r - r - 1 www-data root 565 2011-09-22 19:16 The
-Rw-r - r - 1 www-data www-data 261 2011-09-22 19:42 urls.pyc
13 )use the django when the Admin can not find staic resource (CSS, image, js )?
Modify the lighttpd config. alias.url = ("/ static / admin /" => "/ usr/local/lib/python2.7/dist-packages/django/contrib/admin/media /")


Sunday, June 3, 2012

Django 1.3 Language Translation

Translating Templates with Django

Below is steps for translating one Django websites into Norwegian.


As I'm only providing translation for Norwegian, I set the following in my file:

  ('nb', 'Norwegian Bokmal'),
  ('nn', 'Norwegian Nynorsk'),
  ('en-gb', 'English'),
This defaults to English, but limits the list of languages on offer. I also added LocaleMiddleware to my MIDDLEWARE_CLASSES:

Mark Up Template

Open up the template to translate, and add the trans tag around the text you want translating. So,
<h2>Part 9 - Three Toms and Rolls</h2>
<p>This section contains the first exercises containing snare drum rolls.</p>
<h2>Part 10 - Ride Cymbal and Cut Common</h2>
<p>This part introduces the ride cymbal to the drum kit</p>
<h2>{% trans "Part" %} 9 - {% trans "Three Toms and Rolls" %}</h2>
<p>{% trans "This section contains the first exercises containing snare drum rolls." %}</p>
<h2>{% trans "Part" %} 10 - {% trans "Ride Cymbal and Cut Common" %}</h2>
<p>{% trans "This part introduces the ride cymbal to the drum kit" %}</p>
Add {% load i18n %} at the top of the template too.


Once this is done, you need to run a script which will create message files. You need to run makemessages in the same directory as your settings file, after creating a locale directory
me@coderpriyu:~/web/progperc/site$ export PYTHONPATH=~/web/site
me@coderpriyu:~/web/progperc/site$ ~/web/progperc/django/bin/ makemessages -l nb
Error: This script should be run from the Django SVN tree or your project or app tree. If you did indeed 
run it from the SVN checkout or your project or application, maybe you are just missing the conf/locale 
(in the django tree) or locale (for project and application) directory? It is not created automatically, you 
have to create it by hand if you want to enable i18n for your project or application.
This error means that we need to create a locale directory in the directory that contains
me@coderpriyu:~/web/progperc/site$ mkdir locale
me@coderpriyu:~/web/progperc/site$ ~/web/progperc/django/bin/ makemessages -l nb
processing language nb
Error: errors happened while running xgettext on
/bin/sh: xgettext: not found
This error occurs because we don't have the xgettext command installed. I'm on Ubuntu 11.04, so sudo apt-get install gettext should do the trick.

me@coderpriyu:~/web/progperc/site$ ~/web/progperc/django/bin/ makemessages -l nb
processing language nb
I now have a file, in ~/web/site/locale/nb/LC_MESSAGES called django.po, with contents similar to the following:
# This file is distributed under the same license as the PACKAGE package.
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2011-06-17 11:10+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: volume/templates/volume/Volume2.html:8
#: volume/templates/volume/Volume2.html:18
msgid "Part"
msgstr ""

#: volume/templates/volume/Volume2.html:8
msgid "Three Toms and Rolls"
msgstr ""

#: volume/templates/volume/Volume2.html:9
msgid ""
"This section contains the first exercises containing snare drum rolls.  "
msgstr ""

#: volume/templates/volume/Volume2.html:18
msgid "Ride Cymbal and Cut Common"
msgstr ""

#: volume/templates/volume/Volume2.html:19
msgid ""
"This part introduces the ride cymbal to the drum kit."
msgstr ""

Add translation

Add your translation into the msgstr section (Warning! Google translate Norwegian ahead!)
#: volume/templates/volume/Volume2.html:8
msgid "Three Toms and Rolls"
msgstr "Tre Toms og Rolls"

#: volume/templates/volume/Volume2.html:9
msgid ""
"This section contains the first exercises containing snare drum rolls.  "
msgstr "Denne delen inneholder de første øvelsene inneholder skarptromme ruller."

#: volume/templates/volume/Volume2.html:18
msgid "Ride Cymbal and Cut Common"
msgstr "Ride Cymbal og Cut Common"

#: volume/templates/volume/Volume2.html:19
msgid ""
"This part introduces the ride cymbal to the drum kit."
msgstr "Denne delen introduserer ride cymbal til trommesett."

Compile Language File

Once we've put our translations in, we need to compile the .po file into a .mo file.
me@coderpriyu:~/web/progperc/site$ ~/web/progperc/django/bin/ compilemessages
processing file django.po in /home/coderpriyu/web/site/locale/nb/LC_MESSAGES
You should now be able to run up your app, change your locale in the browser, and see the translated text.

Tuesday, April 17, 2012

Django Initial data dumping and loading

" dumpdata" for dumping data to json file.

$./ dumpdata app.myModel1 app.myModel2 <relative_path_to_app>/fixtures/initial_data.json
   --indent 4

" loaddata" for loading data from json file.

$ ./  loaddata <relative_path_to_app>/fixtures/initial_data.json

Wednesday, April 4, 2012


In the world of programming and engineering, it is necessary to keep track of changes during the application development process. This allows developers and programmers revert unwanted changes in applications under the development process. 

Version Control Systems (VCS) are stand-alone web 2.0 applications that have made the job easier by providing systemized management of multiple revisions of the same unit of information, whether it is a simple document or a digital document, such as source codes of applications or blueprints of electronic models. VCS allows developers to work collaboratively on the same application from different locations using repositories.

The two most famous types of version control systems are:
1-     Centralized version control system - subversion (SVN)
2-     Distributed or decentralized version control system - Git

In the case of centralized version control systems, there is a single central repository and all of the changes that are made to the documents are saved in that repository. There is a client server approach in the case of CVCS, where a single repository is stored on the server that clients can also sync up to.

In case of distributed or decentralized VCS, there is a peer-to-peer approach that clients can synchronize with by exchanging patches from peer to peer. Clients can make changes in the repositories and those changes will be local to them unless they synchronize with someone else. Depending on the requirements, Git also offers a centralized repository. In other terms, each peer has a bona-fide repository which is the working copy of codebase. DVCS provides independent as well as canonical repository.

SVN vs. Git
Both VCS and DVCS are highly appreciated by their users, but I have found that DVCS has some advantages over VCS. Let’s look at the concept of VCS and DVCS in detail by comparing the available systems of both types – SVN and Git.

  • With Git, clients can commit changes to their localized repositories as new revisions while being offline. However, SVN does not provide this facility as user must be online in order to push to the repository from the working copy.
  • SVN help is more organized and to the point while Git provides more than what is actually required. There is some time wasted since it is difficult to get a quick reference from Git’s search.
  • Git’s complete copy of the data is stored locally in the client’s system so it is extremely fast when compared to SVN. With Git there is no time wasted when waiting for network response time, but with SVN it takes longer because all of the data is stored in a centralized repository.
  • There is a smaller chance of data being lost in Git because data copies are stored locally in clients systems. The number of backups available is the same as the number of users on any repository. With SVN, if there is a data loss in the central repository, it will be gone forever.
  • The Git repository has an efficient memory because the data’s file format is compressed, which is not the case with SVN. Also, there are always two copies of a file in the working directory of SVN. One copy is used for storing the actual work while the other copy contains the information used to aid operations (status and commit). Git has a small index file to store the info related to a particular file. When there are a lot of documents, there is a huge impact on disk space in the SVN compared with Git.
  • Git DVCS is based on the concept of branching. The working directory of a developer is itself a branch. In Git, we can easily view the working directories of developers while they are modifying two or more unrelated files at the same time as different branches stemming from the same common base revision of the project. With SVN, there is almost no concept of branching
  • In Git a large number of users can commit or push data to the same repository. If someone wants to push work in a Git repository, then there is no need to worry about data lost or immediate merging of others changes because commits are not sequential in Git like SVN.
  • Git allows its users to have control over the merging of data in synchronized repositories. Merges are always pulled by someone and nobody can push to commit merges in someone else’s repository. The facility to merge data is also there in SVN, but it is somewhat incomplete. SVN merge records seem to miss some of the important details that Git keeps track of.
  • Git keeps track of contents while SVN keeps record of files. Because Git keeps track of contents, whenever there is even a small change in content it tracks it as a separate change. Because of this, the history of a single file in Git is split.
  • Git will not allow you to checkout a subdirectory. Instead, the user will have to checkout the whole repository.  In SVN, checkouts at subdirectory level are possible.

By looking at an overview of the features of Git and SVN, we can see that Git is preferable in most circumstances. Developers, researchers, engineers and other users of VCS have more inclination towards Git, so I predict that Git will be the future of revision control.

“Git's Major Features over Subversion” retrieved Dec 15, 2008 from “

Tuesday, April 3, 2012

Virtual Environment for Django and python with version specified.

Python2.6 is the default Python version on Ubuntu 10.04. Now you may still want to run your Django websites with Python2.5. A nice way to do this is by creating virtual environments to handle $PYTHONPATH and avoid conflicts among different versions. Such a tool already exists: Virtualenvwrapper.

First, to install Virtualenvwrapper, we will need easy_install:
$ sudo apt-get install python-setuptools
$ sudo easy_install virtualenv
$ sudo easy_install virtualenvwrapper
$ mkdir ~/.virtualenvs
We just need to add the following lines to .bashrc.
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/
And run it.
$ source .bashrc
We then create a virtual environment, here named django with Python2.5. Python2.6 is the default version on Ubuntu 10.04.

To create virtual environment 
    here -p specifies the package
$ mkvirtualenv -p python2.5 django
To use virtual environment named "django"
  bracket contains the current virtual environment
$ workon django
To close virtual environment named "django"
$ (django)...:$ deactivate
We are ready to go with Python 2.5. workon sets the current virtual environment and deactivate exits from it.

We can now add some additional Python paths on our virtual environment, for example:
$ workon django
$ (django)...:$ add2virtualenv /home/user/additional_python_path
$ (django)...:$ add2virtualenv
Usage: add2virtualenv dir [dir ...]
Existing paths:
$ (django)...:$
Finally here are some other useful commands:
$ mkvirtualenv django2
$ rmvirtualenv django2
$ workon django
$ (django)...:$ deactivate
$ workon
Now The most important thing is "How to use virtualenv in
production ???"

For that you will need to add it's path to your PYTHONPATH.
For example if your env had for path "/home/www/my_project/env/", the path to add would be:
You can set this up in many different ways, but if your are generating your fcgi or uwsgi interface through, simply add the following at the very top of your (before the rest):
import os
= "/home/www/my_project/env/lib/python2.7/site-packages/"
# Add it to your PYTHONPATH
You can adopt this to whatever your setup is, just in case you could also do the following in the shell :
export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/
You will also need to add the directory of where your file is located to the PYTHONPATH, so django will be able to discover it, just proceed in a similar manner to do so.