De part mon activité, j'ai à travailler avec des flux de données provenant de sources multiples.
Introduction au cauchemard de l'Extract_Transform_Load avec des données formatées approxi-miteu-sement !
* Des fichiers XML ou les champs sont à 100% en CDATA..... (ils se sont déjà fait chier à faire des balises XML, alors faut pas leur demander de se préoccuper de la conformité de ce qu'elles contiennent! on ne parlera même pas de schema...)
* Des mix d'encodage de caractères dans un document XML
* Des mix d'encodage de caractères dans des champs CDATA ! (irrécupérable)
* Le problème précédent réparé par une suppression simple des caractères non ascii !
* De l'html dans des champs purement texte (ça vous va pas, démerdez vous)
* Des clés de données qui ... changent ! Tiens 100% des entrées on changé !? (je vous parle même pas des clés non uniques...)
* Des clés étrangères dont la cible... n'existe pas: ces clés étant calculées automatiquement pas rapport à la clé principale !
* des gens qui mettent des valeurs arbitraires pour des valeurs inconnues... (imaginez une quantité à 1.000.000, les dégats un prix à 1.00, des dates "bientot, sous peu" )
* Un génie qui décide que son application source limitera les requêtes à 3/jour en bloquant la réponse pendant 3 minutes et renvoyant un code HTTP 409 (Un au pif dans la RFC, sans se soucier du fait que c'était implicitement une demande de ré-essai ! On l'a tenu 2 mois ce bug avant son retour d'informations !)
* des jolis fichiers csv comme on faisait il y a 10ans, le tout produit en HTML. Si, Si, c'est possible: une ligne csv par paragraphe !
* Des génies qui ont tout compris à l'XML:
< a >
< nomchamp >bidule< /nomchamp >
< valeurchamp >valeur< /valeurchamp >
< nomchamp >bidule2< /nomchamp >
< valeurchamp >valeur2< /valeurchamp >
< / a >
Et on ne parle que des formats. Je ne vous relate pas les hérésies quand les champs de données doivent avoir une valeur explicite ou un minimum qualitatif.
Le plus grave dans tout cela ? Il s'agit principalement d'enseignes bien connues de l'internet ou de leurs intermédaires.
"xmllint"... hein ?!? Des dev à mettre dans le même panier que les admins tutos, les web cébo, ...
Et vous, le "ça nous semble correct, si ça va pas démerdez vous" c'est aussi au quotidien ?
Journal Le cauchemard de l'ETL
30
oct.
2009
# Pour un titre sans faute
Posté par ✅ ffx . Évalué à 10.
[^] # Re: Pour un titre sans faute
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
# XML
Posté par icyfemur . Évalué à 1.
Si c'est valide XML, de quoi tu te plains ?
[^] # Re: XML
Posté par MrLapinot (site web personnel) . Évalué à 4.
[^] # Re: XML
Posté par fcartegnie . Évalué à 3.
Le charset du document ne valide que les balises: Comme tout est en CDATA, impossible d'avoir une gestion du charset présent dans ces sections par du xml ou xslt...
Quand le charset ne diffère pas entre les sections !
# presque pareil
Posté par pastro . Évalué à 4.
si ça va pas démerdez vous
# Pareil
Posté par Zenitram (site web personnel) . Évalué à 5.
Côté norme :
* Des normes qui laissent un nombre de questions en suspens (et donc la réponse est différente suivant qui implémente)
* Des normes qui compliquent la vie, peu lisibles, donc les développeurs simplifient ou comprennent de manière différentes (et je les comprend)
* Des normes qui utilisent plusieurs nom pour un même champs, mais dans des chapitres différents (à toi de retrouver qui va avec qui)
* Des normes US-centric (codage de caractères? Bah US-ASCII, allez je laisse du 8 bit mais gardez vos fichiers dans votre pays, sinon ça va merder)
* Pareil pour l'heure, UTC c'est chiant, allez on force la structure du champs en oubliant la partie "timezone", c'est pas utile (norme... Américaine! ils ont plusieurs timezone chez eux mais n'en voient pas l'utilité...)
Côté développeurs :
* Une norme? Bah tant que ça marche dans un player laxiste, c'est bon, c'est que ça doit être valide
* une norme spécifie un codage de caractère? Trop chiant je met le codage local, rien à faire de la norme.
* 02/03/2009 ne veut pas dire 2 mars 2009, mais 3 février 2009, mais les américains sont le centre du monde, donc tout le monde doit faire pareil... Sympa les échanges informatique ensuite. Utiliser 2009-02-03 est trop chiant, la flemme.
* ...
Et ce, que ce soit grand organisme (ISO...) ou grandes entreprises (et pas que Microsoft...).
Bref, c'est partout pareil, et il faut vivre avec, c'est la communication entre le gens... Et on se démerde.
[^] # Re: Pareil
Posté par fabricius . Évalué à 4.
[^] # Re: Pareil
Posté par Jokernathan . Évalué à 5.
# Fais en profiter d'autres...
Posté par leoboy . Évalué à 10.
The Daily WTF est un recueil d'histoires et de moments de vie dans le milieu des DSI, des développeurs et des daissïdors pressés qui ne comprennent rien à l'informatique. Les histoires relatent moult projets foireux, mal ficelés ou gérés par des incompétents. Avec - entre autres - les mots de passe vérifiés côté client en Javascript, le développeur qui utilisait sa base de données SQL comme un classeur Excel, l'entreprise de 1.000 personnes dont tout le carnet de commandes était géré dans un fichier Access de 700 Mo (ouvert sur plusieurs postes, cela va de soi), etc etc etc...
Depuis que je lis The Daily WTF, je n'ai plus honte de coder "salement", l'expérimentation et le crade ne me font plus peur, car je sais qu'il y a beaucoup, beaucoup plus fort que moi sur la planète.
Voilà voilà, bonne perte de productivité à la lecture de ce site et à bientôt !
[^] # Re: Fais en profiter d'autres...
Posté par Phil Actaire . Évalué à 3.
C'est vieux, ç'a été dit et redit mais...
... sous prétexte qu'il y a pire, tu ne fais pas d'efforts ?
[^] # Re: Fais en profiter d'autres...
Posté par fcartegnie . Évalué à 2.
[http://goodsense.online.fr/] (anglais...mais des softs en francais ?!?)
# C'est plutôt sympa
Posté par David Pradier . Évalué à 3.
Perso, j'aime bien, ça me donne l'opportunité de changer ça en qqch de propre. Un beau code bien fait, à la fin, ça fait plaisir :-)
En revanche, d'expérience, un client qui te fournit du code comme ça n'est pas un bon client. Ca signifie qu'il n'a pas de contrôle interne au niveau dev, et probablement pas dans le reste de son activité. Dans 2 ans, il sera crevé ; ou il y aura eu une réorganisation qui, en plus de théoriquement faire améliorer le code, te retirera ton contrat. Par exemple, confier une réécriture totale à une SSII.
[^] # Re: C'est plutôt sympa
Posté par Xavier Maillard . Évalué à -2.
# Te plain pas !
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
Tout les jours on m'envoie des fichier CSV qui doivent être transformé en SQL qui va bien puis injecté dans des tables MySQL et tout ça uniquement avec du PHP ...
Notre solution est une agression directement a la source pour envisager qu'on nous fournissent directement quelque chose d'exploitable.
[^] # Re: Te plain pas !
Posté par fcartegnie . Évalué à 2.
On se retrouve à faire des heures de développement de code pour corriger leurs lacunes, quand c'est possible.
Tiens j'ai oublié de mentionner: Le fichier simple "compressé" mais dans un tar.gz ou un zip...
# Problème inverse pour moi...
Posté par windu.2b . Évalué à 2.
Explication : j'avais une appli en Java à faire évoluer. Elle devait parler à un Web-Service (développé en .Net, ça a son importance), via SOAP. Pour ce dernier, c'est la librairie Axis qui était utilisée.
Cette librairie génère des classes Java, en fonction d'un WSDL (et de XSD) donnés en entrée. Pour un champ "xsd:DateTime", elle utilise la classe Calendar de Java.
Lors de l'envoi des données, la date est générée au format ISO 8601, en utilisatn le fuseau 'Z' (heure UTC), après avoir appliqué correctement le décalage horaire heure française -> heure UTC.
Mais en face, c'est une classe DateTime de .Net, qui est utilisée ! Et cette dernière ne sait pas gérer les fuseaux : elle garde telle quelle la date (et l'heure) qu'on lui donne... et la stocke telle quelle ensuite en base de données !
"Facile : y a qu'à utiliser la classe Calendar de .Net, au lieu de la classe DateTime !"... Sauf que non ! D'autres applis utilisent déjà ce Web-Service, et fonctionnent toutes avec la classe "DateTime", donc le bug n'apparait pas. Et donc impossible de modifier le Web-Service, car effets de bord garantis...
Bref, il a fallu pourrir la seule appli qui fonctionnait correctement, en faisant la seule chose à ne pas faire : rajouter le décalage "heure française -> heure UTC" dans l'objet Calendar, avant de l'envoyer...
/me a honte !
[^] # Re: Problème inverse pour moi...
Posté par TImaniac (site web personnel) . Évalué à 4.
Ah si, DateTime sait gérer les fuseaux. Après que le développeur sache pas utiliser DateTime c'est un autre problème.
[^] # Re: Problème inverse pour moi...
Posté par TImaniac (site web personnel) . Évalué à 5.
[WebMethod]
public string HelloWorld(DateTime dt)
{
var alt = dt.ToUniversalTime();
return String.Format("{0} ({1}) <=> {2} ({3})", dt, dt.Kind, alt, alt.Kind);
}
requête SOAP avec en paramètre : 2009-03-02T17:55:13.47Z
résultat obtenu :
02/03/2009 18:55:13 (Local) <=> 02/03/2009 17:55:13 (Utc)
[^] # Re: Problème inverse pour moi...
Posté par windu.2b . Évalué à 4.
Après, j'ai pas cherché non plus, vu qu'il m'avait dit qu'il était hors de question de toucher au code, parce que "ça marche très bien comme ça, actuellement"
[^] # Re: Problème inverse pour moi...
Posté par TImaniac (site web personnel) . Évalué à 2.
# plist
Posté par Octabrain . Évalué à 7.
< a >
< nomchamp >bidule< /nomchamp >
< valeurchamp >valeur< /valeurchamp >
< nomchamp >bidule2< /nomchamp >
< valeurchamp >valeur2< /valeurchamp >
< / a >
[...]
Le plus grave dans tout cela ? Il s'agit principalement d'enseignes bien connues de l'internet ou de leurs intermédaires.
Moi je sais, moi je sais ! C'est appeul pas vrai ? http://developer.apple.com/mac/library/documentation/Darwin/(...)
# Reccord à battre
Posté par Jerome Herman . Évalué à 2.
</rapport values="toto='1',tutu='{if tata<>0 then 1 else select monchamps from matable where truc end}', .... , rendu='echo \"\<html\>\<body\>{$tutu}\</br\>{$tata}....\</html\>\"' '"
De façon général toutes les branches de l'arbre s'appellaient rapport. On a vu trainer une branche debug une fois (mais après un appel au support, les fonctions de debug ne sont pas accessibles sur le logiciel client).
Pour un logiciel de reporting...
Et je compte pas les innombrables cas de transformation XML qui transforment
[section]
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
En
requete = 'select pleinsdetruc from matable'
droits='users'
destination='\\fileserver\disque\repertoire'
....
# Compassion
Posté par sifu . Évalué à 1.
Je trouve que l'on retrouve beaucoup trop de XML sans XSD ou RelaxNG digne de ce nom qui éviterait bien des complications.
Personnellement, j'ai utilisé SSIS (de chez M$) et je crois que je n'en suis pas encore remis...
# CSV FTW
Posté par plagiats . Évalué à 2.
* pérenne tout autant que son mapping (le plus pérenne possible)
* facile à traiter
* facile à analyser par Kevin du service IT quand son batch plante
* facile à archiver
C'est pas la solution idéale, bien entendu qu'on a pensé à mieux depuis et heureusement que tous les échanges ne se font pas par fichiers CSV (manquerait plus que ça), MAIS en entreprise et surtout pour du one-shot ça fonctionne et ça permet de tenir les délais sans bullshit et/ou prise de tête entre services.
[^] # Re: CSV FTW
Posté par sifu . Évalué à 2.
[^] # Re: CSV FTW
Posté par fcartegnie . Évalué à 2.
* pas de charset
* une redondance d'informations en relation directe avec la cardinalité des éléments
* J'ai besoin de te citer le nombre de cas où on trouve le délimiteur dans les champs ?
[^] # Re: CSV FTW
Posté par Zenitram (site web personnel) . Évalué à 2.
Virer le développeur : la norme est précise sur ce point. (comme pour les retours à la ligne)
[^] # Re: CSV FTW
Posté par wismerhill . Évalué à 3.
Déjà tu as généralement le choix entre la virgule (comme le nom l'indique) le point-virgule et la tabulation comme séparateur de champ, ensuite le caractère qui protège les champs (pour le multiligne notamment) peut être un simple ou double quote et tout le monde n'est pas d'accord sur la façon de protéger ce caractère à l'intérieur des champs (j'ai vu des cas où il était précédé d'un backslash plutôt que de le doubler, probablement un développeur qui a fait ça en vitesse sans chercher de doc).
[^] # Re: CSV FTW
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y a la RFC 4180 :
http://www.rfc-editor.org/rfc/rfc4180.txt
"Common Format and MIME Type for Comma-Separated Values (CSV) Files"
(bon, OK, "que" 2005, mais elle existe)
Si il n'y a pas de norme pour le CSV aujourd'hui, il n'y a pas de norme pour HTTP non plus alors (RFC aussi, pas plus).
Et c'est en tous cas celle qu'on me demande aujourd'hui de respecter quand je fournis du CSV à des organisations.
Tes exemple sont du CSV "fait maison" (Microsoft fait du "fait maison" sur les version non-US d'Office, quelle plaie.), il est certes vrai qu'avant 2005 il n'y avait pas de norme précise donc chacun (dont moi) faisait un peu comme il voulait... Mais ce n'est plus le cas depuis 4 ans, les nouveaux projets n'ont plus d'excuse.
[^] # Re: CSV FTW
Posté par wismerhill . Évalué à 5.
Sauf que ça arrive trop tard, à peu près à cette période je cherchais une petite bibliothèque en java pour lire/écrire facilement du CSV, j'ai pas trouvé et je l'ai écrit moi-même (c'est pas franchement compliqué, ce qui est une des raison de toutes les variantes) et j'ai cherché une spécification. Je n'ai pas trouvé cette RFC mais plusieurs explications et j'ai décidé qu'il fallait prendre en compte les différentes variantes, donc trois séparateurs différents et deux quotes différents.
Et même avec ça on a des clients qui ne s'en sortent pas, quand ils exportent en CSV avec excel celui-ci choisit automatiquement le séparateur de champ en fonction des paramètres régionaux et les clients ne savent pas quoi choisir lors de l'import. C'est pire dans l'autre sens, si on n'a pas choisi le bon ils ont toute la ligne dans la première cellule.
Au moins OOo (et tous les autres tableurs que je connaisse) proposent automatiquement de choisir les options de chargement.
De toute façon, depuis les décennies que que des programmeurs font du pseudo-CSV chacun à leur sauce, cette RFC bien tardive risque de ne rester que ça, une request for comment<:i>.
[^] # Re: CSV FTW
Posté par Pierre Carrier . Évalué à 0.
6. Fields containing line breaks (CRLF), double quotes, and commas
should be enclosed in double-quotes. For example:
"aaa","b CRLF
bb","ccc" CRLF
zzz,yyy,xxx
7. If double-quotes are used to enclose fields, then a double-quote
appearing inside a field must be escaped by preceding it with
another double quote. For example:
"aaa","b""bb","ccc"
[^] # Re: CSV FTW
Posté par BAud (site web personnel) . Évalué à 2.
le caractère µ est bien pratique pour cela ;-)
[^] # Re: CSV FTW
Posté par vrm (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.