LeBouquetin a écrit 1916 commentaires

Les humantalks ciblent les développeurs : "Des Talks pour tous les développeurs". On reste cloisonné au sein d'un métier.

Les humantalks sont en général organisés le soir et ciblent des passionnés.

Là on ce que je présente marche bien, c'est qu'on cible une propagation des compétences est interne d'une entreprise (ça va intervenir sur tes heures de travail, pas te bloquer une soirée exprès pour), qu'on ne reste pas cloisonnés par métier, et en fait c'est une des clés de la réussite : apprendre des personnes qui ont d'autres problématiques, donc utilisent d'autres méthodes de travail, d'autres outils.

Ton lien est cassé (on peut le copier/coller, mais le clic foire)

Plus je réfléchis à ce que j'ai écrit (et à la réflexion qui m'y a amené) et plus je me dis que le vrai concept dans ce que je décris c'est vraiment le fait d'écrire du code "ready-to-refactor".

On a pensé à l'archi logicielle géniale, mais comme c'est pas un besoin explicite, on ne l'implémente pas mais on identifie l'endroit où ça doit/peut être refactorisé dans le code. Au minimum, on "centralise" le code crade.

Produire du code "ready-to-refactor" c'est aussi, par exemple ne pas implémenter les fonctionnalités "qu'on aimerait" mais qui :

1. ne sont pas demandées dès maintenant
2. ne remettent pas en cause l'architecture actuelle

Bref, le ready-to-refactor, c'est bon, mangez-en !

Ma version de "comment limiter l'over-engineering"

Définir le niveau d'engineering logiciel attendu

Tout comme un logiciel s'adresse à un public, un code source s'adresse à un public de développeurs.
Est-ce que l'équipe qui développe a vocation à être composée uniquement d'expert du language / de la technologie ? Est-ce que l'équipe est pluri-disciplinaire ? Est-ce que des débutants voire - allez soyons fous, des non-développeurs doivent intervenir et/ou comprendre le code source ?

Exemple : lorsque j'interviens sur des projets en Django, je refuse a priori d'utiliser les signaux. Pourquoi ? Parce que dans 90% des cas, c'est un mécanisme qui n'est pas nécessaire (on peut le remplacer par un appel explicite), et dans 100% des cas ça complique la compréhension du code. Certes, c'est un beau concept ; mais on peut faire la même chose avec des outils simples, alors pourquoi s'en priver ?

Autre exemple : je veux que le code développé par mon équipe soit autant que possible compréhensible par un débutant. Ce n'est pas toujours le cas, mais souvent cela limite la complexité autorisée et finalement, le résultat est le même (je ne travaille pas sur des sujets algorithmiques).

Favoriser la compréhension vs la "beauté" du code

Le fameux "DRY" (don't repeat yourself - ne te répète pas), les abstractions, la méta-programmation… cela rend le code aussi compliqué à comprendre/maintenir qu'un code monolithique développé par des débutants.

La factorisation doit intervenir quand elle apporte un réel plus, et quand elle ne nuit pas à la compréhension du code.

Une séance de debug qui nécessite de passer de plus de 3/4 fonctions/méthodes pour comprendre un mécanisme est significative d'un code trop complexe.

Avoir une bonne vision du projet, et la communiquer clairement

Avoir une bonne vision du projet permet de décider des développements nécessitant de l'anticipation (en terme d'architecture) et ceux qui n'en nécessitent pas. C'est parfois clair pour le décideur / chef de projet / responsable du développement, mais il faut aussi que les développeurs le sachent. Et quand ça ne l'est pas pour les responsables, deux possibilités : soit ils cherchent l'info et la trouve et on retombe dans le cas précédent, soit l'anticipation n'est en général pas une bonne idée.

Ne pas optimiser le code

Souvent je vois des développeurs qui anticipent des problématiques de performance. Genre "Ah oui mais dans ce cas-là on peut améliorer la perf en faisant ceci ou cela". Résultat : un algorithme avec 2 cas de figure au lieu d'un. Sans intelligence supplémentaire, juste une pseudo-optimisation… qui bien souvent n'est pas un goulot d'étranglement.

Quand on ne sait pas quels sont les goulots d'étranglement, on n'optimise pas.

L'optimisation de code / algorithme est un travail de spécialiste. Si ton boulot n'est pas celui-ci, alors produits du code non optimisé ; tu l'optimiseras plus tard si c'est vraiment nécessaire.

Ecrire du code ready-to-refactor

Les développeurs veulent souvent faire un truc "nickel" dès le début. Hors, comme on ne sait pas comment le code va évoluer, on est tenté d'implémenter toute sortes d'abstractions et de flexibilités qui compliquent la compréhension du code.

Le refactoring fait partie du travail quotidien d'un développeur ; la difficulté est de produire du code "rapidement fonctionnel, mais évolutif via refactoring". Comme ce que dit Fransceco un peu plus haut.

Souvent cela passe par faire un code propre, "sauf là, à cet endroit c'est vraiment dégueu mais c'est là qu'on va refactoriser par la suite" pour le rendre plus souple.

C'est un peu comme les "fusibles" dans la structure des voitures haut de gamme : les grosses berlines sont conçues pour "casser à certains endroits" de manière à garder l'habitacle et ses passagers sains et saufs. Dans le code c'est pareil : il faut anticiper ce qui peut/doit être cassé et garder les algorithmes dont la complexité immédiate est nécessaire aussi monolithiques que possibles.

Mais en vrai, une bonne vieille dictature…

Au final, je pense qu'un bon dictateur sera un excellent moyen de limiter l'over-engineering. Et un bon dictateur sera souvent un développeur pas trop passionné de code, ou en tout cas sensible aux problématiques business/délais/coûts tout autant que développement.

Oui, c'est juste plus dur pour 2 raisons :
- on est moins nombreux, donc moins de diversité
- je suis dans la hierarchie, c'est plus difficile d'évaluer la vraie accroche.

Par rapport à un meetup comme il y en a beaucoup, ce qui est important c'est l'absence de thème prédéfini.

La terminologie "speed meetup" me semble très appropriée : session courte, suffisante longue pour savoir si on veut approfondir, suffisamment courte pour ne pas lasser

Problème par rapport à cette solution : tu as un compte, tu associes à ce compte 2 emails (ton perso et ton pro) => seul ton compte apparaît. La solution que tu évoques fonctionne si tu gères bien 2 comptes distincts, ce qui est un peu schizophrénique et difficile à maintenir au quotidien.

Très beau premier journal, clair et très bien rédigé. Tu hésitais à publier ; la note est là pour prouver que tu as bien fait :)

Les lignes autocar qui se développent ne sont pas des lignes de proximité mais des lignes moyenne/longue distance qui se positionnent sur des trajets identifiés comme rentables.

C'est ce genre de ligne que tu évoques quand tu parles des lignes de bus qui se développent ? Y'a pas de pb de connectivité sur ces lignes, c'est déjà bien desservi (en quantité, pas en tarif) par la SNCF… c'est pas sur ce genre de ligne qu'on a besoin de plus de transports en communs.

En général quand tu habites en ville, les transports en commun sont plutôt bons. C'est quand tu habites hors des grandes agglomérations que tu deviens "laissé pour compte des transports en commun".

On supprime toutes les lignes SNCF secondaires, les grandes liaisons se font entre grandes villes, entre les deux tu n'existes pas. Si tu prends le train entre Lyon et Paris, c'est 2h, mais si tu habites entre les deux, tu n'existes pas (sauf Dijon).

Regarde la Suisse, par exemple, où tu peux te rendre quasiment partout en train… c'est très différent de la France en terme d'infrastructures de transports en communs.

A l'époque où j'étais parisien, j'ai participé à quelques vélorutions. Puis j'ai arrêté, parce qu'au final la manifestation se déroulait exactement de la même manière que ce que les différents cyclistes reprochaient aux voitures. "Oui, nous c'est une fois par mois qu'on a le droit d'être con alors on leur montre". Je ne vais pas m'étaler sur le sujet, juste que je me suis dit : "si c'est pour être aussi con d'un côté que de l'autre, j'ai pas envie de prendre parti".

Dans des villes comme Grenoble, où le vélo est vraiment beaucoup utilisé, ce sont les piétons qui doivent faire attention aux cyclistes. Le centre ville est limité à 30km/h partout, et les rois de la route sont les cyclistes. Ils refusent la priorité aux piétons, même sur les passages aménagés. Ils prennent les sens interdits, etc. Bref, ils sont en position de force et se comportent exactement comme ce que tu reproches aux automobilistes.

Le fait que le cycliste soit plus fragile que l'automobiliste ne doit pas déporter le débat : tu dis que c'est la jungle ; à partir du moment où tu vas dans la jungle et que tu as identifié que tu étais plus fragile que les autres, c'est ton choix et de ta responsabilité d'en assumer les conséquences.

Maintenant, si on veut vraiment s'attaquer au fond du problème, c'est que les pôles de vie et les pôle de travail sont de plus en plus distincts, probablement en partie dû à la stratégie de centralisation de la France, et à l'individualisation de la société (diminution des transports publics / transports en commun)

Si c'est le problème que tu veux résoudre, je t'invite à évoquer le sujet et les solutions qu'on pourrait y apporter. Là, tu t'attaques aux symptômes.

p.s : j'aime le vélo.

C'est difficile de trouver le timing idéal, parce que les dates changent en fonction des formations, parfois des écoles, et suivant les candidats, certains s'y prennent 6 mois avant, d'autres 6 jours…

Bref, ça ne coûte rien de publier ; de toute façon si ça intéresse quelqu'un il me contactera :)

Au passage, j'ai reçu différentes candidatures pour un autre poste (stage admin sys) pour lequel la majorité des candidats débute en avril donc c'est qu'il y a encore des stages à pourvoir :)

stop au spam :)

L'idée c'est dans un premier temps de voir si le concept prend Si oui on trouvera des accords d'une manière ou d'une autre.

Justement c'est ce que je dis : c'est une fausse impression.

Ca fait partie des fonctionnalités à implémenter. La stratégie c'est :

1. être capable d'associer une géoloc à une annonce dans notre modèle de données (utiliser GeoAlchemy + PostGIS)
2. intégrer cette feature dans le modèle de base de crawling
3. mettre à jour les différents crawlers pour extraire cette info si présente (on ne l'aura probablement pas sur toutes les sources) / appels API sur OSM ?
4. ajouter un champ de fitrage sur l'interface pour saisir ville de référence + distance.

Si y'a des motivés et/ou des remarques, je suis preneur.

En gros, Scrapy est plus « connu », ils ont un marketing hype et corporate, ce que l'on a pas (et qu'on ne sait pas faire). J'en suis bien conscient, mais ce n'est pas vraiment ce que j'ai en tête par référence.

Non, Scrapy n'est pas hype. Scrapy a un marketing "boîte à outils pour le business", là où weboob a une image plutôt "clé-en-main pour les djeuns".

Du coup l'utilisateur qui cherche une boîte à outils s'oriente vers scrapy, et celui que veut du clé-en-main va vers weboob.

Il faut regarder la réalité en face aussi : weboob a une image "adolescents" qui est véhiculée par le nommage du projet et des modules. Ca n'a rien à voir avec la qualité du code ou du framework (qui est bien foutu, j'avais regardé l'archi et j'avais trouvé ça bien modulaire et bien conçu).

Vu ce que tu dis, je pense effectivement que Weboob a une bonne place à prendre sur ce genre de marché, mais pour ça à mon avis il faut/faudrait :

• cibler les développeurs qui vont intégrer du crawling (donc weboob) dans un de leurs produit et non "ajouter des fonctionnalités à weboob" (donc dispo sur pip pour être facilement intégré dans un projet existant, licence peut-être plus permissive parce que la concurrence le propose)
• renommer le soft parce que weboob désolé, ça fait pas corporate, c'est con mais c'est vrai. (si un client me dit "quelle techno vous utilisez" j'ai pas envie de dire "weboob" et son module "handjob")
• séparer la distribution des modules du coeur - dans weboob, ce qui m'intéresse c'est le coeur, éventuellement les modules "jobboard", mais pas tout le reste)

Je me suis mal exprimé. Ce n'est pas l'image que véhicule weboob qui me dérange vraiment, mais l'image véhiculée par certains contributeurs/défenseurs de weboob. Cf mon message au dessus.

Je ne fais pas un amalgame de tous les contributeurs weboob : c'est un amalgame que j'ai fait, désolé.

Weboob a été créé il y a six ans. Je doute déjà de l'affirmation « référence » de scrapy en 2016, mais alors si tu remontes début 2010, je crois que l'argument d'autorité tombe complètement. Au niveau technique et outils proposés, les projets divergent également.

Oui les projets divergent, c'est ce que je réponds au message plus haut.

Je n'ai pas compris la difficulté à trouver le code source. C'est sur le site officiel (et un gros lien "Get weboob" sur la page d'accueil). Ça prend quelques instants de trouver des clones sur Github. C'est quoi du coup pour toi un code source facile à trouver ?

Code source facile à trouver, c'est "pouvoir parcourir le code en diagonale pour évaluer la solution". En commençant un projet, tu as plusieurs briques techno sur lesquels tu peux t'appuyer pour développer. Donc tu cherches les ressources techniques directement accessible.

Dans weboob ce qui serait intéressant pour moi, c'est de parcourir le code et la doc des modules spécifiques aux jobboards. Ce code n'est pas dans la doc de développeurs - à juste titre car la doc développeurs cible l'archi générale de Weboob et la manière d'ajouter des fonctionnalités. Ce n'est pas ce qui m'intéresse.

Un autre moyen de faire, c'est de faire un pip install dans ton environnement de développement, mais weboob n'est pas dispo sur pypi. Ca s'explique bien - c'est un outil plutôt packagé "clé-en-main", mais ça ne correspond pas à mon besoin.

Le truc c'est que weboob est packagé / documenté comme un outil clé-en-main, pas pour réutiliser/coder sur certaines de ses fonctionnalités. (en clair : mon besoin ne fais pas partie de la cible)

La licence est effectivement un vrai choix.

La licence est effectivement un vrai choix.

Et l'image arrogante de weboob, ou plus exactement de certains de ses contributeurs ou défenseurs en est également un.

Ca fait plusieurs fois que "des personnes de weboob" interviennent de manière agressive ou intempestives sur des fils de discussion sur LinuxFR. Et le message de ton acolyte ci-dessous en est malheureusement la parfaite illustration.

Lol. Je t'ai rien proposé, ça tombe bien :)

Ton comporte colle tout à fait à l'image que véhicule weboob : des mecs qui se prennent pas pour de la merde, qui se croient drôles et qui prennent les gens de haut.

Je m'en fous de weboob. Fais ce que tu veux, vis ta vie. J'ai rien demandé par rapport à weboob : un de tes collègues m'a posé une question, j'y réponds. C'est pas la peine de venir m'insulter si la réponse te convient pas.

LE framework de référence
Selon qui ?

Les personnes (prospects) avec qui j'ai pu échanger sur des problématiques de scraping / crawling. A part sur LinuxFR, je n'ai jamais entendu parler de weboob.

Je me demande toujours pourquoi weboob ne s'est pas basé dessus

Scrappy ne fournit pas grand-chose par dessus requests et lxml,

Scrappy a de gros avantages sur des fonctionnalités "plus bas niveau" que weboob :

• il est basé sur twister pour l'ordonancement des requêtes, la gestion asynchrone des requêtes ce qui est très puissant pour les problématiques de crawling.
• il propose un mécanisme de pipeline hyper souple qui te permet par exemple d'enchaîner les traitements pour dire "je prends l'information à tel endroit. Si elle n'est pas disponible ou pas conforme, je vais la chercher à tel endroit. etc, etc", et ce en gardant un code propre et clair (en gros, pas en faisant des if, elif, else comme on le ferait si on codait bêtement)
• il propose une architecture distribuable pour faire tourner des crawlers sur plusieurs machines et les alimenter gérer à partir d'un "master"
• il s'installe comem n'importe quel module python, donc compatible avec venv et la "généricité" associée. Weboob est un outil "à installer", moins intégré dans un tel contexte (c'est pas mieux ou moins bien, c'est différent)

que weboob utilise aussi tout en proposant beaucoup plus de choses pour faciliter le développement. Il y avait plutôt « à faire » que « à refaire ».

Scrapy n'est pas un outil de traitement de flux HTML mais un frameword de crawling. Par dessus, il faut de l'intelligence de traitement de flux HTML - ce qu'implémente très bien weboob. Mais Weboob aurait très bien pu s'appuyer sur la puissance de Scrapy ; ce n'est pas exclusif car les métiers sont différents.

il faut lutter pour trouver le code

Je ne comprends pas trop vu qu'il y a bien plus de modules libres pour weboob que pour scrapy et que c'est une grande ressource de problèmes déjà résolus.

Réutiliser les modules weboob serait une bonne idée. Mais comme on touche directement au métier, la visibilité sur le code est importante. J'aimerais pouvoir faire un "pip install weboob_apec" par exemple.

La manière dont Scrapy est intégrée dans pyjobs, c'est juste une brique techno, on utilise l'API et puis c'est tout. Et pour l'installer c'est facile : pip install scrapy.

Je considère que weboob est un outil "clé en main" donc pas conçu pour être réutilisé ; scrapy c'est plutôt un "toolkit" qui est concçu pour être réutilisé (mais en contrepartie de quoi il n'est pas tout à fait "clé en main")

Toute contribution est la bienvenue, et c'est relativement facile comme indiqué dans le journal pour cela.

A défaut de proposer une source et de faire une pull-request, n'hésite pas à proposer l'url des sites auxquels tu penses.

Merci pour ton aide.

J'aurais plutôt tendance à dire que c'est Weboob qui a tout refait ;)

Weboob n'est malheureusement pas basé sur Scrapy qui est LE framework de référence pour faire du crawling. Je me demande toujours pourquoi weboob ne s'est pas basé dessus et en suis vraiment curieux.

C'est vrai que pour l'aspect "crawling métier", il y a déjà des modules Weboob dispo.

Le pb de weboob de mon point de vue :

• je n'adhère pas à l'image que véhicule le projet
• il faut lutter pour trouver le code, je pense que c'est rédhibitoire pour favoriser des contributions de personnes qui souvent "n'osent pas vraiment".
• la licence est AGPL ; je voulais un truc permissif

Autant l'image de marque est un « problème » tout à fait subjectif (et peut être encapsulé si vraiment nécessaire), autant les autres problèmes sont à mon avis rédhibitoires.

Je sais pas ; j'ai hésité parce que j'avais peur de me faire recaler :) Mais si les responsables veulent passer le journal en dépêche je suis pas contre :)

Je viens de visiter le site de semantic ui avec mon mobile, ça saccade au scrolling, ça "déscrolle" tout seul, bref je ferai jamais un site/une app avec. Dommage, c'est vrai que ça a l'air pas mal.

Je vais mettre une annonce sur LinuxFR, on va voir :)

@HanhT, le stage ça va être sûr Grenoble, du coup je sais pas si ça correspond à ce que tu cherches (à toi de me dire) ; et c'est plutôt un stage (sur 1 à 6 mois) qu'une alternance a priori.

Je vais mettre une offre.