Technique

lundi 23 août 2010

Mise en ligne des nouveautés du SdZ avec Capistrano

Par Vincent Primault le lundi 23 août 2010, 16h40

Note de Mathieu : comme nous l'avons signalé à toutes les personnes qui travaillent chez Simple IT, nous leur proposons d'intervenir de temps en temps sur le blog pour présenter les projets sur lesquels ils travaillent. Le but est de varier les sujets et les styles d'écriture en donnant la parole aux employés. Vincent Primault (alias vincent1870), développeur sur le Site du Zéro, est le premier à rédiger un tel billet. Vous le trouverez ci-dessous.

Depuis un an et le billet annonçant la fin du bricolage, de nombreuses choses ont encore évolué sur notre façon de travailler en interne. Ce billet est là pour présenter aux curieux les rouages de notre nouvelle méthodologie de développement, qui se veut plus professionnelle et adaptée à la taille grandissante de Simple IT et du code du site.

Retour sur les faits

Pour rappel, le site est depuis le début de l'année en plein chamboulement puisque nous sommes en train de porter tout le code vers le framework web symfony (dans sa version 1.4). Cette décision n'a pas été prise à la légère et permet d'assurer à terme plus de flexibilité dans le code et d'accélérer le développement de nouveaux modules en utilisant toute la batterie d'outils que symfony met à notre disposition.

Cette démarche de rationalisation du développement ne se résume cependant pas à l'adoption de symfony. Depuis le début de l'été, nous n'avons pas chômé, et plusieurs réflexions importantes ont été commencées concernant la façon même dont nous développons et les processus entourant l'écriture. Le reste de ce billet va traiter de la nouvelle organisation mise en place concernant la mise en ligne des nouveautés sur le Site du Zéro.

Git c'est bien

Comme vous le savez sans doute si vous avez lu les billets précédents, le code source du Site du Zéro est versionné via le logiciel Git. Cet outil indispensable pour nous permet de conserver une trace de toutes les modifications apportées au code du site, quand et par qui. L'outil est actuellement bien exploité, nous utilisons notamment beaucoup le système de branches qui nous permet de cloisonner nos développements et de pouvoir changer rapidement de sujet de travail sans rien perdre.

Si je parle de Git c'est qu'on l'utilise en fait actuellement presque trop, en sortant de ses attributions d'origine. C'est en effet lui qui nous permet actuellement de réaliser nos déploiements. Pour rappel, le déploiement est l'action consistant à faire passer du code de la machine d'un développeur vers le serveur de production, Lisa, qui dessert les pages que vous voyez tous les jours. Une fois le code déployé, tous les visiteurs y ont accès, c'est donc une étape essentielle ! Utiliser Git pour cela est très simple et rapide : il suffit de créer une copie du dépôt sur le serveur de production, de lancer la mise à jour des sources et tout est en ligne quasi-instantanément. Si cet usage est courant, il atteint cependant assez vite ses limites, comme nous nous en sommes rendu compte nous-mêmes.

En effet, depuis la mise en place de symfony, la procédure de mise en production a commencé à s'alourdir . Tout d'abord, il a fallu systématiquement nettoyer le cache de symfony en lançant une commande à l'issue de la mise à jour des sources. Cela peut sembler anodin, mais cela faisait une tâche de plus à la charge du développeur. Et il suffit de l'oublier pour que nos changements soient alors non fonctionnels, et qu'on perde alors du temps à trouver d'où vient le problème (c'est du vécu !).

Les problèmes ont continué lorsque récemment nous avons lancé le projet d'exploiter enfin correctement l'ORM fourni avec symfony (Doctrine) en utilisant ses migrations. En deux mots, c'est un outil très pratique permettant d'automatiser les modifications sur la base de données telles que l'ajout de colonnes ou de tables, avec des facilités telles l'annulation des modifications simplement. Cependant cela fait encore quelques commandes de plus à lancer à chaque déploiement, et ce sur la version de développement et de production. La démarche commençait alors à s'alourdir considérablement, nous avons donc cherché du côté d'outils permettant d'industrialiser ces manœuvres.

Capistrano c'est mieux

Je m'intéressais à ce type d'outils depuis un moment, et je lorgnais déjà de fait sur un outil bien précis, répondant au doux nom de Capistrano. Ces outils ne sont pas très nombreux, et ceux matures le sont encore moins. Capistrano est un outil codé en Ruby et assez réputé dans le domaine. Pour l'anecdote il est notamment utilisé par Twitter pour ses déploiements.

Il faut savoir que Capistrano n'est pas réellement un outil de déploiement, mais que ce n'est en fait qu'un outil de réplication de commandes sur un parc de serveurs. Pour l'instant nous n'avons qu'un serveur web de production, mais cela tombe bien car le jour où nous en aurons plus (ce qui arrivera fatalement un jour ou l'autre pour parer au trafic croissant du Site du Zéro) nous serons déjà prêts ! Actuellement nous nous en servons donc "juste" pour exécuter un jeu de commandes à la chaine.

Il est conçu à l'origine pour déployer des projets Ruby on Rails (un framework de développement web codé en Ruby) mais s'adapte très facilement à d'autres projets. Nous avons pour notre part largement repris la base fournie par le projet Capifony qui était une extension de Capistrano à des projets symfony. Adapter Capistrano nécessite juste de connaitre un peu le Ruby, mais cela se fait très bien. Pour tout dire je n'avais jamais touché au Ruby avant de devoir personnaliser Capistrano, et cela s'est très bien passé, les outils de base couplés à Capifony se laissent facilement prendre en main. Je regrette juste que le site de Capistrano soit un peu anarchique et qu'on ait du mal à trouver ce que l'on cherche.

Lors de ses déploiements, Capistrano conserve un historique de toutes les releases du produit. Cela permet par exemple de pouvoir revenir à une version antérieure de façon instantanée. Il gère également des ressources partagées entre toutes les versions, telles que des fichiers de configuration ou des uploads. Le déploiement en lui-même se fait de façon très simple en lançant une simple commande en console. Pour les curieux, cela donne en pratique une arborescence similaire à ce qui suit sur le serveur de production :

current
releases
- 20100820090035
- 20100822090214
shared
- config/databases.yml
- web/uploads
- log

Chaque sous-dossier dans le répertoire releases contient une extraction du code source de Git à une date donnée (indiquée par le nom du répertoire). current est en fait un simple lien pointant vers la dernière version (c'est pour ça que revenir en arrière est très simple, il suffit de changer le lien !). Enfin shared contient toutes les données partagées, avec par exemple les fichiers de configuration symfony, les uploads ou les logs.

Le serveur web va chercher le site dans current. Comme il s'agit d'un lien symbolique, il utilise en fait le code source de la release sur laquelle il pointe.

Et avec Webistrano...

Pour nous combler pleinement, nous voulions un outil capable d'enregistrer un détail de l'activité de déploiement et capable d'agir différemment en fonction de l'environnement ciblé. Capistrano à la base est flexible à volonté, mais ne permet pas forcément d'organiser son code de façon très propre, et réaliser une personnalisation en fonction de l'environnement ciblé aurait été assez compliqué à gérer pour quelqu'un qui ne connaissait que très peu le Ruby comme moi.

Une solution s'est alors naturellement imposée : Webistrano. C'est en fait une simple interface web (codée en Ruby on Rails) pour Capistrano. Les avantages sont alors multiples :

La configuration de l'outil se fait de façon très agréable. Cela ne dispense absolument pas de connaitre le fonctionnement de Capistrano mais c'est bien plus visuel que la version en Ruby.
L'outil gère de façon native la différenciation des environnements de déploiement (par exemple pour nous ceux de pré-production et celui de production).
Le code de personnalisation est bien mieux organisé, on a la possibilité de partager des bouts de code à travers les projets et les environnements.
Le déploiement se fait de façon graphique, on récupère les logs en temps réel.
Chaque déploiement est enregistré, on en garde une trace, et on peut très facilement revenir en arrière si quelque chose se passe mal.
Capistrano est exécuté sur le serveur hébergeant Webistrano, ce qui permet d'éviter à chaque développeur d'installer et configurer Capistrano en local. Tout est centralisé et partagé.

L'outil s'est jusqu'ici remarquablement bien comporté, s'avérant très ergonomique et surtout accélérant le temps passé à configurer Capistrano. Nous avons juste eu à le modifier très légèrement pour nos besoins, mais de façon très mineure (c'était principalement de l'adaptation pour symfony et un peu de personnalisation visuelle).

Une nouvelle rigueur dans le processus de développement

Tout cela nous amène à avoir une nouvelle rigueur dans le processus de déploiement. Actuellement l'intégration en production se fait tout au long de la journée par les développeurs. Ce processus devient peu gérable, les déploiements devant être planifiés. Nous allons donc progressivement tendre vers une rationalisation des déploiements, qui seront faits environ une fois par jour, à heure fixe, tout en gardant une certaine souplesse dans le cas d'une réelle urgence comme une correction de faille.

De plus, les environnements sont maintenant différenciés plus fortement. Nous exploitons un trio classique d'environnements :

La version de développement du site, qui est notre version locale. Chaque développeur travaille avec sa version du code et sa base de données. C'est sur cette version que les nouvelles fonctionnalités sont implémentées.
La version de pré-production du site (aussi appelée de recette) qui est une copie du site en ligne (hébergée sur les serveurs de Simple IT mais non accessible au public). Elle se comporte de façon identique en tout point à la production. Cela nous permet de prévenir au maximum les risques lors du moment fatidique.
La version de production, accessible à tous à l'adresse http://www.siteduzero.com, est le produit fini.

C'est une évolution de plus dans nos processus internes, et certainement pas la dernière. L'objectif est réellement d'automatiser au maximum de façon à décharger les développeurs des tâches répétitives. D'autres réflexions sur des sujets similaires sont dans les tuyaux, vous en saurez plus prochainement !

21 commentaires

jeudi 18 février 2010

En route vers le SdZv4

Par Mathieu Nebra le jeudi 18 février 2010, 17h33

Le Site du Zéro a maintenant 10 ans. Les choses ont beaucoup évolué depuis 1999 sur le Web : on ne conçoit plus du tout des sites web de la même manière. J'ai eu la chance d'observer cette évolution au fil des années et d'en faire profiter progressivement le Site du Zéro.

Que de changements entre la toute première version en HTML 4 lancée un après-midi alors au collège, et l'actuelle version 3 qui sert de base à un site fréquenté par 2 millions de visiteurs uniques par mois ! L'évolution majeure du site, comme certains d'entre vous le savent sûrement, est arrivée avec cette fameuse "v3" qui a été développée en grande partie par Pierre Dubuc (karamilo) aujourd'hui mon associé, ainsi que d'autres personnes qui y ont participé de près ou de loin et qu'on n'oublie pas : winzou, Duael, IAN, Venom, zaz et bien d'autres.

Depuis le lancement de la version 3 en novembre 2005 (lors d'un après-midi pluvieux depuis un appartement miteux à Londres), le site n'a jamais cessé d'évoluer bien au contraire. Les modules du site se sont sans cesse développés, ont été améliorés, transformés, et il en est allé de même pour le design du site. Ce sont pour la plupart des évolutions réalisées par une poignée de bénévoles courageux (que nous ne remercierons jamais assez) mais aussi depuis 2 ans par les développeurs en stage chez Simple IT ainsi que par Romain qui est notre premier développeur salarié depuis fin novembre 2009.

Bref, comme vous le voyez, tout ceci a une longue histoire et les choses se sont accélérées pour nous récemment. A tel point qu'il y a généralement 2 à 3 développeurs en continu sur le site (ce qui reste très inférieur à nos besoins, mais cela va évoluer). Or, le travail en commun avec différentes façons de développer finit par montrer progressivement ses limites.

Le SdZ-framework de la v3

C'est Pierre qui a posé les bases du framework actuel dès 2003 (le lancement de la v3 ayant pris 2 ans à l'époque). Sa structure MVC et sa conception intelligente qui se focalise sur les performances ont permis au site de supporter l'évolution fulgurante du site ces dernières années. Nous sommes en effet passés de 3-4000 visiteurs / jour à 70 000 visiteurs / jour, toujours avec le même framework de base. Parvenir à supporter 2 millions de visiteurs par mois avec seulement 2 serveurs en pratique (un frontal web et un sql) tient parfois du miracle, mais c'est pourtant ce que nous faisons.

Or, le monde du Web a évolué rapidement et on entend parler notamment des framework RAD (Rapid Application Development) que sont :

Ruby on Rails (un des pionniers)
Django
Symfony
CakePHP
etc.

Ces frameworks font la même chose que notre framework actuel : ils gèrent toute la base du site et délèguent les tâches spécifiques à des modules. Ils ont comme particularité d'être plus lourds et plus lents en général car ils rajoutent plusieurs couches d'abstraction, ce qui fait qu'on peut dire sans prendre trop de risques que le sdzframework est pour nous le plus rapide. Normal, il est spécifiquement adapté au SdZ.

Cependant, tous ces frameworks ont aussi de nombreux points forts pour lesquels le sdz-framework a clairement un train de retard. Parmi eux, les bonnes pratiques de développement tels que les tests unitaires et fonctionnels, des outils avancés de débuggage, des systèmes relationnel-objet (ORM), des systèmes de migration de données, de tâches, l'intégration native d'outils Javascript et AJAX, etc.

Si nous avons implémenté progressivement une partie de ces choses-là au fil du temps, le tout manque de cohérence par rapport aux frameworks connus. Il faut aussi compter le temps de formation des nouveaux stagiaires et employés à notre framework qui n'est pas toujours évident à comprendre au début. Et, bien que ce ne soit pas un prérequis, notre framework actuel n'est pas orienté objet et ne peut pas bénéficier de fonctionnalités telle que l'héritage (je rappelle que la v3 a été développée à l'époque de PHP 4, donc toute POO était exclue).

Evoluer vers une v4 pour plus de clarté

Nous ne fonçons pas forcément dans un mur avec la v3 maintenant, mais il est clair que si un jour nous arrivons à une dizaine de développeurs dans nos locaux voire plus (ce qui est probable), il risque d'être un peu tard pour se rendre compte que nos outils deviennent trop limités ou trop délicats à maintenir.

Nous avons donc entamé il y a quelques mois un début de réflexion autour de la possibilité de faire évoluer le site et de le porter sous un framework connu. Les intérêts de passer à ce type de framework open-source sont nombreux :

Il ne sera plus nécessaire de maintenir les fonctionnalités de base du site (système de sessions, de comptes, de cache, de requêtes ajax) et on pourra se concentrer sur ce qui est spécifique au site et donc faire évoluer plus rapidement le site.
Le framework étant connu et particulièrement documenté, nous n'aurons pas à maintenir de documentation propre au framework.
Par conséquent, la durée de formation des nouveaux développeurs sera réduite et nous pourrons annoncer dans nos offres de stage / emploi qu'il est nécessaire de connaître Symfony.
On disposera d'outils puissants pour retracer les erreurs et même les anticiper, ce qui limitera considérablement les risques de régression.

L'idée centrale est de se concentrer sur ce qu'on appelle le métier, c'est-à-dire sur ce qui est propre au site, tout en se reposant sur une architecture solide en laquelle nous avons confiance.

Quand vous décorez l'intérieur de votre maison, vous n'avez pas besoin de penser à la charge que doivent supporter les murs porteurs ou à la meilleure façon de plâtrer du béton ? Eh bien avec un site web, c'est exactement la même chose. On préfère passer du temps à aménager l'intérieur plutôt qu'à se préoccuper de choses qui ne sont pas notre métier. ;o)

Pourquoi Symfony ?

Les frameworks de qualité sont nombreux, j'en ai cité quelques-uns plus haut. Il fallait faire un choix là-dedans, en considérant :

La "facilité" de migration (toute relative car ça reste complexe)
La communauté et la pérennité du projet
Son caractère open-source, un élément indispensable à nos yeux pour pouvoir "hacker" le framework au besoin et probablement proposer des retours pour l'améliorer.

Les frameworks tels que Ruby on Rails et Django ont donc été exclus d'office, car ils sont basés sur d'autres langages (Ruby et Python) ce qui aurait demandé une charge de travail beaucoup trop importante.

Parmi les frameworks PHP, c'est Symfony que nous avons retenu pour la qualité de sa documentation, son tutoriel Jobeet (et nous on aime ça les bons tutos !), sa pérennité (le projet est activement développé et maintenu) et ses références (Dailymotion est en train de passer à Symfony, forcément ça motive et ça encourage !).

La (très) délicate migration

Il ne suffit pas d'avoir la volonté, il faut encore s'organiser. A ce titre, j'ai eu la chance de rencontrer le génial vincent1870 (pardon pour tes chevilles vincent) qui est un des principaux développeurs du site des zCorrecteurs. Il se trouve qu'il s'intéresse beaucoup à Symfony et qu'il a depuis quelques temps une bonne vue d'ensemble du sdzframework. Il a ces derniers temps fait un travail remarquable pour adapter Symfony à nos besoins, trouver une méthode de migration réaliste et progressive et documenter cette méthode. Depuis peu, Romain l'a rejoint pour l'aider à adapter certaines sections spécifiques tels que les crons.

Beaucoup de choses ont déjà été faites sur une branche Git de développement du site. A l'heure actuelle, nous arrivons à poser les premières bases de Symfony et à le coupler au sdzframework. En effet, il est inconcevable de geler le développement du site pendant qu'on le porte vers Symfony (ce qui représente beaucoup de travail). Nous allons donc le faire module par module, progressivement, en gelant les modules un à un.

La migration vers Symfony prendra forcément du temps, on l'estime entre 8 et 12 mois, ce qui est conséquent. Nous pensons mettre en production les premières bases vers la fin de ce mois-ci. Le SdZ semblera être exactement le même, si ce n'est que c'est Symfony qui traitera la requête et qui la routera soit vers l'ancien framework si le module n'a pas été porté, soit vers Symfony lui-même si celui-ci a été porté. Un des premiers modules à être porté devrait être le livre d'or (choisi en raison de son extrême simplicité :-° ).

Quels changements ?

Pour les visiteurs, il n'y aura aucun changement au début (à part peut-être quelques curieux bugs de temps en temps, on ne pourra pas y échapper ^^ ). A terme, ils verront de nouvelles fonctionnalités plus régulièrement, le tout sera plus cohérent et il y aura moins de bugs.

Pour les développeurs, le changement sera énorme au niveau de la structure du code. A terme, le développement du site devrait être beaucoup plus rapide, beaucoup plus facile et beaucoup plus sûr. Mais nous n'en sommes pas encore là. ;o)

65 commentaires un rétrolien

vendredi 11 décembre 2009

Crash test : les nouveaux emballages du Livre du Zéro

Par Mathieu Nebra le vendredi 11 décembre 2009, 17h32

Comme vous le savez peut-être, ce sont pas moins de 1700 Livres du Zéro "Apprenez à programmer en C" qui ont été vendus durant les 2 semaines de précommande en novembre sur le Site du Zéro. A peu près autant de colis sont partis aux 4 coins de la France et du Monde et tout s'est très bien passé dans l'ensemble.

Cependant, alors que tout se passait très bien (et même mieux que prévu), nous avons eu une petite surprise désagréable : certains des livres sont arrivés légèrement écornés.

Pour comprendre notre démarche et pourquoi les choses se sont déroulées ainsi, je pense qu'un bref récapitulatif de nos préparatifs s'impose.

Ce qui s'est passé

Entre la théorie et la pratique, le réveil est parfois douloureux.

La théorie

Plusieurs semaines avant la finalisation du Livre du Zéro, nous sommes partis à la recherche d'un prestataire spécialisé dans les emballages carton. En l'occurrence il s'agit de Raja, un spécialiste bien connu de l'emballage.

Nous avons recherché l'emballage qui nous semblait le plus adapté au format du livre, qui l'englobe bien pour les envois unitaires. Puis, nous avons fait un test consistant à envoyer quelques livres avec cet emballage depuis l'imprimeur basé à Aurillac jusqu'à nos bureaux à Bourg-la-Reine près de Paris.

Tous les livres étaient arrivés en excellent état. Pas une rayure, rien. Nous étions donc satisfaits du choix de l'emballage.

La pratique

Malheureusement, lors de l'envoi de masse le jour J (près de 1700 colis !) nous avons eu la désagréable impression qu'une petite part des livres (quelques %) ont été reçus légèrement abîmés dans certains coins. Pas tous les livres hein (en fait ceux que nous avons vraiment dû renvoyer se comptent sur les doigts de la main), mais ce nombre était suffisant pour éveiller notre attention et déclencher rapidement une série de discussions en interne chez nous pour analyser ce qui s'était passé.

Nous étions verts. Nous avions pris, du moins le pensions-nous, toutes les précautions nécessaires. Nous avions fait des tests et choisi un emballage prévu explicitement pour le transport de livres.

Nous avons en fait découvert à quel point les colis pouvaient être maltraités lors de leur transport par la Poste. Pas tous, bien sûr, mais les nombreux colis qui transitent chaque jour par les centres de tri postaux ne sont pas manipulés avec des gants, c'est le moins qu'on puisse dire.

La solution

Puisque l'emballage se révèle en pratique mal adapté aux conditions de transport, nous nous sommes penchés sur d'autres colis pour livres. Nous sommes allés chercher ce qui se fait de mieux chez Raja et notre interlocuteur nous a confirmé que c'était le "Nec plus ultra" des emballages de livres. Evidemment, il est aussi "ultra plus cher", mais il fallait s'y attendre. Nous préférons néanmoins rogner sur notre marge mais savoir que les gens reçoivent leurs colis en très bon état et qu'ils sont satisfaits. Tout le monde y gagne au final, puisqu'on se doute bien qu'une personne satisfaite est plus susceptible de commander une seconde fois. ;o)

Trêve de bavardages, voici à quoi ressemble le nouvel emballage :

Le livre dans le nouvel emballage (avant de le fermer)

Il dispose d'une bande autocollante très pratique qui va nous dispenser du gros scotch actuel. C'était solide mais pas franchement esthétique.
Une fois refermé, on voit que c'est un beau colis (aussi beau qu'on puisse trouver un bout de carton esthétique du moins) :

Le nouvel emballage une fois refermé

C'est plus flagrant quand on le compare avec l'ancien colis côte à côte :

Le nouvel et l'ancien emballage

CRASH TEST !!§!§!

Avoir un bel emballage, c'est bien ; avoir un emballage résistant, c'est mieux.

Nous avons voulu tester en conditions réelles ce qui arrive à nos pauvres Livres du Zéro lors de leur transport. Pour vous, les Professeurs Mateo et Karamilo ont donc maltraité 2 colis : le nouveau et l'ancien. Le but de cette joyeuse partie de défonçage de carton était de constater la différence d'état des livres au final.

Les dommages

En bons scientifiques que nous sommes, nous avons fait subir exactement les mêmes supplices aux deux emballages. Nous les avons fait tomber d'une bonne hauteur (la nôtre) sur les coins, précisément là où ça fait mal.

Avant la chute

Pendant la chute

Comment ça "y'a un trucage on voit les fils" ? Ah parce que c'est pas suffisant ? On a même fait une vidéo pour montrer ce qu'on leur a fait subir, et comme vous pouvez le voir on les a pas ménagés !

Crash test des emballages du Livre du Zéro
par siteduzero

Attention : certaines images violentes sont susceptibles de choquer la sensibilité des plus jeunes. :-°

Le verdict : cartons

Le résultat ? Le voici. :)

Tout d'abord, l'état des cartons à la sortie de l'expérience. Comme on le voit bien, les coins ont particulièrement pris des dommages :

Le nouvel emballage endommagé

L'ancien emballage endommagé

Le verdict : livre ancien emballage

Les photos sont sans appel : le livre a pris très cher dans l'ancien emballage, preuve que nous n'y sommes pas allés de main morte.

Le livre à la sortie de l'ancien emballage (1)

Le livre à la sortie de l'ancien emballage (2)

Le livre à la sortie de l'ancien emballage (3)

Heureusement personne n'avait reçu de livre dans cet état-là, à une ou deux exceptions près sur 1700.

Le verdict : livre nouvel emballage

Le livre à la sortie du nouvel emballage (1)

Le livre à la sortie du nouvel emballage (2)

Le livre à la sortie du nouvel emballage (3)

Conclusion de l'expérience

Nous avions certes pris le meilleur emballage qui nous était proposé mais nous ne pouvions pas être certains qu'il convienne avant de faire cette expérience. Maintenant nous le savons et nous en sommes sûrs : c'est THE carton qu'il nous faut.

Cette photo résume bien la différence d'état des deux livres :

Comparaison des 2 livres à l'issue des tests

Malgré tous les chocs que nous avons fait subir aux livres, celui dans le nouvel emballage (au second plan) n'est pas endommagé à part un léger accrochage dans le coin qu'on voit dû à la violence des chocs. En revanche, le livre avec l'ancien emballage est effectivement... défoncé. :-°

Nous allons passer commande des nouveaux cartons dans les jours qui viennent. Nous devons écouler le stock d'anciens cartons auparavant (il n'en reste que quelques petites centaines aux dernières nouvelles), mais rassurez-vous, dès les premières alertes de livres endommagés nous avons demandé à l'imprimeur de rajouter du papier à bulles autour du livre. Tous les nouveaux livres arrivent donc en bon état, mais le coût du rajout du papier à bulles n'est pas nul (cela prend notamment plus de temps).

Le nouveau carton remplacera définitivement le précédent début 2010 pour les envois du livre de C... et pour tous les prochains. ;o)

32 commentaires

vendredi 12 juin 2009

Des images dans un flux RSS sur Netvibes

Par Mathieu Nebra le vendredi 12 juin 2009, 14h58

flux
rss

J'ai récemment découvert qu'il était possible d'associer une image à son flux RSS. En fait, pour ceux qui utilisent Netvibes, si vous cochez l'option Affichage détaillé pour le flux vous devriez voir une image devant chaque entrée.

Problème : par défaut, Netvibes (et je soupçonne qu'il n'est pas le seul à agir comme cela) va chercher la première image de la page et l'utilisera pour illustrer l'élément. Ce qui donne quelque chose comme :

Si la page ne contient pas d'image, aucune image n'est associée. Si la première image est un smiley, c'est le smiley qui s'affiche. Plutôt moche.

Pour associer l'image que l'on désire à un élément du flux, il suffit d'ajouter la balise <enclosure /> à l'élément <item> correspondant :

<enclosure url="http://www.siteduzero.com/uploads/fr/nws/big/32001_33000/32483.png" type="image/png" />

On l'a fait récemment pour les news (et il y a tout juste quelques minutes pour les tutos), ça nous permet maintenant d'associer l'icône de la news dans le flux :

Ca a une meilleure tête non ? :)

Bien entendu, il faut que l'utilisateur active l'affichage détaillé (ou utilise un autre lecteur de flux qui utilise le même principe).

L'avantage d'un tel affichage, mis à part l'aspect graphique, est l'affordance au clic. Un élément contenant une image est plus "tentant" à cliquer qu'un simple texte. C'est notamment une des raisons qui m'avaient motivées à associer une image à chaque news lors du passage à New Wave, afin d'encourager un maximum les visiteurs à lire les news.

10 commentaires

mercredi 27 mai 2009

Quelques avantages et défauts de Git

Par Mathieu Nebra le mercredi 27 mai 2009, 16h15

Voilà plusieurs semaines que nous sommes passés de SVN à Git au bureau et j'ai pensé qu'un petit point ici serait bien. En effet, j'ai remarqué qu'un certain nombre de développeurs avaient tendance à nous imiter : si on utilise telle bibliothèque, je découvre quelques semaines plus tard par hasard qu'elle suscite un intérêt soudain chez un certain nombre de visiteurs du site. De la même manière, j'ai appris récemment qu'il était probable que le site des zCorrecteurs passe à Git (attention, c'est une rumeur, je ne sais pas s'ils le feront ;o).

Cela réussit toutefois à m'inquiéter car, si je suis flatté de voir que l'on serve d'exemple pour certaines personnes, il ne faut pas le faire aveuglément. Aucun de nos choix n'est parfait, et il faut bien mesurer les conséquences de son acte avant de changer quelque chose d'aussi important qu'un système de versionnement.

Je voudrais donc ici apporter un oeil critique sur Git. Je souhaite mettre en exergue à la fois les points positifs et les points négatifs que l'on en retire. Bien entendu, tout ceci est extrêmement subjectif. Je sais que Git n'a pas été prévu pour fonctionner comme ceci ou comme cela, mais on en fait un usage bien particulier et je tiens à dire les avantages et défauts sur lesquels on est tombés.

Avantages

Le premier avantage, qui a été la première raison de notre migration, c'est sa gestion des branches. On peut enfin travailler sur plusieurs projets en parallèle sans se marcher sur les pieds. Nous avons donc commencé à utiliser intensivement cette fonctionnalité, et une fois qu'on a compris le fonctionnement c'est un vrai régal. C'est simple, ça marche, et on n'a pas à copier tout le projet comme avec SVN pour créer une branche.
L'interface console un poil plus évoluée que SVN. Ce sont des choses toutes simples, comme le fait qu'il fasse un "less" pour paginer automatiquement lorsqu'on affiche le log des commits. Ou la couleur, plutôt agréable, qu'il faut néanmoins activer au préalable.
Les algorithmes de fusion (merge) : quand un fichier a été modifié par plusieurs personnes en même temps, Git sait s'adapter et choisir un algorithme qui fusionne intelligemment les lignes du fichier qui ont été modifiées. Si par hasard 2 personnes ont modifié en même temps la même ligne (cas rare, mais qui arrive), il y a un conflit et Git laisse des marques dans le fichier pour dire qui a modifié quoi, et vous invite à décider ce que vous gardez.
La rapidité : lorsque vous vous mettez à jour, les données sont empaquetées, compressées, et les mises à jour sont fusionnées à la vitesse de la lumière, même s'il y a eu de très nombreuses modifications depuis la dernière fois. Cette rapidité m'étonne réellement à chaque fois.
Contrairement à SVN, Git ne surveille pas les fichiers mais leur contenu. Cela permet de faire des choses qui auraient été impossibles autrement, comme savoir qu'une fonction a été déplacée d'un fichier à un autre.

Défauts

La complexité : quoiqu'on en dise, ce n'est pas un outil à mettre entre les mains de n'importe qui. C'est fait par des développeurs pour des développeurs. SVN est vraiment facile à utiliser à côté. Cette impression est renforcée par le fait que les commandes ne sont pas intuitives. La même commande semble servir pour 2 choses très différentes (je pense à checkout, qui permet de changer de branche et de remettre à jour un fichier depuis le dernier commit). D'un point de vue du développeur, je suis persuadé que c'était logique et même élégant. Du point de vue de l'utilisateur, c'est une aberration. Voilà ce qui me fait dire que Git se soucie assez peu de la difficulté de prise en main. Il y avait une surcouche qui simplifiait un peu l'utilisation, mais je crois qu'elle a été abandonnée.
Le portage sous Windows est plutôt nul. Il faut utiliser cygwin. Heureusement, le projet msysgit permet d'avoir un installeur tout-en-un, mais je rencontre personnellement quelques difficultés : parfois, il ne veut plus se connecter au serveur par SSH, et ce sans raison apparente. Plus moyen de faire un pull... à moins de réinstaller msysgit. De plus, l'interface console n'est pas courante sous Windows. On est loin d'un TortoiseSVN par exemple. Certes, il existe TortoiseGit, mais il nécessite msysgit pour fonctionner. Enfin, les merges sont sensiblement plus lents sous Windows quand même.
Les retours à la ligne ont intérêt à être tous du même type (\n par exemple). En effet, si l'un de vos développeurs travaille avec un éditeur sous Windows qui est configuré pour créer des \r\n comme retours à la ligne, toutes les lignes d'un fichier seront considérées comme changées lorsqu'il l'éditera... d'où de nombreux conflits de merge. Là encore, c'est à mettre en liaison avec le fait que c'est plutôt fait pour être utilisé sous Linux. Si tout le monde a Linux, édite avec des \n, encode en UTF-8, alors oui, il n'y aura pas de problème. :D
Le très grand nombre de commandes qui existent. On peut se contenter de quelques-unes, mais on en découvre toujours de nouvelles, pas forcément très faciles ni très safe à utiliser. Il faut donc se méfier de ce qu'on fait. C'est à mettre en relation avec la complexité. Comme tout outil Unix, ça fait ce qu'on lui dit, même si on ne sait pas bien ce qu'on fait et qu'on débute (on n'a pas vraiment perdu de travail depuis le début, mais on a failli).

Maintenant ça va mieux, mais il a fallu un temps d'adaptation et pas mal de pédagogie pour que tout le monde l'utilise comme il faut. Ca ne s'utilise pas comme SVN, ça ne ressemble pas à SVN, ce n'est pas SVN. Sachez-le si vous comptez migrer : vous en retirerez de réels bénéfices, mais il faut que votre équipe soit constituée de développeurs, de préférence sous Linux, qui apprennent vite et qui sont habitués aux commandes Unix.

Ces listes ne sont pas exhaustives, je pourrais les compléter à l'occasion. Je pense néanmoins avoir dit l'essentiel pour donner grosso modo mon avis sur le sujet. :o)

18 commentaires

dimanche 3 mai 2009

La fin du bricolage

Par Mathieu Nebra le dimanche 3 mai 2009, 13h56

Un mois s'est écoulé depuis le précédent billet. Ce silence s'explique avant tout pour 2 raisons :

La sortie du nouveau design New Wave, qui, comme toute mise en production qui se respecte, a demandé de nombreuses petites corrections de bugs dans les semaines qui ont suivi. On n'a pas fini, il reste toujours des choses à faire, mais au moins ça s'est calmé de ce côté-ci.
L'arrivée de 2 stagiaires, Willy et Nicolas, qui travaillent sur le développement du site : améliorations et corrections de bugs. Ils seront rejoint dès demain par Mathias, ce qui fait que nous serons 4 au bureau pendant les 2 mois à venir. J'aurai l'occasion de parler plus en détail de ce qu'on fait et de ce en quoi consiste mon / leur travail.

Des développeurs

Aussi étonnant que cela puisse paraître, le Site du Zéro a vu son trafic grossir ces dernières années, mais pas son nombre de développeurs. A temps plein, pour s'occuper du code, il y avait en moyenne entre 0 et 1 développeur, selon les jours. Or, on ne peut pas croire qu'un site comme celui-ci se suffit à lui-même : il y a tous les jours des problèmes différents à régler, de nouvelles fonctionnalités et des améliorations à effectuer que nous aimerions faire depuis un moment.

Pour le SdZ, je ne pense pas qu'il soit non plus nécessaire de lever une armée de développeurs. Mais il est clair que n'avoir personne, ou presque, pour s'en occuper est inadéquat. A l'heure actuelle, je pense qu'entre 2 et 3 développeurs (à temps plein) conviennent. C'est de toute façon difficile actuellement pour moi d'en manager plus que ça.

Des rapports de bugs

Où je veux en venir ? Quel rapport avec le titre "La fin du bricolage" ?

Justement, si j'estime que l'on faisait du "bricolage" avant, c'est précisément parce que n'avions pas vraiment évolué depuis les tous débuts de la version 3 du site. Un serveur de développement, un serveur de production. On teste les fonctionnalités sur la "copie" du site en développement, et dès que c'est bon on passe en production en copiant les fichiers.

Globalement, ça, c'est le B.A.-BA. Mais ce n'était plus suffisant. Nous avions toujours une gestion anarchique des rapports de bugs et des améliorations. Aujourd'hui, nous utilisons comme je l'ai déjà mentionné un bug tracker qui nous permet de mieux suivre ce qui se passe, de gérer les priorités et de savoir "qui est en train de faire quoi". Ca peut paraître bête, mais parfois on ne savait pas toujours bien ce qui était en train d'être développé sur le site. Aujourd'hui heureusement, on a une meilleure visibilité.

Concernant le développement, il a été ces dernières semaines décentralisé. Nous avons certes gardé le serveur de développement, mais nous travaillons avant tout en local.

Des branches

Enfin, et c'est ce qui m'a occupé ces 2 dernières semaines (et qui m'a rendu quasiment invisible) : nous avons changé de logiciel de versionnement. Nous sommes passés de SVN à GIT. Autant dire que le passage s'est un peu fait dans la douleur, tant ces outils (qui ont pourtant le même but en théorie) s'utilisent différemment. Il a fallu nous réhabituer et nous défaire de certaines habitudes.

Branches

Git est, en quelques mots pour ceux qui ne connaissent pas, un système qui nous permet de garder une version de chaque fichier. Chaque modification est enregistrée, et si on veut retrouver le fichier tel qu'il était il y a 6 mois, on peut. On peut savoir qui a modifié le fichier quand, et pour quelle raison. On peut savoir quelles lignes il a ajoutés ou retirées. SVN fait pareil. La différence essentielle à nos yeux qui a justifié la transition, c'est que Git gère les branches de manière beaucoup plus fine.

Une branche est une évolution en parallèle du code source du site. C'est un moyen de tester de nouvelles fonctionnalités, de nouvelles idées, sans risquer de casser la branche principale "qui marche". C'est seulement une fois que la branche est stable que l'on décide de la fusionner avec la branche principale.

Regardez par exemple l'image ci-contre. Elle se lit de bas en haut et représente l'évolution du code. Chaque point est un état à un moment donné du site. La ligne tout à gauche représente la branche principale. C'est le site dit stable, celui que vous voyez quand vous visitez le SdZ. Parfois, on fait dériver en parallèle le site pour tester d'autres fonctionnalités dont on n'est pas sûr du temps qu'elles peuvent prendre à être réalisées : ce sont les branches. Le site évolue en parallèle et, au bout d'un moment, cette évolution est fusionnée avec la branche principale car on la considère utilisable. C'est alors que vous voyez ces changements en production, sur le SdZ.

Il y aurait beaucoup à dire sur Git, le fait notamment qu'il soit décentralisé et ne nécessite pas de serveur. Ou le fait qu'il se soit révélé extrêmement rapide. Ou encore le fait que ce soit un outil vraiment tourné vers les utilisateurs Unix et, bien que ça fonctionne, ce n'est pas encore vraiment la joie sous Windows. Ca reste un outil délicat, très délicat à manipuler. Comme tout bon programme sous Unix, ça fait ce qu'on lui dit, même si on lui dit de faire n'importe quoi. On l'a découvert à nos dépens.

Git a été conçu notamment par Linus Torvalds et est utilisé pour le développement du Kernel de Linux. Pour le moment, ce n'est quand même pas un outil grand public car il expose aux utilisateurs des concepts relativement avancés. En clair, je n'en recommande pas l'usage pour un débutant, mais si votre équipe est constituée de bons développeurs qui ont l'habitude d'utiliser des commandes Unix, alors vous finirez par beaucoup y gagner.

Du temps libre, peut-être ?

Il y avait un temps où on ne savait pas qui faisait quoi, où on ne savait pas où en étaient les résolutions de bugs, où deux personnes pouvaient difficilement travailler en même temps, où il était difficile de tester une nouvelle idée sans risquer de la mettre en production par inadvertance. Ca, c'est ce que j'appelle le bricolage.

L'évolution en interne a été un peu dure, mais elle était nécessaire. Il valait mieux le faire maintenant que de traîner de toute façon.

Paradoxalement, ça m'a mangé à peu près tout mon temps depuis 2-3 semaines. J'espère commencer à pouvoir respirer un peu et pouvoir à nouveau m'occuper du coeur du site : son contenu. J'ai commencé la rédaction du prochain chapitre Linux et j'ai commencé à effectuer des corrections globales - mais ennuyeuses - sur le tutoriel de C. Rien de tout cela n'est encore visible, mais ça ne saurait tarder.

17 commentaires un rétrolien

« billets précédents - page 1 de 2