Carnet de notes

Catégorie : Développement informatique

  • Seriously, Don’t Use Icon Fonts

    So it’s really no wonder that icon fonts became such a hit. Icons displayed via @font-face were reso­lu­tion-inde­pendent and custo­mi­zable in all the ways we expec­ted text to be. Sure, deli­ve­ring icons as a type­face was defi­ni­tely a hack, but it was also useful, versa­tile, and maybe even a little fun.

    But now we need to stop. It’s time to let icon fonts pass on to Hack Heaven, where they can frolic with table-based layouts, Bullet-Proof Roun­ded Corners and Scalable Inman Flash Repla­ce­ments. Here’s why…

    — Cloud Four Blog

    On peut résumé par « utili­sez SVG » mais le fond est bien plus complet.

    L’ar­ticle lie aussi Bullet­proof Acces­sible Icon Fonts, où on se rend compte que tout est loin d’être simple si on veut faire les choses bien. Ce dernier lien devrait être la réfé­rence de ceux qui veulent quand même s’y essayer.

  • The Safe Navi­ga­tion Opera­tor (&.) in Ruby

    The most inter­es­ting addi­tion to Ruby 2.3.0 is the Safe Navi­ga­tion Opera­tor(&.). A simi­lar opera­tor has been present in C# and Groovy for a long time with a slightly different syntax – ?.. So what does it do?

    — Georgi Mitrev, via Pascal

    Ruby ayant déjà la possi­bi­lité d’avoir des ? dans le nom des méthodes, il n’y avait pas de syntaxe super classe. Les discus­sions que j’avais vu tour­naient autour de a.?b mais ça deve­nait moche si la méthode termi­nait déjà par ? : a.?b?.

    Au final nous aurons trois syntaxes :

    a && a.b && a.b.c
a.try(:b).try(:c)
a&.b&.c

    La première est ultra verbeuse et retour­nera false si a ou b retourne false. Sauf à ruser avec des variables tempo­raires, on finit par appe­ler a trois fois et b deux fois.

    La seconde méthode est plus sympa, mais longue assez moche à la lecture. Elle est aussi ultra tolé­rante et n’échouera pas même si rien ne retourne nil ou false mais que les méthodes b ou c n’existent pas.

    La dernière née est donc plus stricte. Elle ne sert que si a ou b retournent nil, et dans aucun autre cas. Restera à s’ha­bi­tuer à la syntaxe.

    Atten­tion, nil&.nil? retourne nil. L’opé­ra­teur & a donc la prio­rité sur ce qui suit. C’est logique, mais c’est un coup à se plan­ter si on en fait pas atten­tion.

    Sinon, spéci­fique­ment pour les Hash, même logique avec la méthode dig, là aussi bien­ve­nue :

    a[:b] && a[:b][:c] && a[:b][:c][:d]
a[:b].try(:[], :c).try(:[], :d)
a.fetch(:b, []).fetch(:c, []).fetch(:d, nil)
a.fetch(:b, nil)&.fetch(:c, nil)&.fetch(:d, nil)
a.dig(:b, :c, :d)

  • Micro­soft’s 16 Keys To Being Agile At Scale

    Every six months there are scena­rio reviews. The group reviews progress and examine where they want to go next. That gene­rally means a recas­ting of the scena­rios. There are three ques­tions: what have we lear­ned over the last six months based on what we built? What do our custo­mers tell us? And what’s chan­ged in the market­place? It’s both plan­ning and lear­ning.

    Every team has the autho­rity to make changes. If the team sees some­thing that was missed, they don’t have to ask permis­sion to make a change. They just keep the leader­ship team infor­med.

    Faire confiance et respon­sa­bi­li­ser, étape bien plus impor­tante que toutes les ques­tions de post-it et autres arte­facts des méthodes agiles.

    f the mana­ger yells at the team or moni­tors their burn-down chart, guess what the mana­ger gets? Perfect burn-down charts. So does the mana­ger want perfect burn-down charts or the right conver­sa­tion? In the end, it has to be the latter.

    Parce que l’im­por­tant c’est de livrer de la valeur pour la société et ses utili­sa­teurs. C’est la seule métrique perti­nente, même si elle est diffi­cile à juger.

    Si on juge par un tableau de bord, l’ef­fet obtenu sera l’amé­lio­ra­tion du tableau de bord, et pas forcé­ment le meilleur choix pour la société ou l’uti­li­sa­teur.

    C’est d’ailleurs là aussi toute une ques­tion de respon­sa­bi­lité et de confiance aux équipes. La respon­sa­bi­li­sa­tion c’est consi­dé­rer que l’équipe peut casser l’in­di­ca­teur ou le mettre hors des clous, parce qu’elle juge que c’est le plus perti­nent, ou simple­ment parce qu’il y a eu une diffi­culté qui l’ex­plique.

    — via Forbes, avec pas mal de bonnes choses à lire dans l’ar­ticle

  • Retro­mat – inspi­ra­tion & plans for (agile) retros­pec­tive

    En panne sur les rétros­pec­tives ? Envie de redon­ner un peu de souffle et d’en­train ?

    Florie m’a fait passer un lien vers Retro­mat, je vous recom­mande de jouer avec. Plein d’idées pour réflé­chir.

    Plan­ning your next retros­pec­tive? Get star­ted with a random plan, tweak it, print it and share the URL. Or just browse around for new ideas!

    Sur le même sujet : Fun retros­pec­tives Acti­vi­ties and ideas for making agile retros­pec­tives more enga­ging

  • #NodeJS : A quick opti­mi­za­tion advice

    The small changes made the func­tion body of add() growing over 600 charac­ter. v8 opti­mi­zer (crank­shaft) inlines the func­tions whose body length, inclu­ding the comments, is less than 600 charac­ters.

    — chez Julien Crou­zet

    Je ne peux m’em­pê­cher de trou­ver étrange d’in­clure les commen­taires. Ça ressemble à une façon d’épar­gner un micro-cycle de CPU assez peu perti­nente. Il reste que c’est à savoir, et que mettre le commen­taire hors de la fonc­tion résout tout. Autant le savoir.

  • A case study on App Down­load Inters­ti­tials

    Les infor­ma­ti­ciens se battent depuis long­temps contre ces inter­sti­ciels qui incitent à télé­char­ger l’app native quand ils se connectent sur le site web avec un smart­phone. C’est pénible, et ça ne répond pas à l’in­ten­tion. C’est même horrible quand on suit un lien direct vers un contenu.

    Les popins ne sont guère mieux (voire pire quand elles sont complexes à fermer). Le comble c’est quand la popin ou l’in­ters­ti­ciel ne sont pas adap­tés à la lecture sur un écran de smart­phone, et empêchent toute suite posi­tive.

    La pratique reste, parce que le marke­ting rêve de fidé­li­ser avec une appli­ca­tion dédiée, consi­dé­rée comme plus quali­ta­tive mais surtout qui reste sur le télé­phone.

    69% of the visits aban­do­ned our page. These users neither went to the app store nor conti­nued to our mobile website.

    On manque de chiffres, ou de gens qui veulent bien publier leurs chiffres. Celui là est juste énorme. 69%… C’est énorme. Pour juste 9% de gens qui vont cliquer sur « je veux l’app », dont certains l’ont déjà, d’autres ne l’ins­tal­le­ront pas, la désins­tal­le­ront dans la foulée ou ne l’uti­li­se­ront pas.

    À l’in­verse, en remplaçant l’in­ters­ti­ciel par une bannière bien faite (non, pas une popin, pitié) :

    1-day active users on our mobile website increa­sed by 17%.

    G+ iOS native app installs were mostly unaf­fec­ted (-2%). (We’re not repor­ting install numbers from Android devices since most come with Google+ instal­led.)

    Ne nous embal­lons pas, Google conti­nue de mettre un inter­sti­ciel sur Gmail quand il est accédé par un smart­phone Android.

  • Super­char­ging page load

    Les bonnes ressources expliquant comment faire du web mobile sont rares. La plupart se limitent à parler de media query ou d’adap­ta­tion du rendu, ce qui est loin d’être fina­le­ment le plus complexe ou le plus impor­tant.

    Ici Google nous parle perfor­mance, avec plusieurs étapes très concrètes, du code exemple, et un aperçu d’uti­li­sa­tion des magiques service workers, en tout juste une dizaine de minutes. Si vous voulez parier sur une techno qui va révo­lu­tion­ner le web mobile dans les 12 mois, misez là dessus.

  • Icon-font, hack ?

    Unicode intègre main­te­nant des picto­grammes depuis des années, et ça se renforce chaque version. Aujourd’­hui on doit dépas­ser les 1000 emoji, dont certains sont en réalité des modi­fi­ca­teurs. Avec la compo­si­tion ce sont des dizaines de milliers qui sont possibles. À cela il faut ajou­ter des milliers de symboles, de la flèche jusqu’à l’en­ve­loppe.

    Tout ça se retrouve ou se retrou­vera dans nos polices de carac­tères. C’est fait pour, à dessein.

    Dans Unicode, et donc dans nos polices de carac­tères se trouve aussi une plage de symboles dite « privée ». Elle est faite pour que vous y mettiez vos propres symboles, à vous, pour vos besoins. Tant qu’on reste là dedans, je ne vois pas trop pourquoi y ajou­ter un picto­gramme repré­sen­tant un panier d’achat serait plus ou moins un hack, une bidouille, que les emojis ou les symboles déjà présents.

    La seule diffé­rence est que vous êtes dans un espace privé donc que le sens de vos picto­gramme est inconnu des programmes qui les utili­se­ront. Bon, c’est prévu comme ça au départ aussi, à dessein, et c’est aussi vrai de n’im­porte quelle image sur une page web.

    Bref, les polices de carac­tères person­na­li­sées avec des picto­grammes, un hack ? ça se discute. Unique­ment si vous consi­dé­rez que les plages Unicode de symboles et autres emoji le sont aussi. Ça se discu­te…

  • 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 ?