Jump to content

About This Club

"An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem." -- John Tukey
  1. What's new in this club
  2. Hm je dirais que la définition change en fonction de la boite. On parle d'un mec 1/ capable de créer, comprendre et automatiser une plateforme compliquée 2/ d'accompagner et former les software engineers, data engineers, etc pour l'utilisation en autonomie de la plateforme 3/ avoir des notions d'archi logicielle plus ou moins poussée en fonction du poste Appelle ça devops, cloud engineer, Site Reliability Engineer (Google), Production Engineer (Facebook), whatever, le fond du travail reste le même, même si la forme change. t'façon dans les faits tu fais du bash pour générer du yaml en CI. Edit : c'est pour ça que j'ai pompeusement appelé mon équipe "Platform Team", parce que c'est pas juste "les mecs de l'infra".
  3. Tu as les rôles de data ops et machine learning engineer qui sont un peu au sommet de la hype de mon point de vue, et que je range abusivement dans la corbeille data eng'. D'un autre côté les développeurs etl d'outils dédiés ( Talend et informatica par exemple) qui sont rebrandés "Data Engineer" et qui eux ne sont pas du tout du bon côté de la hype. Mmmh je dirais un architecte cloud c'est encore une catégorie à part.
  4. DevOps, Data Science, Data Engineering. Les nouvelles compétences. Vous comptez les spécialistes cloud/AWS dans les DevOps ?
  5. Dans mon cas c'est un devops, c'est encore pire côté hype. No data eng on les paye un peu moins.
  6. Quand je dis aux jeunes que maintenant c'est plusse hype de foncer vers la data engineerie plutôt que la data science ils ne me croient pas... Faudrait que je switche de lead data scientist vers lead data engineer, il me manque juste les compétences...
  7. mouahahaha. Ca depend de ton referentiel. Le scrum a l'air moins con que les autres gens du train concernant le suivi de SAFe (heureusement bordel) mais je pense pas que ca gravite dans des sphères inatteignables, effectivement.
  8. Sorry j'avais pas vu ton message. Non, pas besoin évidemment dans ma boite de schtarbés. J'ai quand même demandé à la passer fin Mars, le scrum est moins con que les autres, comme si des gens avaient compris leur métier en fait.
  9. Caramba. Vite, le covid. Je vais faire un tour au bureau, je reviens.
  10. Oui ! À 24 ans il est entre 50 et 55k. Il est super bon, je veux le garder. Il est en totale autonomie sur la moitié du périmètre de l'équipe et il me remplace sur plein de choses, c'est plutôt cool. Et comme je coûte autrement plus cher à la boîte, ce qui est bon pour moi est bon pour la boîte
  11. Oh putain, et maintenant une dispute entre un collègue qui veut exposer le plus de paramètres possibles à l'extérieur, et moi qui veut en exposer le moins possible, avec ce pénible qui modifie la moitié de mon projet SSIS dans mon dos.
  12. Je viens de me rappeler pourquoi je détestais tant SSIS. Je veux dupliquer un package (parce que c'est chiant de tout refaire presque à l'identique), je change le nom et les paramètres, tout se passe bien. Et je cherche à rediriger le data flow depuis une nouvelle source (une table dans SQL Server) vers une nouvelle destination (un CSV, dans le même répertoire que le précédent). Et là, je passe une demi-heure à me battre parce que même avec une requête explicite (où je liste les colonnes une à une), je n'arrive pas à obtenir le bon columnset, j'ai toujours des metadata parasites provenant sans doute de l'ancienne table. La solution était : entre l'ancienne et la nouvelle table, il est bon de pointer vers une tierce table qui n'a aucun nom de colonne en commun avec l'ancienne ni avec la nouvelle. Pourquoi ? Pour faire chier, probablement. Je hais SSIS avec une telle force, même pour des packages simples c'est une merde gluante.
  13. Bon , back to business. Product owner (gngn) pour industrialiser des outils data avec pyspark sur le jouet palantir. C'est toujours mieux que 6 mois de dashboards
  14. J'ai pas l'impression. D'où le conseil de réfléchir en termes d'ensembles et de normalisation ; les histoires de dénormalisation et de méthodes d'accès et de jointure, c'est après, une fois que le SQL (DDL, DML et DQL) est écrit comme il faut.
  15. Jusque là apparemment des échos que j'en ai ça reste moins cher que Teradata.
  16. Ouch, c'est d'autant plus impressionnant. Demande quand même au CIO de regarder sa facture Azure de fin de mois, la part variable pourrait être rigolote.
  17. Je viens d'arriver je ne connais pas tous les tenants et aboutissants de l'architecture. (On compare une appliance on-premise à une cloud base sur Azure) Mais globalement ça va 10 fois plus vite du point de vue utilisateur. (Donc en comptant le réseau, l'I/O, l'outil dans lequel ça tombe, SAS, Microstrategy, Databricks...)
  18. Quelques exemples ? Et sur du matériel de puissance équivalente ?
  19.  
×
×
  • Create New...