Popularité des éditeurs de texte sur liborg

[neuneu2k]

oui, j'aurai du dire un système de modélisation des systèmes distribués…

[0100011]

C'est une tendance générale et infinie à empiler les méta-modèles les uns sur les autres. Turtles all the way down.

[neuneu2k]

Tant qu'il n'y a pas de spagettis pour défaire la structure, les lasagnes, c'est bon, mangez en, le défaut des lasagnes, c'est que ça incite a se concentrer sur une seule couche, et qui veut être le spécialiste des champignons ? (question réthorique, malheureusement, ça pousse aux arbres les gens qui sont parfaitement contents de ne rien comprendre sauf a leur petit cm² de lasagne, et juste sur leur étage).

Le défaut des spagettis, c'est que ça crée la pensée magique, on touille et ça marche !

[Malky]

Sinon pour le topic (enfin ce qu'il en reste), j'utilise généralement Scite qui a plein d'avantages et peu d'inconvénients pour moi.

[Noob]

Les modeles statefull classiques ne sont pas assez souples pour gerer de la distribution dans le temps et l'espace, le premier qui colle un moniteur transactionnel a la place de SWIFT parce que "comme ça, on n'a pas a gérer a la main les problèmes de transactions incomplètes on a une garantie de complétude ou de rollback" tue l'économie mondiale en quelques heures, c'est pire qu'une bombe atomique.

Ensuite, moi aussi ça me manque un système de notifs, c'est connu, ce qui manque a REST, c'est l'abonnement a des notifications sur update d'une représentation de ressource, mais c'est non trivial a large échelle (ce n'est pas comme si on savais le faire a relativement faible latence, sans dépenser une fortune dans des solutions ad-hoc en contraignant massivement le format de la représentation, comme les distributeurs de données de marché).

C'est pas ici ou certains parlaient des problèmes du trading à haute fréquence ? Dans le genre casseur de robot, l'usage d'un modèle transactionnel aurait au moins l'avantage d'en satisfaire certain…

Sinon pour les notifications, si j'ai bien compris ton truc c'est que tu voudrais du pub/sub, mais je connais pas du tout ce domaine là, juste des gens qui ont publié quelque truc et je sais pas du tout quel état en est la recherche là dedans.

[neuneu2k]

Sinon pour les notifications, si j'ai bien compris ton truc c'est que tu voudrais du pub/sub, mais je connais pas du tout ce domaine là, juste des gens qui ont publié quelque truc et je sais pas du tout quel état en est la recherche là dedans.

Pub/Sub, c’est la vision bas niveau, l’idéal en restant fidele a l’orthogonalité de REST serait de pouvoir s’abonner a une représentation de ressource.

Si l’état de la ressource change ET que ça un impact sur sa représentation ALORS envoyer un événement (notif de modification avec le nouvel e-tag, diff avec l’e-tag précédent quand le mimetype le permet).

J’ai une ébauche de spec qui permet de le faire sans étendre http/1.1, avec signature numérique de l’événement et diffusion P2P en snowflake, mais bon, le marché a décidé que c’était mieux de mettre des gigantesques datacenters et de passer par twitter/whatever…

[melt_core]

[Rincevent]

Tant qu'il n'y a pas de spagettis pour défaire la structure, les lasagnes, c'est bon, mangez en, le défaut des lasagnes, c'est que ça incite a se concentrer sur une seule couche, et qui veut être le spécialiste des champignons ? (question réthorique, malheureusement, ça pousse aux arbres les gens qui sont parfaitement contents de ne rien comprendre sauf a leur petit cm² de lasagne, et juste sur leur étage).

Le défaut des spagettis, c'est que ça crée la pensée magique, on touille et ça marche !

Les lasagnes ont un autre défaut : les abstractions ne sont pas parfaites (Joel Spolsky inside).

Enfin pour ce que j'ai à en dire, hein… Mon taux de compréhension de la plupart des messages de ce fil est en chute quasi-libre.

[WBell]

Enfin pour ce que j'ai à en dire, hein… Mon taux de compréhension de la plupart des messages de ce fil est en chute quasi-libre.

Comme disait Coluche, après avoir posé la question, et obtenu une réponse, on comprend plus la question .

[jubal]

Mon taux de compréhension de la plupart des messages de ce fil est en chute quasi-libre.

Pareil, je me suis perdu quelque part entre les spaghettis et les lasagnes

[neuneu2k]

Les lasagnes ont un autre défaut : les abstractions ne sont pas parfaites (Joel Spolsky inside).

Une abstraction parfaite, c'est une mauvaise abstraction (trop de compromis a faire avec la réalité), ce qu'il faut c'est de l'abstraction pour 95% des utilisateurs et des usages, et des fuites choisies pour tomber dans le 5% compliqué ou il faudra quelqu'un qui connais au moins l'abstraction du dessous (et des fois, il faut un type qui connais toute la stack, )

[Poil à gratter]

Il n'y a aucun souci a avoir un état conversationnel dans une architecture REST, c'est juste une question de créer une ressource pour la conversation, c'est meme le seul moyen de faire quelque chose de réellement stateful a grande échelle, et de fait, ça date d'il y a bien plus longtemps que REST, tout ce qui est conversationnel et important, ça a un "n° de dossier" qu'on peut réutiliser avec un autre interlocuteur, voir meme entre deux interlocuteurs différents des originaux, pour continuer la conversation.

Les modeles statefull classiques ne sont pas assez souples pour gerer de la distribution dans le temps et l'espace, le premier qui colle un moniteur transactionnel a la place de SWIFT parce que "comme ça, on n'a pas a gérer a la main les problèmes de transactions incomplètes on a une garantie de complétude ou de rollback" tue l'économie mondiale en quelques heures, c'est pire qu'une bombe atomique.

Ca ne change pas le fait que derriere, les machins qui gerent les ressources sont codées avec un paradigme objet et/ou fonctionnel, REST est un modele de modelisation des systemes distribués, pas un modele de programmation, et n'a strictement aucun rapport avec Node.js

Pub/Sub, c’est la vision bas niveau, l’idéal en restant fidele a l’orthogonalité de REST serait de pouvoir s’abonner a une représentation de ressource.

Visiblement tu as plus creusé le sujet que moi. J'ai aucun doute sur le fait qu'on peut faire du stateful / REST, mais ça va à l'encontre des recommandations REST, entre autre parceque ça rend la solution non trivialement load-balancable. Sinon on peut aussi conserver l'état sur le client, mais ça pose plein de problèmes de sécurité. Enfin, ça devrait pas poser de problèmes, si c'est bien fait…mais on m'a rapporté quelques cas d'utilisation assez funs.

Ensuite je ne sais pas trop ce que tu entends par "numéro de dossier", mais ça me fait furieusement penser à ce truc qu'on a inventé pour contourner le côté stateless de HTTP 1.0 : les SESSIONID dans l'URL (ou le cookie). Évidemment on en avait besoin, mais comme beaucoup de choses, ça a finit par être utilisé un peu n'importe comment. En cela je salue RESTful comme un retour aux sources, avec une bonne grosse dose de bon sens: laisser les systèmes de cache faire leur boulot, les load-balancer gérer au mieux les ressources, et mettre le frein sur le clustering côté serveur. Tout ça en utilisant ce qu'on avait déjà sous la main depuis des années.

Mais bon, je vais devoir creuser la question prochainement: le produit sur lequel je travaille va certainement être réécrit en utilisant une architecture RESTful. Mais pour les notifications je pense plus à des trucs comme Comet/Atmosphere. vu que les clients sont des majoritairement browsers (et quand c'est autre chose, les notifications sont pas vraiment utiles). Ça va être amusant.

Une abstraction parfaite, c'est une mauvaise abstraction (trop de compromis a faire avec la réalité), ce qu'il faut c'est de l'abstraction pour 95% des utilisateurs et des usages, et des fuites choisies pour tomber dans le 5% compliqué ou il faudra quelqu'un qui connais au moins l'abstraction du dessous (et des fois, il faut un type qui connais toute la stack, )

Voilà, je ne sais même pas si 95% est réaliste: je serais content avec une solution qui gère 80% des cas d'utilisation. Et les 20% restant qui demandent de "sortir du cadre", ça reste gérable. Sinon, très bon blog, j'aime bien aussi celui-ci: http://mechanitis.blogspot.nl/

[jubal]

Dans les shell windows, quelqu'un utilise 4NT au fait ? Ca donne quoi ?

[pankkake]

J'utilisais 4DOS il y a plus de 10 ans. C'était pas mal.

Ça existe encore ?

[jubal]

J'utilisais 4DOS il y a plus de 10 ans. C'était pas mal.

Ça existe encore ?

Apparemment. Quand j'ai demande a un ami qui bosse sur windows quel shell il utilisait, il m'a répondu 4NT.

Je ne répèterais pas ici son avis sur powershell, afin de ne pas réveiller le troll qui dors en chacun de nous

[neuneu2k]

Visiblement tu as plus creusé le sujet que moi. J'ai aucun doute sur le fait qu'on peut faire du stateful / REST, mais ça va à l'encontre des recommandations REST, entre autre parceque ça rend la solution non trivialement load-balancable. Sinon on peut aussi conserver l'état sur le client, mais ça pose plein de problèmes de sécurité. Enfin, ça devrait pas poser de problèmes, si c'est bien fait…mais on m'a rapporté quelques cas d'utilisation assez funs.

Ensuite je ne sais pas trop ce que tu entends par "numéro de dossier", mais ça me fait furieusement penser à ce truc qu'on a inventé pour contourner le côté stateless de HTTP 1.0 : les SESSIONID dans l'URL (ou le cookie). Évidemment on en avait besoin, mais comme beaucoup de choses, ça a finit par être utilisé un peu n'importe comment. En cela je salue RESTful comme un retour aux sources, avec une bonne grosse dose de bon sens: laisser les systèmes de cache faire leur boulot, les load-balancer gérer au mieux les ressources, et mettre le frein sur le clustering côté serveur. Tout ça en utilisant ce qu'on avait déjà sous la main depuis des années.

Mais bon, je vais devoir creuser la question prochainement: le produit sur lequel je travaille va certainement être réécrit en utilisant une architecture RESTful. Mais pour les notifications je pense plus à des trucs comme Comet/Atmosphere. vu que les clients sont des majoritairement browsers (et quand c'est autre chose, les notifications sont pas vraiment utiles). Ça va être amusant.

L'idée n'est pas d'être totalement stateless, c'est de ne pas ajouter d'état "technique", et pour tout ce qui est fonctionnel, de 'matérialiser' l'état dans une ressource et ses représentations.

Le problème des sessions, c'est que c'est un état purement technique, ça ne représente rien, par contre, prenons comme exemple un site marchand avec un panier, la solution « traditionnelle » c’est la session, la réponse REST naïve, c’est de le mettre dans le client, ce qui a le même comportement, et les mêmes défauts (persistance du panier peu solide, faible possibilité d’analyse du comportement du client avec son panier, mise en place de listes de courses bricolées).

La solution REST efficace, c’est d’accepter que le panier, tout comme le client c’est un objet métier, pas un truc technique, et tout simplement de lui donner une adresse, opaque du point de vue technique, mais évidemment (on n’est pas des bêtes) avec un sens humain : du genre

http:// www.example.com/users/neuneu2k/lists/42

C’est bien un état, on peut transférer ses représentations, et comme on a décidé que ça avait un sens fonctionnel, il est naturel de le persister (et évidemment, c’est pas automagiquement scalable, faut pas rêver )

Quand a la notif, « comet » (il y a deux termes qui m’horripilent, c’est « comet » et « ajax », Microsoft a inventé et appliqué XHR bien avant qu’on ne colle un nom de lessive, et je n’ai pas retrouvé l’origine du push-pull, mais je sais que je le faisais en 2001 et que je l’avais piqué a quelqu’un…) viole REST par presque tous les trous dans son usage quotidien, ce qui se corrige en l’utilisant correctement, et est peu scalable (ce qui ne se corrige pas trivialement, mais bon, dans le monde de youteube et des machines a 40 cœurs et 10Gb accessibles, finalement, la surconsommation en bande passante par rapport à un système distribué et la scalabilité de comet/SSE/websockets, tout le monde s’en tape un peu )

[jubal]

Est ce que les concepts comme "REST" ou "comet" servent vraiment a quelque chose ?

Pourquoi dire "comet" ou "REST" qui restent assez vague plutôt que de dire ce qu'on veut faire ?

[neuneu2k]

REST est devenu un bullshit word, mais derrière il y a une vraie théorie, si seulement tous ceux qui utilisent le terme lisaient au moins la thèse de fielding, on serait plus avancé.

Comet, c'est juste un mot court pour décrire une technique plus ancienne qui n'avais pas de nom, en soi, c'est bien de nommer les choses, le problème c'est quand ça crée de la pensée magique (j'utilise le mot magique, donc j'ai gagné !)

J'apellais ça push-pull, c'était moche et les gens pigaient pas et le savaient, donc ils avaient peur, maintenant, ça s'apelle Comet, les gens pigent pas et ne le savent pas parce que ça a un nom, donc ils s'en servent.

@Poney: j'invoque en ces lieux un antropologue pour expliquer le pourquoi du comment

[jubal]

J'ai pas lu la thèse de fielding.

Je dois justement faire l’architecture réseau d'un software aujourd'hui, je devrais la lire ?

[neuneu2k]

Ca fait jamais de mal, mais je déconseille l’application immédiate sans au moins une bonne année de « comment je prendrais ce problème si je voulais faire une modélisation orientée ressource » sur des cas que finalement tu traites avec des techniques que tu maîtrise.

Comme tout ce qui est un peu révolutionnaire (tout en étant à 80% du bon sens), il vaut mieux y aller avec précaution et sans le zèle du nouveau converti !

[Poil à gratter]

Ouais enfin Comet et Ajax sont devenus certes des BS words, mais on avait quand même besoin d'avoir un terme pour designer ces techniques. Surtout qu'en fait ça désigne plutôt un ensemble de techniques différentes utilisées conjointement.

Par exemple Ajax, il y a bien la XHR, mais c'est juste une partie de l'idée: en général on va aussi faire de la manipulation DOM (DHTML, pour faire plaisir à neuneu2k), de plus en plus on utilise JSON plutôt que XML pour transférer les données, et quelques autres trucs que j'oublie et qui font partie du paquet de lessive Ajax.

L'idée n'est pas d'être totalement stateless, c'est de ne pas ajouter d'état "technique", et pour tout ce qui est fonctionnel, de 'matérialiser' l'état dans une ressource et ses représentations.

Autant pour un panier ça doit sans doute très bien fonctionner, autant pour ce qui est authentification, mais surtout autorisation, j'ai déjà un peu plus de mal à voir comment on va se dépatouiller avec tout ça. Mais sinon pour les notifications on n'a pas des gros besoins: on doit avoir comme objectif de supporter un truc comme 100 utilisateurs simultanés sur l'application.

[neuneu2k]

Je n'ai rien contre l'usage d'un cookie pour l'auth, tant qu'il n'est pas associé a une session serveur (il peut etre autoporteur, salt, ip, user, timestamp, signature numérique, et roule ma poule).

[neuneu2k]

Quand a l'authorisation, c'est clairement du domaine métier "interne" qu'on n'expose pas comme une ressource visible, on en expose les effets, mais pas forcément une représentation.

Sauf pour une appli de gestion des matrices de droits/acl/whatever, auquel cas on est en présence d'une appli assez simple, qui n'a pas vocation a scaler significativement, sur laquelle une reflection sur l'intégration dans un SI, local ou mondial, ne se pose pas des masses, auquel cas, OSEF de REST, les applis "jetables" (au sens ou elles n'ont pas vocation a l'intégration ou a la croissance fonctionnelle), ça existe, et c'est pas grave

[pankkake]

Je n'ai rien contre l'usage d'un cookie pour l'auth, tant qu'il n'est pas associé a une session serveur (il peut etre autoporteur, salt, ip, user, timestamp, signature numérique, et roule ma poule).

C'est ce que proposait HTTP AUTH.

Mais son implémentation dans les navigateurs est très mal faite niveau interface (par exemple, on ne peut même pas faire de logout, et on est accueilli par la boîte de dialogue, on a pas de mode anonyme par défaut).

Je n'ai pas compris comment fonctionne BrowserID de Mozilla, mais j'espère que ça répond à cette problématique.

Mais dans une API, il n'y a aucune raison de ne pas l'utiliser, plutôt que ces conneries d'OAuth implémentées par des hipsters.

[Poil à gratter]

Il y a des moyens de contrôler un peu l'auth HTTP en bidouillant avec la configuration du serveur (en trifouillant les headers et en faisant du redirect), mais ça reste moche, complètement dépendant de l'implémentation du browser, et il n'y a effectivement pas moyen d'implémenter un logout propre (en gros il faut redemander une auth au browser et attendre que le client clique sur Esc pour que le browser oublie les credentials). Ceci dit avec les Inprivate/Incognito, c'est possible d'avoir une forme de logout en utilisant HTTP AUTH :-)

Mais OAuth c'est quand même utilisé par Google et Microsoft: donc à moins d'utiliser une implémentation en Ruby faite par des hipsters, j'aurais tendance à penser que le protocole est plutôt sécurisé. BrowserID à l'air bien, mais à le gros défaut de ne fonctionner que avec Firefox…

[pankkake]

Il y a des moyens de contrôler un peu l'auth HTTP en bidouillant avec la configuration du serveur (en trifouillant les headers et en faisant du redirect), mais ça reste moche, complètement dépendant de l'implémentation du browser, et il n'y a effectivement pas moyen d'implémenter un logout propre (en gros il faut redemander une auth au browser et attendre que le client clique sur Esc pour que le browser oublie les credentials).

Même ça j'ai fini par malheureusement abandonner, c'était vraiment incompréhensible pour un utilisateur normal. J'ai quand même laissé le support le l'HTTP AUTH dans mon projet, mais il faut le demander explicitement (!). Ça laisse l'utilisation des API possibles facilement sans cookies, ceci dit.

Mais OAuth c'est quand même utilisé par Google et Microsoft: donc à moins d'utiliser une implémentation en Ruby faite par des hipsters, j'aurais tendance à penser que le protocole est plutôt sécurisé.

Ils utilisent la version 2.0 pas encore finalisée. Sur la version 1.0, des failles de sécurité ont été trouvées dans le protocole !

BrowserID à l'air bien, mais à le gros défaut de ne fonctionner que avec Firefox…

À ce que j'ai compris non, même si c'est mieux quand c'est supporté au niveau du navigateur. Mais j'ai toujours pas compris ce que c'était techniquement

[Nirvana]

La bêta de Sublime Text 3 arrive : http://www.sublimetext.com/blog/articles/sublime-text-3-beta

[pankkake]

Un éditeur inutile et hipster.

[neuneu2k]

ST2 n'est pas mal du tout, c'est une resucée plus moderne de gvim qui tiens la route.

Bon, ensuite, moi un éditeur de texte, j'ai deux use cases:

-la rache en prod: vim, vi si y'a pas vim, ed si y'a pas vi (et oui, j'ai utilisé ed de façon interactive, une fois...)

-developpement: IDEA Ultimate

[pankkake]

Moi je veux un éditeur de texte ergonomique. Bon, de plus en plus d'éditeurs ont un "mode vi" mais quand ce n'est pas la première fonctionnalité, je me méfie.