Bonjour a tous,  
 
Pour beaucoup c'est probablement une question stupide, et beaucoup me diront :  
" Va sur google et achete des livres, ou va voir les tuto gratos "....
 
Le contexte :  
 
J'ai un passé de développeur informatique plutot orienté PHP et JAVA mais j'ai arreté d'en faire depuis 2 ans. (Maitrise MVC et langage Objet).
J'ai évolué en tant que Chef de projet depuis cette période, et j'ai coordonné plusieurs sujets.
 
Depuis un an je me suis fait avoir par une SSII (Non je ne dirai pas le nom) qui m'a mis sur une mission de Chef de projet System ( infra, prod ), je ne pouvais pas refusé car j'étais en période d'essai et Lehman Brother tombait 2 jours avant....
 
En gros maintenant, j'ai 3 années en tant que chef de projet :  
- 1 année orientation langage PHP5 Objet MVC
- 1 année orientation coordination CMMI sur divers progiciels et un peu de PHP5.
- 1 année orientation infrastructure systèmes.
Et RIEN ne correspond a un profil comme le mien sur le marché actuellement.
 
C'est pour ca qu'en analysant un peu le marché, je me suis dit que si j'avais cette crédibilité J2EE je pouvais bifurquer vers une fonction de Chef de projet sur cette techno.
 
 
J'ai donc un peu de temps, mais pas trop et je peux pas me permettre de lire un livre entier etc.. etc... Est-ce que quelqu'un connait un moyen simple et efficace et rapide pour assimiler cette techno ?
 
MERCI MERCI  
 
Ronio

D'abord apprendre à se servir d'internet.
 
Par exemple, la bonne catégorie pour cette question n'est pas ici, mais à http://forum.hardware.fr/hfr/Emplo [...] ujet-1.htm
 
Par exemple, il existe un site nommé hhtp://www.google.com qui permet de trouver de la doc en ligne sur J2EE.

J2EE, c'est énorme, ça ne s'apprend pas comme ça, d'un coup de cuiller à pot. Si tu as BEAUCOUP de temps devant toi, la meilleure (et très complète) introduction est le Sun JEE 5 Tutorial.
http://java.sun.com/javaee/5/docs/tutorial/doc/
Le PDF fait 1126 pages...
Je suggère de travailler sur cette version et non sur la 6, parce que la plupart des entreprises travaillent sur du JEE5.

Ensuite, tu récupères l'IDE NetBeans en version EE ( http://netbeans.org/features/web/index.html ) et tu suis les exemples. Bon courage !
Une fois que tu auras lu et intégré au moins les 5 premiers chapitres de ce PDF, tu en sauras plus que pas mal de gens qui ont fait du JEE.
Mais ça n'est pas fini ! Parce qu'il y a des raccourcis. Ainsi, plus grand monde n'utilise les JSP ou JSF sans framework, c'est bien trop pénible, donc pour la partie web, tu pourras aussi aller essayer un framework comme Struts² (évite Struts premier du nom), et éventuellement, s'il te reste encore du temps, le framework Spring.
Si tu n'es pas découragé avant, tu seras paré pour affronter les entretiens les plus durs.

Then forget about it. L'apprentissage de JEE est long et (AMHA) fastidieux. Lire plusieurs bouquins et passer du temps à pratiquer, c'est le minimum pour prétendre en connaître un peu.
 

Crédibilité en n'ayant même pas eu le temps lire un livre? Hmmmmm.  
 
De toute façon, pour être développeur J(2)EE et avoir fait un passage de quelques mois comme PM avant de me raviser et de repasser développeur JEE, je peux te dire que les recruteurs n'aiment pas du tout. Je pensais que ce serait un plus, mais dans la pratique, c'est comme si ça ne rentrait pas dans les cases prévues dans leurs têtes. J'en ai été réduit à passer sous silence ma courte expérience PM dans mon CV, et voilà, ça allait nettement mieux, plus de regards suspicieux.
 
Dans ton cas, c'est pas 3 mois mais 3 ans. Je ne sais pas comment un recruteur va voir ça. Mal, je dirais. Si le marché était bon, bah, no soucy, les sociétés acceptent de toute façon ce qui se présente. Par contre, si le marché est moins favorable, ça risque de les freiner.
 
Bonne chance dans ce revirement.

Les notions à aborder:
 
-Servlet JSP.
- Tomcat
- Hibernate.
- Spring
- Struts
- JSF
- EJB3 JPA JBOSS
- ant maven
- JUnit TestNG
- XML XSL (java => xerces; sax, dom ...)  
- AJAX
- Web services
- ...
 
 
et chaque notion c'est un bon gros livre de 500 pages minimum.

J'avais pas lu la dernière phrase.
Efectivement, s'il peut pas lire ne serait-ce que le JEE tutorial, c'est peine perdue. Y'a pas moyen.

Tu as fait du CMMI, du php5 et de l'infra en CdP
 
Il y a plein de postes sur le marché c'est juste que tu ne cherches pas les bons.
 
"Faire"/"apprendre" du java ca sert a rien sur ces postes. Comprendre l'ecosysteme, les notions et les differents frameworks/approches est par contre un plus (comme il peut l'etre en php). En gros, dire que t'es un crack en java apres X années c'est bien mais en entreprise, il est plus interessant de maitriser un produit*. En java, en sus du langage et ses subtilites/evolutions (generics/interfaces...) tu te doit de maitriser des outils et des methodologies pour etre un bon dev. Un super codeur qui code sous vi ou notepad c'est sympa mais en entreprise on lui preferera un developpeur moins experimenté qui maitrise le versionning, les tests unitaires et un env type eclipse.
 
Maitrises les methodo et les outils qui vont avec (XP/agile/Cycle en V/ Unit testing...) mets ca en avant et tu t'orientes vers de la gestion de projet ou de la qualité, les postes de MOA ou assistance MOA correspondent aussi et sont de bons debouchés. Note cependant que ce sont des postes ou tu ne codes pas et ou tu passes le plus clair de ton temps a faire du chart et des PnL.
 
Si vraiment tu souhaites fair du dev en java je rejoins exhortae sur pas mal de notions a aborder :
- connaitre la syntaxe
- connaitre les concepts (primitives/generics/interfaces...)
- connaitre les libs de base
- apprendre a te servir d'eclipse  
- apprendre a faire des test unitaires (Junit)
- apprendre a faire des builds et des MAJ de libs (ant/maven)
- conteneur de servlet/JSP (tomcat/jetty)
 
ca c'etait la base de base ensuite pour avoir un minimum de bagage :
- cvs/subversion/git/clearcase/perforce au choix
- xerces ou autre parseur xml  
- hibernate (demande un bagage en SQL et idealement en modelisation)
- spring (indispensable pour exploiter au mieux les tests unitaires, et les deploiements)
- struts/webworks et/ou jsf (si orienté web)
 
C'est le bagage minimum attendu d'un bon dev java. Les trucs comme les webservices ou l'ajax c'est bidon une fois que tu connais tout ca car ensuite tu bosses sur des frameworks (struts/jsf) ou la question ne se pose plus.
 
 
* J2EE est un produit mais il est par definition modulable et la VA se fait sur la connaissance des "modules", connaitre jboss c'est bien mais si la boite bosse sur websphere ou weblo c'est moins interessant pour l'employeur.

Merci a tous pour vos retours vraiment constructifs.
 
Il est important de ne pas oublier qu'en tant que chef de projet, la consonante technique aide grandement aux estimations de charge et d'audit mais elle n'est pas en soi une obligation. (enfin en ce qui me concerne)
 
Passer Chef de projet (et pas faire du DEV) sur du java n'est pas forcement maitriser la technique.
 
Merci bcp pop-pan et exhortae pour vos réponses orientées Chef de projet
 
Je met en effet en avant toutes les méthodologies CMMI et Agiles lors de mes entretiens, associés aux connaissances MVC applicables un peu partout.
 
 
Je vais travailler le bagage afin de continuer dans la lancée !
MERCI  
RONIO

estim de charges => depends de l'equipe affectée et de SON experience, a ponderer par la presence ou non de "modules préexistants" ou de réal anterieures.
 
le CdP n'a pas a faire l'archi, c'est l'archi qui la propose car c'est SON boulot.
 
Le boulot du CdP c'est d'etre le liant entre les différents intervenants, de mettre en place les jalons et les methodes permettant d'optimiser la distribution de l'information.
 
Evidemment un bagage techno est un plus, mais c'est un plus en interne, ca sert juste a pas se faire trop chambrer par les devs et a eviter de leur proposer trop de conneries. Ca permet aussi de valider leurs estimations (car ce sont eux qui les font) et les ponderer en orientant parfois vers des solutions plus simples (moins fun pour les devs) mais plus adequates (meilleurs ratio cout/prod.)
 
Honnetemment un bon CdP c'est un gars qui sort les buzzwords et les PnL aux decideurs, qui identifie le vocable d'un client pour affiner une demande et qui exprime clairement un besoin face a des devs. Une personne qui ne crache sur personne en fait et qui a pas la grosse tête.

PnL comme programmation neurolinguistique ?
 
Je ne connais absolument pas ce domaine.

PnL comme Profit 'n Loss

Oui enfin le choix d'une mauvaise techno (par ex  JSF 1.1 et EJB 1.x 2.x, pourtant préconisés par Sun avant JSF 2 et EJB 3, ou Struts premier du nom, ou Oracle Forms) peut facilement doubler ou tripler le temps de développement. Or en Java, bcp plus qu'en PHP, il y a des tas et des tas de frameworks et de technos, dont un bon paquet bien foireux. Il vaut mieux savoir à l'avance ce qui marche et ce qui ne marche pas, ou mal, parce que le choix est vraiment difficile.
Rien que pour le web, il doit bien y avoir au moins une centaine de frameworks open source, dont seulement une petite dizaine dignes d'être considérés. Impossible de les connaitre tous.
Dire "on prend Struts" ou JSF parce que c'est ce qu'on trouve sur les annonces en priorité, c'est juste être nul.

 
Doubler ou tripler par rapport à quoi et dans quel contexte ? Le principe d'une estimation de charges c'est bien d'evaluer ça.
 

 
C'est pour ca qu'on prends des frameworks qui marchent bien ensemble et que struts1/webworks ont mergé par exemple. Apres on peut aussi choisir de faire du full jakarta/apache ou du full spring + web flow, ca depends de son humeur et de l'experience.
 

 
Non, c'est s'adapter au marché. Ton raisonnement serait de dire que comme il y a plein d'annonces java se former a java c'est juste etre nul.  
 
Ca me fait penser a plein de potes qui se masturbent sur Ruby/Rails, parce que c'est super pratique (c'est vrai) et rapide a mettre en oeuvre (vrai aussi) il considerent que c'est le "meilleur compromis actuel en dev web" et se permettent de chier sur java par exemple en mettant en cause sa lourdeur (pas completement faux). Ce sont les memes qui n'ont jamais fait de python ni de lisp, qui n'ont jamais titillé de lex/yacc ni de C r&k et qui ne savent pas commenter.
 
Ce sont les memes qui des qu'il faut lancer un proj web repondent de suite Ruby sans reflechir, sans penser au fait qu'il y a d'autres personnes dans l'equipe, qu'il faut mettre en oeuvre un decoupage fonctionnel des taches, qu'il faut etre capable de disposer de métriques, qu'il faut disposer d'un hebergement adapté, que la maintenance c'est pas eux qui vont la faire, que le client il en a rien a  faire du Ruby et que ca le rassure pas.
 
En gros si ils avaient connu python ils reflechiraient avant. Ce n'est pas le meilleur language qui gagne en entreprise, c'est le plus repandu et rassurant. C'est la meme chose pour les frameworks, c'est la meme chose pour les serveur d'application J2ee... Si la SG choisi vignette pour refaire tous ses sites webs ce n'est pas parce que c'est le meilleur CMS/framework (loin de la), c'est parce que c'est pour eux le meilleur investissement.

Par rapport à l'utilisation de frameworks équivalents plus récents/mieux foutus (Jboss Seam, Stripes par ex) sur un très gros projet.

Je comprends bien ce raisonnement et j'avais bien sûr anticipé ta réponse. Le fait est que pour un projet de taille conséquente, - et quand je dis taille conséquente, je veux dire > 2000 jours-hommes pour du Java -, il vaut mieux que les devs se forment à un framework plus productif plutôt que continuer sur un framework qui divise leur productivité par 1,5 ou 2. Sur le long terme, l'investissement paye. Surtout si ce framework prouve suffisamment son efficacité pour être ensuite réutilisé sur d'autres projets.
D'expérience, l'apprentissage d'un framework ou d'un outil bien foutu n'a JAMAIS été un frein pour la productivité de développeurs (un framework mal foutu ou limitatif, par contre, c'est tout le contraire). C'est par contre toujours une cause d'inquiétudes pour les managers et CP qui voient leurs diagrammes de Gantt dériver, certes, parce que le gain de productivité n'est pas quelque chose de mesurable facilement, alors que le temps perdu au démarrage l'est. Il n'est pas facile de dire "grâce à ce choix technique, j'estime avoir gagné tant de jours par rapport au choix communément admis", alors qu'il est très facile pour le N+1 de dire "tu as perdu tant de jours pour la formation de tes devs à cet outil".
Or le CP, il doit justifier ses dérives et il a peur pour ses fesses. Et pourtant, l'amélioration des processus, c'est aussi le métier du manager.
Pour reprendre l'exemple de Struts 1, c'était typiquement un framework productif il y a 10 ou 12 ans, quand Sun ne proposait que les JSP, mais depuis, de l'eau a coulé sous les ponts et ce serait une erreur de partir la-dessus "pour s'adapter au marché". Dans ses présentations sur les différents frameworks modernes, Matt Raible met tjrs un slide avec Struts barré.

Autres exemples, un produit comme Hibernate ou les concepts de JEE sont globalement loin d'être aisés à appréhender, et pourtant, ils sont largement utilisés partout. Et ça n'est pas parce que tout le monde connait JPA ou les webservices, mais uniquement parce que c'est puissant. Or lorsque Sun a sorti JSF 1.0 ou les EJB 1.0, les managers ont dit: "c'est ça qu'il nous faut". Ils n'y comprenaient rien mais Sun leur expliquait que c'était le nouveau paradigme qui allait résoudre tous leurs problèmes. Sauf que l'expérience a montré que c'était de la merde en barre et plus personne ne songerait à réutiliser ces technologies aujourd'hui (le framework Spring a été développé pour pallier aux insuffisances des EJB). D'ailleurs, les EJB 2.x, c'était encore de la merde, et devant la bronca générale, Sun a décidé de spécifier les EJB 3.0 via le community process.
Le choix par défaut "parce que tout le monde fait comme ça" n'est pas un bon argument en soi. Il faut réellement peser les mérites de chaque outil.

Il y a par ex. d'autres choix courants "sur le marché" qui n'ont pour moi simplement aucune justification possible (si ce n'est l'incompétence, ou des cadeaux commerciaux pour l'achat d'une licence site). Par exemple le couple ClearCase + ClearQuest, qui est à la fois très cher, lent, excessivement compliqué et amha inférieur à Jira + Subversion sur pratiquement tous les points de comparaison possibles (j'ai utilisé les deux systèmes pendant suffisamment d'années et sur suffisamment de projets et contextes différents pour avoir un avis relativement objectif).

Donc l'argument de dire "c'est s'adapter au marché." est relativement bidon. Un gars qui connait Struts apprendra Stripes sans problème en 3 jours, et en prime il pourra faire de l'Ajax. Donc mettre "Struts" dans les annonces d'emploi, pourquoi pas, mais ça n'empêchera pas d'utiliser Struts² ou Stripes plutôt que Struts. De même qu'en réalité des gens qui connaissent réellement JPA/CXF/EJB3/etc sur le bout des doigts, il y en a très peu. Tout le monde apprend sur le tas. Ca c'est la réalité.

Ok, je comprend bien qu'on peut argumenter sans cesse, sur quel choix technologique etc.. etc...
 
Initialement ma question n'était pas d'avoir des retours "détaillés" sur la techno. En fait ma question se résume à :  
 
Est-ce que, les connaissances de Gestion de projet multi-domaine. (équipe interne, équipes externes, dev et systèmes ), la connaissance objet (modelisation uml, MVC) peuvent me permettre de devenir Chef de projet sur des solutions JAVA et si non, quel est le DELTA pour y parvenir ?
 
Je veux juste me donner les moyens d'être crédible sur ce sujet afin de rassurer...
 
Mon objectif est clair et simple :  
Les activités de management, de relations humaines, de coordination et de gestion, notamment dans les projets de plus en plus importants, sont le cœur de métier du chef de projet, même dans un contexte hautement technologique (dixit JAVA ici).  
 

el muchacho > je comprends mieux ce que tu voulais dire, on est d'accord tous les deux, le choix en interne de developper une compétence est lié a la productivité (et oui, struts 1 c'est caca mais plus personne ne l'utilise heureusement et spring sert au depart a  palier aux specs EJB moisies, ok sur clearcase mais il y a toujours le cout de migration qui est un frein surtout sur de gros projets).
 
Ce dont je parlais c'est l'approche "candidat" pas des choix techniques dans l'entreprise. Et sun on sait tous que bon faut pas deconner, pendant longtemps ils ont proposé des trucs un peu... limites (JSR 170 et les implementations a la mors moi le noeud par ex.)
 
ronio > le delta c'est d'apprehender l'existant de l'entreprise et ses competences. Idéalement connaitre TES limites pour pouvoir demander l'avis de personnes plus compétentes dans d'autres domaines, par exemple a 2-3 experts java qui ont benché ou non certaines solutions.
Ce n'est pas grave si un Cdp n'est pas un crack dans tous les domaines, on paye d'autres personnes pour ca. Evidemment si c'est censé etre en meme temps un Lead programmer/architecte la ca va coincer si il est limite techinquement.

 
+1