en gros c'est de l'auto-stop un peu évolué—on n'a jamais vu l'état faire une loi sur l'auto-stop, j'aimerais qu'il ne commence pas de sitôt
Non : tu ne demandes aucune participation financière quand tu prends quelqu'un en auto-stop. Tu changes de type de rapports / stratégie quand tu covoitures et le "factures" à tes passagers.
Pour faire du python depuis plus de 8 annnées en techno principale, en équipe et en solo, en développement et en scripting, le vrai problème est la maintenance et la compréhension du code.
L'absence de typage statique / annontation complique la maintenance du code car tu ne sais pas ce que tu peux / ce que tu ne peux pas faire, ce que tu dois / ce que tu ne dois pas faire.
J'utilise autant que faire se peut python 3 avec les annotations, et lorsqu'on travaille en équipe, ça simplifie énormément la reprise de code de l'un par l'autre.
Quant aux problématiques de performance, elles ne sont généralement pas résolues en python.
Merci pour cette piste qui s'oriente vers une licence pro, donc niveau diplôme c'est cool, et c'est accessible en alternance, visiblement, sur Grenoble (c'est là où idéalement ça se déroulerait).
Comment ça fonctionne ce genre de procédure ? Etait-il en situation illégale ? Est-ce qu'il a fait des démarches qui ont été refusées ? Le ton de cette dépêche et les éléments temporels laissent une impression d'urgence à agir - soit, mais sans expliquer le déroulement des événements qui concernent Cellou Diallo et sa situation personnelle en France ? Pourquoi ça devient extrêmement urgent, là, en 5 jours ?
Le titre est un peu racoleur mais l'article intéressant. Plusieurs points en communs avec ce que je dis, mais également d'autres aspects liés aux développeurs.
Je trouve le titre "Pourquoi les meilleures entreprises et développeurs donnent presque tout ce qu'ils font" raccoleur parce que les entreprises ne donnent pas "presque tout ce qu'elles font", même à leurs concurrents comme le dit l'auteur.
Même en terme de code tout n'est pas publié, loin de là. Ce qui est publié c'est ce qui est réutilisable, et un des intérêts est effectivement d'avoir de la QA, du développement "gratuits".
On pense souvent au code en terme de "logiciel avec ses fonctionnalités", mais de grosses boîtes comme Google, Facebook et autres ont aussi énormément de code lié au déploiement, à l'infrastructure, aux outils internes. Ces développements-là restent souvent fermés (et ça ne me choque pas).
Si je comprends bien, vous avez des clients qui veulent que vous travailliez sur du spécifique et qui vous demandent explicitement que le code produit soit leur seule propriété et qu'il ne soit pas placé sous licence libre ?
C'est pas aussi marqué que ça. Par défaut, les clients demandent en général le transfert de propriété intellectuelle. Dans ces conditions, ils sont propriétaire du code et en font ce qu'ils veulent (licence, pas licence, etc). Quand on travaille sur des sujets qui ont clairement un intérêt à être réutilisé on discute sur le fait de publier une partie, mais souvent, c'est des développements tellement spécifiques que ça ne vaut même pas la peine de discuter du sujet : on ne pourra pas réutiliser, le client ne verra pas l'utilité, donc ça ne peut que brouiller les cartes.
Je ne pense pas que la production de code propriétaire soit obligatoire, car même si certains clients le souhaitent, rien n'empêche de produire du code libre spécifique qui ne sera pas réutilisé ou divulgué en l'état ensuite (bien que de fait on ne peut pas garantir au client que le code ne sera pas publiquement divulgué, puisque la licence le permet).
Je pense par exemple aux milliers d'intégrateurs de solutions type ERP en AGPL, comme pour Odoo avant la version 9.
Oui, dans ce cas produire du libre spécifique a du sens.
Le fait de répondre à des marchés publics qui veulent du libre ne fait pas que ces seuls marchés sont suffisants pour vivre ni que c'est ta source principale de chiffre d'affaire.
Cozycloud est un bon exemple, est-ce que quelqu'un connaissant le type de vente faite par Cozy pourrait nous dire ce qu'ils vendent ? Des contrats de maintenance ? Du support ? Du développement de fonctionnalités ?
Oui et non, google a jamais publié leur algo lié a leur moteur de recherche effectivement.
C'est l'avantage concurrentiel de Google. C'est ça qu'ils ne publient pas.
Mais si tu prend le cas de twitter par example, l'ensemble de leur backbone repose sur Mesos qui un projet libre et ils y contribuent énormément dessus. Ce qui a obligé Google à aussi libérer le sien (Kubernetes (ça fait bien 10 ans qu'ils ont la techno en interne et il le libère que maintenant face à la concurrence)).
Je pourrais parler de netflix aussi avec OSS (le code source de l'ensemble de leur SI basé sur Amazon).
Facebook publie aussi son matos sur opencompute.org.
C'est pas leur avantage concurrentiel. Facebook, son avantage concurentiel, c'est la base utilisateur. Twitter aussi. Pour Netflix, je sais pas trop, je connais pas assez.
Je pense que ces grosses boîtes, leur problème, c'est de recruter les meilleurs dév et d'avoir une forte influence "dans le mieux", c'est pour ça qu'ils publient du code source.
C'est ce que j'appelle garder l'algo monolithique. La gestion des erreurs, les cas particuliers etc ne font pas partie de l'algo à proprement parler.
Sur ce genre de developpement, énormément de personnes vont trouver que le code est trop complexe et le découper en embarquant une partie de l'algo dans la sous-fonction. Le découpage du code doit cependant se faire autant que possible pour que l'algo soit lisible d'une traite. On externalisera uniquement les "details d'implementation".
ou encore mieux un ORM au-dessus de différentes bases NoSQL (je ne suis pas sur que ça existe vu le bordel que c'est au niveau des langages de requêtes NoSQL)
Il y a Ming notamment qui propose de "s'affranchir" de MongoDB en python. Mais bon…
Le concept d'un ORM pour les bases "Not (Only) SQL" ça n'a pas vraiment de sens vu que la définition est la négative d'un modèle (le standard SQL) mais pas la définition d'un standard.
Dire "existe-t-il un ORM pour les différentes bases NoSQL", c'est comme de dire : "existe-t-il un permis pour conduire ou piloter tout ce qui n'est pas une voiture". Non, ça n'existe pas, et c'est assez logique : piloter un avion, manoeuvrer un bateau ou conduire une moto, ça n'a tout simplement rien à voir.
Je t'ai plussé parce que ce que tu évoques est une bonne pratique générale.
Mais en fait je vois pas quelle distinction tu fais entre "plugguer ce genre d'outil sur ta base", et "publier un flux RSS à partir de ta base" ou encore "publier les annonces sur ton propre site". A partir du moment où tu as accès à l'information, que ce soit pour la diffuser sur twitter, ou sur tes propres pages, le risque d'accès à des données confidentielles est bien réel.
Par ailleurs, cet outil n'est a priori pas "paramétrique", donc pas d'injections SQL comme on peut le faire sur un (par exemple) le site web qui accède aux même données et propose des filtres, de la pagination, etc.
Enfin, les bases de données relationnelles proposent des rôles utilisateur avec une gestion de droit d'accès sur les données à granularité plus ou moins fine permettant par exemple de déployer "db2twitter" avec une configuration "qui va bien" et qui n'aurait accès qu'aux données requises.
D'autant plus qu'un plan social, ce n'est pas une action que les dirigeants aiment prendre (cela signifie quand même que leur boîte va mal) et certains dirigeants connaissent les gens sur le départ.
Je pense que le dirigeant d'une petite structure ou PME où il connait chacun de ses collaborateurs (ou quasiment) n'aime pas prendre ce genre de décision parce qu'effectivement, cela signifie que son entreprise ne va pas très bien. Et je pense que beaucoup de ces dirigeants là vivent une situation stressante.
Je pense qu'un dirigeant comme celui d'Airbus, on lui dit "il faut anticiper la baisse des bénéfices dans les prochaines années, réduisez la masse salariale" ; il n'aime pas organiser un plan social, parce qu'il sait que ça va être la merde, mais bon, c'est le job. Je suis pas certain du tout qu'il le vive aussi mal qu'un petit patron.
Dire "les dirigeants c'est ceci ou cela" et "les salariés font ceci ou cela" c'est une pure vue de l'esprit.
Il y a autant de proximité entre un grand patron et un petit patron qu'entre un salarié qui gagne 80K€ voire 100K€ (comme très certainement il y en a dans le public de LinuxFR) et un salarié non diplômé payé au SMIC et qui travaille à la chaîne dans l'industrie lourde.
En fait du code "ready-to-refactor", c'est du code pour lequel tu as déjà en tête la solution technique pour l'adapter aux problématiques qui vont arriver dans les prochaines semaines ou les prochains mois, mais que tu n'as juste pas à t'occuper de cela dès maintenant (donc tu n'implémentes pas cette complexité supplémentaire qui te retarderait en développement, mais également en tests et en gestion des effets de bords).
Les tests sont un pré-requis pour refactoriser en toute sereinité. Mais parfois tu refactorises sans tests (tu te fais quelques sueurs, mais bon, ça fait partie du métier;)
Du code ready-to-refactor, pour moi c'est :
du code propre et correctement conçu là où les algorithmes sont clairs et ne sont pas destinés a priori à être refactorisés
du code plus ou moins propre là où tu as identifié des pistes d'amélioration mais que tu ne les implémentes pas car pas dans l'objectif et générant plus de travail. Ce code sera avantageusement commenté avec des TODO, des HACK ou des FIXME citant auteur, date, et refactoring imaginés.
tu n'as jamais une couverture de test exhaustive de tous les cas possibles et imaginables ; les parties de code identifiées comme "ready-to-refactor" seront mieux testées pour qu'au moment du refactoring on ne se pose pas de question sur le comportement attendu.
le code "ready-to-refactor" sera idéalement encapsulé dans des fonctions ou des méthodes statiques. Ceci permet de localiser le refactoring et de définir un périmètre de test clair.
tu ne fais pas de méta-programmation sur ce code car c'est plus compliqué à comprendre et vu que c'est destiné à être refactorisé…
tu ne fais pas d'optimisation quelle qu'elle soit. (si tu as besoin d'améliorer les perfs, soit tu fais ton refactoring à ce moment-là, soit tu mets un gros cache moche par dessus "en attendant"… mais tu l'identifies comme tel)
Exemples de cas compliqués à refactoriser :
si le code que tu veux/dois refactoriser est disséminé un peu partout dans tes sources, ça devient difficile à refactoriser car tu risques d'oublier des endroits ou des cas de figure.
si ce que tu veux refactoriser ce sont des classes complètes, le problème c'est qu'une classe embarque un état + un comportement, c'est donc plus compliqué qu'une "simple fonction" qui n'embarque qu'un comportement (sous réserve que tu n'utilises pas des variables globales, statiques ou assimilés)
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.
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 :
ne sont pas demandées dès maintenant
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
[^] # Re: c'est quoi une durée courte ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Je cherche une formation courte/alternance spécialisée Linux/réseau si possible diplomante. Évalué à 2.
Je confirme ce que tu dis. Pas vraiment ce genre de truc en bac+3 de ce que je viens de voir.
Par contre niveau timing, c'est pas top… Inscriptions jusqu'à fin avril :-s
[^] # Re: Formation Linux
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Je cherche une formation courte/alternance spécialisée Linux/réseau si possible diplomante. Évalué à 2.
C'est intéressant, le top serait ce genre de formation mais en plus long… Mais je pense que c'est vers ce genre de truc qu'on va s'orienter
[^] # Re: c'est quoi une durée courte ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Je cherche une formation courte/alternance spécialisée Linux/réseau si possible diplomante. Évalué à 2.
Le problème (mais c'est pas forcément rédhibitoire), c'est le temps passé sur des sujets généraux déjà vus : gestion, français, ce genre de truc
# lieu de travail ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message [Emploi] Lead developpeur et développeur sénior PHP/Symfony. Évalué à 3.
Paris ? Télétravail possible ?
[^] # Re: Juste milieu ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 10.
Non : tu ne demandes aucune participation financière quand tu prends quelqu'un en auto-stop. Tu changes de type de rapports / stratégie quand tu covoitures et le "factures" à tes passagers.
[^] # Re: Rigolo
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Typage statique pour Python. Évalué à 10.
Pour faire du python depuis plus de 8 annnées en techno principale, en équipe et en solo, en développement et en scripting, le vrai problème est la maintenance et la compréhension du code.
L'absence de typage statique / annontation complique la maintenance du code car tu ne sais pas ce que tu peux / ce que tu ne peux pas faire, ce que tu dois / ce que tu ne dois pas faire.
J'utilise autant que faire se peut python 3 avec les annotations, et lorsqu'on travaille en équipe, ça simplifie énormément la reprise de code de l'un par l'autre.
Quant aux problématiques de performance, elles ne sont généralement pas résolues en python.
[^] # Re: DA2I // CGIR
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Je cherche une formation courte/alternance spécialisée Linux/réseau si possible diplomante. Évalué à 2.
Merci pour cette piste qui s'oriente vers une licence pro, donc niveau diplôme c'est cool, et c'est accessible en alternance, visiblement, sur Grenoble (c'est là où idéalement ça se déroulerait).
[^] # Re: Sérieusement...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Comité de soutien pour Cellou Diallo contre son expulsion. Évalué à 10.
Vu l'implication du personnage dans le libre Montpelliérain et sur OpenStreetMap, je pense que le relais de l'information se justifie.
Le relais pourrait être plus objectif, ceci dit.
# Contexte ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Comité de soutien pour Cellou Diallo contre son expulsion. Évalué à 10.
Comment ça fonctionne ce genre de procédure ? Etait-il en situation illégale ? Est-ce qu'il a fait des démarches qui ont été refusées ? Le ton de cette dépêche et les éléments temporels laissent une impression d'urgence à agir - soit, mais sans expliquer le déroulement des événements qui concernent Cellou Diallo et sa situation personnelle en France ? Pourquoi ça devient extrêmement urgent, là, en 5 jours ?
[^] # Re: Un parallèle...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 4.
Le titre est un peu racoleur mais l'article intéressant. Plusieurs points en communs avec ce que je dis, mais également d'autres aspects liés aux développeurs.
Je trouve le titre "Pourquoi les meilleures entreprises et développeurs donnent presque tout ce qu'ils font" raccoleur parce que les entreprises ne donnent pas "presque tout ce qu'elles font", même à leurs concurrents comme le dit l'auteur.
Même en terme de code tout n'est pas publié, loin de là. Ce qui est publié c'est ce qui est réutilisable, et un des intérêts est effectivement d'avoir de la QA, du développement "gratuits".
On pense souvent au code en terme de "logiciel avec ses fonctionnalités", mais de grosses boîtes comme Google, Facebook et autres ont aussi énormément de code lié au déploiement, à l'infrastructure, aux outils internes. Ces développements-là restent souvent fermés (et ça ne me choque pas).
[^] # Re: Et la vente de code libre à ses clients ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 4.
Si je comprends bien, vous avez des clients qui veulent que vous travailliez sur du spécifique et qui vous demandent explicitement que le code produit soit leur seule propriété et qu'il ne soit pas placé sous licence libre ?
C'est pas aussi marqué que ça. Par défaut, les clients demandent en général le transfert de propriété intellectuelle. Dans ces conditions, ils sont propriétaire du code et en font ce qu'ils veulent (licence, pas licence, etc). Quand on travaille sur des sujets qui ont clairement un intérêt à être réutilisé on discute sur le fait de publier une partie, mais souvent, c'est des développements tellement spécifiques que ça ne vaut même pas la peine de discuter du sujet : on ne pourra pas réutiliser, le client ne verra pas l'utilité, donc ça ne peut que brouiller les cartes.
Oui, dans ce cas produire du libre spécifique a du sens.
[^] # Re: [HS] Quel saut
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 2.
On n'est pas encore 4 à plein temps :)
[^] # Re: Société est trop général
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 5.
Je ne pense pas nécessairement éditeur, non.
Le fait de répondre à des marchés publics qui veulent du libre ne fait pas que ces seuls marchés sont suffisants pour vivre ni que c'est ta source principale de chiffre d'affaire.
Cozycloud est un bon exemple, est-ce que quelqu'un connaissant le type de vente faite par Cozy pourrait nous dire ce qu'ils vendent ? Des contrats de maintenance ? Du support ? Du développement de fonctionnalités ?
[^] # Re: Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 9.
C'est l'avantage concurrentiel de Google. C'est ça qu'ils ne publient pas.
C'est pas leur avantage concurrentiel. Facebook, son avantage concurentiel, c'est la base utilisateur. Twitter aussi. Pour Netflix, je sais pas trop, je connais pas assez.
Je pense que ces grosses boîtes, leur problème, c'est de recruter les meilleurs dév et d'avoir une forte influence "dans le mieux", c'est pour ça qu'ils publient du code source.
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
C'est ce que j'appelle garder l'algo monolithique. La gestion des erreurs, les cas particuliers etc ne font pas partie de l'algo à proprement parler.
Sur ce genre de developpement, énormément de personnes vont trouver que le code est trop complexe et le découper en embarquant une partie de l'algo dans la sous-fonction. Le découpage du code doit cependant se faire autant que possible pour que l'algo soit lisible d'une traite. On externalisera uniquement les "details d'implementation".
[^] # Re: DB = DataBase != SQL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tweeter le contenu de votre base de données - db2twitter - support des tweets avec image. Évalué à 3.
Il y a Ming notamment qui propose de "s'affranchir" de MongoDB en python. Mais bon…
Le concept d'un ORM pour les bases "Not (Only) SQL" ça n'a pas vraiment de sens vu que la définition est la négative d'un modèle (le standard SQL) mais pas la définition d'un standard.
Dire "existe-t-il un ORM pour les différentes bases NoSQL", c'est comme de dire : "existe-t-il un permis pour conduire ou piloter tout ce qui n'est pas une voiture". Non, ça n'existe pas, et c'est assez logique : piloter un avion, manoeuvrer un bateau ou conduire une moto, ça n'a tout simplement rien à voir.
[^] # Re: Use Case
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Tweeter le contenu de votre base de données - db2twitter - support des tweets avec image. Évalué à 4.
Je t'ai plussé parce que ce que tu évoques est une bonne pratique générale.
Mais en fait je vois pas quelle distinction tu fais entre "plugguer ce genre d'outil sur ta base", et "publier un flux RSS à partir de ta base" ou encore "publier les annonces sur ton propre site". A partir du moment où tu as accès à l'information, que ce soit pour la diffuser sur twitter, ou sur tes propres pages, le risque d'accès à des données confidentielles est bien réel.
Par ailleurs, cet outil n'est a priori pas "paramétrique", donc pas d'injections SQL comme on peut le faire sur un (par exemple) le site web qui accède aux même données et propose des filtres, de la pagination, etc.
Enfin, les bases de données relationnelles proposent des rôles utilisateur avec une gestion de droit d'accès sur les données à granularité plus ou moins fine permettant par exemple de déployer "db2twitter" avec une configuration "qui va bien" et qui n'aurait accès qu'aux données requises.
[^] # Re: Machine à noter
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Quelle violence… ?. Évalué à 10.
Je pense que le dirigeant d'une petite structure ou PME où il connait chacun de ses collaborateurs (ou quasiment) n'aime pas prendre ce genre de décision parce qu'effectivement, cela signifie que son entreprise ne va pas très bien. Et je pense que beaucoup de ces dirigeants là vivent une situation stressante.
Je pense qu'un dirigeant comme celui d'Airbus, on lui dit "il faut anticiper la baisse des bénéfices dans les prochaines années, réduisez la masse salariale" ; il n'aime pas organiser un plan social, parce qu'il sait que ça va être la merde, mais bon, c'est le job. Je suis pas certain du tout qu'il le vive aussi mal qu'un petit patron.
Dire "les dirigeants c'est ceci ou cela" et "les salariés font ceci ou cela" c'est une pure vue de l'esprit.
Il y a autant de proximité entre un grand patron et un petit patron qu'entre un salarié qui gagne 80K€ voire 100K€ (comme très certainement il y en a dans le public de LinuxFR) et un salarié non diplômé payé au SMIC et qui travaille à la chaîne dans l'industrie lourde.
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 2.
En fait du code "ready-to-refactor", c'est du code pour lequel tu as déjà en tête la solution technique pour l'adapter aux problématiques qui vont arriver dans les prochaines semaines ou les prochains mois, mais que tu n'as juste pas à t'occuper de cela dès maintenant (donc tu n'implémentes pas cette complexité supplémentaire qui te retarderait en développement, mais également en tests et en gestion des effets de bords).
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Les tests sont un pré-requis pour refactoriser en toute sereinité. Mais parfois tu refactorises sans tests (tu te fais quelques sueurs, mais bon, ça fait partie du métier;)
Du code ready-to-refactor, pour moi c'est :
Exemples de cas compliqués à refactoriser :
[^] # Re: Sur le même principe, il y a les HumanTalks aussi...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Les réunions pépé-malin - monter en compétence de manière ludique. Évalué à 3.
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.
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 2.
Ton lien est cassé (on peut le copier/coller, mais le clic foire)
[^] # Re: chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 8.
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 :
Bref, le ready-to-refactor, c'est bon, mangez-en !
# chi va piano va sano
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Lutter contre l'overengineering. Évalué à 10.
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.
[^] # Re: la majorité des gens aiment partager leurs connaissances quand l'environnement est bienveillant
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Les réunions pépé-malin - monter en compétence de manière ludique. Évalué à 5.
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