Reprise du message précédent :

un pote qui bosse chez eux a Boston me faisait baver ce weekend quand on échangeait nos méthodes

 
Méthodes de quoi ? Je veux des exemples

la prévention des risque, la gestion des certifications pour ceux qui peuvent changer les ampoules, et un système impeccable pour la maintenance des panneaux "attention sol glissant"
 

 
cet exemple est parlant que si t'as bossé dans une grosse boite.
 
Contexte : tu as cassé ton clavier et tu en veux un neuf.
 
Grosse boite :  
- y'a en général un formulaire à remplir
- le workflow demandera la validation de ton manager (souvent il doit renseigner son cost center pour que le département support sache où facturer le clavier)
- il peut y avoir une validation du département informatique (surtout si tu veux du matos pas standard)
- tu as ton clavier 3 semaines après
 
Google :  
- en dessous d'un cout X, tous les accessoires sont en libre service sur une étagère à coté du bureau du support
- 0 validation, tu viens et tu te sers
 
Pourquoi : Google a étudié le sujet, et s'est rendu compte qu'en dessous d'un certain seuil d'abus, le process pour limiter les abus coute plus cher que les abus en eux-mêmes.
 
Tu as la meme chose sur les depenses de carte de crédit : t'as une allowance journalière, tout ce que le système check c'est que total_expense <= daily allowance * nb of travel days
Chez Nestlé j'avais des allowances par repas (petit dèj, déjeuner, diner, enfin déjeuner, diner, souper, j'entends   ). Après ils ont viré ça pour des allowances quotidiennes, mais tu devais toujours rentrer dans l'outil tes dépenses pour chaque repas
 
c'est trivial, mais ça cumulé au quotidien, ça rend la vie bien plus simple.
 
sinon pour l'onboarding ben c'est propre :  
- tu arrives le matin dans une salle, sur chaque chaise y'a un nom, et posé dessus : ton laptop (que tu as pu choisir), une privacy cover, le stylet (pour ceux qui le supportent), la house + chargeur, une yubikey nano-USB ou USB-C, le process pour enroll la clé que tu peux faire toi meme
- y'a une personne de l'IT qui as une badgeuse (pour vérifier qui tu es), qui t'imprimes un mdp temporaire. Elle te donne une Yubikey neo NFC et tu peux aller vers un des 5-6 laptops neutres te permettant de changer ton mdp et activer ta clé. En 5 min, tu as ton PC, ton compte actif avec ton MDP, et 2 yubikeys activées (activer le certif ssh prend 30sec de plus)
- y'a un stand immigration où ils vérifient que t'es en règle (passport / visa)
- on prend ta photo pour le badge
- après c'est un onboarding standard (présentation de l'IT, general services, etc...)
- avant manger tu peux demander une lettre de référence aux RH pour ouvrir un compte
- après manger la lettre est déjà là.
- a la fin de l'aprèm ils font venir une banque avec qui ils sont partenaire pour ouvrir un compte direct. Ils t'ont aussi briefé sur les démarches administratives (UK national number, etc...)
 
Bref, c'est super bien cadré, et très efficace. Et tu vois bien la philosophie de "tout ce qui est pas explicitement interdit est autorisé"
 
si je compare par rapport à Nestlé :  
- en 2018 on arrive encore à avoir le laptop le jour J (en 2014 tu pouvais attendre une semaine...j'ai fait des onboarding avec des morceaux de wiki imprimés ), mais le compte windows faut attendre en genéral 3-4 jours (la sécu refusait la création du compte si la personne n'était pas venue physiquement)
- 2FA systématique tu oublies, ils commencent seulement à rollout le 2FA de microsoft et c'est sur volontariat uniquement
- pour un certificat SSH tu comptes bien 1-2 semaines
- pour tout ce qui était démarches liées au pays / banque, tu te démerdes.  

Mais il est déjà déballé ou pas le laptop ?

Oui
 
Putain j'y avais pas pensé...  
Le stylet était dans sa boîte d'origine avec le plastique, ça compense non ?

ca va de l'achat de trucs dont tu as besoin au proposition de projet en passant par le code review.
 
 La grosse difference est pas uniquement les processus mais la culture. On a  beaucoup parle du code review. Chez eux comme chez nous, les repo sont ouverts a tout le monde. Par contre, c'est extrêmement rare de prendre le temps de commenter sur quelqu'un d'autre en dehors du process de release. Oui, on fait des PR chez un autre quand on a une dependance et on commence a revoir 2-3 trucs mais c'est a peu prêt tout. Ca reste très territorial. Mon impression chez google c'est que c'est encourage et bienvenu.
 

on a parle exactement de ca.  
Il a bosse avec moi avant donc un exemple la ou je suis:  
- tu dégommes ton ordi (peut importe la raison: cafe ou un bug)
- tu vas au IT desk. ils prennent l'ordi et te file un truc temporaire: un pc par défaut, deja c'est mal barre si t'es un habitue au mac. Ensuite, ton environment de dev est parti, et t'es comme un con avec une merde. Tu perds ton temps au support pendant tous le processus.
- tu vas devoir attendre ton mac . ca va prendre entre 3jours et 6 semaines selon les experiences autour de moi: c'est surtout la faute au support mac, mais en attendant t'es comme un con
 
google:
- tu te leves et tu recuperes un autre mac au desk. tu te connectes: "ah je vois que vous utilisez un ordi temporaire... " les images sont deja prêtes avec un environment adaptes. et roules ma poule.

Précisément, ils font tout ça (en gros), et ils se débrouillent pour que ça te fasse pas chier, c'est en ça qu'ils sont balaises. Quand ils organisent un exercice incendie ils font venir un gars qui déambule au point de rendez-vous avec un caddie plein de glaces pour faire patienter le temps qu'on ait le droit de rentrer.

haha, je viens de le dire à ma femme qui bosse chez big co, maintenant elle est jalouse

C'est pas la glace qui va me faire rattraper les 30 minutes de perdues.

On sait bien. La glace c'est leur façon de dire que sur ce sujet précis ils n'ont pas trouvé de solution pour faire un exercice d'evacuation sans interrompre tout le monde. C'est comme quand tu ramènes des fleurs à ta femme après une réunion qui t'a fait rester tard, c'est pas pour réparer, c'est pour dire merci, et je t'aime

Je tiens à dire que même dans l'administration française on n'en est pas là.

Alors que mon client actuel, une grosse COGIP américaine qui fait du consulting les hopitaux et la big pharma, je n'ai jamais vu autant de gâchis d'argent et de désorganisation. Il n'y a pratiquement aucun process identifiable et je soupçonne qu'il y a des malversations au niveau managérial parce qu'ils sous-traitent tout et les choix de certains fournisseurs sont très discutables pour ne pas dire incompréhensibles (copinage, ou prise illégale d'intérêt).

Les projets ne sont pas cadrés, il n'y a aucune direction de la part du management, il n'y a de décisions prises qu'au tout dernier moment, c'est n'importe quoi. Le directeur technique est un externe, et on ne le voit jamais, à aucune réunion. On a fait un PoC technique avant de lancer le projet sur lequel je suis, ça a duré 2 mois avec 2 solutions concurrentes, ils ont choisi en 30 mn chrono. Enfin ils ont fait semblant parce que manifestement le choix était fait avant même le PoC, et pas pour des raisons techniques.
L'un des deux projets, ça fait 2 ans qu'ils sont dessus, c'est tjrs pas sorti, l'autre ça fait 1 an et les devs ont commencé il y a 2 mois. Pour le projet sur lequel je suis, il n'y a pas de planning, pas de suivi de tâches, pas de livrables disponibles, c'est open bar. Et pourtant tous les outils sont là et disponibles (Gitlab, JIRA, etc). Ah, il n'y a pas non plus de specs fonctionnelles détaillées dignes de ce nom.

Les 2 archis pratiquent de la rétention d'info comme jamais. Ils ne publient pas le schéma de la base, il faut le leur demander, - plusieurs fois -. Ils ne communiquent pas où seulement dans un sens. Et là ils ont collé 2 fichiers que personne ne peut ouvrir parce que personne n'a la licence de l'outil avec lequel ils l'ont créé (Erwin, et pour demander une version de démo il faut passer par un commercial), avant de se barrer tous les deux en vacance. Résultat personne n'a le schéma à jour et on ne peut pas avancer.

En ce qui concerne ma mission, ça fait 4 mois que je bosse pour eux, en pure perte parce que rien de ce que j'ai fait ne sera retenu durant ces 4 mois (ce qui m'énerve un peu quand même). Il n'y a jamais de conflit ouvert, mais un jour, le mec allemand avec qui je bossais sur l'un des PoC a été viré dans l'heure, à l'américaine. J'ai halluciné et me suis retrouvé tout seul.

Voila, c'est une boîte de consulting managée par des anglais, il y a du pognon, mais c'est pas joli joli. Par contre à Paris on a de beaux locaux. A Londres, c'est un poulailler, genre caricature de l'open space où tout le monde à le casque sur les oreilles pour tenter tant bien que mal de s'isoler.
Je ne sais pas si c'est le domaine (la pharma ou le consulting) qui est comme ça, si c'est le management qui est exceptionnellement mauvais ou si ce les anglais qui bossent comme des porcs, mais j'ai presque plus honte de bosser dans ce domaine que dans le militaire ou la banque, parce que derrière la belle façade (cancérologie), tout le gâchis d'argent, ce sont les gens qui payent.

C'est le consulting Kangolcorp a un projet pour une grosse boite de consultance, c'est plus ou moins ce que j'ai vu quand j'étais dessus.
 
La seule différence c'est qu'ils avaient des ramées de specs, juste pas nécessairement à jour, ou compatible entre elles, avec un mix étrange de technique et fonctionnel, qui pouvaient changer rapidement sans avoir d'info, que le feedback d'implé était pas nécessairement répercuté, et souvent gérées par des stagiaires ou temps que tu voyais disparaitre sans info avec une nouvelle personne qui récupérait le truc.

Pour donner une idée de l'absence de drive du management, ici le chef techos nous a dit un jour "bon il faut écrire des requirements". Hop 15 gugusses se mettent à moindre des spécialistes pondre des specs pendant 3 semaines. À l'arrivée, je suis le seul à en avoir pondu une qui ressemble à quelque chose. Le reste va de l'ébauche à squelette (l'un des deux archis nous a sorti un plan style sommaire de Word, avec rien dedans. Et il était en plus complètement hors sujet parce qu'on était organisés en équipes spécialisées chacune dans un domaine).
Suite à ça, les specs n'ont pas évolué, elles restent à l'état d'ébauche. Et tout est comme ça, ça brasse du vent à tout va.

 
nraynaud > noogle

Ca dépend où
 

parceque tu as une (grosse) délégation de signature

le troufion  moyen ne peux pas acheter un bic. Donc csi tu as besoin d'une pièce qui n'est pas en spare, tu dois la faire commander :
1- trouver un fournisseur qui accepte les bons de commande
2- trouver les personnes capable de faire la commande (délégation de signature)
3- commander
4- vérifier avec la personne de l'accueil que le colis arrive
5- service fait auprès de la bonne personne (cf point 2)

et sinon l'appstore me pète les couilles , plus de 12h pour valider un build béta
est ce qu'il y en a qui ont testé des services type hockey ( maintenant appelé visual studio app center)

On va dire que ça dépend alors, parce qu'à l'université pour moi c'était exactement ça. Je veux dire même aller taper des stylos à la secrétaire ça me valait des regards noir si j'avais le malheur de passer deux fois dans la semaine...

Ah oui évidemment, là on parlait du cas où le spare est déjà en stock ; si je pètes mon clavier, je fais un ticket à l'assistance et j'en ai un nouveau dans la demi journée.

J'ai une question build/test/logging.
J'aimerais bien avoir une configuration de logging moins verbeuse pour nos tests automatisés parce que soyons réalistes, personne ne lit les kilomètres de logs qui encombrent la console chaque fois qu'on lance des tests.
 
Level error sans stacktrace pour des tests unitaires bien isolés et level error avec stacktrace pour les tests d'intégration, ça vous semble cohérent ?
 
Dans quel cas on voudrait plus de toute façon ? Si un test pète sur l'intégration continue, le dev va corriger en local d'abord, où il peut diagnostiquer avec un niveau de log plus fin.

À cause des divergences de configuration, il arrive que les trucs qui pêtent en CI soient super difficile à reproduire localement, et dans ce cas là avoir beaucoup de logging aide énormément.

Un truc que je regardais, c'est avoir le CI & la prod qui log absolument tout mais dans un système adapté (chercheable, filtrable et supprimable, avec export textuel en option) au lieu de te sortir un fichier de log textuel kilométrique imbitables. Apparemment chez Joyent ils ont un truc comme ça — mais avec des core dumps. L'avantage c'est que non seulement tu peux analyser ton truc de manière propre, si tu gardes tes logs un moment ça permet de remonter dans le temps et essayer de voir quand un problème qu'on vient de remarquer a été introduit.

Un bonus c'est ce que fait pytest: par défaut il capture les points de sortie (stdout et stderr) et ne les imprime que quand un test échoue (et imprime uniquement ce qui s'est passé pendant le setup, exec & teardown du test). Le logging pendant les tests est complètement invisible pour le tests qui réussissent.

C'est super agréable, et en bonus ça permet de tester ce que sort ton application.

Notre logging n'est actuellement pas d'assez bonne qualité pour fournir une assistance importante si on a un problème d'intégration sur le CI.
Mais c'est un chantier à part entière en terme de refonte. On a des milliards de trucs en WARN qui devaient être de l'INFO ou du DEBUG et qui ne le sont pas, des logs inutiles...
Là je dois parer au plus pressé.

On a par ailleurs des logs intéressants pour le suivi de prod (notamment pour des métriques d'appels) qui sont intégrés dans Splunk, lequel permet de faire de la recherche des dashboards, etc.

Je vais voir si on peut avoir un comportement similaire à pytest parce que c'est ce dont on a besoin au fond : les logs des tests qui passent on s'en cogne d'une grande force.

Je devrais partir en vacances plus souvent ; je suis jamais aussi productif que la semaine qui précède mes congés

dites, vous savez comment je peux retirer un préfixe dans diff? genre l'option qui correspond à -p de patch. Google me renvoie tout le temps vers git diff, mais là je suis dans le tiers monde, j'ai pas git.

Ya "--label" qui te permet de "renommer" tes fichiers. En combinaison avec du shellexp ou cut ça doit pouvoir passer.

https://stackoverflow.com/a/45637467
 
Grillé par masklinn  
 
Edit : ptet des choses à faire à base de https://www.systutorials.com/docs/l [...] ilterdiff/

ou alors tu fais pas diff -u  (c'est -u qui amène ça)

merci à tous
Xavier_OM> intéressant, je croyais que c'était poli chez les barbus de faire -u ?

'tain je suis en récursif ça va être l'horreur.

bon mes devoirs sont trop durs, et le prof est injuste, faites les pour moi svp:
ma commande originale:

et dans le patch je voudrai que les chemins aient la forme:

Tu rajoutes un petit

et c'est marre ?

unix

Après si tu as peur que la regexp choppe trop de truc (ça peut se comprendre), tu peux toujours la blinder hein
 

 
(nb : j'ai testé aucune des deux c'est au feeling)

ok, merci, on va mettre -p1 à patch.

Ha ben oui forcément si c'est pour la commande patch elle-même et pas l'output du diff c'est direct là.

Rha mais ces fonctionnels qui n'expriment pas leurs besoins clairement

\o/ mon premier devis médical à $1927 \o/  
 
je me sens américain maintenant.

 
C'est pas cher pour un bypass gastrique  

chuis pas gros*