Blog Bang Bang - geeks

Du neuf dans mon PC !

jblanche — Sat, 30 Aug 2008 15:57:00 +0200

Quand on est Developpeur Web, et par-dessus le tout un peu Geek, on passe pas mal de temps devant un PC.

De ce fait, on s'habitue à ses outils, ses logiciels et il est assez rare de voir un logiciel modifier en profondeur ses habitudes.

Pourtant, récemment, deux découvertes ont vraiment changé ma façon de travailler et de me servir de mon PC.

Gnome-DO

La première est le logiciel Gnome-Do, équivalent dans Gnome (Linux) de Quicksilver sous Mac ou Enso sous Windows.

Depuis toujours, pour lancer une application il fallait soit réduire les fenêtres gênantes pour aller cliquer sur le bureau, soit aller la chercher dans un menu sous 2 niveaux d'arborescence obscures (Last FM c'est dans Musique ou Internet ? )

Certes il y a aussi la barre des tâches ou le Dock mais ceux-ci s'encombrent très, très vite.

Avec Gnome-Do, tout est plus simple, une combinaison de touche et la fenêtre suivante apparait

Tapez ensuite les premières lettres de l'application à démarrer "Fil" pour Filezilla par exemple et Gnome-Do va deviner seul ce que vous souhaitez faire, un appui sur la touche Entrée plus tard, Filezilla est lancé.

Mais Gnome-Do va plus loin, tapez mail, ou chat et celui-ci vous affichera la liste des contacts correspondant à l'application choisie et démarrera automatiquement l'application correspondante (une fenêtre de chat Pidgin par exemple)

Des tas de plugins, pour gérer votre musique, Twitter... sont déjà disponibles et le gain de temps est tout simplement sidérant !

Seul défaut, l'application se base sur les mots, la langue... mais elle n'est pas pour autant localisée, pour rechercher une adresse sur Google il vous faudra donc taper
map Rue de Tolbiac, Paris
et pas
Carte Rue de Tolbiac, Paris

Pour les "Power users", c'est plutôt une bonne nouvelle, l'anglais est souvent plus court et l'on chat plus régulièrement que l'on ne clavarde...

Par contre, pour le commun des mortels, ce sera surement un obstacle à une large adoption.

Synergy

Le deuxième logiciel à avoir changé ma façon de travailler récemment est Synergy.

Là pas de jaloux, les utilisateurs de Windows, de Mac, de Linux sont concernés, à condition d'avoir au moins deux machines.

En effet, Synergy vous permet en trois clics et avec une configuration du genre"plus simple tu meurs", de partager le clavier et la souris de votre PC principal sur vos PC secondaires.

Vous pouvez préciser ou ceux-ci se place par rapport au PC "serveur" (droite, gauche, dessus dessous) et même effectuer des copier-coller de texte entre les PC.

Synergy s'accommode de ces tâches sous tous les environnements cités précémment mais également quand ceux-ci se "mélangent", un PC Linux, le portable Windows à gauche, le MAC à droite et avec Synergy tout cela se contrôle avec 1 seul clavier et une seule souris !

Du bonheur à l'état pur !

Une application ?

Vous êtes développeur Web, vous travaillez sous Linux, mais 60 % des personnes de ce monde utilisant encore un navigateur plus qu'obsolète, il vous faut tester tout vos sites sous IE6, IE7 et sous une résolution différente.

Une autre ?

Toujours développeur Web, vous développer une application dont le serveur est en RubyOnRails et vous avez l'habitude de coder tout cela sous Linux.
Un des clients possible est une application, Flash, Flex ou AIR, là vos habitudes sont sous Windows...
Avec Synergy, vous passez de l'un à l'autre en un subtil mouvement de poignet

Testez, vous verrez !

OK pour le HomeServer mais comment ? (3/4)

jblanche — Tue, 20 May 2008 00:39:00 +0200

Que gère t'on :

De la musique
Des photos
Des vidéos
Des (cercles d') amis
Des mails
Des bookmarks
Un frigo
Une Télé

Et pourquoi pas

Des noms de domaines et des sites Web
Des flux RSS
Les stores de la maison
les lumières d'ambiance
...

Que va t-on utiliser pour gérer tout cela ?

Pour ce qui est du matériel, le "HomeServer" ne sera rien de plus qu'un PC, avec de gros disques durs (mais vu les prix du stockage actuellement, on peut se le permettre, d'autant plus qu'avec suffisamment de place, le serveur pourra également contenir des sauvegardes de vos données).

Pour le reste un PC bon marché suffira amplement à nos besoins.

Je dis HomeServer mais après tout rien n'empêche de placer l'application que j'aimerais développer sur un hébergement dédié.

La seule différence se situe dans le fait que certains préfèrent avoir cela vraiment "à la maison" et qu'il sera plus difficile "d'augmenter" cet objet avec les fonctions décrites précédemment (table interactive...).

Par contre, le dédié amènera des débits plus intéressant !

Il faut bien garder en tête que cette méthode vise à fournir à tout un chacun de multiples services dans le même produit, mais à destination d'un public restreint !

Si vous souhaitez faire 20.000 visites jours sur votre serveur web, gérer 50 comptes mails et streamer de la vidéo pour le monde entier, vous feriez mieux de vous tourner vers des solutions professionnelles !

Par contre, si vous souhaitez gérer vos quatre comptes mails uploader vos photos du week end en Bretagne et proposer à votre famille et vos amis de regarder la vidéo du petit dernier qui souffle sa première bougie, nul besoin d'un serveur professionnel !

Passons aux logiciels :

Actuellement, pour que vous puissiez lire et écrire des mails partout et depuis beaucoup de terminaux différents(PC, téléphone portable notamment), l'industrie s'appuie sur des formats et protocoles qui ont la sympathique particularité d'être ouverts !

Pour les moins initiés, cela veut dire qu'il est possible à tout un chacun de connaitre l'intégralité de leur fonctionnement et donc de concevoir facilement des applications utilisant ces formats.

Si l'on veut pouvoir gérer sa musique, ses vidéos, ses bookmarks, mais aussi ses cercles d'amis ou son frigo, il est impératifs de tirer les enseignements des problèmes du passé et de s'appuyer sur des protocoles et standards ouverts !

Comparons à nos besoins et regardons ce qu'il existe de ce côté-là :

Pour la musique, la vidéo, la photo aucun problème du côté des formats de fichiers, les formats sont déjà reconnus (ogg vorbis, ogg theora, Jpeg) et ne demandent qu'à se généraliser.
Pour les protocoles de streaming, on citera notamment le RTP
Pour gérer ses cercles d'amis, des solutions existent également, notamment FOAF mais aussi des initiatives comme opensocial de Google .
Pour vos mails, là aussi les solutions existent et sont plus que rodées !
Pour vos noms de domaines et vos sites web tout est près.
Pour les bookmarks, il n'y a pas à ma connaissance de format officiel même si plusieurs sites se sont calqués sur Del.icio.us pour leur formats d'import et d'export de vos bookmarks (donc un format HTML).
Pour les collections de flux RSS (ou Atom), le format de description le plus répandu est l'OPML.
Pour décrire le contenu de votre frigo, tout reste à faire...
Pour dialoguer avec ce même frigo, la TV, les stores et vos lampes d'ambiances, on rentre dans le cadre de la domotique et là encore des gens se penchent sur le problème depuis quelques années et des standards existent.

Comme vous pouvez le constater nous avons entre les mains tout le nécessaire pour mener à bien notre mission !
Avec le nouveau HomeServer, vous avez accès à tout, partout, sur tout vos appareils, tout le temps !

Alors il y a plus qu'à ?

Mes données m'appartiennent (2/4)

jblanche — Thu, 15 May 2008 23:20:00 +0200

Le ton de mon premier billet trahissait déjà surement ma retenue sur le fait d'offrir à des sociétés tierces l'intégralité de ma vie numérique.

De plus, j'aimerais pouvoir gérer plus finement les contenus que je mets à disposition de ces plateformes (qui peut voir telle ou telle photo), pouvoir supprimer facilement une vidéo, un profil...

Pourtant, je suis moi aussi un grand fan du 'tout-en-ligne', je rêve du jour où ma musique, mes vidéos... seront accessibles aussi facilement au travail ou à la maison, depuis un PC, un téléphone portable, un baladeur numérique ou sur mon frigo :D (oui j'aime bien le principe du frigo connecté).

Mais à y regarder de plus près ces deux approches, sont elles vraiment incompatibles ?

Imaginez, que plutôt que de placer vos contenus (musique, photo...) sur votre PC principal, vous déléguiez cette tâche à un autre appareil de la maison (que j'appellerai par la suite "HomeServer"), cet appareil se ferait tout discret, mais aurait la lourde tâche d'héberger tout vos contenus.

Comme nous sommes gourmands, imaginons que nous connections cet appareil à votre réseau "local" (en wifi tant qu'à faire ça évite les câbles qui courent partout) : vous voilà désormais avec des médias disponibles pour tous les PC de la maison et sur votre téléphone portable quand vous êtes chez vous.

Maintenant imaginons que nous relions cet appareil au web, nous voilà en un clin d'oeil, avec la possibilité d'accéder à tout nos contenus depuis la maison mais également depuis l'extérieur ! vous pouvez enfin lire le dernier album de Cyndy Sanders du travail même si les chansons sont hébergées dans votre petit nid douillet.

Tiens et puisque nous avons là un HomeServer connecté au web, pourquoi ne pas lui faire également gérer nos mails et nos bookmarks ?

Maintenant, plongeons nous en 2010 ou 2015, ce n'est pas si loin ! Pourtant, nombre d'entre vous bénéficierons alors déjà de la fibre optique, votre HomeServer serait alors capable d'envoyer les données vers l'extérieur beaucoup plus vite et vous pourrez alors non plus écouter le dernier single mais également regarder le dernier clip de Cyndy Sanders depuis votre lieu de vacances !

Et puisque ces contenus sont disponibles sur le web, pourquoi en limiter l'accès à votre petite personne ? Vos grands parents canadiens seraient surement ravis de découvrir cette perle musicale (à moins qu'ils ne préferent la vidéo du petit dernier qui souffle sa première bougie)...

En maîtrisant de A à Z ce "HomeServer", vous pourrez gérer très finement qui peut consulter quelle photo.

Vous pourriez même prévenir automatiquement certaines personnes de l'ajout de nouvelles ressources sur votre "HomeServer".

J'entends d'ici les ronchons qui se disent "oui mais bon moi je partage mon dossier musique de chez moi, j'ai configuré mon routeur et je peux y accéder de partout !" ou les plus geeks "Avec Music Player Daemon et Icecast chez moi je fais la même chose pour la musique".

Certes la plupart des choses annoncées sont d'ores et déjà possibles, mais le but est d'en facilité la mise en place en fournissant à terme un "HomeServer" PlugAndPlay qui permettrait toutes les choses énoncées ci-dessus pour tout le monde et même plus...

Allez poussons le bouchon encore un peu plus loin Maurice !

On va intégrer ce PC à votre table de salon.
Vous arrivez chez vous, vous posez votre téléphone portable sur la table et celle-ci se charge toute seule d'aller récupérer les dernières photo prises pour les mettre sur votre "HomeServer" puis elle synchronise vos différents Agenda et puisqu'elle converse régulièrement avec votre frigo et votre TV, elle vous rappelle que demain, Julien et Anthony viennent regarder le foot et qu'il n'y a plus de bières au frais[1] !

Alors, si ce "HomeServer" existait, ça ne vous tenterait pas ?

Le but pour dire vrai n'est pas forcement de créer des clones open sources de Youtube ou FlickR mais plutôt de créer un ensemble de WebServices et d'API permettant à chacun de créer des applications (web ou non et de préférence open sources ) pouvant se connecter aux webservices via l'API pour réaliser les différentes tâches.

De cette manière, la communauté de développeurs Java pourra faire une application mobile, les web-addicts se feront leur FlickR like et les Iphone lovers une application de lecture de vidéos...
A terme tout cela serait préinstallé sur un serveur adapté et pourquoi pas installé dans un dispositif bien intégré à la maison (table basse ou autre...)

[1] C'est mieux que Surface de Microsoft et puis est ce Microsoft ou Google ont vraiment besoin de savoir que vous préférez la Leffe à la Kro ?

Retour sur la libération des spécifications du SWF et du FLV.

jblanche — Thu, 01 May 2008 22:18:00 +0200

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 ?

Flash en route vers la liberté ?

jblanche — Thu, 01 May 2008 16:02:00 +0200

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 ? )

Un peu de lecture

jblanche — Thu, 24 Apr 2008 00:08:00 +0200

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

Pourquoi le player flash n'est pas déjà libre ?

jblanche — Mon, 21 Apr 2008 23:24:00 +0200

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.

Sortir des conventions dans Rails - retour d'expérience.

jblanche — Tue, 08 Apr 2008 23:01:00 +0200

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 :

self.pluralize_table_names = false

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 :

module ActiveRecord

  class Base

    self.pluralize_table_names = false

  end

end

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.

Edit du 17/04/08
Avant de vous montrer la solution que j'ai utilisé dans mon cas je vais suite au commentaire de Nicolas, de boldr.fr vous montrer une solution qui fonctionnera dans la majorité des cas (mais pas le mien.)

Afin de dire à rails d'utiliser autre chose qu'un id numérique dans les url de la forme "/comments/1" il existe une option des ressources appellée member_path. En modifiant donc votre fichier "config/routes.rb", vous pouvez indiqué à Rails d'utiliser l'id de votre table pour avoir des url de la forme "/comments/a12bcd3456789" comprises par rails.

Il suffit donc de remplacer :

map.resources :comments

par

map.resources :comments, :member_path => '/comments/:id'

Grâce à celà, vous éviterez beaucoup d'ennuis mais malheureusement, la solution ne fonctionne pas si l'id nouveau contient des '.' car rails se sert de ce caractère pour séparer la partie relative à l'url de l'action de la partie relative au format de retour (html, xml, js...).

La solution dans mon cas devait donc venir d'autre part...

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 :

def numeric_id

    self.id.split('.').last.to_i

  end

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).

def to_param

    "#{self.numeric_id}"

  end

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 :

def self.find_by_numeric_id(nid) Comment.find(:first,:conditions => ['id LIKE ? ', '%'+nid.to_s]) end

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

# GET /comments/1

  # GET /comments/1.xml

  def show

    @comment = Comment.find_by_numeric_id(params[:id])

    

    respond_to do |format|

      format.html # show.html.erb

      format.xml  { render :xml => @comment }

    end

  end

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.

A l'écoute du marché

jblanche — Wed, 02 Apr 2008 23:58:00 +0200

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.

Premier RailsCamp parisien

jblanche — Tue, 01 Apr 2008 23:14:00 +0200

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 :).

Comparatif Prototype vs Jquery

jblanche — Thu, 27 Mar 2008 00:36:00 +0100

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

document.observe('dom:loaded', init);

Jquery

$(document).ready(init);

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

$$('a').invoke('observe', 'click', link_click_handler);

Jquery

$('a').click(link_click_handler);

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

new Ajax.Request('json.php', {

    method: 'post',

    parameters:  $H(link),

    onSuccess: function(transport){populate_links_table(transport.responseJSON);}

  })

Jquery

$.post( 'proto.php', 

        link,

        function(data, textStatus){populate_links_table(data)},

        "json");

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

new Ajax.Request('json.php', {

    method: 'post',

    parameters:  $H(link),

    onLoading: toggleLoader,

    onSuccess: function(transport){populate_links_table(transport.responseJSON);},

    onFailure: function(){alert('There was a problem')},

    onComplete: toggleLoader

  })

Jquery

$.ajax({ type: "POST",

         url: "json.php",

         data: link,

         dataType: "json",

         beforeSend: toggleLoader,

         success: function(msg){ populate_links_table(msg);},

         error: function(req,str,e){alert(str)},

         complete: toggleLoader

        });

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

var rowTemplate = new Template(

        '<tr>'+

                '<td>#{text}</td>'+

                '<td>#{href}</td>'+

                '<td>#{timestamp}</td>'+

        '</tr>'

        );

  $('clicked_links_table').insert({

    bottom: rowTemplate.evaluate({

      text: link.text,

      href: link.href,

      timestamp: link.timestamp

    })

  });

Jquery

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

function populate_links_table(link){

        $('#clicked_links_table').append(

                '<tr>'+

                        '<td>'+link.text+'</td>'+

                        '<td>'+link.href+'</td>'+

                        '<td>'+link.timestamp+'</td>'+

                '</tr>');

}

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 ?

Tutorial : Prototype and JSON

jblanche — Mon, 04 Feb 2008 01:03:00 +0100

Après plusieurs discussions à l'école comme au travail, j'avais envie de tester un peu plus le format JSON pour donner et recevoir des données en AJAX (on devrait dire AJAJ du coup non ?).

Et vu que j'avais également envie de tester des petites choses avec prototype suite à la conférence ParisOnRails, je me suis dis pourquoi pas faire d'une pierre deux coups.

Je vous propose donc le résultat de mes différents tests avec Prototype 1.6 et Scriptaculous côté Javascript et PHP (version 5.2 minimum obligatoire) côté serveur.

J'ai retenu de la conférence de Cristophe Portenneuve que je faisais une grosse bêtise en n'utilisant pas les trésors d'Énumérable (un module de Prototype dédié aux collections), je me suis donc penché de ce côté-là et essayé de construire un petit "site", ou les clics sur les liens sont surveillés par Prototype, envoyés au serveur afin de tenir des statistiques, puis renvoyé (statistiques comprises) en JSON à l'application afin d'offrir un retour à l'utilisateur (ceci afin de tester un autre élément intéressant du nouveau Prototype, les Templates).

Voilà là donc le résultat, en commencant par le code :

/*

* J'observe le document pour repéré l'évenement 'dom:loaded' signifiant que le 

* dom est chargé

*/

document.observe('dom:loaded', init);



function init(){

/*

* Je récupère un tableau contenant tout les liens et j'appelle pour chaque 

* élément la méthode observe avec les paramètres 

* mouseover et link_click_handler.

* Cette méthode crée un écouteur sur chaque lien qui appellera 

* la méthode link_click_handler à chaque évenement click sur le lien.

*/

        $$('a').invoke('observe', 'click', link_click_handler);

        document.observe('click',click_handler);

}



/*

* Je crée un object handler (de type fonction)

* que je vais appliquer à tous les objets que je veut surveiller

*/



var link_click_handler = function register_link_click(){

/*

* Je crée ici mon objet lien en Javasript, il contient le texte

* et la cible du lien surveillé

* Le formatage link[] pour les clés permet de récupérer un array link

* avec toutes les propriétés coté Serveur

* S'il existe un moyen plus élégant d'obtenir le même résultat,

*  je suis preneur...

*/

        var link = {

                'link[text]': this.innerHTML,

                'link[href]': this.href

        }

        

//Je crée une requête AJAX

        new Ajax.Request('register_links.php', {

//en POST c'est plus sur pour passer des données

                method: 'post',

                parameters:  $H(link),

/*

* la seule ligne un peu compliquée Je transforme mon object JS

* en HASH JS auquel j'applique la méthode toJSON qui porte bien son nom

*/

                onSuccess: function(transport){

//je passe la réponse JSON à la fonction qui va remplir mon tableau

                        populate_links_table(transport.responseJSON);

                }

        })

}

var click_handler = function register_link_click(e){

        populate_clicks_table(e);

}



/*

* La fonction chargée de peupler mon tableau

* Elle recoit le résultat de la requête AJAX PHP

*/

function populate_links_table(link){

/*

* Je crée un Template Prototype de ce que je souhaite inséré

* en mettant entre #{} (syntaxe Ruby) les propriété dynamiques

*/

        var rowTemplate = new Template(' #{text} #{href} #{timestamp}');

        //J'appelle la méthode insert de prototype sur mon élément tableau

        $('clicked_links_table').insert({

        /*

        * Je spécifie d'insérer les éléments en bas (bottom) du tableau puis

        * j'évalue (interprête) mon template avec les propriétés associées

        */

                bottom: rowTemplate.evaluate({

                        text: link.text,

                        href: link.href,

                        timestamp: link.timestamp

                })

        });

/*

* Un petit effet de pulsate sur la dernière ligne insérée 

* avant de lui retirer la classe last_row

*/

        $$('.last_row').invoke('pulsate');

        $$('.last_row').invoke('removeClassName','last_row');

}





function populate_clicks_table(event){

        var elem = event.target ;

        var rowTemplate = new Template('#{identifiant} #{posX} #{posY} ');

        $('clicks_table').insert({

                bottom: rowTemplate.evaluate({

                        identifiant: elem.identify(),

                        posX: event.pointerX(),

                        posY: event.pointerY()

                })

        });

/*

* Un petit effet de pulsate sur la dernière ligne insérée avant 

* de lui retirer la classe last_row

*/

        $$('.last_row').invoke('pulsate').invoke('removeClassName','last_row');

}

Le Javascript fait usage d'une autre fonctionnalité de Prototype1.6, l'évènement dom:loaded afin de repérer le moment où le DOM est complètement chargé.

C'est à cet endroit que doit se situer 99,99% du code JS que vous souhaitez exécuter au chargement de la page.

Dans mon cas l'initialisation consiste à surveiller tous les liens pour repérer les clics et agir en conséquence.

C'est là où on est heureux d'utiliser un framework car grâce à $$('a') je récupère une collection de tous les liens du document.

Grâce à la méthode invoke, de Enumerable, j'appelle une méthode identique sur tous les objets de cette collection.

Le premier paramètre étant la méthode appelée, les suivants les paramètres à passer.

Je fait donc ici l'équivalent d'un $('un_lien').observe('click',link_click_handler) pour chaque lien ce qui serait bien plus long à écrire (boucle each puis observe su chaque lien...) et bien moins performant.

Pour ce qui est de la méthode observe elle indique à l'objet "appelant" de surveiller l'évènement passé en premier paramètre et exécute le deuxième paramètre.

Pendant que nous sommes dans les évènements, étudions la suite, le deuxième tableau de la page liste tous les clics, l'élément cliqué (son id s'il en a un) ainsi que les positions X et Y du clic.

On pourrait penser à faire quelque chose comme $$('*').invoke('observe', 'click', click_handler); mais ce serait oublier une chose très pratique avec la majorité des évènements, c'est qu'ils font des bulles (en anglais on dit bubbling event).

Cela veut dire que si la cible du lien ne l'intercepte pas, il est passé à l'élément supérieur et ainsi de suite.

On peut donc se contenter d'un écouteur sur le document qui détectera tous les clics : document.observe('click',click_handler)

Rien de très magique dans la partie AJAX du javascript à part le responseJSON qui vous permet de récupérer directement l'objet JSON renvoyé par le serveur, je ne m'attarderais pas plus.

Hop le javascript a fait son boulot (pour l'instant), la suite se passe côté serveur (en PHP, rare sur ce blog mais ça permet à tout le monde de suivre et en Ruby la logique est la même )

Le code :

/*

* Je crée une petite classe Link qui va geré les liens et les sauvegarder 

* dans ma Base de Données

*/

class Link{

        var $text ;

        var $href ;

        var $timestamp ;

        function __construct($_text, $_href) {

                $this->text     = $_text;

                $this->href     = $_href;

                $this->timestamp= time();

        }

        function save(){

                //Je sauvegarde le lien dans ma Base de Données

        }

}//END Class LINK





/*

* Je précise le header (type de contenu) de ce que je vais renvoyé, nécessaire 

* pour avoir acces au responseJSON de Prototype

*/

header('Content-type: application/json');



/*

* Je récupère le contenu passé en POST

*/

$post_data = ($_POST["link"]) ;



//Je construit mon objet Link

$link = new Link($post_data["text"],$post_data["href"]);



/*

* Je renvoi l'objet JSON complet (avec timestamp) pour vous montrer

* les templates en Prototype et également car une requete Ajax ne se 

* termine bien (onSuccess de Prototype) qu'a la réception d'une réponse

* qui peut être print(""); si vous ne souhaitez rien renvoyé de particulier

* mais qui doit absolument exister.

*/

echo json_encode($link);

Côté php donc, plus besoin de s'embêter à créer du XML, je récupère l'objet link passé en POST.

Je "l'augmente" avec une info timestamp dans le constructeur de sa classe.

Et je renvoie le tout en JSON en 2 temps trois mouvements en faisant json_encode($link) qui me renvoie par exemple

{"text":"Date","href":"http://localhost/lab/proto1_6/#api/date","timestamp":1202080178}

Retour côté Javascript, je récupère l'objet renvoyé et le passe à la méthode chargée de peuplé le tableau adéquat.

Là encore énorme gain de temps et de lignes de code (donc de probables erreurs) car l'on a plus à parser, le XML pour construire un objet Javascript, on a déjà un objet javascript.

Je construit donc un template qui correspond au code HTML que je souhaite inséré dans le tableau en spécifiant les propriétés dynamiques avec la syntaxe inspirée du ruby #{var}

J'appelle ensuite la méthode insert de prototype, lui spécifie d'insérer à la fin du tableau le résultat de l'évaluation du template précédemment crée avec les variables propres à mon Evenement.

var rowTemplate = new Template('#{identifiant} #{posX} #{posY} ');

$('clicks_table').insert({

                bottom: rowTemplate.evaluate({

                identifiant: elem.identify(),

                posX: event.pointerX(),

                posY: event.pointerY()

        })

});

Merci Microsoft, merci IE !

jblanche — Thu, 20 Dec 2007 19:00:00 +0100

Dieu que ce titre sent le troll à plein nez.

Pourtant, ce sont bien des félicitations que j'adresse pour une fois à Internet Explorer, mais puisque rien n'est parfait, c'est à la version 8 qu'elles sont destinées.

En effet, on a appris cette semaine que la version 8 du célébrissime navigateur détesté des webdéveloppeurs passerait le test Acid2.

En fait, il semblerait même, selon le blog IE officiel, que la version de dev actuelle passe déjà ce test ! (mais il est impossible de la télécharger et donc de vérifier).

Si cela s'avère vrai, ce serait vraiment une excellente nouvelle pour tous les webdéveloppeurs du monde, plus de feuille de style alternative, plus de journée "Debug IE" au planning, beaucoup moins de différence de rendu entre les navigateurs...

Toutefois, inutile de s'arrêter en si bon chemin, j'invite donc les développeurs Microsoft à s'atteler dès à présent à l'intégration des spécifications CSS3, du futur Javascript2, des éléments audio et vidéo de HTML5, du SVG, de SMIL, des microformats... (C'est Noël, laissez moi rêver ! )

Flash is everywhere, or not...

jblanche — Wed, 12 Dec 2007 23:15:00 +0100

Selon les statistiques d'Adobe, Flash est installé sur 99.1 % des Ordinateurs Desktop (PC+Mac) connectés au web.

Selon ces mêmes statistiques, le player 9 serait même déjà installé sur environ 90 % du même matériel.

Ces statistiques impressionnantes sont souvent la défense des flasheurs face aux critiques adressées contre leur technologie favorite.

Pourtant, la vérité est moins rose...

Sans remettre en cause les statistiques fournies par Adobe, il faut aussi regarder ce qui se cache derrière.

Premièrement, comme je l'ai déjà dit auparavant, le flash player 9 à beau être installable par exemple sur une plateforme Linux, ce n'est pas pour autant que les utilisateurs Linux en sont satisfait.

Le player fourni pour Linux est loin d'être parfait, sa stabilité laisse parfois à désirer (notamment pour la lecture de vidéos encodées avec le codec H264).

De plus, le plein écran, disponible sous Windows et Mac depuis quelques mois déjà, n'est toujours pas à l'ordre du jour sous Linux.

Même si ces limitations sont très gênantes, Linux ne concerne qu'un petit pourcent d'utilisateurs et les flasheurs vous rétorquerons donc que l'argument ne tient pas la route.

Certes, mais un autre problème bien plus important se pose déjà et devrait s'amplifier dans les mois et années à venir.

Ce problème, c'est que les statistiques données concernent les matériels "Desktop", alors que l'informatique devient de plus en plus embarquée.

Aujourd'hui dans nos portables, PDA, Personal Media Player(ITouch, Archos...).

Demain absolument partout, du frigo à la voiture, en passant par la table basse.

Et sur cette informatique embarquée connectée, le constat est beaucoup moins sympa.

En effet, de 90 %, on passe selon le peu de sources à disposition, à très très peu de PDA, téléphones... compatible Flash9 (Le N800 de Nokia étant le seul pour lequel je suis sur de la compatibilité).

Sur les autres, il y a parfois FlashLite, mais cela veut dire Flash8 au maximum (et pas intégralement supporté), on a donc droit à un web à deux vitesses ou l'on ne peut pas développer des applications en étant certain qu'elles fonctionneront à la fois sur PC et sur mobile.

Hors comme le clame la pub IPhone, ce que l'utilisateur veut, ce n'est pas une pâle copie d'Internet, c'est Internet sur son mobile, lecteur audio et vidéo...(d'ailleurs l'Iphone à semble t-il considéré que l'internet sans Flash restait l'internet ! Osé...)

Enfin pour une autre partie des plateformes, FlashLite n'est même pas disponible...

En refusant depuis des années de délivrer les sources de son player, Flash (et pendant longtemps Macromédia) empêche de nombreuses plateformes de participer au marché des périphériques connectés.

En libérant le code source de sa machine virtuelle ActionScript et en entamant le projet Tamarin avec Mozilla, Adobe a montré son intention de se rapprocher de la communauté du logiciel libre.

Aujourd'hui, il est tant de passer à l'étape suivante et de livrer à tous, le nécessaire au portage du player flash(DOM, bibliothèques multimédias, gestion des événements...) sur toutes les plateformes.

On pourrait alors trouver celui-ci dans tous les téléphones, lecteurs audio et vidéo portables...

A bon entendeur... Salut !

Paris on Rails : a chaud !

jblanche — Mon, 10 Dec 2007 23:39:00 +0100

Je rentre juste de Paris on Rails, le moins que l'on puisse dire, c'est que le programme était dense.

Pas moins de 8 conférences officielles, 4 officieuses, 1 présentation de Ruby et Rails et une visioconférence avec DHH, le créateur du framework et tout ça dans une petite journée.

A chaud donc, une excellente journée, j'ai appris des choses dans à peu près toutes les conférences, discuté avec quelques railers français et parisiens qui ont réussi à en faire le métier et récupéré 2-3 cartes de visites.

Rails pousse, lentement mais surement et s'installe dans les petites moyennes grandes et même très grandes entreprises.

La demande est parait-il beaucoup plus élevée que l'offre, ce qui laisse présager de bonnes choses pour les développeurs qui s'engagent dans cette voie.

Pour revenir, sur les conférences, il y en avait pour tous les goûts :

retour d'expériences d'entreprises (moyennes ou grandes)
Javascript avancé avec Chistophe Porteneuve qui a tenu sa réputation de sliders fou avec une cinquantaine de diapositives en 30mn (et un contenu hautement exhaustif et intéressant)
les vues dans Rails, dans la conférence de Nicolas Merouze de Boldr était également du pain béni pour tous les développeurs rails (les slides de la conf sont déjà disponibles sur son blog).
L'internationalisation avec un des codeurs du plugin Globalize.
Les tests par Jean-Michel Garnier heureux railer français à Barcelone :D...

J'ai un peu moins accroché sur la conférence intitulée : "JRuby et JRuby on Rails, mais que viennent faire Java, NetBeans et GlassFish?", dont je retiendrais seulement que Rails s'intègre à merveille dans un système d'informations en Java (ce qui peut rassurer de grosses structures).

Après la journée de conférence officielle, je me suis rendu au MetroOnRails (organisé par Pierlis et bloogk), un petit buffet entre railers où j'ai pu assister à 4 autres conférences : sur le plugin searchAPI, la librairie Prototype UI, un retour d'expérience sur un DataWarehouse en Ruby et une conférence "fourre-tout" très intéressante sur Atom Publishing Protocol, ActiveResource, ActiveMessaging et les fourmis :).

J'ai enfin discuté avec Nicolas Mérouze de BoldR et un membre de l'association votons.info (discussion dont-il ressortira peut être quelque chose dans les jours à venir...)

Voilà pour ce soir je vais laisser reposer tout ça quelques heures et je reviendrais surement sur les points les plus marquant de cette journée (notamment Prototype 1.6, ça déchire grave comme le dis TDD aka Christophe Porteneuve ! ).

Ruby et RubyOnRails

jblanche — Sat, 27 Oct 2007 17:54:00 +0200

Vous êtes développeur ? logiciel ou web ?

Vous ne cessez d'entendre parler d'un presque vieux langage qui revient à la mode : Le Ruby.

Vous entendez aussi parler d'un frame_quelquechose, framework surement, qui permettrait de faire des sites Webs et bien plus en Ruby plutôt qu'en PHP.

Vous vous dîtes à quoi bon changer puisque je me débrouille en PHP, où vous aimeriez bien essayer, mais vous craignez de vous retrouver perdu dans un nouveau langage, de nouvelles pratiques...

Alors, un seul conseil, foncez sur le dernier hors-série de Linux magazine.

Ne vous laissez pas avoir par le titre du magazine, on ne vous demandera pas de recompiler un noyau ou de porter une barbe de 3 mois pour commencer les tutos de ce magazine et tout est également faisable sur un environnement MacOS ou Windows.

Le magazine traite dans un premier temps du langage Ruby en tant que tel, de ses spécificités, avantages au travers d'une multitude d'exemples vous apprendrez donc à écrire vos premières variables, méthodes et classes ruby.

Puis dans un deuxième temps, il vous sera proposé de créer votre première application RubyOnRails, le fameux framework permettant de construire des applications Web en Ruby.

Là encore on commence avec les bases, les tutoriaux fourmillent d'exemples et si à la fin de cette lecture, vous n'avez pas envie de créer votre première application RubyOnRails, c'est vous êtes déjà un vieux têtu qui refuse de regarder la vérité en face :-D.

Le magazine vous coûtera 6€40, ce n'est certes pas donné, mais il les vaut (pour ceux qui me connaissent, je serais ravi de vous le prêter.)

Et si vous êtes convaincus, vous pourrez venir me rejoindre à ParisOnRails.

ParisOnRails, j'y serais !

jblanche — Tue, 23 Oct 2007 20:33:00 +0200

Quand j'ai vu il y a quelques jours que la cuvée 2007 de ParisOnRails aurait lieu le 10 décembre, j'en ai profité pour me replonger dans rails, que j'avais un peu délaissé par manque de temps ces dernières semaines.

Après ces tests, j'avais d'autant plus envie de me rendre à cette conférence, j'en ai donc parlé au boulot hier et aujourd'hui, j'ai mon ticket.

Un grand merci à mon entreprise (a-g.fr), et à mon école, (les Gobelins), pour m'avoir respectivement offert la place et permis de manquer une journée de cours afin de me rendre à cette conférence.

J'aurais donc la joie d'assister à des conférences présentées par de grands connaisseurs français de RubyOnrails (les auteurs du bouquin de Eyrolles sur RubyonRails ainsi que l'auteur de Bien Développer pour le Web2.0, deux de mes livres de chevets) ainsi que par l'auteur d'un mes blogs favoris : http://blog.boldr.fr/.

Je n'attends plus qu'une chose, être au 10 décembre !