Nous avons 4 serveurs en replica_set… pour le moment il n’y a pas trop de limitation en phase beta.

Attention, passer à MongoDB rend tout retour vers MySQL très difficile … je me fait moi même souffrance sur des vieux projets MySQL !!

Développer c’est comme chanter, tout le monde peut le faire mais ça donne pas le même résultat !

Par la suite, X… m’a fait une offre.
il m’a raconté après qu’avec cette phrase j’avais réussi mon entretien d’embauche

Ça serait sympa de faire du buzz la dessus avec une bannière \ »Fier d’être développeur\ » que chacun pourrait afficher sur son blog ou espace perso…

Car pour casser le mythe du chef de projet tout puissant aboutissement ultime de la carrière, il va falloir en brasser de l’air avant que cela n’arrive aux oreilles de nos décideurs.

Les Chefs de projet, certes il en faut mais ce n’est pas eux qui font un produit de qualité [j'exclue le côté fonctionnel].
Il n’y a qu’à comparer le travail réalisé par 2 équipes :
_ l’une avec un responsable de projet très bon et des développeur inexpérimentés
_ l’autre avec un chef de projet déconnecté du monde avec de bons développeurs

Les entreprises qui ont fait fortune dans l’Informatique ont toutes été bâties autour d’un développeur (ou par un)

Mais c’est plus rassurant d’avoir des petits chefs [tyrannique et incompétents] que pleins de développeurs [doués et aimant leur job]
On sait jamais les ouvriers (3*) pourraient réclamer quelques choses aux grands chefs.

Après on risque de tomber dans le défaut inverse où on voit un PDG qui est fier d’avoir recruté un gars qui lit 3 bouquins par semaine et qui apprend 1 langage par an [Vu sur Capital M6], la quantité n’a jamais fait la qualité… chez nous on appelle ça pipoter son boss [même si la performance reste possible je trouve dommage de la louer de la sorte, en plus trouver 12 livres intéressants et utiles par mois me semble un défi bien difficile ! ]

En fait, ça part bien jusqu’à cette phrase: « J’encourage par contre chacun à prendre des responsabilités de manager. »

Personnellement, on a bien essayé de me faire croire que je serais chef de projet au bout de 2 ans, mais 1. ce n’est pas le métier que je voulais faire (toujours pas d’ailleurs) et 2. faut pas prendre des ingénieurs pour des abrutis non plus (même si dans le lot y en a pas mal quand même).

Le management c’est un métier à part, il est peut être possible de l’apprendre dans les écoles de management mais c’est avant tout une question d’affinités et de compétences. Dans les filières techniques comme celle que j’ai suivie, on forme des techniciens – à la rigueur des chercheurs – et pas des managers. S’il y en a qui se découvrent des dons, pourquoi pas et grand bien leur fasse. Mais je ne vois pas grand chose de commun entre un développeur accompli, concepteur de systèmes logiques plus ou moins complexes, et un chef de projet, gestionnaire de personnes entre autres ressources (je force volontairement le trait ici).

Je suis donc d’accord avec la conclusion de l’article et je suis moi-même fier de mon métier, comme la plupart des collègues de mon équipe actuelle (et pas comme la plupart des gens de ma boite). Mais j’aimerais bien qu’on arrête de restreindre les débouchés à la seule gestion d’équipe et qu’on parle un peu plus des autres profils: consultant, formateur, expert technique, architecte, urbaniste – et développeur senior.

« Aujourd’hui j’ai 36 ans. J’ai été chef de projet, mais j’aime coder. »
=> Ayant été des 2 côtés de l’Atlantique (France, USA), cette phrase sonne étrangement. Parlant assez souvent avec des dev américains/canadiens, prendre du plaisir à coder est presque un truc normal.

On saura que la situation a changé en France quand il n’y aura plus besoin d’écrire cette phrase.

Tu as tout mon soutien.

« Si un serveur secondaire est trop en retard par rapport au serveur primaire, il s’arrête, se vide, et se resynchronise ensuite avec le primaire »

Hum, dans ce cas, si le serveur secondaire est trop en retard, comment va-t-il rattraper son retard s’il s’arrête, se vide, et se resynchronise ensuite avec le primaire ? on ne rattrape pas son retard en s’arrêtant pour se vider, non ?

« Si un noeud a 50%-50% (2 serveurs) il n’y a pas d’élections, les 2 machines passent en secondaire »

donc, si on a 3 serveurs, 1 maitre + 2 secondaires, si on perd le maitre, les secondaires restent secondaires à tout jamais, non ?
et plus aucun update n’est accepté…
sauf si une nouvelle machine est rajoutée.

« Pierre rappelle que le code est plus simple, et que souvent vous retirez des tables de bases de données lorsque vous passez vers MongoDB »

oui, car NoSQL implique dénormalisation (car NoSQL ~ NoJoin), et donc, le modèle de la base se rapproche du modèle objet.
reste que dénormalisation peut impliquer aussi de multiples updates lors d’une mise à jour. Et se pose alors la question de la cohérence des donneés, pb qui se posait moins (voire, pas du tout) avec une base SQL.

« Il faut entre 20 et 25 secondes pour ré-élire un master. »

je ne comprends pas qu’il faille autant de temps.
cela me parait bizarre, sachant que, dans un replica set, les serveurs se connaissent déjà.

« On trouvera facilement un article d’un gars déçu par MongoDB »

perso, j’ai trouvé 2-3 articles qui pestaient contre MongoDB, et notamment sa gestion du clustering, et/ou ses performances qui chutaient quand les données ne tenaient plus totalement en RAM.

donc, je suis d’accord avec la conclusion: « testez, testez et re-testez »

La cellule « fantôme », qui avait pour vocation de préparer Apple au monde du mobile, était localisée à Paris.

Dans une petite/moyenne structure, on peut aussi prendre en compte la complexité de la maintenance des outils. C’est aussi ce qui peut faire préférer elasticsearch à solr. Ou préférer d’autres solutions de map/reduce à Hadoop