par contre il est en mode verbose le devop là...
par contre il est en mode verbose le devop là...
circulez, rien à voir
Dernière modification par Nattefrost ; 06/11/2018 à 22h00. Motif: débat stérile
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 ?
circulez, rien à voir
Dernière modification par Nattefrost ; 06/11/2018 à 22h00. Motif: débat stérile
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 - - -
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...
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.
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é.
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
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).
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
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
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
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.
"Nobody exists on purpose. Nobody belongs anywhere. We're all going to die. Come watch TV." - Morty Smith
C'est bien illustré dans le texte de gene Kim, the Phoenix prokect
https://www.amazon.com/Phoenix-Proje.../dp/0988262592
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:
qui donne: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());
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...Code:1777 (le 1 est un sticky bit, donc les droits c'est 777) 755 755 0
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:
Je me sens saleCode: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'); }
Dernière modification par vectra ; 09/11/2018 à 17h14.
ç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; }
Y'a du monde ici qui sait bien administrer un TFS ?
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
Si, oui
J'avais pas bien compris la logique de boost là-dessusCode:return ((boost::filesystem::status(p) . permissions() & boost::filesystem::perms::owner_all) != boost::filesystem::perms::no_perms);
C'est du C++ template, mais toujours avec des masques de bits à la C
Dans le même genre, pour définir des perms:
C'est pas si mal en fait, même si un peu arrache-cheveux...Code:boost::filesystem::path mypath("/tmp/toto"); boost::filesystem::permissions(mypath, boost::filesystem::perms::owner_all | boost::filesystem::perms::group_all);
Je suis dans une nouvelle vague "functional programming" et je pattoge grave. J'ai déjà touché à quelques langages pseudo fonctionnels (javascript) et purement fonctionnel (haskell, pour xmonad et un tout petit peu de Erlang/Elixir/Phoenix). J'ai essayé de me replonger sur du Haskell hier et je me suis senti complètement à la ramasse dès que j'ai du sortir des "exemples simples".
Est-ce que quelqu'un aurait de bonnes ressources sur la programmation fonctionnelle (au top si c'est illustré via Erlang, Elixir ou Haskell étant donné que j'ai déjà au moins joué plusieurs heures avec leur interpréteurs respectifs) ?
"Nobody exists on purpose. Nobody belongs anywhere. We're all going to die. Come watch TV." - Morty Smith
Tu as fait Learn you a Haskell ?
Dernière modification par Sahnvour ; 22/11/2018 à 14h45. Motif: typo