Les choix technologiques pour le développement d’une application Web2
8 mars 2007 par BertrandJe réagis à un article de Stéphane Thomas sur le choix des technologies pour le développement d’une application Web2… Voila ce qu’il en est de notre côté !
Technologies
- PHP : pourquoi avoir choisi PHP plutot qu’autre chose ? En réalité le choix se limite à JSP, ASP ou PHP. ASP présente plusieurs inconvénients par rapport à PHP : c’est limité à la plate-forme Windows, ça bénéficie de beaucoup moins de support de la communauté Open-Source. En pratique, PHP se révèle plus puissant qu’ASP sur de nombreux points, en particulier sur sa syntaxe pour la gestion des tableaux et listes, plus stable (en particulier ASP est très pénible quand on sombre dans les problèmes d’enregistrement de DLL DCOM, et enfin bénéficie d’une liste absolument prodigieuse de petites fonctions faisant gagner un temps non négligeable au développeur qui sait les utiliser. Par rapport à JSP, notre compétence s’arrête là . Oui peut-être JSP est un bon choix. Ne pouvant pas maîtriser toutes les technologies, il faut bien un jour arrêter son choix sur quelque chose.
- MySQL : après avoir choisi PHP, on a le choix entre deux bases de données : MySQL et PostGre. En fait, on pourrait aussi y ajouter SQLite, qu’on utilise par ailleurs pour nos programmes “embarqués” (CD-Roms). Entre MySQL et PostGre, en réalité, le choix est difficile à faire car les deux technologies sont d’un très haut niveau. En pratique, aucune des deux n’est un mauvais choix. Un google fight a tendance à montrer que MySQL est plus souvent choisi, donc, on fait le choix du nombre…!
Outils de développement
Jusqu’à présent nous utilisons tout bêtement un editeur de texte (Textpad) pour faire l’intégralité des développements. Pas de golive, pas de dreamweaver (l’un et l’autre sont beaucoup trop limités pour la gestion des feuilles de style et les contenus dynamiques). Certains parmis nous utilisent aussi Eclipse, mais le gain apporté par rapport aux frustrations multiples d’un outil pas toujours très stable ne l’emporte pas. L’important est d’avoir accès à la documentation de PHP, de MySQL et du DOM HTML rapidement. Après il y a aussi des outils comme PHPed ou Zend Studio, mais les quelques tests que j’ai pu faire avec ne m’ont pas encore complètement convaincu - mais c’est certainement aussi lié à ma méconnaissance de ces outils. A suivre.
Frameworks
Evidemment, plus personne ne conçoit le développement d’une application web (ou java, c++) sans un framwork. Nous sommes de ce point de vue là assez pragmatiques. Nous avons bien sûr développé au cours du temps des librairies en interne pour gérer les opérations les plus fréquentes (l’authentification, la gestion des objets dans une base de données, etc…). Quand sont arrivés les Ruby on rail et consors, la question s’est posée de savoir s’il ne fallait pas remplacer une partie de nos développement maison par un de ces frameworks. En pratique, c’eut été une très mauvaise idée, pour plusieurs raisons : la première, c’est qu’on a mieux à faire que de changer un socle qui fonctionne (par exemple on peut corriger des bugs et ajouter des fonctionnalités). La seconde, c’est que mine de rien, nos applications ont des fonctionnalités que tous ces frameworks ne sont pas forcément capables de gérer. Par exemple, la gestion de l’internationalisation, qui souvent est un problème annexe pour les frameworks venus des US.
Nous avons en revanche inclus un certain nombre de librairies (n’appelons pas scriptaculous un framework, c’est une librairie !) :
- prototype.js : sélectionné après plusieurs essais de Dojo et d’autres. Pourquoi celui-là plutot qu’un autre ? Parce qu’il marche, qu’il ne prend pas 10 secondes à charger, qu’il est utilisé par beaucoup de gens, que le projet n’est pas mort. jQuery est peut-être aussi très bien (surtout lorsqu’il sera interfacé avec Ext), on regardera à ce moment là . YUI est très bien aussi, tous ces gens là font du boulot très utile pour toute la communauté ! Mootools est buggé (sur IE) et n’est au départ qu’un plagiat de prototype.js et scriptaculous.
- scriptaculous : parce que les gens aiment les petits machins qui bougent. Contient entre autres un excellent composant de tri par drag’n'drop. Dommage qu’il n’y ait pas une librairie de widgets applicatifs basée sur ces deux là (comme Ext).
- js_calendar : un petit widget pour gérer les calendriers (de chez DHTMLGoodies). Contrairement à d’autres, il est multilingue et gère les dates avant 1970…
- htmlmimemail : une librairie indispensable pour l’envoi de mail en PHP (très buggé sinon ). HTMLMimeMail permet d’envoyer du mail en texte brut ou en HTML, avec des pièces jointes, des images, en UTF-8 ou en Latin1, etc… On l’a modifié pour inclure toutes les images d’un document HTML en pièces jointes, et en les retaillant avec GD ci nécessaire. Merci Richard Heyes.
- GNU Gettext et PoEdit : Gettext est un ensemble d’outils pour la gestion de l’internationnalisation des programmes (toutes technologies confondues). C’est génial, très puissant, GNU.
- FusionCharts : un ensemble de graphes en flash. Payant, mais bien faits et avec un bon effet “wow”.
- fValidate : une librairie de validation des formulaires. Plus maintenue depuis longtemps et un peu buggé, mais présentant l’avantage d’être très souple et facile à internationnaliser. On la remplacera peut-être un jour par quelque chose basé sur prototype.js (je reste à l’écoute mais pour l’instant je n’ai rien vu de concluant)
- FCKEditor : un éditeur HTML wysiwyg. En gros on a le choix entre TinyMCE et FCKEditor. FCKEditor était la en premier, c’est lui qu’on a gardé. Il est très bien, très complet, avec beaucoup de bonnes idées dans le code. Merci Federico…
- dhtmlxTree : un petit composant (payant) pour la gestion d’arborescences. Permet le glisser-déposer, les checkboxs, et le chargement dynamique par XMLHttpRequest. C’est le seul qui fasse tout ce qu’on voulait. Un jour quelqu’un en fera un basé sur scriptaculous, peut-être.
- pclzip : un petit composant pour faire de la compression et de la décompression de fichiers zip.
- getid3 : un composant pour récupérer les meta-informations des fichiers multimedia. Permet de connaitre la largeur et hauteur d’un flash ou d’un mpeg, etc…
- wz_tooltip : un petit composant permettant d’afficher des tooltips. Y en a plein d’autres mais celui là marche.
Gestion des bugs
Nous avons longtemps cherché l’application idéale pour la gestion des bugs. Notre choix s’est arrêté finalement sur Bugzilla. Nous avons regardé Mantis, Tracs, etc… Les critères qui ont motivé ce choix sont les suivants :
- multi projets : nous gérons des dizaines de projets : nous avions besoin d’une gestion souple mais fine des droits. Bugzilla n’est pas le plus simple en ce qui concerne la gestion des droits (c’est même assez tordu), mais bon, le travail est fait.
- rapide : comme pour tout système de production, ça doit aller vite, parce qu’un développeur n’aime pas avoir le sentiment de perdre son temps. De ce point de vue là , Bugzilla regorge de bonnes idées et de raccourcis divers. Par exemple de pouvoir mettre des étapes de création de bugs en bookmark, de pouvoir passer d’un bug à l’autre automatiquement quand on les traite par lot, etc.
Au final, ce que nous apprécions dans Bugzilla :
- la gestion des emails, la recherche avancée, les différentes vues, la stabilité de roc, la rapidité, les fonctionnalités avancées
Ce que nous aimons moins :
- le look (surtout quand on donne l’outil aux clients), la gestion des droits un peu tordue, les rapports pas facile à générer (on aurait aimé des rapports et des graphes pré-programmés).
Ce qu’on y ajoutera peut-être un jour :
- un joli petit client Windows pour ajouter un bug, avec la possibilité de faire une copie d’écran, pour donner aux clients.
Gestion des versions
Subversion bien sûr. Aucune hésitation, et aucun regrets ! TortoiseSVN est excellent. Cependant j’utilise Araxis Merge pour les diff, qui est un niveau au dessus.
