Journal Optimisez qui disaient

Posté par .
Tags : aucun
0
21
mar.
2006
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.
  • # Si tu savais...

    Posté par . Évalué à  10 .

    Regardes en meme temps les specifications de la majoritee des nouveaux protocoles reseaux dedies au monde mobile et embarque. Impressionnant comme ils utilisent partout du XML super verbeux alors que jamais un etre humain ne le lira pour plus de 99.99% de son temps d'utilisation. Il n'y a guerre que les gens qui font les specs et font les implementations qui le verront... et encore ethereal aurait pu tres bien faire le boulot !

    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 . Évalué à  10 .

      mon opinion qui n'engage que moi :

      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 . Évalué à  10 .

        Autre hypothèse, pas forcément incompatible avec la première :

        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 (page perso) . Évalué à  10 .

          Ok,

          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 . Évalué à  10 .

            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.
            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 (page perso) . Évalué à  6 .

              heu, y'a pas brothers ou une autre marque (je ne m'en souviens plus) qui fournit des drivers pour cups ?


              si si, même que les pilotes CUPS et SANE sont sous GPL.
              Pour info ... ça marche bien :)
        • [^] # Re: Si tu savais...

          Posté par . Évalué à  9 .

          Diminution substantiel du temps (et donc de l'argent) impartie au développement.

          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 . Évalué à  3 .

            ou a l'inverse , pas de dev sans planning au carré.

            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 . Évalué à  4 .

              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 ...!



              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 . Évalué à  2 .

                merci d'avoir completé ce que je voulais dire. C'est exactement ca.
      • [^] # Re: Si tu savais...

        Posté par . Évalué à  8 .

        ouais.

        l'info, c'etait mieux a vent.
    • [^] # Re: Si tu savais...

      Posté par . Évalué à  1 .

      Pour info, il y a des standard de binarisation xml developes par mpeg7.

      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 . Évalué à  3 .

        En format XML-like et binaire y'a aussi EBML, utilisé avec succès dans le conteneur multimédia Matroska.
    • [^] # Re: Si tu savais...

      Posté par (page perso) . Évalué à  0 .

      Bon, ok, XML c'est verbeux, et ça coute plus en bande passante.

      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 (page perso) . Évalué à  7 .

        On pourrait utiliser ASN.1 à la place de XML. Après tout c'est justement fait pour l'interopérabilité, c'est compact (plus que XML au moins), et c'est complètement standard.

        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 (page perso) . É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 . Évalué à  -3 .

            Je prend parfois des décisions techniques mais je ne suis pas un con pétant !


            je sors ----->[ ]
          • [^] # Re: Si tu savais...

            Posté par . Évalué à  7 .

            je sais que si je connais pas c'est que j'en ai pas besoin mais j'aimerais en savoir un peu plus sur ASN.1. Serait-ce abuser de ton amabilité que te demander éventuellement de développer un peu (sans rentrer dans tous les détails bien sur), ou aurais-tu une URL qui donne plus de renseignement (je sais je peux taper dans google,mais peut-être que dans ton bookmark perso tu aurais un site bien qui traite du sujet, si tu dois chercher dans google laisse tomber, je peux le faire). Merci de ne pas me considérer comme un assisté ou un neuneu, mais comme tu as l'air de connaitre le sujet je pense que tu pourras me donner les bonnes pistes pour chercher.
            Merci d'avance.
            • [^] # Re: Si tu savais...

              Posté par . Évalué à  6 .

              http://fr.wikipedia.org/wiki/ASN.1

              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 :
              Client ::= SEQUENCE {
              nom PrintableString (SIZE (1..40)),
              rue PrintableString (SIZE (1..50)) OPTIONAL,
              codepostal NumericString (SIZE (10)),
              ville PrintableString (SIZE (1..30)),
              pays PrintableString (SIZE (1..20))
              DEFAULT pays-pardefaut }
              pays-pardefaut PrintableString ::= "France"
          • [^] # Re: Si tu savais...

            Posté par (page perso) . Évalué à  7 .

            XML ce n'est pas simplement une "méta-grammaire", c'est aussi :
            - 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 . Évalué à  2 .

              Ta dernière phrase, pleinede bon sens n'est malhereusement pas appliquée dans la majorité des cas. Les choix sont souvent dictés par la mode du moment ou les connaissances du concepteur. Alors en plus quand la persone qui conçoit le bouzin ne connait que XML et rien d'autre - parce que si elle ne le connait pas autre chose, c'est qu'elle n'en a pas besoin - ou que le XML est imposé car "a la mode", tu peux te retrouver avec une solution indaptée aux besoins initiaux :)
              Et c'est valable partout hélas !
              • [^] # Re: Si tu savais...

                Posté par (page perso) . Évalué à  4 .

                > ou que le XML est imposé car "a la mode"

                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 . Évalué à  2 .

                  C'était une façon de parler .... autrement dit "on va faire en XML" non pas parce que pour un problème donné c'est la solution la plus efficacce, mais parce que tout le monde utilise XML, on ne va pas se poser la question d'une autre solution mieux adaptée. C'est un peu comme flash par exemple. En mettant son côté non-libre de côté, si on regarde les sites développés en flash, on se rend compte que pour certains c'est justifié (par rapport a ler activité par xemple) tandis que d'autres utilisent flash pour avir de jolis menus alors qu'on peut faire la lême chose avec des CSS.

                  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 (page perso) . Évalué à  5 .

              XPath, XSLT, quel intéret pour un protocol de type Jabber ?

              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 . Évalué à  2 .

                XPath, XSLT, quel intéret pour un protocol de type Jabber ?


                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.

                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.


                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 (page perso) . Évalué à  3 .

                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.
                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 . Évalué à  2 .

    La plus part des routeurs sont flashables. Existe-t-il des firmwares alternatifs pour différents routeurs comme il en existe pour les jokebox mp3, les pda etc...

    Si oui, avez vous déjà tenté l'expérience ?
    • [^] # Re: OS alternatifs ??

      Posté par (page perso) . Évalué à  1 .

      Pour le routeur présenté je ne sais pas, mais en ce qui concerte les linksys wrt54g openwrt marche très bien. Testé et approuvé :) (il marche aussi sur d'autres matériels ASUS par exemple)
      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 . Évalué à  3 .

      Oui j'ai tenté le coup. Plusieurs marques fabriquent exactement le même modem/routeur que le mien avec un firmware différent (Olitec/Origo/Billion/Telewell/Nethawk/...). Dans le lot il semble que le firmware SMC soit le plus basique. A l'opposé le Billion c'est du pur bonheur. Il propose en plus des fonctionnalités de firewall avancée, la gestion SNMP, un accès ssh (pas testé encore), la gestion des DNS dynamique, et plus d'options un peu partout (il y a par exemple plusieurs comptes en plus de l'administrateur, je n'ai pas encore compris pour quoi faire). Je n'en n'ai pas encore fait le tour. J'ai eu l'impression d'avoir changé de routeur.

      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.
  • # Ton routeur, il marche?

    Posté par (page perso) . Évalué à  1 .

    Ok, imagine que tu as 200ko de page HTML qui pourraient etre 25ko. Sur tes 2Mo de flash, a quoi vont te servir les 175ko liberes?

    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?
    • [^] # Re: Ton routeur, il marche?

      Posté par (page perso) . Évalué à  1 .

      >Ok, imagine que tu as 200ko de page HTML qui pourraient etre 25ko.
      >Sur tes 2Mo de flash, a quoi vont te servir les 175ko liberes?

      Des buffers pour le kernel ?

      >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?

      Je suppose que tu parles du débuggage du routeur en lui-même.

      Mais dans le cas du html, la modification des pages risque d'être ardu et le développeur perdra beaucoup de temps.

      De plus, il est plus rapide avec un peu d'habitude de faire du xhtml/css que de l'html pure vieille école. Les raisons sont simples :
      - Code plus succinct
      - Séparation contenu/présentation

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.