En testant avec jeu de données Kaggle de 30 Mo (19 colonnes x 170 653 lignes), j'obtiens un chargement quasi-instantané.
Les aperçus complets (tout le jeu de données) sont alors nettement plus lents à être générés.
La plupart des traitements se réalisent en quelques secondes.
Les fonctions d'analyse agrégats -> domaine de valeur et agrégats -> explorer les données te permettront de naviguer facilement dans les sous-ensembles de données malgré le volume de données.
L'export CSV s'ouvre au bout de 2 secondes, ce qui reste raisonnable.
sur le plan pratique
Pour la problématique que tu rencontres, si tu as accès à la source de données, je te conseille de lotir la qualification (soit par périmètre homogène, par exemple une base client découpée en portefeuille par commercial, par région…
Autre approche possible pour rendre la qualification digeste (tant pour les collègues et pour les logiciels) : lotir verticalement : que les produits, que les clients, que les adresses des clients, etc.
Tu auras sûrement besoin d'un autre outil, programmable, pour rejouer à plusieurs reprises les scénarii.
Illico trouvera plutôt sa place en amont (tests exploratoires) et en aval (vérification).
Effectivement, le caractère différenciateur principal d'Illico est son positionnement par rapport aux utilisateurs.
en 2 mots : OpenRefine ou Illico ?
Globalement, OpenRefine s'adresse à des informaticiens, programmeurs ou data analyst pour automatiser des traitements complexes (plutôt des données scientifiques, vu la capacité d'OpenRefine à traiter des gros volumes de données).
Illico remplace l'informaticien auprès des utilisateurs métiers qui traitent des données de gestion, généralement des volumes plus faibles qui tiennent dans un tableur.
utilisateurs métiers
Je pense aux collègues dépendants d'un DBA pour une requête SQL ou d'un programmeur sous Access/LoBase ou d'un ETL ;
et confrontés à l'absence d'outil ou de connaissance en programmation, se reportent sur un traitement chronophage, à la main, généralement dans un tableur.
Généralement ils ne sont pas administrateurs de leur poste de travail et ne pourront pas installer d'autres outils.
Et de toute façon, ils ne pourront pas connecter directement ces outils aux applications/logiciels métiers dont ils souhaitent exploiter les données.
Et à leur place, comment faire confiance à des outils qui semblent magiques, pilotés par des commandes obscures dans un langage informatique basé entièrement sur des termes en anglais ? Ils n'ont pas fait LV3 informatique.
En revanche, les logiciels métiers ont souvent des fonctionnalités de listing à l'écran (sélectionner tout, copier-coller) ou d'export au format CSV.
rigidité et fragilité de l'automatisation
Tout outil automatisable - scripts, ETL, base de données - malgré tout le perfectionnement de leurs fonctionnalités paramétrables, rigidifiera le traitement de données de manière conséquente.
Un fichier d'entrée avec une colonne au mauvais endroit ou un nom différent peut tout à fait casser le programme ou la routine mise en place.
Les collègues métiers sont réellement en panique dans ce cas de figure et préfèrent alors corriger une à une toutes les données dans un tableur, quite à y passer leur week-end plutôt que de faire confiance dans un outil qu'ils ne maîtrisent pas.
Sous Illico, l'utilisateur sans même relever ce point, sélectionne la bonne colonne et poursuit le traitement de données, sans avoir à se poser des questions qui ne relèvent en fait que de la rigidité de nos outils préférés1.
1récemment, sur des outils open-source ou propriétaires réputés, j'ai rencontré les contraintes suivantes : sensible à la casse des noms de colonne, sensible à l'encodage des accents dans les noms de colonne, sensible à la casse du nom du fichier chargé, sensible aux espaces rencontrés dans le chemin complet vers le fichier
maîtriser plusieurs outils ?
Illico regroupe au même endroit certaines fonctionnalités que l'on retrouve habituellement dans des outils distincts (maîtriser plusieurs outils : encore une difficulté pour les utilisateurs métiers) :
filtres
pivot (certaines bases de données ne le font pas)
exploration de données (en gros, les tableaux croisés dynamiques des tableurs)
croisement (SQL ou ETL, éventuellement la fonction RechercheV des tableurs)
mise en forme (certains tableurs)
permet de simuler certains traitements plutôt que de les exécuter (et ensuite de devoir analyser la situation avant de revenir en arrière)
doublons
jointure
tester un motif (expression rationnelle)
permet d'annuler la dernière action (j'imagine que certains ETL implémentent aussi un rollback)
documente automatiquement les actions réalisées : paramètres utilisés, nombre de valeurs modifiées, nom du fichier exporté à cette étape
Je ne connais pas d'autres outils qui construit un journal de bord de toutes les actions réalisées, à destination de l'utilisateur métier (par opposition aux journaux d'événements qui s'adressent aux administrateurs informatiques).
Des idées pour trouver un chiffre pertinent (savoir ce qu'il décrit et ce qu'il représente en volume par rapport au total).
Les stat côté distrib se divisent globalement en deux :
l'installation par défaut (pour simplifier : dans l'image ISO),
l'installation volontaire ou mise à jour par l'utilisateur (pour simplifier : apt install ou apt update
Dans les deux cas, ce sont plutôt les mainteneurs des distrib qui peuvent obtenir ces chiffres (nombre de téléchargement de telle ISO avec telle version VLC embarquée, nombre de requête sur le dépôt http://… etc.)
Aussi, certaines distrib mettent en place des stat d'installation (l'utilisateur qui installe la distrib a la possibilité de refuser de participer à ces stat) afin que les mainteneurs optimise la sélection des applications installées par défaut dans la distrib/version suivante.
Le compteur de téléchargement côté distrib, même imparfait, existe peut-être déjà…
Au choix : ce qui fonctionne, les potentialités, les capacités à faire le job remplir à bien la mission.
Dans la dépêche, j'utilise ces deux expressions exactement dans le sens de ces définitions.
pour compléter mes propos
L'interface d'origine - de nov 2011 à mai 2018 - était adaptée aux écrans de 15 pouces1 38 cm
compacte (pas de label, que des placeholder)
le chargement CSV toujours apparent (prenait de la place pour rien)
1 liste de fonctionnalités d'une moitié de l'écran en hauteur, les autres types de chargement tout à la fin de la liste (mettre la première action potentielle le plus loin possible dans la liste déroulante… pas pratique)
aperçu des données en direct (pratique mais prenait de la place sur la liste des transformations de données)
J'ai donc repris ceci par souci de cohérence et pour utiliser au mieux l'espace disponible des écrans plus larges.
côté code, les algorithmes d'origine utilisaient une copie supplémentaire des données (une empreinte mémoire maximum égale 2 fois la taille des données…) là où les nouveaux algorithmes transforment les données in place.
certains mécanismes JS ont été simplifiés par du code CSS
et d'autres codes CSS (info-bulle) ont été remplacés par l'attribut HTML title
le jeu de couleur est moins agressif et s'inspire de solarized
les input (paramètres) vides par défaut, changent de couleur quand l'utilisateur y saisit une valeur (cf. point suivant)
les paramètres saisis ne sont plus effacés à chaque traitement (ce qui permet de rejouer un traitement précédent avec des paramètres pré-saisi)
…
Voilà pour les grands principes.
Je ne détaille pas tout, car vous retrouverez toutes les modifications apportées dans les dernières parties de la documentation utilisateur.
Bien à vous,
1 oui, le pouce anglais ou français n'ont pas la même longueur ; ici il s'agit de l'unité pouce anglais que l'on devrait d'ailleurs prendre l'habitude d'écrire 15po et non 15" … https://fr.wikipedia.org/wiki/Pouce_(unit%C3%A9)#Notations
Dans un cadre professionnel, je confirme et suis souvent surpris du fait qu'un code Bash écrit des années plus tôt s'exécute sans erreur là où les autres outils ou langages ont évolué et de ce fait "cassés" des scripts simples (modification de syntaxes, ajout/suppression de sucres, changement/disparition de librairie, modification de comportement des objets conteneurs ou des compilateurs/environnement d'exécution).
Pour revenir au sujet de Git,
il manque peut-être à Git une interface semi-graphique. Je pense à la commande htop dans une console qui permet d'appeler des options par raccourcis clavier et aussi en clic souris (oui, dans une console).
Ce serait une plus-value en terme de confort pour l'utilisateur… plutôt qu'une recherche de performance qui sera comblée de toute façon par l'évolution de la puissance de nos machines…
Vous l'aurez deviné, j'utilise principalement Git en ligne de commande… ;)
Pour faire court, il s'agit d'un équilibre à chercher/trouver entre complexité (au sens "capacité de gérer tel niveau de complexité"), convivialité, agilité et automatisation.
Je suis tenté de rajouter : coût de licence, permissions de l'utilisateur pour installer, disponibilité de l'équipe technique (priorisation, compréhension de l'enjeu), technicité/technologie, politique/volonté de centraliser (consolider/renforcer des acquis des équipes techniques) ou d'autonomiser les acteurs métiers, etc.
Juste avant de charger les données, je te conseille de modifier la configuration pour éviter un rafraîchissement automatique : configuration (en bas de la liste des transformations/traitements).
Tu verras tout de suite si le volume de données se charge correctement.
Par exemple j'ai essayé de créer un référentiel géographique dans une base de données en m'appuyant sur les données ouvertes de l'ONU : https://unstats.un.org/unsd/methodology/m49/overview/
Ce référentiel est construit de telle façon que chaque ligne représente un pays avec tous ses niveaux parents sur la gauche. En cible j'imagine une table à 3 colonnes CodeParent, Code, Name. […]
Dans ce sens-là, il y a bien une transformation dans Illico :
La transformation est générique et permet de travailler sur des paires (parent->enfant) comme sur n'importe quelle taille de groupe (triplets, quadruplets, etc.).
Dans le cas que tu soulèves, l'idéal sera un groupe de 4 informations/colonnes : CodeParent, NameParent, Code, Name.
[…] Mais dans l'idée la colonne Chemin peut aussi être générée avec une bonne grosse formule.
Peut-être pour une prochaine version ? :-)
Merci pour cette excellente idée. C'est noté ;)
Pour patienter la bonne grosse formule, il y a dorénavant un tutoriel pour décomposer le problème et le résoudre.
Effectivement, rejouer un scénario n'est pas possible en 1 clic dans Illico.
Selon votre profil/besoin, voici deux options possibles :
1. dans Illico, l'historisation des actions
Le journal de bord recense les actions réalisées et les résultats obtenus : nouveaux nombres de lignes/colonnes, nombre de valeurs modifiées, etc.
L'objectif de l'historisation est de permettre à l'utilisateur de maîtriser le sens d'un scénario et au besoin de l'adapter sur des données légèrement différentes (une nouvelle colonne, l'ordre ou les noms des colonnes diffèrent, un format de donnée modifié).
2. pour des utilisateurs plus techniques
Selenium IDE est utilisé pour automatiser des tests de non-régression sur Illico (enregistrer puis rejouer un scénario) :
Posté par asky .
En réponse à la dépêche Oui, Illico !.
Évalué à 3.
Dernière modification le 12 octobre 2018 à 00:37.
Je ne sais pas si l'astuce suivante peut répondre à tes besoins.
1. préparation des données
3 transformations => 3 nouvelles colonnes
concaténer : Global Name - Global Code => Global (monde)
concaténer : Region Name - Region Code => Region (continent)
concaténer : Sub-region Name - Sub-region Code => Sub-region (pays)
2. analyser les données
1 fonction d'analyse
explorer les données
On choisit les axes Global / Region / Sub-region
À chaque clic sur une ligne, un nouveau tableau dynamique permet d'analyser l'axe suivant.
Chaque tableau de synthèse est exportable via le bouton TAB.
Chaque sous-tableau de données résultat1 (la succession des filtres Global / Region / Sub-region) est exportable via HTML et CSV.
remarques
ces tableaux croisés dynamiques rappellent toujours le contexte
Peut-être fallait-il juste remarquer dans ma remarque un trait d'humour :
il se trouve que le thème du sondage est autour du genre,
et "faire mauvais genre" est une expression.
Ensuite, prendre ma remarque au 1er degré, c'est convenir que ni les parenthèses, ni les tirets ni les points ne conviennent (merci pour ta remarque).
Des formulations plus longues (homme et femme) ou neutres (genre humain, espèce humaine, humanité) peuvent être utilisées sans aucun problème.
En réalité, il y a plusieurs limites (qui peuvent être contournées).
limite 1 : le rendu HTML
Un fichier volumineux sera traité relativement rapidement par le JS mais en revanche l'aperçu HTML pourra prendre plusieurs minutes.
La solution consiste à désactiver l'aperçu HTML (par défaut : l'aperçu est automatique après chaque traitement).
D'expérience, les fonctions d'analyse peuvent effectivement suffire à visualiser les données sur une colonne donnée (on n'a pas vraiment toujours besoin d'avoir sous les yeux toutes les lignes et toutes les colonnes).
limite 2 : le navigateur
Selon le réglage du navigateur, un fichier trop volumineux peut éventuellement saturer l'espace alloué par le navigateur (je ne pense pas que ce soit la RAM).
Pour éviter un plantage, certains navigateurs demandent à l'utilisateur d'augmenter la taille (c'était le cas pour le navigateur Opera), d'autres crashent le navigateur ou plantent juste Illico (exception JS que l'on retrouve sous la console).
Un simple réglage du navigateur pourrait suffire.
limite 3 : la techno
Il me semble qu'il y a une limite pour l'objet JS Blob (qui est utilisé pour l'export CSV).
Là aussi, les navigateurs sont plus ou moins tolérants.
[^] # Re: Retours d’expériences ?
Posté par asky . En réponse à la dépêche Illico Editor : nouveautés depuis 2019. Évalué à 6.
sur le plan technique
Je n'ai pas l'occasion de travailler avec des gros jeux de données.
Après plusieurs tests, j'ai trouvé une limite autour de 100Mo avec interruption du chargement de données.
Les ordres de grandeur sont indiqués dans la documentation :
http://illico.tuxfamily.org/doc/build/html/fct/principes.html#jeu-de-donnees-volumineux
En testant avec jeu de données Kaggle de 30 Mo (19 colonnes x 170 653 lignes), j'obtiens un chargement quasi-instantané.
Les aperçus complets (tout le jeu de données) sont alors nettement plus lents à être générés.
La plupart des traitements se réalisent en quelques secondes.
Les fonctions d'analyse agrégats -> domaine de valeur et agrégats -> explorer les données te permettront de naviguer facilement dans les sous-ensembles de données malgré le volume de données.
L'export CSV s'ouvre au bout de 2 secondes, ce qui reste raisonnable.
sur le plan pratique
Pour la problématique que tu rencontres, si tu as accès à la source de données, je te conseille de lotir la qualification (soit par périmètre homogène, par exemple une base client découpée en portefeuille par commercial, par région…
Autre approche possible pour rendre la qualification digeste (tant pour les collègues et pour les logiciels) : lotir verticalement : que les produits, que les clients, que les adresses des clients, etc.
Tu auras sûrement besoin d'un autre outil, programmable, pour rejouer à plusieurs reprises les scénarii.
Illico trouvera plutôt sa place en amont (tests exploratoires) et en aval (vérification).
[^] # Re: Logiciel similaire
Posté par asky . En réponse à la dépêche Illico Editor : rétrospective 2017-2018. Évalué à 5.
Effectivement, le caractère différenciateur principal d'Illico est son positionnement par rapport aux utilisateurs.
en 2 mots : OpenRefine ou Illico ?
Globalement, OpenRefine s'adresse à des informaticiens, programmeurs ou data analyst pour automatiser des traitements complexes (plutôt des données scientifiques, vu la capacité d'OpenRefine à traiter des gros volumes de données).
Illico remplace l'informaticien auprès des utilisateurs métiers qui traitent des données de gestion, généralement des volumes plus faibles qui tiennent dans un tableur.
utilisateurs métiers
Je pense aux collègues dépendants d'un DBA pour une requête SQL ou d'un programmeur sous Access/LoBase ou d'un ETL ;
et confrontés à l'absence d'outil ou de connaissance en programmation, se reportent sur un traitement chronophage, à la main, généralement dans un tableur.
Généralement ils ne sont pas administrateurs de leur poste de travail et ne pourront pas installer d'autres outils.
Et de toute façon, ils ne pourront pas connecter directement ces outils aux applications/logiciels métiers dont ils souhaitent exploiter les données.
Et à leur place, comment faire confiance à des outils qui semblent magiques, pilotés par des commandes obscures dans un langage informatique basé entièrement sur des termes en anglais ? Ils n'ont pas fait LV3 informatique.
En revanche, les logiciels métiers ont souvent des fonctionnalités de listing à l'écran (sélectionner tout, copier-coller) ou d'export au format CSV.
rigidité et fragilité de l'automatisation
Tout outil automatisable - scripts, ETL, base de données - malgré tout le perfectionnement de leurs fonctionnalités paramétrables, rigidifiera le traitement de données de manière conséquente.
Un fichier d'entrée avec une colonne au mauvais endroit ou un nom différent peut tout à fait casser le programme ou la routine mise en place.
Les collègues métiers sont réellement en panique dans ce cas de figure et préfèrent alors corriger une à une toutes les données dans un tableur, quite à y passer leur week-end plutôt que de faire confiance dans un outil qu'ils ne maîtrisent pas.
Sous Illico, l'utilisateur sans même relever ce point, sélectionne la bonne colonne et poursuit le traitement de données, sans avoir à se poser des questions qui ne relèvent en fait que de la rigidité de nos outils préférés1.
1 récemment, sur des outils open-source ou propriétaires réputés, j'ai rencontré les contraintes suivantes : sensible à la casse des noms de colonne, sensible à l'encodage des accents dans les noms de colonne, sensible à la casse du nom du fichier chargé, sensible aux espaces rencontrés dans le chemin complet vers le fichier
maîtriser plusieurs outils ?
Illico regroupe au même endroit certaines fonctionnalités que l'on retrouve habituellement dans des outils distincts (maîtriser plusieurs outils : encore une difficulté pour les utilisateurs métiers) :
permet de simuler certains traitements plutôt que de les exécuter (et ensuite de devoir analyser la situation avant de revenir en arrière)
permet d'annuler la dernière action (j'imagine que certains ETL implémentent aussi un rollback)
documente automatiquement les actions réalisées : paramètres utilisés, nombre de valeurs modifiées, nom du fichier exporté à cette étape
Je ne connais pas d'autres outils qui construit un journal de bord de toutes les actions réalisées, à destination de l'utilisateur métier (par opposition aux journaux d'événements qui s'adressent aux administrateurs informatiques).
[^] # Re: Bravo !!
Posté par asky . En réponse à la dépêche Et de trois ! (et sans le cheval). Évalué à 2.
Des idées pour trouver un chiffre pertinent (savoir ce qu'il décrit et ce qu'il représente en volume par rapport au total).
Les stat côté distrib se divisent globalement en deux :
Dans les deux cas, ce sont plutôt les mainteneurs des distrib qui peuvent obtenir ces chiffres (nombre de téléchargement de telle ISO avec telle version VLC embarquée, nombre de requête sur le dépôt http://… etc.)
Aussi, certaines distrib mettent en place des stat d'installation (l'utilisateur qui installe la distrib a la possibilité de refuser de participer à ces stat) afin que les mainteneurs optimise la sélection des applications installées par défaut dans la distrib/version suivante.
Le compteur de téléchargement côté distrib, même imparfait, existe peut-être déjà…
[^] # Re: rebase
Posté par asky . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 1.
Merci pour la référence.
Juste ce qu'il me fallait.
[^] # Re: Bien intéressant mais
Posté par asky . En réponse à la dépêche Illico Editor : rétrospective 2017-2018. Évalué à 6.
Je vous remercie pour vos remarques sur le choix des mots.
Je suis d'accord à 300% : le choix des mots est important et parfois il faut expliquer aussi.
pour clarifier mes propos
de l'expérience utilisateur
https://fr.wiktionary.org/wiki/expérience_utilisateur
(Informatique) Ressenti de l'utilisateur lors d'une manipulation d'une interface.Wiktionnaire dit que c'est une parataxe (tout comme informatique est la contraction de information et de automatique).
Remarque parataxe vient du latin (on autorise tant que ce n'est pas un anglicisme…)
de la performance
https://fr.wiktionary.org/wiki/performant
De l'anglais performance … mince !
Efficient peut-être .. 2 origines latin/anglais, dans le doute…
Au choix : ce qui fonctionne, les potentialités, les capacités à
faire le jobremplir à bien la mission.Dans la dépêche, j'utilise ces deux expressions exactement dans le sens de ces définitions.
pour compléter mes propos
L'interface d'origine - de nov 2011 à mai 2018 - était adaptée aux écrans de
15 pouces138 cmJ'ai donc repris ceci par souci de cohérence et pour utiliser au mieux l'espace disponible des écrans plus larges.
Voilà pour les grands principes.
Je ne détaille pas tout, car vous retrouverez toutes les modifications apportées dans les dernières parties de la documentation utilisateur.
Bien à vous,
1 oui, le pouce anglais ou français n'ont pas la même longueur ; ici il s'agit de l'unité pouce anglais que l'on devrait d'ailleurs prendre l'habitude d'écrire 15po et non 15" …
https://fr.wikipedia.org/wiki/Pouce_(unit%C3%A9)#Notations
[^] # Re: rebase
Posté par asky . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 2. Dernière modification le 11 décembre 2018 à 23:47.
Dans un cadre professionnel, je confirme et suis souvent surpris du fait qu'un code Bash écrit des années plus tôt s'exécute sans erreur là où les autres outils ou langages ont évolué et de ce fait "cassés" des scripts simples (modification de syntaxes, ajout/suppression de sucres, changement/disparition de librairie, modification de comportement des objets conteneurs ou des compilateurs/environnement d'exécution).
Pour revenir au sujet de Git,
il manque peut-être à Git une interface semi-graphique. Je pense à la commande htop dans une console qui permet d'appeler des options par raccourcis clavier et aussi en clic souris (oui, dans une console).
Ce serait une plus-value en terme de confort pour l'utilisateur… plutôt qu'une recherche de performance qui sera comblée de toute façon par l'évolution de la puissance de nos machines…
Vous l'aurez deviné, j'utilise principalement Git en ligne de commande… ;)
[^] # Re: Outils pour trier, analyser, ... les données
Posté par asky . En réponse au message Analyse de données. Évalué à 1.
Vous (re-)trouverez une présentation d'Illico sur linuxfr
https://linuxfr.org/news/oui-illico
C'est difficile de répondre à la question.
Pour faire court, il s'agit d'un équilibre à chercher/trouver entre complexité (au sens "capacité de gérer tel niveau de complexité"), convivialité, agilité et automatisation.
Je suis tenté de rajouter : coût de licence, permissions de l'utilisateur pour installer, disponibilité de l'équipe technique (priorisation, compréhension de l'enjeu), technicité/technologie, politique/volonté de centraliser (consolider/renforcer des acquis des équipes techniques) ou d'autonomiser les acteurs métiers, etc.
Vaste sujet.
[^] # Re: Cela a l'air pas mal ...
Posté par asky . En réponse à la dépêche Oui, Illico !. Évalué à 0.
Juste avant de charger les données, je te conseille de modifier la configuration pour éviter un rafraîchissement automatique : configuration (en bas de la liste des transformations/traitements).
Tu verras tout de suite si le volume de données se charge correctement.
[^] # Re: Passer d'un arbre à un tableau et réciproquement ?
Posté par asky . En réponse à la dépêche Oui, Illico !. Évalué à 1.
Dans ce sens-là, il y a bien une transformation dans Illico :
http://illico.tuxfamily.org/doc/build/html/fct/col.html#transposer-groupes-de-colonnes
La transformation est générique et permet de travailler sur des paires (parent->enfant) comme sur n'importe quelle taille de groupe (triplets, quadruplets, etc.).
Dans le cas que tu soulèves, l'idéal sera un groupe de 4 informations/colonnes : CodeParent, NameParent, Code, Name.
Merci pour cette excellente idée. C'est noté ;)
Pour patienter la bonne grosse formule, il y a dorénavant un tutoriel pour décomposer le problème et le résoudre.
http://illico.tuxfamily.org/tuto/build/html/exemples/filiation.html
[^] # Re: OpenRefine
Posté par asky . En réponse à la dépêche Oui, Illico !. Évalué à 1.
Effectivement, rejouer un scénario n'est pas possible en 1 clic dans Illico.
Selon votre profil/besoin, voici deux options possibles :
1. dans Illico, l'historisation des actions
Le journal de bord recense les actions réalisées et les résultats obtenus : nouveaux nombres de lignes/colonnes, nombre de valeurs modifiées, etc.
L'objectif de l'historisation est de permettre à l'utilisateur de maîtriser le sens d'un scénario et au besoin de l'adapter sur des données légèrement différentes (une nouvelle colonne, l'ordre ou les noms des colonnes diffèrent, un format de donnée modifié).
2. pour des utilisateurs plus techniques
Selenium IDE est utilisé pour automatiser des tests de non-régression sur Illico (enregistrer puis rejouer un scénario) :
http://docs.seleniumhq.org/projects/ide/
le renommage des exports CSV s'active dans Illico via les préférences -> export CSV ↩
[^] # Re: Passer d'un arbre à un tableau et réciproquement ?
Posté par asky . En réponse à la dépêche Oui, Illico !. Évalué à 3. Dernière modification le 12 octobre 2018 à 00:37.
Je ne sais pas si l'astuce suivante peut répondre à tes besoins.
1. préparation des données
3 transformations => 3 nouvelles colonnes
2. analyser les données
1 fonction d'analyse
On choisit les axes Global / Region / Sub-region
À chaque clic sur une ligne, un nouveau tableau dynamique permet d'analyser l'axe suivant.
Chaque tableau de synthèse est exportable via le bouton TAB.
Chaque sous-tableau de données résultat1 (la succession des filtres Global / Region / Sub-region) est exportable via HTML et CSV.
remarques
ces tableaux croisés dynamiques rappellent toujours le contexte
si ton besoin est uniquement orienté exploration de données
sections de la documentation
les exports des tableaux résultats contiendront toutes les colonnes du tableau original : dans cet exemple, le jeu de données a 18 colonnes. ↩
la mention "sub-region" n'a pas de sens ici puisque l'on compte le nombre de lignes, cf. première capture d'écran (c'est noté pour correction). ↩
[^] # Re: Il faudrait éviter de faire mauvais genre
Posté par asky . En réponse au sondage Genre du lectorat de LinuxFr.org. Évalué à 0.
Peut-être fallait-il juste remarquer dans ma remarque un trait d'humour :
il se trouve que le thème du sondage est autour du genre,
et "faire mauvais genre" est une expression.
Ensuite, prendre ma remarque au 1er degré, c'est convenir que ni les parenthèses, ni les tirets ni les points ne conviennent (merci pour ta remarque).
Des formulations plus longues (homme et femme) ou neutres (genre humain, espèce humaine, humanité) peuvent être utilisées sans aucun problème.
Comme l'humour, c'est une question d'habitude.
[^] # [fichiers volumineux]
Posté par asky . En réponse à la dépêche Oui, Illico !. Évalué à 3.
En réalité, il y a plusieurs limites (qui peuvent être contournées).
limite 1 : le rendu HTML
Un fichier volumineux sera traité relativement rapidement par le JS mais en revanche l'aperçu HTML pourra prendre plusieurs minutes.
La solution consiste à désactiver l'aperçu HTML (par défaut : l'aperçu est automatique après chaque traitement).
D'expérience, les fonctions d'analyse peuvent effectivement suffire à visualiser les données sur une colonne donnée (on n'a pas vraiment toujours besoin d'avoir sous les yeux toutes les lignes et toutes les colonnes).
limite 2 : le navigateur
Selon le réglage du navigateur, un fichier trop volumineux peut éventuellement saturer l'espace alloué par le navigateur (je ne pense pas que ce soit la RAM).
Pour éviter un plantage, certains navigateurs demandent à l'utilisateur d'augmenter la taille (c'était le cas pour le navigateur Opera), d'autres crashent le navigateur ou plantent juste Illico (exception JS que l'on retrouve sous la console).
Un simple réglage du navigateur pourrait suffire.
limite 3 : la techno
Il me semble qu'il y a une limite pour l'objet JS Blob (qui est utilisé pour l'export CSV).
Là aussi, les navigateurs sont plus ou moins tolérants.
et donc en pratique ?
Les limites sont référencées ici
http://illico.tuxfamily.org/doc/build/html/fct/principes.html#gerer-les-fichiers-volumineux
# Il faudrait éviter de faire mauvais genre
Posté par asky . En réponse au sondage Genre du lectorat de LinuxFr.org. Évalué à 3.
Et voilà, bravo ! Sans le vouloir, vous mettez quand même la féminité entre parenthèses ! Merci pour l'image.
Ça fait vraiment mauvais genre.