Ludo a écrit 137 commentaires

  • [^] # Re: Les développeurs Python modernes...

    Posté par  . 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  . 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  . 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  . 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  . 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  . 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  . 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  . 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  . 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  . En réponse au journal Apache n'apprécie pas le HTTP Range. Évalué à 6.

    Au lieu de faire:

    cd /etc/apache2/mods-enabled/ puis sudo ln -s /etc/apache2/mods-available/rangecnt.load

    Est-ce que ceci ne fonctionnerait pas?:

     sudo a2enmod rangecnt
    
    
  • [^] # Re: C et GTK, pas le mieux je pense

    Posté par  . 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  . 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  . 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  . 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  . En réponse au journal Qt dans Ubuntu. Évalué à 5.

    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.
  • [^] # Re: Comparatif ?

    Posté par  . En réponse au journal Pourquoi Ruby on Rails pour la réécriture de LinuxFr.org ?. Évalué à 2.

    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.
  • # Plutôt Ruby

    Posté par  . En réponse au message Que de langages..mais quel langage ?. Évalué à 2.

    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é.
  • [^] # Re: Moi, je suis resté à CVS.

    Posté par  . En réponse au message organisation du développement à plusieurs & sauvegardes. Évalué à 1.

    C'est une tentative de troll ? :-)

    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  . En réponse au journal AppInventor : création graphique d'applications android pour les non programmeurs. Évalué à 1.

    Ce n'est pas ce qui se passe déjà pour la création de sites Web ;-) ?
  • [^] # Re: Pas convaincu

    Posté par  . En réponse à la dépêche Gérez vos projets avec Trac. Évalué à 3.

    C'était en parti dû à Rails.

    Avec le dernier Redmine, ils utilisent Rails 2.3, ça consomme moins de ressources.
  • # par rapport à CiviEvent ?

    Posté par  . En réponse à la dépêche e-venement 1.9.0 "Cognac taste", le libre dans la billetterie est toujours là. Évalué à 3.

    Je ne connais pas e-venement, uniquement CiviEvent, qui est un module CiviCRM, qu'on peut intégrer dans Drupal: http://civicrm.org/civievent

    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  . En réponse à la dépêche Sortie de Phusion Passenger 2.2.12. Évalué à 2.

    Vous avez tous les deux raison ;-)

    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  . En réponse au journal Tutorial GIT Partie 2. Évalué à 3.

    Gitosis fonctionne très bien, l'utilisation de clés SSH me semble justement une bonne idée, notamment pour les déploiements.

    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  . En réponse au journal Clang++ est prêt. Évalué à 0.

    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.
  • [^] # Re: Bench entre GCC et LLVM

    Posté par  . En réponse au journal Clang++ est prêt. Évalué à 1.

    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.