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 :
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 zebul0n (site web personnel) . É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 Philippe F (site web personnel) . Évalué à 6.
Pour l'autre produit phare de Fog Creek, FogBugZ, Joel Spolsky a fait un choix inverse.
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 zebul0n (site web personnel) . É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.
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 Sygne (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 2.
Voila…
Car :
Parce que tu n'as pas ces contraintes :
Time to Market
Total Cost of Ownership
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.
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)
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 Sygne (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 2.
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 Sygne (site web personnel) . É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 barmic . Évalué à 6.
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.
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 berumuron . Évalué à 3. Dernière modification le 26 février 2014 à 15:23.
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 barmic . É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 Zenitram (site web personnel) . Évalué à 1. Dernière modification le 26 février 2014 à 15:28.
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.
gni???
On parle technique, rentabilité, la.
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 barmic . Évalué à 2.
Ok j'avais mal compris. Comme tu parle de :
puis de :
Mea culpa, j'avais mal compris.
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.
Ç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.
On parle là de techno qui sont en prod.
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 ?
: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 Axel . É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 :
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 sifu . Évalué à 2.
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 ckiller . É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
quand même :-D
[^] # Re: bloat
Posté par Zenitram (site web personnel) . Évalué à 1.
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 Lizzie Crowdagger (site web personnel) . É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 sifu . É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 CrEv (site web personnel) . Évalué à 8.
Voici (vu que c'est probablement de mes articles dont tu parles ;-)) :
[^] # Re: bloat
Posté par zebul0n (site web personnel) . Évalué à 4.
D'excellents journaux d'ailleurs ! Merci pour l'effort de rédaction, très inspirant.
[^] # Re: bloat
Posté par CrEv (site web personnel) . Évalué à 3.
Merci :-)
Heu… de rien vu qu'il n'y avait pas de réel effort sur la rédaction…
[^] # Re: bloat
Posté par Zarmakuizz (site web personnel) . É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 SelectivizrUtiliser un fork en version beta de Selectivizr. Merci IE8 !Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: bloat
Posté par barmic . Évalué à 6.
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 Axel . É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 barmic . É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 Anonyme . Évalué à 4. Dernière modification le 26 février 2014 à 15:08.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par barmic . Évalué à 9.
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 Anonyme . Évalué à 1. Dernière modification le 26 février 2014 à 15:37.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
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 Infernal Quack (site web personnel) . Évalué à 2.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par CrEv (site web personnel) . Évalué à 3.
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 jigso . É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 Anonyme . Évalué à 0. Dernière modification le 26 février 2014 à 16:01.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bloat
Posté par barmic . Évalué à 1.
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 devnewton 🍺 (site web personnel) . Évalué à 5.
Ben oui, il y a des serveurs d'application pour ça.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# plop
Posté par CrEv (site web personnel) . Évalué à 5.
Faut dire aussi que ces derniers temps la réaction au troll est de plus en plus pathétique icitte…
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
Client
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 zebul0n (site web personnel) . É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 CrEv (site web personnel) . Évalué à 6.
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é).
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 :
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 dave_null (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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:
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: python et django?
Posté par Atem18 (site web personnel) . Évalué à 1.
J'approuve. Django, c'est la vie.
[^] # Re: python et django?
Posté par totof2000 . É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 ?
[^] # Re: python et django?
Posté par totof2000 . Évalué à 0.
Je me réponds à moi-même pour la dernière partie : on utilise la méthoe class qui fonctionne bizarrement :
[^] # Re: python et django?
Posté par Moonz . É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 GaMa (site web personnel) . Évalué à 1.
Et tu peux même utiliser la fonction qui va bien :
Matthieu Gautier|irc:starmad
[^] # Re: python et django?
Posté par Thomas Debesse (site web personnel) . É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 totof2000 . É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 GaMa (site web personnel) . É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:
À 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 totof2000 . É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 Yth (Mastodon) . É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 Philippe F (site web personnel) . É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 Lizzie Crowdagger (site web personnel) . Évalué à 1. Dernière modification le 27 février 2014 à 11:36.
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)oux.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 fairelen,length, ousizedans celui-là)[^] # Re: python et django?
Posté par barmic . Évalué à 3.
T'inquiète avec python tu peut faire ça :
…
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 totof2000 . Évalué à 1.
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 lolop (site web personnel) . É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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: python et django?
Posté par totof2000 . Évalué à 1.
Elle n'est pas logique par rapport à la logique "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".
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.
Java n'est pas plus objet que C++ pour les mêmes raison. aucun rapport avec main.
[^] # Re: python et django?
Posté par barmic . É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 Yth (Mastodon) . É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 totof2000 . Évalué à -1.
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 GaMa (site web personnel) . É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:
Matthieu Gautier|irc:starmad
[^] # Re: python et django?
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 2.
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
truemais pas par l'objetfalse.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 Lizzie Crowdagger (site web personnel) . É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 totof2000 . É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 Yth (Mastodon) . É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 Zylabon . É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 barmic . É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 totof2000 . Évalué à 2.
Question de cohérence (voir plus haut).
[^] # Re: python et django?
Posté par Atem18 (site web personnel) . Évalué à 1.
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.
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 Moonz . Évalué à 2.
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 berumuron . É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 feth . Évalué à 3.
Ça ?
In[1] type(1)
Out[1] int
[^] # Re: python et django?
Posté par barmic . Évalué à 3.
On repart sur des troll de langages ? Un exemple qui montre l'introspection pyton sur le 1 :
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 totof2000 . É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 feth . É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 totof2000 . Évalué à 1.
Pourquoi faire ?
[^] # Re: python et django?
Posté par feth . É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 dave_null (site web personnel) . Évalué à 1.
Oui, supprimons tout les mots clefs réservés !!!
[^] # Re: python et django?
Posté par feth . É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 dave_null (site web personnel) . Évalué à 1. Dernière modification le 27 février 2014 à 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 totof2000 . É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 feth . Évalué à 2. Dernière modification le 27 février 2014 à 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éeobjet(arguments)), on lui adjoint une méthode__call__.[^] # Re: python et django?
Posté par feth . Évalué à 2.
Hm, désolé mais vous aurez rectifié, l'expression régulière est
__(?P<nom>.*)__.[^] # Re: python et django?
Posté par flan (site web personnel) . Évalué à 2.
Je vois deux gros problèmes :
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 totof2000 . É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é.
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 barmic . Évalué à 1.
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 totof2000 . É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 flan (site web personnel) . Évalué à 1.
As-tu des exemples en particulier ?
[^] # Re: python et django?
Posté par totof2000 . É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 Yth (Mastodon) . É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 totof2000 . Évalué à 2.
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
trollerargumenter de façon plus précise sur les points qui me gènent dans ce langage.[^] # Re: python et django?
Posté par lolop (site web personnel) . É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éthodeest une référence vers la méthode liée à x, etx.méthode()un appel à cette méthode. Et si méthode est un objet utilisateur, un appel à la méthode__call__()de cet objet, soitx.méthode.__call().Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: python et django?
Posté par totof2000 . É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 devnewton 🍺 (site web personnel) . Évalué à 1.
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: python et django?
Posté par Atem18 (site web personnel) . Évalué à 0.
PHP ? :-P
[^] # Re: python et django?
Posté par barmic . É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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: python et django?
Posté par barmic . É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 :
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 hermenegilde . Évalué à 4.
Envlève ton masque, Super Premier Degré Man, on t'a reconnu!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: python et django?
Posté par barmic . É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 devnewton 🍺 (site web personnel) . Évalué à 0.
Bien typé!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: python et django?
Posté par berumuron . Évalué à 1.
Qu'est-ce qu'on "bon" typage dans ce cas ? Un typage statique ?
[^] # Re: python et django?
Posté par barmic . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
Oui, avec le maximum de vérifications et d'avertissements à la compilation.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: python et django?
Posté par totof2000 . É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 Zylabon . É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 :
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 lolop (site web personnel) . Évalué à 1.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: python et django?
Posté par barmic . Évalué à 3.
Si si. Par pas d'erreur possible, ça veut dire que le code ne fait pas d'erreur.
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 wilk . É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 totof2000 . Évalué à 2.
Sale type !!!
# Juste pour alimenter le troll ...
Posté par totof2000 . É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 zebul0n (site web personnel) . Évalué à 3.
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 :
[^] # Re: Juste pour alimenter le troll ...
Posté par totof2000 . Évalué à 3.
Merci pour ce retour.
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 zebul0n (site web personnel) . Évalué à 2.
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é.
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 GaMa (site web personnel) . Évalué à 1.
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 Fabrice Devaux . É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 Moonz . Évalué à 5. Dernière modification le 26 février 2014 à 17:15.
Je ne vois pas en quoi c’est spécifique au web. Au pif :
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 0xfg . É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.
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 zebul0n (site web personnel) . Évalué à 1.
Ben, c'était pas le but, mais c'est bien foiré quand même.
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.
C'est ce que je proposais, de faire part des choix que certains effectuent …
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.
Du raw PHP ou avec Laravel, symphony, CI.
[^] # Re: Un troll juste pour moi :)
Posté par 0xfg . Évalué à 5.
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 Philippe F (site web personnel) . É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 Yth (Mastodon) . É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 0xfg . É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 zebul0n (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.