Comments on Copies, tableurs, mails, et autres crottes de ragondin

Sans être un apologue de “maquereau-hard” (que j’utilise surtout par paresse de passer à autre chose), excel a au moins ce petit avantage qu’on peut lui demander de montrer les références de cellules en style “R1C1 / R(1)C(1)” (les parenthèses dénotant les références relatives) plutôt que le style par défaut “A1 / $A$1” (le préfixe $ dénotant les références absolues) : mine de rien le mode “R1C1” clarifie considérablement la syntaxe des formules répétées sur cellules adjacentes. Si cette option est disponible dans le tableur LibreOffice (n’ai jamais utilisé), ça devrait un peu te simplifier la vie…

Gros intérêt du format CSV ou “tab-separated” pour échanger les data tabulées entre plateformes faiblement compatibles : c’est du texte, donc avec un minimum de GREP on peut facilement redresser des petites choses comme points/virgules décimaux etc. Certes, il y a toujours l’encodage des caractères qui peut venir faire ch…

Je crois que les tableurs considèrent par défaut que “tout résultat qui a l’apparence d’un nombre EST un nombre, même si la data de départ est autre chose”.

JMU : bah non, l'idée de CSV est de rester le plus simple possible. Ca n'a jamais été normé et c'est voulu. Si tu veux de la structure et de la spec, prends du HDF ou du FITS, voire du INI.

Et en demandant aux collègues d'exporter en csv ? Ça permet d'être sûr que tout le formatage excel/libreoffice est supprimé, ainsi que les formules qui se sont mises à faire n'importe quoi. Et à l'ouverture dans libreoffice on peut choisir le séparateur décimal facilement. Ensuite, il faut le réimporter dans ton tableur à toi, pour avoir tes formules, ça ne je sais pas trop comment faire. Mais avec un script python, ça doit être bien plus simple. Moi je fais tout ça en pandas (dans emacs, avec des tableau org-mode et org-babel pour le code, mais un notebook jupyter devrait donner un résultat sympa aussi). Mais j'avoue que j'ai la chance de corriger mes copies tout seul, ou de donner des notes à des gens qui se fichent d'une quelconque normalisation.

Il y a une vraie raison de ne pas utiliser la virgule comme séparateur décimal, c'est que c'est aussi le délimiteur de colonne dans 99% des fichiers type CSV (ça ne s'appelle pas *comma*-separated value pour rien) qui est le format de sortie de moult appareils de mesure en sciences expérimentales et je suppose également de moult programmes pondant des données ailleurs. Je dirais que 90% des oscilloscopes en circulation ne permettent pas de sortir du CSV avec un autre délimiteur que la virgule (beaucoup peuvent sortir du format Excel en revanche, ce qui me dépasse - vu la lenteur, tout fichier de taille plus que "très petite" par rapport à ce que crache un oscillo est impossible à ouvrir - mais pas du ods, lol).

Alors certes, c'est une *mauvaise* raison parce que :
- pour ton cas précis on s'en fiche
- pour les tableurs en général, on pourrait imaginer que les fichiers "tableur" acceptent tous les séparateurs décimaux, mais que le séparateur soit converti en point lors d'un enregistrement en csv, et inversement lors de l'import d'un csv on reconvertit les points en le séparateur local - c'est un problème de programmeur, pas d'utilisateur
- le "format CSV" est une jungle horrible qui aurait pu être corrigée avec un peu de réflexion en amont (au hasard : on impose une ligne de header qui donne l'encodage, le séparateur décimal, le délimiteur de colonne et le délimiteur de texte)

@Ruxor: je pensais à une utilisation *de votre côté*, avec des convertisseurs (maison, gérant par exemple le problème du séparateur décimal pas forcément bien traité par les logiciels) et des nettoyeurs ("qu'il me faut ensuite expurger") automatiques entre les deux (mais je n'ai pas bien compris qui lisait et/ou écrivait les données).

Tu pourrais transposer ton tableau : ça permet de corriger une copie en passant de question en question avec enter plutôt que tab (donc de n'utiliser que le pavé numérique). Je ne sais pas si c'est spécifiquement gaucher, mais stylo rouge en main gauche + pavé numérique en main droite, c'est une super combo.

Il y a peu de chance que tu aies besoin d'une granularité supérieure à 0.1 par question un jour, donc tu peux aussi bien tout noter sur 10, et ça fait que tu tapes au max 2 caractères par question, et ce ne sont que des entiers, et ça dégage ta ligne 33 et le séparateur.

Tu peux faire des arrondis à 0.5 supérieur parce que tout le monde se tape de savoir si un élève a eu 12.2 ou 12.5, et ça règle le problème du 5.9 éliminatoire.

À ça, je rajoute en général une mise en forme conditionnelle (0/10 = fond blanc, 10/10 = fond gris ; valeur incorrecte = police rouge), une anonymisation des copies (les copies sont numérotées, je peux publier le tableau et il est anonyme donc ça pose pas de problème).

"Je n'aime pas la manière dont les tableurs incitent à faire travailler avec des des numéros de ligne et des lettres de colonne explicites, et obligent à tout stocker dans des cellules d'une structure 2d"; "on se retrouve à reproduire les formules à coup de copier-coller"

Pourquoi ne pas utiliser un SGBD (avec ou sans interface graphique fournie ou créée et/ou interface en ligne de commande) ?

Mon mutt est configuré pour un usage pro, voici comment je l'ai scripté pour diffusé un message à des élèves (ici, tous ont le même message, mais c'est trivial à modifier).

#!/bin/bash
# usage : ./diffusion-pub.sh listeEleves message.txt
RECIPIENTSLIST=$1
MESSAGEFILE=$2
#SUBJECT=$3
nbr=1
total=`cat $RECIPIENTSLIST | wc -l`
while read line
do
echo "sending to $line ($nbr/$total)"
mutt -s "$SUBJECT" $line < $MESSAGEFILE
let "nbr+=1"
done < $RECIPIENTSLIST

Il suffirait sans doute de quelques lignes dans un eleves.muttrc et d'ajouter le flag -Feleves.muttrc pour ajuster la config, si celle par défaut ne convient pas. Et peut-être ajouter des pauses pour limiter le débit d'envoi, ici très rapide.