Nouvelle version de DataGrip; quelle bonne surprise!

Hier soir, je reçois une notification pour une nouvelle version de DataGrip (DataGrip 2019.1). Même si j’ai le All Products Pack de JetBrains, je n’utilise pas DataGrip depuis un bon moment puisqu’il ne supporte pas la base de données Cassandra. Ainsi, je suis curieux de savoir si cette célèbre base de données de type NoSql est dans leur roadmap. Après quelques recherche sur Google: oui, ça l’est ! En fait, je l’ai manqué et c’est déjà dans DataGrip depuis la version 2018.3.

Immédiatement, je le mets à jour et je redémarre une base de données Cassandra avec Docker. Malheureusement, mon précédent container est mort (paix à son âme et à ses données); je dois en reconstruire un. Pour le tester, sans redémarrer tout mon projet secret, j’ai besoin d’un schéma déjà construit avec des données. En fait, ce n’est pas si facile à trouver. La plupart des liens trouvés sont des exemples triviaux. ma meilleure trouvaille est un projet âgé de 2-4 ans mais dont la simple copie ne fonctionne pas. Je le fork en tant que projet hpwxf/killrvideo-sample-schema avec un correction rapide au sujet de l’indexation d’une colonne de type set et un fichier de configuration Docker qui active le support des fonctions définies par utilisateur. Je pousse l’image associée sur DockerHub en tant que hpwxf/cassandra. C’est parti !

Le précédent logiciel que j’utilisais pour faire mes investigations était DBeaver. Puisque je n’ai jamais acheté de licence complète pour mes rares utilisations, j’étais limité à la version d’essai de deux semaines de l’Enterprise Edition (celle qui support Cassandra; la version Community de DBeaver ne supporte pas les bases de données NoSQL). Avant de passer à DataGrip, je veux être sûr que tout ce j’ai besoin y est disponible. Pour cela, je réactive une licence d’essai de DBeaver. Je n’ai pas suffisamment de temps pour inspecter tous les aspects de ces deux logiciels et je me concentre sur ce dont j’utilise quotidiennement (ci-dessous, quelques captures d’écrans communs).

DBeaver EE data view
DBeaver EE scheme view
DataGrid data view
DataGrip scheme view
DataGrip console

Le point le plus remarquable est que l’empreinte mémoire de DataGrip est la double de ce que DBeaver EE a besoin pour ce simple exemple. Je n’ai encore idée de comment cette consommation peut évoluer sur des cas plus gros.

DataGrip n’a pas de version Community comme DBeaver et sa version d’essai dure 30 jours. Pour ma modeste utilisation et puisque j’ai déjà le All Products Pack de JetBrains, mon choix est simple: désinstaller DBeaver et poursuivre avec DataGrip.

NB: Ce post n’est en aucun cas associé à l’entreprise JetBrains. Ce propos est mon humble opinion et correspond à mes utilisations.

Expérience avec le Langage naturel

Déjà la semaine passée au salon du Big Data j’avais encore entendu parlé de traitement du langage naturel, et là au détour de recherches sur l’analyse syntaxique pour les langages C/C++ et Scala, je suis tout d’abord tombé sur NLTK qui me semblait déjà pas mal. Ensuite, sans trop d’effort, je suis tombé sur spaCy qui m’a tout de suite intrigué et un peu séduit (même si je n’en ai pas vraiment besoin en ce moment). C’est un techno à base de machine learning et, qui plus est, on peut tout à fait testé soit même ! Je n’ai pas attendu mon reste pour tester cela.

spaCy fournit une comparaison (je n’ai pas vérifié les infos) face à la concurrence, ce qui donne en plus un état de l’art.

Pour commencer, je me suis fait une image docker pour ne pas polluer mon environnement et jouer avec rapidement depuis n’importe où.

Il existe aussi d’autres sympathiques images déjà prêtes comme celle de https://github.com/jgontrum/spacy-api-docker qui est interrogeable via une API REST.

spaCy est un produit de ExplosionAI qui offre gentiment ces outils (demos en ligne et code sur GitHub) à côté d’une offre commerciale (je trouve que c’est une des meilleures techniques pour inspirer confiance et démontrer ses capacités).

L’API est complètement documentée ici et en bonus, j’ai trouvé ce mémo. A partid là, pour jouer un peu avec, à partir de l’image docker citée ci-dessus, j’ai créé ce petit script de démonstration (il existe des avec d’autres exemples de code). Si vous avez la flemme vous pouvez visualiser le résultat en ligne.

Le résultat est cette sortie :

Tokens:
	 ADJ Next
	 NOUN friday
	 ADP at
	 NUM 1
	 NOUN PM
	 PUNCT ,
	 PRON I
	 VERB will
	 VERB have
	 NOUN lunch
	 ADP in
	 PROPN Paris
	 ADP with
	 DET my
	 NOUN friend
	 PROPN Chris
	 PUNCT ,
	 DET the
	 NOUN one
	 PRON who
	 VERB has
	 DET a
	 ADJ red
	 NOUN hair
	 NOUN cat
	 PUNCT .
Entities [('Next friday', 'DATE'), ('1 PM', 'TIME'), ('Paris', 'GPE'), ('Chris', 'PERSON')]

Et ces éléments au format SVG et HTML:

Next friday DATE at 1 PM TIME , I will have lunch in Paris GPE with my friend Chris PERSON , the one who has a red hair cat.

Je pense que j’ai désormais suffisamment digressé de mon sujet principal; je retourne à mon analyse statique.