LeBouquetin a écrit 1916 commentaires

Ce n'est pas 26 M$ mais 26 milliards de dollars. C'est beaucoup plus.

3, non ?

Pourquoi il n'y a pas de honte à gagner sa vie en faisant du code propriétaire ? Parce que je ne prend rien à personne : nous signons un contrat qui satisfait toutes les parties impliquées, n'en déplaise à Stallman (qui n'est pas concerné par les accords que je signe avec des clients).

Pour préciser ma réponse, quand tu gères une entreprise et que tu a du déficit certains mois, tu obtiens un crédit de TVA. Typiquement, les Startup qui vivent sur les fonds qu'elles ont levé et qui ne vendent rien perdent de l'argent chaque mois. A leur déclaration mensuelle de TVA, elles obtiennent un crédit de TVA. Après, une boîte qui ne fait que perdre de l'argent n'est pas pérenne par définition, donc une boîte qui tourne devra toujours payer plus de TVA qu'elle ne pourra en déduire.

Et si on arrive à des sommes négatives, l'état nous rembourse ?

Non, comme pour le reste : il taxe les entreprises et les ménages sur leurs revenus, mais ne les détaxe pas sur leurs pertes.

C'est faux, on voit que tu ne sais pas de quoi tu parles.

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

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

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

Paris ? Télétravail possible ?

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).

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.

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.

On n'est pas encore 4 à plein temps :)

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 ?

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)