J'ai fait ça, en spécif gestion de prod pour 3 boites, c'est du python, interface web, sur base de données oracle/access (à cause d'un lien avec apisoft), mais facilement portable sur postgresql (que j'utilise d'habitude).
Pour la licence du produit lui-même, je suis pas tout seul à en décider et vu que c'est du spécif la question ne s'est jamais vraiment posée. Donc à voir avec ce que tu recherche exactement...
Pour des petites tasses, une cuillère à café de café, bombée. Je met une cuillère à café non bombée de sucre pour deux tasses. Bien sûr pour l'eau il suffit de mettre la quantité des tasses voulues. Je met tout en même temps, mais on peut aussi faire caraméliser le sucre avant de rajouter l'eau, pareil pour le café...
On prend une casserole, de préférence fine et allongée. On met l'eau, le café (le plus fin qu'on trouve) et le sucre, on chauffe (pas trop fort) jusqu'à ce que ça mousse. Juste avant que ça ne déborde on la retire du feu. On peut la remettre 2 ou 3 fois suivant les gouts.
Si ça bout trop vite, par exemple en camping où on ne peut pas régler le feu, il suffit soit de tenir la casserole à bonne distance, soit de remuer à la cuillère pendant la chauffe (si on tourne longtemps ça va donner un gout encore différent, intéressant).
Ensuite avant de servir on tapote la casserole pour faire descendre le marc. Pour ceux qui n'aiment pas avoir à manger en même temps on peut servir à travers une passoire fine.
Et tant qu'à rester libre, on achète du café zapatiste sans passer par les circuit commerciaux.
Comme en ligne de commande, les avantages sont multiples. Très léger et permet une infinité de variations possibles (quantité et choix de café, durée de chauffe...)
* Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
* Execution performance has improved by 15-70%, depending on benchmark.
* Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
* Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
* Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
* Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.
Python peut être extrêmement rapide avec psyco. La difficulté est qu'il ne suffit pas d'importer psyco, il faut aussi adapter son code pour en profiter réellement. Un code optimisé pour python seul ne le sera pas forcément pour python+psyco et inversement. C'est un peu comme en Java, si on fait gaffe on peut obtenir un code proche de la vitesse du C mais si on ne fait pas gaffe ça peut être catastrophique. Je ne sais pas ce qu'il en est avec ruby...
Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
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".
# libre, gratuit ou basé sur le libre ?
Posté par wilk . En réponse au message Gestion de temps du personnel. Évalué à 1.
Pour la licence du produit lui-même, je suis pas tout seul à en décider et vu que c'est du spécif la question ne s'est jamais vraiment posée. Donc à voir avec ce que tu recherche exactement...
[^] # Re: En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 1.
[^] # Re: En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 2.
# En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 10.
Si ça bout trop vite, par exemple en camping où on ne peut pas régler le feu, il suffit soit de tenir la casserole à bonne distance, soit de remuer à la cuillère pendant la chauffe (si on tourne longtemps ça va donner un gout encore différent, intéressant).
Ensuite avant de servir on tapote la casserole pour faire descendre le marc. Pour ceux qui n'aiment pas avoir à manger en même temps on peut servir à travers une passoire fine.
Et tant qu'à rester libre, on achète du café zapatiste sans passer par les circuit commerciaux.
Comme en ligne de commande, les avantages sont multiples. Très léger et permet une infinité de variations possibles (quantité et choix de café, durée de chauffe...)
[^] # Re: Depuis le début
Posté par wilk . En réponse à la dépêche Proposition de moratoire de plusieurs années sur le coeur du langage Python. Évalué à 1.
http://code.google.com/p/unladen-swallow/wiki/Release2009Q3
* Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
* Execution performance has improved by 15-70%, depending on benchmark.
* Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
* Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
* Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
* Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.
Et sur le blog de pypy les résultats annoncés sont pour le moins impressionnants...
http://morepypy.blogspot.com/
[^] # Re: Depuis le début
Posté par wilk . En réponse à la dépêche Proposition de moratoire de plusieurs années sur le coeur du langage Python. Évalué à 1.
Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
# 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".