-
VirtualBox 64bits sous MacOS X
Je suis totalement débutant avec MacOS, je découvre donc les détails de son fonctionnement au fur et à mesure… Je pensais avoir compris que la version 10.6 (Snow Leopard) fonctionnait en 64 bits. C’est donc avec beaucoup de confiance que j’ai commencé à installer un Window 7 64 bits dans une machine virtuelle VirtualBox. Et là j’ai eu une grosse désillusion : ma machine virtuelle ne supporterait pas les 64 bits…
-
Premiers pas avec Git et GitHub
C’est l’été, l’activité baisse un peu, c’est donc l’occasion pour moi de démarrer un nouveau projet que j’avais en tête depuis quelques temps. J’aurai l’occasion de présenter le projet quand il aura un peu avancé. Comme je démarre d’une page blanche, j’ai la chance de pouvoir choisir complètement mon environnement de développement. J’ai donc choisi d’utiliser IDEA, pour lequel j’ai une licence grâce au LyonJUG, ainsi que Maven. La vrai nouveauté pour moi, c’est l’utilisation de Git.
-
Déploiement de Silverpeas sur JOnAS
Voici la présentation que j’ai donnée pour OOsphère, en avril 2010, au sujet du déploiement de Silverpeas sur JOnAS et sous JBoss AS 5.
-
SLF4J et JCL sous Jonas 5
Lors du déploiement d’une application JavaEE, la configuration des logs est un passage obligé. La principale contrainte vient du fait qu’au déploiement, on subit le choix des développeurs : Log4J, Apache commons-logging (ou JCL), SLF4J ou d’autres encore que je m’abstiendrai de citer ici.
SLF4J associé à LogBack est probablement ce qui se fait de mieux aujourd’hui. Il propose d’ailleurs des mécanismes d’interopérabilité avec les autres APIs de Log. Par exemple, dans la dernière application que j’ai déployée, tous les logs envoyés à JCL sont interceptés par SLF4J grâce à la librairie jcl-over-slf4j.jar. A l’inverse, Jonas 5.1 renvoie tous les logs de SLF4J vers JCL.
-
Tests unitaires pour Google App Engine
Les tests unitaires des applications GAE posent les problèmes classiques des applications déployées dans des conteneurs : peut-on tester les classes hors de son contexte cible, peut-on simuler le conteneur, ou faut-il déployer l’application pour la tester ?
La première solution est celle qui s’approche le plus de l’unicité du test, il doit donc être privilégié autant que possible, c’est la technique qui est utilisée pour les POJOs sans contexte d’exécution. En revanche, c’est tout à fait impossible si notre classe a besoin d’une API fournie par le conteneur ou, pire encore, hérite d’une classe ou implémente une interface fournie par celui-ci. Ces cas sont classiques en JavaEE. Dans ce domaine, la tendance a été de remplacer le conteneur par des objets mock ou fake.
Nous allons étudier ce qui est proposé par Google pour son App Engine.
Alexis Hassler
J'ai créé la société Sewatech en 2005, pour y exercer mon métier de développeur full stack, à dominante back end.
Vous pouvez me contacter si vous cherchez un développeur indépendant expérimenté (plus de 25 ans d'expérience) pour intégrer votre équipe de projet. Je peux aussi intervenir pour un audit ou une mission de conseil.
Enfin, je donne des formations sur Spring, Vert.x, WildFly,... en intra sur site ou à distance.
