Alors que je me promenais dans les allées du Devoxx, mon smartphone Android a bipé avec une notification provenant d’un « physical web » beacon. Je me suis dit que ce serait cool d’avoir également ce type de beacon pour propager ma « carte de visite » virtuelle… mais bon, j’ai pas envie d’en acheter un. Faisons avec les moyens du bord....
Dans nos modèles Meurise, MCD, SGBDR, la relation entre tables est naturelle. Avec du NoSQL, ça l’est moins. Mongo nous propose des pistes de modélisation, mais je ne trouvais pas les solutions satisfaisantes. Je m’explique. Imaginons, une collection d’auteurs et une collection d’articles. Avec un SGBDR classique on aurait : D’après Mongo, il y a 2 solutions : On inclue le document auteur (tout ou partie) dans le document article Avantage : quand on veut la liste des articles, on a les infos de l’auteur avec Inconvénient : quand l’auteur change une de ces infos présente dans le document article, il faut faire 2 mise à jour des données On a une référence de l’auteur (son id) dans le document article. Avantage : les mises à jours sont simplifiées Inconvénient : on est forcé de récupérer la liste des articles, puis pour chacun d’eux, récupérer l’id de l’auteur, rechercher tous les auteurs dont l’id se trouve dans cette liste et enfin raccrocher l’article à son auteur. 2 requêtes et des manipulations de listes côté serveur. Mais alors est-ce possible de tout récupérer en un seul appel avec une référence de l’auteur dans l’article? Après un peu de recherche oui....
Vous voulez benchmarquer un serveur de manière rapide et simple? Bon ok, c’est pas du vrai test en charge comme ce que l’on pourrait faire avec JMetter, mais ça permet d’avoir une idée des perfs et de pouvoir comparer des évolutions....
Pour les besoins d’une conférence sur Apache Camel, je trouvais sympa d’afficher les live-tweets sous forme de notification Ubuntu pendant le déroulement des slides. (J’avais trouvé l’idée du Tweet-wall du DevoXX sympa) En creusant un peu, je suis tombé sur la librairie GTK.jar fournie par java-gnome....
Le composant camel-kafka dédié au framework Camel et permettant des interactions avec le bus Kafka est disponible : camel-kafka La documentation se tr...
Dans la même lignée que le mariage Thrift-Camel, ça me trottait depuis longtemps dans la tête de marier Kafka et Camel. Kafka est un bus événementiel très performant de type publish/subscribe. Il gère de la persistance, se coordonne avec Zookeeper fonctionne en cluster. J’avais dans l’idée de créer un composant Camel pour produire et consommer des messages et c’est chose faite....
Dans le cadre de mes pérégrinations architecturales, j’étais tombé au hasard d’un surf sur des slides présentant l’architecture ultime en terme de performances. Cette archi utilisait Thrift et Camel. Thrift servant de protocole et de transport pour communiquer avec un bus Camel. Ça m’a intrigué car le composant Thrift n’existe pas chez Camel. Alors, je me suis arraché le peu de cheveux qu’il me reste et voici la solution....
Aujourd’hui nous verrons comment publier un web service depuis Camel. Il y a plusieurs façons de le faire. En fait c’est très simple avec Spring. Cependant, ça l’est moins quand il faut traiter une requête entrante et déclencher le bon routage en fonction de la méthode invoquée....
Voici la problématique : faire un export display depuis mon PC vers une autre machine en passant par une machine intermédiaire : [root@A]# ssh -R 6000...
L’autre jour, je me suis retrouvé confronté à un problème : comment tester un Web Service en envoyant une enveloppe SOAP uniquement en ligne de commande (sans soapUI). La solution, c’est CURL....
