Tests de performances avec jmeter

13 11 2015

Hello,

Je suis de retour, après une longue absence.

Ces dernières années,  j’ai grandement amélioré mes compétences sur les tests de performances via des expériences professionnelles enrichissantes.

Voici le blog de mon collègue Milamberspace, qui m’a permis d’approfondir mes connaissances sur cette outils :  http://blog.milamberspace.net/

Bonne lecture ,

Dans un prochain billet, je tenterai de mettre en évidence un comparatif entre 2 solutions : Gatling et Jmeter.

 

 





PHP 5.4 – Les nouvelles

24 01 2012

La sortie de PHP5.4 version stable est prévue pour bientôt .

La version RC3 contient pour le moment :

  • Amélioration de l’extension
  • Built-in webserver
  • Traits
  • déréférencement des tableaux
  • Les appels de méthodes via les tableaux
  • La notation binaire pour les entiers
  • Instanciation d’une classe sans passer par son constructucteur
  • Amélioration de l’extension Json
  • Amélioration de l’extension Curl

Dans un prochain billet je reviendrai sur la signification de chacun de ces points.

 





Intégration continue en PHP ou comment industrialiser vos développements PHP ?

17 12 2009

Je présente dans ce billet, mon article sur l’intégration continue que j’ai rédigé dans le cadre professionnel. Cet article est également publié dans le blog de mon entreprise Alti.

Qu’est ce que l’intégration continue ?

« L’intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement ». (Source : wikipedia).

Je rajouterai à cette définition, la notion de « build » a pour objectif de générer automatiquement un produit opérationnel et testable. Cette approche consiste à inspecter (revue de code), compiler, tester (tests unitaires, tests d’intégration, de performance..), déployer, documenter, notifier (Email, Sms, rsss…).

Pourquoi l’intégration continue ?

Source : martinflower.com

Comme schématiser ci-dessus, en général, dans un projet dépourvu de plateforme d’intégration continue, plus le projet grossi en termes de code et de nombre de développeur, plus le nombre de bugs augmente. En général, ces bugs sont corrigés en phase de recette. Par contre il y’a toujours une limite dans la correction de ces bugs (limite rouge), dans le sens où il y’a de très fortes chances d’avoir des « bugs cachés » indétectable par l’utilisateur et là « Oups !! bonjour les dégats ».

De plus on entend souvent de la part des développeurs, une fois avoir livré une fonctionnalité à l’utilisateur des réflexions du genre : « Ca ne marche pas chez toi !!!C’est bizarre pourtant Ca marche sur mon poste de développement».

En plus de pouvoir livrer automatiquement sur un environnement, une plateforme d’intégration continue permet d’éviter ce genre de problème.

Comment ça marche ?

Pour appliquer cette technique, il faut d’abord que :

– l’équipe mette en place un environnement de travail stable et homogène incluant par exemple :

  • une instance virtuelle LAMP (VMWARE) proche techniquement de l’environnement cible
  • Un IDE du type éclipse PDT ou Zend Studio qui exploite l’environnement d’exécution PHP localisé sur le serveur LAMP. Cet IDE facilite le débogage et le travail au quotidien avec des technologies « externes » (XML, webservices, Javascript) dont les plugins sont maintenus par des spécialistes.

– le code source soit partagé (en utilisant des logiciels de gestion de versions tel que Subversion) ;

– les développeurs intègrent dans leur méthode de développement des tests unitaires, tests d’intégration, de performance, des tests IHM automatiques avec sélénium et PHPUnit

– les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications ;

– Ensuite, il faut un outil d’intégration continue tel que Hudson , Xinc ou PHPUndercontrol pour automatiser les tâches de vérification, de compilation, de déploiement et de consolidation des indicateurs de qualité logiciel.

Une telle technique de développement permet de :

  • diminuer fortement les problématiques de déploiement lors de la mise en recette ou en production de l’application.
    • les problèmes d’intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute ;
    • test immédiat des unités modifiées ;
    • prévient rapidement en cas de code incompatible ou manquant ;
    • une version est toujours disponible pour test, démonstration ou distribution
  • aider l’équipe projet à connaître l’état de son projet en fonction d’indicateurs tels que :
    • la proportion des intégrations réussies/échouées
    • l’évolution de la couverture de code. Le code coverage permet d’analyser les statistiques et le détail de la couverture de code des tests unitaires
    • l’évolution des tests unitaires (échoués/total)
    • l’évolution du nombre de violations. Le CodeSniffer permet de fournir un résumé par classe avec le nombre d’erreurs et de warnings générés par fichier
    • Il faut donc documenter le code avec la PHPDoc et écrire les tests unitaires avant de coder les méthodes correspondantes
  • dynamiser le développement, responsabiliser les développeurs et toujours disposer d’un build qui fonctionne.
  • fiabiliser le code en insistant sur les tests unitaires et accroître la qualité logicielle

Comment le mettre en place dans une entreprise ?

Commencer petit (test unitaires, métriques) et rester pragmatique.

Avoir un projet pilote…

Communiquer sur l’existence de ce service et avoir des retours

La pertinence de l’intégration continue s’amplifie lors que l’on conduit un projet avec des méthodes agiles

Conclusion

L’intégration continue, de nos jours est le moyen le plus efficace d’éviter le « boom » pendant une phase d’intégration. Elle permet d’avoir des applications plus robustes et fonctionnellement pertinentes, de capitaliser des bonnes pratiques de fabrication logiciel.

L’intégration continue pouvant être automatisable, et qui dit automatisable dit réactivité, donc plus de réactivité dans nos projets.





Symfony: Comment spécifier une rangée de date pour sfWidgetFormDate?

28 08 2009

A ma connaissance,  Symfony ne nous permet pas encore de spécifier automatiquement  dans les formulaires de type date les options ‘year_min’ and ‘year_max’, alors je propose une solution pour pallier à ça :

$years = range(1920, 2000); //On crée par exemple un tableau de valeur
$years_list = array_combine($years, $years);
new sfWidgetFormDate(array('years' => $years_list))

Et voilà..





Bug dans PHP5.3.0 Pear.bat

11 08 2009

Dans un Projet PHP avec une plateforme Windows (dommage!! je sais), j’ai  suivi les indications qu’ il faut exécuter le go-pear.bat présent à la racine du dossier de PHP (soit c:\wamp\bin\php\php.5.3.0\ par défaut)

C’est ce que je fais, mais patatrac, je me trouve confronté à une, voire deux erreurs :

phar « C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar » does not have a signature

PHP Warning:  require_once(phar://go-pear.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar « phar://go-pear.phar/index.php » in C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar on line 1236

Warning: require_once(phar://go-pear.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar « phar://go-pear.phar/index.php » in C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar on line 1236

Grâce à Google , j’ai trouvé la solution(Ce fût difficile, raison pour laquelle je poste ce billet qui peut être utile à d’autres) :

Modifier directement votre php.ini, en cherchant la directive phar.require_hash, la décommenter et lui donner la valeur Off.





Rasmus Lerdorf , le fondateur de php quitte yahoo

30 07 2009

Suite à l’annonce de la fusion entre Microsoft et Yahoo sur les moteurs de recherche,  Rasmus  fondateur de PHP , produit Open Source annonce qu’il va quitter Yahoo.

Comme il dit dans son blog twitter  » As lame as I feared – time to find a new job« 





Gmail n’est plus en bêta !!! ou presque

9 07 2009

Que les quelque 100 millions de « testeurs » de Gmail se réjouissent ! Google vient d’annoncer aujourd’hui que Gmail perdait son statut de version bêta !!

Après plus de 5 ans de développement et d’améliorations, l’éditeur a enfin décidé de sortir toutes ses Google Apps (Gmail mais aussi Google Calendar, Google Docs et Google Talk) de leur « phase d’expérimentation ». Rassurez-vous, rien ne change : seule la petite mention BETA en gris disparaît.

Pour ceux qui avaient fini par s’habituer, l’équipe de développement propose avec humour une  option inédite dans les Gmail Labs. L’application Retour à la version bêta permet ainsi de retrouver la mention BETA sous le logo Gmail.

Reste que Gmail a largement contribué à rendre la notion de version bêta toute relative. Est-ce grave docteur ?