LeBouquetin a écrit 1923 commentaires

Dans tous les cas je penses qu'il faut pas non plus être hypocrite : ça doit rapporter plus gros de vendre tout un album qu'1 ou 2 titres.

Je pense que tout le monde est d'accord. Mais vendre les morceaux "à l'unité", ça permet de toucher des clients qui n'achèteraient pas l'album entier.

elle se démarque par son utilisation d'une distribution basée sur Debian GNU/Linux, ses quelques plus techniques et son prix réduit

Et une autonomie annoncée quatre fois inférieure. C'est pas négligeable pour un outil qui est censé être mobile...

Je vous demande de vous arrêter !

s/Maghreb et//

Aucun des pays que tu cites n'est dans le Maghreb... :-p

Il y a pas mal d'autres moteurs de recherche ; Exalead notamment.

Au premier démarrage de l'application ça ne paraît pas complètement stupide.

Exact. Mea culpa.

Pour préciser un peu Turbogears 2 ; il est basé sur :
- Pylons pour la partie web,
- SQLAlchemy pour la partie "abstraction de base de données"
- Genshi pour les templates HTML
- ToscaWidgets pour la génération / validation de formulaires
- repoze pour l'authentification

Tout ceci est "par défaut" ; il est tout à fait possible de changer les technologies sous-jacentes en fonction de tes besoins / connaissances.

Personnellement, je vois TurboGears comme un "packaging" de différentes technologies qui sont au top dans leur domaine. Ca rejoint un peu la philosophie Unix : une agglomération d'outils qui font une seule chose mais qui la font bien.

J'avais fait un comparatif l'an dernier pour le boulot pour savoir quelle solution choisir. Les contraintes étaient :

- utilisation de notre technologie disponible sous forme de bibliothèques dynamiques,
- utilisation d'un ORM pour s'affranchir (autant que faire se peut) de la couche SQL,
- services web en SOAP,
- application web d'administration,
- Réutilisation maximale du code entre les différentes applications (on a développé un SI qui tourne avec une trentaine de machines, gérant chacune des services spécifiques).

PHP, on l'a mis de côté, notamment parce l'utilisation de bibliothèques dynamiques nécessite de coder des plugins (pas en langage interprété).

Finalement on utilise :
- TG2 pour la partie application web. L'intérêt c'est notamment qu'il utilise des modules indépendants comme SQLAlchemy pour la partie ORM qui est super bien fait (hormis des "problèmes" de cache pas toujours évident)
- CherryPy / Soaplib pour les services SOAP (et suds pour la partie clients SOAP)

Ca permet notamment de réutiliser SQLAlchemy sur tous les logiciels qu'on a du développer, que ce soit pour les démons de backoffice, les services SOAP, les applications web.

Si tu te limites au "web", je ne sais pas si python est le plus adapté, si tu fais un peu de tout, clairement c'est une force. Notamment pour ses capacités d'introspection.

Un exemple : on a une classe qui centralise tous les codes d'erreur et les messages associés. Elle est utilisée "classiquement" par l'ensemble du code ; l'introspection permet également de générer à la volée une page web qui liste tous les codes d'erreur. Tout ça en ayant "codé en dur" les messages et codes d'erreur (j'aime pas le principe qu'un code d'erreur soit "paramétré dans un fichier : tu peux pas assurer qu'il ne sera pas modifié "involontairement" ou tout simplement "à jour...)

Les seuls points noirs avec python c'est à mon avis :

- qu'il n'est pas typé (ta variable peut être du texte, un objet, etc sans que tu puisses garantir qu'il restera toujours du même type
- Qu'il n'y a aucun moyen de savoir si ton code est valide à moins de faire des tests de tous les cas de figure. Exemple : un log mal formatté qui est affiché dans les cas vraiment exceptionnels ne sera pas détecté squf lorsque ce cas exceptionnel intervient (ie en prod dans un cas de figure improbable et ça te génère une exception qui peut potentiellement faire planter tes services).

Mais pour revenir au sujet original, TG2 est vraiment agréable à utiliser et super flexible.

Puisqu'il y a PostgreSQL, on se fout de l'avenir de MySQL !!!

Il me semble que les marchés adressés par ces deux SGBDR sont différents. Au boulot en tout cas on utilise les deux, mais pas pour les même applications.

J'ai rien contre java en particulier... mais ce que je connais de java c'est lourd par rapport aux fonctionalités. C'est peut-être plus "scalable", plus stable en montée en charge, mais ce que je recherche c'est pour des sites à faible visibilité ; une infrastructure java est (malheureusement) inadaptée.

Ca a l'air pas mal pour ce que je veux faire, cet outil. Je vais l'installer et l'essayer : la démo est vraiment trop lente.

Ça change quoi pour le gars qui insère son CD d'installation sans même mater ce que le disque contiens ?

Ca change que ton CD d'installation te propose des étapes différentes selon qu'il existe déjà des partitions sur le/les disques, même si le mec n'a pas même regardé.

Pour le fabriquant ça veut dire gestion de plusieurs chaîne de procédure et donc coût plus élevé.

Exact. D'ailleurs je pense que c'est la raison principale pour ne pas proposer ce service.

Tout à fait. Mais ça n'empéchait pas de proposer une version "pure", sans OS installé.

Je cherchais un outil de gestion de contenu pour site web pour créer le site web d'une association dont les membres ne sont pas informaticiens. J'ai testé TangoCMS, Drupal, Joomla et d'autres qui n'avaient pas les fonctionnalités requises. J'ai abandonné ces outils pour les raisons suivantes :


TangoCMS me plaisait bien, est sobre et simple à utiliser mais n'est pas encore internationalisé.
Joomla semble "pas trop mal", mais l'installation de modules est compliquée, et l'installeur très mal fini (c'est un euphémisme). Note: je suis développeur, j'aime bien les outils qui fonctionnent bien et gèrent les cas d'erreur.
Drupal - qu'on utilise pourtant au boulot, m'a effrayé à un point qui n'est pas permis. On s'y perd en modules, dépendances, etc.

Pour des besoins personnels, j'aurais sans doute tranché de manière différente, mais pour un utilisateur qui ne baigne pas dans les nouvelles technologies et qui souhaite un outil permettant de gérer des pages et quelques fils d'actualité/news/articles, l'outil le plus prometteur me paraîssait être TangoCMS, même s'il manque encore de fonctionnalités.

Finalement, je crois que je vais finir par proposer à l'association en question d'utiliser dotclear que je trouve plutôt simple d'emploi et complet en terme de fonctionnalités (manque juste à mon goût une "arborescence" pour les pages).

Liens :

dotclear - [http://dotclear.org]
TangoCMS - [http://tangocms.org]
Drupal - [http://drupal.org]
Joomla! - [http://www.joomla.fr]


p.s : je n'ai pas parlé de spip qui était à l'époque un projet très en vogue ; je ne l'ai pas ré-essayé.

p.p.s : j'ai pas trouvé comment indiquer la langue d'un lien lorsqu'on n'indique que l'url entre crochets...

Je l'ai reçue aussi. Je ne l'ai pas ouverte. Dans quelques dizaines années ça sera "collector" ;)

Pas besoin d'archiver des choses dont la bibliothèque nationale s'occupe déjà ; par ailleurs je pense qu'elle le fait certainement mieux que je ne pourrais jamais le faire.

Je répondais à ta phrase "Déja, regarde le nombre de personnes qui s'intéressent aux livres des années 20 rien que maintenant pour rigoler... " comme si "lire un livre des années 20" était réservé à une élite, comme si il s'agissait de livres historiques, rares, précieux. Ca veut rien dire lire un livre des années 20 ; à la base j'expliquais seulement que j'avais trouvé des bouquins, vieux, qu'ils étaient griffonnés et que ça m'intéressait qu'ils le soient. C'est tout.

Dans le second cas, je ne me fais pas le moindre souci. C'est d'ailleurs pour ça que je ne backup ni mes livres, ni mes cds. Je sais que si je les perds, internet les aura conservé pour moi.

Dans ce cas, perso je préfère acheter des livres ; le jour où j'ai besoin d'une version numérique je sais où la trouver :)

Dans les années 20 on lisait aussi des romans. Ceci dit je suis d'accord avec toi, je ne suis pas représentatif de la majorité.

Tu cherches sur internet. Bien souvent tu trouves des ventes d'occasion, tu peux aussi passer une annonce, voire demander à quelqu'un qu'il te le prête pour que tu puisses le relire (ou éventuellement le photocopiller).

Hop un verre d'eau et tu perds ton livre.

Jusqu'à présent, je n'ai jamais eu la malchance d'acheter un bouquin imprimé sur du PQ : les pages ne se délitent pas lorsqu'elles sont humides. Il m'est déjà arrivé de renverser eau, coca, et même du vin sur des bouquins ; les pages étaient frippées mais le texte toujours très lisible.

tu pense qu'un livre traverse les siècles mais tu le barbouilles, tu crois que quelqu'un d'autres va lire tes gribouillis de lecteur dans 100 ans?

J'ai acheté un bouquin des années 20 sur une brocante, il était barbouillé d'esquisses, il y avait même une dédicasse pour un anniversaire. Je suis très satisfait de l'avoir acheté tel quel, ça a même fait partie des critères d'achat (j'aurais tout aussi bien pu acheter la même histoire en version récente et "propre").

Je me suis sans doute emballé sur les siècles, notamment pour les bouquins grand public. Ceci dit, les fichiers "livre électronique", tu crois qu'ils vont durer aussi longtemps ? Tu crois qu'on saura encore les lire ?

Et supposons qu'on sache encore les lire, s'ils sont resté dans ton appareil (ie le livre électronique), tu pourras sûrement pas le connecter. Ton bouquin tu pourras toujours le feuilleter même si les pages se détâchent. Et s'il en manque (des pages), même, bah si ce sont des nouvelles tu auras toujours un certain nombre d'histoires à lire.

On parlait de voyager là, on ne parlait pas de déménager ; c'est complètement différent. Mais en réalité je réagissais surtout sur le fait de jeter un bouquin. Un bouquin on ne le jette pas : on le donne !