planetePHP.fr
rootslabs rootslabs 2016-02-01T10:30:04+01:00

Utiliser CodeClimate avec Github & Travis dans un projet PHP

Après avoir utilisé Scrutinizer-CI, j’ai décidé d’utiliser CodeClimate pour PHPPresentation.

Logo CodeClimate

Ajout du projet sur CodeClimate

Après une connexion via GitHub, j’ai ajouté un projet de type « Repository GitHub ».

Vous avez juste à ajouter le propriétaire et le nom du projet GitHub. Dans notre cas, ce sera « PHPOffice/PHPPresentation ».
L’ajout se fait automatiquement et après le premier build, votre accueil devrait se présenter comme cela :
Accueil

Intégration de CodeClimate dans votre projet

Pour cela, il suffit de rajouter à la racine de votre dépôt un fichier .codeclimate.yml de ce type :

engines:
  phpcodesniffer:
    enabled: true
  phpmd:
    enabled: true
  duplication:
    enabled: true
    config:
      languages:
      - php
ratings:
  paths:
  - src/**/*
  - tests/**
exclude_paths:
- vendor/**/*

Grâce au nœud « engines », votre projet sera testé via PHPCodeSniffer, PHPMd et via un outil interne sur la duplication de code.
Grâce au nœud « ratings », seuls les chemins définis seront utilisés pour le calcul de votre projet.
Grâce au nœud « exclude_paths », les chemins définis seront exclus de l’analyse.

Intégration de CodeClimate avec Travis-CI

Il vous faut pour cela aller dans les settings du projet puis sur l’onglet « Test Coverage ».
A partir de là, tout devrait vous être expliqué.
Mais en gros, cela se passe comme tel :

  • Modifier votre composer.json pour ajouter un require-dev :
    {
     "require-dev": {
       "codeclimate/php-test-reporter": "dev-master"
      }
    }
  • Modifier votre .

la suite...

Remi Collet Remi Collet 2016-01-29T11:24:56+01:00

Apache HTTP Server et répartiteur de charge vers PHP FPM

L'un des avantages de FPM et de séparer et d'isoler proprement le frontal web du serveur d'application.

Voici un exemple de configuration utilisant Apache en répartiteur de charge entre plusieurs instances FPM.

 

La configuration de base est vraiment (trop) simple

    # Creation du repartiteur et de ces membres
    <Proxy balancer://phpfpmlb>
        BalancerMember fcgi://10.0.0.12:9000
        BalancerMember fcgi://10.0.0.34:9000
    </Proxy>
    # Redirection de l'execution PHP vers le repartiteur
    <FilesMatch \.php$>
        SetHandler "proxy:balancer://phpfpmlb"
    </FilesMatch>

Pour aller plus loin, voir la documentation :

 

jy[B]log jy[B]log 2016-01-27T14:32:00+01:00

Défi 2016 : un commit par jour

Fin 2015, période de fête, et période "faisons le point". Pas folichons ce point, concernant mon blog et mes projets open-source. Je n'ai pas écris un seul billet en 2015, et l'activité sur mes projets libres n'a pas été terrible.

Sur github, voici comment mon activité était représenté il y a quelques semaines :

Contributions sur Github en 2015

Parmi toutes ces contributions, indiquées par des carrés verts, il n'y a pas que des évolutions sur le code de mes projets mais aussi des évolutions sur l'extension Opquast Desktop (une mission financée par Temesis, afin qu'elle fonctionne sur les dernières versions de Firefox), et également des ouvertures de tickets, des commentaires...

Cette baisse d'activité sur mes projets libres, en particulier sur Jelix et SlimerJS n'est pas terrible pour moi dans la mesure où ça n'avance pas beaucoup alors que ça m'est utile et que c'est utile pour des utilisateurs.

J'ai donc décidé que cette année, premièrement, j'essaierai d'écrire plus souvent sur mon blog (voilà un premier billet), et deuxièmement, j'augmenterai l'activité sur mes projets libres ou d'autres projets libres, avec un défi : au moins 1 commit par jour sur un dépôt. Et pendant mon temps libre bien sûr.

Un commit, ça peut paraitre beaucoup parce que parfois, pour ajouter une fonctionnalité ou corriger un bug, et donc aboutir à un commit, cela peut prendre plusieurs heures (et je n'ai pas "plusieurs heures" de temps libre chaque jour), et cela peut paraitre peu, parce que, juste "un" commit...

Donc, est-ce réalisable ? Est-ce utile ? Est-ce que cela va apporter vraiment un plus sur mes projets ? Est-ce que cela va être compatible avec mes autres activités ?

J'ai trouvé des réponses dans le post de John Resig, qui s'est lancé le même défi en 2014. Depuis presque deux ans, il arrive à coder tous les jours sur des projets libres, comme on peut le constater sur son tableau de bord github.

Et finalement, pour moi aussi ça fonctionne : depuis presque un mois, j'arrive à committer tous les jours sur mes dépôts Github, en y passant une heure ou deux, le soir principalement. C'est une question d'organisation et d'entrainement. Comme je travaille tous les jours sur un de mes projets perso, je perd moins de temps à me remémorer où j'en suis. Je ne perds pas le fils. Du coup je passe moins de temps que je pensais au début, tout en restant efficace.

la suite...

Pascal Martin (n+1).zéro Pascal Martin (n+1).zéro 2016-01-22T00:00:00+01:00

Les générateurs, c'est le bien ! Un cas d'usage.

J’annonçais lundi le lancement de la « semaine des générateurs » : cette semaine, chaque jour, un article a été posté par un développeur différent, présentant un cas d’utilisation qu’il avait de générateurs. Ils sont tous référencés depuis mon post de lundi.

Aujourd’hui, pour finir cette semaine1, c’est mon tour !

Présentation de mon cas

En recherchant le mot-clef yield dans un de mes projets au boulot2, je l’ai trouvé neuf fois — plus quelques fois dans des commentaires ou noms de méthodes.

Une bonne partie de ces utilisations correspondent à des cas évidents d’utilisation de générateurs pour plusieurs de mes collègues : on parcourt une série de données — souvent depuis une base de données — et on souhaite effectuer un traitement sur chaque ligne, indépendante des autres. Aucune raison donc de tout charger en mémoire dans un tableau. Bien sûr, on souhaite tout de même séparer chargement / manipulation / affichage des données. Plusieurs exemples de ce type ont été montrés cette semaine et je ne partirai donc pas sur un de ces cas pour cet article.

Le cas dont j’ai choisi de parler va, en fait, dans le sens inverse : j’ai en entrée un fichier binaire constitué d’un nombre variable d’enregistrements, chacun de taille variable. J’ai besoin de lire ces enregistrements un par un, de les analyser, puis de les stocker en base de données.

Le format de mes fichiers

Chacun de mes fichiers est composé d’une suite d’enregistrements, indépendants les uns des autres. Chaque enregistrement, une suite de données binaires contenant une liste de livres, est composé des champs suivants :

  • 2 octets (entier) : la taille de l’enregistrement, ces deux octets étant exclus du compte
  • 2 octets (entier) : le nombre de livres dans l’enregistrement
  • Ensuite, pour chaque livre, une suite de données (titre, format, auteurs, …) — toujours les mêmes champs, certains étant de taille variable avec un délimiteur de fin.

Mon approche

J’ai commencé à bosser sur le parcours de ces fichiers il y a quelques mois, alors que notre plate-forme était déjà en PHP 5.6. Donc, je suis directement parti sur des générateurs, pour séparer analyse / parcours / utilisation des données et ne pas les charger intégralement en mémoire — et sans avoir à mettre en place un itérateur à la main.

Un flux, bien sûr !

Pour manipuler un fichier dont j’ai besoin de lire les données alors que j’avance dans le fichier, en partant du début de celui-ci et en allant jusqu’à la fin, je passe généralement par un flux —

la suite...

cd ~tigrou/pwet.fr/Blog cd ~tigrou/pwet.fr/Blog 2016-01-21T17:38:00+01:00

Powered by Metalsmith (and Github, TravisCI, Myth, npm...)

And here is another version of this blog! As usual, it's a good opportunity to experiment recent or interesting technologies and to apply new good practices in a different context than at my daily job at eZ Systems.

The fundamental change this time is that it is now statically generated. To do that, I use a tool called Metalsmith. I've already used Metalsmith to publish my mountain bike website and I still find it brillant. It is at the same time super simple and powerful thanks to its plugins. By the way, the full source code is on Github, each and every new version of this website is made with less and less code, it seems like I'm getting lazier with time. Also, the build process is run by Travis-CI with the great benefit of not having to maintain an up to date environment for that on the hosting server :-)

As a matter of fact, I also did various choices at different levels when rebuilding this website:

  • no external dependencies in the pages like custom fonts, social widgets and so on... Even no Google Analytics. I've came to the conclusion that the price for the reader does not worth it. So the main font is the good old Arial and to share a post on the main social networks (feel free to do it ;-)) you have good old hypertext links. And as a result, you won't see here the stupid cookie warning...
  • it seems like font icons are not that good so this website is font icons free, the few icons were replaced by inline SVG coming from Simple icons.
  • npm as the only package manager and as the tasks runner so no bower, grunt or gulp. Again, given the simplicity of this project, it's more than enough and it's a good way to limit the maintenance to a minimum.
  • no CSS pre-processor: I don't like pre-processors like Sass or Less and I much prefer to write future proof CSS and post-process it to get a working CSS in current browsers. PostCSS is clearly the tool in this area right now but on the other hand Myth has been there for a while, it is much more simple and there's already a plugin for Metalsmith, so for now the winner is... Myth :-)
  • on the CSS side: flexbox all the things and CSS custom properties (variables) for the win. Those 2 new CSS features change everything when it comes to write the stylesheets. And again given the simplicity of this project, there is no need for a grid framework.

As you can see, this new version is focused on the Less is more mantra. Actually, for quite some time now, I try to apply the following quote from Antoine de Saint-Exupéry in my developments:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

la suite...

Kévin Dunglas (Lapin Blanc) Kévin Dunglas (Lapin Blanc) 2016-01-21T09:06:26+01:00

DunglasActionBundle: Symfony controllers, redesigned

Today is my birthday, but – unusually – I offer the gift: DunglasActionBundle – a replacement for the Symfony controller subsystem.

Since few months, a lot of discussions and experimentations are occurring in the Symfony world to find a better and moderner way to  create controllers.

During the past summer, I’ve already switched the API Platform project from the traditional controller system to a variant of the ADR pattern.

Thanks to the support of autowiring I’ve introduced in the version 2.8 of the Dependency Injection Component, it’s now possible to create a generic (and I hope superior) replacement for the controller system of the full stack framework.

With this new system, no more inherited controller class, no more traits, only a plain old callable!

It is as convenient as the original but doesn’t suffer from its drawbacks:

  • Action classes are automatically registered as services by the bundle
  • Dependencies of action classes are explicitly injected in the constructor (no more ugly access to the service container)
  • Dependencies of action classes are automatically injected using the autowiring feature of the Dependency Injection Component
  • Only one action per class thanks to the __invoke() method (but you’re still free to create classes with more than 1 action if you want to)
  • 100% compatible with common libraries and bundles including SensioFrameworkExtraBundle annotations

DunglasActionBundle allows to create reusable, framework agnostic (especially when used with the PSR-7 bridge) and easy to unit test actions.

Guess what, it plays very well with the new Symfony micro framework too!

Installation

As usual, use Composer to install this bundle:

composer require dunglas/action-bundle

Then add the bundle in your application kernel:

// app/AppKernel.

la suite...

AFUP AFUP 2016-01-21T00:00:00+01:00

Soumettez vos sujets de talks pour le PHP Tour Clermont-Ferrand 2016

Comme pour chaque édition de notre cycle de conférences itinérant, une partie de la programmation se penche sur une problématique précise. Il sera cette année question de la performance, au coeur de la nouvelle version PHP7. La performance est devenue un besoin pour tous les développeurs face à la complexité grandissante des applications développées en PHP.

Bien sûr, le programme fera aussi la part-belle aux conférences théoriques et aux retours d’expérience, sur les dernières avancées du langage, ses fonctionnalités et son utilisation dans les plus grandes entreprises...

Un sujet à nous proposer ? Répondez à l'appel à conférenciers grâce à notre formulaire en ligne, et ce avant le 20 février minuit. Nous avons hâte de lire vos propositions !

Pascal Martin (n+1).zéro Pascal Martin (n+1).zéro 2016-01-18T00:00:00+01:00

Semaine des générateurs : le lancement !

A mes yeux, les générateurs (ou « Generators », en anglais) sont la nouveauté la plus frappante de PHP 5.5. Et pourtant, quand, lors d’une conférence à Nantes en septembre dernier, j’ai demandé qui dans la salle utilisait des générateurs, seules deux mains se sont levées. Sur une quarantaine de personnes !

Plusieurs discussions que j’ai eu depuis ont mené à des remarques comme « ça a l’air cool, mais est-ce que tu aurais un cas pratique où tu en as utilisé ? ». Après tout, ça peut effectivement avoir l’air sympa sur le papier et en conférence, mais rien ne vaut des cas réels pour se convaincre.

J’ai donc demandé sur Twitter si des personnes utilisant des générateurs voudraient bien écrire à propos de leur expérience, pour partager des cas d’usage qu’ils ont rencontré et pour nous montrer dans quelles situations, réelles, employer un générateur peut être pratique, utile, ou tout simplement cool !


Plusieurs développeurs m’ont répondu. Et voici donc la première semaine des générateurs !

la suite...

Pascal Martin (n+1).zéro Pascal Martin (n+1).zéro 2016-01-14T00:00:00+01:00

Mes notes du ForumPHP 2015, jour 2

J’ai posté il y a quelques jours les notes que j’ai prises lors des conférences auxquelles j’ai assisté pendant le premier jour du Forum PHP 2015 à Paris.

Après une soirée communautaire qui m’a permis de discuter avec pas mal de monde que je ne vois que trop rarement et dans la suite de ce premier article, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez encore une fois qu’il s’agit de mes notes, soumises à mon interprétation de chaque intervention.


A deep dive into image manipulations with Glide

Jonathan ReininkRésumé, Slides, Vidéo

Pour attaquer cette seconde journée, Jonathan est venu parler de Glide, une bibliothèque de manipulation d’images, dont les principes sont : calculs à la demande et API simple par-dessus HTTP. Elle permet toutes les manipulations classiques (largeur, hauteur, bordures, watermarking, flou, …) en utilisant en-dessousgd ou imagemagick.

Exemple d’URL : http://images.example.com/products/123456.jpg?w=300&h=400&fit=crop

Dans le principe : on enregistre seulement l’image de base et pas les manipulations (par exemple : les différentes miniatures qu’on peut vouloir afficher sur notre site) et on requête les différentes versions à la volée. Stockage sur n’importe quel système (via Flysystem pour abstraire le FS ⇒ stockage en local, sur S3, …).

Au niveau fonctionnalités, on retrouve un peu tout ce qu’on pourrait attendre : presets (utilisables comme base pour plusieurs manipulations sans avoir à tout répéter), defaults (par exemple, pour toujours inclure le même watermark), taille maximale d’image (plus une sécurité qu’autre chose), … Possibilité de signer les URLs avec une clef secrête, pour éviter que n’importe qui ne puisse générer des millions d’URLs différentes (devrait toujours être utilisé, en production !). Possibilité d’activer ou non du cache (pour éventuellement laisser Varnish faire) ou de pré-traiter des images (avec une queue, par exemple).

Mon avis : l’idée est sympa et l’API par URL peut faciliter le branchement. L’asbtraction du système de stockage un plus important. J’ai passé une partie de la conf à me dire que ça répondait exactement à un besoin que j’ai au bureau ^^


ZF3, le futur de PHP

la suite...

Gilles Février Gilles Février 2016-01-13T15:52:09+01:00

Le Forum PHP 2015, un grand cru ! :-)

Préambule : quelques problèmes techniques me rendent parfois la tâche un peu difficile pour publier régulièrement. C’est donc avec plus d’un mois de retard que je publie cet article… Plus de 600 personnes étaient présentes sur les deux jours de l’édition 2015 du Forum PHP qui s’est tenue les 23 et 24 novembre derniers. C’était … Continuer la lecture de Le Forum PHP 2015, un grand cru ! :-) 

Flux ATOM

Flux RSS
Twitter

Les sources

Ajouter une source ?

Envoyez un email avec l'URL du site et du flux à planetephpfr AT afup POINT org

Infos