Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 64 sur 64 PremièrePremière ... 1454565758596061626364
Affichage des résultats 1 891 à 1 917 sur 1917
  1. #1891

  2. #1892
    circulez, rien à voir
    Dernière modification par Nattefrost ; 06/11/2018 à 22h00. Motif: débat stérile

  3. #1893
    Citation Envoyé par Nattefrost Voir le message
    Ouais devops -vvv , j'ai parcouru un peu et lu quelques-uns des paragraphes. Ca s'est mal passé pour lui par moments. Perso je suis tombé dedans un peu par hasard: j'en avais marre (en plus d'etre mauvais en front) du "fullstack" (qui veut du jargon ?) et du web dev, ma boîte m'a proposé de changer vers des taches plus système et ça m'a toujours intéréssé, même si je partais de loin. Du coup j'ai appris sur le tas, comme beaucoup je crois.

    Après je comprend son point de vue, dans une boite plus grosse ou les équipes sont bien segmentées (ce qui n'est pas le cas pour moi) j'imagine que ça peut devenir comme il le décrit. Pour le moment j'ai mes domaines de compétence, du dev et de l'automatisation autour de problématiques infra/sysadmin principalement, on ne me demande pas tout et n'importe quoi et c'est centré autour de la technique ce qui me va bien pour le moment.
    En un mot comme en cent : tu n'as pas lu, ni compris le point de vue.

    Je comprends pas pourquoi du coup tu te justifies. Et beaucoup de webdev font exactement ce que tu fais parce que le marche a evolue de cette facon. Enfin, c'est plus du jargon que des pratiques reelles mais bon, avec le webdev, quoi d'etonnant ?
    Citation Envoyé par Ruvon Voir le message
    Tu as oublié 60 Millions de consommateurs, le Canard Enchaîné et tous les autres médias SJW qui s'intéressent à la défense des droits des gens, ces gros fachos.

  4. #1894
    circulez, rien à voir
    Dernière modification par Nattefrost ; 06/11/2018 à 22h00. Motif: débat stérile

  5. #1895
    Citation Envoyé par Paradox Voir le message
    En un mot comme en cent : tu n'as pas lu, ni compris le point de vue.
    Tu files un lien avec 17 000 dans un style relou à lire. C’est pas super étonnant qu’il le lise en diagonale...

  6. #1896
    Citation Envoyé par Frypolar Voir le message
    Tu files un lien avec 17 000 dans un style relou à lire. C’est pas super étonnant qu’il le lise en diagonale...
    Lire en diagonale, ca veut dire avoir une idee de ce qui y est dit.
    Citation Envoyé par Ruvon Voir le message
    Tu as oublié 60 Millions de consommateurs, le Canard Enchaîné et tous les autres médias SJW qui s'intéressent à la défense des droits des gens, ces gros fachos.

  7. #1897
    Citation Envoyé par Paradox Voir le message
    Lire en diagonale, ca veut dire avoir une idee de ce qui y est dit.
    Ben apparemment c’était la mauvaise diagonale Mais plutôt que de répondre de manière condescendante tu pourrais prendre ce temps pour résumer ce que dit l’article et ce que n’a pas compris selon toi Nattefrost.

  8. #1898
    Citation Envoyé par Nattefrost Voir le message
    J'ai pas l'impression de me justifier (vis à vis de qui ou quoi?), je décris ce que je fais parce que je pense aussi que ces appellations sont artificielles et je préfère décrire ce que je fais pour de vrai tous les jours.
    Quelqu'un qui me dit "je suis développeur" j'en déduis pas grand chose à part qu'il passe beaucoup de temps devant un éditeur/IDE et qu'il connaît au moins un langage de programmation, ça ne donne aucune indication sur la nature de son travail. C'est pareil pour devops.
    Bref c'est difficile de parler sérieusement entre deux commits sans connaître le background des uns et des autres.
    La plupart des gens collent tout et rien derriere DevOps (et pour cause). Y'a qu'a voir wikipedia... mais ca ne change rien. Pas besoin de connaitre le background pour en parler ; je peux parier n'importe quoi que meme si je donnais mon background, tu ne serais pas plus avance pour m'en parler.

    Sinon, l'auteur expliquait son travail a l'epoque, la separation entre les devs et les admins et leur incomprehension mutuelle. Grosso modo, les devs ont fini par comprendre qu'ils faisaient deja du DevOps avec l'evolution de l'affectation de leurs taches mutuelles (les admins se resserant sur l'admin, les devs ont du reprendre la partie admin qui leur "incombaient"). Morale de l'histoire : le terme a ete invente en 2009 mais la methodo existe depuis tres longtemps. Ce qui change en realite c'est la facon dont les entreprises l'applique... mais la realite objective de la methodo ne change pas.

    - - - Mise à jour - - -

    Citation Envoyé par Frypolar Voir le message
    Ben apparemment c’était la mauvaise diagonale Mais plutôt que de répondre de manière condescendante tu pourrais prendre ce temps pour résumer ce que dit l’article et ce que n’a pas compris selon toi Nattefrost.
    Tu veux que je dise quoi a un quelqu'un qui ne lit pas le truc et y voit ce qu'il veut y voir, honnetemment ?

    Si je resume l'article, ce sera vu comme ma vision. S'il le lit, il y a deja beaucoup de chances qu'il ne voit pas le meme chose. Mais le debat peut commencer sur de bonnes bases.

    Si on fait comme tu dis, c'est encore plus condescendant que ce que tu cherches a denoncer : je lui donne ma vision, avant, pendant, apres... Je parle avec moi, moi et peut-etre un bout de lui, tout ca pour lui dire "non tu n'as pas compris"... ou pire, il va dire "oui ok sans comprendre. C'est... hautement qualitatif.

    C'est justement parce que les gens ne veulent pas lire, se documenter, parler voire debattre que ca fini par etre sterile et condescendant... tu parles d'une option viable...
    Citation Envoyé par Ruvon Voir le message
    Tu as oublié 60 Millions de consommateurs, le Canard Enchaîné et tous les autres médias SJW qui s'intéressent à la défense des droits des gens, ces gros fachos.

  9. #1899
    C'est justement parce que les gens ne veulent pas lire, se documenter, parler voire debattre que ca fini par etre sterile et condescendant... tu parles d'une option viable...

    Du texte (doc et articles) j'en lis déjà toute la journée, alors quand je vois un texte de cette taille et que les quelques phrases glanées à droite à gauche ne m'inspirent pas, je ne lis pas l'intégralité. J'ai le droit d'être fainéant.

    Je ne doute pas que ce que dit le gars de l'article soit vrai et factuel quand il raconte ce qui s'est passé et que ses analyses soient valables pour les cas qu'il a rencontrés. Mais c'est jamais que le discours d'un seul type dans un contexte donné, je ne comprend pas la généralisation que tu en fais en nous vendant cet article comme parole d'évangile...

    Là-dessus, ça ne mêne nul part, je ne répondrai plus à ce sujet.
    Dernière modification par Nattefrost ; 06/11/2018 à 22h14.

  10. #1900
    Merci pour l'article, j’espère avoir compris l'essence de ce qu'il essaye d'exprimer. Ça fait pas mal écho a ce que je rencontre actuellement où il y a une équipe "devops" qui à 2 casquettes (administration système + aide aux équipes pour mettre en place le devops) et qui au final n'arrive à ne faire correctement aucune des 2 missions. Du coup soit ils se barrent, soit ils font le service minimum et les projets en sont quasi au même point par manque de volonté des équipes qui aurait un besoin (bah oui, il y a une équipe devops, pourquoi s'intéresser au sujet...). Et au final, les gens en opérationnel ne sont même pas moteur sur le sujet vu qu'ils restent dans un mode de livraison super "classique".

    Bref, c'est un peu la mode effectivement, même si c'est un super principe à mettre en place lorsque tout le monde est motivé.

  11. #1901
    C'est un grand classique en effet cet article. 'tention j'ai lu en diagonal aussi
    "Le devops c'est de la merde parce que je l'ai vu mal fait", j'ai du mal à comprendre la logique.

    Déjà ce genre de terme est trop galvaudé pour avoir beaucoup de sens, mais si il lui en reste, j'ai jamais vu devops défini autrement que par opposition à avoir deux silos dev et ops qui se parlent pas. Donc par essence même, le terme porte du cross-fonctionnel, l'idée d'avoir des gars responsables de A à Z plutôt que des tribus qui vont pas dans un sens commun. Je comprends pas comment tu peux l'attaquer sur le contraire.

    C'est pas parce que y'a trouzemille boites qui "font de l'agile" sur le papier parce que le terme buzz, mais avec des specs faites en 2004 et sans parler aux clients, que ça rend le principe merdique.
    Si tu veux pas parler du principe, et te battre sur le sens des mots et de la sémantique, je trouve ça en effet bien stérile comme débat.
    Et si c'est pas de ça que tu veux parler, bah vaut mieux pas titrer "devops is bullshit" alors que le mot veut tout et rien dire

  12. #1902
    Citation Envoyé par Charmide Voir le message
    "Le devops c'est de la merde parce que je l'ai vu mal fait", j'ai du mal à comprendre la logique.
    Oui et non; si le devops est mal fait dans une boîte, ça n'en fait pas de la merde. Par contre quand c'est mal fait dans 80% des cas (je ne dis pas que c'est le cas, c'est pour l'exemple), c'est peut être pas des boîtes que vient le problème.

  13. #1903
    Non mais le devops, c'est comme le big data et le deep learning: les gens en parlent tellement pour ne rien dire et sans le comprendre que, quand on en parle, c'est forcément pour dire des conneries.
    C'est statistiquement probable en effet, mais c'est le cas pour tout ce qui buzze. Ca ne présume rien quant à l'intérêt de la discipline (d'autant que perso, je ne panne rien aux 3 exemples cités, mais c'est pas facile à admettre ouvertement sans passer pour un has-been).

  14. #1904
    Pareil, je pense aussi que c'est bien statiquement vrai, j'ai hésité à le placer dans ma comparaison mais je pense aussi que c'est vrai pour "l'agile"...

    Par nature des deux, t'auras toujours plus de gens pour appliquer mal des effets de mode, qu'appliquer intelligemment des principes de bon sens. Donc je pense que c'est quand même la faute des boites moi aussi

  15. #1905
    Citation Envoyé par vectra Voir le message
    Non mais le devops, c'est comme le big data et le deep learning: les gens en parlent tellement pour ne rien dire et sans le comprendre que, quand on en parle, c'est forcément pour dire des conneries.
    Ahah, très vrai.
    Because you're young, sharp as a knife
    You need that buzz to come alive

  16. #1906
    Haha, chez Worldline on désespère de trouver des devops. Le soucis c'est qu'on leur demande de savoir tout faire, bosser bcp, mais pour le même salaire qu'un dev de base.
    Mais c'est magique.

    C'est comme le Lead Dev. Ils (nos supérieurs) viennent de découvrir ça : après une réu, on (surtout ils, et ils se sont lâché) a établit qu'un LD, c'est une sorte de superman. Il a toutes les qualités, doit savoir tout faire, tendre vers l'excellence, lalala. Et idem, pas de revalorisation du salaire.

    Content de bientôt quitter cette boite d'andouilles

  17. #1907
    Dans mon ancienne boite (une PME), j'étais"l'informaticien", c'est à dire le mec qui s'occupait de toute la technique (de la réparation d'imprimantes à l'installation d'un ESX ou la migration d'un domaine), et en même temps, je faisais les devs de la boite. Quand j'ai fait une formation VMWare, les mecs ne me croyaient pas, et perso, ce qui me faisait halluciner, c'etaient leurs postes ultra-restrictifs (genre "responsable du déploiement des clients Vmware").
    Des postes comme j'avais, j'en vois encore dans des PME ou des boîtes qui ont grandi très rapidement, et pour moi, c'est ça un DevOps.
    Y'a un poste à pourvoir de ce type à Rosny-sous-Bois d'ailleurs. Perso, je n'y vais pas parce que ça fait trop loin de chez moi, mais s'il y'a des gens intéressés MP

  18. #1908
    Le DevOps c'est avant tout une grosse fracture avec les "anciennes" méthodes. Avoir un script perl qui configure un apache ça n'a plus aucune valeur marchande à l'heure d'aujourd'hui. L'hébergement LAMP est entrain de crever. Du coup t'as deux solutions :

    - tu crèves
    - tu proposes un service plus complet avec de l'intégration continue, des systèmes distribués, de la résilience, du monitoring et de l'alerting en segmentant correctement les choses entre un incident de dev (ex: l'appli se casse la gueule) et un incident de prod (ex: le culster postgres ne réponds plus). Dans mon cas, cette segmentation des différentes missions de chacuns me sauve la vie : je n'ai plus a débug une appli que je connais pas parce que je suis en bout de chaîne (hébergement). Bref, on arrête de me demander de transformer la merde en or.

    Le DevOps, c'est pas forcément un dev qui fait de l'ops qui fait du dev, mais plutôt l'établissement d'un contrat clair et d'outils standardisés (la CI est pour moi le point central) entre un dev et un ops. D'ailleurs, la majorité de nos clients c'est des dev qui ont tenté de faire de l'ops en se rendant compte que finalement c'était un métier complètement différent. Donc oui pousser un POC sur AWS c'est facile pour un dev. Par contre le maintenir derrière c'est une autre histoire (monitoring, astreintes, alerting, maj etc).

    Edit (1) : coquilles orthographiques

    Edit (2) : j'ai la chance de faire du dev (outils internes en python, daemons en go) et de l'ops (mise à jour des services que je dev + d'autres outils via Ansible). J'adore les deux facettes du métier et j'aime bien ça.
    Dernière modification par Mayalabielle ; 08/11/2018 à 13h35.

  19. #1909
    Citation Envoyé par Mayalabielle Voir le message
    Le DevOps c'est avant tout une grosse fracture avec les "anciennes" méthodes. Avoir un script perl qui configure un apache ça n'a plus aucune valeur marchande à l'heure d'aujourd'hui. L'hébergement LAMP est entrain de crever. Du coup t'as deux solutions :

    - tu crèves
    - tu proposes un service plus complet avec de l'intégration continue, des systèmes distribués, de la résilience, du monitoring et de l'alerting en segmentant correctement les choses entre un incident de dev (ex: l'appli se casse la gueule) et un incident de prod (ex: le culster postgres ne réponds plus). Dans mon cas, cette segmentation des différentes missions de chacuns me sauve la vie : je n'ai plus a débug une appli que je connais pas parce que je suis en bout de chaîne (hébergement). Bref, on arrête de me demander de transformer la merde en or.

    Le DevOps, c'est pas forcément un dev qui fait de l'ops qui fait du dev, mais plutôt l'établissement d'un contrat clair et d'outils standardisés (la CI est pour moi le point central) entre un dev et un ops. D'ailleurs, la majorité de nos clientn c'est des dev qui ont tenté de faire de l'ops en se rendant compte que finalement c'était un métier complètement différents. Donc oui pousser un POC sur AWS c'est facile pour un dev. Par contre le maintenir derrière c'est une autre histoire (monitoring, astreintes, alerting, maj etc).
    Ceci.
    C'est la faute à Arteis

  20. #1910
    C'est bien illustré dans le texte de gene Kim, the Phoenix prokect
    https://www.amazon.com/Phoenix-Proje.../dp/0988262592

  21. #1911
    Citation Envoyé par deathdigger Voir le message
    Dans mon ancienne boite (une PME), j'étais"l'informaticien", c'est à dire le mec qui s'occupait de toute la technique (de la réparation d'imprimantes à l'installation d'un ESX ou la migration d'un domaine), et en même temps, je faisais les devs de la boite. Quand j'ai fait une formation VMWare, les mecs ne me croyaient pas, et perso, ce qui me faisait halluciner, c'etaient leurs postes ultra-restrictifs (genre "responsable du déploiement des clients Vmware").
    Des postes comme j'avais, j'en vois encore dans des PME ou des boîtes qui ont grandi très rapidement, et pour moi, c'est ça un DevOps.
    Y'a un poste à pourvoir de ce type à Rosny-sous-Bois d'ailleurs. Perso, je n'y vais pas parce que ça fait trop loin de chez moi, mais s'il y'a des gens intéressés MP
    Fallait demander à être CTO ça fait plus classe

  22. #1912
    https://en.cppreference.com/w/cpp/header/filesystem

    Purée, ils ont enfin intégré ça dans le langage et non plus posix.
    Par contre, c'est que du c++17. Même sur boost, y'a pas tout je le crains

    Je galère pour pécho les droits de fichiers autrement que par stat. J'aimerais obtenir si l'user a le droit d'écrire sur un répertoire d'une manière portable (pour une appli linux/windows).
    Avec boost / c++11, j'ai au mieux cette bouse:

    Code:
    printf("\n%o", bf::status( bf::path("/tmp/")).permissions());
    printf("\n%o", bf::status( bf::path("/home/")).permissions());
    printf("\n%o", bf::status( bf::path("/usr/")).permissions());
    printf("\n%o", bf::status( bf::path("/vmlinuz/")).permissions());
    qui donne:
    Code:
    1777 (le 1 est un sticky bit, donc les droits c'est 777)
    755
    755
    0
    Je me demande comment récupérer facilement les bits indiquant rwx pour user au moins, et tout ça ne me semble pas très portable...

    Une autre solution serait de passer sous c++17, tant que je peux au moins trouver un Visual Studio gratuit qui le supporte totalement. J'ai bon espoir que mes libs le supportent.

    PS:
    ceci fait le job, mais je ne sais pas si c'est portable:

    Code:
    bool
    writeable_cpp11(const boost::filesystem::path &p)
    {
      std::ostringstream o;
      o << std::oct << boost::filesystem::status( p ).permissions();
      size_t len = o.str().size();
      if (!(len == 3 || len == 4)) return false;
      size_t pos = (len == 3) ? 0 : 1; // il peut y avoir un sticky bit à 1 en première position
      return (o.str()[pos] == '7');
    }
    Je me sens sale
    Dernière modification par vectra ; 09/11/2018 à 17h14.

  23. #1913
    ça marche pas ça ?

    Code:
    bool writeable_cpp11(const boost::filesystem::path &p) {
      return (boost::filesystem::status(p).permissions() & boost::filesystem::perms::owner_all) != boost::filesystem::perms::none;
    }

  24. #1914
    Y'a du monde ici qui sait bien administrer un TFS ?

  25. #1915
    Un Serveur Team Fortress? :con:


    Désolé, je sèche.
    Par contre, le BMDJ, c'est le programme des rencontres du logiciel libre à Toulouse ce WE:
    https://2018.capitoledulibre.org/programme/

    Des ateliers Rust, du QML, de l'org-mode

  26. #1916
    Citation Envoyé par deathdigger Voir le message
    Y'a du monde ici qui sait bien administrer un TFS ?
    À quel niveau ?

  27. #1917
    Citation Envoyé par Raplonu Voir le message
    ça marche pas ça ?

    Code:
    bool writeable_cpp11(const boost::filesystem::path &p) {
      return (boost::filesystem::status(p).permissions() & boost::filesystem::perms::owner_all) != boost::filesystem::perms::none;
    }
    Si, oui

    Code:
    return ((boost::filesystem::status(p) . permissions() & boost::filesystem::perms::owner_all)  != boost::filesystem::perms::no_perms);
    J'avais pas bien compris la logique de boost là-dessus
    C'est du C++ template, mais toujours avec des masques de bits à la C

    Dans le même genre, pour définir des perms:

    Code:
    boost::filesystem::path mypath("/tmp/toto");
    boost::filesystem::permissions(mypath, boost::filesystem::perms::owner_all | boost::filesystem::perms::group_all);
    C'est pas si mal en fait, même si un peu arrache-cheveux...

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
  •