AngeZanetti.com

Internet et ses usages, développement Web et humeurs diverses

Tag: Dev

Fuite mémoire avec curl et NSS sous RedHat

Depuis plusieurs mois je travaille pour une startup qui fait de la lutte contre la fraude. En deux mots, les clients nous envoient des flux XML et nous leur renvoyons note correspondant à l’indice de confiance de la transaction.

Et, début Janvier nous avons intégré un GROS client. Du genre à faire pâlir les sysadmin. Cela nous à forcer à reconstruire une partie du code, à revoir l’architecture de l’application (qui est au passage devenue une application symfony2).

Le problème à été de faire communiquer la nouvelle partie avec l’ancienne, et comme nous sommes en PHP, ben nous avons opté pour Curl.

Pour chaque score demandé nous avons donc un appel CURL du nouveau code vers l’ancien. Rien d’inquiétant, cela fait partie de l’habituel en PHP.

Sauf que là :

 

Une belle grosse fuite mémoire, entre chaque restart Apache pas moyen de savoir où partait la mémoire. Nous avons d’abord accusé Symfony, l’ORM à assez mauvaise réputation avec des dæmons et Doctrine avoue ne pas être taillée pour absorber de la charge.

J’ai donc mis en place les fix nécessaires: forcer le garbage collector, désallouer la mémoire des objets inutilisés mais rien n’y faisait.

J’ai ensuite testé de lancer mes commandes en –no-debug, de virer les logs mais pas mieux, ma mémoire disparaissait toujours dans les méandres de mon système…

Toute ma RAM foutait le camp, de manière pernicieuse, petit à petit, Mo par Mo jusqu’à arriver à la limite du système, aux alentours du Go de libre – NB: le serveur n’avait pas l’air de souffrir par ailleurs, l’application ne ralentissait pas outre mesure…  

NSS Softoken

Finalement c’est le sysadmin qui à trouvé l’origine, en farfouillant sur le web. Je lui avais parlé peu de temps avant d’une histoire de fuites mémoire dans le CURL, vaguement, j’avais rien pigé à l’article. Il est retombé dessus quelques jours plus tard, et BIM, révélation! Notre fuite mémoire était en fait dû à une faille système, une sombre histoire de NSS (Network Security Services), qui est utilisée par libcurl et qui faisait du cache là où elle ne devrait pas.  C’est assez bas niveau, mais c’est un bug connu sur la version 3.16.0. C’est la version actuelle sur RedHat… Si vous voulez plus de détail je vous invite à lire cet article qui est la source de nos modifications : https://www.splyt.com/blog/2014-05-16-optimizing-aws-nss-softoken

Le fix est assez simple, il suffit d’ajouter une ligne dans la conf’ Apache:

# execute these commands as ‘root’ echo “export NSS_SDB_USE_CACHE=YES” >> /etc/sysconfig/httpd service httpd restart

Et voilà, comment retrouver le sourire et plusieurs Go de RAM ! 

Comment savoir que son code est de bonne qualité?

C’est une question qui m’a été posée en entretien d’embauche il y a peu de temps:

“Comment un autodidacte comme vous peut-il être sur que son code est de bonne qualité?”

Ça peut paraître une question naïve, surtout venant d’un RH, mais ça me fait pas mal cogiter depuis, au delà de la technique.

Pendant l’entretien j’ai répondu un truc bâteau, qui a d’ailleurs eu l’air de lui plaire, mais il me semble que cette question de comment je produit du code et pourquoi il est bon ou mauvais mérite bien un petit article.

Au passage, si tu passes par là Mme la RH et bien tu trouveras ci dessous une réponse un peu plus complète à ta question :)

DISCLAIMER: Je vais parler ici de méthodes et pas de techniques pure. Si tu cherches à savoir comment indenter ton code ou si tu dois ou non commenter tu ne trouveras pas ton bonheur :)

Comment produire du code de qulité

1 – Mon code marche

Réponse simpliste. Mon code fonctionne, ça tourne en prod depuis des jours/mois/années, mon code est de qualité.

C’est pas faux, mais ce n’est pas suffisant. On a tous en tête des codes qui tournent mais qui ne seront jamais mis à jour tellement l’effort de maintenance est important.

Un code qui tourne n’est pas un bon code, c’est nécessaire mais loin d’être suffisant.

2 – Mon code est le fruit d’une méthode de travail

Produire du code de qualité c’est, pour moi, avant tout la mise en place d’une méthode. Toute l’équipe de développeurs doit être impliquée et faire en sorte que la base de code de tous les projets soit de qualité ou en constante évolution vers une qualité optimale.

Pour ça j’essaie d’appliquer ces trois méthodes :

Merge Request

Je travaille le plus possible avec le workflow de github. Tout mon code est crée sur de nouvelles branches avec Git et quand j’ai fini une fonctionnalité ou un fix je fais relire le tout par un collègue. Tout le code produit est relu, commenté, et n’est mergé que quand celui à qui est affecté la merge request n’est satisfait.

Ce système permet de produire du code bien meilleur, on sait que l’on va être relu, du coup on fait gaffe et on essaye de commenter un peu plus, de mettre des variables explicites etc…

Si jamais des erreurs se sont glissées, il y a de grandes chances que le mainteneur nous le fasse remarquer (autant sur le fond que sur la forme d’ailleurs)

Autre point positif de cette méthode, le mainteneur du code changeant tout le temps, toute l’équipe “voit passer” le nouveau code sur le projet. Cela réduit considérablement l’effort de maintenance.

Extreme Programming

Depuis plusieurs mois j’essaye de mettre en place les règles de l’extreme programming. Au programme, pair programming, ne pas sur optimiser, garder le code le plus simple possible et impliquer toute l’équipe à ces problématiques.

La mise en place des tests automatisés est au programme, mais pour le moment ils ne sont pas encore écrit.

Les retombées sont impressionnantes, l’équipe est plus motivée, le code produit est de meilleure qualité car revu de manière régulière et le pair programming permet d’abattre plus rapidement les situations de blocages – sans avoir à faire des hacks tout moches que l’on aurait tendance à faire seul dans son coin!

Code Sniffer

Enfin, dernier point plus technique, j’ai mis un code sniffer sur mon éditeur de texte préféré. Il râle si mon code n’est pas formaté comme il faut, et, du coup, je râle si le code que je récupère d’un collègue ne respecte pas les règles du standard.

Cela peut paraître anecdotique mais c’est primordial. Cela donne une base de code uniforme sur les milliers de lignes de code de nos applicatifs et cela facilite la maintenance.

3 – Je suis un être social

Autre point qui me tient particulièrement à cœur: l’échange.

Un développeur isolé est un développeur qui travaille mal.

Moi qui n’ai jamais étudié la programmation à l’école (ou très peu) j’ai toujours codé en restant en contact avec des groupes de dev qui pouvait répondre à mes question et vide versa. C’est ce que je fais avec StackOverflow, sur IRC, Twitter etc…

C’est primordial pour moi, cela permet aussi de confronter les idées, d’aller chercher les best-pratices et “d’aspirer” une quantité d’expérience bien plus importante et de manière beaucoup plus interactive qu’en lisant des bouquins!

Par exemple, il y a peu j’ai du concevoir et coder une API RESTFull avec Symfony2. Au final j’ai du passer plus de 70% de mon temps à lire des posts de blogs sur le sujet, à échanger avec des pointures sur IRC et à chercher les meilleurs design pattern et les meilleurs bundle AVANT de commencer à coder.

Seul je n’aurai pas fait un dixième du résultat final et la qualité aurait été réellement en deçà de ce que j’ai finalement produit.

Voilà en substance comment je fais pour savoir si mon code est de bonne qualité, et vous quels sont vos #proTips pour produire du code de qualité ?

 

 

Silex un framework minimaliste PHP que vous devriez tester

Silex est un micro framework édité par SensioLabs, la société qui édite le fameux framework Symfony.

Un micro Framework

Silex est micro, vraiment micro. Même l’installation tiens en deux lignes:

$ curl -sS https://getcomposer.org/installer | php
$ composer.phar install

Une fois ces deux lignes exécutées vous vous trouvez avec:

  • un répertoire vendor qui embarque Pimple, une librairie pour l’injection de dépendances et les modules de gestion HTTP de Symfony ( pour gérer les routes, les requêtes etc..)
  • un répertoire web dans lequel se trouve un fichier index contenant toute voter application (rien pour le moment)
  • et un Composer pour installer en deux coups de cuillère à pot n’importe quelle librairie super utile.
  • et… c’est tout.

Ça ne fait pas lourd, surtout quand on vient de Symfony. Mais quand on y réfléchi deux minutes avec juste ces trois éléments on peut faire beaucoup de choses.

With great power, comes great responsibility

L’architecture de base, celle que je viens de décrire est suffisante pour des petits prototypes, pour tester SIlex ou pour monter votre blog. Mais rapidement, mettre toute vote application dans index.php, voire dans le répertoire web ça devient gênant. C’est pourtant ce que vous trouverez en majorité dans les tutos sur le web.

Si votre projet est fait pour prendre de l’ampleur, pour être maintenu dans le temps par plusieurs personnes il va falloir rendre les choses un peu plus structurées.

Comme Silex n’impose rien, le développeur à le choix. Pour partir sur de bonnes bases je vous propose de partir sur le Skeleton proposé sur Github par SensioLabs: https://github.com/silexphp/Silex-Skeleton

Ça permet de découpler le cœur de l’application du modèle MVC, de séparer les parties publiques et privées. Vous noterez au passage que le composer.json de cet exemple c’est pas mal étoffé et que l’on retrouve des outils Symfony comme Twig ou la console.

L’idée n’est peut être pas pour vous de prendre tout le skeleton, mais en tout cas de s’en inspirer et monter une vraie structure compréhensible et maintenable dans le temps.

Pourquoi pas Symfony ?

J’utilise actuellement Silex parce que le projet que j’ai repris était en Silex, je n’ai pas eu le choix. Cependant je me rends à l’utilisation que Silex peut être une bonne option dans plusieurs cas :

  • Vous voulez monter en compétences sur du PHP objet, savoir vraiment fonctionne des gros framework comme Symfony. Silex est beaucoup plus bas niveau que son cousin, il vous permet de vraiment mettre les mains dans le cambouis, de comprendre comment les choses fonctionnent.
  • Vous avez du code legacy dégueu et vous voulez migrer petit à petit vers quelque chose de plus propre. C’est le cas pour mon projet. 30% du code est horrible en legacy, 30% est sur du Silex mais en mode “Tout dans le index.php” et les derniers 30% ont été codés dans les derniers mois avec plus ou moins le skeleton ci dessus. Silex fonctionne très bien dans cette configuration et nous permet de migrer controlleur par controlleur notre code.
  • Vous êtes un ayatollah de la philosophie KISS, vous ne voulez installer que ce dont vous avez besoin et ne pas avoir un prjet qui finit par embarquer des milliers de lignes de codes qui ne vous serviront jamais.

Pour être honnête, pour des gros projets, des projets à longue durée de vie je vous conseille plutôt de partir sur du Symfony, la doc est mille fois plus abondante,  la structure est fixe et donc l’effort de maintenance et d’évolution sera beaucoup moins important.

Pour le cas d’une migration lente par contre je trouve que Silex est adapté si on part sur de bonnes bases.

Dans tous les cas, Silex vaut le coup d’oeil, au moins pour un side-project. On apprends beaucoup de choses et le chan IRC dédié est d’une grande qualité !

 

Installer un environnement de développement avec VirtualBox

Travailller avec un LAMP, ou un MAMP, installé en local c’est bien pour des petits projets, type création de thème/plugins WordPress, mais pour les projets plus conséquents avec des technos plus exotique que PHP il peut être nécessaire de virtualiser un système d’exploitation pour travailler. Je vous conseillle d’ailleurs de mettre en local le même système que votre machine de production, ça limite grandement les surprises de mise en prod !

Etape 1 : Installation de VirtualBox et de l’OS

Vous trouverez des milliers de tutos sur le web pour installer votre distribution préférée et sur la procédure d’installation de virtualbox, rien de bien compliqué. Petites remarques toutefois, préférez bien sur des OS stables genre debian, ubuntu LTS , CentOS etc… Les distributions à la mode ne sont pas forcement un choix judicieux pour une machine de production.

Limitez les ressources que vous allouez à votre machine, un OS serveur n’a pas besoin de beaucoup de ressources (256Mo de RAM et un petit de processeur devrait suffire) sinon vous allez vraiment avoir du mal à bosser dans de bonnes conditions.

Etape 2 : Configuration de l’OS

Une fois que tous vos paquets sont installés et que votre serveur virtuel tourne bien il va falloir le mettre en relation avec votre machine afin de travailler dans de bonnes conditions.

Pour l’accès je recommande un bon vieil SSH, c’est simple et efficace :

sudo apt-get install open-ssh

Pour le serveur web et le langage je vous laisse choix, nginx, apache2 ou autres, idem PHP, Ruby, Python, faites votre marché !
NB: Faites attention à bien installer la version identique à celle du serveur de production, toujours dans un soucis de compatibilité.

Etape 3 : Configuration du réseau

Ensuite, il faut pouvoir accéder à son serveur depuis son navigateur pour afficher les pages web, pour ça c’est un peu plus complexe, mais pas sorcier non plus.

D’abord rendez vous dans configuration/Réseau de votre machine virtuelle et configurer la carte 1 en NAT, et ajouter une deuxième carte en Réseau privé comme ci dessous  :

Reseau Virtualbox

Ensuite, on va configurer les interfaces réseau dans l’OS directement  – ici une debian. On édite donc  /etc/network/interfaces dans lequel on trouvera lo et eth0 nous allons ajouter eth1 à la fin du fichier :

# The host-only network interface
auto eth1
iface eth1 inet static
address 192.168.56.101
netmask 255.255.255.0
network 192.168.56.0
broadcast 192.168.56.255

Ensuite, pour des raisons pratiques nous allons donner des noms à ces serveurs virtuels pour éviter de retenir des adresses IP obscures, en éditant le /etc/hosts/ de votre machine hôte et en ajoutant :

192.168.56.101    myserver1
192.168.56.102    myserver2

Et voilà vous avez une machine de développement fonctionnelle, reste plus qu’a mettre votre framework préféfé et à installer git pour travailler en équipe !

Freelances contribuez au libre pendant vos temps morts

Dans la vie professionnelle de tout indépendant il y a des temps morts. Entre deux contrats, avant ou après avoir fait de la prospection commerciale, les moments où l’on est pas forcement débordé sont assez fréquents. Hors ce sont bien souvent ces temps là qui nous permettent de nous former, d’apprendre, de faire de la veille.

Freelances contribuez à l'opensource

Depuis quelques temps déjà j’essaye de consacrer ces temps morts à des projets opensource. Je ne le faisais pas forcement avant, mais clairement c’était une erreur pour plusieurs raisons :

Cela permet de faire de la veille active

Être développeur c’est être curieux, être capable de s’adapter aux nouvelles technologies et donc d’apprendre sans cesse. Alors, bien sur, on peut lire des tonnes de flux RSS mais la meilleure façon est encore de mettre les mains dans le code. “C’est en forgeant que l’on devient forgeron”.

Contribuer à des projets libre c’est donc se confronter à de nouveaux outils, à de nouvelles méthodes de travail mais dans une ambiance moins tendue que dans une relation client/prestataire classique. Cela peut être l’occasion de tester le framework de vos rêves de mettre les mains dans un nouveau langage etc… Le plus souvent vous êtes en plus épauler par les anciens de la communauté qui n’hésitent pas à vous donner un conseil, une astuce, une vraie aubaine quand on apprend une nouvelle techno !

Cela contribue à forger vos références et votre réputation

Mettre son temps libre à profit pour des projets opensource cela permet bien sur d’augmenter le nombre de ces compétences, de monter son expérience sur telle ou telle techno mais cela peut aussi faire une jolie référence à présenter à vos futurs clients. De plus, la réputation d’un développeur passant de plus en plus par son profil Github, contribuer à un projet Github libre, le forker, commiter faire des pull request fera monter votre activité sur le réseau social et permettra à vos clients, ou à d’éventuels recruteurs de vous trouver et de voir la qualité de votre code, vos compétences et votre implication.

Faire du libre c’est surtout aider des projets vraiment cools

Evidemment, et, à mon avis c’est le plus important contribuer au libre c’est aussi aider des projets qui en valent la peine. D’ailleurs à ce propos Github est un vrai vivier de petits projets super cools qui ont besoin d’un coup de main ! Je rappelle d’ailleurs que contribuer ce n’est pas forcement coder. En fait c’est bien souvent le reste qui fait défaut. Il y a souvent plus besoin de graphistes, d’ergonomes et de traducteurs que de développeurs. D’ailleurs contribuer ça peut tout simplement être de remonter les bugs.

Bref, la prochaine fois que vous avez un jour ou deux à tuer, sans activité réelle allez faire un tour sur Github, essayer de rencontrer les gens qui font les petits outils que vous utilisez ou tout simplement allez sur les trackeurs de bugs des géants de l’opensource – Mozilla par exemple facilite vraiment la tâche des ces futurs contributeurs – et traduisez, codez, designez, aidez vous verrez c’est beaucoup plus gratifiant, valorisant et plaisant que d’attendre les futurs clients !

 

La programmation objet en PHP

La programmation objet est un pilier du développement actuel. Tout les frameworks modernes sont basé sur ce principe, tout développeur se doit de connaître les bases de la POO et de les appliquer.

Mais bien souvent le client nous presse, on a pas envie de se compliquer la vie ou juste on voit pas l’intérêt de faire vraiment de l’objet. J’ai trouvé sur la chaine Youtube de M6 dédié à la technique une vidéo vraiment bien faite sur les best practices de la POO en PHP. Je n’ai pas résisté à vous la partager !

© 2016 AngeZanetti.com

Theme by Anders NorenUp ↑