HTML5, avec notamment Canvas, permet de plus en plus de se passer de Flash sur les sites web. Voici la preuve en quelques liens :
- Cette très bonne présentation explique comment se passer de Flash avec HTML5, CSS3, JS, Canvas et WebGL ;
- Cette bibliothèque permet notamment de faire des diagrammes de Gantt (attention, la licence n'est pas libre) ;
- gRaphael permet de tracer facilement des graphiques avec SVG grâce à la bibliothèque Raphael ;
- Canviz permet de tracer des graphes au format graphviz en utilisant Canvas ;
- Paul Rouget nous donne nouvelle fois envie avec des démonstrations impressionnantes.
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.
- Plurk : Instant conversations using Comet : Plurk utilise node.js pour leur chat, avec plus de 100 000 utilisateurs simultanés ;
- Cet exemple d'utilisation de Node.js montre comment suivre la présence en ligne d'utilisateurs ;
- Le Blog Howto Node est une très bonne source d'informations sur Node.js ;
- Cette collection de modules pour Node.js me semble relativement exhaustive
- xmpp.js : bibliothèque très proche de Strophe, qui permet d'écrire des composants XMPP/Jabber.
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 :
- Ce billet explique pourquoi vous devriez essayer MongoDB ;
- Il est possible de tester MongoDB sans l'installer grâce à cette interface en ligne ;
- Ce retour d'expérience illustre plus concrètement les avantages de MongoDB ;
- Mongo Tips est un blog avec des astuces pour MongoDB ;
- Ces billets sur MongoMapper sont du même auteur et tout aussi intéressants ;
- MongoEngine est un Document-Object Mapper pour Django ;
- Sleepy.Mongoose est une interface REST pour MongoDB ;
- Depuis la version 1.4, MongoDB est capable de créer d'indexer en tâche de fond (chose que MySQL ne sait toujours pas faire, par exemple).
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 :
- Cette archive, NoSQL Database, essaye de refléter de manière assez exhaustive tout ce qui se passe dans le monde NoSQL ;
- Ce site en français est dédié à CouchDB ;
- Ce retour d'expérience sur l'utilisation de Redis semble particulièrement encourageant pour Redis ;
- Cette collection de liens regroupe différents cas d'usages de Redis ;
- Cet article parle des bases NoSQL de types « graphs » ;
- Cet article sur Riak avance de bons arguments en faveur de son utilisation sur des projets Rails.
Vim & Emacs
Je n'ai pas pu m'empêcher de lancer un petit troll Vim/Emacs en quelques liens :
- Ce screencast explique comment utiliser Vim pour coder des applications Rails ;
- Vimium est une extension Chrome pour avoir des raccourcis claviers à la manière de Vim ;
- Ce tutoriel explique comment utiliser le org-mode d'emacs pour la méthode Getting Things Done (GTD).
Autres
Pour finir, j'ai regroupé des liens qui ne rentraient dans aucune des catégories précédentes :
- Ruby on Rails 3 est enfin disponible en version bêta ;
- Cette convention pour les événements JSON semble bien pratique ;
- Cette méthode pour tester l'utilisabilité est originale, mais je ne serais pas surpris qu'elle soit très efficace ;
- Github fait preuve d'agilité extrême : chacun travaille sur ce qui l'intéresse le plus (et ça a l'air de bien fonctionner) ;
- Cette collection de méthodes de refactoring est une vraie mine d'or pour ceux qui veulent nettoyer leur code ;
- Ce billet vous fera découvrir les webhooks.
Aller plus loin
- Précédente news : Veille technologique sur le web (12 clics)
- Compte delicious avec des liens en vrac (5 clics)
- Devblog af83 (3 clics)
# HTML5 & Canvas
Posté par Paul Rouget . Évalué à 7.
[^] # Re: HTML5 & Canvas
Posté par ✅ ffx . Évalué à 8.
I Can't Believe It's Not Flash (Flash Player 9 (or above) is needed to view presentations.)
Euh... ben c'est du flash finalement...
[^] # Re: HTML5 & Canvas
Posté par Paul Rouget . Évalué à 3.
En fait, il faudrait un équivalent slideshare en HTML/CSS.
[^] # Re: HTML5 & Canvas
Posté par dragoonway . Évalué à 2.
- S5 : http://meyerweb.com/eric/tools/s5/
- Slidy : http://www.w3.org/Talks/Tools/Slidy/
- W3C slidemaker : http://www.w3.org/Talks/slidemaker/YYMMsub/
j'ai une préférence pour S5, mais chacun d'entre eux rempli son office.
[^] # Re: HTML5 & Canvas
Posté par Xavier Bestel (site web personnel) . Évalué à 3.
Perso j'utilise Flot - http://code.google.com/p/flot/ qui est libre et qui envoie du bois.
[^] # Re: HTML5 & Canvas
Posté par jcs (site web personnel) . Évalué à 2.
http://jschessboard.googlecode.com/
# GWT
Posté par Philippe Voncken (site web personnel) . Évalué à 0.
http://code.google.com/intl/fr-FR/webtoolkit/
[^] # Re: GWT
Posté par Jean-Max Reymond (site web personnel) . Évalué à 5.
[^] # Re: GWT
Posté par Philippe Voncken (site web personnel) . Évalué à 9.
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 RB . Évalué à 1.
[^] # Re: GWT
Posté par Philippe Voncken (site web personnel) . Évalué à 1.
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 RB . Évalué à 1.
[^] # Re: GWT
Posté par Mat (site web personnel) . Évalué à 1.
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 grenlibre . Évalué à 2.
http://www.playframework.org/
[^] # Re: GWT
Posté par Thomas Cataldo (site web personnel) . Évalué à 4.
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 whity . Évalué à 1.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# 2
Posté par fcartegnie . É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 Bruno Michel (site web personnel) . Évalué à 7.
Ç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 herodiade . Évalué à 10.
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 defmonkey . Évalué à 4.
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 Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Les adminsys en redemandent
Posté par Nÿco (site web personnel) . Évalué à 2.
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 Bruno Michel (site web personnel) . Évalué à 4.
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 herodiade . Évalué à 3.
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 Nÿco (site web personnel) . Évalué à 1.
[^] # Re: Les adminsys en redemandent
Posté par herodiade . Évalué à 3.
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 Nÿco (site web personnel) . Évalué à 1.
> 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 Bruno Michel (site web personnel) . Évalué à 3.
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 Thomas Cataldo (site web personnel) . Évalué à 2.
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 Etienne Bagnoud (site web personnel) . Évalué à 3.
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 Bruno Michel (site web personnel) . Évalué à 5.
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 herodiade . Évalué à 2.
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 Etienne Bagnoud (site web personnel) . Évalué à 2.
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 defmonkey . Évalué à 2.
# précisions diverses
Posté par Dreammm . Évalué à 4.
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 Bruno Michel (site web personnel) . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 4.
Sinon ?
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . Évalué à 7.
Passque c'est cooool, on t'a dit !
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Source : http://amix.dk/blog/post/19456
http://nodejs.org/#about explique également que Node.js intègre le modèle événementiel au cœur du langage, et pas simplement comme une bibliothèque. Cela a des conséquences comme le peut voir comme des avantages. Par exemple, il est quasiment impossible de faire un appel système bloquant.
Mais ce qui m'a vraiment convaincu de la pertinence de Node.js, c'est la présentation de Ryan Dahl (l'auteur de Node.js) à la jsconf : http://jsconf.eu/2009/video_nodejs_by_ryan_dahl.html
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par manatlan (site web personnel) . Évalué à 5.
"Both are relatively fast—use them if you can. "utf8" is slower and should be avoided when possible." http://nodejs.org/api.html
chouette, on va a nouveau avoir plein de problèmes d'encodings franco-français avec des sites développés par des ricains ;-)
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Jul (site web personnel) . Évalué à 2.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
* http://groups.google.com/group/nodejs/browse_thread/thread/d(...)
* http://groups.google.com/group/nodejs/browse_thread/thread/c(...)
* http://groups.google.com/group/nodejs/browse_thread/thread/6(...)
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Nÿco (site web personnel) . Évalué à 2.
Mais bon, même si je suis d'accord qu'on peut avoir un format de données moins verbeux et plus optimal pour les humains et/ou les machines, j'attends encore de voire des propositions, et mieux, des implémentations... avec des Real-World benchmarks derrière !
Parceque bon, selon les technos et la maturté, les implémentations serveurs (pas seulement XMPP) sont très-très variables en terme de perfs...
Non, le format de données ne fait pas tout.
Par exemple, le JSON emporte tous les suffrages en ce moment, mais bon, ça a bien du mal à mapper les namespaces XML dont on se sert massivement sur XMPP.
Donc bon, voilà quoi.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Maintenant, Node.js se veut une plateforme plus généraliste. Par exemple, il existe des modules Node.js pour un paquet de bases de données SQL, et je suppose que pour communiquer avec certaines de ces bases, l'encodage utilisé puisse être de l'UTF-16.
Mais pour être franc, je préfèrerais quand même que Node.js utilise de l'UTF-8 en interne ;-)
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Jul (site web personnel) . Évalué à 1.
langues asiates, occidentales, hébreu, arabe ....
au dessus on a quoi ?
klingon, elfique ....
Le problème d'utf-8 : sur une chaîne de 10444 caractères donne moi le 10300éme caractère ?
il faut que tu parses ta chaîne pour savoir si les octets représente un caractère ou une continuité de car ... bref, casse couille et lourdingue.
Si on fait l'impasse du klingon, 1300é caractère en unicode 16 c'est *char + 1300 * 2
largement moins gourmand en CPU pour un problème simple.
Le monde actuel (du web notamment) est un monde de string (et dire que des filles portent encore des sloggy), donc ce genre de questions triviales sont courantes. C'est moi ou l'utf-8 est un gouffre de ressources inutiles ?
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par scls19fr (site web personnel) . Évalué à -2.
http://fr.wikipedia.org/wiki/YAML
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par manatlan (site web personnel) . Évalué à 0.
pk c'est vraiment la première fois que je vois un "framework" demandé d'éviter utf8 ... de nos jours, ça fait tâche
# Y'en a qui se touche royalement...
Posté par hugo (site web personnel) . Évalué à 8.
[^] # Re: Y'en a qui se touche royalement...
Posté par PiT (site web personnel) . Évalué à 2.
[^] # Re: Y'en a qui se touche royalement...
Posté par hugo (site web personnel) . Évalué à 2.
# Base de données réparties
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
- 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 ;-)
[^] # Re: Base de données réparties
Posté par herodiade . Évalué à 5.
Tu sais que BerkeleyDB supporte nativement la replication (single master, ok)?
Pour rétablir toute sa coulitude, on se doit d'indiquer qu'il réplique avec "Automatic failover/re-election", qu'il utilise pour ça un "Paxos-compliant election algorithm", et sait faire du "Hot standby", et permet les "Non-stop upgrades" et qu'il a une "Proven scalability to thousands of replica nodes".
Si si,
http://www.oracle.com/technology/products/berkeley-db/db/ind(...)
[^] # Re: Base de données réparties
Posté par Yves Agostini (site web personnel) . Évalué à 2.
http://syncwith.us/
[^] # Re: Base de données réparties
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
# emacs Org-mode
Posté par fabricius . Évalué à 3.
[http://www.youtube.com/watch?v=oJTwQvgfgMM]
# Ou le vilain, il a oublié Symfony 2 :)
Posté par goofy . Évalué à 1.
http://symfony-reloaded.org
[^] # Re: Ou le vilain, il a oublié Symfony 2 :)
Posté par Bruno Michel (site web personnel) . Évalué à 6.
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 __o . Évalué à 5.
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 laurent laffont (site web personnel) . Évalué à 2.
- 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 Zarmakuizz (site web personnel) . Évalué à 1.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Seaside et Pharo
Posté par ... a little wood elfe . Évalué à 1.
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 ;
- 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 laurent laffont (site web personnel) . Évalué à 1.
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 ... a little wood elfe . Évalué à 1.
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 Cyril Chaboisseau (Mastodon) . Évalué à 2.
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.