Nouveau blog, en anglais !

mes prochains posts seront sur mon nouveau blog Coding Tavern.
J'écrirai dorénavant en anglais, car il faut le dire je suis mauvais en Français, et puis de toute façon l'anglais est la langue du développeur !
Design mantra devient Coding Tavern ! :)

WCF over Twitter sur Codeproject !!

Ce qui ne se parle pas n'existe pas, j'ai donc partagé mon enthousiasme sur le projet le plus inutile, mais amusant que j'ai pu faire WCF over Twitter.

Pourquoi les métiers de l'informatique sont si innovants ?

Quand on compare un département IT à une chaine de production, on tend a comparer le développement et l'administration comme des métiers répétitifs "Ils sont devant leur PC tous les jours et produisent du logiciel donc ils font toujours la même chose".
Maintenant, il suffit de réfléchir 5 secondes en quoi consiste les métiers d'administrateur et de développeur et en une phrase c'est très simple : automatiser, et limiter l'intervention humaine.
Ces deux métiers visent cette objectif, avec des outils différents, mais fondamentalement ils visent le même but.
Si je reviens à la comparaison d'un département IT à une chaine de production, les personnes y travaillant sont au final, "des automates qui automatisent".

Mais il y a une chose de sûre, les profiles dans ces deux métiers de l'informatique détestent une chose plus que tout : faire une tache répétitive.
Cette hantise les pousse à inventer des outils qui automatise la fabrication des logiciels qui automatisent(vous suivez ?!).
Pour le développeur cette "meta-meta automatisation" se traduit par des bonnes pratiques de programmation (intégration continue, design patterns, génération de code), et par la création d'outils pour leur propre besoins.
Quand je dois faire quelque chose de répétitif, je fais un outils qui automatise cette tache, même si l'outil prend plus de temps à faire que la tache en question. Car au final, je m'amuse plus et j'apprend quelque chose, si d'autres personnes ont la même chose à faire ça peut même devenir un business.

Le bon développeur arrive a un certain niveau où il ne peut plus automatiser la création de son logiciel, car les décisions à appliquer dépendent fondamentalement de ce qu'attend le client et non plus du code.

A partir de ce moment, l'automatisation n'est plus possible et la créativité est à son maximum.
A partir de ce moment, le développeur essaye juste de comprendre l'utilisateur, son métier, et comment l'aider. A ce niveau je pense que le plus important pour le développeur c'est beaucoup empathie et le désir d'apprendre.
Le désir d'apprendre est synonyme de curiosité intellectuelle, et à ce point j'ai tendance à m'énerver quand quelqu'un dit à un enfant "la curiosité est un vilain défaut", la curiosité est la source de l'innovation, sans curiosité on devient un automate et tous les jours se ressemblent.
Le code n'est en réalité qu'un le moyen d'expression de ses idées, comme ce blog est le moyen d'expression de mes pensées (@Copyright).

Une chose intéressante se produit, petit à petit le développeur devient un expert métier à part entière (si il ne l'était pas avant).
Cette expertise couplé à ses compétences d'automatisation créer de nouvelles idées.
N'est-ce pas la définition de l'innovation ?

Duplex MSMQ sur CodeProject

Duplex MSMQ est sur codeproject, il vous montrera a quel point WCF est extensible, et j'espère qu'il vous donnera des idées d'extension en WCF.
J'en suis particulièrement fier, car malgrès le temps qu'il m'a fallu pour comprendre les entrailles de WCF, l'implémentation final reste simple à comprendre et à écrire !
J'attend votre feedback !
http://www.codeproject.com/KB/WCF/duplexmsmq.aspx

IDispatch sur CodeProject !

Après mon post ma solution pour casser une dépendance temporelle j'ai écrit un article sur codeproject. J'ai besoin de votre feedback ! :)

WCF over Twitter Partie 4 : Autres

Durant les articles précédents je vous ai expliqué comment j'ai implémenté WCF over Twitter tout en vous masquant ce que je ne considérais pas indispensable.

Première chose : Le ChannelListener ne fonctionne que de façon synchrone.
Première conséquence, je dois le spécifier dans le behavior de mon endpoint quand je crée mon service.

ServiceHost host = new ServiceHost(typeof(HelloWorldService), new Uri("twitter://SlasheneServer"));
var end = host.AddServiceEndpoint(typeof(IHelloWorldService), bind, "");
end.Behaviors.Add(new SynchronousReceiveBehavior());
host.Open();

La raison est simple, si vous décidez d'implémenter ChannelListenerBase vous vous rendrez compte qu'il y a une tonne de méthode à implémenter. Donc vu que je suis fainéant, voici mon implémentation des méthodes asynchrones de ChannelListenerBase.

protected override IAsyncResult OnBeginClose(TimeSpan timeout, AsyncCallback callback, object state)
{
 throw new NotImplementedException();
}

protected override IAsyncResult OnBeginOpen(TimeSpan timeout, AsyncCallback callback, object state)
{
 throw new NotImplementedException();
}

... A une exception près.

void _Channel_Closed(object sender, EventArgs e)
{
 ((IInputChannel)sender).Closed -= _Channel_Closed;
 _Reset.Set();
}
protected override IInputChannel OnAcceptChannel(TimeSpan timeout)
{
 var waited = _Reset.WaitOne(timeout);
 if(!waited)
  throw new TimeoutException();
 _Channel = new TwitterInputChannel(this, _Creds);
 _Channel.Closed += new EventHandler(_Channel_Closed);
 return _Channel;
}

protected override IAsyncResult OnBeginAcceptChannel(TimeSpan timeout, AsyncCallback callback, object state)
{
 return new CompletedAsyncResult(callback, state);
}

protected override IInputChannel OnEndAcceptChannel(IAsyncResult result)
{
 CompletedAsyncResult.End(result as CompletedAsyncResult);
 return OnAcceptChannel(this.DefaultOpenTimeout);
}

J'ai dû quand même implémenter les méthodes asynchrones de AcceptChannel.
La seule chose à retenir dans ce bout de code c'est que ma méthode OnAcceptChannel bloque jusqu'à ce que le précédent channel n'est pas fermé.
BeginAcceptChannel invoque directement le AsyncCallback, qui appellera en interne OnEndAcceptChannel pour récupérer le channel. OnEndAcceptChannel bloquera cependant lors de l'appel à OnAcceptChannel (En théorie, je dois appelé le callback que lorsqu'un channel est disponible, mais ça compliquait mon exemple).
CompletedAsyncResult vient de l'exemple de microsoft sur la création d'un TransportBindingElement. Microsoft montre l'implémentation de WCF over UDP, leur implémentation est très complet mais très difficile à comprendre.

De la même façon, dans l'implémentation de mon input channel, je lance une NotImplementedException pour toutes les méthodes asynchrones.

Du coté du client, j'ai du implémenter les méthodes asynchrones. J'ai cependant triché et les méthodes asynchrones invoquent leur contre partie synchrone de façon synchrone...

public IAsyncResult BeginSend(Message message, AsyncCallback callback, object state)
{
 Send(message);
 return new CompletedAsyncResult(callback, state);
}

public void EndSend(IAsyncResult result)
{
 CompletedAsyncResult.End(result);
}

Voila c'est tout !
Vous pouvez trouver le code source sur http://wcfovertwitter.codeplex.com/

MCPD EAD : But atteint !

Mai 2008, je m'étais fixé un but : devenir MCPD Enterprise Application Developer.
Un an et 2 mois plus tard j'ai enfin atteint ce but !
J'ai donc passé mon temps à apprendre et à passer les certifications requises intermédiaires une à une.

Pour arriver à mon objectif :



Après tout ceci, je ne cache pas ma satisfaction d'être arrivé à mon but. Mais le plus intéressant c'est toujours le voyage et non pas la destination.
Ce que j'ai appris par rapport aux certifications, c'est qu'elles certifient que l'on n'est pas nul... mais pas que l'on est bon !

Oui je sais faire de l'ASP.NET, oui je suis certifié ASP.NET mais j'avoue que mon niveau en développement web est largement inférieur à celui d'une personne qui s'est passionné pour cette technologie.

En revanche, je suis confiant de mon niveau en WPF et WCF, et les certifications ne m'ont introduit que le minimum pour me lancer.

Enfin pour ceux qui veulent tenter le voyage, je conseillerai ceci :
Si vous êtes un étudiant, foncez ! si vous ne geekiez pas à coder quand vous étiez au collège ou avant, il y a de grande chance que vous êtes au même niveau que les autres étudiants, vous n'avez pas d'expérience non plus, la certification est le moyen "facile" de se démarquer et de montrer que l'on aime programmer.
Le niveau à l'école sur le développement est extrêmement bas, les certifications vous feront apprendre énormément de choses.

Si vous êtes un employé et que vous avez vos compétences à recycler foncez (surtout qu'il y a des chances que l'entreprise paye).

Dans les autres cas, une certification pour avoir une certification ne sert pas à grand chose.

Enfin, une certification ne vous fera pas devenir un meilleur développeur, elles vous donnera seulement les armes pour le devenir.
Le seul moyen pour être un bon développeur, est de... développer et lire ! Cependant, je pense que ceux qui arriveront au bout de ces certifications seront plus disposés à apprendre par eux même et à développer pour le fun. Ce voyage développera votre curiosité.

Une petite citation de Jeff Atwood pour la fin :
"le plus grand risque dans le développement c'est les programmeurs incompétents.
Il y a des estimations qui annonce que le nombre de programmeurs dont les US ont besoin est de 200 000. C'est faux. Ce n'est pas un problème de quantité que l'on a mais un problème de qualité. Un mauvais programmeur peut facilement créer deux nouveaux emplois par an. Embaucher plus de mauvais programmeurs augmentera seulement notre besoin percu pour eux. Si nous avions plus de bon développeurs et un moyen facile de les identifier, nous aurions besoin de moins de programmeur, et non pas plus."