Blog d'un manchot ...

Accueil | Site Principal

Jeudi, octobre 22 2009

L'Agile Tour 2009 à Grenoble

J'ai assisté ce mardi 20 octobre à l'Agile Tour de Grenoble. Cette fois-ci nous avons été nombreux (au moins 300 personnes) et le programme était intéressant. J'ai dû donc prioriser les sujets.

L'Agile Tour a commencé avec une présentation de Henrik Kniberg sur ce qu'est l'agilité. Bien que connaissant le sujet, j'ai trouvé rafraîchissant cette piqure de rappel. Je suis assez reconnaissant à Henrik pour le livre qu'il a écrit "Scrum And XP From The Trenches" et qui m'a permis de commencer à mettre en place SCRUM sur mon projet actuel, il y a maintenant 2 ans.

Elle a fini, en fin de journée, sur une note de Jérome Barrand sur l'agilité dans d'autres disciplines autre que l'informatique. Nous y avons appris en l'occurrence que l'agilité n'est pas nouveau et qu'elle est même assez ancienne dans certaines disciplines. Il semblerait aussi qu'elle commence à s'introduire dans des domaines aussi surprenant que la finance ! Malgré tout, si l'agilité prend bien dans les entreprises de petites et moyennes tailles, elle a vraiment des difficultés à pénétrer les grandes sociétés qui sont encore régies par une forte hiérarchisation et une parcellisation du travail et des responsabilités.

Entre les deux, j'ai assisté à 4 séances parmi les 24 proposées (6 présentations sont proposées au choix par tranche d'heure) :

  • Retour d'expérience : Le Lean et la création de sites Internet animé par un canadien dont j'ai oublié le nom mais qui n'était pas la personne prévue (elle a eu un accident de moto !),
  • Comment concilier Agilité et projet au forfait animé par Jean-François Jagozinski,
  • La gestion des défauts et besoins non fonctionnels avec SCRUM animé conjointement par Luc Jeanniard et Éric Mignot, deux SCRUM Masters,
  • et un Coding-Dojo : Kata sur le pilotage par les tests d'acceptances (ATDD) animés en binôme par Rémy Sanlaville et Emmanuel Hugonnet.

Le retour d'expérience sur l'application du Lean était intéressant. Une Web Agency s'est créée vers 2000-2001 et n'a cessé de croître jusqu'à connaitre depuis 2007 ce que l'on appelle une crise de croissance. Celle-ci s'est manifestée par un accroissement de son stock de logiciels en développement ou à développer, dérivant dangereusement dans le temps ses livraisons et aboutissant à un mécontentement croissant des clients. Un de ses clients, qui se trouve être une société de conseils sur le Lean, lui a proposé alors ses services. Avec l'aide de la région, 60% a été pris en charge dans le cadre de Agilité PME. La Web Agency a embauché un Lean Manager qui, avec l'aide de la société en conseils, a commencé à prendre la mesure des problèmes d'organisation. A partir de là il a mis en place, via les managers et employés même de la société, une nouvelle organisation basée sur le Lean. Cette dernière a donné apparemment de très bons résultats mais il reste encore pas mal de choses à faire.

La présentation suivante a été aussi un retour d'expérience sur l'application de l'agilité dans le cadre d'un projet en forfait. Plus exactement deux retours d'expériences : un échec et un succès. Le projet qui a été un échec l'était dû au fait que le contour du projet a été imposé dès le début : le périmètre fonctionnel, le temps, et le budget, ne laissant ainsi aucune latitude à la société de services (en générale, les sociétés de services s'en tire avec le système d'avenants). Le projet réussi a tiré les leçons du premier. Le client et la SSII se sont accordés sur un temps de calibrage de trois sprints avant de s'engager sur le périmètre fonctionnel, le délai et le budget. Ce temps de calibrage a permis de mettre en lumière que le projet était impossible à tenir dans le périmètre, le délai et le budget demandé au début. Après négociations, il s'avéra que le client donna la priorité au périmètre fonctionnel, ce qui permit alors de jouer sur le délai et indirectement aussi sur le budget pour remplir les exigences. Finalement, le projet se termina avec le contentement de tout le monde : le client et la société de services y ont trouvé chacun leur compte, ils ont été gagnant-gagnant. Ce que j'en ai tiré de cette présentation est qu'aujourd'hui l'application d'une approche agile dans le cadre d'un projet en forfait dépend beaucoup du contexte et plus particulièrement du client.

La troisième présentation a été en fait un jeu assez animé de questions-réponses. Au travers d'un jeu de transparents, des problèmes que l'on rencontre souvent dans SCRUM sont posés. Il y avait entre autre comment prendre en compte les bogues ou comment considérer la mise en place de l'architecture du projet au premier Sprint. Luc présentait le problème avec des exemples de cas et Éric apportait des réponses. Chacun dans l'assistance pouvait poser aussi ses questions. Évidemment, les réponses dépendent du contexte même du projet mais il était intéressant de voir comment Éric ramenait les choses sur un autre plan afin d'appréhender le problème différemment, dans l'idée de prendre du recul et donc apprécier la solution qui des fois s'avéra évidente. Pour ce faire, il s'appuyait sur les 4 piliers de l'agilité :

  • un processus empirique,
  • un carnet priorisé,
  • des livraisons incrémentales,
  • une équipe autogérée.

et c'est sur l'une ou plusieurs d'entre elles qu'il ramenait le problème. Il était aussi amusant d'entendre comment le principe d'offshoring, tel qu'appliqué dans nos entreprises, a été démonté en quelques mots selon la perspective d'une approche agile.

Le Kata, quant à lui, a été l'occasion, au travers du défit du jeu du pendu, de montrer l'usage de Cuke4Duke (une version de Cubumber pour Java) dans l'écriture de spécifications exécutables. Tout le long de la séance, le pilote et co-pilote ont montré comment pouvait se dérouler un développement selon ATDD et comment on passait de l'ATDD (avec Cuke4Duke) à TDD (avec JUnit), et vice-versa. L'ATDD est encore jeune et les outils, s'ils deviennent maturent, ne semblent pas encore être en capacité à répondre à tous les projets. En effet, le défit portait sur un programme en mode console texte, or des projets reposent sur l'écriture d'applications avec une interface Web et dans ceux-ci il est encore difficile voir impossible de mettre en œuvre ces outils ; il faut en effet tester l'application fonctionnellement via son IHM. (J'en ai déjà fait l'amer expérience avec une application GWT.)

Mercredi, septembre 2 2009

Les 40 ans d'Unix

Unix a fêté ses 40 ans ce mois d'août. Dans le monde de l'informatique, c'est un fait exceptionnel et remarquable. Mais, au regard des qualités et défauts d'Unix, ce n'est finalement pas aussi surprenant. De plus, il a su profité aussi d'un désintérêt temporaire du marketing, sans quoi, sa progression et son impact dans le monde d'aujourd'hui n'aura probablement pas été aussi profond.

Lire la suite...

L'agilité à la plage !

J'ai passé mes vacances cet Eté à la plage du côté de Royan auprès de mes enfants et de ma femme. Baignade et châteaux de sable étaient au rendez-vous. Et c'est justement lors de la construction d'un château de sable avec ma fille ainée que s'est passé un événement fort intéressant si on le met en perspective des méthodes agiles vs. en waterfall.

Lire la suite...

Mercredi, juin 17 2009

BDD cherche sa maman ...

Cela fait depuis quelque temps maintenant que j’assiste aux différentes séances du coding dojo du CARA , le Club Agile de Rhônes-Alpes. Sur 3 séances s’est étalé un atelier sur BDD (Behavior Driven Development).

Lire la suite...

Jeudi, mars 12 2009

Les logiciels libres et les logiciels propriétaires

Les logiciels libres et les logiciels propriétaires sont par essence bien différents. Chacun s’appuie sur une approche et sur des buts bien différents.

Malheureusement, de nombreuses personnes les voient avec le même regard, ce qui n’est pas à l’avantage des logiciels libres.

Lire la suite...

Mercredi, novembre 26 2008

Les bases de données relationnelles

Un excellent article de Martin Fowler, un des grands maîtres à penser dans le domaine du Génie Logiciel, explique le pourquoi de l’échec des systèmes de bases de données orientées objets et de la prédominance actuelle des bases de données relationnelles. Il explique aussi pourquoi cette position de force devrait maintenant évoluer.

Lire la suite...

Mardi, octobre 28 2008

Grails la patte : les services métiers

Ce billet, qui présente le framework Grails, est le quatrième d’une série sur celui-ci. Une illustration du framework au travers d’un exemple simple est présentée. Après avoir définis, dans le billet précédent, nos objets du domaine au travers de l’approche TDD, présentons maintenant les services qui vont fournir des opérations métiers aux IHM ou aux API. Ces opérations métiers, dans le cadre de notre application, seront relativement simple puisqu’il s’agit d’une interface de type CRUD (Create Request Update Delete) sur les questionnaires.

Lire la suite...

Mardi, octobre 21 2008

Grails la patte : les objets du domaine

Ce billet, qui présente le framework Grails, est le troisième d'une série sur celui-ci. Une illustration du framework au travers d'un exemple simple est présentée. Ce billet présente la définition des objets du domaine et comment peuvent être déclarés les invariants métiers. Ils seront présentés selon l'approche TDD (Test Driven Development).

Lire la suite...

Vendredi, octobre 17 2008

Grails la patte : un projet Grails

Ce billet, qui présente le framework Grails, est le second d'une série sur celui-ci. Une illustration du framework au travers d'un exemple simple est présentée. Ce billet présente succinctement la structure d'un projet Grails.

Lire la suite...

Samedi, octobre 4 2008

Grails la patte

Ce billet, qui présente le framework Grails, est le premier d'une série sur celui-ci. Dans les billets qui suivront, une illustration d'une application Web développée avec Grails sera présentée.

Lire la suite...

Vendredi, septembre 26 2008

Le polymorphisme en POO

Un excellent billet a été écrit sur Object Mentor par Dean Wampler au sujet du Principe de Substitution de Liskov avec les langages dits Duke-Typed.

D'abord, il reprend le principe tel qu'écrit par Barbara Liskov :

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

Ici, ce qui doit être relevé est qu'une fonction qui prend en paramètre un objet de type T peut accepter un objet de type S si et seulement si S est un sous-type de T ; sachant qu'un type est la définition syntaxique et sémantique de l'interface d'un objet (ce dernier aspect n'étant quasiment pas pas supportée dans la majorité des langages orientés objets). Or, le terme behavior utilisé dans le principe a toute son importance. Il signifie tout simplement, dans le typage du premier ordre, que le comportement exécuté sera celui du type ... T ; raison pour laquelle S doit être un sous-type de T puisqu'alors ce comportement nécessite d'être hérité. Donc, dans le typage du premier ordre, le polymorphisme n'est pas possible tel quel. Or ce dernier est une propriété essentielle dans la POO. Afin de palier à cela, les langages orienté-objet qui supportent seulement le typage du premier ordre (Java, C#, ...) ont introduits le mécanisme d'attachement (binding) des fonctions (ou plus exactement des messages) définis dans une interface à leur implémentation (les méthodes d'implémentation de la réponse au message) dans un objet. Ceci permet de pouvoir redéfinir l'implémentation de la fonction dans le sous-type S, implémentation qui sera alors appelée en lieu et place de celle définit dans le type père. Or ceci ne brise pas pour autant le principe de Liskov tel que définit par Barbara Liskov si le comportement raffiné satisfait celui hérité. Par contre, il introduit une faiblesse dans le typage.

Le billet de Dean Wampler présente ensuite l'inapplication du principe de Liskov, tel qu'il est écrit, aux langages dits Duke-Typed. Ce terme barbare désigne en fait la nature même du polymorphisme en POO :

S'il se déplace et caquette comme un canard, alors ce doit être un canard.

Autrement dit, comme le souligne si bien Dean, un objet peut se substituer à un autre objet si ce dernier ce comporte tout simplement comme l'autre ... et ceci sans parler de sous-typage. Sa conclusion, après des illustrations de ceci en Ruby et en Scala, est de redéfinir le Principe de Substitution de Liskov en terme non de sous-typage mais en terme de substituabilité (oui encore un barbarisme), autrement dit en terme de polymorphisme tel que définit en POO. Ce que semble ignorer Dean ici est qu'il existe une théorie qui définit précisément le typage sous-jacent à la POO et duquel découle le polymorphisme, la Théorie F-Bound de Cook sur le typage du second ordre. Dans sa théorie, W. Cook définit le typage du second ordre comme une famille polymorphique de types à point fixe. (C'est en quelque sorte une classe de types d'objets pour lequel il existe un et un seul type qui implémente exactement l'interface décrit par la classe). Pour plus de détails sur sa théorie, vous pouvez consulter ses travaux (“Inheritance is not subtyping”, Proc. 17th ACM Symp. Principles of Prog. Lang., (ACM Sigplan, 1990),“F-bounded polymorphism for object-oriented programming”, Proc. 4th Int. Conf. Func. Prog. Lang. and Arch. (Imperial College, London, 1989)).

En conclusion, la POO relève du typage du second ordre dans lequel le polymorphisme est décrit par la sous-classification (cf. Théorie F-Bound) et non plus par le sous-typage tel que pensé par Barbara Liskov ; un objet o1 peut donc se substituer à un objet o2 dès qu'il satisfait le comportement attendu ; autrement dit si son type fait parti de la même famille polymorphique de type que le type de l'objet o1).

Samedi, septembre 20 2008

PHP et le Web

On m'a souvent demandé pourquoi j'écrivais mes sites Web au contenu dynamique avec PHP alors qu'il existe à côté des langages plus ... professionnels. Il est vrai que PHP est mal conçu, tant est si bien qu'il peut être un sujet d'étude sur les erreurs à éviter dans la conception d'un langage. Nous pouvons citer comme exemple le manque de cohérence dans l'interface des fonctions de ses librairies ou encore le contexte global des variables. (Néanmoins, au fur et à mesure de ses évolutions, des défauts sont corrigés ; merci Zend.) Seulement, voilà, PHP fut longtemps le seul langage multi-plate-forme orienté contenu Web et qui soit simple d'utilisation. Ce qui explique aussi pourquoi il est mis à disposition chez tous les hébergeurs de site Web. De plus, malgré ces défauts, il permet à tout un chacun de construire et de prototyper rapidement un site Web.

PHP, par sa nature même, est encore aujourd'hui un langage parfait pour la conception d'applications Web orientées contenu. En effet, parce que l'accent est mis sur la représentation Web de ressources modifiables, les scripts PHP génèrent du contenu Web en mixant à la fois des éléments HTML et des instructions PHP; ils permettent alors de rendre ce contenu dynamique. Autrement dit il suffit d'écrire un modèle de page Web en PHP pour représenter les ressources disponibles (billets d'un blog, photo d'un album, etc.) et non plus une page Web par ressource ; lorsqu'une ressource est modifiée, ajoutée ou supprimée, le script PHP prend en compte dynamiquement le changement.

A côté de ceci, s'il existe des frameworks comme Symphony (qui voguent dans la tendance Ruby On Rails), PHP n'en est pas pour autant la panacée dans la réalisation d'application Web orienté processus, c'est-à-dire des applications dont l'interface Web n'est plus là pour représenter seulement des ressources mais pour interagir avant tout avec l'application (des processus métier sont exécutés à chaque interaction). En effet, dans ce genre d'application, l'accent n'est plus mis sur la représentation Web de ressources, mais sur le domaine métier. Or, à chaque invocation, le script PHP est à nouveau exécuté par le serveur Web, que ce soit dans un processus ou dans un thread, ce qui nécessite alors de charger à nouveau l'ensemble des objets ou des processus impliqués. Afin de rendre disponible les objets et leur modification entre chaque exécution de scripts, les bases de données sont utilisées. Elles servent donc aussi bien de couche de persistance que de couche métier. Autant dire qu'il n'y a pas de couche de domaine (et je ne considère pas les caches comme une couche de domaine). Dans ce cadre ci, des frameworks comme Ruby On Rails ou Grails sont beaucoup plus pertinents. (Je ne parlerais pas du serveur d'application Zend Platform.)

Donc, lorsque j'utilise du PHP, c'est pour concevoir rapidement des sites Web au contenu dynamique. Je n'ai pas trouvé mieux. Par exemple, lorsque j'ai écrit mon album Web de photos (et de vidéo), Wagen, je me suis tourné vers le PHP. Toutefois, je prend un certain nombre de mesures dans la conception afin d'éviter de me retrouver avec un plat de spaghetti difficilement maintenable :

  • le site est découpé en différents scripts, chacun représentant un modèle de génération de pages Web (et non un ensemble de pages différentes) ;
  • un script chargé de générer une page Web ne contient que les instructions PHP dédiées à cette tâche et rien d'autre ;
  • les scripts chargés de générer les pages Web incluent un ou plusieurs fichiers PHP dans lesquels sont définis, sous forme de composants logiciels, les ressources à afficher ;
  • les composants logiciels représentant les ressources encapsulent l'accès à celles-ci, que ces dernières soient sur disque ou en base de données, et proposent des fonctions de traitement de ces dernières.

Samedi, septembre 13 2008

Dotclear 2.0 !

Et voilà chers lecteurs et lectrices ! Mon blog tourne dorénavant sous Dotclear 2.0.

Pour réaliser le portage, il a fallu d'abord porter le thème de Dotclear 1.2 vers Dotclear 2.0. Finalement, ceci s'est plutôt bien passé. En effet, les thèmes sous Dotclear 2.0 sont essentiellement définis par une feuille de style et il m'a fallu juste adapter celle-ci aux goûts et aux couleurs du nouveau moteur de blog. Sous ce dernier, s'il garde la majeur partie des définitions des classes et des identifiants HTML de la version précédente, certaines ont eu des modifications sensibles ; par exemple l'identifiant categories sous Dotclear 1.2 est devenu une classe sous Dotclear 2.0. Sans compter que j'ai dû aussi prendre en compte les nouvelles classes HTML comme tags par exemple ;-)

Ensuite, il a été nécessaire de tester l'exportation et l'importation des données de Dotclear 1.2 vers Dotclear 2.0. Ceci s'est déroulé sans encombres. J'ai juste remanié les liens vers les images. J'ai aussi ajouté des extensions comme dayMode pour afficher un calendrier, remanié l'agencement des composants dans mon blog (à ce titre, Dotclear 2.0 est un délice), et me suis fait un peu la main sur les nouvelles fonctionnalités du moteur de blog ; la seule chose dont je n'ai pas encore compris l'utilité est son concept de pages.

Et pour finir, il a fallu transporter le tout sur le serveur et tester que tout fonctionnait correctement. C'est là que je me suis aperçu que le moteur de MySQL configuré par Free est MyISAM et non InnoDB. Or, Dotclear 2.0 demande un moteur transactionnel. La solution a été d'activer le support de PostgreSQL. A part ce petit dérangement, tout finalement s'est déroulé sans encombres.

A bientôt donc pour de nouveaux billets ...

Jeudi, septembre 11 2008

Une petite vidéo sympa

Hé non, ce n'est pas pour informer de la migration de ce blog vers dotclear 2.0. Je prévoie celle-ci courant samedi.

Non, ce billet est juste pour signaler la présence d'une petite vidéo clin-oeil sur les méthodes de développement agile et disponible sur le blog de ehsavoie.

La vidéo est par ici

Samedi, septembre 6 2008

Fin des vacances

Après quelques semaines d'absence, voici un nouveau billet pour vous faire part de quelques nouvelles. Parti en vacances en Charente-Maritime, la fin de ces dernières a été quelque peu mouvementée. En effet, au large, je me suis coupé le pieds avec un rocher qui se dressait assez haut sous l'eau juste au-dessous de moi ! Et ceci sans parler d'une petite gastro-enterite à la reprise du travail.

Mais, à côté de ceci, une bonne nouvelle est arrivée au mois d'août : la sortie de dotclear 2.0 en version stable (suivie de peu par un correctif, la version 2.0.1) ! Aussi j'ai décidé de migrer mon blog de dotclear 1.2 vers la version 2.0. Il m'a fallu pour cela quelques jours de travail pour porter le thème de mon blogue vers la nouvelle version et appréhender les particularités de celle-ci.

Aussi tenez vous prêt à mettre à jour vos liens car il est fort possible que ceux-ci soient cassés dès la migration effective.

A bientôt ...

Mercredi, juillet 9 2008

Le pattern Store

Dans les applications avec un modèle de domaine partagé, les patterns Factory et Repository sont fréquemment utilisés. La Factory permet de créer des objets métiers en encapsulant le mécanisme de création (et donc aussi la classe d'implémentation réelle de l'objet). Le Repository permet de récupérer des objets métiers existant en offrant aux clients une interface conforme à leur langage (ubiquitous language). Les services et les objets du domaine doivent souvent faire référence à l'un des deux ou aux deux dans la réalisation de leurs tâches.

A côté de ceci, selon le choix de conception du domaine, la persistance des objets du domaine peut-être assurée de façon différente :

  • par appel à la méthode de persistance des objets concernés (qui délègue l'appel au repository sous-jacent),
  • par appel à la méthode put du repository concerné.

De même, la récupération d'objets du domaine existant peut aussi être assurée de différente manière :

  • par appel à des méthodes de classe des objets du domaine (selon le vieux principe qui mieux que la classe connaît ses instances),
  • par appel direct aux méthodes du repository concerné.

Et ces choix, valides, impactent les clients de ces objets, et ceci d'autant plus au cours de vie de l'application où le refactoring est commun et où on peut passer d'un choix à un autre selon le contexte changeant.

C'est à partir de ces constats, et en vue de l'application du DDD (Domain Driven Design), que j'introduis le pattern Store (un dérivé du pattern Facade en fait). Ce pattern consiste à définir une interface qui joue le rôle de magasin d'objets du domaine avec lequel les clients pourront faire leur marché :

  • si l'objet n'existe pas, le magasin demande alors à l'usine de le fabriquer puis le met dans son dépôt (le repository),
  • si l'objet existe, le magasin le récupère du dépôt et le met à disposition aux clients.

Bien sûr, comme nous ne sommes pas dans un monde matériel mais virtuel, l'objet qu'obtient le client est toujours stocké dans le dépôt et peut aussi être utilisé par un autre client ;-)

Voici un petit exemple en Java avec JPA et Spring 2.5. Soit des billets d'un blog:

@Entity
public class Article {
  @Id
  @GeneratedValue(strategy=GenerationType.SEQUENCE)
  private Long id;
  @Column(nullable = false)
  private String title;
  @Column(nullable = false)
  private String author;
  private String subject;
  @Column(nullable = false)
  @Temporal(TemporalType.TIMESTAMP)
  private Date date;
  @Column(nullable = false)
  @Lob
  private String text;
  @OneToMany(cascade = CascadeType.ALL)
  private List<Comment> comments;
  
  protected Article(String title, String author, String subject) {
    ...
  }
  
  ...
}

Soit le dépôt à partir duquel sont récupérés les billets existants :

@Repository
public class ArticleRepository {
  
  @PersistenceContext
  private EntityManager entityManager;

  public void put(Article article) {
    entityManager.persist(article);
  }
  
  public void remove(Article article) {
    entityManager.remove(article);
  }
  
  @SuppressWarnings("unchecked")
  public List<Article> getByDate(Date date) {
    ...
  }
  
  public Article getById(long id) {
   return entityManager.find(Article.class, id);
  }
}

L'usine de nouveaux billets :

@Component
public class ArticleFactory {
   public Article makeArticle(String title, String author, String subject) {
      ...
   }

   ...
}

Et enfin le magasin de billets :

@Component
public class ArticleStore {

   @Resource
   ArticleRepository articleRepository;
   @Resource
   ArticleFactory articleFactory;

   public Article getNewArticle(String title, String author, String subject) {
      Article newArticle = articleFactory.makeArticle(title, author, subject);
      articleRepository.put(newArticle);
      return newArticle;
   }

   public Article getArticleById(long id) {
      return articleRepository.getById(id);
   }

   public List<Article> getArticlesByDate(Date date) {
     return articleRepository.getByDate(date);
   }

   public void removeArticles(List<Article> articles) {
      ...
   }
}

Un service de gestion des billets du blog :

@Service
public class ArticleService {
   @Autowired
   ArticleStore myStore;

   ...
}

Etc.

Les Repository et les Factory restent alors dans la couche du domaine et ne sont plus visibles de l'extérieur. Le magasin devient alors l'objet de communication entre la couche service et celle du domaine avec ceci de particulier qu'il reste un objet du domaine (il parle tout de même le langage du domaine). Il cache les mécanismes de gestion des objets du domaine.

Lundi, juillet 7 2008

Newspeak, un nouveau langage

Décidément, ce début du 21ème siècle aura été riche en langage de programmation. Et je ne parle pas de ces langages commerciaux destinés à la masse comme C# ou Java en son temps. Je parle de ces langages de haut niveau et dignes d'intérêt comme Self ou Scala. Et c'est sur un de ces langages que Gilad Bracha travaille en ce moment à Cadence.

Lire la suite...

Jeudi, juillet 3 2008

XMonad rulez !

Depuis que je suis sous XMonad, j'apprends peu à peu à le connaître, à prendre mes repères et surtout à mettre à jour ma configuration.

Les changements sont :

  • adaptation du mode d'arrangement de fenêtres tall : deux fenêtre peuvent occuper le cadre maître (le premier, le principal),
  • nouveau mode d'arrangement, MosaicAlt qui permet d'arranger les fenêtres en mozaïc,
  • chaque espace de travail a maintenant son propre nom,
  • l'affichage du nom de l'espace de travail courant lors du passage de l'un vers l'autre avec une couleur de fond bleu,
  • le passage à l'espace de travail <n> par la touche Meta-F<n> (Meta-F1 pour aller à l'espace 1),
  • le support de dzen (barre de statut) dans XMonad, ce qui permet d'avoir des informations comme l'espace de travail courant, le mode d'arrangement des fenêtres actif et le la fenêtre qui a le focus. J'en ai profité pour restructurer mon script d'affichage d'information système en plusieurs que j'appelle directement de ma configuration XMonad.

Voici une capture d'écran de mon nouveau espace de travail :

screenshot-xmonad3.jpg

Franchement, depuis que je travaille sous XMonad, ce n'est que du bonheur. Je ne travaille quasiment plus qu'avec le clavier et je trouve plus aisé de passer d'un mode d'arrangement à un autre, d'utiliser les raccourcis clavier pour redimmensionner à la volée certaines fenêtres (j'en ai rarement besoin) et d'avoir toujours sous les yeux les fenêtres non recouvertes et occupant de façon optimale l'espace allouée.

Jeudi, juin 26 2008

XMonad, parce que mon portable le vaut bien

Un environnement graphique, dont l'interaction se fait essentiellement avec la souris, n'est pas des plus facile à utiliser avec un PC portable. Ceci est particulièrement vrai en déplacement où le PC tourne sur la batterie et où il est alors nécessaire d'économiser les ressources afin de garder une plus grande autonomie de fonctionnement. Exit donc les environnements de bureaux de type GNOME ou KDE qui sont lourds aussi bien en consommation ressource qu'en utilisation. Exit aussi la souris connectée sur port USB et qui pompe insidieusement de l'énergie. Il ne reste alors plus que le touchpad pour jouer avec son environnement allégé comme Fluxbox, Fvwm ou autre, personnalisé aux petits oignons pour le rendre agréable aussi bien à l'œil qu'à l'utilisation (j'utilise quotidiennement Fvwm au travers de Fvwm-Crystal) ; et ça peut devenir une véritable galère.

Il existe pourtant une grande variété d'environnements graphiques dans le monde des Unix libres (GNU/Linux, FreeBSD, NetBSD, ...) et parmi elles en ressort une catégorie qui semble bien être adaptée à l'usage quotidien d'un PC portable : les gestionnaires de fenêtres en tuiles (tiling window managers en anglais). Le principe de ces environnements est de gérer l'emplacement des fenêtres des applications graphiques de façon à se qu'elles ne se recouvrent pas et de s'appuyer sur une interaction avec le clavier, rendant ainsi optionnel l'usage d'une souris. De plus, ceux-ci-ci sont assez économes en ressources. Ils sont donc bien adaptés aux PC portables. Pour éviter aux fenêtres de se recouvrir, ils reposent sur le principe du tiling : le ou les espaces de travail (workspace en anglais) sont subdivisés en cadres ou vues et chaque cadre accueille une fenêtre d'une application. A chaque fenêtre qui s'ouvre, un nouveau cadre est créé sans recouvrir les précédents ; un ou plusieurs cadres existants sont donc redimmensionnés à la volée. Les cadres sont ajustés les uns par rapport aux autres comme les tuiles d'une toiture d'une maison. De plus, la dimension des cadres peut être ajustée au clavier.

Il existe plusieurs gestionnaires de fenêtre de cette catégorie : wmii, dwm, ion (ion3), awesome, XMonad, ... Je me suis intéressé à Xmonad. Ce qui m'a plus dans cet environnement, comparé aux autres, est qu'il est écrit en Haskell, un langage fonctionnel pur de haut niveau. Cette caractéristique, qui ne semble que technique, a pourtant tout un intérêt: il permet à XMonad d'être facilement maintenable et évolutif, mais surtout de permette l'écriture rapide de fonctionnalités annexes et riches. Ceci me garantit donc d'une part une évolution croissante de l'environnement, des correctifs de bogues rapides, mais surtout de la présence nombreuse d'extensions qui permet de l'enrichir en fonctionnalités. Et je ne me suis pas trompé à voir effectivement le nombre d'extensions proposées. De plus, XMonad a tellement bien réussi à attirer un certain engouement que la communauté des développeurs GNOME s'y sont intéressés ! A côté de ceci, deux caractéristiques m'ont aussi attirées :

  • sa gestion des fenêtres flottantes de type splash screen ou boites de dialogues. On peut même définir que les fenêtres de telle ou telle application sont à gérer de façon classique, c'est-à-dire en flottant ; c'est ainsi que par défaut est géré The Gimp.
  • son support de différentes politiques d'ajustement des cadres, autre que le tiling, tel que celui par onglets. Chaque espace de travail ou bureau peut avoir sa propre politique d'ajustement et on peut passer l'une à l'autre via le clavier (en général par la combinaison de touches Meta-espace).

Pour adapter XMonad à ses goûts il suffit juste de récupérer son fichier de configuration par défaut, xmonad.hs, (ou celui d'une autre personne sur le Web) et le mettre dans le répertoire caché .xmonad/ à la racine de son compte, puis de l'éditer. Le fichier de configuration est écrit en Haskell et il est donc nécessaire de connaître des rudiments de ce langage ; ceci peut-être un frein pour les non-informaticiens. Une simple combinaison de touches Meta-q au clavier charge à chaud le fichier de configuration. De plus, il existe aussi des outils annexes qui permettent d'obtenir d'autres fonctionnalités : dzen2 pour afficher sur tous les espaces de travail une barre d'état, dmenu pour afficher dynamiquement un menu shell interactif, trayer pour afficher sur tous les espaces de travail une barre de notification, conky pour présenter différentes informations sur les bureaux, etc. Ma configuration actuelle par rapport à celle par défaut (attention, l'archive contient des fichiers cachés) :

  • la touche Meta est la touche Windows (autant qu'elle serve à quelque chose et ça évite d'entrer en conflit avec les touches méta (Ctrl ou Alt) utilisées en général par les applications),
  • support de quatre politiques d'ajustement des cadres : les onglets, le tiling horizontale, le tiling vertical, la pile. La politique d'ajustement par défaut est celle par onglets,
  • le passage d'un workspace à l'autre via les flèches gauche et droite ou via Meta-a et Meta-z ou encore via la souris avec Meta-la roulette,
  • le réglage du son via les flèches haut et bas,
  • le lancement d'Apwal avec la combinaison Meta-clic bouton milieu de la souris.

Voici deux captures d'écran de XMonad en action sur un de mes PC portables. Le premier avec The Gimp en flottant :

screenshot-xmonad1.jpg

Le second avec Mutt et Firefox en tuile horizontale :

screenshot-xmonad2.jpg

Maintenant, il reste encore des choses pour que XMonad soit encore mieux. Parmi ces choses, il y a la possibilité de passer d'un espace de travail à un autre par leur nom via le clavier ou encore le support d'un pager autre que par dzen. Mais après tout, il n'en est qu'à la version 0.7, laissons lui donc le temps encore de progresser d'ici la version 1.0.

Mardi, juin 24 2008

Le Domain Driven Design

Depuis quelque temps, le Domain Driven Design (ou DDD) est sous les feux des projecteurs et il est maintenant facile de trouver sur le Web des articles sur le sujet. Toutefois, dans le milieu des SI (Systèmes d'Information, au sens général) il est aussi décrié. La particularité du DDD, né en 2003 du livre éponyme d'Eric Evans, est de remettre au devant de la scène le modèle du domaine ; l'élaboration d'un système doit être centré sur la conception du modèle du domaine (ou sur sa sélection s'il existe déjà). Et c'est à partir du modèle du domaine que devraient être réalisées la couche de persistance et la couche service. Nous le constatons ici, il va à l'encontre de l'approche architecturale coutumière qui prévaut dans les SI ou dans les applications Web. En effet, les architectures habituelles s'appuient sur une vision très procédurale des processus métiers, approche qui conduit souvent à créer une couche service obèse de logiques métiers et des objets du domaine anémiques. (Ceci est bien sûr une dérive dans la conception traditionnelle d'un SI principalement dû à l'inertie d'une culture plus ancienne dans laquelle les bases de données jouent un rôle primordiale.) Dans le DDD, les entités manipulées dans le système sont identifiées au travers de la conception du modèle et la logique métier est embarquée dans les entités concernées. Ainsi, pour faire simple, au lieu d'avoir d'un côté un objet BankAccount et de l'autre un service BankAccountService ou FundingService avec des opérations withdraw et deposit, nous avons des objets BankAccount avec ces opérations. A la lumière de ceci, nous remarquons alors que le DDD remet la programmation objet, trop souvent boudée et mal comprise, au coeur de la conception. C'est la raison pour laquelle il est aussi décrié, semblant se heurter à la même incompréhension que celle qui a prévalue à la POO (Programmation Orienté Objet).

La figure ci-dessous présente le schéma d'une architecture classique d'un SI :

archi-classique.jpg

Dans cette architecture, la couche du domaine est transversale aux couches de service et de persistance. La couche de service utilise la couche de persistance pour retrouver, créer et mettre à jour les objets du domaine. La couche de persistance gère l'accès au sources de données (en général des bases de données) au travers des DAO (Data Access Object) qui proposent une interface de type CRUD (Create Request Update Delete). Par cette interface, en quelque part, la couche service se voit donc aussi attribuer les opérations de gestions des objets métiers vis à vis des sources de données. Les objets métier ne servent donc souvent plus que de simples enregistrements, vulgaires représentation des véritables objets du modèle domaine. La couche de présentation utilise les opérations de la couche de service pour accomplir les fonctionnalités demandées par les utilisateurs au travers des interfaces Homme-Machine (en générale des interfaces Web, mais pas uniquement). Les informations qui transitent entre la couche de présentation et celle de service sont des DTO (Data Transfer Object), de simples objets qui véhiculent des parties des états des objets du domaine qu'encapsule la couche service. Nous remarquons donc que par cette représentation, la couche du domaine n'est que transversale et que l'attention est surtout porté sur les couches de service et de persistance.

Voici une figure qui illustre une architecture selon le DDD :

archi-DDD.jpg

Dans cette architecture, cette fois la couche du domaine dans laquelle est implémentée le modèle du domaine est le point important. La logique métier est au niveau des objets du domaine concernés et la couche de service utilise ceux-ci pour accomplir les opérations applicatives. La couche de service n'a plus de relation avec la couche de persistance et par ce fait n'est plus en charge de gérer le cycle de vie des objets du domaine vis-à-vis des sources de données. Étant donné que la persistance est une caractéristique importante des objets du domaine dans le SI (ils existent au-delà des contextes d'exécution des applications qui les manipulent), ce sont les objets du domaine eux-même qui gèrent celle-ci en utilisant des objets de type Repository qui encapsulent l'usage réel de la couche de persistance ; ce qui explique la relation entre la couche du domaine et la couche de persistance. La couche de présentation communique comme précédemment avec la couche de service au travers de DTO. Néanmoins, à la différence de l'approche classique, les DTO sont réalisés à partir des objets du domaine et dans certaines approches IHM (Interface Homme-Machine), ils peuvent même contenir leur propre représentation que la couche de présentation peut affiner avant assemblage.

Bien que DDD soit encore vue avec une certaine appréhension, nous pouvons remarquer toutefois son succès au travers des frameworks comme Rails qui reposent sur son approche. En effet, l'accent est mis dans ces frameworks sur le modèle du domaine et c'est à partir de celui-ci qu'est généré à la fois la persistance et la présentation (le scaffolding) ! Du côté de la plate-forme Java, mis à part Grails qui est le pendant de Rails mais pour Java, il existe aujourd'hui les outils nécessaires qui permettent d'appliquer le DDD :

  • la génération des DTO à partir des objets du domaine avec des outils comme Dozer,
  • la gestion de la persistance avec JPA (Java Persistence API),
  • la gestion du cycle de vie des objets métiers et des dépendances souples entre couches avec Spring,
  • etc.

Un article de Srini Penchikala, Domain Driven Design and Development In Practice, en présente quelques aspects. Bref, il existe maintenant les outils suffisants pour appliquer sans souffrir le DDD (ce qui n'était pas le cas il y a quelques années), alors, profitez en : mangez en, c'est bon pour la santé de vos systèmes ;-)

- page 1 de 2