Une conférence. Alt.Net. Paris.

La conférence, c’est le cadre, la forme.
Alt.net, c’est le contexte, le fond, l’esprit.
Paris, c’est le lieu.

C’est trois choses là n’ont aujourd’hui rien à faire ensembles. Néanmoins, je dois vous avouer que cela fait bien longtemps que l’utilité d’un tel évènement me parait une évidence.

J’aime communiquer, écrire, partager, voire des gens, discuter et une conférence est certainement l’un des moments les plus propices à tout ça. J’aimerai qu’on puisse organiser une conférence à laquelle ont aimerai tous aller et se faire plaisir. Avec du web, du .NET dedans, des bonnes pratiques et plein d’autres choses! C’est d’ailleurs, exactement ce que sont en train d’organiser les copains développeurs Java avec le Devoxx francepour 2012. Et vous savez quoi? Ce n’est pas parce que je suis un dev .NET que je n’irais pas! Ca a l’air très sympa, j’irais très certainement et je vous invite franchement à y jeter un oeil.

Mais avant tout ça, pour voir comment mettre tout ça en place, nous avons préparé un petit formulaire avec quelques questions. Je vous invite donc à prendre 5 minutes – pas plus promis – pour remplir ce questionnaire et 30 secondes de plus pour le partager avec vos amis afin que l’on aie un maximum d’avis!

Vous pouvez retrouver aussi avec des notes un peu moins personnes sur le blog d’Alt.Net paris ici et n’oubliez pas aussi notre prochaine présentation Alt.Net paris sur GIT le 14 décembre, il reste encore quelques places.

Si le formulaire ci-dessous ne s’affichait pas correctement vous pouvez accéder directement à la page du questionnaire.

Merci et bon questionnaire!

Les sessions se suivent et ne se ressemblent pas et c’est ça qui est bon!

La dernière session sur Roselyn de Jean Baptiste Evain s’est super bien passée et je tiens encore à remercier tous les participants, Jean-baptiste et surtout a Mick de chez Octo pour tout ce dont il s’est occupé!

En essayant de rester dans cette bonne dynamique de fin d’année, voici venir une nouvelle présentation Alt.Net d’ici 15 jours.

Le sujet sera GIT et la session sera présentée par Sébastien Douche (twitter @sdouche). Sébastien est le fondateur du site GitFR, spécialiste du sujet et bien sur speaker. C’est un vrai plaisir de l’accueillir sur ce sujet car les vrais spécialistes sont rares et nous sommes beaucoup trop à utiliser mal l’outil ou tout du moins de manière très parcellaire…Et puis il y en a beaucoup qui ne l’utilisent pas aussi, surtout dans un environnement Microsoft où les solutions maison sont en général préférées.

Bref, cette session est l’occasion d’approfondir un sujet très intéressant puisque le sujet fait partie des choses les plus importantes pour nous développeurs au quotidien!

Pour le détail, je vous laisse ci-dessous l’intro de la session:

Utilisateur de SVN pendant de nombreuses années, j’avais la sensation croissante de me battre avec mon outil de travail. Pire, il s’adaptait très mal à mes exigences collaboratives. De guerre las, nous en avons choisi un outil de gestion de source décentralisé (Hg puis Git) début 2008. La différence était flagrante, je me sentais comme libéré d’un poids qui me ralentissait, et la production de l’équipe s’est fortement améliorée (quantitativement et qualitativement).

Cette soirée vous donnera la compréhension nécessaire pour aborder sereinement l’utilisation de Git (et aux DVCS en général) : La première partie sera consacrée à la théorie, en passant en revue tous les concepts nécessaires avec l’aide de nombreux schémas didactiques. Nous mettrons en pratique nos nouvelles connaissances dans la seconde partie, en abordant les commandes qui font la «différence», les workflows, l’utilisation de GitHub, le tout saupoudré de conseils pour bien démarrer. Nous aborderons également mais succinctement la philosophie Devops avec un retour d’expérience dans mon entreprise.

La session se passera chez Valtech qui nous a très gentiment fourni une très grande salle, donc malgré la diffusion de l’annonce sur notre liste alt.net depuis 2 jours, il reste encore pas mal de places, profitez-en! De plus cette session sera suivie d’une autre début janvier pour la mise en pratique sous forme d’atelier (avec priorité à ceux qui sont venus à cette première session).

Pour les inscriptions c’est par ici:

http://www.eventbrite.com/event/2421871884

Nous sommes en train d’essayer de re-dynamiser le groupe en ce moment, et il y a pas mal de choses en préparation, donc n’hésitez pas à nous contacter pour proposer des choses! Il y a beaucoup de manières différentes d’échanger, vous n’avez pas besoin d’être un expert mondialement reconnu pour venir présenter quelque chose! Cela peut être plusieurs courtes présentations, des discussions, des retours d’expériences, bref, c’est ouvert et on est là pour le partager ensembles! Contactez moi directement si vous avez un doute ou que vous ne voulez pas poser une question à toute la liste, n’hésitez pas

Learn it, share it!

Kickstarter

Kickstarter porte de nombreux projets très intéressants et c’est d’ailleurs une superbe manière de se faire aider sur un projet sans passer par des traditionnels investisseurs qui ne s’intéressent pas toujours au bien fondé du contenu.

Parmis les derniers en date un projet du bien nommé Grady Booch qui fait partie des légendes de notre petit univers informatique. Ce projet se nomme “Computing the human experience”.

Pourquoi ce projet est sympatique?

Tout d’abord parce qu’il est porté par une personnalité importante et reconnue pour la qualité de son travail. Cela n’engage pas toujours à la réussite absolue mais c’est déja en soit un bon gage pour s’attendre à quelque chose de bon.

Parce qu’il s’agit d’une histoire que l’on va nous raconter en profitant des différents supports qui s’offrent à nous (transmedia powered), cette histoire c’est aussi celle de l’humanité qui a cherché depuis longtemps l’appui des machines. Et puis moi j’aime bien les histoires…

Parce que c’est aussi un travail d’archive et qu’il faut participer à cette construction.

Parce que beaucoup avec peu fait beaucoup au final et que ce n’est pas le genre de projet qui sera financé par des capitaux traditionnels de toute façon.

So, What’s up?

La page du projet est ici:

http://www.kickstarter.com/projects/1747241049/computing-a-documentary-of-the-human-experience

Et bien sur je vous encourage a jeter un oeil à ce type de sites car beaucoup de jeunes projets sympa y voient le jour!

Les conférences sont de formidables occasions d’apprendre de nouvelles choses et les occasions ne sont pas si nombreuses que ça! On en a déjà parlé ici mais les conférences sont l’occasion de rencontrer des gens, de discuter et poser des questions à des experts, de s’informer sur des technos en vrai et avec du temps dédié à ça (le concept de je verrais le screencast j’en ai plein les tiroirs de non visionnées…).

Je reviens donc sur les journées Sql Serveur organisée par le GUSS qui auront lieu chez Microsoft les 12 et 13 décembre. C’est le premier PASS Sql Rally francophone et ça c’est une super news! Malgré son nom, Les journées Sql Serveur, qui est peut être marketingment plus parlant au plus grand nombre, n’en est pas moins porté par l’organe officiel en france de l’association de pro du Sql Server.

Pour avoir déjà assisté à ce type d’évènements à l’étranger, c’est vraiment quelque chose de très sympa que d’avoir des journées entières consacrées à la techno. Les conférences comme les techdays sont trop généralistes et sont plus l’occasion de présenter des produits ou de découvrir rapidement une techno. Là, vous avez 2 jours sur Sql Serveur avec toutes les briques prises en compte.

Il y a de plus des speakers parmis les meilleurs en france sur le sujet de la data et vous aurez rarement l’occasion de voir tout ce petit réuni: http://www.guss.fr/accueil/les-journées-sql-server/speakers.aspx

Pour le détail du programme, c’est ici: http://www.guss.fr/accueil/les-journées-sql-server/agenda.aspx

et pour l’inscription c’est ici: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032496260&Culture=fr-FR

C’est en tout cas une super initiative et j’espère qu’elle sera reconduite les années prochaines!

Je serai là bas les deux jours, donc n’hésitez pas à me faire signe, j’essaierai de vous faire un débrief des sessions auxquelles je vais assister.

Bonne conférence!

Pourquoi tu push?

Comme je l’ai dit dans mon précédent post, je suis très attaché à cette notion de plateforme de développement web intégrée et au fait de pouvoir concevoir aujourd’hui des applications complètes sur une base de html. Parmis les points essentiels de cette manière de concevoir les choses, il y a la notion de temps réel. Cette notion est toute relative et subjective du point de vue utilisateur.

Par exemple, on considère habituellement que toute action de moins de 100ms peut être considérée comme instantanée d’un point de vue de l’interface utilisateur, ou encore que la seconde est la limite acceptable dans une application pour que l’utilisateur ait cette sensation de fluidité qui fait qu’une application est agréable à utiliser.

Dans les applications web, la communication a été globalement depuis le début à sens unique.

Le client effectue une requête > le serveur y répond > la communication est coupée.

Depuis quelques années maintenant, l’évolution de la technologie aidant ainsi que l’expérience que l’on a des applications web, nous avons eut l’envie et le besoin de pousser de l’information depuis le serveur vers le client. Des technologies et spécialistes sont arrivés sur ce segment, avec notamment Comet qui désigne globalement aujourd’hui la notion de push ajax. Néanmoins, les implémentations aussi diverses que variées ne sont pas toujours pratiques, les solutions custom pas forcément évidentes et surtout, elles fonctionnent en général très bien sur unix et pas sous Windows.

Et sur Asp.Net?

Comme je l’ai déjà mentionné, c’est certainement cette fonctionnalité qui a attiré en premier les développeurs sur la plateforme Node.js. Après avoir joué pas mal de temps avec, je me suis rendu que l’on avait au final souvent sous-estimé ce paradigme fonctionnel et appliqué une mauvaise implémentation. J’ai trouvé le fonctionnement et l’apport au sein d’une application vraiment top, mais qu’en est-il en Asp.Net?

J’ai par le passé, déjà implémenté cette pseudo notion de push temps réel dans des applications web mais toujours au travers d’un classique polling ajax (qui s’avère suffisamment efficace la plupart du temps). Néanmoins qu’est-ce qui nous empêche d’avoir de longues connexions persistantes et de faire du long polling ou du streaming en Asp.net?

Pas grand chose en fait, à par peut être une mauvaise interprétation des problématiques.

Faire du long polling et avoir donc quelque chose sur le serveur qui attend pour rien fait peur en général et ont se dit que l’on va rapidement atteindre les limites du raisonnable. D’où le simple polling ajax.

Il répond au même paradigme que les connexions aux bases données:

use it late, release it fast

Donc, en théorie je m’en sors mieux si je fais plein de petite requêtes que une seule longue…Oui, mais ce n’est pas fondamentalement comme cela que cela se passe.

Déjà, il faut voir l’ajout de traffic réseau, un echange de messages toutes les secondes (en partant sur un polling raisonnable à la seconde) n’a pas le même coût qu’un ping de présence toutes les 30 secondes.

Ensuite, il y a les problématiques liées en elles-même à ce choix d’infrastructure applicative. Même si votre polling effectue de requêtes approchées dans le temps, à la seconde, les évents sur le serveur sont eux instantanés! Ce qui implique donc de gérer des buffers, des timestamp qui vont vous permettre de stocker temporairement  les derniers événements et savoir quoi renvoyer à chaque requête utilisateur, ce qui n’est pas forcément trivial à intégrer.

Enfin il faut aussi comprendre le cycle de vie des requêtes http sur IIS et Asp.net. Nous avons à notre disposition depuis .net 2, des handler http asynchrones qui permettent justement un découplage entre les requêtes et les traitements. Je ne vais pas rentrer dans les détails, ce n’est pas le sujet ici et je ne suis pas non plus le mieux qualifié pour en parler, mais lors qu’une requête sur le serveur, celle-ci est prise en compte par un thread de communication. Il y a un pool commun de thread de communication et leur nombre est assez limité. Le traitement peut être réalisé directement de manière synchrone par celui-ci mais peut aussi, dans le cas d’un handler asynchrone, être délégué à un thread de traitement, rendant par la même occasion le thread de communication à nouveau disponible pour servir de nouvelles requêtes.

Cette manière de faire colle donc parfaitement de manière performante avec la notion de long polling!

1. J’envoie une requête ajax sur le serveur
2. un thread de communication prend en charge cette requete
3. il la transfère à un thread de traitement
4. le thread de communication est à nouveau immédiatement disponible pour servir d’autres clients
5. le thread de traitement se met en attente d’un signal (une action ou un timer)
6. quand il a fini il reprend un thread de communication dans le pool et lui donne la main
7. le thread de communication répond au client
8. celui-ci reçoit la réponse, la traite et renvoie à nouveau immédiatement une nouvelle requête au serveur.

Au final, toutes les techniques nécessaires à faire cela sont belles et bien disponibles depuis longtemps, c’est vraiment plus une question de pratiques et d’expériences qui fait que l’on s’y penche un peu plus aujourd’hui.

Ok, let’s do it!

Le principe de base est d’avoir un bus d’événements qui va recevoir les notifications et les repousser vers ses abonnés. Lorsque le handler asynchrone reçoit une requête il donne la main à un traitement annexe et repasse dans le thread pool de connexion. Ce traitement commence par s’abonner au bus d’événements puis s’abonne à un autre événement de type timer. Le premier des deux qui envoie un signal, provoque la poursuite de la séquence et génère la réponse, la main est ensuite rendue au thread de réponse.

J’ai regardé plusieurs types d’implémentations, principalement en passant par les nouvelles classes Task<> ou encore en passant par le framework Reactive Extensions. En parallèle, mon ami Zied a lui voulu faire un test simple sans aucun autre framework avec le bon vieux pattern utilisant le IAsyncResult. Sachant que l’intérêt principal était de faire un test basique et simple, je suis revenu moi aussi vers cette méthode en partant de sa solution. Comme, je voulais un exemple utilisable de bout en bout, j’ai démarré la construction d’un petit framework permettant de faire simplement du long polling.

Vous trouverez donc dans ce framework une manière de faire du long polling. Je n’ai pas la prétention de dire que c’est la meilleure, mais elle fonctionne. J’ai ajouté aussi tout une couche d’infrastructure de manière à rendre cela simple d’utilisation. Vous avez a votre disposition des bus d’événements (que vous mettez en place déclarativement par type et nom), puis des helpers pour accéder à aux send/push simplement. Je vais continuer à travailler sur ce petit framework car je pense qu’il y a un besoin d’avoir quelque chose de simple à comprendre et à mettre en place. Ceci étant, si vous voulez quelque chose d’un peu plus mature aujourd’hui, je vous invite vraiment à utiliser SignalR qui est vraiment très bien (et à regarder le source aussi).

Welcome to Mediator framwork

Ceci est un framwork permettant donc d’envoyer des messages par push dans une page web en asp.net. Les messages sont transportés par une enveloppe contenant un timestamp et l’objet du message en lui-même. Les bus de messages sont identifiées par un type (d’objet) et un nom. La création de ces bus se fait par configuration au démarrage de l’application. Un buffer est aussi intégré pour garder en mémoire les X derniers messages pour chaque bus (afin par exemple de les afficher au moment du chargement d’une page). Coté client, il n’y a rien de particulier, définissez vos requêtes ajax comme d’habitude, partez de l’exemple si vous avez des doutes.

NOTE :

Pour ceux qui n’ont pas la patience d’aller plus loin, vous pouvez aller directement à la page github du projet:

https://github.com/rhwy/Mediator

1. Configuration

1) Importez la librairie Mediator.dll dans votre projet/site

2) Adaptez votre web.config si besoin. Par défaut tous les modules managés sont chargés (ce qui sera donc le cas du notre):

<modules runAllManagedModulesForAllRequests="true"/> 

3) Définissez la route pour l’envoi des messages:

routes.Add(
   "mediator",
   new Route(
      "mediator/{type}/{name}",
      new RouteValueDictionary(new { type = "string", name = "default" }),
      new EventBusRouteHandler()));

Pour l’intant, ce handler ne prend en charge que la propagation des messages aux abonnés, l’envoi des messages se faisant à votre convenance (pour moi préférablement dans un contrôler dédié, voir ci-dessous)

2. Server code

Dans notre exemple nous partirons donc sur un controller dédié dont on pourra par exemple déclarer la route comme ceci:

//Message send
routes.MapRoute(
   "Send",
   "MediatorNotifier/{action}",
   new { controller = "MediatorNotifier", action = "Index" } );

C’est la manière la plus simple de centraliser les éléments liés à la notification temps réel dans votre application si il n’y a pas beaucoup de types de messages différents (ce qui est vrai dans la plupart des cas). Si jamais vous aviez une architecture plus conséquente, il vaut mieux ajouter ces actions spécifiques à chaque controller avec un regroupement plutôt fonctionnel.

Pour ce qui est de l’action en charge de la notification, cela peut facilement être réalisé comme dans l’exemple ci-dessous:

[HttpPost]
public ActionResult NotifyChatMessage(string name, ChatMessage message)
{
   MediatorBus.Send<ChatMessage>(this, message);
   return Json(new { saved = "ok" });
}

L’intéret initial de passer par une action de controller standard au lieu d’intégrer la notification dans le framework avec la distribution des messages  est juste de pouvoir simplement profiter du DefaultModelBinder des actions d’Asp.Net Mvc…On peut donc passer en ajax des objets complexes et fortement typés, et les passer simplement au bus grâce à notre helper MediatorBus.

Le framework embarque aussi une petite mécanique pour avoir une sorte de tampon des derniers messages (pour chaque bus) afin de pouvoir imprimer simplement ce qui est en cours. Ceci est particulièrement utile lors du chargement d’une page pour afficher ce qu’il y a en cours. Il est évident que dans une application ayant un minimum de fonctionnalités, vous auriez tout intérêt à gérer vous même cette fonctionnalité avec une gestion propre et personnelle des évènements et de la persistance. Néanmoins, la mécanique en place vous permet d’avoir une solution simple de suite.

Pour utiliser cette mécanique, j’aurais tendance à passer par une action partielle (souvent les besoins de remontée d’infos de push dans une page, sont plutôt liées à l’application en elle-même et pas à une page en particulier, utiliser cette méthode en simplifie le découplage):

[ChildActionOnly]
public ActionResult BufferOfChatMessage()
{
   ViewBag.Message = "Welcome to long polling demo!";
   var messageBuffer = MediatorBus.BufferOf<ChatMessage>();
   return PartialView(messageBuffer);
}

Puis pour l’appeler dans la vue parente:

   <h2>Simple message exchange</h2>
   <p>
      @Html.Action("BufferOfChatMessage","MediatorNotifier")
   </p>

Voici un exemple de vue allant de pair avec ce modèle:

@model IEnumerable
@{
   Layout = null;
   var messages = Model.Cast<MessageOf<ChatMessage>>();
}
<ul id="messages">
@foreach (var item in messages) {
   <li>@item.MessageItem.User : @item.MessageItem.Message</li>
}
</ul>

3. Code client

Pour envoyer les notifications, il n’y a rien de particulier, c’est au choix de chacun. Pour la partie abonnement, voici un exemple de fonction javascript simple, utilisant jQuery:

function getMessages() {
   $.post("/mediator/string", null, function (data, s) {
      if (data.MessageItem != "" && data.MessageItem != undefined) {
         var $msg = $('<li/>');
         $msg.html(data.MessageItem);
         $msg.prependTo('#messages');
      } else {
         console.log(data.TimeStamp);
      } 

      setTimeout(function () { getMessages(); }, 10000);
   });
}

C’est une fonction récursive qui se rappelle elle-même au moment ou elle a fini.

4. Aller plus loin

Ce petit framework a principalement été initié pour montrer la mise en place du long polling en asp.net sans librairie externe autre. Il n’a pas la prétention de garantir un niveau de qualité de code pour des applications d’entreprise mais peu néanmoins assez sereinement être utilisé en production.

Je vous invite donc à aller voir la page github du projet pour récupérer les soures:

https://github.com/rhwy/Mediator

Je mettrai ça sur auget dès que possible!

Faites moi part de vos retours, forkez le code, remontez vos patches et suggestions! Faites des commentaires, tout cela est plus que bienvenu!

Learn, share, enjoy!

Bon push!

Posons nous quelques instants pour regarder un peu ce qui se passe dans les grandes lignes du web en ce moment,  en dehors des phénomènes de communication sur des mots dont on a perdu le sens ou et en sortant d’un cadre purement technique.

Une chose est très claire pour moi aujourd’hui. Nous avons eut la vague web 2.0, qui même si elle à été plus un buzzword qu’autre chose, nous a apporté des sites à l’ergonomie plus sympathique, au design plus agréable et surtout un niveau de socialisation qu’il n’y avait pas avant. Bien. On parle souvent du prochain Web 3.0 comme étant l’âge de l’internet sémantique et de l’internet des choses. Bien aussi. C’est très important et c’est certainement la tendance pour un futur plus ou moins proche, mais on est loin d’en être là aussi bien techniquement, que dans l’approche projet ou business.

Cela fait aussi pas loin de 2 ans que je me bats contre les petits copains qui font du Flash et du Silverlight sur le bien fondé du Html5 (c’est pour être gentil, car en général les discussions étaient plus houleuses que ça . Je pense qu’avec le temps (et une poussée massive de Microsoft vers le Html5 qui prend bien train en marche finalement), ils seront de plus en plus à venir se ranger de mon coté, et, je vais en profiter pour revenir un peu dessus aussi.

Entre les deux n’y a-t-il donc rien? Est-ce que le web d’aujourd’hui (toujours 2.0 donc) est-il le même que celui de 2004 quand ces évolutions ont commencé à prendre forme dans les médias? En fait il y a pas mal de choses qui se trament en ce moment si on y regarde de plus près. La démocratisation plus que l’arrivée d’Html5 commence à porter ses fruits. Pour la première fois, réellement, avec Html5, nous avons à notre disposition une plateforme (html) qui est réellement prévue pour concevoir des applications multimédias et connectées! On a l’impression que cela ne change pas grand chose, que html4+javascript+css2 ne font pas moins, mais si, la différence est primordiale!

Remontons de 20 ou 30 ans. A cette époque les interfaces graphiques étaient en mode texte (pour faire simple). Une console qui affiche du texte, n’est pas du tout la même chose qu’une interface graphique qui affiche du texte (ou même une console à l’intérieur d’une interface graphique qui affiche du texte).

Dans ces interfaces texte, la gestion de l’affichage et de la console étaient très basiques et très simplement gérées en mémoire. En gros 1 caractère = 1 octet en mémoire pour l’affichage et on le place dans la cellule où se trouve le curseur. Les interfaces graphiques en mode texte, telles que ce bon vieux Norton Commander, ne sont qu’une extrapolation de cette affichage texte avec beaucoup d’artifices pour avoir un semblant d’ergonomie et d’amélioration de l’expérience utilisateur (ou pas suivant les avis…). Avec cette interface graphique quasi séquentielle (prompt), l’interaction utilisateur aussi s’en ressent, on a de quoi interagir pour une action à la fois.

Ca c’est le html 1 à 4.  Le html est initialement un standard servant échanger simplement des documents textes au travers de liens hypertexte. On a une plateforme pour présenter des documents, point. Ce que l’on en fait aujourd’hui c’est du bricolage, cela peut être du beau bricolage certes, mais si vous faites autre chose que présenter de l’information avec cette plateforme c’est du bricolage (arg, moi même je me choque en écrivant cela …)

Puis sont apparues les interfaces de MacOs, Windows 3 et autres (Zappons qui a l’antériorité de quoi et l’échelle de temps, hein?). Là on décide point par point comment va s’afficher une lettre. Ceci va nous permettre d’utiliser des polices aussi différentes que l’on veut mais aussi les tailles que l’on veut. Mais on va pouvoir aussi dessiner des choses à l’écran.

Quand je parle de dessiner je ne parle pas de programmes de type Paint mais bien du fait que l’on peut par exemple avoir cette notion de fenêtres graphiques qui nous est chère! On va aussi pouvoir simplement gérer 2 taches et affichages en même temps (une fenêtre en avant plan que j’utilise et une autre en background qui fait autre chose). On va pouvoir aussi avoir des notifications sur le bureau (l’heure qui s’affiche dans une barre des taches c’est déjà une notification sur le bureau…).

Puis avec le temps, on s’est dits qu’il fallait ajouter un peu d’interactivité et est apparu le javascript (non, non, va t’en vilain applet java). Puis on s’est dits qu’avoir des feuilles de style ce serait pas mal aussi pour définir un peu plus finement comment les choses devaient s’afficher à l’écran.

C’est un peu tout ça que nous ont apportés dans un premier temps les interfaces riches des applets java/activeX (même combat), puis de Flash puis enfin Silverlight. Néanmoins ces ajouts ne sont pas natifs au sein du document original. Pour repartir sur mon analogie avec la console, c’est un peu comme à l’époque du Dos, vous lanciez un beau jeu tout graphique mais qui reposait sur ses propres librairies d’affichage, sans profiter des accélérations ou facilités du système, et à la fin duquel vous retourniez quoi qu’il arrive à votre bonne vieille ligne de commande.

C’est là l’intéret de l’Html5, il s’agit d’une plateforme prévue pour!

Nous avons du dessin bitmap (canvas), du svg (dessin vectoriel), les websockets (communication full duplex bas niveau possible donc), du LocalDB et autres (données structurées en local), des webworkers (va y, fait péter ton thread en tâche de fond), etc…bref, de quoi penser des vrais applications.

Mais Html5, ce n’est pas que ça, c’est aussi, et surtout pour moi, l’apport de la sémantique dans le balisage de l’information.

Elle se situe à deux niveaux:

• Les balises de présentation structurantes (section, navigation, article,…)
• Les micro-data

Mais l’utilisation massive de tout ça va prendre un peu temps et on rangera ça plutôt dans la catégorie Web 3.0

Aujourd’hui nous sommes donc dans une phase d’appropriation d’une plateforme pour le web. Je parle d’appropriation car les changements prennent du temps, la nouvelle manière des applications prend du temps aussi, l’utilisation en masse des nouveaux navigateurs prend du temps aussi. Mais c’est en marche! Ne croyez pas que tout ceux qui font du Html5 le font pour suivre une mode (pas que)! Mais ne faites pas non plus l’erreur de faire du Html5 pour suivre la mode alors que la seule modification de votre application à été de changer la balise html de votre document…

On voit d’ailleurs que beaucoup de librairies javascript commencent à prendre en compte ces nouveautés avec une rétro-compatibilité des anciens navigateurs au détriment éventuellement de certaines fonctionnalités. De même, on voit bien aujourd’hui que les notions de push dans les applications web ne sont pas uniquement accessibles au html5 et websockets, cela s’implémente très bien avec du long polling ou du streaming par exemple. Des librairies comme Socket.io illustrent très bien cet exemple avec des compatibilités ascendantes et des implémentations différentes suivant les clients.

Je mettrais aussi en avant l’apparition et l’utilisation de plus en plus courante de frameworks MVC coté client (knockout.js, backbone.js, javascriptMvc…). Cela est significatif de la prise en compte d’un réel modèle de développement orienté application au sein de pages web. Ces dernières servant principalement de support d’échange.

C’est pour toutes ces raisons aussi qu’il faut regarder et comprendre une plateforme comme Node.js.

En dehors de tout le buzz qu’il a pu y avoir autour de cette plateforme, c’est certainement celle qui incarne aujourd’hui le mieux les changements en cours.

Pourquoi les gens sont arrivés tout d’abord sur Node.js? Parce qu’il y avait enfin la promesse de faire du push web de manière simple et performante!

Pourquoi les gens continuent de l’utiliser et pourquoi il y a de plus en plus d’adeptes? Parce que la solution est simple, elle est globalement performante, elle permet de coder simplement avec le même langage coté serveur et coté client.

Enfin, elle utilise parfaitement un paradigme dont les gens commencent seulement à prendre réellement conscience aujourd’hui qui est le SRP appliqué aux applications : mieux vaut utiliser plein de petites librairies qui font bien une chose, que plusieurs grosses dont on ne se sert pas complètement ou qui se recoupent…C’est aussi une plateforme très dynamique et les applications comme les frameworks vivent de l’usage que les gens en font, c’est donc important…

Nous ne sommes donc pas encore au web 3, mais on ne pas non plus dire qu’il n’y a pas d’évolutions depuis les débuts du web 2…Nous sommes donc pour moi, dans une phase de Web 2.5 correspondant à la mise en place d’applications web structurées et temps réel. Une fois ça en place et avec l’adoption massive des sémantiques issues de Html5 nous serons en bonne voie pour la prochaine génération du web.

Bon Web 2.5 et n’hésitez pas à laisser vos commentaires et votre vision des choses!

Toute l’équipe Alt.Net Paris essaie de se re-dynamiser en ce moment pour organiser plus de présentation ou même simplement des réunions pour discuter. N’hésitez pas à nous contacter si vous voulez parler ou présenter quelque chose, si il y a des sujets que vous voudriez que l’on aborde, etc…

C’est dans ce cadre là que Jean-Baptiste Evain est venu nous proposer une présentation de Roslyn, le futur compilateur as a service de Microsoft. Fraichement sorti de l’équipe mono chez Novell et créateur de SyntaxTree, JB est surtout connu par la création de Mono.Cecil, le décompilateur utilisé par tout le monde. Il est certainement l’un des plus indiqués pour nous présenter cette nouvelle plateforme.

vous trouverez tous les détails de la présentation sur le site d’Alt.Net:

http://www.altnetfr.org/2011/11/07/alt-net-presentation-de-roslyn-par-jean-baptiste-evain/

La présentation aura lieu mardi 29 Novembre 2011 chez Cellenza/Xebia. Attention la salle n’est pas très grande et les places sont très limitées! il ne doit pas rester plus de 15 places à l’heure qu’il est donc dépéchez vous!

Update 10/11/2011: 

Au vu de l’affluence, nous avons décidé de migrer pour une salle plus grande chez Octo. Merci à eux et merci encore à Cellenza pour leur accueil initial!

Voici la nouvelle adresse:

bonne pres!

Après Steve Jobs le 6, ce mois d’octobre est aussi marqué par la disparition d’un autre grand homme de l’informatique. Même si il n’a pas marqué les esprits du grand public comme l’a fait le fondateur d’Apple, Dennis Ritchie n’en est pas moins aussi important pour l’informatique. C’est l’un des pionniers de l’informatique moderne au début des années 70 au sein de ce formidable laboratoire de développement qu’étaient les Bell Labs. Il a créé le C et est l’un des piliers d’Unix, sans compter ses nombreuses contributions.

Dennis MacAlistair Ritchie (9 septembre 1941 - 8 ou 9 octobre 2011¹)

Node.js a beaucoup de bons cotés mais aussi beaucoup de mauvais. Le principal reproche quand on vient du monde .Net est sans doute le manque d’outillage et de support. Ce qui nous amène parfois a perdre du temps avec des choses qui ne sont pas réellement des problèmes mais pour lesquelles on manque juste d’information.

J’ai voulu récemment accéder à un service REST en https avec Node.js. On regarde quelques exemples, on adapte son code et quand on pense que tout est bien on se prend une erreur non explicite. Le pb est ici que tout le code est correct, sauf qu’il faut utiliser la librairie https au lieu de la librairie http.

C’est logique me direz-vous? Si on veut oui, sauf que d’habitude on importe un framework qui fait du http au sens large et qui possède des options pour utiliser le protocole de manière sécurisée ou pas, via un proxy ou pas, etc…

Pour illustrer mon propos, voici comment utiliser un service rest https fourni par Google pour la réduction d’url que nous allons invoquer via un script en ligne de commande pour la démo:

var querystring = require('querystring');
var https = require('https');

//sample data:
var g_data = JSON.stringify({
  "longUrl": "http://www.artofnet.com"
});

//définition de notre configuration de services
var googleApisConfig = {
    Host : 'www.googleapis.com',
    Key : '!!! votre clé api google a changer sous peine d erreur !!!',
    Services : {
	Url : '/urlshortener/v1/url?pp=1&key='
    }
}

//définition de nos options d'appel:
var post_options = {
      host: googleApisConfig.Host,
      port: '443',
      path: googleApisConfig.Services.Url+googleApisConfig.Key,
      method: 'POST',
      headers: {
           'Content-Type': 'application/json'
           ,'X-JavaScript-User-Agent':'node.js'
	   ,'Connection':'close'
      }
  };
//définition de l'appel
var req = https.request(post_options, function(res){
    if(res.statusCode === 200)
		{
			res.setEncoding('utf-8');
			var data = {};
			res.on('data',function(chunk){
				data = eval('(' + chunk + ')');
				console.log("Shortened URL => " + data.id);
			});
		} else {
        console.log("bad status code: " + res.statusCode);
    }
});

req.on('error',function(e){
   console.log(e);
});

req.write(g_data);
req.end();

Soit à l’exécution:

>> node test-url-shrink-https.js
Shortened URL => http://goo.gl/OlL2z

Donc voila, rien de particulier, on voit que les appels se font de la même manière qu’une requête classique. Note: Ceci est un exemple extrait et simplifié pour un test one-shot en ligne de commande, ce n’est pas à utiliser tel quel.

Et encore une fois, on voit bien là toute la puissance du système mais aussi ses pièges. Node.js est une belle plateforme mais attention à ce qu’elle ne devienne pas un php v2 10 ans après.

Si il y a bien un truc dont je ne me souvienne jamais correctement au niveau de la syntaxe en .net, c’est la manipulation des streams. C’est dommage car c’est plutôt bien fournit et bien fait mais malheureusement mal pensé en termes de design d’api. Du coup, c’est très peu intuitif.

Je ne sais pas pour vous mais moi j’ai souvent un string sous la main quand une interface que je veux utiliser ne prend que des streams en entrée et vice-versa.

Donc pour faire très simple si on vous demande un Stream:

string initial_string = "toto";
byte[] bytes = Encoding.ASCII.GetBytes(initial_string);
Stream result = new MemoryStream(bytes);

De même si on vous fourni un stream que vous voulez consommer tout de suite en mémoire sous forme de string:

Stream s = File.OpenRead("monfichier");
StreamReader sr = new StreamReader(s);
string result = sr.ReadToEnd();

 
Avec ça comme base bien en tête, on peut à peu près tout faire