Ludo a écrit 137 commentaires

Ok pour l'ORM, de fait, ça a du sens.

Pour les callbacks en Twisted, c'est un argument que j'ai entendu plusieurs fois.
Ça a du sens, c'est vrai que c'est plus simple à lire.

Après, avec de la rigueur, si tu mets la méthode de callback juste en dessous, ça reste simple à lire, mais c'est vrai que sur ce point, le Javascript fait mieux.

1. Soit tu me dit que tu cherchais un ORM, auquel cas il fallait se tourner vers Twistar, soit tu me dit que tu as horreur du système de callback, alors que fais-tu avec NodeJS, dont le JS est basé sur le même principe ? ;-) Pour moi, cette API de requêtes SQL est KISS en Twisted.
2. Twisted utilise la notion de Factory pour créer chaque instance de protocole, alors qu'en NodeJS, de ce que j'en vois, c'est directement le protocole qui est attaqué. Peut-être que c'est over-engineered dans Twisted, néanmoins, je me sers souvent de cette notion de factory pour gérer de manière globale un groupe de pool de protocol (reconnexion…). Mais j'imagine que c'est aussi possible de coder ce genre de notions en NodeJS, ce n'est qu'une séparation logique.

D'accord avec toi, sauf sur deux points:
1. Tu n'as pas cherché longtemps pour faire du PostGreSQL asynchrone ;-) => http://twistedmatrix.com/documents/current/core/howto/rdbms.html#auto4
2. Perso, je ne trouve pas beaucoup plus la syntaxe de JS adapté pour de l'asynchrone que Twisted, par contre, il faut penser asynchrone avec twisted, ce que ne font pas la plupart des dev python, ils essaient de faire du python "classique" avec twisted.

Pour avoir fait pendant 2 ans du Zend Framework, je suis d'accord avec lui, c'est de la daube par rapport à Django, je ne veux plus toucher à ZF.
Pas de communauté ZF qui publie des exemples, que de la doc théorique, des kilomètres de code à taper quand quelques lignes suffisent avec Django, des bugs…

Sans compter qu'en PHP amuse-toi pour faire des threads, des daemons ou tout truc un peu avancé ;-)

J'utilise aussi beaucoup Python, et je vois monter NodeJS ces derniers temps, en même temps que mes propres besoins en JS côté client augmentent.

La grande force de Python, ce sont les librairies, où dans mon domaine, sont bien plus avancées qu'en NodeJS. De plus le langage JS est moins consistant que Python.

Perso, j'aimerais bien pouvoir utiliser Python côté client plutôt que passer à JS côté serveur, j'ai prévu d'expérimenter certaines solutions, mais j'ai bien peur que je ne pourrais utiliser ça uniquement pour les clients dont on maitrise l'OS client.

Il y a aussi http://saltstack.org/ et https://github.com/sebastien/cuisine

Je te recommanderais plutôt Saltstack, qui est plus riche, j'ai une connaissance qui l'utilise, il en est très content.

Le gros interêt, c'est qu'ils sont en Python, qui possède plus de librairies orienté système que Ruby.

tu confonds avec WebRTC.

Désolé, j'ai cru que tu étais un développeur PHP qui cherchait une excuse pour éviter de tester Django ;-)

Le problème, c'est que si tu fais du PHP pur, tu ne vas pas trouver tes marques rapidement en Django. La logique est différente.
Et faire du Python comme on fait du PHP, tu peux t'en approcher, mais ça perd bcp de son intéret, il vaut vraiment mieux partir d'un framework Python comme Django, Pyramid, Flask, Bottle…
Python ne fonctionne pas comme PHP, il est beaucoup plus proche de Ruby ou Java dans le fonctionnement (pas la lourdeur).

Par contre, si tu fais du Zend Framework ou du Rails ou tout autre framework, fais le tutorial en 4 parties de Django, et tu vas comprendre rapidement l'intérêt.

Je ne sais pas, je n'ai pas de problèmes avec les formulaires Django, je ne suis pas certain de comprendre tes problématiques.

Tu peux venir en discuter sur le chan IRC #django-fr

Il y a aussi des systèmes de formulaires alternatifs comme: http://django-floppyforms.readthedocs.org/en/latest/index.html

Je n'avais pas vu que tu es belge, je serais à l'afpyro ce vendredi si tu veux en discuter de vive voix: http://linuxfr.org/news/afpyro-a-liege-le-vendredi-30-mars

J'ai eu beaucoup de bugs, très peu de docs avec des exemples concrets, il n'y a que de la théorie dans leurs docs.
Pas grand monde poste des informations sur le net et peu d'extensions existent, et c'est très verbeux.

Pour te donner un ordre d'idées, je dois faire pas mal de petites webapps. Les mêmes webapps avec zf ça me prenait 2 semaines en moyenne et pas sûr du résultat, avec django, je suis à 1 à 2 jours, et pas de bugs.

C'est possible parce que dans django tu as plein d'applications réutilisables: http://djangopackages.com

Rails c'est mieux architecturé que zf, mais g eu aussi pas mal de bugs, le patch de gems est obligatoire.

Franchement, le retour sur investissement avec django, vaut la peine de s'y mettre, même si on ne connaît que PHP.

Par contre, il faut perdre les mauvaises habitudes qu'on a en PHP, où la culture de la librairie est beaucoup moins forte. Là où en PHP tu vas devoir réinventer la roue parce que personne n'a fait une librairie potable, en python/django, c'est rare que telle fonctionnalité n'existe pas sous forme de librairie.

J'ai le même parcours que toi, et j'ai la même impression, Django > RoR > ZendFramework.
Je n'avais jamais codé aussi vite des webapps qu'avec Django.

http://www.sagemath.org/ Ça allie la force d'un vrai langage (Python) qui possède une floppée de librairies autour des maths (numpy, scipy…) et un GUI à la Mapple/Mathematica.

Je ne l'ai vu qu'en démo à la PyCON-FR l'année dernière, mais ça a l'air vraiment bien.

C'est en standard dans ces outils, et ils sont globalement meilleurs à WebCollab.

Je ne sais pas comment c'est fait, mais y'a au moins une librairie qui a sû l'implémenter: http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification

Ils n'ont pas tout compris aux licenses, utiliser une license AGPL pour un logiciel qui tourne en local sur le téléphone, c'est de l'overkill.

Il fallait lire la documentation ;-)

Depuis quelques versions, BBB se concentre sur son API, l'application Web ne fonctionne plus, il faut obligatoirement le coupler avec une application qui gère l'authentification et les salles de conférences (Redmine...).

1. Asterisk a été remplacé par Freeswitch.
2. Le module Drupal ne fonctionne plus avec les nouvelles versions.
3. Il fonctionne très bien avec Redmine/Chili project.
4. OpenOffice est utilisé pour la conversion des documents de bureautique en images affichable sur le tableau blanc.

Ca fait des années que je bricole avec php, j'ai fait du web, j'ai écrit des applications web pour des clients, mais j'avais jamais reussi à faire quelque chose qui sort de l'informatique

Par expérience, PHP n'est pas "fait" pour faire des logiciels systèmes, par rapport à du Python. C'est techniquement possible, mais tu te heurtes à:

1. Très peu de libs pour faire des opérations systèmes. Par exemple, faire un outil en ligne de commande qui reçoit des paramètres, tu dois faire quasi tout à la main, alors qu'avec Python: http://docs.python.org/dev/library/argparse.html
2. Faire tourner PHP tout le temps comme daemon, ce n'est pas vraiment optimisé, notamment au niveau du garbage collector.
3. Une API incohérente et des problèmes quand tu as une utilisation avancée, par exemple, avec les sockets.

Tu pourrais peut-être proposer ton journal en dépêche, pour toucher un public plus large.

C'est aussi ce que je me suis dit en lisant le journal, y'a des gros pompages de chez KDE 4, notamment l'intégration avec le Web. Sauf que KDE4 est sorti il y a des années ;-)

Tu peux le mettre sur Github: https://github.com/MCMic/freesiege/downloads

KDE 4.0 est sorti y'a 3 ans et demi, ça me parait trop tard comme projet.

Surtout que maintenant KDE 4 fonctionne bien, fonctionnellement c'est bon aussi, et qu'il y a des milliers de contributeurs KDE alors qu'ils ne sont que deux sur Trinity.

[troll]Pour moi, ça montre surtout la résistance aux changements qu'ont certains "geeks", ils ont tellement galérés à apprendre à utiliser leur outil, qu'ils ne veulent pas qu'ils bougent d'un yota ;-)[/troll]

C'est ce que je dit, il faut que ça soit prévu dans l'ebuild, ce n'est pas vrai pour tous les ebuilds.

Par exemple, si je veux la 2.6.6-r2 et la 2.6.7-r2, ce n'est pas possible car s'est dans le même slot. Je ne peux avoir qu'une version dans mon slot.

Et encore, c'est parce que Gentoo est très souple, la plupart des distributions n'ont pas un système aussi fin.