Première partie de la journée

La deuxième journée est la dernière journée de la partie université de Devoxx. La partie université à la particularité de présenter deux slots de 3 heures de conférence sur un unique sujet, un le matin et l’autre après midi.

JEE6

La journée débute par une présentation sur JEE 6 par Antonio Goncalvez et Alexis Moussine-Pouchkine. Bien ficelée, la présentation passe en revue l’ensemble des nouveautés. Beaucoup de démos rendent la présentation plus concrète, les mise à jour/nouveautés de la spécification sont bien détaillées. Une présentation un peu plus ‘pratique’ ( Qu’est ce qui ne va pas et qu’il faut revoir ? que conseillez vous ?) aurait pu également être interessant, heureusement que la BoF du soir (Why you should care about JEE6) a répondu en parti à cette problèmatique .

Google App Engine

La deuxième moitié de la présentation Google App Engine a porté sur des questions très pratiques. En ce qui concerne l’interaction avec les données, JDO est preferé à JPA. Tout simplement du aux constraintes de BigTable qui est le système de gestion de données de Google sur App Engine. JDO bien que décrié est remis au gout du jour, JPA n’étant pas totalement disponible sur GAE du à l’utilisation de BigTable, le type de système ‘NoSQL’ de Google qui ne gère que les one-to-many et pas les many-to-many.
Un autre point important, à l’autre bout de la chaine est l’intégration avec GAE de certains framework de présentation (Spring MVC / GWT / JSF 2). En ce qui concerne JSF2, l’intégration se révèle être la plus hardue. En effet, les problèmes sont nombreux (problème avec la sauvegarde d’état, avec les beans de scope session et application (uniquement request code and view code), l’ensemble des états doit être sérialisable, le component binding n’est pas possible pour la raison précédente. GWT se révèle plus facile mais ce qui est réellement conseillé, si l’on recherche quelque chose de pratique est l’utilisation de Spring MVC.

Pour développer l’interface utilisateur de l’application de démo, il a fallu environ 3 jours avec Spring MVC, 2 semaines avec GWT et énormément avec JSF. D’autres frameworks ne sont pas disponibles Rich Faces and Ice Faces par exemple. Pour savoir si une librairie est supportée totalement, partiellement ou non supportée, il suffit de chercher la page ‘Will it play on app engine’ où beaucoup de frameworks/librairies sont référencées, avec leurs limites.

SOA

La session de l’après midi était sur SOA(Service Oriented Architecture), avec une approche assez théorique. C’est un paradigme, une manière de concevoir les choses. L’objectif de SOA est de découper les fonctionnalités complexes en un ensemble de fonction simple, les services. Un des points de la présentation à montrer que chaque choix avait un coût, notamment la manière de coupler faiblement les données mais également d’utiliser un ESB. Il faut compter un ou deux ans avant de réellement avoir une architecture SOA, et bien sûr, commencer par un projet non critique, puis un deuxième, refactorer, ajouter un troisième, refactorer. Le refactoring est une composante essentielle : SOA ne s’achète pas, c’est une philosophie qui se crée sur le long terme et, parceque c’est du long terme, elle nécessite un investissement politique de l’entreprise.

Java-monitor & TeamCity

La première présentation sur l’outil java-monitor a montré des cas spécifiques de problèmes (java heap space, impossible d’allouer la mémoire pour lancer le thread …). Cette présentation très synthétique a permis de mettre en évidence quelques mauvaises pratiques : utilisation de System.gc(), une mauvaise configuration du garbage. Il existe une démo en live des possibilités de l’outil.
TeamCity est un outil d’intégration continue. La présentation était constituée essentiellement d’une démo. Quelques fonctionnalités à retenir : possibilité de déclarer plusieurs agents, par exemple en fonction des OS, bonne intégration avec les IDEs existants, possibilité de prendre la responsabilité d’un échec de build ou d’affecter la responsabilité à un membre de l’équipe, de garder un build propre en permanence (test de la construction du build avant le commit). Néanmoins, la présentation n’a pas montré un outil si simple que ca à manipuler. Un but de TeamCity semble être également d’avoir une place dans les outils qui permettent de monitorer la qualité du code (couverture de code avec Emma, d’autres métriques, la possibilité de voir des mauvaises pratiques) mais encore peut finaliser (pas encore possible apparement de pouvoir modifier les règles sans IntellijJ IDEA).

Les BoF

La première, Why I should carry about java EE6 a pu réunir une belle équipe de speakers. Les questions posées ont amené certaines bonnes pratiques à être définie, comme utiliser les @ManagedBean principalement avec CDI mais les approches JSR/JCP ont également était approchée. La prochaine session du Paris Jug aura j’espère l’occasion de développer encore plus le sujet.

Pour conclure, l’ensemble des présentations seront disponible prochainenment sur le site http://parleys.com/ pour une abonnement de 49€. Ce qui est une très bonne affaire !

Pour ceux qui ont la chance d’être resté en mission ou qui n’ont pas vu leur tarif baisser, ce n’est pas le moment changer. Et pour ceux qui ont subit, le risque est de continuer à subir quand le marché aura reprit. Alors comment avoir une vue globale sur le marché de la prestation Java en France ?

Personnellement j’utilise le baromètre du site hitechpros.com. Apprendre à décrypter ce baromètre permet de se faire une idée des tendances du marché.

Comment décrypter ces données ?

Premièrement, ignorer les pourcentages, ils correspondent aux ratios entre les différentes technologies. Cela n’a aucun intérêt, si ce n’est de savoir que les nouvelles technologies sont plus demandées que le reste…

La courbe bleue correspond aux offres de missions (demandes des clients), ramenée a 100% elle sert de base. La courbe rouge correspond aux prestataires disponibles (offres de SSII). Donc plus la courbe rouge baisse, mieux c’est. Pour le mois de septembre, on voit clairement que le ratio offres / demandes se rapproche de plus en plus du ratio pré crise. C’est un premier indicateur qui indique simplement que le marché s’équilibre. Cela ne veut pas dire qu’il y a un plus grand choix de mission, ni que la crise est terminée mais simplement que pour le mois en cours, il y a eu 242 missions pour 457 prestataires. On en déduit qu’il faut théorique au maximum 2 mois pour trouver une mission et en moyenne 1 mois.

Ce ratio baisse aussi si les SSII ont moins d’intercontrat. Et vue qu’elles ont stoppées les recrutements, il est mécanique qu’il baisse. Les jeunes diplômés payent aussi pour cette crise.

Pour se faire une idée de l’évolution réelle de la demande il faut donc jeter un oeil aux mois précédents. Il y avait 255 missions en Septembre, 119 en Août et autour de 200 les mois précédents. Août est traditionnellement peu dynamique;nous l’ignorons donc. Les demandes étaient donc d’environ 200 par mois pendant la crise. Si le nombre d’offres continue de progresser on peut s’attendre à un retour à des tarifs décents.

Voici mon analyse :

- Actuellement le nombre d’intercontrat baisse fortement et les clients commencent à avoir du mal à trouver des ressources. Les indépendants trouvent facilement des missions mais mal payées.

- Si la tendance se confirme, les SSII vont recommencer à recruter afin de répondre aux exigences des clients, les débutants et chômeurs vont réussir à trouver du travail mais moins bien payé qu’avant 2007, car les tarifs n’auront pas encore remontés.

- Lorsque le vivier d’inter-contrats et de jeunes diplômés sera absorbé, le prix commenceront à remonter et les salaires feront de même. Il sera temps pour les indépendants de profiter de cette dynamique avant la prochaine crise.

Pour conclure, n’oubliez pas que le meilleur moyen de rester employable, crise ou pas crise est de se former ! En mission comme à la maison ou en dehors. Ainsi que de bien choisir ses missions !

Et vous comment vivez vous ou avez vous vécu cette crise ? Quelle est votre stratégie pour les mois à venir ?