Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

Nous sommes aujourd’hui le premier décembre. Comme tous les ans, c’est le premier jour des calendriers de l’avent. Sur le web, de nombreux calendriers virtuels en profitent pour parler du web sur un principe simple : un jour = un article. Les articles sont généralement écrits par des auteurs de tous bord, et c’est l’occasion de découvrir de nombreux sujets.

Voici une petite liste des calendriers que je connais, et qui parlent de développement web, de prêt ou de loin :

24joursdeweb est le seul que je connaisse. Il parle du web en général, pas d’une techno en particulier. Tous les sujets sont abordés : développement, intégration, UX, accessibilité, bonnes pratiques…

24ways est son pendant en anglais. Même style d’articles, mais en anglais.

UXmas propose des articles sur le thème de l’UX (User eXperience).

24pullrequests fonctionne un peu différement. Il propose aux utilisateurs de contribuer à un projet open source différent chaque jour, en fournissant une plateforme qui incite à faire une pull request par jour.

Plus décalé, The Avengifs propose tous les jours un Gif rigolo.

Si vous connaissez un calendrier qui manque à cette liste, n’hésitez pas à le dire dans les commentaires !

Retours sur le ForumPHP 2014

27 octobre, 2014

Le Forum PHP, c’était la semaine dernière et c’était super bien. Petit compte rendu pour les absents, les liens ramènent vers la page joind.in des conférences.

La théorie, une vision de l’avenir du web

Plusieurs conférences étaient un peu théoriques, dans le sens où elles présentaient une vision du développement et des pratiques qui gravitent autour de manière idéale. Même si le monde réel est plus mitigé, celles auxquelles j’ai pu assister valaient le coup, et je vous les recommande.
Sebastian Bergman (créateur, entre autres, de phpunit), expliquait qu’il y a 4 grands problèmes à faire des applications : la présentation, la persistance, les problématiques bas niveau, et la logique métier. Aujourd’hui, on gère à peu prêt correctement les 3 premiers grâce -entre autre- aux framework, il y a maintenant plein de choses à faire mieux pour améliorer et rendre pérenne la plus importante, la logique métier. Même si la conférence en elle même était un peu passe partout, j’ai trouvé le rappel d’idées qu’on considère implicites pertinent.
William Durand et son analyse des pratiques de tests automatisés m’a mis sur le cul. Thésard sur la question, son état de l’art et sa vision d’où les tests se dirigent et doivent se diriger donnaient vraiment envie de mieux maîtriser la question. Sa présentation contient un paquet de mots-clés et de librairies qui devraient gagner en popularité.
Francois Zaninotto, dans un discours façon homme politique (une idée originale bien menée) présentait une vision selon laquelle les framework full stack vont décliner pour laisser place à plus de micro framework, de micro services, d’API. L’idée, à terme, étant de se rapprocher d’une philosophie à la unix (faire des applications/services ayant un but unique mais le faisant très bien). L’avenir n’est plus à des mono-technologies, mais à l’usage de techno adaptées à des besoins précis : CMS en PHP, api en node, applis mobiles qui consomme ces API. Ce sera entre autre possible grâce à l’interopérabilité permise par l’utilisation d’HTTP, et des groupes de discussion comme php-fig.

Je vous encourage à regarder les conférences lorsqu’elles seront disponibles car il est bien évidemment très difficile de résumer en quelques mots ces conférences riches en idées.

La pratique, c’est à dire la théorie avec du retard et du pragmatisme

J’ai beaucoup apprécié la vision théorique de ces présentations, mais j’ai aussi beaucoup apprécié les retours d’expérience de plusieurs boites présentes. Cela permet de situer l’état de l’industrie par rapport aux visions théoriques, et car cela m’a permis de voir que ce nous faisons dans ma boite tient autant la route que ce qui se fait ailleurs. Au delà du côté « c’est bon pour l’ego », cela m’a surtout permis de voir que où nous n’avons pas de réponses, d’autres sont tout autant dans le brouillard que nous.

La conclusion ? En théorie, on sait faire beaucoup de choses depuis longtemps. En pratique, le temps que les choses soient intégrées dans l’industrie il faut beaucoup de temps, et pas mal de compromis (« The only sure thing about computer science: everything is a tradeoff« , comme le disent certains, et qui se généralise probablement très bien).

Maison du monde parlait des problèmes de régression de leur site e-commerce. Intégrer l’automatisation de la qualité par des tests ne s’est pas fait sans mal, pose de vrais questions d’organisation et est, chez eux, un enjeu permanent.

Les développeurs de L’express expliquaient l’état de leurs recherches sur l’automatisation de déploiement d’environnement de développements grâce à puppet, chef et amazon. Ces outils permettent de gagner en automatisation, et ont une forte valeur ajoutée, mais laisse encore des questions et ont chez eux un coup d’adoption élevé. Répliquer la configuration exacte de prod est compliqué (notamment quand on souhaite également répliquer la base de données quand elle est conséquente, pour reproduire des bugs complexes sans avoir à le faire directement en prod par exemple). Ils n’ont pas de solution pour reproduire les problèmes d’assets (images, uploads) dans les environnements de développement de manière systématique sans avoir à dire « t’inquiète, ça marchera en prod ».

Maxime Valette, fondateur de Viedemerde, expliquait comment ils ont (sur)vécu à l’explosion de viedemerde.fr à ses débuts, à cheval entre les besoins de communication pour répondre aux journalistes, et les besoins démentiels d’infrastructure auxquels ils n’étaient pas du tout préparé (en pour lesquels le temps possible de mise en place d’une solution se chiffrait en heures). Bref ça a plus parlé de survie que de qualité, mais cela montrait clairement que la qualité de code n’empêche pas du tout un site de survivre à des très gros volumes de visite (comme le dit Jeff Atwood, hardware is cheap).

Les vieux de la vieille

C’est assez inévitable avec un langage qui a plus de 15 ans et qui est le plus déployé dans le monde, des présentations sur les CMS les plus répandus présentaient leur situation courante et l’avenir.
Je ne suis pas utilisateur, mais ça a permis de voir que là où EzPublish et Drupal ont récemment fait le choix de la refonte pour tenir dans le temps, WordPress préfère conserver la rétrocompatibilité en ne touchant pas au core. On verra bien ce que cela donnera dans les années à venir : wordpress a le volume, les autres ont maintenant une meilleure qualité de code, mais ça n’est pas forcément pertinent et nécessaire pour mieux pénétrer le marché…

Les API à l’honneur

Les micro services et API avaient le vent en poupe lors du forum. Plusieurs conférences en parlaient et il y a notamment eu 2 retours d’expérience sur le sujet, l’une faite par les gens d’Elao expliquant tous les problèmes qu’ils ont eu et auquel on peut s’attendre d’être confrontés un jour ou l’autre lorsqu’on cherche à mettre en place une architecture d’api orientée micro services. La présentation était assez macro, et présentait les problématiques de communication, d’infrastructure, de sécurité, de monitoring, de cache…
L’autre, présentée par quelqu’un de l’équipe d’Arte rentrait plus dans les détails, avec quelques bouts de code sur comment ils avaient pu résoudre certains problèmes. Les deux donnaient des idées à des niveaux différents et sont complémentaires.

De nouveaux usages

Les conférences parlaient aussi de « nouveaux » usages, des usages pas encore tout à fait répandus dans la communauté.

Je parle beaucoup d’API, quelqu’un de chez Lemonde est venu expliquer comment ils ont intégré du nodeJS dans leur pile applicative lors de la refonte de leur CMS, notamment pour exposer une API consommé par une application javascript monopage.

J’ai beaucoup aimé sa remarque « Considérez vous comme des développeurs avant d’être des développeurs PHP ». Merci ! Il faudrait l’imprimer en immense et l’afficher dans toutes les boites. Ca marche également avec « vous êtes des développeurs avant d’être des développeurs web ». Cette idée a l’air simple mais en pratique, c’est parce que des gens ont regardé ce qu’il se faisait ailleurs, notamment dans les applis clients lourd, que les bonnes pratiques du génie logiciel (tests automatisés, injection de dépendances par exemple) ont fini par arriver dans le monde du PHP. Ca a toutefois mis beaucoup de temps et PHP (et le web en général) continue d’avoir du retard. Bref, cette conférence était l’application directe de l’idée de Francois Zaninotto, selon laquelle nous arrivions sur plus d’interopérabilité grâce à HTTP, et à l’utilisateur d’outils spécifiques pour des besoins précis.

Une autre série d’outils que j’ai pu découvrir, ce sont les outils d’analyse de code. Scrutinizer, ainsi que qu’Insight de SensioLabs permettent de voir le code qui ne respecte pas des règles élémentaires (le passage de paramètres get directement dans les requêtes SQL, donc source d’injection par exemple), même dans des configurations complexes. Leur force, c’est leur utilisation en SaaS, intégrée avec Github, qui ouvre des perspectives intéressantes.

Une conférence présentait également une idée assez intéressante: l’utilisation de diffbot pour concevoir des API pour ses propres besoins. Basé sur du scraping de page intelligent, on peut se créer sa propre API pour des sites qui n’en proposent pas, par exemple pour sortir de manière automatique la liste des articles publiés par une personne sur un site éditorial, pour par la suite automatiser des tâches (en faisant des graphes de fréquence de publication) de suivi.

J’ai eu l’impression que ça n’a pas intéressé grand monde, peut-être l’intérêt pour les développeurs est moins immédiat que dans d’autres sujet. C’est pourtant hyper disruptif et je suis convaincu que ça va gagner en popularité d’ici peu avec les avancées et les nouveaux besoins amenés par le big data (ça y est, moi aussi je me mets à parler comme un chef de projet d’agence digitale).

La conférence en elle même

La conférence a bien marché, l’organisation était top. Les speakers, pour beaucoup très connus dans la communauté étaient évidemment très compétents. Les sujets étaient généralement pointus, ce qui permet de ramener plusieurs idées et pas mal de motivation pour faire mieux chez soi…

Une seule conférence m’a franchement déçue, celle de Dayle Reese. Il devait parler de Laravel, mais après avoir parlé 15mn de lui s’est trouvé à court de temps. J’y suis allé pour découvrir la philosophie de ce framework controversé (et, ironiquement, qui semble pratiquer le culte de la personnalité derrière son gourou, Taylor Otwell), je ne suis pas plus avancé, et n’ai aucune envie de creuser plus la question, dommage.

Au niveau du fonctionnement, il y avait simultanément deux conférences, ce qui permettait de choisir les thématiques qui nous intéressaient (ou, parfois, de devoir faire un choix terrible !). L’horloge était bien gérée par l’équipe d’organisation, il n’y a presque pas eu de retards et c’était vraiment bien pour ne pas louper de présentation. Une gestion rigoureuse du temps n’est pas la norme dans les conférences alors que c’est pourtant essentiel, c’était donc cool d’avoir bien géré ça.

Le seul bémol, c’est le manque de places parfois pour certaines conférences. Il fallait arriver en avance pour certaines conférence afin d’avoir une place assise, pour des histoires de sécurité, le personnel du beffroi était intransigeant sur la question. C’est d’autant plus dommage pour la table ronde finale, seul événement à ce moment là… il n’y avait pas de places pour tout le monde, et arrivant parmi les derniers, l’accès à la salle m’a été refusé car il ne restait plus de places assises. Dommage pour moi. Même si c’est un signe positif pour l’événement qui marche très bien et pour la communauté qui n’a pas fini de faire des trucs sympa, vu le prix des places c’est pas super cool.

Evidemment, cet article bien trop long met de côté la moitié des conférences, et ne parle pas des ateliers vu que je n’ai participé à aucun d’entre eux. Et si le sujet des API m’a marqué car il m’intéresse, il est probable que chacun soit revenu avec des idées différentes. Quoi qu’il en soit, c’était très chouette et si vous n’y étiez pas, je vous conseille de regarder les slides des présentations. Si vous n’en pouvez plus d’attendre les vidéos officielles, rabattez vous sur la video officieuse du karaoké slideshow 🙂

La semaine dernière, j’ai gagné une entrée à la conférence JS.Everywhere grâce à un article sur RudeBaguette. Merci aux organisateurs de m’avoir donné cette opportunité de participer. Le planning était alléchant et je n’ai pas été déçu, que ce soit par les conférences ou par le salon en lui même. Il y a avait de plus quelques pointures du web, comme par exemple Douglas Crockford (évangéliste célèbre du Javascript) et Tristan Nitot (fondateur de Mozilla Europe).

Au niveau logistique, tout s’est bien passé : les conférences avaient lieu au Tapis Rouge, un hotel plutôt classe dans le Xe, à Paris. La nourriture et les cafés n’ont pas manqués toute la journée. Les conférences étaient à l’heure, et elles se sont toutes globalement bien déroulés (à 2-3 soucis techniques près, comme toujours). Les écrans étaient gros, on y voyait bien, et on entendait bien les conférenciers. Bref sur le plan pratique, félicitation aux organisateurs qui pourront difficilement faire mieux.

Au niveau des conférences, c’était très bon également. Certaines étaient pour tout le monde, mais pour la majorité des autres, il fallait choisir une conférence parmi 4. Toutes ne m’intéressaient pas, mais j’ai parfois regretté de ne pas avoir le don d’ubiquité. J’ai choisi de faire des conférence sur un peu tous les sujets : scalabilité, applis mobiles, sécurité, bonnes pratiques…

Qu’en retenir ? Le mieux c’est de vous parler un peu des conférences auxquelles j’ai assisté. Je ne suis clairement pas un expert sur tous les sujets, autant le dire tout de suite. Mais c’est l’occasion de faire un tour d’horizon de ce qui se passe dans plusieurs domaines.  Lire la suite »

Doctrine, l’ORM de base de Symfony2

Préfixer une table de base de données est, de manière générale, une mauvaise pratique. Souvent parce que cela signifie qu’on cherche à faire cohabiter 2 applications différentes sur une même base de données, ce qui n’est pas une bonne chose du point de vue architecture et séparation des responsabilités (SoC, Separation of Concerns). Dans ce cas, il est largement accepté d’avoir chaque application sur une base séparée, et c’est d’une manière générale la méthode préconisée.

Maintenant, il arrive des cas où il est utile de pouvoir préfixer ses tables. Par exemple parce que c’est la convention requise, ou bien parce que les 2 applications sont 2 parties d’un même tout (par exemple une application Symfony pour le coeur métier, et un WordPress pour la partie blog). Préfixer les tables permet alors d’éviter les collisions de noms.

Lire la suite »

Silex, micro framework PHP

Silex, un micro framework PHP

Cela fait en effet un moment que j’ai envie de réécrire ma page KeiruaProd, afin qu’elle soit conçue à partir d’une base de code bien propre. Il n’y a que quelques pages statiques à l’heure actuelle, mais j’ai 2-3 idées d’évolutions dans les cartons, ce qui est une bonne occasion de repartir sur une base saine sur tous les plans (back et front).

Mes besoins sont simples :
– du code propre, léger, maintenable, respectueux des standards
– séparation front/back
– apprendre, tester des outils
– évolutivité

Ma recherche d’outils adaptés s’est arrêtée sur 2 outils : Silex pour le PHP, et HTML5 Boilerplate pour le code front.

Ca va être l’occasion de vous en parler !

Lire la suite »

Vous connaissez sans doute FOSUserBundle, un des bundle les plus connus et utilisés de Symfony2. Il permet de gérer l’enregistrement et l’authentification de vos utilisateurs de manière très simple, ce qui permet de se concentrer sur le code métier des applications.

La documentation du bundle est très complète et bien fournie, mais ne couvre pas un détail : lorsqu’un utilisateur se connecte dans votre application (avec son login/mot de passe par exemple), si l’authentification réussit, alors l’utilisateur est redirigé vers la page d’accueil.

Mais cela n’est pas forcément ce que l’on souhaite ! On peut vouloir qu’il soit redirigé ailleurs, par exemple vers sa page de profil. Et quand c’est comme ça, on fait comment ? C’est ce que je vais vous expliquer.
Lire la suite »

Permettre à l’utilisateur d’uploader des fichiers est une tâche qui revient régulièrement. Cela peut par exemple permettre à l’utilisateur de mettre en ligne sa photo de profil, ou encore si vous proposez une solution d’hébergement de documents, lui permettre de stocker des fichiers pdf importants.

Dans cet article, nous allons prendre l’exemple de la mise en ligne d’une photo de profil pour vos utilisateurs, et regarder comment implémenter cette fonctionnalité avec Symfony2. Le code utilisé est inspiré de la page du cookbook associée à ce sujet, mais je vais essayer de détailler un peu plus la procédure afin de faciliter sa compréhension.

Lire la suite »

Cet article fait partie d’une série d’articles d’introduction à Backbone.js, largement inspirée du tutoriel (en anglais) Hello Backbone.js. Les bouts de code du tutoriel original ont été légèrement refactorés.

On va reprendre l’exemple précédent, et le refactorer, afin de déléguer le rendu de notre modèle dans une vue dédiée. Cela va nous permettre de gagner en flexibilité pour manipuler les données au niveau atomique (au niveau des éléments du modèle), ce que nous ferons par la suite. Du point de vue fonctionnalité par contre, rien ne va changer : nous allons simplement améliorer la qualité du code.
Lire la suite »


Fatal error: Call to private method CodeColorer::performHighlightCodeBlock() from context '' in /home/keiruapr/blog/www/wp-content/plugins/codecolorer/codecolorer-core.php on line 70