Catégorie : Développement informatique

  • Le métier de déve­lop­peur infor­ma­tique

    — Tim. (@TimDL1992) 16 Mai 2015

    Et cette blague est exac­te­ment pourquoi le travail d’un déve­lop­peur est complexe. Son rôle c’est de tout prévoir, tout en reti­rant tout contexte, toute inter­pré­ta­tion, tout intel­li­gence.

    La phrase la plus proche du métier selon moi c’est celle qui dit « L’in­gé­nieur en pont doit comprendre les enjeux du pont et en faire certains calculs, puis diri­ger des gens du métier pour qu’ils construisent ce pont. L’in­gé­nieur en infor­ma­tique doit non seule­ment savoir construire lui-même ce pont dans les moindres détails, depuis l’ex­trac­tion du mine­rai de fer jusqu’à la pose du revê­te­ment qui permet­tra de rouler dessus, parfois en passant par la construc­tion de l’ap­pa­reil qui extrait le mine­rai de fer lui-même, mais en plus il doit savoir expliquer cela pour le faire faire à des auto­mates qui exécu­te­ront pas à pas chaque instruc­tion avec moins d’in­tel­li­gence et moins d’ini­tia­tive person­nelle qu’un enfant de 3 ans avec un lourd retard mental« . C’est certes cari­ca­tu­ral (donc faux) mais ça donne l’idée.

  • Que faire de Gemfile.lock et compo­ser.lock

    L’objec­tif du Gemfile c’est de dire « le projet a besoin de la biblio­thèque X en version 4.5 mini­mum, et de la biblio­thèque Y en version 1.3 à 1.5 ». L’objec­tif du Gemfile.lock c’est de dire « ici on a X en 4.5.6 et Y en 1.3.8, c’est cet ensemble précis qui est testé et mis en produc­tion ».

    J’ai encore vu passer la ques­tion il y a quelques jours

    Le Gemfile.lock, c’est quoi la bonne pratique, je le pousse sur le git ?

    Et la réponse clas­sique « Oui, pour s’as­su­rer que la produc­tion soit en phase avec les versions que tu as testé », avec parfois quelqu’un qui ajoute « sauf pour les paquets gem / compo­ser, où là il ne faut pas le pous­ser dans le dépôt git ».

    Sauf qu’en fait c’est plus complexe, et ce n’est pas une problé­ma­tique tech­nique. C’est une ques­tion d’or­ga­ni­sa­tion :

    Qui fait la main­te­nance appli­ca­tive ? Qui suit les mises à jour de sécu­rité au jour le jour ? Qui est dispo­nible en astreinte en cas de besoin ? Avez-vous une procé­dure de test auto­ma­tisé suffi­sam­ment fiable ? Quelle est la poli­tique de numé­ro­ta­tion de vos dépen­dances ?

    Plus exac­te­ment, le Gemfile.lock et le compo­ser.lock doivent être maitri­sés par l’équipe qui gère la main­te­nance de sécu­rité.

    Équipe de déve­lop­pe­ment

    Ce peut être l’équipe de déve­lop­pe­ment. Dans ce cas c’est à elle de pous­ser le .lock sur son outil de version­ne­ment, de le mettre à jour et de déclen­cher un déploie­ment en cas de besoin.

    Atten­tion : Dire « je pousse les .lock dans le git », c’est dire, « personne d’autre que moi ne doit y toucher ». C’est parfois présomp­tueux, mais ça veut aussi dire être respon­sable de la mise à jour, y compris quand on n’en n’a pas envie.

    Ça veut dire surveiller en perma­nence le besoin de mettre à jour une des dépen­dances pour des raisons de sécu­rité. Ça veut dire une veille active sur le sujet, du temps dédié à ça, et des outils ou proces­sus bien défi­nis. Très peu d’équipes de dev ont ça.

    Est-ce le rôle de votre équipe de dev ? en a-t-elle les moyens ? le temps ? l’au­to­no­mie ?

    Équipe de produc­tion

    À l’in­verse ça peut être à l’équipe de produc­tion de gérer ces arte­facts. Dans ce cas c’est à cette dernière de pous­ser les .lock sur leur propre version­ne­ment, avec le reste des confi­gu­ra­tions. Eux ont des proces­sus établis pour faire les veilles de sécu­rité, des astreintes en cas de mise à jour en urgence, etc.

    En échange ça veut dire que les dépen­dances sont spéci­fiées très sérieu­se­ment et plus préci­sé­ment dans le Gemfile. Parfois dire « je veux la version 4.5.* » et pas unique­ment « je veux une version 4 ou supé­rieure ». Pous­ser le Gemfile.lock sur le git de l’équipe de déve­lop­pe­ment peut aussi être un indi­ca­teur que le Gemfile d’ori­gine est géré avec légè­reté au départ.

    L’équipe de produc­tion se basera sur ces défi­ni­tions précises, sur les notes de mises à jour des dépen­dances, puis mettra à jour le code et le Gemfile.lock en fonc­tion. Elle fera ensuite passer les tests auto­ma­ti­sés, peut être une équipe de QA. À la fin elle pren­dra – ou non – la respon­sa­bi­lité de déployer en produc­tion la mise à jour sans passer par l’équipe de déve­lop­pe­ment, en fonc­tion de l’ur­gence et du risque. Ça impose donc aussi des tests auto­ma­ti­sés suffi­sam­ment solides pour se baser dessus lors d’une mise à jour mineure.

    Dans une grosse struc­ture, ou avec une équipe de produc­tion dédiée de qualité, c’est proba­ble­ment une des meilleures options. Mais… votre équipe de produc­tion est-elle compé­tente sur ces sujets ? a-t-elle l’au­to­no­mie suffi­sante pour cela ? le code, le Gemfile et les tests auto­ma­ti­sés sont-ils suffi­sa­ment à niveau ?

  • HTTP2 for front-end web deve­lo­pers

    To get websites to load in an accep­table time using HTTP1 we have deve­lo­ped a series of tech­niques; hacks really; to eke perfor­mance out of this old proto­col. They are:

    • Spri­ting: taking multiple images, combi­ning them into one image, and using CSS to only show part of that image in a parti­cu­lar place.
    • Conca­te­na­ting: Taking multiple CSS or JS files and sticking them into one large file.
    • Serving assets from a cookie-less domain.
    • Shar­ding: crea­ting different domains or sub-domains to host assets like images.

    Avec l’ar­ri­vée de HTTP 2, ces quatre opti­mi­sa­tions tendent à deve­nir inutiles, voire contre produc­tives.

    Pour les deux premières, le pipe­li­ning devient plus intel­li­gent (donc réel­le­ment utili­sable) et au besoin le serveur peut pous­ser les conte­nus sans même attendre qu’ils soient deman­dés par le client.

    Pour les deux suivantes, le système de compres­sion des entêtes et de multi­plexage rend le retour sur inves­tis­se­ment d’une nouvelle connexion TCP à un domaine tiers fran­che­ment contes­table. Vous risquez de perdre de la perfor­mance au lieu d’en gagner.

    La leçon est inté­res­sante. Pendant quelques années les déve­lop­peurs ont cher­ché à contour­ner les navi­ga­teurs, croyant pouvoir être plus smart. Le problème c’est que les navi­ga­teurs et les proto­coles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des déve­lop­peurs peuvent désor­mais faire plus de mal que de bien. C’est toute une litté­ra­ture qu’il va falloir mettre à jour.

  • Et que fait-on des esti­ma­tions ?

    Quelle est votre stra­té­gie agile ?

    • Le plus stra­té­gique en premier ?
    • Ce qui est tech­nique­ment plus complexe en premier ?
    • Ce qui est le plus risqué en premier ?
    • Ce qui se voit en premier ?
    • Ce qui est le plus simple en premier ?
    • Ce qui apporte le meilleur retour sur inves­tis­se­ment en premier ?

    Il n’y a pas de bonne ou de mauvaise réponse. C’est unique­ment une histoire de stra­té­gie. L’im­por­tant est d’être cohé­rent sur une période pour mettre en œuvre cette stra­té­gie et de ne pas faire un peu de tout à la fois.

    Inté­res­sant de noter tout de même que sauf ordre de gran­deur extra­or­di­naire (donc facile à iden­ti­fier sans être bon en esti­ma­tion), seule les deux dernières stra­té­gies ont réel­le­ment besoin d’es­ti­ma­tion avant réali­sa­tion.

  • Toute l’es­time que je vous porte

    Toute l’es­time que je vous porte

    Comme beau­coup d’in­gé­nieurs, je suis réti­cent à donner des esti­ma­tions.

    je ne sais pas esti­mer

    Tous les jours, je résous des problèmes nouveaux, pour lesquels je n’ai encore jamais implé­menté de solu­tion.

    Si vous n’avez jamais fait d’in­for­ma­tique, mettez-vous bien ça dans la tête : Contrai­re­ment au maçon qui peut construire des dizaines de maisons, l’in­for­ma­ti­cien ne fait jamais deux fois la même chose. Il peut réuti­li­ser la solu­tion précé­dente à l’in­fini, en quelques heures. Qu’un déve­lop­peur fasse deux fois exac­te­ment la même chose est le symp­tôme d’un problème d’or­ga­ni­sa­tion.

    Si je passe plus de quelques heures, c’est qu’il y a un problème nouveau ou quelque chose de nouveau dans le problème, même si de haut il ressemble à un autre. Mon travail c’est unique­ment de créer ce qui manque, ce qui est nouveau par rapport à d’éven­tuelles solu­tions précé­dentes.

    Et pour ce nouveau, je vais devoir étudier le problème posé, proba­ble­ment décou­vrir des sous-problèmes qu’on n’ima­gi­nait pas. Je ne sais pas ce quelles diffi­cul­tés je vais rencon­trer, quelles solu­tions vont devoir être appliquées, comment les mettre en œuvre, si elles vont réus­sir ou échouer, et encore moins si le besoin racine va effec­ti­ve­ment être couvert à la fin de tout cela.

    Il y a plein de textes qui expliquent la problé­ma­tique de l’es­ti­ma­tion mais j’ai trouvé plus d’une fois que le récit de voyage de Michael Wolfe illustre très bien les enjeux avec une analo­gie que tout le monde comprend.

    vous non plus

    J’ai croisé de nombreuses personnes qui annonçaient savoir esti­mer assez correc­te­ment, et quelques unes qui semblaient effec­ti­ve­ment le faire. Vous en connais­sez peut-être aussi.

    En pratique à chaque fois qu’on y regarde de plus près, l’es­ti­ma­tion n’est pas plus juste qu’une autre. Au mieux on compense les mauvaises esti­ma­tions en jouant sur le contexte. L’es­ti­ma­tion est poten­tiel­le­ment respec­tée, mais elle n’en est pas plus juste. Et quand compen­ser ne suffit pas, on se rassure en consi­dé­rant que ça ne compte pas parce que c’est excep­tion­nel, qu’il y a une cause exté­rieure, ou en repor­tant la faute sur un tiers.

    Même les itéra­tions de la tant aimée métho­do­lo­gie SCRUM jouent sur le même registre : Donner une cible avec un enga­ge­ment permet d’avoir un peu de pres­sion sur l’équipe. C’est de la pres­sion dite « posi­tive », pour avoir envie d’at­teindre l’objec­tif.

    Au final c’est de la pres­sion tout de même, qui souvent se retrouve sur l’am­pli­tude horaire ou sur la fatigue. Quand le mana­ge­ment n’a pas une atten­tion et une culture extrê­me­ment forte sur le sujet, ça joue aussi sur une baisse de qualité ou une créa­tion de dette tech­nique. C’est humain. À défaut c’est le péri­mètre qui bouge, mais l’es­ti­ma­tion n’en est pas meilleure. Bref, on pallie la mauvaise esti­ma­tion en jouant sur le contexte.

    Si vrai­ment quelqu’un estime toujours juste à plus de 90%, sans compen­ser sur le contexte, c’est qu’il est en train de passer du temps à refaire ce qu’il a déjà fait. S’il travaille pour vous : virez-le et embau­chez quelqu’un qui saura réuti­li­ser plutôt que perdre du temps.

    même par petits lots

    Même l’es­ti­ma­tion par petits lots itéra­tifs n’est qu’une illu­sion. On estime effec­ti­ve­ment mieux des petites tâches qu’on sait perce­voir, mais c’est unique­ment parce qu’on réflé­chit déjà à la problé­ma­tique et à sa solu­tion au moment de donner l’es­ti­ma­tion.

    Par la suite on se trompe autant qu’ailleurs. On compense là aussi par l’am­pli­tude horaire, le stress de la pres­sion person­nelle, la qualité ou la dette tech­nique. C’est juste que plus la tâche est petite, plus le déca­lage probable est petit et donc moins il se voit de l’ex­té­rieur quand on regarde unitai­re­ment.

    Vous avez déjà remarqué qu’on ne fait pas tenir 8 tâches d’une heure dans une jour­née ou 5 tâches d’une jour­née dans une semaine ? Des tâches d’une heure dans une jour­née, prévoyez-en 6, moins le temps pour les réunions.

    Et des fois on a juste oublié un cas d’usage ou manqué une problé­ma­tique. Sur un lot impor­tant on aurait assumé et dérapé un peu. Sur une petite tâche le cas manqué peut prendre plusieurs fois l’es­ti­ma­tion de la tâche initiale. On en fait donc une nouvelle tâche, avec sa propre esti­ma­tion. Là aussi, l’ex­cuse du cas excep­tion­nel ou de la sortie de péri­mètre permet d’évi­ter de remettre en cause ses esti­ma­tions.

    Alors oui, les esti­ma­tions sur des petits lots ont tendance à être plus souvent respec­tées mais elles n’en sont pas beau­coup plus justes. Tout ceci n’est qu’œillères et illu­sions.

    C’est mieux – et c’est logique vu qu’on estime au fur et à mesure du projet, une fois la connais­sance acquise – mais ce n’est toujours pas bon.

    la mauvaise ques­tion

    On peut discu­ter de l’uti­lité des esti­ma­tions, de la capa­cité du genre humain à savoir donner des esti­ma­tions abso­lues. On peu aussi s’en­fon­cer dans un projet d’op­po­si­tion, scan­der #noes­ti­ma­te… mais qu’ap­por­te­rait-on comme valeur ?

    Je suis surtout agacé qu’on se pose surtout la mauvaise ques­tion. Au jour le jour je n’ai aucu­ne­ment besoin d’es­ti­mer. J’ai besoin d’ap­por­ter de la valeur. La seule ques­tion à me poser est « qu’est-ce qui amènera à priori le plus de valeur demain si je le fais aujourd’­hui ? » et mettre mes ressources dessus.

    La ques­tion n’est pas simple pour autant. J’ai besoin d’éva­luer si le niveau d’ef­fort à four­nir est rentable par rapport à la valeur ajou­tée atten­due. Ensuite j’ai besoin de prio­ri­ser les évolu­tions entre elles, en fonc­tion de la valeur et du niveau d’ef­fort.

    Sauf que juste­ment, je n’ai besoin pour ces usages que d’un ordre de gran­deur : Est-ce 10, 100 ou 1000 ? Est-ce beau­coup plus ou beau­coup moins que l’autre évolu­tion à laquelle je pense ? Tout autre détail est aussi utile qu’un para­chute pour monter sur une échelle.

    L’éva­lua­tion de la valeur atten­due subit de toutes façons les mêmes incer­ti­tudes que le niveau d’ef­fort à four­nir. Même s’il est fait à base d’une page pleine de formules, calcul de la valeur atten­due dépend parfois tota­le­ment de para­mètres esti­més au doigt mouillé, où même un ordre de gran­deur relève plus de la convic­tion que de l’es­ti­ma­tion.

    le mauvais usage

    Vous posez-vous vrai­ment la bonne ques­tion ?

    En cher­chant à savoir si votre projet dérape vous êtes simple­ment en train de regar­der s’il se conforme au plan prévu, à son esti­ma­tion. Véri­fier la vali­dité d’une esti­ma­tion ne vous appor­tera aucune valeur, surtout quand on sait dès le départ qu’elle est soumise à des aléas impré­vi­sibles.

    Pire, en impo­sant l’es­ti­ma­tion préa­lable comme indi­ca­teur, on freine l’ini­tia­tive (si je le fais, on prend un risque, même si je sais qu’il faut le faire), on freine la capa­cité de chan­ger (si on le fait, il faut recal­cu­ler le plan, re-esti­mer, négo­cier cette esti­ma­tion, expliquer le mauvais indi­ca­teur, ça ne vaut pas le coût ici, tant pis), et on oublie notre objec­tif (l’in­di­ca­teur est bon, tant pis si en fait on s’est rendu compte que ça ne créait pas la valeur atten­due et qu’il aurait fallu faire autre chose, ça aurait remis en cause le plan).

    Vous pouvez vous dire que vous saurez déjouer tout cela, rester agile et prag­ma­tique. Vous vous mentez, du moins tant que votre ques­tion sera « où est-ce qu’on en est par rapport aux esti­ma­tions ? ».

    C’est encore pire si vous utili­sez l’es­ti­ma­tion comme métrique pour appré­cier l’ef­fi­ca­cité ou la compé­tence de l’équipe de produc­tion. Là non seule­ment vous compa­rez juste des choux et des carottes, mais en plus vous inver­sez votre résul­tat : Ce sont des équipes qui respectent toutes leurs esti­ma­tions que vous devriez avoir peur. Elles masquent leurs erreurs en les compen­sant, volon­tai­re­ment ou non, et ça faus­sera toutes vos analyses sur la produc­tion passée ou future.

    arrê­ter de navi­guer dans le passé

    Les méthodes agiles vont dans le bon sens mais il est trop facile de s’ar­rê­ter aux arte­facts sans en comprendre l’objec­tif. Le prin­cipe n’est pas que de décou­per en petits lots plus faciles à esti­mer pour pouvoir reprendre une déci­sion entre les diffé­rents lots.

    Il y a aussi une philo­so­phie derrière, celle de l’ap­port de valeur.

    Seul le présent créé de la valeur. La stra­té­gie envi­sage le futur, les rétros­pec­tives tirent les leçons du passé. Si vous n’êtes ni dans un contexte de choix stra­té­gique ni en train de tirer des leçons en rétros­pec­tive, vous ne devez que vous préoc­cu­per de la meilleure façon d’ap­por­ter de la valeur là, main­te­nant, tout de suite, peu importe ce que vous aviez pu prévu ou estimé par le passé.

    Que dois-je faire aujourd’­hui et main­te­nant pour appor­ter le plus de valeur ?

    La perti­nence de l’es­ti­ma­tion passée ne m’est jamais d’au­cune utilité pour répondre à cette ques­tion. J’in­siste : Jamais. Je prends en compte les diffi­cul­tés et faci­li­tés dans des rétros­pec­tives pour m’amé­lio­rer. Je les prends en compte pour évaluer l’ef­fort à four­nir sur le reste à faire, et donc l’op­por­tu­nité de conti­nuer. Que ces faci­li­tés ou diffi­cul­tés aient été prévues ou non, que j’ai divisé par 2 ou multi­plié par 20 mon esti­ma­tion n’im­porte fina­le­ment aucu­ne­ment.

    Esti­mez, c’est utile, impor­tant. Ensuite oubliez-les et surtout ne les réuti­li­sez pas pour autre chose.

    (sur le même sujet We don’t need no stin­king esti­mates)

    Photo d’en­tête sous licence CC BY-NC-SA par Mark Notari

  • S’oc­cu­per de l’ave­nir et pas du passé

    Pour faci­li­ter les esti­ma­tions l’état de l’art est de travailler par compa­rai­son. On prend la tâche la plus simi­laire réali­sée par le passé et on estime si la nouvelle va rele­ver du même effort, un peu plus ou un peu moins, en fonc­tion des diffi­cul­tés atten­dues.

    Les esti­ma­tions s’amé­liorent vrai­sem­bla­ble­ment avec l’ex­pé­rience, tant parce qu’on a plus de chances d’avoir une réfé­rence simi­laire, que parce qu’on a déjà traversé beau­coup de problé­ma­tiques et qu’on risque moins d’en oublier une.

    Pour que cela fonc­tionne au mieux il faut savoir reve­nir sur ce qui a été réalisé : Iden­ti­fier les diffi­cul­tés, les faci­li­tés, les impré­vus passés. Cher­cher comment on pourra les résoudre mieux ou les iden­ti­fier plus tôt.

    Le dernier verbe conju­gué est au futur.

    Je cherche comment on pourra résoudre les diffi­cul­tés ou impré­vus, pas comment on aurait pu les résoudre. La diffé­rence est de taille. Le passé ne m’in­té­resse pas en soi, c’est trop tard. C’est le futur qui m’in­té­resse.

    Ça peut semble une ques­tion de voca­bu­laire mais ça ne l’est pas. Parfois la réponse est la même, mais pas toujours :

    Imagi­nons qu’une tâche a tota­le­ment dérapé à cause d’une problé­ma­tique majeure qui n’avait pas été prévue. Pour finir la tâche on a du résoudre la problé­ma­tique, elle ne bloquera donc plus jamais. Une démarche qui aurait pu permettre d’iden­ti­fier ce problème en amont ne m’in­té­resse pas, vu que juste­ment ce problème n’exis­tera plus à l’ave­nir. Je suis poten­tiel­le­ment inté­ressé par une démarche qui permet­trait d’iden­ti­fier les autres futurs problèmes qui ne ressemblent pas à celui passé et qui nous sont incon­nus aujourd’­hui. Si on trouve cette perle rare trouve alors on l’adopte, mais sinon on s’épargne du temps et on passe à autre chose.

    Une prévi­sion passée n’est qu’une vision d’un autre présent, peu utile pour prépa­rer l’ave­nir

    Dans la boucle d’ap­pren­tis­sage, je m’in­té­resse au temps passé, aux diffi­cul­tés rencon­trées, aux faci­li­tés que je pour­rais avoir, et aux impré­vus qui sont surve­nus. Je m’y inté­resse car ils sont sources d’amé­lio­ra­tion, que l’es­ti­ma­tion de la tâche passée ait été juste ou ait été fausse.

    En fait savoir quelle était l’es­ti­ma­tion passée et si elle a été respec­tée ne m’est d’au­cune utilité pour m’amé­lio­rer. Si j’ai eu un imprévu, alors que l’ana­ly­se­rai, même si fina­le­ment j’ai eu assez de temps pour le gérer. En fait je l’ana­ly­se­rai même surtout si j’ai eu assez de temps pour le gérer, parce que ça veut dire que j’ai eu une faci­lité par ailleurs qui mérite elle aussi d’être analy­sée.

    Inver­se­ment, si je n’ai eu aucune diffi­culté signi­fi­ca­tive, aucun imprévu ni aucune spéci­fi­cité remarquable, il est probable que je me serve du temps passé sur ma tâche comme réfé­rence pour la suivante simi­laire. Avais-je réussi ou échoué à mon esti­ma­tion la dernière fois ? Peu importe : Main­te­nant j’ai appris et je peux me servir d’un cas concret comme base de réfé­rence. L’es­ti­ma­tion passée n’entre pas en ligne de compte, et encore moins si elle était mauvaise.

    L’es­ti­ma­tion ne sert qu’à déci­der de l’ave­nir. Une fois qu’elle est passée, elle est aussi inté­res­sante qu’un bulle­tin d’ho­ro­scope de l’an­née dernière.

  • Bash­git prompt

    Je bave souvent devant les prompt de termi­nal qu’on voit sur le web mais une fois installé ça fait très gadget, plus gênant qu’autre chose.

    J’ai tout de même ajouté un peu de couleur, pour aider à repé­rer le début de chaque invite quand je remonte dans l’his­to­rique.

    gitprompt

    Reste que quelques indi­ca­teurs ça peut être utile dans un réper­toire git. J’ai tenté oh-my-git mais fina­le­ment je me suis fixé sur bash-git-prompt, avec quelques icônes simples à comprendre. Je regrette juste le nombre de couleurs trop élevé mais ça doit se confi­gu­rer.

  • Infor­ma­tions person­nelles pour les sites e-commerce

    J’ai­me­rai tant un site e-commerce qui ne me deman­de­rait pas de créer un compte pour faire un achat. Qu’il me soit obli­ga­toire de décli­ner nom et adresse pour par exemple ache­ter un livre en ligne… est plus que gênant

    Je regarde la super lampe déco, je clique sur « ache­ter », je saisis une éven­tuel­le­ment adresse de livrai­son, puis mon numéro de carte bancaire, je valide, et voilà !

    Je n’ai pas besoin de plus pour ache­ter mon pain à la boulan­ge­rie, un lit ou une armoire dans mon maga­sin de meuble, ou un livre à ma librai­rie. Tout ce qui vient en plus avant la fina­li­sa­tion de la commande me fera fuir.

    Parce qu’il y a parfois un besoin d’une rela­tion après vente, je peux comprendre qu’on me demande aussi un numéro de télé­phone ou un email, même si ce n’est pas stric­te­ment néces­saire. On pourra m’y envoyer un jeton d’ac­cès pour me relier à mes commandes ou m’au­then­ti­fier si besoin.

    Je ne vois aucune raison incon­tour­nable d’im­po­ser la saisie de plus d’in­for­ma­tions [en fait si, voir commen­taires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décli­ner mon iden­tité.

    Rien n’em­pêche de propo­ser la saisie de bien plus d’in­for­ma­tions, mais après la commande, et de façon tota­le­ment option­nelle.

  • Pagi­na­tion sans limit ni offset

    TL;DR: La pagi­na­tion c’est bien™, le faire avec des para­mètres limit/offset c’est mal™.

    C’est très simple à expliquer : Si les données sont mises à jour entre deux requêtes d’une même pagi­na­tion, au mieux vous manquez des données et en visua­li­sez d’autres en double, au pire vous corrom­pez tous vos calculs.

    Hyper­me­dia

    La solu­tion magique c’est que vos API retournent un nombre limité de résul­tats avec des liens dans les entêtes, proba­ble­ment un rel=next pour les données suivantes et/ou un rel=prev pour les données précé­dentes. Le client n’a qu’à suivre les liens.

    En pratique

    OK, je triche parce que je n’ex­plique rien, alors je vais prendre un exemple : Un hypo­thé­tique client Twit­ter sur une hypo­thé­tique API Twit­ter (je m’au­to­rise donc à ne pas préci­ser ce qui se fait sur les API actuelles).

    Lorsque Twit­ter vous retourne les 100 derniers tweets de votre time­line avec les iden­ti­fiants 3245 à 3566, il peut vous renvoyer deux liens dans les entêtes :

    • Un rel=last qui mène en fait vers l’exacte requête que vous avez faite mais avec en plus un para­mètre since_id=3566. Quand vous voudrez rafrai­chir votre time­line, il vous suffira de suivre le lien. Il vous retour­nera les nouveaux messages jusqu’au 3566 non compris, mais jamais ceux que vous avez déjà reçu.
    • Un rel=prev qui mène vers l’exacte même requête que vous avez faite, mais avec en plus un para­mètre max_id=3245. Quand vous voudrez aller cher­cher les messages plus anciens, il vous suffira de suivre le lien.

    Si vous suivez un rel=prev après avoir suivi un rel=last vous fini­rez avec un lien qui contient et un since_id et un max_id, vous assu­rant de combler les trous que vous avez dans votre time­line, sans jamais renvoyer un message en double ni en oublier.

    Si vous souhai­tez faire une synchro­ni­sa­tion complète, il suffit de stocker tous les liens rel=prev que vous rece­vez dans une liste, et d’al­ler les suivre un à un à la fréquence que vous souhai­tez. Vous pouvez avoir un autre fil d’exé­cu­tion en paral­lèle qui suit le rel=last de temps en temps (il n’y en aura qu’un seul à la fois, vous en aurez un nouveau à chaque fois que vous suivez le précé­dent).

    Bon, dans la vraie vie vous aurez géné­ra­le­ment un rel=next (messages juste suivants) plutôt qu’un rel=last (derniers messages), mais Twit­ter est parti­cu­liers : Ça va si vite qu’en géné­ral la prio­rité est d’avoir les derniers messages à date, quitte à géné­rer des trous dans la time­line qui seront comblés plus tard.

    Twit­ter est aussi facile parce qu’on trie toujours pas date, et que l’iden­ti­fiant unique de chaque message est toujours ordonné lui aussi. Ailleurs on utili­sera peut être la date de dernière modi­fi­ca­tion comme pivot pour gérer la pagi­na­tion. L’im­por­tant est que le critère de tri soit cohé­rent avec la donnée utili­sée comme pivot

     

  • Working with desi­gners

    Working with desi­gners

    J’ai lu récem­ment le Working with desi­gners, et ça me donne l’oc­ca­sion de publier une réflexion qui me trotte dans la tête depuis long­temps :

    Vous avez besoin d’un graphiste dans votre équipe.
    En interne, à demeure.

    Oui, on peut très bien faire un peu tout sans graphisme, et trou­ver un pres­ta­taire quand il s’agit quelques fois dans l’an­née de faire une charte, un design ou une illus­tra­tion. Vous manquez juste 80% de la valeur ajou­tée.

    En fait c’est plus large que ça. On peut tech­nique­ment avoir juste un CEO, qui achète des pres­ta­tions de déve­lop­pe­ment infor­ma­tique à une SSII, délègue le cahier des charges à un cabi­net d’as­sis­tance MOA, fait distri­buer la solu­tion par des vendeurs multi­cartes.

    Ça peut même fonc­tion­ner, dans de rares cas. Vous manquez juste la valeur qui est de réflé­chir au produit, de faire des évolu­tions perma­nentes et progres­sives, de lais­ser les gens s’ex­pri­mer, colla­bo­rer, avoir des initia­tives, appor­ter de la valeur, de l’ému­la­tion… On ne parle pas que de produc­tion sur le projet, mais de parti­ci­per et enri­chir la vie de l’en­tre­prise à tous les niveaux.

    * * *

    En régime de croi­sière, pour une boite techno web, vous aurez besoin d’un déve­lop­peur back, d’un déve­lop­peur front, d’un expert produit/métier, d’un graphiste, d’un commer­cial/marke­ting, d’une personne pour le support client, et d’une personne pour gérer l’ad­mi­nis­tra­tif.

    On peut bien entendu parler aussi d’un direc­teur des opéra­tions ou d’un sys admin, mais ils ne font pas autant parti du même coeur mini­mum pour moi.

    Chacune de ces sept personnes vous appor­tera quelque chose dans l’en­tre­prise,mettra de l’huile dans les rouages, même en dehors du projet lui-même.

    *

    Au départ il n’y a pas le choix, il faut porter plusieurs casquettes et faire quelques impasses. Par la suite vous avez tout inté­rêt à ce que les rôles soient poreux, que chacun soit incité à travaillé sur plus que sa petite case.

    Si par contre vous êtes une dizaine et que vous n’avez pas une personne diffé­rente qui joue le guide pour chacun des rôles, vous ne faites pas une écono­mie, vous vous ampu­tez d’une grosse valeur ajou­tée.

    *

    Votre boite n’est pas une boite techno web ? Dans ce cas vous pouvez peut être éviter d’avoir deux déve­lop­peurs distincts, mais il faudra au mini­mum les rempla­cer par un bidouilleur infor­ma­tique à tout faire (au sens noble, si vous croi­sez le terme anglais hacker, c’est de ça qu’on parle), qui devien­dra vite indis­pen­sable.

    Dans ce cadre, j’aime beau­coup la notion « hacker in resi­dence » et « desi­gner in resi­dence » de eFoun­ders. C’est la compré­hen­sion que même parta­gés entre plusieurs projets, pour faire émer­ger de la valeur il faut des gens impliqués à demeure, au milieu des équipes.

    Photo d’en­tête sous licence CC BY-SA par Axel Hart­mann