J'enseigne, tu éduques

Cet article de Rue 89 me fait bondir. Un enseignant obligé de crier sur la toile son désarroi face aux parents qui abandonnent leur propre rôle.

Enseigner est donc éduquer, mais éduquer n'est pas forcément enseigner. Il est du devoir des parents d'éduquer leurs enfants et de l'enseignant d'instruire. (WPFR)

Même si mon expérience parentale ne se limite pour le moment qu'à la maternelle, je suis déjà désolé de voir des parents "suggérer" aux instituteurs des actions à faire avec leur progéniture et ce de manière assez véhémente. Voire, et parce que c'est à la mode, de se plaindre auprès de la directrice d'une hypothétique théorie...

La loi autorise l'instruction à la maison. Donc, parents, si vous déconsidérez l'enseignant, faites-le ! Vous verrez que ce n'est pas un travail à la gueule du client voire un métier de fainéant. Pendant que vous êtes à votre bureau/atelier/whatever avec une dizaine de collègues dans une relative indépendance, l'enseignant est lui en train d'instruire en moyenne 30 personnes tout en collant au mieux au programme scolaire de l'année, sans parler des différences entre les enfants.

Mettez-vous dans la peau de l'instituteur qui se prend une volée de bois vert car un enfant de petite section n'est pas propre ! Est-ce son rôle ? Non. Par contre, c'est son rôle de punir l'enfant qui n'a pas effectué son travail à la maison. Laisseriez-vous votre entrepreneur immobilier impuni car il ne vous a livré qu'une partie de votre nouvelle maison ou pis n'a rien fait ?

Je crois que, plus que tout autre, le métier d'enseignant est une vocation. Et à devoir composer entre un programme de plus en plus lourd (heureusement car cela démontre que nos connaissances s'accroissent) et des parents qui ont abdiqué leur rôle d'éducateur, je ne peux que les féliciter de tenir encore bon.

One language to rule them all (oh god no !)

@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.

Bref, il veut changer

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)

OpsDev en Freelance

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.

Liste chaînée

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...

100 jours sans fumer

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.

Fourre-tout : Google Analytics

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.

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

A vous!

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é?

Faire du CDN, c'est bien. Le faire intelligemment, c'est mieux!

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

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...