eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

Métier

Tous les billets ayant un rapport avec mon métier : le logiciel. o Technologies o Infos professionnelles o etc.

Fil des billets - Fil des commentaires

dimanche 11 mars 2012

Start and stop mongodb with Junit in java

package fr.lemerdy.eric;

import com.mongodb.*;
import org.fest.util.Files;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.UnknownHostException;
import java.util.ArrayList;
import java.util.List;

import static junit.framework.Assert.assertNotNull;
import static junit.framework.Assert.fail;
import static org.fest.assertions.Assertions.assertThat;

public class AbstractMongoTest {

    @BeforeClass
    public static void start_database_as_a_forked_process() throws IOException, InterruptedException {
        File dbPath = ensureDbPathDoesNotExits();
        assertThat(dbPath.mkdir()).isTrue();
        List lines = startMongoDBAsADaemon();
        assertThat(lines.get(0)).startsWith("forked process: ");
        assertThat(lines.get(1)).startsWith("all output going to: ").endsWith("logpath");
        assertThat(lines).hasSize(2);
        assertThatConnectionToMongodbIsPossible();
    }

    private static List startMongoDBAsADaemon() throws IOException, InterruptedException {
        ProcessBuilder processBuilder = new ProcessBuilder("../../mongodb-osx-x86_64-2.0.3/bin/mongod", "--dbpath",
                "dbpath", "--fork", "--logpath", "logpath");
        processBuilder.directory(new File("target"));
        processBuilder.redirectErrorStream(true);
        Process pwd = processBuilder.start();
        BufferedReader outputReader = new BufferedReader(new InputStreamReader(pwd.getInputStream()));
        String output;
        List lines = new ArrayList();
        while ((output = outputReader.readLine()) != null) {
            lines.add(output.toString());
        }
        pwd.waitFor();
        assertThat(pwd.exitValue()).isEqualTo(0);
        return lines;
    }

    private static void assertThatConnectionToMongodbIsPossible() throws InterruptedException, UnknownHostException {
        Mongo server = null;
        try {
            while (server == null) {
                Thread.sleep(250);
                server = new MongoURI("mongodb://127.0.0.1").connect();
            }
            assertThat(server.getDatabaseNames()).hasSize(1);
        } finally {
            server.close();
        }
    }

    private static File ensureDbPathDoesNotExits() throws IOException {
        File dbPath = new File("target/dbpath");
        if (dbPath.exists()) {
            Files.delete(dbPath);
            assertThat(dbPath.exists()).isFalse();
        }
        return dbPath;
    }

    @Test
    public void should_connect_to_the_test_database() throws Exception {
        Mongo mongo = new Mongo();
        try {
            DB test = mongo.getDB("test");
            assertThat(test.getCollectionNames()).isNotNull();
        } finally {
            mongo.close();
        }
    }

    @AfterClass
    public static void shutdown_mongodb() throws IOException {
        Mongo mongo = new Mongo();
        try {
            DB db = mongo.getDB("admin");
            CommandResult shutdownResult = db.command(new BasicDBObject("shutdown", 1));
            shutdownResult.throwOnError();
            fail("Expecting to loose mongodb connection on shutdown.");
        } catch (Throwable e) {
            assertThat(e.getMessage()).isEqualTo("can't call something : /127.0.0.1:27017/admin");
        } finally {
            mongo.close();
            ensureDbPathDoesNotExits();
        }
    }
}
Edit:
A github project has been created
Thanks to Florent Ramière, an elegant solution based on Rules has been provided. I am grateful to him.

samedi 25 février 2012

How to execute a command when a file change ?

Use incron ! It is similar to cron that triggers commands based on time. Incontab triggers commands based on file system changes.

1. Install incron

sudo apt-get install incron

2. List your incron jobs

incrontab -l
returns :
user 'ericlemerdy' is not allowed to use incron

3. Authorize your user to have incron job

sudo whoami >> /etc/incron.allow

4. List your incron jobs

incrontab -l returns :
no table for ericlemerdy

5. Add a job to your incron

incron -e
Your text editor is now opened, ready to add your first job.

5. Help on job syntax

man 5 incron
The syntax is :
<path> <mask> <command>
Incron will examine your <path> based on the <mask> that can be IN_ACCESS or IN_MODIFY for exemple and then executes your <command>>.
Exemple :
/home/ericlemerdy/tutorial.txt IN_MODIFY pandoc -s --webtex -i -t slidy $@ -o /home/ericlemerdy/tutorial.html
This jobs inspects the file /home/ericlemerdy/tutorial.txt. Every time the file is modified (according to the IN_MODIFY mask), a documentation is generated through a command.
Note the use of $@ in the command. This is replaced with the examined path.

6. Tracking job execution

You can follow the incron activity through the syslog :
tail -f /var/log/syslog
You should get :
Feb 25 17:29:36 harukiya incrond[21714]: starting service (version 0.5.9, built on May 10 2010 14:59:40)
Feb 25 17:29:36 harukiya incrond[21715]: loading system tables
Feb 25 17:29:36 harukiya incrond[21715]: loading user tables
Feb 25 17:29:36 harukiya incrond[21715]: ready to process filesystem events
Feb 25 17:59:49 harukiya incrond[21715]: table for user ericlemerdy created, loading
Feb 25 18:01:23 harukiya incrond[21715]: (ericlemerdy) CMD (pandoc -s --webtex -i -t slidy /home/ericlemerdy/tutorial.txt -o /home/ericlemerdy/tutorial.html)

Conclusion

Incron can be very helpful to execute your tests when your code change or generate a webpage when the sources are changing.

mardi 6 septembre 2011

Learned today: do not blame non-agile developpers

Do not blame non-agile developers

When welcoming a new team member, you could have this feeling that this guy could address a load of reproaches to your team previous work. For example, on the non-perfecteness of the development environment documentation. In this case, I am not pleased because 1) I do not believe in documentation that never get updated (I believe this is ood) and 2) I get my work in too much high sake to start hearing that it could possibly sucks (this is a personal defect). I prefer pairing with this new team member to install its development environment. This is has benefits in several ways:
  • to you, old developer on this project for too long, it reminds how painful it is to start with your poorly documented project where nothing is standard. You could be find yourself justifying your configuration crap and "we live with that until today so, you should be doing the same, new guy."
  • this is the moment to get a brand new feedback on your configuration, your project sources organisation, your development platform. Listen carefully. Seems like this session can be more instructive for you than for him.
  • this is the moment where you meet someone, the moment where you do not know him enough to begin joking with him or hating him. This key moment to get acquainted before entering into a real pair programming session should be the moment to evaluate the developer’s culture compliance with your team's. From this first statement, you can guide further actions.
I have been find to be not tolerant enough with the team member today. I should be more comprehensive in respect with all the above benefits. From my experience, do not give the new team member a chance to not adhere to the team rules, especially when you use some XP practices. Enrol it to your very next task by pair programming. He will learn the project very fast and you will learn very fast from his experience.

mardi 9 août 2011

Learned today: when a story is not a story, partially done work

When a story is not a story.

Have you ever had troubles expressing a user-story when you are in a technical team which has technical tasks to perform ? We experienced today this kind of troubles during the planning meeting. My agilist way of thinking make me think: if it is not a user-story, then it does not exists and this is waste to implement. But things are not that simple. We have to be careful. There is maybe a slight tendancy to consider summer as the time to do fun technical things without adding business-value...

What to do with partially done work lasting from iteration n-1 ?

The perfect situation is that the product owner reset this story as the top priority for this next story. But, this time, things have changed and despite he wants it done for the release, he no longer want it done for the iteration. We choose to finish tasks in progress and let the story in the newly prioritized board.

vendredi 5 août 2011

Learned today: premature end of file, one card per day, never forget your basics, oral vs written discussion

Premature end of file

Consuming a heavy resource on an external web server, we used an xml pull parser to integrate this data in our system. After some time spent reading this resource, the program stopped with a "java.io.IOException: Premature EOF". I presumed this was because the remote server does not supports chunked http requests which the implementation of the parser use... But I was not able to reproduced with a proper integration test. So, in order to get a solution "faster", I unilaterally decided to complexify my production code with a previous step to copy of the resource to a local file (with java.io.File.createTempFile) with the help of Guava and then consume this local resource. The problem is not reproduced.
A kind of "not achieved" feeling stayed with me after this poorly resolution of a problem... The problem is that I do not really figure out why this exception happened. If the problem shows up again, I will be stuck.

One card per day

Jean-Laurent distributed some cards card in the team to spread values and practices. Today, I suggest my colleagues to pick a card randomly and use it appropriately within the day work. The picked cards:

  1. Comment with care: used once in a discussion to comment with care someone else's proposition. That was a clever and funny outside-of-code use of the card.
  2. Dare to say no: used to say no to A LOT of unrelated work discussions within the day. Fun. The card has also been transfered to someone who clearly wanted to say no at one point and did not find the appropriate consensual words to say. The card kindly helped him.
  3. Your solution should not be more complicated than the problem (the card that I pick): invoked a lot today since we tried to design a solution to achieve a kind of genericity/anticipation of a feature.

Never forget your agile basics

Do not anticipate the next hypothetical feature. This is pure waste. We are using agile techniques such as TDD and continuous re-factoring in order to make our product the least resistant to changes, whatever the nature of the change that could possibly land on the backlog. So, we should spend more time implementing the simplest solution to the current problem than consuming precious time to discuss hypothetical features.
There are still different degrees of commitment to this principle toward the team members. Is this a problem ? Our project (short) history proved quite well that the respect of this agile rule brings small but constant successes.

Oral vs written discussion

We had a lot of informal discussions today. Oral is always fuzzy and shows poorly structured thoughts but very creative and inspirational. When someone has written some ideas on the board, we suddenly had a pragmatic basis to discuss upon. That brings the debate further.
This remind me of the "set-based" problem resolution method versus the "point-based". Point-based is such like a conversation where the solution emerges after a laborious peoples expressions of ideas. Whereas set-based is more like: "express the constraints clearly and we will find later the obvious solution that satisfies it". In oral form, I am obsessed on not loosing this factual state of mind when I listen to other people but when its my turn to speak, I always reproduce the same infinite loop of my thoughts...

jeudi 22 juillet 2010

HTML5 with Peter Lubbers 3/3

Ce billet est le troisième et dernier sur le compte rendu de la soirée avec Peter Lubbers hébergée par Zenika le 7 juin dernier. Reprenons où nous avions laissé ce compte-rendu.

WebSocket

C'est une nouveauté "invisible" qui concerne plutôt la communication sous jacente. Http, le protocole de communication qui sert les documents HTML n'a pas été conçu pour ce que l'on appelle aujourd'hui le "Real-time" web qui nécessiterait plutôt un protocole connecté de type Socket. Avec Http, on ne peut qu'envoyer une requête à laquelle un serveur répond. Pour obtenir une dynamique côté client, on serait tenté de faire des rafraichissements de page. Le problème, c'est qu'à chaque fois, on obtient des tas d'informations dans les entêtes. Cela génère du trafic inutile et augmente la latence. Des stratégies ont tout de même été mises en place pour lutter contre cet aspect asynchrone du protocole http. Avec Ajax par exemple, on peut faire du "polling". C'est une stratégie qui consiste à interroger régulièrement le serveur pour mettre à jour le client. Même si le service est rendu, Peter nous a fait remarquer ce c'est très inefficace et cela ne tiens pas la charge. Merci à Peter pour nous faire partager un exemple réel sur le site facebook. La fonctionnalité de chat de facebook qui utilise le polling ajax nécessite 10.000 serveurs pour tenir la charge de ses utilisateurs.
WebSocket est donc la spécification qui se propose de résoudre ce problème. La société Kaazing dans laquelle Peter travaille a participé activement à cette spécification. Il nous en a résumé les caractéristiques:
  • Full-Duplex Socket (communication montante et descendante simultanée) dans le navigateur. Vous ouvrez une connexion persistante entre le navigateur et le serveur web.
  • L'initialisation de la connexion ("hand-shaking") se fait toujours à partir du protocole http. Ça reste donc compatible avec une infrastructure web existante, on ajoute juste un client qui sait parler le WebSocket et un serveur également compatible.
  • Permet des requêtes sur l'autres serveurs que celui qui a transmis l'application web originale. C'était une "lacune" des requêtes Ajax.
  • La réduction de la quantité d'information non nécessaire transmises dans les entêtes peut aller jusqu'à 1/1000 dans les tests effectués par Kaazing.
    Les usages de ce protocole pourraient être par exemple l'édition simultanée à un google doc par plusieurs personnes. Ce serait irréaliste avec http si chaque caractère tapé émettait sa propre requête http.
  • WebSocket permet aussi de faire passer des protocoles de plus haut niveau comme XMPP par exemple pour la messagerie instantanée ou encore d'autres protocoles client-serveur qui seraient utilisés dans le SI.
Peter nous montre ensuite dans le domaine du jeu vidéo, l'exemple du portage de Quake2 qui utilise WebGL et WebSocket. Chez Kaazing, ils ont écrit un client VNC dans le navigateur basé sur WebSocket ce qui évite d'installer un client VNC pour accéder à un partage d'écran.
Pour une démo, rendez-vous sur la page d'accueil de kaazing ou sur leur site de poker en ligne basé sur HTML5.

Geolocation

Cette API permet à une application web de connaître la localisation géographique de l'utilisateur. L'utilisateur peut tout de même refuser de transmettre sa position auquel cas, l'application devra échouer en gérant agréablement ce cas de figure (par exemple en affichant un message). L'application peut donc avoir accès aux coordonnées géographiques de l'utilisateur (et la précision) quel que soit le moyen que le navigateur emploie pour trouver cette position:
  • dispositif de positionnement par satellite type GPS,
  • triangularisation GSM lorsqu'on est en mobilité,
  • ou géo-codage de l'adresse postale du point d'accès à internet déduit à partir de l'IP de l'utilisateur.
On peut aussi avoir accès à d'autres méta données telles que l'altitude ou la vitesse, toujours dépendantes du matériel dont dispose l'utilisateur pour accéder à l'application web.
Chacun de ces dispositifs a des avantages et des inconvénients. Par exemple, le GPS est la solution de positionnement la plus précise mais elle consomme beaucoup d'énergie, ce qui peut se révéler critique pour suivre un trajet pendant longtemps. Le wifi quant à lui est la plupart du temps payent. La résolution à partir de l'IP est rapide mais n'est pas très précise.

Web Storage

Pensez à cette API comme un moyen pour une page de stocker des données directement. Dans la version actuelle de HTML, on dispose déjà des cookies pour faire se genre d'opérations. Peter nous fait la citation de quelqu'un qui aurait qualifié l'API Web Storage de "Cookies dopés" (mieux en anglais "Cookies on Steroïds").
Cette fois, un volume beaucoup plus important peut être stoké dans le "Local Storage" (stockage local) et le Session Storage (stockage dans la session) ou la base de données. Cela fait trois type de stockage. Les deux premiers sont des stockages associatifs de type "clé-valeurs". Le troisième est une base de données WebSQL. La force de cette API est donc de pouvoir alléger les échanges réseaux puisque l'on crée un stockage local de données qui n'ont pas à transiter sur le réseau. De plus, les données sont persistées entre deux démarrages du navigateur ce qui permet de prolonger l'état de la navigation de l'utilisateur.
Le problème avec les cookies, ce sont leur taille fixe. Par exemple, sur un site de voyage qui stocke la commande de l'utilisateur dans un cookie, on peut arriver aux limites de stockage et celà entraîne une rupture de navigation et une perte de données pour le visiteur. Avec cette API, on a beaucoup plus de place. Peter avance aussi l'argument de la sous-exploitation de nos machines. Autant que les sites web puissent profiter de l'espace disque de plus en plus grand sur nos ordinateurs pour ne pas se contenter de simples terminaux web. Dans les implémentations actuelles de l'API, on a accès à une vue qui permet de visualiser ce que les sites web ont stockés dans l'espace du navigateur.
A propos du WebSQL, la spécification est au point mort car il n'y a pas vraiment d'intéret en fait pour spécifier encore un autre dialecte SQL...

Autres API de communication

  • Server-sent events: Cela standardise l'envoi de données en broadcast du serveur au client. C'est le mode 'Comet' qui permet de recevoir des données sans en faire la requête.
  • Cross-document messaging: Cela permet de faire des échanges dans une page (du document principal vers un iframe par exemple) en permettant le partage de contexte javascript.
  • XHR `Level 2` : C'est la nouvelle version de l'objet javascript qui apporte le support d'Ajax. Il est possible maintenant de faire des requêtes à d'autres serveurs qui sont hébergés sur d'autres domaines que celui qui héberge votre script.
Selon Peter, ces APIs sont intéressantes. Il les met tout de même en perspective par rapport à WebSocket qu'il considère comme plus puissant puisqu'il permet de mettre en oeuvre une connection TCP entre un client et un serveur.

Autres nouveautés

  • Offline web applications : C'est plus que le cache actuel qu'on peut trouver dans les navigateur. Avec cette fonction, on spécifie au navigateur qu'une sous-partie du site doit être accessible offline. On décrit cela à travers un fichier cache-manifest.xml à la racine du site. On peut aussi savoir si le navigateur est on-line ou off-line, ce qui permet de réagir applicativement.
  • Drag-and-Drop,
  • History API : apporte un contrôle plus fin sur les bouton précédents et suivants pour historiser la navigation de l'utilisateur.
  • Content editable

Vous pouvez trouver sur ce billet la présentation PDF de Peter Lubbers. Merci à lui pour cette présentation très complète sur l'état de HTML5.

lundi 14 juin 2010

HTML5 with Peter Lubbers 2/3

Compte rendu HTML 5

HTML 5 Forms

Les WebForms 2.0 ou HTML 5 Forms, fournissent des fonctionnalités de formulaire natifs. En guise d'illustration, Peter nous montre le volume de code non négligeable nécessaire à la validation d'une simple adresse e-mail. Ces efforts répétés par les développeurs de sites ou dans les frameworks ou les toolkits se trouvent implémentés dans le browser grâce à HTML 5. Il y a aussi de nouveaux composants comme DatePicker, ColorPicker, valideurs d'adresses web, sliders, etc. D'après le présentateur, on a pas à se soucier de la compatibilité descendante de ce genre de composant car en cas de non compatibilité, les composants sont rendus avec du texte. Il y a aussi la possibilité de rendre un attribut obligatoire. Dans ce cas, la validation côté client est assurée par le navigateur avant même l'envoi au serveur. Ce fut l'occasion de voir le code associé et de constater que les guillemets deviennent accessoires en HTML5:

<input id=name name=name type=text required>
C'est en cela qu'HTML5 est un contrepied au XHTML qui prône lui une conformité rigoureuse à la syntaxe XML.
Pour résumer, cette spécification ajoute à HTML des fonctionnalités natives au navigateur en un nombre réduit d'éléments déclaratifs au lieu de devoir recoder cette partie là à chaque fois côté client.

Des tas d'API

HTML 5 innove en apportant des standards d'API tels que : Canvas, SVG, Audio & Video, Web Socket, Web Workers, Geolocation, Web Storage, etc.

Canvas & SVG

Ce sont des API de dessin pour le navigateur. Par exemple, on peut dessiner une ligne dans la page grâce à ces API. Conformément à l'esprit de HTML5, ces zones graphiques sont accessibles à Javascript et au styles CSS à l'inverse d'une zone remplie par un plug-in. Alors pourquoi deux API pour dessiner ? L'un génère des graphismes "bitmap" (canvas) tandis que l'autre génère des images vectorielles (SVG). Dans un canvas, on est au "bas niveau", on a accès aux dessins de pixels, etc. Alors que SVG nous propose une syntaxe XML, un modèle objet pour décrire des formes, des traits, etc. Cela permet par exemple de concevoir des interfaces fines en réagissant à un clic sur une certaine zone par exemple. Peter tranche en disant qu'il n'y a pas vraiment de bonne ou mauvaise API à ce niveau. Il y a juste des usages différents.

Canvas

Lorsqu'une zone canvas est dessinée, elle l'est à une certaine résolution, elle serait pixelisée si on zoomait dessus. Il existe des canvas 2D et des canvas 3D. Le présentateur a partagé avec nous le site canvasdemo.com qui est une collection de liens vers des créations canvas, une bonne façon de découvrir des exemples de ce qu'on peut faire avec cette API. Je suis assez d'accord avec Peter, "that's cool stuff".
A noter que les canvas 3D (Web GL) ne sont supportés que par quelques navigateurs dans leur version de développement (les canvas 3D que vous pouvez voir sont de la 3D calculée et projetée sur un canvas 3D, ndla)
Comment ça marche ? Vous définissez un élément canvas et un dans un javascript, vous accéder au contexte de ce canvas. Ensuite, vous empilez des instructions de dessin dans ce contexte (line, gradient, rectangle, etc.) et à la manière d'une transaction en base de données, vous "commitez" ces instructions ce qui a pour effet de les dessiner dans la zone. Vous avez aussi accès aux évènement sur les mouvements de la souris.

SVG

En SVG, tout ce qui est dessiné peut passer à une échelle différente, ce n'est pas dépendant de la résolution. C'est assez adapté pour représenter des graphiques de données par exemple ou une carte avec des informations cartographiques additionnelles sur laquelle on pourrait zoomer précisément. A noter que IE 9 supporterait bien SVG et ajouterait une accélération matérielle prometteuse.

Audio and video

Il y a pour ça deux nouveaux éléments audio et video. Ils permettent d'inclure nativement des sons et des vidéos dans vos documents web. L'idée originale de HTML5 ne spécifiait à l'origine qu'un seul codec mais ce n'était pas une offre très diversifiée. Il y a donc aujourd'hui deux conteneurs multimedia compatibles : OGG (libre) et H.264 (non libre). Par exemple, Youtube et Dailymotion proposent déjà du contenu video en HTML5. Cela permet en particulier de se passer de Adobe Flash pour héberger des vidéos ou de la musique. Pour illustrer son propos, Peter nous montre qu'il est possible d'avoir accès aussi au contenu : une vidéo se joue sur une page et un script prend une capture toute les 5 secondes. On peut aussi zoomer lorsque la souris entre sur la vidéo.

Je continuerai dans la dernière partie du compte rendu sur Web Sockets, Web Workers, Geolocation et Web Storage.

mardi 8 juin 2010

HTML5 with Peter Lubbers 1/3

HTMLV

Voici un compte-rendu de la présentation HTML5 de Peter Lubbers de la société Kaazing. Il était invité par Zenika à présenter les grands principes de HTML5.
Dans toute l'assistance de 30 personnes environ, seulement une personne a déclaré être en train d'utiliser réellement HTML5 pour un projet ! Au moins, nous n'étions pas là bas pour rien ce soir.

La société Kaazing dont il est employé est spécialisée dans les web sockets pour l'entreprise, c'est-à-dire fournir des serveurs et des logiciels adaptés pour la diffusion d'informations en masse à travers internet. Peter est quant à lui le co-fondateur du San Francisco HTML5 User Group depuis quelques mois dont le nombre d'adhérents à atteint 500 personnes, ce qui montre l'intérêt pour le sujet en Californie.

HTML5 a au moins un premier mérite, c'est de mettre d'accord des sociétés qui ne le sont jamais ! Apple, Google, Microsoft ou la Fondation Mozilla, toutes ces sociétés soutiennent activement la spécification HTML5 !

Histoire de HTML et origine de HTML5

Un rapide point de vue historique pour commencer:

1981
T. Berners Lee pose les
bases du format HTML

>
'90
HTML 1.0
 

>
1995
HTML 2.0
 

>
1997
HTML 3.2 & HTML 4.0
 

>
1999
HTML 4.1
 

>
2001
XHTML
 

>
2004
WHATWG propose HTML5,
c'est l'apogée du web 2.0

>
2009
HTML5 approprié par le W3C
 

>
2012
la Release Candidate de
HTML5 sera prête

>
2022
Version finale de la spécification
 

A propos de la date de 2022, ne vous inquiétez pas, 80 à 90% de la spécification est dorénavant déjà implémentée dans les navigateurs !
La principale différence entre HTML5 et une simple nouvelle version de HTML est le contrôle très poussé que la page web peut obtenir avec le navigateur à travers CSS et surtout Javascript. HTML5 ajoute de nombreuses API qui permettent de pousser l'application web encore plus loin.
Derrière cette spécification, on trouve le groupe de travail à l'origine de la spécification, le WHATWG, puis le W3C et l'IETF (plus centré protocole) ont rejoint le mouvement. Le WHATWG s'est constitué avec des membres qui développent des navigateurs pour contrer la direction trop puriste prise à l'époque par le W3C.
HTML5 est en fait l'union de plusieurs sous spécifications: WebSocket, Geolocation, Local Storage, etc. Peter nous a expliqué que ça permettait aux participants d'être spécialisés par sujet.

Les principes de conception

Voilà les principes qui guident la spécification:

#1 Compatibilité

Les auteurs sont restés pragmatiques sur le sujet. Ils ont souhaité garder un maximum de compatibilité avec la masse gigantesque de pages internet existantes.

#2 Utilité

Sécurisé, utilisable, erreurs non bloquantes (un fragment de la page ne devrait pas briser toute la page), séparation entre le contenu et la mise en forme

#3 Interopérabilité

Un effort de simplification se cache derrière ce concept. Par exemple, on va chercher à proposer des implémentations natives dans les navigateurs plutôt que de proposer des plugins pour chaque besoin. La plupart des API se veulent simples à utiliser. Peter nous a montré ici la simplification à l'oeuvre dans les entêtes des pages HTML5 :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />

Mais cette simplicité ne veut pas dire ambiguïté, on se souvient tous de l'époque où chaque navigateur interprétait différemment le contenu et la mise en forme. Un effort dans HTML5 est porté sur la non ambiguïté des spécifications.

#4 Accès universel

Cette idée recouvre l'internationalisation et l'accessibilité en fournissant des règles sur les contenus pour les rendre interprétables par d'autres dispositifs qu'un navigateur web sur un écran.

"Plug-in Free"

Peter a voulu insister sur ce point (on voit bien ici que ce sont des éditeurs de navigateurs qui sont majoritairement derrière la spécification, ndla). Par exemple, si on a une page dans lequel un contenu est rendu par un plug-in, le reste de la page ne va pas pouvoir interagir avec ce contenu "piégé" dans le contexte d'exécution du plug-in. Pour illustrer son propos, il nous a propose une démo avec Adobe Flash, il est donc passé au slide suivant et là, paf, écran bleu Windows sur le projecteur - on y a cru 3 secondes ;-) En tous cas, le propos est illustré. Les navigateurs veulent contrôler leur stabilité et ne plus dépendre de plug-in hors de leur contrôle.

Anatomie de HTML5

De nouveau tags apparaissent (section, header, aside, etc.), d'autres sont dépréciés. C'est le cas par exemple de l'élément basefont qui est clairement de la mise en forme. HTML5 ne fait que déprécier car il doit se conformer au principe #1 de compatibilité, vous suivez toujours ?
Comme Peter, je relaye le lien vers la très utile "HTML5 Cheat Sheet" pour visualiser les nouveaux et les anciens éléments.
Pour HTML5, une page dessert un objectif différent d'une autre et n'a donc pas a adopté le même squelette. Peter nous a tout de même montré un exemple classique comparé à sa version HTML4. Voilà un exemple équivalent:

Pour faire du HTML5 dès maintenant, alors que la spécification n'est pas finalisée, il existe des astuces. Par exemple, pour s'adresser en CSS3 à certains navigateurs en particulier, on utilise des attributs spécialisés (-moz... ou -webkit...) en fonction des fonctionnalités implémentées. L'autre astuce pour IE est d'inclure le script html5.js fournit par un projet google code. Ce script transforme un document HTML5 en fonction de l'implémentation actuelle du navigateur.

Je poursuivrai ce compte-rendu avec les innovations des Forms et un aperçu des principales nouvelles APIs qui ont été présentées par Peter.

lundi 23 février 2009

Nabaztag plugin improved

This is a list of improvements of the lastest version:

  • Use a checkbox for the "Report On Success" parameter.
  • Hide non mandatory parameters in an "Advanced..." section.
    hudson-1.5-advanced.png
  • Text-To-Speech messages supports "${projectName}" and "${buildNumber}" special syntax to be more expressive (instead previously of adding project name and build number automatically at the end of the TTS).
    hudson-1.5-variables.png
  • Add help for each parameter.
    hudson-1.5-help.png

The version is available here: nabaztag-1.5.hpi.
The wiki page also contains a new section to request changes. A Jira for such a little plug-in seems oversized, no ?

dimanche 9 novembre 2008

Back from GWT and Restlet @ParisJUG - 3/3

Last graphic report back from ParisJUG
See the full story in one image

- page 1 de 5