Archive for the ‘ Nouvelles technologies ’ Category

save me from firesheep

Aux amoureux de FF (personnellement je préfère Chrome) :
Je suis vraiment triste de ne pas pouvoir installer firesheep sous mon ubuntu… qui plus est que je suis sous ethernet au travail donc je ne peux pas m’amuser à pirater des comptes FB, twitter, MSN, etc. facilement T_T….
Par contre, pour ceux qui souhaitent ne pas se faire « firesheep-é » (est-ce que ce terme existe déjà ?), vous pouvez toujours installer Force-TLS
Je suis gentille n’est ce pas? j’ai mis les liens XD

PS: Firesheep est un add-on firefox sniffeur –> DEMO

couchDB

Maintenant que vous savez ce que c’est NoSQL et REST (si ce n’est pas le cas, vois ces articles dans la catégorie « Tutoriels » à droite), voici donc l’exemple « couchDB » qui adhére à ces 2 concepts.

Primo, selon la définition par Wikipedia à ce jour, coucheDB est : un système de gestion de base de données libre et orientée documents, écrit en langage Erlang.

Secondo, lisez l’article rédigé par mon collègue « Lou Ferrand » ( qui a déjà été cité dans l’article « NoSQL » pour que vous vous remémorez ce qu’est couchDB), cela évitera que je répète des explications déjà bien fournies ^^

Je vais quand même être gentille (pour les paresseux) et donner ma définition propre : CouchDB est un projet Apache de gestion de bases de données non relationnelles, sans utilisation de SQL mais se reposant sur l’architecture REST afin d’exploiter les capacités de HTTP et de … JSON via … ERLANG.

Vous allez me dire :

-impossible de gérer des données sans SQL!! Et bien figurez-vous que si!!

-Si pas de SQL, comment faire les joitures complexes?? (du genre, toutes les factures non payées des clients qui ont déposé leur bilan) … je n’ai pas encore trouvé l’argument pour appuyer ma phrase : « Pas besoin de jointures complexes puisqu’il n’y a plus de SQL ». Mais la réponse est cette phrase. Je vous en dirais plus lorsque je serais experte ^^ (tôt ou tard^^)

– Comment va-t-on manipuler les données si on n’utilise plus de SQL ? voir ci-dessous

Dans la suite, je vais juste vous présenter les basiques en PHP, reste à vous d’élargir votre périmètre 🙂
Je suis partie d’un tutoriel rédigé en anglais.
Il est nécessaire d’installer couchDBX
/*
* Nous allons définir les paramètres du serveur
*/

$serveur['host'] = "localhost";
$serveur['port'] = 5984;

/*
* Une instance de couch que l’on va utiliser pour les tests
* (on établit la connexion)
*/
$couch = new CouchSimple($serveur);

/*
* Commençons par tester la connexion
*/
$resp = $couch->send(« GET », « / »);

/*
* Qui répondra normalement [response: string(46) « {« couchdb »: « Welcome », « version »: « 0.10.1 »} »]
*/
var_dump($resp); // response: string(46) « {« couchdb »: « Welcome », « version »: « 0.7.0a553″} »

/*
* Récupération de la liste des bases de données
*/

$resp = $couch->send(« GET », « /_all_dbs »);
print « Get a list of all databases in CouchDb « ;
var_dump($resp); // string(17) « [« test_suite_db »] »

/*
* Création d’une nouvelle base de données
*/
$resp = $couch->send(« PUT », « /test »);
var_dump($resp); // string(12) « {« ok »:true} »

/*
* Récupération de tous les documents enregistrés dans cette base de données
*/
$resp = $couch->send(« GET », « /test/_all_docs »);
var_dump($resp); // string(27) « {« total_rows »:0, »rows »:[]} »

/*
* Il est nécessaire de comprendre le principe de REST
* Si on utilise PUT, il faudra mettre
* $resp = $couch->send(« PUT », « /test/123 », ‘{« _id »: »123″, »data »: »my data2″}’);
* Si on utilise POST, il faudra mettre
* $resp = $couch->send(« POST », « /test », ‘{« _id »: »123″, »data »: »my data »}’);
*/
print « Create a new document in the database test with the id 123 and some data »;
$resp = $couch->send(« POST », « /test », ‘{« _id »: »123″, »data »: »my data »}’);
var_dump($resp); // string(42) « {« ok »:true, »id »: »123″, »rev »: »2039697587″} »

/*
* Afin de gérer les modifications concurrente, couchDB ne donne pas droit à une modification
* que si on lui renseigne la dernière révision du document à modifier.
* Comment? en récupérant cette révision (_rev)
*
*/
$resp = $couch->send(« GET », « /test/123?_revs=true »);
var_dump($resp);

/*
* Méthode bourrin pour récupérer la révision
*
*/
$tab = split(« : »,$resp);
$tab = split(« \ » »,$tab[2]);
print « revision = « .$tab[1];

/*
* Modifier un document en renseignant la dernière révision
*/
print « Trying to modify a document in the database test with the id 123 and some data »;
$resp = $couch->send(« PUT », « /test/123 », ‘{« _rev »: »‘.$tab[1].' », »data »: »modified data »}’);
var_dump($resp); // string(42) « {« ok »:true, »id »: »123″, »rev »: »2039697587″} »

/*
* Récupération à nouveau de tous les documents dans la base de données qu’on a créé
* On voit que le document précédemment modifié a bel et bien changé de contenu
*/
print « Get all documents in test again, seing doc 123 there »;
$resp = $couch->send(« GET », « /test/_all_docs »);
var_dump($resp); // string(91) « {« total_rows »:1, »offset »:0, »rows »:[{« id »: »123″, »key »: »123″, »value »:{« rev »: »2039697587″}}]} »

/*
* On voit que le document précédemment modifié a bel et bien changé de contenu
*/
print « Get back document with the id 123 »;
$resp = $couch->send(« GET », « /test/123 »);
var_dump($resp); // string(47) « {« _id »: »123″, »_rev »: »2039697587″, »data »: »my data »} »

/*
* Suppression de la base de données qu’on a créé
*/
print « Delete our \ »test\ » database »;
$resp = $couch->send(« DELETE », « /test/ »);
var_dump($resp); // string(12) « {« ok »:true} »

/*
* La classe couchSimple
*/

class CouchSimple {
function CouchSimple($serveur) {
foreach($serveur AS $key => $value) {
$this->$key = $value;
}
}

function send($method, $url, $post_data = NULL) {
/*
* Initialisation d’une connexion par socket
*/
$s = fsockopen($this->host, $this->port, $errno, $errstr);
if(!$s) {
echo « $errno: $errstr\n »;
return false;
}

$request = « $method $url HTTP/1.0\r\nHost: localhost\r\n »;

if($post_data) {
$request .= « Content-Length: « .strlen($post_data). »\r\n\r\n »;
$request .= « $post_data\r\n »;

}
else {
$request .= « \r\n »;
}

fwrite($s, $request);
$response = «  »;

while(!feof($s)) {
$response .= fgets($s);
}

list($this->headers, $this->body) = explode(« \r\n\r\n », $response);
return $this->body;
}
}

REST … zen

Nous avons vu précedemment ce qu’est « NoSQL ». Avant de donner un exemple de base de données (couchDB) que j’aborderai prochainement, parlons d’abord de REST sur lequel l’architecture des bases de données NoSQL se reposent généralement.

Alors qu’est ce que REST ?

REST (Representational State Transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding en 2000 dans sa thèse de Ph.D.

REST est un style d’architecture web axé sur l’exploration via des liens en exploitant pleinement les capacités du protocole HTTP. Les services web ou bases de données suivant ce concept possèdent une architecture où le serveur n’a pas à connaître le client spécifique auquel il s’adresse. Comme le client ne fait que suivre des liens, l’un après l’autre, la notion « d’état » du client n’a même pas à être connue par le serveur : c’est le client qui sait où il est, et où il va aller à l’étape suivante. REST repose sur les standards qui fondent l’infrastructure du Web et c’est là son paradoxe : on ne peut pas pour autant en écrire de spécification précise. REST est un style d’architecture, pas une architecture concrète qui sert de standard : il n’existe pas de spécification du W3C pour la décrire. Il s’agit plutôt d’un « mode de compréhension du Web » sur lequel le développeur construit ses services.

L’information de base, dans une architecture REST, est appelée ressource. Toute information qui peut être nommée est une ressource : un article d’un journal, une photo, un service
ou n’importe quel concept. Une ressource est identifiée par un identificateur de ressource. Il permet aux composants de l’architecture d’identifier les ressources qu’ils manipulent. Sur le web ces identificateurs sont les URI (Uniform Resource Identifier). Les composants de l’architecture manipulent ces ressources en transférant des représentations de ces ressources. Sur le web, on trouve aujourd’hui le plus souvent des représentations au format HTML ou XML. Il est important de préciser que l’identificateur d’une ressource doit être une URI unique et non une URL. URL(Uniform Resource Locator) est un chemin d’accès et non un identifiant. Par exemple, http://www.twitter.com est un chemin d’accès à des flux d’information et non une identification d’un flux précis.

REST est une architecture partant du principe selon lequel Internet est composé de ressources accessibles à partir d’une URL. Par exemple, pour avoir le temps à Paris, un utilisateur
pourrait utiliser une adresse de la forme http://www.meteo.fr/paris/. « Paris » serait alors une ressource. REST est également un type d’architecture pour les systèmes distribués qui propose
de représenter un modèle de données et des services sous la forme de ressources. L’idée est de se reposer sur des méthodes standards du protocole HTTP pour manipuler une ressource. Simplement, REST part du principe selon lequel HTTP suffit largement à l’ensemble des besoins d’un service ou d’une application Web, pour peu qu’on utilise l’ensemble des méthodes de ce protocole. L’accès à une ressource par un composant se fait par appel à cette ressource grâce à son URI en utilisant le protocole HTTP. HTTP implémente les verbes GET, HEAD, PUT, POST, DELETE, etc. (ah bon? il y a d’autres verbes HTTP que GET et POST? … :p) qui permettent aux composants de manipuler les ressources de manière simple et « intuitive ». Lorsqu’un client web récupère un URI, il sait qu’il peut récupérer une représentation de cette ressource en déréférençant l’URI avec la méthode GET.

Alors, selon l’école, il peut y avoir des interprétations légèrement différentes des verbes (appelées aussi méthodes)  POST et PUT . Je vais donc vous donner ma version (bien évidemment celle qui me semble la plus appropriée)

POST : Modification ou ajout d’une nouvelle ressource

PUT : Modification ou ajout d’une nouvelle ressource

Mais si PUT et POST permettent d’ajouter/modifier une ressource, laquelle est la plus adéquate?

J’utilise PUT  pour ajouter une nouvelle ressource lorsque l’emplacement de la nouvelle ressource est déjà défini dans l’URI, sinon j’utilise POST.

J’utilise PUT lorsque je renseigne toutes les informations nécessaires à la création/modification de la ressource. Sinon j’utilise POST.

Ce dilemme d’utiliser POST ou PUT est un vrai casse tête pour les « débutants » (ceux qui n’ont pas l’habitude d’utiliser les méthodes HTTP). L’article de John Calcote (très explicite) sur ce sujet m’a bien éclairé sur leur différence donc je vous laisse le lire pour plus amples informations.

J’espère avoir pu vous expliquer ce qu’est REST … à bientôt pour couchDB ^^

HCARD

Je ne suis pas experte en la matière, mais je souhaite quand même le partager avec vous :). Le web sémantique nous offre pleines de possibilités. J’ai eu l’occasion dans un de mes projets personnels d’utiliser le microformat HCARD. Une librairie JAVA est disponible ici malgré une relative difficulté de compréhension sur le mode d’utilisation dans une classe …

A l’époque, j’étais en train de découvrir les capacités de la « généricité » alors j’espère que vous serez assez tolérant sur cet exemple d’utilisation.

Et comme on ne fait pas d’omelettes sans casser des oeufs, consultez ce tutoriel.

Choco

Voici un article rédigé par « Lou Ferrand » (et oui, il m’aide à faire mes veilles technologiques) sur le framework « Choco », hope you enjoy it!

Choco est une petite nouveauté dans le paysage des frameworks web implémentant le pattern MVC. Sa particularité est que vous développez vos contrôleurs entièrement en JavaScript. Dans ce sens, il nous rappelle un peu SproutCore et Cappuccino mais, à mon avis, Choco est beaucoup plus léger et simple.

Le framework en question repose sur trois bibliothèques JavaScript:

  • Sammy, lui-même un framework JavaScript créé à partir de jQuery, imitant le fonctionnement de Sinatra
  • js-model permet de manipuler des structures de données à la manière d’ActiveRecord
  • Jim, un gestionnaire de packages pour JavaScript

On sent clairement que le développeur s’est inspiré de Rails pour développer ce framework, d’ailleurs Choco est un gem Ruby (voici la page sur RubyGems.org : http://rubygems.org/gems/choco). Vous devrez utiliser la commande rake choco:js:install pour installer les dépendances JS (jQuery, Sammy, etc)

Ensuite, comme pour déployer une application Ruby on Rails, vous devez taper la commande :

$ choco server
*** Choco server is now running on port 9292
*** Launch http://localhost:9292/index.html to start your Choco application

Un serveur Rack est lancé, désormais si tout se passe bien et que vous ouvrez votre navigateur favori à l’adresse http://localhost:9292/index.html, vous devriez voir un Welcome to Choco! apparaître. Si ce n’est pas le cas, c’est sans doute car vous n’avez pas installé les dépendances avec la commande rake.

Sachez toutefois que Choco sert à créer une application web contenant sur une page HTML unique, le contenu sera donc chargé dynamiquement. C’est pour cela que vous verrez qu’un #main est ajouté en fin de l’adresse.

Prenons un exemple connu : dans Gmail la boîte de réception est accessible via https://mail.google.com/mail/#inbox et vous gérez les brouillons sur https://mail.google.com/mail/#drafts, mais la page ne se recharge pas à chaque changement de rubrique. Le même principe est appliqué dans l’interface que vous pourrez développer avec Choco.

Pour le reste, c’est à vous de jouer.

Auteur : Lou Ferrand

Adieu GW

Mieux vaut tard que jamais, mon hommage au projet Google Wave qui a contribué à pas mal de mes projets universitaires …

PS: l’appli est encore disponible mais le développement par Google n’aura plus vraiment de suite, sauf par peut être par des fans dévoués …. 😦

Wanna try CSS3?

Tout simplement énorme! Voici un exemple de mon petit divertissement étant donné que je ne suis pas (encore) experte en CSS3. Pour l’essayer, je vous recommande ce site.

HTML …

Un de mes collègues de formation m’avait dit un jour : « Je propose que les gens qui confondent HTML et programmation soient limités sur Internet à une lecture seule ». Je trouvais cette remarque assez amusante.

Suites aux expériences que j’ai eu, effectivement, beaucoup de gens pensent que HTML est un langage de programmation, pourquoi? Peut être parce que HTML utilise des termes spécifiques qui sont différents du langage humain (balises, JS, CSS, etc…). Mais souvent cette confusion provient des … clients.

Je n’ai nul intention de les reprocher pour cela, car ils ont le droit de ne pas savoir, mais c’est à nous, « avertis » en la matière, de tolérer ces propos. Justement, si les clients avaient le temps de s’y pencher, ils n’auraient pas fait cette erreur de conclusion. Cependant, les clients devraient prendre en considération le vrai travail des développeurs ( et/ou programmeurs) et écouter leur conseil.

Chers clients, ils sont là pour vous aider. Bien évidemment, on est actuellement dans un monde où le client est roi, mais comme dans beaucoup de cas, votre développeur ne pense qu’à satisfaire vos besoins (il y a aussi la rémunération mais bon …).

En vous laissant sur cette réflexion, voici un bonus pour les plus curieux ^^

PS: cet article est volotairement mis dans la catégorie « nouvelles technologies » pour subtilement attirer l’attention sur HTML 5 .