Pour mener cela à bien, nous avons décidé d’utiliser Geolite Country.
Celui-ci permet de géolocaliser l’utilisateur en fonction de son ip sur la base du Pays. Pour une recherche plus affinée, les services sont payants. Mais le client désire uniquement centrer sur le pays de l’utilisateur. L’offre gratuite est donc amplement suffisante.

L’application étant en Python et ayant décidé d’utiliser la base binaire, j’ai donc installé la librairie pygeoip.
Son utilisation est particulièrement simple.

gmaps = urllib.urlopen('http://maps.google.com/maps/geo?q=%s&output=csv' % urllib.quote(country)).read().rsplit(',')

Le fichier GeoIP.dat est la base de données binaire, accessible sur GeoLite via ce lien direct.
Ainsi notre variable « country » est un string contenant le nom du pays. Ici « France ».

Il faut par la suite obtenir la latitude et la longitude de ce pays. Pour cela, Google Maps API est particulièrement utile.

gi = pygeoip.GeoIP('lib/GeoIP.dat')<br />
country = gi.country_name_by_name('o2sources.com')

Notre variable « gmaps » contiendra ainsi un tableau pour lequel les deux derniers éléments sont respectivement la latitude et la longitude.
Il n’y a plus qu’à afficher notre carte Google Maps centrée sur des données

Et puisque du code sans son contexte est d’une utilité moyenne, voici la vue permettant d’obtenir ces données

from django.shortcuts import render_to_response
from django.template import RequestContext

import pygeoip
import urllib

def home(request):
  gi = pygeoip.GeoIP('lib/GeoIP.dat')
  country = gi.country_name_by_name(request.META['REMOTE_ADDR'])
  gmaps = urllib.urlopen('http://maps.google.com/maps/geo?q=%s&output=csv' % urllib.quote(country)).read().rsplit(',')
  return render_to_response('centers/home.html', { 'country': country, 'latitude': gmaps[2], 'longitude': gmaps[3] }, context_instance=RequestContext(request))

Et dans notre template nous n’avons plus qu’à traiter ces données comme nous le désirons. Dans mon cas en affichant une carte Google Maps.
Mais vos besoins peuvent varier et les possibilitées sont quasiment illimitées.

Capistrano est un outil permettant d’automatiser le déploiement des applications développé en Ruby.
Mais il est utilisable avec toutes vos applications. Qu’elles soient développées en Ruby, en PHP, en Python et même, si vous êtes un peu fou, en Java.
Dans l’exemple que je vais donner ci-dessous, l’application est développée en Python avec Django. Et nous avions une problématique majeure : nous désirons pouvoir déployer sur le serveur de développement et/ou sur le serveur de production sans avoir deux tâches différentes (afin d’être DRY évidemment).

Dans un dossier nommé deployment à la base de notre application, j’ai créé deux fichiers.
deploy
Il s’agit d’un script bash, qui permettra d’exécuter le processus sans avoir à taper « cap … ».
En voici le contenu.
#!/bin/bash
ENV=$1 cap deploy -f deployment/deploy.rb

Vous pouvez noter que avant d’exécuter le script, je définis une variable d’environnement à la valeur du premier argument passé en paramètres.
Cela nous permettra de choisir si nous désirons pousser en développement ou en production.

Puis un fichier deploy.rb.
Vous pouvez en voir le contenu complet. Mais je vais également le détailler dans la suite de cet article.

Nous définissons plusieurs valeurs de configuration.
set :deploy_to, {'dev' => '/chemin/vers/le/site/en/developpement', 'prod' => '/chemin/vers/le/site/en/production'}
set :domain, {'dev' => 'host.developpement', 'prod' => 'host.production'}

La première variable contient le chemin de notre application, en développement et en production.
Le second contient les hosts de nos serveurs de développement et de production.

Puis nous définissons le serveur sur lequel nous voulons déployer.
ENV['ENV'] = 'dev' if domain[ENV['ENV']].nil?
role :web, domain[ENV['ENV']], :master => true

Si le paramètre « ENV » est à la valeur « prod », nous déployons en production. Sinon, nous déployons en développement.

Ainsi pour déployer en développement, vous n’aurez qu’à appeller votre script bash :
deployment/deploy
Et en production, il faudra préciser le paramètre.
deployment/deploy prod

Notre tâche capistrano contient ensuite les directives de déploiement.
La tâche deploy:default est appellée automatiquement. Elle fait un svn update, mettant ainsi à jour les fichiers de l’application.
desc "Updating the repository files in " + ENV['ENV'] + " environment"
task :default do
  stream "cd #{deploy_to[ENV['ENV']]}; svn update"
end

Nous avons ensuite une seconde tâche qui supprime tous les fichiers .pyc de notre application, afin d’éviter un quelconque problème de cache avec ceux-ci (ils sont générés automatiquement par Python).
desc "Remove *.pyc files"
task :delpyc do
  stream 'cd ' + deploy_to[ENV['ENV']] + ';find . -type f -name "*.pyc" -exec rm -fv {} \;'
end

Puis nous mettons à jour la base de données de notre application en faisant un syncdb.
desc "Make sure database is in sync with models"
task :syncdb do
  stream "cd #{deploy_to[ENV['ENV']]}; python manage.py syncdb"
end

Et enfin, puisque c’est un projet Django, il faut, afin que les modifications soient prises en compte, recharger Apache.
desc "We reload apache"
task :restart do
  stream "/etc/init.d/apache2 reload"
end

Nous avons maintenant défini nos tâches. Et comme dit précédemment, la tâche default est exécutée automatiquement.
Mais il faut tout de même définir l’ordre d’exécution des tâches. C’est la que viennent les instructions « after ».
after 'deploy', 'deploy:delpyc'
after 'deploy:delpyc', 'deploy:syncdb'
after 'deploy:syncdb', 'deploy:restart'

Notre tâche Capistrano fera donc, dans l’ordre :

1. Un SVN update afin de récupérer la dernière version du projet
2. Une suppression de tous les fichiers .pyc
3. Une remise à jour de la base de données
4. Un rechargement du serveur

Pour rappel, vous pouvez voir la tâche complète et colorisée sur github.

Votre application est à jour. Ici, ça prends 2 minutes chrono. Et on est sur que ça fonctionne (et si ça ne fonctionne pas quand même, cela nous prévient)
Et vous, vous déployez vos applications comment ?