Le loup de Wall Street

Lundi soir, j’ai regardé le loup de Wall Street. Un film qui a une sacrément bonne réputation.

Et honnêtement, le spectacle est saisissant. Un peu comme dans Wall Street, le personnage de Jordan Belfort y est décrit comme une espèce d’escroc boursicoteur, qui mise sur la stupidité de ses clients pour se faire des tonnes de pognon. Mais là où Gordon Gekko est décrit comme une espèce de reptile parasite, cet escroc-ci essaye de construire des choses : une famille, une entreprise, une culture. Bref, il a des aspirations qui le rendent attirant aux yeux du spectateur, ce qu’amplifie une mise en scène et un ensemble de dispositifs dénotant la maestria de Scorcese.

Mais, il y a aussi la drogue omniprésente et les femmes nues, éventuellement représentées en position de trophées. Bon, la drogue fait partie d’un imaginaire du trader bien connu, je ne m’attarderais pas trop dessus.

Par contre, les femmes nues … Je n’en peux plus.

Dans un film de trois heures, je dirais qu’il y a facilement 1/4 d’heure, voire 1/2 heures montrant des femmes plus que déshabillées. Et, collision intéressante de calendrier, ça arrive au même moment que les terribles histoires d’Harvey Weinstein, et le plus terrible encore #dénoncetonporc de Twitter. Du coup, je ne vais vous dire que ce film est avant tout une galerie permettant à de vieux producteurs dégueulasses de faire leur marché de jeunes actrices … Mais la défense de DiCaprio (que vous trouverez à la fin de ce chapitre de l’article Wikipedia) ne tient simplement pas : Scorcese et DiCaprio sont clairement fascinés par le personnage, et son apparente chute est montrée juste pour servir de « cache-sexe » devant l’obscénité du personnage présenté. Et de la part d’hommes de pouvoir dans le milieu d’Hollywood depuis vingt ans, ça devient particulièrement répugnant.

J’ai même en fait assez honte d’avoir regardé ce film bien filmé, mais idéologiquement pourri jusqu’au coeur. Franchement, le même film, tourné du point de vue de l’agent du FBI, m’aurait sans doute bien plus séduit.

Ah, et au fait, si vous pensez que c’est une montée de féminisme, elle n’est pas si récente, puisque j’ai aussi arrêté de regarder Game Of Thrones après la première saison à cause des femmes nues jetées à l’écran par HBO pour distraire le spectateur. La seule chose qui vaudrait le coup, ce serait une parité dans cette exposition frontale de nus : voir autant d’hommes que de femmes, ça aurait du sens en 2017. Ne montrer que de femmes, c’est se contenter d’une vision rétrograde de la beauté physique, et considérer les femmes comme des objets de concupiscence plutôt que comme une partie du public, c’est idiot, primaire et dépassé.

Publicités

Hellboy

J’ai revu hier soir Hellboy.

Bon, dit comme ça, ça n’est pas très impressionant.

Mais … J’ai également lu plusieurs fois les comics dont ce film est tiré (j’ai d’ailleurs acheté le premier tome suite à un premier visionage de ce film). Et si j’avais donné mon avis sur Goodreads suite à cette première lecture, je crois que le film mérite deux ou trois mots.

D’abord (et à mon avis ça compte pas mal) visuellement : comment recréer le style incroyable de Mignolia au cinéma ? C’est impossible. Donc le réalisateur n’essaye pas trop (sauf dans un plan nous montrant les neuf qui sont un). Et il a raison, puisque l’ambiance est visuellement très différente, mais pas inintéressante … Pas inintéressante, mais pas suffisante pour rendre le film inoubliable.

Ensuite, il y a le casting. Ron Perlman qui cabotine pour donner un Hellboy peut-être un peu caricatural n’est pas mauvais du tout dans le genre bougon, mais je crains qu’il manque d’une certaine forme de finesse au moment de faire le choix qui va détruire le monde … ou pas. C’est dommage, parce qu’il est correctement massif, mais ne présente peut-être pas la bonne … faille. Dans le reste du casting, l’agent Myers qui n’est pas dans les comics est un ajout sympathique, une espèce de témoin d’humanité au milieu de la folie du BRPD qui nous relie un peu à ces marginaux. Et puis Liz Sherman … est aussi brillante qu’il le faut. Quant aux méchants, je trouve Raspoutine toujours aussi difficilement perceptible (au sens où ses motivations apocalyptiques sont totallement incompréhensibles), mais l’acteur le rend aussi inhumainement méchant qu’il est nécessaire. Et sa comparse Ilsa Haupstein est également bien campée. Bref, tout ça tourne bien … sauf pour la faute d’intelligence qu’est le chef du BRPD : lâche politicard quand Hellboy est une quête philosophique, il ramène des préoccupations bien trop prosaïques pour être utiles.

Parce qu’en vrai, le secret de cette oeuvre aussi bien au cinéma qu’en comics, c’est que c’est une oeuvre sur la réalisation de soi, quand bien même ça va à l’encontre de ce que veut l’univers. Le courage, c’est parfois refuser. Et ça, quel que soit le média, c’est le coeur de cette oeuvre, et il est bien passé hier soir.

Quand un non-événement devient un petit événement

Mercredi, l’un des disques durs de mon NAS a rendu l’âme (eh oui, encore). J’ai donc commandé un autre disque en ligne, et monté le nouveau disque dans le NAS. Après un poil de bidouille, le NAS a redémarré, et tout son contenu est à nouveau synchronisé en RAID. Tout ça ne méritait évidement pas un article.

Par contre, j’utilisais jusqu’à présent Owncloud pour synchroniser mes données sur mes différentes machines (je pense d’ailleurs qu’il n’est pas innocent dans la faible durée de vie de ce disque). Et comme le NAS n’avait plus qu’un disque, je ne pouvais plus m’en servir. Coup du sort ou coup du hasard, au même moment, je flânais sur le site de Keybase, et en particulier sur la page dont le titre est « Introducing the Keybase filesystem« . En en lisant les détails, et en particulier la partie « But there’s more », j’ai découvert que je pourrais très bien disposer d’une solution de partage bien plus sûre que ce qu’offrait Dropbox, pour peu que Keybase implémente un système de partage de fichiers. Et comme une bonne partie du code est open-source, il ne tient qu’à moi d’aller comprendre comment ça marche pour proposer un partage … qui fonctionne.

Oh, et en bonus, via un autre ensemble d’urls, il est possible de mettre à disposition du contenu de façon sûre. Idéal pour un site web généré statiquement (donc le retour de JBake).

C’est pas encore demain que je vais virer Thunderbird …

Il y a plus de dix ans, j’adorais tester des clients mails/news : Outlook Express, Opera Mail, FoxMail, XNews, et tant d’autres …

Avec l’émergence des clients web à la GMail, tous ces clients ont peu à peu expiré.

Alors quand j’ai vu ce tweet

je me suis fendu d’un essai … rapide. Rapide, parce que si rambox supporte quelques fournisseurs de mail, c’est à travers leur protocole HTTP, et pas IMAP ou POP. Et ça, ça me choque au plus haut point. Parce que bon, il y a bien un module node-imap, alors pourquoi ne pas s’en service ?

Et j’ai beau chercher, je ne vois pas de feature request pour ajouter imap ou pop. Alors quoi ? Ca n’intéresse plus personne ? Je vais faire le vieux con, mais l’avantage de protocoles comme IMAP et POP, c’est d’assurer une compatibilité instantanée avec un bon paquet de fournisseurs de mails en un coup, ce qui paraît une bonne idée, non ?

Une question de modèle

Je suis tombé sur cette question sur Twitter la semaine dernière

Et aussi curieux que ça puisse paraître, ma réponse est un grand oui.

Si demain un site veut utiliser mon CPU pour miner des cryptomonnaies, ce sera avec plaisir.

Parce que le modèle économique de la publicité sur internet a pour moi des limites terribles

  • Comme il s’agit d’un modèle de l’attention, il limite le contenu visible en garnissant les pages web de bandeaux (animés ou non) de pop-ins et autres instrument réduisant mon écran à un panneau publicitaire géant
  • Comme il s’agit d’un modèle de l’attention, il pousse les sites web vers le titre PUTACLIC, l’absence de contenu réel et une économie de l’attention qui réduit à néant les sites de qualité.

Bon, alors, évidement, ce nouveau mode de fonctionnement a des inconvénients clairs :

  • OH MON DIEU MON CPU EST UTILISE ! (parce qu’un CPU d’ordinateur moderne ne fait rien environ … 95% du temps – statistique à vue de nez)
  • Rien n’interdit à un site web de faire du minage et d’afficher de la publicité

Mais je pense que l’émergence d’une économie utilisant mon CPU d’une façon correcte, au lieu de squatter mon écran, pourrait être intéressante.

Java 9, tu modules ?

Rémi ?

Vous connaissez Rémi ? Il est maître de conférences à Marne la Vallée, développeur d’ASM (j’ignorais ça), d’OpenJDK, expert pour le JCP (et clairement spécialiste des évolutions du langage, pas la partie JavaEE) où il a ajouté invokedynamic, et a travaillé sur les lambda, Jigsaw.

Java 9

Java 9 est la dernière grosse release, parce que c’est pénible. Ca va être remplacé par une release tous les six mois …​ c’est un peu plus rapide. Et donc, dans six mois, on verra var apparaître dans le langage Java.

Les modules

Historiquement, ça devait arriver en Java 6 ou 7 …​ Ca a pris un peu de retard.

Qui veut modulariser le JDK ?

Il y a d’une part des développeurs du JDK qui veulent le faire évoluer, mais ne peuvent pas à cause de toutes les APIs qui utilisent des classes « cachées » du JDK. Et d’autre part …​ des experts de sécurité qui considèrent les failles de la plateforme.

D’autres problèmes

L’enfer du CLASSPATH

Sans outil pour gérer automatiquement le CLASSPATH (genre maven, gradle et autres), c’est l’enfer. Par ailleurs, quand le ClassLoader charge une classe, il scanne linéairement tous les jars et charge la première classe qu’il trouve. Du coup, c’est long. Mais aussi super merdique quand on a deux versions du même artefact. Du coup, on aimerait bien que ce soit géré par la JVM. De la même manière, éviter que les NoClassDefFoundError ne sortent qu’à l’exécution serait une bonne idée pour les développeurs.

Alléger Java

Ce serait sympa de pouvoir faire tourner le code Java sur des plateformes plus légères (typiquement pour l’IoT). Personellement, ça meparaît vaguement possible avec des outils comme ProGuard de limiter la taille des dépendances, mais ce serait mieux d’avoir ça directement dans le JDK. Par exemple, rt.jar contient encore des parseurs XML (qui n’ont pas à être des classes privilégiées) ou CORBA (qui s’en sert encore ?).

Comment modulariser ?

standards

Aucun rapport avec Java, bien sûr

Il y a déja des standards de modules en Java

  • maven
  • gradle
  • JBoss
  • OSGi
  • JavaEE

Du coup, Jigsaw doit fournir un système de modules compatible avec tous ces systèmes prééexistants. Ce qui implique tristement qu’il ne peuvent pas contenir de numéros de version. Et ça, c’est moche.

Modularisons donc !

C’est quoi un module ?

Dans un module, il y a

  • des dépendances
  • et des classes qu’on veut garder invisibles aux autres packages

Par exemple, java se est constitué d’un paquet de modules …​ dont java.compiler. Ce qui signifie qu’il n’y a plus de distinctions JRE/JDK.

Tout ça est décrit dans un module-info.java qui va être compilé comme le reste du code. Ca empêche les modifications ultérieures, ce qui est bien.
A la compilation, il ne peut donc plus y avoir de « split-packages » (des packages déclarés dans deux JARS), ou de dépendances cycliques.

Qu’est-ce qu’on perd ?
  • les « split-package »
  • setAccessible(true) sur une classe d’un module fermé

Au passage, ça permettra enfin à Rémi d’optimiser les champs final (un truc dont j’étais sûr qu’il existait déja pourtant)

Enfin, sauf si on active le flag --illegal-access=permit (qui est parfaitement clair). Notez qu’il y a d’autres valeurs possibles (warn, debug). Bon, un jour, il disparaîtra.

En bonus, les classes JavaEE cachés dans JavaSE (java.xml.bind, java.xml.ws et autres) ne seront plus dans le JDK. Notez que ces classes sont toujours accessibles via des dépendances Maven.
Les classes sun. et com.sun. qui ne sont pas utilisées sont également supprimées.

A noter : L’annotation @ForRemovall (je ne suis pas sûr de l’orthographe) indique les classes qui seront supprimées dans la prochaine version du JDK. C’est une version étendue du classique @Deprecated.

Comment trouver les dépendances

Avec jdeps, par exemple, on peut facilement trouver toutes les dépendances d’un module. Notez que cet outil existe déja dans Java8.

Oui, mais comment je transforme mon application pour Java9 ?

Pour ça, Rémi a développé son application de test : ModuleTools qui lui permet de lire et d’écrire un fichier module-info.java ou module-info.class.Et dans son application, il déclare quelques modules, qui dépendent tous de java.base (comme les classes Java dépendent de java.lang.Object).

Contrairement à maven, un require de module n’est pas transitif (contrairement à maven). Du coup, il y a un require transitif, mais qui est limité à un niveau.

En terme d’organisation de fichiers, il est possible d’avoir plusieurs organisations, dont par exemple plusieurs modules dans le même dossier (ce qui n’est supporté ni par maven, ni par gradle, ni par les IDE).

Il est possible de stocker la version du JAR dans le module-info, et de la réutiliser depuis le code, mais le système de modules n’utilise pas la version.

Comment utiliser un JAR non modulaire ?

Typiquement, une dépendance de Maven Central.On ne peut évidement pas ajouter simplement le JAR dans le CLASSPATH. Il suffit en fait de mettre le jar dans le module-path, et Java va générer automatiquement un module-info, qui permet en plus à ce module automatique de dépendre de JARs du CLASSPATH.Et comment s’appelle ce module ? Soit le nom fourni dans le MANIFEST.MF comme Automatic-Module-Name, soit le nom du JAR sans le numéro de version. Du coup, en ce moment, sur GitHub, c’est la fête à l’Automatic-Module-Name. Au passage, il est possible d’utiliser les JARs modulaires comme des JARs classiques, en les mettant dans le CLASSPATH !

Comment limiter la visibilité ?

Si on veut faire un module interne, il est possible de limiter sa visibilité à certains modules spécifiques, et pas au monde entier. C’est très chouette pour mieux gérer la sécurité. C’est ce qu’ont fait les développeurs du JDK pour la tristement célèbre sun.misc.Unsafe dont une partie a été déplacée dans jdk.unsupported, et une autre partie dans un jdk.internal.misc. Du coup, la réflexion n’est plus possible sur les champs privés (dommage pour gaedo). C’aurait été pénible pour JPA …​ mais les fournisseurs d’implémentation JPA utilisent des agents qui changent le code avant son exécution. Cela dit, la réflexion reste possible grâce à open sur un package ou sur le module.Par ailleurs, le très moche ServiceLoader a été étendu pour fonctionner avec les modules …​ La différence, c’est que la description est un peu propre et intégrée au module-info. Et la description à la fois des fournisseurs d’implémentation et de l’utilisation de ces implémentations doit être fournie. C’est super cool, parce que ça permet de tester les injections de dépendances.

Packager ?

Avec jlink, on peut créer une image à la volée de l’application et de ses dépendances. Pratique pour l’embarqué, évidement, mais aussi pour Docker. Hélas, il ne peut pas y avoir de modules automatiques, parce qu’avec ces modules automatiques, il faut embarquer tout le JDK, et ça limite en plus énormément les possibilités d’optimisation de jlink. C’est un peu la carotte de Jigsaw. Ca permet aussi d’utiliser une JVM minimale de 3 Mo !. Bon, sans JIT, mais sur un Raspberry, c’est pas vraiment utile. Ca permet aussi de garantir la durée d’exécution …​ avec jaotc, qui génère du code natif (qui pourra même se passer de JIT). Le but à terme de cette expérience est (accrochez-vous) de réécrire la JVM en Java (pour se débarasser du code C++).

Evidement jlink (et l’ahead-of-time-compiling) est chouette pour les performances. Et pour l’espace disque.

Conclusion

Modulariser, ça n’est pas si facile, à la fois pour les implémenteurs et les utilisateurs. A ce sujet, la conclusion de Rémi est parfaitement claire : si vous avez une application non-modulaire, n’essayez pas de la modulariser. C’est à la fois long, complexe, et sans valeur ajoutée. En revanche, si vous vous lancez dans une nouvelle application, la modulariser dès le départ peut être utile.

Et merci à nos amis du chtijug pour une soirée sans faille, dans une super salle, et avec une vue vraiment chouette !

Comment est-ce que je gère mes services avec Rancher et Consul ?

Mais pourquoi je veux faire ça ?

Admettons que je veuille me mettre aux microservices … ou plutôt aux services packagés dans des conteneurs docker (quelquesoit la taille des dits services).

Je commence par les packager dans des conteneurs Docker et c’est « cool ». Parce que comme ça, je n’ai pas besoin de demander à l’admin sys de déployer du Java partout, mais du Docker.

Donc, j’ai mes services et mon admin a entendu parler (sans doute sur ce blog) d’un chouette truc qui s’appelle Rancher. Et très vite, il veut ajouter une base de données de configuration (parce que mettre les fichiers de config dans les conteneurs, c’est pas terrible … lisez donc 12 factors apps à ce sujet). Donc il me dit d’utiliser Consul. Et Consul, c’est bien pour la config, mais ça fait aussi service registry. C’est-à-dire que ça permet à un service d’en trouver un autre dynamiquement. Un peu comme du JNDI pour les Javaistes … ou du LDAP pour les ancêtres.

Le problème, c’est que Consul fait service registry, et pas service discovery. C’est-à-dire qu’il peut stocker les services, mais pas découvrir quand ils démarrent ou s’arrêtent (enfin pour l’arrêt, si, mais bon, par symétrie, on va considérer ici que ça n’est pas son boulot).

Et comment je fais pour enregistrer mes services ?

Donc, il faut ajouter un composant d’enregistrement, un « registrator ». Coup de bol, il y en a deux pour Rancher :

  1. Gliderlabs registrator
  2. Rancher Registrator

Pourquoi y en a-t-il deux ? C’est assez bien expliqué dans cette chouette question : Do you kill registrator ? Notez que l’auteur de la question est également l’auteur du second registrator … ceci expliquant cela.

Et ça marche comment ?

D’abord, je vous montre le docker-compose.yml, et ensuite on en discute, ok ?

Dans ce fichier, il y a quelques trucs à noter

Attention à la version !

registrator ne supporte l’option useIpFromLabel que dans la branche master. En ancien développeur Java appréciateur des beaux numéros de version, ça me fait mal, mais bon, on me dit que ça marche comme ça dans le monde de Docker …

internal ?

Ca permet à registrator d’utiliser les ports effectivement exposés par les images, au lieu d’utiliser les ports visiobles hors de Rancher, donc ne l’oubliez pas

cleanup, deregister et resync

La doc de registrator est assez claire, mais ça vaut le coup de bien préciser que ces options sont là pour garantir qu’il n’y a pas de services n’existant que dans Consul (ce qui est un peu bête)

useIpFromLabel

A partir de Rancher 1.2, Rancher utilise un système nommé CNI, ce qui fait que l’ip et le port ne sont plus accessibles via le conteneur Docker mais via le label (ajouté dynamiquement par Rancher) io.rancher.container.ip. Du coup, il faut bien signaler au registrator qu’il faut utiliser ce label pour lire l’adresse du conteneur.

Attention aux labels !

Parce que ce registrator est déployé dans Rancher. Il faut donc qu’il soit présent sur tous les hosts (puisqu’il lit la liste des conteneurs depuius le démon Docker local) (d’où le io.rancher.scheduler.global). Il faut également qu’il ait accès au DNS (d’où le io.rancher.container.dns). Les autres options sont moins indispensables.

Et paf !

Une fois que ces opérations sont effectuées, vos conteneurs seront automatiquement enregistrés dans Consul au démarrage, et supprimés de Consul lorsqu’ils s’arrêtent).

Mais qu’est-ce que vous avez fait de Javascript ?

Note préliminaire : cet article est avant tout un recueil de mes opinions. Il ne s’agit pas de faits, ou d’éléments soigneusement étudiés, mais plus d’irritations, d’incompréhensions. (Vu que cet article est en train de devenir mon plus lu, je préfère baliser le terrain)

Je viens de finir un bon paquet de développement Javascript « full-stack » avec Nodejs, Vuejs et tout un tas de trucs. Et franchement,

(oui, il va y avoir un paquet de tweets, parce que j’ai eu l’occasion d’en parler)

Mais qu’est-ce que vous avez fait au langage ?

a7fc014bf8488b37d60ed7dc6c76acbff5d3fb7491ff3cbd302a4a9a4743ef14Quand je faisais du Javascript, avant, on avait un chouette langage fonctionnel salement déguisé en Java par le biais d’un marketting stupide. Et un jour, V8 est arrivé, et comme l’héritage par prototype, c’est pas cool, ES5 et ES6 se sont succédés à un train d’enfer pour apporter toutes les folies des langages orientées objet : import, héritage, interfaces, closures, théoriquement, vous avez maintenant tout ça.

Le cas particulier de l’import

Ca marche comment l’import ? En Javascript classique, ça marche facilement avec requirejs (la doc est claire, et le besoin assez simple). Avec ça, écrire une application un peu complexe, c’est quand même raisonnablement facile (je le sais, je l’ai fait). Mais en ES6, si vous êtes côté serveur (dans Nodejs, kwa), vous écrivez

const expect = require('expect.js')

Mais côté client, vous écrivez

import localForage from 'localforage'

Mais c’est vraiment génial, cette idée de NE PAS UTILISER LA MEME SYNTAXE DANS DIFFERENTS ENVIRONNEMENTS ! Je ne sais pas combien de langages précédents ont eu cette idée … douteuse. Tout ce que je sais, c’est que je n’en connais aucun.

Non mais static, c’est static ou bien ?

Oui, parce que bon, superposer les concepts Java/C# sur une base Lisp, ça donne parfois des résultats curieux.

Du coup, quand vous créez une classe comme ça

class CaVaMarcher {
	static uneFonction() {
	}
	
	static uneAutre() {
		this.uneFonction()
	}
}

Est-ce que ça marche ? Eh bien je n’en sais rien. Mon code me dit que oui, mais ma tête me dit que non. PARCE QUE STATIC AVEC THIIS C’EST ENCORE UNE IDEE GENIALE ! A la décharge des fous qui ont créé ES5/ES6, this a toujours été un problème du Javascript.

Mais qu’est-ce que vous avez fait au build ?

Parce que bon, jusqu’à node/npm, livrer un projet JS, c’était pas super dur : tu prends tes fichiers, si tu es audacieux tu les minifie (mais en vrai ça n’est pas si important si tu caches bien ton JS, ou que tu utilises un CDN), tu les mets dans ton WEB-INF/resources (en Java), et BAM, c’est servi.

Webpack de l’enfer

escapefromhellgraphicEn 2017, comme tu fais de l’ES6, mais que ton navigateur ne le supporte pas forcément, tu passes par webpack pour le transformer en honnête Javascript.

Et dans quel enfer tu t’enfonces ? A côté de ça, générer les interfaces des EJB 1.0 avec ejbgen c’était de la rigolade. Que je vous raconte. Le truc génère un gros fichier Javascript (5 Mo pour notre application) à partir du paquet de code, d’images, de CSS (compilé depuis des préprocesseurs, parce que franchement, la syntaxe CSS n’est pas terriblement lisible – qu’ils disent). Pour ça, il faut configurer ça avec un fichier webpack.js à la syntaxe … Tellement merdique. Regardez donc cet exemple. C’est un cas vraiment super simple qui ne fait pas grand chose de sophistiqué. Et pourtant, c’est déja la merde non documentée. Alors quand il faut ajouter des trucs comme vuejs (j’en reparlerai, pas de panique), ça devient incroyablement tordu.

Surtout avec les histoires de sourcemap (qui sont un authentique exemple de complexité accidentelle) qui sont loin de marcher aussi bien qu’imaginé.

Du coup, webpack, ça marche, mais franchement, ça a un côté terrifiant de complexité inutile dans le concept et dans l’implémentation. Heureusement, le reste du build cache ça.

Non mais ce build JS

npm de merde

dessin-de-merdeLà ça m’énerve vraiment. Quand ces folies de build ES5/ES6 ont commencé, et que les besoins de gérer un cycle de vie et des dépendances se sont posés, il me semble que les Javascripteurs auraient pu, à défaut d’utiliser, tout au moins copier les idées de maven, par exemple, ou d’autres build tools du monde Java (ou d’autres, mais je ne les connais pas). Parce que franchement, les mecs qui ont créé npm (qui a fourni le format canonique du package.json) ne se sont pas trop fait chier : une liste de dépendances, et une map associant des noms de commandes, et c’est marre. Pareil pour la récupération des dépendances : les mettre dans un dossier node_modules dans le projet, sans trop se soucier de la version téléchargée, c’est une PUTAIN D’IDEE DE MERDE.

Yarn de super-merde

800px-kin_no_unkoA cause des défauts invraissemblables de npm, les mecs de facebook ont créé yarn qui « ccorige le problème des versions incorrectes ». PUTAIN MAIS ILS NE POUVAIENT PAS ETRE AMBITIEUX ? Parce que bon, d’accord, ces histoires de dépendances incertaines, c’est un problème. Mais il y en a d’autres.

Comme par exemple le fait que les commandes soient dans cette saleté de map, et soient en fait des exécutables système (qui doivent donc être dans le PATH, et ne marchent donc pas sous Windows – gg les gars).

Ou comme le fait qu’il n’y ait aucune espèce de build standard, et qu’il faut donc tout réécrire dans chaque projet.

Ou comme le fait qu’il ne soit pas possible de définir de modèle de projet, ou de modularisation du build.

Franchement, yarn, c’est bien de l’esbrouffe.

Et ces frameworks de merde

wrong-tool-pizzaParce que bon, angular, c’est l’horreur, tout le monde le sait, ça a été conçu par des mecs qui avaient trop fait de développement JavaEE et en avaient perdu l’esprit. React, je peux pas en dire du mal (mis à part le fait que si tu t’en sers sans la surcouche de Redux, t’as l’air d’être dans la merde, puisque tout le monde te dit qu’il faut utiliser Redux).

Du coup, forcément, tu suis tout le monde comme un mouton, et tu prends vuejs avec l’impression d’être un putain de révolutionnaire. Bon, c’est dommage pour toi, parce que Ractivejs, c’est comme vuejs, mais en mieux (si si, en mieux).

D’abord, t’as pas le concept complètement con de fichier .vue dans lequel tu mélanges le HTML, le Javascript, et le CSS. Parce que qu’est-ce que vous avez PUTAIN DE PAS COMPRIS DANS LA SEPARATION DES RESPONSABILITES ? Je veux dire, quand t’écris ton composant, tu passes pas ton temps à modifier les trois en même temps, si ? En bonus, le fichier .vue, ben ton navigateur ne le comprend pas. Du coup, tu dois aller modifier ton webpack.config.js qui était déja bien merdique pour utiliser le vue-loader, qui fout un peu la merde avec le sass-loader. Bon, mais ce problème de build n’est en fait qu’un épiphénomène.

Ben oui, parce que vuejs fournit peut-être des « composants », mais il faut encore que tu utilises un framework CSS, sinon tu vas galérer avec les resets CSS. Du coup, tu te rajoutes Bulma (oui, le nom est merdique pour les recherches dans Google) par exemple, mais tu dois aussi l’intégrer dans webpack parce qu’il est fourni en SCSS (re-argh).

Et bien sûr, c’est quand tu ajoutes Bulma, vuejs, et toutes tes dépendances, que ton fichier JS généré atteint les 5 Mo. 5 Mo, tout ça parce que tu ne veux pas que l’utilisateur attende au démarrage de ta page. Non mais qu’est-ce que c’est que cette merde ? Tout ça pour un PUTAIN DE SITE MOBILE. Comment vous croyez que ça peut marcher avec une connexion un peu faible ? Ben mal. Très mal. Trop mal.

Et ce offline de merde

pas-de-signal-panneLà, pour le coup, c’est chaud, mais je veux bien comprendre le concept. Quand ton navigateur est déconnecté, pour pouvoir utiliser l’application web, tu dois stocker toutes tes données dans le cache local.

Mais là, tu fais comment ? Tu utilises localForage directement ? Ou tu passes par des web workers ? Et là, j’atteinds ma limite, donc je ne peux pas râler en majuscules.

Mais pour tout le reste, clairement, le monde Javascript déconne à pleins tubes. J’espère bien que ça changera, parce que là, c’est super pour que les sociétés de service fourguent des consultants qui connaissent juste le framework à la mode. Mais honnêtement, c’est pas comme ça qu’on produit du logiciel durable. Mais est-ce que ça fait partie des besoins des clients ? Je n’en sais rien.

Mais du coup tu vas refuser de faire du Javascript ?

Non, parce que dans les bonnes conditions (donc sans node, sans webpack, sans framework aux idées à la con), développer une appli web Javascript (par exemple avec requirejs, Ractivejs, et un peu d’axios pour les requêtes Ajax, le tout en Javascript classique) est assez plaisant, et surtout très simple. Par contre, les outils actuels du développeur full stack Javascript sont, à mon sens, à la fois insuffisants et conceptuellement incorrects.

Je vais me retrousser les manches

Comme tous les ans, en rentrant de vacances, j’ai commencé à trier nos superbes photos des châteaux de la Loire.

Donc paf, je lance GeoSetter (dont l’intégration Google Maps ne marche plus depuis un moment), j’intègre tous mes fichiers GPX, puis j’ouvre Microsoft Expression Media pour saisir les tags IPTC complémentaires … Et l’intégration avec Bing Maps ne marche plus non plus ! Oui, bon, ça fait déja deux logiciels. Dont aucun n’est à jour ni ne fonctionne parfaitement. Surtout que je renomme ensuite les photos avec XNView ! Et là, vous vous rendez bien compte que c’est n’importe quoi. Et je ne vais pas vous parler du fait que j’ai le même genre de workflow pour la musique.

Et comme je suis en ce moment dans une dynamique de création, de nouveauté, d’innovation, de découverte, et que je veux me lancer dans JavaFX, Gradle, Kotlin, et la programmation réactive, et que je cherchais un thème … eh ben c’est tout trouvé !

Donc, d’abord, je crée le projet sur Framagit.

Ensuite, je me forme un peu à Kotlin (et à Gradle, mais ça a l’air plus simple – pour l’instant).

Et après, à partir d’un peu d’étude d’iPhoto, de Microsoft Expression Media, de Daminion Tools, je me lance dans le développement de Yapo.

Oui, parce que j’aurais pu reprendre le nom d’un projet sur le même thème que j’avais précédement lancé (jPhotoOrganizer), mais j*, ça fait un peu naze comme nom, et je ne voulais pas reprendre d’existant (surtout que l’existant, en l’occurence, est caché … dans Google Code – RIP).

Mais à mon avis, pour l’instant, je vais avoir des ambitions modestes : faire une espèce d’explorateur de fichier avec des actions supplémentaires pour les images …

Les jeux de l’été 2017

Cet article est en quelque sorte une suite d’un article homonyme : les jeux de l’été.

Et comme le précédent, il liste les jeux auxquels nous avons joué.

Evidement, les précédents demeurent : Piña Pirata et Munchkin se tiennent en bonne forme. Mobile Frame Zero a été abandonné (beaucoup trop compliqué pour nos joueurs). En revanche, nous avons ajouté une extension à Munchkin : Ton destin est scellé. Ca ne change pas follement le jeu, mais ça ajoute quelques éléments bien marrants (j’ai particulièrement aimé les montures, les serviteurs sont quant à eux plus anecdotiques de mon point de vue).

Mais nous avons également ajouté à la ludothèque l’excellent Carcassonne, qui est vraiment chouette. Les règles sont simples, mais leur intersection crée des situations délicieusement tordues, où on peut facilement avoir l’impression de gagner la partie alors qu’un concurrent a posé quelques paysans habiles qui vont retourner le sort en sa faveur au décompte des points. Aussi sympathique que rempli de rebondissements.