Présentation faites pour PyConFr.

Appuyez sur «Espace» pour passer à la diapo suivante.

Retour d'expérience sur TOMUSS

TOMUSS : The Online Multi User Simple Spreadsheet

Tableur web partagé temps réel pour la saisie des notes et le suivi des étudiants.

Pourquoi cet exposé

• Présenter des techniques peu classiques.
• Voir ce qui a bien fonctionné.
• Voir ce qui aurait put être fait autrement.

Contraintes de l'application

Tables utilisées un seul semestre.

Dizaines de colonnes, centaines de lignes.

Contraintes de l'application

• Facile à utiliser, mais néanmoins être innovante.
• Être simple à débugger et à faire évoluer.
• Consommer peu de ressources (nombreux étudiants).
• Evoluable sans casser les forks

Choix techniques

• Pas de framework car lourds et opaques.

  Mais je regrette JQuery

• Chargement des données en bloc dans le navigateur web.

  Mises à jours envoyées en temps réel.

  Fonctionnement hors ligne et interactivité

Plugin, plugin, plugin et plugin

Un coeur d'application minimaliste.

• Un élément affiché = un plugin.

• Rechargement dynamique des plugins.

• Droits d'accès, profilage...

• Plugins agnostiques.

Monkey Patching

Evite de patcher les sources pour les adapter.

• Ne pas faire de import *

• Ne pas patcher d'autres plugins (rechargement)

• Ne pas patcher de multiples fois la même fonction.

• Indiquer les endroits où il faut patcher.

<troll>Stockage sans BD</troll>

On a besoin d'une BD quand :

• Données volumineuses ou modifiées souvent.
• Accès concurrent en modification.
• Langage de requête riche.

Rien de ceci n'est utile à TOMUSS.

Données stockées comme des programmes Python

L'interprétation du fichier regénère les structures de données internes au serveur.

• Un fichier par table.

• Modification en mode append : historique

• Analysable et modifiable par un être humain et la machine.

• Transférable directement au navigateur web.

Données stockées comme des programmes Python (2)

Sauvegardes journalières avec GIT efficaces.

• 1.6 Go de données sur disque.
• 776 sauvegardes occupant 462 Mo.
• 90% des valeurs jamais modifiées.

Evolutions possibles sans casser les données

• Pas besoin de traduire les données en cas de changement.
• Structure de données internes libres.

Threads

Limiter l'utilisation des threads pour les :

• calculs longs (plutôt lancer un processus)
• interrogations de services distants, une thread par service.
• tâches périodiques

Passage d'information entre threads avec append et pop

De préférence utiliser un framework qui cache tout.

Backtrace envoyée par mail

Avec les variables qui ont une méthode backtrace_html

Analyse de la mémoire

Avoir des outils d'analyse de la mémoire utilisée pour détecter les fuites. objgraph pour afficher

Affichage de l'état du serveur

En temps réel : IPs, tickets, tables, actions, requêtes, verrous

Débuggage

Pouvoir exécuter du code dans le serveur en production.

Pouvoir savoir pour chaque élément HTML :

Si c'était à refaire

Certains choix auraient été meilleurs.

Mais je n'aurais pas eu une première version fonctionnelle rapidement.

Écrire le maximum de code en Python et le traduire en JavaScript.

Framework synchro Python/JS

Synchronisation des données transparentes entre clients et serveur, même classes.

Le rôle du serveur se limite à :

• Assurer la sécurité.
• Stocker les fragments Python dans les fichiers.
• Échanger ces fragments entre les clients.

Donc très léger.

Gestion des caches

Chaque processus TOMUSS gère ses caches.

• Pas de partage de cache entre processus.
• En cas de redémarrage, les caches sont à reremplir. Cela ralenti le développement.

Solution : utiliser memcached

Conclusion

Python permet de changer complètement une application de manière progressive.

Python peut permettre d'adapter une application à votre problème, sans avoir besoin de modifier les sources.

Python permet de patcher et débugger un serveur en production.

Le support de l'unicode est pénible en Python2.

Merci

Des questions ?