wilk a écrit 1159 commentaires

Et textile ? Peut-être pas pour les commentaires, mais pour les dépêches ça pourrait être appréciable.

NGINX n'est pas fait que pour les sites avec fort traffic, il est également particulièrement adapté aux petites configs genre serveurs virtuels. C'est peut-être de cette "mode" qu'il s'agit. C'est à dire de passer d'hébergements mutualisés avec php à des hébergement sur serveurs virtuels et des applis web en mode proxy pour utiliser autre chose que du php.

Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.

Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.

Bruno, tu as démontré que tu pouvais faire faire beaucoup mieux que la plupart des boites spécialisées. En tant que vieux briscard de la prog, je suis impressionné et je te tire mon chapeau pour cette mise en production.

Moi c'est le scrolling d'un commentaire nouveau à l'autre qui me donne le mal de mer...

Autrement dit il faut aller voir le code ?

Je préfère pouvoir importer à l'aide d'une API d'une part pour pouvoir comprendre l'outil et aussi parce que j'ai fait beaucoup de spécifs qui en ont besoin (par exemple de la réplication agence/siege, prise de commande à distance etc.) et j'aimerai bien voir ce que ça donnerait avec openerp.

J'ai également un peu de mal avec la doc développeur (que je n'ai fait que survoler je l'avoue). Par exemple pour commencer j'aimerai importer des données clients, produits, devis, factures etc... Je pensais utiliser xml-rpc, mais où se trouve la liste des fonctions accessibles ? Sinon je pensais taper dans la base postgresql, mais je ne trouve pas non plus de description des tables...

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.