Bonjour les fans de .Net et d’intégration continue!
J’affectionne Hudson en ce moment, et je l’applique de plus en plus pour .Net. Je l’utilise en ce moment pour analyser le code et “gronder” les membres du projet qui codent “mal”.
A défaut d’avoir un plugin Sonar pour .Net, Hudson et son plugin Violations fait déjà pas mal de bon rapports.
Ce plugin supporte pas mal d’outils comme FXCop ou StyleCop. Concernant ce dernier, le plugin bug avec les chemins absolus et les “\”, j’aimerai bien le corriger mais je n’ai pas trop le temps
J’ai regardé les sources de ce plugin, et ça semble assez simple.

Ma petite application Winform qui lit le flux RSS pour afficher l’état des projets.
En ce moment c’est bien rouge… mais ça peut aussi être jaune ou vert

Il supporte aussi CPD qui détecte les Copier/Coller (sans doute la source de bug la plus importante dans équipe), mais il ne supporte pas le C#… Idem, j’aurai bien aimé avoir le temps de l’implémenter.
J’ai vu que TeamCity avait sa propre tâche “Duplicates Finder“, mais ça n’a pas l’air d’être indépendant.
NDepend est magique et répond à ce besoin, mais il est payant, et non supporté par Hudson.
J’ai eu aussi envie de tester Gendarme. Encore une fois, si le temps me le permet, j’ajouterai bien le support des rapports Gendarme dans le plugin Hudson-Violations. En attendant, je peux toujours convertir le XML de Gendarme en XML FXCop (je n’ai pas encore étudié la faisabilité).

Je sais que faire évoluer Hudson ou CPD ou encore Sonar nécessite des connaissance en Java.
Mais le constat est que ces outils sont matures en Java, et les “pâles copies” en .Net ne sont pas à la hauteur (comme CC.Net par exemple).
L’investissement est très variable entre les différents projets (Violation, Sonar, etc), mais je suis convaincu qu’il en vaut le coup.

Et vous, qu’en pensez-vous?

Faut-il absolument faire du .Net pour du .Net? et s’investir sur un CC.Net vieillissant?
Hudson est-il un bon choix d’investissement?
Ne faut-il pas mieux privilégier l’investissement sur Sonar pour les rapports d’analyse?
Et la question la plus important: y a-t-il des personnes motivées par ça?
Je pense même que ça mérite un “meta-projet opensource” avec son site web, qui regroupe les outils de build et d’analyses de code en .Net, afin d’offrir une solution “packagée” pour .Net.

Je vous invite à venir à la session ALT.Net sur l’AOP présenté par Romain Verdier le Mercredi 17 juin.

Pour vous mettre dans le bain et vous permettre de vous informer sur le sujet avant la réunion, voici un exemple d’AOP super simple avec Postsharp : http://bit.ly/71pej

Dans le cadre de mon projet actuel, l’AOP aurait pu m’aider à décorer les méthodes qui nécessitent de l’impersonation (accès à des ressources critiques qui nécessite donc un compte privilégié) ou à gérer la sécurité+log+erreurs au niveau des WebServices (CheckClientCertificate+Log+SoapException).

J’utilise souvent l’AOP avec Spring.net, qui utilise la méthode “création de proxy dynamiquement” ou appelé aussi “dynamic weaving”.

Cette méthode consiste à créer des proxy dynamiquement qui encapsulent l’objet cible en ajoutant le code des aspects aux bons endroits. La limite de l’approche avec Spring.Net est que l’on perd en performance à la création de ces proxy, on ne peut exposer qu’une seule interface, et cela oblige à utiliser Spring.net pour se faire injecter l’instance.

Postsharp lui, fait tout à la compilation, c’est ce que l’on appelle le “static weaving”. L’avantage est que l’on gagne en performance, on ne dépend pas de la façon d’instancier la classe, et la manière d’ajouter des aspects se fait par code (par attributs) se qui peut s’avérer plus agréable que de les déclarer dans un XML (ce que fait Spring.net). L’inconvénient est que cela oblige à posséder le code source de l’objet à “aspectiser” et de le compiler avec les aspects.
On peut citer AspectDNG qui utilise aussi le “static weaving”.

Aspect# utilise le “dynamic weaving” tout comme Spring.net. Ils utilisent tous la réflexion à l’aide de System.Reflection.Emit (fourni par défaut avec .Net) pour créer les proxy dynamiquement. Aspect# le fait par l’intermédiaire de Castle.DynamicProxy (utilisé aussi par NHibernate ou RhinoMock).

Le débat à la session ALT.Net va certainement porter sur Réflexion vs Introspection: la réflexion est moins bonne en performance que l’introspection, car elle nécessite de charger tout le code en mémoire, alors que l’introspection analyse directement l’IL. Voici un petit post sur le débat: http://bit.ly/2xq6aB

Romain a travaillé sur Mono.Cecil.Decompiler avec Jean-Baptiste Evain, il va donc sans doute nous parler des avantages de l’introspection avec Mono.Cecil. Voici un autre post sur le sujet sur le blog de JB.

Voila, j’espère que vous serez ainsi mieux armés pour assister à la session

Mardi 19 Mai a eu lieu la session ALT.Net sur l’Adaptive Object Modeling présenté par Sébastien Ros.
Je voulais simplement dire que j’étais content d’assister à cette rencontre : la présentation de Sébastien était courte et intéressante (et drôle en plus !). En résumé : le type de présentation qui ne nous laisse pas le temps de s’endormir.
Cela nous a aussi permis de débattre de divers sujet à la fin de la présentation : nous avons voté pour des sujets qui nous intéressent, puis nous nous somme divisé en 2 groupes pour en débattre. Cette formule nous permet de changer de groupe si le sujet finit par nous ennuyer
Bref, j’ai bien aimé cette rencontre qui revient sur l’esprit des premières. En plus, Octo nous a bien accueillis avec de succulents petits-fours :p

+    =   

Pour revenir à la présentation de Sébastien : il a commencé par dire que nous faisions tous de l’Adaptive Object Modeling sans le savoir. Et en effet ! Je n’arrête pas d’en faire, sans en connaitre le nom. A la suite de cette présentation, je me rends mieux compte des similitudes de mes projets, des méthodes/patterns employés, et je peux prendre plus facilement du recule sur tout ça.

L’Adaptive Object Modeling c’est quoi : c’est le fait de modéliser une application qui est capable de s’adapter à un modèle métier.
Sébastien a cité 2 exemples : un gestionnaire de tâches (comme Jira/Trac/Redmine) et une GED.

J’ai déjà travaillé sur ces 2 types de projets, mais pour ne pas plagier sa présentation, je vais prendre pour exemple une autre de mes expériences : un logiciel de vente (ok je triche, il a aussi cité cette exemple au tout début).
J’ai en effet travaillé sur une application pour vendre des cuisines, effectuer des devis, confirmer la vente par une facture, commander les meubles à l’aide de bon de commande, etc.
C’était chez un éditeur de logiciel, et le but était donc de faire un logiciel générique que l’ont peut vendre à divers clients.
Pour cela, il faut que l’application s’adapte au modèle métier de chaque client :

• Certains vendent des meubles, d’autres de l’électroménager
• Certains ont un workflow de validation des devis/factures complexe, d’autres non
• Certains appliquent des règles de calcules de prix complexes (taxes, remises, formule de calcule de prix), d’autres vendent les produits à des prix fixes
• Certains appellent un document « devis », d’autres une « quote » (français/canadiens)
• Etc.

L’objectif est donc de modéliser un « méta-modèle » qui s’adapte à l’aide d’une configuration :

• Un produit possède un type : il peut être un meuble, un frigo, etc.
• Un type possède un ensemble d’attributs : un meuble possède une taille, un volume, une couleur, etc.

Bien sûr, un produit aura toujours un prix quel que soit son type. Ce dernier figurera toujours dans un devis, qui sera associé à un acheteur, etc. Il y a donc certaines choses « non générique » car communes à chaque client. Nous avons alors une logique « métier » commune : toutes applications de vente servent à calculer le prix d’un devis/facture.
Comme l’a dit Sébastien : le plus dur est de placer la barre entre le « tout spécifique » et le « tout générique ». C’est l’expérience et le contexte qui nous fera pencher la balance d’un coté plus que de l’autre.

Il existe divers façons de configurer le modèle (XML, Base de données) mais le plus important est de savoir à qui s’adresse cette configuration. En effet, j’ai travaillé sur un projet qui a subit un échec car le client final était incapable de configurer un fichier XML….
Bien sûr, pour nous développeurs, cela nous semble évident avec des outils qui offrent la coloration syntaxique ou la complétion… mais pour le client, nous aurions du lui offrir une interface graphique agréable pour qu’il arrête de nous appeler tous les jours pour un changement de libellé…
Paramétrer des structures de données est aisé, mais paramétrer un comportement l’est moins. Il existe plusieurs solutions : ça peut se résumer à des « true/false » pour activer/désactiver des étapes d’un workflow, ou ça peut aller jusqu’à utiliser un DSL. Sébastien a parlé de modéliser un langage, et a pris comme exemple WorkflowFundation.

Pour conclure, de nombreuses personnes se demandaient de l’intérêt de coder un « méta-model » générique, car la plus part, je pense, sont des consultants qui effectuent des projets spécifiques à leur client. L’intérêt de ce type de démarche est bien sûr de revendre le même logiciel à divers clients voir de vendre de la prestation pour configurer le logiciel (si la configuration devient complexe, comme c’est le cas pour les ERP). L’Adaptive Object Modeling s’adresse donc à des sociétés éditrices de logiciels qui visent un type de client.
Pour terminer, je voudrai revenir sur la difficulté énoncé par Sébastien concernant la balance Spécifique-Générique : j’ai vu certains projets se terminé par un échec car le chef de projet voulait faire « trop » générique en prévision des futurs clients… sauf que cela donne un logiciel qui ne répond même pas au besoin du premier client et qu’il est très difficile d’adapter aux besoins de ce dernier à cause de son aspect trop générique.
Je pense alors qu’il faut une approche « bottom-up », c’est-à-dire de réaliser du spécifique pour le premier client, et rendre des parties génériques si le besoin des autres clients est similaire. On reste alors agile : YAGNI, on ne fait que ce qu’on a besoin. Ce n’est que lorsqu’on a un nouveau besoin (d’un autre client) qu’on procède à du refactoring pour rendre des morceaux du logiciel génériques. Par contre, cela demande de faire un effort sur la modularité (il est plus facile de refactorer un modèle de 10 classes, qu’un modèle d’1 classe constituée de 30000 lignes de codes…).

Aaaaah, je me souviens du bon vieux temps ou je découvrais le développement Web, lors de mon premier stage d’étude, sur une application PHP…
J’avais déjà découvert les joies des incompatibilités des navigateurs: à l’époque, Netscape était le navigateur officiel, et je me battais pour qu’on utilise IE5…
Je m’étais amusé à copier/coller des petits bouts de javascript à droite à gauche, sans trop comprendre ce qu’ils faisaient, afin d’avoir une interface plus user-friendly…
J’étais en admiration sur des applets Java beaucoup plus ergonomiques que mes bouts de Javascripts…
Et je bavais sur des sites entièrement Flash, magnifiques, et performants (quand c’était bien fait…)

Puis j’ai entendu parler de DHTML: “la grosse blague”, ce sont les mots que j’ai sans doute prononcés quand j’ai su que ce n’était qu’un nom marketing pour le couple Html+Javascript.

Aujourd’hui on parle de Web 2.0 ou d’Ajax. On parle aussi d’Adobe Air, ou de Silverlight (on va éviter de parler de JavaFX). Finalement, pas de grosse révolution, mais plutôt une “évolution”.

Pour ceux qui ne sont pas au courant, je développe en .Net depuis un certain temps, et en ASP.Net depuis 1 an.
Comme ça a été conclu lors d’une réunion ALT.Net, les développeurs ASP.Net sont souvent issues du monde Winforms et convertis par la tendance actuelle.
Cela donne des développeurs complètement ignorant du protocole HTTP, de l’HTML et du Javascript: “C’est du C# ou rien!”

Moi même je ne suis pas BON en Javascript, pourtant tout est la:

• Frameworks graphiques puissants et nombreux: ExtJS, Dojo, JQuery, etc.
• Frameworks “de base” n’ayant rien à envier à .Net ou Java: JsUnit, log4js, ActiveRecordJS, etc.
• Moteurs Javascript de plus en plus rapide et performant: v8 de Google ou celui de Mozilla avec un GC.
• Nombreux outils et IDE de plus en plus compatibles: débugage et complétion dans VisualStudio ou à l’aide de pluggin, firebug, YSlow, etc.

Bref, avec du Javascript, il est possible de faire de bonnes applications Web aussi ergonomiques qu’une application Desktop.
Et le Javascript pour le Desktop justement? Python a la vedette en tant que langage de développement d’application Linux/GTK (même si Mono le devance maintenant). Et pourquoi pas des applications GTK-Javascript avec Seed (bon lien à ce sujet)? On peut noter aussi la tentative de Mozilla avec Prism, ou Adobe Air proposant des applications Desktop/Ajax…

Mais la folie Javascript ne s’arrête pas là: pourquoi ne pas faire le Backend, côté serveur, en Javascript? Et bien messieurs, c’est maintenant possible!! Et ce serveur s’appelle Jaxer d’Aptana (dont j’ai parlé dans mon précédent billet).

Jaxer est un serveur web (Apache) avec un moteur de Javascript “server side” sous la forme d’un module, exactement comme pour du PHP ou du Python (ou encore du Perl). Je me permets de citer un blog qui explique ça très bien.
En résumé: avec l’attribut “runat=server-proxy”, le code Javascript est appelable depuis le navigateur mais est exécuté sur le serveur.
Petit exemple:

<script runat="server">
  var newResultSet = Jaxer.DB.execute("SELECT * FROM myTable");
  var newPrice = newResultSet.rows[0].price;
</script>

C’est aussi simple que cela. Certains diront “beurk: du HTML+Javascript+SQL dans le même source…”, mais cet exemple illustre bien ce qui est possible de faire. C’est maintenant à vous de séparer les librairies “.js” des pages HTML, et utiliser des procédures stockées ou un ORM Javascript (comme ActiveRecordJS).
Dans notre cas, le code n’est visible que du coté serveur, si maintenant on souhaite appeler une fonction sur le serveur sur un événement coté client, voici le principe:

<script runat="server-proxy">
  function myServerSideFunction() {
    // ...
  }
</script>
<input onclick="myServerSideFunction();" type="button" />

Dans ce cas, l’Ajax est effectué de manière automatique et transparente: une méthode “proxy” sera visible du coté client pour appeler le code du coté serveur.

C’est bien beau, mais c’est quoi l’avantage?
Après tout, pourquoi apprendre 4 langages ? En générale, on a ça:

• HTML: interface statique
• Javascript: traitement dynamique coté client
• Java/.Net/Python/PHP/Ruby: traitement dynamique coté serveur
• SQL : traitement des données

Aptana propose ceci:

• HTML: encore et toujours
• Javascript: traitement dynamique coté client
• Javascript encore: traitement coté serveur
• pas de SQL à l’aide d’un ORM Javascript : ActiveRecordJS

Donc l’apprentissage de 2 langages suffit!!

Je sais que ça ne va pas plaire aux nombreux développeurs .Net qui adorent le C# et qui connaissent mal l’HTML+Javascript… ces derniers préféreront Silverlight, mais c’est un autre débat
Pour les autres, Jaxer est rapidement testable à l’aide de la solution Cloud d’Aptana, cela permet d’éviter d’installer et cofigurer un Apache.

OK, je ne suis pas original, je parle d’un sujet “dans le vent” : le Cloud Computing…

Cloud Computing: introduction avec Azure et Amazon

Grâce à la présentation chez Fastconnect par Romain, j’ai pu découvrir les joies de Azure. C’est la solution Cloud de Microsoft qui est bien sûr très orientée .Net + VisualStudio.

On parle ici de “Plateform as a Service” puisque Azure nous offre de quoi héberger nos applications (web ou service) à l’aide d’une architecture “cloud”.
On développe des applications qui effectuent des calcules distribués sur X machines, ou on héberge X sites web ASP.Net dont la charge est répartie entre eux.
En plus d’offrir une architecture “scalable”, on a droit à certains services “bas niveau” comme le service de stockage de données binaires (full REST), une queue ou un stockage “à la BigTable“. On peut ensuite bénéficier de services plus “haut niveau” comme “Live Search” ou “Live Calendar“.

Par comparaison, Amazon avec EC2 propose un service “Cloud” orienté “Hardware as a Service” car on loue ici à des machines virtuelles, vierges ou avec des choses pré-installé (comme Linux Apache Msql PHP). La puissance de ces machines est aussi “scalable” à la demande, et on ne paie que ce que l’on utilise.
A la différence d’Azure, où la partie “Hardware” est complètement masquée (IIS7, WindowsServer2008, etc.). Azure offre une interface web d’administration pour surveiller l’utilisation du CPU ou de la mémoire, et on peut rapidement changer le nombre d’instances d’un site web à la demande.
Ceci dit, Amazon offre aussi des couches techniques comme le service de stockage Amazon S3.

Bref, le Cloud ce n’est pas qu’un hébergeur de site web ou une Dedibox, c’est surtout le fait de bénéficier des serveurs des gros mastodontes tel qu’Amazon ou Microsoft pour louer la puissance dont on a besoin, et profiter d’applications et de services pré-installés utilisables tout de suite. C’est aussi la possibilité d’utiliser des services techniques (Database, etc.) ou haut niveaux (Map, Calendar, etc.).

Nouvelle solution de Cloud avec Aptana

Azure offre de quoi développer un site ASP.Net Scalable rapidement, mais je vais faire le chieur en voulant développer une application Rails sous Eclipse!

C’est la que j’ai découvert Aptana Cloud.

La solution d’Aptana est la suivante :

• Comme Azure, Aptana masque la complexité et l’installation des machines virtuelles. On a donc du “Plateform as a Service”. On a droit à une machine pré-installée avec Apache, MySQL, SFTP, SSH, SVN, etc.
• Comme Azure, Aptana offre un IDE (Eclipse) avec un grand nombre de plugins pour développer, déployer et administrer le Cloud rapidement et facilement.
• Comme Azure, Aptana offre une interface Web pour gérer sa machine, la puissance consommée et ce que ça nous coûte en fin de compte. Aptana fournit aussi la possibilité d’héberger un site en “staging mode”, puis quand on est sûr de soi, on a la possibilité de le basculer en “public mode”.
  
• Comme Amazon, la puissance et les prix sont scalables: on ne paye que ce dont on a besoin et on peut changer la puissance à la volé (le site indique $20 par mois, c’est parce qu’une machine de 256mo de RAM avec 5GB de disque coûte $0,027/heure)

Les points négatifs :

• Pas d’architecture applicative “scalable”: contrairement à Azure qui permet de changer en 3 clicks le nombre de processus ou le nombre d’instances d’un site. On dépend ici de la scalabilité de la machine virtuelle. Aptana est en partenariat avec Joyent qui héberge ces machines.
• Pas de services “haut niveau” comme ceux de Google (Google Maps, Google search, etc.) ou de Microsoft (Live Calendar, etc.). Mais rien ne nous empêche de les utiliser…
• Services bas niveau limités: MySQL est OK, mais si l’on a besoin d’un stockage performant et distribué, on utilisera en plus les services d’Amazon (S3) ou Google (BigTable).

Voici pour moi les PLUS d’Aptana:

• Plugins Eclipse de qualité avec un éditeur HTML/Javascript bien meilleur que celui par défaut (de WTP)
• Permet de faire des applications HTML classiques, PHP, Rails, Java, mais aussi Python, Adobe AIR, iPhone, Nokia WRT.
• En quelques clicks dans le Wizard de création du projet, permet de choisir des frameworks Ajax parmi les plus connus (jQuery, Dojo, ExtJS, et j’en passe).
• Fournit une documentation riche à l’aide de vidéos sur Aptana TV.
• Offre un nouveau type de développement full HTML+Javascript : Jaxer.

En résumé, Aptana offre mieux que de simples machines virtuelles :

• un IDE puissant pour développer différents types d’applications
• des machines virtuelles scalables pré-installées pour déployer dessus
• une interface claire pour les administrer (statistiques, etc.)

Le Cloud donne des idées, et Aptana est une solution qui m’a l’air bien sérieuse. Je me suis laissé séduire grâce à l’offre d’essai gratuite, et je pense qu’à l’avenir j’utiliserai ce type de solutions si je veux développer et héberger un site Web.

J’ai cité Jaxer dans les PLUS de la solution d’Aptana, mais j’en parlerai dans mon prochain billet

Je pense que la Dependency Injection est une valeur fondamentale à l’écriture d’un programme, et je l’utilise tous les jours.
Je suis un adorateur (voir expert) de Spring/Spring.Net, et j’affectionne l’écriture de la structure du programme en XML.

Mais cette technique est très largement contestée :

• nécessite un éditeur XML “intelligent” (ce qui est le cas grâce à SpringIDE) pour la complétion de la structure mais aussi des types.
• interprétation au Runtime, et donc erreurs potentielles découvertes qu’au dernier moment.
• verbeux
• mauvaises performance (lecture du XML…)

Ça a aussi ses avantages, c’est pour ça que je reste adorateur de Spring, mais ce n’est pas le sujet…

J’ai déjà souvent eu ce débat avec Romain dans le monde .Net (voir http://ninject.org).
Je connais très mal les alternatives à Spring dans le monde Java, mais je connais celle de Google : Guice.

Voici un tuto/introduction très convaincante.

Pour ceux qui ne connaissent pas Ninject ou Guice, voici un peu le principe :
Au lieu de rédiger un XML, on utilise massivement les annotations (attributs en .Net) pour spécifier les injections. Ceci est aussi possible en Spring (technique dite Autowire) mais l’utilisation du XML reste nécessaire pour personnaliser plus finement les dépendances entre instances.
Dans le cas de Guice, au lieu de rédiger un XML, on créer une classe Module qui réalise le mapping entre une interface et la classe concrète à instancier/injecter.
On peut spécifier bien plus de chose que cela, mais je vous laisse lire l’article pour découvrir par vous même.

Pour ceux qui veulent suivre le débat “Spring vs Guice” ou “XML vs Code”, voici le point de vue de la documentation officielle de Guice.

En lisant un article d’introduction du langage FAN je trouve intéressant que ce dernier soit compatible .NET et Java.
En ce moment, .Net se voit enrichir de nombreux langages, aussi bien statiques (F# par exemple) que dynamiques (Iron Python). Les langages “standards” étant C#, VB.Net et C++/CLI.
Quand on développe sur la JVM, le langage “standard” reste Java. Mais cela ne veut pas dire qu’on a pas le choix : Scala, Jython, Groovy…

+  = FAN ?

Mais le petit nouveau, FAN, cible aussi bien la JVM que la CLR.Net. Certes, les 2 mondes possèdent des concepts similaires, mais aussi très différents et qui risque de ne pas être possible d’exposé dans ce langage.
Ceci dit, la plupart des concepts sont haut-niveaux, et peuvent donc générer un bytecode en utilisant des concepts plus simples et bas niveau, comme un foreach peut être écrit sous la forme d’un for…

En l’occurrence, FAN introduit un concept déjà existant en C# mais absent en Java : les Nullables.
C’est l’objet de cet article.

De nombreuses autres sucreries du langages C# sont introduites dans le JVM à l’aide de FAN comme les Closures. Je vous laisse découvrir tout ça sur la documentation officielle.
Je vous invites aussi à lire cet autre article d’introduction qui expose beaucoup d’avantages.

Pour ma part, j’adore :

• gestion des nullable
• valeur par défaut des arguments des méthodes (ce qui évite plein de surcharge inutile)
• property implicite à la C#, pour toujours moins de code à écrire
• closure en Java
• pas de ; superflux en fin de ligne
• l’équivalent du mot clé dynamic du C#4 avec object->variable !
• mot clé once qui évite de gérer manuellement le caching du résultat (genre : if(truc == null) truc = new Truc(); return truc;")
• l’écriture des listes/maps et l’écriture des instanciations “à la JSON”

A noter aussi une gestion de “package” propre au langage, et qui n’expose pas toute l’API Java (JDK). Je n’ai pas trouvé d’infos concernant .Net à ce sujet, mais ce langage se veut vraiment comme une union des 2 mondes.

En attendant un pluggin Eclipse ou un addin VisualStudio Shell, ils livrent un mini IDE fort sympathique.

Et vous? Qu’en pensez-vous?

Suite au post de Romain sur l’avenir du langage C#, je voulais non seulement répondre, mais en profiter pour parler brièvement d’un autre langage .Net : Oxygene.

C#4 ?

Romain a trouvé une citation un peu abusive mais qui m’est pourtant tout de suite venu à l’esprit concernant C#4 :

The dynamic keyword is going be abused so much… C# is on its way to becoming PHP.

Pour la petite histoire, je viens de passer 2 jours à coder du Javascript… coder?? Débuguer surtout!
Je ne sais pas si suis allergique aux langages dynamiques, mais ça me frustre au plus au point de ne pas savoir quel sont les membres que possède un objet, et de devoir le vérifier au Runtime…
J’ai passé 2h car j’ai fait une faute de frappe sur le nom d’un membre, ce qui ne plante pas, mais comme cela créer dynamiquement un nouveau membre avec ce nouveau nom, j’ai passé beaucoup de temps à comprendre pourquoi sa valeur était “null”.

C’est pour ça que les aspects “dynamiques” me font peur pour la maintenance des futures programmes C#4.
Ceci dit, le mot clé “var” existe déjà en C#3, et je n’ai pas vu quelqu’un en abuser (d’ailleurs, est-ce que la nouvelle version de Resharper suggère toujours de remplacer les types par des var ??!!).
Toujours pour diluer mes propos, il est vrai que dans la réalité on a besoin d’utiliser différents langages pour différents besoin, alors pourquoi ne pas tout réunir en un seul…
Mais j’aimerai éviter ça :

Parfois je me dit aussi que “C# is on its way to becoming C++“. Je n’ai pas beaucoup d’expérience en C++, et de ce fait j’ai parfois du mal à comprendre certains codes.
Mais j’ai surtout l’impression que les possibilités du langage sont tellement nombreuses, qu’on a pas 2 codes source C++ “dans la même prose”, ce qui devient vite difficile à lire. Pouvoir faire 1 chose de 10 manières différentes, n’est en mon sens pas un bon truc.

Mais en pratique, les nouvelles fonctionnalités de C# ne sont utilisées que par une “élite” qui a un besoin très précis. Dans mon travail actuel, les gens ne savent pas encore faire du Linq, et j’ai l’impression que je suis le seul a avoir VRAIMENT migrer sur C#3. Donc, avant que quelqu’un découvre les nouveautés de C#4 et en abuse….

Ah, si, il y en a 1… et c’est le genre de personne à faire une chose d’une certaine façon “juste parce que c’est possible”, si vous voyez ce que  je veux dire… et là, ça devient vraiment dangereux, et on fini par avoir du code incompréhensible car il a détourné une fonctionnalité de son but initial.

Je dois être vieux jeux, mais je préfère parfois la méthode “classique et lisible” même si elle est plus verbeuse. Pourtant, je me laisse séduire, et je deviens vite fan des méthodes d’extension et des expressions lambda. C’est comme si mes 2 personnalités entraient en conflit quand je me dit :

return toto??tata;
// ou
return toto!=null?toto:tata;
// ou
if(toto != null)
return toto;
else
return tata;

Il est clair que je préfère la première solution, mais on m’a défait fait la remarque :

euh, tu peux l’écrire avec le “if”, je trouve ça plus lisible.

Et oui, il faut aussi s’adapter au niveau de lecture de l’équipe.

Mais là, je ne parle que du langage C#, pas des possibilité de la VM ou du Framework. S’il est possible d’interagir entre .Net et Javascript, alors je suis aux anges, mais il existe sans doute d’autres moyens “peut être plus contraignant” que d’ajouter de la dynamicité dans le langage C#. (On génère bien des “stub” pour communiquer en COM !)

Mais au finale, je me laisse prendre au jeux, et finalement je suis fan des expressions lamdba, Linq, les méthodes d’extensions, juste parce que ça s’écrit plus rapidement et que je suis fainéant.

Oxygene ?

Parce que je suis bavard, je voulais en profiter pour parler non pas de C#, mais de Oxygene.

Un peu d’histoire : le créateur de Delphi a aussi été le créateur de C# : Anders Hejlsberg
Petit lien car ça ne fait pas de mal : Anders qui parle du future de C# (je sais, tout le monde l’a déjà vu).

J’ai commencer à coder en Delphi au Lycée (je ne compte pas les années Basic sous AsmstradCPC6128 ).
Delphi était magique à l’époque : langage Pascal Objet, IDE avec un puissant Designer pour application Windows, framework riche…

Puis le monde a évolué : Anders Hejlsberg a quitté Borland pour aller chez Microsoft.
A l’époque, Microsoft a voulu faire leur propre “Java” : J++.
Anders a commencer par travailler la dessus, mais Microsoft est entré en conflit avec Sun concernant ce J++, et c’est comme ça que .Net naquis.
Anders inventa alors C# pour l’occasion, et J++ fut porté sous .Net sous le nom de J#.

Les années noirs pour Borland ont commencé, les entreprises se tournant vers Microsoft et .Net.
Mais je suis resté à coder en Delphi 7 dans mon ancienne société, alors que .Net en était déjà à sa V2. Période de ma vie (en tant que codeur) très frustrante: pas de “foreach”, pas de “generics”, programmation par interface difficile, etc.

Pour Borland, ce fut de pire en pire : ils ont fini par migrer Delphi en .Net, et ont alors inclue le SDK de Microsoft .Net dans leur IDE… comme si Delphi en tant que langage était mort, et que “Delphi 2008″ ne servait surtout qu’à développer en C#. Sans compter les frameworks tel que VCL.Net en conflit avec ceux de .Net comme Winforms.

Je n’ai pas travaillé avec Delphi 2008, mais je l’ai un peu testé. Malgré de gros problème de performance, cet IDE était déjà 1000 fois mieux que VisualStudio : refactoring poussé, historique “à la svn” à chaque sauvegarde/innactivité d’un source, Designer plus sympa, etc.

Mais finalement, Borland a laissé son IDE à Codegear et la mort de Delphi semblait proche. C’est pour cela que mon ancienne société a choisi de passer de Delphi7 à VisualStudio/C#.

Puis, récemment en surfant, j’ai découvert Oxygene.

Et je me suis dit : “haha, la résurrection de Delphi?”
Ce langage est dérivé de Delphi (comme une nouvelle version en quelque sorte), possède toutes (?) les fonctionnalités du langage C#3 comme Linq, etc.
Mais il ajoute aussi son lot de nouveauté que j’adore :

• éviter les tests de nullité inutile :

if(truc.parent != null && truc.parent.parent != null)
toto = truc.parent.parent;
// devient
toto = truc:parent:parent;

• ne pas choisir entre un “for” et un “foreach” car on a besoin d’un compteur

Combien de fois ais-je du ajouter un compteur dans un foreach (et risqué d’oublier le ++) et au final me résigner à utiliser le bon vieux “for”. En Oxygene, le foreach peut gérer l’index :

for each u in Users index i do begin
// et on se sert de i

Maintenant, Oxygene fait du buzz sur le net… enfin surtout “Delphi Prism“.

Finalement, l’IDE de Codegear est abandonné, et Delphi Prism s’intègre à VisualStudio (utilisé comme une application Eclipse RCP).
On retrouve le langage Oxygene, mais aussi un certains nombre de framework pour pouvoir faire des applications multi-plateform à l’aide de Mono.
Et pour faire plaisir aux ex-Delphi-istes, le package inclue une API d’interoperabilité entre .Net et les applications pure Delphi Win32.
Pour plus d’infos : http://www.delphi.org/2008/10/delphi-prism/

Il ne me reste plus qu’à tester tout ça Est-ce que ça veut dire que je vais abandonné C# pour revenir flirter avec Delphi?

Pour ce qui ne sont pas au courant ou qui n’aurai pas vu la vidéo de la PDC, voici l’article d’InfoQ sur Mono.Simd.
J’aime bien le titre “Mono: Going Beyond the Standard”, et c’est de ça que je vais parler…

J’ai posé la question lors de la soirée ALT.Net en présence de Jean-Baptiste Evain, à savoir si on ne va pas se retrouver avec 2 standards : .Net et Mono.
ATTENTION, je ne parle pas des spécifications de la VM ou du langage C#, mais des assembly fournies en standard avec le SDK.

Pour comparer avec le monde Java, Sun établi des spécifications (JSR), et certifie une JDK car elle contient les “fonctionnalités” demandées. C’est indispensable pour le “Write once, Run anyware“.

Mais pour l’instant, Mono reste sur les traces de Microsoft, et il n’y a pas de volonté de standardisation commune, Microsoft faisant le standard de facto.

On dit même Mono être à la traine, car une application .Net ne marchera pas forcement sur Mono (à vérifier avec MoMA).
Mais on se rend déjà compte que seulement la 2ème mouture de Mono fournit son lot de nouveautés, et que l’inverse peut se produire (application Mono ne marchant pas « out of the box » sur la SDK de Microsoft).

• Que nous réserve la version 3 ?
• Mono va-t-il suivre un autre chemin (orienté jeux) ?
• Va-t-on assister à une compétition (positive) .NetDK vs MonoDK ?
• Pourra-t-on dire “je préfère l’implémentation de System.Collection.Generic.List de Mono, plutôt que celle de Microsoft” ?
• Les développeurs choisiront-ils la version Libre pour que leurs applications soit le plus compatible possible, et pour être multi-plateforme (comme développer des WebServices sans utiliser WCF n’existant pas encore sous Mono) ?
• Microsoft vont-ils intégrer le travail de Mono dans le .NetDK officiel ?

Un autre point : l’API de Linux est riche (oui oui!) et je trouve incroyable le nombre de binding Mono pour cette dernière :

• DBus : framework de communication inter-application orienté message
• GStreamer : framework multimedia
• Cairo : framework vectoriel 2D
• Telepathy : framework de chat (xmpp, sip, etc.)
• GTK : remplaçant des winforms ?
• etc.

Ils existent plusieurs applications Mono-Linux qui ne sont pas « portables » sous une autre plateforme, car trop liées aux API natives. Mais la communauté a la volonté de les faire porter sous Mac/Windows (Tomboy,  Banshee), et ça passe forcement par une migration de ces API natives.

Assiste-t-on à un Linux qui envahi notre Windows/Mac grâce à Mono ??

Cela fait du buzz en ce moment, Google sort son navigateur Google-Chrome, et pour l’illustrer l’annonce est faire sous forme de BD!!

Premièrement, j’adore la style “BD”, car comme on le dit : “un schéma vaut parfois mieux qu’un long discours”. Et on comprend tout de suite ce qu’ils veulent dire quand on voit la représentation “imagé”.

J’aime bien donner mon point de vue, et je vais surtout m’attarder sur l’aspect “interface utilisateur” et “Web vs Desktop”.
J’avais déjà lu de nombreux trucs sur la gestion des onglets dans les navigateurs, et en résumé on remarque que l’OS gère tellement mal les fenêtres, que l’on a inventé une nouvelle “barre de tâches” intégrée au navigateur (les onglets).
Certes, avec des gestionnaires de fenêtres tel que sous MacOS, avec Exposé, ou sous Linux, avec Compiz, il est facile de naviguer entre les fenêtres d’une même application sans avoir besoin d’onglet.
Quand on dit que le Web converge vers le Desktop, on s’aperçoit qu’un site n’est ni plus ni moins qu’une application. Cela est d’autant plus flagrant avec des sites comme GMail, ou Facebook. Personnellement, je les laisse toujours ouverts, et pour éviter de les fermer accidentellement, je les laisse dans une fenêtre séparée de ma navigation “temporaire”.
De mon point de vue, ça ne devrait pas être le rôle du navigateur de gérer des fenêtres (onglets), mais plutôt celui de l’OS.

“Mais il subsiste des onglets dans Google-Chrome!!??” me diriez-vous. En effet, je crois que c’est quelque chose qui fait partie des habitudes difficiles à perdre…
Mais un onglet est maintenant une entité bien distincte, et chaque onglet tourne maintenant dans un processus différent comme des applications différentes.
De plus, Google-Chrome propose aussi un mode “standalone” comme dans Google Prism, c’est à dire que l’application web (tel que Gmail) s’ouvre dans une fenêtre dédiée, sans barre de navigation etc… “nul besoin, je suis dans Gmail, et je reste dans Gmail. Les boutons de navigations du site me suffisent.“
J’en profite pour dire que j’adore leur façon de gérer les popups (la BD l’explique mieux que mes mots )

Dans la troisième partie, ils parlent des onglets qui incluent leurs propres boutons de navigation ainsi que leur propre barre d’adresse. Comme je l’ai dit, chaque onglet est une application à part entière avec sa propre interface, et les boutons de navigations/barre d’adresse en font partie.
Il est vrai que j’utilise rarement la boite de recherche, car finalement je tape un mot dans la barre d’adresse, ce qui lance “google j’ai de la chance”… Que les deux soient “fusionnés”, me semble naturel aussi. Google appelle ça “l’omnibox“.
Enfin, Google corrigent des bugs de “fonctionnalité” de Firefox, comme le fait d’aller sur le site “http://cnn.com” quand je tape “cnn“, et non la dernière page mémorisée dans l’historique, à savoir “http://cnn.com/2008/politics/07/27/campaign.wrap/index…..“

Je suis aussi fan de l’idée de la recherche/complétion à l’aide de la touche “tab” dans l’omnibox. C’est peut-être un peu geek, mais ça me rappelle la complétion en ligne de commande sous Linux/MacOS ou MsDos.

Google expliquent aussi les sources des problèmes concernant les ressources et le caractère “mono-threadé” d’un navigateur.
Qui n’a pas déjà pesté sur la lenteur d’affichage des pages, d’exécution du Javascript, du freeze du navigateur à cause d’une pub flash, ou des 380mo en mémoire pris par Firefox ???
Gérer les ressources, c’est normalement le rôle de l’OS. Et je le répète : un site web n’est ni plus ni moins qu’une application, elle devrait alors avoir son propre processus, avec sa propre gestion de ressource, sans empêcher la navigation dans les autres onglets.

Coté performance, on blame souvent Javascript….
Les applications web se rapprochant des applications Desktop, elles deviennent de plus en plus “dynamiques” et “user friendly”. Pour se faire, on utilise Javascript depuis bien longtemps. Mais ce n’est que depuis peu (Web 2.0) que le Javascript est exploité massivement. Et c’est la qu’on se rend compte de ses limites en terme de fonctionnalité et de performance.
Certains contournent le problème, en intégrant un “plugin” tel que Flash/Java/Silverlight, et réalisent leurs sites en partie/entièrement avec. Parfois, le navigateur ne sert plus qu’à lancer le player flash, qui lui gère entièrement l’interface graphique.
Je suis fan de Javascript car ça reste léger, non propriétaire, et cela s’intègre bien avec le HTML. Vous allez me dire que je suis vieux jeux, et qu’il faudrait tout migrer immédiatement vers du Silverlight mais ça c’est un autre débat.

Google est repartie de ZERO pour réaliser son moteur Javascript, chose qui m’étonne peu. Mais ce qui m’a en tout cas fait rire, c’est de lire qu’ils font carrément une machine virtuelle ! L’avenir est aux machines virtuelles, tel que Java et .Net, que ce soit par leur gestion de la mémoire, ou les optimisations de compilations. D’autres arguments sont cités dans la BD, et ils paraissent souvent évidents. Mais il n’y a qu’un géant comme Google qui peut dire “bon, les autres trucs c’est de la merde, on va tout refaire à zero en apprenant des erreurs du passé”. Mine de rien, c’est un challenge énorme, et on a tendance à préférer ré-utiliser un existant même s’il faut le faire évoluer.

A la fin, ils parlent aussi un peu de Google Gears. Pour moi, c’est comme si le navigateur était devenu une machine virtuelle pour héberger nos applications web, et Google Gears c’est le “framework”, qui offre la possibilité d’étendre leurs fonctionnalités à l’aide de “librairies” réutilisables. L’écart Web-Desktop se resserre encore…

Un petit mot sur la sécurité : le fait d’isoler les onglets dans des processus différents permet d’isoler les programmes “malveillant” des autres. Quand le processus est lui aussi découpé en plusieurs niveaux d’isolation, c’est encore mieux. Quelque chose m’a amusé concernant l’interaction entre l’utilisateur et la Sandbox : on dirait qu’il y a un pare-feu interne entre eux, et que seul l’utilisateur peux initier une “connexion” avec la sandbox, qui ne peux que lui répondre. L’explication en image est bien plus parlante -_-’

Je ne couvre pas tout, je vous laisse découvrir la BD par vous même.
Je suis sûr que ce navigateur va changer beaucoup de chose dans nos façons de développer des applications Web, et dans notre façon de surfer.