Blog Bang Bang

Changement d'adresse

jblanche — Thu, 21 Jan 2010 23:14:00 +0100

Comme vous l'avez constaté, ce blog est au point mort depuis un bon moment maintenant.
Mais ma passion pour le web est intacte, alors si vous souhaitez continuer à me suivre, ca se passe ici :
http://jblanche.fr

Principal changement, je m'attaque à l'anglais !

Crédit photo : denemiles sous CC-BY-SA

IE8, l'état de l'art

jblanche — Wed, 04 Feb 2009 18:29:00 +0100

La RC1 de Internet Explorer 8 est sortie il y a quelques jours. Depuis chacun y vas de son petit test et de son analyse de la nouvelle monture du navigateur le plus détesté au monde.

Cette arrivée est parfois saluée, parfois décriée, en tout cas chacun à son avis, souvent trop tranché. Essayons ici de se faire une idée réelle des tenants et aboutissants de l'arrivée du nouveau IE.

Le bon

CSS 2.1

Enfin, enfin, enfin, la norme CSS 2.1, est entièrement supportée par Internet explorer 8. A nous donc, une multitude de techniques CSS jusque là interdite aux développeurs web à cause de leur non-compatibilité avec IE.

Au menu notamment :

les pseudo classes: active et focus.
les pseudo-élements : after et before et leur propriété content pour ajouter du contenu avec les CSS
(attention à utiliser avec parcimonie et connaissance des aléas de cette solution)
les propriétés quote, border-spacing.
Et surement ma préférée : le support du CSS table model.
Grâce à cela, il devient possible d'écrire un code logique et sémantique tout en utilisant les avantages des mises en page "tableau".

Regardez ces deux exemples d'alignement vertical et de design a 3 colonnes pour vous en convaincre.
Peut être enfin la fin de l'utilisation des floats à tout va, tout en gardant un code sémantique.

Le HTML/DOM

Là aussi quelques améliorations et nouveautés sympathiques.

HasLayout a disparu, oh que c'est bon, je crois la moitié des bugs IE auquel j'avais a faire venait directement ou non de lui

IE8 implémente quelques parties des spécifications de HTML5 comme le DOM storage (cookies évolués), les Offline Events ...

Les getAttribute/setAttribute fonctionnent enfin comme partout ailleurs. Le getElementById retourne ce qu'il est censé retourner, sans se soucier des "name"...

Autre : Les outils Developpeurs

Après Firebug et le Wenkit Inspector, IE8 intégrera ce qu'il appelle "outils de développement" permettant de modifier en direct les CSS, d'exécuter du JS avec des points d'arrêts... ...

Le mauvais

hé oui tout n'est malheureusement pas rose malgré cette nouvelle version, bien au contraire...

CSS3

Certes les spécifications de CSS3 ne sont pas terminées, mais certaines sont presque définitives et la concurrence implémente déjà certaines propriétés.
On aurait au moins aimé voir les border-radius pour faire simplement des coins arrondis, les text-shadow et border-shadow pour les ombres, la propriété opacity ou encore le support des couleurs RGBA.

Javascript

Là encore malgré quelques efforts, IE8 est très loin de ses concurrents. On reste bloqué à Javascript 1.5, on ne profitera donc pas des nouveautés apportées par les versions 1.6 et supérieures.

Pas de JIT (Just In Time Compilation) non plus dans IE8 alors que l'arrivée de cette technologie dans les moteurs Javascript de Firefox 3.1 et de Safari 4 (Webkit nighlies) montre un gain exceptionnel des performances.

HTML/DOM

On aurait aimé voir les éléments audio et vidéo de HTML5, permettant d'insérer du son et de la vidéo dans une page aussi facilement qu'une image.
Malheureusement il semblerait que la volonté d'imposer Silverlight sur ce marché ait pris le dessus sur le bon sens.

Le SVG lui aussi attendra, encore...

Idem pour Canvas, il faudra attendre encore, malgré la prolifération des exemples montrant les possibilités de ces deux technologies.

Conclusion

Internet explorer 8, c'est mieux, beaucoup mieux que le 7, sans aucun doute possible.
Le support complet de CSS 2.1 va bientôt changer la vie des Développeurs Web

Mais IE8 reste aussi très loin de la concurrence que représente FF3.1 ou Safari4.
Ces navigateurs vont beaucoup plus loin dans le support de HTML5, des CSS3... Ils supportent très bien le SVG et Canvas, et vont beaucoup plus vite pour exécuter du Javascript avec la compilation à la volée.
Ces atouts leurs permettent de supporter des choses bien plus complexe qu'IE dans les domaines des RIA/RDA.

Autre interrogation, quand pourra t-on vraiment profiter de ces nouveautés sans ce fâcher avec les utilisateurs de versions plus anciennes d'IE ?
Sur ce point, je suis assez optimiste.
En effet, les prévisions annoncent IE6 à moins de 10 % d'ici la fin de l'année, et les utilisateurs ayant fait le saut vers la version 7 devrait en grande partie poursuivre leur migration avec la version 8.

On peut donc penser que l'on pourra coder pour IE8 d'ici janvier 2010 en ne perdant pas plus de 10 % de son lectorat (auquel on pourra toujours proposer une version alternative simpliste... ou pas).

Si j'avais un dernier conseil à donner ce serait donc, de commencer à regarder du coté du CSS Table model, Ceci va changer la vie des intégrateurs Web.

The Web change us all

jblanche — Wed, 21 Jan 2009 21:32:00 +0100

Even developers :

Before :

after :

Wait for it, we have to write those tests before playing with colleagues.

I miss those compiling times

PS : The original picture (the first one) came from the greatest webcomic, xkcd

PS2 : Yes I can write in english too, just for fun

Happy Christmas Web developpers

jblanche — Wed, 24 Dec 2008 15:30:00 +0100

Je vous ai déjà beaucoup parlé de Rails sur ce blog et de tout le bien que je pense de ce framework.

Pourtant, la communauté des développeurs web Ruby était en train de se séparer en deux, depuis quelques mois. En effet un autre framework, partageant les idées ("conventions plutôt que configuration", "Don't repeat Yourself"...) était apparu : Merb.

Merb donc est né de l'idée que Rails était trop "Full Stack", comprenez par là que Rails vous offre un environnement complet et choisi pour vous un ORM (ActiveRecord), un Framework Javascript(Prototype)...
Rails permet évidemment de modifier ces choix par défauts, mais ne facilitait pas forcement la migration. Merb, au contraire, embarque un minimum de choses et laisse le choix des composants additionnels au développeur (ORM, Framework JS, langage de templates...).
Merb est aussi connu pour l'importance accordée aux performances par ses développeurs.
Là ou Rails avait parfois sacrifié un peu de performances, pour un peu plus de clarté, Merb ne fait aucun sacrifice et veut vous apporter le beurre, l'argent du beurre et la crémière (comprenez les performances, la clarté et ... la classe )

De cette fission, certains avaient essayé de créer une "guerre" des frameworks entre ces deux là. Mais les principaux intéressés (les développeurs de chacun des frameworks) ne tarissait pas d'éloges sur leurs concurrents.
J'en veux pour preuve cette liste "tronquée" des raisons pour lesquels Matt Aimonetti, développeur Merb français aime Rails :

Sans Rails, Ruby ne serais pas un des 11 premiers langages de programmation.
Sans Rails, on écrirait encore des centaines de lignes de configurations pour démarrer une petite application.
Sans Rails, beaucoup de développeurs ne saurais pas ce que MVC signifie.
Sans Rails, je ne serais pas un développeur Ruby.
Sans Rails seuls les élites feraient des tests.

Malgré cela, de plus en plus de personnes pensaient à migrer vers Merb, qui semblait devenir plus intéressant que Rails pour les raisons évoquées précédemment et quelques autres (routing, slices...).

Et hier, est arrivé le cadeau de Noël inespéré, les développeurs des deux équipes ont en effet décidé de réunir leurs efforts et de nous réunir les deux frameworks pour la prochaine version majeure.

Merb sera donc mergé dans Rails afin de devenir Rails 3, cela veut dire, tous les avantages de Rails, à commencer par le nom que c'est fait ce framework dans le monde du web, auquels viendront s'additionner tous ceux de Merb (Les API publiques, les slices, le routing avancé, le choix des composants, les performances... ...)

Les réactions dans le monde Ruby sont pour le moment partagées même si le positivisme l'emporte déjà. Pour ma part, je suis TRÈS confiant sur ce rassemblement des forces pour trois raisons :

Les nouveaux modes de développement, Git, Github (ses commentaires), facilite l'investissement de la communauté dans le code du framework. Les décisions prises lors de cette phase de réunion de Rails et Merb seront donc surveillées de très près.
Les développeurs de Rails et de Merb sont parmi les meilleurs que je "connaisse", lire le code des commits des "leads développeurs" de ces deux frameworks est presque toujours un plaisir et une source d'inspiration pour ses propres projets.
La communauté Ruby est très active et beaucoup d'outils, de tutoriels visant à faciliter la migration devrait voir le jour ses prochaines semaines/mois.

En conclusion, nous n'avons plus désormais deux gros frameworks Ruby, mais un seul.
Alors certes la concurrence sera moindre (même si de nombreux autres frameworks encore moins connus existent), mais l'effervescence au sein de la communauté Ruby et les outils adéquats devraient permettre de combler ce manque.

Alors vive Rails, vive Merb, vive Ruby, et Joyeux Noël.

En vrac

jblanche — Thu, 20 Nov 2008 20:40:00 +0100

Des nouvelles de l'open web, il va bien merci pour lui !

Le Web sémantique, que le sujet vous parle ou non, si vous tenez à vos données, lisez cet article !.
Soyez sympas, lisez aussi la suite mais vraiment cet article aurait valu un en vrac à lui tout seul !
De la 3D avec Canvas, hop encore un terrain ou les technos libres viennent concurrencer Flash.
La vidéo libre sur le net, oui oui ça avance...
Prenez le temps, d'essayer, on peut déjà bien s'amuser en mettant par exemple du HTML en overlay, un peu de transparence CSS et un peu d'animation JS et faire pourquoi pas un petit player avancé...
Le son aussi, regardez cette open drum machine !
Des applications web plus réactives, du temps réel, du push server, ça aussi on sait désormais faire avec des technologies et protocoles ouverts comme le Kaazing Gateway et HTML 5 et ses WebSockets.
Cela permet notamment de faire du chat, sans vérifier sans cesse s'il y a de nouveaux messages sur le serveur, ceux si "viendront" a vous automatiquement.
Même le web "clos" s'améliore, mais il peut faire mieux, beaucoup mieux
Ce dernier lien est lui aussi une lecture indispensable, pour comprendre ce qu'apporterait une libération du player Fash, mais également pourquoi cela n'est pas encore possible (n'oubliez pas de lire les commentaires).

Des nouvelles de Ruby et de ses frameworks, tout le monde va bien !

Rails arrive en version 2.2 avec plein de nouvelles features, notamment l'internationalisation dans le framework et le support de Jruby.
Merb 1.0 : L'autre framework Ruby (en tout cas le deuxième plus connu) débarque en version 1.0. Merb est un framework agnostique, que ce soit pour les ORM(Active Record, Datamapper, Sequel...), les framework javascripts (JQuery, Prototype)...
Et ne venez plus me dire que Ruby/Rails/Merb/UnTrucAvecDuRubyDedans c'est lent (j'aurais bien aimé voir Symfony dans ces benchmarks, je pense qu'ils s'en sortirais mieux que ses compères PHP mais par rapport à Rails ou Merb ?).

Flash player 10, caramba encore raté !

jblanche — Wed, 15 Oct 2008 22:12:00 +0200

La dernière version (10) du Flash PLayer est sortie aujourd'hui.
Au menu des réjouissances, gestion de la 3D, utilisation partielle de la carte graphique, meilleure gestion des textes...
Malheureusement tant de nouveauté ne saurait cacher la triste réalité cachée derrière cette sortie.

Flash n'as pas amélioré ses problèmes de compatibilité.

Compatibilité avec les plateformes tout d'abord : Même si le player est sorti pour la deuxième fois sur les 3 OS principaux en même temps, il faudra repasser pour les versions 64bits, pour les architectures mobiles...

Mais le pire reste la compatibilité avec lui-même, ou rétro-compatibilité.

En effet, essayez d'installer la nouvelle version et d'aller uploader une nouvelle vidéo sur votre joli Wordpress ou tout autre outil utilisant SWFUpload, vous ne serez pas déçu ! Que dis-je, vous serez très déçu puisque SWFUpload, ne fonctionne plus avec la version 10 du Flash Player.

Raison invoquée : la sécurité, j'en déduis donc que les 95% actuels de la version 9 sont en danger ?

Bref, je ne vais pas encore m'acharner sur mon meilleur ennemi, mais encore une fois, reposer sur le logiciel montre ses limites, espérons simplement que les alternatives libres s'imposeront aussi vite que possible !

Allez puisque je suis un gros Troll :D, je ne résiste pas à l'idée de vous mettre ici quelques commentaires d'un article écrit il y a un an et demi :

la v9 du player lit sans problème un anim en Flash 3 faite en 98. La retro-compatibilité est et sera toujours assurée par Adobe pour des raisons commerciales évidentes. Maintenant, Flash est une techno qui évolue vite, l'AS est un langage qui évolue vite, et c'est bien. Et ça ne t'oblige en rien à modifier ton code à chaque release de Flash. A titre de comparaison, quand pourra-t-on utiliser les CSS 3?

Pour ce qui est de la rétro compatibilité, Adobe ne risquera pas de se mettre à dos une bonne partie des développeurs (et des utilisateurs) de Flash en la faisant sauter.

Il faut aussi noter le fait que les swf ne "vieillissent" pas...

Et pour se remonter le moral :

"Flash n'est pas selon moi, un format adapté à d'autres usages que ceux auxquels il est actuellement employé (vidéo et son), et il ne le deviendra pas". OLOLOLOL

Peut-on encore dire ceci à l'heure des balises audio et video ? HTML5 Balises Audio et Video
ou encore :

Des belles polices c'est "joli tout plein" et c'est aussi précisément ce que ton client te demande. Si des grafeux, des DA, des typographes on choisi telle police pour pour le print, c'est pas pour voir une Verdana dégeu sur le site de l'annonceur. Et là, désolé, mais Flash est la seule et unique alternative. Il était question, à l'époque de l'apparition des CSS, de la possibilité d'encapsuler des polices à une page html. Ca n'a jamais abouti. Dommage. Flash, point barre.

CSS3 : c'est là, sous nos yeux ! Go go go !
Oh punaise N*r*k va encore me tapper :D

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 !

ActionView : Imprimeur de son état

jblanche — Wed, 06 Aug 2008 00:37:00 +0200

3ème et dernière partie du Modèle M.V.C. dans Rails, la Vue.

Comme vous l'avez compris dans la partie précédente, Ruby on Rails est capable de produire ou de servir bien plus que des pages HTML et notamment du XML, du JSON, des images, du PDF... ...
Toutefois, Rails a été particulièrement bien prévu pour la génération de HTML et en facilite grandement l'écriture...

Pour commencer sachez que le langage de templates inclus par défaut dans Rails se nomme erb.
D'autres existent (Builder, HAML... et ont leur intérêt, mais je m'attarderais ici seulement sur erb).

Celui-ci vous permet d'intégrer du code Ruby dans votre code HTML comme vous le faites avec les balises <? et ?> de PHP.

En Ruby deux types de balises existent :

Le code placé entre <% et %> sera interprété, mais pas affiché.
Le code placé entre <%= et %> sera interprété et affiché.

On écrira par exemple pour afficher les informations d'un étudiant (méthode show)

<h1>Présentation</h1>



  Prénom: <%= h @student.firstname %><br />

  Nom: <%= h @student.lastname %><br /> 

   

  <% if @student.major? %>

    Age : <%= @student.age %>

  <% end %>

@student étant la variable passée par notre controller dans la méthode show dans la partie ActionController de ce tutoriel.

N.B. : Je n'ai pas écrit les méthodes major? et age dans mon modèle Student dans le tutoriel sur ActiveRecord mais l'intégralité de cette mini-application (absolument pas fonctionnelle) est disponible sur Github sur mon dépot.
Vous trouverez ce modèle ici

Vous vous souvenez que l'on avait également une méthode update, censée mettre à jour les données d'un utilisateur provenant d'un formulaire.

Écrivons ce formulaire :

<% form_for @student do |s| %>



  <%= s.label :firstname, "Prénom" %><br />

  <%= s.text_field :firstname %><br />

  

  <%= s.label :lastname, "Nom" %><br />

  <%= s.text_field :lastname %><br />

  

  <%= s.label :date_of_birth, "Date de naissance" %><br />

  <%= s.date_select :date_of_birth %><br />

  

  <%= submit_tag "Enregistrer" %>

<% end %>

Pas mal non

Oui ok un coup de CSS ne ferait pas de mal, mais là n'est pas le sujet

En passant le @student à la méthode form_for, celle-ci sait que le formulaire va modifier l'utilisateur existant et grâce à l'utilisation REST, elle peut aisément générer la balise formcorrespondante.

De même, l'utilisation du |s| permet d'appeler les méthodes de rails pour construire un formulaire ( text_field, date_select, hidden_field...) en les associant à notre étudiant et donc de générer le code du formulaire avec les propriété name des input correctement renseignées.

Regardez plutôt le code généré :

<form action="/students/1-Jonathan_Blanchet" class="edit_student" id="edit_student_1" method="post">
  <div style="margin:0;padding:0">
  <input name="_method" type="hidden" value="put" />
  <input name="authenticity_token" type="hidden" value="c810f8897fcc7bab36a440cb4653b4f87de89d6e" />
  </div>

  <label for="student_firstname">Prénom</label><br />
  <input id="student_firstname" name="student[firstname]" size="30" type="text" value="Jonathan" /><br />

  <label for="student_lastname">Nom</label><br />
  <input id="student_lastname" name="student[lastname]" size="30" type="text" value="Blanchet" /><br />
  ...
</form>

Les inputs _method et authenticity_token sont automatiquement renseignés par Rails.

Le premier informe Rails sur le type de requête a utiliser selon la méthode REST (ici PUT) en attendant que les navigateurs implémentent les méthodes PUT et DELETE (seulement GET ET POST sont actuellement supportées).

Le deuxième sert à protéger le formulaire contre des ataques extérieures mais comme le premier, vous n'aurez jamais à vous en soucier

Pour le reste, vous noterez la forme student[propriété] de tous les inputs qui nous permettra de récupérer un tableau student contenant tous les attributs de notre étudiant.

Vous noterez également que les propriétés value ont été automatiquement proprement remplies.

Voilà pour notre formulaire.

Vous vous souvenez surement que nos étudiants doivent avoir un nom et un prénom sous peine d'être "invalides" pour ActiveRecord.

Rajoutons en haut de notre page le code suivant :

<%= error_messages_for 'student' %>

Si on essaye désormais de sauvegarder notre utilisateur sans nom, nous aurons droit à ceci :

Évidemment, tous ces messages sont personnalisables très facilement

Je ne vous parlerais pas ici d'AJAX car même si la facilité de mise en place de fonctionnalités AJAX avec Rails est souvent mise en avant dans les tutoriels, le code généré par Rails dans sa version actuelle n'est vraiment pas parfait et ne respecte pas le principe de séparation du contenu, de la présentation et du comportement (HTML - CSS - Javascript)

Pour les plus curieux, je vous invite à regarder du côté de UJS un plugin permettant d'écrire ce genre de choses :

apply_behaviour '.list_item:click' do |page, element, event|

  element.replace_html "Deleted." 

  event.stop

end

Pour en savoir plus sur la notion de Progressive Enhancement (utilisation propre du Javascript) et sur les CSS-based Selectors, je vous invite à lire cette excellente présentation (c'est court mais excellent) :

Voilà, c'est terminé pour la partie vue et plus largement, pour cette série d'articles.

J'espère vous avoir convaincu de l'intérêt de Ruby et de Ruby On Rails pour écrire vos applications Web.

Pour ma part, je m'étonne encore régulièrement de la facilité à écrire certaines choses en Ruby ! [private joke]Même une mamie Molette blonde pourrait le faire...[/private joke].

Je vous invite maintenant à me laisser en commentaire, toutes vos questions, réflexions, demandes sur cette série d'articles et/ou sur Ruby/Ruby On Rails en général.
J'y répondrais avec plaisir et peut-être sous la forme d'une FAQ qui pourrait faire office de billet de clôture de cette série.

Maintenance : Dotclear2

jblanche — Fri, 01 Aug 2008 20:28:00 +0200

Ce blog est maintenant propulsé par la version 2 finale de Dotclear, le moteur de blog bien de chez nous.

Pas mal de nouveautés et d'amélioriotations dont une que j'attendais depuis très longtemps, la pré-visualisation des billets dans leur contexte (avec la présentation du blog final).

Le système d'importation des médias a été revu et amélioré, bref ça m'a l'air pas mal du tout

L'ensemble des caractéristiques de cette version est disponible sur le site officiel.

J'ai plusieurs fois été tenté par une migration vers Wordpress ou un moteur de blog écrit avec RubyonRails (Typo ou Méphisto) mais à priori je vais trainer encore un peu sous Dotclear.

ActionController : Monsieur Circulation

jblanche — Wed, 30 Jul 2008 23:10:00 +0200

Dans Rails, ActionController fait la circulation, il va à chaque requête, appeler les modèles nécessaires pour récupérer les données, puis appeler la méthode render pour afficher une vue, un XML... et vous renvoyer le tout.

La politique Rails veut que les controllers soient légers.

"Skinny Controller, Fat Model"
Jamis Buck, 37signals employee

Et ça tombe bien Rails fourni tout ce qu'il faut pour vous simplifier la vie...

Imaginez par exemple que vous vouliez une interface de gestion de nos étudiants précédemment crées.
Si nos souhaits se limitent à l'ajout, modification, suppression, le scaffold de Rails ferait l'affaire, mais on va ici partir "from scratch" pour vous montrer à quel point tout ceci est aisé.

On créera alors un Controller StudentsController

script/generate controller Students

Rails2.1 permet de faire très facilement des controllers dit "Restful".

Si vous ne savez pas ce dont il s'agit je vous invite à lire l'excellente traduction de Biologeek d'un article de Softies on Rails :
Pour ne plus être en REST, comprendre cette architecture
et/ou celle-ci de pompage.net :
Comment j'ai expliqué REST à ma femme

Si vous avez lu et compris, vous aurez retenu qu'avec REST on utilise tous les verbes du protocole HTTP et qu'on parle de ressources plutôt que de pages web ou d'images...

Les ressources, dans notre cas, ce sont des étudiants et voici quelques URLs qui vont nous intéresser

GET    /students                        :action=>"index"

POST   /students                        :action=>"create"

GET    /students/new                    :action=>"new"

GET    /students/:id/edit               :action=>"edit"

GET    /students/:id                    :action=>"show"

PUT    /students/:id                    :action=>"update"

DELETE /students/:id                    :action=>"destroy"

Vous aurez compris que pour afficher un utilisateur on fera /students/:id, mais et c'est là où REST intervient, on utilisera la même adresse pour le supprimer et le modifier.

En effet une ressource = une URI, donc un utilisateur => "/students/:id"

Par contre, le type de requête HTTP, respectivement GET, DELETE ET PUT nous informera sur ce que l'on souhaite faire.

Avec Rails, les actions appelées sont les méthodes publiques des controllers, écrivons donc la méthode qui va afficher un utilisateur

def show

  @student = Student.find(params[:id])

end

Et voilà...
Quoi c'est tout :D

Oui, pour l'instant cela peut suffire, en effet Rails a récupéré notre ressource (l'utilisateur désiré) grâce au find et par défaut, il va appeler la méthode render avec la vue correspondante (show) dans le dossier des vues.

Cette dernière aura accès aux variables d'instance de notre classe et donc à l'objet @student et toutes ses propriétés.

Essayons maintenant d'écrire la méthode nécessaire à la modification (update) d'un utilisateur.

def update

  @student = Student.find(params[:id])

  @student.update_attributes(params[:student])

  redirect_to @student

end

Dans la première ligne, je récupère l'étudiant à créer.
Dans la seconde j'update ses attributs (donc propriétés) avec les paramètres passés par le formulaire.
Dans la dernière je redirige l'utilisateur vers le student modifié (cela appellera la méthode show précédemment créée)

En réalité il faudrait gérer le fait que la sauvegarde se soit ou non bien passée, cela donnerait donc :

def update

  @student = Student.find(params[:id])

    if @student.update_attributes(params[:student])

      redirect_to(@student)

    else

      render :action => "edit"

    end

end

C'est presque la même chose sauf que si la sauvegarde n'a pas fonctionné, on revient sur la page d'édition.

Voilà pour la version HTML, mais si vous avez compris REST, vous savez que l'on aimerait pouvoir avoir d'autre représentation de notre ressource qu'une page web !
Pourquoi pas par exemple, une représentation XML que l'on pourrait passer à un webservice distant ou je ne sais quel autre usage.

Ré-écrivons notre méthode show dans ce but

def show

  @student = Student.find(params[:id])



  respond_to do |format|

    format.html # show.html.erb

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

  end

end

Et voilà, notre controller répondra désormais à la demande générée.
Si vous lui demandez du HTML, celui là réagira comme précédemment, si vous le voulez en XML, il exécutera la ligne :

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

et renverra donc notre objet student converti en XML.

Vous voulez discuter avec une application Flash/Flex/AIR..., installez RubyAMF (l'équivalent Ruby de AMFPHP) et il vous suffira de rajouter :

format.amf { render :amf => @student }

Et voilà vous avez côté ActionScript votre objet tout chaud sans nécessité de désérialisation.
Et vous n'avez presque rien eu à faire côté Rails et finalement, c'est normal, la logique et la ressource sont les mêmes, seul le rendu change !

Comme vous pouvez le voir, ActionController se débrouille donc très bien pour faire la circulation entre la vue et les modèles.

Une des rares autres tâches qui incombe au controller est le contrôle des accès, si vous souhaitez vérifier que l'utilisateur connecté peut accéder à telle ou telle ressource, c'est à lui de s'en charger.

Imaginons dans notre exemple, que les étudiants puissent consulter les informations les concernant, mais que seul l'intendance puisse les éditer, ajouter, supprimer.

Ajoutons à notre controller la ligne suivante :

before_filter :authenticate , :exept => [:index, :show]

Cela signifie qu'avant toutes les méthodes sauf index et show, on exécutera la méthode authenticate et que l'on ne fera la suite que si cette méthode renvoi true.

On peut donc rajouter à la fin de notre controller la méthode authenticate :

private



def authenticate

  authenticate_or_request_with_http_basic do |username, password|

    username == "foo" && password == "bar"

  end

end

On notera que la méthode a été placée après le mot clé private afin de signifier que celle-ci n'est pas une action exécutable par le navigateur.

Notre action va ouvrir une boite de dialogue (si l'utilisateur n'est pas encore authentifier) nous demandant notre login et mot de passe et renverra true si et seulement si ceux-ci sont "foo" et "bar"
N.B. : Evidement, en réalité, cette vérification s'effectuerait en base de donnée

Et voilà, désormais seul les personnes connaissant les logins et mot de passe ont accès à l'intégralité de l'application.

Ce sera tout pour ce soir, nous avons désormais vu comment écrire du Ruby, puis, comment fonctionnent les parties Model et Controller de Rails.

Il ne nous reste donc plus qu'une partie à aborder : les vues.
A bientôt pour ce dernier chapitre.

Maintenance : Déménagement

jblanche — Sun, 27 Jul 2008 12:08:00 +0200

Cette nuit, ce blog a changé de serveur, vous avez vu quelque chose ?

Non, et bien c'est tant mieux

ActiveRecord : Vos données, c'est mon dada.

jblanche — Fri, 25 Jul 2008 22:24:00 +0200

Nous allons donc commencer par le M du M.V.C., le modèle :
ActiveRecord c'est le gestionnaire de vos données et donc la plupart du temps, de votre Base de données dans Rails
Ça tombe bien, la partie Base de données est surement la plus magique de Rails...

Question à 100 piasses : Qui aime écrire du SQL ?
Ceux qui ont répondu OUI peuvent s'en aller :D

En effet que ce soit à la création ou au traitement de vos données, vous n'écrirez pratiquement jamais de SQL avec Rails.
Mais alors comment on les crée nos bases ?

La réponse de Rails s'appelle les migrations.
Quand vous voulez créer une nouvelle table, vous créez (ou faite faire à Rails) une nouvelle migration, celle-ci comporte deux méthodes "up" et "down".

De cette manière, il sera aisé pour Rails de revenir en arrière si finalement votre implémentation de la base ne vous plait pas.

La création de ce modèle s'écrira : (à exécuter en console ou dans l'interface de votre IDE)

script/generate model Student firstname:string lastname:string date_of_birth:date section:string promotion_id:integer

On précise que l'on veut créer un modèle, on donne ensuite son nom, puis les colonnes de la base de données avec leur types.

En exécutant ceci, vous créer tous les fichiers de votre modèle dont une migration ressemblant à ceci, dans le up, on crée notre table, dans le down on la supprime.

class AddStudents < ActiveRecord::Migration

    def self.up

      create_table :students do |t|

        t.string        :firstname

        t.string        :lastname

        t.date          :date_of_birth

        t.string        :section 

        #S pour Scientifique, L pour Littéraire, ES pour Economique et Social

        t.integer       :promotion_id  

        t.timestamps

      end

    end



    def self.down

      drop_table :students

    end

  end

Plutôt simple n'est-ce pas ? Et avec ça Rails s'adaptera à votre base de données, qu'elle soit Mysql, Postgresql, Oracle, SQLite...

Et si demain vous changez Mysql pour Postgres, il suffira de faire un petit

rake db:migrate

pour récréer toutes vos tables (En réalité, Ruby éxécutera à la suite toutes les méthodes up de vos migrations).

Vous aurez surement remarqué le promotion_id, on supposera dans ce tutorial que l'on a ailleurs une table Promotion avec notamment l'année de la promo et que ce champ servira à faire le lien entre un étudiant et sa promotion.

Ok, mais cette liaison elle est définie où ? On a pas écrit les contraintes dans notre SQL là ?
Oui c'est vrai, allons donc modifier nos modèles pour changer ça. Et puisque nous y somme, nous indiquerons qu'un étudiant doit forcément avoir un nom et un prénom (lignes not null en quelque sorte)

class Promotion < ActiveRecord::Base

    has_many :students

end

class Student < ActiveRecord::Base

    belongs_to :promotion

    validates_presence_of :firstname

    validates_presence_of :lastname

  end

Difficile de faire plus clair non ?

Oui mais dans le code après comment ça se passe ?

Imaginez que vous souhaitiez récupérer tous les étudiants (en gros un SELECT * FROM students)
vous ferez simplement

Student.all

Si vous voulez récupérer la ligne correspondant à la promotion de 2006 :

promo_2006 = Promotion.find_by_year(2006)

Les étudiants de cette promo :

promo_2006.students

Allez compliquons un peu, il n'y a pas de where, pas de conditions dans nos requête actuelles, ajoutons les :

Disons que l'on ne veut récupérer que les étudiants Scientifiques.
Ajoutons à notre modèle la ligne suivante :

named_scope :scientists, :conditions => {:section => "S"}

En francais : on nommera "scientists" les étudiants ayant comme section "S"
On peut désormais écrire

Student.scientists

pour récupérer tous les étudiants scientifiques

Ces named_scope sont géniaux, ajoutons-en deux pour trouver les étudiant majeurs et mineurs.

named_scope :majors, :conditions => ['date_of_birth < ?', 18.years.ago]

named_scope :minors, :conditions => ['date_of_birth > ?', 18.years.ago]

On peut maintenant faire dans tous nos Controllers :

Student.majors

Pour récupérer les étudiants majeurs.

Et si l'on veut, dans la promo 2006, les étudiants à la fois majeurs et scientifiques :

promo_2006.students.majors.scientists

Et le tour est joué !
Incroyable non ? (qui me l'écrit en SQL avec la jointure et tout et tout ?)

C'est le moment de citer DHH :

Beautiful code makes happy programmers.
David Heinemeier Hansson, Créateur de Rails

Voilà pour les requêtes, pour créer un enregistrement, c'est tout aussi simple :

jb = Student.create(:firstname => "Jonathan", :lastname => "Blanchet")

La création précédente fonctionnera puisqu'elle remplie bien les conditions décrites précédemment (un étudiant à forcément un nom et un prénom).

Allez un dernier exemple pour la route, imaginez que la personne utilisant cette application souhaite, dans l'interface de création des utilisateurs, pouvoir les lier à une promotion en tapant simplement l'année de celle-ci.

Côté modèle, cela veut dire qu'il va falloir trouver la promotion si elle existe, la crée sinon.

Une fois traduit en Rails cela donne :

Promotion.find_or_create_by_year(params[:year])

Simple non

Allez je vous attend pour la suite, on verra le rôle du Controller.

Les autres articles :

Ruby, c'est quoi comme langage ?
Un peu de syntaxe Ruby...
Rails, la locomotive de Ruby !
ActiveRecord : Vos données, c'est mon dada.
ActionController : Monsieur Circulation
ActionView : Imprimeur de son état

Rails, la locomotive de Ruby !

jblanche — Fri, 25 Jul 2008 22:20:00 +0200

On a vu dans les deux articles précédents les rudiments de la syntaxe Ruby.
Normalement, vous êtes déjà séduit par ces débuts, mais vous n'avez encore rien vu !
Alors ? Ce Ruby on Rails, qu'est ce donc ?

Rails is the killer app for Ruby.
Yukihiro Matsumoto, Createur de Ruby

Ruby on Rails, ou Rails, en fait, est un framework dédié au développement d'application Web.
Un framework, c'est selon Wikipedia, un ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications.
Ceux-ci permettent donc de donner un socle commun à toutes vos applications et en facilite du même coup le développement et la maintenance.

Rails a été à l'origine développé pour les besoins de la société américaine 37signals qui devant le succès et l'engouement remporté par l'application au sein de son activité, a décidé d'en extraire un framework qu'elle "donnerait" à la communauté du logiciel libre.

Rails suit les principes déjà énoncés dans les articles sur Ruby et y ajoute deux grandes règles :

La convention plutôt que la configuration
Le principal défaut des frameworks Java était souvent leur configuration au travers de 18 fichiers XML tous plus flous les uns que les autres ! Avec Rails, c'est tout l'inverse : votre table s'appelle Students, votre modèle s'appellera Student... C'est également pour cette raison que Rails vient avec une architecture de fichiers et de dossiers bien précise, l'application ira dans app, les tests dans test...
DRY ou Don't Repeat Yourself
Le code doit être écrit de façon à éviter toute redondance qui compliquerait les phases de maintenances, de test, de debuggage... Les modifications doivent se faire à un endroit et n'impacter que les objets concernés.

En plus de ces deux règles, Rails comme la majorité des frameworks dédié au Web s'articule autour du modèle MVC ou Modèle-Vue-Controller.

Les modèles sont les classes assurent la gestion des données, ils sont habituellement liés à la base de données.
Les vues déterminent comment sont affichées les informations à l'utilisateur. Il s'agit généralement d'une combinaison de code HTML et de Ruby.
Les contrôleurs réagissent aux requêtes utilisateur et répondent d'ordinaire à l'aide des vues.

Pour faire simple, voici le chemin d'une requête web avec Rails :

Vous appelez une page, celle-ci correspond à une méthode, dans un controller.
Celui-ci appelle un ou plusieurs modèles pour récupérer les informations nécessaires pour vous répondre.
Il envoie ces données données à la vue qui va interpréter et renvoyer le code HTML (ou autre) désiré.
La réponse vous est envoyée.

On trouve partout sur internet, des tutoriels vous expliquant comment construire un blog fonctionnel en 10mn, un site en une demi-heure et Youtube en 2 jours
Ces tutoriels, mêmes s'ils incitent souvent les débutants à essayer Ruby et Rails, restent trop basique et trop axé sur un exemple particulier pour vraiment montrer les avantages de Rails.
Je vais donc pour ma part vous parler de chaque grande partie de Rails (selon le MVC) en vous montrant ce qui selon moi, fait la différence entre Rails et le reste du monde

On commence tout de suite avec celui qui va gérer vos données, le modèle de Rails, nommé ActiveRecord, suivez-moi...

Les autres articles :

Un peu de syntaxe Ruby...

jblanche — Sat, 19 Jul 2008 22:05:00 +0200

Vous avez apprécier l'article précédent ?
Alors, essayons d'écrire un peu plus de Ruby...

Pour commencer, si vous souhaitez tester ces exemples sur votre poste je vous invite à installer Ruby sur votre machine.
Pour les autres, vous pouvez tester en ligne ou vous contenter de lire :).

Pour l'installation, les Linuxiens se débrouillerons avec leur gestionnaire de paquets pour installer les paquets ruby irb et rdoc.

Pour les utilisateurs de Windows, je vous invite à utiliser le one-click install qui vous donnera tout ce qu'il faut pour commencer.

Comme je le disais dans le précédent article, la syntaxe de Ruby peut étonner au premier abord, mais sa lisibilité en est fortement améliorée. Regardons ces quelques lignes tirées ou inspirés du fameux "Why's (poignant) guide to Ruby" et de Softiesonrails pour s'en convaincre.

5.times { print "Hello!" }

Essayons de lire ce bout de code en anglais, Five times print Hello, je vous laisse deviner ce qu'il fait

Un autre exemple :

exit unless "restaurant".include? "aura"

En anglais lu : Exit unless restaurant includes aura
Avec cette ligne, notre programme va se terminer (exit) sauf si (unless) le mot "restaurant" contient (include?) le mot "aura".

On retiendra de cette ligne le unless , assez rare dans les autres langages qui est en fait l'inverse du if ainsi que l'utilisation très judicieuse du point d'interrogation dans le nom de méthode include? pour signifier une question, un test (est-ce que "restaurant" contient "aura" ?.
Vous aurez déduis que les méthodes ce terminant par un point d'interrogation retourneront normalement true ou false.

Allez écrivons maintenant une petite méthode (ou fonction si vous préférez, mais normalement en Programmation Orientée Objet on dit méthode).

Imaginez un appareil photo, écrivons la méthode qui prend une photo.
Celle-ci vérifiera si l'appareil est allumé et s'il reste de la place sur la carte mémoire.

def capture_clicked

  capture_image if @camera.on? && @camera.memory_available? 

end

Comme vous pouvez le constater, une méthode Ruby s'écrit avec def et end.
Pour le reste c'est encore une fois plutôt standard, vous remarquerez toutefois qu'en Ruby, on peut écrire la clause if à la fin de l'instruction ce qui améliore la lisibilité.
En effet, ce que l'on veut faire dans notre cas (99% du temps) c'est capture_screen, il est donc logique de le voir tout dès le début de la méthode et pas encadré par un if comme ce serait le cas dans beaucoup d'autres langages.

Imaginons maintenant qu'on vous demande une méthode qui prendrai des photos en mode rafale tant qu'il y a de place, vous écrieriez alors simplement :

def rafale

  capture_image while @camera.memory_available?

end

Allez un dernier exemple pour la route, écrivons une petite classe Etudiant.
Celui-ci aura un nom, un prénom et un âge.
on a déjà tous écrit un truc du style avec une classe avec trois propriétés et leurs "getters".

<br />class Etudiant

{

    private $prenom;

    private $nom;

    private $age;



    function Etudiant(prenom, nom, age)

    {

        $this->prenom = prenom;

        $this->nom = nom;

        $this->age = age;

    }



    function prenom()

    {

        return $this->prenom;

    }

    function nom()

    {

        return $this->nom;

    }



    function age()

    {

        return $this->age;

    }   

}

C'est moche n'est-ce pas !
Et bien en Ruby cela nous donne :

class Etudiant



  attr_reader :prenom, :nom, :age



  def initialize(prenom, nom, age)

    @prenom, @nom, @age = prenom, nom, age

  end



end

Alors, vous voyez bien que le mot sexy n'était pas exagéré pour décrire la syntaxe de Ruby

Pour information, si l'on veut aussi les "setters", en PHP ce sera trois nouvelles fonctions en Ruby on remplacera juste :

attr_reader :prenom, :nom, :age

par

attr_accessor :prenom, :nom, :age

et si l'on veut mettre un peu de logique dans le getter, pour récupérer le prénom avec une majuscule au début, il suffira de l'écrire à la main

def prenom

  @prenom.capitalize

end

Vous vous demandez quand même surement ce que sont ces @ que l'on peut voir devant certaines variables.
Ce signe sert à distinguer les variables d'instances (les attributs d'un objet) des variables locales (à une méthode ou autre).
Il existe également des variables notées @@ma_variable, celles-ci sont des variables de classes, elles sont donc attachées à la classe et non à son instance.

Regardez ce petit exemple pour mieux comprendre :

class Voiture

  @@nom = "Renault Clio"



  attr_accessor :nom



  def initialize(nom)

    @nom = nom

  end



  def nom

    @nom.capitalize

  end



  def se_presente

    puts "Je suis une "+@@nom+" surnomée "+nom

  end

end

ma_voiture = Voiture.new("titine")

ma_voiture.se_presente

Cet exemple va afficher
Je suis une Renault Clio surnommée Titine.
Vous remarquerez au passage que je peux appeler les méthodes sans les parenthèses, celles-ci sont optionnelles et les conventions veulent qu'on ne les écrive pas quand il n'y a pas de paramètres.

Pour résumer pour les habitués à PHP :
nom équivaut à $nom
@nom équivaut à $this->nom
@@nom équivaut à self::$nom

Alors, c'est qui qui a la plus ~~grosse~~ belle syntaxe ?
Voilà pour ce soir, j'espère que vous avez encore appris plein de belles choses sur Ruby [troll]et je m'excuse d'avance pour les larmes versées lors de votre prochaine tentative de codage en PHP, ActionScript, Cobol ou Fortran :D [/troll]

Les autres articles :

Ruby, c'est quoi comme langage ?

jblanche — Tue, 15 Jul 2008 22:35:00 +0200

Let's go...

Dans Ruby on Rails, il y a avant tout Ruby !

Ruby c'est un langage informatique, au même titre que PHP, Python, Java, C, C++, l'ActionScript...

Parmis tous ces langages, trois familles existent, les langages compilés, les langages interprétés et les langages intermédiaires.
Pour information voici comment se répartissent certains langages que vous connaissez surement :

Langages compilés : C, C++...
Langages interprétés : PHP, PERL...
Langages intermédiaires : Java, ActionScript...

Pour en savoir plus sur les différences entre ces trois familles de langages, je vous invite à lire l'explication de commentcamarche.net dont la vulgarisation est excellente (je m'étais lancé dans une explication, mais faire clair, simple et concis à ce sujet est vraiment compliqué). Puisque que c'est de lui qu'il s'agit, Ruby est un langage interprété, donc de la même famille que PHP, c'est d'ailleurs lui que j'utiliserais dans les comparaisons à venir puisqu'il est surement le langage interpreté le plus connu (au moins des lecteurs de ce blog).

D'ailleurs contrairement à la croyance qui veut que Ruby soit un truc tout nouveau qui tombera bientôt à l'eau, Ruby est en fait aussi "vieux" que PHP, leur première publication ayant toutes les deux eu lieu en 1995.

Attention toutefois, Ruby est très différent de PHP !

Pourquoi ?

Orienté Web / Peut tout faire

PHP a été crée par un développeur Web pour le développement Web, les bases de PHP viennent de la nécessité pour son créateur Rasmus Lerdorf, d'enregistrer la fréquentation sur son CV...

Ruby quant à lui, a été crée par Yukihiro Matsumotow dit "Matz" en s'inspirant notamment de PERL et Smalltalk, cela veut principalement dire que Ruby a été écrit pour être un langage applicatif "à tout faire" en allant du petit script de classement de vos images aux bibliothèques d'interfaces graphiques (il est en cela comparable au C, C++, Java...).

Non-Objet / Objet

Dans un langage objet, les objets répondent à des messages.
exemple : l'objet maVoiture reçoit un message lui demandant d'avancer donne

ma_voiture.avance()

PHP, lui, n'est pas un langage (entièrement) orienté objet.
D'ailleurs à l'origine PHP n'est pas du tout un langage objet.
Même si depuis la version 5, tout cela a bien évolué.

Toutefois, en PHP, pour mettre en majuscule un mot ou une phrase, on écrira :

strtoupper("jonathan")

On voit bien ici que "l'objet" traité est passé à une méthode au lieu de recevoir un message.

Si vous n'avez pas encore compris, regardez ce que cela donne en Ruby.

"jonathan".uppercase()

Ici c'est bien l'objet (le string) qui reçoit le message lui indiquant de se mettre en majuscule.

Une des particularités de Ruby est qu'absolument tout (ou presque) est Objet.

C'est la raison pour laquelle j'ai pu écrire "jonathan".uppercase() sans avoir auparavant créé une instance de String...

Ruby "comprend" automatiquement que ce qui est entre deux guillemets est un string et répond donc aux méthodes de cette classe.

On touche là une autre particularité de Ruby, le "Duck Typing" ou "Typage Canard" (si ça marche comme un canard et si ça cancane comme un canard, alors ce doit être un canard" ).
Le principe est donc de ne pas forcer le programmeur à utiliser une classe donnée, mais de l'obliger à mettre les données dans le format que nous voulons utiliser.
J'ai écrit "jonathan" entre guillemets, Ruby comprends que cet objet est un String.
Si j'écris [1, 14, 15] ce sera un Array (Tableau), {1=>"aaa", 2=>"b"} sera un Hash (ou tableau associatif)...

Bizarreries / P.O.L.S.

Une autre particularité de Ruby est de suivre au maximum le P.O.L.S ou "Principle of Least Surprise" ("Principe de moindre surprise").

Cela peut sembler une évidence, mais en gros cela veut dire que les méthodes font ce que leur nom laisse penser qu'elles font.

Pourtant, lorsque l'on lit la documentation de PHP, on se rend compte que ce n'est pas toujours le cas :

array_merge( array $array1 [, array $array2 [, array $... ]] )

Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.

If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

If only one array is given and the array is numerically indexed, the keys get reindexed in a continuous way.

La même chose en Ruby (méthode merge de la classe Hash) :

hsh.merge(other_hash)

Returns a new hash containing the contents of other_hash and the contents of hsh, overwriting entries in hsh with duplicate keys with those from other_hash.

Vous voyez la différence, n'est ce pas

[private joke]
On peut aussi en faire la démonstration avec AS3 et Ruby pour retourner un string :

AS3 :

myString.split('').reverse().join('')

Ruby

my_string.reverse()

[/private joke]

Voilà pour la première introduction, j'espère vous avoir donner envie d'en savoir un peu plus et je vous monterais bientot les rudiments de la syntaxe Ruby (certes un peu étrange pour un développeur PHP ou Flash, mais tellement sexy à l'usage !)

Les autres articles :

Mais Ruby, Ruby On Rails, c'est quoi en fait ?

jblanche — Tue, 15 Jul 2008 21:57:00 +0200

Comme souvent quand quelque chose vous passionne, vous ne pouvez pas vous empêcher d'en faire la promotion autour de vous.

La plupart temps il s'agit d'un groupe de musique, d'une équipe de foot, d'un réalisateur ou d'un acteur et il est assez facile d'expliquer autour de vous pourquoi votre préféré est selon vous meilleur que tous les autres.
Mais quand l'une de vos passions est le Web, vous êtes déjà un peu plus étrange.
Si vous précisez que c'est du développement Web qu'il s'agit, vous devenez carrément bizare.
Et si vous finissez en expliquant que c'est plus particulièrement de Ruby ou Ruby et Ruby on Rails qu'il s'agit, vous devenez aux yeux de votre interlocuteur un extraterrestre !

Et pourtant, c'est mon cas.
Je suis "accroc" à Ruby et Ruby on Rails et je vais donc essayer d'expliquer en quelques billets ce dont il s'agit avec des mots simples.

Ce tutoriel est désormais terminé, en voici toutes les parties :

En vrac et souvent en retard !

jblanche — Sun, 29 Jun 2008 16:43:00 +0200

La vente liée prend un coup-de-pied au c** : Désormais quand vous achèterez un ordinateur chez Darty (et surement partout ailleurs bientôt), vous connaîtrez le prix du système d'exploitations pré-installé ! A quand la possibilité d'acheter ces mêmes ordinateurs vierges ?
Tous les noms de domaines du monde : Je connais un collectif sans nom à qui cela aurait peut-être facilité l'existence
Nokia rachète Symbian, qui devient libre : un nouvel acteur fort dans le web mobile !
SproutCore : Construire des applications client en Javacript : Pourquoi pas !
Bill Gates à la retraite : on dit quoi à un mec qui a démocratisé l'informatique personnelle, avant de la pourrir ?
Wine en version 1.0 : L'émulateur qui n'en est pas un, sort enfin (15 ans de développement) en version 1.0 ! De plus en plus d'applications Windows fonctionnent sous Wine et donc sous Linux [troll]mais pourquoi utiliser des applications windows[/troll] ?

PS : Un détail a changé sur Blogbangbang, vous avez remarqué ? Mais si regardez mieux.. Non encore un peu plus haut... Voilà, vous y êtes !

john.life_steps.go_forward

jblanche — Wed, 25 Jun 2008 17:15:00 +0200

Voilà cette fois-ci il semblerait bien que ce soit la fin !
Pas de ce blog non rassurez vous il devrait même repartir de plus belle dans les jours à venir.

Je vous parlais plutôt de mes études. Après 20 ans d'études (23 - 3), en passant notamment par La Rochelle (DUT Informatique), l'Irlande ("Bachelor of science in computing") et Paris aux Gobelins (formation de Concepteur Réalisateur Multimédia en apprentissage) cette fois-ci, c'est terminé.

Au lendemain de mon dernier jour en tant qu'étudiant, les impressions sont mitigées.
Le soulagement (les derniers mois ont été intenses), la joie et la curiosité de découvrir la suite priment.

Mais on connait tous, la réaction des autres devant les étudiants, le fameux : "Ah c'était le bon temps, profites-en bien" qui vient un peu tempérer ces impressions plus que positives.
D'autant plus que même si la fin d'année dernière avait été quelque peu difficile, ces deux dernières années resteront quoiqu'il arrive un souvenir extraordinaire.

En effet, être étudiant aux Gobelins est déjà plutôt sympathique en soit, mais ce qui a fait la différence avec les autres années étudiantes, c'est la promotion.
20 personnes au départ et presque autant de très bons amis à l'arrivée[1], bilan exceptionnel !

Maintenant c'est un autre challenge qui s'offre à moi.
Après avoir effectué mes deux ans d'apprentissage dans la société Abstrakt Graphics[2], comme Développeur PHP, je m'envole vers d'autres aventures en tant que développeur Ruby / Ruby on Rails dans la société Eyeka.
Le challenge s'annonce passionnant !

Les conséquences de ce changement, j'avoue ne pas toutes les maitriser pour l'instant, mais dans un premier temps, j'espère avoir un peu plus de temps (et d'argent) à consacrer aux activités annexes (sports, concerts, cinéma...) que j'avais un peu mis de côté depuis quelques temps.

Pour ce qui est de ce blog, attendez vous a voir fleurir les articles concernant Ruby / Ruby on Rails, car à partir du 15 juillet, ce ne sera plus le sujet préféré du "geek" que je suis, mais mon métier !

[1] Je vous reparlerais surement de certains d'entre eux dans un futur très proche.
[2] Qui n'est pas étrangère non plus à l'excellent bilan de ces deux dernières année puisque travailler dans cette entreprise a été quelquechose de très agréable !

En vrac

jblanche — Wed, 04 Jun 2008 23:47:00 +0200

Pas beaucoup de temps en ce moment (pris par le projet de fin d'année de ma dernière année d'étude), donc je vous livre sans grands discours ce qu'il faut lire, voir, savoir en ce moment :

Yahoo fournit un kit d'éléments d'interfaces Web afin de faciliter la création de Wireframes.
Les UltraPortables fourmillent Eeepc700, 900, 1000, Gigabyte M912, Wind U90... Et quel OS choisit t-on le plus souvent pour faire tourner ce beau monde : Linux ( Et pourquoi mettre autre chose puisque c'est celui qui vous coûtera le moins cher à configuration matérielle égale, qu'il offre un meilleur confort d'utilisation et une meilleure autonomie !)
Ubuntu va développer Ubuntu Netbook Remix : des interfaces dédiées à ces matériels.
Les PC de salon à bas prix débarquent eux aussi (EeeBox) et là encore si vous voulez le moins cher ou mieux pour le même prix, c'est la version Linux qu'il vous faudra choisir.
Facebook libère sa plateforme de développement et encourage du même coup les développeurs à utiliser leur plateforme.

Et pour Ruby, Rails :

Rails2.1 est sorti accompagné de son lot de nouveautés.
La Railsconf avait lieu la semaine dernière et les présentations sont disponibles.
On regardera particulièrement celles-ci (liens vers les PDF) :
- Les bons conseils pour les tests
- Fuzed : une solution intérressante pour gérer la montée en charge derrière Rails (ou autre...).
- La gestion des processus longs grâce aux processus asynchrones avec Ruby et Rails.
- La méta-programmation

Bonne Lecture.

PS : Je ne vous oublie pas pour la dernière partie de ma série sur nos ressources et le "HomeServer", elle arrive bientôt.

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'à ?