Les Mongueurs de Perl. Articles. Les mongueurs publient des articles consacrés à l'exploration de Perl dans Linux Magazine depuis le numéro 41 avec la série introductive par Sylvain Lhullier. Depuis Linux Magazine 59, une rubrique régulière s'y est ajoutée : Perles de Mongueurs. Les articles des Mongueurs ont également été repris sous la forme de dossiers (avec des inédits) dans la collection Les dossiers de Linux Magazine. Jifty-fifty, par Charles Minc.
Jifty est un framework avec son ORM(Jifty-DBI) qui est censé permettre le développement simple et rapide d'application. Le slogan des auteurs est "Just fucking do it ". Développement de sondes Nagios, par Guillaume Rousse. Paru dans Linux Magazine 129, juillet/août 2010. Dist-Zilla - Distribution simplifiée pour auteur CPAN, par Jérôme Quelin. Paru dans Linux Magazine 128, juin 2010. Si vous utilisez Perl, vous connaissez déjà le CPAN, proposant plus de 10000 modules réutilisables pour gagner en temps et en qualité. Le langage PIR (4), par Christian Aperghis-Tramoni. ENOPERL. Perles de Mongueurs (28) J'utilise un serveur Linux pour quelques développements internes à mon travail. Il s'agit d'un PC de récupération, sans écran ni clavier, posé sous un bureau, auquel je me connecte par SSH depuis un portable Windows. Il arrive trop souvent hélas que mes collègues l'éteignent le soir en partant. Ou alors ce sont les personnes chargées du ménage qui le débranchent pour brancher l'aspirateur !
;-) Le serveur obtenant son adresse IP par DHCP, celle-ci peut changer au démarrage et il est parfois un peu laborieux de chercher un clavier et un écran, juste pour regarder le résultat de la commande ifconfig. Heureusement, c'est la seule machine du sous-réseau qui fasse tourner le service SSH. J'ai donc programmé un scanneur de ports minimal qui cherche les machines connectées au réseau, et tente de se connecter au service SSH. $|++ permet de passer en mode sans temporisation (ou autoflush), afin d'afficher des points pour indiquer la progression du script. Et voici le résulat :
Tests et Perl - Bonnes pratiques. Compartimenter ses tests Une question qui peut venir à l'esprit est de savoir comment répartir ses tests. Vaut-il mieux les mettre tous dans un seul script ou au contraire les répartir le plus possible ? La réponse est que cela dépend :-) En particulier, cela dépend du code testé et du nombre de fonctions ou fonctionnalités à tester. S'il ne possède qu'un nombre restreint de fonctions ou un périmètre fonctionnel très délimité, l'ensemble des tests peuvent alors tenir dans un seul script court. Quand le code à tester comporte un périmètre fonctionnel plus important, la solution la plus pratique est d'écrire un script par fonction, groupe de fonctions, fonctionnalité ou type de données à traiter, suivant les spécificités du code en question.
Dans le cas du module Parse::Syslog::Mail, assez simple puisqu'il ne fournit que deux méthodes, les scripts se répartissent les tâches de la manière suivante : Pourquoi compter ses tests Test::More 1..51 ok 1 ok 2 ... ok 22 ok 23 Portabilité. Les tests en Perl. Perl dispose depuis longtemps (Perl 1 l'utilisait déjà) d'une technique de test assez simple mais assez efficace. Elle consiste à exécuter des scripts qui vont réaliser des suites de tests basiques pour vérifier le bon fonctionnement du programme testé. Chaque test signale s'il s'est bien exécuté ou pas en affichant sur la sortie standard "ok" ou "not ok". Cela fonctionne donc sur un principe similaire aux checklists effectuées par les ingénieurs de l'ESA ou de la NASA (où Larry Wall a d'ailleurs travaillé).
Illustrons avec un exemple trivial : $a = 1 + 1; print $a == 2 ? "ok\n" : "not ok\n"; Et pour connaître l'avancement des tests en cours, il suffit que le script de test affiche avant cela le nombre total de tests qu'il compte exécuter : print "1..2\n"; # pour exécuter deux tests Cela permet de savoir où on en est et de vérifier si, à la fin du script, on a bien exécuté le nombre de tests annoncés. Perl Testing: A Developer's Notebook Séance de dissection Bail out! Conformance is(), isnt() Scponly. Nous aurons besoin d'une distribution Linux minimaliste. Une Debian avec le strict nécessaire sera largement suffisante. deborphan et dpkg avec son option -l pourront être utiles pour déterminer les paquets inutiles installés ou les paquets orphelins. Il faudra tout de même quelques paquets supplémentaires : scponly fournit un shell minimaliste qui ne permet que l'exécution des commandes scp. Il est compatible avec la plupart des clients SCP pour Microsoft Windows (WinSCP au moins).
Il offre aussi une possibilité de mise en cage (chroot) ;iptables regroupe les commandes qui permettent de manipuler Netfilter (le pare-feu du noyau Linux pour peu que le noyau ait été compilé avec l'option CONFIG_NETFILTER=Y) ; Il faudra configurer un démon SSH (OpenSSH est un excellent choix) de manière à n'autoriser que des utilisateurs connus mais en ne leur laissant pas le loisir de manipuler leurs propres informations d'authentification. Useradd -s /usr/bin/scponly mon-compte-scponly.