Commentaires

Envoyé par sazearte

Et enfin un langage moderne n'est pas négatif, ces langages moderne ont l'avantage de ne pas trainer de boulets hérité des années 2000. Le gros changement de Python3 sur le long terme est une bonne chose.

Je suis d'accord mais quels seraient les candidats. Car Node ou angular pour ne parler que de JS coté serveur sont à placer dans les années 2010 ou dans les années 90 comme héritage de ce bon vieux JS ?

Envoyé par MaitrePylos

Écarter Python et Ruby au motif de 'pas encore éligibles au rang de standards du développement web professionnels', c'est vraiment ne pas connaitre le monde professionnelle.

En effet je ne connais pas de SI ayant une visibilité sur internet en Ruby. Je suis preneur d'info sur le sujet, en revanche j'en connais des tonnes écrits en PHP, JEE ou .NET.

Il subsiste néanmoins que les développeurs qui maitrisent RoR ne sont pas légions. Et que les architectes capables de qualifier cette techno sont surement encore plus rares, pour ne pas dire inexistants.

Y'a aussi Python qui est libre (open-source) et gratuit.

Pour moi, pour développer un projet neuf Python et PHP7 sont de bien meilleur alternatives à Java.
Je ne fais plus de java depuis 5ans, tous mes projets sont soient en Python, et pour le web, sa dépend, mais souvent php car facile à mettre en place.

Niveau possibilité, Python a une pléthore de bibliothèques externe permettant de faire bien plus de choses qu'en Java.
Niveau performances, sa dépends, mais pour les calcules lourd déja j'ai pas trouvé d'équivalent à Numpy, même en java.


Et enfin un langage moderne n'est pas négatif, ces langages moderne ont l'avantage de ne pas trainer de boulets hérité des années 2000. Le gros changement de Python3 sur le long terme est une bonne chose.

Libre ne veut pas dire gratuit, et gratuit ne veut pas dire pas chère.
Il est préférable d'utiliser le terme d'open-source, est-ce que je peux forker java et le modifier ? oui, alors il est open-source.
Écarter Python et Ruby au motif de 'pas encore éligibles au rang de standards du développement web professionnels', c'est vraiment ne pas connaitre le monde professionnelle.

Libre de l’américain free qui signifie gratuit.
Donc oui java est aujourd'hui un gratuitciel mais son propriétaire est Oracle qui pourrait décider d'y instaurer un droit d'utilisation.

[QUOTE]Est il libre ? Oui on ne paie rien pour l'utiliser[/QUOTE]
Heu, personnellement ma définition de "ne rien payer" serait plutôt "gratuit". Et à la ligne suivante vous expliquez qu'il est propriétaire, donc ...

Concernant l'adoption des nouvelles technologies dans les entreprises, j'ai tendance à dire que lorsque vous maitrisez une stack techno en interne, que vous avez des processus de développement basés dessus, c'est assez compliqué de former toutes les équipes à ces nouvelles technos (et en plus si vous avez des modules déjà développés les migrer dans un autre langage n'est pas simple).

PHP à l'avantage d'être libre, gratuit et installé sur de nombreuses plateformes. Reste à voir si sa version 7 sera utilisée en masse (sachant que les améliorations qui ont été effectuées au coeur de l'interpréteur sont très bonnes). En plus de nombreux frameworks sont disponibles.

Merci a tous pour vos avis éclairés sur le sujet.

À la lumière de vos avis d'experts, il apparait que node.js ou une autre plateforme "JavaScript coté serveur" ne semble pas complètement mature pour venir concurrencer l'écosystème JEE sur des petits projets.

Pour les plus pragmatiques je comprends que Spring est idéal pour les petit projets à spécifier et développer en 2 semaines, surtout si on allège un peu l'écosystème.
Ma seule objection serait sur la courbe d'apprentissage de Spring pour un développeur ne venant pas du langage JAVA, mais bon.....

Enfin, je tiens à préciser que je ne voulais en aucun cas sur ce fil ou un autre opposer l'architecte au développeur. En effet, leurs approches peuvent être antagoniste tout en œuvrant de façon synergique.

Excellent
Tu as raison, je suis devant le tableau d'affichage.
et sur ma road map, on ne sais pas ou on va ni quand on doit arriver

autran, d'accord je n'avais pas du tout fait le rapprochement entre le fait de "cloner des tiers" et la scalabilité, mais la réponse que tu donnes est juste. Pour le deuxième point, même si le résultat du benchmark peut te paraitre évident, il faut le faire, et c'est là toute la difficulté de la chose
Enfin pour ce qui est de AngularJS c'était un peu pour plaisanter mais il y a une part de vérité :

Tracer La limite entre le travail d'un architecte fonctionnel et celui d'un développeur a toujours posé problème, arrêter le niveau de détail autorisé à un architecte n'est pas une chose simple mais on peut toujours s'arranger sur un compromis.
Ce dont on est tous d'accord c'est qu'on peut pas monter un projet juste par une vision architecturale fonctionnelle sans se soucier du coté technique ( plate-forme, performances, BDD,requêtes ...) ,Personnellement lors de l’établissement des spécifications fonctionnelles je garde des cases spécifiques à des aspects techniques genre : temps de réponse d'une requête donnée ,sécurité d’accès ...et quand je discute ces spécifications avec le développeur je me trouve très souvent entrain de négocier des choix en mettant en évidence les gains et les pertes en terme de performances,rapidité,charge,récurrence, mon souci est d'optimiser l’interactivité système-utilisateur et le sien est d'optimiser l'appel du serveur applicatif et de la base de données . Être initié au domaine du développement c'est recommandé mais on n'est pas censé savoir développer pour faire des choix appropriés et efficaces ,de tel choix peuvent être réalisés en coopérant avec compétences architecturales techniques.
il n'a y a pas de solutions idéales ou de bons choix , c'est juste un monde ou l'architecte fonctionnel et le développeur doivent communiquer,négocier, s'entendre et se compléter.

Oui je suis également fana Ember à 200%.
Mais je n'ose pas imaginer ce que ça donnerait si je proposais Ember... dans le genre "on t'a dis qu'on ne voulait pas de node alors tu nous l'enrobes dans un nouveau truc"

Quitte à vouloir migrer des développeurs Java vers du FullStack JS, je choisirais plutôt le combo ( nodeJS, Ember). En effet cela sera beaucoup moins traumatisant car Ember se rapproche plus de la conception Object de Java que Angular. De plus Avec Ember-cli, les développeurs aurait une structure définis à disposition et serais beaucoup plus guidé qu'avec Angular.

Dans tout les cas le niveau de JavaScript nécessaire pour développer une application FullStack JS est autrement plus coriace que d'utiliser jQuery ou les composants Primefaces dont se contente la plupart des développeurs Java. ( Ce n'est pas une critique négative, juste une constatation du fait qu'il n'y à pas besoin d'en connaître forcement plus.)

Rien n'empêche d'utiliser du angular et ça marche très bien avec du java, et comparer jee avec nodeJS est un non-sens.

D'autant plus qu'il y a spring qui marche bien pour les petites et moyennes entreprises pour faire des services; et je ne vois pas le problème du nosql, pareil on peut l'utiliser très bien.

Bonjour, tu sembles assimiler JEE à JSF et Node à Angular. J'ai constaté au cours de mes dernières années de dev que SpringMVC était devenu davantage à la mode et que JSF était considéré comme devenu obsolète. SpringMVC se marie très bien avec Angular, ce qui est effectivement moins le cas de JSF.

Concernant l'écosystème (Jenkins, Maven, Sonar, etc...) qui accompagne souvent les applications JEE, cet écosystème ne fait que répondre à des préoccupations en terme d'intégration continue, qualimétrie, etc... Cet écosystème ne fait pas partie de la norme JEE, ce n'est qu'un complément optionnel.

Pour ce qui est des arguments qui pourraient convaincre un DSI d'adopter Node, je pense qu'il ne faut pas obligatoirement l'associer à Angular, bien au contraire. Je suis convaincu que les architectures à base de micro services sont une tendance, bien que naissante, qui a vocation à s'imposer à l'avenir dans certains SI. C'est une architecture qui est portée par le mouvement Docker et qui répond bien à la volonté des DSI de découpler les développements. Pour faire un petit clin d'oeil, c'est finalement la même philosophie de découplage (mais poussée plus loin) qui motive l'adoption des micro services que celle qui a motivé en son temps l'adoption des EJB.

Si je parle des micro services, c'est parce que Node est tout particulièrement bien adapté à ce type d'architecture. Ou du moins certains micro services, puisque cette architecture permet d'avoir un environnement technique hétérogène. Le gain en temps de développement pour du simple CRUD est manifeste entre une application Node et JEE. Les deux freins à l'adoption de Node sont le typage faible de Javascript qui interdit de l'utiliser dans des applications avec un métier complexe, et le manque de confiance dans une techno encore jeune.

Si tu veux convaincre ton DSI, commence avec des ambitions modestes. Identifie un projet complexe bien adapté à une architecture de micro service, et propose de développer les modules CRUD avec Node et la promesse de gain de temps.

Autre domaine où Node est bien adapté, les API qui opèrent le backend des applis mobiles, car ce backend est souvent constitué de simples opérations CRUD.

Ces suggestions sont basées sur l'avantage en terme de temps de développement, mais il existe aussi d'autres avantages. La moindre occupation mémoire en est une, qui là aussi fait que Node est bien adapté à du micro services. Mais je crois savoir qu'il existe encore d'autres avantages liés notamment au mode de traitement des requêtes au niveau du système.

Je suis plutôt du même avis que Gugelhupf. Sauf sur AngularJS, je n'ai aucun avis sur cette techno.

Par contre je ne comprends pas trop le but de ton article.

Au début, Tu parles d'écrire une petite application, et de devoir convaincre la DSI.
La DSI qui est en train de gérer plusieurs projets à quelques dizaines de M€, elle s'en fout un peu de cette application.
C'est pour ça que dans toutes les boîtes, tu as des milliers de petites applications écrites en: PHP, VB, Python, Macros Excel, etc... alors pourquoi pas AngularJS + NodeJS, GWT, Vaadin, Dropwizard, ajouter ici la dernière stack à la mode qui va bien. C'est ce que l'on nomme Shadow IT.

Juste pour infos dans les DSI pour lesquelles j'ai eu l'occasion de bosser, cela fait quelques années que AngularJS fait partie de leur boîte à outils.
C'est juste un outil, pas un but en soi. Elles ont pas eue besoin d'être convaincu.

Ensuite tu conclut ton article en changeant de problématique, tu nous parlant de migration, sans nous expliquer quels seraient les avantages de cette migration pour une DSI.
Oui, il est certainement possible de migrer de JSF vers AngularJS, mais dans quel but ? Pour quel gain ?

Je n'ai pas ton expérience des migrations, dans ma carrière je n'ai fait qu'une migration pour un budget de 100 K€, et 3 pour des budgets > 10 M€.
Mais c'est marrant la motivation ce n'était pas: chouette, une nvlle stack à la mode, allons joyeusement dépenser notre budget illimité.

A chaque fois la motivation principale c'était l'obsolescence: obsolescence des technologies, des matériels ou des compétences.
Il existe évidemment d'autres motivation pour faire des migrations.

Pourquoi le convaincre?

Il faut alors très bien apprendre javascript, j'ai rarement vu des gens qui le maîtrisait vraiment?

A terme est-ce que angular est pérenne? si on se fit à ce que fait google en général, ça peut faire peure à certain.

Angular 2 va sortir et n'est pas vraiment compatible à la version 1, d'ailleurs certain grosse pointure sont partie et travaille sur aurelia

Niveau composant graphique, angular est très pauvre comparativement à ext-js (sench), smart-client

Il faut apprendre un nouveau type de bd (nosql), utiliser un orm fait en js...

Au final il faut tout réapprendre avec des gains incertains.

Quand tu regardes ceux qui ont sauté le pas, c'est souvent de très gros système qui n'a rien à voir avec la quasi totalité des applications que les gens travaillent...

Un petit sprint boot, suivi de micro service rest. C'est simple, très rapide en mette en place tout en ayant la possibilité de mettre le tout dans le cloud.

Envoyé par Gugelhupf

• Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
• "Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
• "Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.

Par curiosité, qu'as-tu voulu dire avec "la technologie JEE permet de faire face à la montée en charge en clonant les « tiers » (aussi appelé scalabilité)" ?
JEE permet de mettre en place une architecture multi-tiers, un tier étant une couche de l'application. Chaque tier pouvant être hébergé sur une plate-forme hard (CPU + RAM + HD) différente.
Afin de gérer la sollicitation de chaque tier, on peut utiliser un cluster de serveurs dédié à une couche. C'est ce que j'appelle cloner un tier. Au passage cela permet de faire face à la montée en charge mais aussi d’implémenter la résilience vis à vis d'une défaillance technique.

"Quant à la mise en production d'une application JEE, cela nécessite d'utiliser des ressources en CPU et RAM très importantes sur la plateforme d’hébergement." => Fais nous un joli benchmark d'application réelle please.
Ce que je veux dire, et là nous sommes au cœur de l'article, c'est que pour développer une application qui sera utilisée par 10 personnes dont 1 personne connectée H24 et 9 qui se connecteront 1 fois par semaine. Pour une application qui met a peine 20 objets en persistance. Pour une application dont l'aspect transactionnel de la persistance est sur une mise à jour de table toute les 15 minutes. Pour une application qui se compose de moins de 10 écrans. Pour ce genre d'application que je qualifierais de petite, utiliser un WILDFLY, voire à minima un TOMCAT si l'on fait l'impasse sur les EJB, requiert pas mal de CPU et de RAM. Ben oui, parce que même un pauvre TOMCAT + APACHE est infiniment plus consommateur de RAM et CPU que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var app = express();

.....pour ça pas besoin de faire un benchmark.

"Sur un prochain post, je montrerai comment migrer en douceur de JEE vers AngularJS et Node.js." AngularsJS 1 c'est devenu has been, alors faudra surtout pas oublier de nous montrer comment migrer des applications Java EE Servlets & Spring & Struts & JSF vers du AngularsJS 2 en TypeScript.
AngularJS est en version 1.4 me semble-t-il la V2 est pour le moment dans les cartons. Pour ma part j'ai déjà fait un tuto sur DVP pour démontrer en quoi Angular (version hasbeen) permet de faire largement aussi bien que JSF (+ AJAX).

Donc oui, dans la mesure ou j'ai déjà migré du JSF vers GWT (un tuto aussi sur DVP pour cette techno) et migré du GWT en angularJS (hasbeen), je pense sans malheureusement pouvoir démontrer que cet espace migratoire est pourvu d'une loi de composition ni que la propriété de transitivité soit vérifiée que l'on doit pouvoir migrer du JSF en Angular.

Bon je vais pas refaire un post là dessus car je vois que je déclenche des réactions épidermiques chez certains. Mais pour moi le premier step de la migration était JSF --> Angular. Pour les steps suivants, je vais les garder au chaud et attendre que mes idées avant-gardistes soient jugées moins mauvaises. Surtout que ça parle de référentiels et d'urbanisation.

Liste des app et site utilisant Node.js avec une explication d'un de leurs développeurs sur la partie sur laquelle il l'utilise :

Netflix (http://www.talentbuddy.co/blog/build...js-at-netflix/)
ebay ( http://www.talentbuddy.co/blog/build...de-js-at-ebay/ )
dowjones ( http://www.talentbuddy.co/blog/build...-at-dow-jones/ )
New York Times (http://www.talentbuddy.co/blog/build...ew-york-times/ )
PayPal ( http://www.talentbuddy.co/blog/building-with-node-js/ )
Medium ( http://www.talentbuddy.co/blog/on-bu...s-a-developer/ )
LinkedIn (http://www.talentbuddy.co/blog/build...s-at-linkedin/)

on peut avoué que c'est des app, sites qui ont du trafic

génial cette liste , si on se rend sur les divers site que tu propose, appart paypal et peut être netflix ( qui n'a pas encore tout migré sous nodejs ), on vois clairement des problèmes de performances, medium étant le pire des cas, avec 3 fois rien comme contenue ( bha oui c'est un blog avec des commentaire ) le bordel rame comme pas possible ( je parle même pas de leur version mobile html sur laquelle naviguer devient un vrai challenge )

Autant pour moi Patrick.
Fonction est une interface que j'injecte dont voici la signature :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface Fonction 
{	
	double valeur(double x);
}

toutes les fonctions devront l'implémenter comme par exemple:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class Carre implements Fonction 
{
	@Override
	public double valeur(double x) 
	{
		return (x*x);
	}
}

ce qui nous donnerait dans le main :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class Principale 
{
	public static void main(String[] args) 
	{
		Fonction monCarre = new Carre();
		Integrale monIntegrale = new Integrale(0, 1, 10000000, monCarre);
		System.out.println(monIntegrale.integraleMoyenne());
	}
}

Mais au départ j'ai fait ce post en réponse à une demande d'un lecteur qui souhaitait faire en java ce que je propose sur mon blog en JavaScript. C'est pour cela que je n’utilise pas de librairie mathématiques bien plus efficaces et pratiques

Et merci encore pour ta lecture attentive du code, c'est toujours un plaisir.

Marc,

@Potomac : Je suis entièrement d'accord avec toi.
A ceci près que, si tu connais une entreprise qui recruterait un développeur de plus de 50 ans indique la moi car je n'en ai jamais vu.
OK, tant pis pour le développeur, il fera un super architecte logiciel.
.... Finalement je vais peut-être monter une SSII de développeurs cinquantenaires, si certains sont intéressés.