Jul/090
Première utilisation de CouchDB
Maintenant que la base est disponible, le but va être de remplacer le code JSON présent dans le contrôleur de test, par des données réelles - c’est à dire alimentées par la base documentaire.
Création d’un document
La première étape sera de créer un élément en base de données. Pour cela, nous utilisons futon.
En cliquant sur la base de données dans l’interface d’administration, on accède à un menu permettant de créer un nouveau document. Un document peut posséder n’importe quel schéma, c’est à dire n’importe quel ensemble de {clés, valeurs}
. Lorsque l’on crée un document, le seul champ obligatoire à saisir est l’identifiant - qui peut être n’importe quelle valeur.
Jul/090
Mise en oeuvre CouchDB (Rake, tests)
CouchDB sera notre base de données documentaire afin de stocker les éléments de façon permanente.
Nous allons donc installer un serveur CouchDB, et mettre en place les éléments permettant ensuite de l’exploiter dans notre application.
Jul/090
Utilisation de structures pour JSON
Jusqu’à présent, les données renvoyées étaient fournies sous forme d’un flux final de caractères :
handle_http(Req, {'GET', json}, _) -> ercm_ctx:return_json_data(Req, "{title:'Test',content:'Data loaded from server'}").
On doit pouvoir construire la structure JSON de façon dynamique et efficace. Pour cela, il faudra créer les structures attendues par le module mochijson2
.
Ce module permet de renvoyer un flux JSON via la méthode encode/1
. La méthode attend en paramètre (voir la documentation de Mochiweb) un json_object()
. Cet objet est défini ainsi :
{struct, [{json_string(), json_term()}]}
json_term()
permet une définition récursive. Ce qui nous intéresse est le json_string()
qui est représenté soit par un atome, soit par un binaire.
Ce qui fait que le flux JSON précédent peut s’écrire de cette façon :
{struct, [{<<"title">>,<<"Test">>},{<<"content">>,<<"Data">>}]}
Cette notation étrange est celle des binaires. On pourrait utiliser des atomes pour les clés comme ci dessous, mais le fait qu’il y ait un nombre limité d’éléments fait que ce n’est pas une bonne idée :
{struct, [{title,<<"Test">>},{content,<<"Data">>}]}
Pour que ce flux puisse être renvoyé, il doit être encodé :
handle_http(Req, {'GET', json}, _) -> Json = {struct, [{<<"title">>,<<"Test">>},{<<"content">>,<<"Data">>}]}, Result = mochijson2:encode(Json), ercm_ctx:return_json_data(Req, Result).
On peut alors simplifier les traitements en modifiant légèrement la fonction return_json_data/2
comme suit (chaque fonction est dans un fichier différent) :
return_json_data(Req, Data) -> Json = {struct, Data}, Result = mochijson2:encode(Json), Req:ok({"application/json", [], Result}). handle_http(Req, {'GET', json}, _) -> Json = [{<<"title">>, <<"Test">>}, {<<"content">>, <<"Data">>}], ercm_ctx:return_json_data(Req, Json).
C’est tout (mais comme j’ai du temps en ce moment, j’en profite…).
Sources : http://github.com/rv/ercm/tree/blog04.
Jul/090
Installation d’un serveur web
La boucle de réaction aux requêtes utilisateurs est trop permissive et permet un accès fichier pour toute URL non reconnue.
On la transforme donc suivant le code suivant :
case Path of "test" -> ctrl_test:handle_http(Req, Params, Data); _ -> Req:respond({501, [], []}) end.
Seulement, les fichiers statiques devront continuer à être fournis au client. Pour cela, on installe un serveur web en frontal du service, et Nginx sera utilisé à cette fin.
En utilisant Arch, l’installation est simple :
yaourt -Sy nginx
On modifie la configuration afin de le faire pointer vers le répertoire des ressources statiques et également pour faire le routage vers notre serveur applicatif Mochiweb. La configuration est stockée dans le fichier /etc/nginx/conf/nginx.conf
et on la modifie comme suit :
server { listen 80; server_name localhost; # Serve static files location ~ ^/assets/ { root /d/apps/ercm/priv/www; expires 30d; } # Serve html views location ~ \.html$ { root /d/apps/ercm/priv/www; } # Anything else is redirected to Mochiweb location / { proxy_pass http://127.0.0.1:8000; }
Pour le démarrer, rien de plus simple :
sudo nginx
Le site doit fonctionner comme avant. Toute URL ne commençant pas par /assets
sera redirigée vers Mochiweb.
Attention ! Il s’agit d’une configuration de développement/test et non pas d’un exemple de ce qu’il faut faire en production, bien évidemment.
Jul/090
Modules et contrôleurs
Erlang est un langage qui permet de créer et maintenir des applications complexes et volumineuses (en lignes de code). Pour ce faire, il est donc important de pouvoir découper de façon logique les programmes.
Ici, on utilisera la notion de modules. Rien d’extraordinaire en l’occurrence.
Jul/090
Sécurisation des accès aux URL et REST
Le premier développement Erlang sera de pouvoir sécuriser un petit peu l’accès à l’application, et préparer le futur système de routage.
La sécurisation d’une application passe par la possibilité de restreindre les vecteurs d’attaque potentiels et de ne permettre l’utilisation de l’API que de la façon dont on l’a imaginée.
Ainsi, notre requête /test
ne devrait être accessible que par méthode GET, et uniquement dans le cadre d’un appel Ajax.
De plus, on essaiera d’avoir un fonctionnement proche d’une architecture RESTful.
Jul/090
Traces
Avant de pouvoir commencer les développements Erlang, il est intéressant de savoir comment « débuguer » (!!! pfff) et générer des traces.
Comme pour les autres fonctions Erlang, il peut être consommateur de temps de trouver les informations nécessaires.
Pour les traces, un système « simple » et immédiat sera de tracer les informations dans la console, via le shell.
Jul/090
Comportements Ajax génériques
Le test Ajax prédédent va être modifié afin d’aporter de la généricité dans les comportements, et la possibilité d’avoir plusieurs blocs sur la même page, sans toucher aux modèles.
Pour cela, nous allons travailler principalement sur le javascript.
Jul/090
Le retour de Ruby : Haml
On ne change pas les bonnes habitudes, et une des premières chose qui me manque sur ce projet est l’utilisation des outils tels que Haml et Sass1.
Heureusement, il est très simple de les rajouter !
Jul/090
Contrats au forfait et agilité
Non lié à Erlang, mais un article très intéressant a été publié sur DrDobbs qui reflète tout à fait mes pensées sur le fonctionnement inadapté entre clients et fournisseurs (SSII) lors de projets aux forfaits.
Depuis quelques temps, on constate que des entreprises demandent des « garanties » (fictives en réalité) fortes via un contrat de type forfait (donc obligation de résultats) tout en laissant entendre implicitement - voir même explicitement - qu’une méthodologie de type agile sera préférable, ou même obligatoire !
Ce qui pose de nombreux problèmes assez insolubles. Notamment, demander un contrat au forfait représente une démission du client final quand à la gestion de son projet. La théorie est que le client, en fournissant l’ensemble des spécifications nécessaires en début de projet, obtiendra en résultat un logiciel satisfaisant ces besoins. Autrement dit, tout ce qui l’intéresse est le coût du projet, et non le pilotage du projet. hors ce projet peut être crucial pour son business, et il est donc primordial qu’il soit en mesure de le contrôler et de le diriger selon ses besoins.
Le forfait est donc le contraire total de l’agilité, où l’accent est mis sur la valeur et l’adéquation de ce qui est « délivré ». L’agilité demande un investissement important du client, ce qui semble normal vu qu’il s’agit de son projet et de son business !
L’agillité est vraiment un mot à la mode ; j’ai récemment vu un projet au forfait comportant une méthodologie agile (pseudo Scrum) et délivrant des diagrammes de Gantt sous MSProject !!!! Aucun commentaire sur la capacité de réaction au changement de cette équipe…
On vit dans un monde merveilleux.