Discussion :

[LSMetag]

Je me demande pourquoi tu dis que tu dois rajouter tel serveur, pourquoi "rajouter", quand vous utilisez les EJB, ranger Tomcat à côté, et utiliser un seul serveur qui a toutes les fonctionnalité.

Pourquoi payer, alors qu'il y a des version open source de conteneur d'EJB, il y a Glassfish de sun, fourni part défaut en téléchargeant Netbeans.



Quand vous voulez acheter une Ferrari c'est que vous êtes riche et il faut assumer aussi la responsabilité de la consommation.

Mais vous n'êtes pas obligé d'acheter un serveur WebSphere pour debugguer, dans le moment où on installe par exemple GlassFish dans nos PC local, et on debugguer.

Moi, je dis que ce qu'empêche au gens d'utiliser les versions free et opensource, les spécifications sont les même que pour JDK et OpenJDK, j'allais dire que c'est le support qui manque pour les version free.

Pour être franc, je ne vois pas trop une entreprise utiliser GlassFish OpenSource Edition. Donc oui même pour GlassFish il faut passer à la caisse.

Sur un projet Websphere qui utilise ses spécificités portail (WCM et WPA), pas possible d'installer un autre serveur d'applications pour débugguer.
Je ne suis pas responsable des choix techniques, malheureusement. C'est une DSI qui a décidé à la place des gens sur le terrain.

Qu'une entreprise utilise OpenJDK, je n'ai encore jamais vu. Ils sont tellement attaché au support (utile ?).

Sinon, j'avais commencé à développer une petite appli console pour garder un suivi des tâches en cours. Récupération de données, calculs et écriture du résultat dans document Excel.
Je l'ai ensuite portée derrière en .NET. Performances n'ayant rien à voir, beaucoup moins de lignes de code (merci LINQ et les Lambda expressions).
Pourtant, à part les requêtes LINQ, je n'ai fait qu'un portage de code.
Après peut-être qu'il y a des subtilités entre les 2 technos.

[Gugelhupf]

Je sais que Struts c'est fini. J'ai pratiqué Spring ^^. Et bien justement, avec Symfony, on peut également bosser par composants.

Le framework Spring n'a rien à voir avec JSF2. On ne parle pas des mêmes "composants"...
Struts, Symfony, ASP.NET, Spring MVC (avec ses balises "bean" beurk)... c'est à peu prêt la même soupe pompé sur RoR. Regarde du coté des frameworks orienté composant tu comprendras la différence

[LSMetag]

J

Si un jour il y a un news sur des failles des produits Microsoft, c'est pour nous dire que Microsoft a corrigé tel faille qui existait, je me souviens un jour d'avoir lu un news que MS a corrigé des failles sur .Net .

S'il y a bien un langage mourant c'est .Net côté client, Microsoft l'enterre bien et personne n'en parle.

Je me demande s'il peux survivre aussi long temps côté serveur, car déjà Microsoft a commencé à supporter Node.js, il l'a intégré a Windows Server, Azure et Visual Studio et de plus côté serveur c'est linux le géant, et je me demande s'il y a des serveur linux qui hébergent des site .net avec mono, ou que mono est là en tant que spectateur.

Personne ne parle de la lourdeur de .net côté serveur, java lui dépasse de loin.
Silverlitght est mort aussi.

Et bien tout simplement on dirait Developez.com c'est une boite à Microsoft, faire l'éloge des produits Microsoft et même ses campagnes, et quand il y a une faille sur android ou java, on en parle.

D'après ce que j'ai vu, Developpez.com signale toujours les failles de Windows et de ses outils (notamment les failles Zero Day). Je ne vois pas où est la discrimination. Après c'est vrai que j'ai peu vu de failles au niveau du framework .NET.

.Net niveau client, si tu parles de Silverlight, c'est tout simplement parce que Microsoft a fait le choix de s'investir sur HTML5 à la place (il participe activement à un organisme de normalisation, je ne sais plus lequel). A mes yeux, je trouvais Silverlight techniquement mieux que Flash, mais il n'est pas possible de détrôner un truc si intégré à la vie du Web. Ils ont misé à la place sur Javascript/HTML 5.

Après, pour les interfaces client, WPF n'est pas du tout à l'abandon et continue de se développer (par contre oui le Winform c'est de l'histoire ancienne). On peut d'ailleurs l'utiliser façon applet Java avec les xbap.

Sinon je veux bien convenir que Mono doit être peu utilisé en entreprise. Mais je me demande si Linux est si dominant niveau serveurs. C'est pas ce que je remarque au niveau des offres d'emplois.

Pour la personne qui dit que .NET est ultra lourd par rapport à un serveur d'applications Java, et bien qu'il compare le démarrage de son Windows 7/8 avec son serveur .NET intégré, et la même chose avec un serveur d'applis Java.
Qu'il compare le démarrage et la navigation de Visual Studio à ceux d'Eclipse.

Et pour ceux qui disent que Visual Studio est commercial et ne peut pas être amélioré par la communauté, qu'ils revoient leur copie. Visual Studio possède une version Express totalement gratuite. Par contre, j'en conviens, il faut une version payante pour bénéficier des addins de la communauté, qui sont gratuits pour la plupart.

[LSMetag]

Le framework Spring n'a rien à voir avec JSF2. On ne parle pas des mêmes "composants"...
Struts, Symfony, ASP.NET, Spring MVC (avec ses balises "bean" beurk)... c'est à peu prêt la même soupe pompé sur RoR. Regarde du coté des frameworks orienté composant tu comprendras la différence

Merci de l'info

[LSMetag]

Hum hum...

Quelques exemples:
- le topic courant (qui essaie quand même de nous faire comprendre que Java c'est nul, de façon à peine déguisée, et qu'on arrive à faire 100x mieux pour moins cher avec moins de lignes de code en changeant de langage, y compris sur les serveurs)
- Java est-il un langage de programmation mourant?
- Java est mort et JavaScript pourrait remplacer Flash
- sans compter tous les "Java vs Xxx" que l'on trouve sur la page best of Développement, et qui finissent à peu près tous par conclure que Xxx est mieux que Java, ou par sortir des chiffres montrant combien Java c'est nul..
- plein d'autres que je ne retrouve plus... mais y'a qu'à attendre, chaque semaine y'a autre chose qui est publié...

Il y a clairement plus de topics à vocation de calomnie de Java que le contraire...

Désolé, mais j'ai de plus en plus un arrière-goût amer en voyant mon langage favori tomber en disgrâce... et de façon vraiment pas justifié à mon avis...

Franchement, tu coupes certains titres. En général c'est des reprises de propos de gens interviewés, avec ensuite "Qu'en pensez-vous ?"

On dit : y a pleins de langages qui sortent, y a des développeurs qui se plaignent de ça, y en a même un qui avance que Java est mourant, comment Java arrive-t-il à rester le meilleur malgré la flambée de toutes ces nouvelles technos ? "Java est-il réellement mourant ?"

Où est la calomnie ? Javascript subit le même traitement quand on parle de Dart et un débat est ouvert sur le forum.

Je crois qu'être fan d'un langage ou d'une techno n'est pas une bonne chose. Ca déforme les jugements, et ça empêche d'avancer sur autre chose.

[Lcf.vs]

Je viens de lire un peu tous vos posts et une chose me frappe...

Vous ne parlez tous que de l'aspect performances... pourtant, un des gros avantages de Node.js, c'est justement qu'il exécute du JS, qu'on exécute aussi côté client!

Jeffe Harrell, directeur de l’ingénierie chez PayPal, décrit dans un billet de blog, les avantages architecturaux de passer de Java à JavaScript. « Imaginez un développeur HTML qui doit demander à un développeur Java de lier la page A et B », explique Harrell.

Devant ce problème, PayPal devait avoir recourt des développeurs ayant des compétences différentes pour l’application Web et l’application serveur. « Chez PayPal, le bloqueur primaire a toujours été la limite artificielle que nous avons établie entre le navigateur et le serveur », explique celui-ci.

Pour surmonter cette situation, PayPal s’est tourné vers Node.js, qui a permis à la fois d’écrire les applications devant s’exécuter dans le navigateur et les applications serveurs en JavaScript. « Il [N.D.L.R : Node.js] unifie nos spécialités pour nous permettre de créer une équipe qui comprend et réagit rapidement aux besoins des utilisateurs à n’importe quel niveau dans la pile de technologie », justifie Jeffe Harrell.

Là où se situe donc le gain majeur, c'est en termes de développement...

Tout le monde parle le même langage et connaît les mêmes outils, réduction des coûts de formations et ceux du personnel (puisqu'un seul langage suffit, plus besoin d'engager des gens connaissant d'autres langages), brainstorming plus aisé, etc.

<troll>Par contre, je ne savais pas qu'il fallait des ingénieurs pour faire du développement sous Node </troll>

<trollbis>J'vais sûrement avoir plein de - par les défenseurs du Java... se rendant compte qu'ils ne servent plus à rien. lol</trollbis>

[remydarcel]

Le choix de la bonne technologie doit dépendre du type de solution qui doit être mise en place et des contraintes à l'intérieur de la société.

Il n'y a pas 1 bonne solution à tous les problèmes. Si on doit monter un système de blog on va probablement s'orienter sur PHP. Pour faire du RAD simple on utilisera aussi PHP. Pour du RAD avancé si on a les compétences du RoR, si on a un gros besoin de performance sur des solutions avec une couche métier non négligeable on s'orientera plutôt sur du play framework ou du vert.x etc...

Dans le cadre de paypal, j'imagine qu'un bon paquet de leurs outils consistent à traiter des flux d'informations (vers Visa, MasterCard, API => cœur du système) etc...

Dans ce cadre node.js est probablement une bonne solution car il est plutôt doué pour traiter des flux de données XML/JSON surtout lorsque les traitements sont simples ou décomposables en élément simple. Par contre sur les composants métiers plus complexes j'ai quelques petits doutes (mais je n'ai pas une forte expérience sur Node non plus).

Ps : Pour les supporters de la programmation orienté composant java, ceux-ci ne sont pas plus avancés en soit que des frameworks de type ASP.NET MVC, RoR ou Symfony. Ils utilisent juste une approche différente qui rajoute certes une couche d'abstraction par rapport aux technologies web mais qui n'est pas toujours justifié en particulier lorsque l'on souhaite faire du spécifique en terme d'UI et/où que les développeurs ont de bonnes connaissances en web. Par exemple dans le cadre d'une exploitation de données multi-support avec API rest + interface web, un framework MVC + système de data-binding javascript type knockout ou angularjs sera probablement plus efficace.

[fr1man]

@LSMetag

Il y a bien plus d'entreprises qui utilisent des serveurs sans payer de support, que tu ne le penses. Ne serait-ce que de ma propre expérience, j'ai connu pas mal de projets avec des Tomcat, JBoss, Jonas en production, sans payer quoi que ce soit.

Quant à la lourdeur de JEE, personne ne t'oblige à utiliser toute la pile d'API si ton projet est simple. On peut faire de bonnes applications sans aucun framework compliqué à mettre en place. Après si ton projet est complexe, c'est quand meme rassurant d'avoir un ensemble d'API permettant de traiter des sujets comme la sécurité, la gestion de transactions, transactions distribuées, communication inter-application vias JMS, etc...

[LSMetag]

@LSMetag

Il y a bien plus d'entreprises qui utilisent des serveurs sans payer de support, que tu ne le penses. Ne serait-ce que de ma propre expérience, j'ai connu pas mal de projets avec des Tomcat, JBoss, Jonas en production, sans payer quoi que ce soit.

Quant à la lourdeur de JEE, personne ne t'oblige à utiliser toute la pile d'API si ton projet est simple. On peut faire de bonnes applications sans aucun framework compliqué à mettre en place. Après si ton projet est complexe, c'est quand meme rassurant d'avoir un ensemble d'API permettant de traiter des sujets comme la sécurité, la gestion de transactions, transactions distribuées, communication inter-application vias JMS, etc...

Justement, quand j'ai parlé d'un projet simple que j'avais développé, c'était juste une appli console SANS aucun API.

Et bien, au moins il y a des entreprises intelligentes alors.

Je ne remets pas du tout en cause la qualité des API de JEE et de la communauté. Je mets juste en avant que les autres technos font désormais pareil, parfois en mieux.
C'est là où je veux en venir. Et c'est pour ça que JEE n'est plus si incontournable qu'avant. JEE est très riche et complet, mais certains auront maintenant tendance à préférer une architecture plus hétérogène, composée d'éléments "meilleurs" que les API JEE dans leurs domaines.
Je trouve JEE plutôt sclérosé depuis la reprise par Oracle, alors que les autres technos évoluent à vitesse grand V. Dart poursuit ses mises à jours même après la sortie de la version 1.0 par ex...

[23JFK]

Sont malins chez paypal, ils ont réussi à mettre dans leurs serveurs une technologie encore plus prisée par les blackhats que le java. Vue la facilité avec laquelle se réalisent des attaques par injection sous javascript (merci le typage faible), tout le temps qu'ils pensent avoir gagné en production, va être perdu en sessions de rustinages.

[fr1man]

@ LSMetag

Sauf que l'ecosystème JAVA est dépendant du JCP et que les choix faits sont réfléchis pour ne pas tout remettre en cause tous les ans.
C'est quand même plus facile pour une équipe qui ne dépend de personne, de pondre un Node.js, un Playframework ou autre.
C'est bien beau tous ces nouveaux frameworks qui sortent tous les mois, mais qui sait ce qu'ils deviendront dans quelques mois mois/années.
Tu pars sur du standard, tu sais que ça ne sera pas abandonné en peu de temps, et que tu continueras à trouver de la main d'oeuvre compétente.
Peut-être que Node.js ou autre, ne sera qu'un pétard mouillé et vite oublié...qui peut le dire...

[Washmid]

Je suis d'accord avec ce développeur. Je rajouterais qu'il en va de même pour .NET. Javascript est très tendance avec son modèle asynchrone et ses Frameworks, a une demande augmentant fortement depuis quelques années, permettant d'effectuer des développements portables, réactifs.

Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.

Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !



Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque.

[imikado]

Sont malins chez paypal, ils ont réussi à mettre dans leurs serveurs une technologie encore plus prisée par les blackhats que le java. Vue la facilité avec laquelle se réalisent des attaques par injection sous javascript (merci le typage faible), tout le temps qu'ils pensent avoir gagné en production, va être perdu en sessions de rustinages.

Javascript est typé: http://web.developpez.com/actu/59624...-a-l-accepter/

De plus, le typage ne protège pas de tout: pour un type string, on peut faire du xss et/ou de l'SQL injection

Et concernant le XSRF/DDOS le typage ne protège en rien

[Gugelhupf]

Javascript est typé

A vrai dire je ne connais pas de langage avec des variables non-typé.

En PHP et JavaScript il est possible de faire ce genre de chose :

Code :

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

1
2
3
4
5
var entier= 1;
alert(typeof(entier)); // number

entier= "1";
alert(typeof(entier)); // string

En Python, même si on ne précise pas le type (duck typing), ce genre de chose n'est pas permis par exemple.

Le fait de pouvoir effectuer des opérations mathématiques sur certaines chaines de caractères (au format entier/décimal) rend la maintenance plus difficile.

Mais je ne sais pas si c'est le pire, en ce qui concerne la portée des variables par exemple (valable aussi pour PHP) :

Code :

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

1
2
3
4
5
if(true){
    var toto = 1;
}

alert(toto); // Affiche 1, variable toto existe toujours

[bunam]

Je me demande si paypal™ a utilisé SmartOS de Joyent qui est la boite qui a crée NodeJS...
SmartOS doit être la meilleure alternative pour faire du NodeJS (dtrace, isolation avec les zones...)
Si oui c'est un aussi un mauvais coup pour Red Hat ou Oracle qui devait fournir précédemment l'OS.

[lxwfr]

Déjà appris ses quelque fonction à vrai n'utilise jamais, Peut-être dû au FAILLES DE SECURITE (Les nouvelle mise à jours=correction).
No.JS j'ai pensé !!! je vais apprendre plus tard (déjà vu quelque part).

[oLie]

Le problème initial chez PayPal étant la rationalisation de leurs compétences JS, je pense que l'objectif est atteint.

Au sujet des perfs, les avancées technologiques couplées à une efficacité budgétaire promeuvent l'application du "commodity hardware", déresponsabilisant le développeur sur l'aspect performance (voir aussi sur la production de code "propre"). C'est d'ailleurs le même principe avec le NoSQL, on "l'accepte" aujourd'hui car le hardware est capable de supporter ce qui était considéré comme de mauvaises pratiques il y a 20 ans sur du hardware moins performant.

Au final, [ame="http://www.youtube.com/watch?v=AFXK03FCa14"]c'est (et ça a toujours été) la monnaie qui dirige le monde[/ame], nous ne sommes que des pions qui, au mieux, cherchent des solutions efficientes dictées par la direction financière et relayé par la DSI, ou au pire, qui subissent des choix d'orientations technologiques parfois douteuses, dictées par des "solutionneurs" d'efficience

[nah-masse-the]

@oLie: ca fait beaucoup de buzword pour dire que l'ingenieurie logiciel est une science qui evolue, si on a du NoSQL aujourd'hui c'est pour pouvoir scaler horizontalement les bases de donnees, pas une question de bonne ou mauvaise pratique... Deja entendu parler du CAP theoreme?


@Gugelhupf: Tout les languages sont types, la seule difference se fait au niveau du typage for ou faible. Le C est type faiblement, tu peut acceder a une valeurs en memoire en la considerant comme un entier ou une chaine de caratere.


@FelipeVervena
"La majorité des pages de Paypal sont servies en CGI : autant utiliser C++ ou C pour une performance maximale plutôt que JS ou Java. Il serait temps de revenir aux sources encore faut-il trouver les compétences."

Va donc coder en assembleur, sans bibliotheque standard pour s'occuper de la memoire ou des entree sortie standard. Serieusement. Fait le. Retourne au sources. J'ai des cartes perforees pour toi si tu veux.


@Washmid
"Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.
Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !
Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque."

Enfin un peu de bon sens, merci.

[oLie]

c'est interessant comme idée, dans ce cas pourquoi ne pas l'avoir inventé dès le début...

[LSMetag]

Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.

Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !



Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque.

Pour être franc, je bosse d'abord au feeling. Si une techno m'intéresse et me semble utile, je l'étudie.

Même en autodidacte, les entreprises qui voudront l'utiliser te prendront car peu la maîtriseront. Donc beaucoup moins de concurrence que si tu rentres dans le moule avec J2EE que tout ingénieur a appris à l'école.

Alors il y a une part de risque à faire ça. Mais me concernant ça a bien payé.

Après, on peut sortir le raisonnement inverse. On ne connaît pas l'avenir d'une techno jeune. Mais pourquoi justement ne pas participer à cet avenir plutôt qu'être attentiste ?

Justement, je ne suis pas très raccord avec les entreprises qui ne misent que sur du mature, car je n'aime pas l'inertie. Je préfère utiliser tout le panel des technos qui s'offrent à moi pour choisir ce qui conviendra mieux à mon application et à ses utilisateurs.

Bien sûr, il faut bien concevoir son appli pour faciliter les migrations en cas de pépin. Il faut aussi garder en tête qu'il faudra choisir les ingénieurs pas forcément par rapport à leur CV, mais par rapport à comment est faite leur tête, et leur laisser quelques semaines pour se former.