Leto II & Siona:

Duncan Idaho, one of my favorite characters:

Also, check this site out if you were also puzzled by the end of original series; Dune: Marty and Daniel

No related posts.

How to add STATIC files

You will most likely add STATIC files to your source code repository. As they are likely to be hardcoded in your code and templates it is a good idea to keep those and your STATIC files in sync.

Your STATIC files are collected (found and copied or symlinked) with the help of finders. This collection process might be a little confusing for you. Basically you don’t need to worry about where your files are copied, you just need to maintain the files in the locations I mention below. Collection process consolidates all your STATIC files for you, and it does it automatically.

If you are developing a reusable app place your STATIC files under the static directory. Your app directory should look like this:

$ ls -1
models.py
static/
templates/
views.py

If you are developing a project absolute filesystem paths listed in your STATICFILES_DIRS setting will be collected:

>>> from django.conf import settings
>>> settings.STATICFILES_DIRS
('/opt/myproject/src/project/static',)

One important thing to note, as I mentioned in the first part, is to set your STATIC_ROOT outside of your project directory. This is the location where all the STATIC files found will be consolidated. Making this directory independent from your project installation enabled its reuse.

How to upload MEDIA files

MEDIA files are typically uploaded by users when the project is online and a reference is stored in a model field. While this is true most of the time, MEDIA files can be generated by code and/or a reference can be provided in some other way that doesn’t involve models. But these edge cases are out of the scope of this post.

The easiest way to allow users upload their files is to use a FileField or ImageField on a model and derive a form from it:

from django.db import models
from django.forms.models import modelform_factory


class MediaModel(models.Model):
    media_file = models.FileField(upload_to='user_media')


MediaForm = modelform_factory(MediaModel)

You can then use this form to provide upload functionality:

def media_create(request):
    if request.method == "POST":
        form = MediaForm(request.POST, request.FILES)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect(reverse('media-list'))
    else:
        form = MediaForm()
    return render_to_response('usermedia/create/html', {'form': form})

Of course it is better to use a generic CreateView now we have them with Django 1.3. I wanted to emphasize one point and avoid the complexities of a class based view; you must pass request.FILES to the form’s constructor. Actually this is a good practice whether or not your form has an file field.

As in the case with STATIC files, MEDIA_ROOT should be in a location seperate from your project files. If you delete your project directory you would also lose MEDIA files otherwise.

Conclusion

This concludes Working with files in Django. I hope these posts are helpful to you. Once you are comfortable working with files I strongly recommend you to take a look at Django Compressor

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

How to setup file serving for development server

As I mentioned earlier, it is best to serve files on a fast HTTP server. But this setup is overkill for development environments, you can safely let Django handle your files. The snippet below relies on the assumption, behind the scenes, that DEBUG is always True in development environment and it is always False in production environment. It should be fine for the purposes of this post:

from django.conf.urls.static import static
from django.contrib.staticfiles.urls import staticfiles_urlpatterns

urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
urlpatterns += staticfiles_urlpatterns()

It is quite straightforward. Nothing gets added to urlpatterns unless DEBUG is True and prefix (MEDIA_URL and STATIC_URL) is not a fully qualified URL.

How to reference STATIC files in templates

There are two ways to reference any file. You can use a file’s location in your file storage (your filesystem for example) for internal use. Or you can build a URL for the file so that clients can access it. This post will cover the latter, as the former is a simple matter of applying os.path.join() to STATIC_ROOT and the particular file’s path.

To build a URL in your templates you can simply concetenate STATIC_URL with the file’s relative location to it:

<img src="{{ STATIC_URL }}myapp/img/logo.png" />

However, to have STATIC_URL available within your template context you need to make sure of two things:

• The template needs to be rendered with a RequestContext.
• django.core.context_processors.static needs to be included in TEMPLATE_CONTEXT_PROCESSORS setting.

I can’t think of a reason why, but if for some reason you are not using RequestContext, you can provide STATIC_URL using getstaticprefix tag:

{% load static %}
{% get_static_prefix as STATIC_URL %}

<img src="{{ STATIC_URL }}myapp/img/logo.png" />

How to reference MEDIA files in templates

Dealing with MEDIA files is much simpler. The FieldFile object returned by ImageField and FileField has path and url properties and you don’t need to do concetenation yourself:

<img src="{{ some_model.some_image_field.url }}" />

Next part deals with adding files to your project.

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 3
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

• Files that are hard coded in templates or in code. We will call them STATIC files.
• Files that are referenced in the code but only known in the run time. We will call them MEDIA files.

Now of course all these files are static and most of them can be classified as media, but I chose those terms because that more or less how they are referred to in Django documentation.

Since files are stored on disk or some other storage backend it is best to serve them on a fast HTTP server and let Django handle only dynamic content.

How to configure STATIC/MEDIA related settings

Let’s look at some code first and we can comment on it afterwards. I use the following setup in my projects:

import os

_PATH = os.path.abspath(os.path.dirname(__file__))

MEDIA_ROOT = os.path.join(_PATH, 'files', 'media')
MEDIA_URL = '/media/'

STATIC_ROOT = os.path.join(_PATH, 'files', 'static')
STATIC_URL = '/static/'
STATICFILES_DIRS = (
    os.path.join(_PATH, 'static'),
)
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)

ADMIN_MEDIA_PREFIX = '/static/admin/'

_PATH should be obvious. But the way I use it is a little tricky here. Basically I am using a files directory that contains media, for MEDIA files, and static, for STATIC files, directories. This seperation is essential. You will pull your hair if you don’t seperate those two from the beginning. This will allow you to reuse them easily if you deploy a new version to a different location.

But why is files under the project directory? Because we need to check-in STATIC files? NO! It is just a convenience for the development environments. I strongly suggest overriding MEDIA_ROOT and STATIC_ROOT in your deployment settings and basically move the files directory outside of the project path. STATIC files that we check-in resides in <_PATH>/static. django.contrib.staticfiles app collects your STATIC files from your project specific directories and within your apps and copies everything in the right places inside STATIC_ROOT.

To sum up the points above:

• Check-in STATIC files in a folder within your project directory (see STATICFILES_DIRS & FileSystemFinder). If you are developing an app AppDirectoriesFinder will collect static files within the static directory in your app directory.
• Seperate the directories, where your MEDIA files are saved and where your STATIC files are collected (see STATIC_ROOT & MEDIA_ROOT).
• Keep your STATIC_ROOT and MEDIA_ROOT outside of your project directory in production environment.

One more thing to note is STATIC_URL and MEDIA_URL should both have a trailing slash. This will save you a lot of trouble later.

Next part deals with serving files in development environment and referencing them in code and templates.

If you enjoyed this post please tell me a little bit about yourself.

Related posts:

1. Working with files in Django – Part 2
2. Working with files in Django – Part 3
3. My PyCon APAC 2011 Presentation: Optimizing Media Performance with django_compressor

I remembered that conversation when I was watching the TED talk The 6 killer apps of prosperity by Niall Ferguson. It is not an in depth analysis of course, but underlines some of the obvious facts and also includes some surprises.

This talk also touches how Ottoman Empire lost its power by giving in to bigotry. And the funniest thing is, according to the speaker, İbrahim Müteferrika was the one who realized the advantages of western empires. The very own İbrahim Müteferrika of Ottoman Empire, who brought the printing technology.

Oh, and it ends with a surprise. If you are really observant or you have watched it till the end, you will see that the trend is reversing.

Related posts:

1. Sign of a Stupid Programmer

Unlike programmers who can’t program, stupid programmers can and do program. That is the problem.

joined = '%s%s%s%s%s%s' % (
    some_list[0],
    some_list[1],
    some_list[2],
    some_list[3],
    some_list[4],
    some_list[5],
    some_list[6])

You just wish they were unable to program. Every single time you encounter their code you question yourself. You ask if this is programming, what the f#ck is it I have been doing all this time?

def __unicode__(self):
    return '%s' % self.some_unicode_attribute

I have been reading on stupidity lately. It all started with Onur tweeting this article. Then I have found the following definition of stupidity:

A stupid person is a person who causes losses to another person or to a group of persons while himself deriving no gain and even possibly incurring losses.

They’re both good reads. I just wish I was introduced to these concepts earlier. I felt stupid for my ignorance on stupidity.

def some_func(**kwargs):
    param1 = kwargs.get('param1', 'param1_default')
    param2 = kwargs.get('param2', 'param2_default')
    param3 = kwargs.get('param3', 'param3_default')
    param4 = kwargs.get('param4', 'param4_default')
    param5 = kwargs.get('param5', 'param5_default')
    param6 = kwargs.get('param6', 'param6_default')

Watch out for the stupid programmer. He is destructive.

Related posts:

1. Was it the imperialism that made the west rich?

I have learned to recognize this behaviour and walk away. There are better ways to waste your time than trying to convince someone who doesn’t want to help himself, to do something fruitful. This education cost me a lot of time. But I think I have finally learned.

While I was reading Ray Dalio’s Principles, I found these two paragraphs below. They simply explain the whole issue:

Unlike any other species, man is capable of reflecting on himself and the things around him to learn and adapt in order to improve. He has this capability because, in the evolution of species man’s brain developed a part that no other species has—the prefrontal cortex. It is the part of the human brain that gives us the ability to reflect and conduct other cognitive thinking. Because of this, people who can objectively reflect on themselves and others —most importantly on their weaknesses are—can figure out how to get around these weaknesses, can evolve fastest and come closer to realizing their potentials than those who can’t.

However, typically defensive, emotional reactions—i.e., ego barriers—stand way of this progress. These reactions take place in the part of the brain called the amygdala. As a result of them, most people don’t like reflecting on their weaknesses even though recognizing them is an essential step toward preventing them from causing them problems. Most people especially dislike others exploring their weaknesses because it makes them feel attacked, which produces fight or flight reactions; however, having others help one find one’s weaknesses is essential because it’s very difficult to identify one’s own. Most people don’t like helping others explore their weaknesses, even though they are willing to talk about behind their backs, For these reasons most people don’t do a good job of understanding themselves and adapting in order to get what they want most out of life. In my opinion, that is the biggest single problem of mankind because it, more than anything else, impedes people’s abilities to address all other problems and it is probably the greatest source of pain for most people.

If we can successfully classify people into these two groups, I think we can do more meaningful things. Of course, it’s OK to become friends with the people who fall into the second category. As long as you don’t forget about their limitations and pick suitable activities.

Now, the second group of people are quite a different story. They would not only accept your help for their personal development, they would welcome it. But, why should we care? It’s their personal development, their problem. Shouldn’t we be worried about our own personal development? These people would have a momentum in their life that will affect your own pace. Moreover they will probably try to engage you and try to help you overcome your weaknesses. You should be worried about your own growth primarily. This is why surrounding yourself with these people is a great idea.

I have been very fortunate to meet people who are not afraid to review and renew themselves. I have managed to understand myself and others better, thanks to their mentoring. You don’t need to wait for a mentor to appear out of nowhere² and give you all the answers and keys though. You can start with Seth Godin’s Quieting the Lizard Brain talk (below) and hopefully begin learning and changing things. After all noone can adapt for you, you will eventually need to exert some effort. Great effort.

1: Also I have been reading about game design but it is not really related to this post.

2: I consider myself really, really lucky, what kind of person would I be if those fantastic people hadn’t appear out of nowhere. I don’t think I would have ever dared to challenge myself.

No related posts.

git commit -a -m"f"

Instead of forming a whole changeset carefully, I just go with it and do many small f commits. If it gets hairy I can revert back to a previous step or remove one or more of them. When I am happy with the result, I rebase and mark all the f commits after the initial commit as fixup. Initial commit usually has the commit message this changeset will finally have but if I want to change it I just mark is as reword.

Note that, what I call an f commit is not an atomic set of modifications, they’re usually undoing or overriding the previous changes. Another way to put it; they are silly commits that I wouldn’t want anyone else to see. They are a better undo mechanism than whatever editor you are using offers, and they allow you to synchronize multiple files.

I am not saying this is revolutionary or anything. But this is one example of how git changed my workflow and my way of thinking, definitely in a positive way. If you are not familiar with interactive rebasing please take the time to learn how it works. It is going to pay really well, trust me.

No related posts.

Programming is human activity, but this image still has nothing to do with it.

Most of the readers of this blog are professional programmers. I am sure for many of you starting was quite easy and natural. But for a lot of people it is an extremely difficult obstacle. I know people, more than 50 people, who studied CS or CE in university but has never written any real code. They get anxious when the possibility presents itself.

The problem with the start is usually the false expectations about programming. There are certain myths about heroic programmers writing incredible programs in impossible conditions with little or no effort. This is of course bullshit. But I have witnessed again and again people setting their expectations about the experience of writing code by these absurd standards. The actual experience inevitably fails to deliver these expectations and the person gives up. This doesn’t have be so. Programming is supposed to be fun.

When we open a book and start reading, the words we see are unlikely the author’s original words. The original, raw content get edited before printing. It is an iterative process. I don’t want to get into the details about publishing¹ but beginners should study this process carefully. Because the process of programming is same, sans the magic.

So the act of programming is also an act of debating. You debate with your tests using your code. When all tests pass, the debate is over. When you are making design decisions, no matter how small they are, there is a debate going on between the requirements, the resources and your professional judgement. Therefore it would be unreasonable to expect programming to be a smooth, frictionless process. If you want to start you should be prepared for it.

I would like to share a few pointers that I hope will make the start more predictable if not easier:

1. Try to find a real problem to work on. Forget about educational/theoretical problems. Solve a real, practical problem. There is one extremely important thing to remember here; the scope of the project must be as small as possible. A series of 2-day projects are much better than a 2 week project.
2. Start by documenting the usage of the code. Write an example script that imports your hypotetical code and uses its functionality. In other words; design top-down, program bottom-up.
3. Then flesh out the structure. Create files, classes, functions, comments. Writing code is good for warming-up to write some code.
4. Divide and conquer. Implement incrementally, accomplish one thing at a time. If a functionality is giving you hard time, try to write something that produces some results but not exactly what you expect. Then continue iterating until you get it right. Don’t wait for the programming muse to come and light the way. Sometimes you need to invent all the wrong implementations before figuring out the correct one.
5. Never hesitate to ask for help. Programming is debating, why not introduce your peers and mentors into the process. If you are asking for help make sure you have a concrete question. Input, expected output and your current code is usually enough. Even when you don’t have a problem or question, share your work with others and try to get as much feedback as possible.
6. Do your research. There is no getting around the reading. I would be lying to you if I said otherwise. If you want to win the debate you need to be well prepared. It may be a little overwhelming in the beginning. But as you build up your knowledge (and experience) you will enjoy reading more.

I hope these pointers are helpful. But I think the most important thing to remember is programming is not a mechanical process but it is very human, I call it a debate, some call it art.

1: Nor am I an expert on the subject.

No related posts.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. Working with files in Django – Part 3