Oddly, I have had four different people ask me about the best way to begin a
Django project or setup their system to make it easy to develop with Django.
Since I've now given my response via email so many times, I figure I might as well broadcast it and hopefully this will help others as well
My assumptions:
- Using Linux (or a Unix machine)
- Single developer with root access (quite possibly a laptop)
- Knowledge of DVCSes (e.g. git / hg / bzr )
What we will do is create a private binary directory and another
Python modules. Then take a checkout of the two most important Django projects, and make them work.
First: create your user
$ sudo adduser newbie
$ ssh localhost -l newbie
$ whoami
newbie
Then we want to create some local bin and lib directories. First the binary directory
$ mkdir ~/bin # On
Ubuntu/
Debian, this will automatically be in your PATH the next time you login
And now a local directory for our various libraries
$ mkdir -p ~/lib/python
$ echo "PYTHONPATH=~/lib/python:" >> ~/.bashrc
$ echo "export PYTHONPATH" >> ~/.bashrc
This will add that directory to our Python path. If you happen to also use another language you can put things into ~/lib/ruby, ~/lib/perl as appropriate
$ mkdir ~/Projects
$ cd ~/Projects
Here is where we will store copies of upstream software. What is the reason for using the repositories rather than packages? This allows us to checkout specific versions to match what our clients might be using. Or test things against newer versions of the upstream project.
First, let's setup Django. I tend to use
git by default, especially if the upstream is using
Subversion. If they are using
Mercurial or
Bazaar, I use those directly.
$ git svn clone -s http://code.djangoproject.com/svn/django/
Initialized empty Git repository in /home/newbie/Projects/django/.git/
Using higher level of URL: http://code.djangoproject.com/svn/django => http://code.djangoproject.com/svn
r1 = 5cda37203ffa6ea83da2958a95c377984482877f (refs/remotes/trunk)
A django-docs/images/flatfiles_admin.png
A django-docs/images/users_changelist.png
A django-docs/model-api.txt
A django-docs/build.py
A django-docs/db-api.txt
A django-docs/writing-apps-guide-outline.txt
A django-docs/templates.txt
r2 = b8249ac45e2154933b9649fd8181d5769e31c9fc (refs/remotes/trunk)
A django/utils/feedgenerator.py
A django/utils/datastructures.py
[...]
r13399 = f3902c67a3b8788de2145899e435a394c512b455 (refs/remotes/releases)
M tests/regressiontests/m2m_through_regress/tests.py
r13400 = cd72207306a5a4eecdf07f65c109f37c8317ed81 (refs/remotes/trunk)
$
Now we have Django, push it into our python path
$ cd ~/lib/python
$ ln -s ~/Projects/django/django/
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.VERSION
(1, 2, 1, 'final', 0)
Now, let's do the same for South.
South is a database migration helper for Django. These are the two things you want to have in any Django at a minimum. There are also plenty of other amazing things like
haystack,
piston,
satchmo, etc. You can follow the same recipie for them too.
$ cd ~/Projects
$ hg clone http://bitbucket.org/andrewgodwin/south/
destination directory: south
requesting all changes
adding changesets
adding manifests
adding file changes
added 802 changesets with 1340 changes to 183 files (+1 heads)
updating to branch default
143 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ~/lib/python
$ ln -s ~/Projects/south/south
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import south
>>> south.__version__
'0.7.1'
Finally, we want to be able to create Django projects. There is a great helper called django-admin that will do this. Let's put it into our path
$ cd ~/bin
$ ln -s ~/Projects/django/django/bin/django-admin.py
$ hash -r
That last statment will cause your interpreter to re-read PATH and make anything new available for execution.
Now, you should go ahead and create your projects. There are a variety of ways to do this. However what I like to do is keep Django applications separate from the Django project. That way, they can easily be re-used if required.
So, for a project called 'foo', we might have
$ mkdir -p ~/Work/foo
$ cd ~/Work/foo
$ mkdir foo.example.com
$ mkdir templates
$ mkdir media
$ mkdir <individual apps>
For each individual app, put them into the Python library. And you then have your re-usability from within Django. For a application called 'bar', you would do:
$ cd ~/Work/foo
$ django-admin.py startapp bar
$ cd ~/lib/python
$ ln -s ~/Work/foo/bar
And now, in your Django foo.example.com setting.py's file you can put 'bar' as one the installed applications and things will Just Work
Obviously there are many way to slice this particular mango, but I've found that this works pretty well for me. You can spruce it up by revision controlling each directory in your project (I do) and also take advantage of things like
virtualenv and
Fabric to make deploying just as easy as developing. But I'll leave those topics until a later date
The X Strike Force needs you! (redux)
This time, the focus is on the
Since a few months, I have been playing around with 
At 
I recently learned about the 
From time to time I see people arguing that the wide deployment of IPv6 will force DNSBLs to significantly change their operations and semantics. Usually they have little or no actual experience with IPv6 and the main argument used to justify this view appears to be more or less "OMG so many bits!1!!!".
I have no reason to believe that this will really happen. People are already sending mail over IPv6 and I expect that the same reputation mechanisms used for IPv4 will be deployed as soon as they will be needed, with small policy changes to cope with the fact that end users typically get a whole network instead of a single IP address.
So I expect that DNSBLs will continue to operate as usual like they currently do for IPv4 addresses, optionally by promoting "single IP" listings to "whole /64" listings when appropriate.
Funny how life brings those A-HA moments in the least probable of circumstances. Take my career's development, for instance. I'm currently taking a training to become a government bureaucrat. During this training, each student goes through a thorough skill assessment to help the trainer select an appropriate training place in some government office. Asides from covering the obvious aspects of formal education and employment history, we also reviewed achievements and accumulated skills. My A-HA moment came as a result of our trainer asking me to completely rewrite my CV to match some known template. Additionally, she requested that I emphasize my technology background more. I countered by pointing out that the word "technology" tends to mean "engineer" to the average employer and yet I've have always been in Product Management or Business Development, which are more Sales-oriented roles than anything else, hence why I emphasize the Sales aspect and deflate the technology aspect in my CV. Still, while she conceded that difference in emphasis, she insisted that having worked in technology probably influenced my skills or my preferred workflow in one way or another. At the moment, I simply could not think of how it might have.
Boy, was I wrong! Where do I begin?
First of all, it dawned onto me that I simply cannot claim to know Microsoft Office anymore. Until recently, my Open Office skills were easily applicable to Microsoft Office, because Open Office borrowed a lot of concepts from its Microsoft counterpart. However, following the recent redesign of Microsoft Office, I found that I cannot navigate my way around Microsoft Word's menus anymore. While this new user interface paradigm indeed removes a lot of clutter, it also hides too many features in less than obvious places, which resulted in me concluding that I simply have to downgrade my Microsoft Office skills to medium. Given the progressive conversion of several Finnish agencies and ministries to Open Office, I'm not in such an uncomfortable position but, then again, other agencies and ministries fiercely cling on to their Microsoft licenses and have recently upgraded them. As such, should my practical training take place in one of those offices, I would essentially be unable to perform at my job. Redeeming factor: a friend who only knows Microsoft products faced similar frustrations last year when she got back from her summer vacations, after she realized that their network administrator had upgraded her workstation. It took her the whole autumn before she felt comfortable using Word again.
Another aspect of working in Free Software that influences my workflow: telecommuting and teleworking. As anyone working on Free Software projects knows, teams tend to be distributed around the globe, which means that there's always someone somewhere pushing a commit or answering bug reports, at any given time of the day. Simultaneously, work quickly becomes location-independent and flexible schedules are the norm; whatever and wherever works for a given developer, as long as the work gets done. Without anyone really noticing, this work methodology has permeated the whole technology ecosystem, even at fortune-500 companies. Employees come in and out of the office at whichever time suits them, while others choose to work from home and only show up whenever face-to-face meetings are called. Others even adopt a nomad lifestyle, constantly roaming the globe for adventures and connecting to the office network via VPN, from the comfort of their hotel room or from a friend's couch, on the other side of the globe.
In my case, having twice worked for Estonian companies while living in Finland, it meant taking the ferry twice a week to visit the office. This brought in more benefits than one might initially think: first of all, the quick walk between the metro station and the harbor in Helsinki meant that I arrived on the ferry with blood pumping adrenaline and fully alert. Being on the ferry gave me 2 hours of quiet time to grab my first coffee and plan my day. Getting out of the ferry in Tallinn meant another quick walk, this time between the harbor and the tramway. By the time I arrived at the office, I had exercised twice and planned all my workday. It's probably the most productive that I've ever been in my whole career. Additionally, I was frequently on the road, meeting customers and following on sales leads, which meant that I got to close many deals using my laptop in my hotel room. As our CEO used to joke, "I have no idea where in the world Martin- ric is today but, just as long as the purchase orders keep on pouring in, it's all the same to me."
As a result of this reflexion, I had to explain to our trainer why I am extremely well-suited to government jobs that require a lot of traveling and where Free Software is used on the desktop and, vice-versa, extremely unsuited to back-office jobs where whatever Microsoft products of the day are the norm. I've had to put particular emphasis on what Open Office is all about, because many homeworks were supposed to be submitted in Microsoft Word format. While Writer indeed offers the option to import and export Microsoft formats, it doesn't come with any WYSIWYG guarantee, which is why I took on the habit of sending her PDF documents. Sadly, this did not always work out so well, especially in cases where the intention was to forward selected parts of a document to third-parties.
Conclusion: working in the Free Software industry, even in non-engineering roles, indeed has a strong influence on someone's choice of methodology, tools and workflow. In some cases, it can even disqualify someone from making certain career choices.
Who would have thought?
Inspired by various Planet Debian postings, I've spent some time
recently looking into a few RC bugs to help with the Squeeze release.
On probably a dozen occasions, I've had people in cars taunt me by
yelling some version of "Lance!", "Hey Lance!" or "Go Lance!" at me
while I am riding my bike. It seems to be particularly likely if I'm
wearing spandex.
Indeed, the "verb" to Lance has an Urban Dictionary 
Up to now I had a single blog hosted on ouaza.com, I used to blog in French and in English on many topics, even though free software and Debian was the main topic. Sometimes I avoided blogging on something because it would not really match the expectations of my readers (and of the various planets syndicating my blog). And I have always been annoyed by the fact that English readers were second-class on my blog because everything was configured in French.
So I decided to fix this once for all, I have created two new blogs in addition to 
More changes concerning those blogs are in the pipe but that will be the topic of other posts. Thanks for following !
