tag:blogger.com,1999:blog-46821213857807243622024-02-02T03:59:25.593+01:00Blog Gauthier DelamarrePoints de vue et analyses sur le logiciel libre en tant que principe. Et pour être plus concret, tests et tutoriels sur certains logiciels libres, liés notamment au développement web en général, et au langage PHP en particulier.Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.comBlogger36125tag:blogger.com,1999:blog-4682121385780724362.post-71318010496605595392013-10-04T14:31:00.000+02:002013-10-04T14:31:04.814+02:00Zend just released a new PHP 5.5 certificationDuring the next ZendCons, with the first one in the US next week and the European edition next month in Paris, Zend announced the availability of a new PHP certification which will take into account the latest developments of the language, now in its 5.5 version.<br />
<br />
On this occasion, the editor has not only updated the certification content, but also the title given to certified people, which becomes "Zend Certified PHP Developer" when we were called "Zend Certified Engineer". Although this change can be considered as cosmetic, I 'm happy about it as it seems important to emphasize that "developer" is a real job. It is a difficult one, so it is rewarding to see it recognized by a certification.<br />
<br />
Despite these slight changes, the nature and structure of this new certification have not fundamentally changed compared to the previous version, based on PHP 5.3 . Many topics remain the same, while others has been updated to challenge candidates on the coolest new features, such as the sections related to Traits, Namespaces, Password Hashing API, or the magic methods (<a href="http://www.zend.com/en/services/certification/php-certification/" target="_blank">list of topics</a>) .<br />
<br />
One can be surprised that the term "generators" is missing as it is one of the biggest news for PHP 5.5 (with its famous new keyword "yield", which I am sure will give us a hard time during training sessions :)). This is explained by the fact that this subject is covered by the topic "Spl" which is what « generators » are in the end. No worries then, this new version will include many questions about them, and I can tell they won’t be that easy.<br />
<br />
The challenge promises to be interesting. For those who wants to be among the firsts to take the exam and become Zend Certified PHP Developers ", please note that it will be proposed to <a href="http://europe.zendcon.com/" target="_blank">ZendCon Europe</a> attendees. To put the odds in favour of these brave first candidates, you can take a full day tutorial on the first day of the event, two sessions of three hours of preparation to pass the exam. And I will have the pleasure of hosting it!<br />
<br />
Please note, seats are limited, both for the tutorial and for the exam itself, so I recommend that you register as soon as possible!<br />
<div>
<br /></div>
Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-77600158099677192702013-10-03T22:01:00.000+02:002013-10-04T10:28:34.414+02:00Une nouvelle certification Zend pour PHP 5.5A l'occasion des prochaines ZendCon, aux Etats-Unis et, pour la première fois, en Europe le mois prochain, Zend vient d'annoncer la disponibilité imminente d'une nouvelle certification, dont l'examen tiendra compte des toutes dernières évolutions du langage, désormais en version 5.5.<br />
<br />
Pour l'occasion, l'éditeur a non-seulement mis à jour le contenu de la certification, mais également le titre attribué aux certifiés, qui devient "Zend Certified PHP Developer", quand nous étions auparavant des "Zend Certified Engineer". Bien que ce changement soit avant-tout d'ordre cosmétique, je m'en réjouis, car il me semble important de souligner que <a href="http://www.gdelamarre.com/2012/07/chef-de-projet-aboutissement-de-la.html" target="_blank">"développeur" est bien un métier</a>, qu'il est difficile, et donc gratifiant d'être reconnu par une certification.<br />
<br />
Malgré ces évolutions de surface, la nature et la structure de cette nouvelle certification n'ont pas fondamentalement changées par rapport à la version précédente, basée sur PHP 5.3. De nombreux sujets déjà présents sont restés inchangés, tandis que d'autres ont été mis-à-jour pour challenger les candidats sur les nouveautés les plus fraîches du langage, comme les sections relatives aux Traits, aux Namespaces, à l'API de hashage, ou encore aux méthodes magiques (<a href="http://www.zend.com/fr/services/certification/php-5-certification/" target="_blank">liste complète des topics</a>).<br />
<br />
On peut être surpris de ne pas voir apparaître dans cette liste le terme "Générateurs", qui constitue une des grosses nouveautés de PHP 5.5 (avec son fameux nouveau mot-clé "yield", qui, je le sens, va nous donner du fil à retordre en formation :)) , mais ceci s'explique par le fait que ce sujet est couvert par le topic "Spl", les générateurs étant finalement, somme toute, des générateurs d'Itérateurs. Pas d'inquiétude donc, l'examen comportera bien des questions à leur sujet, dont je vois venir d'ici qu'elles ne seront pas parmi les plus aisées.<br />
<br />
Le challenge promet d'être intéressant. Pour les plus motivés, sachez qu'il sera proposé aux participants de la <a href="http://europe.zendcon.com/" target="_blank">ZendCon Europe</a> de tenter leur chance sur place pour passer l'examen, et faire ainsi des tous premiers "Zend Certified PHP Developers". Pour mettre toutes les chances du côté de ces téméraires premiers candidats, Zend prévoit de leur offrir, le premier jour de l'événement, deux sessions de trois heures de préparation au passage de l'examen, que j'aurai le plaisir d'animer !<br />
<br />
Attention, les places seront limitées, tant pour le tutorial que pour l'examen, aussi je vous recommande de vous inscrire dès que possible !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com1tag:blogger.com,1999:blog-4682121385780724362.post-80709465929944946152013-08-05T10:57:00.002+02:002013-08-05T10:57:52.025+02:00Comment j'ai arrêté de fumer (presque) malgré moi !<div class="p1">
Après pas loin de 20 ans de tabagisme, à hauteur d'un paquet par jour en moyenne (plutôt 1.5 ces deniers temps d'ailleurs), vingt années ponctuées de nombreuses tentatives pathétiques d'arrêt du tabac, je m'étais fait à l'idée que je resterai fumeur jusqu'à la fin de mes jours.</div>
<div class="p2">
<br /></div>
<div class="p1">
Depuis une semaine maintenant, je n'ai pas réussi à fumer une cigarette entière. J'ai essayé à plusieurs reprises, sans succès. Pire, j'ai du me précipiter pour me rincer la bouche lors de ma dernière tentative, tant le goût de la fumée m'a paru ignoble.</div>
<div class="p2">
<br /></div>
<div class="p1">
Me voici donc dans une situation parfaitement paradoxale : je suis fumeur, ou du moins me considéré-je comme tel, mais je ne peux plus fumer. L'idée de ressentir une fois de plus ce goût infect de cendre et de brûlé m'est insupportable !</div>
<div class="p2">
<br /></div>
<div class="p1">
Un miracle, penseront peut-être certains fumeurs aussi désespérés que je pouvais l'être. A dire vrai, c'est un peu ce que j'en pense également. Mais il y a bien sûr une explication. </div>
<div class="p2">
<br /></div>
<div class="p1">
Dans mon cas, le miracle a pris la forme d'une cigarette électronique. J'ai acheté ce dispositif sans intention, par curiosité pour le gadget bien plus que par espoir de me libérer du tabac. Espoir que je n'avais pas du tout d'ailleurs. J'ai testé la cigarette électronique, j'ai trouvé ça intéressant, alors je l'ai achetée. C'était mardi dernier, vers 14h00.</div>
<div class="p2">
<br /></div>
<div class="p1">
Dans l'après-midi qui a suivi, je n'ai pas allumé de cigarette "à incandescence". Pourquoi n'en ai-je pas allumé ? Pour la simple raison que je n'en avais pas envie - je n'ai pas fait le moindre effort. Le dispositif électronique m'a permis d'absorber mon content de nicotine, et ce faisant, a annihilé toute envie d'une "vraie" cigarette.</div>
<div class="p2">
<br /></div>
<div class="p1">
Arrêtons-nous un instant sur cette idée de "vraie" cigarette : disons le clairement, cette idée est stupide. La cigarette à incandescence est un moyen rudimentaire, archaïque, mais cependant efficace, d'absorber de la nicotine. La cigarette électronique est moyen plus propre, moins nocif, mais tout aussi efficace de parvenir aux mêmes fins. Les deux sont donc des cigarettes, au même titre l'une que l'autre.</div>
<div class="p2">
<br /></div>
<div class="p1">
Pour revenir à ma propre expérience, il m'a suffit de consommer de la nicotine au moyen d'une cigarette électronique pendant une après-midi pour comprendre combien il était aisé de se passer de cigarettes archaïques. Sans compter le plaisir immédiat de ne plus avoir les doigts qui sentent le tabac !</div>
<div class="p2">
<br /></div>
<div class="p1">
Toutefois, à ce stade, il n'était pas question pour moi de cesser de fumer. </div>
<div class="p2">
<br /></div>
<div class="p1">
Mais quelques heures plus tard encore, en début de soirée, alors que je buvais une bière accompagné d'un ami, fumeur, j'ai eu envie de me "faire plaisir" en fumant une "vraie" cigarette (je croyais encore au concept de "vraie" cigarette à ce moment-là :)). Le plaisir a tourné court… quelques bouffées seulement, et j'ai jeté cette cigarette. </div>
<div class="p2">
<br /></div>
<div class="p1">
C'est évidemment à ce moment que j'ai compris qu'il se passait quelque chose de sérieux dans mon rapport au tabac. Bien sûr je ne criai pas victoire immédiatement, et je renouvelai l'expérience chaque jour au moins une fois jusqu'à hier encore. Chaque fois, même cause, même effet : les cigarettes que j'ai allumées cette semaine ont toute invariablement fini écrasées après quelques bouffées. Y compris celles que j'ai allumées en étant convaincu d'en avoir envie et qu'elles me feraient plaisir, sachant que je ne m'interdisais pas de fumer, et je ne me l'interdis toujours pas !</div>
<div class="p2">
<br /></div>
<div class="p1">
A ce jour, c'est donc sans effort et sans frustration que j'ai cessé de consommer des cigarettes à incandescence. C'est également sans appréhension que je pars pour un déplacement d'une semaine sans cigarette archaïque sur moi.</div>
<div class="p2">
<br /></div>
<div class="p1">
Bien sûr, la lutte contre la nicotine n'est pas encore finie. Mais dans celle contre la cigarette, j'ai remporté une grande victoire. Je ne peux pas exclure l'hypothèse d'une "rechute", même si elle me paraît très improbable, mais quoi qu'il arrive, j'ai au moins gagné la certitude que je pouvais très bien vivre sans cigarette et sans fumée, perspective qui me semblait jusqu'alors inimaginable.</div>
<div class="p2">
<br /></div>
<div class="p1">
Enfin, un mot sur le titre de ce billet : j'ai arrêter de fumer des cigarettes archaïques malgré moi dans la mesure où, aujourd'hui, alors même que je n'avais pas décidé d'arrêter, je ne parviens plus à en fumer, j'en suis dégoûté. Alors pourquoi ce "(presque)" ? Parce que je pense que j'étais prêt, et que cela a grandement contribué à l'apparition de ce phénomène. Il est possible que la même expérience quelques années auparavant n'aurait pas eu les mêmes résultats.</div>
<div class="p2">
<br /></div>
<div class="p1">
J'ai rédigé ce billet pour deux raisons : bien sûr pour témoigner de mon expérience avec la cigarette électronique, mais aussi pour m'aider moi-même à comprendre ce qui m'est arrivé. Je peux vous garantir que ça me fait un effet des plus curieux lorsque j'allume une cigarette et que je ne parviens pas à la terminer après en avoir fumé peut-être 150.000 dans ma vie ! Refaire la chronologie, réfléchir à ce qui s'est passé m'aide à mieux comprendre, et à rationaliser.</div>
<div class="p2">
<br /></div>
<br />
<div class="p1">
Si ce billet pouvait encourager, ou mieux, aider ne serait-ce qu'une personne à se libérer également de la cigarette, alors la demi-heure que j'ai consacrée à sa rédaction aura été bien investie ;)</div>
Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com3tag:blogger.com,1999:blog-4682121385780724362.post-15353267025034915412012-12-04T17:09:00.002+01:002012-12-04T17:09:31.944+01:00freeblogware.org devient gdelamarre.comJ'ai changé aujourd'hui le nom de domaine associé à ce blog.<br />
<br />
Le nom originel, freeblogware, reflétait une intention (créer un moteur de blog) qui n'a jamais été réalisée, et depuis ... quelques années maintenant, il me paraissait toujours plus ridicule. Simplement, je ne trouvais pas autre chose.<br />
<br />
Pour finir, j'ai choisi la simplicité, et accordé le nom du blog à celui de la plupart de mes comptes en lignes (Twitter, GTalk, SlideShare et quelques centaines d'autres). Faute d'être créatif, ce nouveau domaine assure au moins un peu de cohérence et peut-être plus de lisibilité dans mes communications :)Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-62087961624134484982012-12-04T17:06:00.001+01:002012-12-04T17:06:24.343+01:00Debrief PHP Tour Nantes 2012
<br />
<div class="p1">
Me voilà dans le train*, enfin en route pour retourner chez moi. Je dis "enfin", mais d'un autre côté, je dois dire que je n'étais pas plus pressé que ça de quitter ce "petit monde" du PHP <strike>français</strike> francophone. </div>
<div class="p1">
<br /></div>
<div class="p1">
Cette édition a offert aux visiteurs toutes les qualités que l'on connaît aux événements organisés par l'AFUP : une logistique impeccable, des membres stables qui assurent la continuité, et de nouvelles têtes qui viennent apporter de nouvelles perspectives, toujours bienvenues pour assurer la vitalité de l'association et de son action.</div>
<div class="p2">
<br /></div>
<div class="p1">
Les promesses du programme ont été tenues, comme à l'habitude ! Les présentations ont couvert des sujets variés, tant techniques que métiers (et pour une fois, nous parlons de notre métier, celui du développement, et plus généralement de l'IT). </div>
<div class="p1">
<br /></div>
<div class="p1">
La récente sortie de Zend Framework 2 (Septembre 2012) a motivé Matthew Weier O'Phiney (lead développeur du projet) et Zeev Suraski (CTO de Zend Technologies) a faire le trajet depuis, respectivement, les Etats-Unis et Israël pour venir présenter au public les dernières évolutions de leurs solutions. Ce qui confirme, il serait dommage de ne pas le souligner, le sérieux de l'image de l'AFUP, de ses membres et des visiteurs des événements qu'elle organise aux yeux des acteurs majeurs du techno-système PHP.</div>
<div class="p2">
<br /></div>
<div class="p1">
Il serait bien sûr trop long de citer tout le monde - le site du PHP Tour vous permettra de consulter a posteriori le programme, et une recherche sur Twitter (#phptour) vous donnera accès aux nombreux commentaires réalisés en direct des différentes sessions.</div>
<div class="p2">
<br /></div>
<div class="p1">
Je tenais cependant à renouveler mes remerciements aux nombreux visiteurs qui sont venus assister à la conférence que j'ai présentée avec mon collègue Christophe Massin sur le thème de la montée en compétence des développeurs et des équipes. La planification d'une seconde session de cette conférence pour répondre à l'intérêt porté par les visiteurs sur ce thème nous démontre la pertinence de notre démarche professionnelle, et nous ne pouvons que nous en réjouir. Pour ceux qui n'ont pas pu se rendre au PHP Tour, nous avons mis en ligne sur Slide Share <a href="http://fr.slideshare.net/gdelamarre/comment-transformer-un-dbutant-en-superdveloppeur" target="_blank">une version plus complète des slides</a>.</div>
<div class="p2">
<br /></div>
<div class="p1">
Enfin, merci à tous les bénévoles de l'AFUP pour leur efficacité dans l'organisation de l'événement, leur accueil et leur "dévouement à la cause" ;) N'oublions pas d'ailleurs de mentionner la nouvelle mouture du site <a href="http://aperophp.net/">aperophp.net</a> qui a été dévoilée durant le PHP Tour !</div>
<div class="p2">
<br /></div>
<div class="p1">
Rendez-vous est pris en Juin pour le prochain Forum PHP à Paris !</div>
<div class="p1">
<br /></div>
<div class="p1">
* évidemment, j'ai publié ce billet quelques jours après sa rédaction, faute de wifi dans le train :(</div>
Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com2tag:blogger.com,1999:blog-4682121385780724362.post-43560860457588564552012-10-01T13:52:00.000+02:002012-10-01T13:52:00.625+02:00PHP Tour 2012 à Nantes : programme en ligne !Ce rapide billet pour signaler la publication du programme complet du PHP Tour 2012 qui se déroulera à Nantes les 29 et 30 Novembre 2012.<br />
<br />
Outre que j'ai le plaisir (et le privilège) d'avoir été sélectionné pour co-présenter, avec mon collègue Christophe Massin, une conférence sur le thème de la montée en compétence des équipes internes, je me réjouis de constater que les conférences liées aux meilleures pratiques (intégration continue, tests unitaires, revues de code, etc.) seront largement représentées, en plus bien sûr de présentations sur le thème principal de cette édition, l'<a href="http://fr.wikipedia.org/wiki/Donn%C3%A9es_ouvertes" target="_blank">Open Data</a>.<br />
<br />
Mais je préfère vous laisser vous faire une idée par vous même sur <a href="http://afup.org/pages/phptournantes2012/deroulement.php" target="_blank">le site officiel du PHP Tour</a>.<br />
<br />
Juste un dernier mot pour rappeler que pour la troisième fois consécutive, <a href="http://www.vaconsulting.lu/" target="_blank">VA Consulting</a> est sponsor des événements d'envergure nationale et internationale organisé par <a href="http://www.afup.org/" target="_blank">l'AFUP</a>, que je remercie au passage pour tous ces efforts déployés pour favoriser la diffusion et le soutien du technosystème PHP !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-79856645290670896782012-07-10T23:12:00.001+02:002012-07-10T23:16:15.214+02:00Gérer la hiérarchie dans une équipe de développement<span class="Apple-style-span" style="font-family: Arial;">Le débat initié récemment <a href="http://www.freeblogware.org/2012/07/chef-de-projet-aboutissement-de-la.html" target="_blank">sur ce blog</a> concernant la place du développeur a ouvert, au travers des commentaires, une question complémentaire à la fois plus vaste mais tout aussi importante : comment gérer l'évolution de carrière de chacun et, par extension, la hiérarchie dans une équipe ?</span><br />
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Il est à la mode de contester l'idée que la hiérarchie est nécessaire pour organiser une équipe. Je ne souscris pas à cette mode. Pour expliquer ma position, je veux d'abord revenir sur l'idée même de hiérarchie. Souvent, on considère que gravir les échelons de l'organisation d'une société donne droit à plus de "pouvoir" (notez les guillemets…). Cette idée, je la rejette également, tout en étant conscient que c'est effectivement comme cela que ça se passe, dans le faits, le plus souvent. </div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
De mon point de vue, appuyé par l'expérience (il ne s'agit pas là de pure spéculation intellectuelle, ni de posture éthique), la hiérarchie est nécessaire dans une équipe, car des décisions doivent être prises pour que les choses avancent. Et les décisions ne peuvent pas toujours être prises de manière collégiale. Aussi, je considère qu'<b>évoluer dans une hiérarchie ne conduit pas à exercer plus de pouvoir, mais à assumer plus de responsabilités</b>.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Certains m'ont objecté que pour être en mesure de faire face à ces responsabilités, il est indispensable d'avoir le contrôle de la situation, et donc le pouvoir, ne serait-ce que de prendre les décisions que l'on juge nécessaires pour mener à bien sa mission. Mon désaccord sur ce point est… subtil. Je pense que ce que l'on qualifie couramment de pouvoir devrait être considéré différemment : pour moi, c'est d'autorité dont on a besoin, laquelle doit être naturelle et légitime pour s'exercer pleinement. Je précise, pour éviter les quiproquos que j'entends <b>autorité dans le sens de référence</b>, et non pas dans son acception coercitive.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Le pouvoir confié arbitrairement à un membre de l'équipe, au prétexte qu'il serait directement lié à sa position dans l'organisation, ne sera pas, ou alors difficilement, accepté par ceux qui sont placés en-dessous (sur l'échelle des responsabilités). En effet, si l'on a pas confiance en la personne supposée assumer la responsabilité de la mission dans laquelle on est engagé, le risque est grand de contester voire même de refuser ses décisions. Avec des conséquences énormes sur le succès de l'équipe. </div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
<b>Une autorité exercée sans légitimité provoque d'abord la frustration</b>. Et la frustration dégrade considérablement la cohésion de l'équipe. Partant du principe que tous les membres de l'équipe ont une importance égale (chacun est indispensable à la réussite de tous), négliger sa cohésion est sans doute la pire erreur qu'un manager puisse commettre.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Aussi, au fur et à mesure que l'équipe s'agrandit, et que de nouvelles responsabilités sont identifiées, il faut trouver la bonne personne à qui confier cette responsabilité. Sur quelle critère ? Le plus important est sans doute <b>la confiance</b>. Pas seulement celle que le manager à dans le candidat qui lui semble être le mieux placé, mais aussi et surtout la confiance qu'ont ses collègues en ce candidat. C'est la confiance qui assurera la légitimité, et la légitimité qui à son tour assurera l'autorité. Et c'est enfin l'autorité qui garantira qu'une responsabilité sera prise en charge dans les meilleures conditions.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Parmi les dilemmes cornéliens auxquels le manager peut être confronté, il y a celui de l'ancienneté. Un membre de l'équipe doit-il se voir confier des responsabilités au seul titre de son ancienneté ? Théoriquement, non, bien sûr. Seules les compétences devraient guider une telle décision. Mais avec le risque là encore de frustrer ce membre de l'équipe si on lui préfère un plus jeune, ou un collègue arrivé après lui dans l'équipe. C'est ce qui explique que l'on préconise parfois de préférer solliciter quelqu'un de l'extérieur, dont on aura (un peu) moins de mal à expliquer qu'il est plus qualifié pour le job et que c'est pour ça qu'on le fait rejoindre l'équipe. </div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Mais ça reste délicat bien sûr. Gare dans ce cas à ne pas démoraliser celui qu'on aura laissé "à sa place", car même si on fait souvent ce choix parce que la personne est à la place qui lui est la plus appropriée, il faut quand même trouver des motivations et un objectif personnel. Je reviendrai plus loin sur ce point.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
L'ancienneté sur un poste donné, autrement dit<b> l'expérience, ne garantit pas toujours la capacité à assumer des responsabilités autres</b>. C'est là que je boucle la boucle avec le sujet précédent : l'expérience de développeur ne prépare en rien aux responsabilités de responsable de projet, c'est pourquoi on fait rarement évoluer les développeurs vers ce poste, ce qu'ils vivent pourtant le plus souvent comme une frustration.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
L'erreur, dans cette situation, vient de ce que <b>les responsabilités dans les équipes sont souvent mal identifiées</b>. Il existe de nombreuses responsabilités que l'on peut dégager à l'intérieur de l'activité de développement, à commencer par l'architecture, mais aussi la qualité (via les tests), ou encore le design de bases de données. Chacune de ces responsabilités peut justifier la création d'un poste dédié, accompagné d'un package plus motivant que celui de "simple" développeur. Ce qui représente je pense le meilleur moyen de satisfaire le désir naturel de chacun de progresser professionnellement sans compromettre la cohésion de l'équipe.</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Résumons-nous : la confiance mutuelle est la base de la cohésion de l'équipe. <b>La confiance confère la légitimité nécessaire à exercer une autorité indispensable au bon fonctionnement d'une équipe</b>. Et la confiance est toujours plus facile à accorder à quelqu'un dont on sait qu'il a une réelle maîtrise du sujet qui lui est confié. Alors je propose aux managers d'équipes IT d'être créatifs, de <b>ne pas limiter leur hiérarchie à développeurs/chef de projet</b>, de ne surtout pas mettre les premiers sous l'autorité du second, et de trouver à chacun la place dans la laquelle il se sentira respecté, car légitime, et qui répondra à ses aspirations en terme d'évolution de carrière. </div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Pour cela, il ne faut pas hésiter à <b>déléguer des responsabilités bien identifiées</b>, et à créer des postes pour que chacun puisse exercer au mieux ses talents dans l'équipe. C'est ainsi que l'on pourra demander à quelqu'un de rester dans sa partie sans le frustrer. <b>La position de développeur ne doit pas être un fourre-tout de l'organigramme</b> dans lequel on maintient tous les profils techniques dont on ne comprend pas toujours bien le job, et dont on pense parfois que la seule évolution de carrière consiste à migrer vers le management. </div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
Le développement est un métier technique, qui offre de multiples spécialisations, et c'est vers ça qu'il faut tendre : il faut former les collaborateurs sur des aspects plus précis du métier pour qu'ils puissent continuer de s'éclater dans leur job, de rendre d'inestimables services aux clients de leur société (pour le service) ou à leur employeur, et tout ça sans vivre <b>la frustration de rester développeur pendant un temps infini</b>, sans avancement ni de responsabilité ni de considération, et surtout, sans perspective !</div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
<br /></div>
<div style="font-family: Arial;">
<br /></div>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com2tag:blogger.com,1999:blog-4682121385780724362.post-15600239701661969762012-07-05T00:31:00.001+02:002016-06-29T09:14:13.738+02:00Chef de projet, aboutissement de la carrière d'un développeur ?Non, cent fois non !!!!!!!!!!!!!!!<br />
<br />
Ceci est un cri du coeur... je viens de lire un billet très récent de Fred Hardy sur <a href="http://blog.mageekbox.net/?post/2012/07/04/Le-developpeur-une-espece-en-danger-d-extinction" target="_blank">son blog mageekbox</a>, lequel billet est une réflexion (amère oserais-je préciser) sur l'état du "marché" du développement. Une fois n'est pas coutume, je suis d'accord avec un certain nombre de constats de Frédéric, mais pas avec leur interprétation. Je reviendrai peut-être sur ces divergences ultérieurement, mais d'abord, je voudrais m'insurger contre cette idée parfaitement farfelue qui apparaît à plusieurs reprises dans les nombreux commentaires de ce billet : l'évolution normale, logique et surtout valorisante du statut de développeur serait celui de chef de projet.<br />
<br />
Quelle aberration ! De ce que j'ai lu dans les commentaires, il semblerait que l'on fourre cette idée saugrenue dans la tête des futurs développeurs dès leur apprentissage... ceci expliquerait cela.<br />
<br />
Ca fait des années (moi aussi je suis vieux ;)) que je m'interroge sur le fait que des développeurs qui ont encore du lait sur le clavier (2-3 ans d'expérience) proclament et même réclament la responsabilité de chef de projet. Je ne comprenais pas bien d'où leur venait cette idée absurde qu'il leur fallait accumuler de l'expérience sur un métier pour prétendre ensuite à en exercer un autre ! Comme si un serveur de restaurant devait naturellement devenir cuisinier. Non pas qu'il ne le puisse pas, mais simplement son expérience, même si elle est dans un domaine proche, n'a rigoureusement rien à voir.<br />
<br />
Car la réalité est celle-ci : un développeur devenu chef de projet, ce n'est pas un développeur qui a réussi, mais au contraire, souvent, un développeur qui a échoué. Soit il s'est trompé en démarrant dans le développement (il n'était pas fait pour ce métier), soit il n'est pas parvenu à exercer convenablement ce métier (et donc il n'était définitivement pas fait pour). Et la confusion vient peut-être du fait que certains chefs de projet ont tendance à penser qu'ils sont également chefs des développeurs, en leur imposant des délais en dépit du bon sens, en faisant preuve d'une autorité artificielle et mal à propos, là où au contraire, ils devraient être à l'écoute et au service des développeurs pour maximiser les chances de succès des projets dont ils ont la responsabilité.<br />
<br />
Un développeur produit du code. C'est le fondamental. Le corollaire, c'est qu'il conçoit des applications. Quand il est bon. Et ça, c'est être architecte. Et c'est ça l'aboutissement d'une carrière de développeur. En aucun cas chef de projet. D'autres possibilités s'offrent aux développeurs, comme consultant, formateur ou encore expert technique. Mais toujours pas chef de projet !<br />
<br />
Pour résumer la situation, passer du développement à la gestion de projet, c'est une <b>reconversion professionnelle</b>. Rien d'autre. Ces deux métiers n'ont rien en commun, si ce n'est qu'ils évoluent en symbiose, l'un ayant besoin de l'autre. Mais les qualités requises pour exercer l'un et l'autre sont très différentes.<br />
<br />
Un développeur doit avoir des qualités d'abstraction, de concentration, de conception, de persévérance et de compréhension technique là où l'on attend d'un chef de projet qu'il soit parfaitement organisé, capable de communiquer tant avec un client qu'un développeur (c'est leur seul lien !) et de suivre méthodiquement l'évolution d'un projet pour s'assurer qu'elle concorde d'une part avec la planification et d'autre part avec les contraintes dictées soit par le métier, soit par le client, selon les circonstances.<br />
<br />
Les développeurs doivent s'ôter de la tête que leur salut passe par l'abandon de la technique (chef de projet, c'est un job du côté management de la force, pas du côté technique) - ou alors, je le répète, c'est qu'ils se sont fourvoyés.<br />
<br />
Pour finir, un mot sur les fantasmes salariaux... une société qui paierait à prix d'or un chef de projet et négligerait ses développeurs fait une grosse erreur. Il est beaucoup plus difficile de trouver sur le marché un développeur compétent (fut-il spécialisé sur tel ou tel framework plutôt que globalement expert sur un langage, ping @mageekguy ;)) qu'un chef de projet. D'ailleurs, certaines statistiques démontrent que développeurs et chefs de projet, pour une expérience identique, ont des salaires très similaires, et même à l'avantage du développeur au-delà d'une certaine expérience (d'après une étude du cabinet Hayes et de Cadremploi citée dans un numéro récent du magazine Programmez).<br />
<br />
Je jette donc un pavé dans la marre : un développeur mal payé, c'est sans doute qu'il s'est mal vendu (par exemple au mauvais employeur), ou alors qu'il se surestime (désolé de rappeler que l'on est pas développeur senior après 3 ans d'expérience !). Le développement est un métier difficile, qui requiert de nombreuses qualités et beaucoup d'expérience, et quand les deux sont réunis, le profil a de la valeur sur le marché, beaucoup de valeur.<br />
<br />
Si vous aimez la technique, poursuivez dans cette voie, les entreprises ont besoin de vous ! En cela je rejoins Frédéric, les bons profils de développeurs se raréfient, et pas parce que certains se sont spécialisés des frameworks, mais parce que trop renoncent ou changent de carrières pour s'orienter, souvent beaucoup trop tôt dans leur carrière, vers le management.Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com44tag:blogger.com,1999:blog-4682121385780724362.post-45926516327222254432012-06-14T15:30:00.002+02:002012-06-14T15:30:47.764+02:00Debrief du Forum PHP 2012Je n'ai pas encore trouvé le temps de poster au sujet du Forum PHP de cette année, pour la simple raison que je suis rigoureusement débordé ! Pour cette même raison, je n'ai exceptionnellement pas pu consacrer au Forum autant de temps qu'à l'habitude, n'étant en capacité de m'y rendre que la deuxième journée.<br />
<br />
Pour autant, j'ai pu constater qu'une fois encore l'organisation était à la hauteur, et ce bien qu'il n'y ait pas eu d'édition parisienne l'an passé, et que de fait le bureau actuel n'a pas été impliqué dans l'organisation de la précédente édition. Bien sûr, il y a eu la première édition du PHP Tour, qui fut un excellent baptême du feu pour les futurs membres titulaires du bureau, mais l'organisation de l'édition parisienne reste un peu plus problématique, notamment du fait d'un plus grand nombre de participants.<br />
<br />
Une mention spéciale doit d'ailleurs être attribuée au choix du lieu, la Cité Universitaire Internationale, qui a accueilli le Forum pour la première fois, dans un cadre vraiment très agréable, nettement plus que ce que n'offre la Cité des Sciences, du moins à mon goût. Le faste quelque peu suranné de certaines salles offrait un contraste charmant avec la thématique du Forum.<br />
<br />
Pour ce qui est du contenu des conférences, il me semble avoir été à la hauteur des précédentes éditions, pour autant que j'ai pu en juger (pas toujours facile en tant que membre de l'organisation de suivre les conférences, surtout quand on est là qu'une seule journée), les échos récoltés auprès des visiteurs confirment cependant largement cette impression.<br />
<br />
Voilà, je n'ai malheureusement pas grand chose de plus à dire sur cette édition. Il me tarde donc d'être à Nantes pour le prochain <a href="http://afup.org/pages/phptournantes2012/" target="_blank">PHP Tour</a>, dont je rappelle que <a href="http://afup.org/pages/phptournantes2012/appel-a-conferenciers.php" target="_blank">l'appel aux conférenciers</a> est ouvert !<br />
<br />
Pour finir, je tiens à remercier toute l'équipe pour ces bons moments chaque fois partagés lors des événements Afup, et à adresser mes félicitations au bureau en place pour le travail effectué, et ce dans des conditions qui n'auront pas été les plus simples de l'histoire du Forum (changement de lieu, une édition en moins, etc.). Bravo à tous !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-26794613352890719622012-05-09T12:06:00.002+02:002012-05-09T12:06:58.592+02:00Zend Studio 9 à 100%... de CPU !Une petite astuce technique, pour les utilisateurs de Zend Studio 9... vous l'aurez peut-être remarqué, il arrive que ZS9, malgré ses améliorations globales sur les performances, soit totalement handicapé à ce niveau par une consommation maximale de CPU. J'indique 100% dans le titre, mais en réalité, ça peut être beaucoup plus, puisque qu'il s'agit de 100% de chaque Core - nous avons des machines ici annonçant 400% d'occupation pour l'application Zend Studio...<br />
<br />
Ou plutôt qui annonçaient, car nous avons trouvé sur le forum Zend une solution sous la forme d'un patch, en attendant qu'elle soit intégré dans une prochaine release. Voici donc la marche à suivre pour retrouver une ZS utilisable confortablement :<br />
<br />
<br />
1) dans Studio, allez dans "Help" -> "install new software"<br />
2) Renseignez le champ "Work with" avec l'url suivante : http://dl.dropbox.com/u/47740218/ZendStudioFeaturePatchesRepository<br />
3) puis installez le seul patch proposé et redémarrez ZS...<br />
<br />
And voilà :)<br />
<br />
Normalement, l'usage CPU de Zend Studio devrait redescendre à quelques pourcents, autour de 2 chez moi hors traitements de fond naturellement.<br />
<br />
Le post original, <a href="http://forums.zend.com/viewtopic.php?f=59&t=49398#p115948" target="_blank">c'est par là</a> !<br />
<br />
Je précise que nous avons testé la manipulation sur des Mac (MacBook Pro et iMac) jusqu'à présent, et ce chaque fois avec succès... aucune certitude concernant les autres environnements, même si le patch n'est absolument pas spécifique à Mac OS X. Bonne chance :)<br />Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-81615041213296540112012-03-07T15:11:00.000+01:002012-03-17T09:19:47.741+01:00PHP 5.4 : tirer un trait sur le passé ?<br />
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Le jeu de mot est un peu facile, je vous le concède. Mais comment ne pas saluer avec enthousiasme la sortie de PHP 5.4 (le 01/03/2012), et de sa plus grosse nouveauté : les traits. Ce concept peu connu dans l'univers PHP, mais qui ne l'est finalement guère plus dans d'autres langages courants va sans doute permettre de repenser en grande partie la conception objet avec PHP dans les mois à venir.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><b><span class="Apple-style-span" style="font-size: small;">PHP 5.4, une version intermédiaire ou majeure ?</span></b></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Avant de parler plus concrètement de l'implémentation des traits en PHP, sujet principal de ce billet, je voudrais revenir sur son titre. Si je considère PHP 5.4 comme une évolution majeure du langage, c'est parce qu'enfin des traits ont été tirés (bis repetita...) sur des caractéristiques archaïques du langage, de sorte que certaines des plus mauvaises habitudes de PHP ne sont plus seulement découragées, mais purement et simplement interdites. </div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Si je ne devais prendre qu'un seul exemple, je citerais la suppression de la directive "register_globals" (et de son pendant programmatique import_request_variables()). Ce fameux register_globals, qui automatise l'intialisation de variables globales dans le script d'après les paramètres GET, POST, le contenu des cookies ou encore la session, tout ça dans le désordre le plus complet, est un symbole de la permissivité de PHP. Un symbole très négatif, car l'activation de cette fonctionnalité a conduit en son temps à de nombreux effets de bords et trous de sécurité (notamment combiné à d'autres mauvaises pratiques, comme l'utilisation de variables non-initialisées). Et pourtant, bien que découragé par sa désactivation par défaut depuis PHP 4.1 (!), l'usage du register_globals s'est maintenu pendant de (trop) nombreuses années.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Donc, la rénovation de PHP est en marche ! Il ne s'agit plus de bricoler par-dessus une carcasse vieillissante, mais de véritablement tailler dans la masse, d'amputer les parties malsaines pour améliorer substantiellement le langage. </div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Pour résumer, PHP 5.4 est la bonne nouvelle que nous attendions depuis l'abandon du développement de PHP 6. Et même si la timide numérotation des deux dernières versions principales de PHP (5.3 et 5.4) ne le souligne pas suffisamment, ce sont bel et bien des versions majeures, et à ce titre devraient inciter les développeurs à réviser leurs habitudes et leur façon de faire, pour y intégrer ce que PHP leur offre désormais.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Et à ce propos, revenons justement aux traits ! Pour ceux qui parmi vous se sont intéressé tant soit peu au sujet et se sont peut-être interrogé sur l'intérêt concret de cette nouveauté, et pour les autres, ceux qui ne savaient pas que ça existait, et par conséquent ne savent probablement pas ce que c'est, je vous propose d'illustrer leur usage en examinant comment les traits auraient pu améliorer sensiblement la qualité du code de Zend Framework (v1) en se basant sur un exemple précis : la gestion d'options.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Mais avant d'étudier l'impact qu'aurait eu la disponibilité des traits sur le code de Zend Framework, il convient de revenir sur la définition même des traits. De quoi s'agit-il au juste ? Les traits peuvent dans une certaines mesure être comparés aux classes abstraites (impossibilité de les instancier, déclaration de propriétés, écriture de méthodes concrètes), mais avec deux différences notables : d'une part les traits ne sont pas hérités, mais simplement utilisés (mot-clé <b>use</b>), et d'autre part il est possible d'utiliser plusieurs traits dans une même classe concrète (comme si les classes abstraites autorisaient l'héritage multiple).</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><blockquote class="tr_bq"><b><span class="Apple-style-span" style="font-size: x-small;">Pas d'héritage</span></b></blockquote><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Le fait que les traits ne nécessitent pas d'héritage permet de maintenir une hiérarchie d'objet qui ne soit pas détournée dans le simple but de la réutilisabilité du code. On décide de les utiliser sur une ou plusieurs classes selon que les méthodes qu'ils exposent seront utiles ou non à cette classe, indépendamment de la nature même des classes qui les utiliseront. De fait, il devient très facile de partager des fonctionnalités identiques entre plusieurs classes sans que celles-ci n'aient le moindre rapport du point de vue conceptuel. A ce titre, les traits sont aisément comparables aux <b>helpers</b> que l'on trouve dans certains frameworks.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><blockquote class="tr_bq"><b><span class="Apple-style-span" style="font-size: x-small;">Usage de multiples traits</span></b></blockquote><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">L'absence de lien entre les traits et le mécanisme d'héritage a également facilité la possibilité d'agréger plusieurs traits sur une même classe. Pour PHP, les traits sont considérés comme des fragments de classes (méthodes et propriétés) dont on peut se servir comme briques de base pour fabriquer d'autres classes. De ce fait, le langage offre une grande liberté d'utilisation des méthodes exposées par les traits, en permettant notamment d'en modifier le nom et la visibilité au moment de l'intégration dans une classe concrète (aliasing - mot-clé<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;"> </span><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;"><b>as</b></span><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;">)</span>, et même de remplacer au run-time une méthode exposée par un trait par une autre méthode, issue d'un autre trait (mot-clé <b>insteadof</b>). </div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><i>Attention toutefois à cette souplesse, car si elle peut rendre de grands services, elle peut aussi conduire à des pratiques à la limite de l'obfuscation de code ! Je pense notamment à l'aliasing et à l'usage d'insteadof naturellement.</i></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><b><span class="Apple-style-span" style="font-size: small;">Comment traiter le cas de la gestion des options dans Zend Framework</span></b></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">De nombreux composants de Zend Framework proposent une gestion d'options, passées sous forme de tableau associatif à l'instanciation, pour faciliter la configuration des instances. Et je trouve ça fort pratique, à tel point qu'il m'arrive régulièrement de recommander de s'en inspirer pour des classes "maison". Mais en même temps, ça fait longtemps que je déplore la multiplicité d'implémentation de ces méthodes de gestion des options. En effet, de même que nous devons écrire nos propres méthode setOptions(), getOption(), etc. dans nos classes propriétaires, on peut constater non sans surprise qu'il existe pas moins de 33 implémentations d'une méthode qui s'appelle setOptions(), dont les principes et prototypes sont très proches sans être identiques.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">L'usage d'un trait dans ce cas aurait apporté des bénéfices significatifs à deux populations :</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"> - aux développeurs du Zend Framework, en leur épargnant l'écriture de 32 méthodes superflues (sans parler des tests unitaires associés !), et en favorisant une certaine standardisation de la gestion d'options. Cette gestion étant réimplémentée dans chaque classe en ayant besoin, et pas toujours par le même contributeur, elle subit les influences des différents auteurs, avec au final des dérives assez importantes dans l'approche.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"> - aux développeurs PHP utilisant Zend Framework dans leurs développements, car ils sont les premières victimes du manque de standardisation évoqué dans le point précédent. En effet, chaque fois que l'on trouve une méthode setOptions() dans Zend Framework, même si le rôle de ces différentes méthodes est similaire, il faudra relire la documentation, voire le code source, pour s'assurer du fonctionnement de chacune. Il ne sera pas possible de capitaliser sur la maîtrise "du mécanisme de gestion d'options de Zend Framework" car dans la réalité, il y a jusqu'à 33 mécanismes de gestion d'options différents !</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Pour finir, voici en quelques lignes ce qui aurait changé dans le code de Zend Framework si l'on avait pu utiliser les traits au moment de son développement. L'exemple est volontairement basé sur une implémentation minimale de setOptions(), celle de Zend_Navigation_Page, pour des soucis de lisibilité :</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><b>Version "officielle" :</b></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><blockquote class="tr_bq">abstract class Zend_Navigation_Page extends Zend_Navigation_Container<br />
/* ... */<br />
public function setOptions(array $options)<br />
{<br />
foreach ($options as $key => $value) {<br />
$this->set($key, $value);<br />
}<br />
return $this;<br />
}<br />
/* ... */<br />
}</blockquote><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><b>Version "traitée" en PHP 5.4</b></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><blockquote class="tr_bq">trait OptionsHandler {<br />
public function setOptions(array $options)<br />
{<br />
foreach ($options as $key => $value) {<br />
$this->set($key, $value);<br />
}<br />
return $this;<br />
}<br />
}</blockquote><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><blockquote class="tr_bq">abstract class Zend_Navigation_Page extends Zend_Navigation_Container<br />
use OptionsHandler;<br />
/* ... */<br />
}</blockquote><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Ces deux écritures sont strictement identiques du point de vue du run-time et de l'appel de la méthode setOptions(). Simplement, en déportant la méthode dans un trait, on lui a assuré une réutilisabilité totale.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Quand on sait qu'il y a des classes aussi différentes que Zend_Translate_Adapter, Zend_Validate_Ip ou encore Zend_Tag_Cloud qui chacune définit une méthode setOptions(), il et évident qu'il aurait été absurde d'un point de vue conceptuel de les faire dériver d'un ancêtre commun, ce qui explique le choix de réimplémenter systématiquement une méthode qui aurait pourtant pu être rendue générique et utilisable par tous ces composants. </div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Les traits sont la seule solution à la fois élégante (un minimum de code), sûre (contrôles à la compilation) et performante (contrairement aux helpers, qui utilisent la méthode magique __call, singulièrement lente) de gérer ce problème de conception.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Il me semble que le temps est venu de tirer également un trait sur l'argument de ses détracteurs selon lequel PHP n'est pas pourvu d'un modèle objet digne de ce nom !</div><div><br />
</div>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com3tag:blogger.com,1999:blog-4682121385780724362.post-60006090521691262092011-11-03T23:25:00.001+01:002011-11-03T23:25:16.197+01:00PHP Tour 2011 : VA Consulting sponsor Bronze !Ce court billet pour signaler que VA Consulting (www.vaconsulting.lu), la société dont je suis responsable des services professionnels, a validé son sponsoring pour la première édition du PHP Tour, qui se déroulera à Lille les 24 et 25 Novembre, tout comme nous l'avions fait l'année passée pour le Forum PHP.<br />
<br />
C'est une grande satisfaction pour moi de pouvoir apporter ce soutien supplémentaire à la tenue ce premier événement majeur de l'AFUP en dehors du Forum, en plus de ma participation en tant que membre de l'association.<br />
<br />
Le choix de Lille sera en outre certainement l'occasion pour nos amis et partenaires belges de venir à notre rencontre durant ce salon, ce dont je me réjouis également.<br />
<br />
Il est encore temps de <a href="http://afup.org/pages/phptourlille2011/inscription.php">réserver vos places</a>, nous vous attendons nombreux !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-26267210669391311432011-06-25T17:51:00.001+02:002011-06-25T17:52:01.700+02:00PHP Tour 2011 : Objectif Lille !Pour la première fois de son histoire, L'AFUP organise un événement parallèle à son fameux "Forum PHP", et au passage quitte (momentanément) Paris.<br />
<br />
Cet événement a été baptisé "PHP Tour" afin d'en souligner l'itinérance. En effet, si la première édition se tiendra à Lille les 24 et 25 Novembre 2011, les suivantes prendront leurs quartiers dans d'autres métropoles françaises. Le programme de la première édition vient d'être mis en ligne, et peut être consulté sur <a href="http://afup.org/pages/phptourlille2011/deroulement.php">le site officiel de l'événement</a>.<br />
<br />
Il est à noter qu'un soin particulier a été apporté pour définir un programme en relation avec le tissu économique local, avec ici notamment plusieurs sessions dédiées au commerce électronique, dont le Nord héberge nombre de gros représentants. Par ailleurs, un certain nombre de conférences sont centrées sur PHP lui-même (comme par exemple une session consacrée à la création d'extensions).<br />
<br />
Naturellement, le programme est complété par de nombreuses présentations, orientées tant sur la technique (niveaux variés) que sur la méthodologie. Autrement dit, il y en aura pour tout le monde !<br />
<br />
Alors venez nombreux, nous comptons sur vous pour que cette première édition du PHP Tour soit mémorable, et place d'emblée ce rendez-vous comme un nouvel incontournable du calendrier PHP francophone !<br />
<br />
Petit rappel : n'oubliez pas non plus d'adhérer à l'AFUP si vous souhaitez soutenir l'action de l'association, et lui permettre d'organiser des événements toujours plus nombreux et réussis.Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-35051495668990013062010-11-11T12:02:00.001+01:002010-11-11T14:28:01.866+01:00Forum PHP 2010 : la grosse édition !L'édition 2010 du Forum PHP a tenu toutes les promesses que le double anniversaire des 10 ans de l'AFUP et des 15 ans de PHP laissait supposer.<br />
<div><br />
</div><div>Ce forum a surclassé par bien des aspects toutes les éditions précédentes, notamment en terme de fréquentation : durant ces deux journées, ce sont plus de 500 personnes qui auront foulé les allées du forum et les salles de conférences ! On peut cependant citer également l'abondance de sponsors et la surface totale dévolue au forum au nombre des records battus cette année. Sans oublier bien entendu les "rock stars" qui nous ont fait le plaisir de participer au programme des conférences, comme Rasmus Lerdorf, Zeev Suraski, Derrick Rethans, etc.</div><div><br />
</div><div>Pour revenir à l'essentiel, c'est-à-dire l'affluence de visiteurs et plus encore l'appétit avec lequel ils ont dévoré les différentes conférences proposées, le nombre de suggestions en rapport avec les sessions elles-mêmes me semble très révélateur. On notera entre autre la proposition de programmer les conférences plusieurs fois, pour pouvoir y assister même si un autre sujet d'intérêt est présenté simultanément. Des demandes relatives à l'information sur les conférenciers et le niveau des présentations ont également été faites à plusieurs reprises. Certains ont même suggéré que le forum soit rallongé d'une journée pour proposer encore plus de sessions, et plus longues !</div><div><br />
</div><div>Ces différents points m'amènent à la conclusion que le forum PHP de l'AFUP, bien qu'il ait conservé son esprit très enthousiaste et décontracté, s'est parallèlement grandement professionnalisé. On ne va plus au Forum uniquement pour "réseauter" et croiser les stars évoquées ci-avant. On y va surtout parce que les sujets abordés sont en phase avec les problématiques quotidiennes du développement web en PHP, qui sont toujours plus complexes, et plus intéressantes.</div><div><br />
</div><div>Pour toutes ces raisons, je suis particulièrement heureux d'avoir pu participer à ce forum au triple titre de membre de l'organisation (étant membre du bureau de <a href="http://www.afup.org/">l'AFUP</a>), de sponsor (avec <a href="http://www.vaconsulting.lu/">VA Consulting</a>) et de conférencier (introduction à Zend Framework, dont vous pouvez trouver le support sur <a href="http://www.slideshare.net/gdelamarre/introduction-zend-framework">slideshare</a>) !</div><div><br />
</div><div>J'ajouterai enfin une conclusion basée sur un sentiment plus personnel par rapport à ce forum. L'aspect professionnel de l'évolution du monde PHP m'importe bien sûr tout particulièrement. A cet égard, le Forum PHP 2010 semble pour moi marquer une nouvelle étape majeure dans la professionnalisation de PHP : l'un des sujets que je le plus entendu aborder sur ce salon est probablement la difficulté de recruter des développeurs qualifiés, des architectes et des experts PHP. </div><div><br />
</div><div>Débattre librement de ce problème signifie qu'un tabou est en train de tomber : oui, parmi les développeurs PHP qui se proposent sur le marché nombreux sont ceux qui ne sont pas à la hauteur des enjeux et des problématiques des projets PHP actuels. Schématiquement, on peut dire que<b> l'écosystème s'est professionnalisé plus vite que les professionnels</b>. Nous entrons donc probablement dans une nouvelle phase de l'évolution de cet écosystème, phase dans laquelle la formation devrait prendre une place centrale et offrir des défis passionnants.</div><div><br />
</div><div>Je remercie une fois encore les nombreux visiteurs du Forum 2010, et vous dis donc à l'année prochaine à tous, pour la 11ème édition !</div>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com5tag:blogger.com,1999:blog-4682121385780724362.post-87900843245421120312010-09-21T23:21:00.000+02:002012-12-05T19:25:08.188+01:00Tester unitairement, ce n'est pas tester une seule fois !Quoique j'ai l'impression que je m'apprête à rédiger des évidences, il me semble malgré tout plus que nécessaire de revenir sur l'intérêt fondamental des tests unitaires, tests dont je parlerai ici dans un sens élargi. Ce billet s'adresse en priorité aux développeurs qui soit ignorent simplement ce que sont les tests unitaires, soit doutent de leur intérêt. Aussi, si ma démonstration vous convainc, je vous invite à en transmettre le lien à tous ceux parmi vos connaissances qui relèveraient de l'une de ces deux catégories !<br />
<br />
1. Définitions<br />
<br />
Je ne veux pas rentrer dans les détails, et encore moins les querelles techniques, que les puristes m'en excusent. Je préfère être plus schématique pour faciliter la compréhension du propos. Et ce précisément parce que j'ai pu constater que la défiance généralement observée à l'endroit des tests unitaires vient principalement du fait que l'on ne comprend pas vraiment de quoi il s'agit concrètement.<br />
<br />
Pour bien comprendre donc de quoi l'on parle je vais tenter de définir ce type de tests par opposition à ceux que l'on pratique intuitivement, ou plus exactement que l'on est bien obligé de pratiquer au cours du développement, à savoir les tests manuels. Car c'est en effet là que réside la différence principale entre ces deux familles de tests : l'une est manuelle, l'autre est automatisée. Cette caractéristique est primordiale dans le concept de test unitaire. Nous verrons bien sûr que ce n'est pas tout, mais lorsque l'on a compris l'intérêt de l'automatisation, les autres concepts véhiculés par le test unitaire prennent tout leur sens de manière assez évidente.<br />
<br />
Revenons donc à nos deux types de tests, et essayons de les caractériser :<br />
<br />
<ul>
<li> les tests "manuels"</li>
<ul>
<li>écriture</li>
<ul>
<li>on y procède le plus souvent en ajoutant des petits straps de code à l'intérieur du code de l'application, à grand renfort de var_dump, print_r, echo et autres die</li>
</ul>
<li>exécution</li>
<ul>
<li>ils s'exécutent en faisant tourner une application ou l'une de ses sous-parties (page, composant, ensemble de composant, etc.) dans son contexte final (i.e. en utilisant l'interface graphique)</li>
</ul>
<li>validation</li>
<ul>
<li>le résultat attendu est comparé au résultat obtenu par l'opérateur du test</li>
</ul>
</ul>
</ul>
<ul>
<li>les tests "automatiques"</li>
<ul>
<li>écriture</li>
<ul>
<li>ils sont écrits sous forme de classes dédiées, indépendantes de l'application, à l'aide d'un framework spécialisé, offrant toutes les méthodes nécessaires pour matérialiser sous forme de code ce que l'on veut tester (<i>assertions</i>)</li>
</ul>
<li>exécution</li>
<ul>
<li>ils sont exécutés dans un environnement neutre, isolé, lui aussi indépendant de l'application</li>
</ul>
<li>validation</li>
<ul>
<li>le résultat attendu est écrit à l'avance, dans la classe de test, et lors de l'exécution, seule la vérification (ou non) de ce résultat attendu comparé à celui obtenu est reporté</li>
</ul>
</ul>
</ul>
<div>
2. Conséquences</div>
<div>
<br /></div>
<div>
Reprenons les trois points déterminants utilisés dans la section précédente pour comparer les deux approches :</div>
<div>
<br /></div>
<div>
<ul>
<li>Ecriture</li>
<ul>
<li>Dans l'approche manuelle, il est nécessaire de modifier le code de l'application elle-même pour y insérer nos tests. <span class="Apple-style-span" style="color: red;">Ceci rend par définition le code nécessaire au test éphémère</span>, puisqu'il n'est pas question de le conserver de manière pérenne (par exemple dans son dépôt Subversion), bien qu'il soit à peu près impossible de ne pas oublier un echo ou un var_dump quelques part avant de sauver voire de déployer son code...</li>
<li>L'approche automatisée permet de déporter le code nécessaire au test dans une arborescence dédiée, <b>et ne vient donc pas polluer l'application</b>.</li>
</ul>
<li>Exécution</li>
<ul>
<li>Le caractère intrusif de l'approche manuelle expliqué ci-dessus implique qu'<span class="Apple-style-span" style="color: red;">il existe un risque que le test lui-même altère le comportement de l'application</span>, et donc le résultat du test. En outre, puisque ce code de test ne peut être conservé de manière persistante,<span class="Apple-style-span" style="color: red;"> il sera nécessaire de le supprimer puis de le réécrire</span> à chaque fois qu'il sera nécessaire de modifier le composant, et donc de le tester de nouveau</li>
<li>A l'inverse, ces problèmes ne peuvent pas exister avec des test automatisés. Puisqu'ils sont écrits et maintenus parallèlement au code de l'application,<b> ils n'en modifient jamais le comportement, et peuvent être rejoués à tout moment et en quelques secondes</b>, ce qui est essentiel pour s'assurer tout au long du développement de l'application que ce qui fonctionnait à un moment fonctionne toujours à un autre moment.</li>
</ul>
<li>Validation</li>
<ul>
<li>Durant un test manuel, on vérifie que le code a produit<span class="Apple-style-span" style="color: red;"> le résultat auquel on s'attendait</span>, laissant parfois l'interprétation des résultats à la <span class="Apple-style-span" style="color: red;">subjectivité</span> du testeur, ou même à sa simple concentration, à son attention du moment...</li>
<li>Dans un test automatique, on vérifie que le code a produit<b> le résultat que l'on voulait</b> ! Ce qui pourrait sembler être un détail est en fait essentiel. Il est <b>objectif</b>, ne dépend pas de l'opérateur. Il ne dépend que des assertions décrites dans la classe de test,<b> qui ne changent ni avec le temps, ni avec l'opérateur</b>.</li>
</ul>
</ul>
</div>
<div>
3. Du test automatisé au test unitaire</div>
<div>
<br /></div>
<div>
Mais alors pourquoi parler de tests unitaires, et non pas simplement de tests automatisés ? Je ne doute pas que les explications ci-dessus vous auront convaincu de l'intérêt de cette approche, mais peut-être vous demandez-vous encore où est le piège ? Si c'était si simple, les tests unitaires, tout le monde les utiliserait depuis longtemps !</div>
<div>
<br /></div>
<div>
Si ces tests automatisés sont appelés "tests unitaires", c'est tout simplement parce qu'ils ne peuvent s'appliquer qu'à des <b>fractions élémentaires de l'application</b> ("unités"), puisqu'ils sont exécutés en-dehors. En règle générale, l'unité retenue pour un test est la classe, les assertions s'appliquant au retour des méthodes. Pour que chaque unité soit indépendante des autres, il faut ... qu'elle n'en dépende pas ! </div>
<div>
<br /></div>
<div>
Prenons un exemple simple : une méthode qui doit travailler sur un objet X doit le recevoir en argument, et non pas l'instancier elle-même (principe de l'<b>injection de dépendance</b>). Au moment de tester cette méthode, elle sera invoquée avec en paramètre cet objet X que l'on aura pris soin d'instancier soit même dans le code du test, avec des données "en dur", et donc que l'on maîtrisera complètement. Ainsi, si le test échoue, on pourra éliminer l'hypothèse que peut-être l'objet X en question n'était pas ce qu'il aurait dû être, etc. En résumé, l'échec d'une assertion ne doit pouvoir signifier qu'une seule chose : l'échec de la méthode testée !</div>
<div>
<br /></div>
<div>
Tester unitairement une application suppose que les classes qui la composent soit fortement découplées. Cela implique <b>une vision très objet du code</b>, qui n'est pas évidente à maîtriser. Et c'est probablement ce qui rend l'adoption massive de la pratique des tests unitaires si délicate. </div>
<div>
<br /></div>
<div>
Pourtant, à bien y réfléchir, on peut aussi voir le code utilitaire comme un guide facilitant grandement la conception des objets composant une application ! En utilisant la phase d'écriture des tests comme support à la conception des objets eux-mêmes, avant même d'en écrire le code, vous vous obligez à créer des objets "propres", très faiblement couplés.</div>
<div>
<br /></div>
<div>
Cerise sur le gâteau, écrire vos tests avant d'écrire les objets vous donne<b> une métrique précise de l'avancement de votre projet</b> : le but étant d'écrire du code jusqu'à ce qu'il permette de faire tourner votre jeu de tests sans que plus aucun test n'échoue, la sortie de l'utilitaire de test vous informera avec précision du nombre de méthodes/objets finalisés, et <b>conformes à vos spécifications</b> (que matérialisent vos tests unitaires). En passant, pour ceux qui ne l'auraient pas identifiée, cette méthodologie est appelée Test Driven Development (dévelopement dirigé par les tests). </div>
<div>
<br /></div>
<div>
Enfin, il est important de préciser que cette méthode, comme les tests unitaires eux-mêmes, doivent en priorité s'appliquer aux <b>parties les plus critiques de l'application</b>, et tout particulièrement la bibliothèque d'objets métiers (ceux qui manipulent vos données !).</div>
<div>
<br /></div>
<div>
Conclusion</div>
<div>
<br /></div>
<div>
Si certains pensent qu'écrire des tests unitaires représente une perte de temps, que l'on ne peut se l'offrir si l'on est pressé, je dirais que ceci n'est (partiellement) vrai que si et seulement si l'on n'est pas à l'aise avec l'écriture de test. Mais ceci, comme tout autre connaissance, vient avec la pratique. Et une fois la compétence acquise, on se rend compte qu'il n'est simplement pas raisonnable de développer sans tests unitaires, ou à tout le moins sans tests automatisés. Pour acquérir cette maîtrise, vous pouvez donc commencer par utiliser un framework de tests unitaires tel <a href="http://www.phpunit.de/">PHPUnit</a> (le vénérable ancêtre) ou <a href="https://github.com/atoum/atoum" target="_blank">Atoum</a> (le challenger) pour automatiser vos tests, quels qu'ils soient, et plus vous l'utiliserez, mieux vous le connaîtrez, plus vous affinerez votre code pour finalement créer un code totalement découplé, testable unitairement, plus facile à debugger, à maintenir et à faire évoluer !</div>
<div>
<br /></div>
Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com2tag:blogger.com,1999:blog-4682121385780724362.post-18703705447901397732010-09-03T13:35:00.000+02:002010-09-03T13:35:58.064+02:00Le programme du Forum PHP 2010 est en ligne !Ce rapide petit billet juste pour relayer l'annonce du programme du Forum PHP 2010. Pour mémoire, cette édition sera l'occasion de fêter les 10 de l'AFUP ainsi que les 15 ans de PHP. On ne sait pas encore si on fera un gâteau avec 25 bougies ou deux séparés :)<br />
<br />
Mais du côté des cadeaux, on a déjà fait le plein avec des conférenciers de qualité, et il va de soi que je ne parle pas de moi :) Je pense plutôt à Rasmus Lerdorf ou encore Jonathan Wage, Fabien Potencier, etc.<br />
<br />
Bref, je vous invite à juger vous-même, et à réserver vos places si ce n'est déjà fait !<br />
<br />
http://afup.org/pages/forumphp2010/deroulement.phpGauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com2tag:blogger.com,1999:blog-4682121385780724362.post-31847864300010770512010-08-18T23:14:00.000+02:002010-08-18T23:14:15.172+02:00L'humilité, la première des bonnes pratiques ?Je ne peux pas croire que je sois le seul à qui il arrive, en relisant un code produit par quelqu'un d'autre, de me dire "<b>mais qu'est-ce qu'il a bien pu lui passer par la tête pour écrire quelque chose d'aussi absurde ?</b>". <div><br />
</div><div>A cette question, que je me suis tant de fois posée, et souvent en termes nettement moins châtiés, j'hésite souvent à apporter l'une des trois réponses suivantes :</div><div><br />
</div><div><b>1. Il était contraint par les délais...</b></div><div><br />
</div><div>C'est la raison la plus souvent invoquée pour justifier un travail bâclé. Mais l'excuse ne tient pas dès lors que l'on admet que négliger une partie d'un projet, si infime soit-elle, conduira nécessairement à de bien plus lourdes pertes de temps ultérieurement. En effet, un élément du système qui serait soit mal conçu, soit mal réalisé, ou encore mal voire pas testé, bloquera la mécanique tôt ou tard, et rendra d'autant plus difficile l'identification et la correction des problèmes engendrés.</div><div><br />
</div><div>Si l'on n'a pas de temps à perdre, on ne peut s'offrir le luxe de l'improvisation, et c'est précisément dans ce contexte que le respect des bonnes pratiques s'impose plus que jamais. Je pense très clairement qu'il faut, en tant que développeur, avoir l'humilité de ne pas penser que l'on peut faire son travail correctement au mépris de toute bonne pratique. Notez au passage que le développement est bien l'un des rares métiers dans lesquels on tolère ce genre d'attitudes. Un cuisinier qui déciderait de cuire un tournedos au micro-ondes pour gérer un afflux de commandes trop important se verra inviter à rendre son tablier sur-le-champ ! Le délai est une contrainte, mais pas la seule. La qualité est autrement plus importante, car elle conditionne notre capacité à continuer de s'adapter aux délais à plus long terme. Sans oublier la confiance qu'elle permet d'établir puis de maintenir avec les donneurs d'ordre.</div><div><br />
</div><div><b>2. Il ne savait pas faire autrement...</b></div><div><br />
</div><div>Le manque de maîtrise des outils et méthodes nécessaires à la réalisation des projets est également un grand classique. A cela il peut y avoir plusieurs raisons. Certains manquent tout simplement d'intérêt pour leur métier, d'autres de discernement quant à leur compétence, et ne se rendent pas vraiment compte qu'ils ne savent pas faire. Dans le premier cas, je ne vois guère de remède. </div><div><br />
</div><div>Pour les autres, prendre quelques minutes après coup pour s'interroger sur ce que l'on vient de faire, avec un peu de recul, et se forcer toujours à se demander s'il n'y aurait pas d'autres façon d'y parvenir, suffit le plus souvent à corriger dès le début un travail qui sinon ne le sera jamais, et polluera l'ensemble de manière définitive. Solliciter des collègues est également un bon moyen, au travers d'un regard extérieur, de valider ou non ses choix. Enfin, il ne faut jamais hésiter à reconnaître ses lacunes, ou au moins à les envisager (on a parfois de bonnes surprises !), et à exiger d'être formé sur les outils que l'on nous demande d'employer. Je pense particulièrement aux frameworks : des responsables prennent parfois la bonne décision de baser les développements sur un framework sans l'accompagner de l'excellente initiative d'y former ses équipes. Un développeur est supposé connaître un langage. Maîtriser un framework, même s'il est basé sur ce langage qu'il connait, n'est pas évident, et surtout pas inné. Une formation est un bon moyen d'en prendre possession rapidement, sans contracter de mauvaises habitudes par simple manque de connaissances, que l'on ne peut pas inventer !</div><div><br />
</div><div><b>3. Il n'est pas développeur, il est soudeur à l'arc</b></div><div><br />
</div><div>Ceci expliquant cela... </div><div><br />
</div><div><b>Conclusion</b></div><div><br />
</div><div>Trêve de plaisanterie, aborder son métier avec humilité me semble être une nécessité absolue si l'on a la naïve mais essentielle ambition de continuer de progresser. Etre humble ne signifie pas douter de soi, et encore moins s'imposer de penser que ce que l'on fait n'est pas bon. Cela signifie être conscient que l'on peut toujours se tromper, et qu'il faut rester vigilant. Qu'il ne faut jamais douter que d'autres peuvent avoir une meilleure approche d'un problème, et se réjouir d'en profiter plutôt que de se morfondre de n'y avoir pas pensé soi-même, ou pire, rejeter en bloc et n'en faire qu'à sa tête. </div><div><br />
</div><div>Enfin, être humble dans le développement, c'est aussi se rappeler que ce que l'on fait n'est pas une fin en soi, mais a pour vocation de soutenir un activité commerciale, associative, éducative... En gardant cela à l'esprit, on évite plus facilement de tomber dans le piège du "troll", ces fameux débats stériles et partisans infiniment nuisibles à la qualité du travail produit, mais aussi aux conditions dans lesquelles on le fait !</div>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com4tag:blogger.com,1999:blog-4682121385780724362.post-86244869166413625072010-08-17T23:31:00.000+02:002010-08-18T23:15:30.762+02:00france.frBon je fais court, très court même. Mais après avoir longtemps résisté, tant c'était facile, et de fait presque indigne, je craque.<br />
<br />
On pourrait croire que je n'assume pas mon billet sur Drupal (et tout le mal que j'en pense, pour résumer à l'attention de ceux qui ne l'auraient pas lu) si je ne faisais pas la moindre référence au délicieux fiasco qu'a été le lancement (et qui sait, peut-être le développement aussi ?) de <a href="http://www.france.fr/">www.france.fr</a>.<br />
<br />
Pour être honnête, je ne me suis pas plus intéressé que ça à ce dossier. J'ai simplement entendu beaucoup de monde railler abondamment les services de l'Etat avant de découvrir, par hasard soit dit en passant, que ce site avait été développé avec Drupal.<br />
<br />
Je n'ai qu'une chose à dire : CQFD !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com4tag:blogger.com,1999:blog-4682121385780724362.post-78821712305042860872010-08-17T23:00:00.000+02:002010-08-17T23:00:32.372+02:00Série d'interviews sur PHP6A l'initiative de mon camarade de jeu <a href="http://blog.mageekbox.net/">Frédéric Hardy</a>, une série de plusieurs interviews sur l'avenir de PHP 6 a été publiée sur son blog personnel, que je qualifierais volontiers de professionnel.<br />
<br />
Il m'a fait la gentillesse de solliciter <a href="http://blog.mageekbox.net/?post/2010/08/09/L-avenir-de-PHP-vu-par-Gauthier-Delamarre">mon point de vue</a> sur la question, aussi je souhaitais faire connaitre cette publication car elle me semble tirer le débat un peu vers le haut, et nous donner l'occasion de réfléchir d'une manière un peu plus objective sur l'avenir de PHP.<br />
<br />
Bien que je me pose moi-même la question depuis un moment, et qu'il me soit arrivé de m'exprimer sur le sujet, je me suis rendu compte en répondant aux questions de Frédéric à quel point nous pouvions parfois, en tant qu'utilisateurs (entendez "développeurs" naturellement), être très éloigné de la façon dont la plateforme évolue.<br />
<br />
Alors j'espère que la lecture de <a href="http://blog.mageekbox.net/?category/PHP-X">ces différentes interviews</a> vous amènera vous aussi à vous interroger plus avant sur l'implication que nous pouvons avoir dans l'évolution de PHP, en tant que professionnels aussi bien que de passionnés.<br />
<br />
Pour ma part, j'en suis arrivé à la conclusion que JFK, qui n'en savait pourtant rien, avait déjà bien résumé la situation, du moins si on s'autorise à le paraphraser : "ne te demande pas ce que PHP peut faire pour toi, mais demande-toi ce que tu peux faire pour PHP".Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-89077820421340640452010-06-16T14:06:00.001+02:002010-07-02T02:11:29.591+02:00Pourquoi je déteste Drupal (et la plupart des autres CMS)Voilà quelque temps que je me retrouve régulièrement empêtré dans des débats stériles concernant les CMS (système de gestion de contenus prêt-à-l'emploi) en PHP, et particulièrement Drupal, auquel j'ai été confronté lors de missions chez différents clients, et dont la popularité le désigne tout naturellement comme bouc-émissaire de premier choix pour traiter du mirage que sont les promesses des CMS.<br />
<br />
Je vais donc tenter dans ce post de résumer les raisons objectives pour lesquelles je n'accepte plus de travailler sur des projets basés sur cet environnement. Bien sûr la liste n'est pas exhaustive, mais les problèmes qu'elle pointe sont tels qu'il ne devrait pas être nécessaire d'en ajouter plus. Ces observations sont issues de l'expérience, et dénoncent des défauts qui handicapent réellement les projets. Il faut les prendre pour ce qu'ils sont, à savoir une mise en garde.<br />
<br />
Voici donc les reproches que je peux adresser à Drupal, même si encore une fois ils pourraient s'appliquer à l'essentiel des autres CMS disponibles à l'heure actuelle :<br />
<ol><li>L'approche procédurale<br />
<br />
Les CMS s'adressent principalement à un public de non-développeurs ; autrement dit, au grand public. Celui-ci ayant quasi systématiquement recours aux hébergements mutualisés, lesquels ont très longtemps (et continuent pour certains !) imposé PHP4 à leurs clients, les CMS ont dû se plier à cette contrainte et maintenir une compatibilité totale avec cette version désormais obsolète de PHP, sur laquelle beaucoup ont en plus été conçus, sans que leur design initial n'ait jamais été remis en cause.<br />
<br />
Ceci semble avoir parfaitement satisfait les développeurs de Drupal (ainsi que ceux de sa communauté), qui sont dans l'ensemble très fâchés avec le développement objet. Songez que l'un des seuls objets core de Drupal est le node (concept absolument central de Drupal), qui n'est autre qu'une bête StdClass !<br />
<br />
Je suis même tombé (merci Alex !) sur un article d'un évangéliste Drupal qui nous explique avec le plus grand sérieux que l'absence de classes dans le design de Drupal est un choix délibéré, mais que cela n'empêche pas Drupal d'appliquer la majorité des concepts du paradigme objet. Encore plus savoureux, il nous est exposé la thèse suivante : en se gardant d'utiliser les objets, il a été possible aux développeurs Drupal d'implémenter des concepts "encore plus objet" que ce que permet le moteur orienté objet de PHP ! Ca me fait penser à ceux des artistes contemporains qui mettent trente secondes à créer une "oeuvre", puis des années à en théoriser le concept, mais c'est une autre histoire... Bref, pour consulter ce chef-d'oeuvre de mauvaise foi, <a href="http://drupal.org/node/547518">c'est par là</a> !<br />
<br />
Nous pouvons donc constater que ces développeurs sont adeptes de ce que PHP a de plus médiocre à offrir, du fait d'une utilisation sans discernement de sa permissivité, au mépris de toute bonne pratique. Je pense ici notamment à ces fameuses variables globales, à commencer par $user (dont je vous laisse deviner ce qu'elle matérialise...), ainsi qu'au recours à eval(), le honni (encore présent dans Drupal 7, j'ai vérifié) !<br />
<br />
On se retrouve donc confronté à une base de code foisonnant de fonctions par milliers, très fermement couplées entre elles (puisqu'impossibles à redéfinir, naturellement), limitant de fait les personnalisations possibles. Ceci à conduit à la mise au point dans Drupal d'un système de module qui a paradoxalement fait sa renommée. Mais j'y reviendrai dans le point suivant.<br />
</li>
<li>Une modularité très discutable</li>
Drupal offre à ses utilisateurs un aréopage de modules hétéroclites, et surtout très souvent en conflit les uns avec les autres. S'il est juste de dire que des modules existent pour couvrir fonctionnellement de très nombreux besoins concrets, il faut toutefois relativiser la soit disant valeur-ajoutée de cette manne :
<ul><li> le foisonnement en est tel qu'il est souvent long et difficile de sélectionner le plus approprié (étrangement, la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6...)<br />
<br />
</li>
<li> cette vilaine manie qu'ont les développeurs de recourir aux patches pour appliquer leurs modules vous amène très vite à casser toute compatibilité descendante avec les futures versions du CMS, ainsi qu'avec certains autres modules. <br />
<br />
</li>
<li> le recours à l'appel "à l'aveugle" de fonctions via call_user_func(), dans le contexte du mécanisme de hooks, est une plaie du point de vue des performances d'une part (au moins jusqu'à PHP 5.3, dont je ne suis pas certain de la compatibilité avec Drupal par ailleurs), mais aussi et surtout pour la compréhension du flux d'exécution ! C'est bien simple, on n'y comprend rien (point de vue confirmé par d'honnêtes Drupal fan boys...)<br />
</li>
</ul>
<li>Un emploi déraisonnable de la base de données<br />
<br />
Dans Drupal, tout ou presque se passe dans la base de données. Outre que ceci est parfaitement imbécile là encore du point de vue des performances (j'ai souvent vu des pages de sites Drupal nécessiter de 400 à 1000 requêtes SQL pour être générées, le cache n'arrangeant que peu les choses, sans compter les modules qui parfois produisent des requêtes de plusieurs dizaines de secondes), c'est absolument cataclysmique pour les tests (unitaires ou pas), la gestion des versions et des mises en production.<br />
<br />
En effet, les modifications que l'on apporte à un projet sous Drupal sont partagées entre le code et la base de données. Autrement dit, pour tester ce que l'on a fait localement sur un serveur de recette par exemple, il faut synchroniser les bases de données, ce qui n'est pas chose aisée. Bien sûr, cela sera également nécessaire pour que les autres collaborateurs du projet puissent appliquer vos modifications sur leurs environnements locaux. Et une fois de plus sur la production. Et procéder à l'opération inverse pour revenir en arrière, le tout en parfait accord avec le versionning SVN/GIT. Mission quasi impossible.<br />
<br />
Moralité, les développeurs travaillent sur des versions qui ne sont pas identiques, ce qui se révèle être une source intarissable de bugs les plus idiots qui soient.<br />
</li>
</ol><h2><span class="Apple-style-span" style="font-family: inherit;"><span class="Apple-style-span" style="font-size: medium;">Conclusion</span></span></h2>J'en aurais encore beaucoup à dire sur le sujet, mais je préfère partir du principe que si nous ne sommes pas d'accord à ce stade, nous ne le serons jamais, et inversement !<br />
<br />
Je finirai donc en rappelant simplement une fois de plus que les CMS sont conçus uniquement pour un public de non-développeurs, et qu'il ne faut pas y recourir si l'on à la moindre velléité de personnalisation (essayer d'intégrer un véritable workflow à Drupal, on en reparlera...). <br />
<br />
Dans le cas contraire, c'est-à-dire dans tous les projets que l'on peut avoir à gérer dans un contexte professionnel (hors "web agencies de quartier" s'entend), ces CMS sont à proscrire. Ils ne sont pas faits pour vous, même si le succès rencontré auprès d'une foule d'amateurs et de quelques professionnels désoeuvrés leur a laissé croire le contraire.<br />
<br />
Pour un développement sur la base d'un cahier des charges précis, utilisez des frameworks, c'est-à-dire des environnements maîtrisés de bout en bout, lesquels vous fourniront le cadre nécessaire pour écrire un code métier efficace et maintenable, les outils nécessaires à la mise en place d'un véritable cycle de développement, plutôt que l'illusion de vous fournir un code métier "clés en main" (ce qui est, convenons-en, proprement absurde !).Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com122tag:blogger.com,1999:blog-4682121385780724362.post-15212312872344269512010-06-11T11:20:00.001+02:002010-06-11T11:22:38.682+02:00Forum PHP 2010 : Appel à conférenciers !En attendant un contenu propre qui reste en perpétuelle préparation, je me devais de le relayer ce communiqué de presse de l'AFUP, qui enjoint tous les experts PHP de la planète (non, je n'exagère pas :)) à soumettre des sujets de conférence pour le prochain Forum PHP, qui se tiendra le 9 et 10 Novembre 2010 à la Cité de Sciences de La Villette (Paris).<br />
<br />
Voici le texte intégral, que vous pourrez également retrouver sur : <a href="http://afup.org/pages/site/?route=actualites/412/experts-php-participez-au-forum-php-2010">http://afup.org/pages/site/?route=actualites/412/experts-php-participez-au-forum-php-2010</a><br />
<br /><br /><br /><br /><br />
<br />
<blockquote>Experts PHP : participez au Forum PHP 2010 !<br /><br /><br />
A l'occasion de cet anniversaire, l'Association Française des Utilisateurs de PHP organise un Forum plus ambitieux que jamais, prévoyant de nombreuses conférences et débats, ainsi qu'un espace d'exposition pour les équipes de projets libres souhaitant venir à la rencontre d'un public de professionnels (développeurs, décideurs, presse...).<br /><br /><br />
Vous êtes expert sur un domaine, vous avez installé une ou plusieurs applications PHP (CMS, e-commerce, CRM, GED) dans un contexte spécifique (forte charge, client reconnu, projet innovant) ou bien vous participez à un projet Open Source lié à PHP, venez partager votre expérience !<br /><br /><br />
Pour l'édition 2010, les thèmes particulièrement mis en lumière seront les suivants :<br /><br /><br />
* PHP de A à Z : Débuter en PHP, Réussir un projet avec PHP, Choisir son hébergement<br /><br /><br />
* Outils basés sur PHP : CMS et CMF, outils de e-commerce et de business, paiement en ligne, CRM et ERP<br /><br /><br />
* Industrialisation de PHP : Performances, tests, authentification centralisée, frameworks<br /><br /><br />
* Technologies autour de PHP (Javascript, HTML 5, microformats)<br /><br /><br />
Pour soumettre votre sujet de conférence, rendez-vous surhttp://afup.org/pages/forumphp2010/appel-a-conferenciers.php et complétez une demande en ligne avant le 30 Juin 2010.<br /><br /><br />
Vous souhaitez traiter un autre thème ? Vous n'avez pas d'expérience en tant que conférencier ? Vous souhaitez des renseignements sur la logistique que nécessite votre participation au Forum ?<br /><br /><br />
Contactez Sarah sur organisation@afup.org</blockquote>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com0tag:blogger.com,1999:blog-4682121385780724362.post-42775740335676071412010-01-17T19:15:00.001+01:002010-01-17T19:30:08.141+01:00Solr : le SQL killer pour la rechercheCeux qui connaissent le Zend Framework et qui ont été confronté à la problématique de mettre ne place un moteur de recherche sur un site ou une application ont certainement eu ne serait-ce que la curiosité de regarder de près Zend_Search_Lucene. Ce composant est une réécriture de Java Lucene, excellent moteur de recherche full-text (entre autre) développé et maintenu par la fondation Apache.<br />
<br />
Le portage en PHP est parfaitement compatible au niveau binaire avec son homologue Java. Au niveau binaire signifie, en l'espèce, qu'il est capable d'interroger des index créés avec la version Java de Lucene, et qu'inversement, Java Lucene peut travailler avec les index créés par Zend_Search_Lucene. Et ces index sont stockés dans un format binaire, pour améliorer les performances.<br />
<br />
Et c'est précisément là que le bât blesse dans la version PHP de Lucene... si vous avez non seulement regardé de près, mais aussi testé un minimum, avec un jeu de données réaliste, vous vous serez sans doute rendu compte que dès que l'on atteint quelques dizaines de milliers d'entrées dans l'index, ce n'est clairement plus utilisable.<br />
<br />
C'est donc là que Solr intervient. Solr est une application Java à déployer sur un serveur d'application type Tomcat (ou encore Jetty, par ailleurs fourni avec l'archive). Son déploiement n'est d'ailleurs pas exactement trivial, du moins pour un habitué de PHP comme je le suis. Mais passons, j'ai tout de même réussi à m'en sortir sans trop de difficultés.<br />
<br />
Pour un usage "basique" (mais déjà très impressionnant), peu d'étapes suffisent avant une réelle possibilité d'exploitation.<br />
<br />
La première consiste à définir les caractéristiques de son index. Cela se passe dans un fichier XML, qui a l'avantage d'être fourni avec non-seulement un exemple de schéma, mais aussi et surtout de très abondant commentaires, qui constituent par ailleurs l'essentiel de la documentation sur le sujet (ce que l'on peut au passage déplorer, mais bon, imaginons que ça suivra). Définir son index ressemble approximativement à designer une table de base de données. Cela dit, il y a naturellement certaines différences fondamentales.<br />
<br />
Parmi les premières notions à acquérir, il y a pas mal de jargon... les notions de "document", de "field types", "fields", "tokenizer"... qui nous sont le plus souvent familières, mais pas nécessairement selon les mêmes acceptions que celles retenues dans Solr/Lucene. Mais là encore, cela s'acquiert très vite. Déjà, quand on a retenu que Document (Solr) = Row (SQL), on a fait du chemin :)<br />
<br />
Bref, une fois le schéma défini, on peut commencer de charger des données dans l'index (après avoir simplement redémarré Solr). L'alimentation de l'index, comme la plupart de opérations que l'on réalise sur Solr, se fait via un pseudo service web. En fait, il suffit d'appeler une URL, qui varie selon l'opération qui nous intéresse, et de lui adjoindre d'éventuels paramètres directement dans la "query string" (type ?param=value&otherParam=otherValue). Un peu finalement comme on le ferait pour appeler les différentes actions d'un contrôleur dans une application MVC.<br />
<br />
Les actions principales avec Solr sont select (effectuer une recherche), update (ajouter/mettre à jour des documents), et admin (pour accéder à l'interface d'admin, qui, attention n'est pas protégée par défaut !).<br />
<br />
Ce billet n'étant pas un tutoriel à proprement parler, je ne résisterai à la tentation de rentrer trop dans les détails, mais je conclurai en listant quelques unes des fonctionnalités de Solr, afin de vous inciter à aller télécharger le package et à suivre le getting started pour vous convaincre que Solr est une mine d'or pour qui a besoin d'un service de recherche évolué, et somme toute d'une simplicité déconcertante à mettre en place (comparée à la complexité et à la lourdeur des requêtes SQL qu'il faudrait écrire pour s'en passer, sans même parler du degré de pertinence infiniment moindre avec cette deuxième solution) :<br />
<br />
- recherche ultra rapide sur un serveur standard, y compris sur des index allant jusqu'à +/- 1 million de documents<br />
- gestion native et simplissime des facettes de recherche (ajout de &facet=on&facet.field=NOM_CHAMP) pour l'activer<br />
- recherche par similarité<br />
- indices de pertinence natif (mais également personnalisable)<br />
- recherches spatiales (à partir de coordonnées - intégré à la v1.5, disponible en plug-in pour les précédentes)<br />
- différents formats de résultats possibles (json, source php, php sérialisé, XML...)<br />
- possibilité d'effectuer directement une transformation XSLT sur les résultats XML pour retourner du code HTML directement affichable en guise de résultats de recherche<br />
- etc.<br />
<br />
Convaincu ? J'espère :) En tout cas, la suite, <a href="http://lucene.apache.org/solr/">c'est par là</a> !Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com1tag:blogger.com,1999:blog-4682121385780724362.post-28915070481094126052009-12-20T19:44:00.000+01:002009-12-20T19:44:17.305+01:00MacOSX et PHP, la révélation !Alors que ça fait pourtant plusieurs années maintenant que je vois de plus en plus de développeurs passer sur Mac, pendant que dans le même temps les PC m'exaspéraient eux aussi de plus en plus, et pourtant je n'avais pas encore établi le lien de causalité entre les deux phénomènes.<br />
<br />
Ce paradoxe m'est apparu clairement il y a quelques mois maintenant. Je n'ai pourtant succombé que la semaine passée. En effet, j'ai longtemps refréné mes envies d'achat car je craignais franchement de regretter mon achat une fois l'effet "wahouh" dissipé, me disant que finalement, tout ça, ça restait de l'informatique d'ordinateur.<br />
<br />
Et bien non, trois fois non. Les machines d'Apple sont tout simplement incomparables aux PC. Et je tiens à préciser PC, et non Windows. Certes je n'ai jamais eu de plaisir particulier à utiliser le système de Microsoft, sans pour autant tomber dans l'anti-windows bête et méchant. Le problème d'ailleurs, c'est que les systèmes GNU/Linux commençaient aussi (depuis un moment) à me causer la même frustration que les différents Windows : c'est souvent joli, plein de bonnes idées, mais ça ne marche pas très bien, et surtout pas très longtemps. Sans compter que même quand ça marche, il est préférable de ne garder qu'un minimum d'applications simultanément, faute de quoi on s'expose à la sanction suprême : le recours au swap, et là, c'est le drame.<br />
<br />
A ces différents facteurs s'en sont ajoutés deux autres pour m'amener à choisir Mac : un support brillant de la virtualisation et bien sûr la disponibilité native de très nombreux outils de développement, à commencer par ceux que j'utilise le plus : la suite Zend (Studio + Server particulièrement).<br />
<br />
Bref, me voilà donc l'heureux possesseur d'un iMac. Une petite bête ; la plus petite de la gamme en fait, à ceci près que j'ai doublé sa mémoire dès l'achat (pour passer de 4 à 8 Go). Et depuis, c'est le bonheur :)<br />
<br />
C'est bien simple, je n'ai jamais vu de machine aussi réactive. Même avec quatre machines virtuelles en cours d'exécution (deux Ubuntu Server avec 512 Mo de RAM, une autre Desktop avec 2 Go et un Windows Vista lui aussi doté de 2 Go), je ne constate aucun ralentissement notable des applications natives de Mac OS !<br />
<br />
Par comparaison, j'utilise régulièrement une seule de ces quatre VM sur mon laptop Dell (Centrino Duo, 2 Go de RAM) habituellement, et elle est infiniment plus lente :(<br />
<br />
Le propos, vous l'aurez compris, est très clair : si vous n'êtes ni un inconditionnel de Microsoft ni un intransigeant du logiciel libre, et qu'accessoirement, vous souhaitez travailler sur une machine qui tourne bien, qui est plutôt esthétique et très ergonomique (je ne vous ai même pas parlé de la nouvelle Magic Mouse !), aucune hésitation, achetez un Mac !<br />
<br />
Un dernier mot pour ceux qui pensent que c'est cher, je dirai... oui et non. Les iMac c'est franchement peu cher même comparé à PC, ça tient la route. Quand aux portables, certes ils sont plus chers, mais comment dire... bref, le prix ne doit pas être le seul critère de choix, sinon c'est le mauvais achat assuré. Je précise cependant que même le entrées de gamme Mac sont très nettement au-dessus du niveau moyen des PC. A bon entendeur... :)Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com3tag:blogger.com,1999:blog-4682121385780724362.post-61720494093134678362009-11-22T13:30:00.001+01:002009-11-22T13:38:17.803+01:00Debrief Forum PHP 2009 - de l'avenir de PHP...Je n'ai guère trouvé le temps de publier quoi que ce soit depuis un moment, pas même sur l'édition 2009 du Forum PHP de l'AFUP. Pas question cependant de faire moi-même le réumé de ce qui s'est dit et passé, puisque vous trouverez de nombreuses ressources sur le sujet, notamment les slides des diverses conférences, sur <a href="http://www.afup.org/pages/forumphp2009/resumes.php">le site de l'AFUP</a>.<br />
<br />
Je souhaitais en revanche publier une réflexion sur la perception de PHP en entreprise qu'en ont les gens qui sont au coeur de PHP en France (et en Belgique pour certains, ne les oublions pas, nos voisins d'Outre-Quiévrain ayant été nombreux cette année encore à faire le déplacement).<br />
<br />
Deux éléments ressortent particulièrement à mes yeux : d'une part la réelle prise de conscience de la majorité des acteurs quant à l'importance du respect des bonnes pratiques et autres méthodologies éprouvées dans le développement d'applications, comme de sites, en PHP, et d'autre part le sentiment que PHP en entreprise, c'est désormais non seulement crédible, mais également une réalité. La deuxième observation découlant sans aucun doute de la première.<br />
<br />
Naturellement, on ne peut que se réjouir de cette évolution de l'écosystème PHP professionnel, qui se démarque enfin de l'image d'amateurisme, voire de "bidouille" dont a été longtemps entaché la réputation de PHP aux yeux des entreprises, notamment des plus importantes. La qualité des présentations, l'approche des professionnels rencontrés sur place, ainsi que l'omniprésence des termes "industrialisation" et "bonnes pratiques" m'en ont covaincu.<br />
<br />
Je suis donc globalement en accord avec ce constat, mais j'y apporterais un bémol. D'abord parce que cette évolution ne concerne malheureusement pas la totalité de la profession, et ensuite parce qu'il reste de grosses lacunes dans les outils logiciels impliqués par une telle industrialisation du développement en PHP ; je pense tout particulièrement aux solutions de déploiement qui sont encore, n'ayons pas peur des mots, indigentes. En effet, cette problématique absolument critique est aujourd'hui encore très majoritairement adressée par des scripts dans le meilleur des cas, totalement manuellement dans la plupart des situations...<br />
<br />
Cette faiblesse handicape également l'émergence de solutions d'intégration continue, qui sont elles aussi essentielles à la mise en place de nouvelles pratiques plus fiables et efficaces de manière industrielles. Malgré certaines initiatives intéressantes en matière d'intégration continue (comme <a href="http://ci.symfony-project.org/">sismo</a> de Sensio Labs, qui n'est pas encore - à ma connaissance _ disponible publiquement), cette catégorie d'outils n'est pas encore suffisamment pourvue pour PHP.<br />
<br />
Aussi dirais-je en conclusion que s'il est juste de dire que PHP en entreprise est prêt, il faut se rendre compte que nous ne sommes qu'au bas de la pente... il reste du travail, et il faudrait prendre garde à ce que de gros projets ne soient confiés à PHP sans que ne soient appliquées ces pratiques et méthodologies relatives à l'industrialisation qui sont indispensables à leur réussite. Faute de quoi... je crains que des échecs trop retentissant ne ternissent (définitivement ?) la crédibilité de PHP comme plateforme majeure de l'industrie logicielle en entreprise.<br />
<br />
Mais nous n'en sommes pas là, bien au contraire ! Alors le rendez-vous en 2010 pour démontrer que mes craintes étaient infondées, à l'occasion des dix ans de l'AFUP et des 15 ans de PHP - quels meilleurs symboles pour mettre en avant la pérennité de la technologie comme celle de sa communauté ?Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com3tag:blogger.com,1999:blog-4682121385780724362.post-53195076454942085342009-10-11T19:25:00.001+02:002009-10-11T19:27:48.608+02:00Rappels sur la normalisation<b>Qu'est-ce que la normalisation ?</b><br />
<br />
Ce que l'on appelle normalisation (ou "formes normales") en matière de bases de données relationnelles est un ensemble de règles à respecter pour préserver l'intégrité des données (c'est-à-dire la cohérence des relations) tout en limitant les redondances (stockage répété de valeurs identiques).<br />
<br />
On pourrait faire le parallèle entre les formes normales et les design patterns : dans un cas comme dans l'autre, il s'agit de décrire une solution éprouvée à un problème courant. Tous deux permettent de guider la conception (soit de la base, soit d'un programme ou d'une partie d'un programme), laissant au développeur le soin de l'implémentation. <br />
<br />
Outre les deux objectifs principaux cités plus haut (préservation de l'intégrité des données et prévention de la redondance), les formes normales offrent aussi pour avantage, lorsqu'elles sont respectées avec scrupule (mais discernement, nous en reparlerons plus tard) de faciliter la maintenance et la collaboration. En effet, en normalisant ses bases de données, on s'assure que quiconque connaissant les formes normalisées saura les reconnaitre, et comprendre d'autant plus aisément l'organisation des données.<br />
<br />
<b>Les principales formes normales</b><br />
<br />
Une fois n'est pas coutume, ceux qui ne connaissent pas la normalisation vont s'apercevoir que dans les faits, ils la pratiquent déjà, comme la prose de M. Jourdain (on ne se lasse pas de cette référence !). Ceci pour une simple raison : comme beaucoup de bonnes pratiques, la normalisation a été tout d'abord édictée par le bon sens.<br />
<br />
Voici une brève présentation des 3 premières formes normales :<br />
<ul><li><u>1FN (1ère forme normale)</u></li>
<ul><li>La plus élémentaire de toutes, la première forme normale impose que toute donnée soit indivisible (<i>atomique</i>), que la table dispose d'une <b>clé primaire</b>, composée d'une ou plusieurs colonne, et que les données redondantes soient extraites dans leur propre table, disposant d'une clé primaire elle-aussi.</li>
<ul><li>Exemple</li>
<ul><li>employes(<b>secu</b>, date_embauche, nom, prenom)</li>
</ul>
<li>Contre-exemple</li>
<ul><li>employes(<b>secu</b>, ancienneté, nom), où nom servirait à stocker à la fois le nom et le prénom, et poste la définition du poste de l'employé.</li>
</ul>
</ul>
<li>Concrètement, le respect de la première forme normale garantit la possibilité de filtrer, trier et/ou lier une table sur n'importe laquelle de ses colonnes. Dans le contre-exemple, il serait impossible de sélectionner toues les employés portant le même nom sans recourir à un traitement sur la colonne (ex. nom LIKE 'nom_de_famille%'), ce qui n'est ni des plus performants, ni des plus pertinents (imaginez avoir un employé nommé 'Martin' et un autre nommé 'Martinot'...). </li>
<li>Remarquez également que l'on aura préféré stocker la date d'entrée de l'employé dans l'entreprise plutôt que son ancienneté exprimée en durée, tout simplement parce que dans ce dernier cas, une mise-à-jour régulière de l'enregistrement est nécessaire pour maintenir l'exactitude de cette donnée. Ceci constitue une autre règle essentielle de normalisation.</li>
</ul></ul><div><br />
</div><ul><li><u>2FN (2ème forme normale)</u></li>
<ul><li>La respect de la deuxième forme normale implique tout d'abord le respect de la 1ère. Cette règle est valable pour chaque règle ultérieure. La 2FN s'applique aux tables employant des clés composites. Elle prescrit que toutes les données ne faisant pas partie de la clé doivent en dépendre directement (mais pas d'une partie seulement de la clé).</li>
<ul><li>Exemple : </li>
<ul><li>fonctions(<b>departement</b>,<b> poste</b>)</li>
<li>emplacement(departement, batiment)</li>
</ul>
<li>Contre-exemple :</li>
<ul><li>fonctions(<b>departement</b>,<b> poste, </b>batiment)</li>
</ul>
</ul>
<li>En admettant que dans cette société, chaque département se voit attribuer un et un seul bâtiment, respecter la 2NF a entraîné la scission de la table en deux, car l'attribut <i>batiment</i> ne dépendait que d'une partie de la clé (<i>departement</i>) et non pas de la totalité.</li>
</ul></ul><div><br />
</div><ul><li><u>3FN (3ème forme normale)</u></li>
<ul><li>La troisième forme normalisée impose que chaque attribut qui n'est pas une clé dépende de la clé primaire.</li>
<ul><li>Exemple : </li>
<ul><li>employes(<b>secu</b>, nom, date_embauche, prenom, poste)</li>
<li>salaires(<b>poste</b>, <b>ancienneté</b>, salaire)</li>
</ul>
<li>Contre-exemple :</li>
<ul><li>employes(<b>secu</b>, nom, date_embauche, prenom, poste, salaire)</li>
</ul>
</ul>
<li>Ici, on considère que le salaire dépend de l'ancienneté (déduite de la date d'embauche) et du psote occupé. Dans ce cas, pour respecter la 3NF, il nous faut séparer l'information <i>salaire</i> de la table <i>employes </i>car cette information ne dépend pas de la clé (<i>secu</i>) mais d'autres attributs (<i>date_embauche</i> et <i>poste</i>) qui ne font pas partie de la clé primaire.</li>
</ul>
</ul><div><br />
</div><div>Appliquer ces règles de conception à toutes ses tables est le plus souvent une bonne idée. S'il existe d'autres formes normalisées un peu plus complexes, le respect de ses trois là permet déjà de s'assurer d'un maximum de cohérence pour un minimum de redondance, le tout selon une façon standardisée de faire qui devrait grandement faciliter la compréhension de tous les intervenants.<br />
</div><div><br />
</div><div>Bien sûr, on peut redouter que le fait de multiplier le nombre de tables peut avoir un impact négatif sur les performances globales de l'application, et complexifier légèrement l'écriture des requêtes. Si cette observation n'est pas sans fondement, on s'aperçoit souvent à l'usage que des tables designées de façon anarchiques ne sont guère plus performantes, et que les requêtes à écrire pour les interroger sont d'autant plus complexes qu'elles ne répondent pas à des schémas standards. Autrement dit, quelle que soit la façon d'aborder le problème, la conception de bases de données reste un exercice délicat, et dans la plupart des cas, même si l'on est pas convaincu d'emblée, il est préférable de s'en remettre aux règles de normalisation pour éviter de commettre des erreurs dont les conséquences peuvent s'avérer colossales selon l'ampleur des projets !<br />
</div><ul></ul>Gauthierhttp://www.blogger.com/profile/01426092346514000343noreply@blogger.com2