Blog de Florent Viel

Déploiement avec Go et Ansible dans Docker

2016-04-04T00:00:00+00:00

La semaine dernière je me suis mis en tête de développer une application afin de centraliser tous les déploiements qu’on fait à Xotelia. J’ai fait le tour et il existe en SaaS ou en Open source des solutions pour ça. Je n’en ai pas trouvé qui fonctionne avec ansible (bien que lors d’un déploiement on puisse installer ce qu’on veut), ou alors trop cher. De plus on ne déploie pas chaque branche, seulement master ou une feature-branch qu’on veut tester sur un environnement différent de la production. C’est la que j’ai décidé de développer notre propre outil de déploiement. À savoir que sur chacun de nos projets nous avons un playbook ansible de déploiement, mais que jusqu’à maintenant on les lance sur nos propres machines. Il me fallait aussi un outil qui me permette de lancer une commande dans hipchat pour déclencher un déploiement.

Étant un grand fan de go et de docker je me suis dit que ça serait pas mal de pouvoir lancer un container docker, dans lequel je lance ansible, et avoir par dessus un petit frontent avec un flux des logs.

J’ai donc commencé a chercher un client docker en go et je suis tombé sur celui-la. Il me semblait qu’il n’y en avait pas à part dans le core de docker ou alors développé par des tiers, mais je me suis trompé. Et qui plus est, très bien documenté et idiomatic.

Pour le stockage des résultats des builds je me suis tourné vers RethinkDB. Une base de données NoSQL.

Le principe de fonctionnement est simple, quand je reçois un événement de déploiement depuis github, je crée un container à partir d’une image qui contient ansible. Dans ce container je clone le dépôt à déployer et je lance le playbook ansible. Je notifie github et hipchat de l’état du déploiement via leurs API respective. Une fois le déploiement terminé je supprime le container.

Les embûches

Je suis tombé sur plusieurs problèmes lors du développement de ce projet. Tout d’abord il faut savoir que quand dans la console on lance docker run en fait en interne docker va faire un create puis un start.

Ensuite il faut que depuis ce container je puisse me connecter en ssh sur les serveurs sur lesquels je vais déployer mes projets, et que je puisse aussi cloner les projets que je vais déployer. Pour ce faire je passe en bind la clé SSH de l’hôte sur lequel est installé deployer vers le root du container comme ceci :

import "github.com/docker/engine-api/types/container"

hostConfig := container.HostConfig{
    Binds: []string{"/home/deployer/.ssh/id_rsa:/root/.ssh/id_rsa"},
}

Je crée donc mon container avec cette configuration, et je le lance. Comme je ne m’attache pas a celui-ci, tout se passe en background. Donc il faut que j’attende la fin de l’exécution pour récupérer l’exit code.

exitCode, err := dockerClient.ContainerWait(ctx, container.ID)

Je fais beaucoup d’appels à l’API docker dans la même fonction et donc beaucoup d’erreur à gérer. Comme go permet de retourner plusieurs éléments par fonction, à chaque fois que j’ai une erreur, je la remonte. Il me faut donc un moyen pour arrêter le container en cours à la moindre erreur pour ne pas laisser de déchêts sur la route. C’est la qu’intervient le mot-clé defer. Ce mot-clé permet de définir un comportement qui sera exécuté juste avant le retour d’une fonction. Très pratique pour fermer un fichier ou un io.Reader.

On arrive à la partie la plus intéressante, que j’ai fais en deux fois. La récupération des logs du container une fois l’exécution terminée.

import "github.com/docker/engine-api/types"

logOpts := types.ContainerLogsOptions{
    ContainerID: container.ID,
    ShowStdout:  true,
    ShowStderr:  true,
    Follow:      true,
}

Ce qui a été exécuté dans le container a peut–être écrit dans la sortie standard ou la sortie d’erreur. Il faut donc que je récupère les deux. C’est la que je suis tombé sur une partir qui manque de documentation. Quand on demande à l’API docker les logs d’un container avec les deux sorties, docker va les multiplexer pour les mettre dans le même io.Reader. Et pour savoir sur quelle sortie correspond quelle ligne, docker va rajouter un header à chaque ligne pour indiquer si ça correspond a stdin, stdout ou stderr.

Il faut donc je de démultiplexe ce que me renvoit docker pour avoir un résultat lisible. En fouyant un peu sur github et google, je suis tombé sur ce petit package dans le projet docker. et en particulier la fonction StdCopy. Cette fonction permet de démultiplexer une source (io.Reader) et d’écrire stdout et stderr vers deux io.Writer distinct.

Et voilà le tour est joué, j’ai mes logs propre pour chaque déploiement. Sauf que les problèmes ne s’arrêtent pas là. J’ai voulu rajouter de la couleur dans ces logs. Car la commande ansible écrit sur stdout avec différentes couleurs. Pour ce faire il faut que le terminal utilisé supporte la couleur. Il suffit de rajouter ENV TERM xterm dans le Dockerfile du container et ansible va pouvoir afficher de la couleur. Mais ce n’est pas tout, il faut aussi dire à docker d’utiliser un pseudo terminal (PTY) pour le container sinon cette variable d’environnement ne servira a rien. Pour ça il faut modifier la configuration utilisée pour créer le container :

import "github.com/docker/engine-api/types/container"

config := container.Config{
    [...]
    Tty:       true,
    OpenStdin: true,
    [...]
}

Mais voilà, en rajoutant cette configuration, quand on récuère les logs, docker ne va pas multiplexer les sorties stdout et stderr mais va renvoyer la sortie brut du pseudo terminal. Donc il ne faut plus utiliser stdcopy.StdCopy.

Comme je l’ai dit plus haut, je voulais avoir une page pour suivre le déploiement et afficher le flux des logs. J’avais deux possibilités pour ça, soit utiliser les Websocket ou Server-sent event. Le premier est en full duplexe, c’est à dire que le serveur et le client peuvent écrire dedans. Le deuxième est dans un sens seulement, le serveur envoi des messages au client. Je suis parti sur Server-sent event, car je n’ai pas besoin que le client (la page web) envoi de message au serveur.

Côté serveur, j’utilise un petit package go qui me permet de créer les événements. Ensuite, pour que dans mon handler du flux je puisse renvoyer les logs sous la forme d’événements j’ai créé une struct qui contient un http.ResponseWriter et la quantité de data envoyée. Avec cette struct j’implémente l’interface io.Writer. Je me suis inspiré de ce que j’ai trouvé dans le projet drone :

import (
    "http"
    "strconv"

    "github.com/manucorporat/sse"
)

type StreamWriter struct {
    writer http.ResponseWriter
    count  int
}

func (w *StreamWriter) Write(data []byte) (int, error) {
    var err = sse.Encode(w.writer, sse.Event{
        Id:    strconv.Itoa(w.count),
        Event: "message",
        Data:  string(data),
    })
    w.writer.(http.Flusher).Flush() // ne pas oublier de flush le ResponseWriter à chaque message pour que le serveur envoi l'événement au client.
    w.count += len(data)
    return len(data), err
}

Il ne me reste plus qu’a copier le io.Reader que me renvoi docker pour les logs dans cet io.Writer. Ne pas oublier de définir le Content-Type à text/event-stream.

import (
    "http"
    "io"

    "github.com/manucorporat/sse"
)

func streamHandler(w http.ResponseWriter, req *http.Request) {
    w.Header().Set("Content-Type", sse.ContentType)
    reader, _ := dockerClient.ContainerLogs(ctx, logOpts)
    writer := &StreamWriter{w, 0}
    io.Copy(writer, reader)
}

Je peux donc récupérer ces événements depuis la page du déploiement et les afficher.

Résultat final

J’ai donc maintenant une application qui reçoit les événements de déploiement de github et qui lance le déploiement dans un container docker. Je peux suivre le tout dans une joli page web. Ainsi est né Deployer.

La suite du projet ? Avoir une meilleure gestion des releases, savoir qui a déployer quoi à quel moment, un historique des commits déployés, une intégration avec une application github oauth pour simplifier l’ajout de projet à déployer, une sécurisation du webhook github avec un secret, etc. La liste est longue.

Les bonnes pratiques de développement - partie 2

2015-03-27T00:00:00+00:00

Parties : [1][2]

Dans la première partie de ce sujet j’ai plus parlé du côté humain dans le développement, aujourd’hui on va rentrer dans le code et savoir ce qu’il faut faire pour qu’un projet dure sans devenir legacy.

Disclaimer

Tout ce que je vais écrire dans cette série d’article reflète uniquement ma propre opinion.

Gestion des dépendances

Le plus important dans un projet, et surtout en équipe, c’est la gestion des dépendances, non seulement applicative, mais aussi logicielle, et même matérielle (au moins virtuelle) quand c’est possible.

Les dépendances applicatives c’est quoi ? Ce sont les vendors de son application. Typiquement définie dans ton composer.json, Gemfile, requirements.txt, etc. Garder la même version de ces dépendances sur tous les postes de tous les développeurs est assez simple. A peu près chaque système de gestion de dépendance stocke dans le répertoire du projet un fichier dans lequel il indique toutes les versions de tous les vendors installés. Avec composer c’est le fichier composer.lock. Très important de le versionner, ainsi les vendors seront les même en dev, CI, stagging, prod, etc.

Les dépendances logicielles c’est quoi ? Ce sont les logiciels nécessaires pour faire tourner son application. Pour une application Symfony il s’agit d’un Nginx, de PHP et sûrement de MySQL. Alors en équipe ou même tout seul, je déconseille fortement d’installer manuellement ces dépendances. Car on va se retrouver avec une version de nginx en local, une autre en CI et encore une autre en prod. C’est le meilleur moyen de laisser passer des erreurs pour les voir seulement en prod, trop tard… Ce que je conseille plutôt c’est d’utiliser vagrant ou encore mieux docker.

Vagrant par exemple, permet de créer une machine virtuelle, de dire comment la provisionner, c’est à dire qu’est-ce qu’il faut installer dessus, et ensuite de pouvoir partager cette machine virtuelle entre tous les collaborateurs du projet. Comme ça tout le monde à la même version des mêmes logiciels d’installés.

Ensuite Docker. Ça peut être un meilleur choix si tout le monde est sous linux. Car en plus de pouvoir utiliser les mêmes images en dev, ces images pourront servir en CI et pourquoi pas en prod. Je dis sous linux seulement car actuellement, sous mac ou windows, la seule façon d’utiliser docker est de passer par boot2docker et il y a certains problèmes au niveau du partage de fichiers entre l’hôte et la machine virtuelle qui contient docker, voir ici.

Revenons à vagrant, ça règle les problèmes de la dev, mais pas de la prod ni de la CI. C’est à dire qu’il nous faut encore installer manuellement nos dépendances logicielle. Il existe des solutions pour ça comme ansible. Un peu comme Chef ou Puppet, ces solutions permettent de transposer en code la façon d’installer ses dépendances, et donc de pouvoir versionner tout ça. Ainsi, on peut utiliser ces recettes pour notre vagrant, mais aussi en CI et en prod. Comme ça on est à peu près sûr de pouvoir reproduire un bug de prod en local.

Les dépendances matérielles c’est quoi ? C’est le matériel qu’on utilise pour développer, faire tourner sa prod, etc. Autant que possible, si plusieurs personnes travaillent sur un même projet, qu’elles aient le même matériel (un MacBook Pro 13” Retina c’est parfait :D). Après si on utilise vagrant ça limite la casse de ce côté là car on émule les ressources, elles seront donc les mêmes pour tout le monde dans la machine virtuelle.

En prod on utilise forcément pas le même matériel, par contre on peut essayer d’avoir une architecture similaire à la prod en dev. Je dis bien similaire car si on a 50 frontaux avec du load balancing, 10 MySQL et 20 Redis, ça va être compliqué d’avoir la même chose sur sa seule machine de dev.

Tests

On attaque une grosse partie, les tests. Alors je ne suis pas un fou furieux du TDD ou BDD, mais j’essaye d’utiliser les deux en fonction du besoin. Actuellement, je travaille sur Xotelia. À l’origine c’est un gros projet monolithique basé sur un framework maison. Autant dire que se mettre à faire du TDD la dedans c’était du suicide. Par contre le BDD s’y prête bien. Au fur et à mesure de l’apprentissage du projet j’ai pu mettre en place quelques briques de BDD pour valider certaines fonctionnalités, à commencer par le login.

C’est grâce à cet effort de fond que j’ai pu transformer ce lourd framework maison et hybride Symfony. Qui est devenu beaucoup agréable pour développer et avoir des bons retours d’erreurs.

Tout ça pour dire que l’utilisation du TDD ou du BDD se fait au jugement. Il ne faut pas foncer tête baissée. Comme cité plus haut, pour le cas d’un projet legacy, le TDD est exclu. Trop complexe à mettre en place et à maintenir, pour au final quel gain ? Au contraire sur un nouveau projet, le TDD s’avère très utile. À bon escient, il permet de développer de manière moins couplée, de valider le fonctionnement de ses classes, etc. Par contre il n’est pas nécessaire de faire du TDD pour tout. Inutile de tester un controller Symfony, c’est déjà fait au niveau du framework. De plus la logique métier ne doit pas se situer dans le controller (dans le meilleur des mondes).

Ensuite pour une API rest par exemple, pas besoin non plus de faire de TDD. Seul ce qui importe dans une API c’est son interface, qu’elle soit consistante et une fois déployée en prod, qu’elle ne change pas. Donc peut importe le mécanisme derrière une API ce qu’il faut valider c’est la sortie. Et là une fois de plus le BDD s’y prête à merveille.

Je recommande de lire cet article pour un point de vue plus détaillé sur les tests.

Code review

Quand on travaille en équipe on ne peut pas se permettre de pusher directement sur le master les yeux fermés. On risque d’introduire des bugs, d’avoir oublié des choses, il va être difficile de revenir en arrière, etc. Il vaut mieux dans ce cas utiliser le système de Pull Request de GitHub, ou les Merge Request de Bitbucket. Voire pourquoi pas se coupler à un vrai système de code review comme gerrit, pas très sexy mais très puissant.

Il est très important de faire relire son code par au moins une autre personne. Ça permet de détecter les oublis de ;, un développement manquant, une autre façon de faire les choses, etc. Couplé à un système de branche, on se retrouve avec un historique clair, on peut savoir quelles features ont été mergées a quel moment et on peut facilement revenir en arrière si besoin.

Conclusion

J’espère que vous pratiquez déjà tout ça. Si non il est temps de s’y mettre. n’hésitez pas à me donner vos impressions et vos bonne pratiques dans les commentaires. J’en intégrerai peut-être certaines à cet article.

Les bonnes pratiques de développement - partie 1

2015-03-20T00:00:00+00:00

Parties : [1][2]

Voilà bien un sujet pour lequel j’ai pu discuter pendant des heures cumulées autour de la machine à café. Ce sujet sera traité en plusieurs articles, pour qu’il soit plus digeste à lire. Je mettrai à jour au cours de l’écritures les références vers les différentes parties.

Disclaimer

Tout ce que je vais écrire dans cette série d’article reflète uniquement ma propre opinion.

Introduction

Commençons par définir le périmètre des bonnes pratiques de développement. Pour moi ce sujet couvre l’organisation de l’équipe, la façon de répondre à un besoin, son implication dans le projet, la façon de concevoir et d’écrire du code, le tester. Dans cette première partie je vais traiter le niveau humain.

L’humain

En tant que développeur on est avant tout un humain, ce qui implique des relations sociales et pas seulement homme - machine. On voit ce type de relation à tous les niveaux. Dans le métro pour aller au travail, autour de la machine à café, il s’agit le plus souvent de relations informelles. Au travail on les retrouves lors de réunions, de rendez-vous, mais aussi lorsqu’on répond à un email, un ticket de bug. Il y a toujours quelqu’un de l’autre côté qui va lire et interpréter ce qu’on a écris. Le plus souvent pas comme on le pensait car on a tous des grilles de perception différentes. C’est pourquoi être un bon développeur c’est avant tout savoir bien communiquer, tant à l’oral qu’à l’écrit.

Communication orale

C’est un type de communication facile, en face à face, au téléphone, skype, whatever. C’est très pratique, mais très souvent un piège. Par exemple, ton client t’appelle, te demande de faire telle ou telle correction urgente, toi tu t’exécute, et là, le lendemain ou la semaine suivante, on te demande d’ou sort cette demande. Comment la justifier ? impossible… Ce genre de problèmes m’est arrivé plusieurs fois, c’est pourquoi depuis je pars du principe que toute communication orale est informelle. Dès qu’il s’agit d’une communication formelle, je retranscris par écrit.

Communication écrite

Là non plus ce n’est pas si simple. Certes, c’est écrit, mais toujours sujet à interprétation. Chaque personne à son vécu, son éducation, etc. Bref on a tous un milliards de facteurs qui font qu’on va interpréter différemment ce qu’on lit. C’est pourquoi il faut être explicite au maximum sur le message qu’on veut faire passer. Par exemple, si un ticket est vague, toujours demander un maximum d’explications aux personnes concernées avant de se lancer dans le code. Car au final ça retombe souvent sur le développeur et on peut se retrouver à avoir travailler pendant une semaine pour rien… Un cahier des charges est toujours soumit au changement, et sur un projet en perpétuelle évolution, difficile d’écrire un cahier des charges qui couvre tout de manière exhaustive. En tant que développeur, j’essaye de toujours avoir une trace de tout ce qui est fait sur les projets sur lesquels je travaille. Tickets, mails, historique git, pull request, etc.

Gestion du temps

Bien coder, s’est aussi bien gérer son temps. Ça commence par l’estimation d’une tâche, souvent fausse car on a jamais tous les paramètres. Mais c’est aussi la façon de le découper dans la journée pour allouer tant de temps aux mails, tant au code, et ainsi de suite. En tant que développeur on a souvent besoin de longue session non interrompue de code. Car le changement de tâche a un coût. Si on commence une tâche, qu’au bout d’une heure on reçoit un mail ou un appel, et qu’en suite on retourne dans le code, il va falloir du temps pour retrouver où on en était. J’essaye donc au maximum de dépiler mes mails en début de journée, faire un tour des tickets, en choisir un et m’y atteler. J’essaye de préférence d’avoir des tâches ayant un périmètre le plus petit possible, ainsi je peux en traiter plusieurs dans la journée. C’est beaucoup plus motivant car à la fin de la journée on à l’impression d’avoir abattu beaucoup de travail. Ce n’est pas toujours possible, certaines demandes peuvent nécessiter plusieurs jours. Dans ce type de tâche il est important de se définir plusieurs objectifs afin qu’elles ne paraissent pas insurmontables.

Conclusion

Pour être un bon développeur, il faut donc savoir communiquer et bien gérer son temps. Dans le prochain article je rentrerai plus en détail sur le code. La façon de l’organiser, gérer un environnement de développement, comment éviter les régressions. Si vous avez des questions, des remarques, des choses à ajouter, n’hésitez pas à utiliser les commentaires pour m’en faire part.

Pourquoi choisir Go

2015-03-13T00:00:00+00:00

Je suis un grand fan du langage de programmation Go. Dans cet article je vais essayer d’expliquer pourquoi c’est un bon choix en entreprise, quels sont ses avantages.

Introduction

Petite remise dans le contexte. Go (Golang) est un langage de programmation compilé, développé par Google qui a maintenant 5 ans. C’est un langage qui se veut simple dans sa conception et son utilisation. Pour ceux qui ne connaissent pas, je conseille d’aller jeter un oeil à Un tour de Go. C’est un didacticiel en ligne qui permet de faire le tour du langage et de découvrir ses fonctionnalités.

Venant d’un langage interprété comme PHP ça peut être un peu déroutant au début, mais sa syntaxe s’inspire du C, du C++ et du Python, donc rien de fondamentalement nouveau. La où Go innove, c’est au niveau des fonctionnalités. Globalement vous pouvez à peu près tout faire avec les Slice, les Map, les channels et les Goroutines. Vous allez me dire, mais ce langage est vide, on ne peut rien faire avec, où sont les generics ? les generator ? et j’en passe. À l’heure actuelle, on part du principe qu’un nouveau langage de programmation doit reprendre les concepts et les fonctionnalités de ses prédécesseurs. Go n’a pas choisi cette voie car ses concepteurs voulaient un langage simple par nature. Je vous laisse consulter ce billet de Rob Pike, un des trois fondateurs du langage.

Tour des fonctionnalités

Je vous ai cité précédemment les principales fonctionnalités du langage. Ce qui en fait un langage simple c’est que pour une fois, la spécification est lisible, tout y est bien documenté, il existe même un genre de résumé de cette spécification ici. Je ne vais pas m’étendre sur les Slice et les Map, en gros un Slice c’est un tableau indexé de data, et un Map permet de définir une structure de data.

Je vais rentrer un peu plus dans le détail sur les channels et les goroutines. Une goroutine est un genre de thread simplifié qui permet d’écrire du code asynchrone très rapidement. le simple fait de placer le mot-clé go devant un appel de fonction ou une fonction anonyme crée une goroutine.

go list.Sort()  // run list.Sort concurrently; don't wait for it.

Alors tout ça c’est bien gentil, mais comment on récupère le traitement d’une goroutine ? Comment sait-on que son exécution est terminée ? C’est là qu’entre en jeu les channels. Un channel permet de communiquer avec des goroutines.

c := make(chan int)  // Allocate a _channel.
// Start the sort in a goroutine; when it completes, signal on the _channel.
go func() {
    list.Sort()
    c <- 1  // Send a signal; value does not matter.
}()
doSomethingForAWhile()
<-c   // Wait for sort to finish; discard sent value.

Dans cet exemple, on crée un channel d’int, on crée une goroutine dans laquelle on va procéder au tri de notre list, à la fin de ce tri on informe le channel que le tri est terminé en envoyant un signal, dans cet exemple, la valeur du signal n’a pas d’importance. Pendant ce temps on a appelé la fonction doSomethingForAWhile qui va réaliser un traitement assez long. et la dernière ligne indique qu’on attend de recevoir le signal pour passer à la suite. De cette façon on est prévenu de la fin de l’exécution de notre goroutine.

Ces deux fonctionnalités permettent d’écrire des programmes complexes, avec des traitements asynchrones tout en restant simple dans l’écriture.

Avantages

Le premier avantage de Go, particulièrement en entreprise, quand on travaille en équipe c’est la convention de codage. Elle est écrite dans le compilateur, ce qui fait qu’un programme qui ne respecte pas cette convention ne fonctionnera pas. Le langage met à disposition plusieurs outils pour formater son code correctement comme go fmt qui est inclus et golint qui propose des suggestions d’amélioration ainsi que go vet qui inspecte les constructeurs. Comme ça pas de discussion sans fin pour savoir si on met son accolade en fin de ligne ou sur la ligne suivante.

L’autre avantage est que pratiquement tout est intégré dans la bibliothèque de base. Besoin de faire un serveur web ? net/http à la rescousse. Besoin de toucher à l’I/O ? io et io/ioutil sont la. Pour travailler avec les fichiers ? os est la pour vous servir. Vous faites une API en JSON ? encoding/json est là. Bref vous l’aurez compris, tout est déjà inclus. Mais ça ne vous empêche pas d’utiliser des bibliothèques d’autres développeurs.

On en vient donc à la gestion de dépendances. Avec Go, pas de composer.json, pas de Gemfile, pas de requirements.txt. Les dépendances dont on a besoin se déclarent dans le fichier qui les utilise, et le compilateur râle s’il y a des dépendances qui ne sont pas utilisés.

package main

import "fmt"

func main() {
    fmt.Println("Hello, world!")
}

Alors vous allez dire, comment on spécifie la version d’une dépendance pour être sûr que notre programme sera compilé avec les mêmes vendors sur notre machine, sur notre CI et sur notre prod ? Il existe plusieurs solutions pour ça comme gopkg.in qui sert d’alias dans les imports en spécifiant une version :

import "gopkg.in/yaml.v1"

Il existe aussi godep qui permet de sauvegarder son workspace local de dépendances, qui sera à ajouter dans sons VCS.

La plupart du temps, il suffit d’utiliser la technique de base de déclarer ses dépendances dans le block import car un programme en Go ne doit pas casser la compatibilité. Si c’est le cas, il faut faire un nouveau projet. On évite ainsi avec le Dependency hell.

Un autre avantage de Go est que celui-ci est compilé en un binaire statique. Ainsi, un simple scp puis un restart permet de déployer une nouvelle version de son programme. Go à été pensé par ses créateurs pour des gros code source, des gros projets avec des grosses équipes qui travaillent dessus. Alors oui, un Hello world en Go génère un binaire plus gros que la même chose en C ou C++. Mais c’est un langage conçu avec son temps. On a des teraoctets de stockage et des gigaoctets de mémoire vive à l’heure actuelle sur nos machines de production, donc pas besoin d’avoir un binaire qui fait 18Ko au lieu de 3Mo. Pas de Makefile non plus pour compiler son programme, un simple go build suffit.

Inconvénients

Comment ça des inconvénients ?

Preuve par l’exemple

Il y a maintenant des dizaines d’entreprise qui ont fait le choix de Golang, alors pourquoi pas vous ?

Je ne vais pas faire une liste exhaustive ici de toutes les entreprises qui ont fais le paris de Go, mais le simple fait de lire ces articles permet d’avoir un bon aperçu de pourquoi c’est une bonne décision.

J’ai moi même eu l’occasion de faire un peu de Go en entreprise. Chez mon ancien employeur, je travaillais sur un réseau social qui traitait beaucoup d’images dans beaucoup de formats. J’ai développé un worker en Go qui permet de générer les miniatures de façon asynchrone sans surcharger les requêtes HTTP, tout en profitant de toutes les capacités d’un serveur dédié à ce process.

Pour mon employeur actuel j’ai développé un petit programme qui permet de faire du debug sur des requêtes HTTP sans pourrir la réponse. Quand c’est de l’AJAX et qu’on renvoie du JSON, pas facile de faire un var_dump au milieu de tout ça. Il s’agit d’un petit programme connecté à Redis, qui possède un seul point d’entrée sur son API pour envoyer les messages, et il suffit d’ouvrir une page web sur l’index pour avoir le flux en temps réel (Websocket) des messages qu’on lui envoie. Je vous laisse regarder ici.

Je suis actuellement en train de développer un mini clone open source de Vagrantcloud (désormais Atlas) qui permettra de gérer sois-même ses versions de box sur son propre serveur, avec du continuous build des box via packer.

Conclusion

J’espère vous avoir donné l’envie de tester ce langage de programmation, et pourquoi pas avoir l’occasion de travailler sur un gros projet en Go dans votre entreprise.

Happy Coding!

Mes impressions sur le télétravail

2015-03-06T00:00:00+00:00

Celà fait maintenant 9 mois que je suis en télétravail et je peux tout de suite dire que j’apprécie ça.

“ Pursuit of Happiness ”

Tout d’abord, qu’est-ce qui m’a amené à faire du télétravail ? Le désir d’avoir plus d’autonomie, mais aussi de pouvoir voir mon fils toute la journée et m’occuper de lui la journée autant que ma femme.

J’ai d’abord commencé le fonctionnement en tant que freelance, puis ensuite en CDI pour Xotelia. J’ai d’abord commencé en tant que freelance car ça m’a permis d’organiser mon emploi du temps comme je le voulais, tout en gardant des moments de disponible pour mon client. J’avais besoin de cette souplesse pour passer mon permis de conduire, ainsi que d’autres obligations. Étant en freelance je pouvais travailler tous les jours de la semaine. J’essayais quand même de garder du temps libre à consacrer à ma famille. Cette expérience de freelance n’a duré que 4 mois, à la suite desquels j’ai été embauché en CDI chez mon client.

J’ai perdu la souplesse d’organisation de mon emploi de temps car les jours et les horaires de travail sont fixes. Mais je n’ai pas perdu les avantages du télétravail. À savoir :

Le temps de trajet entre mon domicile et mon lieu de travail est d’environ 3 secondes, le temps d’aller dans mon bureau :),
La possibilité de travailler d’où je veux,
L’organisation de mon poste de travail comme bon me semble.

Il faut savoir qu’il y à quand même quelques inconvénients :

Pas de discussion off à la machine à café,
Tout seul toute la journée,
Pas de contact humain (enfin dans mon cas je vois ma femme et mon fils :)

Il existe beaucoup d’outils, surtout dans le développement informatique, qui permettent de contourner ces inconvénients. Tout d’abord mettre en place un chat pour que l’équipe reste soudée et puisse discuter toutes la journée, nous utilisons HipChat. Mettre en place un système de ticket comme Redmine et surtout un gestionnaire de version décentralisé comme GitHub. Enfin bref, presque tout ce qui est fait en interne dans l’entreprise, peut être mis sur une plateforme en ligne. Vous trouverez une liste des outils pratique en télétravail ici.

The Graal

D’une manière générale, ce mode de fonctionnement me va plutôt bien. Certes il impose une certaine rigueur pour ne pas finir sur Twitter, Hacker News ou Reddit toutes les 5 minutes. Mais avec de la concentration, et surtout, un métier passionnant, ce n’est pas vraiment un problème. Celà dit, ce n’est pas fait pour tout le monde non plus. Le seul problème que je peux noter pour ce mode de travail c’est de voir rarement l’équipe. Mais ce problème est en partie résolu par le fait que je descende régulièrement sur Lyon dans les bureaux de la société pour quelques jours. Ça permet de renforcer l’équipe, pour moi de voir des gens et d’une manière générale que personne ne soit oublié. Je peux citer un excellent article sur le sujet mais aussi un excellent bouquin.

J’arrive globalement à rester concentré 6 heures dans la journée, je peux me prendre une petite pause quand bon me semble pour boire un café, ou simplement me dégourdir les jambes. Le midi je mange chez moi. Ce qui me permet d’économiser par mois un abonnement aux transports en communs, des pleins d’essence et des dépenses inutiles pour m’acheter un sandwich ou me payer un resto à l’extérieur.

Pour conclure, ce mode de travail me correspond parfaitement et s’il le fallait je pourrai intégrer d’autres personnes en télétravail au sein de l’équipe Xotelia. Dans un futur plus ou moins proche je serai peut être de nouveau amené à travailler dans des bureaux, mais ce n’est pas au programme pour l’instant. Pour ceux que ça intéresse, il existe un site d’offres d’emploi uniquement consacré au télétravail We Work Remotely.

Happy remote work!

Retours d'expériences sur le recrutement

2015-02-27T00:00:00+00:00

Ces dernières semaines j’ai été amené à faire passer des entretiens techniques pour trouver deux personnes avec qui je vais partager mes tâches au quotidien.

Remise dans le contexte

Tout d’abord, une petite remise dans le contexte s’impose. Je travaille pour Xotelia, un gestionnaire de canaux de ventes en SaaS. Je suis tout seul à m’occuper des corrections de bugs, des évolutions et des nouveaux projets. L’entreprise vient de faire une levée de fonds et il faut donc agrandir l’équipe technique pour pouvoir tenir la charge qui va arriver.

On m’a donc confié la tâche de trouver des personnes avec qui je travaillerai. Pour préciser, je m’occupe seulement de l’entretien technique et je suis en bout de chaîne. Nous passons par un cabinet de recrutement pour aller au plus vite, donc il y a un premier filtre à ce niveau là et ensuite le candidat a un entretien avec le patron, ce qui fait un second filtre. Je me retrouve donc avec des candidats qui correspondent à la fiche de poste et qui ont été jugés comme capables de travailler en équipe chez Xotelia. Un autre point à prendre en compte est le fait que je suis en télétravail, la société est sur Lyon donc tous les entretiens que je fais passer se déroulent sur Skype.

Comme c’est une expérience nouvelle pour moi, je me suis un peu renseigné en quoi consiste un entretien technique, et oui jusqu’à présent j’ai toujours été à la place du candidat, maintenant je suis à la place du recruteur. J’ai donc trouvé plusieurs articles ici et là. Je sais comment je suis, je veux travailler avec des gens comme moi, mais il me fallait définir les critères qui me définissent pour trouver quelqu’un comme moi.

En lisant ces deux articles, je me suis rendu compte qu’au final c’était assez simple. Il me fallait quelqu’un de motivé, mais surtout de passionné.

Quelqu’un qui a vu des lumières s’allumer dans ses yeux le jour où il a compilé son premier programme et qui a voulu le montrer à tout le monde. Même si ce programme ne faisait qu’afficher Hello, World! dans la console.

Déroulement de l’entretien prévu

Je me suis donc basé sur le retour d’expérience de Nicolas Bize pour le déroulement de mes entretiens :

Rapide passage en revue du CV (10 min)
Présentation de la stack technique de Xotelia (10 min)
Questions sur quels sont les projets dont il est le plus fier et discussions (25-30 min)
Test technique par mail

Après avoir fait passer plusieurs entretiens, je peux confirmer que la méthode de Nicolas fonctionne.

“ we have about 30 minutes left. Will you please tell me about the best project that you’ve ever created? ”

Je me rendais rapidement compte de la motivation du candidat en voyant pétiller ses yeux quand il me parlait de ses projets. J’essaye au début de l’entretien de le mettre en confiance en posant des questions naïves sur des technos qu’il a pu utiliser, etc. Pour l’explication de la stack Xotelia, je mentionnais quelques technos mais rien de trop explicite non plus, il ne s’agit pas d’un meetup d’experts PHP. Puis ensuite venait la question fatidique “ Parle-moi des projets dont tu es le plus fier ”. La plupart du temps, j’écoutais le candidat parler mais je pouvais aussi appuyer ce qu’il disait à certains moment en mentionnant qu’il m’est arrivé la même chose dans ma carrière ou que j’ai aussi utilisé telle techno. À la fin de cet entretien, je savais déjà si la personne correspondait au profil ou pas. Mais je faisais quand même passer un petit test technique. Rien de bien compliqué, pas non plus le questionnaire de la certification Zend. Un petit développement en rapport avec le métier de Xotelia.

Ce test me permet d’avoir un aperçu de la façon de penser du candidat, de comment il organise son code pour résoudre un problème. Un candidat m’a même dit qu’il s’est bien amusé à faire ce test.

Ma responsabilité dans ce recrutement n’est pas moindre, car il s’agit pour moi de trouver les bonnes personnes qui seront à même techniquement de monter au créneau sur le projet pour le faire décoller et soutenir les défis techniques qui vont arriver avec la levée de fond.

J’ai trouvé cette expérience très intéressante et je serai prêt à recommencer, la prochaine fois dans la même pièce !

Shell interactif Symfony2

2014-04-30T00:00:00+00:00

En python avec le framework django ou en ruby avec rails on dispose d’un shell interactif qui permet de jouer avec ses modèles, la base de donnée, etc. Cette possibilité manquant dans Symfony2. C’est pourquoi j’ai développé une petite lib basée sur psysh qui permet d’avoir un shell interactif php avec l’application bootée dedans.

Le projet est disponible ici. L’installastion est simple :

composer require-dev luxifer/symfony-repl

Ou en le rajoutant à la main dans son composer.json et en lançant un composer update :

{
    "require-dev": {
        "luxifer/symfony-repl": "dev-master"
    }
}

Ensuite à la racine de son projet Symfony, il suffit de lancer bin/symfony-repl et le shell se lance.

Psy Shell v0.1.8 (PHP 5.5.11 — cli) by Justin Hileman
>>>

Depuis ce shell on a la variable $kernel qui est exposée et qui est le kernel Symfony. Depuis ce shell on peut lancer $kernel->getContainer() pour accéder au conteneur de service symfony et donc ainsi accéder à tous les services définis. Tout le code qu’on a écrit dans le dossier src/ est disponible et on peut donc facilement instancier un modèle comme Acme\UserBundle\Entity\User.

Cette petite lib va instancier un kernel Symfony avec l’environnement de dev, c’est une sorte de proof of concept, par la suite je vais rajouter des fonctionnalités pour changer l’environnement ou même le fichier de bootstrap de Symfony.

Happy development!

Permissions sur le dossier .ssh de linux

2013-12-31T00:00:00+00:00

Je ne sais pas si certains d’entre vous ont déjà eu ce problème. La connexion ssh par clé publique est bien configurée, et pourtant ssh demande quand même un mot de passe. Dans la plupart des cas il s’agit d’un problème de permissions sur le dossier .ssh. Voici les bonnes permissions à appliquer sur ce dossier :

# dossier .ssh

drwxr-xr-x  2 luxifer luxifer 4096 oct.  18 20:11 .
drwx------ 21 luxifer luxifer 4096 déc.  30 10:59 ..
-rw-r--r--  1 luxifer luxifer  803 oct.  18 20:11 authorized_keys
-rw-------  1 luxifer luxifer 1675 oct.  16 15:43 id_rsa
-rw-r--r--  1 luxifer luxifer  404 oct.  16 15:43 id_rsa.pub

# dossier home

drwxr-xr-x   2 luxifer luxifer  4096 oct.  18 20:11 .ssh

Pour la petite explication, dans le dossier .ssh, le dossier .. doit avoir un chmod de 700 qui autorise seulement le propriétaire à aller vers le dossier supérieur. De ce fait lors de la connexion ssh, tant qu’on est pas connecté, le dossier home est protégé. ensuite, les fichiers authorized_keys et id_rsa.pub doivent être en chmod 644 car ce sont eux qui sont utiles lors de la connexion. Pour finir le ficher id_rsa doit être en chod 600 car c’est la clé privée.

Ensuite dans le dossier home, le dossier .ssh doit être en chmod 755 car ssh a besoin d’y accéder lors de la connexion.

Et voilà :)

Intégration continue avec Symfony 2, Composer et Jenkins

2013-05-31T00:00:00+00:00

Bonjour,

Aujourd’hui on va parler d’intégration continue avec Symfony2, Composer et Jenkins.

Après plusieurs jours de galère à chercher de la doc sur comment mettre en place des tests automatisé sur symfony2 avec jenkins, j’ai finalement réussi à faire ce que je voulais. Tout d’abord, plusieurs problèmatiques se posent. Pour les tests unitaires pas besoin de grand chose, on test juste une classe, une fonction ou une méthode. Pour les tests fonctionnels c’est différent. Il faut un environnement, une base de donnée et potentiellement un jeu de donnée.

Passons donc aux choses sérieuses.

Symfony permet de créer différents environnements, typiquement dev et prod. Les besoins ne sont pas les mêmes, en dev on a besoin de debug, de sandbox, etc. En prod on a besoin de cache, etc. On va donc commencer par mettre en place en environnement pour les test et faire en sorte qu’il soit le plus petit et le plus indépendant possible.

À la création d’un projet Symfony 2, l’environnement de test est déjà créé, il nous reste à le customiser.

# app/config_test.yml

doctrine:
    dbal:
        driver:     pdo_sqlite
        path:       %kernel.root_dir%/var/test.db
        user:       root

On va donc dire à symfony qu’on veut utiliser sqlite comme base de donnée car les jeux de données sont petit et qu’on a pas besoin de performance. J’ai choisi de stocker la base dans un fichier, mais il est très bien possible de la stocker en mémoire en remplaçant l’option path par memory: true.

Ensuite pour exécuter sa suite de tests, il faut un bootstrap pour initialiser une requête d’un test fonctionnel. La le problème c’est que le bootstrap.php.cache de symfony de base va seulement faire un autoload des vendors et initialiser le kernel. Avec un environnement de test il faut monter une base donnée, créer les tables et charger les fixtures. Il est possible de dire à phpunit d’utiliser un fichier de bootstrap spécifique qui va faire les choses à notre place.

<!-- app/phpunit.xml.dist -->

<phpunit
    bootstrap = "tests.bootstrap.php" >

Dans ce fichier on indique à phpunit d’utiliser un fichier spécifique pour exécuter nos tâches de bootstrap.

<?php
// app/tests.bootstrap.php

if (isset($_ENV['BOOTSTRAP_DB_ENV'])) {
    passthru(sprintf(
        'rm "%s/var/test.db"',
        __DIR__
    ));
    passthru(sprintf(
        'php "%s/console" doctrine:schema:update --force --env=%s',
        __DIR__,
        $_ENV['BOOTSTRAP_DB_ENV']
    ));
    passthru(sprintf(
        'php "%s/console" doctrine:fixtures:load --append --env=%s',
        __DIR__,
        $_ENV['BOOTSTRAP_DB_ENV']
    ));
}

require __DIR__.'/bootstrap.php.cache';

Dans ce fichier on liste les tâches à exécuter si la variable d’environement BOOTSTRAP_DB_ENV est définie. Là on indique qu’on veut supprimer la base de test existante, créer le schéma et charger les fixtures.

Ensuite pour définir cette variable d’environnement, il faut rajouter ceci dans son fichier phpunit.xml.dist

<!-- app/phpunit.xml.dist -->

<php>
    <env name="BOOTSTRAP_DB_ENV" value="test"/>
</php>

Cette modification va permettre de créer une fase de donnée et de charger les fixtures, nécessaires à l’exécution de la suite de tests.

Désormais, lors de l’exécution de bin/vendor/phpunit la base de données de test sera supprimée, créée et les fixtures seront chargées avant d’exécuter les tests.

Ensuite il faut dire à Jenkins de récupérér composer et d’installer les vendors avant de lancer phpunit.

<!-- build.xml -->

<target name="composer" depends="clean" description="Download composer and install project dependancies">
     <exec executable="wget" failonerror="true">
        <arg value="-nc" />
        <arg value="http://getcomposer.org/composer.phar" />
    </exec>
    <exec executable="php">
        <arg value="composer.phar" />
        <arg value="config" />
        <arg value="--global" />
        <arg value="github-oauth.github.com" />
        <arg value="github_oauth-key" />
    </exec>
    <exec executable="php" failonerror="true">
        <arg value="composer.phar" />
        <arg value="install" />
        <arg value="--dev" />
        <arg value="--prefer-dist" />
        <arg value="--no-progress" />
        <arg value="--no-interaction" />
        <arg value="--no-scripts" />
    </exec>
</target>
<target name="phpunit" description="Execute tests">
    <exec executable="${basedir}/vendor/bin/phpunit" failonerror="true">
        <arg value="-c" />
        <arg path="${basedir}/app" />
    </exec>
</target>

Le paramètre github-oauth.github.com sert a passer sa clé oauth à composer pour éviter les problèmes de fair-use avec l’api github.

Cette tâche ant va donc dire jenkins de télécharger composer, de configurer la clé oauth github et ensuite de lancer l’installation des vendors en utilisant --prefer-dist qui permet de récupérer en priorité les archives plutôt qu’un git clone. L’exécution des scripts est la aussi inutiles car tout les scripts nécessaires sont lancés par le bootstrap de test.

La deuxième tâche sert a lancer phpunit avec le fichier de config situé dans app/.

En configurant Jenkins au post-receive git, l’exécution des tests sera faite à chaque git push. Pour finir il suffit d’activer les rapports nécessaires jenkins pour avoir des statistiques sur son dashboard projet.

J’espère que ça vous sera utile. Bonne journée.

Corriger le problème de GDM sur Archlinux après la màj 3.8

2013-05-25T00:00:00+00:00

Bonjour,

Je ne pense pas être le seul a avoir eu ce problème étant donné qu’il est dans le wiki d’Archlinux. Après la dernière mise à jour majeur de gnome vers la version 3.8, gdm ne se lance plus et impossible de trouver pourquoi dans les logs. Le problème vient de la méthode d’accélération du pilote graphique intel. Par défaut c’est UXA qui est plus stable techniquement mais qui est plus lente que la méthode SNA. Il faut donc changer de méthode pour passer à SNA qui est plus rapide et nécessaire pour gnome.

#/etc/X11/xorg.conf.d/20-intel.conf

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
EndSection

Il suffit de redémarrer et le tour est joué.