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.

Publicités

Chtijug et barbecue

Gravitee

Bon, je connais les speakers depuis …​ 10 ans facile. Et ça fait plaisir de les voir sur scène !

Gravitee, un API Manager

Donc l’API management (voir la session chez Kiabi – et la page Wikipedia de définition), ça permet de créer et de publier des API, de les maintenir en état de marche, et enfin de collecter des statistiques d’usage.

D’un point de vue architecture, il y a principalement deux composants

  1. Un portail d’API, permettant l’enregistrement d’utilisateurs, la découverte des API.
  2. Une gateway, qui va exécuter les appels en les dispatchant auprès des services backend.

Pour les clients, ça peut être

  • Une façon d’exposer une API
  • Un reverse proxy
  • Un ESB pour les API REST (mais ça c’est faux : il y a tout un tas de différences entre l’API manager et l’ESB)

Gravitee, le produit

Existe depuis 2015, et nos speakers ont créé la société GraviteeSource pour fournir le conseil, la formation autour du produit.

Démonstration de création d’API

A partir d’un serveur exposant l’API, on peut facilement créer les éléments dans Gravitee grâce …​ à un wizard ! Il faut noter que, dans le wizard simple, la notion de plan de consomation (pour pouvoir facturer facilement, évidement). Par ailleurs, on peut importer facilement de la doc RAML/SWAGGER/Markdown. Et c’est fini, l’API est déployable

Consomation d’API

Une fois l’API créée, il faut créer une souscription pour pouvoir l’utiliser.

Et là, les petits gars, vous avez déja de quoi remplir quelques rapports de bugs pour améliorer vos présentations 😉

Cela dit, les écrans d’administration sont sacrément bien fichus, avec une vision complète des temps de réponse et de la qualité des réponses.

Réécriture de la réponse

L’un des éléments intéressants d’un API manager, c’est la possibilité de modifier les requêtes pendant leur exécution grâce à des politiques de transformation préconçues (des transformations simples) ou …​ du Groovy (j’aime beaucoup), ou aussi de créer un cache au niveau de la gateway.

Développement de policy

Comme gravitee est développé en Java avec des mécanismes de plugins typiques, ajouter une policy, c’est assez facile, et c’est parti …​ avec un archétype Maven ! Et je dois dire que le code produit par la génération d’archétype est, un peu comme pour Wisdom, assez complet.

Web multi-écrans

J’ai déja vu la présentation sur Youtube, mais en live, ça n’est évidement pas pareil …​

Un truc marrant dès le début de la présentation : Hubert nous parle de 2008 et de ses deux écrans. De mémoire, avec mon voisin de derrière, en 2009, on bossait dans une boîte où chaque poste avait 3 écrans sur deux machines avec Synergy …​ Et encore, ça n’était pas ma première fois avec plusieurs écrans.

Donc, plusieurs écrans, et des interfaces avec plusieurs écrans. Dans le web.

Un truc très intéressant dans sa présentation, c’est qu’il intègre un avis contraire, celui de quelqu’un qui affirme ne travailler qu’avec un seul écran.

Et Hubert enchaîne ensuite avec les différentes techniques permettant la communication : window.open, et autres hacks. J’ai malheureusement un trou dans mes notes. Dans mes souvenirs, il y a un ou deux hacks, et une technologie parfaite pour les applis du futur, mais pas forcément disponible partout.

Cela dit, il y a une faille dans cette présentation (formellement impressionante) : le cas d’usage est quand même super limité : faire du web, sur plusieurs écrans, sans serveur …​ mis à part TiddliWiki, je connais peu de projets sur ce créneau. D’ailleurs, même les applications comme Atom, Brackets, Code ont un serveur web (oui, dans le même process, mais conceptuellement, il y a quand même un client, et un serveur). Personnellement, quand j’ai le genre de besoin dont Hubert parle (avoir des clients qui communiquent entre eux), je reste simple et je mets du websocket sur mon serveur.

Conclusion

Les sujets étaient assez spécifiques, mais les speakers étaient très chouettes, et la soirée s’est finie tranquillement sur les pelouses de Norsys

Un mastodonte est-il plus léger qu’un oiseau ?

Ouais, bon, je tente le titre accrocheur.

Donc, j’ai entendu parler toute la semaine dernière de mastodon, un réseau social de microblogging décentralisé.

Autrement dit, un équivalent de twitter (avec une limite des messages à 500 caractères) qui présente l’avantage (en termes de scalabilité) de permettre l’ajout de nouvelles instances au réseau. Pour être plus clair, le réseau social n’est plus un unique site web, mais un ensemble de sites web sur des serveurs différents, dans des pays différents.

Ca me plaisait pas mal (moins d’adhérence à la silicon valley, plus de possibilité de survie du réseau, tout ça tout ça.

J’attendais juste de trouver une instance « sympathique ».

Et soudain, grâce à Camille Gévaudan, la lumière

Donc j’y suis allé, j’y ai créé un compte.

Pour l’instant, c’est sûr que le réseau est encore peut-être un peu jeune. Mais

  • Les fonctionnalités sont équivalentes à celle de Twitter
  • La liberté est plaisante
  • Le nombre d’instances est déjà élevé

Je vais donc tenter la migration complète vers mastodon : envoyer le flux RSS de Shaarli vers mastodon, puis générer un flux RSS de mastodon et l’envoyer vers Twitter.

Fiddler pour débugger à distance

Vous connaissez Fiddler ? C’est un très bon proxy de débuggage http pour Windows.

Eh bien aujourd’hui, j’ai découvert que je pouvais l’utiliser pour intercepter les requêtes entre un serveur Apache (sur une autre machine) et mon serveur web Java (lui aussi sur une autre machine). Le pire, c’est que ça n’est même pas compliqué.

Il suffit de régler le proxy pour accepter les requêtes distantes

2016-11-04-20_54_19-telerik-fiddler-options

Et de régler le proxy que fiddler utilisera pour recevoir les requêtes pour que ce soit l’autre machine

2016-11-04-20_56_38-telerik-fiddler-options

Et là, les requêtes arriveront bien d’Apache dans Fiddler pour repartir aussi sec vers le serveur.

Très cool.

 

Développeurs, il est temps de changer le monde !

A la suite de mon article précédent, j’ai réfléchi (un peu).

Et plusieurs idées ce sont assemblées dans ma tête. Je vais essayer de les articuler correctement, mais ça n’est pas si facile …

Vous vous souvenez de la matinée sur le rôle social du développeur à Devoxx ce printemps ? Non ? Dans ce cas-là, j’en ai parlé :

Et je vous invite à relire ces articles pour bien comprendre de quoi il s’agit. L’idée que j’ai tiré, sans originalité, il est vrai, de ces quatre conférences, c’est que la révolution industrielle de l’informatique va changer la donne, comme les précédentes. Pour mémoire, la révolution de l’imprimerie n’a pas vraiment été une bonne chose pour les moines copistes.

Il est déjà évident que la plupart des tâches pilotées par des workflows sont maintenant totalement définies par l’ordinateur (pensez par exemple aux centres d’appels, à la gestion des interventions des grandes entreprises, les remboursements de notes de frais, …).

Mais d’autres domaines vont bientôt tomber dans l’escarcelle des informaticiens : la bancassurance, la médecine. Le plus important étant évidement l’implémentation de la loi. En effet, si la loi est implémentée par du code (c’est le cas du code des impôts, par exemple), ce n’est plus vraiment le politicien qui choisit comme l’impôt est prélevé, mais le code écrit par un informaticien, quand bien même c’est un sous-traitant d’une grosse SSII en contrat avec le gouvernement.

Or actuellement, nos représentants politiques (députés, maires, ministres), sont là pour … nous représenter, parce que leur connaissance de la loi est plus grande, parce qu’ils sont des personnes clé.

En conséquence, on retrouve par exemple dans l’assemblée nationale (je ne retrouve plus les statistiques que j’avais pu consulter il y a quelques années)

  • des avocats
  • des notaires
  • des médecins
  • des fonctionnaires (je sais, ça n’est pas un métier, mais un statut), au premier rang desquels une palanquée d’inspecteurs des impôts.
  • et un agriculteur

Est-ce qu’il y a des informaticiens dans le tas ? je ne crois pas, non.

Est-ce qu’il y a des gens qui comprennent ce qu’est réellement la révolution numérique ? Je suis à peu près certain que non.

Alors ?

Qu’est-ce qu’il faut faire ?

Vous vous doutez bien de la terrible réponse que je vais apporter : nous, les pionniers du digital, devons trouver des représentants, des champions, et les aider à prendre des responsabilités politiques, pour éviter que les politiques ne décident un jour que toutes ces histoires d’ordinateurs sont décidément trop dangereuses pour leur pouvoir, ce qui arrivera forcément.

Pas de chti jug sur Typescript pour moi

Ce soir, c’est chtijug sur Typescript. Et en plus, le lieu a l’air sympa.

Pas parce que je n’aime pas Cyril et ses amis, bien au contraire, je trouve le boulot du chijug vraiment chouette.

Mais plutôt parce que … comment dire … tout cet écosystème Javascript me fatigue à un point fou.

Je vous explique.

J’ai fait ma première page web avec du Javascript en 1999 … ou 2000. Bon, la wayback machine a une version datant de juillet 2001. Enfin bref. A l’époque, faire du Javascript était un sale boulot.

Heureusement, jQuery a tout changé. Et pendant quelques années, faire du web dynamique était raisonnablement simple conceptuellement et techniquement.

Et puis un jour, l’apocalypse de la sur-architecture s’est pointée sous les traits de nodejs. Je ne vais pas refaire l’article contre nodejs, parce qu’il suffit de regarder quelques twits de Mario Fusco ou Sam&Max pour comprendre

Et c’est quoi le rapport avec Typescript ?

Pour être honnête, Typescript n’est pas une solution, mais un élément du problème.

En effet, de mon point de vue, les langages modernes ont été créés pour permettre aux gens d’être plus productifs que l’assembleur ou le C, par exemple. Seulement, et au risque de choquer mes camarades Javaistes, le Javascript n’est pas ce genre de langage.

Non.

Comme l’écrivait Douglas Crockford il y a … un moment, le javascript n’est pas le langage qu’on croit. Et franchement, une fois qu’on comprend que le Javascript est un langage fonctionnel s’exécutant dans un environnement peu commode, il se passe une certaine épiphanie qui permet de mieux en comprendre la réelle simplicité. Une simplicité qui rend des monstruosités comme Angular, React, ou Typescript, aussi pratiques qu’un 38 tonnes en ville.

C’est aussi pour ça (en plus de ne pas assister à une conf sans doute intéressante sur un langage qui doit sans aucun doute avoir de bons côtés) que j’ai décidé de ne plus me lancer dans des projets front-end en utilisant autre chose que des bibliothèques simples (voire élémentaires) qui remplissent proprement une fonction simple et claire. Des outils comme

  • RequireJS
  • RactiveJS
  • jQuery
  • underscoreJS

Et sorti de là, comme disait il y a bien longtemps mon prof d’info, point-barre. Du coup, forcément, ce talk sur Typescript présentait un problème d’intérêt fondamental : comment diable pouvais-je m’intéresser à un langage dont la finalité actuelle est précisément de faire quelque chose qui me répugne au plus haut point ?

#devoxxfr – L’Expérience Développeur et votre API

Et comment on fait de belles api alors ?
Evidement, ce talk parle d’apis rest/http. Mais à mon avis, ça peut se projeter sur d’autres domaines comme les interfaces entre modules (quels qu’ils soient).

Première chose à envisager : quels sont les utilisateurs ?

Donc d’abord, rendre l’api compréhensible.

Et rendre la documentation « inutile » : proposer des exemples de code, faire des guides d’utilisation (des howto, typiquement), et avoir un exemple complet d’utilisation. Toute cette documentation, écrivez-la avec des outils « connus ».
Permettre aux utilisateurs de contribuer de la doc est également une bonne façon de créer de la documentation facilement.

#devoxxfr – mon appli est secure … je crois

Allez c’est parti pour un peu de sécurité, enfin … je crois. Donc petit retour d’expérience sur la sécurité. Ou plus exactement sur les projets où on gère la sécurité à la fin.

Les MOA, les chefs de projet, ils ne parlent pas de la sécurité, parce que pour eux, ça n’est pas la sécurité.

Donc dans votre appli, vous mettez des trucs qui servent à rien : Spring security, OAuth, et même un WAF (web application firewall … genre f5, quoi).

Et comme ça arrive en fin du projet, même les simples bugs sont critiques et toute l’équipe a l’air nulle.

La sécurité, plus on s’approche des données, plus c’est fonctionnel, plus on s’éloigne, plus c’est technique.

On pourrait lire tous les bouquins de l’OWASP et comprendre ce qu’ils font, ou on pourrait … contrôler et valider que ça marche bien (autrement dit faire des tests).

Et donc, ils ont développé une application (highway to URLHell) qui montre tous les points d’accès de l’application. Et rien que ça, c’est déja très chouette.

Et là, on a une belle liste de boulettes :
deleteAll accessible par ‘importe quel user
dump de la base accessible
Opérations crud non protégées entre users (donc appel aux delete d’autres entrées)

ca attaque quand même assez fort en termes de liens entre authentification et autorisation.

Clairement, leur outil H2H est une super idée pour identifier le périmètre d’attaque d’une application. Et je vais sans doute le tester assez prochainement.

#devoxxfr – l’ISS sur mon portable

Comme le types algébriques est annulé (le speaker s’est perdu dans Devoxx), on passe tout de suite à l’ISS sur le portable d’Audrey Neveu.

Et à priori, il sera question d’ionic … déjà vu au chtijug il me semble. Et pour alimenter ionic, Audrey va utiliser streamdata.io (entreprise chez laquelle Audrey est évangéliste). Comme ionic est déjà vu, je vous le laisse de côté …

Cela dit, pour les données, il faut faire du temps réel. Pour faire du temps réel, on va semble-t-il prendre du server-side-events, solution sur laquelle se base streamdata.io. Et manifestement, c’est une solution qui fait tout un tas de trucs bien malins.

Et c’est parti pour le dev ionic/cordova/angular/streamdata/…
Et ça va très très vite jusqu’à la fin .. qui montre bien la position de l’ISS en temps réel.

Cela dit, je retiens évidement l’intérêt de streamdata (que je ne connaissais pas) et de ces server-sent-events. ca a l’air bien pratique pour faire de la notification en HTTP plutôt que de l’échange bidirectionnel façon websocket.

Joyeux jour de l’internet de merde

Demain, c’est le 1er avril.

Le jour où tout est faux sur internet … et pas drôle.

J’ai envie de dire que c’était mieux avant, mais en fait ça n’est pas complètement vrai.

Avant, l’humour était d’une qualité aussi médiocre, mais il était mieux caché. Ou tout au moins, il ne suffisait pas d’avoir un ordinateur (ou pire, un iPad), pour se prétendre un geek. Et du coup, cet humour geek pouvait se permettre d’être un peu plus éllitiste. Et du coup, peut-être plus drôle … enfin, plus à mon goût.

Alors demain, il y aura sur chaque site web des blagues foireuses, des fonctionnalités bancales, voire pire, des choses qui feront rêver … jusqu’à ce qu’on comprenne que ce sont des blagues.

Alors demain, s’il vous plaît, retenez vos blagues (qui ont consommé un peu ou beaucoup de temps de développeur). Ou plutôt, laissez ça aux enfants, ce sera bien mieux.