L'assemblée générale de l'association aura lieu en visioconférence ce vendredi 30 octobre 2020 à partir de 16h, venez nombreux !

Nous recherchons une ou un développeur(se) avec déjà une première expérience significative en python/open source pour poursuivre le développement de nos services autour de l'analyse de données. Vous souhaitez développer des briques innovantes front ou back autour de la data, contactez-nous ! Ce n'est pas un poste de data scientist même si vous pourrez y goûter...

Groover est une plateforme web grâce à laquelle les artistes peuvent envoyer leur musique à une sélection de médias, labels & influenceurs musicaux, et sont assurés d'avoir un retour dans la semaine sur leur musique, et bien souvent de nouvelles opportunités (playlists, radios, articles etc.) Nous cherchons un stagiaire Backend Developer pour rejoindre l'équipe technique de Groover.

Groover est une plateforme web grâce à laquelle les artistes peuvent envoyer leur musique à une sélection de médias, labels & influenceurs musicaux, et sont assurés d'avoir un retour dans la semaine sur leur musique, et bien souvent de nouvelles opportunités (playlists, radios, articles etc.) Nous cherchons un Ingénieur Backend pour contribuer au développement du produit et à la qualité du code backend.

Nous recherchons une personne expérimentée en Python et Django avec au moins une expérience de développement front-end sur Vue.js où autre framework Javascript. Les responsabilités à prendre sont ouvertes et nombreuses. Notre startup vient d'être selectionnée par un accélarateur majeur de la côte Est américaine. L'équipe est internationale et fonctionne à distance et en Anglais. Cf. offre d'emploi en attachement.

Tour d'horizon de la dernière version du célèbre langage de programmation

Adaptive Channel est spécialisée dans le développement et la distribution de contenus presse et vidéo à bord des avions. Société de 10 personnes créée en 2009, nous travaillons avec les plus grands partenaires du monde de l’In Flight Entertainment (IFE) basés dans la Silicon Valley et avec les plus grandes compagnies aériennes internationales. Adaptive Channel est à la recherche d’une personne pour rejoindre son équipe Back End.

Skilled Python Quantitative Developers needed to work on challenging problems at the intersection of technology and quantitative research.

Très souvent vous pouvez avoir deux styles de codes différents qui font la même chose en Python :

---

import os

if os.path.exists("fichier.txt"):
    os.unlink("fichier.txt")

---

import os
try:
    os.unlink("fichier.txt")
except OSError:  # levé si le fichier n'existe pas
    pass

---

Alors, lequel choisir ?

Personnellement, j’ai toujours préféré le premier choix, et pourtant… dans la documentation officielle, ils le déconseillent !

Pourquoi cela ? Explication : l’opposé de EAFP, c’est LBYL.

EAFP : Easier to ask for forgiveness than permission

Plus facile de demander pardon que la permission. Ce style de codage très utilisé en Python suppose l’existence de clés ou d’attributs valides et intercepte les exceptions si l’hypothèse s’avère fausse. Ce style propre et rapide se caractérise par la présence de nombreuses déclarations try and except. La technique contraste avec le style LBYL commun à de nombreux autres langages tels que C.

LBYL : Look before you leap

Réfléchir avant d’agir.

Ce style de codage teste explicitement les conditions préalables avant d’effectuer des appels ou des recherches. Ce style contraste avec l’approche EAFP et se caractérise par la présence de nombreuses déclarations if.

Dans un environnement multi-thread, l’approche LBYL peut risquer d’introduire une condition de concurrence entre « la vérification » et « la validation ». Par exemple, le code : if key in mapping: return mapping [key] peut échouer si un autre thread supprime la clé du mappage après le test, mais avant la recherche. Ce problème peut être résolu avec des verrous ou en utilisant l’approche EAFP.

Conseil d’un ami :

• gitlab n’est pas 100% opensource, ils proposent une édition communautaire limité et la totalité des fonctionnalités est dispo avec la version entreprise, leur modèle économique c’est de brider la version CEE (community) dans pas mal de coin pour te pousser à prendre une licence, perso je trouve que c’est plus un freeware qu’autre chose
• gitlab est pas mal mais honnêtement pour l’avoir beaucoup (vraiment beaucoup) utilisé dans le passé ce n’est pas la meilleur alternative.

Si tu cherche à mettre en place un truc je te conseille fortement de jeter un œil à :

• git –init bare
• Gitea (un exemple ici
• gerrit (un exemple ici)
• jenkins/zuul

Cette stack est un peu plus compliquée à mettre qu’un gitlab, mais c’est très puissant, surtout la partie gerrit qui transcende la manière de faire des revues de code.

Si le code Django / Python n’est pas correct, il y a des méthodes pour améliorer les choses notamment :

• https://nvie.com/posts/a-successful-git-branching-model/
• https://semver.org/

Il est également important de mettre en place un système de « core developer » même au sein d’un projet privé en entreprise, afin de garantir la cohérence des données et l’intégrité de l’historique. En effet, si tout le monde à les droits d’écriture sur tout, ça finira toujours à un moment donné à partir dans tous les sens… L’idée, c’est de donner les droits d’écriture à seulement 2-3 personnes de confiance qui ont un certain niveau et à tous les autres imposer de faire des forks dans leur namespace gitlab et de proposer des merge request (l’équivalent des pull requests avec github). Ainsi, la revue de code est obligatoire et il n’est plus possible de merger du mauvais code… et les développeurs « standard » (sans droits donc) ont juste 2-3 commandes de base à connaître pour bosser avec les autres. Sans ce genre de système cela ne peut pas réellement fonctionner car git à été developpé pour ce mode de fonctionnement (au même titre que svn et d’autres gestionnaire de version) et donc son workflow est idéal dans ce cadre.

Fonctionner comme ça m’a permis de :

1. coder un petit robot qui réagissait au merge requests proposé et donc qui checkait tout un tas de choses automatiquement et qui proposait des commandes si les choses n’allaient pas
2. responsabiliser les gens de l’équipe en les rendant responsables de leur propre forks
3. faire monter en compétence l’équipe qui était ultra frileuse à faire du versionning puis au final à pris goût au truc…

J’ai fais des petites formations au début pour leur expliquer l’intérêt et expliquer la sémantique des changement et qu’il est important de penser ses commits de manière propre. Cela permet :

• dans certains cas de retirer (revert) des bugs complet d’un seul coup,
• de faire du debug de manière automatique sans rien toucher et de trouver les changements responsable d’un bug (git bisect),
• de faire un gain énorme de qualité au final
• d’avoir des historiques clairs avec des messages de commit ayant une réelle plus value (exemple)
• d’automatiser tout un tas d’actions qui vont augmenter la qualité globale du projet et vont réduire les taches inutiles et donc laisser plus de temps pour les trucs fun à faire.

C’est gagnant gagnant, mais au début les gens râlent… il faut juste s’y préparer et avec le temps ils changent d’avis !

Dans le cadre d'un partenariat avec un acteur local du monde de l'assurance, nous recherchons un Lead Developpeur Full-Stack qui soit force de proposition en termes de choix techniques pour prendre en mains un tout nouveau développement novateur et ambitieux.

Nous vous offrons de co-construire votre poste idéal. Êtes-vous prêt·e à relever le défi ? ✓ le métier qui vous passionne, à votre rythme ✓ une équipe où règne bienveillance, confiance et reconnaissance ✓ le confort du salariat sans la pression hiérarchique ✓ la satisfaction d’entreprendre sans le stress d’être seul·e aux commandes