barmic a écrit 10455 commentaires

  • [^] # Re: Rien de neuf

    Posté par  . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 5.

    Ensuite, le problème de JAVA, c'est que la machine virtuelle avait une connexion directe avec la machine physique.

    Entre une machine virtuelle (la JVM) et une autre (V8 par exemple), ça n'est pas si différent.

    Le problème c'est que là où les moteurs sont partis de petits pour ajouter des fonctionnalités en ayant dès le départ la notion de sécurité en tête. La JVM pour les applets est une vm généraliste qui tente de limiter les accès et c'est bien plus compliqué à faire (en fait ça demande un travail que ni Sun, ni Oracle n'ont voulu payer).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Ah oui, quand même

    Posté par  . En réponse à la dépêche Séminaire de réarmement intellectuel et technique sur le "Big Data". Évalué à 5.

    Le prix du temps de travail des professionnels qui catalyseront la construction collective qui aura lieu dans ces deux jours.

    Avec ce premier séminaire ? Qui est là pour réarmer intellectuellement ?

    Je ne doute pas que c'est le prix, mais pour moi ça veut plus dire que ce n'est pas la bonne façon de faire. Tu ne peux pas espérer avoir un publique large (comme c'est espéré dans le premier paragraphe de la dépêche) et demander un tel investissement initial.

    Si un logiciel n'a pas de prix, le travail lui en a un…

    Je n'en doute pas. Mais il y a pleins de façons de faire (par exemple avec du sponsoring) ou en commençant moins grand.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Pas pire

    Posté par  . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 10.

    sans bac à sable

    Si si, il y a celle de tout code JS. Il ne s'agit pas d'un plugin de ton navigateur, mais d'une JVM implémentée en js donc elle ne sort pas (de ce que j'ai compris) de ton moteur js. C'est pas très différent de la VM complète écrite en JS (je crois que c'était Samuel Hocevar qui l'avais fait).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: En Metapost

    Posté par  . En réponse au journal Écrire des diagrammes de séquences. Évalué à 4.

    Je ne connais pas METAPOST, mais j'ai déjà fais du tikz. Il y a un système de positionnement qui n'est pas nécessaire pour un digramme de séquence. Mais c'est sympa et assez facile finalement :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: seqdiag

    Posté par  . En réponse au journal Écrire des diagrammes de séquences. Évalué à 5.

    Ça me fait penser qu'on peut détourner des logiciels de visualisation de traces pour ça (comme ViTE).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # seqdiag

    Posté par  . En réponse au journal Écrire des diagrammes de séquences. Évalué à 6.

    J'ai eu le même besoin récemment et je suis passé par seqdiag.

    Je n'avais pas de besoin aussi sophistiqués que toi, mais il était nécessaire pour moi de travailler avec du texte. En effet je génère mes diagrammes à partir de CSV que je sors de wireshark (et j'ai une moulinette awk qui génère la source du diagramme).

    Ton outil a l'air très sympa :)

    C'est agréable d'avoir une sortie PNG, mais pour moins t'embêter à ta place j'aurais plutôt généré du SVG ou du postscript (qui ne nécessitent pas de bibliothèque en plus pour leur génération).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: faudrait donner quelques explications.

    Posté par  . En réponse au journal Fin du monde en vue ?. Évalué à 7.

    De deux car le monde ne tourne pas autour […] de l'informatique loin de la […]

    (désolé de tronçonner ta phrase, mais je ne pense pas en changer le sens)

    J'ai l'impression que si au contraire. Du moins ça dépend de ce qu'on entend par « le monde tourne autour ». Dans les pays riches, la société de l'information est omniprésente et j'ai l'impression qu'on développe une dépendance forte à tout cela. Ce n'est pas qu'une histoire de réseaux sociaux. De manière direct, nous nous sommes créé un besoin de nous informer partout tout le temps1. De manière indirect, nous faisons dépendre de plus en plus de choses de l'informatique (si là maintenant dans l'instant ta carte bancaire disparaît et que ta banque t'annonce 2 ou 3 semaines avant que tu la reçoive par exemple ? - je sais les allemands sont très liquide il paraît, mais ils retirent aux guichets ou aux distributeurs ? -).

    Bien sûr on survivrait à l’absence de l'informatique, on en a pas un besoin physionomique, mais ça serait dans la douleur.


    1. dédicace aux pubs de voitures ou de nourriture qui essaient de vendre leur produit en parlant de réseaux sociaux ou en te vendant des tablettes par exemple… 

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: faudrait donner quelques explications.

    Posté par  . En réponse au journal Fin du monde en vue ?. Évalué à 3.

    Oui oui on est d'accord. La phrase que je cite ne parle pas de base mutualisée que Free le fait (du moins c'est ce que j'avais compris).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Et neovim maintenant ?

    Posté par  . En réponse au journal [Bookmark] Vim 8. Évalué à 5.

    Si on parle de ça quel est le rapport avec un éditeur de texte ? Je sais que chez emacs ils imaginent des tas de trucs tous aussi inutiles les uns que les autres pour tout faire avec emacs, mais eux… Jack c'est surtout pour faire de la production audio si je ne m'abuse. Pouvoir développer un logiciel de montage non linéaire en plugin de vim c'est peut être un chouia too much, non ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: faudrait donner quelques explications.

    Posté par  . En réponse au journal Fin du monde en vue ?. Évalué à 9.

    […]donc ta base est rarement exposée à des requêtes arbitraires.

    Si tu es sujet à de l'injection SQL alors tu avais déjà un problème :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Et neovim maintenant ?

    Posté par  . En réponse au journal [Bookmark] Vim 8. Évalué à 2.

    C'est quoi ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: algo

    Posté par  . En réponse au journal DeuSu, un moteur de recherche libre avec son propre index. Évalué à 6.

    Euh… lol ^^

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

    Plutôt la couche en dessous

    Donc dans l'Action ?

    avec des catch que des if/else if

    Il n'y a pas de différence, tu as un bloque de code de traitement dans ton UI par possibilité d'erreur dans l'Action et potentiellement pour la combinatoire des différentes Actions. Mieux tu peux avoir des exception identiques pour des Actions différentes qui demandent donc des réactions différentes en terme d'affichage utilisateur. Tu peux avoir une IOException pour pleins de raisons différentes et dans des cas d'accès disques ou réseau.

    Certaines doivent être transformée avant car n'intéresse pas le niveau plus haut, mais si tu choppes ton exception pour juste la renommer "parce que", je m'insurge.

    On va pas boucler là dessus ?

    Typiquement si ton parseur de nombre dans le xml te pête à la gueule te disant juste NumberFormatException, ça à du sens de la chopper au dessus disant que c'est le parsing xsd qui vient de foirer en ajoutant ligne+colonne de l'erreur. Par contre chopper toutes les Exception lors de la lecture d'un fichier pour les transformer en JYarrivePasException, non. Les actions à entreprendre peuvent dépendre du type de l’exception; donc pas au niveau de L'UI qui ne devrait faire que de l'affichage, mais juste en dessous. (par exemple ouvrir une fenêtre avec un gros point rouge sur la ligne qui a planté le parsing).

    Rien empêche d'avoir ça dans ton exception plutôt que dans le code de l'UI. Je l'ai déjà dis plus haut, mais bon. Imagine tu ta gestion d'erreur soit relativement simple et consiste à afficher un message à l'utilisateur. Si tu sors une exception qui contient :

    • un identifiant d'erreur
    • une liste de variables nommées qui donnent un contexte à ton erreur (pour le cas d'un xml que tu n'arrive pas à parser : ligne, colonne, nom du fichier, nom de la balise si possible, code d'erreur de ton parseur, identifiant de l'erreur,…)

    Ton UI va devoir :

    • attraper l'exception
    • récupérer le format du message d'erreur à partir de l'identifiant de l'erreur et de la locale
    • générer le texte utilisateur à partir du format qu'il vient de récupérer et des variables contenues dans l'exception

    et ce bout de code sera identique à pas mal de cas. xcomcmdr sera content car la SRP sera vraiment respectée l'UI ne s'intéresse pas à savoir comment est-ce que l'Action se débrouille pour rendre son service !

    Bien sûr ça n'est pas aussi simple, par exemple les parseurs XML te fournissent généralement une liste d'erreur, c'est au développeur de voir comment il veut gérer ces cas pour l'utilisateur.


    Les checkeds exceptions devraient être utilisées comme ça. Elles ne sont pas parfaites, il y a pleins de cas où elles sont sous-optimales, voir carrément embêtante, mais affirmer qu'elles sont mauvaises parce que quand on les utilise mal elles sont chiantes à gérer ne me semble pas plus intéressant que ça. Il faut savoir comment elles devraient être utiliser pour pouvoir ensuite savoir quand les utiliser ou pas.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: recherche

    Posté par  . En réponse au journal DeuSu, un moteur de recherche libre avec son propre index. Évalué à 7.

    Je fais une recherche pour tester avec « linuxfr », et le premier résultat qui tombe est mon propre flux atom (http://linuxfr.org/users/goffi.atom), c'est une coïncidence ? Je n'ai pas ajouté « goffi » ou quoi que ce soit.

    Pour moi aussi c'est ton flux qui sort en premier.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 2.

    Pareil si c'est un soucis d'encodage du fichier ou du format qui n'est pas le bon, c'est l'utilisateur qui à la main sur ce qu'il donne. Si y a un problème de verrou sur le fichier c'est encore lui qui sait quel fichier il peut fermer.

    Donc l'UI doit savoir faire tout ça ? Si par configuration tu as le choix entre une action qui va accéder au disque, à une base de données ou à un webservice, ton ui va devoir gérer chacun de ses cas dans un enchaînement de if/else/if ? Les exceptions te permettent de gérer chacun de ses cas dans des classes différentes et soit d'être génériques soit par polymorphisme effectuer le bon traitement.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 2.

    Merci :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.

    Je ne suis pas d'accord. L'UI n'a pas à savoir qu'il peut y avoir une IOException, une SQLException ou je ne sais quoi d'autres, c'est de la logique interne de l'implémentation de ton Action que tu leak.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

    Je vois pas comment m'expliquer plus clairement. Les choses sont liées entre elles. Si tu as une abstraction, elle doit bien avoir un sens, non ? Tu est sensé faire le même boulot d'abstraction avec tes exceptions qu'avec le reste de ton code. Ça donne un comportement cohérent à ton API.

    Il ne s'agit en aucun cas de faire un rethrow de l'exception tout juste encapsulée dans une nouvelle exception, mais de faire un travail de normalisation à fin de permettre à l’appelant d'utiliser ton abstraction de manière facilité et de ne pas avoir à se préoccuper de tous les cas, mais uniquement à faire un travail de présentation (pour l'exemple du dessus).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.

    qui dit exactement la même chose

    Ben non. Elle fait l'abstraction. Une exception comme IOException est inutilisable pour une interface graphique. Elle n'a qu'un message (voir : https://docs.oracle.com/javase/8/docs/api/java/io/IOException.html). Si tu veux avoir un message un minimum propre dans ton interface il va falloir avoir une description de l'erreur plus intelligente que ça. Par exemple un code d'erreur et une série de paramètres (le chemin ici par exemple). Le code peut te permettre d'avoir un message d'erreur localisé qui sera formaté avec les paramètres contenu dans la nouvelle exception. Tu peux aussi catégoriser l'erreur pour pour pouvoir faire des renvoies aux documentation de ton logiciel qui concernent cette partie.

    Exactement la même chose dis-tu ? ^^

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: autorisation explicite pour une image??

    Posté par  . En réponse au journal [Bookmark]Les liens vers des contenus sont illégaux, sont illégaux (sous 2 conditions). Évalué à 6.

    Tout ça pour dire que ta généralisation est rapide, trop rapide

    Hum ? On me parle du droit, non ? Aller voir le site du service publique conçu pour ça est une généralisation ? En quoi ?

    Qu'il y ai une certaine liberté flexibilité avec ce droit c'est possible, mais je ne généralise pas je dis juste ce que la loi dit et elle ne semble pas dire :

    […] le droit […] autorise des copies même dans sans autorisation explicite (sous conditions).

    Où tu semble dire qu'on a le droit sauf dans certains cas, alors que c'est plutôt on a pas le droit sauf dans certains cas.

    Je ne doute pas que les photos de journalisme entrent dans les cas exceptionnels ou que ce droit est peu ou mal appliqué (pour de bonnes ou de mauvaises raisons). Mais de base sortir son smartphone prendre une photo de quelqu'un et l'envoyer sur instagram n'est pas autorisé en France, quelque soit la beauté de la photo :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: autorisation explicite pour une image??

    Posté par  . En réponse au journal [Bookmark]Les liens vers des contenus sont illégaux, sont illégaux (sous 2 conditions). Évalué à 7.

    Comme je l'ai dis, je ne suis pas sûr de moi, mais puisque tu semble si prompte à me rentrer dedans j'ai vérifié :
    https://www.service-public.fr/particuliers/vosdroits/F32103

    Votre image est une donnée personnelle. Vous avez donc un droit sur son utilisation et vous pouvez vous opposer à sa conservation ou sa diffusion publique sans votre autorisation, sauf cas particuliers.

    Le reste de la page semble on ne peut plus clair et piétine presque chacune de tes affirmations :

    • le droit est à priori
    • l'autorisation est toujours nécessaire sauf cas particulier (et pas l'inverse)
    • cela concerne aussi bien les anonymes que les personnes connues

    J'ai été souvent "menacé" de poursuites pour avoir publié mes photos prisent sur la voie publique et j'attends toujours une injonction.

    Peut être est-ce uniquement de la chance ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.

    "L'UI qui s'occupe des SQLExceptions du Data Layer ? Je vois aucun problème avec ça. SRP n'est aucunement violé !"
    - barmic , 2016

    C'est justement ce que je dis. Tu ne devrais avoir ni SQLException, ni IOException au niveau de l'UI (que ce soit dans les signatures utilisées ou dans le code). À la place tu devrait avoir une abstraction. C'est bien le fait de propager très loin ton exception qui viole la SRP.

    Si dans l'exemple de l'article que tu présente, l'Action ou le Repository (la responsabilité de chacun n'est pas très clair avec juste le nom) aurait encapsuler l'exception dans un type comme ActionException (nom peut être mal choisi). Tu aurais :

    • pas de viol de la SRP
    • meilleur respect de Demeter
    • plus de robustesse aux évolutions

    Ça fait combien de fois que je dis qu'il ne faut pas propager comme ça les exceptions ? Tiens je le dis juste dans le commentaire où tu répond bizarrement…

    Tu peux répéter à l'envie que les Checked Exceptions n'apportent aucun problème […]

    Non je dis que ton argument est mauvais pas que les checked exceptions sont exempte de problème. Les API fluent (très en vogues en ce moment) ne marchent pas très bien avec. Tu as des cas où il est plus agréable de faire autrement (code de retour, Optional, pour les API fluent ou de promesse avec des onException()).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: autorisation explicite pour une image??

    Posté par  . En réponse au journal [Bookmark]Les liens vers des contenus sont illégaux, sont illégaux (sous 2 conditions). Évalué à 2.

    Il n'y a pas besoin de ça, le droit est bien plus complexe et autorise des copies même dans sans autorisation explicite (sous conditions).

    Le droit à l'image est à priori si je ne m'abuse (et il est largement violé par beaucoup de photographes).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.

    Tu peux répéter la même chose à l'envi ça ne rendra pas les choses plus vraies pour autant.

    Si tu change le comportement extérieur de UserRepository.getContent(Path) ça signature change que ce soit explicite ou implicite les cas d'erreurs changent (c'est pas un problème de java ou autre). C'est factuel. Le fait que tu ne veux pas le voir apparaître dans ton code sans autre raison que « ça fait des choses à changer » (alors que ça ne fait que mettre en évidence ce qui a changé), n'est pas plus intéressant que ça. C'est comme si tu me disais que le typage statique est contraignant parce que si tu change le type d'une variable, tu dois le reporter partout où tu t'en sert.

    Surtout que c'est dans des cas rare que tu fais ça. Selon ton niveau de design tu va présenter un type d'exception et tu va encapsuler toutes exceptions spécifiques comme un sous type de se dernier. Dans l'exemple de l'article, tu expose ton implémentation donc oui chaque modification va tout bazarder. Mais le design de l'exemple est à revoir AMHA.

    D'ailleurs (c'est assez marrant) l'auteur met le doigt sur le problème :

    Moreover, if you use an interface of a library (e.g. Action.execute()) you are not able to change the signature at all.

    C'est bien que lever une IOException dans une méthode AddUserAction.execute(Object) n'est probablement pas une bonne idée.

    Pour moi l'erreur consiste à avoir une approche bottom-up plutôt que top-down. Ici la question qu'il faut se poser c'est est-ce que ContextMenu.menuClicked() a quelque chose à faire d'une IOException ? Ce qui l'intéresse c'est peut être plutôt de savoir que l'Action ai échouée. Que ça vienne d'une erreur d'IO, d'une connexion à la base raté ou autre, ne change probablement pas vraiment son comportement, non ? Si son job c'est d'afficher l'erreur qui va bien à l'utilisateur alors ça peut carrément être traité dans une exception générique à tous les cas.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Mauvaise connaissance du c++

    Posté par  . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

    Bon, va te documenter sur la différence entre les Checked Exceptions et les Exceptions normales

    Je suis aller voir si je ratais quelque chose et ils semble que non, c'est assez simple. Les exceptions non vérifiées peuvent être ignorée silencieusement alors que les autres doivent être géré (soit par un try/catch soit par un throws) et c'est vérifié statiquement.

    et pourquoi seul Java les implémente

    Pas trouvé grand chose là dessus. Le seul truc qui parle d'une controverse que j'ai trouvé c'est ça : https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
    En cherchant un peu différemment j'ai trouvé ça d'intéressant : http://stackoverflow.com/a/18472120. Globalement il y a quelques arguments :

    • la distance entre l'erreur et sa gestion. J'en ai déjà parlé si c'est si long que ça c'est que tu as des modules bien trop gros (il devient difficile d'avoir une compréhension simple de « j'ai une erreur ici, ça se répercute là »)
      • il y a un argument sur l'encapsulation que je ne comprends pas du tout. L'encapsulation consiste basiquement à cacher la représentation interne pour n'exposer qu'une API (pour moi les erreurs font partie de l'API, mais bon). Plus tu écarte cette gestion d'erreur de l'endroit où elle est levée, plus tu expose de ton fonctionnement interne. Pire tu complexifie l'usage de ton API en ayant des cas implicites. Au final on viol la loi de Demeter.
    • l'existence d'unchecked exception empêche de faire de l'exception-free. L'exception-free est un mythe, ça ne peux fonctionner que sur du code sans allocation par exemple. Ce n'est pas du tout ou rien. Tu as toutes les erreurs métier qui peuvent se gérer comme ça et c'est déjà énorme
    • des questions de performance. Ok mais c'est au détriment de la qualité du code (on perd l'analyse statique de la gestion d'erreur)

    parce que là tu parles dans le vide…

    Il semble en effet. C'est dommage, mais j'aurais au moins essayé de communiqué.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)