Quand on parle du futur du web, deux choses (parmi tant d'autres) reviennent régulièrement...

Premièrement les adeptes du web sont pratiquement tous fan du "tout-en-ligne", on commence par mettre en ligne ses mails(Gmail, YahooMail, Hotmail...), ses bookmarks (del.icio.us, Diigo), puis on met en ligne ses photos (FlickR, Picassa), ses vidéos (Youtube, Dailymotion), sa musique (Deezer, LastFM)...

Cette possibilité d'avoir tout en distant revêt aux yeux des "geeks" d'énormes avantages :

• Le premier étant bien sûr d'avoir accès à ses contenus de partout dans le monde et sur un maximum de terminaux différents (aux questions de formats près).
• Le deuxième avantage à externaliser ses données est que beaucoup ont plus confiance (à tort ?) envers les serveurs des géants du web qu'en leurs disques durs quand aux questions de la sauvegarde de ses contenus (en plus c'est souvent plus économique).

Mais, à coté de cela, quand les geeks parlent du web de demain, il y a toujours quelques rabat-joie (dont je fais partie) pour nuancer les bienfaits du "tout-en-ligne".

En effet, en adoptant cette solution, vous abandonnez à 2-3 grands groupes (même seulement 1 si vous choisissez un combo Gmail, GoogleDocs, Picassa, YouTube) l'intégralité de vos données.

Cette concentration des données à de gros désavantages. En effet, même si l'on voit mal Google faire faillite l'an prochain, il est impossible d'avoir une vision à 10ans (il y a 10 ans Google naissait) voir 20ans (il y a 20 ans les premiers navigateurs web n'était pas nés) des grands du web.

Que deviendront alors vos données le jour ou Google et Yahoo suite à des problèmes financiers ne pourrons plus financer leurs millions de serveurs ?

Et dès aujourd'hui, combien on déjà "perdu" l'intégralité de leurs mails suite à un "bug" de leurs webmails (cherchez un peu sur le web et vous verrez que ça arrive plus souvent qu'on ne le croit).

De plus, cette concentration des données permet aux grands groupes du web, d'en savoir énormément (trop ?) sur vous.

Google (ça retombe souvent sur lui), analyse vos mails, vos visites (via son moteur de recherche), les pubs sur lesquelles vous cliquez (AdSense, Cibleclick), les tags de vos photos, de vos vidéos... Tout cela afin de "mieux" coller à vos désirs et de vendre toujours plus cher ses espaces de pubs aux annonceurs.

Quand vous "offrez" votre identité numérique à Facebook, vous mettez entre les mains d'une entreprise vos goûts cinématographiques, musicaux, votre liste d'amis, des photos...

Depuis quelque temps, cette concentration fait peur et de plus en plus de monde voit en google et les autres un Big Brother qui serais susceptible de savoir absolument tout sur vous !

Alors, ou aller ? Doit-on forcément se priver des avantages du "tout-en-ligne" si l'on souhaite garder un minimum de dépendance vis-à-vis des grandes entreprises du Web ou doit-on céder à leur règles au nom du progrès ?

N'est-il pas possible de concilier les avantages de ces deux mondes ?

Vos idées sont les bienvenues mais pour être franc, j'ai déjà la mienne et je vais vous la faire partager dans le billet suivant (Il est écrit mais je suis curieux de connaitre votre sentiment sur ce problème avant de vous donner le mien).

Le train est propice à la réflexion et au travail, j'ai donc profité de mes récents voyages pour écrire une série de billets sur des thèmes et un projet qui me tiennent à coeur. La mise en ligne de l'ensemble de nos ressources et notre contrôle sur celles-ci.

Cette série se divise en quatre articles (plus celui ci) sous la forme suivante :

1. Description de la situation et du problème ?
2. Peut-on solutionner le problème ?
3. Comment ?
4. Le projet

Comme promis (finalement j'ai été plus vite que prévu), je vais revenir ici sur les changements apportés par l'annonce récente de la libération des spécifications des formats swf et flv faîte par Adobe aujourd'hui.

Cet article va donc s'efforcer de détailler ce qui va changer, mais aussi ce qui ne changera pas suite à cette annonce.

Ce qui change :

Le player unique

C'est le principal changement apporté par cette nouvelle, d'autres players flashs vont être écrits et chacun va pouvoir écrire le sien.

Cette situation à des avantages, on va pouvoir avoir de bon player flash sur des plateformes non-supportés par le player officiel (64bits, MID...) ainsi que des mini-players (j'y reviendrais plus tard) et ses inconvénients, on va surement voir apparaître des problèmes de compatibilité de certaines fonctionnalités de flash sur certains players notamment à cause des plateformes (même si c'est déjà le cas avec le player officiel qui par exemple ne supporte pas le scrolling sous Mac).

Malgré quelques déboires à prévoir, c'est vraiment la révolution apportée par cette annonce, vos télévisions, votre portable, votre frigo... pourront bientôt embarquer un player flash quelquesoit leur architecture matérielle !

De plus dans son annonce, Adobe annnonce un énigmatique "Publishing the device porting layer APIs for Adobe Flash Player", qui selon les rumeurs, se traduirait par un player flash livré en deux parties. La première serait le player proprement dit (machine virtuelle, codecs...), et la deuxième serait une couche d'abstraction ("device porting layer") correspondant à l'architecture matériel hôte. Il suffirait donc de coder cette couche d'abstraction pour profiter du player officiel sur de nouvelles plateformes, à suivre, car cela limiterait en grande partie les problèmes de compatibilité...

L'accessibilité

Si le format SWF est ouvert, puisque finalement c'est bien de celà qu'il s'agit, l'accessibilité du flash va s'en trouver transformée !

En effet, les lecteurs d'écran et autres dispositifs destinés aux différents handicaps pourront intégrer leur propre lecteur (les fameux mini-lecteurs) et adapter la lecture des contenus Flash à l'utilisateur.

L'indexation

L'indexation est finalement un problème assez proche de l'accessibilité et de la même façon que les lecteurs d'écran pourront "lire" ces contenus, les robots fureteurs de Google et ses amis pourraient bien intégrer une version minimaliste d'un player flash capable de lire les différents contenus et donc, de les indexer.

Attention, l'accessibilité ne se résume pas à une question de formats (ouvert ou non).
L'accessibilité passe aussi notamment par des contenus "structurés". Un site HTML qui ne contiendrait que des "div" et une tartine de CSS n'aurait rien d'accessible !
En HTML, c'est les balises qui décrivent le contenu ( <p> pour un paragraphe, <h1> pour un titre de niveau 1 <h2> pour un titre de niveau 2 ...)
A ce titre, il faut espérer que flash intégrera dans ses prochaines versions un mécanisme de structuration des contenus afin d'apporter une notion de sémantique à ses contenus.

Les développements de contenus Flash

En libérant les spécifications des formats SWF et FLV, Adobe ne se contente pas de facilité leur lecture, ils vont aussi faciliter leur création, on peut donc imaginer que des Flash IDE et Flex Builder alternatifs devraient voir le jour ces prochains mois.

Pour le PDF, son ouverture avait permis son intégration dans un grand nombre de logiciel tiers avec la possibilité d'exporter son document en PDF, on pourrait pourquoi pas imaginer la même chose par exemple dans une plateforme de blog que l'on pourrait avoir soit en flash, soit en HTML (même si je ne souhaite pas voir apparaître de tel solutions notamment pour les problèmes d'accessibilité abordés juste au-dessus).

Ce qui ne change pas (pour le moment ? ) :

La sécurité

J'ai abordé dans un billet récent le problème de la sécurité du player Flash, celui-ci ne change pas suite à cette ouverture puisque le player reste lui propriétaire.
On ne sait toujours pas ce qui se passe dans celui-ci et les problèmes de sécurité sont donc toujours là, ils sont même plus présent puisque les plateformes "d'attaque" vont se multiplier.

Imaginez un nouveau virus qui passerait par une faille de sécurité de Flash, il ne viserait alors plus "que" les PC mais aussi les mobiles et autres dispositifs intégrant le player.

Par contre dans le cas de logiciels nécessitant une sécurité avancée, ils pourraient embarquer un des players libres amenés à sortir et donc limité les problèmes de sécurité.

Le streaming ?

C'est presque hors sujet mais à-priori, cette annonce ne fait pas mention du protocole RTMP, le protocole utilisé par Flash pour streamer de la vidéo et dont l'ouverture offrirait une myriade de possibilités.

Conclusion :

Selon moi, cette nouvelle est évidemment une excellente nouvelle même si elle ne va pas encore assez loin.

La première conséquence va être comme je l'ai expliqué, la prolifération de nouveaux players Flash et forcément, l'avantage N°1 du flash (la quasi absence de problèmes de compatibilité) va en prendre un coup.

Pour ce qui est de la "guerre" des applications web mobile, qui comprenait pour le moment Google et son Android et Apple avec l'Iphone, Adobe va surement devenir le troisième participant et la lutte s'annonce rude !

Enfin, ma recherche d'informations sur les blogs anglophone m'as également permis d'apprendre de nombreuses choses et notament des raisons qui se tiennent (plus que les miennes) pour expliquer la non-libération du player flash.

En effet, certains codecs audios et videos (comme le H.264 ou le fameux NellyMoser) ne sont pas libres mais également pas gratuits !
Adobe paye pour intégrer ces composants à son player.

La prochaine étape est donc de "remplacer" ces codecs par des codecs libres (il en existe pourtant tant de très bons ! Pourquoi avoir été chercher du côté des codecs propriétaires ? )

Et vous, vous en pensez quoi de cette annonce, vous êtes plus ravi de la bonne nouvelle pour les mobiles ou vous craignez les problèmes de compatibilité un peu partout ?

Alors, ça y est, c'est donc vrai ?

Les dirigeants d'Adobe lisent ce blog !

Pourquoi cet enthousiasme ?
Parce qu'Adobe vient d'annoncer la libération des spécifications des formats SWF et FLV (Annonce officielle), sous un projet au doux nom de Open Screen Project.

Il va me falloir un peu plus de temps pour décrire les conséquences réelles de cette libération mais on peut déjà imaginer que les players libres alternatifs (Gnash, SWFDec...) vont très rapidement refaire leur retard sur le player officiel.

Atention, Adobe n'as pas annoncé pour le moment la libération du player, mais juste des spécifications, mais si Adobe souhaite voir son player et pas un autre installé dans les différents "devices", ils le feront peut-être.

Aujourd'hui, Adobe à en fait mis les formats SWF et FLV au même niveau que le format PDF.
Le format de document est ouvert (mais pas libre pour le moment) et chacun peut créer facilement son lecteur PDF (et pourquoi pas le founir en open source ).
Les lecteurs officiels (AcrobatReader ou le Player Flash) restent eux propriétaires.

Ce sera tout pour aujourd'hui, un autre article examinant plus en détails les conséquences de cet acte arrivera dans les jours à venir (il est là).

Une chose est sûre, les conséquences sont lourdes, très lourdes !

P.S. : Tout ceci sera réel à compter de la prochaine major release (ils sors quand le player 10 ? )

Je viens de recevoir ceci :

Deux pavés d'environ 850 pages chacun qui ne sont pas près de quitter mon bureau

Ces livres ne sont pas à conseiller aux vrais débutants (qui iront plutôt vers celui-ci chez Eyrolles) puisqu'il ne s'agit pas vraiment de livre aidant à l'apprentissage, mais plus de "bible" de Ruby et de Rails qui vous donneront les outils et méthodes à utiliser pour un problème donné".

J'ai déjà commencé à fouiner un peu dans chacun et les problématiques abordées sont vraiment larges et pour certains plutôt pointues !
Je crois que vais bien m'amuser

Un sujet récurent sur ce blog et un de mes bouc-émissaire préféré, le player flash...
Ce tout petit logiciel installé sur parait-il, plus de 98.8 % des "Internet-enabled desktops" des "mature markets"[1], n'est pourtant toujours pas libre (Ah croire que les dirigeants d'Adobe ne lisent même pas ce blog :D)
Mais la vraie question, c'est pourquoi ne l'est-il toujours pas ? Et en discutant avec quelques amis plus flasheurs que moi, eux aussi se posent la question...

Après tout le player ne rapporte pas d'argent à Adobe et en ne le libérant pas, ils se coupent comme je l'ai déjà expliqué d'une partie des utilisateurs supposés de ce player et des architectures matérielles exotiques qui aimeraient en profiter (64bits...).

Pourtant, dernièrement une possible réponse m'est apparue. En effet le flash player est installé sur un nombre important de machine et même s'il est régulièrement accusé pour ses failles de sécurité, celles-ci restent bien cachées et peu exposées au grand public.
Pourtant récemment, c'est bien grâce une faille du player Flash qui a permis de faire tomber la machine sous Vista[2] lors du "PWN to OWN contest" (un concours visant à tester la sécurité des OS Mac OS Leopard, Windows Vista et Linux Ubuntu)[3], et si l'on se rend sur les différents sites (anglophones) traitant de sécurité informatique on peut se rendre compte que flash est souvent décrié sur ce point.

Le problème, c'est que quand un hacker cherche à prendre le contrôle d'une machine distante, il va chercher à exploiter une faille d'un logiciel installé sur celle-ci. Hors Flash est installé à peu près partout (je suppose qu'il y a plus de player Flash installés de part le monde que de Windows), cela en fait une cible idéale.

Le vrai problème est qu'il n'est pas possible à chacun (chaque OS ou chaque navigateur) d'implémenter sa machine virtuelle pour interpreté l'ActionScript.
Il n'existe qu'une (ou presque) machine virtuelle (la machine officielle) et lorsque l'on trouve une faille dans celle-ci on touche donc absolument tous les players flash de la planète( la dernière faille trouvée permettait de prendre le contrôle de la machine distante et était exécutable sur Mac, Linux, Windows et sur toutes les versions de Flash depuis la 7 ! )

Revenons au fait, si Adobe libérait le code de son player immédiatement, il s'en suivrait une période de flottement ou des dizaines et des dizaines de failles seraient surement découvertes en peu de temps. Ce qui aurait pour effet de ternir l'image de Flash pour pas mal de monde !
Certains en déduirais presque que je viens de donner un argument à Adobe pour garder son code propriétaire.

Mais d'un autre côté, à l'heure ou l'on parle de plus en plus de flash pour faire de l'applicatif(Flex, Air et leurs amis). Peut-on vraiment se permettre d'utiliser dans des secteurs ou la sécurité est souvent très importante un player et une technologie qui eux ne sont pas sécurisés ?

Un jour ou l'autre, Adobe devra libérer son player (à moins qu'une faille plus importante que les autres mette beaucoup de monde sur les genoux et décrédibilise le player face à une concurrence qui pointe le bout de son nez [4]).

Adobe devrait donc le libérer au plus vite d'autant plus qu'ils se sont déjà rapproché du libre avec Flex et Tamarin et qu'ils ont là un vivier de bêta-découvreurs de failles qui pourrait leur permettre de découvrir une grande partie des failles de sécurité avant une réelle libération du player Flash.
De plus certaines société spécialisées seraient surement prête à exécuter cette mission contre quelques euros...

[1] "Internet-enabled desktops" et "mature markets", avec deux trois autres conditions, ils auraient pu nous annoncer 100%
[2] L'an dernier c'est le player quicktime qui avait fait sauter une machine, saloperies de players propriétaires !
[3] Sachez pour information que le MacBook Air est tombé le premier à cause d'une faille de Safari, suivi de la machine Vista pour la faille Flash, le Ubuntu lui n'est pas tombé bien que la faille Flash aurait pu être exploité sous tous les systèmes sus-cités.
[4] Sylverlight pour la vidéo et l'applicatif même si on peut imaginer qu'à terme, le problème serait le même.

Tout d'abord, sachez qu'il ne faut jamais outrepasser les conventions de Rails sans une excellente raison.

Toutefois, il arrive que l'on ai une excellente raison, le cas présenté dans ce billet sera celui (tiré d'une application réelle) d'une base de données assez mal conçue où les noms de tables sont tous au singulier et où, comble du massacre, les id d'une des tables sont sous forme de chaine de caractères.

Bien sur, cette base de données est utilisée par 18 autres applications dans la société et vous ne pouvez en aucun cas en modifier la structure (sinon ce serait trop facile).

Problème N°1 : Les noms de tables.

Notre premier problème est donc que Rails considère par défaut qu'un nom de modèle doit-être un singulier et que le nom de la table correspondante doit être un pluriel.

Nous pourrions donc ajouter à l'un de nos modèles la ligne suivante :

Mais selon moi, cette propriété étant commune à tous nos modèles, il n'est pas logique de la placer dans l'un d'entre eux. Nous allons donc spécifier cette propriété générale à tous les instances d'AciveRecord ailleurs.

Pour cela, la version 2 de Rails nous offre un dossier config/initializers où placer tous nos scripts à exécuter au démarrage de l'application après les configurations par défaut, c'est donc l'endroit parfait pour rajouter un script "do_not_pluralize.rb" avec pour contenu :

Et voilà, nous venons d'overrider le paramètre pluralize_table_names d'ActiveRecord::Base et désormais, tout est clean.

Problème N°2 : Des chaînes de caractères comme id, drôle d'idée...

Les id de notre table "comment" (nom d'emprunt) sont donc des strings. Cela ne pose aucun problème à activeRecord qui saura évidemment faire un find("a12.bcd.3456789") si "a12.bcd.3456789" est la valeur du champ id de notre enregistrement.

Là où intervient le problème, c'est que comme vous êtes quelqu'un d'attentif, vous savez qu'avec Rails2, REST et les named routes ont enfin droit leurs heures de gloire.

Or, cela implique que l'URL d'accès à votre enregistrement soit de la forme :

/comments pour la liste des commentaires.
/comments/1 pour le commentaire 1
/comments/last pour une méthode supplémentaire last que vous auriez définie et qui vous ramènerait probablement les derniers commentaires.

Or avec notre id, l'url est de la forme "/comments/a12.bcd.3456789".

Rails pense alors que 'a12.bcd.3456789' est une méthode à appeler mais il ne la trouvera évidement jamais.

Dans le cas que j'ai eu à d'étudier, le salut est venu du fait que la suite de nombre suffixant l'id (ici '3456789') était unique, j'ai donc décider d'utiliser celle-ci comme paramètre de l'URL.

Pour récupérer ce nouvel id (que j'appellerai numeric_id), j'ai donc écrit la méthode suivante :

Il ne me restait plus qu'à indiquer à rails d'utiliser ce paramètre dans les URL grâce à la méthode to_param ^[1] (toujours dans mon modèle).

Grâce à cela, j'ai donc des url "/comments/3456789" que Rails analisera sans problème.

Dernières modifications, il faut indiquer aux méthodes agissant sur un seul enregistrement dans le controller (show, edit, update, destroy et celle que vous pourriez créer) d'utiliser notre nouvel identifiant numérique plutôt que celui par défaut.

Pour cela je rajoute une méthode find_by_numeric_id dans notre modèle :

Et je modifie les méthodes précédemment citées pour utiliser notre find, ma méthode show devient donc :

Et voilà vous avez désormais une base seine sur laquelle faire reposer la suite de votre développement.

Je me répète mais ce genre de modification ne doit être utilisé que si vous ne pouvez pas faire autrement

[1]Attention, si vous prévoyez d'utiliser la méthode to_param dans le cas d'un model Active_ressource, allez faire un tour ici afin de résoudre un bug de rails (corrigé dans la version SVN) qui fait que activeressource utilise parfois l'id au lieu de to_param.

J'ai trouvé mon futur employeur. Je ne suis donc plus à l'écoute du marché pour le moment.

Ceux qui me lisent régulièrement le savent sûrement, je suis actuellement étudiant en apprentissage dans la formation Concepteur Réalisateur Multimédia aux Gobelins et dans la société Abtrakt Graphics.

Mon apprentissage se termine au mois de juin et même si ma société actuelle souhaite me conserver dans son effectif, je suis à l'écoute d'autres propositions.

Je souhaite tout particulièrement m'investir dans les domaines du développement web à l'aide du framework en Ruby On Rails et du respect des standards du web. J'apprécie également les projets bien menés, les méthodes agiles et la conception orientée utilisateurs.

Je cherche donc l'entreprise qui me permettrait de mettre en œuvre ces compétences et j'invite les personnes intéressées à consulter mon CV à l'adresse suivante : cv.blogbangbang.com et à me contacter si mon profil les intéresse.

Rails progresse encore, la preuve c'est que pour la première fois, un RailsCamp aura lieu à Paris le 17 mai.

C'est quoi un Railscamp ?
Un Railscamp, c'est un Barcamp sur RubyOnRails et un BarCamp est une "non-conférence" ouverte qui prend la forme d'ateliers-événements participatifs où le contenu est fourni par les participants qui doivent tous, à un titre ou à un autre, apporter quelque chose au Barcamp (définition de la page officielle du RailsCamp).

Je serais donc de la partie en espérant que naisse de cet évènement, des rencontre sympa avec d'autres Railers, des projets sympa et pourquoi pas plus.

Par contre, je ne sais pas encore ce que je vais amener à part ma bonne humeur et ma motivation :).

Retour des billets plus "technos" avec un comparatif des deux frameworks Javascripts les plus utilisés du moment, j'ai nommé Prototype et Jquery.
Jusqu'ici j'étais plutôt Prototype, car je l'ai connu avant, qu'il est le framework par défaut de Rails auquel il est magnifiquement intégré.
Mais à force d'entendre dire que Jquery était plus esthétique plus facile, plus sympa, je me suis dit qu'il fallait que j'essai.

Il en est ressorti le billet suivant comparant le nécessaire dans chacun des deux framework pour réaliser les mêmes opérations.
Ces bouts de code correspondent en partie à ceux utilisés dans le billet Tutorial : Prototype and JSON et les fichiers sont disponibles au téléchargement (prototype / jquery).
L'application est quand à elle visible ici pour Jquery et ici pour Prototype.

Ecouter l'évènement signalant que le DOM est chargé et lancer une méthode.

Prototype

Jquery

La syntaxe Jquery est un peu plus courte, mais à mon sens un peu moins lisible ('dom:loaded' est plus clair que 'ready' ) Pas de quoi fouetter un chat donc :

Prototype 1 - 1 Jquery

Écouter un évenement sur un ensemble d'objets du DOM

Prototype

Jquery

Ici clairement, la concision comme la clarté sont du côté de Jquery à moins qu'il y ait moyen de faire plus propre en Prototype ?

Prototype 1 - 2 Jquery

Réaliser une opération Ajax simple (1 callback max).

Prototype

Jquery

La concision est encore légèrement du côté de Jquery, mais la lisibilité est encore pour Prototype.
Perso j'aime beaucoup l'utilisation de chaine comme clé de tableau (method, parameters...) de Prototype qui fait penser aux symboles de Ruby.
Par contre je n'aime pas le fait de devoir passer mon tableau link à la méthode $H pour que tout ce passe bien.

Pas de note ici, vous allez comprendre pourquoi juste après.

Réaliser une opération Ajax avancée (plus de 1 callback).

Prototype

Jquery

Alors là, du coup je suis bien embetté, Jquery se met aux clés nommées également et y gagne en lisibilité mais du coup, il perd en cohérence.
Si l'on veut rajouter un callback à une requête comme celle écrite au-dessus, il suffit de rajouter 1 lignes en Prototype alors qu'il faut tout réécrire en Jquery.
A moins bien sûr d'écrire toutes ses requêtes avec la méthode de plus haut niveau .ajax et d'oublier les .post, mais ce n'est pas ce que l'on voit la plupart du temps dans les forums, tutoriels...

Autre différence, Jquery à besoin de savoir dès le départ qu'il va recevoir du JSON alors que Prototype décide dans le callback quel objet utiliser (responseJSON ici).
Deux points à attribuer ici puisque l'on en a pas attribué au cas précédent.
Pour moi l'avantage va à Prototype qui garde la même logique et facilite les modifications sur une requête tel que l'ajout de callback et ne nécessite pas de connaitre le type de la réponse avant d'en avoir besoin.

Toutefois Jquery étant clair dans le deuxième cas, je dirais 2-1 pour Prototype dans cette partie du tutoriel, soit au total :

Prototype 3 - 3 Jquery

Utiliser des templates pour insérer le code souhaité.

Prototype

Jquery

Pas de système de template chez Jquery à ma connaissance, on doit donc faire :

Alors là, par contre il n'y a pas photo, Ce n'est peut-être pas très visible sur un petit template comme celui ci mais le code Prototype est beaucoup plus lisible et facile à écrire, relire, débugger...

Prototype 4 - 3 Jquery

Conclusion

Évidemment, toutes ces notes sont très subjectives, mais pour ma part je vais en rester à Prototype.
Jquery est un excellent framework Javascript et est bien plus concis que Prototype dans la majorité des syntaxes mais à mon sens il y perd en lisibilité et en clarté.

Et vous, vous en pensez quoi ?

Pour la première fois depuis 3 ans, je ne suis pas en Irlande pour fêter ce qui est surement une des fêtes nationales les plus sympa au monde.

Je passe le bonjour a ceux qui me lise de là-bas (même si je doute qu'il soit encore en état de lire quoique ce soit à l'heure qu'il est) et j'espère bien vous y retrouver l'an prochain.

Clément, Cyril, une petite place pour une dernière Guiness à ma santé !

P.S. : Promis, les billets pour "techos" reviennent au prochain tour, mais je vous jure que c'est pas facile de trouver du temps en ce moment.

Je n'ai pas le temps pas les moyens, ce n'est pas raisonnable, je n'ai plus l'âge et je ferais mieux de faire du vrai sport mais tant pis, j'ai quand même acheté une Wii.

Plus sérieusement, j'attendais d'avoir le moindre petit pécule de côté pour me faire ce petit plaisir et gouter à nouveau aux joies de Mario après mes dernières aventures sur ... Super Nintendo !

J'ai déjà bien testé Mario Galaxy et comment dire, c'est ENORME !
Alors certes je n'ai pas le temps mais je vais quand même allez chercher quelques étoiles dégommer deux trois tortues, sauver Peach et je reviens...