Poil à gratter

Woputaing.... j'en gardais un très bon souvenir de ce jeu, mais là j'ai pris une douche froide

Ouais, ça, et du lait, en quantité astronomique.

Ah, ils vont bien rigoler avec le nouveau stagiaire chez Habitat!

IE11 est largement dans la course niveau performances et respect des standards, d'ailleurs pour le touch, c'est Chrome qui ne respecte pas le standard. Le seul truc qui craint à mort c'est l'interface graphique archi-lente, et le mode compatibilité désastreux. On sait: ils ont nettoyé le moteur de rendu HTML de IE de tout le code legacy, et ça forme la base pour le projet Spartan. C'est juste que maintenant on sait que Spartan ne s'appellera pas IE 12. J'aimerais bien qu'ils gardent Spartan: après Cortana ça ferait une paire et en plus c'est sympathique comme référence. Et Spartan embarquera Internet Explorer pour le mode "enterprise legacy": quand le navigateur passera en mode entreprise ça sera en fait IE qui sera executé en arrière plan. IMO les devs IE ne doivent avoir qu'une envie c'est de bazarder IE, mais avec tout le code dans la nature qui utilise des ActiveX et tout un tas de trucs propriétaires c'est juste hors de question.

Un témoignage qui vaut son pesant de cacahouètes: http://stephanescotto.unblog.fr/2015/03/14/aller-photographier-les-antilles-francaises-et-se-faire-racketter-par-letat/

Juste en passant vite fait, la - vieille - vidéo sur React dans cet article explique très bien pourquoi JSX est une mauvaise idée, et c'est un des points qui m'avait fait aimer React à l'époque: https://developer.atlassian.com/blog/2015/02/rebuilding-hipchat-with-react/

Fixed.

Justement, ce genre de requêtes simples plus grand monde n'a besoin de les écrire puisque c'est géré par un ORM ou une couche DAO pour une application un peu plus conséquente. Celles qu'on a besoin d'écrire à la main ce sont justement les requêtes un peu velues.

Frikandel, fricadelles, fricandel: c'est la même chose, version néerlandaise, flamande et wallonne. Au FEBO ils servent des frikandels, et au Smullet's ils servent des frikadels.

Ah, je comprends mieux! Tout le monde ne fait pas le métier par passion, mais juste à but alimentaire (et c'est parfaitement normal), du coup certains développeurs ne sont effectivement pas très curieux de savoir comment ça marche le machin qui leur envoie le data. Néanmoins, on est bien obligés de se spécialiser, et maîtriser SQL ce n'est juste pas possible pour un développeur généraliste. En plus on oublie très vite quand on ne pratique pas.... J'avais su, mais là si on me demande la différence entre un LEFT OUTER JOIN, un LEFT JOIN et un RIGHT JOIN, je serais bien incapable d'expliquer quoi que ce soit

On avait déjà évoqué la question dans le sujet des geeks informatique, et la conclusion était que geek != développeur. Bon, en même temps un ORM en PHP... Comment est-ce possible d'avoir un layer de cache dans un ORM PHP? Mais de toutes façons je n'ai jamais vu une application qui faisait tous ses accès BDD en utilisant uniquement l'ORM: il y a toujours une part de requêtes écrites à la main pour d'évidentes raisons de performance. Enfin si, j'en ai vu qui faisait tout avec l'ORM, mais ça s'est mal terminé Ensuite ça fait quand même longtemps que les ORMs sont un peu plus malins et ne chargent pas la totalité d'un graphe d'objets ou même les membres de l'objet avec des stratégies de lazy loading/fetching: https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html Je n'ai jamais vraiment trop adhéré cette idée d'impedance mismatch: oui il y a des différences, mais rien d'insurmontable. Les problèmes que j'ai vu venaient plutôt d'un mapping très naïf et d'un manque de couches dans l'application. Il est aussi possible de solutionner beaucoup de problèmes en ayant plusieurs modèles objets dédiés à des usages différents (typiquement écriture vs lecture). Ça se fait depuis des années, et c'est désormais formalisé sous le nom de CQRS. Bref, ce n'est pas tout noir ou tout blanc. En revanche ce que je sais c'est qu'implémenter de l'optimistic locking ou un cache L2, à la main, sans ORM, ce n'est juste pas possible. Et c'est là qu'un ORM apporte beaucoup et permet de faire monter en charge des applications. Certes, ce n'est pas très bien nommé. Mais DOM temporaire ça ne serait pas beaucoup mieux. Ils avaient fait des processeurs Java qui pouvaient exécuter du bytecode directement. donc oui ça peut servir de jeux d'instructions. Je n'aime pas non plus JSX mais pas parce qu'il plie le DOM à la gestion de la vue, juste parce que c'est un langage de template et que de ce fait il est limité. C'est IMO LA grande incohérence dans React: tout peut être fait en JavaScript si on le veut (manipulation DOM, et même CSS), et on bénéficie donc de toute la puissance d'un langage de programmation complet. Seulement c'est un peu lourd à écrire. Alors ils ont cédé à la facilité et créé un énième langage de template avec toutes les limitations qui viennent avec. Entre autre c'est adverse au refactoring (bon, ce n'est pas non plus le point fort de JavaScript...) et ça force à construire des outils ad-hoc dans les IDE pour aider les développeurs. Il est mal foutu, mais au moins ça fonctionne déjà sur des sites à fort trafic. Et Facebook utilisait déjà React longtemps avant sa publication, donc avec ou sans React c'est un clairement un site très gourmand en ressources. Il y a aussi une part de réaction (ahah) à l'encontre d'Angular, mais il y a un phénomène intéressant qui est que React pollinise d'autres frameworks avec les idées de vDOM, styling en JavaScript, Flux, etc. J'ai déjà repéré 3-4 frameworks qui se basent sur vDOM et se disent meilleurs que React. Ember.js commence à incorporer des idées aussi. Donc ça me paraît parti pour durer.

À mon avis ils vont faire un semi-flop: ils en vendront mais uniquement aux fan boys qui achètent de toutes façons n'importe quoi du moment qu'il y a une pomme dessus. Déjà, ça ne fonctionne qu'avec un iPhone: Apple est encore une fois scotché dans les années 90 avec du tout propriétaire et du non cross-plateformes. Ensuite l'autonomie est pourrie et le temps de rechargement assez conséquent: ça enlève une grande partie de l'intérêt "fitness". Enfin les fonctionnalités sont relativement limitées, ainsi que les capteurs. Et cerise sur le gâteau, le prix... En revanche je serais assez intéressé par le MS Band v2, ou un autre sous licence (Fitbit?) surtout vu que je suis passé sur Lumia cet automne: pouvoir sauver une note, créer un rendez-vous en parlant à mon poignet je trouve ça assez cool. Le capteur d'UV, bonne idée soit pour se protéger ou pour faire de la vitamine D. http://www.windowscentral.com/how-microsoft-band-will-beat-apples-watch

Ah, ces littéraires

Gloups

C'est vrai, pas grand chose à voir. En fait j'ai essayé de faire "court", et ce que j'ai écrit n'est pas très clair à la relecture. Mais c'est amusant que tu dises ça car j'ai eu la même discussion aujourd'hui à propos de la programmation multi-thread en Java. Mon avis étant que c'est un domaine d'expert à ne pas mettre entre toutes les mains, et que je préfère largement utiliser un framework plutôt que de faire semblant de maîtriser la chose (et me bananer lamentablement). Je parle d'Hibernate parce que Emmanuel Bernard en avait parlé dans un Podcast "Les cast-codeurs" où ils évoquaient le sujet: il avait comparé la façon de fonctionner du vDOM avec celle d'Hibernate. En fait, tout comme le vDOM, Hibernate utilise un modèle temporaire qui enregistre toutes les modifications (en gros un vSQL) faites au graphe d'objets avant d'envoyer des requêtes SQL. Cela permet des optimisations comme par exemple de ne pas exécuter du tout de requêtes SQL si après plusieurs opérations le modèle est finalement identique. Il y a aussi évidemment les excellent caches d'entité et de niveau 2 qui aident un petit peu Alors par contre je ne vois pas en quoi Hibernate protège des conneries au niveau de la DB elle même, ou alors c'est juste que tu veux tenir les devs Java éloignés grâce à des couches Or ce ce genre d'optimisations sont impossibles à détecter localement, il faut un superviseur pour gérer les états. Et ce n'est évidemment pas réaliste d'écrire quelque chose d'aussi sophistiqué pour chaque projet. C'est là qu'entre en jeu un framework comme React et son vDOM. Bon évidemment je ne pense pas que React est parfait, et il a encore plein de défauts (par exemple JSX), mais c'est un grand pas en avant, il me semble.

Très bonne nouvelle: l'équipe Angular avait annoncé qu'ils allaient coopérer avec l'équipe Typescript pour faire converger AtScript et TypeScript, et honnêtement je n'y croyais pas du tout. Je voyais mal Google et Microsoft coopérer. En plus AtScript ça me semblait un peu genre: on aimerait bien utiliser TypeScript, mais on ne peut pas parce qu'on est Google, alors on va faire un truc qui ressemble à TypeScript. Au final on va récupérer un truc positif du couac Angular 2.0: TypeScript 1.5 aura des annotations.

Oui, je n'avais pas oublié J'ai recherché encore mais je n'arrive décidément pas à mettre la main sur le blog qui détaille des points techniques à propos du vDom. En résumé, le vDom c'est un peu l'équivalent dans le monde JavaScript du code managé qu'on connaît déjà bien dans le monde Java . Ça rajoute une étape intermédiaire de transcription, et intuitivement ça paraît lourd et plus lent, mais en fait c'est tout le contraire: c'est plus rapide et ça ne pourra que devenir plus rapide dans le futur. C'est assez contre intuitif, et beaucoup de développeurs, même chevronnés, ont du mal à réaliser ceci. Par exemple ils vont considérer qu'utiliser Hibernate est plus lent que faire du SQL "à la main", alors que pour la majorité des projets (qui sont souvent des CRUDs) utiliser Hibernate offre de meilleurs performances malgré toutes les couches que ça ajoute. C'est l'éternel débat "natif vs managé", et en tant que développeur Java je ne peux que penser que ce débat est plié depuis des années. On a une implémentation native du DOM - en C++ pour ce que j'en sais - dans les navigateurs, et une implémentation managée en JavaScript. Je fais le pari dès aujourd'hui que la version managée va exploser les versions natives d'ici peu. Le vDom a aussi ceci de particulier que c'est une implémentation légère du DOM: React n'émule pas tous les attributs qu'on peut trouver sur un élément, mais seulement ceux qui sont utilisés. Et ça fait déjà une différence énorme: la spécification du DOM est un monstre, avec une tétrachiée d'attributs que les moteurs des navigateurs doivent implémenter. Reac peut s'affranchir de cet héritage douteux. TL;DR: IMO React à gagné et est en train d'enfoncer les autres frameworks à plates coutures, à tel point que ce sont désormais les autres frameworks qui intègrent le vDOM ou Flux. Flipboard, Hipchat, et d'autres que j'oublie sont passés sur React: j'attends toujours des vraies applications critiques écrites avec Angular... (qui est à mon avis le grand perdant dans l'histoire)

Ouais, tu pourras économiser ton smart-phone à $1.000 en utilisant ta montre à $1.000 qui a une autonomie de moins d'un jour. Update: apparemment si tu achètes la voiture Apple tu pourras utiliser la batterie de la voiture pour porter l'autonomie de ta montre à 2 (deux) jours!

Félicitations!

Ah oui, c'est intéressant. Mais je vois sur leur site qu'ils prennent 5% de royalties, mais au moins pas de licence à payer avant d'avoir commencé à gagner de l'argent. Je n'ai jamais cru à ces Steambox, je me demandais d'ailleurs récemment si c'était abandonné...

Ouais auberge de jeunesse, ou bien deux groupes de 4 dans un hôtel avec des chambres collectives et douche commune, ça doit se trouver dans les 30-40 euros par personne.

Li quoi? Mais ça va sans doute venir un jour. Tout comme Remote IE qui marche déjà sur Android: https://blogs.msdn.com/b/ie/archive/2014/11/02/announcing-remoteie-test-the-latest-ie-on-windows-mac-os-x-ios-and-android.aspx?Redirected=true Je pense quand même qu'ils vont privilégier Mac, question de parts de marché...

Ça s'annonce pas mal du tout ce projet Spartan:

Ouais, sans compter l'update gratuite vers Windows 10. Et aussi Unity 5 qui devient gratuit en personal edition: http://unity3d.com/unity/personal-edition

Ça doit être joli Sinon tu peux utiliser un Qwerty international: tu devras te taper 2 touches pour les accents, mais c'est finalement tellement plus logique qu'il n'y a pas besoin de mémoriser le layout. C'est du coup plus facile quand tu changes de langue assez souvent. L'Azerty Canadien est pas mal aussi puisqu'il a un double layout français/anglais et c'est aussi plus logique au final.