wilk a écrit 1090 commentaires

Le sharding, en quelque sorte c'est ce que fait dokeos ! répartir les données.
Je ne sais pas comment font les hébergeurs mais j'imagine qu'ils ajoutent tout simplement des machines.

Pour les sauvegardes il y a plusieurs solutions. Je ne connais pas MySQL, mais normalement on ne sauvegarde pas au niveau du système de fichier mais au niveau du sgbd, c'est lui qui fait un snapshot cohérent. Encore une fois, ça dépend aussi de l'application, si elle gère bien les transactions. Si les bases sont grosses et qu'un snapshot trop fréquent est trop lourd on fait des réplications en continue.

Les tests de charge (genre ab) sur 10000 accès simultanés c'est intéressant pour les sites à fort traffic, mais dans le cas d'une application je doute de l'utilité. Mais bref, personnellement si je veux faire des tests d'appli web, je le script en python...

Ok, je n'avais pas compris si tu voulais un avis sur le bidule ou simplement un conseil pour faire avec.
Donc, vu la situation, tu as peut-être effectivement intérêt à choisir l'option multi-base, ça sera effectivement plus souple. S'il y a des problèmes de charges ce sera assez facile d'en déplacer une partie sur une autre machine par ex, de savoir laquelle charge etc. Ca ne sera pas forcément le plus performant mais ça sera le plus simple. Les hébergeurs ont l'habitude de gérer des quantités importantes de bases, ça doit donc se faire.

Imagine toi une maison avec chacun sa chambre ou tous dans le même dortoir... Plus tu disperse les données plus la somme prendra de place et plus le sgbd va mouliner pour trouver ses petits.

Pour les sauvegardes il y a des solutions pour ne pas bloquer l'usager.

Pour les tests ce qu'il faudrait d'abord c'est isoler les points faibles. Le problème vient rarement des requêtes simples, même en très grande quantité, mais plutôt de passages critiques qui font tomber tout le monde (par ex des stats).

Pour l'utilisateur peut-être, mais pour la mise en place et la maintenance on dirait pas...

Si jamais tu veux pouvoir faire des requêtes sur toutes les données, (pour des stats, transferts etc) il vaut beaucoup mieux (pour toi autant que pour le sgbd) ne pas s'éparpiller sur plusieurs tables et encore moins sur plusieurs bases.
L'intérêt de dispatcher sur plusieurs bases c'est inversement quand les données ne doivent surtout pas se rejoindre (sécurité, versions différentes etc.).

Au niveau volume des données ça dépend surtout du logiciel, si les requêtes sont optimisées etc.

Pour des petites quantités de données, une base SQL s'en tirera toujours. Par contre quand ça commence à grossir, ça peut faire très mal...

Peut-être pour des cas bien particuliers, je doute que l'on puisse généraliser comme ça (c'est un FUD !). Est-ce qu'il y a par exemple des benchs couchdb vs postgresql avec insertions atomiques, quelques contrôles d'intégrités, d'unicité et validité des données (une date est bien une date), le tout pendant qu'il y a des requêtes en lecture en parallèle ?

Sur le site de couchdb c'est assez clair : What it is Not : A replacement for relational databases.

Rien que le passage obligatoire par json ça ne doit pas être gratuit sur de grandes quantités de données. Si on prend une date par ex, j'imagine que c'est stocké en texte ? Qu'en est-il de l'occupation disque et mémoire ?

Autant je peux imaginer l'intérêt d'un tel système sur un cluster pour fournir des documents très différents en lecture seule, autant pour des données genre facturation je doute, surtout sur un grand nombre de données...

Tu ne serais pas tombé par hasard dans le piège d'avoir trouvé un marteau et de considérer que tous les problèmes sont des clous ;-) ?

Je me souviens surtout des versions 4.x. Par contre il faut préciser que c'était le résultat qui était assez fiable, jamais l'éditeur (mais c'était tellement naturel qu'un éditeur plante qu'on n'y faisait pas plus attention que ça, comme tu dis, le ctr-s était de rigueur !)

En tout cas, je peux confirmer qu'avec VI + python, si on comprend également les temps de maintenance, y a pas photo, le gain de temps de dev est énorme face à windev. Je me souviens d'avoir participé à une formation sur apisoft xcs, c'était assez rigolo de voir les autres batailler pour arriver à lancer des fonctions sur oracle puis essayer d'afficher le résultat ! Le formateur entrain d'expliquer qu'il était indispensable d'utiliser je ne sais pas combien de couches. Pendant qu'en quelques lignes de python+cx_oracle je lançais les requêtes en question avec le résultat affiché instantanément... Ha oui, mais en console c'est pas du jeu, le client tout ça... Pas de problème, avec reportlab, une dizaine de ligne de code plus tard je sortais un pdf :-)

Windev est sorti à l'époque où il y avait un tas d'applications à passer de dos à windows. Il n'y avait pas beaucoup d'outils à l'époque et les développeurs n'étaient pas formés pour. Windev est très bien tombé. En plus les premières versions étaient assez fiables et novatrices, le développement était effectivement très rapide, même sans utiliser le RAD. Access aussi a cartonné à cette époque.
La diffusion des programmes ne demandait pas de licence, le cout était donc dérisoire pour une boite de dev.

Ensuite ils ont péniblement continué sur leur lancée, on ne peut pas leur enlever ça, ils ont un certain mérite quand même (presque 20 ans, et la boite 25 ans).

Aujourd'hui, effectivement avec les outils libres qu'on a, ça n'a plus beaucoup d'intérêt, surtout qu'ils ont un peu raté le virage web.

Tu as un lien vers cette étude d'IBM ? C'est vrai que c'est ce que je constate aussi...

Je viens de faire un test en aveugle, café turc vs cafetière italienne. Même café, même dose de café, même dose d'eau, même tasse, pas de sucre.
Le résultat est vraiment différent, avec l'italienne, le café est plus amère et acide. J'ai pas d'expresso sous la main...

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...

Je voulais dire : si on doit mettre du sucre, le mettre à ce moment là et non après. Désolé d'avoir heurté ta sensibilité !

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...)

J'oubliais, en passant, unladen swallow Q3 est sorti y a 3j...
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/

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)

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).

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 !

http://mail.python.org/pipermail/python-announce-list/2009-J(...)

Un copain me disait récemment, que ce qu'il n'aime pas avec Python c'est les problèmes d'indentation. Une indentation, où ça ? ;-)