# La gestion du temps en Java

par Xavier Calland

Dans la lignée de sa présentation sur UTC, Édouard Siha (@edseeya) nous propose un article qui nous plonge dans la gestion des dates et du temps dans une application Java. 

Avant de rappeler quelques bonnes pratiques au niveau Java (notamment l’utilisation de java.time) il est avant tout question de présenter comment définit et mesure le temps. Ainsi UT, TIA et UTC n’auront plus de secrets, indispensable pour savoir ce qu’on veut représenter dans nos applications.

De mon point vue, la gestion du temps dans les applications c’est comme pour la gestion de l’encodage. C’est souvent source de problèmes et d’erreurs pour ces concepts au final pas si complexes, il faut juste passer cette barrière psychologique de “c’est compliqué je n’y comprends rien” et se mettre dedans.

Et comme une application Java va souvent stocker ces données en base, la représentation du temps est également une question à se poser dans la modélisation de la base de données. Postgresql nous rappelle la correspondance entre les types Java et Postgresql.

À noter que Javascript n’est pas en reste avec cette proposition d’API “Temporal”.

# Sortie de MetaMask 8

par Charles-Henry Vagner

MetaMask est un portefeuille de crypto-monnaie Ether ou ERC-20 et une passerelle vers la blockchain Ethereum. En d’autres termes, MetaMask permet d’interagir avec les applications décentralisées déployées dans une blockchain Ethereum directement au sein des navigateurs Chrome, Firefox et Brave.

Dan Finlay qui est le Lead Developer de MetaMask a annoncé la sortie de la version 8 de l’outil sur le Medium de MetaMask. Cette mise à jour majeure apporte un certain nombre de nouveautés particulièrement intéressantes pour les utilisateurs :

  • L’interface utilisateur a été retravaillée.
  • Lorsqu’un utilisateur se connecte pour la première fois à MetaMask, son expérience est fluidifiée avec un retour après l’installation et la configuration du portefeuille.
  • L’utilisateur peut sélectionner les comptes associés à chaque site (aucun par défaut ; principe de Privacy by Design).

Et pour les développeurs :

  • LavaMoat est un ensemble d’outils qui isole les dépendances tierces lors du build. Il a été utilisé pour la mise en oeuvre du nouveau robinet MetaMask.
  • Il est maintenant possible d’encrypter et de décrypter des messages au sein des applications web3, avec le consentement systématique de l’utilisateur.
  • La nouvelle API fournisseur ERC-1193 à base de promesses et de souscriptions est disponible.

Pour finir, Dan Finlay nous indique que l’objet web3 jusqu’alors injecté par MetaMask est déprécié. En remplacement, il convient d’utiliser window.ethereum ou ether.js sans quoi les applications ne fonctionneront plus à terme.

# Trilogie pédagogique pour la mise en oeuvre de contraintes spatiales avec PostGIS

Par Cédric Darbon

Comme toute base de données « classique », la base de donnée géographique est le réceptacle de données en provenance d’origines diverses (client SIG bureautique, extranet cartographique, ETL spatial,  etc.). Dès lors que l’on souhaite conserver l’intégrité de ses données, il convient de mettre en place des mécanismes qui garantissent cette dernière et  nous évitent de nombreux désagréments, notamment dans un contexte « multi-application ». Il n’est en effet pas si rare que la saisie d’une géométrie dans un outil s’effectue sans souci mais que sa lecture ou son export dans un autre pose problème.

Une des solutions pour éviter de déployer ces contrôles d’intégrité au sein de chaque application exploitant la base de données consiste à coder les règles directement au sein du moteur SGBD. J’invite ceux qui souhaiteraient se lancer dans cette démarche à consulter la trilogie d’articles  de Paul Ramsey (le créateur de PostGIS) dédiée à la mise en place de contraintes spatiales sous PostGIS.

Le premier article traite des CHECK qui peuvent être mis en place rapidement lors de la création de la table (ou après) sur les colonnes « geometry ». Dans ce cas, la géométrie entrante est analysée au regard des contraintes définies (validité avec « St_IsValid », non intersection d’éléments linéaires la composant avec « ST_IsSimple », longueur ou surface  min ou max avec « St_Length » et « St_Area », etc.). S’il est de coutume de mettre systématiquement les trois contraintes de base sur le type, le système de coordonnées et la dimension, cet article nous rappelle que les possibilités d’exploitation des CHECK avec PostGIS sont beaucoup plus larges puisque toutes les fonctions prenant en paramètre la seule géométrie en cours peuvent être exploitées pour nous alerter.

Le second article aborde la mise en place de contraintes au niveau d’une table géographique dans une logique de maintien de la cohérence spatiale d’une couche de données. Paul Ramsey met ici à profit les TRIGGERs combinés aux opérateurs de relation spatiale (“St_Intersects” ou “St_Relate” en lien avec la matrice DE-9IM) pour garantir que les règles topologiques établies (dans son exemple, non recouvrement de parcelles) sont respectées.

 

Le dernier article présente un cas d’usage plus élaboré de maintien d’un graphe routier en combinant l’utilisation de contraintes CHECK et de TRIGGERs. Il présente notamment l’intérêt de la mise en place de TRIGGERs en mode DEFERRABLE permettant de garantir que, dans son cas d’usage, la connectivité du graphe est assurée au sein de la transaction quel que soit l’ordre d’insertion des polylignes composant le graphe.

En résumé, ces 3 articles constituent au choix et selon son niveau de connaissance de PostgreSQL/PostGIS, un petit rappel qui ne fait pas de mal ou une base de travail sur laquelle entamer la réflexion sur l’intégrité de sa base de donnée spatiale.

Tweetez
Partagez
Partagez
0 Partages