Guillaume Maillard a écrit 268 commentaires

Non, ce n'est pas ce que je voulais dire, dit autrement : l'argument de popularité pour justifier que quelque chose est bien ou bon, n'est pas un bon argument (mais un biais courant, cf https://fr.wikipedia.org/wiki/Argumentum_ad_populum).

C'est un peu brutal, de résumer par "les choses ne te plaisent pas tant pis pour toi",
quand aux problèmes précis de bande passante et processeur utilisées,
tu bifurques par "face à d'autres avantages", sans les mentionner ni les évaluer.
Idem pour la non difficulté de multi-thread'er et de gérer la concurrence d'une "map" dans le contexte d'un seul serveur.

Est ce que qu'on parle toujours informatique avec quelque chose d'aussi flou que :

"pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes"

Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).

Si je comprend bien, une application avec des threads et faire attention à la consommation en bande passante et CPU, c'est considéré comme difficile à faire correctement ou long à écrire.
Du coup, est utilisée la solution la moins mauvaise, et tout le monde s'en félicite car c'est la plus utilisée ("auto congratulation" garantie).

N'as tu pas une petite liste dans un coin des technos/logiciels bien mauvais que tout le monde utilise?
Démontrant ainsi que la popularité n'a rien à voir avec la qualité?

Concernant Redis, les avantages présentés sont "la facilité d'implémentation par les clients qui résulte d'une diminution de bugs".
Dans le même genre, on a MySQL, LA base de données qui par défaut ne détectait pas d'erreur de type… si on insérait un entier dans un champs "VARCHAR", sans la moindre difficulté. Surement aussi "par facilité d'usage". A priori, toujours n°1 : https://www.eversql.com/most-popular-databases-in-2018-according-to-stackoverflow-survey/

Bref, l'idée n'est pas de donner des leçons ou d'arriver avec mes gros sabots; j'en ai juste un peu marre de voir l'informatique partir en vrille année après année, conséquence d'un "jenfoutisme" global, ou tout est histoire de mode, ou tout est recrée sans cesse en moins bien.

Aujourd'hui je peste parce que l'éditeur de texte par défaut d'Ubuntu prend 30 secondes pour enregistrer 20Mo, dans 5 ans, ça sera peut être en 5 secondes. Restons "optimistes".
Dans le genre, petite dédicace à Sage, éditeur à 1Md de CA, qui ne voit pas non plus le problème quand son logiciel phare de gestion prend 3 jours (oui, 3 jours) pour exporter une liste d'article de 3Mo.

"Ils ont considéré que le gain en performance ne valait pas les autres avantages" ?

Le cas de Redis est intéressant, la page doc se termine par :
"While comparable in performance to a binary protocol the Redis protocol is significantly simpler to implement in most very high level languages, reducing the number of bugs in client software."

C'est écrit donc c'est vrai?
Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?

Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?
A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.
Apres je conçois très bien que l'on puisse avoir différents processus souhaitant discuter avec une "map" unique. Mais autant minimiser le coût des 'appels'.

Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, …) sans requérir un service.

libRobert.so ? ;)

Merci pour cette réponse bien détaillée et étayée sur… la gestion des systèmes d'information.

Ce qui, pour moi et pour le Larousse, n'a RIEN à voir avec l'informatique.

C'est avec ce melimelo que l'on se retrouve avec tout un tas de gens qui pense faire de l'informatique quand ils utilisent Excel. Au final, le DSI c'est celui qui a su dépanner un PC et réinstaller le Windows sur le PC du patron.
Le même DSI qui va monter en "compétences" abreuvé de stratégie "isomorphe à l’organisation et aux circuits d’information formalisés et non-formalisés".
C'est encore pire dans les grosses boîtes, car ils sont formés à l'école pour cela.

J'ai pas mal d'exemples de clients, de conseils régionaux, banques, société du CAC40 et multinationales (dans lesquels j'ai bossé ou ai des amis dans ces structures); dans les faits on y trouve la pire informatique du monde, certains quittent à peine Windows XP, d'autres se font hacker dans les grandes largeurs, d'autres ont quasiment un serveur pour 10 employés (car le cloud c'est cool, les micro-services aussi…)
La crise sanitaire actuelle a aussi démontrée que les "grandes" DSI se montrent incapables de gérer le télétravail.

Je nuancerais aussi ton constat sur le besoin de performances, car sauf erreurs, Google, Amazon et Microsoft ont au total des millions de serveurs, ceux sont les plus gros consommateurs de bande passante et de CPU au monde.
Bref, ils ont la plus grande partie des serveurs produits, leur faire gagner 1% de performance ou diminuer la bande passante, c'est toucher le jackpot.
Tu comprends donc pourquoi je tique fortement sur le fait de recommander Python, qui peut être 30x plus lent que le C/C++/Rust/Java/C#… cf les benchmarks cités plus haut.
De plus, accepter de perdre 5% de performance ici et la, fait qu'au final (à force d'empiler les services, frameworks, librairies,…) on accepte que l'utilisation des ordinateurs se dégrade non-stop, alors que les performances du matériel soient en constante progression.

Pour la petite histoire, aujourd'hui un collègue a utilisé l'éditeur de texte par défaut de son Ubuntu (19.10) pour modifier un fichier SQL de 20Mo (sur un PC i5 gen9, 32 Go de RAM, SSD nVme), 40 secondes pour sauvegarder le fichier modifié de 10 caractères.
Je trouve cela lamentable, un PC d'il y a 20 ans permettait de modifier ce genre de minuscule fichier et de le sauvegarder en moins d'une seconde.
Les arguments de maintenabilité, d'adaptabilité et "d’orthogonalité avec la stratégie de déploiement des projets de diversité d'hyper-structurabilité homomorphe aux besoins opérationnels dans le cadre de la démarche qualité et d'adéquation du besoin intrinseque du profil utilisateur" (oui, je sais… c'est cadeau :) )… sont des inepties de ceux qui ne veulent pas admettre que c'est codé/designé par des quiches.
Un éditeur de texte correcte peut très bien être écrit avec un langage objet, être testé, avoir un code simple à comprendre et courte… ET sauvegarder un fichier de 20Mo en moins de quelques microseconde sur un SSD qui peut encaisser 2Go/s en écriture.

Concernant Robert, je ne peux que te souhaiter de prendre note des avis que tu as eu ici (documentation, performance, anglais…), ça ne nécessite qu'un peu d'investissement mais engendrera beaucoup de satisfaction (pour tous).

Je vais tenter de faire court. Dans mon post précédent, je n'ai fait que parler d'informatique (dont la définition est : théorie et traitement de l'information à l'aide de programmes mis en œuvre sur ordinateurs). En bifurquant vers les processus organisationnels, les aspects légaux,… et autres choses qui n'ont de rapport avec l'informatique que par la magie des discours commerciaux, on s'éloigne du sujet.

Je n'ai aucun doute sur le fait que tu fais cela avec beaucoup d'intelligence, mais ce n'est pas une raison pour chercher par tous les moyens à justifier des choix à l'encontre d'une bonne pratique de l'informatique (genre on s'en fout : des performances, de la bande passante utilisée, de l'accessibilité…).
De ce que je comprend maintenant ton système n'a d'utilité que si il est au centre d'une architecture multi-serveurs (sinon pourquoi ne pas avoir une hashmap/un graphe directement dans l'appli, plus simple et plus rapide). Donc réservé aux gros déploiements.

Quand on a ce genre d'architecture, on cherche l'optimum, car perdre 5% de performances c'est payé quelques serveurs de plus pour "rien".
En pratique, un protocole non binaire, et qui cause en français c'est un magnifique gâchis de bande passante et de CPU.

Je m'étais dit de ne pas rajouter d'huile sur le feu vu le nombre de détracteurs ci-dessus… mais bon… j'ai un peu de temps à perdre.

Normal donc de se faire incendier quand on arrive avec une description longue d'un projet, qui au final, n'explique pas vraiment son intérêt puis assène post après post un discours idéologique en mode 'je sais tout'.

Pas la peine d'en remettre une couche sur le français, les explications ont étés claires:

• l'ascii est à préféré car évite les problème de clavier, d'encodage, est plus compacte et rapide à traiter (1 octet = 1 caractère).

• le français n'est pas universel en informatique

En revanche le coup du "développeur contemporain", c'est d'un non-sens terrible.
"développeur à la mode" ou "développeur inexpérimenté", pourquoi pas.

• Python n'a rien d'un langage performant, voir https://github.com/kostya/benchmarks pour s'en convaincre. Pour la clarté du code, vu que les "espaces" ont une significations, on repassera.

• Rust produit du code compilé comme des centaines de langages, le fait qu'il soit à la mode et que MS l'utilise ne prouve rien ( argumentum ad populum ), sauf qu'il est à la mode dans son petit monde. La dernière fois que j'ai regardé Rust, il n'existait pas de spécification formelle du langage. On est loin de la maturité des C/C++/Java/etc…

• LISP est langage de niche qui permet de faire des choses extrêmement avancé en quelques lignes, mais dès que l'on veut faire des choses 'communes' avec d'autre environnements comme : du réseau, une interface graphique, charger une image, jouer un son, on est content de ne pas s'en servir.

Le choix d'un langage devrait dépendre du besoin et d'une réflexion technique, pas de la mode.

Bref, avant de s'extasier devant tel ou tel langage, je serais déjà content qu'un développeur "contemporain" maîtrise les aspects bas niveau (architecture, gestion des caches, latence..) des entités avec lesquels il interagit…afin de comprendre que parser du JSON à 2Go/s n'est pas de la science fiction.

L'esprit critique c'est bien, on peut parler des heures de zététique aussi si tu veux.

Tout ce que je dis c'est que s'inscrire pour bénéficier gratuitement des milliers d'heures de travail, c'est pas la fin du monde. Créer un Prestashop a coûté plusieurs millions d'euros, tu n'as rien à payer pour t'en servir ou l'adapter.

Pour en revenir aux points évoqués, et pas vraiment dans le sujet.
1. oui un ecommerce ne fait pas forcement gagner de l'argent, mais utiliser un ecommerce opensource fait économiser beaucoup d'argent.
2. Prestashop c'est pas non plus la joie côté finance, début 2019, l’entreprise a licencié 4% de ses effectifs.

Si tous les propriétaires d'un ecommerce avaient daigné donner 10€ chacun par an (ce qui est peanuts au regard de l'outil qui est le coeur de l'activité d'un "e-commercant"), la situation financière de l'éditeur serait pérenne.
On peut transposer la situation à d'autres succès, comme vlc (3000€ de don par mois, 3 milliards de téléchargement au total…) et toujours de centaines de personnes pour se plaindre de ci ou ca.
(on peut aussi parler de LibreOffice, 125 000 € de don par an…)
Bref, se plaindre va un temps, si on ne donne pas les moyens aux projets opensource, il ne faut pas s'étonner des travers marketing, de bugs, manque de polish, ou disparition d'un tas d'outils.

Et alors? C'est le choix des développeurs de PHP, pas celui de Prestashop.
Les développeurs sont libres, tout comme leur code, le minimum c'est de respecter cela.

Il faut vraiment vous faire la liste des projets libres à succès qui ont disparus car dès qu'il faut dépenser un euro pour un logiciel libre qui en fait gagner des milliers/qui vous fait gagner du temps/ vous simplifie la vie, il n'y a plus personne?

Carrément trop dur comme démarche pour pouvoir télécharger gratuitement d'un logiciel qui a demandé des milliers d'heures de travail chaque année et qui va vous permettre de gagner de l'argent sans rien n'y connaître en informatique…

oui, mais pas des langages de programmation.

Juste une petite note pour préciser que les entreprises utilisent des logiciels de gestion commerciale pour faire leurs factures. Utiliser LibreOffice et cette extension risque de ne pas être très pratique.

J'en profite pour vous annoncer que la prochaine version d'OpenConcerto (ERP OpenSource) intégrera Factur-X en standard lors de la création d'une facture.

Super initiative, si le projet aboutit, ça va faire un carton!
Tu peux me compter dans les premiers acheteurs.

Un FPGA libre sur un PCB avec hdmi et 2 ports USB fera le bonheur des libristes fan de retrogaming/retrocomputing.

En pratique, qu'est ce qu'il est pratique de faire du point de vue d'une application Java avec D-Bus?
J'imagine que le cas d'utilisation doit être plus intéressant que d'afficher une notification dans Gnome, non?

effectivement la modification des modèles est délicate et ils ne sont pas terribles et ils ne comportent pas, pour les factures, de zone avec l'IBAN ;

Nous avons pourtant fait en sorte que la modification soit simple (modèle OpenDocument) modifiable en WYSIWYG avec LibreOffice et paramétrage en XML.
Le reste c'est surtout une histoire de goût, si on avait mis l'IBAN par défaut, on aurait des centaines questions de personnes sur comment le retirer. Nous avons donc mis le minimum, avec un style le plus simplet et passe partout.

j'ai un affichage pourri, une histoire de polices de caractères (?) ;
Oui, certaines distributions font un peu n'importe quoi sur l'intégration de Java et des polices.

je ne peux pas le désinstaller complètement (j'ai essayé tout ce que je savais pourtant), à la limite le remettre à zéro me suffirait, mais je n'ai pas trouvé comment ;

Il n'y a rien à désinstaller vu que rien n'est installé dans le système,
pour repartir de zéro, vous pouvez effacer votre base de données (OpenConcerto.h2.db), le logiciel s'occupera de la recréer.

un commercial obligatoire pour une petite structure c'est pénible.

C'est plutôt bien pour un client de savoir qui lui a fait le devis, TIPS : notez qu'il se remplit en automatique si vous liez un commercial a votre utilisateur.

supprimer les mentions à OpenOffice, plus développé depuis 2014, et ne garder que la référence au format OpenDocument (quitte à indiquer quels logiciels travaillent avec, LibreOffice, Gnumeric, Excel, etc.), je précise d'ailleurs ce que format n'est pas le format d'OpenOffice ou de LibreOffice comme xlsx est le format d'Excel, c'est un format ouvert qui est le format natif des suites libres mais qui ne leur est pas propre, par ailleurs les suites MS Office pour Windows ouvrent et travaillent ces formats depuis 2007 pour la version Windows et, pour autant que je sache, depuis 2016 pour la version OS X ;

Nous gardons la référence à OpenOffice car il est le plus connu de la bande :)

dans les Préférences globales, corriger "Gestion des piéces commericales" et remplacer par "gestion des pièces commerciales", curieusement (ou pas) le panneau de paramétrage associé est écrit correctement.

Oups. Typo corrigé de notre côté.

Merci pour votre retour.

Complexe? En monoposte, il suffit d'extraire l'archive tar.gz et de double cliquer sur le .sh …

Quel est le problème de "qualité" rencontrez-vous? L'impression se fait en 300dpi, nous n'avons pas retour de problèmes particuliers.

Pour l'export en JSON, qu'entendez vous par là ? Exporter une facture en JSON ? Pour quel usage?

Si vous avez des propositions, n'hésitez pas, ici ou dans le forum.

Oui, bien sûr tout dépend des fonctionnalités recherchées, nous avons des clients de plus de 200 personnes qui sont très contents d'OpenConcerto.

Quand je lis "développent fermé", je tousse… la licence est libre : GNU GPL et nous hébergeons un dépôt subversion accessible librement et anonymement.

Si vous ne voyez pas plus de contributions externes, c'est simplement que malheureusement le monde des logiciels de gestion est peu réceptif au concept de partage pour des questions d'avantage concurrentiel. Il y a pas mal de clone/renommage d'OpenConcerto en circulation, nous n'y pouvons pas grand chose.

De notre côté, comme vous le soulignez, nos développements sont disponibles sous licence libre.

(Et évidement, nous ne travaillons pas gratuitement, je ne connais pas d'ingénieurs prêts à travailler non stop sur un logiciel de gestion pour 0 € de l'heure.
Seul le coût de la licence est à 0€ pour les utilisateurs, ce qui est déjà pas mal, non? Impossible de faire mieux sans faire couler à pic notre société)

Une sorte d'apologie de la "hype" en fin de compte?
J'ai comme l'impression que certains se font plaisir au grès des tendances, la "mode",
des surcouches, des abstractions tout en discréditant toutes ces vielles technologies de plus d'un an.

Je comprend qu'il y ait un haut besoin de redondance quand on commence à hyper complexifier les choses, mais plutôt que de simplifier j'ai l'impression que tout converge vers le "on va répartir la charge et tout redonder" au lien de fiabiliser et de simplifier.

Bref, on en a pas fini de voir des pages web de plus de 1Mo et des "frontends" qui n'encaisse pas plus de 100 req/s….

Aurais tu des exemples d'applications qui sont, selon ta description, basées sur des "techno modernes"?
Difficile d'en trouver trace hors du helloworld ou de la description d'infra basées sur des milliers de serveurs.

Si seulement la priorité était de corriger la version officielle…

Peut être qu'un jour, ils se bougeront chez Oracle et changerons le bytecode pour inclure les génériques…(dont l'implémentation actuelle n'est pas géniale).
Le "diamant" c'est pas la plus brillante des idées.
On aurait aimé passer de

List<String> l=new ArrayList<String>();

à

List<String> l=new ArrayList();

Mais j'ai l'impression que c'est comme pouvoir synchroniser les constructeurs pour éviter de gérer les barrières mémoires avec des accès à des "final"…. c'est pas pour demain…

1

Je suis tout à fait d'accord avec toi quand tu considère que sur la ligne (et uniquement celle ci)

var myMap = new HashMap<String, String>();

il n'y a pas de perte d'information, mais je ne vois pas le gain par rapport à :

HashMap<String, String> myMap = new HashMap<>();

car ce n'est ni plus substantiellement long à écrire, ni à lire, ni à comprendre, ni à stocker.
Donc, pour moi, à ce niveau, 'var' c'est inutile.

2

Sur ton exemple :

var myContacts = getContacts();
for (var contact : myContacts){
   display(contact.name);
}

le problème est masqué car le var myContacts = getContacts(); est juste au dessus de ta boucle.
Intercales un ou deux écrans de code et tu n'a plus le contexte.
Pour pas te perdre, tu vas avoir tendance à généraliser ce que tu fais dans ton exemple, cad nommer tes variables en fonction de leurs types.

Par contre, si tu écris du code métier avec beaucoup d'abstraction, très rapidement tu te moques du type

J'aurais tendance à dire que dans ces cas, les classes manipulées implémentent souvent de multiples interfaces et qu'il est donc important de bien savoir ce que l'on manipule.
Peut être un exemple simple et court qui te parleras plus :

void store(String s, int nb) throws IOException {
  var stream = getCurrentStream();
  for(int i=0;i<nb;i++){
      stream.write(s, 0, s.length());
  }
}

Il se passe quoi? On écrit un fichier? On écrit sur une socket? On a flingué les perfs ? Le code est correct?

Par contre si tu écris :

void store(String s, int nb) throws IOException {
  FileOutput stream = getCurrentStream();
  for(int i=0;i<nb;i++){
      stream.write(s, 0, s.length());
  }
}

C'est tout de suite plus clair, on écrit dans un fichier
et, en plus, de la pire des façons.

On écrira donc :

void store(String s, int nb) throws IOException {
  FileOutput stream = getCurrentStream();
  BufferedOutputStream b = new BufferedOutputStream(stream);
  for(int i=0;i<nb;i++){
      b.write(s, 0, s.length());
  }
  b.flush();
}

Donc, pour moi, à ce niveau, 'var' c'est casse gueule.

Désolé de devoir me contenter de code de quelques lignes pour la lisibilité, les vrais problèmes apparaissent avec la complexité et la taille. Bien que je travaille en équipe sur un "codebase" d'un demi million de lignes Java depuis des années, je comprend très bien que "var" puisse être attrayant pour de tout petits projets, mais même dans ce cas j'ai du mal a y voir un véritable gain.

On ne le connaît pas exactement mais on s'en fout

C'est vrai, après tout, tant que ça compile… :) dans la même veine j'ai
"et si ça plante, on reboot."
et
"ici ça marche"
et
"j'écris du code c'est pas mon job de m'occuper des bugs"

Avec des raisonnements comme ça, c'est sûr qu'on fait des logiciels de qualité.

Tu passe la souris dessus

Il est où le gain de temps et de lisibilité ?