Bruno Michel a écrit 3285 commentaires

Ou sur http://linux.noumba.net/ ou encore sur jabber.

Je te souhaite la bienvenue sur LinuxFr.org.

Je te conseille la lecture de http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsLecteurL(...) qui permet de mieux comprendre comment LinuxFr.org fonctionne.

Il faut avoir au moins 10 points d'expérience pour poster un journal. L'expérience n'est pas affichée sur le site, mais comme je suis admin, je peux te dire que tu as actuellement 5 XP.

Après recherche sur internet, il semblerait que le participe passé de se rendre compte est toujours invariable, mais je n'ai pas compris si cela faisait parti d'une règle plus générale ou si c'était une exception.

OK. En fait, LinuxFR.org respecte les standards du web (au moins sur ce cas), mais il y a effectivement un problème d'ergonomie. Il existe une entrée dans le tracker sur ce sujet : https://linuxfr.org/tracker/344.html .

Les comparaisons de chaines de caractères avec ==, ca ne va pas marcher.

Pourrais-tu dire en quoi LinuxFR ne respecte pas les standards du web ?

Je pense que le forum petites annonces correspond déjà à ce besoin : https://linuxfr.org/forums/45/ . Il faudrait peut être communiquer plus sur ce forum.

Techniquement, Mercurial est une copie de GIT en python.

Mercurial n'a pas copié sur git. Ils ont été créés en même temps, et chacun s'est inspiré de l'autre pour s'améliorer (ainsi que de darcs ou de bazaar-ng). Cette "concurrence" a été très bénéfique pour ces projets, et a notamment apportée de nombreuses idées (aussi bien pour git ou mercurial que pour les autres scm).

Par contre, JRuby on rails pourrait devenir rapidement une alternative valable. En effet, JRuby permet déjà de faire tourner rails, et les développeurs sont en train d'optimiser JRuby pour rails. En effet, les benchmarks montrent que JRuby est plus rapide Ruby 1.8 sur quasiment tous les domaines, mais pour une raison mystérieuse, JRuy est plus lent que Ruby 1.8 pour faire tourner rails. Le problème pourrait venir des regexps, mais ce n'est pas sur. Ce qui est sur, c'est que ca avance, et je conseille d'aller lire http://ola-bini.blogspot.com/ pour avoir les dernières infos.

Depuis, ils sont revenus sur leurs propos. En particulier, leurs problèmes de montée en charge étaient dûs à des problèmes d'architecture, et non à rails.

We hit some scaling stumbling blocks a few months back, but not because Ruby or Rails was working against us.

Source : http://twitter.com/blog/2007/06/under-hood-at-twitter.html

For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.

Source : http://highscalability.com/scaling-twitter-making-twitter-10(...)

A ma connaissance, rails et YARV ne font pas bon ménage. Ca devrait s'améliorer rapidement, mias pour le moment, assez peu d'applis en rails peuvent tourner avec YARV. Je doute donc que des sites à fort trafic utilise YARV.

D'autre part, je souhaite nuancer certains propos ci-dessus. Certes, RoR est assez mauvais en performance/conso mémoire par rapport à du PHP de base, mais les retours que j'ai eu sur les frameworks PHP utilisant un ORM sont loin d'être glorieux. Ils seraient même plus lents que RoR !

Sinon :

et quand je voit symfony, qui avec la même facilité, est plus puissant que RoR...

Joli troll, pas le moindre argument concret pour être sur que l'on ne puisse pas te contredire. Pour ma part, je ne connais pas assez Symphony pour le critiquer. Je trouve juste le code écrit en RoR plus lisible que l'équivalent écrit avec Symphony.

Tellement de pub que le serveur est tombé sous la charge (mais il est vire reparti).

Bah, si tu sais, pourquoi tu ne le fais pas ?

Quand suffisamment de monde sera intéressé par OpenID. Pour le moment, seules 10 personnes ont votés pour dans le tracker [https://linuxfr.org/tracker/457.html], et vu le boulot que ca représente, c'est nettement insuffisant.

D'autres part, OpenID semble poser des problèmes. Nous attendons des réponses à [https://linuxfr.org/comments/860880.html] pour nous convaincre ;-)

Vous savez ce qu'il reste à faire pour avoir OpenID sur LinuxFR.org.

Ce commentaire est posté en mon nom uniquement, mais je pense qu'il est partagé par les autres admins LinuxFR.org.

Les moderateurs/relecteurs habitent tous en Region Parisienne ?

Non, tous les admodérolecteurs n'habitent pas en région parisienne.

Un bon d'achat dans un pub irlandais, ca le fait ?

Oui, mais une partie de l'intérêt provient de la discussion qui va avec la Guinness (discussion à propos de LinuxFR ou d'un autre sujet).

Et pour ceux qui n'aiment pas la Guiness, un whisky ca le fait?

Je ne connais pas les gouts de toute l'équipe LinuxFR. Pour ma part, Guinness ou whisky, ca me va :-)

Pour les dons à LinuxFR, le moyen de payement privilégié reste la pinte de Guinness offerte à un admin (ou un modérateur/relecteur).

Linuxfr passera à OpenID quand un contributeur proposera cette fonctionnalité ou qu'il y aura suffisamment de personnes qui auront voté pour. Pour le moment, 6 votes, ca fait un peu léger vu que ca demanderait pas mal de boulot pour le faire.

Mettre les liens entre crochets a un avantage : ca évite les problèmes avec les virgules ou les parenthèses collées à une URL.

Je fais cela depuis longtemps, et j'aurais quelques petites remarques à faire sur le site, mais je n'ose pas poster sur le système de suivi, car je n'ai aucune certitude que ce que je prends pour des lacunes du site ne soient en fait le fruit de mon incompétence.

C'est pas grave, il ne faut pas hésiter à poster dans le suivi. Il est fait pour ca, et ce genre de remarques/remontées de bugs nous intéresse.

Merci pour le lien. Je ne connaissais pas, et leur offre à 10 euros me semble pas mal. Je pense que je vais essayer cela bientôt :)

J'ai aussi réussi à poster ce commentaire.

Le code que tu cites est obsolète. La documentation "introduction" décrit le
fonctionnement des versions antérieures. Le controler a évolué.

Tu peux te référer au manuel qui est à jour:
http://pmo.developpez.com/manuel/

Pour répondre à ta question concernant SQL

PMO tout comme PDO n'est pas la pour se substituer au langage SQL. PMO se
concentre donc sur son rôle crée une couche d'abstraction objet entre le sgbd,
et l'application.

La méthode getObjectByValue peut récupérer un Objet (et non enregistrement car
il embarque des méthodes) en fonction de l'attribut que tu désignes en
paramètre. Ca peut être login si t 'as une table utilisateur avec une colonne
login, tout comme ça peut être nomproduit si t'as une table produit, ou même
age si t'as une table personne etc ... PMO découvre le schéma de tes tables
dynamiquement, tu as donc des méthodes génériques.

Le nombre d'objets que tu crées en mémoire, dépend de l'optimisation de ta
requête. Si tu as une table avec 10000 enregistrements et que tu fais un
select * sans critère forcément tu auras un nombre d'objets ultra importants.
Et c'est clairement pas une bonne idée, si tu veux juste modifier un login ..

Par contre si tu fais un select * from utilisateur where login="toto"; t'auras
qu'un seul objet à manipuler ;) Les contraintes sont les même qu'avec un
mysql_fetch_row hormis que tu manipules des objets.

Pour le nommage setLogin, non étant donné que cette méthode est spécialisé à
une colonne login, alor que setAttribute te permet de manipuler n'importe
quelle colonne.

Pour le $user->commit(), cela fait justement parti des dernières évolutions
comme $user->delete();

Si t'es vraiment interressé pour soumettre des évolutions, n'hésite pas à me
contacter sur mon mail perso, ou sur la liste de diffusion google du projet.
Jusqu'à maintenant j'ai essayé d'implémenter tout ce qu'on m'a soumis.

Code34 : j'ai posté ton commentaire pour tester, et visiblement, j'y suis arrivé. Pourrais-tu me dire ce qui t'as bloqué et quelle(s) erreur(s) ont été retournée(s) par templeet ?

Je n'utilise pas les magiques car je ne trouve pas ça propre.

$pmo->login = 'nouveaulogin';
En terme de lisibilité, c'est mal, même si derrière ça fait appel à une
méthode et que la variable est protected.

La deuxième raison c'est que les objets de PMO sont extensibles, et que
l'utilisateur peut utiliser ces propres objets grace au polymorphisme.
Implémentation des magiques pour d'autres fonctionnalités.

Comparaison:
$pmo = pmo_record::singleton()->get_by_login('ancienLogin');
$pmo->login = 'nouveaulogin';
$pmo->commit();


Le code PMO actuel
$object = $map->getObjectByValue('utilisateur","login","ancienLogin");
$object->setAttribute("login","nouveaulogin");
$object->commit();

Etant donné que cela fait quand même plusieurs fois qu'on me soumet cette
évolution, je vais tout de même y réfléchir.

Au niveau de la méthode singleton, cela est implémenté de cette manière:
$object = $controler->createObject("utilisateur");

Le controleur va créer l'objet avec les bons attributs initialisés à blanc. Il
est fort possible que dans la prochaine version la méthode create soit intégré
dans l'objet

$object->create('utilisateur");