Des poneys à Liberation.fr

2 051 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
2 051
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Des poneys à Liberation.fr

  1. 1. DES PONEYS À LIBÉRATION.FR Mathieu Pillard Yohan BonifaceRencontres django-fr, 16 avril 2011
  2. 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. 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. 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. 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. 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. 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. 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. 9. Exemple dappli générique quonaimerait voir plus souvent (1)
  10. 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. 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

×