Le document décrit la transition vers Django d'une plateforme vieillissante lancée en 2009, d'une équipe réduite et sans expérience préalable. L'utilisation de Django pour diverses applications a conduit à la mise en place d'une architecture simple et d'une synchronisation presque en temps réel entre les anciens et nouveaux systèmes. Les prochaines étapes incluent l'achèvement des fonctionnalités communautaires et la création d'une architecture solide d'ici septembre.

1. DES PONEYS À LIBÉRATION.FR
Mathieu Pillard Yohan Boniface
Rencontres django-fr, 16 avril 2011

2. Introduction
● Projet lancé en décembre 2009
●
Équipe très réduite (au départ, 2 personnes, ne
connaissant ni python ni django :-)
●
Toute une (double) plateforme vieillissante (en
PHP) et couteuse en place, à maintenir en
parallèle du remplacement
● Migration le plus possible brique par brique

3. État des lieux aujourd'hui
● On est loin d'avoir fini
● On utilise django pour :
● Next.liberation.fr (2 millions de pages vues/mois)
● La recherche front (300.000 pages vues/mois)
● La « liseuse » du journal papier sur le web (1 million de pages vues/mois)
● L'API pour accéder à nos données (30 millions de requêtes / mois)
● De la pub et autres trucs divers
● Architecture ultra-simple car besoins ultra-limités :
● Un frontal, une base de données, et un gros CDN devant qui cache tout
pour nous

4. Migration et synchronisation
● Le “back”, où sont créées les données, n'est pas encore en django
● Du coup, on synchronise les changements vers notre architecture
django en quasi-live
● Fonctionnement :
● Triggers SQL sur toutes les anciennes tables
● Créé des entrées en base dans created/updated/delete_rows
● Vérifié toutes les minutes par un démon
● Table de correspondance anciens modèles <=> nouveaux modèles
● Synchro des fichiers via un autre démon
● On ne synchronise que dans un sens, pas question d'avoir 2 endroits qui
écrivent en même temps
● Gère entre 5.000 et 25.000 update/delete/inserts en base par jour

5. API
● On utilise piston – pratiquement le seul choix abouti au
moment de la mise en place il y a un an
● On est à peu près REST, mais on triche : c'est du read-only
● On aime :
● Relative simplicité
● Rapide à mettre en place
● On aime pas :
● Pas facile de sortir des clous
● Peu maintenu – c'est en train de changer, un « community fork »
est en train de se mettre en place

6. Des petites applis par milliers
● But : refaire notre zone “communautaire” en django - reproduire les
fonctionnalités existantes
● Idée : profiter de l'écosystème d'applications django existantes
● Applications séparées plutôt que Pinax
● Pinax est orienté “clé en main”, pas adapté pour notre besoin
● La 0.9 se fait toujours attendre...
● Forks de quasi-toutes les applis concernées (~ une douzaine) sur
https://github.com/liberation
● Réactivité tout en gardant un contrôle
● Rajoute de fonctionnements qui nous manquent et re-versement des
changements à la communauté
● Presque tout est fait, mais pas encore en prod, les priorités ont changé en
cours de route :-)

7. La slide qu'on(g) savait pas ou la mettre
(et j'ai pas pensé à proposer le sujet de conf assez tôt)
● La super appli de la mort qu'on adore : django_compressor
● Gère la concaténation, minification etc de vos fichiers css/js
automatiquement
● Transparent pour les développeurs, juste des templatetags à
rajouter dans les templates, pas de settings compliqués à ajouter
● Commandes de management optionnelles pour remplir le cache
en une fois au lieu de générer en live
● Gère automatiquement les modifications, suffixage pour les
caches, etc
● Bien maintenu, documenté et testé

8. Minute philosophique: machine à café
ou boîte à outils?
● Beaucoup d'applis django sont construites en mode « plug&play »
● Très avantageux pour des petits sites, génériques, rapidement
● Beaucoup plus compliquer pour intégrer les fonctionnalités dans une
modélisation déjà existante et plus exigeante
● Pistes:
● Restreindre le périmètre des applis, les contenir à des fonctionnalités
cohérentes
● Éviter d'imposer une modélisation (donner le choix du modèle/manager via des
settings, et proposer des classes abstraites de base)
● Ne pas tenter de gérer la glue entre les applis à l'intérieur des applis (utiliser les
signaux, laisser les développeurs les utiliser)

9. Exemple d'appli générique qu'on
aimerait voir plus souvent (1)

10. Exemple d'appli générique qu'on
aimerait voir plus souvent (2)
Dans project/settings.py :
WIKIMODEL = 'mywikimodel'
WIKIAPPNAME = 'libe'
Dans wikiapp/__init__.py :
from django.db.models.loading import getmodel
from django.conf import settings
def get_model():
appname = getattr(settings, 'WIKIAPPNAME', 'wikiapp')
model = getattr(settings, 'WIKIMODEL', 'WikiModel')
return getmodel(appname, model)
Et ensuite, utilisation de wikiapp.get_model() partout au lieu de
WikiModel. Le projet implémentant l'application peut utiliser sa
propre modélisation, rajouter des champs, méthodes, etc

11. Conclusion, futur
● On pensait avoir fini vite, c'était sans compter les autres
projets à développer, l'ancienne plateforme à maintenir...
● Prochaines étapes :
● Finir la partie news
● Finir la partie communautaire
● Finir de mettre en place une vraie architecture
● Ça fait beaucoup de finir, mais ca devrait être prêt en septembre
si tout va bien
● Une fois que tout est la, un back-office propre coté django