Générer des PDF grâce à wkhtml avec docker

La génération de documents PDF de synthèse ou factures est régulièrement demandé par les clients. Il est toujours assez difficile d’y arriver facilement du premier coup. Entre les images à positionner, les tableaux à créer correctement et à faire rentrer sur une feuille A4 tout en utilisant du CSS relativement simple afin que le fichier soit au plus proche de ce que l’on souhaite.

Heureusement, un outil existe : wkhtmltpdpf. Il permet à partir d’une page HTML de générer un PDF convenable. Il existe sa librairie PHP associée afin de pouvoir les générer simplement.

Si vous utilisez déjà cette librairie, vous avez sans doute été confronté à une erreur avec des fichiers inaccessibles par le binaire (images ou feuilles de styles par exemple). Le document ne pourra alors plus être créé tant que ces fichiers n’auront pas été trouvés. Nous allons voir deux techniques afin de résoudre ce problème dans le contexte d’une application Symfony utilisant docker. La première en manipulant docker afin que les différents container se connaissent les uns les autres, la seconde plus simple en modifiant simplement quelques paramètres lié à Twig.

Accélerez facilement vos tests fonctionnels Symfony

Ce titre est un peu trompeur car il s’agit en fait d’accélérer le chargement de certaines fixtures, mais c’est bien au niveau de la vitesse d’exécution des tests que les gains se sentiront le plus.

Introduction

Les tests fonctionnels et leurs fixtures sont relativement simples et rapides à écrire avec l’écosystème Symfony : Doctrine Data Fixtures, LiipFunctionalTestBundle, Alice, Faker

Problème

Si vous avez choisi de hasher le mot de passe de vos utilisateurs avec Bcrypt (qui l’encodeur recommandé par Symfony) il est possible que l’exécution de votre suite de tests soit anormalement lente. Bcrypt est lent par nature et par design, cela permet notamment de limiter les attaques de type brute-force.

Recrutement développeurs PHP chez Lexik Montpellier

Description du poste :

Vous êtes motivé et passionné par votre métier, vous suivez avec attention l’évolution des frameworks et des derniers langages à la mode. Vous avez déjà travaillé en équipe et vous aimez ça.

Vous bénéficiez d’une bonne expérience à titre privé ou professionnel dans les technologies suivantes :

  • PHP , OOP ;
  • HTML / CSS ;
  • SQL (MySQL, SQLite, PostgreSQL, …).

Une expérience ou un intérêt dans les domaines suivants seront un atout :

  • Framework Symfony ;
  • Gestionnaire de version (Git ) ;
  • Javascript, Angularjs, ReactJS, node.js ;
  • Tests unitaires et fonctionnels, intégration continue ;
  • Méthodologie de développement agile (Scrum).

Angular2 – UI : repensez vos modals pour des fenêtres dynamiques

Notre besoin était d’avoir une modal comme d’habitude, puis une modal dans une modal, comme d’habitude.. Mais comment afficher deux modales à la fois sur une page.

C’est en regardant Tag Manager de Google que nous nous sommes grandement inspiré de leur implémentation pour créer notre propre SheetComponent pour Angular2.

Le principe est d’ouvrir une fenêtre venant de la droite de l’écran et se déplaçant vers la gauche jusqu’à une certaine distance sans coller au bord de l’écran, puis d’insérer dans la fenêtre le composant désiré. Pour ouvrir une seconde fenêtre, on va décaler la première jusqu’au bord de l’écran, et afficher la nouvelle depuis la droite de l’écran jusqu’à une certaine distance…etc..on peut faire ça à l’infini.

Domain Driven Design : partie 2

Dans la première partie on a vu à quoi servait le DDD, le nommage des classes, découper son projet en Bounded Context et comment les Aggregates peuvent séparer les responsabilités.

Comment faire pour éviter que notre projet ne se transforme en une usine à gaz ?

Si on avait une règle à retenir ça serait celle-ci :

Un cas d’utilisation = une transaction = un aggregate

Domain Driven Design : Partie 1

Domain Driven Design c’est essentiellement une question de nommage. On nomme énormément de choses dans notre code, mais de quelle manière ? et pourquoi ?

Pour ceux qui aiment la programmation orientée objet, on modélise très vite notre model en un diagramme de classe. On donne un nom générique à chaque classe et c’est plié.

Pourtant quand on commence un nouveau projet, on nous donne un contexte, un domaine sur lequel nous reposer. Si on doit proposer un catalogue de vélo ou de voyages, on va utiliser des mots et des termes différents. Cependant, notre code lui va rester sensiblement le même.

Automatisation de relance email, ne développez pas !

Dans le cadre de plusieurs projets, hors du pur développement technique, nos clients nous demandent de mettre en place la couche « Technique / Marketing ».
Voici quelques exemples :

  • Relancer une action non terminée
  • Solliciter un utilisateur qui n’a pas complètement rempli son profil à J+5
  • Envoyer une relance pour l’expiration de sa carte bleue tous les mois tant que cette CB n’est pas à jour