La KiwiParty 🥝 2018, nous y étions !

Pour cette 9e édition de la KiwiParty à Strasbourg, nous avons une nouvelle fois répondu présents, et avons eu la chance d’assister à de nombreuses conférences de qualité.

Logo de la kiwiparty 2018

Par ailleurs, JoliCode a soutenu cette année la KiwiParty en se portant sponsor. Nous en avons profité pour faire découvrir aux visiteurs notre outil redirection.io, qui permet de gérer les plans de redirection de sites Web, en améliorant ainsi l’expérience utilisateur et en minimisant l’occurrence d’erreurs HTTP – un must have pour le SEO et pour les frontends de qualité !

En avant pour un rapide résumé de quelques conférences qui ont retenu notre attention.

Manifeste pour un Web éthique

Arnaud Malon nous a rappelé qu’en tant que développeurs, nous avons un rôle primordial à jouer pour garder le Web universel (👋 coucou les sites qui ne fonctionnent que sous Chrome 👋), respectueux des gens (en prenant en compte l’accessibilité numérique), de la vie privée et de la planète.

Des exemples de tweets sujets à controverse :

La présentation est disponible sur youtube.

Embarquement Agile : Comment transmettre sa culture à une nouvelle personne en 5 semaines ?

Florian Ferbach nous a présenté rapidement le processus d’intégration d’une nouvelle personne chez Marmelab : « l’embarquement Agile ».

Le processus est assez atypique. Durant 5 semaines, la nouvelle recrue travaillera sur des projets annexes (5 sprints d’une semaine), encadrée par un tuteur et un product owner. La plupart des projets sont des jeux. Chaque réalisation vise à faire sortir le développeur de sa zone de confort et valider les savoir-faire mais également les savoir-être des nouvelles recrues. La rétrospective et la démo sont organisées avec l’ensemble des employés de Marmelab.

La vidéo de la conférence est disponible sur youtube.

MJML, le nouveau standard pour écrire nos emails ?

Thomas Deneulin nous a présenté MJML, un package nodejs afin de simplifier la conception des emails.

En effet, lors de la conception d’un e-mail, deux critères sont à prendre en compte :

  • Le responsive ;
  • Le support des différents webmails.

Ces deux points étant difficiles à traiter en temps normal, MJML nous propose une liste de composants disponibles afin de simplifier cette tâche :

Il y a de nombreuses contributions sur Github et même une application MJML pour desktop afin de visualiser le rendu en temps réel.

Vous pouvez retrouvez sa conférence sur youtube.

CSS3+, une plongée dans le futur

Dans une première partie, Jonathan Giamporcaro nous a présenté quelques fonctionnalités clé en CSS pouvant être utilisées à l’heure actuelle ou en passe de le devenir. Parmi celles-ci, nous avons noté :

  • Flexbox (Modèle de positionnement) ;
  • Les propriétés personnalisés (Custom Properties) ;
  • Le Scroll snap points (Pour les sliders notamment) ;
  • Les sélecteurs de niveau 4 (:has, :placeholder-shown, :any-link, …).

En deuxième partie, Jonathan nous a parlé du projet révolutionnaire HOUDINI.

CSS Houdini permet d’exposer certaines parties du moteur CSS aux développeurs via plusieurs API pour “hacker” le moteur de rendu CSS.

Parmi ces API, nous trouvons :

  • Layout API : Cette API permet aux développeurs de créer leur propre algorithme de mise en page via la propriété CSS display ;
  • Typed Object Model : Il s’agit de fournir aux développeurs une interface JavaScript permettant de manipuler le CSS ;
  • Paint API : Cette API permet de générer, en JavaScript, une image à chaque fois qu’une propriété CSS attend une image.

Vous pouvez retrouvez sa conférence sur youtube.

Gérer le mode hors-ligne grâce aux Service Workers

Corinne Schillinger nous a fait une présentation, avec démo à l’appui, des Service workers. Ils offrent de nombreuses perspectives et peuvent notamment permettre de gérer le mode offline de nos sites ou applications. Ils viennent remplacer de vieux projets expérimentaux, comme par exemple Gears. Les Service Workers sont désormais bien supportés par la plupart des navigateurs. Il faut voir le Service Worker comme un processus qui tourne en tâche de fond de votre navigateur et qui va exécuter des actions à chaque fois que vous essayez d’accéder au site pour lequel le Service Worker a été enregistré. Le Service Worker n’a pas accès au DOM. Il est non-bloquant.

Pour le mettre en place, certains points doivent être respectés :

  • le protocole HTTPS, pour des raisons de sécurité, la seule exception est localhost pour les environnements de développement ;
  • la same-origin policy ;
  • Il est recommandé de positionner le fichier JS à la racine du projet pour ne pas limiter ses possibilités d’action.

Corinne nous a montré un exemple d’implémentation avec la mise en cache des différents assets.

Vous pouvez retrouvez sa conférence sur youtube.

Arrêtez de nous demander combien coûte une ligne de code !

Aurélie Guillaume nous a proposé d’aborder le coût d’une ligne de code.

Cette question est souvent posée par les clients – même si pour notre part, nous n’avons jamais rencontré ce type de demande – avec comme attente une unité de mesure :

  • Notion de temps
  • Notion de prix
  • Notion de complexité
  • Notion de vélocité

Cela peut être difficile de répondre à cette question car beaucoup de choses sont à prendre en compte :

  • Les coûts humains ;
  • Les coûts de conception : gestion de projet, UI, UX, développement, etc ;
  • Les coûts de Q/A & processus qualité ;
  • Les coûts de mise en place de l’infrastructure ;
  • Coût du « code legacy » & des évolutions ;
  • Les failles de sécurité ont aussi un coût
    • Coût en image pour l’entreprise ;
    • Perte directe du Chiffre d’Affaires ;
    • Développement en urgence pour sécuriser la faille ;
    • Mise en péril potentielle de la société ;
  • Le coût de la techno, éventuellement propriétaire ;
  • La manière d’implémenter le code peut aussi faire varier le coût : CMS, Framework ou from scratch.

Le coût d’une ligne de code n’est pas une équation, et il n’y a pas de réponse à la question « Combien coûte une ligne de code ? ». Au lieu de parler de coût, parlez plutôt de valeur.
Il faut simplement expliquer aux clients que leur projet ne doit pas être perçu comme un coût, mais une valeur réelle pour leurs entreprises.

Vous pouvez retrouver sa conférence sur youtube.

Préprocesseurs vs CSS natif : Le match !

Jonathan Levaillant a commencé sa présentation en mettant en évidence les dérives possibles des pré-processeurs, et en donnant deux exemples :

  • Le nesting
  • La directive @extend

Il a ensuite confronté trois fonctionnalités offertes par les préprocesseurs à leurs équivalents en CSS natif :

  • calc() : Calcul sur des unités différentes ;
  • custom properties var(–) : bénéficient de la cascade et peuvent être manipulées en JavaScript ;
  • pseudo-classe :matches : simplification d’écriture de sélecteurs.

Pour finir, il nous conseille d’utiliser les pré-processeurs pour la partie dynamique, et le CSS natif pour la partie structurelle.

Vous pouvez retrouvez sa conférence sur youtube.

Pour finir en Kiwi !

Merci à l’équipe des bénévoles pour l’organisation de cette édition 2018, qui était une très belle réussite. Nous n’avons pas pu aborder toutes les présentations, mais vous en retrouverez les enregistrements sur youtube.

À l’année prochaine !

blog comments powered by Disqus