vendredi 31 décembre 2010

Comment j’ai expliqué REST à ma femme


Par Ryan Tomayko






Ma femme : Qui est Roy Fielding ?
Moi : Un type. Plutôt brillant.
Ma femme : Oh ? Qu'est-ce qu'il a fait ?
Moi : Il a aidé à développer les premiers serveurs Web et ensuite a fait bonnombre de recherches sur le pourquoi du fonctionnement du Web. Son nom est dans le document technique définissant le protocole utilisé pour rapatrier des pages d'un serveur vers ton navigateur.
Ma femme : Comment ça marche ?
Moi : Le Web ?
Ma femme : Ouais.
Moi : Hmm. Eh bien, c'est assez étonnant. Et le truc amusant est que c'est vraiment sous-estimé. Le protocole dont je parlais, HTTP, peut faire plein de choses vraiment géniales que bon nombre de gens ignorent pour une raison ou une autre.
Ma femme : Tu veux dire http comme le début de la ligne que je tape dans le navigateur ?
Moi : Oui. Cette première partie dit au navigateur quel protocole utiliser. Ce truc que tu tapes là est l'une des avancées les plus importantes de l'histoire de l'informatique.
Ma femme : Pourquoi ?
Moi : Parce que cela décrit la localisation de quelque chose n'importe où dans le monde à partir de n'importe où dans le monde. C'est le principe fondateur du Web. Une façon de l'imaginer serait les coordonnées GPS pour la connaissance et l'information.
Ma femme : Pour les pages Web ?
Moi : Pour n'importe quoi. Vraiment. Ce type, Roy Fielding, en parle beaucoup dans ses travaux de recherche. Le Web est construit sur un style d'architecture appelé RESTREST fournit la définition d'une ressource, qui est ce vers quoi on pointe.
Ma femme : Une page Web est une ressource ?
Moi : En quelque sorte. Une page Web est la représentation d'une ressource. Les ressources sont juste des concepts. Les URLs -ces trucs que tu tapes dans le navigateur...
Ma femme : Je sais ce qu'est un URL...
Moi : Oh, d'accord. Ceux-ci disent au navigateur qu'il y a un concept quelque part. Un navigateur peut alors aller demander une représentation particulière du concept. De manière spécifique, le navigateur demande la représentation page Web du concept.
Ma femme : Quels sont les autres types de représentations disponibles ?
Moi : En fait, les représentations sont une de ces choses qui ne sont pas souvent utilisées. Dans la plupart des cas, une ressource a seulement une unique représentation. Mais, il y a espoir que les représentations seront utilisées plus souvent dans le futur parce qu'il y a un nombre important de formats qui apparaissent un peu partout.
Ma femme : Comme quoi ?
Moi : Hmm. Eh bien, il y a ce concept que les gens appellent « services Web ». Cela recouvre beaucoup de choses différentes pour différentes personnes mais le concept élémentaire est que les machines pourraient utiliser le Web de la même façon que les gens le font.
Ma femme : Encore un truc du genre robot ?
Moi : Non, pas vraiment. Je ne pense pas que les machines s'assoiront à une table et navigueront sur le Web. Mais les ordinateurs peuvent utiliser les mêmes protocoles pour s'envoyer des messages de l'un à l'autre. Nous avons fait cela depuis très longtemps mais aucune des techniques que nous utilisons aujourd'hui ne fonctionne très bien lorsque nous avons besoin de parler à toutes les machines dans le monde entier.
Ma femme : Pourquoi cela ?
Moi : Parce qu'elles n'ont pas été conçues pour fonctionner comme ça. Quand Fielding et ses potes ont commencé à construire le Web, être capable de parler à toutes les machines n'importe où dans le monde était une exigence première. La plupart des techniques que nous utilisons au travail pour faire communiquer les ordinateurs entre eux n'ont pas eu cette exigence. On avait juste besoin de parler avec un petit groupe de machines.
Ma femme : Et maintenant, on a besoin de parler à toutes les machines ?
Moi : Oui - et plus. On a besoin de parler à toutes les machines à propos de toutes ces choses contenues dans les autres machines. Nous avons besoin d'un moyen pour qu'une machine parle à une autre machine à propos d'une ressource qui est peut-être disponible sur une troisième machine.
Ma femme : Quoi ?
Moi : Disons que tu parles à ta soeur et qu'elle veuille t'emprunter ta moto ou quelque chose mais que tu ne l'as pas - ta mère l'a. Donc tu dis à ta soeur de la prendre directement chez ta mère. Ceci arrive en permanence dans la vie courante et cela arrive tout le temps quand les machines commencent à parler également.
Ma femme : Donc comment les machines se disent l'une à l'autre où se trouvent les choses ?
Moi : L'URL, bien sûr. Si toutes les choses dont les machines ont besoin de parler possèdent un URL correspondant, nous avons créé l'équivalent machine d'un nom commun. Que toi, moi et le reste du monde ayons décidé de parler des noms de la même façon est assez important, hein ?
Ma femme : Ouais.
Moi : Les machines n'ont pas de noms universels - c'est pourquoi elles sont nulles. Chaque langage de programmation, chaque base de données, ou tout autre système a une façon différente de parler des noms. C'est pourquoi l'URLest tellement important. Cela permet à tous les systèmes d'échanger avec tous les autres à propos de leurs noms.
Ma femme : Mais quand je regarde une page Web, je n'y pense pas de cette façon.
Moi : Personne. Sauf Fielding et quelques personnes. C'est bien pour cela que les machines sont toujours aussi nulles.
Ma femme : Et à propos des verbes, des pronoms et des adjectifs ?
Moi : Amusant que tu demandes car c'est un autre aspect important de REST. En tout cas, les verbes le sont.
Ma femme : Je blaguais, seulement.
Moi : C'est une drôle de blague mais ce n'est pas vraiment une blague en fait. Les verbes sont importants. Il existe un concept puissant en programmation et en théorie de l'informatique appelé polymorphisme. C'est une façon technique de dire que les différents noms peuvent se voir appliquer le même verbe.
Ma femme : Je pige pas.
Moi : Bon... Regarde la table basse. Quels sont les noms communs ? Tasse, plateau, journal, télécommande. Maintenant, quelles sont les choses que tu peux faire avec toutes ces choses ?
Ma femme : Je ne pige toujours pas...
Moi : Tu peux les prendre, hein ? Tu peux les attraper. Tu peux les cogner. Tu peux les brûler. Tu peux appliquer tous ces verbes sur chacun de ces objets.
Ma femme : Ouais... et alors ?
Moi : Eh bien, c'est important. Si au lieu de dire, « prends la tasse, » ou « prends le journal, » ou « prends la télécommande » que se passerait-il si nous avions besoin d'utiliser des verbes différents pour chacun des noms communs ? Je ne pourrais pas utiliser le mot « prendre » universellement, mais à la place penser un nouveau mot pour chaque combinaison verbe-nom commun.
Ma femme : Houlà. Bizarre !
Moi : Oui, en effet. Nos cerveaux sont en quelque sorte assez intelligents pour savoir que le même verbe peut être appliqué à différents noms communs. Certains verbes sont plus spécifiques que d'autres et ne peuvent être utilisés que sur un petit ensemble de noms communs. Par exemple, je ne peux pas conduire une tasse et je ne peux pas boire une voiture. Mais certains verbes sont universels comme prendre (GET), placer (PUT) et effacer (DELETE).
Ma femme : Tu ne peux pas effacer une tasse.
Moi : Bien sûr, mais tu peux la jeter. C'était une autre blague, hein ?
Ma femme : Ouais.
Moi : Enfin. HTTP -ce protocole que Fielding et ses copains ont créé- est entièrement consacré à l'application des verbes sur des noms communs. Par exemple, quand tu vas sur une page Web, le navigateur fait un HTTP GET de l'URL que tu as tapé et en retour obtient une page Web.
Les pages Web ont habituellement des images, ok ? Celles-ci sont des ressources séparées. La page Web donne juste les URLs vers les images et le navigateur fait des HTTP GETs supplémentaires sur elles jusqu'à ce que toutes les ressources soient obtenues et la page affichée. Mais la chose importante est que des noms communs de nature très différente peuvent être traités de la même façon. Que le nom soit une image, un texte, une vidéo, un mp3, un diaporama, quoi que ce soit. Je peux tous les prendre de la même façon avec un URL.
Ma femme : Il semble que GET est un verbe plutôt important.
Moi : En effet. Particulièrement quand tu utilises un navigateur Web parce que les navigateurs ne font pratiquement que prendre (GET) les choses. Ils ne font pas grand-chose d'autre, peu d'autres types d'interaction avec les ressources. C'est un problème car cela a incité de nombreuses personnes à croire queHTTP ne sert juste qu'à prendre (GET). Mais HTTP est vraiment un protocole général pour appliquer des verbes sur des noms communs.
Ma femme : Cool. Mais je ne vois toujours pas le pourquoi du comment. De quels types de noms et de verbes as-tu besoin ?
Moi : Eh bien les noms sont là mais pas dans le bon format.
Par exemple, quand tu navigues sur le site fnac.fr pour chercher des choses à m'offrir pour Noël. Imagine que chaque produit soit un nom. Maintenant, s'il existait dans une représentation que la machine pouvait comprendre, tu pourrais faire plein de choses sympas avec.
Ma femme : Pourquoi une machine ne peut-elle pas comprendre une simple page Web ?
Moi : Parce que les pages Web sont écrites pour être comprises par les gens. Une machine n'est pas intéressée par la présentation et le style. Pratiquement, les machines ont juste besoin des données. Idéalement, chaque URL aurait une version lisible par un humain et une représentation pour une machine. Quand la machine prend une ressource, elle demandera la version appropriée lisible par la machine. Quand un navigateur prend la ressource pour un humain, il demandera celle lisible par un humain.
Ma femme : Donc les gens auront à rendre toutes leurs pages lisibles par les machines.
Moi : Si c'est profitable. Regarde, nous avons parlé de tout ceci avec de nombreuses abstractions. Passons à un exemple concret. Tu es enseignante - à l'école je parie que vous avez un gros système informatique, ou trois ou quatre systèmes probablement, qui vous permettent de gérer les étudiants : dans quelles classes sont-ils, quels cours ils suivent, les contacts en cas d'urgence, l'information à propos des livres de cours, etc. Maintenant, prends l'URL pour chacun de ces noms suivants : élève, enseignant, classe, livre, salle de classe, etc. De nos jours, demander l'URL avec un navigateur te permet d'obtenir une page Web. S'il existait une version machine de la représentation pour chaque URL, il serait trivial de créer de nouveaux outils sur le système car toute cette information serait « consommable » d'une façon normalisée. Il serait aussi plus facile pour chacun des systèmes de communiquer entre eux. Ou, tu pourrais construire un système national ou régional qui serait capable de communiquer avec chacun des systèmes individuels des écoles pour compiler les bulletins scolaires. Les possibilités sont infinies.
Chacun des systèmes obtiendrait l'information des autres en utilisant un simpleHTTP GET. Si un système a besoin d'ajouter quelque chose à un autre système, il utiliserait HTTP POST. Si un système veut mettre à jour quelque chose dans un autre système, il utilise un HTTP PUT. L'apparence des données restant la seule chose qui doit être définie.
Ma femme : Donc, c'est ce sur quoi, toi et tous les ingénieurs en informatique travaillent en ce moment ? Décider à quoi doivent ressembler les données ?
Moi : Malheureusement, non. À la place, la grande majorité de ceux-ci sont occupés à définir des couches de spécifications complexes pour traiter ce problème d'une façon différente qui est loin d'être aussi utile ou claire. Les noms ne sont pas universels et les verbes ne sont pas polymorphes. Nous sommes en train de jeter des dizaines d'années d'utilisation concrète et de techniques éprouvées et commençons avec quelque chose qui ressemble beaucoup à d'autres systèmes qui ont précédemment échoué. La seule raison pour laquelle nous utilisons HTTP est de nous épargner des discussions avec nos responsables réseaux et sécurité. Nous sacrifions la simplicité pour des outils flashy et magiques.
Ma femme : Pourquoi ?
Moi : J'en ai aucune idée.
Ma femme : Pourquoi tu n'en dis rien ?
Moi : Je le ferai peut-être un jour.

jeudi 30 décembre 2010

Rails 3 : Episode 1 => Bundler et Gemfile

Pour ne pas être long: Rails 3 est devenu un outil de développement de "tous les jours" pour nous et pour beaucoup d'autres Rubyistes qui font du web de la plus belle des manières : en faisant du Rails.
Et pour tout "gros" projet, nous faisons face à un nombre de défis. Et si l'on prend l'exemple de l'environnement de développement qui est souvent différent de celui du déploiement, ce qui implique donc une gestion des dépendances de notre application pour s'assurer son bon fonctionnement.

Ce qui nous rappelle l'un des pires cauchemars des développeurs:
chez moi ça marche mais pas sur le serveur ".
 Heureusement pour nous (rubyistes), les  gestionnaires de dépendances écrits en Ruby ne manquent pas. Le plus célèbre parmi eux c'est Bundler une GEM qui permet de faire plus que la gestion de dépendances.



Getting started with bundler is easy : 
$ gem install bundler
Utilisation : (un résumé de ce que vous pouvez faire avec Bundler)
Pour faire son boulot, Bundler exige la présence d'un fichier nommé Gemfile. Ce fichier contient la liste des dépendances et aussi pour quels environnements (aussi appelés groupes) : développement, test et production.
Il est facultatif de spécifier l'environnement pour lequel on veut gérer les dépendances. 
Un Gemfile ressemble à ça : 




Nous avons une "source"; là où Bundler ira chercher les GEMs listées et puis "gem" suivie du nom de la GEM et de sa version. Si la version n'est pas spécifiée, Bundler utilisera la dernière version stable disponible.
Bundler est utilisé par défaut par Rails 3. Donc on comprend un peu mieux la présence de ce mystérieux "Gemfile" dans nos projets Rails.
Voici quelques commandes de Bundler : 
$ bundle
s'assure que toutes les dépendances spécifiées dans le Gemfile sont bien présentes sur le système sinon il les installe depuis la source spécifiée. Il utiliser RubyGems par défaut.
$ bundle show [nom_gem]
Affiche la liste des GEMs spécifiées dans le Gemfile et leurs dépendances. Si nom_gem est spécifié, il renvoie l'emplacement de nom_gem sur le système.
$ bundle open <nom_gem>
Ouvre le code source de nom_gem dans votre éditeur par défaut.
$ bundle update [nom_gem]
Recrée le Gemfile.lock et lance "bundle" pour installer les nouvelles dépendances.
$ bundle check
Vérifie que les dépendances sont satisfaites par les GEMs installées sur le système.
$ bundle package
Copie toutes les dépendances du projet dans "vendor/cache". Utiliser quand l'application est déployée en local.
----------------------------------------------------------------
<> : obligatoire | []: optionnel 
----------------------------------------------------------------


Dans le prochain épisode nous parlerons de : ActiveRelation.

mardi 28 décembre 2010

Discovering Sinatra : episode 1 - what is Sinatra ? -



Sinatra est un framework web. Bref, c'est une bibliothèque qui vous permet d'écrire des applications web avec un minimum de formalités administratives. Vous n'avez plus qu'à charger Sinatra, et commencer à coder la logique applicative. Mais cela semble terriblement familier, n'est-il pas? Il ya beaucoup d'autres frameworks diront certains (en particulier dans la communauté Ruby), alors qu'est ce qui rend si différent Sinatra ?

Au lieu de parler de ce que Sinatra est, parlons de ce qu'il n'est pas. Voici donc quelques-unes des "choses" que Sinatra n'est pas.

-> Big - Sinatra est minuscule. Vraiment minuscule. Environ 1500 lignes de code soit environ 1% de la taille de Rails.

-> La solution absolue à vos problèmes - Sinatra ne résout pas vos problèmes en claquant vos doigts. Il ne fait rien que rails ou d'autres frameworks ne peuvent faire. C'est juste un framework web.

-> L'outil idéal pour tous les emplois - d'autres frameworks peuvent être meilleurs que Sinatra pour certains types d'applications. Les "gros" projets sont plus abordables avec des frameworks tels que Rails ou Merb. Sinatra est adapté pour des projets à petite et moyenne échelles.

En termes simples, Sintra est un framework web minimal et élégant. Il n'inclut pas plusieurs centaines d'assistants(helpers), ou une bibliothèque ORM (comme ActiveRecord, DataMapper ou Sequel), ou moteur de templating (Haml, Mustache, etc).
Sinatra est fier de sa petite taille :), et cela se reflète dans vos applications.
Les applications Sinatra sont souvent écrites dans un seul fichier quelque soient leurs tailles.

Alors pour quels types d'applications pouvons-nous utiliser Sinatra? De petites applications web, par exemple. Rails est tout simplement trop grand pour sortir de sa propre voie, parfois vous n'avez pas besoin de tout ce qu'il embarque. Un "petit" framework est souvent un bon choix pour une petite(ou moyenne) application. Une autre grande utilisation de Sinatra: les web services. Sa simplicité, son "indépendance" et sa philosophie font de Sinatra un outil idéal pour écrire des API et web services.

Une dernière chose à dire, Sinatra c'est juste du code Ruby. Oui, il s'agit d'un DSL (Domaine Specific Language), mais ça reste du Ruby.
Vous pouvez utiliser toutes les GEM Ruby que vous voulez, et c'est facile.
Vous voulez réaliser une "backed end application" (une application utilisant une base de données) pas de soucis Utiliser un ORM(DataMapper, ActiveRecord ou n'importe quel autre ORM) pour vos modéles.
Vous voulez à la sortie du XML? Très facile, juste utiliser "Builder" (par exemple) et allez-y. Il n'y a rien qui se met entre vous et votre code.

lundi 29 novembre 2010

Introduction au langage Ruby


Le langage Ruby, au départ très confidentiel car ne disposant que d'une communauté japonaise, gagne en popularité, au point d'être comparé à Python quand il s'agit de définir un langage simple d'accès et complet.

Plus récemment, Ruby s'est distingué sur le terrain de PHP grâce à un framework de création d'application Web très complet, baptisé Rails. Ruby On Rails gagne peu à peu le coeur des développeurs voulant prendre leur distance face à un PHP considéré comme bancal et trop proche de Java.

Ruby est une combinaison de Smalltalk pour l'utilisation de l'Objet, de Python pour la simplicité d'utilisation, et de Perl pour la flexibilité (Ruby étant par ailleurs un clin d'oeil à Perl). Sans être la réponse à tous les problèmes des programmeurs, il mérite que l'on s'intéresse à son approche inhabituelle du développement.

Présentation
L'initiateur de Ruby, Yukihiro "Matz" Matsumoto, l'a créé en 1995 autour d'une idée, "quick and easy" (rapide et simple) : le langage devait être non seulement rapide à prendre en main, mais également faciliter le développement d'applications, sans pour autant en limiter les possibilités. Ruby, un langage interprété et orienté Objet, dispose des caractéristiques suivantes :
- une syntaxe très simple
- des variables non typées, dont la déclaration est facultative
- une gestion interne de la mémoire
- une application stricte de la règle "tout est objet"
- la possibilité d'appeler des modules externes

Ceux qui pensaient avoir trouvé en Python l'idéal de la syntaxe simplifié (abandon des points-virgules et des accolades, blocs délimités par l'indentation) trouveront en Ruby une syntaxe parfois encore plus simple. En revanche, cette syntaxe prend parfois une distance telle par rapport aux syntaxes habituelles (type C) que Ruby ne peut être recommandé comme premier langage, ou langage d'apprentissage : la transition vers d'autres serait plus ardue qu'avec, par exemple, Python.

Pour utiliser Ruby, des installateurs sont disponibles en ligne pour Windows, Mac OS X et autres.


Un premier programme
Voici un premier programme Ruby, présentant quelques caractéristiques vitales. Notez que les programmes Ruby sont contenus dans des fichiers portant l'extension .rb.

# Méthode bonjour()
def bonjour(nom)
      resultat = "Bonjour, " + nom
      return resultat
end

# Programme principal
3.times do
puts bonjour("petit canard")
end


Ce petit programme, une fois lancé, affiche le résultat suivant :
Bonjour, petit canard
Bonjour, petit canard
Bonjour, petit canard

Nous voyons ici comme créer une méthode, transmettre un paramètre et créer une simple boucle.

def en Python permet de créer une fonction, tandis qu'en Ruby il créé une méthode de la classe Object, la racine de la hiérarchie des classes de Ruby. Toute méthode se termine par le mot-clef end. Notre méthode, bonjour(), prend un seul argument, que nous adjoignons à la chaîne "Bonjour, " via le signe de concaténation +. Nous mettons enfin le tout dans la variable resultat, qui ne sert qu'une fois, car renvoyée aussitôt par return vers l'instruction ayant appelé la méthode.

3.times est une construction particulière de Ruby : times est ici une méthode de l'objet 3. En effet, tout dans Ruby étant un objet, 3 est donc automatiquement reconnu comme un objet de type Integer (Entier) : il dispose donc de toutes les méthodes rattachées à cet objet. i.times est une méthode permettant de lancer une itération, c'est-à-dire une boucle, entre 0 et i-1. Les instructions placées entre les mots-clefs do et end seront donc répétées ici trois fois. Ruby dispose d'autres manières de créer des itérations ; notablement, chaque type de données dispose de son propre jeu d'itérateurs, ce qui rend le code beaucoup plus facile à lire et écrire.

puts, enfin, est l'équivalent Ruby du echo de PHP, du print de Python ou du sprintf() de C : elle affiche le contenu d'une chaîne à l'écran. En l'occurrence ici, la chaîne est renvoyée par l'appel de fonction bonjour(), donc c'est le résultat qui est affiché trois fois. Ici encore, Ruby dispose d'autres méthodes permettant d'afficher une chaîne, puts étant propre à ce langage.



Ce premier exemple permet déjà de découvrir quelques-unes des spécificités de ce langage, et d'apprécier la manière dont il a été conçu. Nous plongerons plus en avant dans ses fonctionnalités dans de prochains articles, pour culminer avec une application faisant usage du fameux framework Rails.

 

jeudi 4 novembre 2010