Le livre de

Présentation des intervenants

Allons à la rencontre de ces personnages et de leurs projets.

• Ned Batchelder est ingénieur en chef chez Tabblo.com. Tabblo à débuté comme outil de conte construit autour du partage de photographies, mais à été récemment racheté par Hewlett-Packard dans un objectif plus large:

  HP à perçu une réelle valeur dans notre style de développement web, et dans la façon dont nous avons reliés les mondes physiques et virtuels. Ils nous ont acquis de façons à ce que nous puissions apporter cette technologie à d’autre sites internet. Tabblo.com reste un grand site de conte, mais nous travaillons aussi à présent à la la modularisation et à l’amélioration des parties les plus intéressantes de notre technologie.

• Johannes Beigel est développeur principal chez Brainbot Technologies AG. Le principal site public de Brainbot sous Django est http://pediapress.com/, où vous pouvez commander des versions imprimées d’articles de Wikipédia. L’équipe de Johannes travail actuellement sur un programme de gestion des connaissances d’entreprises connu sous le nom de Brainfiler.

  Johannes nous explique que Brainfiler

  […] est une solution logicielle pour gérer, rechercher, catégoriser et partager l’information depuis des sources d’informations distribuées. Il est destiné à un usage en entreprise, à la fois pour l’intranet et l’internet, et est hautement évolutif et personnalisable. Le développement des concepts et des composants principaux à débuté en 2001. Nous avons récemment redessinés/réimplémentés le serveur d’application et l’interface web, [à présent] basée sur Django.

• David Cramer est développeur principal chez Curse, Inc. Il développe Curse.com, un site dédié aux jeux en lignes massivement multi-joueurs tel que World of Warcraft, Ultima Online, et bien d’autres.

  Curse.com est l’un des plus gros sites de l’internet qui soit déployé sous DJango:

  Nous avons environ 60-90 million de page vues par mois en moyenne, avec un pic de 130 millions de pages vues [en un mois], en utilisant Django. Nous avons un site web très dynamique, centré sur les utilisateurs qui sont des joueurs en ligne, plus spécialement des jeux massivement multijoueurs, et nous sommes l’un des plus grand site web dédié à World of Warcraft. Notre site web à démarré au début de l’année 2005, et depuis la fin 2006 nous avons accru notre portée au dela de World of Warcraft.

• Christian Hammond est ingénieur senior chez VMware (un développeur principal pour ce logiciel de virtualisation). Il est aussi développeur principal de Review Board (http://www.review-board.org/), un system de revue de code basé sur le web. Review Board à démarré comme projet interne à VMware, mais est à présent open source:

  Fin 2006, David Trowbridge et moi même discutions du procédé que nous avons utilisés chez VMware pour gérer les revues de code. Avant que les gens remontent le code vers le dépôt des sources, ils étaient supposés envoyer un diff des modifications sur une liste de diffusion pour qu’il soit revu. Tout cela était pris en charge par mail, et il devint difficile de garder une trace des révisions demandant votre attention. Nous avons commençer à discuter des solutions potentielles à ce problème.

  Plutôt que d’écrire mes idées, je les ai traduite en code. Rapidement, Rewiew Board était né. Review Board aide les développeurs, contributeurs et relecteurs à conserver la trace du code nécessitant un examen et à mieux communiquer entre eux. Au lieu de vaguement référencer une partie du code dans un courrier, le relecteur est capable de commenter directement le code. Le code, ainsi que les commentaires, apparaîtrons ensuite dans la revue, fournissant au développeur assez de contexte pour rapidement faire les changements nécessaires.

  Review Board grandit rapidement au sein de VMware. Plus rapidement que prévu, en fait. En quelques semaines, nous avions 10 équipes utilisant Review Board. Cependant, ce projet n’est pas interne à VMware. Il à été décidé dès le premier jour qu’il devait être open source et rendu disponible à l’usage de n’importe quelle compagnie ou projet.

  Nous avons fait l’annonce open source et le site ensemble, disponibles à l’adresse http://www.review-board.org/. La réponse à notre annonce publique fût aussi impréssionnante que l’annonce interne à VMware. Rapidement, notre serveur de démonstration a atteint plus de 600 utilisateurs, et les gens commençèrent à contribuer au projet.

  Review Board n’est pas le seul réviseur de code sur le marché, mais il est le premier à avoir été open source et à proposer l’ensemble des fonctionnalités sur lesquelles nous avons travaillés. Nous espérons qu’il fera gagner du temps à de nombreux projets open sources et commerciaux.

Pourquoi Django ?

Nous avons demandé à chaque développeur pourquoi il a décidé d’utiliser Django, quelles étaient les autres options envisagées, et comment la décision d’utiliser Django à finallement été faite.

Ned Batchelder:

Avant que je ne rejoigne Tabblo, Antonio Rodriguez (CTO et fondateur de Tabblo) fit une évaluation de Rails et de Django, et trouva que les deux fournissaient un bon environnement de développement prêt à l’emploi. En comparant les deux, il trouva que Django avait une plus grande profondeur technique qui rendrait plus facile la construction d’un site robuste et évolutif. De plus, les fondations Python de Django signifiait que nous allions avoir toute la richesse de l’écosystème Python pour supporter notre travail. Ceci à été définitivement prouvé lorsque nous avons construit Tabblo.

Johannes Beigel:

Comme nous codions en Python depuis maintenant de nombreuses années, et que nous avions rapidement commencés à utiliser le framework Twisted, Newow était la solution la plus «naturelle» pour nos histoires d’applications web. Mais nous avons rapidement réalisés — en dépit de la parfaite intégration de Twisted — que beaucoup de chose devenaient un peu lourdes et se plaçaient en travers de notre processus de développement agile.

Après quelques recherches sur internet il est rapidement devenu clair que Django était le framework de développement web le plus prometteur pour nos besoins.

Le déclencheur qui nous amena à Django fût sa syntaxe de gabarit, mais nous appréciâmes trés tôt toutes les autres fonctionnalités incluses, aussi Django se vendît de lui même.

Après quelques années de développement parallèle et de déploiement (Nevow est encore utilisé pour certains projets sur des sites clients), nous arrivons à la conclusion que Django est beaucoup moins lourd, produit du code qui est plus simple à maintenir, et que travailler avec est plus sympathique.

David Cramer:

J’ai entendu parler de Django à l’été 2006, à l’époque où nous étions prêt à faire une révision de Curse, nous avons donc fait quelques recherches à son sujet. Nous avons tous été impressionés par ce qu’il pouvait faire, et par le temps qu’il pouvait nous épargner. Nous en avons discutés, choisit Django, et commencer à écrire la troisième revision du site web quasiment immédiatement.

Christian Hammond:

J’ai joué avec Django sur une paire de petits projets et ai été très impressionné. Il est basé sur Python, dont je suis devenu un grand fan, et facilite non seulement le développement de sites et d’applications web, mais aussi leurs organisation et leurs maintenabilité. Ceci à toujours été laborieux en PHP et Perl. Sur la base des expériences passées, choisir Django était évident.

Prise en main

Puisque Django est un outil relativement nouveau, il n’y a pas beaucoup de développeurs experimentés. Nous avons demandé à notre «panel» comment il avait motivé leurs équipes et quels étaient les astuces qu’ils voulaient partager avec les développeurs Django débutants.

Johannes Beigel:

Après avoir codé principalement en C++ et en Perl, nous avons basculés en Python et continués à utiliser le C++ pour le code nécessitant d’intenses calculs.

[Nous avons appris Django] grâce au tutoriel, parcourant la documentation pour se faire une idée des possibilités (il est facile de passer à côté de beaucoup de fonctionnalité en lisant uniquement le tutoriel), et avons cherché à comprendre les concepts de bases dérrière le middleware, les objets Request, les modèles de données, les balises de gabarits, les filtres personnalisés, les formulaires, les permissions, la localisation… Nous [avons pu] ensuite creuser ces sujets lorsque [nous] en avions besoins.

David Cramer:

Le site web de documentation est super. Continuez comme cela.

Christian Hammond:

David et moi même avions déjà eu une expérience avec Django, bien quelle fût limitée. Nous avons beaucoup appris au travers du développement de Review Board. J’aimerais inciter les nouveaux utilisateurs à lire la documentation Django, bien écrite, ainsi [que le livre que vous lisez actuellement], tous deux nous ayant été précieux.

Nous n’avons pas eu à fournir de pot-de-vin pour obtenir cette citation — Juré !

Porter du code existant

Bien que Review Board et Tabblo étaient des développements naissants, les autres sites furent portés depuis du code existant. Nous étions intéressés de savoir comment ce processus s’est déroulé.

Johannes Beigel:

Nous avons commencés à «porter» le site de Nevow, mais avons rapidement réalisés que nous voulions modifier tant de concepts (à la fois dans l’interface utilisateur que dans la partie serveur d’applications) que nous avons tout repris depuis le début et utilisés l’ancien code principalement comme référence.

David Cramer:

Le site précédent était écrit en PHP. Passer de PHP à Python fut intéressant en terme de programmation. Le seul eccueil est que vous devez être beaucoup plus attentif à la gestion de la mémoire [puisque les processus restent actifs beaucoup plus longtemps qu’en PHP (où ils ont un cylce unique)].

Comment cela s’est-il passé ?

À présent la question à un million d’euros: Comment Django vous à traités ? Nous voulions plus particulièrement savoir où Django à échoué ? Il est important de savoir où sont les faiblesses de vos outils avant d’aller vers une impasse.

Ned Batchelder:

Django nous a permis d’expérimenter les fonctionnalités de notre site web. En tant que start-up recherchant à la fois la chaleur des clients et des affaires, et aujourd’hui faisant partie de HP et travaillant avec de nombreux partenaires, nous devons être très agiles lorsqu’il s’agit d’adpater le logiciel aux nouvelles demandes. La séparation des fonctionnalités en modèles, vues et controleurs nous à donné la modularité nécessaire au choix de l’endroit à étendre et modifier. L’environnement Python sous tendu nous offre l’opportunité d’utiliser des bibliothèques existantes afin de résoudre les problèmes sans avoir à réinventer la roue. PIL, PDFlib, ZSI, JSmin et BeautifulSoup ne sont qu’une poignée des bibliothèques que nous avons incorporées pour faire nos profonds changements.

La partie la plus difficile dans notre utilisationde Django furent les relations entre les objets mémoires et les objets base de données. Tout d’abord, l’ORM de Django ne permet pas de s’assurer que deux références à un même enregistrement de la base de données sont un seul et même objet Python, vous pouvez donc vous retrouver dans des situations où deux parties du code tentent toutes deux de modifier le même enregistrement, et qu’une des deux copies soit corrompue.

Ensuite, le modèle de développement de Django vous encourage à baser vos objets de données sur des objets de base de données. Nous avons trouvés au fil du temps de plus en plus d’utilité aux objets de données qui ne sont pas liés à la base de données, et nous avons du nous éloigner de l’idée que les données soient stockées dans la base de données.

Pour une grande base de code ayant une longue durée de vie, il fait certainement sens de passer du temps à anticiper les façons dont vos données seront stockées et accessibles, ainsi qu’à contruire des infrastructures à l’appui de ces moyens.

Nous avons aussi ajouter nos propres outils de migration des bases de données de façon à ce que les développeurs n’aient pas à appliquer de patchs SQL pour conserver leurs schémas de base de données à jour. Les développeurs qui changent le schéma écrivent une fonction Python pour mettre à jour la base de données, et celle-ci est apliquée automatiquement lorsque le serveur est lancé.

Johannes Beigel:

Nous considérons Django comme une plate-forme talentueuse qui correspond parfaitement à la façon de pensée en Python. Presque tout à fonctionné comme prévu.

Ce qui nous à demandé un peu de travail dans notre actuel projet fut de modifier le fichier global settings.py et la structure/configuration du répertoire (pour les applis, les gabarits, les données locales, etc.), parce que nous avons implémentés un système hautement modulaire et configurable, où toutes les vues Django sont en fait des méthodes de quelques instances de classes. Mais avec l’omnipotence du code Python dynamique, cela est resté faisable.

David Cramer:

Nous avons pu transférer nos grandes applications reposant sur des bases de données en un week-end. Cela aurait pris une à deux semaines avec le site web précédent, en PHP. Django à brillé exactement là où nous l’attendions.

Aujourd’hui, alors que Django est une grande plate-forme, nous ne pouvons pas dire qu’il réponde aux besoins de tout un chacun. Lors du lancement de notre site web sous Django, nous avons connu le mois de l’année le plus riche en trafic, sans pouvoir y répondre. Lors des mois suivants, nous avons modifiés des composants et des pièces, principalement matérielles et logicielles servant les requêtes Django. [Ceci inclu la modification de notre] configuration matérielle, l’optimisation de Django, [et la personnalisation] du logiciel que nous utilisions pour répondre aux requêtes (qui, à l’époque, était lighttpd et FastCGI).

En mai 2007, Blizzard (le créateur de World of Warcraft) à sorti un nouveau patch plutôt conséquent, comme ils l’avaient fait en décembre lors du premier lancement de Django. La première chose à nous traverser l’esprit fut, «Hey, nous avons presque tenu le coup en Décembre, c’est loin d’être aussi conséquent, nous devrions nous en sortir». Nous avons tenu prêt de 12 heures avant que les serveurs commencent à sentir la chaleur. La question était à nouveau posée: est-ce que Django était réellement la meilleure solution pour ce que nous voulions faire ?

Grâce au support conséquent de la communauté, et une nuit plus tard, nous avons pu implémenter plusieurs «rustines» sur le site web pendant ces quelques jours. Les changements (qui ont heureusement été intégrés à Django depuis que ce livre est paru) sont parvenus à rassurés, bien que tout le monde n’ai pas besoin de répondre à 300 requêtes par secondes, tous ceux qui doivent le faire et qui, avec Django, le peuvent.

Christian Hammond:

Django nous a permis de construire Review Board assez rapidement en nous forçant à rester organisés autours de ces URL, vues, et gabarits séparés, et en fournissant des composants natifs utiles, tel que l’application d’identification, le cache natif, et l’abstraction de la base de données. Presque tout à vraiment bien fonctionné pour nous.

Étant une [application web] dynamique, nous avons du écrire beaucoup de code Javascript. C’est un domaine ou Django ne nous à pas vraiment aidé. Les gabarits Django, les balises de gabarits, les filtres, et le support des formulaires sont bien, mais ne sont pas facilement utilisable depuis le code Javascript. Parfois, nous voulions utiliser un gabarit ou un filtre particulier sans pouvoir le faire depuis Javascript. J’aimerais personnellement voir quelques solutions créatives à cela incorporées à Django.

Structure de l’équipe

Souvent les projets qui réussissent sont le fait de leur équipe, pas de leur choix technologique. Nous avons demandé à notre panel comment leur équipe fonctionne, et quels sont les outils et techniques qu’ils utilisent pour rester en piste.

Ned Batchelder:

Nous avons l’environnement standard d’une start-up web: Trac/SVN, cinq développeurs. Nous avons un serveur de test, un serveur de production, le script de déploiement correspondant, et ainsi de suite.

Memcached assure.

Johannes Beigel:

Nous utilisons Trac pour son suivi de bugs et pour son wiki et sommes passés de Subversion + SVK à Mercurial (un système de contrôle de versions distribué en Python qui gère les branches/fusions comme un charme).

Je pense que nous avons un processus de développement très agile, mais que nous ne suivons pas une méthodologie «rigide» telle que la Programmation Extreme ([bien que] nous empruntions pas mal de ses idées). Nous sommes plutôt des programmeurs pragmatiques.

Nous avons un système de compilation automatisé (personnalisé mais basé sur SCons) et des tests unitaires pour presque tout.

David Cramer:

Notre équipe se compose de quatre développeurs web, travaillant tous dans le même bureau, il est donc facile de communiquer. Nous nous basons sur les outils courants telqs que SVN et Trac.

Christian Hammond:

Review Board à actuellement deux développeurs principaux (David Trowbridge et moi même) ainsi qu’une paire de contributeurs. Nous sommes héberger par Google Code et utilisons leur dépôt Subversion, leur suivi des bugs et leur wiki. Nous utilisons en fait Review Board pour réviser nos changements avant de les envoyer. Nous testons sur nos machines locales, à la fois à la main et grâce à des tests unitaires. Nos utilisateurs chez VMware qui utilisent Review Board chaque jour fournissent beaucoup de retour d’expérience et de remontée de bugs très utiles, que nous essayons d’incorporer au programme.

Déploiement

Les développerus Django prennent la facilité de développement et l’aspect évolutif très au sérieux, nous sommes donc très intéressés d’entendre les essais et tribulations du monde réel.

Ned Batchelder:

Nous avons utilisés le cache à la fois pour les requêtes et les réponses afin d’accélerer le temp de réponse. Nous avons une configuration classique: un multiplexeur, plusieurs serveurs d’applis, un serveur de base de données. Ceci a bien fonctionné pour nous, parce que nous pouvons utiliser le cache sur le serveur d’application pour éviter les accès à la base de données, puis ensuite ajouter des serveurs d’applis selon les besoins pour gérer le volume.

Johannes Beigel:

Des serveurs Linux, de préférence Debian, avec beaucoup de RAM. Lighttpd pour le serveur web, Pounds pour le frontal HTTPS et la répartition de charge si besoin, et Memcached pour la mise en cache. SQLite pour les petites bases de données, PostgreSQL si les données viennent à grandir, et des bases de données personnalisées et hautement spécialisées pour nos composants de recherche et de gestion de connaissance.

David Cramer:

Notre structure est toujours ouverte au débat [mais voici ce qui est actuellement]:

Lorsqu’un utilisateur fait une requête sur le site il est dirigé vers une grappe de serveur Squid utilisant lighttpd. Ici, les serveurs vérifient si l’utilisateur est identifié. S’il ne l’est pas , une page provenant du cache est servie. Un utilisateur identifié est dirigé vers une grappe de serveurs web supportant Apache2 plus mod_python (chacun ayant une grosse quantité de mémoire), chacun etant reliés à un système Memcached distribué et à un serveur de base de données MySQL monstrueux. Le contenu statique est hébergé sur une grappe de serveurs lighttpd. Les médias, comme les gros fichiers et les vidéos, sont hébergés (actuellement) sur un serveur utilisant une installation Django minimale à base de lighttpd plus fastcgi. À présent nous sommes en train de migrer le service de tous les médias vers un service similaire à Amazon S3.

Christian Hammond:

Il y a actuellement deux serveurs de production principaux. L’un est chez VMware est se constitue d’une machine virtuelle Ubuntu tournant sur VMware ESX. Nous utilisons MySQL pour la base de données, Memcached pour la mise en cache, et actuellement Apache pour le serveur web. Nous avons plusieurs serveur puissants que nous pouvons adapter selon nos besoins. Nous pourrions avoir à déplacer MySQL ou Memcached vers une autre machine virtuelle selon que notre base d’utilisateurs augmente.

Le second serveur de production est celui de Review Borad lui-même. La configuration est assez proche de celui chez VMware, à part la machine virtuelle qui est hébergée sur un serveur VMware.

<< précédent ◊ suivant >>