L'affreux

Bel anglicisme.

Je ne sais pas mais on pourrait imaginer que le gouvernement allemand ait demandé à faire étudier par ses services le contenu de la boite avant qu'il ne soit transmis au procureur français.

C'est possible, mais dans quel but ? Le gouvernement a son intérêt dans les actes terroristes.

La gardienne des sauces plutôt.

Je n'espère pas. Autant Google est monté sur de l'éthique, de l'ouverture et de la passion, autant Facebook est un système fermé dont la technologie est contestable. Je pense notamment au JavaScript : la plateforme Facebook n'a toujours pas pris le tournant applicatif de HTML 5, elle est déjà has been. Dans le Web, Microsoft fait tout bien depuis plusieurs années. Ils n'ont pas d'idée, mais à force de bosser sur les sous-jacents, ils vont avoir un socle véritablement solide. Ils ne sont pas hors course.

Bah présente-la à Mobius ! C'est exactement ça le problème. Si c'est un repas ponctuel, le(s) riche(s) se partage(nt) la facture, c'est la moindre des choses. Mais si c'est un rendez-vous régulier, la place de celui qui se fait toujours inviter est gênante.

Avec justesse. Blaguer sur le sujet est amusant. Critiquer avec sérieux le serait moins. Il n'existe pas que la manière moderne, pour un couple, de mener une vie saine. On peut épiloguer sur chaque défaite pour cause d'inégalités, ça ne prouve rien et l'on pourrait facilement relever les échecs pour cause d'égalitarisme, surtout que les derniers dépassent de loin les premiers. Oui.

C'est juste une caisse dédiée au foyer. J'ai aussi pratiqué ça pour des vacances entre potes en mode étudiant fauché : quand la caisse est vide, chacun remet au pot, et d'ailleurs personne ne comprend pourquoi ça s'est vidé si vite. Ben oui, compter ou ne pas compter, il faut choisir.

Suggère-leur la solution du pot commun (en liquide) ou du compte commun (je pense qu'il existe la possibilité d'avoir deux CB ?). Ça évite la compta.

Quel documentaire ? La vidéo du premier post ? Elle est trop longue, pas regardé. Dans les sociétés humaines primitives, les activités économiques à l'échelle du village n'ont pas besoin de monnaie et fonctionnent sans. Certaines denrées alimentaires jouent un rôle monétaire dans certains échanges. L'origine de la monnaie est simplement ici : un bien dont tout le monde a besoin couramment et qui, donc, est accepté par tout le monde. La monnaie moderne, qui est une monnaie-crédit, est d'une autre nature. L'origine et la nature de la monnaie sont deux sujets distincts, la première est du domaine de l'anthropologie, la seconde de l'économie.

Sur la nature de la monnaie, un intervenant ici qui s'appelait gdm avait rédigé des pages dans Wikibéral. Ensuite il s'est manifestement trompé sur le cas du bitcoin, mais ses explications, pour la monnaie utilisée couramment de nos jours, restent ce que j'ai lu de mieux. Les robinsonades sont trop artificielles. Elles mélangent deux sujets : la nature de la monnaie et ses origines. Pour comprendre les origines de la monnaie, il faut se tourner vers les anthropologues et les historiens.

Note bien qu'il est plus facile d'envisager une contribution à 50/50 quand on est le plus riche.

Un apport au foyer à 50/50 et les grand-parents qui éduquent les enfants. Hé hé. Le féminisme, c'est pas pour moi, mais je reconnais, c'est pas mal.

Ah OK. Je ne pigeai pas la date de départ, mais c'est logique.

Et avant le 19è ?

Je sais, ça rentre pas, mais on. n'est. pas. des. geeks. Renommez ce fil en "Expat & Web" si ça vous perturbe.

Ah ouiii OK merci. Effectivement. Je regarderai.

Un programme front-end en JavaScript est en dehors des problématiques de montée en charge. Facebook utilise 25% du CPU pour faire quoi ? Ils sont nuls en performance front-end, il n'y a pas à chercher plus loin. "ligens" ?? Quel que soit le langage, on peut lever un RAM les bons éléments. Ça demande en revanche d'y réfléchir au début du projet, alors qu'une couche ORM en plus permet de ne pas s'occuper de la performance et de corriger le tir à la fin. Mais la couche additionnelle apporte aussi des inconvénients, à commencer par la lourdeur au codage comme à l'exécution. PHP ne reste pas en RAM d'une requête sur l'autre. Ça n'a pas empêché des développeurs PHP de développer Doctrine. J'imagine qu'ils justifient leur travail par d'autres mauvaises raisons que le cache du serveur d'application. Je ne connaissais pas celui-là mais je ne vois pas l'intérêt d'un mapping objet sur les mot-clés de SQL. Le standard SQL 92 est bien respecté depuis des années, si on fait attention, on peut relativement aisément passer d'un SGBD à l'autre. Cette couche n'apporte rien. Pour des raisons fonctionnelles, la plupart des INSERT, UPDATE et DELETE sont faits unitairement. C'est pourquoi on peut les générer avec un petit Helper. Il n'y a pas besoin d'aller plus loin.

… pour la version ORM. En SQL ça donne : geek <> développeur. Et en unicode : geek ≠ développeur. Marche aussi.

Eh bien on s'est trouvé un gros point de divergence : l'empilage des couches. On peut charger certaines données, notamment celles en lecture seule, dans des tables de hashages, à l'ancienne, ça marche encore. Mais le SGBD n'est pas forcément mauvais pour les optimisations. Si on ne le sollicite pas de manière stupide, il détermine plutôt bien ce qu'il faut lever en RAM. Le SGBD, en lui-même, est déjà une couche d'accès au données. "OUTER" est un mot-clé optionnel. J'ai quelque chose qui génère l'essentiel des requêtes en écriture, mais les SELECT, ça m'a toujours paru normal de les écrire à la main.

C'est pas faux. J'aime beaucoup le modèle asynchrone de JavaScript. Des tâches simultanées sur un seul thread. Plus facile et moins de bugs indétectables. Personnellement je trouve le DOM virtuel mal nommé. Le vrai DOM est déjà virtuel, c'est une arborescence standardisée d'objets manipulables en JavaScript. Je ne suis pas convaincu qu'on puisse faire le parallèle avec du code managé comme le bytecode en Java versus le code machine. Les ORM et le virtual DOM, c'est d'un autre ordre. Ne serait-ce que sur l'élégance. Le bytecode pourrait (presque?) servir de jeu d'instructions à un processeur. Les ORM font carrément l'impasse sur la véritable nature du stockage relationnel, pour présenter une façade obéissant aux logiques de la POO. Idem pour le virtual DOM : il s'agit de plier le DOM à la gestion de la vue. JSX n'est pas une erreur (enfin si mais…), c'est une fonctionnalité cohérente avec l'approche du virtual DOM. AngularJS est mal foutu, maintenant que ça se voit, React en profite. Mais React aussi est mal foutu. Je ne crois pas du tout à sa généralisation. Il bénéficie d'une réaction à l'encontre de Angular. Et puis, bon, Facebook hein. Sous Firefox/Linux, les pages Facebook pompent 25% du CPU. J'avais constaté ce changement justement au moment où Facebook publiait React.

Pour ma part je ne suis pas vraiment geek et la discussion m'intéresse. Comme quoi… Non. Le SQL est une affaire sérieuse, et qui devrait donc est prise au sérieux par les développeurs. J'avais écrit un article finement intitulé : Les ORM c'est mal. Même chose pour le Virtual DOM, sauf que je ne suis pas encore tombé sur un projet où il m'est imposé donc je n'ai pas encore écrit un texte à charge pour me décharger.

Il y aurait un marché pour une plateforme de paiement et pour un CMS. Ici PrestaShop n'est manifestement pas capable de traiter des nombres avec décimales variables.

Citizen four. À voir. Pas vu, j'étais dans un pays sans cinéma. Mais la morale dans Chappie est complètement inversée : l'aventure progressiste est présentée comme l'option la plus sage bien qu'incomprise. Les informaticiens sont des génies qui compilent des tera-octets de lignes de code et réussissent tout du premier coup. Le même casque neuronal sert à lire l'activité mentale d'un humain ou d'un robot. C'est juste idiot, mais on s'en fiche, c'est du spectacle, c'est fun, c'est marrant, c'est même mignon, on s'en prend plein la vue, et puis après tout la morale inversée donne un ton décalé, inhabituel, alors pourquoi pas.

Chappie : c'est idiot, mais ça détend. Je recommande.