Support de "unmerdify", par @vjousse. Unmerdify est une libraire qui va parser les pages HTML en utilisant les règles FiveFilters afin d’en extraire le contenu intéressant et jeter tout les reste.
Nous recherchons un·e développeur·se avec déjà une première expérience professionnelle significative en Python pour poursuivre le développement de nos services. Avoir également de l’expérience avec Vue, Typescript, Docker ou Ansible est un plus.
Type d’emploi : CDI ou CDD, temps plein ou 4/5, poste sur Nantes (présentiel mini 2/3 jours par semaine) Ce n’est pas un poste de data scientist.
Qui est OctopusMind ?
OctopusMind, spécialiste de l’Open Data économique, développe des services autour de l’analyse des données. Nous éditons principalement une plateforme mondiale de détection d’appels d’offres : www.j360.info
L’entreprise, d’une dizaine de personnes, développe ses propres outils pour analyser quotidiennement une grande masse de données, en alliant intelligence humaine et artificielle www.octopusmind.info
Nous recherchons pour ce poste un collaborateur habitant à proximité de Nantes.
Nous vous proposons
L’équipe IT, sans lead developer, est en lien avec l’équipe R&D ML et l’équipe de veille des marchés. Nous suivons un SCRUM maison, ajusté régulièrement selon nos besoins. Nous discutons ensemble de nos priorités et nous les répartissons à chaque sprint selon les profils et envies de chacun·e.
Vous participerez :
Au développement back de j360 et son back-end (Python/Django, PostgreSQL, ElasticSearch).
Aux scripts de collecte de données (Python/Scrapy).
À la relecture de code et l’accompagnement vos collègues en leur fournissant du mentorat sur les bonnes pratiques, l’architecture, les design patterns, etc.
En fonction de vos centres d’intérêts :
Au développement front de l’application j360 (Vue3/Quasar/Typescript).
Au déploiement des applications (Docker/Docker-Compose, Ansible) et intégration des services R&D (Gitlab CI).
À la réflexion produit, analyse technique et à la définition des priorités de l’entreprise (Trello).
À l’ajustement de nos méthodes de travail au sein de l’équipe et de l’entreprise.
Avantages :
Horaires flexibles - RTT - Titres-restaurant - Participation au transport - Épargne salariale - Plan d’intéressement et plan épargne entreprise
Télétravail/présentiel
Statut cadre en fonction du diplôme/l’expérience (Syntec)
Processus de recrutement :
Les candidatures “one clic” ne sont pas regardées. Si vous prenez le temps de faire une candidature personnalisée, nous l’étudierons; sinon ne perdez pas votre temps, envoyez votre candidature à une ESN car on a pas de baby foot.
CV + présentation de vous et de ce qui vous intéresse à adresser par mail à job @ octopusmind.info
Vous pouvez illustrer vos compétences techniques avec des exemples de projets ou passer notre test technique.
Echanges et précisions par mail ou téléphone
Entretien dans nos bureaux à Nantes
Offre (salaire en fonction de l’expérience/niveau)
SVP pas de démarchage pour de l’outsouring ou cabinet RH, merci
Qui n'a pas rêvé de faire sa console de pirates qui contrôle ses agents au doigt et à l'œil traditionnellement sur IRC ?
C'est le principe d'un Control & Command parfois appelé C&C pour les botnets. Mais ici, on en fait un éducationnel.
Il s'agit de piloter des agents à distance en leur envoyant des commandes sur un BUS qui résulte dans des actions prédéfinies comme :
- arrêtes toi,
- reprends,
- dis si tu es présent et en vie …
Ci-suit un petit exemple en python de l'implémentation d'une telle logique en moins de 100 lignes de codes
Ingrédients
Cette recette nécessite : python, et en dépendances : paho-mqtt, confined, ainsi qu'un serveur MQTT (mosquitto avec ses utilitaires en ligne de commande) correctement configurés.
La pièce de résistance
Pour tout process que l'on veut piloter on va écrire du code python comme :
importpaho.mqtt.clientasmqttfromtimeimporttime,sleepfromconfinedimportparse,Value,popfromsubprocessimportPopen,PIPEimportpathlibimportosimportsocketstack=[]client_id=socket.gethostname()show_must_go=Falsedefon_connect(client,userdata,flags,reason_code,properties):print(f"Connected with result code {reason_code}")client.subscribe(f"BUS/{client_id}")client.subscribe(f"BUS")defon_lun(*a,**kw):kw["ctx"]["state"]="RAZ"defon_set_time_slice(*a,**kw):kw["ctx"]["time_slice"]=stack.pop().floatdefon_ping(*a,**kw):globalclient_idclient=kw["ctx"]["client"]client.publish("RES",f"'{client_id}':PONG")defon_sel(stack,**kw):globalclient_id,show_must_goifstack.pop().str==client_id:show_must_go=Truedefon_unsel(stack,**kw):globalclient_id,show_must_goifstack.pop().str==client_id:show_must_go=Falsedefon_test(stack,**kw):print("Yo")ctx=dict(cap=["www","forth"],time_slice=10,dispatch=dict(lun=on_lun,ping=on_ping,sel=on_sel,unsel=on_unsel,tsset=on_set_time_slice,_TEST=on_test,),)defon_message(client,userdata,msg):globalstack,ctxctx["client"]=clientclient.publish("RES",str(parse(ctx,msg.payload.decode(),data=stack,)))mqttc=mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,client_id=client_id)mqttc.on_connect=on_connectmqttc.on_message=on_messagemqttc.username="pub"mqttc.password="pub"mqttc.tls_set(keyfile="./cfg/pub.key",certfile="./cfg/pub.crt",ca_certs="./cfg/RootCA.crt",tls_version=2)mqttc.connect("badass.home",8883,60)mqttc.loop_start()os.chdir(os.path.dirname(__file__))plugins=pathlib.Path("../plugin")whileTrue:start=time()ifshow_must_go:forpinplugins.glob("*_enabled"):withPopen([p,],stdout=PIPE,stdin=PIPE,stderr=PIPE,bufsize=0,)aswriter:whileres:=writer.stdout.read():writer.stdout.flush()formsginres.split():mqttc.publish(f"DATA/{client_id}",msg.decode())mqttc.publish("DATA/",f"{client_id}:core.processing_time:{time()-start}:GAUGE")iftime()-start<ctx["time_slice"]:sleep(ctx["time_slice"]-(time()-start))
Le client est en mode parano : TLS activé avec login/pass enforcé coté serveur par MQTT.
Trop petit pour être un projet, ultra dur à tester, mais assez rigolo pour être utile
Des idées de futurs ?
Un projet « Bus Of Things » (BOT) qui standardiserait les commandes envoyées et leurs API pour faire comme une sorte d'ansible.
Une logique d'IPC/messaging générique pour des systèmes distribués (inclurais la gestion de process & co).
Un FORTH qui verrait toute fonction/agent comme reliée à un BUS MQTT et pour lequel les messages serait du FORTH qui agirait sur la fonction que s'appelerio objective FORTH. (Ça implique de sacrément développé la partie langage).
Pleins d'idées, trop d'idées …
Les sorties actuellement ressemblent au format d'entrée … C'est suspect non ?
Oui, j'ai envie de tester de laisser l'orchestrateur accepter des injections de code depuis les agents. Ex légitime, quand une sonde de mesure est en OVERRUN (trop de temps passé à mesurer comparé à une cadence attendue) qu'elle puisse changer la « clock » avec TSSET de l'orchestrateur.
J'ai envie d'expérimenter des systèmes scheduler less où chaque agent peut devenir le contrôleur et prendre la main et/ou modifier l'orchestrateur qui envoie les commandes.
.