Journal MailPile, le prochain diaspora? Ou pas…

Posté par  . Licence CC By‑SA.
Étiquettes :
-9
10
oct.
2013

Si ceci était un journal bookmark, il n'y aurai que ce lien

Il y a bien longtemps, une petite équipe d'étudiants inexpérimentés (et un peu bras cassés) lancent l'idée du siècle! Faire un réseau social libre, concurrent de facebook, et distribué…

Il lancent une campagne de dons et réunissent 200k$ au lieu de 10k$. Après un peu de temps les gens se rendent compte de l'arnaque!
Au lieu d'adopter le concept de « release early, release often », il nous sortent un beau jour un énorme bloatware en ruby on rails, mal conçu, mal codé avec 50 % des fonds épuisés.

À la fin, le projet est abandonné^W donné à la communauté.

Cher journal,

L'histoire semble recommencer. MailPile est un projet islandais par des gens qui on l'air expérimentés. L'idée est d'offrir un client mail qui simplifie le chiffrement et qui peux être utilisé comme webmail.

Ils ont récemment lancé une campagne de don qui a bien marché: 160k$ au lieu de 100k$.

Le code a été publié dès le premier jour

Il y a toujours quelque problèmes

  • Les fichiers pour faire le paquet Debian dans le dépot principale. C'est une des plus mauvaise pratique que j'ai vu. La configuration des paquets debian est dans un dépot à part. Vont-il ajouter Red Hat, Gentoo et Arch?
  • Ils utilisent docker pour le développement alors que virtualenv est fait pour ça.
  • Il utilisent un fichier requirements.txt au lieu de spécifier les dépendances dans le setup.py.
  • Ils utilisent l'AGPLv3 comme diaspora

Le code est plutôt cracra, avec des:

if condition: action

Ou encore:

if condition
and condition:
    action

La PEP8 est très souvent ignorée.

Et toi, Journal, qu'en penses tu?

  • # Libre

    Posté par  . Évalué à 9.

    Ben j'en pense que le code est libre et que ça permet d'envoyer des patchs correctifs s'il y a des choses à corriger.

    • [^] # Re: Libre

      Posté par  . Évalué à -1.

      En général les développeurs râlent quand on leur fait remarquer les problèmes d'indentation, de lisibilité, etc. Il faut un motif plus sérieux pour envoyer un patch.

      • [^] # Re: Libre

        Posté par  . Évalué à 4.

        C'est idiot. Si tu envoies un patch pour la présentation, c'est que tu as déjà fait le boulot fastidieux. Le dev devrait être content, non ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Libre

          Posté par  . Évalué à 7.

          C'est idiot. Si tu envoies un patch pour la présentation, c'est que tu as déjà fait le boulot fastidieux. Le dev devrait être content, non ?

          Ca dépend. Sur un petit projet oui. Sur un gros projet distribué où ca va faire des conflits pour 100 dev et péter tout les patchs soumis et en attente il faut vraiment vraiment que ca vaille le coup…

          Si le code initial n'était pas lisible alors c'est qu'il y a un problème quelque part dans le process. Si il était lisible, alors est ce que le netoyage vaut le cout par rapport au bruit et a la maintenance qu'il ajoute ?

      • [^] # Re: Libre

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 10 octobre 2013 à 11:50.

        Perso, j'ai un gars fan de l'indentation et autre truc cosmétique, qui m'envoie les patchs, et je les accepte, ça permet d'avoir un code plus propre.
        Le tout est que ça prenne pas trop de temps pour le dév principal (du coup, mon gars a carrément les droits de commit maintenant, et il repasse sur mes nouvelles conneries d'indentation assez souvent)

        Je ne vois pas pourquoi on devrait refuser ce genre de patch (si ça bouffe pas trop de temps, bien entendu), surtout que pour moi c'est chiant à faire mais que lui aime faire, tout le monde est content.

        • [^] # Re: Libre

          Posté par  . Évalué à 1.

          Attention aux… guerres d'indentation !

          Après, s'il y en a pas, c'est tout bénef en effet.

          • [^] # Re: Libre

            Posté par  (site web personnel) . Évalué à 5.

            Y'en a pas ;-) PEP8 !

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: Libre

              Posté par  . Évalué à 1.

              Ça vaut pas pour tous les langages. Si on part sur du c++, comme le dit l'exemple plus bas, ou le logiciel de Zenitram plus haut, ça peut être vraiment violent.

              • [^] # Re: Libre

                Posté par  (site web personnel) . Évalué à 3.

                Si le projet a des règles définies concernant la présentation du code, un coup de AStyle et c'est bon.

                Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: Libre

        Posté par  (site web personnel) . Évalué à 7.

        Ça dépend du langage. En C/C++, les dev vont râler car il s'agit de leur style. S'ils ont codé comme ça, c'est que ça leur plaît.

        En Python, où il y a des lignes de conduite (PEP 8) plus précises et officielles, ça passe beaucoup mieux.

        • [^] # Re: Libre

          Posté par  . Évalué à -1.

          Spaces are the preferred indentation method.

          Je ne fais pas de python, mais je n'aime déjà pas PEP8.

          • [^] # Re: Libre

            Posté par  . Évalué à 4.

            Je prédis un -10 sur ton commentaire (et par extension le mien aussi), l'inquisition anti-tabulation était très puissante.

            • [^] # Re: Libre

              Posté par  . Évalué à 5.

              C'est une vraie cabale !

          • [^] # Re: Libre

            Posté par  (site web personnel, Mastodon) . Évalué à 7.

            Les espaces servent à espacer, les tabulations servent à aligner, du coup on utilise des espaces pour aligner. Logique.

            Et je parle pas de la taille des sources (8 caractères au lieu d'un et ce plusieurs fois par ligne ça doit pas être anodin question taille de fichier).

            • [^] # Re: Libre

              Posté par  . Évalué à 5.

              Le problème des tabulations c'est que leur taille varient. Si tu veut faire une indentation comme ça :

              int main(int argc,
         char** argv) {

              Tu ne peux pas. Si dans des cas particuliers comme là :

              switch(machin) {
  case toto:
    bidule();
    break;
  default:
    // truc
}

              Tu veux utiliser des demi-indetation, ben c'est pas possible.

              J'ai entendu dire qu'il y avait des gens qui savait faire en sorte que leur code indenté avec des tabulations peut subir des changement de taille d'indentation sans que ça ne change la lisibilité de la chose, mais c'est rare.

              Et je parle pas de la taille des sources (8 caractères au lieu d'un et ce plusieurs fois par ligne ça doit pas être anodin question taille de fichier).

              Sur un langage compilé tu t'en fous, comme tous les langages sont compilés (sauf quelques rares), tu t'en fou tout le temps.

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

              • [^] # Re: Libre

                Posté par  . Évalué à 4.

                Le problème des tabulations c'est que leur taille varient

                C'est justement leur principal intérêt, les gens préférant des indentations de 1, 2, 3, 4, 5, 6, 7, 8 espaces ou plus (ou des indentations négatives) peuvent travailler ensembles de manière plus transparente.

              • [^] # Re: Libre

                Posté par  . Évalué à 4. Dernière modification le 10 octobre 2013 à 15:30.

                Le problème des tabulations c'est que leur taille varient. Si tu veut faire une indentation comme ça :

                Je t'ai mis un code qui mixe espaces et indentation pour avoir un affichage correct quelque soit la taille des indentations. Chez moi par exemple c'est 8 et linuxfr c'est 4, pourtant le code s'affiche bien.

                Mon editeur est emacs et il gère cela tout seul.

                #include <stdio.h>
#include <stdlib.h>


int main(int argc,
         char** argv) {     /* Espaces, car le but est d'avoir un alignement */

    /* Ensuite que des indentations */
    switch(argc) {
    case 1:
        printf("lol%s\n",
               argv[0]); /* Ici, 2 indentation, et ensuite des espaces pour aligner */
        break;
    default:
        puts("Wrong");
    }

    return EXIT_SUCCESS;
}

                • [^] # Re: Libre

                  Posté par  . Évalué à 2.

                  Merci pour le très bon exemple. :)

                  Mais je trouve que ça deviens compliqué s'il faut mélanger les deux (même si je comprend le principe).

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

                • [^] # Re: Libre

                  Posté par  (site web personnel) . Évalué à 6.

                  EN fait je crois que cet exemple est justement celui qui justifie le choix des espaces dans la pep8:
                  choisir des espace ou des tab pour l'indentation peu importes, mais pas de mélange c'est trop horrible en python (vue que l'indentation fait partie du code)

                • [^] # Re: Libre

                  Posté par  . Évalué à 1.

                  Je suis totalement d'accord avec cette utilisation des tabulations. J'ai l'impression que c'est le même débat que pour les langages typés ou dynamiques : on veut associer un sens à chaque élément, sans dépendre du contexte. Tant que je n'aurais pas compris pourquoi on peut préférer un langage dynamique je ne comprendrai pas ceux qui veulent indenter avec un nombre arbitraire d'espaces.

                  En fait je suis plus rigide encore: je n'aligne jamais du code, mais ajoute un niveau d'indentation, mon code est peut-être aussi lisible avec une police à taille variable.

                • [^] # Re: Libre

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Parfait, c'est ce que je fais aussi, ça permet d'associer le meilleur des deux mondes. =)

                  Après Python est un cas à part…

          • [^] # Re: Libre

            Posté par  . Évalué à 2.

            Je ne l'ai pas lue en entier mais elle m'a l'air relativement souple.

            Rien que sur les indentations :

            Spaces are the preferred indentation method.

            Tabs should be used solely to remain consistent with code that is already indented with tabs.

            En gros, c'est conseillé mais pas obligatoire.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Libre

            Posté par  . Évalué à -1.

            Moi je n'utilise pas de voiture, mais je tiens à dire que je n'aime vraiment pas le code de la route.

            • [^] # Re: Libre

              Posté par  . Évalué à 5.

              Très mauvais exemple.

              Le code de la route, concerne (liste non exhaustive) :

              • les automobiles,
              • les autobus,
              • les autobus articulés,
              • les véhicules remorqués,
              • les cyclomoteurs,
              • les cyclistes,
              • les (cyclistes) assistés,
              • les véhicules agricoles et forestiers,
              • les véhicules à traction animale,
              • les engins de service hivernal,
              • les piétons.

              Pour se retrouver dans aucune des catégories que j'ai cité, il faut vraiment le vouloir.

              • [^] # Re: Libre

                Posté par  (site web personnel) . Évalué à 2.

                Il habite sur une plate-forme de forage ;)

                Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # AGPLv3

    Posté par  (site web personnel) . Évalué à 10.

    Quel est le problème avec la AGPLv3 ?

  • # Indentation

    Posté par  (site web personnel) . Évalué à 7.

    Je ne pense pas que l'indentation soit un critère important sur la qualité et la beauté du code.
    C'est bien entendu important de respecter la PEP8 ou d'autres styles lisibles, mais cela se change facilement et automatiquement.

    Je préfère ça a un problème d'architecture, de conception ou de cohérence qui sont plus délicats à repérer et corriger.

  • # Aucune chance

    Posté par  (site web personnel) . Évalué à 10.

    Parfois ils mettent une espace entre des {} et parfois non. Je mets peu d'espoir dans l'avenir de ce projet s'ils ne font pas d'efforts pour améliorer tout ça.

    Et comme Diaspora, ils utilisent un site web pour présenter leur projet. S'ils font tout comme Diaspora, ça va se planter, c'est sûr…

    blog.rom1v.com

    • [^] # Re: Aucune chance

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 10 octobre 2013 à 11:43.

      Ce qui m'inquièterait, à la rigueur, ce serait qu'ils fassent leurs boucles à la main sans list-comprehension, ou bien qu'ils fassent du caca avec l'héritage ou bien qu'ils n'aient pas de cloisonnement correct de leurs objets…

  • # virtualenv en dev

    Posté par  . Évalué à 10.

    Ils utilisent docker pour le développement alors que virtualenv est fait pour ça.

    Faux et il n'y a pas à chercher bien loin: c'est juste documenté sur la page d'accueil du dépôt, et juste avant la section qui explique comment utiliser le projet avec docker, ce qui laisse supposer que docker est une méthode alternative de leur point de vue.

    https://github.com/pagekite/Mailpile#developing-using-virtualenv

  • # requirements.txt et répertoire debian

    Posté par  (site web personnel) . Évalué à 4.

    Comme pour le moment, le projet est orienté dev, il semble normal de préférer requirements.txt à setup.py.

    Quant au fait de proposer le répertoire debian dans le dépôt même, cela n'a jamais été une mauvaise pratique tant que les tarballs releasés sont exempts de ce répertoire. Tiré du wiki:

    Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default.

  • # sécurité ou pas

    Posté par  . Évalué à -2.

    un webmail qui te propose d'utiliser OpenPGP, ça veut dire qu'il faut que tu mettes ta clef privée sur leur serveur ?

    moi je trouve pas ça génial

    • [^] # Re: sécurité ou pas

      Posté par  . Évalué à 6.

      Ça veut dire qu'il faut mettre ta clef privée sur TON serveur… ou ton installe locale : ce truc est prévu pour tourner même à partir d'une clef usb.

    • [^] # Re: sécurité ou pas

      Posté par  . Évalué à 2.

      http://openpgpjs.org/ et HTML5 pour le stockage des clefs localement dans le navigateur. Si si, ça marche.

      • [^] # Re: sécurité ou pas

        Posté par  . Évalué à 2. Dernière modification le 10 octobre 2013 à 23:58.

        Dans ce cas, il faut vérifier à chaque fois (ou un plugin dans le navigateur) pour vérifier que le javascript qui lit ma clef est toujours le même qu'un référence qui aura été approuvée par la communauté.

        Bref on a une solution inutilisable (vérification à chaque fois à la main) ou un truc à installer. Et quite à installer un truc, je préfère installer GnuPG.

        Edit : je viens de voir que ça peut servir à faire un plugin pour le navigateur. Dans ce cadre, ça peut être interessant, ce n'est pas le site qui envoi le code. Mais il faut toujours installer un truc… Bref, utiliser GnuPG sur mon client localement me parrait toujours la meilleure solution.

  • # J'en ai un peu marre de ce genre de journal

    Posté par  . Évalué à 10.

    Salut,

    Ce genre de journal me saoule un tantinet. Ce n'est que du code bashing.
    Il ne faut pas oublier que les PEP ne sont que des recommandations.

    Tu préfères un code moche en PEP8 à un code aéré et clair qui s'en approche autant que possible ?

    Et depuis quand la PEP8 interdit le:

    if condition: action

    Dans la doc de la PEP8, ça dit:

    Rather not
    (Qui se traduit par "Plutôt pas")

    Et puis ça aussi:

    While sometimes it's okay to put an if/for/while with a small body on the same line, never do this for multi-clause statements.
    (Qui se traduit par: "Quand parfois c'est ok de mettre une condition et un petit corps sur une même ligne, ne le faites jamais pour un gros bloc de conditions - Désolé, ma trad est naze, je sais)

    Faudrait relire ce lien: PEP8 et tourner 7 fois son clavier avant de s'emporter…
    Pour finir un peu plus calmement, et quitte à me faire moinsser, il ne faut pas être des nazis de la PEP8 et de la moindre déviation par rapport à des recommandations.

    L'essentiel, c'est d'avoir du code bien conçu, stable, testé et le plus aéré/commenté possible.
    Après, si tu trouves qu'ils ne vont pas assez loin dans la démarche, libre à toi de corriger et de proposer ta façon.

  • # framework web, wsgi

    Posté par  (site web personnel) . Évalué à 5.

    c'est dommage mais après un rapide survol du code, ils n'utilisent aucun framework web et ils font pas non plus une appli wsgi. Ils perdent du temps et de l'énergie sur ces points :(

  • # webmail

    Posté par  (site web personnel) . Évalué à 1.

    Perso, c'est un projet que je suis avec assez d'intérêt.

    Le seul truc que je ne suis pas sur d'avoir compris, c'est si on va devoir se créer un compte pour avoir une nouvelle adresse email en @mailpile.com où si on va pouvoir utiliser également cette webmail pour gérer ses autres comptes.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # MailPile est un projet islandais par des gens qui on l'air expérimentés.

    Posté par  . Évalué à 6.

    Je ne sais pas comment interpréter cette phrase.

    Si c'est du sarcasme, j'aimerais rappeler que Movim et Jappix, par exemple, ne sont pas développés par des anciens à 2 doigts de la retraite, et ils ne me semblent pas souffrir de tant de critique au niveau du code.

    Dans le cas présent, les développeurs ne sont pas des jeunes diplômés, mais on tire déjà à boulet rouge sur leur code.

    Franchement, je ne saurais pas dire si leur code est pourri ou excellent. Quand on lit leur profil, il n'est même pas clair si ce sont des professionnels du développement ou s'ils sont un juste un peu versés dans la chose.

  • # Et tes projets open source à toi, ils ressemblent à quoi ?

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 10 octobre 2013 à 16:34.

    Parce que je sens qu'on va rire…

  • # Le code ne fait pas le soft

    Posté par  . Évalué à 6.

    Jusqu'à preuve du contraire, ça peut être mal codé, relou à lire, avec pleins de trucs écrits en dur (ce qui est le cas là) sans pour autant être un soft avec une GUI imbitable et sans pour autant avoir des bugs. Oui, la probabilité qu'il y ait une présence de bug ou des efforts de correction décuplés, ça n'est pas pour autant que le soft est pourri et qu'il va couler (open source ou pas!).
    J'ai déjà vu nombre de logiciels libres qui sont codés avec les pieds et où pleins de sociétés se faisaient du blé dessus, et les clients réclamaient ce logiciel.

    Après, oui, avoir un soft open source codé avec les pieds ne donne vraiment pas envie aux développeurs de s'investir dedans, donc son évolution est plus difficile. Mais en soit, rien n'empêche un développeur d'y participer ou de forker.

    Par contre, je vois pas le problème avec AGPLv3? Au contraire, il faut utiliser AGPL lorsqu'il s'agit de webapps, pour la protection des droits fondamentaux (du libre) des utilisateurs!

    • [^] # Re: Le code ne fait pas le soft

      Posté par  (site web personnel) . Évalué à -2.

      Jusqu'à preuve du contraire, ça peut être mal codé, relou à lire, avec pleins de trucs écrits en dur (ce qui est le cas là) sans pour autant être un soft avec une GUI imbitable et sans pour autant avoir des bugs.

      Au début, j'ai pensé à Windows, et puis en fait non.

      Comment ça, encore deux heures avant Vendredi ? Zut alors, c'est sorti tout seul…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.