La mouvance actuelle dit que tout projet qui se veut un minimum industrialisé doit pouvoir détecter les anomalies au plus tôt. Pour ce faire, il est dit qu’il doit disposer de tests, qu’ils soient unitaire, d’intégration, fonctionnel ou d’acceptance.
Pour adresser le problème des tests d’intégration, il est souvent utile de démarrer l’application cible de manière embedded.
Cette article montrera comment il est possible de faire pour un contexte donné.
Ça y est… Devoxx est fini… :’( Comme je l’ai dit dans un article précédent, je ne ferai pas de compte-rendu exhaustif de présentations auxquelles j’ai pu assisté à Devoxx.
Cependant, je tenais à revenir sur la présentation “Service Versioning in SOA and Cloud” par Ignaz Wanders (@ignazw) dont le synopsis était :
Keeping versioning under control is essential in the success of a SOA. However, there are no industry standards for service versioning, thus leaving the responsibility of implementing a service versioning system up to the architects and developers within the IT enterprise.
Ça y est… Devoxx est fini… :'(
Pour ceux qui ne le sauraient pas encore, Devoxx est L’évènement à ne pas manquer.
Pour faire court, Devoxx est une conférence Java indépendante qui en est à sa 11ième édition et qui a lieu à Anvers (Belgique). Elle a également fait récemment de nombreux petits avec Devoxx France qui en est à sa 2ième édition et qui aura lieu cette année du 27 au 29 mars 2013 à Paris mais également avec le petit nouveau : Devoxx UK (du 25 au 26 mars 2013 à Londres).
Une fois n’est pas coutume (quoique…)… cet article ne sert à rien… mais a juste pour objectif d’annoncer que je quitte la société de service que j’ai rejoint il y a déjà 3 ans pour me lancer dans le vaste monde de l’indépendance…
Je quitte donc une société de service où j’ai eu la chance de rencontrer et côtoyer des personnes géniales (aussi bien humainement que professionnellement) et qui m’a donné ma chance pour essayer de suivre et de transmettre mon enthousiasme à mes joyeux camarades ;-)
Parce qu’il est parfois nécessaire de valider ses jsp, cet article fera un petit retour sur comment cela peut être mis en oeuvre.
Oui, je sais, les jsp c’est has been me diront certains… Cependant, il ne faut pas oublier que dans le monde Java, cela reste une des technologies indispensables quelle que soit le framework utilisé (j’entends par là dans le cas où les pages sont rendus dynamiquement par une technologie java).
Au cours de la vie d’un projet, il est courant d’avoir recours à des tests de charge.
Cependant, je me suis rendu compte que, trop souvent, le sujet est mal maîtrisé et donc malheureusement mal traité.
En effet, combien de fois n’ai-je pas vu un test de charge effectué avec la méthodologie “clic clic partout”, l’utilisation de Selenium, la commande curl, ou, dans le meilleur des cas, avec quelques scénarii JMeter issus de l’utilisation du recorder de ce dernier.
Lorsqu’un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d’approches :
le découper fonctionnellement, le découper techniquement. En outre, en plus de ce type de découpage, il est également important de s’interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c’est ce dernier qui est utilisé, ou faut-il en créer plusieurs?
Il y a un moment déjà, j’avais fait un article sur le plugin release oh combien pratique dans notre utilisation de maven. J’y avais mentionné les 2 goals prepare et perform qui sont les plus connus et qui, pour rappel, permettent de :
vérifier que lors du lancement du processus de génération du livrable, le code est bien conforme à ce qui se trouve sur le SCM, tagger le code source à partir duquel le livrable est produit et permettant ainsi sa reproductivité, incrémenter le numéro de version des poms, générer le livrable, et le déployer sur le remote proxy repository.
Pour ceux qui l’aurait loupé, du 18 au 20 avril 2012 dernier a eu lieu la toute première édition de Devoxx France.
L’annonce avait été faite pendant la dernière édition de Devoxx “l’originale” à Anvers en Belgique qui fêtait pour l’occasion ses 10 ans.
Ayant eu l’opportunité d’y assister (chose que je conseille vivement à tous les développeurs), j’ai écrit un petit compte rendu d’une des moultes conférences qui m’ont marquées aussi bien par sa qualité scénique que par son contenu.
Suite à de nombreuses présentations de Cassandra (faites, entre autre, par Michaël Figuière) et à une opportunité de regarder plus précisément ce qui se cachait réellement derrière cette implémentation d’une solution de la famille des produits NoSQL orienté colonnes, je vais, dans cet article, tenter de décrire ce que j’ai aimé et ce que je n’ai pas aimé sur Apache Cassandra.
Je tiens toutefois à préciser que je n’ai aucune expérience réelle sur le produit et que je ne m’appuierai donc que sur sa documentation officielle en version 1.
