Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 10 2019

Comment je travaille

Photo d'un souvenir du Japon

Voici un mode d’emploi sur mon travail en tant que Lead Développeur à KissKissBankBank.

Même si l’exercice est un peu étrange, l’idée derrière l’écriture de ce « Manager README » est de partager mes valeurs et mes attentes afin d’être plus transparent et de mieux travailler ensemble. Allez, c’est parti.

Mes valeurs

Bienveillance

J’ai envie que chacun se sente bien dans l’équipe. Je considère que tout le monde part avec de bonnes intentions. Il est important de rester ouvert, à l’écoute de toutes les idées et opinions et de trouver les compromis qui permettent à tous d’avancer.

Entraide

Le code appartient à tout le monde et nous en sommes tous responsables. Les décisions sont partagées autant que possible. La compétition se fait entre les entreprises, pas entre les gens.

Complémentarité

Nous ne travaillons pas tous de la même manière. L’équipe parfaite n’est pas constituée que de super-stars, c’est une équipe riche de différents talents où les forces de chacun se coordonnent et où tout le monde trouve sa place.

Solutions > Code

Nous construisons des solutions, pas du code. Parfois, la meilleure solution est de ne pas écrire une seule ligne. Et comme chaque ligne de code ajoute un brin de dette technique, mes changements préférés sont ceux où on retire plus de code qu’on en ajoute.

Qualité

J’attache beaucoup d’importance à la qualité de ce que l’on produit. Je reconnais le pouvoir extrêmement bénéfique qu’ont les petites améliorations sur l’ensemble. Je considère que nous sommes des jardiniers et que c’est de notre responsabilité à tous de nettoyer, de réparer, d’améliorer ce que l’on touche et de faire attention aux mauvaises herbes.

Rigueur

Dans la recherche de qualité et l’application des bonnes pratiques, j’apprécie la rigueur dans le code que l’on produit. Un principe d’informatique qui résume ma philosophie, c’est d’être flexible sur ce que l’on reçoit et d’être précis sur ce que l’on renvoie.

Artisanat

En tant que développeurs nous pouvons construire nos propres outils, profitons-en. Il est important de regarder comment nos outils nous impactent, comment on peut mieux s’en servir et pourquoi pas en façonner de nouveaux, plus adaptés à nos besoins.

Process

L’efficacité découle des process

Notre travail est aussi de réfléchir à comment on travaille. Il est important de mettre en place des méthodologies qui peuvent nous aider à mieux communiquer et mieux avancer. Néanmoins, nos process doivent s’adapter à nous et pas l’inverse : si ça ne fonctionne pas, trouvons autre chose.

Communication

Notre travail repose majoritairement sur de la communication. C’est ce qui fait la différence entre une équipe qui fonctionne et une équipe qui ne fonctionne pas. J’y accorde donc beaucoup d’importance, que ce soit dans le code, en réunion, en compte-rendus, sur un ticket, en commentaire de revue de code, sur Slack, etc.

Revue

La revue de code permet de détecter des bugs, de partager nos connaissances, de prendre du recul, de mettre en place des bonnes pratiques et d’uniformiser notre style. Je considère que c’est primordial de prendre du temps au moment où déplacer du code est le moins coûteux.

Mes commentaires s’adressent au code et pas à la personne qui l’a écrit. J’essaie pour ça d’écrire sous la forme de questions plutôt que d’affirmations, de faire des critiques constructives et d’avoir un discours bienveillant. Je réalise que ce n’est pas toujours agréable de recevoir des retours sur ce que l’on produit mais je suis convaincu que c’est de cette manière que l’on avance le mieux.

Petits changements

Je suis un grand partisan des petits changements déployés rapidement. En plus d’être concentrés sur une seule problématique, ils sont plus faciles à relire, à comprendre et, en cas de problème, de revenir en arrière. Si une pull request dépasse 500 lignes, je préfère réfléchir à une façon de la découper.

Vous et moi au jour le jour

Je suis disponible pour vous

Je suis content de déplacer mon planning pour débloquer le votre. Je préfère être interrompu plutôt que de vous voir frustrés.

Si vous bloquez sur un problème, que vous hésitez ou que vous voulez une paire d’yeux de plus, faites-moi signe sur Slack. Toutes les questions sont les bienvenues.

Vos pull requests

J’essaie de relire ce qu’on m’assigne en moins de 24h, mais je n’y arrive pas toujours ou il m’arrive également de ne pas voir des changements sur ce que j’ai déjà relu. Si vous êtes en attente de ma relecture, remettez-moi en revue et prévenez-moi par Slack.

Mes commentaires ne sont pas des règles à suivre dans l’absolu, mais le début d’une discussion. Alors, n’hésitez pas à répondre, à partager votre approche ou même que l’on en discute de vive voix.

Partage des connaissances

Je veux que l’on puisse apprendre ensemble. Si je n’ai pas été assez clair, reprenez-moi. Si je vous prends le clavier sans vous laisser faire, arrêtez-moi. Si je ne vous explique pas comment j’en suis arrivé à ces conclusions, demandez-moi. Ça peut vous aider à trouver la solution vous-même la prochaine fois.

Si vous apprenez quelque chose, ça mériterait d’être ailleurs que dans ma tête, alors prenons le temps de le documenter ensemble.

Temps de réponse

Vous pouvez m’envoyer des messages via Slack n’importe quand. Pendant les heures de travail, j’essaie de répondre dans l’heure.

Je lis très rarement mes emails. Si vous m’envoyez un email important, prévenez-moi par Slack.

Je ne suis pas fan des appels téléphoniques et mon téléphone est constamment en silencieux. Si vous voulez qu’on s’appelle, convenons-en par Slack.

Horaires

Je travaille au 4/5èmes et mon jour non-travaillé est le mercredi. J’arrive en général vers 10h30 et je pars aux alentours de 19:30.

Il m’arrive parfois de travailler les weekends ou mes jours off. C’est très rare, c’est mon choix et je n’attends ça de personne. Si je vous envoie un message un weekend, je ne m’attends pas à ce que vous le lisiez ou que vous y répondiez : les réponses peuvent toujours attendre les horaires travaillés.

Sur mon jour non-travaillé je suis souvent connecté sur Slack. Ça ne me dérange pas que vous m’écriviez mais ne vous étonnez pas si j’attends le lendemain pour vous répondre.

Calendrier

Mon calendrier est ouvert et vous pouvez y prendre des créneaux dedans si vous me prévenez en parallèle via Slack. Il m’arrive souvent de ne pas voir le temps passer alors n’hésitez pas à me faire de grands signes si c’est l’heure d’une réunion. J’essaie de m’améliorer là dessus.

Feedback

Je suis très preneur de points en tête-à-tête, de façon ponctuelle ou régulière. On peut parler de vous au sein de l’équipe ou au sein de l’entreprise. On peut également réfléchir ensemble à ce qui nous manque, à nos façons de travailler ou à n’importe quel autre sujet.

Je suis également à l’écoute de retours et critiques sur ma façon de travailler. Dites-moi si j’ai raté quelque chose et que voyez une opportunité de m’améliorer une prochaine fois.

Enfin, merci d’avance pour toutes vos remarques sur cet article, en espérant qu’il sera utile !

October 31 2016

Happy Halloween!

August 16 2015

Lazy Sunday morning. #kittens #sleep

August 14 2015

Peach et Banga

August 13 2015

Banga
Ice-Tea
Banga et Ice-Tea
Ice-Tea dans une chaussure
Ice-Tea

August 09 2015

Banga et Ice-Tea

July 08 2015

Traduire ses routes dans Rails

Photo de portes de Fushimi Inari-taisha

Les URLs de votre site sont visibles et méritent autant d’attention que le reste de votre interface. Dans ce cas, pourquoi avoir des chemins en anglais uniquement alors que le reste de votre site est traduit ?

https://monsite.com/en/books/1/edit
https://monsite.com/fr/books/1/edit
https://monsite.com/es/books/1/edit

Je trouve que les adresses suivantes, traduites, sont plus élégantes et compréhensibles par tous :

https://monsite.com/en/books/1/edit
https://monsite.com/fr/livres/1/éditer
https://monsite.com/es/libros/1/editar

Mieux, non ?

route_localize

Pour avoir des URLs pareilles avec Ruby on Rails sans pour autant tout dupliquer, j’ai développé la gemme route_localize.

Une fois installée, il suffit d’entourer les routes à traduire dans config/routes.rb :

scope localize: %w(en fr es) do
  resource :books
end

Vous pouvez ensuite traduire les chemins que vous voulez dans vos fichiers de localisation :

fr:
  routes:
    books: livres
    edit: éditer

Et voilà ! Magie !

Si vous souhaitez faire passer vos utilisateurs d’une langue à l’autre sur votre site un petit helper prends la langue voulue et vous retourne le chemin traduit.

July 06 2015

Enregistrer la langue d’un utilisateur avec Devise

Daim photographié

J’ai créé une petite gemme Ruby. Son petit nom c’est devise-track_locale. Si vous utilisez Ruby on Rails et Devise sur un site multilangue, cela vous permets d’enregistrer la dernière langue utilisée par l’utilisateur, automatiquement.

C’est un module Devise, donc son installation est aussi simple que d’ajouter :track_locale dans la liste de modules Devise et un champ locale sur les utilisateurs.

Ce n’est pas grand chose, mais plutôt que de garder cette fonctionnalité sur un site j’en ai fait une petite librairie externe, réutilisable, open-source, testée. Et je compte bien en faire autant pour tous ces petits développements qui sortent des fonctionnalités du cœur de mes sites.

April 18 2015

Gudetama, the lazy egg
Reposted byliwq liwq

March 17 2015

Ember en 2015

Trois choses à retirer de la Keynote d’ouverture d’EmberConf 2015 à propos du framework JavaScript Ember :

EmberJS Logo

V2

Toutes les nouvelles features de la version 2 d’Ember sont déjà dans la version 1. Cette nouvelle version va juste retirer les warnings. Du coup la mise à jour d’Ember peut se faire de façon beaucoup plus graduelle et rétrocompatible. Si on compare ça à Angular, la version 2 ne sera pas du tout compatible et introduit énormément de nouvelles façons de faire d’un coup.

Glimmer

Leur nouveau moteur de templates d’Ember, nommé « Glimmer » est au même niveau que React en terme de performances. Un des gros plus de React est son moteur de diff qui permets de minimiser les accès au DOM. Glimmer permets la même chose dans Ember mais il n’y a rien à changer aux templates normaux (handlebars) ou à construire du DOM à la main. Plutôt que de faire du diff sur chaque élément d’un DOM virtuel, il ne fait du diff que sur les parties à l’intérieur des {{}} de handlebars. Il reste du travail pour le rendre rétrocompatible avec les anciennes versions d’Ember, mais le travail avance sur is-ember-fast-yet.firebaseapp.com.

Fastboot

Enfin, Fastboot est le moteur de prérendu d’Ember. Cette application Node prends une application Ember « Single Page App » et génère l’HTML nécessaire pour la servir avec l’HTML déjà tout fait pré-rendue aux navigateurs, en appellant votre API via HTTP si nécessaire. Le premier chargement de vos applications devient beaucoup plus rapide, comme une application côté serveur uniquement. Et ce, encore une fois, sans changer votre façon de travailler avec Ember.

January 05 2015

Peach et Sunny
A lighthouse boat in front of Chrisitian IV's Brewery (the largest tiled roof in northern Europe) in Copenhagen.

November 20 2014

September 04 2014

August 09 2014

August 06 2014

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl