Ergonomie, Rails et Architecture de l'information web (2.0)

Wordpress 2.5, dont une démo est disponible en ligne apporte son habituel lot de nouveautés, parmi lesquelles une refonte en profondeur de l’administration, organisée autour des fonctionnalités de plus en plus nombreuses et diversifiées du plus populaire des blogware open source. Qu’on aime ou qu’on aime pas – et je rentre depuis longtemps dans la seconde catégorie – force m’est d’avouer que cette nouvelle version est impressionnante.
Plutôt qu’un tour complet de cette nouvelle admin qui ne servirait pas à grand-chose, je vous propose de passer en revue les 9 petits trucs qui vous changent la vie.

Les Open Source CMS Awards 2007, récompenses attribuées aux meilleurs outils de gestion de contenus libres viennent d’être attribués sur le site de l’éditeur britannique Pact Publishing, et j’avoue que certains résultats me laissent sans voix.

Meilleurs CMS de l’année 2007 :

1. Drupal.
2. Joomla.
3. CMS Made Simple.

CMS les plus prometteurs :

1. MODx.
2. TYPOlight (rien à voir avec Typo).
3. dotCMS.

Meilleur CMS développés en PHP :

1. Joomla.
2. Drupal.
3. e107.

Meilleurs CMS n’ayant pas été développés en PHP :

1. mojoPortal.
2. Plone.
3. Silva.

Meilleur CMS à vocation sociale.

1. Wordpress.
2. Drupal.
3. Elgg.

Je viens enfin de finir de dépiler les quelque 27000 billets qui s’étaient pernicieusement accumulés dans mon agrégateur durant les vacances. Plein plein plein de très bonnes choses, dont :

• Design Float est un Digg like consacré uniquement au webdesign. Une mine de ressources pour ceux qui s’intéressent au sujet.
• Deziner Folio. Ils s’étaient fait connaître en offrant au téléchargement plus de 130 styles Photoshop web 2.0 (sic), mais leurs autres ressources sont probablement encore plus intéressantes.
• Six ways to start writing process, chez Lifehack. Six conseils pleins de bon sens pour ceux qui aspirent à écrire un peu sérieusement.
• Ultimate Server-Side Web Development Cheat Sheets, une liste impressionnante de cheat sheets sur les langages web coté serveur : Ruby, PHP, Perl, ASP.net, Python…
• Ultimate Web Development Cheat Sheet Guide, la même que précédemment, mais pour les langages orienté front : Javascript, CSS, XHTML…
• OpenXML is defective by design, 13 fautes de conception critiques qui rendent le format OpenXML bon à jeter.

Les deux animateurs de Railsenvy remettent le couvert avec leurs parodies des films publicitaires d’Apple comparant Ruby on Rails à ses concurrents. À ceux qui leur reprochaient de comparer un framework à des langages, réjouissez-vous, ils vous ont écouté et égratignent cette fois Cake PHP dans un spot qui s’avère être de loin le meilleur de la série.

À mourir de rire… sauf peut-être pour les fans de Cake PHP.

Après Java, c’est au tour de PHP de subir l’humour ravageur de Gregg et Jason, dans une autre parodie des publicités Apple. Et c’est bon !

Je trouve juste dommage qu’ils tournent sous Mephisto quand Typo leur tend les bras…

Chez Matt ce matin, on pouvait lire :

Dreamhost upgrades their servers to PHP 5.2 (newer is better, right?) and most of their PHP5 customers break. WP 2.1 had a lot of workarounds in it just to run under 5.2. That’s stupid. I’m sure there is a perfectly rational reason why PHP core was “forced” to break existing scripts, but constantly shooting your users in the foot isn’t a good way for PHP to stay relevant. (I write this as someone whose entire company and livelihood is based on PHP.)

C’est à dire en bon français :

Dreamhost vient de mettre son PHP à jour vers la version 5.2 (plus c’est neuf, plus c’est bon parait-il), et la majorité de leurs clients sous PHP sont dans les choux. Nous avons du beaucoup batailler afin de faire tourner Wordpress 2.1 sous PHP 5.2. C’est stupide. Je suis certain que l’équipe de PHP avait une excellente raison pour être “forcée” de casser l’existant, mais ce n’est pas en tirant constamment une balle dans le pied de ses utilisateurs que PHP va rester un langage pertinent. (J’écris ceci en tant que personne dont l’entreprise et la vie sont entièrement basés sur PHP).

Je n’irai certainement pas contredire Matt quand il parle de la nécessité d’assurer un minimum de rétrocompatibilité d’une version d’un langage à l’autre. Tout en évoluant constamment, Ruby on Rails a bien compris la problématique en permettant d’inclure la bonne version du framework dans l’application, celle-ci prenant le pas sur la version installée sur le système. Mais venant de quelqu’un qui change les hooks de l’API de plugins de Wordpress entre deux release candidates au point de rendre ces derniers inutilisables, sans prévenir personne, et sans rien documenter, c’est un peu l’hôpital qui se moque de la charité.

Dans le cadre de son développement, Actualys, agence spécialisée dans l’accompagnement des grands comptes dans leurs projets web recrute un développeur PHP expérimenté pour une mission longue durée dans la banque et la finance.

Expert en PHP, vous maîtrisez parfaitement l’environnement LAMP, la programmation orientée objet et les outils de gestion de sources (CVS). Imaginatif et ouvert d’esprit, vous utilisez quotidiennement les méthodes agiles, et plus particulièrement l’eXtrême Programming. Vous serez amené à rejoindre une équipe dynamique au sein d’un grand groupe bancaire pour une mission longue durée autour des problématiques liées aux OPCVM.

Si vous justifiez de 3 ans d’expérience réussie dans les technologies citées et êtes disponible immédiatement, envoyez votre CV à candidat[at]actualys[dot]com.

• Post : CDi / Freelance.
• Disponibilité : immédiate
• Environnement technique : LAMP / Sybase

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

• Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
• Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
• Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.

Le mois de novembre va être particulièrement chargé en termes de rencontres consacrées au web et aux nouvelles technologies, principalement durant les quinze prochains jours. Si vous vous trouvez à Paris, je serai ravi de vous rencontrer à l’occasion des événements suivants :

• À l’apéro organisé en marge du forum PHP, le 9 novembre à partir de 20 heures au pub Kitty O’Sheas, 10 rue des Capucines, 75002 Paris.
• Au septième BarCamp Paris, le 11 novembre de 14 heures à 20 heures, 38 avenue de l’Opéra 75002 Paris, dans les locaux de Google. J’y présenterai les Microformats à travers un cas d’usage précis, bien que n’ayant pas encore décidé lequel.
• Au séminaire du W3C sur le web mobile, le 16 novembre de 9 heures à 13 heures 30 à l’Entrepot, 7-9 rue Francis de Pressensé, 75014 Paris.
• Aux rencontres Paris on Rails le 17 novembre de 9 heures à 18 heures à la Tour Descartes à la Défense.

Si avec tout ça, vous parvenez encore à m’éviter, c’est clairement que vous ne voulez pas me voir.

[edit]
À l’occasion du BarCamp 7, je parlerai à priori de l’utilisation des Microformats et de la publication des données personnelles dans le cadre de l’optimisation de l’efficacité des réseaux sociaux. On dirait un sujet de thèse, ça pète hein ?

Plus sérieusement, pour ceux que ça intéresse et qui ne pourraient pas venir, je mettrai la présentation en ligne… si je trouve le temps de la faire.

Jeff Curnew a adapté mon thèmes manager pour le faire fonctionner sous Wordpress 2.0, ce qui est fort gentil de sa part, puisque je ne l’aurais pas fait moi même :