wilk a écrit 1201 commentaires

Je viens de voir ça passer dans les annonces

https://launchpad.net/pyexiv2

Merci de t'être intéressé à mon code ! Je viens de l'essayer, sauf erreur ton code est beaucoup plus rapide avec pypy mais moins avec cpython ou psyco. Tu confirmes ?

ton code
cpython 124s
pypy 13s
psyco 4s

le mien
cpython 86s
pypy 107s
psyco 1s

J'ai testé sur un petit algo qui recherche les différentes possibilités de déplacement d'un cheval sur un damier sans repasser par la même case... Je ne sais pas si c'est très clair, ça donne par ex sur un damier 3x3

147
6X2
385

J'ai écrit le code pour python, c, php, java et différentes variations python.

Avec pypy1.4 il n'y a quasiment pas de différence avec cpython, en revanche il y a énormément de différence avec psyco... (de 3m contre 2s), je trouve curieux que ce genre de code n'ait pas été plus optimisé, il faudra que je leur en parle...
http://hg.flibuste.net/libre/games/cheval/file

En revanche je viens d'essayer sur petit programme de calcul d'itinéraires (un vrai programme en prod), c'est impressionnant, le résultat est similaire qu'avec psyco, le rapport est de 1 à 100 ! C'est très prometteur.

Ruby est un langage bien plus fun que Python : je pense que la communauté Python est trop sérieuse

En tant que développeur en Python pour le boulot, je confirme tout à fait ton point de vue. J'ai justement choisi Python pour aller droit au but sans me laisser distraire. Pour les loisirs ou r&d ça m'ennuierait sûrement.

Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

Le typage est un critère de maintenabilité ? Pour un compilateur peut-être, pour un humain c'est déjà moins sûr.

C'est plutôt la concision et la clarté du code qui compte. (cf l'étude d'IBM qui fait un rapprochement tout bête entre le nombre de lignes et le nombre de bugs).

La disponibilité d'un IDE potable me semble aussi un minimum si on veut que les développeurs se concentrent plus sur le fond que la forme (autocomplétion, refactoring, affichage des erreurs à la volée)

De la même manière, plus le code va être concis, explicite et clair, moins l'ide va avoir d'importance.

Oui, c'est un casse tête quand il y a beaucoup de parties dynamiques...

Une solution que j'utilise maintenant, en complément, c'est de générer (à la volée toujours) un certain nombre de données dans des fichiers html ou json qui sont appelés en javascript/ajax.

Même question pour la base de données. Est-ce un choix technique ou une préférence personnelle ?

Si mes souvenirs sont bon, la version actuelle avec templeet utilisait (je ne sais pas si c'est toujours le cas) la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj. Personnellement j'utilise ce système très souvent, avec nginx et une appli en proxy (python) c'est redoutablement simple et efficace.

Quel système de cache est utilisé dans cette nouvelle version (et qui devrait rendre caduque les questions sur la rapidité du langage...) ?

C'est justement parce que l'on n'a pas la patience de "tout essayer à taton" que l'on trouve beaucoup plus efficace de ne pas changer d'éditeur au grès des modes.

Est-ce que les djeuns utilisent les crayons gris ? Il va bien arriver un moment ou ils risquent d'être considérés comme obsolètes, non ? Non.

ocase avec un seul C ça fait vraiment moche...

On commence à trouver des Txxx d'occasion. Mais je me pose la même question que toi, est-ce que la fiabilité, le bon clavier, l'écran mat etc sont toujours d'actualité sur ces modèles ? Est-ce que dans la concurrence il y a un équivalent aujourd'hui ?

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é !