Matthieu a écrit 16 commentaires

  • # Très bon article, merci !

    Posté par  (site web personnel) . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 5.

    Merci pour ce lien vers un très bon tuto, bien documenté et clairement présenté. Je voulais m'essayer à utiliser BorgBackup depuis un moment, cela sera peut-être l'article qui me permettra de m'y mettre enfin !

    J'attends la suite avec impatience pour en savoir plus sur la sauvegarde sur un serveur distant en particulier :)

  • [^] # Re: Petite correction des titres de sections

    Posté par  (site web personnel) . En réponse à la dépêche GIMP 2.10.34 est sorti. Évalué à 4.

    Effectivement à certains endroits on avait gardé les termes originaux en anglais pour plus de clarté, mais là c'était bien une erreur de ma part :)

    Au passage merci Jona d'avoir initié cette dépêche et de l'avoir menée jusqu'à sa publication !

  • # Petite correction des titres de sections

    Posté par  (site web personnel) . En réponse à la dépêche GIMP 2.10.34 est sorti. Évalué à 4. Dernière modification le 27 avril 2023 à 12:09.

    Oups, j'ai oublié de retirer le texte en anglais de certains titres de sections pendant la traduction de certains passages de cette dépêche…

    Si un membre de l'équipe de modération passe par là, est-il possible de retirer les passages "(Original: <du texte en anglais>)" qui restent dans trois des titres de sections, pour ne garder que les titres en français ? Merci beaucoup et désolé pour cette étourderie :)

  • [^] # Re: Possibilité de visionner la conférence en différé ?

    Posté par  (site web personnel) . En réponse à la dépêche Conférence "GIMP et ZeMarmot" à Vandœuvre-lès-Nancy. Évalué à 1.

    Merci pour vos réponses :) J'essaierai de revisiter leur instance PeerTube de temps en temps pour voir si la vidéo est mise en ligne !

  • # Possibilité de visionner la conférence en différé ?

    Posté par  (site web personnel) . En réponse à la dépêche Conférence "GIMP et ZeMarmot" à Vandœuvre-lès-Nancy. Évalué à 1.

    Ayant malheureusement manqué la diffusion en direct, je me demandais s'il existait une possibilité de visionner la conférence en différé ?

    J'ai tenté le lien du direct (https://fccl-vandoeuvre.fr/film), en espérant qu'il pointerait peut-être vers une archive de la vidéo, mais apparemment la vidéo ne marchait que pendant le direct (ou alors j'ai peut-être manqué quelque chose sur la page ?).

    J'en profite pour remercier Jehan et Aryeom pour leur super travail sur Gimp et ZeMarmot ! :)

  • # Vidéos disponibles en ligne

    Posté par  (site web personnel) . En réponse au lien Conférence RStudio : présentations accessibles en direct en ligne les 27 et 28 juillet. Évalué à 2.

    Les enregistrements des présentations et les supports utilisés pendant les ateliers sont maintenant disponibles en ligne:

  • # Typo lien

    Posté par  (site web personnel) . En réponse au journal Ada au FOSDEM. Évalué à 2.

    Il y a une petite faute de frappe dans le lien pour la traditionnelle présentation de Jean-Pierre Rosen qui empêche le lien de fonctionner (un caractère "]" s'est glissé dans le markdown définissant le lien).

    Merci pour ce journal très intéressant qui donne envie de suivre les présentations !

  • # Article du Framablog sur Infoclimat

    Posté par  (site web personnel) . En réponse au journal OpenData Meteo. Évalué à 9.

    Un post récent du Framablog au sujet d'Infoclimat est également disponible :)

    Je ne suis pas abonné à NextInpact donc je n'ai malheureusement pas pu lire l'article mentionné dans le journal, mais j'ai trouvé cette interview de deux bénévoles d'Infoclimat sur le Framablog très intéressante. À noter : ils recrutent deux personnes en ce moment !

  • # Chercher du côté de `/etc/acpi/events/` ?

    Posté par  (site web personnel) . En réponse au message Luminosité : Passer de 2% à 10% par appui.. Évalué à 3.

    La page suivante m'a bien aidé lorsque j'ai voulu contrôler la luminosité de l'écran de mon portable via les touches de fonctions :

    https://bbs.archlinux.org/viewtopic.php?id=134972 (en particulier le commentaire de cmorgenstern en #11)

    J'utilise une session Openbox installée par-dessus Ubuntu. En m'inspirant des conseils de cmorgenstern ci-dessus, j'ai réussi à ajouter deux fichiers dans /etc/acpi/events/ correspondants aux touches de fonction pour augmenter et diminuer la luminosité.

    Ces fichiers pointent chacun vers un script cible à exécuter lorsque la touche de fonction correspondante est pressée. Si tu arrives à régler la luminosité avec brightnessctl en ligne de commande avec le pas qui t'intéresse (+/- 10%), il est sans doute possible d'utiliser une commande similaire dans ces scripts cibles.

    Dans mon cas, mes scripts cibles écrivent directement dans le fichier système /sys/class/backlight/intel_backlight/brightness pour établir le niveau de luminosité (le fichier système à modifier dépend de ton ordinateur). A titre d'exemple, voici le script cible lancé lorsque je presse la touche de fonction pour diminuer la luminosité :

    #! /bin/bash
    
    # Fichier système dans lequel le niveau actuel de luminosité est écrit
    bl_device=/sys/class/backlight/intel_backlight/brightness
    # Fichier système contenant la valeur maximale autorisée dans le fichier précédent
    max_br=/sys/class/backlight/intel_backlight/max_brightness
    # Luminosité minimale (choix arbitraire pour éviter de se retrouver avec un écran noir)
    min_br=10
    
    # Facteur appliqué à la luminosité (ici une baisse de 15%)
    mult_factor=0.85
    
    # Lecture de la luminosité actuelle
    current_br=`cat $bl_device`
    # Lecture de la luminosité max
    max_br=`cat $max_br`
    # Calcul de la nouvelle luminosité à appliquer
    raw_new_br=`echo "$current_br * $mult_factor" | bc -l`
    # Arrondi de la valeur précédente
    rounded_new_br=`printf %.0f $raw_new_br`
    
    # Vérifier que la nouvelle valeur de luminosité est comprise entre min_br et max_br
    valid_new_br=$(( min_br > rounded_new_br ? min_br : rounded_new_br ))
    valid_new_br=$(( valid_new_br > max_br ? max_br : valid_new_br ))
    
    # Debugging si besoin
    #echo "Current brightness: $current_br"
    #echo "Min. brightness: $min_br"
    #echo "Max. brightness: $max_br"
    #echo "New brightness (raw): $raw_new_br"
    #echo "New brightness (rounded): $rounded_new_br"
    #echo "New brightness (valid): $valid_new_br"
    
    # Modification de la luminosité en écrivant la nouvelle valeur dans le fichier système
    echo $valid_new_br | sudo tee $bl_device

    J'espère que cela pourra t'être utile :)

  • [^] # Re: reproductible en collaboratif

    Posté par  (site web personnel) . En réponse au journal Préparation de figures avec R : automatiser l'ajout d'annotations manuelles. Évalué à 3. Dernière modification le 20 septembre 2021 à 22:56.

    C'est vrai que base::dput() peut convertir au format "code à copier-coller" une gamme d'objets R beaucoup plus large que tibble::tribble(). Mais j'aime bien utiliser tribble() quand je dois utiliser une petite data.frame dans un exemple simple, comme ici, plutôt que la sortie de dput() car je trouve le format de tribble() beaucoup plus facile à lire dans un contexte pédagogique :)

    Pour comparaison, voici la sortie de dput() pour générer le même objet z que le code du journal qui utilise tribble() :

    structure(list(ville = c("Paris", "Marseille", "Lyon", "Toulouse", 
      "Nice", "Nantes", "Montpellier", "Strasbourg", "Bordeaux", "Lille", 
      "Rennes", "Reims", "Toulon", "Saint-Étienne", "Le Havre", "Brest", 
      "Biarritz"), lat = c(48.86, 43.3, 45.76, 43.6, 43.7, 47.22, 43.61, 
      48.57, 44.84, 50.64, 48.11, 49.26, 43.12, 45.43, 49.49, 48.39, 
      43.48), lon = c(2.35, 5.37, 4.83, 1.44, 7.27, -1.55, 3.88, 7.75, 
      -0.58, 3.06, -1.68, 4.03, 5.93, 4.39, 0.1, -4.49, -1.56), superficie_km2 = c(105.4, 
      240.62, 47.87, 118.3, 71.92, 65.19, 56.88, 78.26, 49.36, 34.51, 
      50.39, 47.02, 42.84, 79.97, 46.95, 49.51, 11.66), habitants = c(2175601, 
      868277, 518635, 486828, 341032, 314138, 290053, 284677, 257068, 
      233098, 217728, 182211, 176198, 173089, 169733, 139602, 25532
      )), row.names = c(NA, -17L), class = c("tbl_df", "tbl", "data.frame"
      ))

    À noter aussi que vous pouvez utiliser le paquet datapasta pour générer facilement le code tribble() correspondant à la data.frame que vous voulez reproduire ! datapasta::dpasta() est un peu l'équivalent de base::dput() pour les tableaux de données. Par exemple, pour préparer le code du journal, je suis en fait parti des données stockées dans un fichier tsv puis j'ai utilisé :

    library(readr)
    z <- read_tsv("villes-france.tsv")
    datapasta::dpasta(z)

    Ce qui m'a affiché dans ma console:

    tibble::tribble(
               ~ville,  ~lat,  ~lon, ~superficie_km2, ~habitants,
              "Paris", 48.86,  2.35,           105.4,    2175601,
          "Marseille",  43.3,  5.37,          240.62,     868277,
               "Lyon", 45.76,  4.83,           47.87,     518635,
           "Toulouse",  43.6,  1.44,           118.3,     486828,
               "Nice",  43.7,  7.27,           71.92,     341032,
             "Nantes", 47.22, -1.55,           65.19,     314138,
        "Montpellier", 43.61,  3.88,           56.88,     290053,
         "Strasbourg", 48.57,  7.75,           78.26,     284677,
           "Bordeaux", 44.84, -0.58,           49.36,     257068,
              "Lille", 50.64,  3.06,           34.51,     233098,
             "Rennes", 48.11, -1.68,           50.39,     217728,
              "Reims", 49.26,  4.03,           47.02,     182211,
             "Toulon", 43.12,  5.93,           42.84,     176198,
      "Saint-Étienne", 45.43,  4.39,           79.97,     173089,
           "Le Havre", 49.49,   0.1,           46.95,     169733,
              "Brest", 48.39, -4.49,           49.51,     139602,
           "Biarritz", 43.48, -1.56,           11.66,      25532
      )
  • [^] # Re: reproductible en collaboratif

    Posté par  (site web personnel) . En réponse au journal Préparation de figures avec R : automatiser l'ajout d'annotations manuelles. Évalué à 2.

    C'est une bonne remarque !

    Je n'ai pas publié les fichiers sources du journal sur une instance Git publique, mais j'ai fait en sorte que le code R fourni dans le journal soit complet (les données sont définies dans l'appel à tibble::tribble()). En faisant un copier-coller du code dans une session R cela produira la figure de base présentée dans le journal.

    La seule partie non-reproductible est, justement, le fichier svg contenant les annotations manuelles faites avec Inkscape, ce que je laisse en tant qu'exercice au lecteur :) Mais si quelqu'un préfère télécharger le fichier d'annotations manuelles que j'ai utilisé dans le journal, il est aussi accessible ici.

  • [^] # Re: Reproductibilité

    Posté par  (site web personnel) . En réponse au journal Préparation de figures avec R : automatiser l'ajout d'annotations manuelles. Évalué à 3.

    Merci pour le lien, il est très pertinent par rapport au sujet du journal et je regrette de ne pas l'avoir inséré dans le journal moi-même :)

    Sur la page en question, Paul Murrell explique dans le détail comment ajouter un fichier svg extérieur à une figure faite avec ggplot(), et il présente aussi les paquets grConvert et gridSVG pour la manipulation de svg dans R. Je ne connaissais pas la fonction ggplot2::annotation_custom(), c'est une bonne surprise de voir que ggplot a déjà un mécanisme pour ce genre de choses !

    Mon cas d'usage était un peu différent, dans la mesure où je voulais pouvoir ajouter un ficher svg extérieur non pas à un objet ggplot mais à une figure faite avec les fonctions R de base (et celles de grid éventuellement). Mais je te remercie pour le lien car cela me sera bien utile si je dois faire la même chose sur un graphe ggplot dans le futur !

  • [^] # Re: Reproductibilité

    Posté par  (site web personnel) . En réponse au journal Préparation de figures avec R : automatiser l'ajout d'annotations manuelles. Évalué à 4.

    Merci pour ces retours très intéressants ! Je vais essayer de répondre en vrac aux remarques ci-dessus :)

    1. Terminologie du mot "reproductibilité"

    Effectivement, comme déjà mentionné dans les commentaires ci-dessus, on peut avoir des points de vue légèrement différents sur ce qu'on entend par "reproductibilité" selon la terminologie qu'on utilise. Dans le cadre de ce journal, j'aurais peut-être dû utiliser "automatisation" plutôt que "reproductibilité".

    D'un côté, on peut considérer la reproductibilité d'une expérience ou d'une analyse d'un jeu de données. Dans ce cas, ce qui est nécessaire et suffisant pour "reproduire" les choses c'est une description précise des méthodes utilisées (à la manière d'une bonne section "Matériels et Méthodes" dans un rapport scientifique qui doit permettre de reproduire un modèle statistique ou une analyse, même sans avoir accès aux détails de l'implémentation dans le code). Dans ce cas, la présentation des résultats de l'analyse ne rentre pas dans ce critère de reproductibilité : un tableau de résultats ou une figure sont juste un format de présentation de l'information produite par l'analyse, et c'est l'information elle-même qui doit être reproductible, pas sa présentation en tableau ou figure.

    D'un autre côté, on peut considérer la reproductibilité de tout un pipeline qui produit un document final (un rapport pour des décideurs ou un manuscrit à soumettre à un journal). Dans ce cas, le besoin à satisfaire est de pouvoir "reproduire" toutes les étapes de l'analyse et de la production du document final, afin de pouvoir produire un document en suivant exactement les mêmes recettes très facilement. Bien sûr, si les données en entrée changent, le document final va aussi changer, mais la recette appliquée aux données pour produire le document reste la même. Dans ce cas, le mot "reproductibilité" recouvre en fait un mélange de "reproductibilité" comme définie au paragraphe précédent et d'"automatisation".

    2. Reproductibilité et exécution planifiée/avec Jenkins

    Je n'utilise pas Jenkins (cela a l'air assez avancé et au-delà de mes compétences actuelles :) ) mais c'est vrai que l'approche proposée dans le journal se prête bien à l'utilisation des options d'intégration continue sur GitLab et GitHub.

    Pour préciser un peu le contexte, dans mon précédent groupe de recherche en biologie nous utilisions R pour les analyses de données et la préparation de figures, R Markdown pour la préparation de rapports, LaTeX ou Google Docs pour la préparation de manuscrits et Git pour la gestion de versions. Pour travailler de manière collaborative sur un projet, on utilisait GitLab.

    Après un certain temps, notre méthode de travail collaboratif a plus ou moins convergée vers les éléments suivants :

    • Pour chaque projet de recherche, on structure notre code et on stocke nos données à la manière d'un paquet R1. Bien sûr, le paquet en question n'est pas destiné à une publication sur CRAN, mais cela nous permet de suivre une structure claire pour organiser les fichiers et de profiter de tous les outils de documentation (roxygen2) et de test (testthat) disponibles pour les paquets R.

    • Toujours en suivant l'approche "un projet = un paquet", les analyses sont stockées en tant que vignettes R markdown dans le dossier vignettes/ du projet. Là encore, on profite de l'écosystème R : écrire une vignette par analyse nous permet ensuite d'utiliser pkgdown pour générer automatiquement une documentation complète du projet à partir du code R.

    • Finalement, tout cela est partagé entre collaborateurs en utilisant GitLab et son intégration continue : à chaque fois que quelqu'un met à jour le code du projet sur GitLab, le paquet est assemblé, documenté, testé, et les vignettes sont exécutées par pkgdown pour préparer le site web contenant l'ensemble de la documentation et des résultats du projet.

    C'est une approche très agréable, parce qu'elle permet d'avoir un site propre et toujours à jour sur un projet, et de détecter tout de suite quand une analyse marche sur la machine personnelle d'un collaborateur mais échoue sur l'instance GitLab. Cela permet aussi de faciliter le partage de la recherche de manière publique : soit en basculant le dépôt GitLab de "privé" à "public" lorsque l'article final est accepté, soit en ayant tout en "public" dès le début pour une recherche vraiment ouverte !

    Je pense que cela rejoint sans doute un peu ce que tu avais à l'esprit en mentionnant une exécution planifiée avec Jenkins ?

    3. Reproductibilité et paquets

    C'est vrai que l'utilisation de paquets peut rendre les choses plus compliquées. Il n'est pas toujours possible de se passer de paquets tierces pour des raisons pratiques (par exemple, si on a besoin de faire tourner un modèle Bayésien en utilisant une approche HMC, il vaut mieux utiliser rstan plutôt que d'essayer d'écrire sa propre implémentation). Il y a plusieurs outils qui existent dans l'écosystème R pour essayer de pallier à ce problème, comme par exemple les paquets packrat ou renv (voir aussi les autres entrées dans la section "Package Reproducibility" de la CRAN Task View: Reproducible Research). Dans tous les cas, une bonne pratique est d'ajouter à la fin des sorties de scripts R toutes les informations retournées par sessionInfo() afin de garder la trace de l'environnement utilisé (y compris les versions de R et des paquets).

    4. Utilisation de ggplot2

    J'aime beaucoup ggplot2 pour une utilisation interactive, notamment pour explorer les données. Les figures produites sont en général claires et jolies, et le code est court et simple, ce qui permet une manipulation très rapide pour essayer différentes visualisations des données. Cependant, pour les figures finales d'un papier, j'ai presque toujours besoin d'une disposition différente de celle par défaut de ggplot2, et j'ai souvent l'impression de devoir nager à contre-courant lorsque je personnalise trop une figure faite avec ggplot (mais c'est sans doute aussi lié au fait que je connais mieux les commandes R de base que celles de ggplot pour faire des graphiques). Donc en général, pour les figures, j'utilise ggplot2 pour l'exploration et j'utilise les fonctions de base (avec beaucoup de grid aussi) pour les figures à publier. Et c'est pour ces dernières que j'ai plusieurs fois eu à faire quelques ajouts manuels :)

    5. Shiny

    J'aimerais bien apprendre à me servir de Shiny un jour ! Pour ceux et celles qui ne connaissent pas, Shiny permet de créer des applications web à partir de code R2. C'est un outil très puissant pour explorer les données de manière interactive, et c'est vrai que c'est sans doute une excellente façon de partager des résultats compliqués avec des collaborateurs !


    1. Voir le livre de Hadley Wickham accessible en ligne "R Packages" pour apprendre comment écrire un paquet R. 

    2. Voir le livre de Hadley Wickham accessible en ligne "Mastering Shiny"

  • # Lien intéressant dans l'article du Guardian

    Posté par  (site web personnel) . En réponse au lien La fondation Openstreetmap cherche à bouger hors du Royaume Uni à cause du Brexit. Évalué à 5.

    L'article du Guardian contient un lien vers un autre article également intéressant :

    "Inside the ‘Wikipedia of Maps,’ Tensions Grow Over Corporate Influence" (Vous pouvez utiliser le mode "Reader view" de Firefox pour lire l'article sans avoir à créer un compte chez Bloomberg.)

  • [^] # Re: Données altimétriques

    Posté par  (site web personnel) . En réponse au journal Une brève introduction à l'utilisation des données OpenStreetMap. Évalué à 2.

    J'arrive moi aussi longtemps après ton commentaire :) et je n'ai malheureusement pas vraiment d'expérience avec l'utilisation des données SRTM. J'y ai jeté un œil par le passé par curiosité, mais à l'époque cela me semblait demander un peu trop d'efforts pour trouver comment y accéder facilement.

    Aujourd'hui, un bon endroit pour commencer à débroussailler le sujet est sans doute cette page du wiki d'OpenStreetMap. Il y a notamment une section "Data in OSM format (XML)" qui semble intéressante.

    Des ressources un peu plus éloignées, mais qui pourraient peut-être t'intéresser (en particulier si tu es déjà utilisat[eur|rice] de R) :

    • le paquet leaflet, mentionné par Bruno plus haut, permet d'avoir accès très facilement à de nombreux fournisseurs de tuiles précalculées ("Third-Party Tiles" dans la doc). Parmi les fournisseurs, il y a notamment des entrées liées à GeoportailFrance et une entrée OpenTopoMap.
    • le paquet R spacey permet d'accéder facilement aux données altimétriques pour les USA via les bases de données USGS et ESRI et de produire de jolies vues en quelques lignes de code (doc).
    • le paquet spacey est lui-même basé sur le paquet rayshader de Tyler Morgan-Wall pour la visualisation (doc), qui est très utilisé pour faire de jolies vues 3D du relief d'une zone géographique donnée (le fil Twitter de Tyler Morgan-Wall présente de nombreuses visualisations de terrain, souvent très jolies, mais cela est peut-être éloigné de ton objectif).

    Bon courage dans ta recherche de données altimétriques, et n'hésite pas à partager tes retours d'expérience si tu trouves quelque chose de bien ! Je suis sûr que cela en intéresserait plus d'un sur ce site :)

  • [^] # Re: Merci !

    Posté par  (site web personnel) . En réponse au journal Une brève introduction à l'utilisation des données OpenStreetMap. Évalué à 9.

    Merci pour ce conseil et ces précisions ! Je dois admettre que pour ma première tentative de contribution à LinuxFr, je me sentais plus à l'aise à l'idée d'expérimenter avec un journal plutôt qu'avec une dépêche publiée en page d'accueil :)

    Au passage, merci à toutes et tous pour ce site et la communauté très accueillante qui existe autour ! Même si ce journal est mon premier contenu publié, je visite régulièrement le site avec intérêt depuis plusieurs années.