Ce weekend, j'ai eu la curiosité de regarder la tête qu'avaient les pages web de l'interface de configuration de mon routeur (SMC 7401BRA) et là je suis tombé un peu sur le cul de voir... ça. Une espèce de merde de html qui ressemble à ce que génère Word. Une ignominie bourrée d'attributs de style en dur dupliqués partout, de fonctions javascript recopiées dans tous les fichier (alors qu'il y a à côté une css et un fichier javascript inclus dans certaines pages donc c'est géré), des balises "font" vide des "span lang=zh_TW" alors que tout est en anglais et le pire c'est qu'il ne semble y avoir aucune cohérence d'une page à l'autre. Normalement un générateur donne toujours à peu près le même rendu (pourri). Ca voudrait donc dire que cette "chose" a été codée à la main ???
Je n'aurais jamais cru qu'on trouverais une telle merde dans le monde de l'embarqué. Mon routeur n'a que 2Mo de mémoire flash. Autrement dit le moindre ko compte. Comment peut-on utiliser des
pages aussi merdiques dans ces conditions ? En nettoyant tout ça on doit gagner les 3/4 en taille. Ce n'est pas rien vu le faible espace de stockage. J'avoue que ça me laisse rêveur.
Journal Optimisez qui disaient
21
mar.
2006
# Si tu savais...
Posté par cedric . Évalué à 10.
Ce qui est encore plus drole c'est que sur un mobile sur batterie, la moindre action consomme de la batterie, alors pourquoi diable ils tiennent absolument a tout parser !
[^] # Re: Si tu savais...
Posté par kesako . Évalué à 10.
Baisse generale du niveau technique (et meme du niveau tout court) de tous les chefs de projets en informatique. Chacun se couvre avec le travail de l'autre.
[^] # Re: Si tu savais...
Posté par Yoann A. . Évalué à 10.
Diminution substantiel du temps (et donc de l'argent) impartie au développement. On fait donc au plus vite, au détriment de l'optimisation et parfois de la sécurité aussi.
L'argument étant que, de toutes manières, la pérénité est vaine : tout produit sera remplacé par un nouveau dans les 6 mois qui suivent, parce que la course aux parts de marché est rude et en constante accélération.
(je n'ai pas dit que je suis d'accord avec ce que je viens d'écrire)
[^] # Re: Si tu savais...
Posté par hervé Couvelard . Évalué à 10.
Mais ne peut-on penser que si on fait un truc bien et intelligent, on pourra le réutiliser (en le faisant évoluer) sur le projet suivant ?
Ne peut-on penser qu'avec des outils plus pointus, mieux fait, mieux pensé, on 'capitalise' en interne du savoir faire et en externe de la 'reconnaissance' client.
Je m'explique lorsque l'on me demande quelle imprimante choisir, je donne HP ou epson à cause de la facilité d'installation sous linux (même si c'est pour un winwin), en clair je dis merci à ma manière en les conseillant.
[^] # Re: Si tu savais...
Posté par Matthieu . Évalué à 10.
D'un autre côté, faut pas trop demander aux ingénieurs informaticiens de trop réfléchir sur un projet, car sinon ils font arriver à la conclusion que le logiciel a faire est débile et sera obsolète dans 2 mois. ;-)
je donne HP ou epson à cause de la facilité d'installation sous linux
heu, y'a pas brothers ou une autre marque (je ne m'en souviens plus) qui fournit des drivers pour cups ?
[^] # Re: Si tu savais...
Posté par Marc Poiroud (site web personnel) . Évalué à 6.
si si, même que les pilotes CUPS et SANE sont sous GPL.
Pour info ... ça marche bien :)
[^] # Re: Si tu savais...
Posté par imalip . Évalué à 9.
Qui va en général avec une augmentation monstrueuse du travail a réaliser en amont, et des procedure a suivre méticuleusement. C'est comme ca que je me suis retrouvé a devoir écrire les specs d'une glue entre une API non définie et une sur le point de changer. Et surtout, pas le droit de coder quoi que ce soit avant d'avoir les specs finies, lues, relues, pré-validées, corrigées, re-relues, revalidées, certifiées par le bureau de vérification.
Bilan, 3 mois de procédures, specs et réunions avant de passer une demi-journée a écrire et tester un wrapper entre OPA_Jpeg_Decode et GFDecodeJpeg. Il suffit d'imaginer ca appliqué a un projet plus important pour ne plus s'etonner de la qualité de certains produits...
[^] # Re: Si tu savais...
Posté par kesako . Évalué à 3.
Genre on fait une specif. On pense que le dev n'est pas con et qu'il va faire un travail a "l'etat de l'art" . Donc on ne precise pas tout ce qui est evident.
Manque de bol, le boulot est fait par un stagiaire ou un nouveau .
Resultat : manque plein de chose, ou il y a plein de choses branlantes.
Avec un pro dans le temps, il corrigerait ca vite fait bien fait en 10 minutes montre en main. Meme si ce n'est pas lui qui a fait le boulot.
maintenant , pas question : c'est pas dans les specif , donc c'est une evolution , donc faut planifier et allouer des resources ... meme si le dev est dans le bureau d'a cote ...!
Est ce qu'ils se rendent compte que ca revient a creuser leur tombe , puis qu'on ferait la meme chose avec un gars en Inde ou en Chine, 10 fois moins cher?
[^] # Re: Si tu savais...
Posté par totof2000 . Évalué à 4.
maintenant , pas question : c'est pas dans les specif , donc c'est une evolution , donc faut planifier et allouer des resources ... meme si le dev est dans le bureau d'a cote ...!
Mouais, mais j'ai connu dans ce genre de méthodes les spécifications qui change plus de dix fois par jour pour un meme programme parce que l'analyse en amont n'avait pas été faite correctement.
Mais je suis d'accord que l'excès dans un sens comme dans l'autre est nuisible pour tout le monde.
[^] # Re: Si tu savais...
Posté par kesako . Évalué à 2.
[^] # Re: Si tu savais...
Posté par hiphopmomo . Évalué à 8.
l'info, c'etait mieux a vent.
[^] # Re: Si tu savais...
Posté par Pierre . Évalué à 1.
http://www.mitre.org/news/events/xml4bin/pdf/thienot_binary.(...)
Ca n'est pas libre (encore, m'a dis cedric il y a qq temps), mais c'est assez interressant dans l'approche.
Le probleme, par rapport a xml, c'est la compatibilite. Faut refaire pas mal de soft pour le supporter.
[^] # Re: Si tu savais...
Posté par pshunter . Évalué à 3.
[^] # Re: Si tu savais...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Le choix de XML est tout de même judicieux : cela améliore l'interoperabilité.
Quand tu n'as pas de spec et que tu as un flux xml, le reverse engeenering est plus facile sur ce genre de type de donnée même si le nom des balises n'évoque pas grand chose, que sur un flux binaire contenant une suite d'octet pas trés logique, L'information est structurée.
Ensuite, cela permet d'éviter d'écrire un énième parser de flux. Parser XML + api DOM pour en extraire les données et basta. Pas de nième bibliothèque bas niveau à développer, ou dont il faut apprendre l'API.
Ensuite cela permet des choses sympa. Genre pour des passerelles entre deux flux de formats xml différents. Une feuille XSLT pour transformer un message d'un format A à un format B et basta (bon, ok c'est super théorique et simpliste comme exemple, dans la réalité, ça peut être plus compliqué, tout dépend des différences entre le format A et B).
Alors c'est sûr, XML est plus gourmand en ressource.
[^] # Re: Si tu savais...
Posté par jcs (site web personnel) . Évalué à 7.
L'avantage c'est qu'on aurait enfin des bibliothèques ASN.1 libres et de bonne qualité. L'inconvénient c'est qu'on a pas de XSLT dans ce cas là.
[^] # Re: Si tu savais...
Posté par vrm (site web personnel) . Évalué à 4.
ASN.1 c'est fais pour ca.. l'intérop réseau avec une grammaire standard et des facon d'encoder en binaire standard.
XML dans les protocoles c'est juste une abération, un effet de mode accouplé à des preneur de déscision technique incompétents
[^] # Re: Si tu savais...
Posté par Matthieu . Évalué à -3.
je sors ----->[ ]
[^] # Re: Si tu savais...
Posté par totof2000 . Évalué à 7.
Merci d'avance.
[^] # Re: Si tu savais...
Posté par Matthieu . Évalué à 6.
ASN.1 (Abstract Syntax Notation One) est un standard international destiné à l'origine à décrire les données échangées dans les protocoles de télécommunication (modèle OSI). Standardisé en 1984, utilisé à l'origine pour les échanges de courriers électroniques, il fournit une notation formelle qui décrit le format des messages. Il est mis en ½uvre dans un grand nombre d'applications (gestion de réseaux, messagerie, sécurité, téléphonie, Internet, etc.).
La norme initiale date de 1988 (CCITT Recommendation X.208 : Specification of Abstract Syntax Notation One), une nouvelle version (ISO/CEI 8824-1 / UIT-T X.680) a été émise en 1993.
Exemple :
[^] # Re: Si tu savais...
Posté par totof2000 . Évalué à 2.
[^] # Re: Si tu savais...
Posté par vrm (site web personnel) . Évalué à 2.
http://luca.ntop.org/Teaching/Appunti/asn1.html
ASN.1 est une grammaire pour décrire des procotoles. On l'associe à un enocder (BER, DER par example ) vqui encode les message de façon binaire
[^] # Re: Si tu savais...
Posté par TImaniac (site web personnel) . Évalué à 7.
- un standard pour la rédaction des grammaires avec protocole de validation (XML-Schema)
- un standard de transformation (XSLT)
- un standard de requête (XPath)
- des implémentations standards (DOM, SAX)
- une structure en arbre des données, permettant
- possibilitée de combiner plusieurs grammaire (eXtensible ML)
Bref, questions outils pour l'interopérabilité c'est bien plus poussé que ce que propose ASN.1.
Je ne parles même pas des normes ws-*...
Je ne vois pas du tout en quoi c'est absurde d'utiliser XML dans les protocoles de "haut niveau" (niveau application), sachant que ce n'est pas contradictoire avec ASN.1 :
http://asn1.elibel.tm.fr/en/xml/
C'est comme si je te disais ASN.1 c'est naz, franchement on devrait tous coder en binaire, c'est vrai quoi, c'est une grammaire simple et standard : des 0 et des 1.
Faut juste faire le bon choix en fonction du contexte.
[^] # Re: Si tu savais...
Posté par totof2000 . Évalué à 2.
Et c'est valable partout hélas !
[^] # Re: Si tu savais...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Elle dure la mode, vu le nombre d'année qu'existe XML... :-p
XML, ce n'est pas une histoire de mode. Si on l'utilise de plus en plus, c'est parce que (à mon avis) la puissance des machines d'aujourd'hui permet de profiter toute la puissance d'XML, de toutes ses possibilités, et que par la même occasion, on dispose de plus en plus d'outils et de bibliothèques.
Et puis des specifications de technos annexes à XML (xsl, xpath, xquery, rdf, etc...) sortent, s'améliorent. Bref, ça devient vraiment interressant d'utiliser XML. ça devient universel.
[^] # Re: Si tu savais...
Posté par totof2000 . Évalué à 2.
Je ne remet nullement en cause l'utilité de XML, car c'est effectivement une solution adaptée à beaucoup de problèms.
[^] # Re: Si tu savais...
Posté par vrm (site web personnel) . Évalué à 5.
tu fait un grammaire ASN.1 tu met un encoder BER et tu dois bien avoir une économie d'au moins 50% sur la taille de tes messages. C'est sur ASN.1 c'est pas fait pour du document (type xhtml,fop ou fichier de config) mais pour les communications réseaux. oui un encodeur XML existe .. mais l'interet est plutot limité.
Désolé mais quand je vois des abérations comme XML-RPC ou Jabber/XMPP ca me mets hors de moi... je suis persuadé qu'avec ASN.1 on peut gagner 50 à 80% sur la taille des messages. Désolé mais XML vu sa nature verbeuse et textuelle na rien à faire dans les protocoles de communication.
[^] # Re: Si tu savais...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
C'est super facile à comprendre le protocole à partir du moment où tu connais un peu XML. Du coup, c'est facile de développer un logiciel client (qui n'est d'ailleurs pas forcément un client type messagerie instantanée à destination d'un utilisateur humain
Pourquoi plein d'applications utilisent des fichiers texte ? Parce que les outils nécessaires à sa manipulation sont multiples, c'est donc un gain de temps.
Pourquoi plein d'applications utilisent des fichiers xml ? Parce que les outils nécessaires à sa manipulation sont multiples, c'est donc un gain de temps. En plus, par rapport à du texte, c'est nativement structuré sous forme arborescente, ce qui est beaucoup plus puissant.
Pourquoi tout le monde n'utilise pas XML ? Parce qu'il faudrait être c.. pour croire que c'est LA solution. En attendant, si tu veux structurer des données, c'est quand même un outil puissant.
Tu gagnes 50 à 80% sur la taille, mais tu perds combien en développement quand il s'agit de faire des interfaces entre tes différents formats ?
Pourquoi on utilise majoritairement l'Anglais pour la communication internationale ? Pas parce que c'est la "meilleure" langue, ni la plus concise, ni la plus adaptée à tel ou tel sujet mais simplement parce que c'est plus simple quand tout le monde se comprend... Ca ne remet pas en cause pour autant l'intérêt des autres langues !
[^] # Re: Si tu savais...
Posté par TImaniac (site web personnel) . Évalué à 3.
Je viens d'expliquer qu'il est tout à fait envisageable d'avoir un protocole sous-jacent plus "efficace" et qui compresse le flux XML pour réduire considérablement sa taille. (essai de gziper un .xml tu vas voir). C'est même paramètrable en fonction des acteurs échangeant des données. (Apache le fait par exemple).
Après si dans la pratique la compression n'est pas toujours utilisée, c'est pour des raisons d'interopérabilité, et non pas une impossibilité.
Le problème de la verbosité est donc un faux problème dans ces protocoles de couches applicatives comme Jabber/XMPP ou XML-RPC.
Prend par exemple les web-services, qui sont un espèce de XML-RPC amélioré : toute la puissance des web-services résident dans leur faculté de s'auto-documenter, le message peut contenir un schema décrivant la structure du message lui-même, donnant le message ainsi que la clé pour le décrypter. Et ca en matière d'interopérabilité c'est vital.
Un autre exemple : regardes la technique dite "Ajax", elle se base sur un concept extrêment simple : la possibilité d'accéder à un flux XML depuis le serveur, et ce par script : tu peux alors utiliser toute la puissance de javascript pour "parser" le flux XML, parcque tous les outils sont là en standard.
# OS alternatifs ??
Posté par KiKouN . Évalué à 2.
Si oui, avez vous déjà tenté l'expérience ?
[^] # Re: OS alternatifs ??
Posté par Bapt (site web personnel) . Évalué à 1.
http://openwrt.org/
SInon la base pour la plupart des firmware alternatifs sous linux c'est basé sur openembedded :
http://oe.handhelds.org/
[^] # Re: OS alternatifs ??
Posté par Croconux . Évalué à 3.
Deux regrets : Ca tourne sous VxWorks, un OS embaqué sur lequel j'ai trouvé peu de doc (enfin sans acheter une license $$$). J'aurai bien aimé un petit Linux mais apparemment sur le mien ça n'existe pas. Et ensuite la procédure de flashage est un peu lourde. Il ne suffit pas de faire un simple update via l'interface web. Il faut faire un hard reset, c'est à dire écraser complètement le contenu de la mémoire flash et réécrire dessus. Ca ne peut se faire que par l'USB. Il faut ouvrir le router, mettre un cavalier sur deux contact et utiliser un utilitaire spécial pour écrire le firmware. L'avantage c'est que même si le routeur est complètement viandé suite à une manip douteuse et qu'il ne boote même plus il est encore possible de remettre le firmware d'origine. A ce propos il y a un bidouilleur de génie qui a eu la bonne idée de faire un live CD FreeDos pour effectuer toutes les manips. En effet tous les utilitaires tournent uniquement sous DOS (la misère). Grace à ce CD, il suffit de booter, de choisir un firmware dans le menu et zou.
[^] # Re: OS alternatifs ??
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
http://spacegrant.colorado.edu/~dixonc/vxworks/docs/vxworks/(...)
Question subsidiaire : quel est le montant de l'amende que je risque en postant ce lien ? Moi je mise sur 150 ¤, et vous ?
# Ton routeur, il marche?
Posté par Erwan . Évalué à 1.
Autre chose: le mec qui a developpe ca, il a peut-etre fait les pages a la va vite pour se concentrer ensuite sur le debuggage. Il aurait mieux fait de faire de tres belles pages bien chiadees, avec du xhtml et des feuilles de style plutot que du debuggage?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.