Journal Huit ans et plus toutes ses dents

Posté par . Licence CC by-sa.
22
27
déc.
2018

En 2010 , j'ai trouvé un emploi d'ingénieur support dans un grand éditeur Américain .
En 2019, suite à un plan social de grande envergure, je me prépare à trouver "un nouveau challenge", donc me voilà à réseauter professionnellement, pour trouver une nouveau challenge.
Pas de pleurs, le CE a fait du bon travail et l'entreprise est en train de mourir (comme beaucoup de gros éditeurs), donc je ne regrette pas de quitter cet endroit toxique.
Par contre, il m'est impossible de vous dire le nom de cette entreprise.

Je dois vous rappeler que je ne cherchais pas particulièrement à quitter mon poste, et que j'ai une utilisation assez bureautique/internet de mon linux.

Je me suis donc bien aperçu que les profils recherchés en production informatique avaient beaucoup évolué.

En 2010, le terme à la mode , si ma mémoire ne me fait pas défaut, était "virtualisation" voir "déduplication"(que mon correcteur orthographique ne connait pas encore) pour le stockage, le langage à connaitre était le perl.

Depuis, en suivant un peu les actualités, j'ai vu, il y a quelques années la montées en puissance des containers dockers. En suivant mes incidents, j'ai pu voir aussi la mort des unix propriétaires, souvent remplacés par des VMs vmware et la montée en puissance du cloud

Aujourd'hui, je vois que de nombreuses offres demandent de maîtriser le python (Est ce que perl est vraiment mort ?) . Je ne maîtrisais pas python, et je n'en avais pas vraiment l'utilité, MAIS j'ai découvert récemment un langage fourni de documentation sur internet, et très riche, avec des modules en nombre plus important que les mots clés du langage. J'aime beaucoup ce langage.

Outre python, je vois que la virtualisation est désormais plus un basique qu'un atout.

Deux mots reviennent néanmoins sans cesse dans les offres d'emplois :
Le Big Data et le cloud.

Qu'en est il du big data ?
Hadoop semble tenir la corde mais quel hadoop ?
Celui de Cloudera/Hortonworks , HDinsight de Microsoft , ou le hadoop from scratch ?

J'ai réussi à faire mon CPF sur hadoop avec hbase, hive, le java mapreduce, scala de L'EPFL et python pour les traitement RRD (impala si mes souvenirs sont bons). Est ce que cela utile ?(hadoop en tant que non développeur me semble quand même être de l'édition de fichier XML)

Concernant le cloud, je pense demander une formation en openstack de RedHat en reconversion, car la compréhension que j'en ai est qu'il s'agit de la base de nombreux cloud.

Pour le stockage, on parle désormais de stockage objet, ou de stockage partagé . La déduplication est , à juste titre selon moi, peu à peu mis aux oubliettes

Maintenant, je réalise que les grands éditeurs ne recrutent pas beaucoup, et qu'ils ont de sérieux problèmes.
En résumé, je réalise qu'en huit passé à troubleshooter mon produit propriétaire , je n'ai pas vraiment eu de visus sur l'évolution des prods, pourriez vous me donner des avis ?
Dois je continuer à apprendre python ? Dois je insister sur hadoop , sur le cloud ?
Concernant les recruteurs, viser les startup est il vraiment jouable et utile ?
La startup Française de stockage objet Anneau est il vraiment un killer ou juste un expert dans sa communication ?

Quelles sont vos prévisions pour 2019 ?

  • # Linux

    Posté par . Évalué à 10.

    Cloud et Big data est une réalité mais il n'y a pas tant de technologie clé derrière. Chacun a la sienne. Hadoop reste minoritaire. Il y a une monté d'AWS et autre mais c'est juste une interface a utilisé par des appels. La vrai différence ces 10 dernières années c'est la chute de Windows server et la montée de Linux et notamment de Docker. Les compétences des technologies Windows est toujours demandé mais il y a trop de candidats inversement il est difficile de trouvé des Linuxiens ils sont recherchés. Python n'est qu'une des conséquences de Linux en sois et Perl est en sois toujours intéressant. Ce qui ne bouge pas c'est C/C++ et Java…

    • [^] # Re: Linux

      Posté par . Évalué à 4.

      Wooww, tu me rassures quand même.
      Donc, il faut que renforce mes connaissances docker ? A ce que j'ai compris, docker un "émulateurs" de machine: comme des VMS , mais partageant le kernel de l'hôte.
      Donc, tu me conseilles de bien me plonger dans kubernetes, et ansible (les deux que je connait pas du tout à part un rapport avec docker)  ?

      • [^] # Re: Linux

        Posté par (page perso) . Évalué à 10.

        comme des VMS , mais partageant le kernel de l'hôte.

        Comme des chroot, des zone Solaris, des jails Freebsd…

        kubernetes, et ansible (les deux que je connait pas du tout à part un rapport avec docker)  ?

        Kubernetes, c'est un orchestrateur de containeurs. Il s'arrange pour en démarrer le nombre qu'il faut sur le cluster (en très basique).

        Ansible, c'est de la gestion de configuration, comme Puppet, Chef, Salt, ou CFEngine.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Linux

          Posté par . Évalué à 7. Dernière modification le 28/12/18 à 09:46.

          Oui j'ai compris ce qu'était un conteneur quand on m'a dit que c'était grosso-modo un cumul de :
          - chroot (isolation du filesystem)
          - cgroups (isolation des ressources kernel, comme RAM, CPU…)

          Faire mumuse avec les cgroups à la main (un petit bout de code qui fait un malloc de 200Mo par exemple, il marche en temps normal, mais si on l'exécute sous un cgroups qui limite à 100Mo, le malloc part en erreur) est une excellente introduction aux conteneurs.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Linux

          Posté par . Évalué à 3.

          Ansible, c'est de la gestion de configuration, comme Puppet, Chef, Salt, ou CFEngine.

          S'il connaît déjà perl, il sera peut-être aussi intéressé par rex, outil que j'ai choisi au taf pour 2 raisons:

          • pas d'agent (comme puppet, me semble);
          • dépend de perl, donc 0 dépendance sur Debian, perl étant obligatoire de toute façon, contrairement à python;

          Au début je voulais utiliser cfengine (les systèmes que je veux automatiser sont des systèmes «embarqués» (dans le sens pas des masses d'espace disque, pas d'accès physique et une connexion GPRS/[1-4]G), j'essaie de réduire les dépendances, mais il est plus complexe à utiliser, tout en offrant plus de fonctionnalités. J'ai honnêtement du mal à comprendre quel binaire doit réellement fonctionner en permanence, et j'ai aussi l'impression que ça fait double-emploi avec runit (qui au vu de mon usage a un certain nombre de problèmes, il faudrait que je teste nosh, il a l'air plus efficace pour gérer les dépendances).
          À bien y réfléchir, j'ai l'impression que les gestionnaires de configuration avec ou sans agent sont complémentaires: avec agent, ça permets d'avoir un système qui s'auto-répare, mais ça semble pénible d'effectuer des tâches «one-shot», contrairement aux systèmes sans agents.

          • [^] # Re: Linux

            Posté par (page perso) . Évalué à 3.

            pas d'agent (comme puppet, me semble);

            C'est le contraire, puppet a un agent et un des avantages d'ansible (selon ceux qui le voient comme un avantage) est d'être sans agent.

            • [^] # Re: Linux

              Posté par . Évalué à 2. Dernière modification le 16/01/19 à 13:24.

              Merci de la correction.

    • [^] # Re: Linux

      Posté par . Évalué à 1.

      Concernant le Big Data ont peut simplifier en disant que soit on utilise une plateforme complète comme Hadoop soit on utilise une (ou des) bases Nosql (Mongodb,couchbase,Elastic , Neo4j, etc) Sachant qu'Hadoop intégre aussi des bases NoSql (Habse,accumulo,..)
      AWS utilise tout ça y compris Hadoop qui n'est pas du tout minoritaire dans les grands entreprises (Banques,Assurances,Industries..)

  • # Nuage maison et nuage privateur

    Posté par (page perso) . Évalué à 10.

    La mode est au nuage, mais il y a deux grandes approches: soit la boite héberge elle même son nuage, soit elle fait appel aux gafeurs.

    La première approche est plus difficile, mais elle indique que l'entreprise a la volonté de maîtriser son SI et ses données. Le boulot y est aussi peut être plus intéressants pour les profils comme le tien.

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Nuage maison et nuage privateur

      Posté par . Évalué à 2.

      D'où l’intérêt de connaitre les containers et tout ce qui tourne autour ?

      • [^] # Re: Nuage maison et nuage privateur

        Posté par . Évalué à 1.

        Oui , c'est un plus, notamment pour des applications de traitement de données (Docker est intégré à la dernière version de Hadoop Hortonworks par exemple)

    • [^] # Re: Nuage maison et nuage privateur

      Posté par . Évalué à 0.

      La mode est au nuage, mais il y a deux grandes approches: soit la boite héberge elle-même son nuage […]

      Est-ce que ça a un sens de parler de nuage dans ce cas-là ?

      • [^] # Re: Nuage maison et nuage privateur

        Posté par (page perso) . Évalué à 9. Dernière modification le 01/01/19 à 11:45.

        Un nuage privé garde d'autres caractéristiques du nuage : ressources crées/détruites dynamiquement rapidement, facturées à chaque projet utilisateur à la consommation, des API pour l'infra, les sauvegardes, etc. Il y a toujours des trucs inconnus qui tournent sur le même hyperviseur que toi, mais c'est un autre projet de la boîte.

  • # Avec le cloud, la mode est au devops, infrastructure as code. déploiement continu

    Posté par . Évalué à 10.

    Pour le premier (devops), ce serait bien de te mettre un peu au courant de ce que ça signifie. Pour les autres termes, connaître des outils tels que git, ansible, et jenkins peut aider.

  • # Python rulz!

    Posté par . Évalué à 9.

    J'ai pas de réponse générale à apporter, chacun son métier.

    Le Big Data, c'est un peu un métier à part, par exemple, et c'est assez costaud sur le plan théorique, il faut un bagage correct en maths. On est plusieurs de ma boîte à avoir essayé de suivre un MOOC big data un peu en dilettante à temps perdu (celui-ci, je crois : https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04006+session10/about) et on s'est cassé les dents. Ça demande des pré-requis et de l'investissement.

    Python est un outil qu'on peut utiliser dans plein de métiers et ça vaut d'autant plus le coup de l'apprendre que c'est très accessible et super sympa. Je recommande chaudement ce cours en ligne : https://www.fun-mooc.fr/courses/course-v1:UCA+107001+session02/about.

    Comme dit dans un autre commentaire, savoir utiliser un gestionnaire de version (git par exemple), faire des tests unitaires (pytest en python) et un peu d'intégration continue (analyse statique de code lors des commits, déploiement automatisé quand les tests passent, ce genre de choses), c'est bien aussi. Mais franchement, j'ai regardé un jour la doc de Jenkins et j'ai trouvé ça assez touffu alors sans projet réel sur lequel l'utiliser, je me vois pas l'apprendre. C'est bien de connaître l'idée et je pense pas que ça soit rédhibitoire à l'embauche : ça peut s'apprendre sur le tas au fur et à mesure.

    • [^] # Re: Python rulz!

      Posté par . Évalué à 3. Dernière modification le 28/12/18 à 16:59.

      Bonjour,

      C'est bien ce que j'ai cru comprendre pour le big data, que c'était un monde de matheux/informaticien.

      Les algo de mapreduce m'ont mapreducé , ais les outils de "db" m'ont interessé, jusqu'au moment où j'ai comparé les perfs entre pig sur un CSV (40 secs de traitements) et le même CSV mais sur mysql (0.1 sec ?) , et qu'en effet, cela valait le coup qu'à partir un certains nombre de datanode

      Un grand merci concernant le lien python, j'aimerais rajouté que , moi qui ne comprenait pas grand chose à la programmation GUI en cours il y a 20 ans, j'ai pu créer mes premières GUI avec tkinter

      • [^] # Re: Python rulz!

        Posté par . Évalué à 2.

        On n'utilise plus mapreduce et Pig depuis assez longtemps maintenant (c'est à dire au moins 3 ans ;-) , c'est Hive+llap et SPARK.
        Faire du Big Data sur un fichier csv (a priori petit ) ne sert à rien , le temps de latence est trop important.
        Il faut faire le même exercice sur une base de plusieurs millions de lignes (quelques tera par exemple..)

  • # Sortir du lot

    Posté par . Évalué à 3. Dernière modification le 28/12/18 à 16:47.

    Pourquoi ne pas sortir du lot en proposant des compétences plus rares mais utiles ? Je pense notamment au Go qui peut être utilisé dans pour le développement dans différents domaines comme le devops ou le backend.

    • [^] # Re: Sortir du lot

      Posté par (page perso) . Évalué à 8.

      Je ne sais pas si faire du Go, c'est sortir du lot en ce moment, mais c'est sûr que ça peut être utile.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Sortir du lot

        Posté par . Évalué à 1.

        Apprendre un langage même superficiellement n'est jamais vraiment du temps perdu.

        Chaque langage a sa force, je parlais de python, qui est puissant en fait non par sa quantité de modules, mais bien pour sa facilité de travailler avec des tableaux et des maps quelque soit a source, base de donnée ou fichier texte. Les threads sont déconcertant de facilité à mettre en place. La programmation objet qu je n'ai pas encore commencé en fait

        Perl me semblait assez aisé pour traiter le fichiers

        J'éviterais de parler d'autres langages pour éviter de dire des aneries

        • [^] # Re: Sortir du lot

          Posté par . Évalué à 0.

          Sortir du lot, c'est bien pour un jeune, mais pour un développeur expérimenté, il faut qu'en apprenant un minimum de techno il puisse s'assurer un avenir assez lointain. Le Go a en l’occurrence encore, a mon avis, un avenir relativement incertains (Même s'il est moins incertain que Rust tout autant intéressant pourtant).

    • [^] # Re: Sortir du lot

      Posté par (page perso) . Évalué à -2.

      Fais plutôt du NodeJS, c'est clairement plus bankable sur le marché de l'emploi que Go.

      Et l'écosystème est clairement plus riche.

      Par contre, si tu veux devenir un SPOF dans l'entreprise, c'est plus facile avec Go.

      • [^] # Re: Sortir du lot

        Posté par . Évalué à 4.

        si tu veux devenir un SPOF dans l'entreprise, c'est plus facile avec Go

        Ce qui veut dire que l'entreprise ne devrait pas utiliser Go, pour ne pas avoir de SPOF ?
        (je suppose que SPOF == Single Point Of Failure …)

        • [^] # Re: Sortir du lot

          Posté par . Évalué à 6. Dernière modification le 05/01/19 à 20:33.

          Ce serait triste que quelqu'un qui considère NodeJS comme une bonne technologie qualifie go de «seul point d'échec» quand on voit la quantité de foirages autour de node (qui viens bien entendu avec npm, médaille d'or de l'usine à gaz, qui n'est d'ai…
          Je ne comprend personnellement pas pourquoi utiliser ce machin:

          • c'est pénible à débugger;
          • quand il faut accéder à une lib système il faut se taper une API mal documentée et instable;
          • maîtriser les dépendances est une gageure;

          Perso, je dois me taper un bout de NodeJS (+ electron, pour ne pas aider) au taf… enfin, je me contente d'intégrer le code au système, c'est un collègue qui doit supporter l'implémentation (pour raisons «historique» de moins d'un an)… et c'est un cauchemard. À un tel point qu'au final l'application risque fort d'être réécrite dans un autre langage cette année. Un langage avec des outils qui permettent d'analyser statiquement le code, d'exécuter pas à pas le code, et qui est capable d'utiliser les lib systèmes, c'est à dire: n'importe lequel sauf ecmascript (en pratique, ça sera sûrement C++ pour le coup, mais go ne m'aurait pas dérangé plus que ça).

          De mon côté, j'ai aussi commencé à me faire une collection de liens sur les problèmes de sécurité autour de NodeJS (et son environnement, et sa communauté), pour me détendre quand je dois interagir avec ce truc. S'il y a bien une technologique que je déteste c'est bien NodeJS: je préférerais retravailler sous windows et son gestionnaire de fenêtres merdique plutôt qu'être concerné par une autre projet qui l'utilise. Je suis pas loin d'éprouver de la haine pour ce machin.

  • # Mon point de vue

    Posté par . Évalué à 5.

    • python
    • Docker / kubernetes
    • savoir utiliser les apis / services d'AWS et / ou Azure
    • serverless : AWS Lambda et son équivalent chez Azure
    • [^] # Re: Mon point de vue

      Posté par . Évalué à 2.

      Tout à fait d'accord avec cette liste de technos. Je rajouterais juste Ansible ou équivalent.

    • [^] # Re: Mon point de vue

      Posté par (page perso) . Évalué à 4. Dernière modification le 28/12/18 à 22:41.

      Python est sûrement l'un des plus polyvalents : admin sys (scripts « à l'ancienne » ou personnalisation d'Ansible), web, « middle » data (permet d'utiliser les outils Big Data pour tester des algos, par exemple), analyse de données, calcul numérique, …

    • [^] # Re: Mon point de vue

      Posté par . Évalué à 0.

      Concernant AWS/Azure, j'ai cru comprendre qu'en fait elles reposaient sur oenstack , est ce correct ? (Vous l'avez devinez, je connais un peu S3 et EC4 comme beaucoup de monde, mais passé ça … )

      • [^] # Re: Mon point de vue

        Posté par . Évalué à 3.

        Non c'est totalement faux.

        Sinon EC4 n'existe pas, c'est EC2.

        • [^] # Re: Mon point de vue

          Posté par . Évalué à 0.

          Ok merci. J'avais retenu S3 ECx avec le delta entre 3 et x de 1 :-). Bon, l'avantage de ne rien savoir est que je ne peux que m'amméliorer

  • # Comment ça, le Perl a disparu ???

    Posté par (page perso) . Évalué à 4. Dernière modification le 28/12/18 à 19:31.

  • # bon courage

    Posté par (page perso) . Évalué à 7.

    En résumé, je réalise qu'en huit passé à troubleshooter mon produit propriétaire , je n'ai pas vraiment eu de visus sur l'évolution des prods, pourriez vous me donner des avis ?

    La veille techno, c'est un truc qui se fait au quotidien. Mon avis, c'est que n'est pas un passionné sinon tu ne te retrouverais pas en 2019 avec 8 ans de veille de retard.

    Dois je continuer à apprendre python ?

    Python c'est un outil pour développer des applications complètes, pour faire du traitement de données, pour faire du scripting et de l'automatisation. Continue de l'apprendre. Ça te fera pas te faire embaucher, mais c'est un couteau suisse qui te servira au quotidien.

    Dois je insister sur hadoop

    Tu ne cibles pas un boulot de développeur, je me trompe ? Laisse tomber hadoop.

    sur le cloud ?

    Ça c'est la base. Que tu veuilles faire de la prod, du développement, du devops, c'est le standard d'infrastructure, le cloud.

    Si tu veux rattraper ton retard, c'est là dessus qu'il faut le rattraper, et avec les problématiques connexes : technos de déploiement, orchestration, «scalabilite», serverless, devops.

    Apprends les principes généraux avant de focaliser sur une techno spécifique. Rattrape ta veille techno avant de mettre les mains dans le camboui. On s'en br… de kubernetes si tu ne maîtrises pas ce qu'est l'orchestration et ce qu'est un conteneur.

    • [^] # Re: bon courage

      Posté par . Évalué à 6.

      La veille techno, c'est un truc qui se fait au quotidien. Mon avis, c'est que n'est pas un passionné sinon tu ne te retrouverais pas en 2019 avec 8 ans de veille de retard.

      Entre un livre sur le cloud, et un livre sur la rétro-ingénierie plein d'ASM, je choisis toujours le second. Suis-je un non passionné pour autant ?

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: bon courage

        Posté par (page perso) . Évalué à 10. Dernière modification le 29/12/18 à 11:14.

        Entre un livre sur le cloud, et un livre sur la rétro-ingénierie plein d'ASM, je choisis toujours le second. Suis-je un non passionné pour autant ?

        Lire un livre, pour moi ce n'est pas de la veille, c'est approfondir un sujet. La veille c'est le contraire : survoler tout ce qui passe pour savoir ce qu'il pourrait être intéressant d'approfondir.

        Si tu es passionné et que tu fais de la prod, je m'attends (naïvement?) à ce que tu sois au fait de l'état de l'art dans le domaine, même si tu ne pratiques pas.

        • [^] # Re: bon courage

          Posté par (page perso) . Évalué à 8. Dernière modification le 29/12/18 à 11:18.

          Au passage je précise bien : je ne dis pas que l'auteur n'est pas passionné. Je donne simplement mon avis - qui est subjectif.

          Je donne mon avis parce que c'est ce que l'auteur a demandé. J'ai une position de recruteur et donc mon avis peut être intéressant pour se préparer à des entretiens, indépendamment du fait que j'ai tord ou raison.

    • [^] # Re: bon courage

      Posté par . Évalué à -3.

      La veille techno, c'est un truc qui se fait au quotidien. Mon avis, c'est que n'est pas un passionné sinon tu ne te retrouverais pas en 2019 avec 8 ans de veille de retard.

      C'est quoi cette façon de juger les gens ? Tu te prends pour qui ?

      Tu ne cibles pas un boulot de développeur, je me trompe ? Laisse tomber hadoop.

      N'importe quoi .. Si Hadoop ne concernait que les développeurs … Il y a des gens qui pondent desarchitectures baséessur Hadoop sans être développeurs, et maintiennent/administrent le bouzin.

      • [^] # Re: bon courage

        Posté par (page perso) . Évalué à 9.

        C'est quoi cette façon de juger les gens ? Tu te prends pour qui ?

        J'ai répondu à ce genre d'interprétation avant même que tu commentes (cf. mes commentaires ci-dessus)

        N'importe quoi .. Si Hadoop ne concernait que les développeurs … Il y a des gens qui pondent desarchitectures baséessur Hadoop sans être développeurs, et maintiennent/administrent le bouzin.

        Évidemment. Mais s'autoformer sur hadoop dans le but d'être recruté ça veut dire quoi ? C'est comme dire «je vais me remettre au développement après 5 ans à faire des technos MS, je vais me plonger dans MySQL». On s'en fout. Soit tu as les bases et tu es capable d'apprendre sur le tas, soit tu es expert et on te recrute pour ça.

        • [^] # Re: bon courage

          Posté par . Évalué à 3. Dernière modification le 30/12/18 à 11:19.

          J'ai répondu à ce genre d'interprétation avant même que tu commentes (cf. mes commentaires ci-dessus)

          Effectivement, je suis parti un peu vite (je n'aime pas trop les gens qui se mettent à juger quelqu'un sur 10 lignes d'un post sur linuxfr). Celà dit, tu aurais pu aussi formiler ton commentaire plus clairement.

          s'autoformer sur hadoop dans le but d'être recruté ça veut dire quoi ?

          Ca dépend comment c'est présenté (tout seul, ça veut rien dire), mais ça peut vouloir dire que la personne s'est intéressée un minimum au sujet. Certes on lui proposera pas un poste d'architecte ou d'admin Hadoopo/big data, mais on peut l'intégrer à une équipe qui travaille sur le sujet en se disant que le big data ne la fera pas fuir dans 6 mois (oui, il y a des personnes comme ça: réfractaires à certaines technos).

    • [^] # Re: bon courage

      Posté par . Évalué à 3.

      Effectivement. Je dirais plus simplement que s'autoformer à des technos dont le concept est assez différent nécessite un investissement du temps personnel qu'on est pas tous à vouloir sacrifié. C'est d'autant plus vrai qu'un éditeur en panique te colle des objectifs rarement atteignable. S'en suit peut être un perte de confiance mais surtout une fatigue morale. Grosse pensée aux employé de redhat lorsque les shareholders reclameront une hausse des marges.

      Donc oui, j'avais l'envie mais pas l'énergie pour m'y atteler.

      Donc voilà, je sais pas si effectivement, je suis autant passioné que toi, mais je suis sûr que j'étais exténué (et au vu des commentaire sur blind, je n'étais pas le seul)

      • [^] # Re: bon courage

        Posté par . Évalué à 5. Dernière modification le 30/12/18 à 13:08.

        C'est pour ça que j'ai réagi comme je l'ai fait à la réponse que tu as eu : je suis personnellement passé par une période (certes un peu moins longue) ou les circonstances ont fait que je n'ai pas été en mesure de faire la veille techno que j'aurais aimé faire (période ou vie perso et pro ne se passaient pas comme je le voulais). L'envie était là mais l'énergie (tant physique que morale) ne suivait pas toujours.

        Juste un conseil: si tu as "subi" une forme quelconque de harcellement moral, ou si la situation que tu as vécue chez ton employeur a miné ton moral ou ta confiance en toi, je ne peux que te conseiller quelques séances chez un ou une psy. Ca peut t'aider à reprendre confiance en toi pour un nouveau job (et de ne pas te réenfermer dans une situation qui ne te plairait pas faute de mieux). Ca pourrait faire une grosse différence.

        Pour ma part, je ne l'ai pas fait (si je l'ai fait mais bien plus tard), et j'ai du trainer pendant des années un boulet dont j'aurtais pu me libérer bien avant.

    • [^] # Re: bon courage

      Posté par . Évalué à 7.

      La veille techno, c'est un truc qui se fait au quotidien. Mon avis, c'est que n'est pas un passionné sinon tu ne te retrouverais pas en 2019 avec 8 ans de veille de retard.

      Je ne suis pas tout à fait d'accord. Même en étant passionné, on ne retiens de notre veille quotidienne que les trucs qui nous intéressent, soit parce qu'utile professionnellement (j'ai longtemps suivi les nouveautés d'AWS pour cette raison) soit parce que le sujet nous intéresse personnellement (par exemple de la veille sur un langage particulier).

      Maintenant, sur tous les autres sujets, j'ai vu passer des infos (par exemple, il me semble qu'on peut faire des requêtes sur des champs en JSON dans mysql), mais :
      1 - Je suis loin d'être sur de la valeur de ces infos que j'ai retenu
      2 - Je me vois mal les utiliser pour un entretien (pour la simple raison du point 1)

      Du coup, j'imagine bien que si je reste 8 ans au même poste dans une boite qui utilise des trucs "non-hype" que je me sentirai moyennement à l'aise pour prétendre connaitre les trucs "hype" même si j'ai déjà vu passer des articles que j'aurai survolé.

  • # On va supposer que tu es sur Paris ...

    Posté par . Évalué à 8.

    On va supposer que tu es sur Paris … ou me trompe - je ?

    C'est déjà plus facile …

    A un moment j'ai recherché aussi à changer mais pour d'autres raisons …

    Eh ben en province oui il y a besoin de Linuxien ou d'unixien mais la plupart des sociétés consultés
    - ne veulent pas du télétravail
    - imposent des déplacements nationaux voire même Européens
    ou
    - ne veulent pas de vieux pénibles qui de plus coutent cher mais c'est peut être pas ton cas …

    bref pas simple …

  • # Concernant Hadoop et Big data

    Posté par . Évalué à 1.

    Les technologies Big Data (et les traitements de données en général) sont très demandées :
    Pour un développeur il s'agit de connaître les briques à utiliser et dans quels contextes (Hbase , Hive et surtout Spark) avec un langage au choix parmi Python-R-Scala-Java.
    Le big Data n'est pas seulement de l'apprentissage automatique avec les algorithmes stats/maths mais intervient dans toutes les composantes du traitement de la donnée.

    Pour hadoop le choix se fait entre Hortonworks et Cloudera , sachant qu'ils ont annoncé une fusion et qu'ils se partage le marché à 90% aujourd'hui. (pour info HDinsight de Microsoft c'est du Hortonworks)

    Openstack : oui c'est demandé

  • # Merci

    Posté par . Évalué à 3.

    Merci pour tout vos commentaires.
    1- le fun mooc sur python est très interessant. Et c'est vrai que ce langage est attachant, amusant, puissant et pas rebarbatif.

    2- merci des corrections pour le big data sui confirme qie certains institut de CPF sont de piètre qualité

    3- merci pour m'avoir donné les priorités. L'objectif est surtout de savoir ce dont il est question. Ce dont je redoute est de me retrouver en dinosaures dans un nouveau poste.

    4- En fait, je pense que le problèmeest surtout de niveau: que peut on faire après 8 ans de support sur un produit ? Architecte sur ce produit, consultant pour un partenaire, manager une équipe de jeunes techniciens/ingénieurs. Je ne cible rien de bien particulier pour le moment mais vos réactions montrent qu'il y a du boulot actuellement.

    5- encore une fois, grosse pensée pour les employés de redhat: les marges à target+0.1%, vous serez des génies et les marges à target-0.1%, vous serez des parias à riffer

  • # A l'ancienne

    Posté par . Évalué à 10.

    Marrant, tout le monde ne parle plus que de Docker, de cloud, de devops, de big data, on en trouve plein sur les offres d'emploi. Mais dès qu'on commence à bosser on réalise que ce qu'ils cherchent surtout ce sont des gens prêts à débugguer des applis historiques en php5/tomcat sur des rhel5/deb6, à l'ancienne, car c'est ce qui constitue la majorité du parc informatique dans les entreprises.

    • [^] # Re: A l'ancienne

      Posté par . Évalué à 1.

      C'est pas faux , l'un n'exclut pas l'autre mais à un moment donné il faut choisir et la question du début était assez orientée virtualisation , cloud et big data..

      • [^] # Re: A l'ancienne

        Posté par . Évalué à 6.

        En fait la manière dont j'interprète la question est "dois-je me mettre à la page docker pour être embauchage en 2018?" et à mon sens il y a beaucoup plus de taf sur des infra "historiques" que sur des mécaniques automatisées bien huilées.

        Toutes les entreprises veulent se mettre au cloud et à Docker car dans la tête des décideurs c'est la facilité et la souplesse. Mais quand tu présente l'estimation des coûts pour le code et que tu explique qu'il va falloir recoder leur applicatif moisi pour le rendre stateless et mettre en place un git et une chaîne d'intégration continue, le résultat est souvent "on verra plus tard".

        • [^] # Re: A l'ancienne

          Posté par . Évalué à 2.

          Tout a fait.

          Pour autant, quand tu cherches à recruter, il me semble normal de chercher a avoir quelqu'un qui a des compétences devops si c'est la direction vers laquelle tu souhaites aller.

          Parce qu'à un moment donné, si tu as le budget pour bouger, autant avoir déjà les compétences en interne.

          • [^] # Re: A l'ancienne

            Posté par . Évalué à 4.

            Bon après la plupart des employeurs/recruteurs n'en ont absolument rien à carrer que tu aies des connaissances devops, que tu te sois autoformé à patati ou patata. Ce qu'ils recherchent c'est quelqu'un qui a des expériences concrètes dans un milieu professionnel (oublies le "j'administre une ferme kubernetes dans le cloud pour héberger les sites de mon association/la famille/les copains").

    • [^] # Re: A l'ancienne

      Posté par (page perso) . Évalué à 3.

      Tu peux tomber sur pire : debugger des applis pourries ET déployées n'importe comment dans un sandwich Docker fait par des devs (médiocres) qui se croyaient ops.

  • # machine learning > bigdata

    Posté par (page perso) . Évalué à 6.

    C'est déjà has been le big data. Le hype c'est le machine learning et l'AI maintenant.

    Sinon si tu es plutôt intéresser par l'infrastructure et les grands éditeurs, tu peux voir à bosser sur le cloud lui même plutôt que sur des trucs qui utilisent le cloud.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: machine learning > bigdata

      Posté par . Évalué à 4.

      Faire du machine learning (apprentissage automatique) et de de l'IA sans big data c'est difficile..pas impossible mais difficile : Plus tu as de données plus ton apprentissage est rapide et pertinent.
      Les algorithmes de machine learning et deep learning sont inclus dans les solutions comme Haddop/Spark/Tensorflow/H2o

      • [^] # Re: machine learning > bigdata

        Posté par (page perso) . Évalué à 2. Dernière modification le 11/01/19 à 17:36.

        Ça ne le contredit pas. La hype ML repose sur l'ancienne hype BigData qui peut se reposer elle-même sur une infra ancienne ancienne hype devops/docker/pouet.

        Et il a raison, mes collègues Data Scientist avec le tiers de mon ancienneté dans le monde du travail (2-3 ans les concernant) négocient des salaires auxquels je n'arrive pas à prétendre, alors qu'en tant que dev Scala je suis déjà dans une belle niche.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.