Archives de catégorie : Software Engineering

MapReduce ? Mais qu’est-ce c’est ?

MapReduce est un schéma de développement (design pattern) proposé par Google en 2004 permettant de traiter de gros volumes de données de manière parallèle et distribuée (merci Wikipédia). D’accord, mais une fois qu’on a dit ça, on est bien avancés. Je vous propose, dans le contenu qui va suivre, d’aborder le problème de fond qui a mené à ce type de solution, et l’application de MapReduce sur un cas simple et que l’on peut se représenter.

Quel est le problème ?

Au cours des 20 dernières années, avec la croissance de l’usage d’internet et de ses applications, les volumes de données stockées, traitées a considérablement grossi. Au point où, pour les stocker, les transporter et les traiter, il n’est plus possible de le faire sur un seul serveur, localisé à un même endroit.

Les données des applications sont donc maintenant distribuées sur plusieurs machines, parfois sur plusieurs pays ou continents. Pour bien comprendre le problème, nous allons l’illustrer avec un exemple simple.

Imaginons une application qui permette de suivre la santé de ses utilisateurs. À ces fins elle conserve pour chaque utilisateur son poids et sa taille. Disons que l’on veut obtenir des données sur l’ensemble de nos utilisateurs, telles que le poids moyen, ou l’IMC moyen. Voici ce à quoi ressemble un utilisateur :

user {
    id: 8374702028476,
    name: "Pierre Ponce",
    weight: 78,
    height: 183,
}

Dans une petite application, ces utilisateurs sont stockés dans un SGBD relationnel dont nous avons l’habitude (tel que MySQL, PostgreSQL, Oracle, …). Les données sont donc dans une table, et l’on va opérer dessus en faisant des requêtes SQL sur l’ensemble ou un sous-ensemble du jeu de données. Il est très facile de compter le nombre de d’utilisateurs, obtenir la somme de tous les poids ou de toutes les tailles avec ce type de systèmes. On peut, par exemple, simplement calculer le poids moyen de l’ensemble de nos utilisateurs avec ce genre de requêtes. Je vous laisse me faire confiance, ou faire un tour du coté de SQL pour voir ce qui est possible.

Que se passe-t-il lorsque l’on veut faire ce type de traitement mais que les données sont distribuées pour des questions de volume, de proximité géographique ou de performances ? Comment utiliser les ressources parallèles de nos infrastructures pour accélérer ces traitements ?

On ne peut effectivement pas transférer toutes les données au même endroit pour faire ces calculs …

Quelques pistes

En se creusant un peu la tête on peut avoir une idée d’approche. Dans notre cas de poids moyen, il suffit de s’intéresser aux propriétés de la moyenne. Pour des utilisateurs A, B, …, F, le poids moyen se calcule de la manière suivante :

W_{avg} = (W_A + W_B + W_C + W_D + W_E + W_F) / 6

Mais on peut aussi le calculer de la manière suivante :

W_{avg1} = (W_A + W_B) / 2 \\ W_{avg2} = (W_C + W_D) / 2 \\ W_{avg3} = (W_E + W_F) / 2 \\ W_{avg} = (W_{avg1} + W_{avg2} + W_{avg3}) / 3

Ça commence à ressembler à un calcul distribué ça non ? Si on considère que les données de nos utilisateurs sont distribuées sur plusieurs serveurs, on peut tout à fait commencer par calculer une moyenne localement sur chacun, et ensuite terminer le calcul autre part. On a ainsi distribué le travail, et transféré peu de données à la fin. En conservant ça à l’esprit, on peut attaquer MapReduce.

Le principe de MapReduce

Le principe de cette méthode est d’appliquer deux opérations map() et reduce(). pour traiter le problème.

L’opération map() a pour but de nous aider à de découper le problème initial en sous problèmes plus petits et traitables en parallèle. Elle prend en général en entrée une donnée et produit un à plusieurs couples (clé, valeur) qui seront ensuite traités par reduce(). map() peut ainsi être réalisée simultanément sur un grand nombre de données, là où elles se trouvent.

Les données émises sont groupées par clés avant d’être fournies à reduce(), par exemple :

(key_1, "value_a")
(key_2, "value_b")
(key_1, "value_c")

deviendra :

(key_1, ["value_a", "value_c"])
(key_2, ["value_b"])

On peut alors appliquer reduce() sur ces nouveaux couples (clef, liste de valeurs) et pour chacun d’entre eux, et calculer une valeur finale. Là aussi, cette opération peut être réalisée en parallèle sur chaque couple. Nous allons voir une application dans les paragraphes suivants. Pour plus de détails sur la partie théorique, je vous invite à lire la publication de Google sur le sujet.

Application

Partons d’un ensemble de clients dont nous avons quelques informations corporelles, et nous souhaitons calculer l’IMC moyen de notre groupe d’utilisateurs. Pour rappel l’IMC se calcule de la manière suivante :

imc = \frac {weight_{kg}} {height_m^2}

Voici quelques utilisateurs :

{id: 7638, name: "Pierre",  height: 1.78, weight: 76},
{id: 5932, name: "Arthur",  height: 1.83, weight: 65},
{id: 213,  name: "Susanne", height: 1.65, weight: 58},
...

Voici l’implémentation de map() que nous allons appliquer :

map(Client c) {
    imc = c.weight / (c.height * c.height);
    // Emit is the classic way for map() to produce (key, value)
    emit("imc", imc);
}

Nous obtenons alors les couples suivants :

("imc", 23.99)
("imc", 19.41)
("imc", 21.30)

Qui seront transformés de la manière suivante avant d’être transmis à reduce() :

("imc", [23.99, 19.41, 21.30])

Voici l’implémentation de reduce() que l’on va appliquer :

reduce(key, values[]) {
    sum = 0;
    count = 0;
    for (v in values) {
        sum += v;
        count++;
    }

    // Emit is the classic way for reduce() to produce the final value
    emit(sum/count);
}

Le résultat de notre map/reduce est donc bien l’IMC moyen de notre ensemble d’utilisateurs.

Ici on voit bien que les map() sont exécutables en parallèle car les données en entrée sont indépendantes. Ils peuvent être exécutés sur les machines où sont stockées les données, et avec toutes les capacités de calcul disponibles localement. Par la suite, reduce() peut aussi être exécuté localement sur les résultats de map() collectés. Il faudra alors terminer le calcul de moyenne en récupérant les résultats de ce map/reduce. Mais devinez quoi ? Il ne reste que très peu de données à regrouper et calculer !

Pour creuser le problème, je vous invite à consulter les références listées ci-dessous, vous aurez ainsi plus de détails ainsi que des exemples d’implémentations.

Remerciements

À Ningyu Li qui a toujours soif d’apprendre et m’a obligé à mettre mes idées en ordre sur le sujet.

Références

Développeurs – Quelles questions poser durant un entretien d’embauche ?

Est-ce que je veux vraiment travailler dans cette entreprise ? ou Quelles questions poser durant un entretien ?

Ce post est la traduction d’un article en anglais que j’ai adoré. Il propose une série de questions à poser lors d’un entretien d’embauche en tant que développeur. J’aurai souhaité l’avoir lu avant mes précédents recrutement, et m’a été d’une aide précieuse pour mes entretiens en tant que recruteur. L’article original d’Elena est disponible ici.

J’ai pratiqué les entretiens d’embauche des deux côtés depuis un moment maintenant. En tant que candidate, pendant 9 ans, et en tant que recruteur – pour 90 entretiens.

J’ai donc décidé d’écrire les questions que je pose habituellement à l’entreprise dans laquelle je postule.

Ces questions m’aident à comprendre la culture d’entreprise, leur manière de faire et, si possible, le niveau de « maturité » des mes collègues potentiels. Habituellement, je pose ces questions à une personne technique – un développeur, au directeur technique ou à un chef d’équipe. Ils sont les personnes les plus proches du poste que je suis susceptible d’occuper, ils seront donc plus à même de me donner des détails que quelqu’un des ressources humaines.

Il est important de ne pas uniquement se concenter sur ce qu’ils vous répondent, mais aussi comment ils vous répondent. Soyez attentif à leur langage corporel, aux éventuels mensonges ou omissions volontaires dans leur propos. Par exemple, si quelqu’un vous dit « la qualité du code est très importante pour nous » mais semble hésitant ou évite votre regard, peut être que votre interlocuteur n’est pas tout à fait factuel.

Assurez-vous également de poser les questions les plus ouvertes possibles. Par exemple :

  • « Corrigez-vous les bugs ? » est une question fermée. Il est facile de répondre « oui, bien sûr » – ce n’est pas une réponse très intéressante.
  • En revanche, « Comment corrigez-vous les bugs ? » est une question ouverte. Cela oblige votre interlocuteur à répondre quelque chose de plus complet que « oui » ou « non ». Vous pourrez par exemple apprendre que l’entreprise a une équipé qualité ou non, écrit des tests ou non, préfère surveiller plutôt que tester, ou encore préfère la rapidité de livraison plutôt que la qualité, ou le contraire. Tous ces éléments ont de la valeur, et sont importants à connaître avant d’intégrer l’entreprise.

J’ai ajouté une icône de drapeau à côté de certaines questions : ⚑. Les réponses à ces questions peuvent, à mon avis, être rédhibitoires : selon leur réponse, je pourrai décider de refuser de travailler avec eux.

Vous pouvez évidemment poser vos propres questions en fonction de ce qui est le plus important pour vous. Vous avez certainement vos propres « drapeaux » en fonction de ce que vous cherchez. Cette méthode fonctionne très bien pour moi, mais vous pouvez l’adapter autant que vous le souhaitez.

Voici donc une liste de questions que je pose habituellement, organisées par grands thèmes.

Méthodes de travail et produit

Comment êtes-vous organisés ? Quelle méthode de travail utilisez-vous ? Pouvez-vous décrire un jour ou une semaine de travail de l’équipe ?

Comment est constitué l’équipe ? Combien de personnes ? Sur quels postes ?

Quelles technologies (stacks) utilisez-vous ? Comment avez vous choisi celles-ci parmi ses équivalents (concurrents) ?
Ici, je m’attends à ce que mon interlocuteur réponde quelque chose de raisonnable, réfléchi. Par exemple : « nous avons choisi cette techno parce que nous la connaissions déjà bien / nous l’avons déjà utilisé et elle fonctionne / nous l’avons soigneusement comparée aux autres et elle répond à notre besoin ». Si il répond « parce que c’est à la mode en ce moment/c’est ce que tout le monde utilise », c’est un drapeau ⚑.

Dans le cas où il répond : « on utilise les dernières technos » – Que signifie « dernière techno » et quels sont les avantages de procéder ainsi ?

Comment décririez-vous la qualité de votre produit ? ⚑
Une fois on m’a répondu : « notre code est parfait parce que j’ai l’ai écrit » ! C’est bien d’avoir confiance en soi, mais c’est aussi révélateur de la nature du travail d’équipe dans l’entreprise.

Faites-vous des revues de code ?
Oui je sais, c’est une question fermée. Mais si le sujet n’a pas été abordé dans la discussion sur la qualité du code, il est judicieux de la poser directement.

Comment gérez-vous la dette technique ?

Privilégiez-vous la vitesse de développement par rapport à la qualité ou l’inverse ? ⚑
Bien sûr, cela dépend de ce que vous attendez de l’entreprise. Si vous aimez le prototypage rapide vous vous attendrez à ce qu’ils fassent de même. Si vous êtes plutôt du genre la-qualité-avant-tout, vous attendrez une réponse différente.

Comment vous assurez-vous que votre produit fonctionne comme attendu ?
Comprenez : Comment testez-vous ? Comment surveillez-vous votre produit (monitoring, instrumentation) ? Comment communiquez-vous avec les clients ? Comment préparez-vous le développement des fonctionnalités ?

Quel est votre processus de livraison (release process) ?

Sur quel produit vais-je travailler ?
Plus de questions auto-centrées sont à la fin de cet article.

Relations client

Qui sont vos clients ?

Comment communiquez-vous avec vos clients ? Qui fait cela ? Comment collectez-vous leurs besoins, leurs retours ? ⚑
L’entreprise doit avoir des clients, ou au moins l’objectif d’en avoir. Autrement vous risquez de travailler sur quelque chose que personne ne va utiliser.

Comment donnez-vous des priorités aux tâches ?

Comment traitez-vous les retours et les demandes client ?
Ils doivent écouter les clients ! Ils doivent se battre pour satisfaire leurs clients ! Ils ne doivent pas uniquement considérer leur argent ou à l’inverse ne leur parler que technique. Si ils sont irrespectueux envers eux, c’est un drapeau ⚑ : votre interlocuteur n’est peut être pas si mature.

L’entreprise

Quelles sont les valeurs de l’entreprise ?

Comment définissez-vous et mesurez-vous le succès ?
Ils doivent l’avoir défini non ? Sinon comment peuvent-ils savoir qu’ils sont sur la bonne voie ?

Quels sont vos plans à long terme ?

Rétrospectivement, quelles erreurs avez-vous fait en tant qu’entreprise/département/équipe ? Qu’en avez-vous appris ?
Cette question peut sembler intrusive, mais vous apprendrez beaucoup sur l’entreprise et votre interlocuteur. Cela a encore plus de valeur si vous allez travailler avec votre interviewer, ou devrez lui rendre des comptes.

Comment vous assurez-vous, en tant qu’entreprise ou équipe, de travailler sur les bons sujets ?

Qui prend les décisions business ? ⚑

Qui prend les décisions techniques ? ⚑
Ce qui peut aussi être formulé : si un autre développeur et moi sommes en désaccord sur une implémentation quelconque, que va-t-il se passer ?

Ces questions de prise de décisions prennent de plus en plus d’importance à mesure que votre carrière avance. En tant que chef d’équipe, vous ne souhaiteriez probablement pas vous retrouver sans pouvoir de décision – pour quelles raisons vous embaucheraient-ils dans ce cas ?
Plus généralement, si toutes les décisions sont prises par une seule personne, ce n’est probablement pas une bonne chose. À l’inverse, si toutes les décisions sont prise collectivement, que se passe-t-il quand certains sont en désaccord ? Mieux vaut éclaircir le sujet.

L’humain

Décrivez la diversité de votre équipe ? Avez-vous des engagements concernant la diversité ? ⚑
Si votre interlocuteur n’a aucune idée de ce dont vous parlez, c’est un très mauvais signe en ce qui me concerne !
Posez cette question même si vous faites partie de la majorité. Vous aiderez les minorités en le faisant. Cela devrait aider les entreprises à aller dans la bonne direction. Une équipe équilibrée est au bénéfice de tous : le business, l’équipe, les majorités et les minorités.

Quel est l’équilibre travail/vie personnelle ? ⚑
Les employés font-ils des heures supplémentaires ? Souvent ? Pour quelles raisons ? Est-ce rémunéré ?
À travers ces réponses, recherchez une culture toxique ! Le « Nous sommes une grande famille » peut sembler attirant, mais en réalité vous avez déjà une famille, des loisirs, et d’autres engagements en dehors du travail. Ne les abandonnez pas juste pour un poste.

Comment les gens travaillent-ils en équipe ? Sur des postes équivalents (c.à.d. entre développeurs) ou sur des postes différents (c.à.d. entre développeurs et QA) ?
Je préfère les entreprises dans lesquelles poser des questions est encouragé, non répréhensible. Je pense également que le travail d’équipe créé un environnement plus sain : lorsqu’il est possible de discuter librement de tâches complexes avec quelqu’un, on avance bien plus vite. D’une manière générale, deux têtes valent mieux qu’une. D’un autre côté, si les réunions et les discussions sont trop nombreuses, cela pourrait être contre-productif.

Comment accompagnez-vous les débutants ?
Parfois ils n’ont pas de jeunes développeurs du tout – ce qui n’est pas très bon signe. Investir dans les jeunes et les aider à acquérir des compétences bénéficie à tout le monde : les séniors acquièrent des compétences d’accompagnement et transmettent la connaissance (ce qui réduit les goulots d’étranglement); les juniors apprenant beaucoup plus vite des compétences spécifiques.

Si je suis en désaccord avec quelqu’un ou que je suis harcelée de quelque manière que ce soit, que suis-je censée faire ? ⚑
C’est une questions particulièrement intéressante, surtout si votre interlocuteur est voué à être votre manager direct. Vous êtes alors en droit d’attendre un niveau de maturité élevé de leur part. Ils doivent être capable de comprendre qu’il y a un conflit, écouter toutes les parties et faire de leur mieux pour le résoudre.

Encouragez-vous la compétition interne ? ⚑
Ou si ils disent « nous aimons les défis/la compétition », qu’est-ce que cela signifie ?
Essayez de creuser le sujet : est-ce une concurrence saine, basée sur le respect et dans l’objectif de l’amélioration du produit et du process ? Quelques exemples seraient : « c’est ce qu’il y a de mieux pour l’équipe à l’instant t », « c’est ce que veulent nos clients », « comment pouvons nous améliorer le process ».
Peut être qu’ils ne parlent que de compétition technique : « comment améliore-t-on le passage à l’échelle », ou « comment améliorer les performances sur smartphones ».
Mais parfois « défis/concurrence » peut signifier que l’on va en permanence remettre en question votre professionnalisme ou vous mettre en défaut. « Ton code est pourri » ou « tes designs sont moches » sont des exemples typiques.

Comment gérez-vous le regard critique ?
Dans certaines entreprises, il est interdit de remettre en question les pratiques. D’autres sont pleines de personnes qui passent leur temps à se plaindre. Il doit y avoir un équilibre sain entre les deux.

À propos de votre interlocuteur

Dans quelle équipe et sur quel produit travaillez-vous ?

Aimez-vous travailler ici ?
Bien sûr, vous ne pouvez pas vous attendre à ce qu’il réponde qu’il déteste travailler ici et attend juste une autre opportunité pour partir. Mais vous pourrez peut-être voir une lueur dans leurs yeux si ils aiment ce qu’ils font.

Quelle est le dernier défi ou la chose la plus intéressante que vous ayez fait dans les 3 derniers mois ? ⚑
Ils vous ont probablement posé cette question, maintenant c’est votre tour. Regardez attentivement ce qu’ils considèrent comme intéressant.

Sur quel sujet souhaiteriez vous que l’entreprise consacre plus du temps ?
Voyez si ils mentionnent les technos, le produit ou les gens. Vous pourrez ainsi poser des questions sur les éléments manquants.

À propos de moi

Sur quoi vais-je travailler ?
Certaines entreprises embauchent pour leur équipe – dans ce cas ils vous le diront. D’autres entreprises embauchent pour l’entreprise dans son ensemble – vous pourriez finir dans n’importe quelle équipe, sans expérience préalable ou sur des sujets qui ne vous intéresse pas.

Quel niveau d’autonomie vais-je bénéficier ? Quelles décisions puis-je prendre ?
Encore une fois, plus vous avez de l’expérience, plus cette question est importante.

Qu’attendez-vous de moi dans les trois prochains mois ? L’année qui vient ?
Cette question montre si l’entreprise est prête à embaucher. Elle doit savoir ce qu’elle va faire faire à ses nouveaux recrutés. Ont-ils prévu un plan ? Une liste de responsabilités ? Vous saurez également si ils embauchent juste pour grossir et avoir l’air plus intéressant au prés des investisseurs.

Comment évaluez-vous les performances ? Mes performances ?

Qui sera mon manager ?
La réponse peut être très intéressante. Par exemple, une fois un directeur technique (CTO) qui m’interviewais m’a répondu que mon manager serait le président (CEO) de l’entreprise. Suite à cela j’ai eu beaucoup de questions à poser sur ce que faisait le dit CTO. Il est apparu qu’il n’avait pas vraiment d’autres responsabilités que celles d’un développeur standard, et qu’ils prenaient leurs décisions sur la base du code écrit et pas toujours en fonction du business. À mon sens, ils étaient trop junior pour être CTO.

Quelles sont mes perspectives professionnelles ? De carrière et d’avancement ?

Quel est la fourchette de salaire pour ce poste ? Les bonus ? Stock-options ? Congés ? Etc.
Cette question peut paraitre la plus importante. Et peut être qu’elle l’est. Mais ce sur quoi vous allez travailler, les gens avec qui vous allez travailler doivent aussi être pris en compte.

L’importance de poser les bonnes questions

Poser les bonnes questions vous aidera à prendre la bonne décision.

En premier lieu, elles vous montreront si c’est vraiment l’entreprise pour laquelle vous avez envie de travailler. Par exemple, une grosse entreprise qui n’accorde aucune importance à la diversité ou la résolution de conflits véhicule probablement une atmosphère toxique. Si ils n’accordent de l’importance qu’à la vitesse de livraison et n’ont aucun contrôle sur la qualité, vous en saurez plus sur le produit, la base de code et le management.
Bien sûr, vous êtes les plus à mène de savoir pour quelle entreprise vous voulez travailler. À vous de créer votre ensemble de questions et évaluer les entreprises sur ce qui compte le plus.

Ensuite, poser des questions leur montrera que vous êtes un professionnel qui n’est pas prêt à accepter n’importe quelle offre. Ils verront en vous une personne qui accorde de la valeur au temps qu’elle consacre.

Enfin, cela montrera que vous êtes intéressé par l’entretien et le poste. Une fois j’ai interviewé une personne qui n’avait qu’une seule question : si je connaissais la meilleure période pour visiter le musée de la maison d’Anne Frank (Je ne sais pas d’ailleurs, désolée – c’est toujours bondé). Après l’ensemble des entretiens, nous nous sommes rendu compte que le candidat avait posé la même question à tous les intervenants. Inutile de mentionner que le candidat n’était pas plus intéressé par le poste que par un voyage gratuit à Amsterdam.

Posez autant de questions que vous le pouvez. Plus vous aurez d’information, meilleure sera votre prise de décision.

Bonne chance pour votre prochain entretien !