thedude a écrit 2062 commentaires

hop hop hop.
Deja je suis pas pour plus de regulation.

La regulation me parait pas mal:
- subventionne par l'etat = cense etre de la culture = acces de la culture a tous et ocup de pouce pour les artistes en chiant, donc pas de business effrene sur le prix des places. C'est cense etre un tremplin pour les artistes non mainstream, pour resumer un concept vague en 3 mots pas tres clairs.
Faut quand meme en vivre, mais c'est pas une industrie. Je ne considere pas muse comme un artiste ayant besoin de ca, la question dans ce cas est donc: s'ils ont eu une subvention, what the fuck?
Le prix est contraint, mais ya des sous publics, ca parait normal.

- pas subentionne par l'etat: prix libres. Et la ton argumentaire s'ecroule. Le black n'a aucune raison d'etre. La concurrence entre les revendeurs laissera les places a un prix decent. La concurrence entre revendeurs evitera de devoir chercher des heures pour se faire mettre sans vaseline ni gros sel.

Non, ce black n'a rien de normal. C'est un pur parasitage.

Si probleme il y a ici, c'est des organisateurs profitant des subventions qui au final leur pourissent le marche.
Peut etre etant qu'ils ne pourraient pas vivre sans ses subventions. Mais c'est une problematique differente ca.
Le probleme c'est pas la regulation des billets subventionnes, c'est l'attribution meme de la subvention en premier lieux..

C'est quelque chose de courant par chez nous enfait, un autre tres bel exemple est le milieu du parachutisme qui a ete serieusement pourri par les subventions, l'associatif bidon etc.

Pour faire court, les clubs se montaient initialement en assoc 1901 pour profiter des avantages fiscaux et des subventions.
Un avion ca coute cher, le matos para aussi, c'etait initialement la seule facon d'offir une prestation a un prix correct aux adherents.
Ca marchait tant que l'esprit associatif primait.
Ensuite, ca c'est professionalise (normal, c'est l'evolution naturelle). Certains ont voulu en vivre decemment. Mais c'etait pas trop possible sans les subventions, initialement.
Puis le tandem s'est developpe et c'est possible aujourd'hui d'en vivre a plein temps.
Le probleme: subvention = asso (theoriquement non, mais en pratique oui) = pas de travail sinon requalification fiscale et paf, plus rentable.
Le black c'est develope, initialement pour bootstraper le milieu on va dire. Puis ca a continue parce "on a toujours fait comme ca".
Sur le court terme, ca va. Sur le long terme c'est une cata, les pro du milieu ont un salaire de merde, aucune assurance sante, aucun chomedu, tu peux mettre la moitie du milieu pro para en taule pour fraude fiscale, le black a tellement tire les prix vers le bas qu'il devient presque impossible de se faire une place en etant declare, le fisc a fait un joli coup de filet dans les gros clubs associatif (genre redressement de qq millions quand meme...).

On pourrait dire que la reglementation fiscal n'est pas bonne. Mais non, c'est pas ca le probleme. Le probleme c'est le detournement d'un statut et de subventions pour un but different de ce a quoi ils sont destines. Le milieu s'est pourri lui meme en tentant de faire du business avec un statut qui est clairement fait pour ne PAS faire de business (ou en tout cas le rendre difficile).

Sinon, tu termines encore avec un parallele foireux. Le hashcich et l'alcool sont (etait) interdit. Et c'est ca qui a cree le marche parallele.
Il n'est pas interdit de faire un concert, ni de vendre les places au prix que l'on veut.
Sauf si on est subventionne. Mais c'est l'organisateur qui cree la situation du prix fixe, pas la regulation.

...
On vient de passer de "je prends des places en plus pour les potes mais je sais pas qui" a "finalement empechement de derniere minute, j'y vais pas".
Pas trop le meme use case.

Pour ce cas de figure, il ya un truc qui s'appelle "assurance annulation".
Quand ton couple bat de l'aile et que tu fais un week end pour tenter de le sauver, c'est generalement intelligent de prendre une assurance annulation.

c'est juste la conséquence d'une volonté de réguler à la con.
Non, c'est tres precisement la consequence d'un marche sans aucune regulation: le black.

Au black, on ne paye pas de tva.
On fait ce qu'on veut (y compris s'arranger avec les autres pour garder les prix haut).
On n'est pas declare, donc on ne paye pas de charges.
Ces frais en moins faussent la concurrence (benefices indecents).

Ce systeme est asocial (on baffre tout et on cotise pas a la secu).
Le black, c'est de la merde. De la grosse merde. De la perte pour la societe et une vision a court terme pour celui qui la pratique.
C'est tout le contraire d'un marche regule ce qu'il faut pour mettre tout les acteurs a egalite et en concurrence.

Je rappelle que la loi en question ne s'applique qu'aux concerts subventionnes.
Je doute que muse soit subventionne.

Comparer la vente de billets d'avion avec la vente de billets, c'est assez incongru t'avoueras...
Cas legitime? Tu connais ne serait ce qu'une seule personne qui prend 4 billets d'avions en se disant qu'il trouvera bien 3 potes pour venir en week end avec lui?
Autant c'est tres courant pour les concerts, autant pour les vacances, faut etre un peu tordu pour faire ca, non?

BOpf.
Tu verifies les papiers de chaque personne allant au concert?
Comment fais tu pour gerer les cas de reventes legitimes (ie pour une valeur inferieur ou egale a la valeur faciale?

Exemple de base: concert de machin, je sais que sur tous mes potes yen a au moins 3 qui vont etre interesses.
Je prend 4 places, mais je sais pas pour qui sont les places.
C'est des potes, je leur revend les places au prix que je les ait acheter.

generalement, quand les gens s'organisent pour bosser au black, c'est pour deux raisons:
- c'est une pratique, eventuellement illegale, qui paie bien, voire tres bien, quand c'est fait au black, mais qui est (serait) comme n'importe quel autre business quand c'est fait dans les regles.
- c'est une pratique qui rapporte tres peu, mais c'est fait par passion, d'ou le black pour tenter d'en vivre.

Je doute que les mecs restent a l'entree des bouches de metro par passion, donc il reste la premiere option.

Personne ne fait quelque chose d'illegal si ca ne rapporte pas.
Et on ne voit pas d'organisation illegal se former si ca ne rapporte pas.

Ton raisonnement est bel et bien, mais la pratique dit que si le risque etait si grand au black, on ne serait pas dans la situation actuelle.
La prise de risque sur un concert tel que muse est tres probablement quasi nulle: la salle sera pleine, tout le monde le sait.
Apres, c'est sur que si tu vends au black des places d'yvette horner...

J'ai du mal a suivre ton raisonnement dans ce cas precis.

Le vendeur au black n'apporte aucune valeur ajoutee.
La valeur ajoutee ici, c'est billetel, via son reseau de revendeurs, qui la cree.
Ce sont EUX et uniquement EUX qui cree la valeur ajoutee de revente au particulier.
Ils sont presents partout,de la boutique a 'ternet, et vendent a quiconque veut une place.

Le marche noir fait tout pour diminuer l'opulence de place et s'arrange pour que les points de revente soient tres precisement durs a trouver: on cree une rarete, faut en chier pour la trouver sa place, sinon tu la paierais pas 3 fois son prix.
Longtemps avant le concert, tout est fait pour que la place soit introuvable.
Si elle est introuvable, elle est chere et le revendeur a moyen de pression.
Non seulement le revendeur n'apporte pas la place a l'acheteur, mais en plus il fait tout pour que justement, ca soit pas facile a trouver. Ou est la valeur ajoutee la dedans?

Juste avant le concert, le temps jouant, le revendeur a encore moyen de pression: ca commence bientot, yaura bientot plus de place etc etc.

Bref, on est clairement dans un cas d'emprise mafieuse sur un systeme plutot sain a la base.

Rajoute a ca la fraude des revendeurs au black (TVA, travail non declare, loi machin sur la valeur faciale), j'ai du mal a comprendre que tu trouves ca normal.

Que les revendeurs au black s'organisent en gros, qu'ils soient tous connus et identifies, s'acquittent de la tva, tu sais ce qu'il va se passer?
Ils vont se mettre en concurrence et hooooo!!! Magie!!! Les places vont revenir a leur prix normal...

Ta comparaison avec la RDA ne tient pas.
Ici le prix n'est pas "pas cher, pas cher", ca reste l'organisateur qui l'a fixe, c'est un juste prix: il couvre l'investissement (donc fait bouffer du monde) et permet de faire bouffer celui qui investit.
Et il ya des produits en vente, les gros concerts, c'est courant quand meme.
Au contraire, si on doit faire une comparaison avec la rda, je dirais plutot que c'est le revendeur qui tient le role du communisme: il organise la rarete pour avoir du pouvoir sur le client. A la difference du gouvernement est allemand, il l'utilise ce pouvoir pour l'argent et non pour la soumission du client, mais le schema de raisonnement est le meme.

ouaip, effectivement, je me suis un peu enflamme avec la regie.

L'idee que j'avais, c'est que le concerteux a un budget fixe, et que si le prix de la place a triple, ben ca fait autant de sous qui ne partiront pas en bieres, tshirt.
Mais a moins que la regie de vente de places gere qq chose a l'interieur des salles, ils perdent pas grand chose.

Toujours est il qu'ils investissent en pub etc, pour au final ne retrouver qu'une partie de l'argent investit dans le concert par le client: meme si c'est ne techniquement pas "se faire enfler", on pourrait le voir comme ca.

certes.
Apres, forcer le constructeur a prendre les arguments, ca pose des problemes pratique:
- Quand ton objet a un gros nombre de membres obligatoires, v'la la gueule du constructeur... 15 parametres au constructeur, c'est pas humain.
- Ca rend le code absolument illisible. Surtout quand nombre des membres ont le meme type (genre string). T'as une probabilite de te planter quand tu construit manuellement l'objet qui est tres proche de 1. Et pour la relecture, bon courage.
- Tu rajoutes un attribut, t'as *tout* ton code qui pete.
- Ca fait exploser le code du constructeur. Tu te tapes en enorme if(param1 == null || param2 == null ....) throw new IllegalArgumentException("Param1, param2 ... must not be null").
Et si en plus tu veux une exception au message pertinent, ben ton constructeur vient de prendre 56 (15 * 4) lignes pour rien.

Et en pratique, des classes avec 15 membres obligatoires (ou plus meme...), ca se voit regulierement.

Ca c'est pour les problemes les plus simples.
Je sais pas pour les autres langages, mais le concept de bean en java est quand meme largement repandu, parce qu'il apporte beaucoup de souplesse et de genericite.
C'est plus simple de construire un objet vide et de lui setter ses properties a la ligne d'apres dans le code que de devoir deviner quel parametre va ou en fonction de son nom.

Alors on fait une entorse a la theorie, parce que c'est ingerable sinon.

Ouais.
On peut aussi leur casser les 2 jambes. Ca marche bien aussi.
Ou utiliser la "sulfateuse d'agrigente". Efficace (mais un peu bruyant).

(quoi comment ca, expeditif?)

Faut voir.

C'est quand meme un sacre parasitage: le revendeur au black n'en branle pas une, il investit juste un peu et recupere 2 fois sa mise en cadeau bonux.
Apres, si c'est un enorme fan qui a acheter 2 places et en revend une sous le manteau pour rembourser la sienne (ou parce que son compagnon de concert le lache au dernier moment), c'est plus comprehensible et ca va de toutes facon etre dur a eviter, encore plus a detecter.

Si le marche parallele trust toutes les places et qu'au final, le plupart des places sont vendus a de revendeurs douteux qui n'ont cure du concert en question, ca va pas trop leur plaire de voir leur vrais client payer 3 fois le prix normal.

Et ca doit pas trop plaire aux groupes/tourneurs non plus, qui se font serieusement enfler, ni a la regie de vente de places qui se fait aussi enfler serieusement, bref, dans l'ensemble, je doute que quiconque dans le milieu ne voit ca d'un bon oeil.

Mais un site web avec systeme d'achat en ligne et tout, ca m'etonnerais *beaucoup* que ca soit vu avec clemence.
Bref tout est question des proportions que ca prend.

Soit.
On a avait deja des preuves tangibles, maintenant on en est sur:
Tu es un couillon d'etudiant qui croit tout connaitre.

Sur ce, on se retrouve dans 5 a 10 ans, on reparlera du meme sujet, tu auras change d'avis.
Bonne continuation, et bon depucelage.

non, meme si tu changes de pseudo, on te reconnaitra si tu dit toujours les memes conneries.

J'attends toujours les explications quand a:
- les problemes de qualite d'hibernate (code illisible? bugs? perfs? archi pourrie? merde il a rien de tout ca)
- ta solution super efficace mieux qu'hibernate.

ah.
Ben pourquoi ils se sont fait chier a implementer Spring en python et a mettre l'IoC en tete de liste des features, si ca se fait naturellement par construction du langage?

Non, mais la, serieusement, le concept meme d'IoC et d'AOP, va falloir que vous m'expliquiez comment ca se construit par le langage, vu que le concept meme du truc, c'est d'etre totalement externe a la classe traitee et entierement dependant d'un contexte d'utilisation (ie une config de l'appli).

Pour le reste de spring, en vrac la gestion des pools de connexion db, la transactionnalite et la secu (authent notamment) , serieux expliques moi comment on met tout ca dans le langage?!?

wow.

Je pense que t'as pas compris grand chose au concept vu ce que t'en dis.
Comme j'ai demande plus haut ,je vois pas comme la DI peut etre integree dans le langage, vu que le concept meme du truc, c'est en gros:

Une classe se base sur certains objets (dont l'implementation peut etre remplacee) pour faire ses operations.

L'exemple de base, c'est un service qui a un besoin d'un DAO pour recuperer ses objets depuis la db et ensuite en faire ce qu'elle a faire.

Demander au service d'instancier en dur sa dependance, ie le DAO ici, ca pose de gros problemes.
Le premier evident etant que si ton DAO est thread safe, ce qu'on espere tous, c'est plutot idiot et meme dangereux d'en instancier plusieurs.

Conceptuellement, ton service n'a pas a savoir comment ton dao est architecture, il ne possede pas le dao, se contente de l'utiliser. Un autre qu'il possede encore moins, c'est la config du dao (host db, login pass et ce genre de conneries).
Et la pour le coup, la derniere chose que tu veux faire, c'est que ton service ai a connaitre tout ca.

Ca va te donner, dans le constructeur du service:
monDao = MonDAOORacle(hots, login, pass);

et si tu passes a pgsql, faut que tu passes dans tous tes services et que tu changes par
monDao = MonDAOPGsql(host, login, pass);

C'est ballot quand meme...

C'est encore plus idiot de demander a ton dao d'instancier les services, ca le lie a un composant qui lui est totalement etranger. Son boulot, c'est de cracher des objets depuis la db, et de les y remettre, c'est tout.

Bref, le probleme est donc: comment faire pour que les dependances du service soient satisfaites?
Le service ne peut pas creer le dao, mais le dao ne peut pas creer le service.
Ben la solution c'est que ces objets n'ont pas a gerer leur dependances puisqu'ils n'ont pas, et n'ont pas a avoir, l'information necessaire. Par contre, une classe externe, dont le but est de gerer tout ce merdier, elle a l'information et le contexte elle, et peut donc coordoner tout ce bordel.

Ton dao est un singleton? Tres bien, spring va t'en creer une seule instance et la donner a tout le monde.
FInalemet singleton, c'etait pas une bonne idee et tu refactores le DAO?
Pourquoi le service devrait connaitre les details d'implem du DAO? Il se contente d'appeler des methode publiques dessus.
Pas grave, tu changes un attribut dans la config de spring, et chaque service aura son instance a lui.

Le client a un sursaut de decence, et il passe la db d'oracle a PGSql?
Pourquoi le service devrait savoir quelle db stocke le tout? il travaille avec des objets lui, pas des relation!
Ben tu changes l'implem de ton dao dans spring et ca roule.

Tu fais des tests unitaires et ton DAO est en fait un simple mockup? Pourquoi est ce que le service devrait avoir connaissance de l'existence meme de tests unitaires?
Allez hop, tu changes l'implem de ton bean dans spring et paf, ton service n'est meme pas au courant qu'il parle a un dao bidon.

Et sans toucher la moindre ligne de code.
Ton service a besoin d'un DAO et il se fout eperdumment de savoir d'ou il vient. Et tant mieux, peut importe d'ou tu viens, dis moi plutot ou tu va.
L'archi du dao ne fuit pas dans le service, celle du service ne fuit pas dans le dao, tout le monde est isole et ton appli est plus simple a maintenir, modifier et a developper.

Ca t'eclaire un peu plus sur le DI et l'IoC en general?

Apres, spring, ca se limite pas qu'a ca non plus, mais ca reste un de ses usages premiers.

mouais...

Pratique, c'est pas faux, élégant, j'en suis moins sûr.
tu parles de l'IoC en elle meme ou de la facon dont spring le fait?

A quoi ca ressemblerait si c'etait dans le langage (ie sans workaround?) J'ai du mal a comprendre comment tu peux integrer ce concept au langage sans soit casser le decouplage offert par l'IoC, soit pourrir ta classe injectee avec des trucs sans rapport.
DIsons que le concept meme de l'IoC c'est de declare/effectuer les injections en dehors des classes concernees.

De meme, comment tu ferais pour gerer la distinction prototype/singleton (desole le terme est pas adapte ici, mais l'adapte ne me revient pas), avoir plusieurs instances des beans injectes etc?

Pour le cote usine a gaz, je te trouve tres dur avec spring.
Je connais pas webflow, donc je m'abstiendrais de commenter dessus.

Garde a l'esprit tout de meme que jee, spring et tout ces machins compliques, ca a un objectif: rendre des trucs tres complexes possible.
Pas rendre le dev web simple, pas etre simple a utiliser, juste rendre une enorme appli metier faisable.
Si tu veux qq chose de simple, jee n'est clairement pas le bon choix.

Donc ouais, ya plein de couches, c'est un peu le bordel, mais sans ca, ca serait un bordel bien plus grand a gerer.

En pratique, spring (en particulier) j'ai aucun reproche a lui faire, il m'injecte mes beans la ou je veux, ca me donne un point central pour les declarer, et vu comment l'appli devient touffue, je suis plutot content de declarer mes services/repository/assemblers de facon externe a l'appli, sans pour autant les transformer en singleton.
Pour ce qui est de devoir debugger dans les couches de spring, soit tu as rate qq chose, soit je comprends pas ce que tu veux dire. Ca doit etre le framework web le moins intrusif et qui gene le moins le debuggage que je connaisse. J'ai peut etre pas compris ce que tu veux dire cela dit.

Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème.
???
On a le mapping de nos domain objects sur les objets eux meme via les annotations eeeeeet....
C'est tout.

@entity(table="plop")
@OneToMany(joinColumn="shaby")
@Column(bla)
etc.

On se prend parfois un peu la tete pour arriver a ecrire le mapping (mais bon, avec hibernate t'en chies un peu au debut, puis les meme pb reviennent, tu sais donc les resoudre et ca va vite au final).
On a un systeme de filter pour les recherches qui utilise HQL. Bref, la partie repository dans notre appli, c'est getFromId, saveOrUpdate, delete et 50 lignes de construction de requete HQL.
Apres que tu kiffes le SQL, ok, c'est ton droit le plus fondamental, mais quand tu vois la db purement comme une facon de persister ton graphe d'objet en ram, c'est agreable de ne (presque) pas y penser.

Tu aimes peut etre certes ca, c'est cool, mais dans la plupart des cas, une requete sql c'est juste "bon ben, db, tu prends toutes ces lignes la, et eventuellement tu me choppes les autres lignes dans cette table avec le meme id et aussi dans cette autre table, pis apres tu me tries ca comme ca. Merci". Les cas ou le sql est rellement interessant sont pas si courant, et la plupart du cas c'est juste du boiler plate bien relou.
Rajoutes par dessus la problematique du cache et celle de la mise a jour du graphe persiste a chaque modification, ca devient dur de trouver des arguments au SQL pur.
By the end of the day, tout ce que veut, c'est un set d'objet de toutes facons, donc etre oblige de passer par un langage pas du tout adapte aux objet pour ca, je trouve ca particulierement casse bonbons.
Et c'est vraiment ce qui me gene dans le sql avec les langages objet: t'introduis un paradigme relationnel qui n'a strictement rien a voir avec l'objet.

c'est beau un colleur d'affiche.

Donc sego merite une medaille pour avoir gagne sa region a une election ou toute la droite s'est prise une deculottee, le vote sanction, alors qu'elle a laaaaargement ete aidee par ce vote sanction (mange t il au fouquet's ce vote sanction?).

Par contre, quand sarko gagne une election a la sueur de son front, et fait un joli score au premier tour, faut relativiser, c'est pas pareil contexte, tout ca, il a ete aide blabla.

non, c'est faux.

La gpl est le contrat passe entre les dev initiaux et le redistributeur.
Ce contrat force la distribution des sources avec le binaire.
Si cette clause n'est pas honoree (ou que, par exemple, le binaire est redistribuee sous un autre licence), la seule personne qui peut faire appliquer la gpl, c'est le developpeur.
Et en l'occurence, ce que dit la gpl, c'est que si tu ne peut/veut pas redistribuer les sources, et bien tu arretes de distribuer le binaire. Point.

Donc, legalement, quand qq1 redistribue sans honorer la gpl, il lese les developpeurs, pas les utilisateur, parce que les utilisateur n'ont pas signe la gpl.

Quand au troisieme larron, celui qui a recu le binaire sans les sources, il n'a pas signe la gpl, et il peut pas faire grand chose, en tout cas pas selon les termes de la gpl.
Reste l'attaque pour contrefacon.
Ce qui ne lui donnera pas le droit au sources, et encore moins sous gpl.

Bah, ben tu vas nous expliquer ou est le manque de qualite dans hibernate alors.

Et puis tant que tu y es, tu vas aussi nous fournir un exemple de mapping DB/Objet, de plus de 4 lignes, fait par tes pitites mimines, qui:
- abstrait integralement du sgbd sous jacent comme hibernate le permet. Genre tu coupes ton serveur, tu passes d'oracle a mysql et tu relances.
- offre les perfs d'hibernate (je pense notamment au 2nd level cache)
- maintient ton graphe d'objet a jour automatiquement (genre les delete orphans etc)
- ne contient pas une seule ligne de SQL
- se configure quasi exclusivement directement dans le code (je suis gentil, t'as droit a un fichier de config pour les connexions db et un autre pour declarer les classes qui sont mappees).

tu ne m'as pas insulte personnellement, mais ton message precedent est un insulte a l'intelligence...

Sans compter que "mon con", c'est une tournure certes tres familiere, mais surement pas une insulte...
Une peu comme "ben mon cochon" si tu veux.

Ça n'intéresse vraiment personne à part les extrêmes libristes, le Hurd??
Mon petit doigt me dit que ce qui n'interesse pas les personnes competentes, c'est pas tant le hurd que le combat contre les moulins de don rms et sancho gnu.
Et peut etre aussi le fait que le personnage a pas l'air franchement agreable en tant que collegue, ni l'air d'etre un bon chef de projet.

mouarf...

Ben ecoutes mon con, c'est bien pour toi, si tu consideres que xmlhttprequest est equivalent au RemoteServices de flex, que se taper le parsing du xml en retour c'est pareil que d'avoir un mapping objet via amf, que de se hacker du html douteux pour en faire qq chose pour lequel il n'est pas fait (genre des tableaux, des grids etc), si tu trouves ca cool de hacker une balise <a href> avec du javascript et au moins 3 styles css pour singer un bouton, ben ecoutes, grand bien t'en fasse!!!

Si t'es pas foutu de voir l'interet de container haut niveau pour gerer des formulaires, des tabs, des accordion, des dividedbox ou autre, ni de voir que leur equivalent html est un hack immonde, je me dit que tu dois pas capter grand chose a ce que tu vois.
De meme, pour passer a cote des evenement de flex, genre propertyChange et collectionUpdate pour ne nommer que les plus utiles, faut etre sacrement aveugle.
Et je passe sur les qualite du MXML qui permet de se faire une UI riche et dynamique en quelques tags.

Bref, tout ca pour dire autant je comprends qu'on critique flex sur l'aspect politique, autant sur l'aspect purement technique, faut etre un gros boeuf endoctrine pour dire que n'importe quel framework JS de base fait de meme.

sisi, bien sur pour les cookies flash. Qui ne sont d'ailleurs pas des cookies.
Mais pour le savoir, faut se renseigner, et faire un clique droit sur un film flash, settings (ah les salauds, ca a ete bien planque!!!) et ensuite t'as le choix pour la taille max des shared objects, par site et tout et tout...

C'est toi qui est genial...

Cette page, elle propose de lancer une appli AIR (la version "native" de flex, en clair: la meme chose mais en dehors du browser). Cette appli AIR, c'est un showcase des possibilite de flex. En clair: une demo technologique pour presenter ce qui est faisable en flex, code source a l'appui.
Ton alternate content il a pas trop de sens dans ce cas precis, parce qu'il n'y a pas de contenu, mais une application interactive...

Et le film flash en question, c'est juste un installeur de la chose en question.
Le flashmaster en question n'en a donc rien a foutre des utilisateurs qui ne veulent pas installer flash, precisement parce que son site s'adresse a ceux qui veulent installer flash...

non cette performance n'est pas a relativiser.
C'est sarko qui a fait en sorte que les conditions soient differentes, tu crois pas?
Alors oui, il avait un terrain favorable, c'est surement parce qu'il s'est demerde pour le creer ce terrain favorable.

Royal pouvait elle aussi commencer a travailler des 2002 sur son election en 2007.
Ou alors c'est encore la faute a quelqu'un que sego a pas reussi a faire ca?