Ca pourrait ĂȘtre intĂ©ressant ce topic, surtout si on est plus que @valsou, @Guiwy et moi Ă y rĂ©agir !
De mon cÎté, ça fait plus de 15 ans maintenant que je bosse dans le développement, en tant que full-stack developper, mais ces derniÚres années ont plutÎt été axées architecture, sécurité, et devops.
Jâai commencĂ© par du .Net (VB.net puis C#) dans lequel je me suis certifiĂ© Ă lâĂ©poque, mais depuis 5 ou 6 ans, je nâai pratiquement plus eu dâoccasion dâen faire. Chez mon employeur actuel, câest surtout du Java/Scala avec le framework Play que lâon utilise pour les back-ends. Parfois du SpringBoot.
CĂŽtĂ© front, jâai fait du ASP.net Webforms et MVC, du Struts (je prĂ©fĂšrerai oublier cette expĂ©rience), du SpringMVC, jâai touchĂ© un peu du Symfony aussi, mais Ă lâheure actuelle, câest que de lâAngularJS 1 (on commence Ă migrer vers le 2 maintenant que ça sâest bien stabilisĂ©).
CĂŽtĂ© mobile jâai fait beaucoup de Windows Mobile Ă lâĂ©poque, mais assez peu de Windows Phone/Android/iPhone/BlackBerry. Ca va reprendre cette annĂ©e pour ce qui est iOs et Android.
CĂŽtĂ© embarquĂ© jâai eu plusieurs projets aussi, certains en C ou C++, dâautres en J2ME, une approche et des contraintes bien diffĂ©rentes encore du dĂ©veloppement plus classique.
Actuellement, je ne dĂ©veloppe plus autant quâavant, mais je suis plutĂŽt chargĂ© de la mise en place dâarchitectures destinĂ©es Ă sâappliquer Ă lâensemble des apps et apiâs dĂ©veloppĂ©es chez nous, et de mettre en place des outils dâamĂ©lioration de productivitĂ©/qualitĂ©.
On a rĂ©cemment mis en place tout un environnement basĂ© sur des middlewares IBM (Datapower / API Connect / Security Access Manager) qui permet aux dĂ©veloppeurs de ne plus devoir du tout se soucier tout ce qui concerne lâauthentification et la façon dont les services sont exposĂ©es (que ce soit intranet, intra-groupe, avec les autres opĂ©rateurs tĂ©lĂ©coms, ou apps publiques web/mobile).
Toute la partie sĂ©curitĂ© est abstraite et gĂ©rĂ©e centralement, et tout ça couplĂ© Ă lâutilisation massive de Docker (qui facilite trĂšs fortement les dĂ©ploiements, le clustering et la haute dispo), et dâoutils permettant de faire du dĂ©ploiement continu (je pourrais vous en parler durant des heures de ça ) , câest que du bonheur pour dĂ©velopper en pouvant juste se concentrer sur la problĂ©matique âbusinessâ Ă rĂ©soudre!
Je suis dâailleurs invitĂ© par IBM avec un collĂšgue la semaine prochaine pour aller prĂ©senter cette archi Ă Las Vegas
Il semblerait que trĂšs peu de boites dans le monde aient combinĂ© ces produits de cette façon pour crĂ©er ce genre de plateforme destinĂ©e Ă hĂ©berger toutes les apps et apiâs. (tu mâĂ©tonnes, vu le prix astronomique que coĂ»tent les licences annuelles de ces produitsâŠ)
Sinon pour rebondir sur les dires de @Vernam, câest clair et net quâune fois quâon a goĂ»tĂ© aux ORM et quâon les maĂźtrise un peu, il nâest plus envisageable de sâen passer, et de devoir Ă©crire ce genre de code Ă la main. Que ce soit Entity, Hibernate, EBean ou des tonnes dâautres, ça vaut la peine de sây investir un peu dĂšs quâon commence Ă faire des apps avec un minimum de complexitĂ© au niveau du modĂšle de donnĂ©es.
@valsou Je me suis posĂ© une question en lisant la description de ton projet actuel : pourquoi tâes-tu fait chier Ă gĂ©rer le noscript? CâĂ©tait juste pour le sport de faire du progressive enhancement ou il y avait une autre raison?
Parce que de mon expĂ©rience perso, depuis dĂ©jĂ pas mal dâannĂ©es en milieu pro, mĂȘme pour les apps grand public, notre gestion du noscript câest juste lâaffichage dâun message âce site a besoin de javascript pour fonctionnerâ