Si vous comptez venir à l’édition 2012 du Forum PHP et que vous voulez le faire savoir, n’hésitez pas à utiliser le code HTML suivant :

<a href="http://afup.org/pages/forumphp2012/">
  <img src="http://afup.org/templates/forumphp2012/images/bandeau-forum-php-2012-fr-small.jpg" alt="Forum PHP 2012, j'y serai !" />
</a>

Ce qui donne le résultat suivant :

Ce bandeau est aussi disponible en plus grande taille et en anglais :

Et si vous n’avez pas encore réservé vos places, foncez sur la billetterie ! Le programme est très riche, et promet un cru 2012 très intéressant.

Jusque là, nous gérions tout, lancions les idées, les mettions en pratique, …
Toutefois, pour stabiliser le fonctionnement, il devient nécessaire de changer ce fonctionnement pour qu’il repose sur un groupe de personnes.

Quels chantiers ?

Dans cette idée, nous désirons mettre en place des groupes de travail pour les grands chantier :

ApéroPHP du 29

Nous sommes en cours de stabilisation de l’apéro du 29 : le réflexe du 29 de chaque mois commence à donner ses fruits, mais il reste plusieurs point à creuser :
- Travailler sur le lieu de RDV, puisque les essais au café Leffe Terreaux, puis au Ninkasi Sans-soucis et Kafé Berlin ne sont que partiellement convenables, et qu’il faudrait un lieu où il est possible de discuter avec plus de monde que ses voisins directs.
- Organiser chaque mois l’apéro (ajouter l’apéro sur le site, réserver le lieux, communiquer, …)

Ce n’est pas énormément de travail, et je pense que si plusieurs personnes sont partantes, il est même possible que ça ne demande qu’une paire de minute par mois.

Ateliers PHP

Suite au premier atelier qui fut une réelle réussite (guichet fermé, 99% d’inscrits présents, beaucoup de feed-back), il faut continuer dans cette voie.
Il y a déjà quelques idées et quelques contacts pour de futurs ateliers, et je pense qu’il faut au minimum un groupe de travail sur les ateliers (au sens général), quitte à monter un groupe par atelier si nécessaire.

Pour continuer dans cet atelier, les tâches sont les suivantes :
- Prévoir une roadmap des futurs ateliers
- Rechercher des salles, en fonction du nombre de personnes que l’on veut accueillir
- Annoncer les prochains ateliers, gérer les réservations

Conférences

La différence entre Atelier et Conférence réside avant tout dans la taille de l’évènement.
Nous travaillons actuellement à faire venir la conférence « Performance PHP » sur Lyon. Les choses démarrent, mais il semble que cela soit possible.

Il faut donc un groupe de travail pour l’organisation de cette conférence, et c’est le point qui me semble le plus urgent.

Pour réussir à organiser cet évènement, il nous faut désormais :
- Trouver une salle permettant d’accueillir une centaine de personnes
- Gérer la communication et les réservations
- Monter une demande de budget pour le bureau de l’AFUP

Conclusion

Maintenant que nous avons réussi à donner de l’élan à notre antenne locale, il faut continuer sur cette lancée, et s’ouvrir de nouveaux horizons et pour cela, il faut des bonnes âmes.
Comme vous venez de le voir, plusieurs chantiers sont en cours, avec plusieurs types de travail, et je ne doute pas que vous trouverez une occupation qui corresponde à ce que vous savez/pouvez faire.
Nous comptons donc désormais sur vous pour nous épauler dans la vie de l’AFUP Lyon

En quelques mots, mes raisons sont les suivantes :

• -> Cela va faire 6 ans en mars prochain que je travaille pour Prestaconcept, au début comme développeur, mais rapidement avec des responsabilités qui n’ont cessées de s’étendre. Au cours de ces années, j’ai travaillé sur de nombreux projets, dans des domaines très hétéroclites (adserving, VOD, ecommerce, extranet, portails, site vitrine, etravel, …) pour des clients eux aussi très différents. Aujourd’hui, j’ai l’impression de commencer à tourner en rond, de ne plus découvrir.
• -> Je suis aujourd’hui lassé par les contraintes d’une SSII (respect des coûts et des délais imposés par un client non technicien, de devoir réduire des temps pour « passer le budget », de marcher sur la tête pour faire plaisir au client, …)
• -> J’ai besoin d’un vrai challenge, avec des personnes qui sont au moins aussi passionnées que moi
• -> La perspective de travailler pour Eric Daspet, dans un projet extrêmement ambitieux et novateur est plus que stimulant
• -> L’organisation de travail désirée : Agilité, appropriation du projet par l’équipe, temps de R&D prévu, poste de travail en libre choix, …

De ces 6 ans passés chez Prestaconcept, je retiens surtout :

• -> Des patrons formidables, merci Ludovic Mugnier et Cyrille Gaulard pour votre temps, votre pédagogie, votre vision
• -> Une SSII avec un vrai idéal de qualité. Des discussions que je peux avoir avec des employés d’autres SSII lyonnaises, je pense que Prestaconcept reste « haut de gamme » pour une SSII
• -> L’apprentissage. Dans le moule SSII, j’ai découvert beaucoup de techniques, dans pas mal de domaines d’activité

Mais maintenant, j’ai l’esprit tourné vers cette nouvelle aventure, et j’ai retrouvé une envie et une motivation que je ne m’étais pas rendu compte avoir perdu.
Certes, je perd une « situation sociale » puisque je quitte un rôle de manager pour un rôle de développeur. Toutefois, je fais parti de ces gens pour qui il est plus important de s’éclater dans son travail, d’être motivé pour aller au travail plutôt que d’avoir une « situation ».

Voici les actions menées depuis :

L’apéroPHP du 29

Tout les 29, un apéroPHP est organisé. Cette régularité permet d’augmenter la visibilité de ces évènements, et attirer de plus en plus de monde.
Pour le moment, il n’y a pas de lieu de fixe, nous essayons. Je suis toujours à la recherche d’un lieu qui permet de boire un coup, de discuter, de prendre la parole devant tout le monde pour présenter les actions, … mais je n’ai pas encore trouvé la perle rare.

Refonte du site aperophp.net

Tout le monde a dû, à un moment où à un autre, se dire que le site aperophp.net devrait subir un petit lifting.
Eh bien nous avons pris le taureau par les cornes, et le 21 janvier dernier, quelques courageux se sont réunis pour lancer les bases du nouveau site.
Julien Fusco et Gautier Di Folco continuent de travailler sur le site, et le project leader, Martin Supiot, de l’AFUP Nantes, devrait pouvoir annoncer sa mise en ligne d’ici la fin du mois de mars.

Les ateliers PHP

Sur l’exemple de ce que peuvent faire l’AFUP centre, Lille ou Bordeaux, nous démarrons le principe des ateliers PHP.
Le but est de faire une mini-conférence (1h) pour présenter un sujet, déclencher des échanges ou récupérer des retours d’expérience.

Le premier atelier PHP lyonnais aura lieu le 29 février prochain, juste avant l’apéro PHP.
Vous trouverez toutes les informations ici : source officielle

Comme je trouve le sujet intéressant et que j’ai un avis complémentaire, bien que différent, je me permet dont d’écrire cet article pour l’exposer.

Différence entre temps d’exécution et temps de rendu

Pour ma part, je trouve la micro-optimisation assez peu intéressante dans le sens où elle est micro. Cette optimisation se base en tout et pour tout sur le temps d’exécution brut d’un script PHP, en se demandant si je peux gagner 10% en remplaçant tout mes echo par des print, ou alors en utilisant des  » au lieu de ‘.

Sauf que, dans la vie d’une application web, ce temps n’est rien. Pour enfoncer une porte ouverte, le fonctionnement du web se décompose en plusieurs phases :

1. Envoi d’une requête : interroger les serveurs DNS, trouver le serveur et ouvrir une connexion avec lui.
2. Génération de la réponse : le temps d’exécution
3. Téléchargement du résultat : le temps que le HTML généré par le PHP reviennent sur le client
4. Interprétation du résultat : le temps que le navigateur interprète le HTML, découvre les ressources nécessaire au rendu
5. Chargement des ressources annexes (assets) : pour chaque ressource, on repart du début (requête, réponse, téléchargement et interprétation)

Le temps de rendu est l’ensemble des temps nécessaires pour réaliser toutes ces phases.

Prenons l’exemple, au hasard, d’un moteur de recherche bien connu, et analysons le chargement de la page d’accueil :

Analyse du chargement de la homepage

Voici ce que l’on peut apprendre de cette analyse :

• le temps complet de chargement de la page est de 964ms
• la requête initiale (requête, génération, téléchargement du résultat) prend 110ms (95ms de génération du résultat)

Il est donc clair que le temps de rendu (le temps nécessaire pour que l’utilisateur puisse utiliser la page) est 9 fois plus important que le temps d’exécution du script sur le serveur. Du coup, gagner 10% sur le temps d’exécution ne fait gagner que 1% sur le temps de rendu.
Et je parle ici de la page d’accueil de Google, qui optimise beaucoup ses chargements, mais pour d’autres sites, moins optimisé, c’est encore pire dès que le nombre de CSS, de JS ou d’images croît.

Optimisez vos chargements

Pour agir de façon drastiquement efficace sur votre temps de rendu, tant que le temps d’exécution est inférieur à 75% du temps de rendu, c’est du côté du chargement qu’il faut chercher.

Pour agir sur le chargement, j’utilise 2 outils : Page Speed et Yslow. Ces outils se basent sur une liste d’optimisations de chargement de pages web.
Je vous conseille de ne pas chercher à atteindre la perfection sur tout les points, mais c’est une bonne base de travail. Je vous conseille également de travailler avec les 2 outils en parallèle, car ils ne sont pas toujours d’accord, et cela permet de pondérer les conseils de chacun.

Micro-optimisation vs. macro-optimisation

Sur ce point, je suis totalement d’accord avec ZenProg : commencer par ce qui apporte réellement un gain de performance à vos sites !

Par expérience, je sais que lorsqu’un script PHP est lent, il faut commencer par traquer les causes suivantes :

1. Requêtes non optimisées
2. Schéma de base de données non optimisé
3. Requêtes dans des boucles
4. Boucles non optimisées

Requêtes non optimisées

Faire un EXPLAIN PLAN est un minimum vital pour des requêtes un minimum complexe. Dans de (trop) nombreux cas, 80% du temps d’exécution du script est l’oeuvre d’une requête non optimisée qui bloque le PHP

Schéma de base de données non optimisé

Comme le dit ZenProg, un index bien pensé (un index sur le(s) champ(s) sur lequel/lesquels se base les requêtes les plus fréquentes) permet de gagner beaucoup de temps, pour la même raison que pour le point précédent.

Requêtes dans une boucle

L’une des plus grosses fautes de développement, selon moi, c’est de ne pas contrôler les requêtes générées par son code source. Il est très facile de se retrouver dans un cas de figure où une requête est exécutée dans une boucle, surtout avec les frameworks MVC.
Contrôler le nombre de requêtes générées, et travailler sur des données de test réalistes (des dizaines d’enregistrement minimum) permettent donc de se rendre compte quand le nombre de requêtes d’une page semble trop important pour le travail réalisé, et donc se rendre compte qu’on a des requêtes inutiles.

Boucles non optimisées

Je vois trop souvent des algos qui, suite à plusieurs évolutions, se retrouvent avec plusieurs parcours d’un même tableau.
Au final, c’est du temps perdu lors des milliers/millions d’exécution de l’algo, juste parce le développeur n’a pas voulu « perdre » quelques minutes à prendre du recul sur son algo.

La lisibilité du code

Je sais que je sors un peu du sujet, mais je trouve qu’on y perd plus lorsque la micro-optimisation d’un code source rend sa lecture difficile

L’optimisation hors script

Je ne pouvais pas finir cet article portant sur l’optimisation sans parler de l’optimisation que j’appelle « hors site ».
J’entends par là qu’il y a des optimisations qui sont applicables sans se pencher sur un script, mais qui améliorent drastiquement son temps d’exécution :

• Mettre en place un cache d’Opcode (APC, …)
• Mettre en place un cache de rendu

Conclusion

Pour moi, bencher si print est plus efficace que echo, c’est de la masturbation intellectuelle pour la plupart des développeurs web que nous sommes.
Après la démonstration que je viens de vous faire, je pense que le jour où vous en serez réduis à remplacer vos print par des echo dans votre code source pour l’optimiser, c’est que vous aurez des besoins en performance très particulier, et que vous aurez déjà éculé les optimisations que je vous ai listées.

J’ai détecté le soucis en essayant de mettre à jour les ports
sudo port selfupdate
sudo port upgrade outdated


Je suis tombé rapidement sur l’erreur suivante (dans mon cas, c’était sur gettext) :
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for gettext is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/gettext/main.log
Error: Status 1 encountered during processing.
To report a bug, see


Le soucis viens en fait de MacPorts, qui n’est plus adapté au nouvel OS, mais qui ne sais pas se mettre à jour.
Pour résoudre ce soucis, il existe heureusement une explication fournie par MacPort.

Pour information, je n’ai toujours pas migré de Snow Leopard vers Lion, car j’attends les 1er retours avant de me jeter sur la mise à jour.

Mais revenons au sujet : le remplacement de MySQL par PostGreSQL.
Pour ma part, cela fait longtemps que MySQL n’est plus mon SGBD préféré, et je dirais même que j’ai pas mal de choses à lui reprocher, dont la source est toujours la même : sous couvert de simplicité d’utilisation, il ne respecte pas la norme SQL ANSI-92.

• Possibilité d’utiliser des mots-clés réservés pour les tables, colonnes, … en utilisant le « ` »
• Création automatique d’index
• Intégration des dates plus que limitée (tout est converti en timestamp à votre insu)
• tant encore

Je sais bien que vous pourrez me répondre « mais si c’est plus simple à utiliser, où est le mal ? ». Et j’aurais du mal à vous contredire sur ce point.
Mais le soucis est ailleurs, au niveau de la maîtrise.
Non seulement, les milliers (millions ?) de développeurs ayant découvert le SQL avec MySQL apprennent de très mauvaises habitudes, mais les défendent alors même qu’elles sont contraires aux standards.

Le plus marrant, selon moi, est que ce sont ces mêmes personnes qui défendent Mozilla parce que « c’est libre, respectueux des standards, alors que Internet Explorer, non » qui utilisent MySQL (preuve selon moi de l’immense majorité de personnes qui ont adoptés Firefox pour être « hype » et pas par conviction).

Bref, pour en revenir à nouveau au sujet de base, j’utilise PostGreSQL depuis plusieurs années, et j’en pense le plus grand bien : non seulement il est ouvert, en pleine force de l’âge, équipé pour supporter les très gros volumes, permettant l’utilisation de techniques SQL avancées, mais également utilisable rapidement pour des sites à petits volumes, avec des bases de données simples.

Donc, en conclusion, je trouve que cette migration est une très bonne nouvelle pour PostGreSQL, pour augmenter sa visibilité au développeurs amateurs, qui apprennent sur les outils démocratiques.
Et, qui sais, un jour nous aurons une majorité de LAPP (Linux-Apache-PostGreSQL-PHP) au détriment du traditionnel LAMP (Linux-Apache-MySQL-PHP)

Sous l’impulsion de Geoffrey Bachelet, il y a une équipe de motivé, dont je fais parti, qui est composé d’une dizaine de personnes.

Nous sommes en phase de création, on se cherche un peu, mais nous avons déjà de bonnes idées, et des mises en pratique vont suivre dès la rentrée.
Au programme, nous avons :

• Coding party pour recoder le site aperophp.net
• Organisation d’une conférence technique à la rentrée
• Déposer une candidature pour le PHP Tour 2012

Un leitmotiv que nous allons tenter de suivre va être l’ouverture aux autres technologies. Et dans cette voie, nous avons participé il y a quelques temps au Barcamp Lyon 2011, avec des devs Java, JS, Ruby, Microsoft, …
De cet évènement sont ressortis quelques contacts intéressants qui annoncent des collaborations intéressantes. Affaire à suivre

Je suis très content qu’une communauté de développeurs PHP se mette enfin en place sur Lyon je suis très motivé par cette association, et je compte donc m’investir autant que possible dans son activité.

Je suis très heureux que ça bouge enfin

Je sais que je m’y prend un peu tard, puisque l’évènement aura lieu dans moins de 15 jours maintenant, mais le week-end des 25 et 26 juin 2011 se tiendra à Lyon la première Game Dev Party Lyonnaise.

Le principe est simple :
Vous êtes développeur et vous ne savez pas comment utiliser vos compétences ?
Vous avez une super idée de jeu, mais vous n’avez pas le temps/les compétences/la motivation pour la mettre en pratique ?
Rejoignez-vous pour 48h, et pour aller le plus loin possible dans la réalisation de cette idée.

Le lieu est également sympa puisque ça sera l’atelier des médias

Je m’étais inscrit parce que le challenge m’intéressais beaucoup, mais des obligations familiales font que je serais dans le sud ce week-end là.

Ce projet, en plus d’être très prometteur, est dans une phase de développement très forte, et toujours en version beta, ce qui implique que de nouvelles versions sortent très régulièrement (15 versions depuis le début de l’année 2011, dont une version majeure).
La principale conséquence est qu’il est à la fois difficile d’être toujours à jour, mais également qu’un code peut ne plus fonctionner du jour au lendemain.
Heureusement, dans ce genre de technos très dans le vent, il existe toujours une solution.

L’astuce du jour s’appelle n. C’est un package qui permet d’installer/activer/supprimer rapidement et facilement n’importe quelle version de node.js, en permettant à plusieurs versions de cohabiter.

Installation

n s’installe très facilement grâce à npm :
sudo npm install -g n

C’est tout. Il y a pire me direz vous.

EDIT : comme me le fait remarquer Naholyr dans les commentaires, la version actuelle de npm demande l’option « -g » pour une installation globale

Utilisation

n permet de consulter les versions de node installer, d’en ajouter, de changer la version utilisée, de supprimer des versions inutiles, ou d’installer rapidement la dernière version disponible :

Voir les versions installées

Cette commande affiche la liste des versions de node installées
mrandy:~$ n
0.4.6
ο 0.4.7


Activer/installer une version de node.js

Imaginons que vous avez besoin d’installer node.js v0.3.8 (dernière version 0.3) pour exécuter un de vos codes
mrandy:~$ sudo n 0.4.6
mrandy:~$ n
ο 0.4.6
0.4.7

Cette commande va modifier la version active de node (celle appelée par défaut).
Dans le cas où la version demandée n’était pas installée, cette commande va télécharger les sources, les compiler, installer la version et l’activer :
mrandy:~$ sudo n 0.4.0
[...]
mrandy:~$ n
ο 0.4.0
0.4.6
0.4.7


Installer la version la plus récente

Seulement voilà, sur un projet aussi dynamique, on ne sait jamais si on a la dernière version ou pas.
Heureusement, n gère ce cas puisque la commande « n latest » est un alias pour la dernière version disponible.
mrandy:~$ sudo n latest
[...]
mrandy:~$ n
0.4.0
0.4.6
0.4.7
ο 0.4.8


Supprimer une version de node

C’est bien joli tout ça, mais au bout d’un moment, on se retrouve avec plus d’une dizaine de versions installée, et c’est un peu le boxon pour un psychorigide comme moi.
Mais rassurez-vous, là aussi, n a tout prévu :

mrandy:~$ sudo n rm 0.4.0
[...]
mrandy:~$ n
0.4.6
0.4.7
ο 0.4.8


Et tout le reste


n help // affiche la liste des commandes de n
n use 0.4.7 // Execute node avec la version donnée (activation one shot)
n bin 0.4.7 // Affiche le chemin vers l'exécutable de la version donnée
n ls // Affiche la liste des versions de node.js disponible, en indiquant lesquelles sont installée