Mois : juin 2018

Tests vs tdd

Bonjour,

Aujourd’hui j’aimerais m’entretenir sur l’importance des tests unitaires, d’intégration, de charge et autres.

Il est très important d’effectuer des tests.

Faire du TDD ou écrire les tests après coup importe peu. Je pense que faire des tests sur les getters et setters devient un fardeau plus qu’une aide.

Certains setters ne sont pas triviaux, comme une conversion ou un casting. Dans ce cas, on peut avoir besoin d’en faire le test.

Ce qu’il ne faut pas faire, c’est réparer du code sans en écrire un test.

Une bonne pratique, plus que l’écriture des tests avant le code, a mon avis, est d’écrire un test avant la correction de bug.

C’est là que réside la puissance de l’automatisme. On remarque le comportement erroné du code. On écrit le test qui devrait passer au vert après correctif. Enfin, on écrit le patch qui fera passer le test.

Ainsi, on fait le plus important, des tests de non régression.

Soap en PHP

Bonjour,

J’ai un travail qui implique d’écrire un service soap en php. Et certaines taches de ce service sont aussi d’utiliser soap en tant que client vers un autre serveur.

J’ai fais un exemple minimal afin de me mettre sur les rails. C’est un exemple trouvé sur github que j’ai légèrement modifié

serveur.php

<?php
class MySoapServer{
 public function getMessage(){
 return 'Hello,World!';
 }
 public function addNumbers($num1, $num2){
 return $num1+$num2;
 }
}
$options = [
 'uri'=>'http://localhost/test'//je sais pas a quoi ca sert
];
$server = new SoapServer(NULL,$options);
$server->setClass('MySoapServer');
$server->handle();

client.php

<?php
$options = [
 'location' => 'http://localhost:8000',
 'uri' => 'http://localhost/everth',//je sais pas ce que c'est
 'exceptions' => false
];
$client = new SoapClient(NULL,$options);
echo $client->getMessage();
echo $client->addNumbers(3,5);

Pour tester :

php -S 0.0.0.0:8000 serveur.php
php client.php

 

Régler php-fpm

Bonjour,

Il y a quelques années, j’utilisais suexec pour qu’apache gère php en tant qu’utilisateur local. Cette solution ne marche que sous certaines conditions, et cgi n’en fait pas partie.

Quand j’ai mis php en fast-cgi afin d’en utiliser plusieurs versions, la création et modification de fichiers via php est devenu problématique.

Il y a plusieurs solutions à ce problème.

  • chmod 777
  • mount bind avec changement d’utilisateur
  • acl

Celle que j’ai retenu, c’est de régler php-fpm pour changer l’uid et gid du site.

Par défaut c’est www-data qui exécute les pages du site. Pour changer celà, on va regarder pas a pas ce qu’il faut faire.

Il faut avoir php en fast-cgi.

Je donne ci-dessous un exemple pour php7.2, mais on peut facilement adapter et faire fonctionner le truc pour php5 ou 7.0.

On arrete le service php-fpm

sudo /etc/init.d/php7.2-fpm stop

On règle certaines variables

site=www.symfony.loc
repertoire=/home/brahim/symfony/www
utilisateur=brahim
groupe=brahim
sudo /etc/init.d/php7.2-fpm stop
sudo cp /etc/php/7.2/fpm/pool.d/www.conf  /etc/php/7.2/fpm/pool.d/${site}.conf

On copie et modifie le fichier pool fpm

site=www.symfony.loc repertoire=/home/brahim/symfony/www utilisateur=brahim groupe=brahim sudo /etc/init.d/php7.2-fpm stop sudo cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/${site}.conf

On modifie le fichier fraîchement copié

sudo nano -w /etc/php/7.2/fpm/pool.d/${site}.conf

Il faut remplacer :

  • [www] -> [www.symfony.loc]
  • user = www-data -> user = brahim
  • group = www-data -> group = brahim
  • listen = /run/php/php7.2-fpm.sock -> listen = /run/php/php7.2-www.symfony.loc.sock

Il faut adapter les changements en fonction du site.

Enfin, on lance le service

sudo /etc/init.d/php7.2-fpm start

Voilà, le site tournera sous les droits de brahim:brahim.

Plus besoin de changer via chmod ou autre.

Faire attention à ses données

Introduction

Bonjour,

Aujourd’hui, on va parler des données. On n’est jamais trop paranoïaque quand il s’agit de sauvegarder ses données.

Je ne vais pas imposer les mesures de certaines entreprises qui imposent 2 sauvegardes éloignées de plus de 50km dans des coffres forts pour se pré-munir aux catastrophes genre incendie, tremblement de terre, vol industriel ou vandalisme.

Ici, je vais juste donner des petites astuces faciles à mettre en oeuvre, qui sauveront la vie un jour ou l’autre.

Clé usb

Les clés usb ne sont pas faites pour stocker les données. Elles sont faites pour transporter les données.

Il faut toujours avoir une copie de tout le contenu de sa clé ailleurs.

On ne travaille jamais directement sur le fichier depuis la clé usb. On fait une copie sur le bureau (ou dans mes documents), on effectue son travail, et ensuite on écrase la copie sur clé usb. Si l’ordinateur n’est pas à nous, on peut supprimer le fichier et vider la corbeille.

Si on a son travail dessus afin d’utiliser différentes machines, on désigne un des ordinateurs en tant que « responsable » de ce fichier. Dès que possible, on copie le fichier sur l’ordinateur responsable. Il se peut que sur la même clé on ait des fichiers qui ont des responsables différents.

Si on perd la clé usb, on sait ou trouver la dernière version des fichiers, et on aura perdu 1 journée max de travail.

Disque dur externe

Ne jamais attacher un disque externe en permanence sur son ordinateur. Si on a besoin de place, on en fait, ou on achète un disque dur interne plus gros.

Il est possible d’avoir en permanence un disque externe dans son cartable, mais il faut pouvoir se dispenser d’avoir à le brancher systématiquement.

Les films, musiques, téléchargements, photos seront délestés du disque principal et migreront vers le disque externe.

Un disque dur externe appel naturellement à la catastrophe avec son câble qui fait une si jolie opportunité pour le faire voltiger. Il faut faire attention à toujours le poser au milieu du bureau afin de ne pas avoir de boucle au bord de la table.

Alimentation

Il ne faut jamais bouger un disque sous tension (sauf SSD). Toujours poser son disque dur, ou laptop, avant de l’allumer. Et toujours attendre l’extinction avant de commencer à le ranger.

Sauvegarde

On peut sauvegarder toutes ses données sur le cloud, mais il y a toujours le risque que la société coule ou arrête le produit. Dans ce cas, on perd toutes nos données sans forcément de préavis ou trop court pour agir efficacement.

Il faut donc enregistrer ses données dans un disque dur local. De préférence que l’on ne bouge jamais (sur un vieil ordi qui joue le rôle de serveur de sauvegarde). Pas forcément allumé 24h/24, mais qui fait des sauvegardes au moins 1 fois par jour : on allume, on lance la sauvegarde, puis on éteint.

Régulièrement (une fois par semaine, par exemple), on branche un disque externe à notre serveur de sauvegarde pour récupérer l’intégralité de son contenu. Ce disque est dédié à la sauvegarde et ne bouge que pour aller de son tiroir de rangement, vers le serveur et y revenir le plus tôt possible. Ne pas laisser le disque dur externe attaché en permanence sur le serveur. Il suffirait d’un dysfonctionnement électrique pour griller les 2 seules sauvegardes locales.

Quoi sauvegarder ?

Il est inutile de sauvegarder des données que l’on peut récupérer facilement, comme la musique, les films, les logiciels téléchargés. Les bons candidats à la sauvegarde son les fichiers que l’on a créé soit même : Document office, photos et vidéos de vacance ou pro, codes sources (repository git par exemple), sauvegardes des jeux, etc.

Il ne faut pas hésiter à mettre tout le matériel électronique sous la sauvegarde. Ordinateur de bureau, ordinateur portable, téléphone, paramétrage du routeur etc.

Logiciel pour sauvegarder

Certains apareils ont un logiciel spécifique pour le tansfert, comme les smartphones, en revanche, ce qui est sur ordinateur peut être facilement mis à jour, grâce à des copies incrémentales (qui ne copie que ce qui à changé) via rsync ou cobian backup, pour ne citer qu’eux.

Conclusion

Il ne faut pas négliger la sauvegarde régulière de ses données et aussi vérifier de temps en temps que la sauvegarde automatique (si on opte pour celle ci) stock bien tous les fichiers.

Des petites habitudes évitent bien des déboires plus tard, ce n’est pas trop contraignant et comme dit plus haut, ça sauve la vie.

Awardspace, 1 an après

Bonjour,

Comme vous le savez, j’ai testé certains hébergeurs gratuits et j’ai retenu Awardspace.

Cela fait déjà 1 an. Et j’ai reçu une invitation à renouveler mon abonnement (toujours gratuitement).

Je garde donc la même formule, et en un clic, c’est reparti pour un an, je garde aussi le nom de domaine (un sous domaine chez eux pour être exact) enregistré.

Avec le temps, je me suis aperçu de certaines limitations qui peuvent avoir pesé dans la balance lors du test des hébergeurs.

  • Https ne fonctionne pas
  • La fonction mail (envoi via php) est bloquée
  • La racine du site est la racine du répertoire du compte
  • Pas de ssh
  • Pas de git

Parmis les points positifs

  • Version de php5.6 à php7.2 au choix
  • 1 Go d’espace disque
  • 5 Go de transfert par mois
  • Toujours rapide et jamais down
  • Compression http (mod_deflate)
  • Gestion du cache (mod_expires)
  • Réécriture d’url (mod_rewrite)

Alors, le verdict ?

Malgré les limitations rencontrées au fil de l’utilisation, je reste satisfait et je n’ai pas envie de refaire une session de test.

Il me serait plus naturel de discuter des points évoqués sur une option payante avec eux que de choisir un autre hébergeur que je connais moins et qui pourrait me donner moins de liberté que là où je suis.