Dec 24

Dans un précédent billet j’ai parlé des vertues du typage et quand sans lui, il fallait avoir un bon nombre de tests pour éviter les regressions. Cette batterie de tests n’est —selon moi— pas suffisante, voires impossible a mettre en place suivant les situations. Dans le cas ou vous écrivez un framework par exemple, vous ne pouvez imposer des tests aux utilisateurs de votre framework afin de compenser tout changement d’API.

Les langages dynamiques sont par définition des languages avec un typage faible…voire inexistant. J’ai lu dans un billet sur RubyCLR, que l’intéret de tout typage tombait de par l’usage de Test Driven Development. C’est tout simplement faux et que c’est l’utilsation de TTD et langugae dynamique donnent cette impression.

Une grande partie des nouvelles technologies suivent le même schéma d’adoption. Dans un premier temps, la nouvelle technologie est adoptée par énormément d’utilisateur et une certaine euphorie accompagne cette adoption. A ce stade, les sociétés commence à se pencher dessus sans l’adopter vraiment ou alors de manière expérimentale. On voir alors tout un tas de détracteurs apparaitres qui par la meme occasion mettent en exèrgue certains défauts (faux mythe) et la technologie est alors quelque peu délaissée. Si elle ne disparait pas, elle va survivre et progressivement etre adoptée par plus en plus de personnes … y compris les sociétés.

La survie de la technologie dépend uniquement de sa vraie valeur intrinsèque. Je pense que les languages dynamiques sont au premier stade: beaucoup d’”early adopters” avec peu de vrai applications/framework l’utilsations ou alors en tant qu’outil. Ou voit alors quelquesfan annoncer l’inutilité du typage. C’est abhérent car le typage n’est pas uniquement un artéfact due à la faible abstaraction des premiers langagues: le typage défini un modèle, et le modèle est au centre de tout a partir du moment ou il faut développer un système/application complexe qui est appeller à évoluer. C’est à ce point fondamental que certaines méthodologies commencent par le modèle avant le développement lui même (MDA).

Je pense donc que pour l’instant les languages dynamiques offrent une rapidité de dévelopment inégalée bien utile aucx development d’outils internes, de test ou de prototypage…mais n’enlève rien au besoin fondamental de typage/contrat des entitées utilisées dans une application ou un système complexe afin qu’il puisse évoluer.

Dec 17

Voici un article très intéressant sur les anti-pattern en SOA.

Dec 12

C’est certainement parce que je suis encore newby en PHP et wordpress et que je ne suis pas un super fan du Javascript…mais y a quand même des trucs qui m’échappent. J’ai installé WordPress (techno de ce blog) qui est très réputé en tant qu’application de Content Management, et j’ai voulu installer un plug-in pour mes exemples de code. Malheureusement, j’avais déjà mis aussi un autre plug-in pour l’intégration avec Copermine…il semble que multiplier les plug-in est une assez mauvaise idée: je ne sais pas le quel ne fonctionne pas bien mais je remet un peu aussi en code l’architecture de WordPress. Je n’irai cependant pas jusqu’à incriminer PHP. 

En bref, je ne comprend pas qu’un système ouvert comme wordpress ne blinde pas plus son architecture des plug-in. D’une manière générale, dès que l’on ouvre un système à des personnalisations comme l’ajout de plug-in, il faut impérativement que cela soit cloisonné. Dans le cas contraire, les plug-in se marchent dessus, les upgrades ne sont plus possible et les modifications peuvent cassé le système. Si de plus, l’utilisateur n’est pas d’un niveau non négligeable pour aller lui même résoudre son problème…et bien il change de soft.  Je vais donc continuer à regarder là ou ça dérape, mais en conclusion: ne jamais trop pousser un soft trop en dehors de ce pour quoi il été conçu, surtout s’il est ouvert…à tous les vents !!!

Dec 12

Si on demande aux aficionados des langages sois-disant nobles comme le C# ou Java, ils diront que oui. Je partage en partie cet avis, mais il est tout a fait possible d’avoir les inconvénients du Javascript en Java ou C# voire AOP. Je ne tiens pas a lancer le vaste débat sur quel langage de programmation est le meilleur, car cela finit toujours par des discussions assez stériles, mais je tiens a parler d’un point en particulier: le typage. 

Il est vrai que le javascript n’est pas typé ce qui ne permet pas une détection des problème compile-time mais run-time…ce qui me pose tout de même un sérieux problème. Ce qui est étonnant, c’est de voir à quel point les nouveaux développements en langages typés tendent a essayer d’aller dans la même voie que le javascript. En effet, avec l’arrivée des AOP comme spring et les développements autour des WebServices avec des invocations dynamiques ou les WebServices qui sont eux même non typés…on arrive aux mêmes problèmes. Au final on obtient du code très fragile et difficiles a faire évolués sans une batterie de tests impressionnante.

Dec 06

Le but de cet exemple est de montrer comment séparer la logique métier de l’interface utilisateur. Pour cela j’utilise un control qui publie un évènement spécifique (logique métier) et utilise un template (interface utilisateur) pour le rendu. Le template implément alors la convertion vers l’évènement du control. Vous pouvez étendre cet exemple avec l’utilisation d’un template différent suivant le thème choisi par l’utilisateur…cela fera peut-être l’objet d’un autre article.

Vous pouvez trouver le code source ici.

Pour implétenter cet example il faut:

  • implémenter le control qui charge le template
  • ajouter l’évènement spécific
  • remonter les évènement a partir du template
  • implémenter le template

Control chargeant un template

L’érreur la plus classique est d’oublié de dériver de INamingContainer qui permet de faire remonter les évènements venant du template.
[csharp]namespace BubbleEvent
{
[System.Web.UI.ToolboxData(”<{0}:TemplateControl runat=server />“)]
public class TemplateControl : System.Web.UI.WebControls.WebControl, System.Web.UI.INamingContainer
{
protected override void CreateChildControls()
{
Controls.Clear();
System.Web.UI.ITemplate template = Page.LoadTemplate(”mytemplate.ascx”);
template.InstantiateIn(this);
}
}
}[/csharp]
Ajout de l’évènement métier

Afin de simplifier, on pourrait utiliser System.Web.UI.WebControls.CommandEventArgs et System.Web.UI.WebControls.CommandEventHandler, mais je voulais montrer un exemple complet.
[csharp]namespace BubbleEvent
{

public class TemplateControl : System.Web.UI.WebControls.WebControl, System.Web.UI.INamingContainer
{

public event TemplateControlTextSelectedEventHandler TextSelected;

public delegate void TemplateControlTextSelectedEventHandler(object source, TemplateControlTextSelectedEventArgs e);

public class TemplateControlTextSelectedEventArgs : System.EventArgs
{
private System.String fText;
public System.String Text { get { return fText; } }
public TemplateControlTextSelectedEventArgs(System.String text)
{
fText = text;
}
}
}
}[/csharp]
Remonter l’évènement avec OnBubbleEvent

A noter: l’appel à base.OnBubbleEvent(sender, args). C’est utile dans le cas ou le control dériverai d’un autre custom control.
[csharp]namespace BubbleEvent
{

public class TemplateControl : System.Web.UI.WebControls.WebControl, System.Web.UI.INamingContainer
{
… protected override bool OnBubbleEvent(System.Object sender, System.EventArgs args)
{
if (base.OnBubbleEvent(sender, args))
return true;
if (args is TemplateControlTextSelectedEventArgs)
{
TemplateControlTextSelectedEventArgs textArgs = args as TemplateControlTextSelectedEventArgs;
if (TextSelected != null)
TextSelected(this, textArgs);
return true;
}
return false;
} …
}
}[/csharp]
Implémenter le template

Afin de montrer clairement la convertion entre un évènement lié à l’interface graphique (le template) et l’évènement métier, j’ai utilisé des évènements basé sur des boutons…ce qui est très différent par rapport a faire remonter du text. Le bouton fButtonHello doit fait remonter la chaine ‘Hello !’, alors que le bouton fButtonHelloAndName va faire remonter la chaine ‘Hello ‘avec le nom tapé dans le TextBox fName. Voici le template.

[asp]
<%@ Control Language="C#" AutoEventWireup="true" CodeFile="mytemplate.ascx.cs" Inherits="mytemplate" %>
Name :


[/asp]

Il reste donc a implémenter la convertion.

[csharp]public partial class mytemplate : System.Web.UI.UserControl
{
void ButtonHelloClicked(object sender, System.EventArgs e)
{
RaiseBubbleEvent(this, new BubbleEvent.TemplateControl.TemplateControlTextSelectedEventArgs(”hello !”));
}
void ButtonHelloAndNameClicked(object sender, System.EventArgs e)
{
RaiseBubbleEvent(this, new BubbleEvent.TemplateControl.TemplateControlTextSelectedEventArgs(”hello ” + fName.Text + ” !”));
}
protected void Page_Load(object sender, System.EventArgs e)
{
fButtonHello.Click += new System.EventHandler(ButtonHelloClicked);
fButtonHelloAndName.Click += new System.EventHandler(ButtonHelloAndNameClicked);
}
}[/csharp]

Voila, l’essentiel est fait, il ne reste plus qu’a utiliser ce control dans une page.
[asp]
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<%@ Register TagPrefix="custom" Namespace="BubbleEvent" %>




Result:



[/asp]
Et le code associé:
[csharp]public partial class _Default : System.Web.UI.Page
{
private void TextSelected(object sender, BubbleEvent.TemplateControl.TemplateControlTextSelectedEventArgs args)
{
fResult.Text = args.Text;
}

protected void Page_Load(object sender, System.EventArgs e)
{
fTemplate.TextSelected += new BubbleEvent.TemplateControl.TemplateControlTextSelectedEventHandler(TextSelected);
}
}
[/csharp]

Conclusion

On peut donc séparer la logique métier de l’interface utilisateur en utilsant un template pout l’interface et une classe métier implémentant des évènements métier. Cette technique est très bien adaptée pour faire une intégration AJAX: le template ait les appels AJAX qui relèbent de l’interface et ne remonent que les évènements métier pertinents.

Dec 03

De l’utilisation abusive de buzzword à leur intérêt voir l’utilisation qui en est faite, il y a en général un fossé indiscutable. Je prendrai pour exemple SOA et MDA.

Il est vrai que MDA est moins connu mais il n’en est pas moins pas utilisé à des fins de markéting sans vrai intérêt derrière. Pour SOA, il est clair que l’on est dans le domaine du concept que tout le monde met à sa sauce…voire même les clients eux-mêmes. SOA veut dire “Service Oriented Architecture”, qui n’est ni plus ni moins un concept pour définir une séparation claire entre implémentation et application. Les mauvaises langues diront que c’est ni plus ni moins que le concept de design pattern : Façade…je dois avouer que je ne leur donne pas tord!
Je parle dans cette article de SOA et MDA car le concept MDA (”Model Driven Architecture”) est en partie en recouvrement avec le SOA car le MDA est basé sur une description claire du modèle des applications afin de pouvoir les porter sur des implémentation différentes.
Revenons au SOA. Comme je l’ai dit, il requière une séparation entre application (objets métiers, workflow, …etc) et l’implémentation, le but étant de pouvoir faire ce comprendre des applications d’architecture différentes et qu’elles puissent interagir. Le fait qu’une application soit exposée en Web Service n’en fait pas de facto une application SOA, mais il est vrai que 90% du chemin a été parcouru car une architecture WebService se repose (dans 99% des cas) sur du SOAP (over HTTP) qui est —lui— un standard…donc le canal de communication est déjà en place et il ne reste plus qu’a exposer des objets qui sont indépendants de l’implémentation. Si par exemple l’application retourne des images dans un format propriétaire…perdu! Ou encore s’il faut faire un appel pour ouvrir une transaction, puis la fermer après l’appel…on est encore trop proche de l’implémentation.
Autre problème souvent sous-estimé: le versioning! Si les objets manipulés, ou les méthodes changes d’une version à une autre, l’interaction avec les autres applications devient un cauchemar alors que SOA intrinsèquement cherche a gommer ces problématiques. Bref n’est pas SOA qui veut, même si tout le monde prétend l’être afin de pouvoir placer ce buzzword dans leur plaquettes.
Le concept MDA est quand a lui moins un buzzword, mais a-t-il sa place dans une plaquette marketing (ce qui est souvent le cas). A mon avis c’est un terme qui ne doit pas sortir d’une R&D car il n’offre que peut d’avantages en tant que Client excepté le fait d’avoir une documentation claire et précise d’une ou plusieurs applications de son système d’information. Le principe est simple: la ou les applications sont défini dans un modèle qui va décrire les objets métiers, les worklows — bref, tout ce qui compose une application — indépendamment de l’implémentation (2 ou 3 tiers, J2EE ou .Net, …etc.). Ce concept est beaucoup plus pragmatique que SOA car il permet entre autre de simplifier les des migrations d’implémentation en assurant minimisant le risque de voir apparaître des bugs. Pour les applications particulièrement sensibles comme les applications financières c’est un atout majeur. Il permet aussi d’assurer des modifications substantielles dans les mêmes conditions. Là ou je trouve qu’il y a de l’abus, c’est que documentations technique exhaustive est tout à fait valable, or je n’ai jamais vu une documentation technique markétée MDA !!