@pivwan T'en as pas marre d'utiliser des saloperies en PHP?

-- Nikkau (@Nikkau) December 18, 2013

Paradoxalement non, je n'en ai pas marre. Pourquoi ? Probablement parce que je considère PHP comme le langage le plus approprié pour gérer un simple site web avec une base de données bête et méchante.

PHP c'est tout pourri et surtout on fait de la merde avec...

J'entends tout à fait cet argument. Cependant, le mot PHP peut être remplacé n'importe quel langage et ce sera la même chose. Je suis très volontiers d'accord avec le fait que des codes PHP immondes pullulent encore et participent à cet état de fait. Cependant :

1. C'est un langage simple pour faire des choses simples. il est possible de faire de grandes choses mais cela implique d'avoir une équipe très compétente.
2. Oui, c'est un joyeux foutoir dans les nommages de fonctions (genre les chaînes de caractères & mbstring) mais il faut se rappeler que les objets & namespaces ne sont pas des concepts présents dès la conception du langage. L'arrivée des namespaces a, à mon sens, très fortement contribué à rationaliser tout cela.
3. La compatibilité descendante. On pourra dire ce que l'on veut, mais PHP doit faire partie des langages les plus permissifs que je connais sur le sujet. J'ai vu peu de fonctions réellement retirées du langage.
4. La sécurité intrinsèque de PHP est tout aussi mauvaise que celle des autres langages. Oui, il y a plus de CVE déclarées pour des projets incluant PHP (20000) que Perl (5000) mais ces chiffres sont à pondérer avec le nombre de projets web utilisant chaque langage.

Globalement, la qualité des codes PHP produits ces dernières années s'est améliorée. Des frameworks tels symfony2 ou zf2, des groupes comme le PHP- FIG, des spécifications telles que les PSR et des outils comme composer ont participé à une élévation du niveau. Et, de ce que je peux en lire sur internals, un mouvement pour rationaliser le langage et ses dépendances s'initie.

Le gang des bricoleurs

Je ne le répéterai jamais assez : chaque langage a ses forces & ses faiblesses. Utiliseriez-vous une visseuse pour planter un clou ? Bien sûr que non, et c'est pareil dans l'informatique.

Faire un site transactionnel en PHP est pour moi une aberration sans nom. Et a contrario, même si le langage est très puissant, je ne considère pas Java comme le bon langage pour coder un CMS (et pourtant j'en administre régulièrement)

Tout langage a été créé pour répondre à un besoin : il peut être détourné mais il faut bien comprendre les limites à ne pas dépasser, ce qui est souvent difficile.

Je suis un fervent partisan du couplage faible. Je veux bien un frontend en PHP qui publie des messages à destination d'autres applications. Mais non, développer un système de publish/subscribe en PHP est une mauvaise idée. Des outils comme ActiveMQ ou RabbitMQ le font très bien et ont le mérite de proposer des connecteurs pour PHP.

Donc oui, je continuerai à utiliser des composants en PHP si je considère que c'est l'outil le mieux adapté à ce que je veux.

Cela fera bientôt 5 ans que je suis dans ma société. Comme partout, il y a eu des hauts et des bas, mais je suis globalement satisfait de ce que j'ai pu y faire.

Mais déjà 5 ans. Et je suis déjà pris d'envies de changement. De part Paris Web, j'ai découvert un pan des métiers de l'internet que je ne connaissais pas. Et je me suis surtout rendu compte que, quoique j'en dise, je suis toujours un développeur et pas uniquement un administrateur.

Donc, si vous cherchez un devops (ou plutôt un OpsDev) avec une forte compétence Java, de bonnes connaissances en système *nix et un bagage en développement PHP, symfony 1 & 2, (plus un bon nombre de notions sur la qualité et l'accessibilité), je suis votre homme !

Tout est négociable, le salaire aussi, voire même un déplacement en province (genre Nantes, c'est sympa comme ville)

Suite à une discussion avec un ancien collègue, je me prends à réfléchir à ma suite de carrière.

Je suis dans le backend (hébergement) avec un bagage frontend (css réduit, mais pas mal de PHP) et je pense appartenir à la catégorie des OpsDev (oui, les alter ego des devops)

On parle beaucoup des devops en sous-entendant les développeurs qui se sont construit un bagage backend, mais il existe, en nombre plus réduit, des administrateurs qui ont aussi un bagage frontend assez développé. Et ces personnes ont souvent du mal à trouver un job qui correspond à leurs aspirations. Quand on regarde les divers sites d'offres d'emploi spécialisés dans le web, on trouve beaucoup d'offres pour des experts sur divers frameworks web (quelque soit la technologie) avec un bagage technique sur l'administration. Les offres concernant des administrateurs techniques ayant un bon bagage frontend sont bien moins présentes.

Avec l'arrivée à maturité d'un bon nombre de plate-formes de virtualisation, même les PME peuvent obtenir un environnement propre, scalable et à peu de frais. Mais il y a un travail d'intégration à faire (front & back) pour que ce soit utilisable facilement en agence. Et c'est là que le opsdev intervient en ajoutant une compétence back aux projets front.

Amis d'agences et sociétés de taille moyenne, prendriez-vous un opsdev ? Une personne qui comprend votre métier, enfin je crois, tout en apportant sa contribution sur les parties "cachées" d'un projet web.

Mon pocket se remplit de liens en tous genres et plus ou moins frais. Vous devez déjà en connaître certains, découvrez-en d'autres.

• Zapier API Status Board : un tableau de bord d'un concurrent, à mon sens, de IFTTT. Je ne me sers pas du produit en lui-même, mais cette page est bien pratique.
• Webmentions : une alternative aux pingbacks qui semble prometteuse (utilisation intelligente des codes HTTP par exemple)
• colourcode : un complément/une alternative à Kuler de Adode. J'aime bien
• Comprendre le fonctionnement de la JVM partie 1 et partie 2 : même en travaillant dessus tous les jours, il est quelques fois nécessaire de se replonger dans la documentation liée aux mécanismes de la Java Virtual Machine.
• Le versionning sémantique : si seulement tous les projets pouvaient adopter cette spécification...

Cela fait déjà une centaine de jours que j'ai arrêté de fumer des cigarettes. Je suis passé à la cigarette électronique et globalement, cela se passe bien.

Et tu n'as pas envie d'en fumer une ? Là, maintenant ?

Les premiers jours oui, j'ai eu envie de fumer. Mais le fait d'avoir commencé à vapoter tout en fumant mes dernières cigarettes et en me faisant un surdosage de nicotine comme avec un patch trop puissant m'a rapidement fait arrêter la cigarette. Autre astuce: le goût des liquides. Commencé avec un goût camel, j'ai rapidement changé pour des fruits et n'a plus envie de cigarette depuis. J'en suis même à baisser le dosage en nicotine de mes liquides.

Tu fais ton rebelle, tu la sors partout !

Vous pouvez ramener vos enfants devant l'écran. Cela ne parle que de cigarette. Par rapport au tabac, je vapote dans les mêmes lieux et m'impose les mêmes restrictions à deux exceptions près: au bureau (après accord de mes collègues) et chez moi.

Et la santé ? Tu as pris 20 kilos non ?

Je n'ai pas pris 20 kilos non, mais je fais attention. Je ne crois pas que ce soit la nicotine qui crée l'effet coupe-faim donc je dois faire attention à ce que je mange. Sinon oui, je vais mieux. J'ai retrouvé du goût et de l'odorat, je tousse moins et mes fameuses migraines sont de l'histoire ancienne. Les poumons sont encore encrassés, et devraient le rester encore quelques années, mais je vais mieux. Sur le sujet du "la cigarette électronique n'est pas nocive", elle l'est certainement beaucoup moins que le tabac oui. Mais il ne faut pas oublier qu'au lieu de goudrons et de produits brûlés, un vapoteur s'envoie de la nicotine et de la vapeur d'alcool dans les poumons.

On peut t'appeler Crésus maintenant !

Non, mais mes finances vont bien, merci de vous en inquiéter. Comparativement à la cigarette, passer à l'électronique assure une tranquillité d'esprit et de porte-feuille. Il n'y a plus le stress du dimanche matin avec un paquet quasi vide et les questionnements sur où aller chercher un paquet de clopes. Pareil pour la monnaie, disparus les calculs savants à la machine à café ou au magasin pour savoir si l'on peut acheter le pain et son paquet de clopes. Un rapide calcul m'a permis de constater que mon budget "plâtrage de poumons" a été divisé par huit environ.

Et maintenant, tu comptes faire quoi ?

Baisser le dosage et définitivement arrêter. J'ai commencé à vapoter avec un dosage à 16mg/l de nicotine dans mes liquides, ce qui correspond à un paquet de cigarettes quotidien. Depuis quelques jours, je suis descendu à 11mg/l, équivalent à un demi-paquet. Sur le dosage, cela ira. Le plus difficile va être de perdre le geste.

Rapidement, parce que j'en aurai certainement encore besoin et que d'autres me l'ont demandé, quelques liens que j'ai trouvé sur un usage "intelligent" de Google Analytics et son paramétrage. A noter que j'ai principalement cherché des éléments liés à Universal Analytics et non GA.js.

• Explication de certaines variables utm_* (fr) : tracer facilement les origines des utilisateurs externes quand on poste des liens vers son site.
• Référence de variables utm_* (en) : toutes ne sont pas positionnables par le producteur, mais c'est toujours intéressant de savoir à quoi cela correspond.
• Définir un objectif (en) : le moins compliqué que j'ai pu trouver sur les objectifs. Et surtout le truc de ne pas cocher la case "Required step"…
• Tableau de bord & affichage des données (en) : c'est bien de collecter les données, c'est mieux de savoir correctement les lire…
• Tracer le A/B testing avec Google Analytics (en) : tout est dans le titre.
• Télécharger les données brutes (en) : gAnalytics limite le volume de données exportées, dépassez cette limite (merci @nhoizey)

Voilà, si vous avez d'autres liens/ressources pour mieux utiliser cet outil, n'hésitez pas à commenter!

Designer, développeur, intégrateur, expert, vous avez des choses à dire sur votre métier et nous voulons les entendre! Et si, en bonus, je vous proposais de les dire dans un lieu superbe devant un public de qualité?

L'appel à orateurs de Paris Web est ouvert et nous attendons vos propositions de conférences. Et si vous avez peur, pourquoi ne pas venir vous entraîner avant lors d'un atelier dédié?

Dès qu'un site atteint une fréquentation plus que raisonnable, les coûts d'hébergement associés montent en flèche et l'on réfléchit aux moyens d'optimiser les performances et réduire la consommation globale en ressources. Entre la mise en cache côté navigateur et celui côté serveur (quelque soit la technologie serveur, il existe pratiquement toujours un système de cache soit opcode soit du html généré), on arrive souvent au déport des ressources statiques sur des Content Delivery Network (CDN) extérieurs.

En plus de réduire la consommation de ressources sur le serveur, les CDN ont des avantages certains, particulièrement pour des sites internationaux: serveurs plus proches du client final, gestion quasi automatique des caches (client et/ou serveur) et cela pour un coût globalement plus réduit que celui de mettre des serveurs en batterie chez son hébergeur pour supporter la charge.

Mais, surtout si votre site est à destination des grosses entreprises ayant de bonnes contraintes sécurité, il ne faut pas oublier certaines choses:

1. Mettez vos ressources sur CDN derrière un sous-domaine de votre site ! Cela peut paraître bête, mais si votre utilisateur est protégé par un proxy de type websense, il est plus que probable que le domaine principal de votre CDN soit bloqué par le proxy. Votre site pourra être bien beau sur votre poste de développement, votre mobile, le PC de votre grand-mère; si la feuille de style principale n'est pas accessible chez votre client, je doute que le rendu soit tel que vous le désirez.
2. Rendez votre site accessible! En corollaire du point 1, si tous les assets (essentiellement javascript) ne sont pas chargés du fait de ce proxy, les fonctionnalités principales de votre site seront toujours disponibles.
   1. Vous pensez à tous vos clients potentiels.
   2. Mieux vaut un site moins beau mais fonctionnel qu'un site inutilisable.
   3. Pub éhontée: ils pourront vous aider.
3. Résistez à la tentation d'utiliser des librairies hébergées hors de votre contrôle (par exemple chez Google ou Microsoft). Si vous avez pris un CDN, surtout un payant, utilisez-le ! Parce que vous déportez vos ressources vous utiliser un nouveau domaine. Et utiliser un autre domaine dans vos pages oblige le navigateur à créer une nouvelle connexion vers celui-ci; avec la latence associée. En réunissant tous vos assets au même endroit, vous n'obligez le navigateur à créer qu'une seule connexion supplémentaire (oui, la grande majorité des CDN gèrent le http 1.1 et le pipelining associé, ainsi que la compression à la volée)
4. La qualité à un coût: ne succombez pas au chant des sirènes d'un CDN payant peu connu voire gratuit. Il faut des ressources et de l'intelligence pour opérer ce type de service.

Enfin, s'affranchir de certaines contraintes d'hébergement n'est pas une autorisation pour ne pas faire du code de qualité et de l'optimisation sur vos assets.

En attendant de pouvoir finir mon billet sur mon retour de Paris Web 2012, une réflexion dans le vague suite à plusieurs discussions avec des auditeurs et orateurs. Alors que les deux mondes œuvrent pour le même client, la communication et les interactions entre le front (design&dev) et le back (prod) est toujours aussi difficile. "Cela marche sur mon poste" et "Cela vient de ton code" font partie des récriminations les plus courantes quand il y a un problème sur une application. La structure habituelle d'un projet n'aide jamais à améliorer cet état de fait alors que les deux parties gagneraient à comprendre ce que fait l'autre.

Sans le code, le serveur ne sert pas à grand chose et sans le serveur, le code n'est qu'un amas de fichiers. "Galériens du back et soutiers du front, tous dans le même bateau", cela ferait un beau sujet de conférence...

A moins de trois semaines de l'évènement, j'avoue avoir encore du mal à l'appréhender. Depuis décembre 2011, je suis dans l'équipe. J'essaie, autant que faire se peut, de contribuer au projet. Et par rapport à mes expériences précédentes dans l'évènementiel, c'est un gros changement:

• Sans filet: autant au FJV, nous n'étions que "standiste" avec l'organisation principale en dernier recours; ici c'est sans filet: le commissariat c'est nous.
• Une équipe plus réduite: JOL, ce sont environ 500 personnes dans le staff, il y a donc un bon vivier de volontaires pour animer le stand. Ici, nous sommes "seulement" 18.
• Moins de goodies: les taxis nous ont maudit les veilles de FJV quand nous leur apportions plus de cent kilos de goodies en tout genre et souvent plus fragiles les uns que les autres.
• Et surtout un travail en amont beaucoup plus important pour PW.

Je m'arroge donc le droit d'angoisser. Et fortement.