Journal S’il vous plaît... architecture-moi un Kanboard !

31
26
fév.
2014

0xfg nous a fait le plaisir de partager son "gestionnaire de tâches visuel qui permet de gérer facilement des petits projets de manière collaborative" : Kanboard

Comme il l’explique dans sa dépêche, la pile logicielle utilisée est :

D'un point de vue technique, Kanboard est une application web développée en PHP et utilise Sqlite pour enregistrer ses données.

Avec du vanilla javascript (pas de framework) pour gérer les interactions côté client.

S’ensuit alors une discussion sur la merditude de PHP qui ne peut mener nul part, puisque le langage parfait n’existant pas, on trouverait toujours à redire sur le choix de la techno employée. C’est le but inavoué de ce journal.
Pour autant, sans vouloir argumenter de la supériorité, des manques ou des faiblesses d’un langage par rapport à un autre, on peut tout à fait exprimer ses choix en matière de technologie à utiliser.
Enfin, je vous encourage à argumenter, c’est juste que : c’est horrible, c’est lent, le code est pas beau, c’est quoi la différence entre un bon chasseurdéveloppeur et un mauvais chasseurdéveloppeur, ce sont des arguments d’une portée limitée …

Je commence par vous présenter le choix de Fog Creek pour son application Trello. C’est assez ressemblant avec Kanboard, même si les finalités ne sont pas les mêmes.

Vous trouverez la démarche et les explications de ce choix sur leur blog : Trello Stack

Serveur

  • node.js parce que :

    • propagation instantanée des mises à jour
    • gére les évènements coté serveur de façon non blocante
    • adapté aux applications SPA avec le framework Express pour gérer les routes et le middleware Connect pour l’auth et la gestion des cookies
    • Cluster pour gérer les instances nodejs
    • Le tout écrit en CoffeeScript qui compile vers javascript
  • HAProxy pour :

    • la répartition de charge
  • Redis pour :

    • gérer de façon rapide les données éphémères partagées entre les différentes instances
    • le PubSub pour renvoyer les modifications aux clients
  • mongoDB pour :

    • une base de données orientée documents leur permettant de faire tourner différente versions de codes sans avoir à gérer les migrations de schéma que pourraient subir une base de données classique SQL

Il existe de nombreuses solutions NoSQL, ce blog vous en propose une comparaison : Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris

Client

  • mustache pour :

    • le système de micro templating afin de générer le HTML
  • Less :

    • Less est un préprocesseur CSS, ce genre d’outil évite de se répéter dans son code et permet de pallier au manque de CSS tels que les variables ou les calculs.

D’autres solutions existent telles que :
- Saas/compass
- stylus

  • Backbone.js pour :

    • gérer les évènements du DOM
    • regénérer le HTML produit par mustache en cas de changement
  • pushState pour :

    • pour executer les changements de pages dans le cadre d’une SPA en conservant la possibilité d’obtenir des liens propres (bookmark) en appelant le controller Backbone.js adéquat
  • Pour les mises à jour de l’interface en temps réel :

    • Socket.IO pour gérer les connections WebSocket dans les navigateurs récents
    • Du polling AJAX pour les navigateurs plus anciens ou IE ne supportant pas les WebSocket

Le monde des frameworks MVC côté javascript évoluant à un rythme effréné, il est tout à fait envisageable de se tourner vers d’autres solutions :
- angularjs (Google)
- emberjs (Tilde)
- React (Facebook)

Si vous cherchez bien, vous trouverez de nombreuses querelles de clocher concernant ces solutions, comme d'habitude en somme …

J’ai bien compris la démarche de 0xfg exprimé dans ce commentaire :

Au départ j'avais hésité à le faire en Python ou en Golang mais finalement je l'ai fais en PHP pour que se soit vraiment simple à installer partout. Quitte à faire un logiciel libre pour soit même autant qu'il serve aux autres également…

On est donc loin de l’esprit de Fog Creek en ce qui concerne Trello, puisque eux même expliquent que le logiciel n’a pas pour but d’être distribué mais uniquement à être utilisé en solution SaaS.

Disons que je suis curieux et que j’aimerais connaître vos choix sur les briques logicielles que vous affectionnez.
Merci de partager vos connaissances ou réflexions.

Et vous, si vous deviez écrire ce Kanboard de zéro, quels seraient vos choix en matière de langage, framework ou architecture en général ?

  • # Corrections du journal

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

    C'est mon premier journal (j'ai hésité avec une entrée de forum) et je suis pas très fort en storytelling, alors si vous voulez m’aider à corriger mes fautes d'orthographe, de grammaire, de structure ou techniques, merci de m'en faire part dans ce fil afin de ne pas en mettre partout, ça me permettra de m'améliorer.

  • # Et php pour FogBugZ

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

    Pour l'autre produit phare de Fog Creek, FogBugZ, Joel Spolsky a fait un choix inverse.

    • FogBugZ est développé dans un langage maison qui ressemble a du PHP, mais en mieux, avec quelques fonctionnalités sympa.
    • ce langage est compilé vers du PHP de base, et tu peux choisir la version cible de ton PHP
    • du coup le déploiment d'un FogBugZ en interne dans une entreprise est triviale, la seule dépendance est un PHP de base, sans modules à la con.

    Le mode de distribution a donc une influence majeure sur les choix techniques à mettre en place dans l'architecture du logiciel et a fortiori son langage de programmation.

    • [^] # Re: Et php pour FogBugZ

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

      Est ce que tu aurais un lien sous la main par hasard, ça m'intéresse bien, mais j'arrive pas à retrouver de post sur son blog.

      Le mode de distribution a donc une influence majeure sur les choix techniques à mettre en place dans l'architecture du logiciel et a fortiori son langage de programmation.

      Absolument, je laisse le choix du mode de distribution à ceux qui souhaiterait nous présenter une stack qui leur tient à coeur.

  • # Drôle de métier

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

    Je ne développe que pour le plaisir, et donc mon approche du développement est forcément biaisée. Mais l'utilisation de tant de technologies pour publier un site interactif me laisse assez songeur.

    C'est sympa d'en utiliser une ou deux, parce que ces technologies ont toutes leur charme et leur intérêt. Mais les quelques technologies orientées web2.0 que j'ai essayées (peewee et bottlepy pour python, qui sont, il est vrai, très jeunes) ont tendance à changer régulièrement, parfois avec des modifications d'API, et les briques censées fonctionner ensemble supposent en vérité de prendre soin d'utiliser telle ou telle version, ce qui suppose d'utiliser une version spécifique du langage source, qui n'est pas forcément disponible sur le serveur à disposition… Bref.

    J'ai lu une fois un article de quelqu'un dont c'est le métier de créer des applications pour le web avec python. Pour chaque application, il embarquait la version de python et des bibliothèques qui conviennent dans une machine virtuelle, pour être certain d'avoir le bon équilibre.

    Le développement web, c'est vraiment une façon de surfer sur la vague des technologies mouvantes qui me laisse assez perplexe.

    • [^] # Re: Drôle de métier

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

      Je ne développe que pour le plaisir,

      Voila…
      Car :

      Mais l'utilisation de tant de technologies pour publier un site interactif me laisse assez songeur.

      Parce que tu n'as pas ces contraintes :
      Time to Market
      Total Cost of Ownership

      qui n'est pas forcément disponible sur le serveur à disposition

      Mais avoir une bonne machine dédiée ou VM pour cette app est le minimum du moment où tu arrêtes de jouer et fait un site avec des gens qui vont dessus.

      Pour chaque application, il embarquait la version de python et des bibliothèques qui conviennent dans une machine virtuelle, pour être certain d'avoir le bon équilibre.

      Et surtout c'est plus rapide au final à livrer.
      Que les gens qui veulent de la compatibilité sur plus de choses aident (mais en fait, ça râle un peu mais dès qu'il faut mettre la main au protefeuilles ils font pareil : hop VM, moins cher)

      Le développement web, c'est vraiment une façon de surfer sur la vague des technologies mouvantes qui me laisse assez perplexe.

      C'est parce que tu n'as pas la contrainte de temps.


      Perso, j'essaye de faire un travail de fond et compatible partout, pour des raisons de qui j'ai comme clients pros et de ce qui m'est demandé (spécialisé), mais clairement je suis du coup en retard sur plein de choses, car quand je développe ça prend justement du temps et pour un site web, c'est souvent une (bonne) idée à présenter et des briques "standards" suffisent alors amplement, pas la peine de perdre son temps à refaire ce que d'autre font déjà. L'usage de 10 technos existantes se justifie donc dans certains cas.

      • [^] # Re: Drôle de métier

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

        Je me doute bien que les développeurs web ont intérêt à utiliser toutes ces technologies.

        Mais à leur place, j'irai vite me mettre à l'abri dans la position du créateur de frameworks plutôt que dans celle d'utilisateur, avant de disparaître noyé sous la vague ou par simple obsolescence programmée.

        • [^] # Re: Drôle de métier

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

          avant de disparaître noyé sous la vague ou par simple obsolescence programmée.

          Pourquoi?
          - Si ça ne marche pas, tu aurais pas perdu ton temps, poubelle
          - Si ça marche, tu as l'argent pour maintenir/forker/refaire le travail mieux.

          C'est justement tout son interêt : tenter à moindre coût.

          • [^] # Re: Drôle de métier

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

            Il est vrai que le flux perpétuel c'est très bien pour ceux qui savent saisir le kairos par les cheveux.

            Personnellement, je suis plutôt tourné vers l'un, et je crois que si c'était mon métier, je préférerais ta situation Zenitram.

      • [^] # Re: Drôle de métier

        Posté par . Évalué à 6.

        Mais avoir une bonne machine dédiée ou VM pour cette app est le minimum du moment où tu arrêtes de jouer et fait un site avec des gens qui vont dessus.

        Il y a pas un manque de cohérence entre reprocher à CozyCloud des problèmes de performance et expliquer que « dès que ça deviens sérieux » ce sera de toute manière une VM dédiée. Ça dépend juste des contextes, si owncloud avait été distribué sous forme de VM il n'aurait pas eu le succès qu'il a ajourd'hui. Au contraire j'ai l'impression que les logiciels dont on entend parlé distribué sous cette forme ne sont pas très populaire.

        Au passage pourquoi dénigrer ainsi ? Il y a un paquet de logiciel qui ont largement fais leur preuve par rapport à tout ce que tu a pu coder dans ta vie qui ne sont distribuer par VM (owncloud, cozycloud, redmine, wordpress, dotclear, mediawiki, hudson, buildbot,… si tu veux en barrer dans la liste n'hésite pas je peux en ajouter autant que tu souhaite). Tu reproche ailleurs à d'autre de mettre de la moral dans leur commentaire, mais là ce n'est pas bien mieux.

        L'usage de 10 technos existantes se justifie donc dans certains cas.

        Dans les années 2 000, on reprochait à l'écosystème Java d'avoir trop de techno d'être une stack trop grosse. On expliquait que les développeurs Java ne maitrisaient plus rien de leur logiciel et que dès qu'il y avait un problème un peu subtile ils étaient perdu. Qu'est ce qui est différent aujourd'hui sauf la mode ?

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

        • [^] # Re: Drôle de métier

          Posté par (page perso) . Évalué à 3. Dernière modification le 26/02/14 à 15:23.

          qui ne sont distribuer par VM

          Rah ! Je t'aurais bien pertiné mais je hais c'te foutue faute !

          P.S. désolé c'était plus fort que moi, mais c'est de bonne guerre :)

          • [^] # Re: Drôle de métier

            Posté par . Évalué à 2.

            Mais tu as tout à fait raison. Généralement je pertine systématiquement tous les commentaires qui me font des remarques sur l'orthographe car ils m'aident à m'améliorer. :)

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

        • [^] # Re: Drôle de métier

          Posté par (page perso) . Évalué à 1. Dernière modification le 26/02/14 à 15:28.

          Au passage pourquoi dénigrer ainsi ?

          Hein?
          La VM, je ne parle pas de distribuer le logiciel sous VM, mais que le logiciel est installé sur une VM avec les bon logiciels (et bonnes versions) dessus.
          Parait même que LinuxFr est dans des VM.

          Et je ne sais pas où tu vois du dénigrement, je dis juste que dans certains cas, c'est plus simple de gérer une seule version des éléments, c'est tout. Pour d'autres cas, c'est mieux de fournir le plus compatible possible.
          Dire que l'un est parfois plus rapide à déployer ne veut pas dire que c'est la seule chose à faire dans tous les cas.

          Tu reproche ailleurs à d'autre de mettre de la moral dans leur commentaire, mais là ce n'est pas bien mieux.

          gni???
          On parle technique, rentabilité, la.

          On expliquait que les développeurs Java ne maitrisaient plus rien de leur logiciel et que dès qu'il y avait un problème un peu subtile ils étaient perdu. Qu'est ce qui est différent aujourd'hui sauf la mode ?

          Java est toujours utilisé, et j'en passe.
          Mais pire : maintenant on a plein de libs pour plein de choses, tu fais ton proto et tu regardes si ça prend ou pas (et si ça prend tu refais dans plus maintenable si tu veux)
          Ca n'a rien à voir, mais sinon oui le monde a changé, ça va encore plus vite, il y a encore plus de libs, et le principal élément d'un site web aujourd'hui est le concept, pas la technique.


          tu fais comme tu veux, de mon côté j'explique juste pourquoi les gens font comme ça, pour réponde à "ça me laisse songeur" du commentaire auquel je répond. Tu le prend pour toi si tu as envie, tu le prend comme moralisateur si tu as envie, mais ça rete ton envie.

          • [^] # Re: Drôle de métier

            Posté par . Évalué à 2.

            La VM, je ne parle pas de distribuer le logiciel sous VM, mais que le logiciel est installé sur une VM avec les bon logiciels (et bonnes versions) dessus.

            Ok j'avais mal compris. Comme tu parle de :

            Mais avoir une bonne machine dédiée ou VM pour cette app est le minimum du moment où tu arrêtes de jouer et fait un site avec des gens qui vont dessus.

            puis de :

            Que les gens qui veulent de la compatibilité sur plus de choses aident (mais en fait, ça râle un peu mais dès qu'il faut mettre la main au protefeuilles ils font pareil : hop VM, moins cher)

            Mea culpa, j'avais mal compris.

            gni???
            On parle technique, rentabilité, la.

            Technique oui, rentabilité je sais pas (tu es le seul à placer le débat dans un contexte entreprise), mais « du moment où tu arrêtes de jouer et fait un site avec des gens qui vont dessus », c'est pas de la technique, c'est juste une manière de dire « si tu n'utilise pas MA bonne pratique, c'est que tu fais de la merde » (c'est un argument classique chez toi de dire que si on es « sérieux », on fait comme tu le dis sinon on fait de la merde/des jouets/etc). Pourtant ailleurs tu explique que les bonnes pratiques, faut les prendre avec des pincettes.

            Java est toujours utilisé, et j'en passe.

            Ça ne répond pas à la question. Pourquoi est-ce que la complexification des stack étaient considérées comme un mal il y a 10 ans et est considéré comme super aujourd'hui.

            Mais pire : maintenant on a plein de libs pour plein de choses, tu fais ton proto et tu regardes si ça prend ou pas (et si ça prend tu refais dans plus maintenable si tu veux)

            On parle là de techno qui sont en prod.

            Ca n'a rien à voir, mais sinon oui le monde a changé, ça va encore plus vite, il y a encore plus de libs, et le principal élément d'un site web aujourd'hui est le concept, pas la technique.

            Justement. Si on en a fini avec le chalenge technique pourquoi il y a tant de révolutions technologique et pourquoi rare sont les blocs dont on parlent qui ont plus de 2 ou 3 ans ?

            tu fais comme tu veux, de mon côté j'explique juste pourquoi les gens font comme ça, pour réponde à "ça me laisse songeur" du commentaire auquel je répond. Tu le prend pour toi si tu as envie, tu le prend comme moralisateur si tu as envie, mais ça rete ton envie.

            :D alors que généralement tu nous sors un « Quoi ?! En , il y en a encore qui font ça ?! » ou « En , si on ne fait pas comme ça, c'est qu'on fait un truc utilisé par personne. ».

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

  • # bloat

    Posté par . Évalué à 10.

    Très intéressant journal, donnant un exemple bien représentatif de la jungle abominable que peut être le développement web aujourd'hui. Il y a quelques mois, il y avait eu une depeche (ou un journal) intéressant sur le développement web moderne et toutes ces technos disponibles.

    Dans cet exemple, on se retrouve donc avec une "stack" web :

    • pas intégrée aux distributions linux standard (debian/centos) : ce qui veut dire déploiement et maintenance (mise à jour, sauvegarde, réinstallation) à la main et donc laborieuse
    • Avec une gestion de paquets autonome & indépendante du système (cf remarque précédente)
    • 2 moteurs différents pour le stockage, et avec lesquels on peut tirer un trait sur l'ACID (bon faut voir s'il est nécessaire pour cette appli, c'est vrai)
    • stack serveur, c'est déjà bien riche : 3 frameworks dont 1 pas mis à jour depuis 2 ans et à qui on relègue la gestion des processus, pid & log de l'application. Le bonheur pour tout admin système.
    • Langage serveur : un langage qui compile dans un autre langage. On me chuchote à l'oreille un truc de hipster (bah ouais, pour juste du "sucre syntaxique" (quelle expression moisie d'ailleurs), c'est cher payé). Qui plus est il est distribué comme "module" pour Node.js. Dans les faits ça veut dire que le développeur n'a pas la vie facile, on est loin du code-upload-test des familles quand on fasait du web dans les startups. Bref j'ai de gros doutes sur la facilité et l'accessibilité du déploiement de l'appli.
    • côté client, youpi, on a un préprocésseur CSS, déjà ça c'est bien rébarbatif, se taper de la compilation avant un déploiement pas très folichon. On pourra se moquer des serveurs d'applications Java EE
    • un bon gros framework MVC… côté client ! bah ouais, comme même, tout le boulot que vous ne faites pas côté serveur, faut bien le faire quelque part !
    • un petit peu de temps passé à bidouiller l'historique du navigateur avec le pushState
    • une bonne vieille bibilothèque pour gérer le réseau… avec son pendant serveur à installer également du côté du node.js

    Dieu merci, le ruby a été évité.
    Il est bien loin le temps où on pouvait se contenter d'installer apache & son module PHP (ou même un petit WAMP pour produire en local).

    Le fait est que tout ça est devenu très complexe, mais, et c'est ça qui change, pour tous les acteurs du process de développement : développeurs de l'application, administrateurs, et designers.

    Je décernerai un 0/20 à l'accessibilité aux nouveaux venus, un 5/20 pour le déploiement, et 7/20 côté industriel/maintenance à une telle architecture.
    Quelqu'un qui plongerait dans cette architecture avec un simple slip de bain se noie directement. La courbe d'apprentissage et de maîtrise est plutôt raide et c'est selon moi un des gros inconvénients de se faire une architecture aux petits oignons pour une application web plutôt que de l'optimiser progressivement.

    Mais pour autant ça n'en fait pas quelque chose d'inintéressant, bien au contraire, mais il faut savoir dans quoi on met les doigts…

    • [^] # Re: bloat

      Posté par . Évalué à 2.

      pas intégrée aux distributions linux standard (debian/centos) : ce qui veut dire déploiement et maintenance (mise à jour, sauvegarde, réinstallation) à la main et donc laborieuse

      C'est marrant car l'autre jour, je suis tombé via linuxfr sur http://www.bortzmeyer.org/reveal-js.html et j'y ai appris que Grunt http://gruntjs.com/ (un outil pour lancer des tâches en JS) n'était pas packagé sous Debian pour une sombre histoire de licence https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727.

      Vu que cet outil semble assez hype et est semble t-il très utilisé dans le développement JS on se retrouve du coup avec une grande palanquée d'outils non packagés pour une connerie.

      En effet, l'outil utilise JSHint qui repose en partie sur JSLint qui utilise une licence MIT modifié qui pose problème à Debian (cf. http://tanguy.ortolo.eu/blog/article46/json-license).

      • [^] # Re: bloat

        Posté par . Évalué à 10.

        Pourquoi lorsque qu'il s'agit d'un projet utilisant javascript, j'ai cette impression de bordel sans nom ? d'avoir des tonnes de trucs "trop révolutionnaire" mais finalement assez isolés, avec des licences anarchiques, et sans aucun s'inquiéter de ce qui se fait à coté.

        il manque peut-être un rms.js qui fédérait un peu les efforts de dev.

        Je ne suis pas un expert de ce genre de framework.js mais
        gruik quand même :-D

      • [^] # Re: bloat

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

        une sombre histoire de licence

        Ah ouais, quand même…
        Je suis impressionné, ces gens qui mettent de la morale (mais qui ne l'explicite pas, sinon ça ne serait pas marrant) dans leur livrable.

        vous savez ce que vous avez le droit de faire avec ce genre de licence?
        "The Software shall be used for Good, not Evil."
        Parce que mon "Evil" n'est pas forcément le "Evil" de la personne qui a écrit (déjà je trouve cette clause comme "Evil").
        Bref, toute la beauté du non libre.

        • [^] # Re: bloat

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

          Je crois que c'est plus à vocation humoristique qu'autre chose. Après une licence c'est pas forcément le meilleur endroit pour faire de l'humour ou du second degré, mais c'est un autre problème.

          • [^] # Re: bloat

            Posté par . Évalué à 7.

            Le problème est que le soucis a été remonté à l'auteur et que ce dernier a refusé les changements de licence notamment pour les projets dérivés. La licence pose soucis à plusieurs entités dont debian.
            C'est donc de l'humour qui fait chier …
            Après c'est sûr que le mec fait ce qu'il veut … Mais c'est vraiment de l'énergie perdue.

    • [^] # Re: bloat

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

      Il y a quelques mois, il y avait eu une depeche (ou un journal) intéressant sur le développement web moderne et toutes ces technos disponibles.

      Voici (vu que c'est probablement de mes articles dont tu parles ;-)) :

      • [^] # Re: bloat

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

        D'excellents journaux d'ailleurs ! Merci pour l'effort de rédaction, très inspirant.

        • [^] # Re: bloat

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

          D'excellents journaux d'ailleurs !

          Merci :-)

          Merci pour l'effort de rédaction

          Heu… de rien vu qu'il n'y avait pas de réel effort sur la rédaction…

    • [^] # Re: bloat

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

      Et encore, t'as pas parlé des bibliothèques comme jQuery et consort qui proposent leur propre syntaxe pour toutes les actions de base, et où tu te retrouves avec du code entièrement saucissonné à ladite bibliothèque. Ladite bibliothèque a périmé en 3 ans ? Amuse-toi à réécrire le code pour le saucissonner à autre chose !

      Exemple ? Pour un problème donné, des solutions en pur css, et des solutions avec du jQuery. C'est pas forcément le meilleur exemple, mais plusieurs fois j'ai cherché une solution à des problèmes et je devais ajouter -"with jQuery" à ma recherche pour éviter toutes les réponses "fais-le donc en jQuery" (même quand c'est juste une question d'utilisation de css, donc aucun javascript nécessaire).

      Et la compatibilité Internet Explorer. J'utilise au boulot Selectivizr pour que IE8 gère le sélecteur :nth-child, qui permet de colorer une ligne sur deux d'un tableau. Selectivizr a besoin d'une bibliothèque genre jQuery et consorts, sauf que certaines sont mortes et plus compatibles donc tu embarques jQuery, au revoir la lib concurrente du projet qui utilise une syntaxe très proche et qui crée des collusions (les $("body").kekchose() par exemple).

      Mais, Selectivizr ne fait rien si on modifie dynamiquement le contenu de la page ! La solution ? Utiliser IE9.js, dont l'extension pour gérer ce cas ne marche plus, au lieu de Selectivizr Utiliser un fork en version beta de Selectivizr. Merci IE8 !

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: bloat

      Posté par . Évalué à 6.

      comme même

      Rah ! Je t'aurais bien pertiné mais je hais c'te foutue faute ! ^

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

      • [^] # Re: bloat

        Posté par . Évalué à 9.

        atta ça arrive à tout le monde :( jore toi tu fais jamais de faute..
        Je saurais toi je critiquerai pas aussi vite !

        • [^] # Re: bloat

          Posté par . Évalué à 9.

          J'en fais pleins. Mais j'ai un problème avec celle là parce que je vois pas comment les gens prononcent « quand même » pour arriver à l'écrire « comme même » (note que j'ai aussi relativement peur de la lire trop souvent et de me mettre à la faire…).

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

    • [^] # Commentaire supprimé

      Posté par . Évalué à 4. Dernière modification le 26/02/14 à 15:08.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: bloat

        Posté par . Évalué à 9.

        Le web. est un gros foutoir, je te l'accorde. Mais les outils fournissent un solution correcte (probablement une des meilleurs actuellement) pour démêler ce merdier sans nom.

        T'es sérieux ? Parce que quand je vois la dépêche sur Brackets et tous les liens et la discussion qui s'en suit. J'ai pas l'impression que les outils soient corrects. Ils existent mais ça ne va pas plus loin. Il y a une époque où les développeurs web se targuaient d'avoir le meilleur workflow : ils écrivent d'un coté, font un F5 de l'autre et voient le résultat. Aujourd'hui ils lancent une phase de build plus complexe que pour un projet en C/C++ (ils lancent au moins un compilateur par langages et en utilisent au moins 3), envoient tout sur une machine virtuelle et relancent le tout. J'ai pas l'impression que ce soit génial.

        Chaque techno est peut être génial, mais l'ensemble donne la nausée.

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

        • [^] # Commentaire supprimé

          Posté par . Évalué à 1. Dernière modification le 26/02/14 à 15:37.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: bloat

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

            Ce sont les 158 656 pages de recommandations du w3 [...]
            

            Oh pinaise ! Çà fait quand même plus de 6000 lignes en une 1/2 heure ça.
            Je savais pas qu'ils avançaient si vite ! ;)

          • [^] # Re: bloat

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

            Ce sont les 158 656 pages de recommandations du w3 qui donnent la nausée.

            Non, ce sont les 456 895 266 implémentations foireuses de celles-ci qui font chier. C'est aussi pour ça qu'on utilise des frameworks (comme jquery) pour ne pas avoir à nous palucher les subtilités à la main.

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: bloat

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

          envoient tout sur une machine virtuelle et relancent le tout

          Oué enfin on a quand même inventé le live reload. Tu modifie le code dans ton éditeur préféré (donc emacs évidemment) et hop ton serveur est à jour et hop ton navigateur vient de se rafraichir tout seul comme un grand sans que tu fasses rien. Et même hop, ta suite de test unitaire s'est rechargée.

      • [^] # Re: bloat

        Posté par . Évalué à 9.

        Je rebondis sur la facilité de déploiement à la nodejs fichier : vous appelez ça un "déploiement" ?
        Quid du compte sous lequel ça tourne ? et les logs ? et l'arrêt du process ? et le lancement au boot de la machine ?
        Bref on est loin d'une solution finie.
        C'est marrant, je retrouve un peu les mêmes travers avec mes collègues javaneux, pour eux il suffit de lancer ´java package.jar´, le reste "c'est du détail" - le genre de détails qui fait qu'en prod, c'est un bordel innommable…

        • [^] # Commentaire supprimé

          Posté par . Évalué à 0. Dernière modification le 26/02/14 à 16:01.

          Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: bloat

          Posté par . Évalué à 1.

          C'est marrant, je retrouve un peu les mêmes travers avec mes collègues javaneux, pour eux il suffit de lancer ´java package.jar´, le reste "c'est du détail" - le genre de détails qui fait qu'en prod, c'est un bordel innommable…

          En principe il y a tout de même pas mal d'outillage avec Java EE. Les logs ont leur propre fichier de configuration et le serveur d'application est traité indépendamment de l'application.

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

        • [^] # Re: bloat

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

          je retrouve un peu les mêmes travers avec mes collègues javaneux, pour eux il suffit de lancer ´java package.jar´, le reste "c'est du détail"

          Ben oui, il y a des serveurs d'application pour ça.

          http://devnewton.bci.im

  • # plop

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

    S’ensuit alors une discussion sur la merditude de PHP qui ne peut mener nul part

    Faut dire aussi que ces derniers temps la réaction au troll est de plus en plus pathétique icitte…

    Disons que je suis curieux et que j’aimerais connaître vos choix sur les briques logicielles que vous affectionnez.
    Et vous, si vous deviez écrire ce Kanboard de zéro, quels seraient vos choix en matière de langage, framework ou architecture en général ?

    Pour ce cas précis j'en sais trop rien. Mais je peux raconter un poil la stack de deux de mes derniers projets (l'un pro, l'autre perso).

    Projet pro :

    Serveur

    • clojure avec compojure (en gros un DSL au dessus de ring) et liberator : parce que c'est un langage fonctionnel, dont la manière de gérer les données est vraiment sympa. Pour réaliser des traitements sur des ensembles, des listes de listes, etc c'est vraiment sympa. Le langage est expressif, concis et c'est d'autant plus agréable au jour le jour. Et ça tourne sur jvm donc le déploiement est plutôt facile (déployé sur heroku dans ce cas précis).
    • leiningen pour gérer les dépendances, le build, les tests, … en clojure
    • postgresql comme base de données parce qu'elle fonctionne vraiment bien, qu'elle est dispo partout ou presque et parce que j'avais l'habitude de travailler avec (par exemple sur des données carto). Ha oui et on peut aller assez loin avec les possibilités de stockage et d'accès à des données json. On utilise korma pour l'accès à la DB depuis clojure.

    Client

    • angularjs pour architecturer le front (qui consomme des services REST fournis par le serveur). Plutôt bien, puissant mais assez complexe et contraignant.
    • sass et compass pour la partie css. Pourquoi lui et pas un autre ? Parce qu'on est plutôt orienté ruby et que c'est un meilleur choix dans ce cas que less qui est en js.
    • bower pour gérer les dépendances js et css
    • grunt pour builder, minifier, …
    • karma, ng-scenario, phantomjs, jasmine pour les tests
    • yeoman pour gérer la stack front
    • node.js pour le serveur frontal et fournir tout cet ensemble

    Je pense que je n'ai pas du oublier grand chose.

    Projet perso (plus petit) : sinatra avec sprockets, sass, haml, bower et simplement jquery pour l'interactivité côté client.

    • [^] # Re: plop

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

      Juste quelques questions, puisque tu utilises sinatra côté perso et qu'apparemment vous êtes "plutôt orienté ruby", pourquoi clojure plutôt que ROR, c'est pas mal aussi pour les services REST. Pour des questions de performance ?

      Comment tu qualifierais la courbe d'apprentissage de clojure ?

      • [^] # Re: plop

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

        puisque tu utilises sinatra côté perso

        Ha oué mais bon, côté perso j'utilise du ruby, du go, beaucoup de js, du coffee, de l'ada, du c++, du java et même parfois du PHP (et oué).

        pourquoi clojure plutôt que ROR, c'est pas mal aussi pour les services REST. Pour des questions de performance ?

        Bon, déjà le choix a été fait juste avant que j'arrive sur ce projet donc voilà.
        Maintenant faut pas tout mélanger entre langage et framework.
        ROR à mon avis c'était presque trop pour le serveur (qui traite des données et publie des services REST). Pas vraiment besoin, vu que le front est sur un autre serveur.
        Après on aurait justement pu prendre du sinatra ou une autre techno ruby. La raison exacte je ne l'ai pas totalement, mais ce qui est certain aujourd'hui c'est que clojure est un bon choix.
        La première chose c'est que les données qu'on traite sont essentiellement des listes de map (pour simplifier un peu). Et les langages fonctionnels (comme lisp et dérivés) sont justement très agréables à utiliser pour ça. Le code reste clair et concis, et vraiment très puissant. Le modèle de donnée est très souple. En gros on n'a pas définit de modèle objet mais juste des règles qui se basent sur des ensembles. Je sais pas si ça peut être clair dit comme ça…
        Côté productivité clojure est vraiment bien (alors que c'était mon premier projet avec cette techno et la première fois que je faisais du fonctionnel)

        En gros pour résumer le choix :

        • fonctionnel ce qui en fait un langage plutôt adapté aux traitements qu'on doit faire
        • modèle de données adapté à notre problématique métier
        • jvm (c'est plutôt sympa et rassurant)

        Comment tu qualifierais la courbe d'apprentissage de clojure ?

        Heu… vu que j'ai tendance à coder dans beaucoup de langages depuis le temps, je reste plutôt à l'aise avec de nouveaux donc je sais pas si ça représente grand chose…
        C'est la première fois que j'utilisais un langage fonctionnel (jamais utilisé de lisp, ocaml ou autre avant). Mais en gros il m'a fallu moins d'une semaine pour passer de "je comprend rien du tout — mais vraiment rien — à ce que je lis" à "je suis capable d'écrire une première feature".
        Pour ça, lecture (partielle) de Clojure Programming et exos sur 4Clojure.
        Ensuite, faut encore compter quelques semaines pour vraiment arriver à rentrer dans les principes du fonctionnel des traitements de listes (genre pour vraiment commencer à se faire plaisir avec map, reduce, etc). Mais c'est vraiment cool :-)

        Dans tous les cas un choix que je ne regrette absolument pas et je conseil vraiment à tous ceux qui n'en ont jamais fait de tenter les langages fonctionnels, ça change ma manière de voir la programmation et au final change ma façon de coder même dans les autres langages.

    • [^] # Re: plop

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

      Cotés client j'ai la même chose car je me suis basé sur Yeoman et AngularJS. J'utilise juste TypeScript en plus car écrire du JavaScript directement, ce n'est pas assez hype.

      Cotés serveur, j'ai plusieurs prototypes en C#, Node.Js ou Java et j'hésite encore sur lequel partir.

  • # python et django?

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

    Quand j'ai besoin d'une petite application web facile à installer et à maintenir, je prends les versions de python, django et sqlite présents dans debian stable pour les raisons suivantes:

    • facile à installer derrière mon serveur web (cherokee): un coup fastcgi et c'est parti.
    • facile à maintenir: le cadriciel force l'utilisation d'une structure MVC. Il y a un module pour gérer les migrations et les évolutions de la base.
    • l'interface "administration" est générée, ça tombe bien c'est souvent la plus longue et la moins intéressante à faire.

    Ce n'est pas aussi bien qu'une vraie stack JEE service oriented avec du nosql highly scalable, mais au moins ça tient dans les quelques centaines de mégaoctets de RAM de mon serveur.

    http://devnewton.bci.im

    • [^] # Re: python et django?

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

      J'approuve. Django, c'est la vie.

      • [^] # Re: python et django?

        Posté par . Évalué à -2.

        Ben moi, non je n'approuve pas.

        Python, c'est un peu le Visual Basic du Libre : un langage fait pour les gens qui "ne sont pas développeurs", qui leur permet de faire des trucs vite fait en console et les copier/coller dans un script, en donnant l'impression que c'est bien programmé parce que le code est bien indenté. Au final on obtient du code inélégant et inefficace. Enfin, ce qui me gène dans Python, c'est que certains le présentent comme tout objet. Mais est-il possible de faire la même chose que ci-dessous avec les types natifs ?

        irb(main):006:0> 1.class()
        => Fixnum
        
        • [^] # Re: python et django?

          Posté par . Évalué à 0.

          Je me réponds à moi-même pour la dernière partie : on utilise la méthoe class qui fonctionne bizarrement :

          >>> "a".__class__
          <type 'str'>
          >>> 1.__class__
            File "<stdin>", line 1
              1.__class__
                        ^
          
          • [^] # Re: python et django?

            Posté par . Évalué à 2.

            Parce que syntaxiquement nombre + "." indique que l’utilisateur veut écrire un nombre à virgules et s’attend à un nombre après.

            (1).__class__ marche très bien.

            • [^] # Re: python et django?

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

              Et tu peux même utiliser la fonction qui va bien :

              >>> type("a")
              <type 'str'>
              >>> type(1)
              <type 'int'>
              >>> type(type(1))
              <type 'type'>
              

              Matthieu Gautier|irc:starmad

              • [^] # Re: python et django?

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

                Oui mais là c’est plus de l’objet, la fonction type n’est pas une méthode de la classe de l’objet (1).

                ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: python et django?

                Posté par . Évalué à 1.

                Hein ? Pour demander à un objet de retourner son type, il faut demander à une fonction extérieure ? C'est ce manque de cohérence que je reproche à Python (mais il m'a été démontré hereusement que l'objet lui-même est capabble de retourner son type).

                • [^] # Re: python et django?

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

                  Enfin, là tu te contredis toi-même.

                  Il ne faut pas appeler une fonction pour demander son type à un objet. Il suffit de regarder son attribut __class__

                  Cette logique d'avoir des attributs particulier (en "double underscore" nom "double underscore") et des fonctions pour simplifier les appel est classique en python:

                  • __str__(self) pour str(obj)
                  • __repr__(self) pour repr(obj)
                  • __abs__(self) pour abs(obj)
                  • __doc__ pour help(obj)
                  • __nonzero__ pour bool(obj) (en python3 c'est __bool__)
                  • __getattr__(self, name) et __getattribute__(self, name) pour getattr(obj, name) ou obj.name
                  • __add__(self, other) pour obj+other

                  À part l'incohérence de nom entre class et type(), je trouve au contraire que le fonctionnement est très cohérent avec le reste de python.

                  Matthieu Gautier|irc:starmad

                  • [^] # Re: python et django?

                    Posté par . Évalué à 3.

                    Là on s'éloigne un peu du sujet initial quelque part (et je me suis laissé avoir) : pour ma part j'ai pris l'exemple de (1).__class__ comme j'aurais pu prendre autre chose : ma question initiale était de savoir si les types de base sont des objets et j'ai eu ma réponse. Et justement, c'est le fait d'utiliser type() qui m'a induit en erreur et qui m'a mis le doute. Et c'est là que je croyais voir une incohérence (qui n'existe pas) avec le paradigme objet : ne pas pouvoir demander à un objet son type et devoir passer par une autre fonction. Vous m'avez montré que c'est possible donc je n'ai plus rien à ajouter. Au passage, si on prend Ruby (encore), lorsqu'on veut par exemple convertir un tableau en chaine, on utilise la méthode to_s de l'objet. Peut-on faire la même chose en Python ou doit-on utiliser une fonction à qui on passera en paramètre une instance d'objet (comme type()) ?

                    • [^] # Re: python et django?

                      Posté par . Évalué à 2.

                      Classiquement on va faire str(tableau), mais on peut aussi faire tableau.__str__().
                      En pratique la fonction str() se contente d'appeler la fonction str() de l'objet fourni en paramètre.
                      Même chose qu'avec type(…) et (…).__class__, il y a les deux possibilités.

                      Yth.

                    • [^] # Re: python et django?

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

                      C'est toujours le reproche numéro 1 que font les ruby-istes à Python: en python on écrit souvent len(toto), type(toto), unicode(toto), etc et ça choque les ruby-istes (et les smalltalk-istes) qui estiment qu'un langage n'est pas objet si on peut pas faire toto.len(), toto.type(), toto.as_unicode().

                      Le choix a été fait il y au longtemps par Guido, avec l'argument suivant: il estimait que la forme Python était plus lisible et plus facile à comprendre. Cet argument peut faire débat, perso, ça me passe au dessus. En langage courant en dit "je veux la longeur de toto" et "I want the length of toto", ce qui se calque bien sur le choix fait par Guido.

                      Ce qui me gène par contre, c'est l'argument que à cause de ce choix de syntaxe, Python ne serait pas un langage objet. Où est-il dit que si on applique une fonction à un objet, un langage n'est plus objet ? Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

                      Est-ce que interdire la fonction main() comme le fait java en fait un langage plus objet qu'un langage où on appelle une fonction main() ?

                      • [^] # Re: python et django?

                        Posté par (page perso) . Évalué à 1. Dernière modification le 27/02/14 à 11:36.

                        Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

                        J'imagine que le C++ doit être considéré comme encore moins un langage entièrement objet que Python, vu que les types de base (int, float, par exemple) ne sont pas des objets.

                        À moins en fait que Python ne soit « moins objet » que le C++ parce qu'il n'y a pas de possibilité de définir des attributs privés ou protégés, et que donc c'est pas de la vraie encapsulation et pas du vrai objet.

                        En fait je suis pas sûre qu'il y ait une définition unique qui fasse qu'un langage est « plus objet » qu'un autre (par exemple : est-ce que c'est plus «pur objet» d'inclure le maximum de fonctionnalités liées à la programmation objet, ou de décourager l'utilisation d'un autre style de programmation?). Cela dit je suis d'accord que pour moi le fait de pouvoir appliquer une fonction à un objet, plutôt que d'appeler directement la méthode de la fonction, c'est pas spécialement « non objet ». En l'occurrence je reprocherais plutôt un problème de cohérence, qui fait que quand tu connais pas bien et que tu te rappelles juste que pour avoir ce que tu veux c'est «plop», tu sais pas trop s'il faut plutôt faire plop(x) ou x.plop(). (Surtout si comme moi, dès que tu passes d'un langage à un autre t'as déjà du mal à te rappeler s'il faut faire len, length, ou size dans celui-là)

                        • [^] # Re: python et django?

                          Posté par . Évalué à 3.

                          T'inquiète avec python tu peut faire ça :

                          x.plop=plop
                          x.plop()

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

                        • [^] # Re: python et django?

                          Posté par . Évalué à 1.

                          En l'occurrence je reprocherais plutôt un problème de cohérence

                          C'est bien ça qui me gène avec Python : une incohérence que l'obn retrouve sur plein de choses qui paraissent des détails, mais qui, mis bout à bout, rendent le développement un peu pénible.

                        • [^] # Re: python et django?

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

                          Y'a quand même pas une multitude de fonctions builtins dans ce genre. La principale est len(), que tout développeur Python apprend à utiliser avec tout type conteneur / collection sans justement se poser la question de savoir s'il faut appeler un x.size() ou x.getsize() ou x.len() ou x.getlen() ou x.length() ou autre chose encore (je maudit Java pour son incohérence sur les noms de méthodes permettant de connaître le nombre d'éléments).

                          Après, les fonctions génériques sur les séquences comme max(), min(), sum(), enumerate(), sorted(), reversed() permettent de bénéficier de leurs algorithmes avec tout type de séquence.

                          Pour le reste, ça passe par des méthodes.

                          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                      • [^] # Re: python et django?

                        Posté par . Évalué à 1.

                        Le choix a été fait il y au longtemps par Guido, avec l'argument suivant: il estimait que la forme Python était plus lisible et plus facile à comprendre

                        Elle n'est pas logique par rapport à la logique "objet".

                        Ce qui me gène par contre, c'est l'argument que à cause de ce choix de syntaxe, Python ne serait pas un langage objet.

                        Ce n'est pas ce que j'ai dit. D'ailleurs j'ai posé la question avant d'affirmer. Je dis simplement que ce n'est pas cohérent avec la logique "objet".

                        Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

                        Le C++ n'est pas un langage objet. Les types de base ne sont pas des objets. De mémoire tu ne peux pas dériver ton propre type à partir d'un int, ni surcharger une méthode de int, dans la mesure ou int n'est pas un objet.

                        Est-ce que interdire la fonction main() comme le fait java en fait un langage plus objet qu'un langage où on appelle une fonction main() ?

                        Java n'est pas plus objet que C++ pour les mêmes raison. aucun rapport avec main.

                        • [^] # Re: python et django?

                          Posté par . Évalué à 2.

                          Tiens moi aussi je peux le faire. Ruby n'est pas objet parce qu'il ne permet pas de définir des types abstrait ni de faire de la programmation par contrat. De plus les langages dynamiques sont par définition non objet car le comportement des objets n'est pas lié à celui défini dans la classe.

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

                        • [^] # Re: python et django?

                          Posté par . Évalué à 2.

                          C'est du grand n'importe quoi…
                          BASIC n'est pas objet.
                          le C n'est pas objet, ce qui n'empêche pas de programmer avec des objets d'ailleurs.

                          Mais dire que C++, Java, Python, Ruby ne sont pas des langages objets, excuse-moi du peu, mais faut vraiment être sérieusement à côté de la plaque…

                          Tout ça parce qu'il existe des raccourcis de code pour écrire str(objet) en plus de objet.__str__() (ce qui revient strictement au même en interne, un peu comme une sorte de lien symbolique de fonction) Python n'est pas objet ?
                          Quelle absurdité, on aura vraiment tout lu…

                          Yth.

                          • [^] # Re: python et django?

                            Posté par . Évalué à -1.

                            Mais dire que C++, Java, Python, Ruby ne sont pas des langages objets, excuse-moi du peu, mais faut vraiment être sérieusement à côté de la plaque…

                            Non, pas vraiment. Un langage comme smalltalk, ou tout est objet, est un langage objet.

                            C++, Java, et même Perl ou python ne sont pas des langages objet, justement parce que tout n'est pas objet.

                            • [^] # Re: python et django?

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

                              Mais tout est objet en python. Tout !!!

                              Le nom des variables sont des objets
                              Ton module est un objet.

                              Même la frame courante est un objet:

                              """
                              A module doc
                              """
                              import sys
                              
                              var = "salut"
                              
                              def print_frame_info(frame):
                                  print(type(frame))
                                  print("function name : ", frame.f_code.co_name)
                                  print("namespace :")
                                  for key, val  in frame.f_locals.items():
                                      print(" - %(key)s : %(val)s of type %(type)s "%{'key':key, 'val':val, 'type':type(val)})
                              
                              def function0(arg):
                                  """
                                  A function doc
                                  """
                                  frame = sys._getframe(0)
                                  while frame:
                                      print("---------")
                                      print_frame_info(frame)
                                      frame = frame.f_back
                              
                              
                              def function1():
                                  function0(var)
                              
                              function1()
                              ---------
                              <class 'frame'>
                              function name :  function0
                              namespace :
                               - frame : <frame object at 0x93d2de4> of type <class 'frame'> 
                               - arg : salut of type <class 'str'> 
                              ---------
                              <class 'frame'>
                              function name :  function1
                              namespace :
                              ---------
                              <class 'frame'>
                              function name :  <module>
                              namespace :
                               - function1 : <function function1 at 0xb700822c> of type <class 'function'> 
                               - function0 : <function function0 at 0xb70081ec> of type <class 'function'> 
                               - __builtins__ : <module 'builtins' (built-in)> of type <class 'module'> 
                               - __file__ : python3_object.py of type <class 'str'> 
                               - __package__ : None of type <class 'NoneType'> 
                               - sys : <module 'sys' (built-in)> of type <class 'module'> 
                               - var : salut of type <class 'str'> 
                               - __cached__ : None of type <class 'NoneType'> 
                               - __name__ : __main__ of type <class 'str'> 
                               - print_frame_info : <function print_frame_info at 0xb70081ac> of type <class 'function'> 
                               - __doc__ : 
                              A module doc
                               of type <class 'str'> 
                              
                              

                              Matthieu Gautier|irc:starmad

                              • [^] # Re: python et django?

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

                                Mais tout est objet en python. Tout !!!

                                Pas tout à fait. Là où Smalltalk va plus loin que Python, par exemple, c'est qu'en Python, si je ne dis pas de bêtises, "if" est une construction spéciale, un mot-clé réservé. Alors qu'en Smalltalk ça va être une méthode d'un objet booléen qui va prendre en paramètre un morceau de code qui sera executé par l'objet true mais pas par l'objet false.

                                Du coup il y a effectivement une démarche plus pure dans Smalltalk, puisque des choses qui sont des mots-clés réservés dans la plupart des langages (y compris orientés objet) deviennent des objets ou des méthodes comme les autres. Après c'est des approches différentes : Python fait plutôt le choix du pragmatisme que de la beauté conceptuelle.

                            • [^] # Re: python et django?

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

                              C'est quand même une définition très restrictive de ce qu'est un langage objet. Après ça se tient, si tu définis un langage objet comme ça, y'a plein de langages qui effectivement ne sont pas objet et, bon, OK. Après j'ai l'impression que les définitions les plus courantes ne sont pas aussi restrictives, et qu'il y a une distinction entre «langage objet» et «langage objet pur». Après, on peut trouver que c'est «laxiste» e et que seuls les langages objets purs (donc où tout est objet) méritent l'appellation objet, ça peut se tenir, mais au final je sais pas si c'est un débat très intéressant.

                              • [^] # Re: python et django?

                                Posté par . Évalué à 1.

                                Certains différencient langage objet (ou tout est objet) et langage orienté objet (qui permet d'utiliser le paradigme objet).

                                • [^] # Re: python et django?

                                  Posté par . Évalué à 2.

                                  Le problème c'est que dans l'excès inverse, on peut très bien faire du C pur, mais en programmation orientée objet…
                                  Alors, non-orienté objet c'est quoi ? Basic et assembleur ?

                                  Yth.

                                  • [^] # Re: python et django?

                                    Posté par . Évalué à 3.

                                    On peut faire de l'orienté objet en assembleur aussi, de la même manière qu'en C, même si ça doit être sportif :)

                                    Basic je connais pas assez.

                                    Please do not feed the trolls

                • [^] # Re: python et django?

                  Posté par . Évalué à 2.

                  Les objets doivent nécessairement avoir de la réflexion ?

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

        • [^] # Re: python et django?

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

          Python, c'est un peu le Visual Basic du Libre : un langage fait pour les gens qui "ne sont pas développeurs", qui leur permet de faire des trucs vite fait en console et les copier/coller dans un script, en donnant l'impression que c'est bien programmé parce que le code est bien indenté. Au final on obtient du code inélégant et inefficace.

          Java est la référence du développeur, pourtant j'ai vu des codes sources Java tout bonnement abominables. Et ne parlons pas de PHP. N'oublie pas que les langages ne sont qu'un outil. Si des personnes ne savent pas s'en servir correctement, ce n'est pas la faute du langage.

          Enfin, ce qui me gène dans Python, c'est que certains le présentent comme tout objet. Mais est-il possible de faire la même chose que ci-dessous avec les types natifs ?
          irb(main):006:0> 1.class()
          => Fixnum

          Je ne comprends pas ton code ou 'pseudo-code', donc la seule chose que je te dirais, est que Python n'est pas "full-object". La personne t'affirmant le contraire est un imbécile. Ruby, au contraire, est "full-object".

          • [^] # Re: python et django?

            Posté par . Évalué à 2.

            Je ne comprends pas ton code ou 'pseudo-code', donc la seule chose que je te dirais, est que Python n'est pas "full-object". La personne t'affirmant le contraire est un imbécile. Ruby, au contraire, est "full-object".

            Qu’est-ce que tu endends par "full-object" ?

            Les nombres, les modules, les fonctions, les classes sont des objets en Python.

        • [^] # Re: python et django?

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

          Parce que c'est un langage accessible aux non développeurs qui permet de faire des trucs vite fait en console et les copier-coller dans un script, les VRAIS développeurs ne pourraient pas le trouver adapté pour développer une appli web ?

          Ce n'est pas parce que certaines personnes font du code inélégant et inefficace que je me passerais du Python qui n'est pas défini QUE par l'indentation forcée mais aussi par des conventions pensées pour rendre le code lisible et compréhensible. Tout ce que l'on pourrait reprocher à Python, ce sont les performances… mais pour un Kanboard quoi, c'est amplement suffisant.

          De plus le code inélégant et inefficace n'est pas l'apanage du Python que je sache…

        • [^] # Re: python et django?

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

          Ça ?
           In[1]  type(1)
           Out[1]  int

        • [^] # Re: python et django?

          Posté par . Évalué à 3.

          On repart sur des troll de langages ? Un exemple qui montre l'introspection pyton sur le 1 :

          In [1]: [method for method in dir(1) if callable(getattr(1, method))]
          Out[1]: 
          ['__abs__',
           '__add__',
           '__and__',
           '__class__',
           '__cmp__',
           '__coerce__',
           '__delattr__',
           '__div__',
           '__divmod__',
           '__float__',
           '__floordiv__',
           '__format__',
           '__getattribute__',
           '__getnewargs__',
           '__hash__',
           '__hex__',
           '__index__',
           '__init__',
           '__int__',
           '__invert__',
           '__long__',
           '__lshift__',
           '__mod__',
           '__mul__',
           '__neg__',
           '__new__',
           '__nonzero__',
           '__oct__',
           '__or__',
           '__pos__',
           '__pow__',
           '__radd__',
           '__rand__',
           '__rdiv__',
           '__rdivmod__',
           '__reduce__',
           '__reduce_ex__',
           '__repr__',
           '__rfloordiv__',
           '__rlshift__',
           '__rmod__',
           '__rmul__',
           '__ror__',
           '__rpow__',
           '__rrshift__',
           '__rshift__',
           '__rsub__',
           '__rtruediv__',
           '__rxor__',
           '__setattr__',
           '__sizeof__',
           '__str__',
           '__sub__',
           '__subclasshook__',
           '__truediv__',
           '__trunc__',
           '__xor__',
           'bit_length',
           'conjugate']

          Donc vu le nombre de méthode que « 1 » a je pense que c'est un objet. Python est-il pour autant tout objet ? J'en sais rien. Mais OSEF, non ?

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

          • [^] # Re: python et django?

            Posté par . Évalué à 1.

            Tu mets en évidence un second reproche que je fais à Python.

            En ruby, pour faire la même chose je fais simplement :

            irb(main):002:0> 1.methods()
            => ["%", "odd?", "inspect", "prec_i", "<<", "tap", "div", "&", "clone", ">>", "public_methods", "__send__", "object_id", "instance_variable_defined?", "equal?", "freeze", "to_sym", "*", "ord", "+", "extend", "next", "send", "round", "methods", "prec_f", "-", "even?", "singleton_method_added", "divmod", "hash", "/", "integer?", "downto", "dup", "to_enum", "instance_variables", "|", "eql?", "size", "instance_eval", "truncate", "~", "id", "to_i", "singleton_methods", "modulo", "taint", "zero?", "times", "instance_variable_get", "frozen?", "enum_for", "display", "instance_of?", "", "method", "to_a", "+@", "-@", "quo", "instance_exec", "type", "**", "upto", "to_f", "<", "step", "protected_methods", "<=>", "between?", "==", "remainder", ">", "===", "to_int", "nonzero?", "pred", "instance_variable_set", "coerce", "respond_to?", "kind_of?", "floor", "succ", ">=", "prec", "to_s", "<=", "fdiv", "class", "private_methods", "=~", "tainted?", "__id__", "abs", "untaint", "nil?", "chr", "id2name", "is_a?", "ceil", "[]"]

            • [^] # Re: python et django?

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

              Tu veux dire que tu ne peux pas créer une classe dont les instances auraient un attribut 'methods' ? Ouch.

              • [^] # Re: python et django?

                Posté par . Évalué à 1.

                Pourquoi faire ?

                • [^] # Re: python et django?

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

                  Je ne sais pas, ça dépend du cas de figure. Par exemple, imaginons qu'on crée un outil de gestion pour les bureaux « Outils et Méthodes » des industries.

                  • [^] # Re: python et django?

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

                    Oui, supprimons tout les mots clefs réservés !!!

                    • [^] # Re: python et django?

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

                      Je crois qu'en effet un langage dans lequel on a pesé le pour et le contre avant d'ajouter un mot clef réservé sera plus ergonomique. Et puis .methods(), ça n'est pas un mot clef, c'est un attribut appelable. Un mot clef ça serait "if".

                      • [^] # Re: python et django?

                        Posté par (page perso) . Évalué à 1. Dernière modification le 27/02/14 à 00:17.

                        Pour moi un mot clef réservé est un mot que l'on ne peut pas utiliser, comme en SQL par exemple. Que ce soit un nom de méthode, une structure de contrôle ou un type ne change pas grand chose.

                        Ça me choque pas d'avoir réservé methods, le nom correspond facilement. Et un __methods__ ou autre serait particulièrement moche pour les deux trois rares cas ou le développeur voudrait écrire une méthode methods.

                        • [^] # Re: python et django?

                          Posté par . Évalué à 2.

                          Celà dit, le fait d'avoir cette convention (utiliser les __ __ pour ce genre de méthode ) n'est pas gênant. C'est une convention du langage comme une autre et qui peut être pratique.

                          • [^] # Re: python et django?

                            Posté par (page perso) . Évalué à 2. Dernière modification le 27/02/14 à 08:51.

                            De plus en Python, habituellement, on écrit régulièrement des attributs nommés selon l'expression régulière __(?<nom>.*)__, pour implémenter un protocole, mais on les utilise peu directement.
                            Par exemple, pour rendre un objet indexable (utilisable avec la notation objet[index]), on lui ajoute une méthode __getitem__ (et éventuellement __setitem__ pour l'affectation), et pour le rendre "appelable" (callable —utilisable avec la notation parenthésée objet(arguments)), on lui adjoint une méthode __call__.

            • [^] # Re: python et django?

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

              Je vois deux gros problèmes :

              • on ne peut pas réutiliser le mot methods
              • ça veut dire que les méthodes sont des choses un peu à part, différentes des autres attributs.

              En Python, ça me semble plus cohérent pour deux raisons :
              * les méthodes sont des attributs au même titre que les autres. Et comme tout en Python, ce sont des objets comme les autres. La différence, c'est qu'ils ont une méthode (ou un attribut) __ call __.
              * toutes les méthodes s'appellent mon_objet.ma_methode. Il n'y a pas d'attributs avec des noms particuliers comme >>, & ou encore [].

          • [^] # Re: python et django?

            Posté par . Évalué à 1.

            J'en sais rien. Mais OSEF, non ?

            Non, c'est une question de logique et de cohérence. Un article récent de GLMF expliquait que le fait par exemple que Java ne soit pas full object a poussé les développeurs à créerr des patterns permettant de pallier ce problème, mais au prix d'une plus grande complexité.

            Par contre on m'a expliqué pourquoi ce que j'ai tenté de faire ne marche pas et ça me parait logique (le fait que l'interprêteur s'attend à avoir un chiffre derrière le 1).

            • [^] # Re: python et django?

              Posté par . Évalué à 1.

              Non, c'est une question de logique et de cohérence. Un article récent de GLMF expliquait que le fait par exemple que Java ne soit pas full object a poussé les développeurs à créerr des patterns permettant de pallier ce problème, mais au prix d'une plus grande complexité.

              Ce grand moment de troll où le gars fait tout un article pour dire que l'orienté objet c'est lent sans autre argument que « si en java ils ont mis des types, c'est parce que sinon ce serait lent » ? Il n'y a qu'ici qu'on peut voir des gens utiliser cet article comme argument :)

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

              • [^] # Re: python et django?

                Posté par . Évalué à 2.

                Quand on trolle on utilise n'importe quelle source qui pourrait sembler appuyer ses "arguments " :).

                Plus sérieusement, ce que je n'aime pas dans Python par rapport à Ruby, c'est le manque de concision dans la façon d'écrire le code: mais ça c'est plus une question de gout qu'un réel problème technique.

                • [^] # Re: python et django?

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

                  As-tu des exemples en particulier ?

                  • [^] # Re: python et django?

                    Posté par . Évalué à 2.

                    La tout de suite ? non pas vraiment car ça fait un moment que je n'ai pas fait de python. Je devrais en refaire bientôt et je nemanquerai pas de relever tout ces points pour en faire un journal du Vendredi …

                • [^] # Re: python et django?

                  Posté par . Évalué à 1.

                  Bigre, pour moi c'est un gros atout de python, la concision justement.

                  Je vais donc me permettre de supposer que tu ne maîtrises pas assez python pour savoir faire du code à la fois performant et concis.
                  Car comme dans tout langage on peut l'écrire de façon verbeuse et non performante.

                  Après je ne connais pas du tout Ruby, c'est peut-être encore plus concis, mais si c'est le cas j'ai du mal à imaginer comment ça pourrait ne pas se faire au détriment de la clarté.
                  C'est comme Perl, je suis allergique (juste moi, hein, je respecte ceux qui aiment Perl), je trouve que quand c'est très concis c'est surtout très illisible.

                  Yth.

                  • [^] # Re: python et django?

                    Posté par . Évalué à 2.

                    Après je ne connais pas du tout Ruby, c'est peut-être encore plus concis, mais si c'est le cas j'ai du mal à imaginer comment ça pourrait ne pas se faire au détriment de la clarté.

                    C'est comme n'importe quel langage: ce n'est pas clair quand tu ne connais pas le langage, mais ça le devient quand tu es un peu rodé à celui-ci. Par contre, à la différence de Perl, tu arrives à relire ton propre code 6 mois après l'avoir écrit.

                    Comme je l'ai dit, je vais refaire bientôt du Python. Je pourrai donc troller argumenter de façon plus précise sur les points qui me gènent dans ce langage.

                • [^] # Re: python et django?

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

                  Finalement, les goûts et les couleurs… c'est le truc qui m'a fait ne pas trop apprécier Ruby, son côté super concis qui (parfois) nuit à la relecture - sauf erreur on peut appeler une méthode sans les parenthèses (*).
                  Mais je comprends qu'on puisse lui trouver une élégance dans sa façon d'exprimer beaucoup en peu d'instructions.

                  Ah, l'autre truc qui pour moi est définitivement éliminatoire, c'est les chaînes mutables par défaut.

                  (*) Beuark pour moi - en Python x.méthode est une référence vers la méthode liée à x, et x.méthode() un appel à cette méthode. Et si méthode est un objet utilisateur, un appel à la méthode __call__() de cet objet, soit x.méthode.__call().

                  Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                  • [^] # Re: python et django?

                    Posté par . Évalué à 2.

                    Personnellement, si on parle de variable, je trouve que tout langage devrait avoir des variables à affectation unique.

        • [^] # Re: python et django?

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

          Python, c'est un peu le Visual Basic du Libre

          J'aimerais bien un langage plus puissant (surtout typé en fait), mais dans cette catégorie (connu, peu consommateur de ram, avec un super cadriciel web productif…), il n'y a pas grand monde.

          http://devnewton.bci.im

          • [^] # Re: python et django?

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

            J'aimerais bien un langage plus puissant (surtout typé en fait), mais dans cette catégorie (connu, peu consommateur de ram, avec un super cadriciel web productif…), il n'y a pas grand monde.

            PHP ? :-P

          • [^] # Re: python et django?

            Posté par . Évalué à 3.

            Python est typé.

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

            • [^] # Commentaire supprimé

              Posté par . Évalué à 4.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: python et django?

                Posté par . Évalué à 4.

                Hum, je suis pas très calé en ruby, mais le typage doit se ressembler dans les deux, c'est un typage dynamique et fort.
                Qu'est ce qui te fait dire que l'un est plus fortement typé que l'autre ?

                Si on veut jouer :

                irb(main):038:0> p=1
                => 1
                irb(main):039:0> p.class
                => Fixnum
                irb(main):040:0> while p.class == 1.class
                irb(main):041:1> p*=1000
                irb(main):042:1> end
                => nil
                irb(main):043:0> p.class
                => Bignum

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

                • [^] # Re: python et django?

                  Posté par . Évalué à 4.

                  Envlève ton masque, Super Premier Degré Man, on t'a reconnu!

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 3.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: python et django?

                    Posté par . Évalué à 3.

                    Faut pas me faire des coups pareil ! Moi je suis nul^Wnil en contrepèterie.

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

            • [^] # Re: python et django?

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

              Bien typé!

              http://devnewton.bci.im

              • [^] # Re: python et django?

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

                Qu'est-ce qu'on "bon" typage dans ce cas ? Un typage statique ?

                • [^] # Re: python et django?

                  Posté par . Évalué à 3.

                  Un mauvais typage, il voit une variable…

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

                • [^] # Re: python et django?

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

                  Oui, avec le maximum de vérifications et d'avertissements à la compilation.

                  http://devnewton.bci.im

                  • [^] # Re: python et django?

                    Posté par . Évalué à 1.

                    Tout dépend des objectifs : Erlang n'a pas de typage statique tout simplement parce que l'un de ses objectifs est de pouvoir remplacer le code à chaud, et avec un typage statique, ce serait impossible. C'est ce que j'avais lu sur le sujet, et l'explication m'a paru logique (j'essaierai de retrouver le papier - très intéressant - sur ce sujet).

                • [^] # Re: python et django?

                  Posté par . Évalué à 3.

                  La différence entre un bon typage et un mauvais typage c'est la taille du caca quand il y a un bug.

                  Pour un programme :

                  • Parfaitement typé, ça s'appelle une preuve, toute erreur est détecté à la compilation, aucune erreur n'est possible à l’exécution.
                  • Statiquement et fortement typé, typiquement Caml, Haskell, Ada, Java (encore qu'il est moche celui là). Beaucoup d'erreurs de type sont détecté par le compilo, et beaucoup (voir toutes) sont détectés au runtime.
                  • Statiquement et faiblement typé, genre C, beaucoup d'erreur détecté à la compilation, très peu à l’exécution.
                  • Dynamiquement et fortement typé, python, erlang : rien n'est fait en statique, et aucune erreur ne passe à l’exécution.
                  • Dynamiquement et faiblement typé, php, assembleur, la fête du slip à tout les étages.

                  Ce qui est bon ? Une preuve c'est très long à écrire, les langages dynamiquement typés sont plus chiants à déboguer. Les langages qui testent des tas de choses à l’exécution sont plus lent que ceux qui ne le font pas. Ça dépend de ce qu'on veut ! Sachant que des langages comme Haskell ou Caml peuvent déduire les types tout seuls automatiquement.

                  Please do not feed the trolls

                  • [^] # Re: python et django?

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

                    Parfaitement typé, ça s'appelle une preuve, toute erreur est détecté à la compilation, aucune erreur n'est possible à l’exécution.

                    Heu, aucune erreur possible à l'exécution… et toute erreur détectée à la compilation, c'est peut-être valable dans un contexte limité où les entrées/sorties et les ressources dispos sont très contrôlés, et les algos mathématiquement construits. Mais pour les 99,99% autres programmes, j'ai comme un doute.

                    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                    • [^] # Re: python et django?

                      Posté par . Évalué à 3.

                      Si si. Par pas d'erreur possible, ça veut dire que le code ne fait pas d'erreur.

                      • les entrées/sorties les cas d'erreur sont tous gérés car le compilateur te force à tous les gérer
                      • les problèmes de matériel ne sont pas du ressort du logiciel, si un gars débranche la machine il n'y a rien à faire

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

                      • [^] # Re: python et django?

                        Posté par . Évalué à 1.

                        Le code qui ne fait pas d'erreur ça veut juste dire que le programme ne va pas planter, ça ne veut pas dire pour autant qu'il n'aura pas de bugs…

              • [^] # Re: python et django?

                Posté par . Évalué à 2.

                Sale type !!!

  • # Juste pour alimenter le troll ...

    Posté par . Évalué à 4.

    Côté serveur, je mettrais Erlang, avec mnesia en database entre autres choses parce qu'il permet les mises à jour à chaud, et parce que le concept même du langage (pas de programmation défensive) permet d'économiser des lignes de codes plus ou moins redondantes (par contre j'avoue que la syntaxe est parfois un peu lourde).

    Je développerais une api REST pour laisser la possibilité aux personnes qui n'aimeraient pas mon client de développer le leur et éventuellement sous-traiter cet aspect à des développeurs plus compétents que moi dans ce domaine.

    Côté client je ne sais pas : je ne connais pas trop les solutions. Probablement quelque chose à base de HTML5/Javascript. Par contre quel est l'intéret de passer par des frameworks style jquery et compagnie pour développer un client relativement simple? D'autre part, si on se limite à HTML5, est-ce réellement utile d'ajouter des couches telles que JQuery par exemple ? C'est une vraie question car je devrai y passer pour mes 2-3 projets lorsque j'aurai avancé suffisamment sur la partie serveur (je traine un peu des pieds pour m'y mettre d'ailleurs parce que c'est un peu la jungle de ce côté).

    • [^] # Re: Juste pour alimenter le troll ...

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

      D'autre part, si on se limite à HTML5, est-ce réellement utile d'ajouter des couches telles que JQuery par exemple ?

      T'as pas toujours l'envie ou le temps de réinventer la roue, et ces frameworks te proposent une belle palanquée de plugins, je te donne 2 exemples :

      • Un datepicker : En HTML5, tu as l'input type="date", mais ça fonctionne pas sur tous les navigateurs, c'est impossible à skinner pour coller au style de ton interface, tu peux pas limiter le choix des dates (à ma connaissance)
      • Un champ autocomplete : En HTML5, tu as l'input list avec le datalist associé, encore une fois ça fonctionne pas sur tous les navigateurs ou les implémentations sont buggées, ça réagit pas comme tu le souhaiterais avec la surimpression des caractères tapés …
      • [^] # Re: Juste pour alimenter le troll ...

        Posté par . Évalué à 3.

        Merci pour ce retour.

        T'as pas toujours l'envie ou le temps de réinventer la roue, et ces frameworks te proposent une belle palanquée de plugins

        Donc à mettre en balance le temps passé sur l'apprentissage et la prise en main du framework par rapport aux besoins et au temps passé à "réinventer la roue". Mais existe-t-il un moyen relativement simple de faire cette évaluation ? Autrment dit, si je reprends l'exemple d'un datepicker, est-ce que ça vaut le coup pour un champ date sur une page de l'ensemble du site ?

        • [^] # Re: Juste pour alimenter le troll ...

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

          si je reprends l'exemple d'un datepicker, est-ce que ça vaut le coup pour un champ date sur une page de l'ensemble du site ?

          Non, ça vaut carrément pas le coup si c'est juste pour ça. Tout dépend de l'importance de ce champ date, s'il est souvent modifié, etc …
          Mais sur un site de voyage ou d'une compagnie aérienne par exemple, le champ date, c'est vraiment le truc qui faut éviter de foirer ou espérer que tous les utilisateurs auront le dernier navigateur mis à jour, ou entreront la date au bon format. Sur ce genre de site, faut prévoir les cas ou javascript est désactivé côté navigateur aussi, mais c'est une minorité.

          Donc à mettre en balance le temps passé sur l'apprentissage et la prise en main du framework par rapport aux besoins et au temps passé à "réinventer la roue".

          Oui, faut peser le pour et le contre. Tout dépend des besoins, et si c'est pas nécessaire, ça ne fait que rajouter de la lourdeur pour pas grand chose …
          Si tu sais que tu vas avoir besoin d'un datepicker, de champs autocomplete ou dropdown aux petits oignons, d'un slider, de gestions de tabs, de fenêtres modales, de tooltips, d'une librairie de graph pour balancer des charts ou que sais je encore … Ça commence à faire pas mal de truc à réinventer et oui la solution de facilité c'est de balancer un framework (jquery, dojo, mootools, …)

          Mais bon, souvent y'a pas de courbe d'apprentissage du tout si tu veux juste balancer un plugin … C'est aussi pour ça que c'est souvent décrié, parce que utilisé à tort. Tu peux parfois voir plusieurs frameworks inclus uniquement pour un plugin fonctionnant avec tel ou tel !

          • [^] # Re: Juste pour alimenter le troll ...

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

            Sur ce genre de site, faut prévoir les cas ou javascript est désactivé côté navigateur aussi, mais c'est une minorité.

            Je suis d'accord, une minorité de sites prévoie le cas où javascript est désactivé coté navigateur.

            Matthieu Gautier|irc:starmad

  • # C'est beau, le web...

    Posté par . Évalué à 1.

    … toutes ces "technologies" empilées les unes sur les autres.

    Le travail de développeur web, tu ne fais qu'empiler des briques et essayer qu'elles tombent pas, ou tu écris quand même un peu de code ? :)

    • [^] # Re: C'est beau, le web...

      Posté par . Évalué à 5. Dernière modification le 26/02/14 à 17:15.

      Je ne vois pas en quoi c’est spécifique au web. Au pif :

      $ ldd =claws-mail | wc -l
      85
      

      Je préfère ça à la situation où chacun réinvente la roue (carrée) de son côté.

  • # Un troll juste pour moi :)

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

    J'ai vraiment de la chance d'avoir un troll en mon honneur :)

    Le truc qu'il faut voir aussi c'est que j'essaie de réduire au maximum les dépendances externes, non seulement cela simplifie l'installation mais aussi la maintenance sur le long terme.

    Exemple :

    Je n'utilise pas jQuery pour ne pas me retrouver dans 3 ans avec un truc du style "le plugin X marche uniquement avec la version Y de jQuery donc on upgrade pas jQuery mais il y a une faille de sécurité dans la version Y", conséquence : dès le départ je supporte uniquement certains navigateurs web modernes ce qui fait que je peux utiliser du "vanilla javascript" qui utilise les API standards et normalisées.

    Certes, il ne faut pas réinventer la roue non plus mais faire des choix.

    Utiliser les dernières technologies ou projets à la mode c'est bien pour s'amuser ou quand on travail pour une startup kikoo lol 2.0 qui va vivre 6 mois. Mais dans la vrai vie, on doit faire des choix on fonction du contexte/contraintes.

    Dans ma vie professionnelle je passe mes journées à faire du Golang, du Python, du PHP et des shell-scripts.

    • J'utilise Go pour une plateforme qui doit gérer 1 milliard de requêtes HTTP par jour avec des milliers de connections concurrentes, le tout sur un nombre raisonnable de serveurs. Golang fait parfaitement la job et tourne sans problème.
    • J'utilise Python pour générer des rapports ou des stats.
    • J'utilise PHP pour faire des interfaces de management, des dashboards, des outils web internes.

    La difficulté est peut-être de choisir le bon outil pour faire la job demandée. Et surtout de penser à la maintenance sur le long terme, tests unitaires/fonctionnels, dette technique, etc… on en revient au même, tout dépend du contexte et de l'objectif à atteindre.

    Sur ce, je vous laisse troller :)

    • [^] # Re: Un troll juste pour moi :)

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

      J'ai vraiment de la chance d'avoir un troll en mon honneur :)
      Sur ce, je vous laisse troller :)

      Ben, c'était pas le but, mais c'est bien foiré quand même.

      Utiliser les dernières technologies ou projets à la mode c'est bien pour s'amuser ou quand on travail pour une startup kikoo lol 2.0 qui va vivre 6 mois.

      Je sais pas si tu parles de l'exemple que j'ai donné mais on est loin du kikoo lol. C'est toi qui troll pour le coup.

      Mais dans la vrai vie, on doit faire des choix on fonction du contexte/contraintes.

      C'est ce que je proposais, de faire part des choix que certains effectuent …

      J'utilise Go pour une plateforme qui doit gérer 1 milliard de requêtes HTTP par jour avec des milliers de connections concurrentes, le tout sur un nombre raisonnable de serveurs.

      Et t'as pas envie d'en parler ? T'utilises Revel, Gorilla, c'est interfacé avec une DB et un ORM, avec un reverse proxy ou en direct.

      J'utilise PHP pour faire des interfaces de management, des dashboards, des outils web internes.

      Du raw PHP ou avec Laravel, symphony, CI.

      • [^] # Re: Un troll juste pour moi :)

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

        Et t'as pas envie d'en parler ? T'utilises Revel, Gorilla, c'est interfacé avec une DB et un ORM, avec un reverse proxy ou en direct.

        Ce projet en Go n'est pas une application web mais un "service" parmi d'autres (architecture SOA). On utilise aucun framework ou ORM et ça reçoit le trafic directement derrière un load-balancer cisco qui coûte les yeux de la tête.

        Il y a énormément de business logic à l'intérieur de ce service, en fait pour être plus précis c'est un Ad-Network avec un système de real-time bidding auction, ça fait à la fois du CPC et du CPM.

        Avec ce genre de trafic, ton principal bottleneck va être les I/O sur le network et le disque. Si tu veux avoir un nombre raisonnable de serveurs, tu ne peux donc pas aller lire/écrire directement dans une base de données et ce même en utilisant un pool de connexions car celui-ci va être atteints en quelques secondes et ainsi ralentir les autres goroutines qui attendent d'avoir une connection disponible. Sans pool, tu va très vite arriver à limite du nombre maximum de file descriptors même si tu personnalise cette valeur… bref je passe les détails…

        La solution que l'on a adoptée est de tout faire en mémoire et d'avoir un démon le plus indépendant possible. Le service récupère ou reçoit les données qui vont bien à interval régulier. Une fois que tu a tweaker ton kernel aux petits oignons pour gérer autant de connexions TCP, ça roule comme sur des roulettes.

        Pour info, l'ancien système tournait avec 30 serveurs PHP avec du hardware bien costaud et un cluster memcached, la plateforme ne scalait plus, en période de pointe le load average de certains serveur montaient à plus de 100 et le response time côté client pouvait dépasser la seconde. Le même système fonctionne aujourd'hui sur seulement 10 serveurs et la load est même pas à 1 ou 2 avec un response time de 4ms à 100ms, tout ça parce que l'on a éliminé un par un chacun des bottlenecks, surtout le fait de tout faire en mémoire on a plus de problème de IO. A la fin, on se retrouve avec une architecture vraiment simple car on a plus de cluster memcached/redis/mysql mais un simple démon sans dépendances.

        On aurait pu faire la même chose en Java ou C++, mais en sachant que Go à été conçu exactement pour ce genre de problématique…

        • [^] # Re: Un troll juste pour moi :)

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

          Excuses ma grande naïveté mais à chaque fois que je vois "on gère tout en RAM", je ne comprends pas. Comment tu fais si on tu as un crash de ton serveur ? Tu as bien une notion de persistance hors-RAM quelque part ?

          • [^] # Re: Un troll juste pour moi :)

            Posté par . Évalué à 2.

            Il dit qu'il a 10 machines qui font tourner la chose, ça signifie qu'il y a communication de RAM entre ces deux machines, je suppose que rien n'empêche une onzième machine dédiée à ça de communiquer avec cette RAM partagée aussi, et de se contenter elle de stocker sur du disque, ou de conserver un état en dur, avec le moins de retard possible, et qui servirait en cas de redémarrage de l'ensemble du système à « kickstarter » les autres machines.

            Bref, je pense que l'idée est que tout tourne en RAM, mais qu'un service extérieur s'assure de conserver l'état.
            Peut-être avec en plus des logs, pour chaque « transaction », le redémarrage se fait à partir du dernier état sauvegardé auquel on applique les logs depuis la coupure.

            Bref il y a des solutions, mais ce qui compte là c'est que l'application tourne avec des données en RAM et pas via un serveur de base de donnée. C'est là qu'on a un gain de temps énorme, et si ça se fait au prix d'une difficulté accrue pour la persistance des données, le jeu peut largement en valoir la chandelle.

            Yth.

          • [^] # Re: Un troll juste pour moi :)

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

            Les données de départ sont bien stockées dans une base de données classique. C'est juste que le service possède les données dénormalisées en mémoire, un maximum de chose est précalculé à l'avance. Si le service crash on s'en fou, le reste du système est conçu pour gérer cela automatiquement sans perte de données…

        • [^] # Re: Un troll juste pour moi :)

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

          C'est intéressant, il y a eu une présentation à la pgcon 2013 sur un cas tout à fait semblable (Ad-Network).
          Ils ont utilisé un reverse proxy devant des instances nodejs et redis avant d'envoyer les données à interval régulier vers PostgreSQL.

Suivre le flux des commentaires

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