En vrac :

• des deadlines hyper serrées, de la pression, des burnouts, certains bossent 14h/j 7j/semaine
• culture toxique niveau management
• des gens brillants, surtout au début avant leur départ, d'autres qui restent car ils ont peur de ne pas retrouver un job
• gros turnover surtout pour la partie autopilot
• peu de considération pour la sécurité informatique (ndlr : ça se tient avec un management pareil)

Thread hyper instructif sur l'envers du décor.

Fichage de salariés, licenciements montés de toutes pièces, répression syndicale, management brutal… Politis publie des preuves et des témoignages exclusifs.

Je déterre un vieil article de 2009.

La mentalité française vis à vis des métiers de l'informatique a longtemps été de considérer que la technique n'était qu'un passage avant d'aller vers du management. En gros "Si t'es pas chef de projet à 40 ans, t'as raté ta vie!". C'est très lié à l'élitisme des grandes écoles dans ce pays.

J'ai jamais compris ce culte du management. J'ai moi même fait une formation en alternance qui préparait à être "chef de projet" (y'avait que ça) mais je n'ai jamais quitté la technique et ça me branche toujours autant. Heureusement c'est en train de changer. Des écoles comme 42 viennent casser cette vieille façon de penser l'informatique, et la technique recommence à être revalorisée car on comprend qu'elle représente un élément clé dans la réussite d'un produit. La culture d'entreprises à succès comme facebook ou google ont peut-être contribué à cela.

lien via @lpmillet

Merci à toi Benjamin et aux autres contributeurs pour cette appli qui m'évite d'aller sur les sites (pourris) de mes banques et qui me permet de gagner en fonctionalités:

• recherche full text
• alertes/rapport mail
• graphique des entrées sorties / catégorie / de la balance selon le temps. très instructif pour comprendre ses dépenses et anticiper.
• archiver/historiser les transactions chez moi et ne pas compter sur l'informatique des banques. par exemple à la banque postale, pour revenir dans le temps il faut se palucher des PDF.

Dans votre carrière d'informaticien (arg, je déteste ce mot trop généraliste/abstrait, en plus d'être encore mal connoté), vous vous êtes certainement retrouvés dans cette scène.

Joli tuto pour ceux qui veulent commencer avec saltstack.

"""
Voilà bientôt cinq ans que l’établissement a ouvert. Lorsque cinq militants, d’âges et de milieux différents, se sont lancés dans une boulangerie bio autogérée pour mettre en pratique leur idéal politique communiste libertaire, rien ne présageait encore le succès qu’ils rencontrent aujourd’hui. Parmi le quintette de fondateurs issus de fédérations communistes et anarchistes, Pierre, le principal initiateur du projet, est le seul à avoir une formation de boulanger. Les autres sont informaticiens, graphistes, doctorants ou étudiants. Mais tous sont d’accord sur la direction à choisir : ni Dieu, ni maître, ce sera une boulangerie sans patron. Résultat : pas de hiérarchie dans la gestion, des salaires égaux, une rotation des tâches pour égaliser les compétences et des prix cassés pour les clients les plus modestes.
"""

Voici la vidéo de cette rencontre: http://www.dailymotion.com/video/k5o36NvlFBfyQAbZUDk

TL;DW; ? Ce que je retiens:
"""
Avoid Technical Debt

• use a framework
• be open to new technologies
• unit tests
• loosely coupled code
• code reusability (modularize the code)
• reduce code complexity
• code reviews and feedback
• coding standards (promote good architecture)
• design patterns
• general best practices
• static code analysis
• continuous integration tools
• configuration management tools

Pay off Debt

• Make a plan
• Set goals
• Stay inside your budget
• Consistency
• Pay off some debt each sprint on regular interval
  """

De nombreux trolls en perspective.

Viendez.

"""
C’est largement mieux de donner des objectifs globaux et de permettre à vos développeurs de les atteindre comme ils le souhaitent. Parfois ils échoueront ; vous devez faire avec ça. Et ne réagissez pas aux échecs en ajoutant des processus et du contrôle. Travaillez à monter une belle équipe en qui vous pouvez avoir confiance et qui peut contribuer à la réussite plutôt que d’occuper des salles comme des pisseurs de code passifs.
"""

"""
“Infrastructure as a code” changes the administrator mindset. It makes them developers and requires from them programmatic skills. It perfectly matches the DevOps concept. Looking at it from the other side – taking care of infrastructure becomes interesting for developers and starts to no longer be considered as a necessary evil.

In the current tools and technology state implementing this approach takes quite a lot of time. Using it for small scale solutions and systems might (let me emphasise: might) not pay off. However, if you are managing several dozen configurations and machines you will notice the benefits quite fast. While implementing new changes might still take more time than in the old approach, full tracking, automation and gained stability will leverage the additional effort.

There will be less and less classical admins in the future. We have see this trend since many years ago. I also expect that “Infrastructure as a code” tools will go into direction when setup and usage will be so simple and user friendly that almost no one will consider configuring infrastructure without them.
"""

petit tuto d'introduction à Augeas: http://augeas.net/
Il parle de puppet mais on peut l'utiliser avec salstack également: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.augeas.html

autre prise en main rapide: http://augeas.net/tour.html

Détails techniques sur la gestion de conf (chef) chez Facebook.

Quelques notes pour vous donner envie de voir cette vidéo*
15:50 move indempotency up (avoid stale entries)
24:50 code reviews + lint (testing chef cookbooks)
32:30 we're facebook, fuck it, let's do it! (utilisation d'un module en erlang pour améliorer les perfs, bleeding-edge non-testé ni utilisé par personne)
35:20 tests in production
39:35 Q: how many homogeneous/heterogeneous systems can you maintain? A: > 17k
Q: how many people are needed? A: ~4

• malgré le ton pédant du mec

comme libreboard.com

L'article montre les limites des systèmes de déploiement déclaratifs comme puppet
"""
...
And obviously, the entire problem of server deployment is deeply stateful - your server is quite literally a state machine, and each deployment attempts to modify its current state into (hopefully) the expected target state.

Unfortunately, in such a system it can be difficult to predict how the current state will interact with your deployment scripts. Performing the same deployment to two servers that started in different states can have drastically different results. Usually one of them failing.

Puppet is a little different, in that you don’t specify what you want to happen, but rather the desired state. Instead of writing down the steps required to install the package foo, you simply state that you want foo to be installed, and puppet knows what to do to get the current system (whatever its state) into the state you asked for.

Which would be great, if it weren’t a pretty big lie.
...
"""
NixOS fait également parti de ces systèmes mais son approche différente permet de s'astreindre des principaux défauts de ses 'concurrents'.
Plutôt que de tenter d'ammener le serveur (dans un état X) vers un état Y, NixOS part de zéro.