barmic a écrit 10455 commentaires

Et c'est bien. Tu peux même te servir de cet arborescence pour jouer sur la granularité des erreurs et ne pas exposer cette précision dans ton API.

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

ça impact tout la pile

Non, ça n'impacte que ceux qui décident de ne pas se charger de ce 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)

Je ne comprends pas. Les checkeds exceptions sont là pour t'empêcher de lancer des erreurs de manière implicite (comme je le dis ça fait parti du contrat de ta méthode) et sont donc de la responsabilité de toute la pile d'appel traversante. Les exceptions non vérifiées sont pratiques pour justement traverser 80% (ou 100% qui sait ?) de ta pile sans avoir à te demander ce qui se passe.

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

Ou alors, de serveur auquel il faut coller un disque dur externe, ce qui transforme une merveille de compacité en affreux machin en deux parties, ce qui n'est pas censé être le but de ces appareils.

C'est pas lié au connecteur ça. Si tu colle un HDD à ton RPi qui sera 3 fois plus gros et 10 fois plus lourd mettant à mal toute la « merveille de compacité ».

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

Les checked exceptions qui impactent absolument tout le monde au moindre changement/ajout : non merci.

Ce n'est pas possible. Vraiment. Si tu as ce genre de situation c'est probablement que le design est à revoir. Les exceptions ce n'est pas fait pour traverser toutes ta pile d’exécution. Si tu as vraiment ce genre d'impact (ou que tu en as l'impression) c'est que tu ne maîtrise pas le cheminement de tes erreurs. De plus ça peut vouloir dire que tu expose trop de choses aux appelants.

Ce n'est pas simple, mais la gestion d'erreur n'est pas simple. Devoir traiter l'erreur à tous les étages via des retours de méthodes n'est pas particulièrement plus simple, ni agréable.

Après, si ça te gêne pas de violer SRP, c'est dommage.

Probablement parce que ça n'a rien avoir. Si tu change une exception, même si tu fais passe plat de cette exception, tu change ton contrat (à moins que ton contrat soit déjà large et qu'il annoncé une exception mère). Donc c'est ça responsabilité de l'annoncer.

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

ça pollue le code appelant

C'est de la gestion d'erreur, si tu considère que c'est de la pollution c'est dommage. De plus si elles n'en ont rien c'est de loin ce qu'il y a de plus concis.

Mais surtout, là où tu traite ton exception tu as forcément un couplage avec l'exception. Il doit la comprendre et savoir quoi en faire. Faire remonter aussi haut que tu semble le dire ton exception, pousserait à penser que tu expose du fonctionnement un peu trop interne à trop haut. Ensuite pour toutes les méthodes passe plat, c'est plutôt sympa pour avoir une meilleure visibilité des chemins que ton exception peut prendre (et les refacto peuvent facilement être automatisés).

et j'ose pas imaginer le bordel si tu mets ça dans une bibliothèque partagée publiquement, pour tous ses utilisateurs…

Le type de tes exceptions est exactement comme le type de tes paramètres ou de ton retour. Si tu casse ton API c'est dommage pour toi.

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

[…] faire des choses non standards […]

Il est décrit où ce standard ? Par qui ?

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

Juste au cas où ton interrogation soit sincère (ce dont je doute).

Tu cherche à envenimer la discussion.

Non?? Où tu vois ça? À la limite tu peux m’accuser de causer cela, mais ce n’est pas ce que je cherche.

Tu introduit des oppositions homme/femme et m'accuse d'être le produit d'une société patriarcale juste par le fait d'avoir donner un exemple. Tu ne cherche manifestement pas à débattre.

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

Personne n'a dit que c'était impossible :)

Si c'est pour empêcher ce genre de choses, je préfère par contre déclarer le constructeurs comme privé comme ça c'est vérifié systématiquement à la compilation.

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

L'initialisation par défaut doit TOUJOURS être fait, sauf si trés bonne raison, point barre.

Vous n'avez pas l'air de vous comprendre…

Il ne veut pas d'initialisation automatique silencieuse, il veut que celui qui crée l'objet se pose la question de la valeur que cet objet doit avoir.

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

Du coup je vais le dire autrement : comme le document d'archi ne donne aucune info sur un quelconque découpage de la stack cozy pour le moment pour moi c'est du pur monolithique.

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

[…] vous n'êtes pas non plus dans une approche monolithique.

Tous les diagrammes d'archi du document montrent, ils cherchent à livrer sous forme d'un unique binaire exécutable,… Le fais qu'il y ai les applications n'a rien avoir avec la notion de microservice (sinon firefox serait aussi concerné).

Pour rappel les microservices consistent à découper un logiciel en une série d'application au couplage faible communiquant entre eux via des API (souvent REST). Normalement chaque microservice est conçu par une équipe différent (d'1 à 3 personnes) et une description (que je trouve claire sur la taille d'un microservice) est : « on peut réécrire un microservice dans un autre langage en 1 ou 2 jours (on a pas à alerté le manager etc) ».

Du coup ni d'un point de vu organisationnel, ni d'un point de vu technique cela ne s'approche des microservices.

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

C'est qui « nous » ?

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

Tiens puisqu'on parle de switch, que pensez-vous de « Duff's device » ?

Personnellement je trouve ça immonde et je ne vois que des cas rares où il faut vraiment produire le code plus performant possible au détriment de tout le reste qui peuvent rendre ce truc acceptable…

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

Block new users to create/edit wiki pages

Je ne comprends pas très bien : https://github.com/linuxfrorg/linuxfr.org/commit/7c200427c6135446cd860541c758e0e6ed616a9f

Ça rend impossible l'édition si on a le karma par défaut ? Si on retombe sur la valeur par défaut (0 ? 20 ?), on ne pourra plus éditer le wiki ?

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

Solar est plus léger, non ?

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

Tu cherche à envenimer la discussion. Il n'y a pas de raison de continuer dans ce fonctionnement là. Ne soit par contre pas surprise de récolter la qualité de débat que tu sème (autrement dit ne vient pas ensuite pleurnicher au près des modérateurs que tel ou tel membre ne réagit pas comme tu le souhaiterais).

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

Merci pour toutes ces précisions

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

Le seul truc que j’ai trouvé c’est cet article qui confirme mon point de vue. Il existe probablement des produits pour hommes plus chers, mais globalement quand des produits identiques sont marketés «rose» ou «bleu», c’est les roses qui sont les plus chers.

Donc il faut ignorer l'existence du problème inverse ?

Les normes de beauté peuvent être très violentes

Oui mais ça n'a rien avoir avec l'existence ou non de norme de beauté. C'est l'hyper médiatisation qui fait ça. Ça marche aussi bien avec les normes de beauté qu'avec n'importe quel forme de réussite (ou échec) social. L'hypermédiatisation (les réseaux sociaux, mais pas que) permettent à certains de devenir des starts ou au contraire de se faire démolir.

On peut citer le fait que les femmes[…]

Pourquoi tu me sors une tirade sur le ton de pour les femmes c'est pire ? Quand tu es dans cette situation c'est aussi difficile pour un homme que pour une femme (tes statistiques ne vont pas aider ni l'un ni l'autre). Pourquoi mets-tu immédiatement homme et femme en opposition ? La pression esthétique est plus forte chez les femmes, elle n'est pas pour autant inexistante chez les hommes. Pour l'exemple, un homme petit c'est largement plus mal vu qu'une femme petite et ne t'inquiète pas il n'existe aucune chirurgie esthétique pour y remédier. Il est juste possible de porter des talonnettes. Mais ce n'est qu'un exemple j'aurais pu te parler de taille de sexe, hein ?

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

Du coup, ça permet de faire des choses assez sympas, comme avoir dans le navigateur une base de données locale, qui peut fonctionner en mode offline et se resynchroniser quand le réseau revient.

Ok merci je vois. Mais il y a quoi comme sécurité pour ne pas totalement exposer sa base au client du coup ? Authentification, gestion de quota ou ce genre de choses ou alors tout est en HTTP et vous vérifiez ça via un reverse proxy ?

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

Effectivement, CouchDB sort des modèles classiques de base de données et il faut souvent un peu de temps avant de comprendre comment l'utiliser.

C'est un peu le cas de toutes les db non relationnelle.

En particulier, la réplication est très puissante et on s'en sert beaucoup (pour le partage entre instance cozy, ou la synchronisation des contacts et calendriers entre le cozy et un smartphone).

Tu en parlais plus haut, j'ai pas compris ce qu'elle avait de particulier dans leur doc. Tu peux en dire plus ?

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

Éventuellement tu peux scoper :

Ça résous que partiellement, tu n'a pas vraiment de lisibilité sur quels sont les données d'entrée et de sortie de chaque cas.

Ce pattern n'est pas si mal adapté aux switches :

int map(char value) {
    switch (value) {
    case 'a': return 12;
    case 'b': return 642;
    case 'r': return 727;
    // …
    }
}

Oui c'est une option (c'est aussi une solution pour ce dont je parle au dessus). Mais vraiment je préfère une construction comme ici (avec guava) :

public static final Map<String, Integer> myStruc = ImmutableMap.<String, Integer>builder()
           .put("foo", 42)
           .put("bar", 84)
           .build(); // on peut utiliser .of() dans ce cas c'est plus concis

On peut plus tard imaginer charger ces valeurs depuis un fichier.

En java en plus dans une Map, tu vas devoir wrapper ces valeurs dans des objets.

J'avoue ne pas connaître le coût de l'auo(un)boxing. Tu as plus d'info là dessus ? (je sais qu'il y a des systèmes de cache dans la JVM pour certaines valeurs 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)

Cascade de if/else : il me faut moins d'une seconde pour reconnaître la structure du code, même si c'est un peu moche car répétition du « else if (str == ».

Personnellement il m'en faut bien plus (quelque soit le langage) pour vérifier que l'on fait un test d'égalité sur la même variable et qu'on a pas des doublons… Le if/else laisse toute l'amplitude a faire tout et n'importe quoi ce que je trouve très gênant. Personnellement je considère la multiplication de if dans un code comme un code smell donc je préfère éviter dans ajouter.

La solution soit disant « élégante » avec les templates : je n'ose imaginer le temps que ça me prendrait pour me rendre compte de quoi il s'agit… Heureusement que je savais qu'on essayait de reproduire une cascade de if/else.

Question d'habitude. Quand tu commence à jouer avec des API fluent, ça se lit vite.

std::function : c'est mieux que la précédente (templates), mais ce n'est pas plus beau que les if/else (il y a tout plein de symboles qui ne rendent pas les choses plus lisibles à mon sens). Je pense qu'il me faut ~10 secondes pour être certain de bien interpréter (comprendre : qu'il n'y a pas un piège subtile qui se cache derrière cette conception).

Là AMHA le problème vient des lambdas du C++ qui sont trop complexes.

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

je sais qu'il y a des études là dessus, mais ça reste très loin de mise en production (si tu crypte les données, adieu les indexes, les vues, etc…)

Le chiffrement homomorphique est discuté dans leur document : https://github.com/cozy/cozy-stack/blob/master/doc/architecture.md#encrypted-data

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

Et pour les chagrins qui veulent du code dans leur case: on peut utiliser une std::function (mais il y a un coût caché). Un truc du genre :

C'est ce que je fais de plus en plus (alors que mon langage a un switch sur les java.lang.String ;) ). Je vois de plus en plus de problèmes aux switch/case :

• ils alourdissent fortement le code
• chaque case leak son contexte avec le reste du code
• ils sont piégeux (qui n'a pas un jour oublié le break ?)
• il est difficile de tester chaque case
• il est possible d'ajouter des fonctions mais ça ne rend pas le code énormément plus simple
• lorsqu'il s'agit juste de choisir une valeur (encore plus que lorsqu'il s'agit d'un calcul), on voudrait pouvoir être totalement déclaratif ('a' → 12, 'b' → 642, 'r' → 727,…)

Du coup pour toutes ces raisons j'ai une lourde préférence pour utiliser une Map. Je la déclare et construit en statique à la classe, donc le coût de construction n'est payé d'une seule fois par exécution et tant que je n'ai pas de vrai besoin de performance (et que l'on a pas encore établi que les problème venait de là) je garde le tout sous cette forme.

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