# Java s’inspire de Kotlin

Par Thomas Broyer

Je dis Kotlin ici, mais c’est également vrai pour Scala, C# et d’autres langages : parmi les travaux en cours sur le langage Java, on trouve plusieurs sujets qui ressemblent fort à ce qu’on peut déjà trouver en Kotlin.

On avait déjà eu droit aux blocs de texte et aux expressions switch (dont la syntaxe même rappelle les when de Kotlin), qui continuent d’ailleurs d’évoluer ; on attend maintenant pour JDK 14 le pattern matching pour les instanceof (qui fait beaucoup penser aux smart casts de Kotlin, mais en plus verbeux, forcément) et les records (qui rappellent les data class de Kotlin sur certains aspects). Dans les prochaines versions, on peut s’attendre à voir apparaître les sealed types (qui, combinés aux records, apporteront à Java les types algébriques de données), les classes inline (proches des records mais avec des caractéristiques d’utilisation de la mémoire bien différentes), les champs lazy (limités aux champs statiques ici), les corps de méthodes concis, et bien sûr l’intégration du pattern matching dans les switch.

D’ici la prochaine LTS (JDK 17 pour rappel), on aura peut-être un langage Java bien amélioré et ressemblant de plus en plus à Kotlin ; et en attendant, utilisons Kotlin !

# Redhat libère Quay et s’attaque encore un peu plus à la suprématie de Docker

Par Guillaume Poittevin

« Docker par ci, docker par là, docker par ci, docker par là, docker par ci, … »

Mais finalement utiliser des conteneurs Linux (LXC) n’est pas l’apanage de Docker. Et Redhat depuis quelques temps a passé la vitesse supérieure pour proposer sa vision des conteneurs Linux. Buildah pour construire des images. Podman pour lancer et manager des conteneurs. OpenShift pour le déploiement et l’orchestration.

Ce mois ci Redhat libère Quay son dépôt privé d’image, la boucle est donc bouclée. Il est désormais possible de faire tout ce que propose Docker avec les outils Redhat.

Quay embarque également le scan de sécurité s’appuyant sur Clair.

# Accessibilité et développement web

Par Xavier Calland

L’accessibilité des sites et applications est un enjeu majeur pour le web et c’est un aspect que tout développeur devrait avoir en tête au quotidien.

Heureusement pour nous, c’est un sujet qui préoccupe beaucoup de monde dans le domaine du développement informatique.

On peut noter par exemple :

• Jen Simmons nous présente les différents outils présents dans Firefox notamment pour vérifier les contrastes et simuler les différents types de dyschromatopsie. Chrome intègre également des fonctionnalités de contrôle des contrastes.
• Nolan Lawson nous livre son retour d’expérience après avoir travaillé à rendre une application plus accessible.
• Des extensions comme accessibilityinsights ou axe sont disponibles pour les navigateurs récents.

# Jsonpath – un langage de requête pour le format json [PostgreSQL]

Par Aurélien Morlé

On connaît tous le JSON (JavaScript Object Notation) mais un peu moins déjà le JsonPath qui est un peu comme xpath pour le format XML. Le support de JsonPath est arrivé dans PostgreSQL 12 et cela ouvre de nombreuses possibilités. C’est ce que je vous propose de découvrir à travers la présentation de Oleg Bartunov durant la PostgreSQL Conference Europe qui a eu lieu à Milan le mois dernier. Vous trouverez cette présentation ici (en anglais).

# Comment HTTP/2 modifie nos Web APIs

Par Thomas Broyer

Mark Nottingham, co-président des groupes de travail HTTP et QUIC à l’IETF, revient ici sur ce que le multiplexing apporté par HTTP/2 (et HTTP/3) implique pour la conception des APIs HTTP. En bref, alors qu’avec HTTP/1.1 une requête est relativement “coûteuse”, ce n’est plus du tout le cas avec HTTP/2 ; tous les mécanismes de batching imaginés alors pour contourner cette limitation (dans GraphQL, HAL et JSON:API par exemple) deviennent donc obsolètes, voire contre-productifs, et Mark Nottingham nous enjoint à créer des APIs les plus “détaillées” / précises (fine-grained) possibles.

Basé sur ce même constat, Kévin Dunglas, un français (cocorico !), a imaginé Vulcain, un protocole (et son implémentation de référence) basé sur HTTP/2 et tirant partie du HTTP/2 Push pour améliorer la performance de requêtes en cascade (le cas nominal étant la récupération d’une liste, suivi de la récupération des détails de chacun des éléments de la liste ; avec Vulcain, le client peut indiquer au serveur qu’il sera intéressé par ces détails, et le serveur va alors les “pousser” en même temps que la première réponse ; on obtient ainsi un semblant de batching, sans aucun compromis concernant la sémantique HTTP et notamment la “cachabilité” des réponses).

Le débat REST vs GraphQL touche-t-il à sa fin ?

# Les anciens navigateurs ne doivent pas dégrader les performances des plus récents, et comment bien le gérer

Par Thomas Broyer

Instagram a publié un retour d’expérience concernant les performances de son code JavaScript, et comment envoyer moins de code aux navigateurs. Basés sur leurs statistiques d’utilisation, ils ont décidé de produire deux sorties différentes à partir de leur code source : une optimisée pour les navigateurs modernes (leur plus grande audience), et une autre pour tous les autres navigateurs. L’idée est de ne pas pénaliser les utilisateurs de navigateurs récents en leur servant du code JavaScript émulant des fonctionnalités qu’ils supportent nativement, ces émulations étant réservées aux navigateurs plus anciens. Les premiers recevront donc moins de code, pour de meilleures performances, et ces derniers plus de code, émulant des fonctionnalités qu’ils ne supportent pas nativement.

Dans la même veine, on a vu apparaître ce mois-ci un nouveau plugin Babel, preset-modules, promettant de bien meilleures optimisations que preset-env lorsqu’on cible des navigateurs récents (notamment ceux supportant les modules ES2015).

Instagram utilise également une “astuce” d’optimisation, les inline requires, pour éviter d’exécuter du code avant qu’il ne soit réellement nécessaire. Il existe plusieurs plugins Babel promettant la même fonctionnalité (on citera https://www.npmjs.com/package/babel-plugin-lazy-require et https://www.npmjs.com/package/babel-plugin-transform-inline-imports-commonjs par exemple), mais bizarrement ils n’ont reçu aucune mise à jour depuis quelques temps… à évaluer et à suivre…

# Une salle de gym découvre la cybersécurité

Par Quentin Aymard

Bien loin des complexes catastrophes cyber dont on entend parler régulièrement, la sécurité est parfois l’affaire de petites actions locales et peu coûteuses. Un chercheur en sécurité a ainsi découvert sur les réseaux sociaux une photo innocemment prise par un employé d’une salle de sport sur son lieu de travail. Problème ? Un coin de l’image montre un écran d’ordinateur portant un sticker avec identifiant email et mot de passe parfaitement lisibles… Le chercheur a donc contacté la salle de sport afin que ledit mot de passe soit changé. Il a ensuite posté cette petite histoire sur Twitter, dont la morale est que se reposer sur la supposition qu’aucun acteur malveillant n’a accès aux locaux est une grosse erreur. Une simple inattention, une photo hasardeuse, un regard curieux à travers la fenêtre peuvent entraîner de sérieuses conséquences, facilement évitables à l’aide de quelques bonnes pratiques !

# Les choses à ne pas faire en SQL [PostgreSQL]

Par Aurélien Morlé

Comme dans tout langage, en SQL il a certains pièges dans lesquels parfois nous tombons dedans quand nous débutons … Et cela engendre souvent des bugs applicatifs qui ne sont pas toujours évidents à identifier. Ce sont des erreurs assez simples mais qui peuvent poser de nombreux problèmes typiquement une division par zéro… ou un count sur un champ qui peut être null… bref tout un tas de petites choses que nous savons avec le temps mais qui parfois peuvent jouer de mauvais tour. Ces erreurs communément faites au moins une fois par tout à chacun sont répertoriés dans cet article et donne aussi le moyen pour s’en prémunir.