Le fil des geeks informatiques

[Poil à gratter]

Tiens je viens de découvrir une extension bien chouette pour ceux qui utilisent des webmails ou Google groups et qui écrivent des mails contenant du code: Markdown here

 

https://github.com/adam-p/markdown-here

 

C'est juste génial de simplicité: fini de se battre avec l'éditeur rich-text tout pourri de GMail. On écrit du markup, on clique sur toggle et ça rend du HTML joliment formaté.

 

J'ai juste un regret: ça ne marche pas dans Google docs

[Poil à gratter]

http://www.playframework.com/

 

C'est celui utilisé par linkedin et the guardian, par exemple. Interopérable java/scala mais il est clairement orienté scala depuis qqs temps.

 

Ha bin je ne te remercie pas, Malky !

 

J'ai testé Play! 2.2.0 avec Scala 2.10.2, en installant leur nouveau packaging: Typesafe Activator. Oh bon sang, qu'est-ce que c'est lourd, à part peut-être Websphere j'ai jamais rien vu d'aussi lourd. Bon, je vous passe les détails, à la fin je suis resté bloqué par ça: https://github.com/playframework/playframework/pull/1729#issuecomment-26031084

Donc j'ai plus qu'à tester la 2.2.1 (ou pas)

 

Mais finalement je poste plus pour dire que je vais pouvoir tirer quelque chose de l'expérience: en fait je suis en train de travailler sur un projet qui ressemble comme 2 gouttes d'eau à Activator (une application Angular.js qui génère un squelette d'application) et j'ai vu de très bonnes idées à piocher.

[neuneu2k]

J'aime bcp Play 2.0, je l'aime tellement que je ne l'utilise pas pour des raisons propres et que je travaille sur un truc perso qui y ressemble, si par hasard çà interesse quelqu'un c'est en open source, mais pas documenté, parce que la documentation c'est un aveu d'échec

 

Ce que je reproche à Play, comme à beaucoups de machins en scala, c'est sbt, sbt est une horreur sans nom, il n'apporte fonctionnelement rien à maven 3.0 tout en étant totalement imbitable.

 

Ca et l'idée à la mode selon laquelle un serveur doit etre uniquement asynchrone à la node.js au lieu d'etre multi-paradigme, les perfs "papier" à plus de 100k requetes/seconde c'est gentil, mais ça ne corresponds pas aux usages réels en dehors de l'éternel serveur de chat mono-noeud sans intelligence qui est devenu le hello world de l'asynchrone...

 

Pour ma part, je me contenterai de 20k req/secondes avec un modele plus universel...

 

[Jesrad]

Toi, tu ne gères pas une messagerie internationale de bientôt 500 000 utilisateurs...

[neuneu2k]

Toi, tu ne gères pas une messagerie internationale de bientôt 500 000 utilisateurs...

 

A ce niveau, il est de toute façon nécéssaire de séparer les fonctions, donc oui, les noeuds "real time", ça se fait en pur asynchrone, avec du routage d'interrupts sur des cores fixes, et on peut tout à fait passer les 500k req/sec sur de l'infra spécialisée, mais je n'utiliserai jamais cette infra spécialisée pour faire tout le site

 

De façon générale, j'observe souvent des gens qui collent des serveurs asynchrones de ouf derriere un nginx cloudflare ou pire, un lolvarnish, j'aime bien varnish, mais personne n'a jamais réussi à passer les 10k/s dessus

 

Evidemment, y'a toujours des cas spécifiques ou un moteur spécifique est meilleur q'un généraliste multi-paradigme, ce que je dénonce ce n'est pas le fait que les gens aient réalisé les possibilités de travailler en pur evenementiel, c'est que c'est un trend à la con.

 

[Poil à gratter]

Ah bin chacun sa croix  Moi c'est l'héritage servlets...

 

@Neuneu2k: vas-y balance, je suis en train d'évaluer des trucs pour mes délires perso, et qui sait peut-être un jour appliquer ça au travail. Aujourd'hui je vais mettre les mains dans Vert.x, sur le papier c'est vraiment chouette: multi-langage et avec un concept de workers pour le code bloquant. Et toute autre proposition est la bienvenue

 

Et 100% d'accord sur les benchmarks ridicules (200k JSON serialization...), l'horreur de SBT, et le tout asynchrone à la Node.js qui sert à pas grand chose.

 

En fait si je continue sur la métaphore du "Magpie developer", hier soir avec  Play 2, j'avais l'impression d'être tombé sur le nid rempli des trucs brillants. C'est un gros empilage de tous les trucs cools du moment, et l'install à téléchargé la moitié d'internet pour les dépendances. Problème: c'est tellement bleeding edge que ça marche pas...

[Jesrad]

A ce niveau, il est de toute façon nécéssaire de séparer les fonctions, donc oui, les noeuds "real time", ça se fait en pur asynchrone, avec du routage d'interrupts sur des cores fixes, et on peut tout à fait passer les 500k req/sec sur de l'infra spécialisée, mais je n'utiliserai jamais cette infra spécialisée pour faire tout le site

 

De façon générale, j'observe souvent des gens qui collent des serveurs asynchrones de ouf derriere un nginx cloudflare ou pire, un lolvarnish, j'aime bien varnish, mais personne n'a jamais réussi à passer les 10k/s dessus

 

Evidemment, y'a toujours des cas spécifiques ou un moteur spécifique est meilleur q'un généraliste multi-paradigme, ce que je dénonce ce n'est pas le fait que les gens aient réalisé les possibilités de travailler en pur evenementiel, c'est que c'est un trend à la con.

De fait, je me souviens avoir lu qu'un 'simple' postgreSQL avec un wrapper JSON ou custom est deux fois plus performant qu'une DB nosql dédiée...

[ModernGuy]

Quand Microsoft a sorti WinXP, certains grands comptes qui étaient sous contrat de licence avec MS utilisaient certaines machines assez puissantes mais dépourvues de lecteur CD. Microsoft leur a livré une version sur... un peu plus de 250 disquettes 3"1/2.

http://superuser.com/questions/52038/what-was-the-highest-number-of-floppy-disks-ever-used-for-a-product

Noundidiou le stagiaire qui a inséré 250+ disquettes pour installer le système, comment il a du se faire chier !

Dans mon souvenir étant donné la fréquence des erreurs irrécupérables des erreurs I/O sur ces périphériques il me paraît statistiquement très improbable de réussir une install en entier... (déjà un soft sur 10 -15 diskettes il y avait 50% de chance pour qu'il y en ait une d'illisible dans le tas)

[Malky]

Dans mon souvenir étant donné la fréquence des erreurs irrécupérables des erreurs I/O sur ces périphériques il me paraît statistiquement très improbable de réussir une install en entier... (déjà un soft sur 10 -15 diskettes il y avait 50% de chance pour qu'il y en ait une d'illisible dans le tas)

 

On ne doit pas avoir les mêmes souvenirs, ou alors tu insérais les disquettes au marteau C'était pas top fiable mais quand même pas à ce point là.

[neuneu2k]

De fait, je me souviens avoir lu qu'un 'simple' postgreSQL avec un wrapper JSON ou custom est deux fois plus performant qu'une DB nosql dédiée...

 

Ca ne m'étonne pas, les gens collent du noSQL pour un oui pour un non, alors que ça n'a réellement une valeur ajoutée forte que pour des volumes très elevés (à la fois en IO et en taille de la base).

[jubal]

Ca ne m'étonne pas, les gens collent du noSQL pour un oui pour un non, alors que ça n'a réellement une valeur ajoutée forte que pour des volumes très elevés (à la fois en IO et en taille de la base).

Les gens collent surtout du SQL pour un oui ou pour un non, alors que ça n'a de valeur ajoutée que quand on a besoin de requêtes SQL complexes.

[Rincevent]

Les gens collent du SQL pour un oui pour un non, parce que l'accès aux données est un domaine à la fois enclin aux bugs, enclin aux pertes de performances à cause d'algorithmes trop naïfs, et relativement orthogonal aux traitements à proprement parler, et qu'il est donc un bon candidat à l'externalisation "as a service".

Utiliser du SQL, c'est une preuve d'humilité, un peu comme utiliser un langage à ramasse-miettes. Mais comme toute bonne chose, on peut bien ou mal l'utiliser.

[ModernGuy]

On ne doit pas avoir les mêmes souvenirs, ou alors tu insérais les disquettes au marteau C'était pas top fiable mais quand même pas à ce point là.

Ouais je noircis un peu le tableau mais sur 200 disquettes (lol "disquette", un mot qui sent bien l'académie française tiens...) la probabilité d'une défaillance est quand même assez élevée. Bref...

Sinon, je suis à la recherche d'un IDE C++ assez leger avec quelques librairies graphiques et surtout un modelisateur UML fonctionnel pour un projet perso, quelqu'un aurait un tuyau ?

[jubal]

Les gens collent du SQL pour un oui pour un non, parce que l'accès aux données est un domaine à la fois enclin aux bugs, enclin aux pertes de performances à cause d'algorithmes trop naïfs, et relativement orthogonal aux traitements à proprement parler, et qu'il est donc un bon candidat à l'externalisation "as a service".

Ben oui mais pour ça le noSQL ça marche aussi, et c'est plus simple a utiliser.

[Sloonz]

Ca ne m'étonne pas, les gens collent du noSQL pour un oui pour un non, alors que ça n'a réellement une valeur ajoutée forte que pour des volumes très elevés (à la fois en IO et en taille de la base).

Le jour ou un SGBDR m’offrira un truc aussi simple que http://guide.couchdb.org/draft/notifications.html j’envisagerai de remplacer CouchDB par du bon vieux SQL…

[Rincevent]

Ben oui mais pour ça le noSQL ça marche aussi, et c'est plus simple a utiliser.

Ca dépend. Parfois le relationnel marche mieux, parfois le non-relationnel. Parfois le non-relationnel est plus simple, et parfois c'est le relationnel. Le gros avantage du relationnel, c'est qu'un tas de gens baragouinent le langage, et que l'essentiel en est partagé entre les différentes implémentations.

Et puis si tu veux pouvoir faire du relationnel, puis utiliser des gros fichiers plats bien crades à côté, tu fais comme tout le monde, et tu prends un iSeries. Personne n'en est fier, personne ne se souvient même en avoir acheté, et pourtant presque tout le monde en a. Presque tout le monde, vraiment.

[Poil à gratter]

De toutes façons c'est un débat d'arrière garde NoSQL/SQL: les moteurs de base de données SQL sont en train d'intégrer des fonctionnalités qui n'étaient disponibles que dans les moteurs NoSQL. Comme memory tables, big tables, sharding. key-value. Il ne manque plus que les graphes, ou alors je suis passé à côté.

 

Le marché, c'est magique

[Rincevent]

Il n'y a jamais eu de débat dans l'esprit des gens qui savaient ce qu'ils racontaient. Les deux sont très bien, et répondent à des problèmes différents. Il n'y a pas une unique solution qui soit idéale, ni même optimale dans tous les cas et pour tous les usages. Croire le contraire, c'est montrer son hubris, son mépris des problèmes concrets et son caractère de tyran en puissance.

J'ai dit.

[Poil à gratter]

Tout à fait, mais la magie c'est que désormais on n'a pas forcément besoin de choisir dès le début de la conception

Et c'est un bon principe de conception logicielle.

[L'affreux]

Le relationnel apporte aussi une garantie sur l'intégrité des transactions. Le NoSQL n'est pas standardisé alors pour chaque outil il faut re-vérifier. Le NoSQL est même fait pour tolérer des états non intègres, l'objectif étant certes d'en réduire le nombre mais le monde relationnel n'a pas cette tolérance. Alors pour stocker des commentaires Facebook pourquoi pas. Stocker une compta en NoSQL n'est pas une bonne idée.

[Rincevent]

Le relationnel apporte aussi une garantie sur l'intégrité des transactions. Le NoSQL n'est pas standardisé alors pour chaque outil il faut re-vérifier. Le NoSQL est même fait pour tolérer des états non intègres, l'objectif étant certes d'en réduire le nombre mais le monde relationnel n'a pas cette tolérance. Alors pour stocker des commentaires Facebook pourquoi pas. Stocker une compta en NoSQL n'est pas une bonne idée.

Pile ce que je dis, avec plus de détails que je n'en ai exposé. Merci.

[neuneu2k]

Voila, dans l'idéal, on utilise le bon outil pour le bon job, mais comme dans la majorité des applis, on a besoin à un endroit d'une base de donnée relationnelle, on en a déjà une, et c'est un assez bon datastore générique dans énormément de cas, rarement le meilleur mais ça évite de complexifier l'infra (donc le risque opérationnel).

 

Maintenant, si de toute façon, on a des milliers de noeuds, des milliards d'actions utilisateur et plusieurs datacenters, évidemment qu'on va avoir un truc du genre :

 

Au frontend

• une in memory data grid lègere
• un store orienté document optimisé pour la recherche
• un middleware real time, plutot orienté topics riches, pour communiquer avec les clients (c'est à cet endroit que le gentil monsieur à la mode totalement réactif est à sa place)

Et au backend

• Une base de donnée relationnelle
• Un cluster hadoop
• Du networking adaptatif
• De la réplication multi-site intelligente capable de merger un split-brain correctement

Et entre les deux

• Un middleware orienté messages,plutot orienté queues, pour gerer tous les flux interactifs entre le front-end et le backend (évidemment, les initial load de la grid et du document store se font autrement, en mode batch)

Et ça c'est si c'est pas le résultat d'une croissance organique, qu'on s'est imposé des limites en terme de complexité, et qu'on n'a pas laissé une grosse consultence y mettre ses gros doigts pleins de CORBA et de Web-Services

 

 

[Poil à gratter]

Voila, dans l'idéal, on utilise le bon outil pour le bon job, mais comme dans la majorité des applis, on a besoin à un endroit d'une base de donnée relationnelle, on en a déjà une, et c'est un assez bon datastore générique dans énormément de cas, rarement le meilleur mais ça évite de complexifier l'infra (donc le risque opérationnel).

Un RDBMS est un outil très flexible quand on sait comment l'utiliser correctement. On peut émuler la plupart des fonctionnalités des bases NoSQL, mais ça demande plus de travail.

[Nirvana]

Faudrait renommer le fil "Le fil des admins/architectes système", parce que là c'est trompeur. Un geek, en général, ça s'intéresse aux jeux vidéo, à Star Wars et compagnie. Là c'est de la pure discussion technique restreinte à un ou deux métiers très précis.

[Poil à gratter]

Nan ça serait plutôt développeurs en folie, un architecte système à d'autres préoccupations.

 

Sinon tu vas apprendre qu'il y a 2 types de geeks:

- ceux qui aiment Star Wars

- ceux qui aiment la SF.

 

Enfin je suis d'accord que c'est une discussion très technique, restreinte à peu de gens, mais ça recouvre beaucoup de métier différents: ça peut aller du développeur web indépendant, au développeur base de données en entreprise, en passant par le développeur Java.

 

Tu comprendras plus tard, quand tu auras commencé ta carrière, Nirvana

[jubal]

Faudrait renommer le fil "Le fil des admins/architectes système", parce que là c'est trompeur. Un geek, en général, ça s'intéresse aux jeux vidéo, à Star Wars et compagnie. Là c'est de la pure discussion technique restreinte à un ou deux métiers très précis.

Un geek informatique comme son nom l'indique ça s’intéresse a l'informatique.

Relis le premier message du fil pour comprendre la raison de sa création

[jubal]

Enfin je suis d'accord que c'est une discussion très technique, restreinte à peu de gens, mais ça recouvre beaucoup de métier différents: ça peut aller du développeur web indépendant, au développeur base de données en entreprise, en passant par le développeur Java.

Je dirais même que ça recouvre plus que des métiers, je faisais de l'informatique avant d'avoir un métier.

Ça recouvre des trucs intéressant ou rigolo en informatique.

[Nirvana]

http://hackertyper.com/

[Cthulhu]

http://moviecode.tumblr.com/

[Nirvana]

Le système Midori de Microsoft se rapproche de sa phase commerciale

 

Cet article a l'air intéressant mais je n'y comprends pas grand chose. Ca changera quoi pour le commun des mortels (à long terme éventuellement)