INTERVIEWS 
 
Landon Bradshaw
Directeur technique
Maguma
Landon Bradshaw
"Objet et modules font de PHP5 une évolution nécessaire"
L'allemand Maguma, créé par Tobias Ratschiller, développeur principal de phpMyAdmin et qui a depuis quitté la société, propose un éditeur de code PHP. Entretien.
 (15/03/2005)
 
  En savoir plus
Dossier Logiciels libres/Open Source
  Le site
Maguma
Quelles sont les raisons de la création de Maguma ?
À l'origine, amener plus de professionnalisme au développement PHP, par le biais d'outils de création d'applications. C'est toujours notre objectif aujourd'hui, bien qu'après avoir travaillé sur une plate-forme applicative côté serveur, nous mettons maintenant l'accent sur des outils côté client.

En quoi votre éditeur PHP se démarque-t-il ?
En lançant notre produit Maguma Studio, nous nous sommes aperçus qu'une application monolithique risquait de rendre difficile l'ajout de fonctionnalités, que ce soit celles rendues nécessaires par les évolutions de PHP, ou d'autres. Aussi quand est venu le moment de lancer Maguma Workbench, nous avons décidé de parier sur la modularité. Ainsi Workbench est une plate-forme qui offre l'API pour se connecter aux fonctionnalités de Studio.

Diriez-vous que PHP5 est une révolution pour le développement PHP, ou une évolution nécessaire ?
Je dirais une évolution nécessaire, et ce de deux manières. Pour commencer, la structure et la gestion de l'Objet ont été largement améliorées et standardisées depuis PHP4. Baser la structure sur le modèle Java a été une décision intelligente : il s'agit d'une architecture éprouvée et permettant aux programmeurs de l'autre côté de la barrière d'être rapidement productif en PHP.
Je m'attends à ce que les sites comme PHPClasses.com soient inondés d'objets réutilisables, pouvant être facilement intégré par le programmeur PHP.
Ensuite, les modules : placer un bon nombre d'extensions dans PECL est une des idées que j'ai cherché à propager depuis un bon moment. À l'époque de PHP3, nous avions 10 modules parmi lesquels choisir, mais avec PHP4 il y en avait trop dans le paquetage de base. Prenons exemple sur Apache : les modules de base du serveur sont maintenus à un nombre minimum, on ne garde que l'essentiel, et les autres artifices sont ajoutés atour de l'installation initiale.

Connaissez-vous les proportions de code PHP3/4/5 conçu avec vos produits ?
Je ne peux pas vous donner les chiffres exacts, mais d'après ce que je sais de nos clients par le biais des retours, je pense pouvoir les estimer respectivement à 0%, 85% et 15%. PHP4 reste largement la plate-forme la plus utilisée, tandis que PHP5 augmente, même si le plus gros des projets PHP5 semble être des projets internes que des extranets.

Dans combien de temps estimez-vous que PHP5 sera plus utilisé que PHP4 ?
À la vitesse où vont les choses avec PHP5, je pense que le passage de flambeau se fera début 2006 au plus tard, ce principalement pour deux raisons : le meilleur support Objet, et l'intégration de MySQLi. Le support Objet offre une structure try/catch très attendue de la part des programmeurs en provenance d'autres langages fortement Objet, et MySQLi rend l'intégration à une base de données plus robuste que jamais, en ajoutant les fonctionnalités des derniers produits MySQL.

Quels sont les outils et méthodes utilisés par vos développeurs pour concevoir Maguma Workbench ?
L'outil le plus utilisé lors du développement de Workbench est sans contexte wxWidgets. Il s'agit d'une boîte à outils de création d'interface multiplate-forme dont la robustesse autorise le développement d'un tel produit. Par ailleurs, il dispose d'un grand nombre d'objets de base requis pour toutes les fonctionnalités que nous ou nos clients pourrions rêver. Côté Windows, nous en restons à Visual C++ 6 pour le développement et le débogage. Sur Linux, c'est une combinaison de vim, gcc, gdb, et l'un d'entre nous utilise CodeForge. Nous utilisons CVS pour gérer les fichiers sources, et CVSTrac pour la maintenance et la communication.
Pendant les premiers développements de Workbench, nous avons mis en place une série de directives et conseils pour indiquer comment l'architecture devait être implémentée, et comment le code devait être formaté et documenté. Notre API de documentation est générée avec Doxygen.
L'un des plus importants aspects du développement continu de Workbench reste nos utilisateurs : nous essayons de prendre chacun idée en compte, envoyée par mail, via les forums ou dans nos rêves, et de les implémenter dans la plate-forme. Certaines idées prennent plus de temps que de coller une étiquette sur une bouteille.

Votre outil est multiplate-forme : Windows, Linux et Mac OS. Comment se déroule le développement dans de telles conditions ? Chaque plate-forme s'est-elle révélée un bon investissement ?
Linux et Windows se sont révélés assez simples à mettre en place, tandis que le port Mac OS se présente comme le plus difficile des trois, et nous ne sommes même pas sortis de la phase bêta, car nous voulons ajouter les fonctionnalités sans briser l'arbre-source. Nous pensons que notre décision de proposer notre outil sur plusieurs plates-formes est importante, car même si beaucoup de débutants PHP viennent du monde Windows, les utilisateurs plus anciens ou avancés ont souvent migré vers d'autres plates-formes, et nous devons rester avec eux tout en offrant un bon produit aux nouveaux.

Nous avons préféré C++ à Java pour le développement multiplate-forme"
Avec les optimisations au coeur de Java, comme le gain en vitesse d'exécution, pensez-vous que la décision originelle d'écrire Workbench en C++ tient toujours la route pour un projet multiplate-forme ? Quelles autres technologies pourraient aujourd'hui être utilisées pour un tel développement ?
Certes, Java a été optimisé et est bien supérieur à ses versions précédentes, mais je pense qu'il reste trop compliqué à gérer du côté de l'utilisateur final, trop en tout cas pour proposer un environnement que nous pourrions soutenir. Côté serveur, Java offre de nombreux avantages, on peut s'en servir pour lui lancer des appels depuis une interface PHP par exemple, mais je pense que notre choix de garder le développement de Workbench en C++ est le bon. Cela nous donne la sécurité de savoir qu'il n'y a pas une couche supplémentaire hors de notre contrôle dans le programme.
La différence de vitesse entre notre Workbench compilé et un programme similaire tournant sur la JVM n'est pas aussi énorme qu'il y a deux ans, quand nous avons lancé le développement, mais elle est toujours présente. Je plaide cependant mon ignorance certaine sur les derniers tests de vitesse pour des applications Java tournant dans un environnement JIT compilé.

Votre société tient ses racines dans l'Open Source. Quelles sont vos relations, en tant qu'entité commerciale, avec ce mouvement aujourd'hui ?
L'Open Source est une part majeure de notre activité, même si cela peut sembler étrange pour une société qui produit des logiciels propriétaires. Il y a cinq ans, vous auriez eu du mal à trouver une société qui utilise des produits Open Source dans son environnement de travail, mais les temps changent...

Quelles sont vos visions pour 2005, pour votre société comme pour le monde PHP ?
Pour notre société, 2005 sera très positive, car cette année nous verra sortir plus de produits pour les développeurs PHP. Nous avons des idées en attente, des produits visant à un système particulier les structures que nous estimons importants face aux technologies en cours et à venir.
Côté PHP, je ne crois pas qu'il se passera grand'chose, simplement plus de migrations de PHP4 à PHP5, plus de bonnes pratiques en matière de programmation, mais rien de changement de paradigme bouleversant pour le langage. Comme on dit, "Qui veut voyager loin ménage sa monture", ou une phrase de cet acabit. Je peux raisonnablement prédire que le futur promet beaucoup et que le langage continuera d'obtenir de nouveaux serveurs dans les études Netcraft.
 
Propos recueillis par Xavier Borderie, JDN Développeurs

PARCOURS
  
 
Landon Bradshow, est directement technique de Maguma GmbH depuis 2003, après y avoir été chef de projet de 2000 à 2002.

1998 Webmaster/développeur/administrateur réseau chez Motorola.

1998 Développeur/graphiste chez Exxon.