Développement

Je publie aujourd'hui une première version fonctionnelle et presque totalement testée d'un validateur de fichier CSV : deblan/csv-validator. J'ai décidé de m'appuyer sur les contraintes de validation proposées dans Symfony.

Pour installer ce composant, il faut passer par composer :

composer require deblan/csv-validator dev-master

Voici un exemple simple et concret :

C'est sous lience BSD donc éclatez-vous avec !

Au mettre titre que SVN, je vais déployer progressivement des hooks pour traiter le code source "pushé" vers mon Gitlab (et les projets que je gère).

En m’appuyant sur un script récupéré sur Github, j'ai réalisé un hook GIT pre-receive qui permet de vérifier que le code soumis est valide PSR2. Il fonctionne pour le moment très bien mais je suis ouvert aux corrections si vous en avez à me proposer. Il faudra prendre une ou deux minutes pour configurer les premières variables.

Une nouvelle version de mon wall vient d'être mise ligne ! Bienvenue GIST.

• Du chiffrement : on peut à présent partager du code colorisé chiffré et déchiffré coté navigateur
• L'application est fondée sur git et permet de versionner les modifications réalisées sur du code et d'accéder aux différentes versions avec des diff
• Il est à présent possible d'insérer sur son site le résultat de la colorisation
• L'application est multilingue et fonctionne très bien sur téléphone
• Toujours et encore libre, avec une procédure d'installation simplifiée !

La procédure d'installation :

Les gens qui travaillent avec moi savent que je suis un "Syntax nazi". Je ne supporte pas quand le code ne suit pas les conventions. Ainsi, pour éviter de rager quand j'update mes sources, j'ai décidé de créer un hook SVN pour valider les commits des fichiers PHP.

Vous l'aurez donc compris, il s'agit ici de valider les uniquement les fichiers PHP suivant la norme PSR2. Par ailleurs, je ne m'attarde que sur le code de l'équipe de développement. Il s'agit donc de tout ce qui se trouve dans le répertoire "src" des applications symfony2 que nous développons.

Un hook SVN est un script qui sera exécuté à un instant donné et qui, suivant le code d'erreur, va valider ou non l'action en cours. Dans le cas de commit SVN, le hook est "pre-commit". Il se place dans le répertoire "hooks" du dépôt SVN et se nomme "pre-commit". Vous y trouvez d'ailleurs des fichiers .tmpl donnant quelques exemples.

Mon script s'appuie sur PHP_CodeSniffer (phpcs) que j'ai installé via composer. En effet, il existe un paquet Debian pour phpcs mais le standard PSR2 n'est pas pris en charge dans celui de la Wheezy (version de Debian du serveur SVN).

Voici le contenu du script :

#!/bin/sh

SVNLOOK=/usr/bin/svnlook
PHPCS=/usr/local/src/phpcs/vendor/bin/phpcs
STANDARD=PSR2
SEVERITY=1
FINAL_REPORT=

for FILE in `$SVNLOOK changed -t "$2" "$1" | egrep -v '^D' | cut -b 5- | egrep '^src.*\.php$'`; do
    REPORT=`$SVNLOOK cat -t "$2" "$1" "$FILE" | $PHPCS --standard=$STANDARD -n --report=full --error-severity=$SEVERITY | sed 's,STDIN,'$FILE','`

    if [ -n "$REPORT" ]; then
        FINAL_REPORT="$FINAL_REPORT$REPORT\n\n"
    fi
done

if [ -n "$FINAL_REPORT" ]; then
    echo "$FINAL_REPORT" >&2
    exit 1
fi

exit 0

Voici un exemple de sortie lorsque la validation échoue :

Envoi          src/FooBar/Bundle/PacteBundle/Controller/CollaboratorController.php
Envoi          src/FooBar/Bundle/PacteBundle/Controller/PacteController.php
Envoi          src/FooBar/Bundle/PacteBundle/Controller/TeamController.php
Transmission des données ..svn: E165001: Échec de la propagation (commit), détails : 
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

FILE: src/FooBar/Bundle/PacteBundle/Controller/CollaboratorController.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
 18 | ERROR | Spaces must be used to indent lines; tabs are not allowed
 18 | ERROR | Line indented incorrectly; expected at least 4 spaces, found 1
 18 | ERROR | Line indented incorrectly; expected 4 spaces, found 1
 19 | ERROR | Opening brace indented incorrectly; expected 1 spaces, found 4
 32 | ERROR | Closing brace indented incorrectly; expected 1 spaces, found 4
--------------------------------------------------------------------------------


FILE: src/FooBar/Bundle/PacteBundle/Controller/PacteController.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
 15 | ERROR | Spaces must be used to indent lines; tabs are not allowed
 15 | ERROR | Line indented incorrectly; expected at least 4 spaces, found 1
 15 | ERROR | Line indented incorrectly; expected 4 spaces, found 1
 16 | ERROR | Opening brace indented incorrectly; expected 1 spaces, found 4
 18 | ERROR | Closing brace indented incorrectly; expected 1 spaces, found 4
--------------------------------------------------------------------------------

Édit : mise à jour du code qui plantait lors de la suppression d'un fichier.

Le développement d'applications web nécessite souvent l'envoi d'emails, ne serait-ce que pour la gestion d'un espace membre par exemple. On a deux façons de voir les choses quand on est encore en phase de développement :

• Utiliser un serveur de mail "fake" qui va délivrer une copie du mail si il avait été envoyé
• Utiliser un vrai serveur d'envoi de mail

La première méthode est pas mal du tout, cependant il arrivera le moment où il faudra vraiment envoyer le mail, ne serait-ce que pour s'assurer qu'on n'est pas passé à côté de quelque chose (comme un problème lié aux clients mails). Ainsi, je suis assez partisant d'envoyer du vrai mail, même dans la phase de développement.

Pour se faire, deux nouvelles solutions s'offrent à nous :

• Passer par un serveur de mail en local pour délivrer le mail
• Passer par un relais SMTP pour délivrer le message

Dans le premier cas, vous avez 1 chance sur 100 que le message ne soit pas bloqué par les services anti-spam. Du coup, on va préférer passer un relais SMTP qui lui ne devrait pas poser de problème.

Pour se faire, on va installer un serveur de mail en local puis configurer un relais SMTP. Ça veut dire que le serveur de mail va faire office de client pour se connecter à un autre serveur de mail pour délivrer nos messages. Le principal intérêt de cette méthode est que quelque soit le programme qui enverra du mail en utilisant le serveur de mail "localhost" pourra faire transiter les messages vers le relais SMTP et les délivrer correctement.

Le seul pré-requis est d'avoir un relais SMTP sur lequel se connecter. En d'autres mots, vous devez avoir un prestataire d'envoie de mail qui n'est pas trop restrictif (donc pas Free par exemple) : OVH, Gandi, Gmail, …

Il faut déjà installer un serveur de mail sur sa machine. Je vous propose d'utiliser Postfix dont la renommée n'est pas à faire :

$ su - 
# aptitude update
# aptitude install postfix

Éditions à présent le fichier de conf (/etc/postfix/main.cf) :

[...]
myhostname = exemple.fr

relayhost = serveur.smtp.relais # exemple : mail.deblan.fr
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
[...]

Il est nécessaire de prévoir un fichier pour s'authentifier sur le serveur SMTP relais :

# touch /etc/postfix/sasl_passwd
# echo "serveur.smtp.relais login:password" > /etc/postfix/sasl_passwd

Modifiez le login et le password, si le login contient un "@", remplacez le par "#".

# postmap /etc/postfix/sasl_passwd (à faire à chaque modification du fichier)
# chown root:root /etc/postfix/sasl_passwd*
# chmod 600 /etc/postfix/sasl_passwd*
# service postfix restart

À présent, si le relais mail n'est pas bloquant et que les identifiants sont bons, vous passerez par un "vrai" serveur de mails pour délivrer les messages de votre espaces de développement (et pas que).

Si vous envoyez le mail au nom d'un domaine qui n'est pas celui du serveur de mail, il faudra prendre le temps de faire une configuration SPF pour rendre l'envoi de mail légitime depuis ce serveur relais. À titre d'exemple, j'ai deux serveurs de mails qui peuvent délivrer des messages avec comme domaine d'expédition "deblan.fr". Les ip's associées sont 5.135.190.125 et 109.190.159.83. Voici les entrées DNS que j'ai créées :

$ dig -t TXT deblan.fr
[...]
deblan.fr. 10739 IN TXT	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN TXT	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

$ dig -t SPF deblan.fr
[...]
deblan.fr. 10739 IN	SPF	"spf2.0/mfrom mx ip4:109.190.159.83 ip4:5.135.190.125 ~all"
deblan.fr. 10739 IN	SPF	"v=spf1 ip4:109.190.159.83 ip4:5.135.190.125 ~all"
[...]

Si je fais un test de query SPF, voilà résultats :

$ spfquery -i 5.135.190.125 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 5.135.190.125 as permitted sender) client-ip=5.135.190.125; envelope-from=foo@deblan.fr;
'
$ spfquery -i 109.190.159.83 -s foo@deblan.fr | tail -n 1
Received-SPF: pass (spfquery: domain of deblan.fr designates 109.190.159.83 as permitted sender) client-ip=109.190.159.83; envelope-from=foo@deblan.fr;

$ spfquery -i 1.2.3.4 -s foo@deblan.fr | tail -n 1
Received-SPF: softfail (spfquery: transitioning domain of deblan.fr does not designate 1.2.3.4 as permitted sender) client-ip=1.2.3.4; envelope-from=foo@deblan.fr;

Les 2 ip's que je rend légitimes passent le test sans problème alors que le 3ème est en échec. Ce test SPF devient très important et par expérience, c'est la source de beaucoup de rejets. Si vous avez des IPV6, pensez à les déclarer, je me suis fais avoir il y a quelques jours encore :)

J'espère que ça vous sera utile :)