Dans ce billet, nous allons mettre en pratique l’initiation à Vue.js reçue le mois dernier. Je vous propose de coder un pseudo Google Form avec l’aide de Vue.js, de Bootsrap et du framework de validation VeeValidate. Le formulaire HTML est généré automatiquement à partir d’un paramétrage JSON récupéré par une API REST. Nous n’aborderons pas ici la partie serveur. Un utilisateur peut sauvegarder son formulaire à l’état de brouillon afin de poursuivre ultérieurement sa saisie. Le formulaire à afficher peut donc être pré-saisi. La validation est dynamique: elle se fait au fur et à mesure de la saisie du formulaire. Voici un exemple de formulaire :

Dans le cadre d’une série d’articles sur Elasticsearch et AngularJS, j’ai eu le besoin d’indexer des données de manière offline. Cherchant une source de donnée musicale, j’ai opté pour MusicBrainz qui, à l’instar d’IMDb pour le cinéma, est une plateforme ouverte collectant des méta-données sur les artistes, leurs albums et leurs chansons puis les mettant à disposition du publique. Cette plateforme est composée d’une base de données relationnelles et d’une interface web permettant d’effectuer des recherches, de consulter les données et de participer à l’enrichissement de la base. Last.fm, The Guardian ou bien encore la BBC s’interfacent avec MusicBrainz.

Dans l’article Elastifiez la base MusicBrainz sur OpenShift, je proposais 2 méthodes pour installer la base de données : récupérer une VM ou un dump de la base PostgreSQL. Dans les 2 cas, la procédure d’installation demandait une intervention humaine. Ce billet vous en propose une 3ième : automatiser l’installation de base de données à l’aide de Docker. Après quelques lignes de commande et un peu de patience le temps de l’import du dump PostgreSQL, vous pourrez vous connecter localement à la base musicale contenant des données à jour.

Implémentation de référence de Bean Validation 1.1, Hibernate Validator 5.x requière une implémentation d’Unified Expression Language respectant la JSR-341 (correspond aux EL 2.2). EL 2.2 étant apparue avec Java EE 6, il n’est donc pas possible d’utiliser Hibernate Validator 5 dans un serveur d’application Java EE 5 et un conteneur de servlets 2.5. C’est pourquoi Hibernate Validator 5 ne fonctionne pas avec Tomcat 6.

Essayer et vous tomberez au runtime sur l’exception suivante : NoSuchMethodError: javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory)

Dans l’architecture d’une applicative n-tiers, une couche de mapping objet / objet peut intervenir à plusieurs niveaux :

1. En entrée ou en sortie d’un web service SOAP afin de convertir en objet métier les DTO générés à partir du WSDL, ou inversement.
2. Entre la couche de présentation et la couche de services métiers lorsque la première expose des DTO et la seconde travaille avec des objets métiers.
3. Entre la couche de services métiers et la couche d’accès aux données afin de mapper les entités persistances en objets métiers.

Dans le premier exemple, le développeur n’a guère le choix. Dans les 2 autres, il s’agit d’un choix d’architecture. L’introduction d’une couche de mapping n’est pas un choix à prendre à la légère : ayant pour objectif de découpler les couches, elle complexifie l’application et peut détériorer ses performances. Le choix d’en introduire une et d’utiliser un framework pour faciliter sa mise en œuvre n’est pas non plus évident.

Ce billet est découpé en 2 parties :

1. Une première dressant les avantages et les inconvénients d’utiliser Dozer par rapport à une approche manuelle,
2. et une seconde présentant les résultats d’un micro-benchmark comparant plusieurs frameworks : Dozer, Orika, Selma, MapStruct et ModelMapper.

Dans le cadre de l’ externalisation du développement d’une application, les revues de code se pratiquent différemment. En effet, la livraison du code intervient souvent après un long effet tunnel. Dès le début des développements, les développeurs doivent connaître mes attentes. Ce billet a pour objectif de les formaliser de manière synthétique.

Afin de préparer la migration technique d’un site web, j’ai eu besoin de reconstruire un environnement à l’identique de la production.

Hébergé sur un serveur Linux, ce site est propulsé par Apache 2.2, PHP 5.6 et MySQL 5.5. C’était l’occasion parfaite pour découvrir Docker. Une première étape consiste à décomposer cette plateforme LAMP en conteneurs Docker ayant chacun leur responsabilité. Voici les 3 conteneurs identifiés :

1. site: conteneur Apache et PHP sur lequel les pages PHP du site sont déployées
2. database: conteneur MySQL hébergeant la base de données utilisée par les pages PHP
3. phpmyadmin: conteneur dédié à l’outil d’administration de base de données phpMyAdmin

Pour orchestrer le démarrage des conteneurs, gérer leur configuration et définir leurs interactions, l’utilisation de l’outil Docker Compose paraissait évidente.

Dans ce billet, vous trouverez le fichier docker-compose correspondant, un Dockerfile personnalisant l’image officielle php:5.6-apache, les lignes de commandes démarrant les conteneurs sous MacOSX et alimentant la base à partir d’un script SQL.

Ouvert aux extensions, Spring Batch Admin a tout pour devenir un véritable serveur de batchs : monitoring, chargement et mise à jour à chaud de la configuration des jobs, ordonnancement, exécution de jobs sur réception de fichiers … En 3 ans, c’est la seconde fois que je suis amené à personnaliser Spring Batch Admin. Le manuel de référence fourmille d’explications. Ce billet recense quelques informations complémentaires qui, je l’espère, pourront vous être utiles :

• Transformer Spring Batch Admin en une application auto-exécutable embarquant sa propre base de données et son propre conteneur de servlet
• Personnaliser l’interface d’admin
• Adapter les templates FreeMarker au besoin métier
• Exécuter un job suite à la réception d’un fichier
• Router un message en fonction du résultat de l’exécution d’un job
• Ajouter un contrôleur REST