Il configure également le smoothing RGB pour que les fonts soient clean !

Profitez bien !

#! /bin/sh
WINE_FOLDER=$HOME/.wine-gp7
GP7_EXE=$HOME/Nextcloud/Documents/softwares/guitar-pro-7-setup.exe

# echo "Remove wine prefix"
# rm -rf $WINE_FOLDER
echo "Configure font smoothing"
WINEPREFIX=$WINE_FOLDER winetricks settings fontsmooth=rgb
echo "Install corefonts"
WINEPREFIX=$WINE_FOLDER winetricks settings corefonts
echo "Install GuitarPro7"
WINEPREFIX=$WINE_FOLDER wine $GP7_EXE &
exit 0

J'ai récemment décidé de passer du moteur de blog Pelican à Ghost.
Ce changement a été motivé par l'envie de pouvoir éditer du contenu depuis n'importe où.
En espérant que cela me motive pour le faire plus souvent !

Bienvenu(es) donc sur ce nouveau blog !

Et pour ce faire, j'ai codé un petit script python qui utilise Pandoc pour convertir les articles
que j'avais écrit en reStructuredText (RST) vers le format Markdown, utilisé par le moteur de Ghost.

Il commence par extraire les tags RST à coup d'expression régulière et utilise ensuite Pandoc
pour s'occuper de la conversion.

Il est disponnible en licence MIT sur mon repo Github.

C'est une première version qui recevra peut être des améliorations.
Si vou êtes tentés, n'hésitez pas à contribuer !

Il y a pas mal de plugin pour la traduction de texte pour les utilisateurs de VIM. Malheureusement, google a changer sa politique pour l'utilisation de ses APIs, et les développeurs de plugins n'ont pas forcément suivi. Du coup, il devient assez difficile de trouver quelque chose d'utilisable.

J'ai cherché, fouiné, parcouru pas mal de thread et de blog et j'en ai pondu deux petits mapping perso qui s'appuient sur translate-shell, un soft qui permet de faire des traductions en utilisant Google© translate.

Le premier mapping permet de prend le texte sélectionné, et de le traduire :

vnoremap <leader>t y:sp newfile<CR>pgg^vG$:!trans -b :fr<CR>

Le second prend la ligne courante, et la traduit :

nnoremap <leader>t ^v$y:sp newfile<CR>pgg^vG$:!trans -b :fr<CR>

Quelques explications sur ces mapping :

• vnoremap{.sourceCode} et nnoremap permettent de créer un raccourcis clavier en mode visuel et normal;
• <leader>t{.sourceCode} dit à VIM d'utiliser la touche leader suivi de la touche t comme raccourci;
• y:sp newfile<CR>{.sourceCode} fait dans l'ordre : copier la sélection (y) etouvrir un buffer vide (:sp newfile<CR>);
• pgg^vG${.sourceCode} copie la sélection (p), déplace le curseur à la première ligne (gg), déplace le curseur au début de la ligne (^), passe en mode visuel (v), déplace le curseur à la dernière ligne (G), et déplace le curseur à la fin de la ligne;
• :!trans -b :fr{.sourceCode} demande à translate-shell de traduire la sélection en mode simplifié (!trans -b), vers la langue français (:fr).

Le texte à traduire est ouvert dans un nouveau buffer, et est remplacé par la traduction une fois celle-ci trouvée.

Et voilà ! Le deuxième mapping fait globalement la même chose, à ceci près qu'il sélection la ligne courante avant d'ouvrir le buffer et de faire la traduction.

Pré requis

Commençons cet article par quelques rappels histoire de savoir de quoi
on va parler ici.

ORM

Un object-relational mapping (mapping objet-relationnel en français)
est une technique de programmation informatique qui crée l'illusion
d'une base de données orientée objet à partir d'une base de données
relationnelle en définissant des correspondances entre cette base de
données et les objets du langage utilisé. On pourrait le désigner par
« correspondance entre monde objet et monde relationnel ». —
Wikipédia

Un ORM est donc un outil qui permet d'associer un ou plusieurs objets, à
une ou plusieurs tables d'une base de données relationnelle. C'est le
parallèle entre votre modèle de données et vos données telles qu'elles
sont stockées.

Django

Django est un framework web écrit en Python. Il vous fournit tout (ou
presque) ce dont vous avez besoin pour construire une application web en
Python:

• un routeur d'url;
• une gestion de l'authentification;
• une gestion des sessions;
• un moteur de template;
• un ORM;
• un système de middleware;
• et j'en passe

Utilisez la puissance de l'ORM de Django

Je ne vais pas passer sur les méthodes de base de l'ORM, la
documentation
s'en charge déjà très bien elle-même. Passons plutôt à une utilisation
un peu plus avancée et du coup plus sympa. Intéressons nous aux méthodes
annotate et aggregate.

Mise en place

class Student(models.Model):
    firstname = models.CharField(max_length=30)
    lastname = models.CharField(max_length=30)

    def __unicode__(self):
        return '{} {}'.format(self.firstname, self.lastname)


class Grade(models.Model):
    student = models.ForeignKey(Student)
    value = models.FloatField()

Annotate

Annotate permet d'ajouter, à la volée et à chacun des éléments
retournés par la requête, un ou plusieurs attributs. De ce fait, il sera
possible de filtrer, trier, ou faire des actions d'agrégation sur ces
attributs en base de données.

Regardons quelques exemples pour illustrer ça :

import random
from django.db.models import Avg
s1 = Student.objects.create(firstname='john', lastname='doe')
s2 = Student.objects.create(firstname='jane', lastname='doe')
for value in [random.randint(0, 20) for i in xrange(0, 30)]:
    Grade(student=s1, value).save()
for value in [random.randint(0, 20) for i in xrange(0, 30)]:
    Grade(student=s2, value).save()
# ajouter la moyenne des notes de chaque élève
students = Student.objects.annotate(avg=Avg('grade__value'))
print(students[0].avg)  # 8.23
print(students[1].avg)  # 11.3
print(students.filter(avg__gte=10))  # <QuerySet [<Student: john doe>]>

On peut également ajouter un attribut avec une valeur arbitraire

from django.db.models import ExpressionWrapper, Value, IntegerField
students = Student.objects.annotate(max_abs=ExpressionWrapper(Value(3),
                                                             output_field=IntegerField()))
print(students[0].max_abs)  # 3
print(students[1].max_abs)  # 3

Mais annotate nous permet de faire des choses plus complexes, comme
concaténer plusieurs champs.

from django.db.models import F, ExpressionWrapper, Value
from django.db.models.functions import Concat
students = students.annotate(fullname=ExpressionWrapper(Concat(F('firstname'), Value(' '), F('lastname')),
                                                        output_field=CharField()))
print(students[1].fullname)  # jane doe

Ici, c'est l'objet F() qui permet de faire référence à un attribut de
l'élément en cours de traitement.

Admettons maintenant que vous vouliez, pour chaque élément, indiquer si
l'élève est reçu ou non (c'est à dire, est-ce que sa moyenne est
supérieur ou égale à 10). Utilisons Case() et `When()`:

from django.db.models import Case, When
students_with_avg = Student.objects.annotate(avg=Avg('grade__value'))
# ajoutons l'admissibilité
admissible = ExpressionWrapper(Value('admis'), output_field=CharField())
non_admissible = ExpressionWrapper(Value('non admis'), output_field=CharField())
students = students_with_avg.annotate(admissible=Case(When(avg__gte=10, then=admissible),
                                                      default=non_admissible))
students = students.annotate(fullname=ExpressionWrapper(Concat(F('firstname'), Value(' '), F('lastname')),
                                                        output_field=CharField()))

print(dict(students.values_list('fullname', 'admissible')))
# output: {'john doe': 'non admis',
#          'jane doe': 'admis'}

Aggregate

Aggregate quant à elle, s'applique sur l'ensemble des éléments
retournés par la requête. Elle permet d'exécuter une fonction (Sum, par
exemple) sur le résultat de la requête. Voyons quelques exemples.

from django.db.models import Max, Min
# trouvons la moyenne générale
students_with_avg = Student.objects.annotate(student_avg=Avg('grade__value'))
global_avg = students_with_avg.aggregate(Avg('sutdent_avg'))
print(global_avg)  # {'student_avg__avg': 9.765}
# trouvons la note la plus basse
print(Grade.objects.aggregate(min_value=Min('value'),
                              max_value=Max('value')))
# output: {'min_value': 3, 'max_value': 18}

Voilà déjà de quoi jouer un peu avec l'ORM de Django.

Pour le premier article de la catégorie 'OnTheGo', je vous propose de découvrir un jeu qui m'a déjà fait perdre plusieurs heures de ma vie : Enyo.

C'est un jeux de la catégorie Puzzle Game dans lequel vous incarnez Enyo, la déesse grecque des champs de bataille. Le but est de résoudre des plateaux de 10x10, composés de terre ou de pièges. Pour résoudre un
plateau, il vous faudra vous débarrasser des ennemis présent sur les cases en utilisant vos capacités guerrière :

• le coup de bouclier (sert également au déplacement de base)
• le grappin, qui permet d'attraper un ennemis et de le tirer derrière
  soi
• le lancer de bouclier, qui permet d'attaquer un ennemis à distance
• le saut, qui, une fois sur deux, assomme les ennemis alentours

Pour vous débarrasser d'un ennemi, il faut le faire tomber dans un piège. De prima bord, le jeu semble facile, mais ne vous y laisser pas prendre, il demande une véritable réflexion, d'autant que le nombre de monstres augmente au fil des niveaux !

Le jeux est disponible "gratuitement" (moyennant publicités) sur iOS et android. Un achat in-app est possible sur iOS pour supprimer la publicité.

Amusez vous bien !

Dans ce nouveau article sur Django, nous allons définir un ModelManager pour des modèles abstraits, qui comme vous le savez, ne peuvent pas être requêtées en l'état.

L'héritage entre deux modèles en Django peux se faire de 2 façon dans le framework : de manière concrète ou abstraite.

Un héritage concret est très pratique, dans le cas de clé étrangère par exemple. En effet, il est impossible de créer un lien vers un modèle abstrait, puisque justement il n'a pas d'existence en DB. L'inconvénient est qu'il est nécessaire de maintenir une table pour le modèle papa.

L'héritage abstrait, quant à lui, est utile lorsque des modèles distincts partagent des attributs ou des méthodes, mais qu'ils n'ont pas nécessairement de lien.

En résumé, les modèles concrets sont liés entre eux par un lien 1-1, qui fait office de clé primaire. Lorsqu'un modèle hérite d'un modèle abstrait, ce lien n'existe pas.

Il devient donc pénible de faire d'obtenir la liste des instances d'un modèle qui hérite d'un modèle abstrait.

Voici un petit bout de code qui permet, de manière détournée, d'obtenir toutes les instances d'un enfant d'un modèle abstrait :

from django.core.exceptions import FieldError, ObjectDoesNotExist
from django.db.models.query import QuerySet
import functools


class AbstractQuerySetSequence(list):
    def query(self, _name, *args, **kwargs):
        objects = AbstractQuerySetSequence()
        for k, qs in self:
            try:
                objects.append((k, getattr(qs, _name)(*args, **kwargs)))
            except FieldError as e:
                objects.append((k, qs))
            except Exception as e:
                objects.append((k, e))
        return objects

    def __getattr__(self, _name):
        try:
            return getattr(super(AbstractQuerySetSequence, self), _name)
        except AttributeError:
            return functools.partial(self.query, _name)

    def to_json(self):
        return {k.___name__: list(v) for k, v in self}


class AbstractModelChildrenRegister(object):
    """ Class to register abstract model children and
    query throught them.
    """
    def __init__(self, *args, **kwargs):
        self.models = []

    def register(self, model):
        self.models.append(model)

    def managers(self):
        return [m.objects for m in self.models]

    def query(self, _name, *args, **kwargs):
        objects = AbstractQuerySetSequence()
        for manager in self.managers():
            try:
                attr = getattr(manager, _name)
                obj = attr(*args, **kwargs)
            except FieldError:
                obj = attr()
            except Exception as err:
                obj = err
            objects.append((manager.model, obj))
        return objects

    def get_one(self, *args, **kwargs):
        for manager in self.managers():
            try:
                obj = manager.get(*args, **kwargs)
            except:
                pass
            else:
                return obj
        raise ObjectDoesNotExist

    def __getattr__(self, _name):
        if not hasattr(QuerySet(), _name):
            return getattr(super(AbstractModelChildrenRegister, self), _name)
        return functools.partial(self.query, _name)

Ce 'Manager', placé sur un modèle abstrait, maintient un registre des classes enfantes de celui-ci. On expose ensuite l'api d'un ModelManager et on répercute les appelles à cette api sur les modèles du registre. Le résultat est une liste de tuples de ce type : (ModelEnfant, QuerySet). En cas de FieldError, la queryset précédente (ou .all()) est renvoyée. Si c'est un autre type d'erreur qui est levé, la queryset est remplacée par celle-ci.

Et voilà !

Bon ça à l'air vraiment super sur le papier, mais est-ce que ça fonctionne ? Voyons un exemple. Je passe volontairement les détails de l'initialisation du projet Django.

from django.db import models
from demo.utils.abstract import AbstractModelChildrenRegister


class TitledModel(models.Model):
    title = models.CharField(max_length=32)

    register = AbstractModelChildrenRegister()

    class Meta:
        abstract = True


class Serie(TitledModel):
    pass
TitledModel.register.register(Serie)


class Article(TitledModel):
    draft = models.BooleanField(default=False)
    content = models.TextField()
    serie = models.ForeignKey(Serie, related_name="articles", null=True, blank=True)
TitledModel.register.register(Article)

Voilà on a créé deux modèles qui implémentent TitledModel. On va créer quelques objets et voir comment notre bidouille s'en sort:

>>> from demo.models import TitledModel, Article
>>> Article.objects.create(title='Mon super article 1',
                           content='Super article de la mort')
<Article: Article object>
>>> Article.objects.create(title='Mon super article 2',
                           content='Autre super article de la mort')
<Article: Article object>
>>> TitledModel.register.all()
[(demo.models.Serie, []), (demo.models.Article, [<Article: Article object>])]
>>> TitledModel.register.filter(title='Mon super article 1')\
...                     .values_list('title', flat=True)
[(demo.models.Serie, []), (demo.models.Article, [u'Mon super article 1'])]

Ça marche !

Django est plein de surprises. Sa class Model est impressionnante de
complexité. Voici un exemple de ce qui est possible de faire:

# utilisation
class MonModel(models.Model):
    ...
    data = EncryptedField(encoder=Base64Enc)
    ...

mon_instance = MonModel()
mon_instance.data = "coucou"
print(mon_instance.data)
# 'coucou'
print(mon_instance.data_enc)
# 'Y291Y291\n'

Moi, ça me botte. Au final, ça s'apparente à ce que Django fait pour les mots de passe de la base User avec la méthode set_password,
mais en plus pratique.
On va voir le détail des opérations pour arriver à ce résultat.

Tout d'abord, il faut implémenter un objet qui permet d'encoder et de décoder des messages : un encodeur. Pour l'exemple, on va en faire un que ne fait
strictement rien, et un objet qui crée une représentation base64 du contenu.

from django.db import models
import base64

class BaseEnc(object):
    def encode(self, value):
        return value

    def decode(self, msg):
        return msg

class Base64Enc(object):
    def encode(self, value):
        return base64.encodestring(value)

    def decode(self, msg):
        return base64.decodestring(msg)

Maintenant, on crée une sous-classe de TextField et on surcharge quelques méthodes.

class EncodedField(models.TextField):

    description = "An encoded field"

    def __init__(self, encoder=BaseEnc, *args, **kwargs):
        self.encoder = encoder()
        super(EncodedField, self).__init__(*args, **kwargs)

    def contribute_to_class(self, cls, name):
        if self.db_column is None:
            self.db_column = name
        self.field_name = name + '_enc'
        super(EncodedField, self).contribute_to_class(cls, self.field_name)
        setattr(cls, name, property(self.get_data, self.set_data))

    def get_data(self, obj):
        if getattr(obj, self.field_name):
            return self.encoder.decode(getattr(obj, self.field_name))
        return None

    def set_data(self, obj, data):
        if data:
            setattr(obj, self.field_name, self.encoder.encode(data))
        else:
            setattr(obj, self.field_name, None)

La magie opère dans la méthode contribute_to_class. La raison d'être de cette méthode est très bien expliquée dans cet article d'Alex Gaynor. Pour ceux d'entre vous qui ne seraient pas anglophones, ou qui auraient la flemme de tout lire voici un raccourci :

Certaines classes de Django possède une méthode add_to_class. C'est le cas des classes qui héritent de ModelBase par exemple.
Lorsque vous ajoutez un attribut data = MaValeur à un modèle MonModel, add_to_class('data', MaValeur) est appelée.
Deux cas de figurent se présentent, soit MaValeur ne possède pas de méthode contribute_to_class, soit cette méthode existe.

Dans le premier cas, add_to_class va simplement faire un setattr('data', MaValeur). Dans le second, c'est contribute_to_class qui va être appelée.

Ok, maintenant que c'est clair, on reprend.

Notre méthode contribute_to_class va faire plusieurs choses:

• changer l'attribut field_name de notre attribut en ajoutant "_enc" au nom de l'attribut
• définir un getter/setter attaché au nom de l'attribut telle qu'on l'a définit dans le modèle

Par exemple, pour un attribut appelé data, les données enregistrées en DB se retrouveront dans l'attribut data_enc, tandis que l'attribut data retournera le resultat de instance_de_champ.get_data('data_enc'). Et voilà, notre valeur est décodée !

Je suis tombé l'autre jour sur un projet formidable en pure
Javascript pour afficher, trier (et bien d'autre chose) des listes
html sous diverses formes : list (ul, ol), table, ...), j'ai nommé :
ListJs.

Il fait super bien le taf et du coup je m'en sers TRÈS souvent.

Il intègre un système de plugins et d'ailleur le développeur en propose
certains :

• ListPagination
• ListSearch

J'en propose un également pour permettre l'export de la-dites liste,
pour l'instant uniquement en CSV mais d'autres formats arriveront plus
tard. Il est disponible sur mon repo Github :
ListExportable.

Il reste quelques petites choses à faire :

• Implémenter d'autres formats d'exports
• Faire des tests...

Dépendances

Il nécessite uniquement de ListJs (forcément), et de jQuery (>= 1.7)
pour la gestion de l'évènement click.

Usage

$(document).ready(function () {
	// defining list options
	var options = {
		valueNames: ['col1', 'col2', '...']
		plugins: [
		  ListExportable({
			linkContainersSelector: ".exporters",
			exportLinkTemplate: '<a href=''>Export {{type}}</a>',
			type: ['csv'],  // only csv for now, sorry...
			filename: "export",  // some browsers will not handle the filename definition
		  })
		]
	};

	var listObj = new List('myTabelListId', options);

});

Les framework CSS nous ont apporté énormément d'outils pour créer du
contenu responsive. Le plus appreciable est le système de grille, qui
permet d'afficher des éléments en respectant un pattern bien définit. Je
vous laisse consulter la doc des framework pour en apprendre plus.

Ce système de grille est extrèmement pratique lorsque le nombre
d'éléments que l'on a à afficher est fixe. On peut, par exemple,
découper notre liste d'éléments en une liste de listes de N éléments, N
étant le nombre d'éléments à afficher par ligne.

En python on aurait par exemple ça côté serveur :

>>> def list_to_rows(l, elem_by_row):
        return [[l[l.index(x) + i] for i in xrange(0, elem_by_row) if l.index(x) + i < len(l)]
                for x in l[::elem_by_row]]

>>>> mylist = [1,2,3,4,5,6,7]
>>> list_to_rows(mylist, 2)
[[1, 2], [3, 4], [5, 6], [7]]

Ici on utilise le slicing python en définissant un step. Attention, ça
ne marchera pas avec un générateur !

On aurait plus qu'à parcourir notre liste de liste côté HTML pour
afficher les lignes successives, ici en Jinja par exemple.

<div>
    {% for row in mylist %}
    <div class="row">
        {% for elem in row %}
        <article>
            <div class="col s6">  <!-- On indique s6 parce qu'on veut afficher 2 élément par ligne (list_to_rows(mylist, 2)) -->
            {{ elem }}
            </div>
        </article>
        {% endfor %}
    </div>
    {% endfor %}
</div>

C'est simple et efficace. Mais si on veut pouvoir filtrer dynamiquement
sur cette liste côté client, ça ne fonctionnera plus. Enlevez un élément
à votre liste une fois le Jinja rendu et c'est le drâme.

On peut pour cela faire confiance à AngularJs. Côté serveur, on envoie
simplement notre liste. On ne s'en occupe pas d'avantage.

Côté client en revenche, on va pouvoir controller la façon donc elle
sera affichée :

<div ng-app="myapp" ng-controller="AppCtrl">
    <article ng-repeat="elmt in list">
        <span ng-switch="$index%3">
            <div class="row" ng-switch-when=0>
                {{ elmt.name }}
            </div>
		</span>
    </article>
</div>

Il faut quelques explications je pense. Tout d'abord, on met notre
affichage dans le scope de notre controller AppCtrl

Ensuite, on boucle sur la liste avec la directive ng-repeat. On ne va
s'interesser qu'aux éléments donc l'index est divisble par 3 avec la
directive ng-switch="outerIndex%3" et ng-switch-when=0.

Bon, c'est déjà pas mal. Mais nous on veut tout afficher.

On va donc modifier un peu notre template Angular pour ça.

<div ng-app="myapp" ng-controller="AppCtrl">
    <article ng-repeat="_ in list" ng-init="outerIndex=$index">
        <span ng-switch="outerIndex%3">
            <div class="row" ng-switch-when=0>
                <div ng-repeat="elmt in list.slice(outerIndex, outerIndex+3) track by $index">
                    <div ng-if="elmt">
                        <div class="col s4 bordered">
                            {{ elmt.name }}
                        </div>
                    </div>
                </div>
            </div>
        </span>
    </article>
</div>

On fait une deuxième boucle dans la première. Cette boucle, on la fait
sur un slice de la list originale, entre l'index de l'élément définit
par le switch, et 3 index plus loin. En gros, pour le 4ème élément de la
liste originale (index 3, divisible par 3 donc), on va faire un slice de
la liste de l'index 3 à 6. Ce qui donnera les 4ème, 5ème et 6ème
éléments de la liste.

Ces éléments, on veut qu'ils soient identifiés par leur $index dans la
seconde boucle (AngularJs pleurniche si la liste contient des
doublons...). On est donc obligé de stocker la variable d'indexation de
la première boucle dans une autre variable nommée ici outerIndex et
d'utiliser track by $index dans la seconde.

Ensuite, si l'élément existe, on affiche l'éléments dans un colonne de
largeur 4 (puisqu'on veut afficher 3 éléments par ligne dans cette
exemple).

Voilà, la première étape est faite. C'était le plus important. Relisez
cette partie, faites des tests pour bien comprendre tout ce qu'il se
passe.

Je vous parlais de filtrage, ou tout du moins, de modifications dans la
liste. L'avantage d'angular et de sa directive ng-repeat, c'est qu'il
va modifier le DOM si vous modifier la liste à partir duquel il est
créé. Si vous retirez 3 éléments à la liste, vous faites sauter une
ligne.

Du coup, pourquoi ne pas utiliser de filtre sur cette affichage ? Bah
pourquoi pas :

<div ng-app="myapp" ng-controller="AppCtrl">
    <article ng-repeat="_ in (fList = (list | filter: greaterThan('id', 2)))" ng-init="outerIndex=$index"> <span ng-switch="outerIndex%3">
        <div class="row" ng-switch-when=0>
            <div ng-repeat="elmt in fList.slice(outerIndex, outerIndex+3) track by $index">
                <div ng-if="elmt">
                    <div class="col s4 bordered">
                        {{ elmt.name }}
                    </div>
                </div>
            </div>
        </span>
    </article>
</div>

L'astuce ici repose dans la première directive ng-repeat : on stocke
le résultat du filtre dans une variable fList pour l'utiliser dans la
seconde boucle. Et c'est tout. Vous pouvez chaîner vos filtre, rendre le
nombre de ligne dynamique, ... Il y a déjà de quoi s'amuser un petit
moment !

Tastypie est très bien pour construire une API à partir de modèle
Django. Elle propose tout un tas d'authentification et les sources sont
bien écrites, de sorte que lorsqu'on à un besoin non répertorié dans la
doc, on peut quand même se débrouiller.

Il y a quand même un petit défaut : le versionnement. Alors peut être
que j'ai loupé quelque chose, mais je n'ai rien vu qui permette de
versionner correctement l'Api construire avec cette lib. C'est dommage
parce que ça partait bien : on peut en effet créer plusieurs Api avec
des noms (ou dans notre cas des versions) différentes, mais rien n'est
très clair dans la doc quant au comportement des resources.

Du coup, voici une solution que j'utilise qui permet de maintenir
plusieurs versions d'Api, sans trop de problèmes :

On commence par l'arborescence de notre application :

- CookBook /
- cookbook /
    - __init__.py
    - settings.py
    - urls
    - wsgy.py
- manage.py
- recipes /
    - __init__.py
    - admin.py
    - migrations /
        __init__.py
    - models.py
    - tests.py
    - views.py

On va faire une bête application de snippets de code. Le fichier
recipes/models.py ressemble à ça :

# -*- coding: utf8 -*-
from django.db import models

class Recipe(models.Model):
    ''' '''
    snippet = models.TextField()
    name = models.CharField(max_length=255)
    language = models.CharField(max_length=255)
    edited = models.DateTimeField(auto_now=True)
    created = models.DateTimeField(auto_now_add=True)


class FileCheatSheet(models.Model):
    ''' '''
    name = models.CharField(max_length=255)
    sheet = models.FileField(upload_to="cheat_sheets")

Voilà, c'est pas bien compliqué, mais c'est pas le but. Je vous passe
les étapes de migrations de DB et tout ce qui s'en suit.

Bon, maintenant qu'on a notre modèle, on va créer la ressource pour
l'api. (Oubliez pas d'ajouter tastypie dans le tuple INSTALLED_APPS)

On va commencer par créer un module api dans l'app recipes. Il
contiendra un module v1 qui lui même contiendra un fichier
resources.py

- CookBook /
- cookbook /
    - ...
- recipes /
    - ...
    - api /
        - __init__.py
        - v1 /
            - __init__.py
            - resources.py
- ...

Voilà, on à la base de notre api. L'avantage de cette arborescence,
c'est que l'on sépare bien les ressources pour chaque version.

Notre fichier de ressources pour la v1 pourrai ressembler à ça :

# api/v1/resources.py
# -*- coding: utf8 -*-
from tastypie.resources import ModelResource
from tastypie.authorization import Authorization
from recipes.models import Recipe, FileCheatSheet


class RecipeResource(ModelResource):
    ''' The resource exposing the Recipe model '''

    class Meta:
        queryset = Recipe.objects.all()
        resource_name = "recipes"
        list_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        detail_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        authorization = Authorization()


class FileCheatSheetResource(ModelResource):
    ''' The resource exposing the FileCheatSheet model '''

    class Meta:
        queryset = FileCheatSheet.objects.all()
        resource_name = "cheatsheets"
        list_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        detail_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        authorization = Authorization()

def deserialize(self, request, data, format=None):
    format = format.lower()
    if format is None:
        format = request.META.get('CONTENT_TYPE', 'application/json')
    if format == 'application/x-www-form-urlencoded':
        return request.POST
    elif format.startswith('multipart'):
        data = request.POST.copy()
        data.update(request.FILES)
        return data
    return super(FileCheatSheetResource, self).deserialize(request, data, format)



# api/v1/__init__.py
# -*- coding: utf8 -*-
from tastypie.api import Api
from recipes.api.v1.resources import RecipeResource, FileCheatSheetResource

# define v1 api
api = Api(api_name="v1")
# register urls
api.register(RecipeResource())
api.register(FileCheatSheetResource())

Ici, il y a une petite subtilité : comme on va uploader un fichier via
l'api (pour l'attribut sheet), il faut définir un désérialiseur pour
le Content-Type multipart/form-data. Il faut simplement ajouter les
données contenu dans le QueryDict request.FILES à request.POST (on
est obligé de la copier dans une autre variable puisque c'est un objet
immuable).

Dans api/v1/init.py, on va enregistrer nos ressources pour qu'elles
soit exposées :

# api/v1/__init__.py
# -*- coding: utf8 -*-
from tastypie.api import Api
from recipes.api.v1.resources import RecipeResource, FileCheatSheetResource

# define v1 api
api = Api(api_name="v1")
# register urls
api.register(RecipeResource())
api.register(FileCheatSheetResource())

On a plus qu'à injecter les urls de l'api dans nos urls du projet :

# cookbook/urls.py
# -*- coding: utf8 -*-
...
from recipes.api.v1 import api as api_v1
...

app_patterns = patterns('',
    ...
    url(r'^api/', include(api_v1.urls)),
    ...
)

Voilà, notre api est fonctionnelle. J'ai volontairement passé sous
silence la partie authentification et autorisation, ce n'est pas l'objet
ici. On utilise ici la classe Authorization qui autorise tout et
n'importe quoi du moment que les verbes sont disponible dans
list_allowed_method et detail_allowed_method. A bien sûr ne pas
faire en prod...

Bon c'est pas mal ça, mais maintenant, j'aimerai bien pouvoir ajouter un
nouveau snippet depuis l'api en lui envoyant un ficher, plutôt que du
contenu brut, parce qu'avec un CURL, c'est plus pratique. Eh bien c'est
maintenant qu'il va falloir faire une v2.

Du coup on va créer un nouveau module v2 dans notre arborescence :

- CookBook /
- cookbook /
    - ...
- recipes /
    - ...
    - api /
        - __init__.py
        - v1 /
            - ...
        - v2 /
            - __init__.py
            - resources.py
- ...

Maintenant on va définir nos ressources, avec les changements. Mais on
n'a peut être pas envie de dupliquer le code de FileCheatSheetResource
vu qu'on ne va pas le changer. La documentation de Tastypie n'apportant
aucune solution, voici celle que j'ai choisi :

# api/v2/resources.py
# -*- coding: utf8 -*-
from tastypie.resources import ModelResource
from tastypie.authorization import Authorization
from tastypie import fields
from recipes.models import Recipe
from recipes.api.v1.resources import FileCheatSheetResource as V1FileCheatSheetResource


class RecipeResource(ModelResource):
    ''' The resource exposing the Recipe model '''
    snippet_raw = fields.CharField(null=True, blank=True)
    snippet_file = fields.FileField(null=True, blank=True)

    class Meta:
        queryset = Recipe.objects.all()
        resource_name = "recipes"
        list_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        detail_allowed_method = ['get', 'post', 'put', 'delete', 'patch']
        authorization = Authorization()
        excludes = ('snippet',)

def deserialize(self, request, data, format=None):
    format = format.lower()
    if format is None:
        format = request.META.get('CONTENT_TYPE', 'application/json')
    if format == 'application/x-www-form-urlencoded':
        return request.POST
    elif format.startswith('multipart'):
        data = request.POST.copy()
        data['snippet'] = request.POST.get('snippet_raw', None)
        if "snippet_file" in request.FILES:
            data['snippet'] = request.FILES['snipper_file'].read()
        return data
    return super(RecipeResource, self).deserialize(request, data, format)

def save(self, bundle, skip_errors=False):
    ''' Override the save method to create the snippet object
        from file or raw data
    '''
    snippet_buffer = bundle.data['snippet']
    # create the object
    obj = Recipe(snippet=snippet_buffer)
    # switch objects
    bundle.obj = obj
    return super(RecipeResource, self).save(bundle, skip_errors)

def dehydrate(self, bundle):
    ''' Override the dehydrate methode to re-add the snippet attribute
        and remove snipper_raw and snipper_file ones
    '''
    bundle = super(RecipeResource, self).dehydrate(bundle)
    bundle.data.pop('snippet_raw')
    bundle.data.pop('snippet_file')
    bundle.data['snippet'] = bundle.obj.snippet
    return bundle


class FileCheatSheetResource(V1FileCheatSheetResource):
    ''' Nothing to change for this resource in v2 '''
    pass

Quelques explications sont nécessaires. Dans cette version de la
ressource pour les Recipe, on va définir nous même les champs que l'on
veut pouvoir populer via l'api. Comme on définit un FileField, on est
obligé de remettre un désérialiseur pour récupérer les données d'un
formulaire multipart.

Ici on ne se contente pas de copier les données de requests.FILES dans
ce que retourne le désérialiseur. On va renvoyer le contenu du fichier
que l'on a envoyé (si c'est le cas) ou bien le contenu brut.

La méthode save est là pour créer l'objet. On récupère la valeur
snippet_raw et on y va.

Quant à elle, la méthode dehydrate est là pour nettoyer un peu les
données qu'on expose. En effet, comme on demande à envoyer wnippet_raw
ou snippet_file, et qu'on à exclu snippet, les premiers seront
afficher tandis que le dernier ne le sera pas. On utilise dehydrate pour
remettre de l'ordre dans tout ça.

Voilà, on a plus qu'à enregistrer nos ressources pour les exposer.

# api/v2/__init__.py
# -*- coding: utf8 -*-
from tastypie.api import Api
from recipes.api.v2.resources import RecipeResource, FileCheatSheetResource

# define v2 api
api = Api(api_name="v2")
# register urls
api.register(RecipeResource())
api.register(FileCheatSheetResource())

L'inconvénient, de cette manière de faire, c'est que l'ont est obligé
d'importer les ressources inchangées de la v1 pour en créer une
nouvelle, "vide".

En contrepartie, l'attribut resource_uri des objets conserve la
version de l'api utilisée pour faire l'appel. C'est une question
d'harmonie et ça évite de perdre les utilisateurs.

Il y a néanmoins une autre façon de procéder :

# api/v2/resources.py
# -*- coding: utf8 -*-
from tastypie.resources import ModelResource
from tastypie.authorization import Authorization
from tastypie import fields
from recipes.models import Recipe


class RecipeResource(ModelResource):
    ''' The resource exposing the Recipe model '''
    ...

# cette fois, on ne surcharge pas le FileCheatSheetResource de la v1



# api/v1/__init__.py
# -*- coding: utf8 -*-
from tastypie.api import Api
from recipes.api.v1.resources import RecipeResource, FileCheatSheetResource

# define v1 api
api = Api(api_name="v1")
# register urls
api.register(RecipeResource())
api.register(FileCheatSheetResource())

# api/v2/__init__.py
# -*- coding: utf8 -*-
from tastypie.api import Api
from recipes.api.v2.resources import RecipeResource
from recipes.api.v1.resources import FileCheatSheetResource

# define v2 api
api = Api(api_name="v2")
# register urls
api.register(RecipeResource())
api.register(FileCheatSheetResource())

L'avantage de cette façon de procéder, c'est qu'on ne duplique pas de
code. De plus, le changelog de la v2 est tout fait, puisque qu'il
suffit de regarder le fichier api/v2/resources.py pour voir ce qui a
changé par rapport à la v1.

En revanche, lorsque l'on va interroger l'api sur la v1, les uri des
objects qui sont identiques en v1 et en v2 seront renvoyés avec la v2.
Ca peut être perturbant pour les utilisateurs non-avertis. Ils risquent
de se demander pourquoi ont lui renvoie l'uri en v2 alors qu'il parle à
la v1.

En bref, si votre Api ne contient pas beaucoup de ressources, ça peut
valoir le coup d'utiliser la première version. Si elle en contient
énormément, ça va vite devenir pénible. A vous de voir à ce moment là si
la cohérence des uri est importante où pas.

Rappelons tout de même que, puisque l'objet n'est pas altéré entre
les deux versions, ça ne cassera absoluement rien !

À vous !

Tastypie propose plusieurs méthodes d'authentification
(ApiKeyAuthentication, BasicAuthentification,
OAuthAuthentication). Malheureusement,

elles ne déclenchent pas de signaux lors du succès de l'opération. On va
voir comment faire notre propre classe d'authentification pour envoyer
un signal lorsque l'utilisateur réussi à se connecter.

D'après la doc de
Tastypie,
on peut implémenter notre authentification de cette façon :

from tastypie.authentication import Authentication

class SillyAuthentication(Authentication):
	def is_authenticated(self, request, **kwargs):
		if 'daniel' in request.user.username:
			return True
		return False

# Optional but recommended
def get_identifier(self, request):
	return request.user.username

Du coup, on a juste à récupérer le résultat de l'authentification et
envoyer le signal si on a True.

from tastypie.authentication import BasicAuthentication
from django.contrib.auth.signals import user_logged_in

class SignaledBasicAuthentication(BasicAuthentication):
	""" Send a signal when finish BasicAuthentication """
	def is_authenticated(self, request, **kwargs):
		authorized = super(SignaledBasicAuthentication, self).is_authenticated(request, **kwargs)
		if authorized is True:
			user_logged_in.send(sender=request.user.__class__, request=request, user=request.user)
		return authorized

Dans l'exemple ci-dessus, on surcharge une BasicAuthentication, mais
toutes les classes d'authentification de tastypie sont sur le même
schéma.

Lorsque l'on cherche à optimiser son code, on a souvent besoin de
trouver quels blocs d'instructions posent problème. Le plus souvent, on
va chercher à trouver les morceaux de code qui prennent le plus de temps
à s'executer. Voyons quelles solutions s'offrent à nous.

Dans un premier temps, et de manière tout à fait intuitive, on peut
printer des time{.sourceCode} avant et après le bloc d'instruction à
bencher :

import time

t = time.time()
# mes instructions ...
print time.time() - t

On aura le résultat en secondes. Ca peut suffire, mais pas toujours.
Lorsque les instructions font appel à des méthodes de bibliothèques
tierces, on ne va pas s'amuser à mettre des print dans les sources de
là-dite bibliothèque. Il existe un profileur dans la lib standart de
python qui est bien pratique, j'ai nommé
cProfile. Attention
cependant, il va au bout des choses. Si votre fonction est grosse, cela
risque de devenir vite illisible.

L'utilisation est relativement simple. Essentiellement 2 cas de figures
:

• Soit vous voulez un benchmark d'une fonction de la lib standart et
  vous utilisez cProfile.runc("<mon appel>"){.sourceCode}
• Soit vous voulez un benchmark d'un truc bien à vous :
  cProfile.runctx("<mon appel>", None, locals()){.sourceCode}

Si la seconde solution vous revient en pleine face avec une
NameError{.sourceCode}, remplacez None{.sourceCode} par
globals(){.sourceCode}. Attention cependant, le dict
globals(){.sourceCode} est très consistant.

Du coup on aurait par exemple ça :

import cProfile

def my_func(arg1, arg2):
    print(arg1, arg2)

cProfile.runctx("my_func('Mulder', 'Scully')", None, locals()
# ou, si locals() est pas suffisant,
# cProfile.runctx("my_func('Mulder', 'Scully')", globals(), locals())
Mulder Scully
         5 function calls in 0.000 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 <stdin>:1(my_func)
        1    0.000    0.000    0.000    0.000 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 {built-in method exec}
        1    0.000    0.000    0.000    0.000 {built-in method print}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

Ici on vois que notre fonction prend un temps tellement négligeable que
cProfile le considère comme nul.

Ce qui est surtout intéressant de noter, c'est que cProfile affiche le
temps d'exécution, ainsi que le nombre d'exécutions des fonctions
built-in appelées. C'est ça qui nous intéresse lorsque l'on veut un
benchmark d'une fonction à nous utilisant une bibliothèque tierce.

Bon, ça, c'était pour l'utilisation dans un shell Python. Vous pouvez
aussi l'utiliser dans vos sources, mais ça va vite devenir pénible si
votre fonction prend pléthore d'arguments. Du coup, voilà un petit
décorateur pour vous faciliter le profilage.

import cProfile

def profiler(sort=-1, use_globals=False, use_locals=True):
    def decr(func):
        def wrp(*args, **kwargs):
            g = globals() if use_globals else None
            l = locals() if use_locals else None
            cProfile.runctx("func(*args, **kwargs)", g, l, sort=sort)
            return func(*args, **kwargs)
        return wrp
    return decr

Rien de bien magique ici, il est sous la forme d'un générateur de
décorateur, pour pouvoir lui passer l'index par lequel cProfile va trier
les résultats. Si vous voulez en savoir plus sur les décorateurs, un
petit tour sur le formidable article de
Sam&Max
vous fera le plus grand bien !

À vous de jouer !

En ce moment, je bosse beaucoup avec un Active Directory, logiciel
Microsoft utilisant Ldap. Si on met de côté les erreurs abstraites
incompréhensible, l'obligation d'envoyer des string sur la plupart des
champs (l'unicode serait quand même vachement plus cool) et j'en passe,
c'est sympa.

La plupart des champs temporels de l'AD utilise le type "Long Int", et
contrairement à ce qu'on pourrait croire, ce n'est pas un timestamp.
C'est un filetime. Le filetime est la représentation du nombre
d'intervals de 100 nano-secondes depuis le 1er Janvier 1601 (UTC).
Pourquoi faire simple quand on peut faire ça.

Passe encore, j'ai trouvé un petit module qui permet de convertir tout
ça chez Reliably
Broken.

Mais comme le disent nos chers conseillers SFR, "Et c'est pas fini !" :
non content d'utiliser une représentation de datetime exotique, ils en
utilisent une autre : le GeneralizedTime String.

C'est une chaîne de caractères qui concatène l'année (sur 4 chiffres),
le mois (sur 2), le jour (sur 2), l'heure (sur 2) et optionnelement les
minutes, les secondes, les microsecondes (sur 3 chiffres) et un
indicateur pour l'offset heures/minutes par rapport à l'UTC, l'UTC, ou
rien du tout. Plus d'info sur
l'ASN.1

Concrètement, ça ressemble à ça :

20150131143554.230          # datetime(2015, 01, 31, 14, 35, 554, 230)
20150131143554.230Z         # datetime(2015, 01, 31, 14, 35, 554, 230, tzinfo=<UTC>)
20150131143554.230+0300     # datetime(2015, 01, 31, 11, 35, 554, 230, tzinfo=<UTC>)

C'est relativement simple à parser, mais n'ayant rien trouvé pour
convertir ça en datetime sur le grand internet mondial, voici une petite
tool function pour le faire.

""" Tool function to convert Generalized Time string
    to Python datetime object
"""

import datetime
import pytz

def gt_to_dt(gt):
    """ Convert GeneralizedTime string to python datetime object

        >>> gt_to_dt("20150131143554.230")
        datetime.datetime(2015, 1, 31, 14, 35, 54, 230)
        >>> gt_to_dt("20150131143554.230Z")
        datetime.datetime(2015, 1, 31, 14, 35, 54, 230, tzinfo=<UTC>)
        >>> gt_to_dt("20150131143554.230+0300")
        datetime.datetime(2015, 1, 31, 11, 35, 54, 230, tzinfo=<UTC>)
    """
    # check UTC and offset from local time
    utc = False
    if "Z" in gt.upper():
        utc = True
        gt = gt[:-1]
    if gt[-5] in ['+', '-']:
        # offsets are given from local time to UTC, so substract the offset to get UTC time
        hour_offset, min_offset = -int(gt[-5] + gt[-4:-2]), -int(gt[-5] + gt[-2:])
        utc = True
        gt = gt[:-5]
    else:
        hour_offset, min_offset = 0, 0

    # microseconds are optionnals
    if "." in gt:
        microsecond = int(gt[gt.index('.') + 1:])
        gt = gt[:gt.index('.')]
    else:
        microsecond = 0

    # seconds and minutes are optionnals too
    if len(gt) == 14:
        year, month, day, hours, minutes, sec = int(gt[:4]), int(gt[4:6]), int(gt[6:8]), int(gt[8:10]), int(gt[10:12]), int(gt[12:])
        hours += hour_offset
        minutes += min_offset
    elif len(gt) == 12:
        year, month, day, hours, minutes, sec = int(gt[:4]), int(gt[4:6]), int(gt[6:8]), int(gt[8:10]), int(gt[10:]), 0
        hours += hour_offset
        minutes += min_offset
    elif len(gt) == 10:
        year, month, day, hours, minutes, sec = int(gt[:4]), int(gt[4:6]), int(gt[6:8]), int(gt[8:]), 0, 0
        hours += hour_offset
        minutes += min_offset
    else:
        # can't be a generalized time
        raise ValueError('This is not a generalized time string')

    # construct aware or naive datetime
    if utc:
        dt = datetime.datetime(year, month, day, hours, minutes, sec, microsecond, tzinfo=pytz.UTC)
    else:
        dt = datetime.datetime(year, month, day, hours, minutes, sec, microsecond)
    # done !
    return dt