Denis Dollfus' Blog

ALT.NET

ALT.NET, c'est une autre façon de concevoir, d'exploiter et de faire évoluer .Net.

Si vous voulez comprendre ce nouveau buzzword, lisez ce billet clair et .net de Laurent Capin.

Notez quand même que le centre de ALT.NET penche plus vers le ALT que vers le .NET. Le manifeste Values & Practices de ALT.NET n'a en effet aucun point de contact avec .Net. Il pourrait tout aussi bien être le manifeste de ALT.JAVA. Du moins si Java n'avait pas déjà adopté (et conçu) la plupart de ces outils/valeurs/pratiques ...

Ce qu'il manque peut-être à ALT.NET, c'est un argumentaire qui justifie l'investissement Alt dans .Net et non dans Java.

[Mise à jour du 20 juillet] Do it yourself. J'ai ajouté sur alnetpedia.com une phrase pour souligner que .Net est la cible de ALT.NET. Retouchée par Dabid Laribee ça donne : "And we seek to apply these values and practices with the .NET Framework." Quand même.

Castle ActiveRecord et les objets "transients"

Pour ceux qui connaissent le projet open-source .Net Castle, ActiveRecord va faire pour sa prochaine version une amélioration intéressante concernant la gestion des objets "transients".

Pour rappel, Castle comprend plusieurs projets, dont :
•    un container IoC (Inversion of Control) , MicroKernel
•    un container plus élaboré qui repose sur le précédent et y ajoute des fonctions de configuration et d'interception
•    un framework MVC pour le Web, MonoRail (qui n'a rien à voir avec Mono)
•    un framework de programmation orienté aspect, Aspect#
•    un framework de persistance, ActiveRecord.

Castle ActiveRecord est une surcouche à NHibernate dont la particularité est de permettre la description du mapping entre classes et database et entre classes directement dans le code sous forme d'attributs.

Une des limitations d'ActiveRecord était de ne pas exposer de moyen de faire des Update sur des objets détachés de la session NHibernate courante, c.-à-d. sur des objets créés hors contexte NHibernate et doté d'un clé primaire valide.

Or ce scenario est commun quand on utilise la classe ObjectDataSource pour le databinding de l'UI : en cas d'update lors d'un postback, le framework .Net crée "dans notre dos", par reflection, une instance de la classe de la source de données, lui assigne toutes ses propriétés (éventuellement modifiées par l'utilisateur via l'UI) et la passe en paramètre de la fonction d'update spécifiée dans la déclaration de l'ObjectDataSource.

On se retrouve donc face à la session nhibernate avec un objet inconnu de la session, peut-être même copie d'un objet présent en session. Appeler Update() sur cet objet lance une exception. NHibernate sait gérer ce cas grâce à la méthode SaveOrUpdateCopy de l'interface ISession (remplacé par merge en v3), pas ActiveRecord qui ne donnait pas d'accès à cette méthode.

Et bien dans la prochaine release de Castle ActiveRecord, l'équivalent fonctionnel de SaveOrUpdateCopy est disponible via la méthode SaveCopy de ActiveRecordBase. Pour l'instant disponible seulement depuis le repository Subversion de castle ou depuis leur serveur de build.

[ActiveRecord or not ActiveRecord ? This is another question…]

Les langages de développement les plus énervants

Quels sont les environnements les moins pratiques, ceux qui dissimulent les fautes de syntaxe jusqu'à l'exécution du programme, ceux dont l'autocompletion est la plus rudimentaire, ceux dont le code est difficilement auto-explicatif, et ceux qui obligent les développeurs à gérer eux-mêmes les allocations mémoire ?

Bref, quels sont les langages de développement qui font craquer les développeurs ?

Pour répondre à cette question, voici le Fuck Index (allez,  F Index c'est plus joli), indice de vulgarité des langages de développement, dont la paternité revient à Didier Girard suite à ce post. L'hypothèse à la base du F Index est que plus un développeur est frustré, fatigué et énervé par son environnement de développement, plus il aura tendance à jurer et à en laisser des traces dans son code.

Pour calculer le F Index pour JavaScript par exemple, la recette est simple :

Allez sur Google Code et cherchez le nombre d'occurrence pour la requête "lang:javascript" (83300).

Recommencez avec la requête "fuck lang:javascript" (200). Divisez l'un par l'autre et vous obtenez le F Index de JavaScript, en l'occurrence 0,24%.

Et voici le hit parade :

Perl : 0,35%

C : 0,32%

JavaScript : 0,24%

C++: 0,17%

Cobol : 0,1%

Java : 0,06%

C# : 0,047%

Ca a du sens non ? Même si, forcément, certains diront que le F Index est biaisé.