Les technos web cools du moment

Posté par  (site web personnel) . Modéré par baud123.
Étiquettes :
33
24
fév.
2010
Internet
Dans le cadre de mon activité professionnelle, je fais de la veille autour des technologies web. Suite à un récent journal sur CouchDb, je me suis dit que les lecteurs de LinuxFr.org pourrait être intéressé par le sujet. J'ai donc regroupé un paquet de liens récents dans la seconde partie de cette dépêche. La plupart viennent du compte delicious qui me sert pour la veille. Les autres liens sont de l'auto-promotion vers des billets que j'ai écrit. HTML5 & Canvas

HTML5, avec notamment Canvas, permet de plus en plus de se passer de Flash sur les sites web. Voici la preuve en quelques liens :

Node.js

Node.js est LA plate-forme cool du moment. C'est un environnement Javascript côté serveur qui utilise le moteur V8. Sa grande force est son modèle événementiel, similaire dans le principe à EventMachine ou à Twisted. Node.js va toutefois plus loin en intégrant ça au cœur du langage et des API de bas niveaux. Par exemple, la lecture d'un fichier se fera par défaut de manière asynchrone. Le projet est encore tout jeune (quelques mois), mais je suis prêt à parier que l'on va en entendre parler dans les années à venir.

MongoDB

Les bases de données NoSQL ont la cote, surtout pour le développement d'applications web. MongoDB est, à mon humble avis, parmi les bases NoSQL les plus attrayantes. En effet, elle est simple à prendre en main, mais offre déjà de nombreux avantages par rapport à une base de données relationnelles : plus de souplesse (pas de schéma dans la base, et donc pas de migrations pour modifier ce schéma), les types composés (tableau et hash) bien pratiques, des performances brutes impressionnantes, administration simple même pour de la réplication ou du sharding... Voici de quoi approfondir le sujet :

Autres bases NoSQL

MongoDB n'est pas la seule base de données NoSQL. Un nombre très conséquent d'articles sur ce domaine sort chaque jour. Je me suis limité à quelques liens qui me semblent particulièrement pertinents :

Vim & Emacs

Je n'ai pas pu m'empêcher de lancer un petit troll Vim/Emacs en quelques liens :

Autres

Pour finir, j'ai regroupé des liens qui ne rentraient dans aucune des catégories précédentes :

Aller plus loin

  • # HTML5 & Canvas

    Posté par  . Évalué à 7.

    Vous pouvez voir ici tout un paquet de démos sur ce que l'on peut faire aujourd'hui avec ces nouvelles technos: http://hacks.mozilla.org/

  • # GWT

    Posté par  (site web personnel) . Évalué à 0.

    Pour moi la plus cool du moment est GWT

    http://code.google.com/intl/fr-FR/webtoolkit/

    • [^] # Re: GWT

      Posté par  (site web personnel) . Évalué à 5.

      un argumentaire ?

      • [^] # Re: GWT

        Posté par  (site web personnel) . Évalué à 9.

        Google prend en charge la complexité multi-langage du Web en proposant aux developpeurs une abstraction en Java.

        Il n'y a plus que du Java (et du css pour ceux qui veulent / peuvent) que ce soit du côté client que du côté serveur. Le code Java côté client est compilé par GWT pour obtenir un code Javascript hyper optimisé.

        La grosse avancé la dedans est la simplification de l'architecture vue par le développeur. La maintenance est bien plus facile, car le développeur dispose d'outils très performant (Eclipse entre autre) pour pouvoir maintenir (debugger.. etc..) le code de manière bien plus simple.

        En plus de la simplification, le code executé par le navigateur est très optimisé, et s'exécute donc plus vite. l'utilisateur final voit vraiment la différence.

        L'architecture de GWT permet aux developpeurs de controler de manière très fine les flux entre le navigateur et le serveur. L'un des slogan de GWT est "ne paie que ce que tu utilises" ce qui veut dire que le client ne "téléchargera" que les ressources dont il a besoin. GWT permet de diminuer le nombre d'appel serveur en regroupant les ressources afin de ne faire qu'un appel pour récupérer l'ensemble des images afficher sur la page (idem pour tous les types de ressources).

        Tout est basé sur les standards existants, ce qui est un bon point pour la pérennité.

        Côté accesibilité, ils essais de faire au mieux dans le contexte Ajax avec la norme en cours de validation ARIA. Je n'ai pas eu l'occasion de tester ce point.

        Je ne peux pas être exhaustif ici (sinon la réponse serait démesurement longue) mais en tout cas pour réaliser des APPLICATIONS WEB, aujourd'hui il n'y a pas mieux.

        • [^] # Re: GWT

          Posté par  . Évalué à 1.

          Est-ce que quelqu'un a utilisé GWT avec un backend PHP (comme project gwtphp) + framework PHP ? Le probleme c'est qu'on ne peut pas forcement avoir un serveur java derriere mais au niveau interface GWT m'interesse, par contre je ne sais pas si on perd beaucoup de facilitées de dev si on onleve le java en backend.

          • [^] # Re: GWT

            Posté par  (site web personnel) . Évalué à 1.

            Tu peux dialoguer avec le serveur en JSON ou en XML.

            Tu peux donc utiliser la techno de ton choix côté serveur, pas de problème la dessus.

            infos: http://code.google.com/intl/fr/webtoolkit/doc/latest/DevGuid(...)

            • [^] # Re: GWT

              Posté par  . Évalué à 1.

              Ma question ne porte pas sur la faisabilité technique, elle porte sur le fait de savoir s'il est avantageux de passer d'une solution pure framework php + jquery css par exemple a un GWT + framework php au niveau productivité. Ou si la solution GWT a plus de sens quand elle s'applique aussi bien a la partie client que serveur.

        • [^] # Re: GWT

          Posté par  (site web personnel) . Évalué à 1.

          Je ne peux pas être exhaustif ici (sinon la réponse serait démesurement longue) mais en tout cas pour réaliser des APPLICATIONS WEB, aujourd'hui il n'y a pas mieux.

          Je ne sais pas si c'est mieux, et de toutes façons c'est objectif, mais il y a aussi tapestry[1] de chez apache qui fait des choses similaires et qui est très pratique.

          Ça suit le même principe, tout est développé en java, et avec des templates en html.

          Certains tags spéciaux (un peu comme STRUTS) permettent d'insérer des valeurs obtenues par du code java.

          Alors certes ce n'est pas que du java, mais ça apporte la souplesse du html/css et il y a un principe de composants.
          Un composant c'est un bout de page html (par exemple un tableau, un graphique, ...) qui est paramétrable.
          Il est par la suite possible d'utiliser ces composants dans une page html autant de fois que nécessaire.

          Tapestry est capable de gérer des retours ajax, il suffit simplement de définir des zones qu'il doit rafraîchir au retour ajax, et il 'rejouera' le template sur ces portions seulement.

          Il y a très peu de code java à écrire, ça utilise beaucoup les annotations, et avec un peu de pratique, ça permet d'aller très vite, car on s'aperçoit à l'usage que l'utilisation des composants est très puissante car elle rend le code source très modulaire.

          [1] http://tapestry.apache.org/

    • [^] # Re: GWT

      Posté par  . Évalué à 2.

      A voir aussi : Play! framework.

      http://www.playframework.org/

    • [^] # Re: GWT

      Posté par  (site web personnel) . Évalué à 4.

      Complètement d'accord.

      Le résultat final est une appli full ajax tout en javascript avec un fichier js pour chaque moteur de rendu multiplié par le nombre de langues que l'on souhaite supporter.

      Je l'utilises pour minig depuis plus de 2ans et je ne regrette absolument pas. Je peux faire transiter des objets complexes entre le navigateur et le serveur sans m'occuper de comment ils seront transmis sur le wire.

      Si je dois lui faire une seule critique : il se base beaucoup sur le fait que les modèles mémoires de java et de javascript doivent être similaires en terme de récupération de ram. Malheureusement aucun moteur n'implémente sa collecte de ram comme java : les références croisées ne sont pas collectés par les navigateurs du moment. Les API de gwt évoluent petit à petit pour pouvoir régler ça.

      En dehors de ce petit bemol, c'est vraiment génial, test du code dans mon navigateur et les erreurs s'affichent sous la forme de stacktrace java avec numéro de ligne. Refresh du navigateur pour exécuter le code tout juste sauvegardé dans eclipse. Permet un cycle de dev qu'on jalousai aux développeurs php avant.

      • [^] # Re: GWT

        Posté par  . Évalué à 1.

        GWT ne gère pas le javascript désactivé. Tant que ce point là ne sera pas réglé, GWT ne sera pas pour moi.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

  • # 2

    Posté par  . Évalué à 2.


    * gRaphael permet de tracer facilement des graphiques avec Canvas grâce à la bibliothèque Raphael ;
    ...


    Pour moi c'est inutilisable pour l'instant car pas une solution 'portable', à savoir avec un fallback en cas de non javascript ou de non-canvas.
    Personnellement, j'ai du faire ma propre lib qui génère des graphes en SVG et en cas de non support fait un rendu JPEG.
    Toujours en attente d'une bibliothèque supportant le rendu avec formats de sortie multiples...

    Les bases de données NoSQL ont la cote, surtout pour le développement d'applications web.
    Ca ressemble tout de même à du memcached avec une seule différence au niveau de la fonction de hachage (ou se trouve le traitement des requêtes NoSQL). Le tout avec les désavantages de ne plus avoir de langage standardisé (pour l'instant ?) :/

    • [^] # Re: 2

      Posté par  (site web personnel) . Évalué à 7.

      > Ca ressemble tout de même à du memcached

      Ça dépend des bases de données NoSQL. Redis ressemble très fortement à du memcached, il est "juste" plus rapide, a un jeu d'instructions un peu plus étendu et surtout a une notion de persistance. Quand on relance memcached, on a perdu toutes les données, alors que l'on retrouve toutes ses données quand on relance Redis. Ceci dit, redis reste très proche de memcached.

      Par contre, il existe d'autres bases de données NoSQL qui n'ont pas grand chose à voir avec memcached. Par exemple, MongoDB est beaucoup plus proche d'une base de données SQL que de memcached. On peut faire des requêtes avec des opérateurs évolués et une sémantique qui s'inspire en parti du SQL (table <-> collection, colonne <-> champ, des critères de tri, ORDER BY <-> sort(), limit & offset <-> limit() & skip(), etc.). En pratique, des requêtes sur MongoDB, ça ressemble à ça :


      db.posts.insert({author: 'georges', title: 'foobar', body: 'blablabla', created_at: new Date('03-28-2009'), tags: ['titi', 'toto']});

      articles = db.posts.find().sort({created_at:-1}).limit(10);
      a_post = db.posts.findOne({}, {title: 1, body: 1});
      db.posts.find({author:"george"}).count();

  • # Les adminsys en redemande

    Posté par  . Évalué à 10.

    > Node.js est LA plate-forme cool du moment

    Confrères sysadmins, vous aviez réussi à échapper aux frameworks web J2EE plébiscités par les dissaildeurs pressés ? Les confs en XML ne vous font plus peur ? et bien paf, les webkiddies ne vous épargneront pas les serveurs - http, ftp et leur config - en javascript !

    Avec ses petits copains Comet et Web Sockets, vous découvrirez aussi le bonheur de maintenir des centaines de milliers de connexions persistantes à travers votre pauvre firewall stateful sous iptables/conntrack. Yipiii :) Un plaisir à ne pas bouder, car ça ne durera pas : quelqu'un écrira bientôt le firewall enfin scalable en javascript.

    Vous découvrirez aussi, attendris, la larme à l'oeil, les charmes vintages des bases de données sans mot de passe exposées au public, lorsque vos jeunes javascripteurs réclameront l'accès REST direct du navigateur au Mongo ou à la Couche ; car après tout, ce n'est que du json, c'est cool et ça ne peux pas faire de mal hein ?

    En tout cas : merci coolitude, car nous voila enfin à l'abris des buffer overflows :)

    • [^] # Re: Les adminsys en redemande

      Posté par  . Évalué à 4.

      Avec ses petits copains Comet et Web Sockets, vous découvrirez aussi le bonheur de maintenir des centaines de milliers de connexions persistantes à travers votre pauvre firewall stateful sous iptables/conntrack. Yipiii :) Un plaisir à ne pas bouder, car ça ne durera pas : quelqu'un écrira bientôt le firewall enfin scalable en javascript.

      Ne te plains pas, tu vas enfin pouvoir acheter bientôt du nouveau matos pour gérer ces milliers de sockets persistantes qui n'existaient pas avant. Entre les ours polaires et la coolitude, il va falloir choisir.

      • [^] # Re: Les adminsys en redemande

        Posté par  (site web personnel) . Évalué à 4.

        Ou pas. Plurk arrive bien à tenir les 100 000 connexions simultanées avec un seul serveur grâce à Node.js (source : http://news.ycombinator.com/item?id=1088699 ). Donc il n'y a pas forcément besoin d'acheter plus de matos.

        • [^] # Re: Les adminsys en redemandent

          Posté par  (site web personnel) . Évalué à 2.

          > Plurk arrive bien à tenir les 100 000 connexions simultanées

          Qui font quoi ?

          L'article en dit assez peu :
          # huge amount of usage - to this day our users have posted over 1 billion unique messages
          # complexity of Plurk's features - such as mute, responses seen, private plurks etc.

          « un milliard de message jusqu'à maintenant » depuis quand ?

          Ça ne fait pas de présence ? C'est souvent ça le premier consommateur de ressources d'un système d'IM.

          > avec un seul serveur grâce à Node.js

          Quel hardware/puissance ?

          Autre précision de l'article :
          We have rewritten to node.js from Java+JBoss Netty, because the old solution had scalability problems. We have also been able to build a very sophisticated messaging system given JavaScript expressiveness and the simplicity of node.js. Generally, we have found node.js and V8 very impressive - and it uses about 10 times less memory than Java+Netty did. The bottom line is if you implement anything comet related - - try to use node.js!

          A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?

          • [^] # Re: Les adminsys en redemandent

            Posté par  (site web personnel) . Évalué à 4.

            > Qui font quoi ?

            Bonne question ;-)
            Je n'en sais rien.

            > « un milliard de message jusqu'à maintenant » depuis quand ?

            Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.

            > Ça ne fait pas de présence ?

            Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.

            > Quel hardware/puissance ?

            1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic level. node.js uses around 10x less than that).

            > A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?

            Je ne connais pas Netty, mais d'après amix, node.js propose une API de plus haut niveau que Netty, et est donc plus facile à utiliser.

            • [^] # Re: Les adminsys en redemandent

              Posté par  . Évalué à 3.

              Les API de multiplexage des sockets utilisées par node.js (epoll(7) ou kqueue(2)) scalent le nombre de connexions en O(1), il est connu qu'on peux accepter un nombre quasiment infini de connexions dormantes. Aucun mérite :). Le chiffre peut impressionner parce qu'il ne correspond pas à ce qu'on compte habituellement : "100 000 connexions simultanées", ce n'est pas "100 000 connexions par seconde" et encore moins "100 000 requêtes GET par seconde".

              Mais je parlais des firewalls à état traversés pour atteindre les node.js, pas des serveurs applicatifs node.js eux-même (pour autant que ces firewalls soient aussi utilisés pour autre chose que maintenir des connexions vides, ie. router du vrais traffic).

              > 1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM
              > serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic
              > level. node.js uses around 10x less than that).

              En même temps, le bougre ne supporte pas les architectures 64 bits, si j'en crois la doc. Il aurait donc bien du mal à utiliser plus - même lorsqu'il serait pertinent de cacher des choses en ram...

              • [^] # Re: Les adminsys en redemandent

                Posté par  (site web personnel) . Évalué à 1.

                Oui, mais "100 000 connexions simultanées" nécessite de conserver un contexte en mémoire, et peut-être du keepalive.

                • [^] # Re: Les adminsys en redemandent

                  Posté par  . Évalué à 3.

                  > Oui, mais "100 000 connexions simultanées" nécessite de conserver un contexte en mémoire,

                  Le coût système (non applicatif) mémoire de la conservation de sockets TCP established est évaluable. Je ne connais pas la surcharge spécifique de libev (utilisée par node.js), mais c'est vraisemblablement du même ordre que pour la libevent, pour laquelle les valeurs sont connues :

                  Voir la seconde partie de ce test (l'implem en C avec libevent) de Richard Jones (de Last.fm, qui semble largement plus sérieux que le gars de Plurk btw) :
                  1 *million* de connexions consomme moins de 2 GB (userland, RSS) + kernel, avec libevent.

                  "I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB". "the resident memory per connection for the server process with libevent is just under 2KB. [...] the kernel/tcp stack is consuming an additional 8KB per connection".
                  http://www.metabrew.com/article/a-million-user-comet-applica(...)

                  Un autre test du même genre (mesure du cout de connexions http persistentes et dormantes en utilisant libevent) : "Resources now jumped to a maximum of 21MB resident (25MB virtual) for 200,000 working connections, but once again the OS was showing ~450MB extra memory used"
                  http://aleccolocco.blogspot.com/2008/10/gazillion-user-comet(...)

                  Un autre exemple spécialement pour toi ;) : la doc de djabberd (en Perl, utilisant epoll) affirme, dans le même ordre (ie. sans détails) que "A recent test had 300k connections in 1GB of RAM". cf. http://www.danga.com/djabberd/#perf

                  Ça donne une idée du coût système des connexions.

                  Reste à savoir le cout des états applicatifs node.js associés, qui dépendent évidement de ce qu'on fait (en terme "métier"/application) avec toutes ces connexions, et c'est ce qui n'est pas indiqué dans le "wow mon node.js tient 100 000 connexions simultanées"... 1KB (largement de quoi stocker un cookie et une position dans une machine à état simple) par connexion coûte dans ces conditions 100 MB au total.

                  > et peut-être du keepalive.

                  Du keepalive HTTP il y en a forcément ; c'est la fonctionnalité HTTP fondamentale sur laquelle repose Comet, et c'est bien pour ça que le "100 000" n'a pas trop de sens, car on ne parle pas de 100k nouvelles connexions + req GET par seconde, il s'agit de 100k connexions établies progressivement sur un laps de temps indéterminé, dormantes, et maintenues au cas où le serveur aurait quelque chose à signaler au client. Cela dit ça doit être cocasse lorsqu'ils mettent à jour l'appli ou redémarrent le serveur, et se reprennent les 100k connexions simultanément d'un seul coup dans la face.

                  Si tu parle du keepalive TCP (SO_KEEPALIVE), ça ne coûte (par défaut sous Linux) rien pendant les 2 premières heures, et ensuite une paire de paquets toutes les 75s (net.ipv4.tcp_keepalive_intvl et net.ipv4.tcp_keepalive_time). Pas trop violent ;)

            • [^] # Re: Les adminsys en redemandent

              Posté par  (site web personnel) . Évalué à 1.

              >> « un milliard de message jusqu'à maintenant » depuis quand ?

              > Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.

              OK pour cette approximation, docn essayons un calcul simple : disons 1 millard de messages en 6 mois.

              Donc 6 x 30 jours x 24 heures x 3600 secondes = beaucoup, que je divise par 1 milliard, puis 1/x = 64... 64 messages par seconde... bof... ;-) bon, OK, ça accélère, mais bon, voilà quoi...

              >> Ça ne fait pas de présence ?

              > Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.

              Lien :

              Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster, qu'ils soient situés sur le même serveur, ou des serveurs distants fédérés (donc trafic local et inter-serveur).

              Le mec change d'état manuellement quand il veut (pas souvent), sinon automatiquement, quand il s'éloigne de sa machine plus de n minutes, quand il rabat son écran et passe en veille, etc.

              Et je ne parle pas des presence probes.

              J'ai peu de stats sur la taille des rosters, mais estimons que Facebook est le pire des cas, et la taille moyenne de la liste de contacts là-bas est de 130 entrées.

              Sachant qu'un user envoie et reçoit de la présence, quoi qu'il fasse, puisque le modèle est en push, mais qu'il ne fait pas forcément de messages, un serveur de présence et d'IM passe donc le plus clair de son temps (et de ses ressources) à router des présences.

              • [^] # Re: Les adminsys en redemandent

                Posté par  (site web personnel) . Évalué à 3.

                > 64 messages par seconde

                Si j'ai bien compris, ces messages sont l'équivalent de tweets. On peut donc imaginer qu'ils sont diffusés à une centaine de followers en moyenne. L'équivalent en IM serait 64 messages/s dans des chans avec une centaine de personnes, ou 6 400 messages directs par secondes.

                > Un mec se connecte, il envoie sa présence, elle est diffusée à tous les items de son roster

                OK, c'est donc relativement semblable à ce que Plurk ou Twitter fait lorsqu'un message normal est posté (ie le transmettre à tous les followers), la gestion des serveurs distants fédérés en moins. Par contre, l'IM a un gros avantage en termes de performance sur les messages normaux : le message va de une personne vers *une* autre personne, ce qui est beaucoup plus efficace à acheminer.

    • [^] # Re: Les adminsys en redemande

      Posté par  (site web personnel) . Évalué à 2.

      Désolé de vouloir contourner le problème numéro uno du web : le côté déconnecté.

      Les sysadmins nous demandent des applis web pour éviter d'avoir à redéployer tout un parc et les users ne veulent perdre aucune feature.

      Je développe un webmail et les utilisateurs ne me demandent plus le bouton refresh depuis que je push les infos sur leur navigateur toutes les 24sec.

      • [^] # Re: Les adminsys en redemande

        Posté par  (site web personnel) . Évalué à 3.

        leur navigateur toutes les 24sec.

        Surtout quand les clients mails natifs font se travail de l'ordre de la minute. Thunderbird, il me semble, c'est toutes les 10 minutes par défaut.
        C'est ça, je crois, qu'il critique. Pourquoi pousser toutes les demi-minutes une donnée qui peut en attendre 10 ? Sachant qu'un mail peut-être retarder pendant plusieurs jours sur les serveurs de mails, il n'y a aucune raison de rafraîchir à cette vitesse.
        Le mail n'est pas de la communication instantanée. C'est juste gaspiller des ressources inutilement. Tous les 24s on fait travailler une infrastructure réseau pour quelque chose qui est nécessaire toutes les 10 minutes.
        Donc un bon vieux "refresh" HTML suffit, mais c'est moins cool.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: Les adminsys en redemande

          Posté par  (site web personnel) . Évalué à 5.

          > Surtout quand les clients mails natifs font se travail de l'ordre de la minute.

          On est en 2010, les personnes qui n'utilisent pas de webmails, ont au moins configuré leur client mail pour utiliser un protocole révolutionnaire appelé IMAP. Et devines quoi ? Dans IMAP, il y a une commande, IDLE, qui permet de dire au serveur « réponds-moi quand tu auras quelque chose à me dire, pas avant » (en gros). Ainsi, les clients mails natifs gardent une connexion ouverte avec le serveur IMAP et sont capable d'afficher un mail dans la seconde où il arrive. Par exemple, ça m'arrive souvent d'envoyer des mails sur des mailing-lists auxquelles je suis abonné et voir le mail arriver quasi-instantanément.

          Pour les détails techniques, je te renvoie à http://www.isode.com/whitepapers/imap-idle.html

          • [^] # Re: Les adminsys en redemande

            Posté par  . Évalué à 2.

            > Dans IMAP, il y a une commande, IDLE

            Un protocole conçu pour ça, précisément, pas Hyper Text Transport "Quand j'ai un marteau tout ressemble à un clou" Protocol ;). Bon je reconnais que j'exagère, il y a surement lieu de s'inspirer du mail pour améliorer le web (y compris, peut-être, l'IDLE d'IMAP). Mais la situation est différente et beaucoup plus facile à gérer pour le mail :

            o C'est éminemment, naturellement shardable / partitionable (à la différence d'une application appuyée sur une base de donnée relationnelle, les mailboxes sont des "data stores" très faciles à dispatcher et répartir). A l'opposé des prérequis pour la construction, par exemple, d'un graphe de réseau social. Voir à ce sujet les réflexions de James Hamilton, par exemple ici : http://perspectives.mvdirona.com/2008/06/08/ScalingLinkedIn.(...)
            Ok, rien à voir avec le sujet de ce thread, mais en écho au thème des nouveaux systèmes de stockage NoSQL.

            o Des questions de volumes et de dimensionnements (prévisibles ou pas). Le trafic (nombre de connexions) d'un serveur IMAP est généralement facile à anticiper, ou du moins suit des évolutions prédictibles; un trafic normalement limitée à l'ensemble des utilisateurs connus et enregistrés. Servis par un applicatif minimal et quasi non bloquant (hormis l'auth, presque de pures I/O). L'applicatif est en même temps directement le serveur de stockage. Naturellement asynchrone. Je ne crois pas qu'il y ai beaucoup d'environnement IMAP dans le monde qui ont l'occasion de recevoir 100 000 connexions simultanées, ni même 10k. Ca n'est pas tout à fait de même nature que les vagues de flux sur une application webtwolol (parfois très soudain, avec 2 à 6 connexions simultanées par clients, des applications faisant généralement des traitements, etc). Et puis, personne n'a encore eu le mauvais gout de distribuer un serveur IMAP en javascript (à ma connaissance) :P

          • [^] # Re: Les adminsys en redemande

            Posté par  (site web personnel) . Évalué à 2.

            Oui exactement, en 2010 les personnes utilisent un protocole révolutionnaire appelé IMAP pour récupérer leur mail. Mais certains ont décidés qu'un protocole totalement inapproprié, comme HTTP, serait plus intéressant et on a vu naître les Webmails.
            Et comme excuse au webmail on a dit "la mobilité". Tu peux toujours y aller depuis n'importe où, sans rien avoir besoin d'installer, sauf qu'en 2010, IMAP on le retrouve bientôt dans les iMontres et les iTire-bouchons tellement qu'il est partout.

            Entre une requête HTTP toutes les 24s et une commande IDLE de IMAP, l'effort est différent.

            Donc oui, utiliser un protocole que tout le monde a dans sa poche et spécialement conçu pour lire les mails, IMAP.
            Non pour utiliser le HTTP pour recevoir les mails.

            Et finalement il pourrait y avoir n'importe quelle commande magique dans IMAP, c'est STMP qui définit l'échange de mail et SMTP est très cool sur le temps. Tellement cool qu'on ralentit même le transfert pour déterminer si c'est du spam ou pas. 24s c'est peut-être le temps que mettra le serveur SMTP à recevoir les entêtes du mail (voir moins).

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Modèle évènementiel

    Posté par  . Évalué à 2.

    Jamais compris pourquoi les nouveaux langages n'ont pas ça de base, comme TCL le fait depuis bien longtemps (fileevent, after, ...). C'est tellement pratique.

  • # précisions diverses

    Posté par  . Évalué à 4.

    rgraph n'est pas opensource

    raphael c'est du SVG et pas du canvas non ?

    le screencast sur vim est payant, ça va mieux en le disant

    et merci pour tout le reste :-)

    • [^] # Re: précisions diverses

      Posté par  (site web personnel) . Évalué à 2.

      > rgraph n'est pas opensource

      Arf, oui, je me suis fait avoir :/

      > raphael c'est du SVG et pas du canvas non ?

      J'étais persuadé que c'était du canvas, mais je viens de vérifier sur le site, c'est bien du SVG. Je corrige la dépêche.

      Merci pour les précisions.

  • # Quel est l'avantage de Node.js par rapport à Twisted ?

    Posté par  (site web personnel) . Évalué à 4.

    J'ai du mal à saisir ... à part peut être le fait de pouvoir coder, dans le même language, en JS, qu'on soit client ou server side ...

    Sinon ?

  • # Y'en a qui se touche royalement...

    Posté par  (site web personnel) . Évalué à 8.

    9$ le screencast de l'utilisation de Vim avec Rails, faut peut être pas exagérer...

  • # Base de données réparties

    Posté par  (site web personnel) . Évalué à 2.

    J'en profite pour savoir si vous connaissez un truc tout bête du genre :

    - stockage de paire clef-valeur

    - redondance sur disons 3 serveurs (ou plus)

    - tolérant aux pannes d'un des trois serveurs

    - rapide et facile d'utilisation

    - utilisable sous Perl et de préférence avec "tie"

    En gros, aujourd'hui, j'ai trois serveurs qui utilisent chacun une base Berkeley indépendante que j'attaque sous Perl. Je voudrais fusionner ces trois bases qui sont identiques dans la forme mais pas tout à fait dans le contenu car cela dépend aujourd'hui des requêtes sur les serveurs mais en gardant une grande tolérance aux pannes de l'un des serveurs.

    Donc en gros, je souhaite avoir trois bases Berkeley qui se synchronise de manière aysnchrone, au mieux... et avoir le moins de code Perl a modifier ;-)

  • # emacs Org-mode

    Posté par  . Évalué à 3.

    Pour ceux que ça interresse et qui comprennent l'anglais, il y a une vidéo intitulé «Emacs Org-mode: a system for note-taking and project planning»
    [http://www.youtube.com/watch?v=oJTwQvgfgMM]

  • # Ou le vilain, il a oublié Symfony 2 :)

    Posté par  . Évalué à 1.

    C'est quoi cette veille techno toute la semaine dernière c'était le Symfony live !

    http://symfony-reloaded.org

    • [^] # Re: Ou le vilain, il a oublié Symfony 2 :)

      Posté par  (site web personnel) . Évalué à 6.

      [troll mode="violent"]
      Comme indiqué dans le titre, je ne m'intéresse qu'aux technos web cools, et Symfony 2 ne rentre définitivement pas dans cette catégorie.

      Déjà, il utilise les namespaces PHP avec des backslashs :
      namespace Bundle\HelloBundle\Controller;
      use Symfony\Framework\WebBundle\Controller;

      Les templates sont moches avec encore des <?php echo $name ?> (je pensais que ça ne se faisait plus depuis au moins 10 ans).

      Les benchmarks qui ont servis à annoncer des performances aussi flateuses n'ont visiblement pas été faits avec la rigueur nécessaire à cet exercice : http://paul-m-jones.com/?p=1222

      Les outils décrits sur http://symfony-reloaded.org/tools doivent être intégrés à Django ou Rails depuis au moins 5 ans.

      Pas un mot sur la sécurité. C'est vrai, c'est un détail pour faire des applications web.

      L'utilisation de bases de données NoSQL ? Hum, rien non plus...

      Sérieusement, il y a un seul truc cool dans tout ça ? Ou c'est juste une reprise en PHP des principes qui ont fait le succès de Django et Rails ?
      [/troll]

      • [^] # Re: Ou le vilain, il a oublié Symfony 2 :)

        Posté par  . Évalué à 5.

        > Les templates sont moches

        Tu utilises le moteur que tu veux.

        > Les outils décrits sur http://symfony-reloaded.org/tools doivent être intégrés à Django ou Rails depuis au moins 5 ans.

        Tout ça est présent dans Symfony 1; et Symfony a été le premier le faire pour une partie d'entre eux.

        > Pas un mot sur la sécurité. C'est vrai, c'est un détail pour faire des applications web.

        Pour les injections SQL, tout passe par Doctrine (ORM), on tape pas de requête à la main, donc pas de problème de ce côté là.

        Pour les injections de javascript, le moteur de rendu par défaut "wrap" toutes les variables de template de façon à les échapper. Pour afficher quelque chose sans l'échapper il faut le faire explicitement.

        Pour les CSRF, il y a ce qu'il faut pour générer des tokens uniques et les vérifier pour les formulaires.

        Etc. Je pense que Symfony est très bien placé de ce côté là.

  • # Seaside et Pharo

    Posté par  (site web personnel) . Évalué à 2.

    je vote pour Seaside et Pharo car:
    - fini les templates
    - prise en charge du workflow, composants réellement réutilisables,
    - vrai debugger
    - coder, modifier, debugger live, sans redémarrer régulièrement le serveur
    - pas besoin de bases pour les applications simples
    - un fichier à copier pour déployer
    - c'est fun

    Seaside: http://seaside.st/
    Pharo: http://pharo-project.org/
    Vidéos: http://pharocasts.blogspot.com/

    • [^] # Re: Seaside et Pharo

      Posté par  (site web personnel) . Évalué à 1.

      On a eu une p'tite conférence en anglais sur Pharo dans mon école d'ingé (pendant les JM2L), je veux bien croire que ce soit fun de programmer avec (haut niveau, on peut faire appel à des fonctions comme en bash de façon assez haut-niveau, et j'ai bien aimé la démonstration de l'IDE qui type les variables à ta place, pour ce que j'ai retenu du côté fun).

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Seaside et Pharo

      Posté par  . Évalué à 1.

      - pas besoin de bases pour les applications simples

      Vu que tu n'as pas donné de lien pour ce point, je propose SandstoneDb. Une API de persistance pour SmallTalk dans le style Active Record mais sans base de donnée :
      http://onsmalltalk.com/sandstonedb-simple-activerecord-style(...)

      L'auteur explique (en anglais) dans cet article pourquoi il a décidé d'écrire ce framework.

      Bon allez je tente un résumé rapide :
      - les bases de données relationnelles sont trop éloignées de l'orienté objet ce qui génère un code plus complexe que nécessaire ;
      - les bases de données objets paraissent une bonne solution, orientée objet et proposant/masquant tout un système complexe pour améliorer les performances de la couche de persistance ;
      - mais une base de donnée nécessite d'ouvrir puis de gérer une connexion à la base, ce qui génère encore une fois beaucoup de code inutile ;
      - dans la majorité des cas les performances ne sont pas un problème car l'application n'aura probablement jamais assez d'utilisateurs/contenu pour dépasser les capacités d'une simple écriture sur le disque de l'objet sérialisé, l'important est d'avoir moins de code à écrire.

      Attention il ne dit pas que c'est la solution universelle, juste que pour un prototype ou pour une petite application métier, les performances seront suffisantes et le coût de développement sera moindre.

      • [^] # Re: Seaside et Pharo

        Posté par  (site web personnel) . Évalué à 1.

        Encore plus simple: utiliser une variable de classe pour stocker les données. C'est alors l'image qui fait la persistence.
        C'est ce que je voulais dire par "pas de bases de données"

        Exemple ici: http://pharocasts.blogspot.com/2010/01/seaside-blog.html

        En base de données objet performante lorsque la taille est supérieure à 100Mo, il y a Magma... et d'autres.

        http://www.seaside.st/documentation/persistence

        • [^] # Re: Seaside et Pharo

          Posté par  . Évalué à 1.

          Oui c'est aussi possible. `

          Mais à mon goût cela mélange trop les données et le code. Ce qui peut compliquer la sauvegarde des données (obligé de sauvegarder toute l'image), la diffusion des données (obligé de diffuser le code en même temps) voire la diffusion du code (si la diffusion se fait par le biais de l'image entière).

          Et je ne suis pas certain que ce soit plus simple au final puisque invariablement on va redévelopper certaines méthodes d'accès/gestion de transaction qui sont déjà là dans SandstoneDb.

  • # vimperator rulez!

    Posté par  . Évalué à 2.

    Pour les aficionados de vim dans le navigateur, il y a aussi Vimperator qui est vraiment très bon et surtout bien mieux que l'équivalent vimium pour Chrome.

    Une fois que l'on a installé cette extension, il est difficile de s'en passer.
    (à réserver pour les fanas de vim œuf corse !)

Suivre le flux des commentaires

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