Combattre le spam

S’il y a bien une chose de désagréable lorsqu’un met en place un site web, avec des formulaires de commentaires à la disposition des visiteurs, c’est vous l’avez deviné… le spam. Ça commence par un commentaire de temps en temps, puis un commentaire par jour, puis deux, puis trois et leur nombre augmente encore.

Pour lutter, j’avais donc mis en place le plugin Akismet, qui fait du bon travail, il faut bien le reconnaître. Néanmoins, je préfèrerais me passer de 251 commentaires classés indésirables en moins d’une journée. C’est pourquoi, après quelques recherches, j’ai trouvé le plugin GrowMap Anti-Spambot. Ce plugin ajoute une case à cocher pour confirmer que le visiteur n’est pas un spammeur, si la case n’est pas coché, le commentaire n’est pas sauvegardé. GrowMap ajoute également un champ de formulaire invisible pour les visiteurs mais visible pour un bot lisant le code source de la page. Le bot de spam va donc compléter le champ et identifier ainsi le commentaire comme étant du spam.

Je viens donc de désactiver Askimet pour tester GrowMap pendant quelques jours afin de juger son efficacité. Curieux de voir le résultat.

Pull Request: Remarques

Quelques bons usages qui peuvent faciliter l’acceptation d’une Pull Request sur Github et que j’ai découvert après quelques Pull Request.

  • Toujours décrire la fonctionnalité que vous ajoutez du mieux possible.
  • Faire des Pull Request contenant peu de fichier. On gagne ici en lisibilité. En effet, une Pull Request ajoutant 50 000 fichiers à cause de nouvelles dépendances, à beaucoup de chance de rebuter le développeur. En conclusion, faire quelque chose de clair!
  • Utiliser les outils de tests du projet. Cela nécessite peut-être de prendre en main des nouveaux outils mais augmente grandement les chances de faire accepter votre demande. Et surtout, vous évitez les commit de plusieurs milliers de fichiers.
  • Ça peut sembler idiot, mais utiliser le mécanisme de test du projet libre à la place de tester seulement son cas de test à la main peut vous évitez de chercher pendant des heures pourquoi cela ne marche pas comme vous le pensez.

Git: Les commandes de base

Passons en revue les commandes basiques dont vous aurez besoin dès les premiers instants de votre utilisation de Git.

Pour créer un nouveau dépôt, il suffit de créer un dossier pour celui-ci puis d’effectuer un git init en se plaçant dans le dossier.
A noter que dans notre cas, l’utilisation de Gitolite implique que le dépôt doit être créer par un administrateur en modifiant conf/gitolite.conf.
Pour cloner un dépôt existant, c’est-à-dire, le récupérer sur votre machine:
git clone http://github.com/path/depository.git
Par exemple, ou avec ssh:// selon le protocole.

Pour connaître les fichiers modifiés récemment:
git status

Pour voir ce qui a été changé:
git diff
Il est possible de spécifier un fichier après diff.

Pour ajouter des fichiers à prendre en compte lors du commit:
git add fichier1 fichier2

Pour faire un commit, ie sauvegarder vos changements:
git commit
git commit -a pour inclure tous les fichiers listés dans git status.
git commit fichier1 fichier2 pour indiquer précisément quels fichiers inclure.

Visionner les logs:
git log
Options utiles: -p ou –stat

Modifier le dernier message de commit:
git commit –amend

Annuler le dernier commit:
git reset HEAD^ (Les fichiers restent modifiés)
git reset –hard HEAD^ (Les changements effectués dans les fichiers seront perdus)

Restaurer un fichier à son état du dernier commit:
git checkout fichier

Récupérer les nouveautés présentes sur le serveur:
git pull

Envoyer ses propres modifications au serveur:
git push

Annulé un commit publié:
git revert idDuCommit

Les branches

Quand faire une branche:
« Créez une branche pour toute modification que vous vous apprêtez à faire et qui risque d’être un peu longue. »

Voir les branches:
git branch
On trouve une étoile devant la branche où on se trouve.

Créer une branche:
git branch nomBranche

Se placer dans une branche:
git checkout nomBranche

Fusionner une branche dans la branche où vous vous trouvez:
git merge nomBranche

Scier/Supprimer une branche:
git branch -d nomBranche

Pour changer de branche sans avoir à faire un commit avant:
git stash
A pour effet de mettre de côté les fichiers en cours de modification.
On peut alors changer de branche, faire des modifs et revenir dans la branche précédente où on retrouve son travail avec:
git stash apply

Autres fonctionnalités:

Tagger un commit:
git tag nomTag idCommit

Appliquer les tags:
git push -tags

Supprimer un tag:
git tag -d nomTag

Chercher les fichiers contenant un mot:
git grep « mot »

Pour obtenir également le numéro de ligne:
git grep -n « mot »

Je crois qu’on a fait le tour. Pour le reste, direction le manuel ou la doc en ligne ;).
ProGit Version Française.

[Vidéo] Sintel – Blender Fundation

Il y a quelques semaines sortait le court-métrage Tears of Steel de la Blender Fundation. Aujourd’hui, c’est le court-métrage précédent Sintel que je souhaite partager. Sintel raconte l’histoire émouvante de l’amitié entre une jeune fille et un dragon. Images superbes, bande-son magnifique… A découvrir sans plus attendre:

Lien vers « Sintel – Third Open Movie by Blender Foundation »

Gitolite: Installation

Pour pouvoir travailler à plusieurs sur un projet, ou même tout seul, mais avec un gestionnaire de version et pas un Dropbox inutile, je me suis penché sur l’installation d’un serveur Git, associé à Gitolite pour la gestion des utilisateurs.
Alors, pourquoi se faire son propre serveur, quel intérêt? Bien sûr, Github nous propose déjà ses services, mais pour héberger ses projets persos, pas encore près pour Github car trop jeune, ou ses projets d’école, rien de tel que son installation à soi. Rajoutons à cela la satisfaction d’héberger les données sur son propre serveur, en sachant que nous les contrôlons.

Trêve de bavardage, on va tout d’abord générer une clé rsa avec:
ssh-keygen -t rsa
Donner à la clé votre nom d’utilisateur.

On envoie la clé sur le serveur:
scp ~/.ssh/id_rsa.pub user@serveur.exemple.org:/tmp/user.pub

On se connecte au serveur via ssh et on obtient les droits root:
ssh user@serveur.exemple.org
sudo su –

On commence par installer tous les paquets nécessaires:
aptitude install  git-all perl openssh-server gitolite

On ajoute un utilisateur gitolite avec:
adduser gitolite

On passe à l’utilisateur gitolite:
su – gitolite

Et on exécute le script d’installation de Gitolite:
gl-setup /tmp/user.pub

Retour sur le poste client.
On va récupérer le dépot gitolite-admin qui va nous permettre de donner des droits et d’ajouter des utilisateurs via Git:
git clone gitolite@serveur.exemple.org:gitolite-admin

A ce stade, si un message vous indique que le dépot n’est pas valable, une opération s’impose pour forcer l’utilisation de la clé précédemment générée lors de la connexion.
Dans le fichier .ssh/config sur le poste client:

Host gitolite
User gitolite
HostName 37.26.241.58
IdentityFile ~/.ssh/user
IdentitiesOnly yes

Cela devrait régler le problème, sinon une recherche sur le net s’impose.

On se place dans le dossier:
cd gitolite-admin

On édite le fichier de conf pour ajouter un dépot, par exemple test:
vim conf/gitolite.conf

repo    test
RW+    =   user

On commit:
git commit -a -m « Add test repository »

On peut ensuite cloner le dépôt test:
git clone gitolite@serveur.exemple.org:test

Ajouter un readme à celui-ci:
echo « Test Repo » > README

Faire un commit:
git commit -a -m « Initial commit »

Et faire le premier push:
git push origin master

Voilà, à ce stade, le serveur Git fonctionne parfaitement et je suis en mesure de créer des dépôts, ajouter des utilisateurs, faire des commits, des push, des pull, etc…
Une seule contrainte, paramétrer les clefs sur chacun des postes de développement.
Autre point à éclaircir, le paramétrage des clefs sous Windows (Beurk), pour ceux qui développent sur cette plateforme avec des outils propres à cet OS (Dev Ps Vita).
Prochaines étapes donc: documenter ce point pour les éventuels utilisateurs et étudier l’installation du Etherpad-Lite modifié de Framasoft pour compléter les outils disponibles.
Et bien sûr, proposer ces outils aux amis et connaissances ;).

J’allais oublier les liens qui peuvent servir:
Gitolite sur Github
Gitolite dans la doc Ubuntu
Concernant le problème de dépôts/clefs:
http://serverfault.com/questions/270688/gitolite-clone-not-working-as-intended
http://www.dotkam.com/2010/08/22/gitolite-does-not-appear-to-be-a-git-repository/