Sortie de Tapage 0.15

Posté par (page perso) . Modéré par patrick_g.
Tags :
3
17
août
2010
Internet
Tapage est un réseau social décentralisé, en français, sous licence AGPL. Il fonctionne selon un système de modules : Tapage fournit les fonctionnalités essentielles/génériques aux modules (comme l'hébergement social des données, la position des données sur la page...), et les modules fournissent les fonctionnalités. Ils sont écrits en Javascript et peuvent être ajoutés ou être retirés à la volée, pour afficher les informations désirées.

La version 0.15 est une version majeure, qui apporte une correction de nombreux bugs, la suppression de SQL (pour simplifier l’installation), de nouvelles variables pour les modules : zone_contacts qui est le champs des contacts de l’utilisateur, zone_medias qui est le champs des médias de l’utilisateur (photos, vidéos, son...).

Cette version apporte surtout la décentralisation qui n'était pas encore implantée jusque là. Le protocole utilisé est simplement basé sur HTTP pour être utilisable par PHP, et éviter de passer par des binaires qui ne peuvent pas être installés chez la plupart des hébergeurs.

Tapage n'est pas encore parfait, les défauts sont dans la suite de la dépêche. Tapage n'est toujours pas user-friand. Il reste des bugs, la CSS fait mal aux yeux, l'utilisation de GET pour éviter de se déconnecter entre deux pages n'est pas sexy et le code source n'est pas super propre.

De plus il manque plein de modules. Il y en juste quelques-uns qui font juste le strict minimum : écrire du texte, micro-blogger, changer de page sans perdre la session... Sans compter que la décentralisation n'est pas parfaite, quelques points ralentissent la propagation des données lors de la sauvegarde d'une page.

Le développeur principal de Tapage s'est donné comme objectif de corriger ces défauts pour la version 0.2, qui n'est pas pour tout de suite vu le nombre de nouveautés prévues. Sans compter que le serveur principal du projet va devoir fermer dans moins d'une semaine car personne n'a donné de l'argent au projet depuis la création.
  • # jugaison

    Posté par . Évalué à 2.

    Tapage fournit
  • # Petit détail...

    Posté par (page perso) . Évalué à 5.

    Il y a des gens qui l'utilisent ?
    • [^] # Re: Petit détail...

      Posté par (page perso) . Évalué à 9.

      J'espère que non, pour l'instant, avec tout les trous de sécurité qu'il y a, ce n'est pas à conseiller.

      Quand je parle de trou de sécurité, c'est par exemple:
      '');
      Le contenu de $info provenant d'un cookie. D'ailleurs, un cookie c'est fortement limité en taille.


      $arr[$_GET['id']]['value'] = stripcslashes($_POST['txt']);
      La programmation avec les magic quotes activées, c'est mal.

      echo '// \''.time().$_COOKIE['mail'].'\' en sha1 : zone_case.dev_id = \''.sha1(time().$_COOKIE['mail']).'\';';
      Argh!

      if($_GET['code'] != 0 AND preg_match('#^[a-z0-9._-]+@[a-z0-9._-]{2,}\.[a-z]{2,4}$#', $_GET['mail']))
      Confusion entre and et && (qui n'ont pas le même comportement). Utilisation des comparaisons non-stricte (par exemple, 'toto' == 0 est toujours vrai)
      La Regex est fausse, une ignominie. En PHP, il faut utiliser filter_var pour ce genre de chose. Cette regex refuse des adresse légitimes syntaxiquement telle que toto+tartare@example.com, sans compter les .museum, etc.

      Les commentaires en français, programmer en français, ça n'a pas d'intérêt, surtout quand on écrit un logiciel libre (il n'y a pas longtemps, j'ai eu le bonheur de tomber sur des commentaires en Kanji, haha).


      $serveur = file_get_contents('http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur');
      Ça fait mal au postérieur ça. Très mal.


      if($_GET['captcha'] !== $_SESSION['captcha'] )
      Bug de session à l'horizon.

      Et beaucoup de copier-coller, le script ajax.php long comme un bras et pas une seule fonction à l'horizon (je n'en suis même pas à me plaindre du défaut d'encapsulation, c'est dire).

      Bref, va falloir bosser pour rendre ça utilisable. Parce qu'aucune bonne pratique de base n'est appliquée. Aucune. Bref, c'est un prototype, à ne surtout pas utiliser en production.

      Au fait, les CSS, c'est mieux que le style inliné dans le HTML.

      Une bibliothèque Javascript (jQuery, prototype ou autre) est aujourd'hui indispensable pour une application d'envergure.
      Une bonne pratique pour éviter les bogues dans Javascript, c'est de déclarer correctement les variables (en utilisant le mot-clé var) ou en précisant explicitement qu'on utilises un attribut de l'objet global (window est l'objet global dans un navigateur web).

      /* Une fonction qui permet de savoir si le visiteur est sur ça page. */
      function if_admin()
      {
      if(domaine.toLowerCase() == monadresse.toLowerCase())
      {
      return true;
      }
      else
      {
      return false
      }
      }

      C'est quand même plus simple comme ça:
      /* Is the visitor admin of this page? */
      function is_admin() { return domaine.toLowerCase() == monadresse.toLowerCase() }

      À noter que l'emploi de variables globales sans documenté est très mal venu.

      Fin bref, du taf :p
      • [^] # Re: Petitdétail...

        Posté par . Évalué à 3.

        Sur leur site :

        Faire un don.
        Merci d'avance, ça devient vraiment vraiment urgent.

        J'ai tendance à me demander pourquoi ce sont toujours les mauvais projets qui réclament absolument des dons.
      • [^] # Re: Petit détail...

        Posté par (page perso) . Évalué à 1.

        « Le contenu de $info provenant d'un cookie. D'ailleurs, un cookie c'est fortement limité en taille. »
        Le cookie contient uniquement l'adresse de la page + le mot de passe. Y'a de la place dans le cookie pour ça.
        On passe toujours par la fonction getInfoPage() qui vérifie si le mot de passe est bon.
        On utilise jamais le cookie sans passer par getInfoPage().

        « $arr[$_GET['id']]['value'] = stripcslashes($_POST['txt']);
        La programmation avec les magic quotes activées, c'est mal. »

        J'utilise pas les magic quotes ! :/

        « echo '// \''.time().$_COOKIE['mail'].'\' en sha1 : zone_case.dev_id = \''.sha1(time().$_COOKIE['mail']).'\';';
        Argh! »

        ...? C'est une méthode comme une autre pour générer un ID unique, pour le développeur.
        Mais je préfère utiliser uuidgen.

        « $serveur = file_get_contents('http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur');
        Ça fait mal au postérieur ça. Très mal. »

        C'est prévu de remplacer les file_get_contents par curl.

        « if($_GET['captcha'] !== $_SESSION['captcha'] )
        Bug de session à l'horizon. »

        ...?

        « La Regex est fausse, une ignominie. »
        C'est la regex qu'il y a dans les cours des regex du SDZ.
        • [^] # Re: Petit détail...

          Posté par . Évalué à 8.

          > C'est la regex qu'il y a dans le cours des regex du SDZ.

          Je crois que tout a été dit.
          • [^] # Re: Petit détail...

            Posté par (page perso) . Évalué à -1.

            Et 2-3 regex dans le code que je n'ai pas écrites et plusieurs fonctions à la fin d'index.js. Si vous voulez taper, tapez.

            Et puis c'est indiqué dans la dépêche que le code source n'est pas propre.
        • [^] # Re: Petit détail...

          Posté par (page perso) . Évalué à 2.

          Comment tu sais qu'il y a de la place dans le cookie pour ça? Tu ne vérifie pas la taille. C'est un a priori de développeur. C'est un travers que nous partageons presque tous. Même moi j'en ai, et je m'insulte copieusement quand je m'en rend compte.

          Si tu n'utilises pas les magic-quotes, pourquoi ce stripcslashes?

          Ce n'est pas sha1 que je pointais, mais le CSRF possible avec $_COOKIE['mail'] craché directement dans la sortie standard (qui est à priori le document HTML.

          file_get_contents n'est pas le problème. Le problème est d'utiliser une information provenant directement du client Web pour acquérir une ressource, sans faire aucune vérification du contenu, ni aucune protection pour construire l'URL de la ressource.

          L'utilisateur va ouvrir plusieurs onglets, ou plusieurs fenêtre sur ton application, dans le même navigateur. Pour peut que le captcha soit requis pour plusieurs actions, le captcha sera certainement régénéré (sinon, il ne sert à rien), et donc les requêtes vont s'invalider les unes les autres.

          Le SDZ est malfamé. Il est à proscrire de ces sources d'apprentissage. La raison est que leurs « cours » sont remplis d'imprécisions, d'erreurs et d'a priori de développeurs débutants.
          • [^] # Re: Petit détail...

            Posté par (page perso) . Évalué à 0.

            « Comment tu sais qu'il y a de la place dans le cookie pour ça? Tu ne vérifie pas la taille. C'est un a priori de développeur. C'est un travers que nous partageons presque tous. Même moi j'en ai, et je m'insulte copieusement quand je m'en rend compte. »
            Ça m'étonnerait beaucoup qu'un serialise(adresse/mdp) prenne 4ko.

            « Si tu n'utilises pas les magic-quotes, pourquoi ce stripcslashes? »
            Les données sont envoyées par ajax, et je me retrouvais avec des \' de partout.

            « CSRF possible avec echo $_COOKIE['mail'] »
            On ne peut même plus rappeler à l'utilisateur ce qu'il a tapé ?

            « http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur
            Provenant directement du client Web pour acquérir une ressource, sans faire aucune vérification du contenu, ni aucune protection pour construire l'URL de la ressource. »


            Là le seul truc qui ne va pas pour moi c'est que je ne vérifie pas la réponse.
            Après, si $_GET['adresse'] contient n'importe quoi, ça retourne false et puis on en parle plus.

            « L'utilisateur va ouvrir plusieurs onglets, ou plusieurs fenêtre sur ton application, dans le même navigateur. Pour peut que le captcha soit requis pour plusieurs actions, le captcha sera certainement régénéré (sinon, il ne sert à rien), et donc les requêtes vont s'invalider les unes les autres. »
            Au pire ça demande de retaper le capchat et ça marche.

            « Le SDZ est malfamé. »
            :O
            • [^] # Re: Petit détail...

              Posté par (page perso) . Évalué à 2.

              Si tu veux courir après des bogues à la con, et qu'en plus tu aimes ça, fais-toi plaisir et ne vérifie rien. En effet :) La fonction assert est utile dans bien des cas, au moins pour ces cas qui n'arrivent jamais.

              Donc, tu programme par hasard en virant les quotes sans comprendre comment elles sont arrivées là?

              On peut rappeler à l'utilisateur ce qu'il a tapé. Mais toute insertion d'une données qui n'est pas garantie d'être formatée dans le format d'arrivée doit être formatée. Pour le HTML, en PHP, tu utilises htmlspecialchars et/ou htmlentities. C'est au choix. Normalement il faudrait aussi vérifier l'encodage associé.

              L'utilisateur peut injecter une URL via $_GET['adresse'], et détourner ton site pour détourner un autre site par exemple, pour que le courroux se déverse sur toi. J'en ai suspendu beaucoup des gugus dans ton genre quand je travaillais dans le support chez un hébergeur Internet.

              Au pire, l'utilisateur est ennuyé et ira voir ailleurs si s'est mieux. Je te conseille de lire ce ceci http://sensible.com/ qui parle très bien de l'accessibilité et de ces emmerdeurs que sont les utilisateurs.
              • [^] # Re: Petit détail...

                Posté par (page perso) . Évalué à 0.

                « Ben justement, la variable ne contient peut être pas n'importe quoi, mais une url valide, mais qui renvoi des données non légitimes, du coup tu ne peux pas faire confiance à ta variable $server. »

                Ha, ça, c'est déjà prévu pour tapage 0.2 :
                « Par exemple, dans tapage 0.15 il est possible à n'importe quel javascript de se rajouter tout seul comme contact au visiteur. »
            • [^] # Re: Petit détail...

              Posté par . Évalué à 8.

              Ça m'étonnerait beaucoup qu'un serialise(adresse/mdp) prenne 4ko.

              surement, néanmoins au fur et à mesure que ton projet avancera, tu (ou d'autres) rajouteras peut être des infos dans ce cookie. Autant faire ça proprement dès le début. C'est une bonne pratique à avoir

              Après, si $_GET['adresse'] contient n'importe quoi, ça retourne false et puis on en parle plus.

              Ben justement, la variable ne contient peut être pas n'importe quoi, mais une url valide, mais qui renvoi des données non légitimes, du coup tu ne peux pas faire confiance à ta variable $server.

              « CSRF possible avec echo $_COOKIE['mail'] »
              On ne peut même plus rappeler à l'utilisateur ce qu'il a tapé ?


              J'ai pas lu le code source, et je ne vois pas trop comment exploiter le CSRF ici, sauf utilisateur qui veut se faire du mal à lui même.
              Ceci dit il faut imaginer ce que peut faire l'utilisateur si il change lui même la valeur du cookie, soit par un autre adresse mail, soit par du code html/javascript.

              Et de manière générale mieu vaut valider toutes les données, ça évite des cas que tu ne soupçonnais pas.
      • [^] # Re: Petit détail...

        Posté par (page perso) . Évalué à 4.

        Du code désastreux… et en français, histoire d'empêcher le reste du monde de contribuer.

        Pourquoi ce genre de truc a droit à une dépêche ?

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: Petit détail...

          Posté par . Évalué à 7.

          parce que l'idée est sympathique
          parce que ça peut permettre de recruter des devs qui rendront le code lisible
          parce que si tout les trucs avec des codes crades n'avaient plus le droit de cité, on aurait 2 fois moin de dépêche.

          pour pour le coté en "en français", c'est parce qu'en France on est les meilleurs, on a donc pas besoin des incompétents des autres pays.

          (une partie de ce commentaire est ironique, à toi de découvrir laquelle)
          • [^] # Re: Petit détail...

            Posté par (page perso) . Évalué à 3.

            Sauf qu'il existe des projets du même genre bien plus crédibles, y compris une en PHP (GNU Social).

            DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: Petit détail...

              Posté par . Évalué à 7.

              ben oui, pourquoi sortir des dépêches sur gnome alors qu'il existe des projets plus crédibles genre kde, pourquoi sortir des dépêches sur emacs alors qu'il existe des projets plus crédibles comme vim, pourquoi sortir des dépêches sur dragonflyBSD alors qu'il existe des projets plus crédibles comme FreeBSD ?

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Petit détail...

          Posté par . Évalué à 2.

          Je sais pourquoi certaines gens d'ici réclament les commentaires en Anglais, mais je vois pas pourquoi l'auteur d'un projet qui a choisi de développer en faisant des commentaires en Français subirait l'obligation de rédiger ses commentaires en Anglais.

          Au pire , tu proposes des patchs de traduction des commentaires pour aider au projet, ça sera ptet plus efficace que demander à la personne qui a choisi de rendre visible son code auprès des professionnels qui sont ici et francophones, et prêt, apparemment à soutenir la lecture critique de son code, de faire quelque chose qu'il n'a pas envie.

          Et si ça se trouve, ptet que le développeur réussira ainsi à centraliser un système qui finalement s'étendra au monde entier.
          ( déjà, il peut toucher + de 280 Millions d'individus dans le monde, et s'il traduit en Espagnol, il dépassera largement le quota des gens qui parlent Anglais ).

          Sedullus dux et princeps Lemovicum occiditur

          • [^] # Re: Petit détail...

            Posté par (page perso) . Évalué à 2.

            96,7% des développeurs compétents lisent l'anglais technique sans difficulté.
            56,41% des mauvais développeurs ne lisent pas correctement l'anglais technique.

            Ces données proviennent de la fondation Carambar (http://fr.wikipedia.org/wiki/Carambar#Culture_populaire )



            Ce qui n'empêche pas d'avoir beaucoup de développeurs francophones. C'est juste que nous sommes un pouillème du cheptel. Et si le logiciel vient à être utilisé... ben les non francophones le déconseillerons fortement (pas possible de comprendre le source, c'est kif-kif du closed source).
            • [^] # Re: Petit détail...

              Posté par . Évalué à 4.

              et ? Je fais partie de ceux qui lisent l'anglais technique sans difficultés, de ceux qui lisent le handbook FreeBSD de préférence dans sa version en-US . Et c'est pas pour ça que je foutrais des commentaires sur mes codes en anglais. Par contre, je me vois mal proposer un patch sur un projet hébergé à Berkeley avec des commentaires en Français.

              Après je sais pas comment ni pourquoi ceux qui ont écrit ce projet le font , mais je les soutiens à fond dans l'usage du Français. Et je pense qu'à un certain moment, les commentaires laissant penser que l'Anglais serait la langue obligatoire pour toute personne vivant sur Terre n'est rien d'autre au pire qu'une volonté de refuser toute évolution culturelle francophone, hispanique, arabe, russe ou chinoise, au mieux qu'un snobisme. Tous deux sont profondément malsains.

              Et tous deux contribuent à se couper d'une base importante de développeurs, qui travaillant avec les outils de Microsoft, ont accès à tout ce qui leur est nécessaire dans leur langue de prédilection. ( MSDN ).

              Sur le pouième , comme je l'ai suggéré plus haut, rien n'interdit les traducteurs que le code gêne de proposer des patchs avec des commentaires en Anglais. ( Sinon, les Américains qui ont fait des études devraient pouvoir se débrouiller avec les outils de traduction et leurs amis , si vraiment ce projet a les reins pour devenir international ).

              Comment a fait de Brogglie ? Comment ont fait Marie Curie et Bohr ? Est-il plus important de "ne pas se couper de Berkeley " , ou de " ne pas se couper de Julie Martin " qui a envie d'un Facebook à la Française sans la rétention et la revente des données ?

              Sedullus dux et princeps Lemovicum occiditur

              • [^] # Re: Petitdétail...

                Posté par . Évalué à 2.

                Le langage qu'ils utilisent a un vocabulaire basé sur l'anglais, donc en mon
                sens il est normal de rester cohérent et d'avoir la totalité du code source en
                anglais (les variables/fonctions évidement, mais aussi les commentaires).

                Si le langage utilisé avait été le LSE ou le GOTO++, je n'aurais pas trouvé
                choquant que les sources soient intégralement en français.
                • [^] # Re: Petitdétail...

                  Posté par (page perso) . Évalué à 5.

                  Si on suit ton raisonnement, les commentaires des scipts perl doivent être écrits en langage des signes... ben ça va pas aider à la compréhension ça !
                • [^] # Re: Petitdétail...

                  Posté par . Évalué à 2.

                  Je suis choqué , totalement choqué, que l'on puisse confondre le nom de variables et leur contexte dans l'informatique avec la réalité vivante d'une langue: les deux n'ont strictement rien à voir.

                  Par exemple , Le sens de " if " est totalement différent en C et en Anglais.
                  Son emploi est complètement différent et les règles de grammaire n'ont strictement rien à voir.

                  Idem pour tous les mots clés.

                  Quant aux noms de fonctions, ce sont des noms de fonctions, personne n'est capable d'en connaître l'usage et ses limites sans jamais avoir lu le manpage de ces fonctions.

                  Exemple :
                  isValid() : C'est une fonction qui détermine si le client est handicapé ou s'il est valide ?

                  isTrue() : C'est une fonction qui vérifie si le client a dit la vérité ?

                  Bref, trop de raccourcis , trop d'amalgames font des mauvais programmeurs.

                  Sedullus dux et princeps Lemovicum occiditur

                  • [^] # Re:Petitdétail...

                    Posté par . Évalué à 3.

                    Bizarrement, par expérience, les mauvais programmeurs sont ceux qui ont appris
                    avec le site du zéro et qui écrivent leur code en français. Mais peut-être as-tu
                    la chance de vivre dans un monde parallèle où les meilleurs codeurs sont ceux
                    que je viens de décrire.

                    Quoi que finalement je ne t'envie pas.
                    • [^] # Re: Re:Petitdétail...

                      Posté par . Évalué à 2.

                      il dit qu'il voit pas le rapport.

                      Sedullus dux et princeps Lemovicum occiditur

                  • [^] # Re: Petitdétail...

                    Posté par (page perso) . Évalué à 0.

                    Depuis quand « valider » est un terme français ? C'est un jour uen collègue, provenant d'un enseignement littéraire, qui m'a fait remarquer le faux ami « éditer » ainsi que l'emploi impropre de « valider » en français. « valider » devrait être remplacé par exemple par « approuver ».

                    Le nom des fonctions doit permettre au client de ta fonction (ou de ta classe, objet, etc) de pouvoir l'utiliser rien qu'en lisant son nom et son prototype. Si ce n'est pas le cas, c'est qu'elle est mal-nommée, imbuée d'un piège à con idiotique ou idiosynchratique.

                    Par contre je ne comprends pas ta remarque sur le if. On en m'a jamais encore relevé à l'emploie de « if » dans une phrase.

                    if self.isStupid(): self.sparkStupidThingsTo(you)
                    if I am stupid, then I'm sparking stupid things to you.
                    • [^] # Re: Petitdétail...

                      Posté par . Évalué à 2.

                      http://littre.reverso.net/dictionnaire-francais/definition/v(...)

                      il dit qu'il faut apprendre à lire le Français, déjà.


                      Le nom des fonctions doit permettre au client de ta fonction (ou de ta classe, objet, etc) de pouvoir l'utiliser rien qu'en lisant son nom et son prototype. Si ce n'est pas le cas, c'est qu'elle est mal-nommée, imbuée d'un piège à con idiotique ou idiosynchratique.
                      et ?
                      Le fait de savoir les codes , la méthode pour lire correctement une fonction dont le nom provient de l'Anglais a-t-il réellement une relation avec l'Anglais ?

                      http://download.oracle.com/javase/1.4.2/docs/api/
                      -> java.sql
                      Interface PreparedStatement

                      public interface PreparedStatement
                      extends Statement

                      An object that represents a precompiled SQL statement.

                      A SQL statement is precompiled and stored in a PreparedStatement object. This object can then be used to efficiently execute this statement multiple times.

                      Note: The setter methods (setShort, setString, and so on) for setting IN parameter values must specify types that are compatible with the defined SQL type of the input parameter. For instance, if the IN parameter has SQL type INTEGER, then the method setInt should be used.

                      If arbitrary parameter type conversions are required, the method setObject should be used with a target SQL type.

                      In the following example of setting a parameter, con represents an active connection:
                      PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
                      SET SALARY = ? WHERE ID = ?");
                      pstmt.setBigDecimal(1, 153833.00)
                      pstmt.setInt(2, 110592)



                      bon, et maintenant, l'Anglais :

                      http://www.thefreedictionary.com/prepared

                      prepared
                      adjective
                      1. willing, minded, able, ready, inclined, disposed, in the mood, predisposed, of a mind Are you prepared to take industrial action?
                      2. ready, set, all set I was prepared for a long wait.
                      3. fit, primed, in order, arranged, in readiness, all systems go (informal) The country is fully prepared for war.


                      http://www.thefreedictionary.com/statement

                      statement
                      noun
                      1. announcement, declaration, communication, explanation, communiqué, proclamation, utterance He now disowns that statement, saying he was depressed when he made it.
                      2. account, report, testimony, evidence statements from witnesses to the event


                      L'anglais est bien plus complexe que le simple nommage d'une fonction.
                      Pareil pour " if" . Tu peux toujours chercher des cas dans lesquels le sens de " if " en Anglais ressemble à la simple condition de boucle de beaucoup de langages ( traduisant en fait une série d'instructions à passer au processeur ) , mais une simple visite à la page http://www.thefreedictionary.com/if te montrera que tu as tout à fait tord de chercher le moindre point commun .

                      Enfin, l'illustration de tes deux dernières lignes montre qu'il y a au niveau de la phraséologie une construction totalement différente entre le langage utilisé et l'Anglais.

                      Sedullus dux et princeps Lemovicum occiditur

                      • [^] # Décalage

                        Posté par (page perso) . Évalué à 1.

                        L'usage de « Valider » n'était pas d'un emploi courant avant son usage massif en informatique. C'est d'ailleurs un problème quand j'essaye d'expliquer à des vieux qu'il faut valider un formulaire. Parce que pour eux, valider un formulaire, ce n'est pas le soumettre pour vérification, mais plutôt vérifier que le formulaire fait correctement son travail. Oui, même au sein d'une même langue, il y a des décalages sémantiques selon les générations et les régions. C'est pourquoi je considère depuis de nombreuses années l'emploi de dictionnaires pour imposer sa vision comme étant issu du syndrome parisianiste: il n'y aurait que le français de Paris qui aurait le droit d'exister, et leurs cerbères sont le petit robert et la rousse.

                        Je ne vois pas le conflit entre l'usage de prepared dans le concept des requêtes préparées.

                        Quand au conditionnel en anglais, effectivement, je ne le maîtrise pas. Je parle ce Globish que j'ai appris dans les documentations informatiques.
                        • [^] # Re: Décalage

                          Posté par . Évalué à 2.

                          Nan pour " isValid" , tu es à côté de mon commentaire.

                          Je ne vois pas le conflit entre l'usage de prepared dans le concept des requêtes préparées.

                          Heureusement que les personnes qui ont inventé cette fonction ne l'ont pas nommée par antinomie .

                          Sedullus dux et princeps Lemovicum occiditur

                        • [^] # Re: Décalage

                          Posté par . Évalué à 4.

                          > L'usage de « Valider » n'était pas d'un emploi courant avant son usage massif en informatique.

                          foutaises. c'est courant à l'armée ou dans n'importe quelle bureaucratie et autres enfers à procédures
      • [^] # Re: Petit détail...

        Posté par (page perso) . Évalué à 3.

        Les commentaires en français, programmer en français, ça n'a pas d'intérêt, surtout quand on écrit un logiciel libre (il n'y a pas longtemps, j'ai eu le bonheur de tomber sur des commentaires en Kanji, haha).

        Il faut voir aussi qu'il y a des gens qui ne parlent tout simplement pas (ou mal) anglais.
        Et oui c'est un énorme handicape en informatique.
        • [^] # Re: Petit détail...

          Posté par (page perso) . Évalué à -1.

          J'en suis bien conscient puisque j'ai appris l'anglais grâce à Linux. Ce qui fait que je l'écris mal, comprends mal, etc. Mais il semblerait que mes collègues ne s'en plaignent pas trop.
          • [^] # Re: Petit détail...

            Posté par . Évalué à 7.

            Très honnêtement je préfère un commentaire écrit en bon français (entre autres sans risques d'emploi de faux-amis...) plutôt qu'un mauvais anglais.

            Une connaissance qui bossait avec une boite japonaise me disait qu'au final il préférait quand ils commentaient en jap, parce qu'en anglais leurs commentaires ne voulaient juste rien dire (et oui, le pote en question parlait suffisamment bien japonais pour dire ce genre de choses).

            J'ai une règle simple : il faut que le code en lui-même (variables comprises) soit écrit en anglais pour une raison tout bête : les langages info sont écrits en "anglais", et faire un mélange des genres est à mon sens une mauvaise idée. Par contre, les commentaires doivent avant tout être compréhensibles pour les développeurs actifs. Si ceux-ci sont majoritairement francophones, pourquoi ne pas écrire en Français ?
            • [^] # Re: Petit détail...

              Posté par (page perso) . Évalué à 2.

              Je préfère un Globish à un bon français. De toute façon, les développeurs qui écrivent correctement en français ne courent malheureusement pas les rues. donc tant qu'à choisir, autant avoir des commentaires concis et internationaux, plutôt que des commentaires en français.

              Le français n'est pas une bonne idée pour commenter du code écrit en anglais, pour plusieurs raisons. La première, c'est que les structures de langage sont en anglais (hors horreurs verbeuses comme le W-Langage). La deuxième, c'est que le français prend plus de place pour exprimer la même chose, en moins précis (c'est statistique). La troisième, c'est qu'il est horrible et pénible de lire : FILE * fic = open("", "rb") ; Ceci en raison de la nécessité de changer d'aire cérébrale. Nous n'utilisons pas la même aire pour parler anglais ou français, et encore moins pour parser du code. Changer de contexte est couteux en ressource, je préfère donc un code qui me permet de n'utiliser que deux contexte pour ma réflexion plutôt que trois pour cette activité déjà suffisamment complexe. Déjà que j'ai l'aire « râleur » qui s'inflamme dès que je lis le code d'un autre, ou un code que j'ai oublié qu'il était de moi.
      • [^] # Re: Petit détail...

        Posté par (page perso) . Évalué à 3.

        A propos de magic_quotes : si on code pour que l'appli soit hébergée sur des plate-formes qu'on ne maîtrise pas, vaux mieux s'assurer que si magic_quotes est activé, ça va pas péter son appli genre avec http://svn.kd2.org/svn/misc/libs/tools/disable_magic_quotes_(...) par exemple.

        Ne jamais développer avec magic_quotes ou register_globals activé, on est au 21ème siècle quand même.

        file_get_contents c'est bien, curl n'est que rarement nécessaire. Par contre comme déjà dis, le _GET['adresse'] en dur c'est mal. Utilise filter_var stp ou parse_url à la limite. Je conseillerais également de rajouter un contexte (cf. la doc de file_get_contents et de stream_context_create) pour ajouter un timeout, genre :

        $context = stream_context_create(array('http' => array('timeout' => 5)));

        (de mémoire, vérifie dans le manuel)

        Car si le site en face est down, ton script risque de timeout avec le site que tu requête, sans compter qu'attendre plus de 5 secondes une requête c'est bien trop, y'a un souci.

        Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?! WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en POST. JAMAIS.

        Enfin $array[$_GET['id']] c'est mal aussi, vaux mieux vérifier avant que 1. _GET['id'] existe et est un numérique 2. il ait le droit de taper cet ID-ci. ensuite et ça mange pas de pain, caster la variable en int :

        $array[(int)$_GET['id']] = 'bla bla';

        De manière générale :
        - toutes les variables venant de _GET, _POST, _COOKIE, _REQUEST et même _SERVER doivent être vérifiées, puis castées ou escapées.
        - bien avoir conscience de la portée des variables, si tu utilise une variable $id à un endroit, se poser la question d'où vient-elle, es-tu sûr que c'est toi qui l'a forgée et pas par exemple un paramètre de la query string ? (particulièrement important pour les applications installées n'importe où, là ou on ne peux pas être sûr que register_globals est désactivé)

        Bref il y a du boulot.

        Mais l'idée de fond est intéressante, bon courage, ne pas se décourager avec nos commentaires techniques, ils ne sont là que pour t'aider à t'améliorer. La sécurité est importante, et c'est vrai que quand on débute on n'y pense pas vraiment (j'en suis le premier exemple), mais il faut la prendre en compte.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Petit détail...

          Posté par (page perso) . Évalué à 2.

          Dans l'absolu, quand on débute on fait toujours de la merde. Parce que malheureusement, notre métier s'apprend en forgeant.
        • [^] # Re: Petit détail...

          Posté par (page perso) . Évalué à 0.

          Le problème du timeout était déjà noté, mais merci quand même de l'avoir dit :].

          « file_get_contents c'est bien, curl n'est que rarement nécessaire »
          Je vais remplacer file_get_contents par curl juste pour de la performance :

          Lorsque l'on sauvegarde une page, il faut que toutes les requêtes partent en même temps au lieu de partir l'une après l'autre.

          « Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?! WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en POST. JAMAIS. »

          Bah heu... Tout le monde fait ça, non ...?
          Et puis, je vais pas demander au client de retaper le MDP chaque session ?

          « Enfin $array[$_GET['id']] c'est mal aussi, vaux mieux vérifier avant que 1. _GET['id'] existe et est un numérique 2. il ait le droit de taper cet ID-ci. ensuite et ça mange pas de pain, caster la variable en int : »
          Non, il a le droit de mettre n'importe quoi ici. Normalement les ID que tapage fournis sont genre « bloc_(INT) ». Mais ça peut être n'importe quoi ça marche.

          « bien avoir conscience de la portée des variables »
          Oui oui, ajax.php c'est juste plein de conditions l'une à la suite des autres. Donc on commence chaque condition sans aucune variable ( sauf ceux qui sont tapé dans config.php mais c'est tout).
          • [^] # Re: Petitdétail...

            Posté par . Évalué à 6.

            > **« Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?!
            > WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en
            > POST. JAMAIS. »**
            >
            >
            > Bah heu... Tout le monde fait ça, non ...?
            >
            > Et puis, je vais pas demander au client de retaper le MDP chaque session ?

            À mon avis, tu devrais apprendre un peu la programmation web, les choses simples
            comme les cookies de session, avant de lancer de gros projets qui ont pour but
            d'être sérieux, parce que là votre niveau d'incompétence m'inquiète.
          • [^] # Re: Petit détail...

            Posté par . Évalué à 3.

            « Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?! WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en POST. JAMAIS. »

            Bah heu... Tout le monde fait ça, non ...?
            Et puis, je vais pas demander au client de retaper le MDP chaque session ?


            Je t'invite à regarder les cookies utilisés par linuxfr.
            Généralement, après authentification, tu inscris dans le cookie une valeur aléatoire connue du serveur et du navigateur.
            Tant que le cookie est valide, l'utilisateur reste authentifié, si le cookie expire, que tu vires cette valeur de ta base de donnée, ou que le cookie expire, l'utilisateur n'est plus authentifié. Tu peux également vérifier le couple id de session/ip, ca n'est pas magique, mais ça rend le vol de cookie un tout petit peu moin efficace.

            Je ne maitrise pas php, mais il me semble que c'est ainsi que sont gérés les sessions (variable $SESSION ou un truc comme ça, mais là je dis ptet une connerie).
            • [^] # Re: Petit détail...

              Posté par (page perso) . Évalué à 1.

              « Généralement, après authentification, tu inscris dans le cookie une valeur aléatoire connue du serveur et du navigateur.
              Tant que le cookie est valide, l'utilisateur reste authentifié. »

              Haaa, je ne connaissais pas du tout.
              Je note pour la prochaine version. :]
              • [^] # Re: Petit détail...

                Posté par . Évalué à 6.

                Haaa, je ne connaissais pas du tout.

                Désolé si ça te paraît hautain, décourageant et/ou condescendant, mais c'est un peu flippant pour la suite. Ce à quoi tu t'attaques - réseau social décentralisé - n'est pas un problème tout à fait trivial. Ton idée de départ, sur le papier, n'est pas mauvaise (en tous cas j'avais caressé quelque-chose de similaire il y a un temps, et je ne suis pas le seul). Par contre, tu sembles vouloir à tout prix réinventer la roue, plutôt que de t'appuyer sur des protocoles existants (XMPP & co). Cela peut se justifier par ta volonté initiale de faire un truc hébergeable "sur le premier site free.fr qui traine", mais c'est une contrainte forte.

                Et malgré cela, tu sembles débarquer complètement dans la monde du développement web - voire du développement tout court - et l'idée qu'un mot de passe puisse circuler en clair dans chaque requête faite au serveur ne t'a pas ému plus que cela.

                Pardon d'être aussi direct, mais je penses que tu gagnerais - sans parler du reste du monde - à suivre de près un projet existant (tu as le choix) pour :
                * t'habituer à lire du vrai code déjà écrit avec de bonnes bases
                * te faire la main sur des petites contributions cosmétiques/mineures
                * te faire une réputation dans leur communauté pour proposer ensuite des idées/directions plus audacieuses - ce qui semble être ton point fort.

                C'est très courageux de se lancer dans l'implémentation de ses idées, mais ce n'est pas une raison pour faire l'impasse sur les fondamentaux. À plus forte raison quand ton implémentation a vocation à être utilisée par beaucoup de gens : les faiblesses inhérentes à ta réalisation risquent d'être d'autant plus pénalisantes.
          • [^] # Re: Petit détail...

            Posté par (page perso) . Évalué à 3.

            Concernant curl : je n'ai pas connaissance du fait que curl dans PHP serait asynchrone... Donc le comportement est le même, sauf à utiliser multiget peut-être ?

            Pour le coup du cookie... Je t'invite à lire une doc sur les sessions PHP... Un petit exemple de login :

            session_start();

            if (sha1($_POST['password'] . 'secret') == $user['password'])
            {
            $_SESSION['logged'] = true;
            }

            if (!empty($_SESSION['logged']))
            echo "Je suis connecté";

            Note que ici le mot de passe est stocké hashé avec un salt général, ce que tu devrais toujours faire (ne jamais stocker de mot de passe en clair, autre base de la sécurité).

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Petit détail...

        Posté par (page perso) . Évalué à 2.

        À propos de la Regex pour l'adresse e-mail, en voici une qui devrait être complète (attention les yeux pour ceux qui n'ont pas l'habitude) http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
  • # version 0.15 ou 0.1.5 ?

    Posté par (page perso) . Évalué à 3.

    Sortie de Tapage 0.15

    Le développeur principal de tapage s'est donné comme objectif de corriger ces défauts pour la version 0.2

    Il n'y a pas comme un problème de numéro de version ?
  • # C'est un concurrent de Diaspora ?

    Posté par (page perso) . Évalué à 3.

    Pourquoi ne pas tenter de bosser avec diaspora ?

    http://joindiaspora.com

    Mais bon, facebook est loin d'être mort .... et "google me" arrive a grands pas ...

    L'avenir est le social, ça c'est clair.
  • # Ta page où est /b/

    Posté par (page perso) . Évalué à 3.

    >> Tapage n'est toujours pas user-friand.

    Euh… C'est une tentative d'écrire « user-friendly, » ça ?
    Car « friand » en anglais, c'est « qui aime énormément, » comme en français d'ailleurs. Là, je lis que le projet n'aime pas les utilisateurs…


    >> le CSS fait mal aux yeux

    Il me semble que « le CSS, » c'est bizarre. On dit « la CSS » pour parler du visuel. Éventuellement, « le code (de la) CSS, » non ?


    >> Le développeur principal de tapage s'est donné

    Pour être cohérent avec le reste de la dépêche, il faudrait écrire « Tapage. » Ou mieux, mettre le nom du projet en italique.
    • [^] # Re: Ta pageoùest /b/

      Posté par . Évalué à 2.

      À la vue de toutes les critiques qu'ils se sont pris les pauvres dans les autres commentaires, le tien fait très pinaillerie.
      • [^] # Re: Ta pageoùest /b/

        Posté par (page perso) . Évalué à 2.

        Mon commentaire concerne la qualite' de la depeche, pas celle du projet, et c'est malheureusement pas en me moinssant que ca va permettre de prendre en compte ces remarques.

Suivre le flux des commentaires

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