Nov 30

Scala User Group : API Akka

Ce lundi 29/11 à eu lieu, chez Xebia, le Scala User Group. La session de cette soirée a été l’occasion d’avoir un aperçu de l’API Akka, destinée à mettre en place un système de calcul distribué.

Celui-ci se base sur des acteurs (« Actors »), qui sont des composants distribués sur une ou plusieurs machines, et qui prennent en charge des calculs à partir d’une file de message propre. Un orchestrateur va prendre l’ensemble des données à traiter, les subdiviser en paquets, mettre ces paquets dans des messages et les répartir suivant les différents acteurs. De cette manière, chaque acteur peut traiter son contenu indépendamment des autres, ce qui permet de pouvoir lancer les calculs en parallèle (sur différents coeurs de processeur, ou différentes machines, etc…). Ce modèle, assez classique pour du calcul réparti, est enrichi dans Akka d’une gestion de fail-over et d’une gestion de transaction propres et simples.

Voilà un exemple de code (tiré de la homepage de Akka):

// Code du serveur
class HelloWorldActor extends Actor {
  //Définition de l'action à la réception d'un message
  def receive = {
    case msg => self reply (msg + " World")
  }
}
// Démarrage du serveur et inscription
RemoteNode.start("localhost", 9999).register(
  "hello-service", actorOf[HelloWorldActor])

// Code du client
val actor = RemoteClient.actorFor("hello-service", "localhost", 9999)
//Envoi d'un message sur l'acteur et attente du résultat
val result = actor !! "Hello"
Nov 09

Présentation de l'API HTML5 AppCache

Le 08/11/2010 à eu lieu chez Zenika une présentation par Peter Lubbers de la spécification HTML5 AppCache.

AppCache permet de mettre en cache, au niveau du navigateur web, une partie du site web que l’utilisateur est en train de visiter. Ce cache permet de pouvoir continuer à consulter le site web même si l’utilisateur perd sa connexion.

Le cas d’utilisation le plus classique est lorsque l’utilisateur prend l’avion : avec une partie du site mis en cache, l’utilisateur peut continuer à consulter les pages web même si il n’y a pas accéder avant d’embarquer.

La spécification de ce système est disponible sur le WHATWG et sur le W3C.

Fonctionnement

Pour peupler le cache à partir d’une page (par exemple « index.html »), il suffit d’ajouter l’attribut manifest à la balise html de cette page.

<html manifest="site.manifest">
<!-- Code de la page -->
</html>

Le contenu de l’attribut est le nom du fichier qui va contenir la description du contenu du cache. Par convention, son extension est « .manifest » et son MIME-type doit être « text/cache-manifest ».

Ce fichier est un fichier textuel, case-sensitive, qui contient trois sections : CACHE, NETWORK et FALLBACK.

CACHE va contenir la liste des ressources à télécharger et à placer dans le cache ; NETWORK liste les ressources qu’il faut forcément aller rechercher sur le réseau (et donc ne pas contenir en cache) ; Enfin FALLBACK permet de définir les pages qui seront affichées lorsqu’une ressource ne sera pas disponible (pas dans le cache et pas de connexion pour aller la récupérer).

CACHE MANIFEST
#Pages dans le cache. Si cette section est au début,
#on peut omettre le header "CACHE:"
CACHE:
index.html
next.html
fallback.html

#Pages à automatiquement rechercher sur le réseau
NETWORK:
versatile.html

#Toute page tombant en erreur va être remplacer par fallback.html
FALLBACK:
/ fallback.html

Si on accède, lorsqu’on est connecté, à la page index.html, le navigateur va enregistrer en cache les pages index.html, next.html et fallback.html. Si le réseau est coupé, et que l’utilisateur veut accéder à la page next.html, il pourra y accéder. Si par contre, il tente d’accéder à la page versatile.html, comme cette page est cherchée sur le réseau et que celui-ci est coupé, le navigateur va fournir la page fallback.html à la place.

Utilisation dans Javascript

Coté Javascript, on peut également exploiter l’AppCache, d’une part pour savoir si il est disponible (avec le booléen window.applicationCache), mais également pour faire un rafraîchissement de celui-ci (integer window.applicationCache.status pour connaître l’état du cache, méthode window.applicationCache.update() pour mettre à jour le cache et Window.applicationCache.swapCache() pour utiliser la nouvelle version mise à jour).

Il est également possible de gérer les évènements liés au cache.

Demo

Un exemple de site utilisant le AppCache, créé par Peter Lubbers, peut être télécharger ici.

Nov 09

Eclipse Day Paris 2010

Ce vendredi 05/11/2010 à eu lieu, au Pavillon Royal (Bois de Boulogne), l’Eclipse Day Paris, qui est une journée de conférences sur l’IDE Eclipse, ses nouveautés et avancées, ainsi que l’écosystème des applications qui gravitent autour.

Les conférences auquelles j’ai assisté sont les suivantes :

  • Discours d’ouverture du CEO de la Fondation Eclipse, Mike MilinKovich;
  • Retours d’expériences par des consultants de Zenika et ProxiAD sur la mise en place des technologies Eclipse chez des clients;
  • Les nouveautés et prévisions pour le système de persistence EclipseLink, par Doug Clarke;
  • Utilisation de Git avec Eclipse, par Chris Aniszczyk;
  • Les projets Virgo et Gemini, par Steve Powell;
  • Solution de génération de rapport OpenDocument à partir de multiples sources (Sodius);
  • Sonatype : Maven, m2eclipse, Nexus & Hudson;
  • Framework Eclipse Scout.

Les choses que j’ai à retenir de ces présentations :

– L’écosystème d’Eclipse est constitué de milliers de projets, dans des domaines variés, et beaucoup de ces projets profiteraient de nouveaux développeurs / commiters.

– Deux API, Eclipse RCP et Eclipse RAP, sont deux API graphiques (le premier se basant sur SWT, le second sur un affichage web standard HTML/Javascript), se basant sur (quasiment) les même principes d’affichage, rendant le développement des plugins assez similaire.

– Montée en force du système de versioning GIT, et intégration de celui-ci dans Eclipse à travers EGIT et JGIT.

– L’architecture d’Eclipse évolue avec le système Virgo et les composants Gemini.

– Sonatype a annoncé le sortie imminente du plugin Eclipse pour Maven M2Eclipse en version 1.0.

Nov 08

Lego Mindstorm animé par du Java

J’ai eu l’occasion récente d’acquérir le fabuleux set de Lego « Mindstorm NXT 2 ».

Pour ceux qui ne le savent pas, il s’agit d’un coffret de Lego Technic contenant un bloc programmable, des moteurs (trois éléments qui peuvent tourner, afin d’animer roues, bras et autres), et des capteurs (deux de toucher, un de distance et un de lumière).

Rien de mieux pour réveiller en moi les joies de la construction improbable et de pouvoir leur donner vie !

Les avantages du Lego Mindstorms NXT sont nombreux : c’est un kit d’apprentissage à la robotique à moindre frais (~300€), il est fait en Lego (donc très simple pour l’assemblage, et la nostalgie empêche de baisser les bras trop vite), mais surtout, on peut faire du développement en Java !

Pour cela, il existe une API très bien faite, dénommé « LeJOS« , et qui fonctione de la manière suivante :

  • En premier lieu, on flashe le bloc programmable avec les outils fournis. Cela passe par un outil très simple qui prend toute l’opération en charge.
  • Ensuite, il suffit de développer une application avec les JAR fournis avec l’API (qui regroupe une JVM simplifiée et l’API d’accès aux moteurs et capteurs).
  • Il n’y a plus qu’à compiler avec les outils donnés et à faire le push du programme sur le bloc programmable.

L’API est très bien documentée, ainsi que tous les outils de compilation / publication.

Pour vous montrer la simplicité du développement, voilà un exemple de code avec la machine qui va avec :

La machine :

Deux moteurs sont utilisés pour l’avancement de la voiture, et le troisième est utilisé pour la direction des roues avant. Le capteur d’ultrason est mis à l’avant de la voiture pour éviter les colisions sur les murs et les objets.

Pour activer cette petite voiture, un programme simple va la faire avancer, sauf si il y a un objet devant, auquel cas elle va reculer et changer de direction.

Le code pour cela est le suivant :

import lejos.nxt.Button;
import lejos.nxt.Motor;
import lejos.nxt.MotorPort;
import lejos.nxt.SensorPort;
import lejos.nxt.UltrasonicSensor;

/** Programme pour la voiture Lego. */
public class Car {

  //Les deux moteurs pour les roues arrières.
  private static Motor back1 = new Motor(MotorPort.A);
  private static Motor back2 = new Motor(MotorPort.B);

  //Le moteur utilisé pour la direction avant.
  private static Motor direction = new Motor(MotorPort.C);

  //Le capteur d'ultrason.
  private static UltrasonicSensor sonic = new UltrasonicSensor(SensorPort.S1);

  //La boucle principale.
  public static void main(String[] args) throws Exception {

    //Boucle jusqu'à ce qu'on presse le bouton d'échappement.
    while (!Button.ESCAPE.isPressed()) {
      //Récupère la distance en CM.
      int distance = sonic.getDistance();
      if (distance <10) {
        changeDirection();
      } else {
        moveForward();
      }
    }
  }

  //Fait tourner les roues avant et recule.
  private static void changeDirection() {
    direction.rotate(35, false);
    moveBackward();
    direction.rotate(-35, false);
  }

  //Avance.
  private static void moveForward() {
    back1.rotate(360, true);
    back2.rotate(360, true);
  }

  //Recule.
  private static void moveBackward() {
    back1.rotate(-360, true);
    back2.rotate(-360, true);
  }
}