3 présentations #Python ce soir, 18h00 en attendant la PyConFr, sur le BBB de l'AFPy → https://discuss.afpy.org/t/en-attendant-la-pyconfr-du-15-avril-2021/222/13

Lightnings talks #Python sur notre BBB demain, venez nombreux : https://discuss.afpy.org/t/conferences-du-15-avril-2021-18h00/222

Entreprise à la pointe de la technologie et engagée dans le « mieux consommer ». Nous recherchons aujourd’hui un Lead Dev backend/fullstack. Il s’agit d’une création de poste dans le but de développer une plateforme afin d’accompagner toujours mieux nos clients. Missions Missions : 70% de technique (dev) et 30% de management. Participation à l’élaboration architecturale des nouveaux modules ainsi qu’aux choix des technologies Encadrement des équipes : équipe de 3 personnes (2 back / 1 front). Objectif : monté en compétences afin qu’ils deviennent fullstack Stack technique Python/ Django VueJS Azure PostgreSQL Profil recherche Minimum 5 ans d’expérience sur du développement Python Bon/ne communiquant/e Expériences en management d’équipe apprécié Avantages Perspective dévolution RTT 2 jours de remote / semaine après Covid Mutuelle

Internet adore les yoyos technologiques, alternants l'enthousiasme d'un pionnier bricolant un produit attirant du monde, avec des clones, puis de la normalisation, qui seront adoptés par les suiveurs, et le contexte évoluant, nouveau produit, nouveau yoyo.
Dans cet article, nous vous présentons ces solutions. Okay, il n'y a pas 10 exemples et le dernier est moins surprenant qu'enthousiasmant. C'est le 1er avril il faut nous excuser pour le titre piège à clics.
Discuter
talk est plus vieux qu'UNIX, mais il traine encore sur les Linux et OS X contemporains, et permet à plusieurs utilisateurs d'une même machine de discuter ensemble.


talk




✅ 1 à 1


❌ groupe


❌ serveur



Plus tard, en 1988, apparaitra irc, pour discuter depuis des machines distantes, en se connectant à un serveur. Il existe des passerelles web comme Kiwiirc, et il vous faudra rapidement un bouncer comme ZNC pour ne pas perdre le fil des discussions.


irc




✅ 1 à 1


✅ groupe


✅ serveur


✅ commandes


❌ authentification


❌ présence


❌ hors ligne



Pour accompagner la démocratisation d'Internet et l'arrivée fracassante du web, icq est apparu en 1996. Premier arrivée d'une longue lignée de service de tchat propriétaire et exclusif, avec des vagues successives, avec parfois des rachats, mais toujours une grosse fascination pour isoler les communautés entre elles.


icq




✅ 1 à 1


✅ groupe


✅ serveur


✅ présence


✅ hors ligne


✅ écrit…


❌ protocole public


❌ passerelles


❌ web



Le Minitel, les SMS et les pagers, ça ne compte pas : ce n'est pas Internet, mais clairement, ils ont servi d'inspiration pour la suite.
Normaliser les protocoles
Une première tentative de rapprochement des réseaux se fait avec des clients multi-protocoles, se basant par exemple sur libpurple.
Louable effort permettant de limiter le nombre de logiciels à lancer pour discuter avec des personnes dispersées sur différents réseaux, ça ne résout en rien les groupes de discussions, et pas grand-chose pour le chiffrage de bout en bout.
Pour résoudre le problème d'interopérabilité entre différents services, bah, il suffit d'écrire un nouveau protocole qui fait mieux que tout le monde, et de proposer des passerelles vers les vieux services.
XMPP
XMPP proposa en 1998 d'écrire des tonnes de spécifications (les XEPs), pour faire mieux que tout ce qui existait actuellement. XMPP amène la notion de syndication, qui permet à un utilisateur sur un serveur de discuter avec un autre utilisateur sur un autre serveur, comme le propose le mail depuis toujours.
Collision de dates, XMPP rate l'arrivée du Web interactif, et surtout des smartphones.
Ils ont aussi raté l'arrivée des discussions chiffrées, des groupes de discussions, et de la fin de l'hégémonie du XML. Mais ils ont tout spécifié, tellement spécifiés qu'aucun client n'implémente suffisamment de fonctions parmi la pléthore de XEP, et c'est mission impossible pour trouver deux clients qui donnent envie, avec des fonctions qui se recoupent.
XMPP a des implémentations serveur correctes (le terrifiant Ejabberd ou le contemporain Prosody), mais les clients sont tous vieillissants, et le protocole n'est pas adapté aux connexions intermittentes des réseaux de téléphonie mobile.
XMPP a raté sa chance de devenir hégémonique, tout comme XHTML, XSLT, Atom et SOAP, mais ce n'est pas grave.
XMPP a un retour de visibilité avec WebRTC, qui a besoin d'établir des connexions entre utilisateurs en se gardant bien de préciser comment, et oui, XMPP est tout à fait adapté à ce genre d'usage. Jitsi, le boss de la visioconférence libre, s'appuie sur Prosody pour gérer les utilisateurs et les groupes de discussions, mais sans trop se soucier de la possibilité qu'un client autre que l'application web se connecte, ou même de la syndication de serveurs à serveurs.


xmpp




✅ 1 à 1


✅ groupe


✅ serveur


✅ présence


✅ hors ligne


✅ écrit…


❌ images/vidéos


❌ appel voix/vidéo


✅ protocole public


✅ passerelles


✅ web


✅ syndication de serveurs


❌ utilisateurs


❌ chiffrage bout en bout


❌ adapté smartphone



La discussion d'entreprise
Slack a un peu surpris tout le monde, en proposant un tchat web, en ciblant les entreprises. Techniquement, ça ne fait que reprendre la notion des forums, mais avec plus de temps réel, une vraie UX, des CSS décentes.
Slack est conçu pour fonctionner dans un navigateur web (pas de soucis de logiciel à déployer et mettre à jour), avec du texte, mais en reprenant la notion de commandes d'irc (avec des lignes du type /command)
Slack propose un client lourd, qui est un peu ce que l'on peut faire de pire avec Electron. 2Go de RAM pour échanger du texte et des smileys, ce n'est pas raisonnable.
Slack est devenu un standard de fait, et permet au sein d'une entreprise (avec confidentialité et horaires) d'avoir des discussions en ligne.
Mattermost
Il existe un clone de qualité, Mattermost, qui reprends verbatim le même système de webhook que Slack, pour qu'une application puisse simplement envoyer des messages sur un chan.
On échappe au client lourd, mais il y a un client smartphone, et même un client curse, en mode texte, en haskell.
Mattermost propose une API REST complète, mais n'a pas vocation à être intégré dans un client multiplateforme, ni à faire partie d'une syndication.
Mattermost évolue maintenant pour proposer des workflows, comme les sondages, la résolution collaborative d'incidents ou les réunions standup.
Mattermost propose une intégration aux outils de visioconférence comme Jitsi.
Les tchats d'entreprise ne sont pas conçus pour chiffrer les discussions entre personnes, et ont même tendance à tout indexer, avec des volontés claires d'indiscrétion pour Slack. La connexion TLS protège juste des indiscrets de l'extérieur.


Mattermost




✅ 1 à 1


✅ groupe


✅ serveur


✅ présence


✅ hors ligne


✅ écrit…


✅ images/vidéos


✅ protocole public


✅ passerelles


✅ web


✅ commandes


❌ chiffrage bout en bout


❌ adapté smartphone



Discuter dans des groupes chiffrés
Whatsapp et Signal ont démontré qu'une application de discussions instantanées conçue initialement pour les smartphones, axée sur les groupes, les images, les vidéos et surtout du chiffrage de bout en bout, avait une efficacité redoutable.
Conçu pour smartphone, ces applications ont besoin de votre 06, et les versions desktop sont considérées comme secondaires et il faut les apairer avec son smartphone.


Signal




✅ 1 à 1


✅ groupe


✅ serveur


✅ présence


✅ hors ligne


✅ écrit…


✅ images/vidéos


✅ appel voix/vidéo


❌ protocole public


❌ passerelles


❌ web


❌ syndication de serveurs


✅ chiffrage bout en bout


✅ utilisateurs


✅ adapté smartphone



Sur un smartphone, pour ne pas manger toute la batterie, il ne faut pas qu'une application gère un flot descendant intermittent. Recevoir des évènements ("vous avez un nouveau message") qui vont arriver de temps en temps, n'importe quand, est le pire usage possible du réseau pour un smartphone. C'est pour ça que le smartphone va le gérer à votre place, en prenant en compte les stratégies de mise en veille de certains éléments du téléphone, ou des spécificités des protocoles utilisés en téléphonie. Ce système de notification s'appelle APNS chez iOS, et Notifications chez Android.
Avec les notifications natives, il est donc possible d'avoir une application qui ne mange pas toutes les piles, ce qui est un prérequis.
L'autre point important pour du tchat moderne est le chiffrage de bout en bout, pour rendre impossible la censure. Le chiffrage entre deux clients est maitrisé depuis longtemps, mais pour les groupes, il faut un truc un peu plus moderne : le double ratchet de Signal.
Telegram, clone russe de Signal, reprends les fonctions de son concurrent, en apportant un soin pour avoir un vrai client desktop, sans passer par Electron, et en proposant une API complète avec widget web, bot et de quoi coder un client.
Matrix
What is the matrix?

Matrix se positionne clairement comme un remplaçant libre de Whatsapp et Signal, avec de la syndication de serveur, et le smartphone comme première cible. La voip, grace à webrtc, en tête à tête fait partie des fonctions de base.

Pour faire ça proprement, Matrix a plein de specs.
Cette stratégie reprends celle de XMPP, mais sans le XML, et en gardant HTTP.
Matrix.org fournit un serveur en Python, Synapse qui est l'implémentation de référence, mais ils en ont aussi un second, en Golang Dendrite. Matrix.org fournit plein de SDK, mais pas de client de référence, pour ça, il faut aller voir Element.
Profitant de son statut de standard, de l'API REST et des SDKs, il commence à y avoir des projets qui intègre le protocole Matrix, comme Thunderbird ou même l'état français avec Tchap, qui est un fork de Riot, le prédécesseur de Element.
Oui, il existe un plugin weechat pour profiter de matrix dans votre terminal.
Pour les passerelles, Matrix est très agressif en proposant plein de bridges ciblant autant des produits propriétaires que libre.


Matrix




✅ 1 à 1


✅ groupe


✅ serveur


✅ présence


✅ hors ligne


✅ écrit…


✅ images/vidéos


✅ appel voix/vidéo


✅ protocole public


✅ passerelles


✅ web


✅ commandes


✅ syndication de serveurs


✅ chiffrage bout en bout


✅ adapté smartphone


❌ utilisateurs



Internet gagne toujours à suivre des normes pour avoir des outils interopérables, et laisser voguer la créativité des développeurs, plutôt que de subir des coups de GAFA sur le coin de la tête.
Matrix part sur de bonnes bases, mais, stable depuis 2 ans, avec seulement deux implémentations du serveur, il n'a pas encore subi le baptême du feu.
À suivre, donc.

Saint-Mandé, France, ou bien en télétravail à 100%. Temps complet

Vous avez raté l'édition précédent de "En attendant la PyConFR
" ? Pas de problème ! Toutes les présentations et lightning talks sont désormais disponibles en vidéo ici : https://discuss.afpy.org/t/conferences-du-18-fevrier-2021/162/23 ! Bon (re-)visionnage !

#python

Bonjour les francophones, la documentation #Python a de nouveau besoin de vous ! Venez rejoindre nos vétérans de la traduction ce mercredi 24 mars à 18h30 sur notre BBB, toutes les bonnes volontés sont le bienvenu ! https://bbb.afpy.org/b/jul-fss-kpj-txw

"En attendant la @PyConFR" c'est maintenant !
👍
https://bbb.afpy.org/b/jul-fss-kpj-txw

N'oubliez pas ce soir à 19h c'est notre édition mensuelle de "En attendant la @PyConFR
". Au programme : Lightning Talks #Python. Retrouvez nous sur notre BBB https://bbb.afpy.org/b/jul-fss-kpj-txw et n'hésitez pas à proposer des nouveaux sujets sur notre Discuss https://discuss.afpy.org !

Petite soirée conférences en attendant la PyCon Fr : https://discuss.afpy.org/t/conferences-de-mars-2021/193 mercredi 17 mars 19h00 sur notre BBB : https://bbb.afpy.org/b/jul-fss-kpj-txw

Il reste des slots, si vous voulez présentez un truc, venez nous en parler (sur http://discuss.afpy.org).

Grafana, Influxdb et Telegraf permettent de moissonner vos mesures, mais parfois, il est necessaire d'aller plus loin et de créer son propre capteur.
Qu'il s'agisse d'améliorer les performances, benchmarker différentes pistes, auditer un soucis de perf ou tout simplement maintenir un service, il est important de pouvoir prendre son pouls.
Dans cet article nous vous présentons une maquette fonctionnelle complétant une stack standard de récupération et de visualisation de données pour l'adapter à vos besoins.
Grafana
Grafana est la réponse. Quel que soit vos choix, ils seront visualisés par Grafana au moins, et si vous en avez le besoin par d'autres outils.
Influxdata
Influxdata propose un ensemble cohérent d'outils pour collecter des données, les enregistrer, les requêter et finalement les afficher dans Grafana.
+----------+ +----------+ +---------+
| Telegraf +-->| Influxdb |<---+ Grafana |
+----------+ +----------+ +---------+

Telegraf
Telegraf est le collecteur d'Influxdata.
Architecturé sur un ensemble de plugins (aggregateurs, entrées, sorties, parseurs, processeurs, serialiseurs), ce sont ici les inputs qui nous interessent, et l'outil propose une longue liste d'inputs.
Une large partie des inputs est dédiée à un service précis.
Certains inputs "service" permettent de faire des requêtes libres, comme le propose redis et postgresql_extensible), mais rien pour les autres bases de données (mariadb a pourtant des trucs à dire).
Une partie des inputs est générique et permet de récupérer des informations variées :

procstat mais cgroup sera plus efficace
tail
exec
execd

Les inputs peuvent requêter des services distants :

http
prometheus
snmp
amqp_consumer
kafka_consumer
kinesis_consumer
mqtt_consumer
nats_consumer
nsq_consumer
postgresql_extensible

Les inputs peuvent être un service réseau, et attendre des métriques poussées par divers clients.

influxdb_listener
statsd (avec l'option tag, à la Datadog)
webhooks
riemann_listener

La liste des plugins est conséquente, mais il est quand même possible de ne pas trouver l'input qu'il nous faut.
Il est important d'instrumenter les applications que l'on développe, mais qu'en est-il pour un service existant ?
La sonde prometheus gagne son status de standard de fait et se trouve dans beaucoup de services modernes. Il existe des exporter tout prêt comme blackbox_exporter.
Par contre, coder un agent, juste pour exposer un endpoint prometheus n'est pas raisonnable.
Développer un agent qui va causer influxdb ou statsd est faisable, mais bon, on perds la centralisation du tempo de la mesure, et ça fera un systemd de plus.
La réponse officielle de telegraf pour récupérer des données spécifiques est exec ou mieux, execd.
exec va lancer une commande à chaque fois, et parser STDOUT. Simple, mais ça implique de lancer une commande plusieurs fois par minute.
execd va lui aussi lancer une commande, mais sans l'éteindre, et il redemandera à chaque fois une nouvelle réponse (toujours sur STDOUT).
La commande pourra réagir à une nouvelle ligne dans STDIN, un signal UNIX, ou se contenter d'écrire périodiquement de nouvelles choses dans STDOUT.
telegraf recommande la première approche : STDIN, qui fonctionnera aussi sur Windows.
Telegraf utilise des plugins pour parser les mesures, et son format de prédiléction est celui d'Influxdb, le line protocol.
Un service avec execd
Voici un exemple simple de l'utilisation d'execd avec python.
Configurer un inputs.execd est trivial, il faut choisir une commande, un signal et un format.
[[inputs.execd]]
## One program to run as daemon.
## NOTE: process and each argument should each be their own string
command = ["./my_command.py"]

## Define how the process is signaled on each collection interval.
## Valid values are:
## "none" : Do not signal anything. (Recommended for service inputs)
## The process must output metrics by itself.
## "STDIN" : Send a newline on STDIN. (Recommended for gather inputs)
## "SIGHUP" : Send a HUP signal. Not available on Windows. (not recommended)
## "SIGUSR1" : Send a USR1 signal. Not available on Windows.
## "SIGUSR2" : Send a USR2 signal. Not available on Windows.
signal = "STDIN"

## Delay before the process is restarted after an unexpected termination
restart_delay = "10s"

## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "influx"

Le line-protocol est simplissime :
measurement[,tags] fields [timestamp]

measurement est le nom de la mesure.
Les tags sont un ensemble de clef=valeur séparés par des ,, qui permettront de regrouper/filtrer les mesures. Attention de ne jamais avoir de tag qui peut avoir un grand nombre de valeur (comme un id unique).
Les fields sont un ensemble de clef=nombre séparés par des ,.
timestamp n'est pas utilisé, ce sera à Telegraf de le gérer.
En python, l'implémentation du line-protocole va donner ça :
def marshal(dico):
return ",".join("=".join(t) for t in sorted(dico.items()))


# https://docs.influxdata.com/influxdb/v2.0/reference/syntax/line-protocol/
def write(writer, measurement, tags={}, fields={}):
"Writes to the Influxdb's line protocol"
print(measurement, ",", marshal(tags), " ", marshal(fields),
sep='', file=writer)

La commande sera une boucle sur STDIN, qui ira chercher plusieurs mesures, et les affichera formaté sur STDOUT
for _ in sys.stdin: # execd protocol, newline trigger fresh stats
for tags, fields in fetch_my_measurements():
write(sys.stdout, "my_measurement", tags, fields)

Il faut bien sûr écrire son bout de code métier dans fetch_my_measurements, qui va yield des tags et des fields.
Telegraf permet simplement de tester un bout de config.
Il va lancer la récolte de mesure une fois, il l'affichera sur STDOUT ce qu'il enverrait à Influxdb (le line-protocol), sur STDERR les trucs bizarres, et stoppera. Attention à tester avec l'utilisateur telegraf (avec sudo ou gosu selon votre chapelle) si vous avez des contraintes de sécurité basées sur l'utilisateur.
telegraf --config my_command.conf --test

Au delà de d'influxData et Grafana
Il est aisé de récupérer des mesures précises pour comprendre le comportement de votre application en prod, de les stocker, et d'explorer depuis Grafana.
Vous pouvez maintenant partir à la recherche de nouvelles sources, et Linux (le kernel) bosse beaucoup sur ce sujet, cgroup est là depuis longtemps, mais ebpf devrait enfin amener les outils qui faisaient la réputation de Solaris.
Garder un oeil sur le sniffing réseau, avec pcap et ses successeurs, avec packetbeat comme hérault.
Niveau applicatif, statsd fait le job, prometheus est la norme inévitable, mais la fusion entre mesure, trace et log avance bien avec opentelemetry d'un coté, et l'omniprésent Grafana de l'autre (avec Loki qui vient de sortir sa 2.2, et Tempo qui souhaite piquer la place de Jaeger).
Et voilà !
Voila, vous êtes maintenant capable d'aller chercher les mesures nécessaires à la compréhension de vos soucis de performances, et de valider vos hypothèses en regardant ce que ça change au niveau des métriques.

Pour nous accompagner dans notre quotidien, nous sommes à la recherche d'un·e développeur·se passionné·e et ayant envie de s’impliquer dans un projet novateur et ayant du sens. Vous renforcerez notre équipe sur des problématiques d'infrastructures, d'architectures, de scaling, de traitement et stockage de données et vous serez en charge des tâches d'administration système, de maintenance de l'infrastructure, du déploiement des applications et des problématiques de performance. Une connaissance de Python est un plus. Stack technique : Backend : Django, Postgres, Kafka Frontend : Angular Infrastructure: OVH, Docker, OpenShift / k8s Process: Bitbucket, Jenkins Vos qualités : - Vous appréciez travailler dans le cadre dynamique et porteur d’une jeune entreprise innovante en plein essor : vous n’avez pas peur du changement et de l'autonomie, - Vous vous familiarisez rapidement avec de nouveaux systèmes et concepts, - Vous aimez votre code propre, élégant et savez écrire les choses avec simplicité et pragmatisme, - Vous êtes précis·e, rigoureux·euse et prévoyant·e : vous avez l'ambition de développer des systèmes fiables, tolérants aux pannes et performants, - Vous savez que votre responsabilité ne s’arrête pas au déploiement, et vous vous souciez de la bonne qualité de l’expérience utilisateur, - Vous communiquez aisément : vous n’hésitez pas à poser des questions, à donner votre avis et émettre des suggestions lorsque cela est pertinent, et vous n’hésitez pas à mettre votre expérience au profit d’idées novatrices, - Vous avez le sens du travail en équipe, nécessaire dans le contexte de développement d’une startup. Nous rejoindre c'est: - une startup innovante et en pleine croissance, - une équipe bienveillante, ambitieuse, persévérante, et à échelle humaine, - une ambiance agréable, stimulante, avec des événements internes et des moments de partage, - une ville vivante avec un fort patrimoine culturel et historique et régulièrement classé parmi les villes les plus attractive de France: Strasbourg

C'est sur notre BBB perso : https://bbb.afpy.org/b/jul-fss-kpj-txw

N'oubliez pas ce soir à 18h30 : c'est lighting talks ! Venez partager vos retours d'expériences, vos succès ou vos échecs, ainsi que vos découvertes autour de #Python avec nous ! #AFPy

https://discuss.afpy.org/t/calendrier-de-lafpy/64/13?u=mdk

Our unique technology constantly scans the corners of the Internet and retrieves billions of documents every day! We develop intelligent algorithms to automatically analyze this massive data, in real-time. In this context, the web platform team is in charge of developing and maintaining all the tools our cybersecurity analysts and our customers use to filter out, augment and more generally make sense of digital threat alerts. The main challenges we face, product-wise, are to show this huge amount of information in the most comprehensible way possible as well as to make the tools fast enough so they don’t get in the way. Technically, we deal daily with the whole stack: from the massive amount of indexed data to the responsive UI we show our users, through relational and no-SQL databases and home-built APIs. We are hiring experienced Fullstack Software Engineers to help get us to the next level by developing a single, unified product out from the various tools we have built so far, as well as guide us in the design of a brand new, public API to allow our customers and partners integrate with our product.

Python Engineers (mid-senior level) needed in Paris to work on greenfield design & builds of massive-scale data computation platforms for quantitative trading.