Première beta de POCHE 1.0 disponible

Posté par  (site web personnel) . Édité par NeoX, ZeroHeure, Florent Zara, Nils Ratusznik, tuiu pol et palm123. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
33
8
août
2013
PHP

POCHE est une application web pour gérer une liste de lectures à lire plus tard. Grâce à un bookmarklet, vous sauvegardez facilement un lien dans votre POCHE. POCHE sauvegarde le contenu entier d’un lien : les textes et les photos sont enregistrés sur votre serveur (mais pas la pub!). Ensuite vous pouvez lire une page dans une vue confortable.

Logo Poche

C'est une alternative open source à Pocket / Readability / Instapaper. Vos données vous appartiennent et ne dépendent pas d'une société. Pour éviter ce qui nous est arrivé avec Google Reader, prenez les devants avec Pocket & co.

Voici les principales modifications de la version 1.0 :

  • possibilité de traduire POCHE (à venir : français, allemand, espagnol et chinois) ;
  • remplacement de RainTPL par Twig ;
  • stockage possible : SQLite, MySQL et PostgreSQL ;
  • énorme refactoring ;
  • à la suppression d’un lien, plus de confirmation ;
  • import depuis pocket / readability / instapaper depuis l’écran de configuration ;
  • notification de mise à jour disponible depuis l’écran de configuration ;
  • plus du tout de javascript ;
  • possibilité de créer des thèmes ;
  • pagination à l’affichage des liens ;
  • partage par email et sur twitter ;
  • nouveau design, plus adapté aux tablettes / smartphones (on rencontrait des problèmes avec l’ancienne interface) ;
  • multi-utilisateurs (techniquement, c’est pensé pour, une interface d’admin viendra) ;
  • extension pour Chrome disponible ici ;

Pour télécharger / installer, la lecture du billet sur le site de POCHE est vivement conseillée.

Aller plus loin

  • # Couleurs favorites des dévs : #000000 et #FFFFFF

    Posté par  . Évalué à 3. Dernière modification le 08 août 2013 à 16:50.

    Le site web est joli, très coloré. Quel dommage que l'application soit en noir et blanc.

    Envisagez-vous :

    • un système de catégories/tags ? Une fois que j'aurai des centaines d'articles il va falloir les organiser.
    • l'intégration d'un moteur de recherche ? (Je sais c'est gros un moteur de recherche et c'est pas votre projet, mais en termes de fonctionnalités j'ai déjà ça sur mon ordinateur de bureau pour les articles que je garde avec l'extension Scrapbook de Firefox : 1) le moteur intégré à Scrapbook et 2) recoll, interface Qt / moteur xapian. Si je veux pouvoir passer au nuage, il faut que ce soit à équivalence de fonctionnalités.)
    • un système pour exporter mes données (lisible par l'humain et/ou de façon utilisable par d'autres applications) ?

    La dépêche dit que le texte et les images sont téléchargées sur mon serveur. Pourtant quand je lis une nouvelle sur le site de démonstration (par exemple Attaqué par un requin, il réplique au taser, login poche/poche), l'image (le maitre-nageur) provient d'un autre domaine. Pouvez-vous expliquer ?

    Merci pour la dépêche et pour l'application, ce sera très utile. J'hésite un peu à installer. Je ne veux pas dépendre d'entreprises extérieures et je suis content que POCHE me permette d'éviter cela, mais mes compétences en bases de données sont limitées et j'ai peur qu'une upgrade future se passe mal. Qu'avez-vous prévu pour garantir la pérennité des données au cours des migrations ?

    • [^] # Re: Couleurs favorites des dévs : #000000 et #FFFFFF

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

      Quel dommage que l'application soit en noir et blanc.

      En effet, c'est très sobre. Priorité au contenu, c'est fait pour lire, on n'est pas dérangé par le reste. Mais il y a la possibilité de créer des thèmes (avec plein d'autres couleurs donc).
      Et je recherche toujours un infographiste qui pourrait nous dépanner.

      • un système de catégories/tags ? Une fois que j'aurai des centaines d'articles il va falloir les organiser.
      • l'intégration d'un moteur de recherche ? (Je sais c'est gros un moteur de recherche et c'est pas votre projet, mais en termes de fonctionnalités j'ai déjà ça sur mon ordinateur de bureau pour les articles que je garde avec l'extension Scrapbook de Firefox : 1) le moteur intégré à Scrapbook et 2) recoll, interface Qt / moteur xapian. Si je veux pouvoir passer au nuage, il faut que ce soit à équivalence de fonctionnalités.)
      • un système pour exporter mes données (lisible par l'humain et/ou de façon utilisable par d'autres applications) ?

      ces 3 fonctionnalités sont prévues, elles sont déjà dans les tickets sur github.

      pour les images, la configuration le permet. Pour ne pas surcharger la démo, c'est désactivé, mais ça se remet facilement (par contre, il y a encore quelques soucis de ce côté-là).

      Concernant les mises à jour, c'est prévu : déjà là, il y a un script qui s'occupe de mettre à jour de la 0.3 à la 1.0.

  • # Liens avec Shaarli ...

    Posté par  . Évalué à 4.

    Bonjour,

    Utilisateur de Sharlii, je me pose la question d'un pont entre les deux.
    Une fois que j'ai lu, par exemple, j'aimerais bien pouvoir sauver cela rapidement dans Sharlii si le lien valait le coup.
    D'autre part, ce serait pas mal de pouvoir tagger les liens.

    Merci.

    • [^] # Re: Liens avec Shaarli ...

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

      bonjour !
      Comme je le dis au-dessus, les tags sont prévus (cf ticket sur github).

      Pour le pont avec shaarli, je vais le rajouter dans la todo list, bonne idée.

    • [^] # Re: Liens avec Shaarli ...

      Posté par  . Évalué à 2.

      Une fois que j'ai lu, par exemple, j'aimerais bien pouvoir sauver cela rapidement dans Sharlii si le lien valait le coup.

      Je ne comprends pas bien l'intérêt. shaarli et poche ont le même but : stocker des liens. Je vois pas bien l'intérêt d'en garder un sur les deux ou alors c'est le fait de stocker sur ton serveur les info qui t'intéresse et alors c'est plutôt l'inverse qu'il faudrait, mais je ne vois pas l'intérêt de passer par shaarli du coup.

      Bref pour moi, il me semble que c'est plutôt 2 concurrents qui ont leurs avantages et leurs inconvénients. Si un rapprochement se fait je pense que c'est plus pour l'intéropérabilité.

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

      • [^] # Re: Liens avec Shaarli ...

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

        Bonjour Michel,

        Je ne vois pas poche comme un concurrent de shaarli.
        As-tu testé poche ? Le but ici est de conserver pour lire plus tard. C'est fermé pour chaque utilisateur.

        Shaarli, c'est pour partager, rien que là c'est une grosse différence.

        Ensuite; le contenu : poche récupère le contenu de l'article.
        Shaarli fait un lien vers l'article.

        poche = pocket
        shaarli = delicious

        • [^] # Re: Liens avec Shaarli ...

          Posté par  . Évalué à 2.

          As-tu testé poche ? Le but ici est de conserver pour lire plus tard. C'est fermé pour chaque utilisateur.

          Oui et c'est comme ça que je me sert de Shaarli.

          Shaarli, c'est pour partager, rien que là c'est une grosse différence.

          J'ai vu dans le bug tracker sur github que c'était en discussion.

          Ensuite; le contenu : poche récupère le contenu de l'article.
          Shaarli fait un lien vers l'article.

          Ce n'est pas parce qu'ils n'ont pas exactement les même fonctionnalités qu'ils ne sont pas concurrents ;)

          poche = pocket
          shaarli = delicious

          Je comprends. Ça se tiens.

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

  • # Fête du slip

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

    Bon, comme d'habitude, je suis allé regarder le code source. Et je n'ai pas été déçu. je ne vais m'étendre sur l'usage du français et des caractères UTF-8, l'ami Nicolas semble joueur.

    Utilisation de données externes sans contrôle :

    <?php  return $protocol . "://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

    curl_init n'échoue jamais, pas plus que ces petis copains il faut croire ;)

    <?php
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);

    inc/functions.php:60

    <?php
$httpcodeOK = isset($httpcode) and ($httpcode == 200 or $httpcode == 301);

    Quelque soit la valeur numérique de $httpcode, $httpcodeOK sera vrai. La raison en est la précédence des opérateurs (l'affectation est prioritaire sur les opérateurs 'and' et 'or').
    'and' n'est pas l'équivalent de '&&'.

    J'aime beaucoup le salt public dans inc/config.php

    La classe Store devrait être une interface.

    Je ne comprend pas pourquoi le constructeur du parent (vide en plus) est appelé dans certaines méthodes de la classe SQLite.

    Plus généralement, tu indique dans la documentation :

    You have to protect your db/poche.sqlite file. Modify the virtual host of your website to add this condition

    Déjà, tu considère que tout le monde utilise Apache ou Nginx, ce qui est une erreur. Ensuite, tu t'appuye sur un cache-misère pour éviter un accès direct au fichier de base de données. Une bonne pratique est de fournir un répertoire public, qui est exporté par le serveur web, plutôt que d'exporter tout le répertoire applicatif.

    La regex sur les email est fausse :'( Une bonne pratique est d'utiliser filter_var plutôt que de faire le malin avec une regex pourrie.

    functions.php pourrait avoir un nom un peu plus parlant.

    Allé, j't'ai fait un p'tit Pull Request.

    • [^] # Re: Fête du slip

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

      Bonsoir LupusMic !

      Merci pour ton message et ton pull request.

      Comme je te l'ai dit sur github, tu as regardé le code de la branche master.
      Merci de prendre en compte la branche de dev ;-)

      Oui il y a du mauvais code dedans. Et même s'il n'est pas entièrement de moi, j'en ai la responsabilité.
      C'est pourquoi nous ne sommes encore qu'en beta et que toute aide, comme la tienne avec ta pull request, est la bienvenue.

      Je suis au début partie d'un script pas propre, j'essaie de tout refaire au mieux. Il faut juste me laisser le temps.

      À bientôt !

      • [^] # Framework web

        Posté par  . Évalué à -1.

        On lit des tas de trucs méchants concernant PHP (Why PHP sucks et suivre les liens du paragraphe Other Anti-PHP Sites). Vu la taille de la base de code disponible, on peut comprendre que dans de nombreux cas où on étend un programme existant, il n'y ait pas le choix. Mais pour un code entièrement nouveau, il y avait de nombreux frameworks possibles. Par exemple très récemment, on découvrait sur linuxfr cozycloud, tout jeune logiciel web en python, concurrent d'un plus ancien logiciel en PHP (owncloud). D'où ma question : qu'est-ce qui a motivé le choix du langage dans le cas de poche ?

        • [^] # Re: Framework web

          Posté par  . Évalué à 9.

          Je ne sais pas pour Poche, mais PHP garde un atout majeur comparé à la plupart (totalité?) des autres solutions : il se déploie sans effort sur 99% des offres d'hébergements, même les moins onéreux.

          • [^] # Re: Framework web

            Posté par  . Évalué à 2.

            Un peu comme le flash quoi.

            Ca c'est un argument qui fera changer le choses

        • [^] # Re: Framework web

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

          Avant d'utiliser un Framework, il faut déjà maîtriser PHP.
          Utiliser un Framework, c'est choisir une architecture, se limiter à un sous-ensemble de PHP.

          Personnellement, aucun framework PHP ne me plait. Python n'est pas objet (pas de modificateurs de visibilité, donc pas d'encapsulation, donc pas objet), et surtout avant de pouvoir déployer du Python, il faut réfléchir plus que pour du PHP.

          Si PHP continue à avoir tant de succès, c'est parce que n'importe quel demeuré peut immédiatement publier son script troué sans effort. Ce qui rend donc la technologie moins cher, puisqu'on peut embaucher des imbéciles qui feront des scripts pas plus pourris que les autres.

          :)

          • [^] # Re: Framework web

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

            Si PHP continue à avoir tant de succès, c'est parce que n'importe quel demeuré peut immédiatement publier son script troué sans effort.

            Allez, on va dire que j'ai appris à te connaitre depuis hier :-) donc je ne le prends pas pour moi.

          • [^] # Re: Framework web

            Posté par  . Évalué à 4.

            on peut embaucher des imbéciles qui feront des scripts pas plus pourris que les autres.

            L'argument est valable pour un environnement d'entreprise, mais pour un projet de passionné comme Poche, il était libre de son choix. Je retiens l'argument du déploiement pour Poche, qui doit être installable par un particulier louant un serveur mutualisé ou virtuel aux caractéristiques limitées.

            • [^] # Re: Framework web

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

              C'est pourtant assez lié, on a tendance à developper les compétences qu'on espère utiles au travail, pour faire la différence ou avoir un travail pour manger.

              Par contre, pour l'hébergement virtuel, l'argument ne vaut pas. Tu installe ce que tu veux sur un virtuel puisque c'est une machine complète. Et Python (ou Ruby, ou autre Perl) ne mange pas plus de ressources qu'un déploiement PHP, et mod_wsgi est assez équivalent à un déploiement PHP.

              • [^] # Re: Framework web

                Posté par  . Évalué à 3. Dernière modification le 09 août 2013 à 13:25.

                Et Python (ou Ruby, ou autre Perl) ne mange pas plus de ressources qu'un déploiement PHP

                Je compare cozycloud (python) à owncloud (php), deux logiciels ayant le même niveau de fonction :

                • commentaires de la dépêche cozycloud : ça ne s'installe pas avec 256 Mo, les fonctionnalités sont limitées avec 512 Mo, l'auteur utilise 1024 Mo pour avoir toutes les extensions.
                • commentaire du journal owncloud : apparemment ça marche dès 256 Mo.

                Ça pourrait être que cozycloud est mal codé et bouffe trop de mémoire pour rien, mais en l'occurrence aucun commentaire ne critique la qualité du code, alors que les problèmes liés au déploiement sont critiqués : nécessité de compiler un module avec gcc ; nombre d'appliquettes affichées sur la page d'accueil.

                • [^] # Re: Framework web

                  Posté par  . Évalué à 5.

                  Cozycloud c'est du node.js, le python c'est juste le script d'installation.

                  Depending on the time of day, the French go either way.

                  • [^] # Re: Framework web

                    Posté par  . Évalué à 2.

                    ok merci j'avais mal interprété.

          • [^] # Re: Framework web

            Posté par  . Évalué à 3.

            Python n'est pas objet (pas de modificateurs de visibilité, donc pas d'encapsulation, donc pas objet)

            C'est pas parce qu'il n'y a pas de modificateurs de visibilité que ce n'est pas objet, on met un _ devant les trucs privés et l'utilisateur de la classe sait que ça ne doit pas être utilisé de l'extérieur. Cf. la devise de Python.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Framework web

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

              L'encapsulation des données est un principe fondamental de la programmation orientée objet, et que je considère comme central. Python ne propose pas de tels mécanismes, mais propose uniquement d'adopter une convention qui sera violée comme toutes les conventions. Ce n'est pas une encapsulation propre.

              La programmation objet à pour but d'encapsuler des mécanismes et d'en exposer une interface simple d'utilisation. S'il est possible facilement de venir foutre le bordel, il n'y a plus d'intérêt à faire de l'objet.

              Quand à la devise de Python, elle est tellement ridicule que je ne comprends toujours pas comment des gens peuvent continuer à la défendre. Surtout dans un langage où l'implicite est malgré tout très présent.

              • [^] # Re: Framework web

                Posté par  . Évalué à 1.

                L'encapsulation des données est un principe fondamental de la programmation orientée objet, et que je considère comme central. Python ne propose pas de tels mécanismes, mais propose uniquement d'adopter une convention qui sera violée comme toutes les conventions. Ce n'est pas une encapsulation propre.

                La programmation objet à pour but d'encapsuler des mécanismes et d'en exposer une interface simple d'utilisation. S'il est possible facilement de venir foutre le bordel, il n'y a plus d'intérêt à faire de l'objet.

                Les conventions disent d'indenter proprement, de mettre les noms de constantes en capitales, et de ne pas utiliser des variables membres préfixées de _ en dehors de la classe (en plus c'est pratique de le savoir au sein de la classe en un coup d'œil).

                C'est pas dur. Mauvais dèv, changer de dèv.

                Quand à la devise de Python, elle est tellement ridicule que je ne comprends toujours pas comment des gens peuvent continuer à la défendre.

                Je t'écoute.

                Surtout dans un langage où l'implicite est malgré tout très présent.

                Exemple?

                (je m'y connais pas spécialement en Python)

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Framework web

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

                  Les conventions disent d'indenter proprement

                  Ce n'est pas une convention. Un programme Python est naturellement indenté, car l'indentation est utilisée pour distinguer les blocs de code, là où le C (et inspirés) utilise des accolades.

                  de mettre les noms de constantes en capitales

                  Ce qui est un aberration. Il ne peut pas y avoir de constante en Python, donc aucune variable ne peut voir son nom être capitalisée… à moins d'utiliser un décorateur, j'avoue.
                  Ceci dit, j'ai arrêté de capitaliser les constantes :

                  • en PHP, il ne peut y avoir de collision variable/constante, donc l'absence de $ ou de () suffit à distinguer une constante des autres symboles.
                  • en C/C++, les macros devraient être en captales. Si en C les constantes sont par incidence des macros (#define), ce n'est pas la culture en C++ (où on utilisera const sur des données statiques membres ou des variables globales). Je sais, un vilain peut toujours faire un const_cast, mais il faut le taper, et ça se voit (et je ne crois pas qu'un const_cast sur une globale constante soit un comportement définit).
                  • en Python, parce que finalement, il y a toujours un couillon pour venir affecter une nouvelle valeur à ta constante. Je préfère encapsuler et fournir des copies de la valeur, histoire d'être certain que personne ne vienne y foutre le bordel.
                  • en JavaScript, comment dire, c'est, hmmm

                  • en SQL, j'ai même arrêter d'écrire les clauses en majuscules. Un jour, j'essaierai de comprendre pourquoi tout le monde écrit ses requêtes en majuscules.

                    C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps.

                  Je t'écoute.

                  Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.

                  Pourtant, il y a des choses implicites. Par exemple, les invariables sont copiés quand passés en argument, ou encore assigné à une variable. Le ducktyping : il n'y a pas plus implicite que le ducktyping, puisque tu suppose que l'objet qui t'es donné réagi comme tu t'y attends. L'absence totale de typehinting : ce qui est explicite, c'est de dire quel type/interface tu attends en argument, pas de le dire vaguement dans le doc ou laisser le plaisir de la lecture de la fonction.

                  et de ne pas utiliser des variables membres préfixées de _ en dehors de la classe (en plus c'est pratique de le savoir au sein de la classe en un coup d'œil).

                  Et pourquoi ne pas utiliser l'hungarian notation tant qu'on y est ? J'utilise _ pour préfixer, j'ai même essayer _classname_varname pour améliorer ça, mais ça reste encore de la convention, on peut saloper depuis l'extérieur de la fonction.

                  C'est pas dur. Mauvais dèv, changer de dèv.

                  Entendons-nous bien, je considère qu'un langage de programmation est un outil pour exprimer des idées, des concepts. S'il faut passer des heures pour une erreur de typo (oh, mais c'est length, pas lenght) parce que le langage est laxiste, je dis non. je veux que mon programme échoue le plus tôt possible, pour que je puisse corriger les problèmes, je ne veux pas que le programme tombe en marche et erre dans un état indéterminé.

                  On peut ensuite s'amuser à contrôler chaque argument de chaque fonction, qu'il expose la bonne interface, que l'attribut machin expose la bonne interface, etc. Mais franchement, pourquoi est-ce que c'est à moi de contrôler ça manuellement en 3 lignes de code alors que le langage peut être utilisé à cette fin ?

                  • [^] # Re: Framework web

                    Posté par  . Évalué à 1.

                    Les conventions disent d'indenter proprement

                    Ce n'est pas une convention. Un programme Python est naturellement indenté, car l'indentation est utilisée pour distinguer les blocs de code, là où le C (et inspirés) utilise des accolades.

                    En fait là je parlais en général. Et puis tu peux utiliser les accolades en Python! :p

                    de mettre les noms de constantes en capitales

                    Ce qui est un aberration. Il ne peut pas y avoir de constante en Python, donc aucune variable ne peut voir son nom être capitalisée… à moins d'utiliser un décorateur, j'avoue.
                    Ceci dit, j'ai arrêté de capitaliser les constantes :

                    • en PHP, il ne peut y avoir de collision variable/constante, donc l'absence de $ ou de () suffit à distinguer une constante des autres symboles.

                    Lapin compris (j'ai fait très très peu de PHP).

                    • en C/C++, les macros devraient être en captales. Si en C les constantes sont par incidence des macros (#define), ce n'est pas la culture en C++ (où on utilisera const sur des données statiques membres ou des variables globales). Je sais, un vilain peut toujours faire un const_cast, mais il faut le taper, et ça se voit (et je ne crois pas qu'un const_cast sur une globale constante soit un comportement définit).

                    Ah, j'y avais pas pensé.

                    • en Python, parce que finalement, il y a toujours un couillon pour venir affecter une nouvelle valeur à ta constante. Je préfère encapsuler et fournir des copies de la valeur, histoire d'être certain que personne ne vienne y foutre le bordel.

                    Ok, m'enfin quand même. Si les gens sont pas foutu de comprendre qu'il ne faut pas modifier une variable… (même si je regrette l'absence de const en Python)

                    • en JavaScript, comment dire, c'est, hmmm

                    ?

                    • en SQL, j'ai même arrêter d'écrire les clauses en majuscules. Un jour, j'essaierai de comprendre pourquoi tout le monde écrit ses requêtes en majuscules.

                    Entièrement d'accord.

                    C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps

                    Ou sinon on privilégie l'efficacité à l'esthéthique, et des fois savoir que c'est une constante au premier coup d'œil ça peut être pratique.

                    Je t'écoute.

                    Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.

                    En effet.

                    Pourtant, il y a des choses implicites. Par exemple, les invariables sont copiés quand passés en argument, ou encore assigné à une variable. Le ducktyping : il n'y a pas plus implicite que le ducktyping, puisque tu suppose que l'objet qui t'es donné réagi comme tu t'y attends.

                    J'avoue que je n'ai pas (encore) rencontré d'exemple de duck typing.

                    L'absence totale de typehinting : ce qui est explicite, c'est de dire quel type/interface tu attends en argument, pas de le dire vaguement dans le doc ou laisser le plaisir de la lecture de la fonction.

                    En effet, c'est dommage.

                    et de ne pas utiliser des variables membres préfixées de _ en dehors de la classe (en plus c'est pratique de le savoir au sein de la classe en un coup d'œil).

                    Et pourquoi ne pas utiliser l'hungarian notation tant qu'on y est ? J'utilise _ pour préfixer, j'ai même essayer _classname_varname pour améliorer ça, mais ça reste encore de la convention, on peut saloper depuis l'extérieur de la fonction.

                    Si les gens font de la merde aussi, ils peuvent en faire dans tous les langages.

                    Pour le reste, on peut utiliser des outils comme Pylint, ou même le compiler vers un autre langage (C, Java, C#).

                    Je ne suis pas défenseur à tout prix de Python mais il faut reconnaitre qu'il est pratique pour des petits ou moyens projets.

                    Écrit en Bépo selon l’orthographe de 1990

                    • [^] # Re: Framework web

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

                      En fait là je parlais en général. Et puis tu peux utiliser les accolades en Python! :p

                      Non, les accolades, en Python, c'est pour les dict.

                      Lapin compris (j'ai fait très très peu de PHP).

                      Dans l'exemple suivant, au niveau global, answer nomme une constante, une classe et une variable.

                      <?php

const answer = 42;

class answer {
    private $answer;

    function __construct($answer)
    {
        $this->answer = $answer;
    }

    function answer()
    {
         return $this->answer;
    }
}

$answer = new answer(answer);
var_dump($answer->answer());

                      Ou sinon on privilégie l'efficacité à l'esthéthique, et des fois savoir que c'est une constante au premier coup d'œil ça peut être pratique.

                      Dans le cas de PHP, la question ne se pose pas, car le contexte indique directement qu'on a une constante. Ceci dit, je ne vois pas pourquoi je devrais considérer une variable différemment selon que c'est une constante ou non. Dans le cas de Python, c'est trompeur, puisque les constantes n'existent pas.

                      J'avoue que je n'ai pas (encore) rencontré d'exemple de duck typing.

                      Oh si, tu as dû. Le ducktyping vient d'une idée très simple : jusque là, tout va bien. En fait, tant que l'objet que tu manipule se comporte comme ce à quoi tu t'attends, tout va bien. En gros, ce qui marche comme un canard, est un canard. Bref, une oie est un canard par exemple. C'est génial quand tu fais un prototype, mais ça devient un enfer sur un projet plus important.

                      Si les gens font de la merde aussi, ils peuvent en faire dans tous les langages.

                      Non. C'est une erreur habituelle à mon sens. Un langage exigeant ne permettra pas à l'incompétent de croire qu'il peut écrire une application de facturation en quelques clicks. Apprendre des langages exigeant comme Ada ou C++, ça permet de structurer sa pensée, ce qui permet d'utiliser des outils plus laxistes pour prototyper. Mais au final, il faudra bien structurer.

                      Pour le reste, on peut utiliser des outils comme Pylint, ou même le compiler vers un autre langage (C, Java, C#).

                      Les outils pour analyser le code sont légions, et très utiles. Je les utilises systématiquement, et en compléments les tests unitaires et fonctionnels. Quand à compiler, je ne vois pas l'intérêt de compiler du code bancal : tu n'auras pas magiquement le type hinting, par exemple.

                      • [^] # Re: Framework web

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

                        Ceci dit, je ne vois pas pourquoi je devrais considérer une variable différemment selon que c'est une constante ou non. Dans le cas de Python, c'est trompeur, puisque les constantes n'existent pas.

                        Marrant, à partir du même constat technique, je fais la conclusion inverse. Le manque de const en Python est éventuellement un problème ; mais si de toutes les façons tu fais un projet en Python, et que tu as besoin d'une constante, pourquoi risquer de te tromper toi-même en ne la mettant pas en majuscule ? Si en faisant la revue de code d'un de mes dev il me fait un module.MYCONST = blabla, je le vois immédiatement et il a droit a coup de pied au cul (virtuel). C'est sûrement pourquoi en 10 ans de Python ce n'est pas quelque chose qui m'a provoqué un seul bug je pense (d'autre trucs oui, mais pas ça).

                      • [^] # Re: Framework web

                        Posté par  . Évalué à 3.

                        Apprendre des langages exigeant comme Ada ou C++, ça permet de structurer sa pensée, ce qui permet d'utiliser des outils plus laxistes pour prototyper. Mais au final, il faudra bien structurer.

                        Oh ben oui c'est fou comme on apprend vite à structurer sa pensée quand on oublie un ; après la définition d'une classe dans un .h en C++.

                        • [^] # Re: Framework web

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

                          En effet, ça structure énormément. Je n'oublie plus ce maudit point-virgule depuis des années, et l'utilises pour documenter.

                          class turlute
{
/* bwaaaaaaaaaaaaah */
} /* class turlute*/ ;

                  • [^] # Re: Framework web

                    Posté par  . Évalué à 3.

                    Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.

                    Ce n'est ni inutile ni absurde, ça viens juste d'une idée grotesque : pouvoir ajouter/modifier les méthodes d'une classe ou d'un objet dynamiquement. Ça sert à rien mais ça tue les perf (oui les new style class existent mais ce n'est pas assez utilisé).

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

                    • [^] # Re: Framework web

                      Posté par  . Évalué à 1. Dernière modification le 11 août 2013 à 11:56.

                      C'est pas forcément grotesque (c'est parfois utile en dernier recours), c'est surtout vite mal utilisé.
                      (d'où les 'refinements' en Ruby 2.0)

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Framework web

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

                        Je rejoins le commentaire de xcomcmdr, ça fait partie des outils à manipuler avec précaution et le moins possible (comme l'assembleur inline en C par exemple), mais qui peuvent te sauver la vie.

                        Sur ton propre code c'est en effet assez inutile, en revanche même les meilleures bibliothèques ou frameworks ont des limites qui peuvent te gêner. Forker un framework de 100K lignes de code parce qu'il manque une méthode dans une classe de base (pour ton usage en tout cas) c'est un peu pénible, et maintenir un patch par dessus ça rend ton soft pénible à installer pour tes utilisateurs.

                        Je fais ça genre 2 fois dans mon soft de 40K lignes de code pour modifier légèrement Django (derrière j'ai ma batterie de tests unitaires qui va bien) ; ça me semble raisonnable, et la moins affreuse des solutions (ça m'économise des milliers de lignes de code).

                        • [^] # Re: Framework web

                          Posté par  . Évalué à 2.

                          Dans n'importe quel modèle objet tu peut hériter des classes en question, c'est à mon humble avis nettement plus propre car une fois que tu es construis ton objet tu sais qu'il est fini, il faut pas en plus que tu lui ajoute des choses en plus pour le finir. De plus c'est un énorme effet de bord. Si tu passe cet objet en paramètre d'une méthode celle-ci peut écraser ta modification. Enfin ça n'apporte que du sucre syntaxique face à garder la méthode séparée (sachant que garder la méthode séparée permet de ne pas créer d'effet de bord).

                          Mais surtout, je trouve que pour un usage qui devrait être quasi inexistant, on explique cela bien trop tôt. Comme si c'était une fonctionnalité de base du langage.

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

                          • [^] # Re: Framework web

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

                            Dans n'importe quel modèle objet tu peut hériter des classes en question, c'est à mon humble avis nettement plus propre car une fois que tu es construis ton objet tu sais qu'il est fini, il faut pas en plus que tu lui ajoute des choses en plus pour le finir. De plus c'est un énorme effet de bord. Si tu passe cet objet en paramètre d'une méthode celle-ci peut écraser ta modification. Enfin ça n'apporte que du sucre syntaxique face à garder la méthode séparée (sachant que garder la méthode séparée permet de ne pas créer d'effet de bord).

                            Mon problème est que ce n'est pas moi qui instancie les-dits objets, et donc qui choisit leur classe. Donc je pouvais :

                            Méthode 1:
                            - Copier toute la machinerie d'instanciation, (et donc la mettre à jour quand Django évolue).
                            - Dériver de la classe de base pour faire ma propre classe de base, puis refaire toutes les classes filles que me fournit Django (des dizaines). Même remarque sur la maintenance.
                            - Utiliser ces nouvelles classes dans mon code, et dupliquer les classes fournies en contributions à Django qui utilisent les classes de Django, et pas les miennes forcément.

                            Méthode 2:
                            Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.

                            Ma méthode permet d'avoir un résultat élégant (comme si c'était intégré à Django de base), et sans écrire/dupliquer des pans entiers de Django. Je pense donc, dans la mesure où en des années de développement sur ce projet j'ai fait un tel "hack" 2 fois, qu'on se situe dans le domaine du hack intelligent (dont on se serait bien passé mais qui sauve la vie).

                            Mais oui j'ai fait attention de prendre des noms qui limitent la probabilité de collisions, et mon code est super bien testé (pas pour ce hack en particulier hein, de manière générale). Et je le répète c'est à utiliser en dernier recours.

                            Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.

                            Mes collègues qui font du Java à côté de moi, confrontés au même genre de problème, sont obligés de faire des trucs bien plus crades (surcharge de package, introspection pour modifier des trucs private…).

                            Mais surtout, je trouve que pour un usage qui devrait être quasi inexistant, on explique cela bien trop tôt. Comme si c'était une fonctionnalité de base du langage.

                            Ça c'est un autre problème, moi je dis juste que ce n'est pas inutile. Maintenant si je dois faire la promotion de Python, ce n'est pas dit que j'en parle en effet.

                            • [^] # Re: Framework web

                              Posté par  . Évalué à 2.

                              Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.

                              Le gros avantage c'est que tu sais que cette méthode n'a pas d'effet de bord. Seul ton code accède à ce dont il est le seul à avoir besoin.

                              Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.

                              Je ne connais pas les refinements de ruby, mais les classes d'extension de C# d'après ce que l'on voit dans le lien plus haut ne permet que d'ajouter des choses, donc les collisions se voient déjà bien mieux.

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

                              • [^] # Re: Framework web

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

                                Le gros avantage c'est que tu sais que cette méthode n'a pas d'effet de bord. Seul ton code accède à ce dont il est le seul à avoir besoin.

                                Tout à fait d'accord, vu que tu répète ce que j'ai dit (peut être pas assez clairement ?). Cette fois, le hack était très peu risqué et avait d'énormes retombées en terme d'élégance dans le reste de l'application, notamment en permettant d'économiser beaucoup de lignes de code. Mais d'autres fois le compromis est beaucoup moins favorable, et je vais faire autrement. En technique, on est sans arrêt dans le compromis.

                                Mais dans le fond on est d'accord je pense, donc pas la peine de chipoter pendant 3 heures.

                                Je ne connais pas les refinements de ruby, mais les classes d'extension de C# d'après ce que l'on voit dans le lien plus haut ne permet que d'ajouter des choses, donc les collisions se voient déjà bien mieux.

                                Je ne ferai pas de journaux sur Rust en disant que j'ai hâte de m'y essayer si je pensais que l'approche dynamique de Python était l'alpha et l'oméga.

          • [^] # Re: Framework web

            Posté par  . Évalué à 2.

            pas de modificateurs de visibilité, donc pas d'encapsulation, donc pas objet

            les modificateurs de visibilité sont-ils vraiment nécessaires pour faire de l'encapsulation ? et l'encapsulation est-elle vraiment nécessaire pour faire de l'objet ?

            • [^] # Re: Framework web

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

              Ils sont indispensables, puisque leur absence entraîne une impossibilité d'encapsuler. L'encapsulation, c'est rendre étanche l'état interne d'un système de ces clients, et de fournir aux clients une interface de manipulation.

              Bien évidement, les modificateur de visibilité ne garantissent pas l'encapsulation. Nombreux sont les imbéciles à générer automatiquement des getter qui exposent induement un composant interne à l'extérieur. Comme par exemple, le dernier getter proposé dans cet exemple :

              class State
{
    /* ... */
} /* class State */;

class BlackBox
{
        class Impl;
        std::unique_ptr<Impl> p_impl;

    public:
        BlackBox();
        BlackBox(BlackBox const &);
        BlackBox & operator=(BlackBox const &);

        // Une copie de l'état interne de l'objet
        State const state() const;

        // Optimisation du précédent, mais avec une brèche qui peut mener à la
        // manipulation de l'état interne de l'objet
        State const & state() const;

        // Une exposition directe de l'état interne de l'objet
        State & state();

} /* class BlackBox */;

              On voit bien que dans le premier, la manipulation de l'état interne de l'objet n'est pas possible sans reverse engineering. Dans le second cas, un const_cast est possible, c'est parfois ça le coût de l'optimisation. Dans le dernier cas, c'est la fête du slip : il n'est plus possible de changer d'état sans effet de bord. Sauf à limiter fortement la conception interne de la classe, et c'est là qu'on voit que l'encapsulation n'est plus.

              Tu me diras qu'en Python, on s'en fout, on manipule des références.

              # abstract
class State(object):
    pass

class InitState(State):
    message = 'Initial'

class TermState(State):
    message = 'Terminal'

class BlackBox(object):
    def __init__(self):
        self._state = InitState()

    def state(self):
        return self._state

    def next_state(self):
        if isinstance(self._state, TermState):
            raise BaseException('Mais euh!')

        self._state = TermState()

def client():
    bb = BlackBox()

    # Aquisition d'une reference sur l'etat interne de l'objet (note que ce commentaire est
    # errone)
    current_test = bb.state()

    while current_test.message is 'Initial':
        bb.next_state()

client()

              Au temps pour les références et leur usage incorrect… Alors oui, il est possible de faire la même connerie en C++, conserver l'état et le réutilisé plus tard. Mais la grosse différence, c'est qu'en C++ tu sais que tu acquiert une copie, et que donc c'est copie a une durée de vie courte.

              C'est pour ce genre de conneries que j'aime l'encapsulation, l'hermétisme des systèmes et la rigueur.

              • [^] # Re: Framework web

                Posté par  . Évalué à 2.

                Je comprends ce que tu dis mais pour moi l'encapsulation doit surtout se faire grâce à une interface. Si un client attaque directement une implémentation et fout la merde, je dirais c'est son problème. À lui d'utiliser l'interface.

                • [^] # Re: Framework web

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

                  Justement, l'interface c'est ce qui est publique (ou protégé pour les héritiés). Ce qui est privé relève du détail d'implémentation. C'est ça l'encapsulation, c'est ça le principe fondateur de la programmation orientée objet. Sinon on aurait juste gardé les struct en C.

                  • [^] # Re: Framework web

                    Posté par  . Évalué à 2.

                    Ah. Moi je croyais que l'intérêt c'était le polymorphisme, l'héritage, les méthodes virtuelles, tout ça.

                    • [^] # Re: Framework web

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

                      Le polymorphisme permet de fournir une interface publique dynamique, qu'importe l'implémentation.

                      L'héritage complet permet d'encapsuler une hiérarchie. Par complet, j'entends celui de C++, qui permet des héritages privés ou protégés, encapsulant ainsi l'héritage.

                      Je suppose que par "méthodes virtuelles" tu veux parler des méthodes virtuelles pures (sinon tu te répètes :p ). Encore une fois, c'est un moyen d'indiquer une interface, et de déléguer aux implémentations l'encapsulation du problème.

                      Tu me trouveras certainement monomaniaque, mais au final, quand on réfléchi à tous les avantages de la programmation orientée objet, on en revient toujours à un dénominateur commun : l'encapsulation.

                      • [^] # Re: Framework web

                        Posté par  . Évalué à 1.

                        Je pensais au "polymorphisme de méthode"…

                        Pour ce qui est de l'héritage autre que publique, je ne vois pas trop son intérêt par rapport à la composition…

                        Ce que je trouve pénible, c'est l'utilisation systématique du maximum de contraintes pour décrire un objet. Pour moi le fait de devoir introduire des contraintes dans une définition est un inconvénient.

                        • [^] # Re: Framework web

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

                          Je pensais au "polymorphisme de méthode"…

                          Ben, c'est ce que permet une fonction membre virtuelle. Donc tu parles de la même chose. Personnellement, je ne connais que deux types de polymorphismes : statique, dynamique. Le premier est résolu à la compilation (en C++, il est obtenu à l'aide de templates) ; le second à l'aide de méthodes virtuelles.

                          Pour ce qui est de l'héritage autre que publique, je ne vois pas trop son intérêt par rapport à la composition…

                          L'héritage privé est l'héritage canonique. C'est pour ça que c'est sa visibilité par défaut en C++. L'intérêt de ce type d'héritage réside dans la dérivation de templates, du genre :

                          #include <string>
#include <vector>

class string_list
    : private std::vector<std::string>
{
    using std::vector<std::string>::cbegin;
    using std::vector<std::string>::cend;
} /* class string_list */;

                          Une composition, dans ce cas, pourrait introduire une indirection, et plus de code (donc statistiquement plus de bogues).

                          Pour moi le fait de devoir introduire des contraintes dans une définition est un inconvénient.

                          Et malheureusement, la plupart des développeurs pensent comme toi : à mort la rigueur ; personne ne va oser faire ça ; les mutex c'est pour les fillettes ; tout est publique, je n'ai rien à cacher.

                          Forcer un type permet d'assurer que le code n'échouera pas bêtement.
                          J'aime être certain que je ne créé pas de variable sans le savoir, en me trompant en tapant la variable.
                          J'aime savoir si la classe que j'utilise est copiable, clonable, si ces attributs sont en lecture seule ou non, si je peux la dériver, etc. J'aime la certitude, circonscrire les risques, là où tu semble te délecter du risque maximal.

                          • [^] # Re: Framework web

                            Posté par  . Évalué à 1.

                            Personnellement, je ne connais que deux types de polymorphismes : statique, dynamique.

                            Eh bien on parle aussi parfois de polymorphisme de méthode pour désigner la surcharge par opposition au polymorphisme de type que tu connais. Visiblement c'est un terme qui ne semble pas très répandu, j'ai trouvé peu de références sur le net, en tout cas il était utilisé dans les cours que j'ai eus sur les langages objets.

                            Une composition, dans ce cas, pourrait introduire une indirection, et plus de code (donc statistiquement plus de bogues).

                            S'il faut avoir peur d'une simple délégation, où va le monde ? :-)

                            J'ai pas compris l'exemple que tu as donné, pourquoi ne pas faire ça ? Le template ne fait pas bien son job ?

                            typedef std::vector<std::string> string_array;

                            Pour le reste du commentaire, je n'ai pas envie d'être méchant, alors je n'y réponds pas…

                            • [^] # Re: Framework web

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

                              Eh bien on parle aussi parfois de polymorphisme de méthode pour désigner la surcharge par opposition au polymorphisme de type que tu connais. Visiblement c'est un terme qui ne semble pas très répandu, j'ai trouvé peu de références sur le net, en tout cas il était utilisé dans les cours que j'ai eus sur les langages objets.

                              J'avais justement parcouru le Web pour tenter de trouver quelque chose, mais rien de bien intéressant. Ça a l'air d'être une lubie d'universitaires franco-français.

                              S'il faut avoir peur d'une simple délégation, où va le monde ? :-)
                              Je suis un fainéant, moins j'en fait et mieux je me porte :-D

                              J'ai pas compris l'exemple que tu as donné, pourquoi ne pas faire ça ? Le template ne fait pas bien son job ?

                              typedef std::vector<std::string> string_array;

                              Dans ce cas, string_array reste un std::vector. Je ne veux pas exposer l'interface de std::vector, et l'utilisateur n'a pas à savoir comment est implémenté string_array. Bref, dans ton cas, il est possible de confondre des type, puisque string_array est publiquement un std::vectorstd::string.
                              Ceci implique que n'importe quel std::vectorstd::string peut être fournit en lieu et place de string_array. Donc le jour où tu décide de remplacer std::vectorstd::string par std::vectorstd::string<MonAlloc, MonAlloc>, partout où le code utilisera std::vertorstd::string devront être mis à jour. Alors qu'en étant orthogonal dès le départ, on évite ses blagues.

                              De plus, il n'est pas possible de restreindre l'usage des méthodes de std::vector.

                              Pour le reste du commentaire, je n'ai pas envie d'être méchant, alors je n'y réponds pas…

                              Bah, plus personne ne nous regarde, on est entre nous, fais-moi mal.

                              • [^] # Re: Framework web

                                Posté par  . Évalué à 1.

                                Dans ce cas, string_array reste un std::vector. Je ne veux pas exposer l'interface de std::vector, et l'utilisateur n'a pas à savoir comment est implémenté string_array. Bref, dans ton cas, il est possible de confondre des type, puisque string_array est publiquement un std::vectorstd::string.
                                Ceci implique que n'importe quel std::vectorstd::string peut être fournit en lieu et place de string_array. Donc le jour où tu décide de remplacer std::vectorstd::string par std::vectorstd::string, partout où le code utilisera std::vertorstd::string devront être mis à jour. Alors qu'en étant orthogonal dès le départ, on évite ses blagues.

                                bah si tu aimes être responsable des conneries des autres…

                                De plus, il n'est pas possible de restreindre l'usage des méthodes de std::vector.

                                C'est clair qu'en mettant tout privé on évite efficacement les bugs.

                                • [^] # Re: Framework web

                                  Posté par  . Évalué à 3.

                                  bah si tu aimes être responsable des conneries des autres…

                                  Ce n'est pas être responsable des conneries des autres, juste fournir un service fiable et simple à utiliser¹. Tu sais qu'aucun client de classe ne pourra faire autre chose que ce que tu prévois de faire. Le fait de limiter ce que tu expose permet d'avoir une bien meilleure couverture de test et un fonctionnement plus fiable. Imagine sur un programme multitâche, une classe qui possède un tableau, qui l'expose et qui dans l'une de ses méthodes itère sur ce tableau. Cette dernière méthode peut planter à tout moment parce qu'entre deux itérations tu aura quelqu'un d'autre qui aura modifié ce tableau.

                                  J'avais écris un journal qui se rapproche un peu de ça. Le fait d'exposer ton état interne pose les même problèmes que le fait d'utiliser des variables globales ça rend le nombre de branches possible trop grande pour être humainement compréhensible.

                                  De manière un peu moins terre à terre le fait d'encapsuler fortement permet d'écrire des modules et/ou des classes plus autonomes, ton gros programmes deviens un ensemble de sous programmes dont l'interface entre eux est totalement maitrisé (tu connais la liste des méthodes qu'il peut appeler sans avoir à imaginer qu'il fait évoluer tel ou tel partie de ton état interne) et c'est donc bien plus simple à maintenir puisque tu peut tout changer (donc y compris la représentation interne de ton état) sans avoir à toucher aux utilisateurs de ta classe.

                                  C'est clair qu'en mettant tout privé on évite efficacement les bugs.

                                  Ça ne les supprime pas, ça en enlève un certains nombres qui sont potentiellement une plaie à dégager.

                                  D'autre part tu parler de contrainte de type. Je te conseille de regarder ce qui est fait dans les langages fonctionnels ou d'autres comme l'ADA. Dans les quels on peut contraindre les types de manière bien plus forte qu'en python ou C++. C'est enrichissant. Le système de type est un outil du programmeur pas une contraintes (même en python).

                                  ¹ : l'objectif ce n'est pas de créer le plus grand nombre de pièges possibles en se disant que ceux qui tombe dedans c'est bien fait pour eux, mais au contraire de limiter les erreurs et de les détecter au plus tôt.

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

                                  • [^] # Re: Framework web

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

                                    Il me semble d'ailleurs que cet article a participé à ma compréhension de la programmation orientée objet et fonctionnelle, en plus des ouvrages ou conférences de Stroustrup, Meyers et Sutter.

        • [^] # Re: Framework web

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

          pourquoi PHP et pas python ? parce que je ne maitrise pas python.

        • [^] # Re: Framework web

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

          {{#trollMode}}
          Arrêtez avec vos discussions sur le choix des langages et autres "c'est toujours mieux ailleurs", un langage n'est qu'un outil n'importe quel imbécile peut faire un script / programme pourri dans beaucoup de langage … c'est comme pour le français on peut bien parler … mais on peut aussi faire plein de fautes d'otographe … c'est pas pour ça que le français c'est moins bien que l'anglais … quoi que …
          {{/trollMode}}

          Personnellement, je trouve l'application bien sympa, niveau code, on peut toujours faire mieux et l'équipe semble aller dans le bon sens. Je souhaite un bel avenir à cet outil, et je plussoie une intégration de Sharlii

          • [^] # Re: Framework web

            Posté par  . Évalué à 3.

            Note que je n'ai pas dit qu'ils auraient dû choisir autre chose, j'ai demandé à l'auteur d'expliquer ce qui a motivé son choix. Il a répondu en disant que c'était le langage qu'il connait, et c'est une bonne réponse.

    • [^] # Re: Fête du slip

      Posté par  . Évalué à 5.

      Déjà, tu considère que tout le monde utilise Apache ou Nginx […]

      C'est déjà pas mal quand on voit le nombre de logiciel qui considèrent juste que tu utilise apache et pour les quels c'est à toi de te fader les réécriture d'url…

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

      • [^] # Re: Fête du slip

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

        Au départ je n'avais pas vu la partie sur Nginx, mais je me suis dit que le troll vallait quand même, un peu.

        Plus sérieusement, ce n'est pas le boulot de l'application d'expliquer comment on configure un autre logiciel. Ou alors, dans un tutoriel, mais à part du logiciel principal.

  • # Lien cassé

    Posté par  . Évalué à 1.

    Le projet est intéressant mais pour ma part, le lien donné sur la page d'installation pour le téléchargement http://static.inthepoche.com/files/poche-1.0-latest-with-twig.zip ne fonctionne pas.

  • # Hors sujet mais

    Posté par  . Évalué à 2.

    Question a propos de linuxfr:

    Je me rappelle qu'avant il y avait une note NEW! (en rouge) devant les commentaires qu'on n'avait pas encore lus. Je ne vois plus cette note (mais sur la page des dépêches on a bien le nombre de commentaires non vus sur la dépêche qui sont affichés).

    Je n'ai peut être pas suivi et cette option est activable qqpart? Sinon, je trouve que ca manque cruellement.

    Merci et désolé pour le hors sujet.

    • [^] # Re: Hors sujet mais

      Posté par  . Évalué à 3.

      c'est en fonction de la feuille de style

      Depending on the time of day, the French go either way.

      • [^] # Re: Hors sujet mais

        Posté par  . Évalué à 0.

        Dans ce cas, quelles feuilles de style le gèrent? Car je viens d'en essayer 2-3 (dont celle par defaut) et aucune ne semble mettre en valeur les nouveaux messages…

        • [^] # Re: Hors sujet mais

          Posté par  . Évalué à 4.

          aucune ne semble mettre en valeur les nouveaux messages…

          Si c'est juste plus subtile. Celle par défaut change la couleur des cadres de titres des nouveaux commentaires.

          Exemple de barre de titre d'un ancien et d'un nouveau commentaire

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

          • [^] # Re: Hors sujet mais

            Posté par  . Évalué à 4.

            Et:
            Titre de l'image

            Depending on the time of day, the French go either way.

          • [^] # Re: Hors sujet mais

            Posté par  . Évalué à 0.

            Ah oui merci. En effet, c'est subtil!
            Dommage, j'aimais bien le NEW! en rouge, c'etait visible au premier coup d'oeil en scrollant.

            Encore merci.

            • [^] # Re: Hors sujet mais

              Posté par  . Évalué à 4.

              Tu peux te faire une feuille de style personalisée (basée sur celle actuelle) qui ajoute un NEW ! rouge devant les nouveaux commentaires.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Hors sujet mais

      Posté par  . Évalué à 3.

      Je suis comme toi, la feuille de style par défaut m'est inutilisable.

      La meilleure que j'ai trouvé pour la mise en valeur des nouveaux messages est cascade-alternative, met en valeur les nouveaux messages avec un fond gris foncé.

      cascade-alternative

  • # Moteur de template ?

    Posté par  . Évalué à 1.

    Pourquoi changer de RainTPL vers Twig ? A croire ça, mieux vaudrait l'inverse. Si t'as des raisons précises, des avis techniques, je serais heureux de les lire, ça me turlupine.

  • # Il manque l'essentiel dans la documentation : comment ajouter un lien?

    Posté par  . Évalué à 1.

    J'ai cherché dans la démo comment ajouter un lien, je n'ai pas trouvé.
    J'ai cherché dans la documentation, ce n'est pas indiqué.

    Ça manque!

  • # Pour toutes vos questions

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

    Si vous avez des questions à propos de poche (et uniquement à propos de poche), y'a le mail support@inthepoche.com, y'a @getpoche, y'a https://groups.google.com/forum/#!forum/poche-users, https://www.facebook.com/inthepoche ou https://plus.google.com/u/0/b/103875824443262355243/103875824443262355243/posts

    Y'a même irc.freenode.net ##poche

    Pas que ça part en sucette ici … mais bon !

  • # Merci

    Posté par  (Mastodon) . Évalué à 1. Dernière modification le 14 août 2013 à 11:11.

    Je viens de l’installer, avec l’appli android et le xpi pour firefox, et du même coup, j’ai migré et supprimé mon compte pocket.

    Ça marche bien, ça fait le boulot, juste quelques suggestions pour les futures versions 

    • Pouvoir avoir plusieurs comptes sur une instance (une pour chaque membre de la famille par exemple.
    • La possibilité d’ajouter des tags.
    • La consultation hors ligne (à mon avis en html5 plutôt que dupliquer le travail entre les différents extensions (xpi,apk…)).

    J’en ai profité pour signaler un bug en https… ☺

    • [^] # Re: Merci

      Posté par  (Mastodon) . Évalué à 1.

      Ah, et j’avais oublié, serait-il possible d’utiliser des requêtes AJAX pour les bouton lu/non lu, favoris et supprimer ? on y gagnerait beaucoup sur mobile dans le train avec une connexion poussive ;-)

      • [^] # Re: Merci

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

        Bonjour Landry !

        Merci pour vos deux commentaires et pour l'utilisation de poche.

        • Pouvoir avoir plusieurs comptes sur une instance (une pour chaque membre de la famille par exemple.
          C'est techniquement faisable, la structure de la base est pensée pour le multi utilisateurs, il ne manque que l'interface d'admin pour créer un compte. C'est donc possible de bidouiller dans la base pour ajouter un compte ;-)

        • La possibilité d’ajouter des tags.
          C'est planifié.

        • La consultation hors ligne (à mon avis en html5 plutôt que dupliquer le travail entre les différents extensions (xpi,apk…))
          Également au planning.

        • requêtes AJAX pour les bouton lu/non lu, favoris et supprimer
          C'était comme ça au début. Et puis j'ai supprimé tout le javascript … et puis ça va surement revenir car nous aurons prochainement un système de file d'attente (pour gérer l'ajout des liens, pour éviter les surcharges) et donc on pourra envisager de marquer comme lu tout ça depuis la file d'attente.

        Merci encore pour les retours !
        Bonne utilisation !

Suivre le flux des commentaires

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