Nous sommes quelques uns à traduire en ce moment le bouquin de mercurial, les premiers chapitres sont fait, tu peux aller voir http://belaran.eu/hgbook-fr-SNAPSHOT/read/
Le premier chapitre parle justement du choix d'un gestionnaire de sources
Au niveau impressionnant il y a également, shedskin, qui vient de sortir en 0.2 et qui compile (sous certaines conditions) un programme python en c++. http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.
Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)
Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.
Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
10000 est un choix arbitraire pour ne compiler que le code très utilisé et ne pas pénaliser le démarrage et la mémoire.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
Psyco vient de sortir. Pour l'instant il n'y a pas encore beaucoup d'info (support des générateurs), mais Christian Tismer, nouveau mainteneur (payé), promet une renaissance du projet !
Personne n'a trop parlé de l'appli, mais ça me semble important aussi. Vous ne trouvez pas curieux qu'un erp engendre autant de requêtes ?
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
Je crois que la sortie de cette version 3.1 est le signal pour montrer que la branche 3 est mure et que le portage des modules peut commencer sans crainte.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
Je me suis amusé à coder le problème des parcours de chevaux aux échecs qui doivent remplir une grille, en utilisant un code le plus semblable possible (sans utiliser les librairies spécifiques des différentes langages).
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
Le plus simple c'est encore de faire tes petites bidouilles dans un clone à part, que tu merge dans ta branche principale quand c'est prêt à pusher. C'est la différence avec git où dans le même répertoire tu peux avoir plusieurs branches aussi distinctes que des clones.
rebase, tu l'as comme extension dans mercurial, ça permettra de "rebaser" tes bidouilles dans l'historique comme si ça avait été dans la même branche, plutôt que de faire des merges. http://www.selenic.com/mercurial/wiki/RebaseProject
Tout dépend de ce que tu fait comme administration !
Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()
J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...
La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...
Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.
Dans la vraie vie comme tu dis, plus les données sont importantes, financièrement parlant, plus le critère de choix devient financier également et non plus technique. Bref, c'est l'assureur qui choisit et non le directeur technique.
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
Je suis passé de bazaar à mercurial il n'y a pas très longtemps, il me semble tout simplement que mercurial est ce que bazaar cherchait à devenir en vain... Simple et rapide, il suffit d'essayer.
Parce qu'il est tellement pratique que pour ce que je fait ça a fait mentir l'adage comme quoi on programme mieux dans le langage qu'on connait le mieux et avec celui qui est en théorie le plus adapté au besoin. Le tout qui se vérifie sur la durée au niveau de la maintenance.
Que demander de plus ?
Ce que je fait avec ? Des scripts d'admin, de graphisme, de gestion, en ligne ou pas, sous linux ou pas, pro ou pas.
Et pour le plaisir d'être plus proche du système, de mes goûts, par nostalgie, pour que ça tourne plus vite, je m'autorise de lui coller un peu de C.
La seule fois où j'ai perdu du temps avec Python c'est quand j'ai décidé de migrer mes applis en utf8/unicode au lieu d'attendre la v3...
Forcement, quand t'as appris Java t'étais débutant :)
C'est ça qui est génial, je peux rester débutant tout en assurant mon job grâce au Python !
Je reviens sur mon paradoxe, autant on trouve pléthore de raisons pour obliger les développeurs à faire du java, autant tous ceux qui utilisent python l'on fait par choix. Curieux non ?
Bon j'arrête sinon je vais être obligé de raconter ma vie ;-)
# hgbook en français
Posté par wilk . En réponse au message A la recherche du meilleur outil .... Évalué à 2.
Le premier chapitre parle justement du choix d'un gestionnaire de sources
[^] # Re: Psyco V2
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 4.
Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)
query('select mon champ'
- - - - - - 'from matable'
- - - - - - 'where macondition'
- - - - - - 'order by montri',
- - - - - - - - - monparam1='cecicela',
- - - - - - - - - monparam2='etci')
Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
[^] # Re: Ça me brule les lèvres...
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
# Psyco V2
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 3.
http://mail.python.org/pipermail/python-announce-list/2009-J(...)
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 4.
[^] # Re: mysql=oracle donc poubelle
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
Donc btrfs >= oracle
[^] # Re: ton ERP
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
[^] # Re: Quand switcher ?
Posté par wilk . En réponse à la dépêche Python arrive en version 3.1. Évalué à 5.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
[^] # Re: Ça passe très bien :)t
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
c 5s
gcj 7s
java 7s
python2.5 + psyco 18s
python2.5 303s
java est extrêmement performant s'il est utilisé comme du C. On retrouve ces résultats sur http://shootout.alioth.debian.org/
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
# clone à part
Posté par wilk . En réponse au message Mercurial: Publier uniquement ce que l'on veut .... Évalué à 1.
rebase, tu l'as comme extension dans mercurial, ça permettra de "rebaser" tes bidouilles dans l'historique comme si ça avait été dans la même branche, plutôt que de faire des merges.
http://www.selenic.com/mercurial/wiki/RebaseProject
[^] # Re: Cela dépend de ce que tu fais...
Posté par wilk . En réponse au message [Programmation] Shell / Perl / Python. Évalué à 1.
Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()
J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...
La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...
Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.
[^] # Re: Karma...
Posté par wilk . En réponse à la dépêche Évolutions du site LinuxFr.org. Évalué à 1.
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par wilk . En réponse à la dépêche Oracle achète Sun. Évalué à 4.
[^] # Re: Juste un mot sur mercurial
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://www.selenic.com/mercurial/wiki/index.cgi/TranslatingM(...)
[^] # Re: mercurial après bazaar
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://article.gmane.org/gmane.comp.version-control.mercuria(...)
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
[^] # Re: dommage
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://www.python.org/dev/peps/pep-0374/
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
# mercurial après bazaar
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 5.
# Pratique
Posté par wilk . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 1.
Que demander de plus ?
Ce que je fait avec ? Des scripts d'admin, de graphisme, de gestion, en ligne ou pas, sous linux ou pas, pro ou pas.
Et pour le plaisir d'être plus proche du système, de mes goûts, par nostalgie, pour que ça tourne plus vite, je m'autorise de lui coller un peu de C.
La seule fois où j'ai perdu du temps avec Python c'est quand j'ai décidé de migrer mes applis en utf8/unicode au lieu d'attendre la v3...
# L'histoire de python
Posté par wilk . En réponse au journal Explorez les richesses du langage Python. Évalué à 5.
http://python-history.blogspot.com
[^] # Re: sqlgrey...
Posté par wilk . En réponse au journal Luttons intelligemment contre le spam avec Whitelister. Évalué à 1.
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à 1.
C'est ça qui est génial, je peux rester débutant tout en assurant mon job grâce au Python !
Je reviens sur mon paradoxe, autant on trouve pléthore de raisons pour obliger les développeurs à faire du java, autant tous ceux qui utilisent python l'on fait par choix. Curieux non ?
Bon j'arrête sinon je vais être obligé de raconter ma vie ;-)