Guillaume Maillard a écrit 181 commentaires

  • # En pratique

    Posté par (page perso) . En réponse à la dépêche Communiquer avec D-Bus en Java avec JNIDBus. Évalué à 3 (+1/-0).

    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?

  • [^] # Re: J'ai testé

    Posté par (page perso) . En réponse à la dépêche OpenConcerto 1.6. Évalué à 2.

    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.

  • [^] # Re: Pour un vieux Mac ?

    Posté par (page perso) . En réponse à la dépêche OpenConcerto 1.6. Évalué à 3.

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

  • [^] # Re: Mon retour

    Posté par (page perso) . En réponse à la dépêche OpenConcerto 1.6. Évalué à 3. Dernière modification le 02/02/19 à 19:42.

    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.

  • [^] # Re: ça convient pour une entreprise de 180 personnes ?

    Posté par (page perso) . En réponse à la dépêche OpenConcerto 1.6. Évalué à 6.

    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.

  • [^] # Re: logiciel de caisse

    Posté par (page perso) . En réponse à la dépêche OpenConcerto 1.6. Évalué à 10.

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

  • [^] # Re: Je suis resté en 2000

    Posté par (page perso) . En réponse à la dépêche Démystifier l’activité d’hébergeur. Évalué à 4.

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

  • [^] # Re: Je suis resté en 2000

    Posté par (page perso) . En réponse à la dépêche Démystifier l’activité d’hébergeur. Évalué à 4.

    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.

  • [^] # Re: Beurk

    Posté par (page perso) . En réponse à la dépêche Sortie de ONLYOFFICE Desktop Editors 5.2 avec la connexion à Nextcloud / ownCloud. Évalué à 4.

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

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 0.

    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…

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 0.

    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.

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à -8.

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

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 3.

    Tu passe la souris dessus

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

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 4. Dernière modification le 10/11/18 à 11:26.

    LA question que je pose depuis le début et que tout le monde fait semblant de ne pas comprendre et d'éluder (avec un petit downvote au passage), c'est quand tu lis :

    auto counter=getNextValue();
    
    if ( counter == numeric_limits<decltype(counter)>::max() )
     throw overflow_error("counter too big");
    
    ++counter;

    comment tu connais le type de retour de getNextValue() sans aller voir sa déclaration (dans un autre fichier ou des centaines de lignes plus loin) ?

    Ce n'est pas en répondant que "le langage XY a aussi des var/auto" ou "j'y arrive" que tu réponds à la question. Idem pour Renaud. Vos postures a base d'argument d'autorité genre "tu l'utilises pas tu sais pas", "je m'en sers, ca marche", "OCaml c'est bien", c'est le genre de poudre aux yeux qu'on laissera aux politiques. Et n'allez pas penser que je suis réfractaire à la nouveauté, il y en a de très intéressantes, mais pas celle ci.

    De plus, je ne suis pas fan du code que tu proposes, tester les limites des types en dynamique alors que le type ne changera pas en runtime tout ca parce que c'est "mieux" d'écrire "auto counter" que "int counter", ca n'a pas de sens (et je ne parle même pas des performances…).

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 1.

    J'ai l'impression que par lisible tu veux dire "rapide à lire".
    Oui, "for (auto element : conteneur)" c'est rapide à lire

    Par lisible, j’entends compréhensible, et ceci ne l'est pas, car si la définition de "conteneur" est 40 lignes plus haut ou si c'est lui même un "auto" machin, le code n'est PAS compréhensible. Même pas en rêve avec tes technos dites "modernes" et les bonnes pratiques de mamie.

    Pour reprendre sur Java et ne pas digresser sur le C++ qui n'a jamais eu de syntaxe claire,

    for (String str : parts){
    }
    est parfaitement compréhensible, on a tout le contexte. On ne peux pas se tromper sur l'utilisation/le type de 'str'.

    Je ne dis pas que le compilateur va se tromper, c'est le programmeur qui ne peux pas s'y retrouver (à moins que ta "bonne pratique" c'est frde nommer les variables/les paramètres en incluant le type.
    genre :

    var myInt = getNextValue();
    Et ici, franchement, on a frôle la débilité profonde.

    Comme tu es sérieux et rigoureux, tu vas écrire pour ton compteur :

    var count = getNextValue();
    et peut être même l'incrémenter quelques lignes plus bas.
    Et comment tu vas être sûr que tu ne risque pas te faire un overflow?
    count c'est un "int", un "long" ? Ah, non pas de bol, il est lu d'un stream octet par octet, c'est un "byte".

    Conclusion, tu ne peux pas comprendre en lisant le code (faut aller voir la signature du getNextValue() pour savoir, une perte de temps), bref, c'est casse gueule au possible et complètement inutile (et c'est pas parce que Rust le fait que c'est bien).

    Cette "évolution" de Java est juste là pour faire plaisir aux amateurs de Javascript qui voudrait goûter à Java.

    (notons au passage que les gros projets Javascript migrent vers Cleartype pour justement avoir du code "lisible" et plus robuste que la loterie à base de "let" et "var")

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à 0.

    C'est assez naïf comme raisonnement. Ce n'est pas parce que le compilateur connait le type que le "programmeur" oui.

    Suffit de passer ce "var" magique à une API qui a des méthodes de même nom mais avec des arguments de types différents pour être sûr d'avoir du code Java du niveau d'un code javascript…

    Ça va compiler sans problèmes, ça c'est sûr!
    Je ne parle même pas des problèmes de refactoring que cela implique.

    L'argument C++ et autre, je vois pas le rapport, en C++ on peut aussi se contenter de void** !

    code plus lisible et maintenable,

    C'est tout le contraire, on ne sait plus de quoi on parle:

    var toto = getNextValue();
    Tu m'explique comment tu arrives à mieux lire le type de toto pour savoir quoi en faire 3 lignes plus bas?

    var titi = toto.apply();
    toujours sûr de savoir de quoi on cause?
    Je suis très curieux de voir un exemple réel…

    en évitant les noms à rallonge

    on parle de type, pas de nom de variable ou de paramètre, gagner quelques octets dans un code source n'apporte rien à moins d'avoir de sérieuses douleurs au doigts.
    Aux dernières nouvelles, le temps à "taper" le code est ridiculement faible par rapport au temps à passer à réfléchir sur l'architecture, les algorithmes, bref à quoi frapper sur le clavier…

  • [^] # Re: Inférence de types

    Posté par (page perso) . En réponse à la dépêche Sortie de JDK 10. Évalué à -1.

    C'est surtout aussi inutile que casse gueule… le typage fort c'est un avantage pas un inconvénient.

    Quand je lis "certains types peuvent être soit inconnus du programmeur", je comprend qu'on est pas en train de parler de programmation mais de bidouille, d'un code mal maitrisé qui a toute les chances d'être buggé jusqu'au trognon.

  • # Un peu d'air frais

    Posté par (page perso) . En réponse à la dépêche Haiku R1 bêta 1. Évalué à 10.

    Après l'avoir utilisé quelques heures, je ne peux que vous conseiller de le tester, ça fait du bien, l'ensemble est stable (sauf peut être le navigateur qui plante aléatoire sur Youtube).

    L'avantage c'est qu'étant basé sur une architecture performante d'il y a 20 ans (1 thread par fenêtre par exemple), et bien que non fortement optimisé, tout est très rapide et peu gourmand en mémoire.

    Graphiquement, ce n'est pas aussi bon que l'original, les marges et alignements ne sont pas terribles, le look "glossy" (que n'avait pas BeOS) fait un peu désuet, mais rien compliqué à corriger.
    J'espère que le "subpixel rendering" des polices arrivera bientôt.

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 5.

    Tu as tout à fait raison, les interfaces sont plus élaborées maintenant, mais je nuancerai ton propos en te donnant rendez-vous dans 1 an.
    En effet, dans un an, les développeurs de GNOME auront passés des milliers d'heures sur leurs projets, les attentes des utilisateurs n'auront pas bougé, les matériels n'auront pas été révolutionnés.
    Et pourtant, je prends le pari que la situation n'aura pas évoluée en termes de qualité et de performance.
    Par contre on aura le droit a de nouvelles icônes ou des bizarreries d'ergonomie, GNOME a un passif de 20 ans.

    On pourra toujours me reprocher d'être trop corrosif avec GNOME, mais quand ton job et ta passion c'est le développement logiciel, au bout de 25 ans, voire que la qualité a tendance a se dégrader et qu'il y a toujours quelqu'un pour le justifier avec un aplomb fabuleux, ça me fatigue.
    Par "faire du code rapide, pas cher et de qualité, ça n'existe pas", si tu veux dire que dans un temps donné, un développeur ne peut pas écrire du code performant (quasi) sans bugs, c'est difficile à justifier.
    Car cela revient à dire que tous les développeurs ont le même niveau. J'ai croisé assez de développeurs bien meilleur que moi et aussi bien pire, pour te garantir que je peux faire du code moins rapide, cher et de moins de bonne qualité que certains.
    La capacité à écrire du code rapide et de qualité est, de mon point de vue, surtout lié à l'expérience (formation, temps passé sur le même sujet, etc) et l'attention portée aux détails.

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 1.

    Bizarre de me prêter des affirmations que je n'ai pas émises pour défendre coûte que coûte un logiciel mal codé (gdm).

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 2.

    Et pourtant vrai, si tu es développeur, tu peux mettre quelques "printf" pour t'en rendre compte.

    Quand tu ouvres un dossier, les droits sont analysés (pour mettre des petites icônes d'interdiction), les icônes sont associées aux types des fichiers et disposées en fonction de la taille de la fenêtre, tout cela dans le respect du "thèmes", de tes préférences etc…etc…

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 4.

    Je ne suis pas au courant d'un accident nucléaire causé par un bug logiciel, ni d’appareil médical qui plante tous les jours…
    Surement que les logiciels qui gèrent les plannings ou autres ne doivent pas être au top niveau, mais je ne faisais pas référence à cela.

    Pour les jeux, tu crois vraiment que c'est des quiches qui codent les moteurs 3D ?
    En 10ms, un développeur de Gnome n'est pas foutu d'ouvrir un dossier, les moteurs 3D s'occupent de gérer des millions de polygone, des gigas de textures, etc…
    Je t'invite à regarder les publications/vidéos de Mike Acton par exemple (Data Oriented Programming) ou de Jonathan Blow (qui travaille sur le compilateur de son langage Jai). Le compilateur Jai compile 20 000 lignes de code par seconde, ce qu'il trouve encore lent par rapport à ce qu'il pense possible de faire (x2).

    Le bugs auxquels tu fais référence concernent une minorité de jeux, et souvent ceux dont la date de sortie est définie avant que le jeu soit terminé. Quand les studios laisse la possibilité au devs de finir le job, en quelques mois tout est corrigé/terminé.

    Gnome, lui, n'a pas de réelle deadline. Une version "stable" sort quand elle est décrétée stable. Gnome a nécessité 20 ans de travail pour en arriver où il en est. Il ne manque pas ici de commentaires pour asseoir (ansi que leur bugtracker) que la stabilité n'est pas son fort. Personnellement, je ne faisais juste qu'une parenthèse sur la gloutonnerie de ressources.

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 2. Dernière modification le 22/09/18 à 14:26.

    Oui c'est un constat général dans le monde du logiciel.

    Il a toutefois des exceptions dans le monde :
    - de l'embarqué (car les ressources sont extrêmement limitées),
    - des applications critiques (pour la santé, le nucléaire… car des vies sont en jeu),
    - des jeux "AAA" (car il faut sortir la plus "belle" des images en moins de 10ms),
    - du calcul scientifique (car les minutes d'utilisation de supercalculateur sont chères)

    C'est aussi une culture, pour un tout jeune "développeur" web, la conso mémoire c'est un concept lointain, il sait tout au plus que sa page web va consommer 300Mo de mémoire vive dans Chrome et pour le CPU, il ne prendra "que" 10% d'un cœur de son Core i7…

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 3.

    Rappelons que stocker en mémoire une image brute (bitmap) 4k en 32bits, nécessite 32Mo.

    Un "desktop" a peine booté qui consomme 1Go, cela n'a rien de normal même en 4k.
    La crypto, la gestion de l'autonomie, l'usb ou n'importe qu'elle techno que vous allez trouver ne justifie pas cela.
    Le poids des images vectorielles c'est peanuts par rapports à leurs équivalents bitmap.

    La "gestion de l'autonomie", la crypto et le rendu vectoriel sont pris en charge matériellement depuis des années et au dernières nouvelles. Ce n'est pas le boulot de Gnome d'implémenter ces points et ils n'ont pas d'impact majeurs sur la consommation CPU.

    Je ne vois pas pourquoi un gestionnaire de session comme gdm aurait besoin d'un bitamp 4k en permanence… mais bon, si cela vous fait plaisir de vous conforter dans l'idée que les développeurs de Gnome sont à la hauteur, pourquoi pas.

  • [^] # Re: Super les gars

    Posté par (page perso) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à -1.

    Que l'OS ne protège pas (par de la mitigation ultra sophistiquée) les applications mal codées n'en fait pas un OS non fiable ou non sécurisé.

    Il a été conçu principalement pour le marché des systèmes embarqués industriels et médicaux, qui ont besoin de fiabilité et du temps réels.
    Des systèmes fermés difficilement piratables car n’exécutent pas de code externe.
    Comme le document de l'article l'explique, les processus sont complètements isolés et il ne peuvent pas planter le système. Et il n’intègre pas de blague comme le tueur aléatoire de processus de linux "en cas de besoin".

    Les commentaires sur OSNews semblent aller dans ce sens aussi.

    Bon après, c'est sûr que si tu lances gnome/gdm en root dessus, QNX ne ferra rien de magique :)

    Mais n'étant pas non plus un fanboy de QNX, je ne chercherai pas d'arguments bidons pour excuser tout bug/faille de QNX (NDLR : comme d'autre l'ont fait avec gdm…). On ne peut que souhaiter qu'ils intègrent des mitigations plus poussées. Ainsi les billes qui lancent leurs applis buggées en root, pleines de failles exploitables à distance auront moins de chances d'engendrer des morts… si des hackers ont envie de pirater leur propres assistants respiratoires, c'est pas trop mon problème.