Accéder au contenu principal

JavaBarcamp#4

Voici un rapide billet décrivant ce sympathique JavaBarCamp#4. Sympathique à tout point de vue, car non seulement l'organisation orchestrée par Philippe Antoine et Luc Bizeul a été sans faille, mais en plus nous avons eu le plaisir de passer la soirée dans les locaux de Google, avec au menu des goodies, un buffet très attractif et un accueil sans blingbling.

Encore une fois, j'ai été agréablement surpris de croiser des têtes connues aux profils aussi variés, qu'intéressant. En effet, ce barcamp m'a permis de joindre l'utile à l'agréable et donc de boire un bon verre de blanc tout en discutant de Spring 3.0. Et malgré moult tentatives les dimanches en famille, je me retrouve assez rapidement cantonné à updater l'antivirus de l'organisateur du repas dominical. Bref.

Côté contenu, peu de surprise car les principaux thèmes retenus ont été :
  • Spring 3,
  • Cloud computing,
  • TDD, DDD,
  • JQuery...
Et malgré quelques approches timides ma part et d'autres d'aborder des thèmes comme LIFT (merci Sadek), DSL, Life Hacking et autres joyeusetés et bien pas de quoi casser des briques. Néanmoins, il reste que les réunions auxquelles j'ai eu la chance de participer, qui étaient basées respectivement sur Spring 3.0 et TDD ont été de très bonnes qualités.

Il en résulte que Spring 3.0 va principalement nous faciliter la tache au niveau de nos architectures REST et qu'il devient full 1.5. Côté TDD, je suis encore conforté dans l'idée qu'il s'agit d'une méthodologie difficile à mettre en œuvre mais qu'une fois prise en main, elle apporte un gain de fiabilité sans comparaison. J'ai en outre découvert, qu'il existait un plugin Eclipse appelé JUnitMax permettant de jouer en continu et de manière intelligente nos tests unitaires dans notre IDE préféré. A creuser. J'espère trouver le temps pour le mettre en œuvre chez Vidal et faire un retour sur ce blog dans les jours qui viennent.

Autres post :

Commentaires

Luc a dit…
Salut, la prochaine édition des JavaCampParis aura lieu le 27 août : http://barcamp.org/JavaCampParis5 en espérant t'y voir, en attendant n'hésite pas à diffuser l'info :)

Luc

Posts les plus consultés de ce blog

Faire sa machine virtuelle sous Debian ARM avec QEMU

Introduction L'objet de ce article est de vous expliquer comment faire  pas à pas,  sa machine virtuelle Debian Wheezy   tournant sur un processeur ARM   avec QEMU . Il est relativement simple de trouver des ressources à ce sujet sur le Web, mais je voulais apporter ma pierre à l'édifice sous forme d'un petit  tutorial prêt à l'emploi. A propos d'ARM et d'émulation, il faut savoir qu'au jour d'aujourd'hui, VirtualBox est incapable de virtualiser un OS tournant sur ARM, cela m'a donc obligé à m'intéresser de plus prêt à QEMU. Et si vous vous demandez pourquoi, je veux émuler de l'ARM, vous le serez au prochain épisode... QEMU QEMU est un logiciel développé à l'origine par le célébrissime programmeur  Fabrice Bellard . Le succès de cet émulateur vient principalement du fait, qu'il est tout aussi capable d'émuler que de virtualiser. La principale différence entre l'émulation et la virtualisation est qu'un ...

Create and use a result captor in Mockito

Today I will show you how to create a Mockito captor In Mockito it exists the possibilty to use ArgumentCaptor to allow developers to verify the arguments used during the call of mocked method, but not the result itself. Indeed, in the current release of Mockito it's not possible to capture it and my solution to do that is to build a ResultCaptor class which implements the Answer interface and generify it for more conveniance. Let's take a look. Create the ResultCaptor class public static class ResultCaptor < T > implements Answer < T > { private T result = null ; public T getResult () { return result ; } @Override public T answer ( InvocationOnMock invocationOnMock) throws Throwable { //noinspection unchecked result = ( T ) invocationOnMock.callRealMethod(); return result ; } } In this quite simple implementation we see that the ResultCaptor class implements the Answer interface which force to override the...

Releaser avec Maven sur github

Le but de l'exercice est de releaser un projet Maven simple en utilisant le maven-release-plugin via Cygwin sur la plateforme github . En effet, la procédure serait aussi simple que sur Subversion , à la condition d'avoir ses settings et ses POM au carré, ce que nous allons voir de suite. Pour mener à bien l'opération, les pré-requis sont les suivants : Avoir un environnement de développement sous Cygwin , le mien étant Windows XP SP3 / Cygwin 2.712 , / java 1.6.0_17 / git 1.7.1 avec une auto-complétion des commandes git bien pratique, Avoir une configuration Maven opérationnelle dans le sens où vous avez accès aux maximums de repositories publics et une plateforme d'hébergement/déploiement pour vos archives. La mienne étant Maven 2.2.1 / Nexus™ Open Source Edition 1.7.1. J'avoue avoir de la chance, car j'utilise pour mes tests, ma plateforme d'entreprise (chez Vidal) configurée aux petits oignons par mon collègue Thierry que je salue au pass...