# Moins de poudre de perlimpinpin, plus de contexte [Opinion, Performances]
par Thomas Broyer
Dans la même veine que le “désenchantement logiciel” du mois dernier, cet article appelle les développeurs à prendre leurs responsabilités, mais cette fois concernant la performance des applications : arrêtez d’appliquer bêtement de la poudre de perlimpinpin censée améliorer les performances de vos applications, et prenez le temps de mesurer et de réfléchir (et attention aux microbenchmarks !). Tout est affaire de compromis entre la performance et autre chose, et parfois, le gain en performance ne vaut pas le coup/coût.
Parlant de responsabilités, il y a plus de 40 ans, Gary Kildall s’inspirait d’une fonctionnalité d’Unix pour son système d’exploitation CP/M. Cette fonctionnalité allait ensuite être copiée dans QDOS, qui deviendra PC-DOS puis MS-DOS. Le code existe toujours dans Windows 10, mais aujourd’hui le fonctionnement est totalement inattendu pour les utilisateurs. It’s not a bug, it’s a feature. Cette histoire nous rappelle que la bonne conception des fonctionnalités, et leur évolution dans le temps, est essentielle dans notre métier. Ici, tout commence avec le choix de l’implémenter dans le noyau du système plutôt que dans la commande de copie de fichier, puis le choix d’implémentation pour conserver la compatibilité ascendante quand PC-DOS 2.0 apporta le support des répertoires, et enfin de conserver cette dette technique jusqu’à aujourd’hui !
# Firefox Monitor (suite) [Sécurité, Vie privée, Données personnelles]
par Xavier Calland
Nous vous en parlions dans notre Best of Tech #1, Mozilla sortait Firefox Monitor pour vérifier si vos adresses mails et mots de passe ont fuité sur internet.
Un mois plus tard, Mozilla fait évoluer Firefox Monitor se dote d’une traduction dans 26 langues.
De plus Firefox va notifier les utilisateurs lorsqu’ils visitent un site ayant récemment fait l’objet d’une fuite de données.
# L’API hooks débarque dans React [React, JS, Hooks]
Par Mathieu Sanchez
L’équipe en charge de React chez Facebook a introduit une nouvelle API visant à simplifier la réutilisation de composants ; diminuer fortement les (trop) nombreuses couches de “provider”, “HOCs” et autres abstractions autour des composants. De plus, elle permet de se passer des classes au profit de composants fonctionnels.
À noter qu’en plus du typage pour Flow, le typage de cette nouvelle API existe déjà pour TypeScript.
# Le guide intergalactique du Javascript [JS, Handbook]
Par Guillaume Poittevin
Cet article assez détaillé sur Javascript m’a paru très intéressant. La première partie expliquant assez bien les différentes versions de Javascript, notamment leur nommage histoire, que tout le monde puisse s’y retrouver, et quel version a introduit les changements principaux.
Après ces rappels, ce guide s’attache à décrire les principales fonctionnalités du langage, ce qui permettra à chacun d’écrire du Javascript moderne et efficace.
Pour finir quelques bonnes pratiques sont également données en fin d’article.
# Démystifier console.log() [JS, Debug]
Par Alexandre Nicolas
Quand il s’agit de débugger une application Javascript, console.log() s’impose généralement comme l’outil par défaut chez de nombreux développeurs. Il est important de noter que l’objet « console » dispose d’une riche panoplie de fonctions supplémentaires pouvant faciliter la vie du développeur sur ce qui est loggé (Mise en forme, temps d’exécution, stack d’appels, …).
Si vous voulez en savoir plus, c’est ici !
# J2Cl [JS, Java, GWT]
par Thomas Broyer
Après des années (au moins 3 !) de développement, Google a enfin rendu public son nouveau compilateur source-to-source Java-to-JS. Partant de code source Java, le compilateur va produire du code JavaScript prêt à être compilé/optimisé par leur Closure Compiler, d’où son nom : J2Cl, aka Java to Closure. En interne, J2Cl est utilisé par GMail, Docs, Slides et Calendar, entre autres, et a remplacé GWT dans certaines de ces applications. Pour Google, le but est de partager du code métier entre toutes les plateformes : les serveurs, les applications Android, les applications iOS (avec J2ObjC), et enfin le web (avec J2Cl). Lors du lancement d’Inbox il y a 4 ans, Google avait annoncé partager ainsi 70% du code entre toutes les plateformes, le reste à charge pour chacune étant l’interface utilisateur, le stockage éventuel, et les interactions réseaux. GWT était alors utilisé, avec déjà de nombreuses modifications spécifiques, mais son approche monolithique le rendait difficile à intégrer avec les outils de développement JavaScript de Google, et notamment le reste des développements en JavaScript “pur”.
Avec cette nouvelle approche, une bibliothèque Java est transformée en une bibliothèque JavaScript, telle qu’elle aurait pu être écrite directement. La phase de compilation/optimisation laissée au Closure Compiler permet ainsi d’intégrer idiomatiquement des développements réalisés en JavaScript par les développeurs frontend.
GWT 3 sera d’ailleurs une refondation de GWT basée sur ce nouveau compilateur et le Closure Compiler, et pour la première fois entièrement piloté par la communauté opensource !
# Anonymiser vos données [PostgreSQL, RGPD]
Par Aurélien Morlé
A l’heure du RGPD, le besoin d’anonymiser une base de données est devenu de plus en plus récurrent et quoi de plus simple que de le faire de façon déclarative directement dans la base de données ? C’est l’idée que propose Damien Clochard dans cet outil open source qui ne demande qu’à évoluer. Le projet en est encore à l’état de prototype mais il n’en est pas moins intéressant à suivre et contribuer.
Cela se présente sous la forme d’une extension nommée PostgreSQL Anonymizer qui permet de masquer ou remplacer les données à caractère personnel et les données sensibles en général. L’extension peut être utilisée pour mettre un masque sur certains utilisateurs ou pour modifier les données sensibles de manière permanente. Plusieurs méthodes sont possibles : la randomisation, le brouillage partiel ou encore les règles ad-hoc.
Si vous souhaitez en savoir plus, c’est ici ! le projet est disponible sur gitlab.
# Postgresql PITR via blog LeBonCoin
Par Alexis Venner
L’équipe tech du Bon Coin revient sur différentes méthodes de backup de bases de données PostgreSQL : dumps « classiques » vs Point In Time Recovery. Avantages et inconvénients des différentes techniques, aspects pratiques, l’article répond à la fameuse question : « quelle solution choisir ? ». Spoiler : ça dépend ! Pour lire l’article, c’est par ici
1 Pingback