Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 157 sur 309 PremièrePremière ... 57107147149150151152153154155156157158159160161162163164165167207257 ... DernièreDernière
Affichage des résultats 4 681 à 4 710 sur 9247
  1. #4681
    C'est avant tout une relation de confiance. Un risque à prendre par le client donc.

  2. #4682
    Citation Envoyé par gros_bidule Voir le message
    Huhu, ça fait maintenant 1 an que je bosse dans une startup où l'on pratique véritablement l'agilité. Je n'ai jamais été aussi tranquille ; zéro stress, et les clients semblent satisfaits.
    Malgré un salaire moindre (l'effet startup n'aide pas non plus), pour rien au monde je ne reviendrais dans une boite qui applique les méthodos plus classiques.

    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 .

  3. #4683
    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.

  4. #4684
    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.

  5. #4685
    Pour moderniser un peu nos nouveaux projets, j'avais bossé sur des projets ASP MVC classique et nous nous servions d'AngularJS pour dynamiser nos pages. Hormis Bootstrap, il n'y avait aucun autre framework et ça marchait très bien.

  6. #4686
    Citation Envoyé par gros_bidule Voir le message
    ... dev backend, et Maven est mon ami : ... Grunt/Gulp trop compliqué & usine à gaz...
    Tu es sûr de t'y être penché assez longtemps ? De mon point de vue, etant en train d'évoluer de 7ans de java vers du javascript, je vis l'ecosystème node / npm comme une délivrance, maven se pose là comme usine à gaz quand même.

  7. #4687

  8. #4688
    Citation Envoyé par Sangoon Voir le message
    Tu es sûr de t'y être penché assez longtemps ? De mon point de vue, etant en train d'évoluer de 7ans de java vers du javascript, je vis l'ecosystème node / npm comme une délivrance, maven se pose là comme usine à gaz quand même.
    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).

  9. #4689
    Citation Envoyé par Nattefrost Voir le message
    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.
    C'est pas pareil c'est pire. Au moins l'écosystème Java est mature. Le JS est ultra bouillonnant mais les outils sont encore complètement immatures. Ça sera mieux dans 3 ans je pense mais pour le moment c'est la jungle.
    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

  10. #4690
    Citation Envoyé par TKN Jez Voir le message
    Mais vous utilisez pas Gradle?
    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 - - -

    Citation Envoyé par Teocali Voir le message
    C'est pas pareil c'est pire. Au moins l'écosystème Java est mature. Le JS est ultra bouillonnant mais les outils sont encore complètement immatures. Ça sera mieux dans 3 ans je pense mais pour le moment c'est la jungle.
    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...

  11. #4691
    Citation Envoyé par Sangoon Voir le message
    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...
    Y'a eu des progrès, mais ça reste loin, tellement loin, d'un truc agréable a utiliser. Et puis le langage, mon Dieu...
    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

  12. #4692
    C'est quoi le problème avec le JS en lui même ? Son écosystème oui, mais le langage ?

  13. #4693
    Citation Envoyé par Monsieur Odd Voir le message
    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).

  14. #4694
    Citation Envoyé par Nattefrost Voir le message
    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.

  15. #4695
    Citation Envoyé par Monsieur Odd Voir le message
    C'est quoi le problème avec le JS en lui même ? Son écosystème oui, mais le langage ?
    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

  16. #4696
    {insérez le pavé de défense du JS que j'ai fait y'a genre 6 pages}

  17. #4697
    Citation Envoyé par Charmide Voir le message
    {insérez le pavé de défense du JS que j'ai fait y'a genre 6 pages}
    {insérer les arguments de Sam sur le fait que l'ecosystème est peut-être excellent, le JS reste un langage de merde}
    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

  18. #4698
    {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}

  19. #4699
    {C'est pour le jeu de la biscotte ?}

  20. #4700
    Citation Envoyé par Charmide Voir le message
    {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}
    Case in point.
    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

  21. #4701
    {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.

  22. #4702
    Citation Envoyé par gros_bidule Voir le message
    {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.

  23. #4703
    Citation Envoyé par Sangoon Voir le message
    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.
    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é.

  24. #4704
    Eh ouais, le "à l'ancienne" ça marche pas trop bien.

  25. #4705
    Citation Envoyé par Charmide Voir le message
    Eh ouais, le "à l'ancienne" ça marche pas trop bien.

    Gniii... Se retenir de remettre une pièce dans le jukebox

    Et accessoirement demain j'attaque un projet full front sans back-end. Et surtout sans node.js. ça va pas être simple...
    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

  26. #4706
    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?!).

  27. #4707
    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

  28. #4708
    Citation Envoyé par Teocali Voir le message
    Gniii... Se retenir de remettre une pièce dans le jukebox
    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 - - -

    Citation Envoyé par Nattefrost Voir le message
    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?!).
    Citation Envoyé par Teocali Voir le message
    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
    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?

  29. #4709
    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.

  30. #4710
    Citation Envoyé par gros_bidule Voir le message
    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".

Page 157 sur 309 PremièrePremière ... 57107147149150151152153154155156157158159160161162163164165167207257 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •