On Sunday (Dec. 06) parliamentary elections were held in Venzuela. I took the opportunity to fetch some data from Twitter's public stream and use graphics to show what was happening in "social media" during that day. To achieve this I relied in the Python programming language.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import json, os
from twython import TwythonStreamer

caracas_location = "-67.017225,10.419554,-66.778716,10.52006"

class MyStreamer(TwythonStreamer):
    def on_success(self, data):
        if data['coordinates'] is not None:
            with open('tweets.txt', 'a') as f:
                f.write(json.dumps(data))
                f.write('\n')

    def on_error(self, status_code, data):
        with open('errors.txt', 'a') as f:
            f.write('error: {0}: {1}'.format(status_code, data))



stream = MyStreamer(os.environ['APP_KEY'], os.environ['APP_SECRET'],
                        os.environ['OAUTH_TOKEN'], os.environ['OAUTH_TOKEN_SECRET'])

stream.statuses.filter(locations=caracas_location)

If you're working with third party APIs, you might find code like YOUR_SECRET_KEY="some secret api key" in your source code, this is a bad practices for a lot of reasons (security, source code sharing, etc). Instead, the recommended way to manage this kind of situation is to add the value as a enviroment variable, and read it in your code with something like this:

1
2

import os
os.environ.get('YOUR_SECRET_KEY')

So, how do you avoid to add the variable to the enviroment each time you do some coding? If you're working with virtualenv you simply add it in the env/bin/activate script:

1
2

YOUR_SECRET_KEY="some secret api key"
export YOUR_SECRET_KEY

These are some extra steps that I've found necessary when starting development in a recently-installed Debian machine.

1
2
3
4

$ sudo apt-get install libjpeg libjpeg-dev libfreetype6 libfreetype6-dev zlib1g-dev
$ sudo ln -s /usr/lib/`uname -i`-linux-gnu/libfreetype.so /usr/lib/
$ sudo ln -s /usr/lib/`uname -i`-linux-gnu/libjpeg.so /usr/lib/
$ sudo ln -s /usr/lib/`uname -i`-linux-gnu/libz.so /usr/lib/

1

$ sudo apt-get install python-dev libxml2-dev libxslt1-dev

1
2

$ sudo apt-get  -u install libfreetype6-dev
$ sudo apt-get build-dep python-matplotlib

1

$ pip install matplotlib

1

$ locale

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

LANG=es_VE.UTF-8
LANGUAGE=es_VE:es
LC_CTYPE="es_VE.UTF-8"
LC_NUMERIC="es_VE.UTF-8"
LC_TIME="es_VE.UTF-8"
LC_COLLATE="es_VE.UTF-8"
LC_MONETARY="es_VE.UTF-8"
LC_MESSAGES="es_VE.UTF-8"
LC_PAPER="es_VE.UTF-8"
LC_NAME="es_VE.UTF-8"
LC_ADDRESS="es_VE.UTF-8"
LC_TELEPHONE="es_VE.UTF-8"
LC_MEASUREMENT="es_VE.UTF-8"
LC_IDENTIFICATION="es_VE.UTF-8"
LC_ALL=

1
2
3
4
5
6

import locale

try:
    locale.setlocale(locale …

UPDATE: This article was originally written when Django version was 1.4. Since this article was published I made changes based on the new features of Django. You can see some of them in this repository: https://github.com/jackboot7/django-project-template.

This is short entry on how I organize my Django projects, in a way that will be easy to deploy to a production server. This is not meant to be a full tutorial on Django, but just to document the way I layout my Django applications. I consider this layout a work in progress, as each day I learn something new that I can integrate into my project's layout. Anyway, I hope someone else can find this entry useful.

For most of my small/pet/side projects, I use a simple server schema, working only with a local development machine and a production server, I know that is a good practice to use a staging server with the same setup as the production server, but for small projects I found this unnecessary.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

| - project_domain_name/
| | - .gitignore (.hgignore )
| | - requirements.pip
| | - env/                       # Virtual enviroment.
| | - var/
| | - server_config/             # Server configuration files.
| | | - nginx.conf
| | | - uwsgi.ini
| | |
| | - server_logs/               # Server logs.
| | | - errors.log
| | | - access.log
| | |
| | - project_dir/               # Django project. Most of the time I name it 'webapp'
| | | - apps/                    # Application apps.
| | | - templates/
| | | - static/
| | | - manage.py
| | | - urls.py
| | | - settings.py
| | | - local_settings.py

Some days ago, I started to work on a web application that requires to encode audio wave files (.wav) into three other formats, being: MP3, Flac and M4A. That encoding will run in its own Celery task.

One thing I knew for certain is that I wouldn't be running commands such as lame or flac directly.

Since the project is being written in Python, I though it would be nice to use a library to do all the encoding directly in Python code, without calling any external program..

If you're going to write an audio related application in Python, I recommend a visit to the audio section in the Python wiki, where you can find all the audio related modules that are available for Python.

I decided to use the API from Python Audio Tools, which is a very complete library to do audio manipulation. In the backend, it uses lame, flac and other commands to do the enconding of the files, but I won't have to run those commands directly.

So far, I'm very happy with the results I've got using audiotools, since it deals with metadata for the audio files (ID3v2 tagging, et al.) and it can even embed artwork into the files (if the format support such metadata).

I wrote a small Python script to show a basic use of this library, if you want, you can check it out on my githhub repo. I'll be adding a little more functionality to it as soon as I got some free time.