Advertisement

Des poneys à Liberation.fr

Apr. 18, 2011
Advertisement

More Related Content

Similar to Des poneys à Liberation.fr(20)

Advertisement

Des poneys à Liberation.fr

  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
Advertisement