Les technos dans le Web bougent plus que les sockets UNIX, en effet ;-)
tout dépend ce que tu fais avec Python et Ruby, je fais pas mal de choses qui n'ont rien à voir avec du Web, pourtant, ça m'arrive d'avoir besoin d'une lib qui n'est pas dans le système. Mais ce qui est au niveau du système est souvent plus figé et abouti que ce qu'il y a pour le Web, question d'ancienneté des technologies.
Oui, en théorie, non, en pratique dans toutes les distributions Linux que je connais, il faut que ça soit explicitement défini, par exemple python2 et python3, tu ne peux pas installer en même temps les versions que tu veux, même avec les slots, il faut que ça soit explicitement défini dans les ebuilds de mes souvenirs de Gentoo.
Virtualenv, ça correspond à embarquer ces propres versions avec le programme, mais avec un système de packages comme les distributions Linux pour gérer facilement les dépendances et les mises à jour. Ce n'est pas obligatoire, mais ça fait gagner du temps, surtout pour les eggs Python avec du code C.
Tout dépend du contexte, parfois ça aussi du bon d'avoir une version récente qui corrige les bugs ou rajoute des fonctionnalités dont tu as besoin.
Par exemple, la version de xlrd dans Debian Lenny a des problèmes avec certains fichiers XLS, j'étais content d'avoir la version qui fonctionne grâce à virtualenv.
Et justement, virtualenv évite de "pourrir" ce qui est installé sur le serveur.
Ça rentre en contradiction de la philosophie de la plupart des distributions Linux, où il n'y a qu'une version de librairie partagée par tous, pour simplifier les mises à jours et éviter la duplication, mais dans les faits, surtout pour du développement custom, il faut aussi être pragmatique.
En effet, quel est l'intérêt que le développeur redéveloppe dans son application quelque chose qui existe déjà dans la nouvelle version de la librairie ?
Posté par Ludo .
En réponse à la dépêche Weboob 0.9.
Évalué à 2.
Ok, normal que ça ne soit pas prioritaire.
Oui, j'ai bien compris que Weboob avait plus de fonctionnalités que Scrapy, mais c'était justement pour savoir si ça ne vous simplierait pas la vie de faire un wrapper de scrapy dans weboob pour remplacer certains morceaux de base comme weboob.tools.browser
Après, n'ayant aucune expérience avec scrapy, peut-être que pour vous, c'est mieux de faire vos propres libs.
Posté par Ludo .
En réponse à la dépêche Weboob 0.9.
Évalué à 6.
Ce commentaire s'adresse aux développeurs de Weboob, je voudrais savoir ce qu'ils pensent d'argparse: http://docs.python.org/library/argparse.html
Je l'utilise très souvent, c'est la meilleure librairie que j'ai utilisé pour l'instant, tous langages confondus.
Y'a t'il une raison technique qui vous a fait préférer de parser vous même la ligne de commande plutôt qu'utiliser cette librairie ?
De plus, j'entends assez souvent parler de Scrapy: http://scrapy.org/
Même question, avez-vous déjà jeté un coup d'oeil sur cette librairie ?
Je ne remets pas en question le logiciel qui est très pratique, c'est pour avoir un retour d'expếriences éventuel sur ces deux librairies.
Si tu as une distrib qui fait bien les choses pour 64 bits comme Arch Linux, tu as les librairies 32bits sous forme de package, donc pas de soucis. Ça fait bien 2 ans que je suis en 64bits, jamais eu un soucis pour lancer un programme en 32bits.
Ce ne sont que des jeux libres qui ont été testé, il aurait fallu inclure des jeux qui ont été populaires sous Windows XP comme Starcraft, Dungeon Keeper II...
Ou alors, indiquer "jeux libres" au lieu de "jeux" dans le titre, en effet ce n'est pas représentatif des jeux windows, car souvent les jeux propriétaires utilisent d'autres libs que les jeux libres comme DirectX.
Y'a que moi que ça dérange qu'on parle d'une surcouche pour un langage, car trop difficile à apprendre?
Déjà que je trouve que l'API de PHP est une catastrophe, ce qui est confirmé par les nombreuses surcouches que doivent faire les différents frameworks (ZF, Drupal...), mais là, c'est carrément la syntaxe même du langage.
Quelqu'un peut m'expliquer pourquoi ils n'ont pas fait une syntaxe simple directement? Je pensais que la manière de fonctionner d'Erlang imposait cette logique?
Irail, http://project.irail.be/ est un projet open source autour des horaires des transports en commun. Pour l'instant centré sur la Belgique, mais les contributeurs Européens sont les bienvenus ;)
Ils ont fait des démarches à ce sujet auprès des compagnies de transport en commun. Si j'ai bien compris, il y a une directive Européenne qui obligent les compagnies à donner cette information. Contacte-les si tu veux plus d'informations.
Pour moi, Mark s'est rendu compte que Qt avait beaucoup d'avantages et de cohérence dans l'API par rapport à GTK, et le passage à la licence LGPL a dû finir de le convaincre que c'était un bon choix.
La différence notable entre KDE et Gnome est au niveau philosophie d'un Desktop Environnement et non du toolkit, ça ne me choque pas de faire un Gnome avec Qt.
Je suis d'accord avec toi, c'est le langage PHP qui pêche beaucoup par rapport à Ruby, y'a qu'à regarder l'inconsistence de l'API en PHP (tout est fonction, pas de regroupement par classes, l'ordre des paramètres qui change pour des fonctions proches...)
De plus, pour avoir fait pas mal de Zend Framework, il y a de bonnes idées, mais il y a souvent pas mal d'abstractions dans les classes qui complexifient le code sans pourtant avoir des avantages probants.
Alors qu'en RoR, le framework me semble plus pragmatique par rapport au besoins quotidiens d'un développeur Web.
Si le Web t'intéresse et que tu veux monter rapidement en compétences, je te dirais plutôt Ruby.
Le langage est pur objet, y'a pas mal de choses intéressantes
Moi-même je m'y suis récemment, et j'ai pu rapidement faire des applications. Y'a pleins de gems intéressants qui permettent d'ajouter des fonctionnalités.
Sinon, Python est aussi un bon choix, peut-être "moins" pur, mais avec une plus grosse communauté.
Passenger est recommandé, mais Passenger dans Gentoo a eu pas mal de problèmes (je n'en connais pas la raison), j'ai dû garder une certaine version de Passenger dans la Gentoo pour que cela fonctionne correctement.
Bien que l'implémentation LLVM soit "jeune", ils ont déjà des performances proches. J'imagine donc qu'ils ont encore de la "marge" sur ce qu'ils peuvent faire, même si je n'ai aucune preuve pour l'étayer.
Merci pour les infos, c'est justement la performance du code généré qui me semble plus importante que la vitesse de compilation (on utilise plus souvent un programme qu'on le compile ;-) )
C'est néanmoins bien parti pour qu'ils "explosent" les performances de GCC.
[^] # Re: Les développeurs Python modernes...
Posté par Ludo . En réponse au journal Chronokiwi sort en version d3b63be4cb. Évalué à 1.
Les technos dans le Web bougent plus que les sockets UNIX, en effet ;-)
tout dépend ce que tu fais avec Python et Ruby, je fais pas mal de choses qui n'ont rien à voir avec du Web, pourtant, ça m'arrive d'avoir besoin d'une lib qui n'est pas dans le système. Mais ce qui est au niveau du système est souvent plus figé et abouti que ce qu'il y a pour le Web, question d'ancienneté des technologies.
[^] # Re: Les développeurs Python modernes...
Posté par Ludo . En réponse au journal Chronokiwi sort en version d3b63be4cb. Évalué à 1.
Oui, en théorie, non, en pratique dans toutes les distributions Linux que je connais, il faut que ça soit explicitement défini, par exemple python2 et python3, tu ne peux pas installer en même temps les versions que tu veux, même avec les slots, il faut que ça soit explicitement défini dans les ebuilds de mes souvenirs de Gentoo.
[^] # Re: Les développeurs Python modernes...
Posté par Ludo . En réponse au journal Chronokiwi sort en version d3b63be4cb. Évalué à 1.
Virtualenv, ça correspond à embarquer ces propres versions avec le programme, mais avec un système de packages comme les distributions Linux pour gérer facilement les dépendances et les mises à jour. Ce n'est pas obligatoire, mais ça fait gagner du temps, surtout pour les eggs Python avec du code C.
[^] # Re: Les développeurs Python modernes...
Posté par Ludo . En réponse au journal Chronokiwi sort en version d3b63be4cb. Évalué à 1.
Tout dépend du contexte, parfois ça aussi du bon d'avoir une version récente qui corrige les bugs ou rajoute des fonctionnalités dont tu as besoin.
Par exemple, la version de xlrd dans Debian Lenny a des problèmes avec certains fichiers XLS, j'étais content d'avoir la version qui fonctionne grâce à virtualenv.
Et justement, virtualenv évite de "pourrir" ce qui est installé sur le serveur.
Ça rentre en contradiction de la philosophie de la plupart des distributions Linux, où il n'y a qu'une version de librairie partagée par tous, pour simplifier les mises à jours et éviter la duplication, mais dans les faits, surtout pour du développement custom, il faut aussi être pragmatique.
En effet, quel est l'intérêt que le développeur redéveloppe dans son application quelque chose qui existe déjà dans la nouvelle version de la librairie ?
[^] # Re: Librairies Python
Posté par Ludo . En réponse à la dépêche Weboob 0.9. Évalué à 2.
Ok, normal que ça ne soit pas prioritaire.
Oui, j'ai bien compris que Weboob avait plus de fonctionnalités que Scrapy, mais c'était justement pour savoir si ça ne vous simplierait pas la vie de faire un wrapper de scrapy dans weboob pour remplacer certains morceaux de base comme weboob.tools.browser
Après, n'ayant aucune expérience avec scrapy, peut-être que pour vous, c'est mieux de faire vos propres libs.
# Librairies Python
Posté par Ludo . En réponse à la dépêche Weboob 0.9. Évalué à 6.
Ce commentaire s'adresse aux développeurs de Weboob, je voudrais savoir ce qu'ils pensent d'argparse: http://docs.python.org/library/argparse.html
Je l'utilise très souvent, c'est la meilleure librairie que j'ai utilisé pour l'instant, tous langages confondus.
Y'a t'il une raison technique qui vous a fait préférer de parser vous même la ligne de commande plutôt qu'utiliser cette librairie ?
De plus, j'entends assez souvent parler de Scrapy: http://scrapy.org/
Même question, avez-vous déjà jeté un coup d'oeil sur cette librairie ?
Je ne remets pas en question le logiciel qui est très pratique, c'est pour avoir un retour d'expếriences éventuel sur ces deux librairies.
[^] # Re: L'intérêt de ce type de question sur un journal ?
Posté par Ludo . En réponse au journal Quels avantages à installer un noyau 64 bits ?. Évalué à 6.
Si tu as une distrib qui fait bien les choses pour 64 bits comme Arch Linux, tu as les librairies 32bits sous forme de package, donc pas de soucis. Ça fait bien 2 ans que je suis en 64bits, jamais eu un soucis pour lancer un programme en 32bits.
# Interêt du test ?
Posté par Ludo . En réponse au journal Le Match ! Linux+Wine opposé à Windows 7. Évalué à 10.
Ce ne sont que des jeux libres qui ont été testé, il aurait fallu inclure des jeux qui ont été populaires sous Windows XP comme Starcraft, Dungeon Keeper II...
Ou alors, indiquer "jeux libres" au lieu de "jeux" dans le titre, en effet ce n'est pas représentatif des jeux windows, car souvent les jeux propriétaires utilisent d'autres libs que les jeux libres comme DirectX.
# Utilise Chromium
Posté par Ludo . En réponse au message A quelles informations ont accès les extensions firefox ? . Évalué à 0.
Si cela te travaille vraiment, utilise Chromium, c'est libre et il y a une politique de droit d'accès aux informations, un peu comme avec Android.
[^] # Re: mod_rangecnt + fail2ban
Posté par Ludo . En réponse au journal Apache n'apprécie pas le HTTP Range. Évalué à 6.
Au lieu de faire:
Est-ce que ceci ne fonctionnerait pas?:
[^] # Re: C et GTK, pas le mieux je pense
Posté par Ludo . En réponse à la dépêche Co-financement d'un logiciel de transfert vers machine-outil. Évalué à 3.
Je confirme Python+Qt avec PySide me semble également le meilleur choix.
# Si surcouche de langage nécessaire, changer de langage ?
Posté par Ludo . En réponse à la dépêche Elixir, enfin une syntaxe agréable pour Erlang ?. Évalué à 3.
Y'a que moi que ça dérange qu'on parle d'une surcouche pour un langage, car trop difficile à apprendre?
Déjà que je trouve que l'API de PHP est une catastrophe, ce qui est confirmé par les nombreuses surcouches que doivent faire les différents frameworks (ZF, Drupal...), mais là, c'est carrément la syntaxe même du langage.
Quelqu'un peut m'expliquer pourquoi ils n'ont pas fait une syntaxe simple directement? Je pensais que la manière de fonctionner d'Erlang imposait cette logique?
[^] # Re: GPL vs AGPL
Posté par Ludo . En réponse au journal Omoma : application web de gestion financière. Évalué à 4.
Pour moi aussi, ça me semble important de le mettre sous licence AGPL, pour éviter des abus éventuels.
# demander à irail
Posté par Ludo . En réponse au journal Un plasmoïde pour Infolignes : ai-je le droit de le publier?. Évalué à 4.
Irail, http://project.irail.be/ est un projet open source autour des horaires des transports en commun. Pour l'instant centré sur la Belgique, mais les contributeurs Européens sont les bienvenus ;) Ils ont fait des démarches à ce sujet auprès des compagnies de transport en commun. Si j'ai bien compris, il y a une directive Européenne qui obligent les compagnies à donner cette information. Contacte-les si tu veux plus d'informations.
# Il faut résonner en terme de Toolkit et non en tant que DE
Posté par Ludo . En réponse au journal Qt dans Ubuntu. Évalué à 5.
La différence notable entre KDE et Gnome est au niveau philosophie d'un Desktop Environnement et non du toolkit, ça ne me choque pas de faire un Gnome avec Qt.
[^] # Re: Comparatif ?
Posté par Ludo . En réponse au journal Pourquoi Ruby on Rails pour la réécriture de LinuxFr.org ?. Évalué à 2.
De plus, pour avoir fait pas mal de Zend Framework, il y a de bonnes idées, mais il y a souvent pas mal d'abstractions dans les classes qui complexifient le code sans pourtant avoir des avantages probants.
Alors qu'en RoR, le framework me semble plus pragmatique par rapport au besoins quotidiens d'un développeur Web.
# Plutôt Ruby
Posté par Ludo . En réponse au message Que de langages..mais quel langage ?. Évalué à 2.
Le langage est pur objet, y'a pas mal de choses intéressantes
Moi-même je m'y suis récemment, et j'ai pu rapidement faire des applications. Y'a pleins de gems intéressants qui permettent d'ajouter des fonctionnalités.
Sinon, Python est aussi un bon choix, peut-être "moins" pur, mais avec une plus grosse communauté.
[^] # Re: Moi, je suis resté à CVS.
Posté par Ludo . En réponse au message organisation du développement à plusieurs & sauvegardes. Évalué à 1.
Git c'est très bien, SVN ça va, mais CVS...
J'ai bossé avec les trois, y'a pas photo.
Comment as-tu fait pour n'avoir aucun problème avec CVS ? Tu bosses tout seul ?
[^] # Re: ainsi va le monde
Posté par Ludo . En réponse au journal AppInventor : création graphique d'applications android pour les non programmeurs. Évalué à 1.
[^] # Re: Pas convaincu
Posté par Ludo . En réponse à la dépêche Gérez vos projets avec Trac. Évalué à 3.
Avec le dernier Redmine, ils utilisent Rails 2.3, ça consomme moins de ressources.
# par rapport à CiviEvent ?
Posté par Ludo . En réponse à la dépêche e-venement 1.9.0 "Cognac taste", le libre dans la billetterie est toujours là. Évalué à 3.
Quelqu'un ici présent aurait-il une expérience sur les deux outils, pour les positionner l'un par rapport à l'autre ?
[^] # Re: Mouais
Posté par Ludo . En réponse à la dépêche Sortie de Phusion Passenger 2.2.12. Évalué à 2.
Passenger est recommandé, mais Passenger dans Gentoo a eu pas mal de problèmes (je n'en connais pas la raison), j'ai dû garder une certaine version de Passenger dans la Gentoo pour que cela fonctionne correctement.
[^] # Re: Serveur git et authentification simple
Posté par Ludo . En réponse au journal Tutorial GIT Partie 2. Évalué à 3.
Il faut 30 secondes pour générer une clé SSH (ssh-heygen), et c'est fait une fois pour toute.
Donc le côté pas simple, j'ai du mal à voir.
[^] # Re: Bench entre GCC et LLVM
Posté par Ludo . En réponse au journal Clang++ est prêt. Évalué à 0.
[^] # Re: Bench entre GCC et LLVM
Posté par Ludo . En réponse au journal Clang++ est prêt. Évalué à 1.
C'est néanmoins bien parti pour qu'ils "explosent" les performances de GCC.