C'est avant tout une relation de confiance. Un risque à prendre par le client donc.
Dans ma boite (startup si a ~20-30 personnes on est encore une startup) on est en agile mais on a trop de clients et selon moi n'avons pas assez de devs pour la quantité de nouveaux devs demandés (peut-être que les sales sautent trop sur tout et n'importe quoi meme si on a de grosses boites très connues comme clients), tous les developpements sont dictés par les nouveaux contrats signés par les sales sur des trucs pas encore développés, et avec des deadlines relativement serrées.
Les plus anciens font des semaines de 70+ heures c'est un délire, et même moi qui suis stagiaire on me demande d'augmenter mes heures -à demi mot bien sûr, jamais explicitement- et je sais pas quelle attitude adopter.
Donc l'agile tout dépend de comment c'est mis en place. Pourtant a coté de ça tout le monde est super cool et j'ai envie de rester...
PS : désolé pour le mini-pavé, je voulais juste donner un avis différent, et je suis saoul .
C'est vrai que la politique de la boite compte énormément, agile ou pas. J'ai la chance d'avoir un patron très très zen
Sinon, certains d'entre-vous font-ils de l'AngularJS (ou VueJS, React...) sans toute la couche Node, Grunt/Gulp, Bower etc ?
Autant j'aime la transpilation Typescript et SASS/LESS, mais tout le reste me fait vomir (je suis avant tout dev backend, et Maven est mon ami : je trouve Node lent, Grunt/Gulp trop compliqué & usine à gaz, et puis ça pue le JS).
Les docs Angular se basent toujours sur la même stack, j'en ai marre. Vous auriez de l'expérience sur des stacks différentes ?
J'avais envisagé une simple appli Web Java avec Maven, genre une ou deux servlets pour servir le contenu, et on met Angular dessus. Ca vous paraît réaliste ? Ou une base Python, ché pas. Je dois devenir officiellement dev fullstack, mais je vais droit vers le burnout avec ces bêtises.
Je vois pas ce qui empêche de faire du django ou flask avec vuejs (perso je partirai sur vuejs, pour éviter les usines à gaz). Après trouver de la doc sur le sujet je n'ai pas connaissance mais ça doit exister, django est quand même bien présent, par contre vuejs est peut etre un peu frais (et pas le plus répandu) pour déjà avoir des tutos/docs sur comment faire du django+vuejs.
Mais vous utilisez pas Gradle?
L'écosysteme JS une délivrance? Je connais la réputation de l'ecosysteme java comme usine a gaz mais JS à mes yeux c'est pareil.
Entre les différents package managers et le nombre de technos qui reposent dessus, puis le drama leftpad ne m'a pas rassuré non plus...
Récemment j'ai gouté aux deux mondes conjoints : Cordova. Pour faire tourner cette merveille il faut java, ant, git, node, npm ainsi que les outils android (sdk, platform tools et consorts).
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Si, si depuis quelques années déjà mais on bosse aussi sur des gros projets historiques en maven ....
Et oui Gradle est déjà un peu plus souple et bien plus moderne dans son approche que mvn, mais ça reste un cran au dessous au niveau ressources & co par rapport à l'écosystème autour de nodeJs.
- - - Mise à jour - - -
Je suis d'accord que les outils sont encore jeunes, mais y a quand même eu d'énormes progrès ces deux dernières années.
Le rapprochement entre IO.js et node.js, le passe à une version lts de node.js, ECMAScript 2015 qui se généralise etc...
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
C'est quoi le problème avec le JS en lui même ? Son écosystème oui, mais le langage ?
Le typage aux fraises, l'absence de stdlib digne de ce nom, les dizaines de petits "tips" qu'il faut savoir sinon tu te vautres sur des erreurs que tu comprends pas d'ou elles viennent.
Je parle bien de JS vanilla, sans framework sans rien (beaucoup de librairies modernes pallient à la plupart de ces problèmes).
Ouais ok mais on est plus à l'époque du JS vanilla, oui il n'y a pas de typage fort, oui il n'y pas de lib standard aussi complète que dans d'autre langages. Mais suivant ce qu'on a besoin de développer ça fait le job de façons rapide, propre et efficace, la communauté est extrêmement active et surtout, pour ma part, je prends du plaisir à coder en javascript aussi bien du code back que front.
Un mec a fait bien mieux que moi pour expliquer : http://sametmax.com/un-gros-troll-de...r-javacscript/
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
{insérez le pavé qui dit qu'on s'en branle de ce que ça fait quand tu additionnes 12 et un array dans la vie de tous les jours, même si tu peux faire des vidéos rigolol dessus}
{C'est pour le jeu de la biscotte ?}
{mais qu'ai-je fais, ça ne devait pas se passer comme ça }
Ce qui m'embête, c'est de trouver la stack alternative à Node+grunt/gulp/etc qui permette de rester un minimum sérieux si je veux un jour en parler lors d'un entretien. Je prends note des frameworks Python.
Aujourd'hui j'ai l'impression qu'un dev fullstack doit absolument parler Gulp, Mocha, etc. Je suis juste incompatible (en un mot) avec ces trucs.
C'est dommage car ce que j'aime beaucoup dans Angular (et tout ce qui fait la même chose) c'est de pouvoir clairement découpler le frontend du backend. Par exemple, quel plaisir de ne plus faire de Spring MVC ou Stripes, et se concentrer sur du REST En plus ça simplifie des aspects de la sécurité.
Mais peut être devrais-je attendre un peu. Je vois Gulp comme Ant : puissant mais reloux (et pas que). Ce n'est pas étonnant vu la jeunesse du bousin. Toute la stack frontend a l'air de renaitre depuis quelques années, et passe par les mêmes erreurs que le backend. j'espère que d'ici 2~3 ans on aura une stack un peu plus claire et efficace.
Grunt est en perte de vitesse (pour moi) mais était la référence pendant 4 ans. Gulp est très clean et expressif, principalement grâce au concept de pipe, tu peux faire une config basique en 30 lignes pour 90% des projets. J'appellerais pas ça Ant. Perso si j'avais un truc à lancer maintenant, j'utiliserais webpack.
Dans tous les cas, si tu veux faire du front "qui fait bien sur le CV", tu auras des problèmes de:
- live reload en cours de dev (intelligent, pas appuyer sur F5 dès que quelque chose change dans le dossier app/ - si je change une couleur dans le CSS ça devrait répercuter ça sans que je perde l'état de l'app par ex.)
- compilation depuis languages intermédiaires: SASS ou LESS, Coffeescript/ES6(aka.JS vanilla mais pas pourri)/JSX/etc.
- gestion des dépendances
- mise en commun de ces dépendances, que ce soit créer un gros bundle.js qui rassemble ton code et tes librairies, ou mettre les <script> des 92 dépendances bower dans ton index.html
- optimisations diverses pour la prod (minification, mettres tes images en sprites, etc.)
Faut bien les résoudre d'une façon ou d'une autre (même si tous n'ont pas la même importance). Y'a pléthore d'outils qui attaquent tout ou une partie de ces problèmes.
Personnellement, si tu attaques la chose sans avoir des repères, je te conseille de procéder à rebours: tu veux faire de l'angular, regarde ce que les mecs qui l'utilisent dans l'industrie et ont l'air de savoir ce qu'ils racontent utilisent, le truc qui fait "consensus" dans cette communauté là, et roule avec ça.
Le front là-maintenant c'est bien bien eco-système driven. 4 ou 5 frameworks/way of life qui regardent le même problème mais le résolvent différemment. C'est la même distinction que les langages.
Tu as pas les devs Java vs Python vs C#-vs Go vs Ruby, mais team React vs team Ember vs team Angular 1.X vs team Angular 2.X vs team templates HTML en back & jquery vs team wordpress.
Les uns sont aussi aliens aux autres que pour les langages.
T'arrêtes pas au cliché de "le front c'est une jungle totalement immature, les mecs ont oublié les 30 ans de programmation qui les précédaient". Il y a des raisons pour son existence, mais ça reste superficiel.
Si j'en parle c'est précisément que c'est mon cas (et c'est pas mon choix), la stack sur laquelle je travaille c'est JS+jQuery, à l'ancienne. jQuery pallie à la plupart des problemes de la stdlib inexistante de JS on est d'accord. Le problème du typage c'est pas juste le typage dynamique (python, ruby et même perl n'ont pas ces problèmes), l'absurdité du '===' pour comparer le type en plus de la valeur, le fait d'être autorisé à ne fournir qu'un argument si y en a 3 dans la définition de fonction et que du coup les deux autres default à undefined sans rien dire là ou 99% des langages te leveraient une erreur.
Ce langage est hostile envers le developpeur, plus je pratique moins j'aime.
PS : pour ne rien arranger le front n'est pas un domaine que j'apprécie beaucoup, j'en fais par nécéssité.
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Du coup ce que je comprend pas c'est qu'on produise des frameworks et des librairies à foison, que l'ecosysteme soit aussi dynamique alors que la base est moisie du cul, on dirait que ça fait kiffer les gens (un peu comme faire du cgi perl en 2016 parce que c'est 'nerd') et en même temps trendy parce que c'est du front et qu'on peut faire des trucs jolis (mais à quel prix?!).
Inertie technique : le langage de base restera le JavaScript parce qu'il est connu par tous les navigateurs, et les navigateurs n'ont aucune raison de rajouter un langage quand tous les devis front end connaissent le JS
Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09
Si tu penses que "l'ancienne" du web marche bien... T'as pas dû en faire beaucoup.
Oublie pas de faire une version flash de ton site hein
Ou alors tu as supputé que je pensais que vieux = nécessairement mauvais, ce qui est mal de ta part.
- - - Mise à jour - - -
J'ai du mal à vous comprendre.
Personne n'a envie de coder en langage machine. La base est vraiment moisie, waouh, 0 typage, pas de librairie standard. Dur.
Pourquoi est-ce qu'on produit langages et frameworks par dessus?
C'est pas compliqué.
1) Un navigateur ça lit du JS, qui de base est caca.
2) Le web c'est important, ça brasse masse cash, c'est dans la vie de tout le monde.
Qu'est ce que tu veux faire à part construire des surcouches (y compris des langages totalement différents type TypeScript) pour pouvoir faire du code propre, bien architecturé et reposant sur des principes solides?
En quoi ça a quoique ce soit à voir avec de l'inertie tech? Si c'était ça, le mouvement serait pas à la multiplication des frameworks et des langages qui compilent vers JS, mais au vanilla JS qui "est compris par tout le monde".
Ou alors vous en voulez vraiment qu'aux éditeurs de navigateurs? Dart5lyfe?
C'est pas Mozilla qui parlait de flancher sur une future alternative au JS, qui cette fois-ci serait directement compilée dans une sorte de bytecode, donc plus rapide/léger, mais en perdant le côté "c'est juste du texte" (d'ailleurs comment qu'on dit ça ? ).
Ce n'est pas non plus pour bientôt, mais l'idée me semble bonne.
Je saurais pas te dire si c'est du mozilla ou pas mais c'est un truc dans l'air oui.
Tiens, autre chose auquel ça me fait penser, c'est Scala.js. Scala c'est un language que j'adore, à bonne réputation académique, avec un système de typage très solide. Avec ça, tu peux en écrire puis le compiler en JS. Tu n'as quasiment pas de limitations, tu peux y faire tout ce que tu ferais avec du JS (manipulations de DOM, calls API, etc.).
Au début ma réaction c'était naturellement "what the fuck, jamais je met ça en prod, ça doit être ingérable". Mais de ce que j'en ai lu et après avoir discuter avec une amie plutôt douer en écriture de codez et pas bête, le truc a l'air assez solide.
Même sans le truc dont tu parles qui me semble aussi une bonne idée, y'a des gens qui y vont en disant "OK, au final le browser va lire du JS, mais on s'en moque, y'a qu'à surcompiler par-dessus".