Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 67 sur 183 PremièrePremière ... 1757596061626364656667686970717273747577117167 ... DernièreDernière
Affichage des résultats 1 981 à 2 010 sur 5463
  1. #1981
    Citation Envoyé par Helix Voir le message
    Un minimum de C me semble être indispensable. Il fait office de glue, c'est difficile de s'en passer si on veut utiliser une bibliothèque X avec un langage Y.
    Bof, ça dépend vraiment dans quel domaine tu bosses.
    Mais c'est toujours intéressant de faire un peu de bas niveau en effet.

    Pour la place de Python, c'est pas étonnant vu la popularité du langage.
    Pour Go, Rust, TypeScript, Swift et Kotlin, ce sont des langages récents et modernes qui fournissent de très bonnes alternatives par rapport aux langages classiques de leurs domaines respectifs.

    C'est plus le positionnement de Scala qui me surprend.
    C'est la faute à Arteis

  2. #1982
    Packt est un éditeur qui cherche encore sa place, et est très agressif sur les tarifs et la taille de l'offre : c'est incroyable de voir la facilité qu'on a en temps qu'auteur de pouvoir sortir un bouquin chez eux, avec des droits d'auteurs intéressants.
    Mais voilà, à mon goût ils en font trop, et la qualité est clairement inégale d'un bouquin à un autre.
    Les voir mettre en avant Scala ne me surprend pas : Packt met en avant les sujets qu'il couvre le plus et qu'il aimerait que vous achetiez , pas les sujets vraiment intéressants pour les devs.

    Aujourd'hui Scala tu en fais où ? Dans le milieu scientifique (bien que Python lui fasse une sacrée concurrence), certains outils comme Gatling, deux-trois barbus sur Akka, et en gros voilà. C'est un peu comme Groovy : il a eu son heure de gloire, mais c'est vieux, ça ne bouge pas assez, et des langages plus modernes ont eu l'intelligence de s'en inspirer pour en prendre les qualités sans les défauts (ex: Kotlin).

    Mais c'est toujours intéressant de faire un peu de bas niveau en effet.
    Je rejoins ton avis. Ne serait-ce que pour savoir comment fonctionne un programme, ou un PC (c'est quoi la ram, les caches L1, le multithreading ce n'est pas "magique", etc).
    Je vois de plus en plus de jeunes (ingés ou pas) qui sortent de l'école tout fiers d'avoir fait une appli Spring Boot, mais ils ne savent même pas ce qu'est un pointeur. Un pointeur quoi, et il leur faut donc du temps (et faire des bêtises) pour réaliser que tu peux facilement modifier un objet passé à une méthode, par exemple.
    Je trouve cela dommage : en perdant les bases on fait des bêtises sans en avoir conscience, et on en vient à élaborer des bonnes pratiques qui n'en sont pas.

  3. #1983
    Citation Envoyé par gros_bidule Voir le message
    Packt est un éditeur qui cherche encore sa place, et est très agressif sur les tarifs et la taille de l'offre : c'est incroyable de voir la facilité qu'on a en temps qu'auteur de pouvoir sortir un bouquin chez eux, avec des droits d'auteurs intéressants.
    Mais voilà, à mon goût ils en font trop, et la qualité est clairement inégale d'un bouquin à un autre.
    Les voir mettre en avant Scala ne me surprend pas : Packt met en avant les sujets qu'il couvre le plus et qu'il aimerait que vous achetiez , pas les sujets vraiment intéressants pour les devs.
    Je suis dans l'ensemble assez d'accord en rajoutant quand même qu'avec le nombre d'eBook qu'il offre tous les ans je me demande comment il ne coule pas...

    J'ai déjà plusieurs fois été surpris de voir des livres de chez eux dans les centres de services, les bureaux, what ever. Y a des gens qui les achètent

    Je vous rejoins pour le bas niveau bien que j'en ai fais que très (trop?) peu, pointeur, liste chainé, doublement chainé (doublement aie), triplement chainé (aie aie aie) (Bon après je fais plus du tout de dev'...). A un moment, j'avais même envisagé de pousser en C / C++ juste car je pense que c'est une bonne base pour après touché à d'autres langages (C#, Objective-C, Swift... ).
    Citation Envoyé par Kazemaho Voir le message
    Ma cherie arrete pas de raler qu'elle en veut une plus grosse, plus moderne, plus plus plus et moi j'y comprends rien.

  4. #1984
    Citation Envoyé par ook4mi Voir le message
    Loin de moi l'idée d'être un expert mais afin de donner un peu de vie au topic, je tente un partage. N'hésitez pas à donner vos avis .

    D'après Packt (donc ça vaut ce que ça vaut... Même si je suis fan de leur ebook gratuit, c'est pas forcément les mieux placés pour ce type d'article.)

    En 2019 :
    1) Python
    2) Go
    3) Rust
    4) TypeScript
    5) Scala
    6) Swift
    7) Kotlin
    8) C

    Je ne sais pas vraiment quoi en penser... Je ne suis pas surpris pour Python car clairement on en entend tellement parler dans beaucoup de domaine et la facilité à pondre ces premières lignes de code en font un super outil pour démarrer le développement / devenir développeur tout court :D .

    Je suis un peu surpris par le C qui je pense est un langage vieillissant même si très performant. J'en ai fais que à la fac mais dans le monde professionnel, il y a quelques années quelques clients avaient des batchs en C sur des serveurs Linux mais je croise de plus en plus d'autres solutions pour les traitements de type Batch chez les clients du coin donc je le pensais en déclins...

    Je n'ai par contre, jamais touché les autres langages (même si GO m'a longtemps fait de l'oeil).

    Cool, je connais et j'utilise déjà les 4 premiers de la liste.
    "Nobody exists on purpose. Nobody belongs anywhere. We're all going to die. Come watch TV." - Morty Smith

  5. #1985
    Pareil, j'apprends le dev sur mon temps libre avec python, un peu de js/php,... et plus le temps passe et plus j'essaie à mon tout petit niveau de faire les choses "à la main" pour mieux comprendre comment ça marche. Plutôt que d'utiliser certains "outils" qui facilitent la vie mais qui amènent trop d'abstraction. Genre bootstrap pour le templating, jquery, requests pour python, etc...

    Bon on est loin de c++, java et d'autres langages velus sur lesquels j'arriverais même pas à faire un hello world, mais j'imagine que le même principe est applicable partout.

  6. #1986
    Des ouvrages sur Python pour les intéressés:
    https://www.humblebundle.com/books/p...ckt-2019-books
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  7. #1987
    Citation Envoyé par ook4mi Voir le message
    qu'avec le nombre d'eBook qu'il offre tous les ans je me demande comment il ne coule pas...
    Simple :
    - l'auteur est payé avec les droits d'auteur, + une petite avance sur ceux-ci (pour un auteur débutant c'est 150~250USD)
    - le travail de relecture technique est en grande partie (sinon intégralement) effectué par d'autres auteurs, et ce gratuitement (ils sont payés en recevant un exemplaire du bouquin qu'ils relisent+ leur nom dans ledit bouquin + un bouquin au choix , rien de plus)
    Vu comme ça, si l'auteur est d'accord pour "donner" son bouquin, ça ne doit quasiment rien coûter à Packt Publishing.

  8. #1988
    Citation Envoyé par gros_bidule Voir le message
    Aujourd'hui Scala tu en fais où ? Dans le milieu scientifique (bien que Python lui fasse une sacrée concurrence), certains outils comme Gatling, deux-trois barbus sur Akka, et en gros voilà. C'est un peu comme Groovy : il a eu son heure de gloire, mais c'est vieux, ça ne bouge pas assez, et des langages plus modernes ont eu l'intelligence de s'en inspirer pour en prendre les qualités sans les défauts (ex: Kotlin).
    This. Tu as raisons sur tous les points. Excepté que Scala est utilisé également dans le milieu professionnel si tu as besoin de truc pas mal distribué. Genre, chez restore.eu.

    Par contre, c'est vrai que Kotlin fait autant en plus facile. Avec en plus le gros avantages d'avoir une chaine de tooling beaucoup plus pratique (car basée sur celle de Java). j'ai un pote qui bosse en scala (chez Restore, justement) et il rale un peu sur le langage (surtout après avoir gouté à Kotlin) mais surtout, surtout, sur la chaine de tooling.

    C'est à mon avis le gros gros point fort de Kotlin. Les mecs de Jetbrains ont le gros avantages de posséder le meilleur (full stop) IDE Java sur le marché à l'heure actuelle, donc toutes les nouveautés Kotlin sont intégrées immédiatement. Tu rajoutes à ça le fait que Google à très vite adopté le langage, et que les plugins Maven et surtout gradle sont sortis dans la foulée, tu te retrouves avec un langage qui a de très grande chance de venir faire des chatouilles à Java. Bien plus que Scala et Groovy, dans tous les cas.

    Perso, pour mon client principal, je bosse en Kotlin/Spring/Hibernate, sur une base de code en Java, et c'est juste le rève.
    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

  9. #1989
    Citation Envoyé par Teocali Voir le message
    Perso, pour mon client principal, je bosse en Kotlin/Spring/Hibernate, sur une base de code en Java, et c'est juste le rève.
    Je confirme.
    Pour les projets Android, c'est aussi le pied.
    C'est la faute à Arteis

  10. #1990
    Citation Envoyé par Orhin Voir le message
    Je confirme.
    Pour les projets Android, c'est aussi le pied.
    j'imagine.
    Perso, Je suis juste en train de réfléchir à me débarasser d'Hibernate. Faut que je prenne de regarder comment fonctionne JOOQL avec Spring.

    Ah, et sinon, au passage, j'exècre les mecs qui ont pensé, à quelque époque que ce soit, que c'était une bonne idée d'encoder un document XML dans un paramètre d'URL... surtout ceux, quand tu leurs fais remarquer, qui te réponde "Bah, comment tu fais pour passer une requète HTTP GET avec ton Xml, alors ?"
    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

  11. #1991
    Non mais déjà le XML pour les API c'est le mal.
    C'est la faute à Arteis

  12. #1992
    Citation Envoyé par Orhin Voir le message
    Non mais déjà le XML pour les API c'est le mal.
    Ouais, enfin là, ils ont une excuse : leur truc existe depuis 2003.

    Mais même en 2003, la méthode HTTP POST existait, donc bon.
    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

  13. #1993
    Citation Envoyé par Teocali Voir le message
    Ouais, enfin là, ils ont une excuse : leur truc existe depuis 2003.

    Mais même en 2003, la méthode HTTP POST existait, donc bon.
    La méthode existait.
    Mais ils voulaient un GET, tu l'as dit toi même.
    Du coup comment tu fais pour passer un XML en utilisant que GET sinon ?

  14. #1994
    Citation Envoyé par DrGurdil Voir le message
    La méthode existait.
    Mais ils voulaient un GET, tu l'as dit toi même.
    Du coup comment tu fais pour passer un XML en utilisant que GET sinon ?
    Super simple : tu fais pas.
    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

  15. #1995
    Pour revenir vite fait sur python, je vois régulièrement des articles dire que c'est un langages qui semble être apprécié comme disait ook4mi au dessus. Mais concrètement dans le milieu professionnel c'est quoi les grands domaines d'utilisation?

  16. #1996
    Citation Envoyé par ook4mi Voir le message
    Loin de moi l'idée d'être un expert mais afin de donner un peu de vie au topic, je tente un partage. N'hésitez pas à donner vos avis .

    D'après Packt (donc ça vaut ce que ça vaut... Même si je suis fan de leur ebook gratuit, c'est pas forcément les mieux placés pour ce type d'article.)

    En 2019 :
    1) Python
    2) Go
    3) Rust
    4) TypeScript
    5) Scala
    6) Swift
    7) Kotlin
    8) C

    Je ne sais pas vraiment quoi en penser... Je ne suis pas surpris pour Python car clairement on en entend tellement parler dans beaucoup de domaine et la facilité à pondre ces premières lignes de code en font un super outil pour démarrer le développement / devenir développeur tout court :D .

    Je suis un peu surpris par le C qui je pense est un langage vieillissant même si très performant. J'en ai fais que à la fac mais dans le monde professionnel, il y a quelques années quelques clients avaient des batchs en C sur des serveurs Linux mais je croise de plus en plus d'autres solutions pour les traitements de type Batch chez les clients du coin donc je le pensais en déclins...

    Je n'ai par contre, jamais touché les autres langages (même si GO m'a longtemps fait de l'oeil).

    Le C reste le langage le plus utilisé en pratique avec le Java (https://www.tiobe.com/tiobe-index/)

    Sur Devellopez les sondages donnent peu ou prou la même chose : https://www.developpez.com/actu/2278...on-un-rapport/
    javascript (pour le web etc..) java, python et C dans un mouchoir de poche.

    Le C reste le langage, également, le plus demandé par les entreprise en pratique (https://www.inteam.fr/blog/langages-...s-entreprises/, date de 2015 mais ça n'a pas du trop évoluer). Point intéressant, il prends même de la distance par rapport aux langages concurrents en ayant une avance de plus en plus longue sur les autres langages demandés.

    Bien entendu tout ceci reste à moduler avec ce qu'on désire faire en bout de chaine, c'est évident. Néanmoins il y a un aspect pédagogique à prendre en compte, j'enseigne maintenant le C, le Java et le Python aux débutants et si on comprends presque instantanément le langage Java, Python, Javascript, C# ainsi que les bases de l'architecture machine en ayant d'abord travaillé le C/C++, l'inverse n'est absolument pas vrai. Il est donc en general privilégié, dans l'enseignement, de commencer par du C/C++ puis d'évoluer vers les langages de plus hauts niveaux (en commençant par Java, qui est semblable) .

  17. #1997
    Citation Envoyé par M0s Voir le message
    Pour revenir vite fait sur python, je vois régulièrement des articles dire que c'est un langages qui semble être apprécié comme disait ook4mi au dessus. Mais concrètement dans le milieu professionnel c'est quoi les grands domaines d'utilisation?
    Perso je m'en sert quand je dois faire un enchainement des taches répétitives sur des fichiers et que c'est pas destiné à être diffusé ou que si ça doit être diffusé c'est juste un truc avec très peu d'I/O (genre pas de path de sortie à mettre ou autre).

    Sinon si ça doit être diffusé j'utilise autre chose pour avoir une belle interface graphique qui rassure les collègues.

    - - - Mise à jour - - -

    Citation Envoyé par Teocali Voir le message
    Super simple : tu fais pas.
    Dans la vraie vie si tu fais pas ton collègue le fera et tu passeras pour un incapable et ton collègue pour le sauveur de la situation

  18. #1998
    Citation Envoyé par ducon Voir le message
    Ce n’est pas le truc magnifique mais complètement impossible à faire tourner car il demande une quantité de RAM délirante ?
    Ben heuuu, non, je le fait tourner sur des chemins assez sympatoches par mes étudiants de M1 qui le codent de bout en bout à partir de 0. Ça tourne très bien et très rapidement sur des PC très bas de gamme. Les neurones ne coutent pas particulièrement cher en ram par ailleurs, c'est surtout les liens en entrée, et ici l'entrée est petite (car uniquement deux dimensions pour une position X/Y des étapes) donc deux liens par neurones uniquement. C'est très petit en ram.

  19. #1999
    Citation Envoyé par M0s Voir le message
    Pour revenir vite fait sur python, je vois régulièrement des articles dire que c'est un langages qui semble être apprécié comme disait ook4mi au dessus. Mais concrètement dans le milieu professionnel c'est quoi les grands domaines d'utilisation?
    Bah un peu de tout en fait.
    Perso dans ma boite y'a plusieurs équipes python qui font du logiciel scientifique, de l'iot et du web.
    C'est la faute à Arteis

  20. #2000
    Citation Envoyé par DrGurdil Voir le message
    Dans la vraie vie si tu fais pas ton collègue le fera et tu passeras pour un incapable et ton collègue pour le sauveur de la situation
    Dans la vraie vie, si tu fais quelques chose de stupide alors que t'as le choix de pas le faire, alors tu es stupide. Corollaire : les mecs qui ont pondus ce... truc sont stupides. Vouloir, c'est pas la même chose que devoir, hein. Je sais que ça ressemble, et que le niveau moyen de français chez les développeurs (et je parle en connaissance de cause) tutoie celui de la profondeur des Mariannes, mais ça reste différent.
    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. #2001
    Citation Envoyé par Teocali Voir le message
    Dans la vraie vie, si tu fais quelques chose de stupide alors que t'as le choix de pas le faire, alors tu es stupide. Corollaire : les mecs qui ont pondus ce... truc sont stupides. Vouloir, c'est pas la même chose que devoir, hein. Je sais que ça ressemble, et que le niveau moyen de français chez les développeurs (et je parle en connaissance de cause) tutoie celui de la profondeur des Mariannes, mais ça reste différent.
    Alors là chapeau, condescendance / 10

  22. #2002
    Ok, je corrige : quand un mec fait quelque chose de stupide par choix, il n'est pas forcément stupide, il peut être aussi incompétent.

    Et plus sérieusement, tu m'expliques ou est la condescendance ? Si c'est la remarque pour l'orthographe, c'était plutot un self-take that, hein. Quand je dis que je parle en connaissance de cause, c'est que je suis developpeur depuis 15 ans, donc j'ai largement eu l'occasion de faire souffrir la langue française... Hier encore, j'ai envoyé un mail pro... dans les destinataires, y'avait les responsable commerciaux de certaines boites françaises assez connue (pas de noms, pas de noms...)... t'aurais vu la gueule des fôtes d'orthographe... j'en ai eu honte, pour le coup.
    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

  23. #2003
    Citation Envoyé par DrGurdil Voir le message
    Perso je m'en sert quand je dois faire un enchainement des taches répétitives sur des fichiers et que c'est pas destiné à être diffusé ou que si ça doit être diffusé c'est juste un truc avec très peu d'I/O (genre pas de path de sortie à mettre ou autre).

    Sinon si ça doit être diffusé j'utilise autre chose pour avoir une belle interface graphique qui rassure les collègues.
    Citation Envoyé par Orhin Voir le message
    Bah un peu de tout en fait.
    Perso dans ma boite y'a plusieurs équipes python qui font du logiciel scientifique, de l'iot et du web.
    Je vois, merci à vous

  24. #2004
    @M0s ma boite fait une solution web qu'elle vend à des entreprises. C'est python/django de la cave au grenier.

    Sinon je l'utilise un peu pour mes projets persos : site perso, scripts d'admin unix (conjointement à bash).
    Dernière modification par Nattefrost ; 02/01/2019 à 18h25.

  25. #2005
    Dans la vraie vie, si tu fais quelques chose de stupide alors que t'as le choix de pas le faire, alors tu es stupide. Corollaire : les mecs qui ont pondus ce... truc sont stupides
    Citation Envoyé par Teocali Voir le message
    Ok, je corrige : quand un mec fait quelque chose de stupide par choix, il n'est pas forcément stupide, il peut être aussi incompétent.
    Il y a quelques mois, j'ai du pondre un truc dans cette veine là. Un gros GET bien dégueulasse avec une quantité folles de paramètres.

    Pourquoi ? Car en face, le système du client, une entité gigantesque dans notre domaine d'activité, n'était pas capable de gérer pour une même action une redirection depuis le navigateur du client et un POST (pour des raisons assez rocambolesques). Il était totalement impossible de faire évoluer le système du client et celui-ci ne pouvait pas spécialement consommer de valeurs encodées ne serait-ce qu'en Base64.
    La documentation du client n'était pas valide et différait complétement de la réalité avec des comportement différent selon ses environnements. Bien évidemment, le besoin est sorti de nulle part quelques jours avant la livraison de notre brique en prod' avec presque aucune marge de manœuvre.

    J'avais donc les choix suivants :
    - Prendre mon temps pour réaliser une solution élégante et distinguée.
    - Attendre une hypothétique évolution coté client.
    - Faire quelque chose Quick&Dirty qui arrive à marier sécurité et délai minuscule

    Parfois, il est nécessaire de faire comme on peut plutôt que comme on veut. Sans contexte, le prochain dev à passer sur ce sujet risque de se demander pourquoi j'ai été aussi bête, stupide ou incompétent.

  26. #2006
    Ouais moi aussi j'attends "la vraie vie" où t'as des principes super arrêtés pas du tout pragmatique et où tout est binaire

    Plus j'avance plus je me dis que c'est un vrai talent de savoir faire des trucs temporaires, aka du code avec une durée de péremption <20 ans.

    Etape 1, tu fais des trucs tout naze parce que tu connais pas les bonnes pratiques.
    Etape 2, tu fais des trucs super classe en respectant les bonnes pratiques, tout en conspuant ces imbéciles qui sont aux autrers étapes, mais tu fais 8 mois pour le faire et entre temps ça sert plus à rien parce que les besoins et/ou le contexte ont changé.
    Etape 3, tu fais un MVP tout naze en connaissance de cause vite fait pour parer au plus pressé et confronter la chose au besoin, tu le stabilise/refactor/refait en te servant de la V1 comme spec une fois que c'est le bon moment.

    Après on est d'accord, les mecs coincés à l'étape 1 c'est quand même le pire
    Mention spéciale aussi aux mecs qui savent qui ont fait un truc tout naze en connaissance de cause mais qui se trouvent toujours des excuses pour pas le refactorer également (et aux changements de gens qui font qu'on oublie).

  27. #2007
    Citation Envoyé par M0s Voir le message
    Pour revenir vite fait sur python, je vois régulièrement des articles dire que c'est un langages qui semble être apprécié comme disait ook4mi au dessus. Mais concrètement dans le milieu professionnel c'est quoi les grands domaines d'utilisation?
    J'avais toujours considéré que Python, en dehors de son utilisation comme langage de scripting un peu évolué, était surtout un bon langage pour apprendre la programmation (confluence de: syntaxe facile, pas de compilation obligatoire, et on essaie de mettre sous le tapis les problèmes de typage trop dynamique qui donnent de mauvaises habitudes). Les mêmes facteurs en font un langage qui semble très apprécié des gens qui n'ont pas une bonne formation en informatique générale.

    Par ailleurs, Python a été pas mal utilisé comme langage de base pour des systèmes de calcul mathématique et scientifique.

    Et le gros truc qui semble émerger, c'est l'utilisation en apprentissage, avec des bibliothèques de réseaux de neurones qui sont écrites en Python, ou au moins très faciles à interfacer avec. Encore une fois, on retrouve la dimension "langage pour non informaticiens".

    Bon, après, j'ai un peu l'impression que ça peut jouer des tours à certains. Cet été, pendant que je faisais passer des oraux, j'ai vu pas mal de jeunes de prépa qui m'expliquaient que le tri fusion c'est un algo de tri en O(n log n), et quand je regardais leur code je voyais une belle implémentation quadratique - pour laquelle je suis persuadé que les coupables, c'étaient les profs de prépa. Vivement qu'on ait des vrais informaticiens pour enseigner l'info en prépa... (Pour la petite histoire, j'ai passé l'agrég de maths il y a un peu plus de 25 ans, et à l'époque on m'avait garanti que "oui, la création d'une agrégation d'informatique, c'est pour dans 2, 3 ans maximum")

  28. #2008
    Nous on développe comme ça, quick and dirty et on refactorise/ré-architecture au fur et à mesure de l'avancement du projet.

    Mais faut du courage pour le faire, on est parfois allé contre l'avis de la direction qui voulais du quick-and-dirty tout le temps (hors ça, c'est finir dans le mur) car ils avaient étés échaudés de nos rythmes de développement quand on était en waterfall (ton Etape 2 en somme). Et c'est je pense le plus gros problème de la méthode Agile : tout le monde est content quand ça déboule rapidement en début de projet, mais après faut absolument avoir un management technique qui a les reins assez solides pour tenir bon dans les étapes subséquentes "oui il faut qu'on refasse telle architecture, oui on va changer de techno, oui on va prendre 2 semaines pour couvrir telle partie, etc", sinon on se retrouve dans le plat de nouille et on a rien gagné face à l'Etape 1.

    Par contre, on a dus se battre pendant 9 mois pour pousser cette façon de faire, et depuis tout le monde est content et convaincu (aujourd'hui, quand on dit qu'on va refactoriser et prendre quelques semaines c'est même vu comme quelque-chose de positif : ça veux dire qu'on a passé un cap dans la vie du produit).

  29. #2009
    Citation Envoyé par Nattefrost Voir le message
    @M0s ma boite fait une solution web qu'elle vend à des entreprises. C'est python/django de la cave au grenier.
    Citation Envoyé par Shosuro Phil Voir le message
    Par ailleurs, Python a été pas mal utilisé comme langage de base pour des systèmes de calcul mathématique et scientifique.

    Et le gros truc qui semble émerger, c'est l'utilisation en apprentissage, avec des bibliothèques de réseaux de neurones qui sont écrites en Python, ou au moins très faciles à interfacer avec. Encore une fois, on retrouve la dimension "langage pour non informaticiens".
    Ah d'accord, ça fait un champ d'utilisation assez vaste en fait. Merci à vous également.

  30. #2010
    Citation Envoyé par Dross Voir le message
    Nous on développe comme ça, quick and dirty et on refactorise/ré-architecture au fur et à mesure de l'avancement du projet.

    Mais faut du courage pour le faire, on est parfois allé contre l'avis de la direction qui voulais du quick-and-dirty tout le temps (hors ça, c'est finir dans le mur) car ils avaient étés échaudés de nos rythmes de développement quand on était en waterfall (ton Etape 2 en somme). Et c'est je pense le plus gros problème de la méthode Agile : tout le monde est content quand ça déboule rapidement en début de projet, mais après faut absolument avoir un management technique qui a les reins assez solides pour tenir bon dans les étapes subséquentes "oui il faut qu'on refasse telle architecture, oui on va changer de techno, oui on va prendre 2 semaines pour couvrir telle partie, etc", sinon on se retrouve dans le plat de nouille et on a rien gagné face à l'Etape 1.

    Par contre, on a dus se battre pendant 9 mois pour pousser cette façon de faire, et depuis tout le monde est content et convaincu (aujourd'hui, quand on dit qu'on va refactoriser et prendre quelques semaines c'est même vu comme quelque-chose de positif : ça veux dire qu'on a passé un cap dans la vie du produit).
    C'est tout à ton/votre honneur d'avoir réussi à faire ça et ça fait plaisir à entendre, c'est clairement pas simple et périlleux. 9 mois c'est un joli score, y'en a qui se prennent des murs pendant bien plus longtemps que ça!

    C'est turbo cliché mais c'est aussi vraie dans "la vie réelle" le coup du manager commercialo-commercial qui pense que le refactoring c'est du temps perdu à la sauce 'il suffit de' et 'pourquoi vous avez pas fait ça dès le début' tout en changeant de direction toutes les 12 minutes. En face le dev barbu dans sa tour d'ivoire qui va passer 6 mois à refactorer un truc tout seul dans son coin en changeant de langage vers celui qu'il préfère, tout ça pour gagner 18 nanosecondes sur le temps d'exécution d'un script qui est lancé deux fois par an "par principe".

    Je me demande quand même fortement pourquoi y'a aussi peu de monde qui arrive à avoir les deux points de vue.. ou même qui essaie, ou qui peut parler aux deux côtés, comme ton management technique de qualité

Page 67 sur 183 PremièrePremière ... 1757596061626364656667686970717273747577117167 ... 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
  •