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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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 !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
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 :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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 :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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 ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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 :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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 !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# 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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # 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
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: parametre utilisateur ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message Visibilité de l'entreprise m'employant lors de contributions github. Évalué à 2.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Beau projet, beau journal
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Fourmilière artificielle: Intelligine. Évalué à 6.
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 :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: On est toujours le "con" d'un autre
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Bagnole, pouvoir, autorité. Évalué à 4.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: On est toujours le "con" d'un autre
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Bagnole, pouvoir, autorité. Évalué à 6.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# On est toujours le "con" d'un autre
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Bagnole, pouvoir, autorité. Évalué à 10.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Un peu tard...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au message [recrutement][stage][pourvu] Développeur web/backend Python sur Grenoble. Évalué à 3.
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 :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: module
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Pyjobs s'enrichit de nouvelles sources et propose un stage en développement web fullstack python. Évalué à 0.
stop au spam :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et les job-boards ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - un job-board pour les agréger tous.. Évalué à 2.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: statistiques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal pyjobs - un job-board pour les agréger tous.. Évalué à 3.
Justement c'est ce que je dis : c'est une fausse impression.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo