Golang : Extraire les données d'un flux RSS

Golang : Extraire les données d’un flux RSS

Pour celles et ceux qui viendraient visualiser la syntaxe de Go, sachez que malgré sa syntaxe au premier abord déroutante, elle n’en est pas moins facile à appréhender et facile à comprendre après 2/3 heures de pratique. Pour ma part, j’ai dans un premier temps découvert simplement le langage Go (Golang) via mon dernier amour… Docker ! Par la suite, je suis allé voir un meetup traitant de ce sujet et après avoir travailler 1 heure sur un projet désormais au fin fond de mon GitLab, je me suis lancé sur le travail de deux projets, dont les problématiques de performance et de maintenabilité du code sont des points clés d’un projet viable.

Pour l’écriture de ce billet, j’ai extrait une problématique d’un de mes projets. À savoir que l’utilisation du langage est selon moi un grand atout, car ce langage récent est extrêmement facile à compiler et facilite l’utilisation de librairie externe… Quand cela est nécessaire car Go possède une panoplie de package bien sentis. En l’occurrence ici, le package encoding/xml.

L’exemple qui suit présente l’extraction de données depuis un RSS mais cette méthode peut-être facilement adaptée pour extraire un sitemap ou tout autre XML correctement construit.

Lire plus

Intégrer Grunt JS dans Symfony et remplacer Assetic

Intégrer Grunt JS dans Symfony et remplacer Assetic

Je connaissais Grunt JS sans l’avoir jamais utilisé mais il aura fallu que j’entende un développeur Symfony m’en faire la messe pour que je me penche sur cette solution. Dans un premier temps, remplacer Assetic par Grunt JS était pour moi une solution pour faire fonctionner mes projets Symfony avec HHVM. Désormais le serveur PHP de Facebook fonctionne parfaitement avec Assetic mais je trouve de moins en moins de raisons de continuer à utiliser Assetic. Pour finir, l’utilisation de Grunt, un plugin basé sur Node JS, pousse la plupart des développeurs à se servir de Bower, un autre plugin permettant de gérer les dépendances. Nous reparlerons de Bower plus bas. Faisons un bref tour des pour et des contre.

Attention ! Avant de vous lancer dans la migration de votre application, je vous conseille de versionner votre code et de faire quelques essais. Lire l’intégralité de l’article avant de vous lancer dans cette mission de longue haleine est fortement conseillé.

Introduction

Assetic, l’ami mal compris

Pour ma part, je considère qu’Assetic est mal compris et mal utiliser. Je vais vous exposer ma pensée. (Par ailleurs, j’ai corrigé cet article suite à une incompréhension de ma part, merci à Manuel Klein pour ses retours).

Avantage

L’utilisation d’Assetic permet d’annuler le cache sur les ressources car le nom des ressources JS et CSS générés change à chaque fois que vous lancerez la commande “assetic:dump”. Un avantage certains !

Inconvénients
  • Assetic propose peu d’options pour configurer la manière dont sont générés les ressources.
  • Il est nécessaire d’installer des bundles PHP pour générer des ressources exotiques comme le LESS. Le code PHP est installé dans les vendors alors que cette tâche n’est utile que pour le client. Non pour le serveur. De plus cela augmente le nombre de votre projet.
  • Du code PHP est nécessaire dans les templates Twig utilisant Assetic soit quasiment tous. Tandis qu’avec Grunt, la ressource compilé sera appelé via le nom que vous lui aurez donné.

Réellement se servir d’Assetic dans ses templates

Je vois souvent dans les templates Twig que je croise, des ressources liées tantôt via Assetic, tantôt via les assets de Symfony.

1
2
3
4
5
# Utilisation d'Assetic
@NamespaceMyBundle/Resources/public/css/main.css
# Assetic inutilisé, utilisation des Assets
/bundles/namespacemy/css/main.css

Dans le premier cas, Assetic s’applique vraiment. Dans le deuxième cas, Assetic est complètement occulté pour ne se servir des assets de Symfony. L’utilisation des assets est d’ailleurs une erreur selon moi, du moins pour l’accès aux ressources JS et CSS. Fin de la parenthèse…

Grunt JS le compilateur Sooo flexible !

Grunt JS repose sur Node.js. C’est un outils côté client qui va grâce à des modules permettre d’effectuer de nombreuses actions telle que la concaténation de fichiers, minification, compression d’image, compilation de LESS, TypeScript… Contrairement à Assetic, vous devrez mettre en place certaines configurations mais rassurez-vous, cet investissement initial sera payant et au final bien plus rapide qu’Assetic.

Initiation à Bower, le composer.json des ressources

Grunt JS est bien et vient se placer sur le même segment qu’Assetic. Mais tant qu’à utiliser Node.js, autant se servir de Bower ! C’est un gestionnaire de dépendances. Pour faire simple, vous définissez les ressources dont vous avez besoin, « telle librairie dans telle version » et Bower s’occupe de récupérer la version que vous souhaitez. Bien évidement, tout comme composer.json pour PHP, vous pouvez ajouter des plages de version. Si vous voulez une librairie dans sa version 3.3., *Bower vous mettra la dernière version disponible. Une solution permettant de faire facilement des mises à jour de ces ressources. Un problème récurrent sur nos projets standards car nous avons (avions !) tendance à télécharger une version et de ne jamais la mettre à jour la suite. Nous n’avions pas les mises à jour mineures qui sont parfois si utiles.

Techniquement, Bower utilise le fichier bower.json. Sa syntaxe est très simple. Je vous incite à l’utiliser même si vous pouvez continuer sans. Le fichier devra être versionné contrairement aux ressources que Bower viendra télécharger pour vous. Pour vous lancer je vous donne un exemple plus bas.

Versionnage des ressources compilés

Pour ma part, j’avais pris l’habitude de ne pas versionner mes ressources compilés pour Assetic mais j’ai décidé de faire l’inverse pour Grunt JS. Puisque je me passe de ressources gérer par Bower (voir Initiation à Bower), je vais compiler mes ressources et les gitters. De cette manière, je pourrai déployer rapidement mon application. Je n’ai jamais eu de retour sur cette pratique mais cela me semble respectable car on annule deux opérations au moment de déploiement (récupération des ressources avec Bower et compilation avec Grunt JS), ainsi que la nécessité d’avoir Node.js sur sa machine.

Lire plus

Soft Delete : Comment se passer de Gedmo dans Symfony

Soft Delete : Comment se passer de Gedmo dans Symfony

Symfony propose de nombreuses fonctionnalités et Doctrine en ajoute également beaucoup. Au fur et à mesure que la standardisation de Symfony avance, les bundles les moins utiles et les plus consommateurs sont remplacés par des snippets efficaces. Avec l’utilisation de Doctrine comme ORM, on a souvent besoin de Gedmo pour gérer le Soft Delete. Je me suis posé quelques minutes pour mettre en place un système similaire dans le but de limiter les dépendances de mon application.

Comment fonctionne le Soft Delete ?

Vous voulez supprimer un objet. Plutôt que de directement le supprimer, vous voulez l’archiver de manière à ce qu’il puisse être restauré plus tard. Cet objet archivé pourra être réellement supprimé par la suite. Pour cela, nous ajoutons un champs deletedAt sur notre entité. Si le champs est null, l’objet est disponible. Au contraire si le champs est complété de la date de suppression effective ( < maintenant), l’article est supprimé.

Lire plus

Bonnes pratiques Symfony (recommandation officielle)

Il y a quelques jours, Fabien Potencier via Sensio, dévoilait un e-book rassemblant les bonnes pratiques et recommandations pour développer un projet Symfony. Compilé des recommandations postés par la communauté, le but de ce document est de donner un ensemble de conseils en lien avec la philosophie de Symfony. Je vais tenter de vous résumer brièvement les 31 conseils décrit en anglais dans ce post.

Introduction

Ce document commence par quelques conseils et quelques phrases ayant pour but de nous inspirer du document.

« Ce document n’est pas un tutoriel »

Ce document a été écrit dans le but d’être lu par l’intégralité des Symfony developers. Aussi bien, les experts que les néophytes.

« Ne refactorisez pas vos applications »

Dès le début du document, il est spécifiquement expliqué qu’à la suite de cette lecture, nous ne devons pas mettre à jour et refactorisez nos applications dans le but qu’elle colle parfaitement aux multiples recommandations de Sensio. On peut donc immédiatement faire le lien avec les premières idées développés dans le document : ces bonnes pratiques doivent nous permettre de nous simplifier la vie, tout comme simplifier la relecture de code. Pour appuyer mes propos, trois raisons sont avancées :

  • Your existing applications are not wrong, they just follow another set of guidelines;
  • A full codebase refactorization is prone to introduce errors in your applications;
  • The amount of work spent on this could be better dedicated to improving your tests or adding features that provide real value to the end users.

    Lire plus

Implémenter un UserProvider

Suite au premier article que j’avais rédigé pour mon entreprise qui mettait en avant l’utilisation de la sécurité (firewalls, authentification…), et d’un second article que j’ai rédigé sur ce propre article qui met en avant les méthodes permettant d’ajouter les fonctionnalités essentielles comme créer un compte, valider son compte, changer son mot de passe ou encore générer un nouveau mot de passe, j’ai décidé d’écrire un troisième et dernier article sur ce sujet, pour vous décrire comment implémenter son propre provider d’authentification.

À quoi sert un provider pour l’authentification ?

Le provider d’authentification est l’élément qui permet à un utilisateur qui souhaiterai s’authentifier d’être rattaché à un utilisateur d’une base de donnée ou dans renvoyé une erreur si les informations ne sont pas correctes. De base, Symfony2 propose un provider implémenter ce qui ne vous oblige pas à un implémenter un.

Lire plus

Implémenter son propre SecurityController

Implémenter son propre SecurityController

J’ai récemment rédigé un article pour mon entreprise sur la gestion des utilisateurs et de leur authentification en utilisant nativement le Core de Symfony2, et donc en se passant de FOSUserBundle. Suite à ce premier article déjà riche, j’ai voulu vous décrire une deuxième partie tout aussi utile qui va nous permettre de mettre en place rapidement les fonctions indispensables à savoir, réinitialiser son mot de passe, changer son password, valider son compte ou encore s’enregistrer. Des actions tout aussi indispensable lorsqu’on possède un système gérant des utilisateurs.

Mettre en place un SecurityController

Dans un premier temps, si vous n’avez pas suivis le premier tutoriel sur comment mettre en place une gestion utilisateur, je vous conseille d’y jeter un coup d’œil. Si vous avez suivis la solution, vous devriez en toute logique avoir un contrôleur SecurityController ou avec un autre nom. Dans mon cas, je ne possède que trois méthodes dont une seule réellement utilisable.

Lire plus

Twig: accélérer la génération de ses templates avec include (2/2)

Ce deuxième article fais suite à un premier post donnant des solutions rapides pour optimiser la génération des templates. Il est le fruit d’optimisation déjà utilisé sur des sites en production qui possédait un taux de latence trop important.

Nous utilisons tous les includes de Twig pour déporter ou factoriser nos vues. Mais peut-être n’avez-vous jamais compris pourquoi nous avions la possibilité de passer des paramètres, alors qu’un include de base hérite des variables du contexte en cours.

1
{% include "ProjectMyBundle:Sub:template.html.twig" %}

Souvent nous utilisons cette notation. Dans ce cas, l’include donnera une copie de toutes nos variables à notre template. Cela n’est pas toujours nécessaire, et nous avons tort de copier l’intégralité de nos variables.

Intérêt de l’option « only »

Je me suis longtemps demandé qu’elle était l’intérêt de cette option. D’ailleurs il faut dire que la documentation ne donne pas beaucoup d’élément. Vous pouvez aller jeter un coup d’œil sur la documentation des includes Twig. Elle donne peu d’élément mais elle donne surtout un inconvénient et aucun avantage : se passer de certaines variables. Vue de cette manière, cela n’est pas rentable ; pourquoi je devrais me passer de certaines variables.

Mettons en œuvre nos includes ! Admettons que notre template de base ait 5 variables et que j’inclue un template qui n’utilise qu’une seule de ces variable, voilà la notation qui sera préférable.

1
{% include "ProjectMyBundle:Sub:template.html.twig" with {"object": myVar} only %}

De cette manière seul une variable « object » sera disponible dans mon template. Cela limite la copie de variable inutile, et donc d’allocation de mémoire (gain de temps et de consommation mémoire).

Code et cas d’utilisation

1
2
3
4
5
6
// Controller
// Ici le génère un template en passant un variable imposante (une collection) contenant tous les objets pour une table donnée
public function testAction() {
$objects = $this->container->get("doctrine.orm.default_entity_manager")->getRepository("ProjectMyBundle:Test")->findAll();
return array("objects" => $objects);
}

Nous effectuons une boucle sur notre collection et nous donnons un template chaque itération de la collection au template. Dans ce cas, chaque fois que l’on fait appelle à l’intégration d’un template, l’intégralité des variables sont copiées ainsi que celles qui sont passées avec l’option « with ». Dans notre premier cas on pourrait très bien imaginer accéder à notre collection (objects) ainsi que notre itération en cours (object).

1
2
3
4
5
{# Template 1 #}
{% for object in objects %}
{% include "ProjectMyBundle:Sub:template.html.twig" with {"object": object} %}
{% endfor %}

Dans notre deuxième cas, j’active l’option only ce qui permet de copier uniquement les variables passés en paramètres. Facile ?

1
2
3
4
5
{# Template 2 #}
{% for object in objects %}
{% include "ProjectMyBundle:Sub:template.html.twig" with {"object": object} only %}
{% endfor %}

Benchmark

J’ai réalisé les tests avec les templates et le code donnés dans la partie ci-dessus. J’ai effectuer avec 5 itérations de chaque template, en pensant à vider le cache avant chaque premier test.

Benchmark des performances Twig avec l'utilisation des includes

Avec ce graphe, on voit bien le chargement est globalement plus long pour ceux qui n’utilisent pas l’option only. La différence a tendance à se réduire après la mise en cache. Cela est dû au fait que mon template est petit et que peu de variable sont utilisés. Dans des cas plus appliqués on note des gains pouvant aller jusqu’à 30%.

Ici, si on fait une moyenne des valeurs, on atteint une différence moyenne de 9 ms (48,6 - 39,6 = 9). On peut donc calculer un gain approximatif de 20% même si cela est à relativiser dans notre cas puisque le premier shot est terriblement long sans l’utilisation de « only ».

Conclusion

Dans notre exemple, on remarque qu’il est facile (à condition d’être méthodique) de limiter le temps de génération des templates. Malgré nos résultats qui montrent que le temps de génération tend à se réduire, le gain serait bien plus rapide sur des templates plus costaud et utilisant plus de variable que dans notre cas d’utilisation.

Twig: accélérer la génération de ses templates (1/2)

Dans cette première partie, je vais vous faire part d’une solution permettant de stabiliser le temps de génération de vos templates Twig.

Récemment je me suis posé pour réfléchir autour des solutions que propose Twig pour accéder aux propriétés d’un objet ou d’un tableau.

Accéder à une propriété d’un objet

Twig a été conçu pour simplifier nos templates, aussi bien en terme de code qu’en terme de propreté. Il a également été conçu pour permettre aux intégrateurs, personnes n’ayant pas tous de connaissances en développement, un accès facile aux propriétés d’un objet ou autres. Cela grâce à une syntaxe simplifiée.

Seulement voilà, étant développeur avant-tout, je me suis posé la question de comment twig faisait pour déterminer quelle méthode d’un objet doit être appelé.

Lire plus

PHP : Comment écrire un script High-Performance

Le PHP est au beau être langage de type script et critiqué pour être lent, il n’empêche qu’il reste l’un des langages pour serveur web des plus utilisés. Avec le temps, les sociétés majeurs du web qui utilisent le PHP, on cherché à optimiser le moteur. L’introduction de la notion de Garbage Collector dans la version 5.3 fut une avancée notable. Mais il existe de nombreux moyens d‘optimiser les performances d’un script.

Optimiser vos scripts PHP

Principalement utilisé dans le cadre de la simple génération de page, ces optimisations, bien que pouvant apporté un certain gain, ne sont pas assez visible pour l’utilisateur. L’optimisation des bases de données, des serveurs web avec l’utilisation de Nginx, l’optimisation des moteurs avec l’arrivée de HHVM ou encore de HippyVM vous permettrons de simplement accélérer le rendu de vos pages et d’optimiser le temps de réponses de vos requêtes de manière plus simple. Malgré cela, nous développons parfois des scripts PHP dans le but de faire des traitement lourd, ou les serveurs web ne peuvent rien.

Lire plus