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
A new version 0.8.3 of
Rcpp
is now CRAN and in
Debian.
It comes about three weeks after the
0.8.2
release. And even though we
promised to
concentrate on documentation, it contains a raft of new features:
Thanks to the versatility of the Linux kernel, Debian has always been known for supporting a large number of architectures. It has also often been criticized for that as it is said to slow down the development of Debian.
Among these architectures, the ARM one was considered dead a few years ago, and some people wanted to get rid of it. Today all major distributions now have an ARM port, one of those distributions being even based on Debian. It seems Debian was right.
Now that Android has been ported to MIPS, we may see more and more MIPS based devices. Will the same scenario happen again?
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?
Another month, another update, but nothing spectacular to be announced
in FusionForge-world. We're still working on finishing the transition
to the new configuration system, we're testing the migration to a
simpler and more flexible set of Apache configuration files, and work
is in progress on the RPM packaging. And so on.
Possibly the most newsworthy item is the FusionForge presence at next
month's 
Father's Day in the US has always been a weird one for me. I've been
pottering through the day oblivious, when a friend who is a father will tell
me that they've been thinking of me especially today because of 
There are lots of 
After more than 9 months from the previous release, the Bash Completion Team is
proud to announce the release of bash-completion 1.2!
In this release, we dropped support for bash < 3.2. We're sorry, but we cannot
stop development just to support versions that old. By now, everyone should
have a version fulfilling our requirement.
As usual, lots of completions have been added: we're now at 168 files in our
contrib/ directory (1.1 had 145, and 1.0 had 44 -- but most completions in 1.0
were bundled in the main file). Now bash_completion only contains helper
functions, and basic filename-based completions. Everything has moved to
contrib/!
This release also saw the contribution of many external people, despite the
fact that our bugtracker on 
For the second time (First time was 
One of the things I most like about WNBR is its diversity. Not everybody goes for the same reasons. As people who read me often will know, I took part because I believe (and act accordingly!) that the bicycle is the best, most efficient vehicle in by far most of the situations we face day to day, but we need to raise awareness in everybody that the bicycle is just one more vehicle: On one side, we have the right to safely ride on the streets, like any other vehicle. On the other side, we must be responsible, safe drivers, just as we want car drivers to be.
Ok, and I will recognize it before anybody complains that I sound too idealistic: I took part of the WNBR because it is _tons_ of fun. This year, we were between 300 and 500 people (depending on whom you ask). Compared to 2008, I felt less tension, more integration, more respect within the group. Of course, it is only natural in the society I live in that most of the participants were men, but the proportion of women really tends to even out. Also, many more people joined fully or partially in the nude (as nudity is not required, it is just an invitation). There was a great display of creativity, people painted with all kinds of interesting phrases and designs, some really beautiful.
Oh, one more point, important to me: This is one of the best ways to show that we bikers are not athletes or anything like that. We were people ranging from very thin to quite fat, from very young to quite old. And that is even more striking when we show our whole equipment. If we can all bike around... So can you!
Some links, with obvious nudity warnings in case you are offended by looking at innocent butts and similar stuff:
Some people still ask me from time to time when I'll upload