1.
DES PONEYS À LIBÉRATION.FR Mathieu Pillard Yohan BonifaceRencontres 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 aujourdhui● On est loin davoir 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) ● LAPI 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, nest 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 davoir 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 : cest du read-only● On aime : ● Relative simplicité ● Rapide à mettre en place● On aime pas : ● Pas facile de sortir des clous ● Peu maintenu – cest 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 dapplications 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 quon(g) savait pas ou la mettre(et jai pas pensé à proposer le sujet de conf assez tôt)● La super appli de la mort quon 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 dapplis 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 dimposer 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 à lintérieur des applis (utiliser les signaux, laisser les développeurs les utiliser)

9.
Exemple dappli générique quonaimerait voir plus souvent (1)

10.
Exemple dappli générique quonaimerait voir plus souvent (2)Dans project/settings.py :WIKIMODEL = mywikimodelWIKIAPPNAME = libeDans wikiapp/__init__.py :from django.db.models.loading import getmodelfrom django.conf import settingsdef 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 deWikiModel. Le projet implémentant lapplication peut utiliser sapropre 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, lancienne 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