C'est devenu ridicule!

Je crois que c'est maintenant un running gag: Je ne tiens pas mon blogue à jour!

Je n'ai simplement pas le temps ni suffisamment d'intérêt pour le faire. C'est pourquoi j'ai décidé de le fermer.

Qu'est-ce que ça veut dire? C'est bien simple: pas grand chose. Je vais retirer le lien vers le blogue de ma page personnelle. Le blogue va rester en ligne mais il ne sera plus mis à jour (Ha ha!). C'est tout.

Vous pouvez donc enlever le blogue de vos agrégateurs. Si vous désirez rester en contact avec moi, faites-le via Twitter, Facebook, LinkedIn ou courriel.

Peut-être qu'un jour je vais tenter à nouveau de maintenir un blogue, mais pour le moment, c'est fini.

Où suis-je ???

Woah, ça fait longtemps que je n'ai pas écrit sur mon blogue! Que suis-je devenu? Suis-je mort? Que se passe-t-il ???

Entre le travail, la vie personnelle et les loisirs, je dois avouer que je n'ai pas beaucoup de temps à consacrer à mon blogue. De plus, les choses sont plutôt lentes au travail dernièrement, ce qui fait que je n'ai pas énormément d'idées d'articles.

Vous courrez plus de chances d'avoir de mes nouvelles si vous me suivez sur Twitter. Après tout, écrire un message de 140 caractères ou moins nécessite moins de temps que de penser à une phrase d'introduction pour un article sur mon blogue!

Je travail aussi, à temps perdu, sur une librairie .Net de validation, que j'ai nommée nValid. Cette librairie a débutée comme un petit projet me permettant d'explorer les façons de créer des interfaces fluides, sujet très à la mode dernièrement en .NET. J'y ai pris intérêt, et j'ai décidé de poursuivre le développement et d'en faire un projet open source. Vous pourrez donc bientôt télécharger la librairie, et si ça vous intéresse, le code source.

Bien entendu, une fois ce projet disponible à tous, ce sera un bon sujet de discussion, et quelques articles paraîtront sur ce blogue discutant de la librairie plus en détails.

StackOverflow

Jeff Atwood et Joel Spolsky ont récemment lancé une version beta publique de leur nouveau site, stackoverflow. Ce site a un but bien simple: offrir un endroit où les programmeurs peuvent poser des questions à d'autres programmeurs. Tous les sujets touchant de près ou de loin à la programmation sont les bienvenus.

L'élément qui démarque le plus stackoverflow des autres sites du genre est sa facilité d'utilisation. En effet, vous pouvez utiliser le site sans même vous inscrire. Vous pouvez lire, poser et répondre à toutes les questions dès votre arrivée sur le site. Si vous décidez de vous inscrire, vous n'avez qu'à inscrire votre identifiant OpenID, et en quelques secondes, le tour est joué. L'inscription donne accès au système de réputation et de badges.

Ces deux systèmes font de stackoverflow une expérience très... accrochant. La réputation est un score représentant votre niveau d'implication sur le site. Ce score augmente lorsque d'autres usagers votent pour vos questions et réponses. Plus votre réputation augmente, plus vous pouvez interagir avec le site. Avec un niveau de réputation suffisamment élevé, vous pouvez utiliser le site comme s'il s'agissait d'un Wiki, et éditer les questions et réponses des autres utilisateurs.

Quant aux badges, il s'agit de marqueurs que vous obtenez en utilisant les différentes fonctionnalités du site. Certains sont faciles à obtenir, comme « premier vote positif » ou « remplir tous les champs de son profile », et d’autres sont plus difficiles, comme « votre réponse a reçu 100 votes positifs ».

C’est la combinaison de la réputation, des badges et de la facilité d’utilisation qui fait le succès de stackoverflow. En offrant des objectifs précis aux utilisateurs, les développeurs du site dirigent nos actions vers leurs objectifs. En donnant plus de pouvoirs à ceux qui ont fait leurs preuves, la tâche de modération du contenue devient moins lourde. Avec aucune barrière artificielle dans le chemin des nouveaux visiteurs, les questions et réponses arrivent en abondance.

La technologie derrière stackoverflow est ASP.NET MVC, et il est très intéressant de voir un site d’envergure utiliser ce nouveau framework. Si vous désirez plus de détails au sujet du développement de leur site, écoutez le podcast de Jeff et Joel, qui offre des discussions très intéressantes sur plusieurs sujets.

Je vous suggère fortement de faire l’essai de stackoverflow. Posez vos questions et vous verrez que les réponses ne tarderont pas!

Déménagé!

J'ai déménagé! Me voici maintenant propriétaire d'une belle maison à Charlesbourg. Le déménagement a très bien été, grâce à une dixaine d'amis et membres de ma famille qui nous ont aidé.

Nous sommes maintenant presque complètement installés, et nous pouvons enfin profiter de la tranquillité qu'apporte une maison qui nous appartiens.

Voici quelques photos que j'ai prises plus tôt cette semaine:

Est-ce que la culture devrait apparaître dans l'URL ?

Récemment j'ai assisté à une conférence sur ASP.NET MVC donnée par Scott Hansleman dans le cadre d'un événement de la CUNQ. Pendant sa présentation, Scott a mentionné la globalisation d'applications, et son opinion sur le sujet.

Selon lui, la culture (en-US, fr-CA, etc.) n'a rien à faire dans l'URL. L'application devrait se fier exclusivement sur les paramètres du navigateur. Il va même jusqu'à dire que dans la majorité des cas, il est inutile d'offrir aux visiteurs l'option de sélectionner leur langue préférée (par exemple avec des petits drapeaux représentant les différentes cultures disponibles).

Je n'ai pu m'empêcher d'intervenir. Selon moi, pour certains usagers, la possibilité de changer la langue active sur un site est très utile. Il serait fâchant pour les usagers de devoir modifier la configuration de leur navigateur chaque fois qu'ils désirent changer la langue d'un site.

Scott répond à cela que la proportion d'usagers susceptibles de vouloir ce type de fonctionnalité est si petite qu'elle ne justifie pas d'encombrer l'interface, ni même l'URL.

D'une part, je comprends son point. Pourquoi rendre l'URL moins "amicale" pour un paramètre de la sorte? Toutefois, j'utilise moi même ce type de fonctionnalité assez fréquemment, et je connais plusieurs personnes qui pensent comme moi. Il est parfois aussi pratique de pouvoir changer la langue du site simplement en modifiant "fr" pour "en" dans l'url, ou encore d'avoir la possibilité de faire un lien direct à une page dans une langue précise.

Je crois qu'un compromis est possible. La partie de l'URL déterminant la langue devrait être optionnelle. Si elle est spécifiée, le site utilise cette langue, autrement, il se fie sur les paramètres du navigateur.

Je vais probablement créer un petit exemple d'une façon de faire cela avec ASP.NET MVC. Ce sera une bonne façon de voir par la même occasion s'il est simple de concevoir des sites multilingues avec ce framework. En attendant, qu'en pensez-vous? Quelle est votre opinion là dessus?

Nearly Free Speech

Depuis sa mise en ligne, mon site était hébergé sur mon ordinateur personnel, chez moi. C'était loin d'être idéal!

Premièrement il y a la question évidente de la disponibilité: si mon ordinateur est fermé, ou si ma connexion Internet fait défaut, le site n'est pas accessible. Pas très intéressant...

Ensuite, mon fournisseur de services Internet est Vidéotron, et ils ont la fâcheuse particularité de bloquer le port 80. Donc, pour héberger mon site chez moi, j'ai du avoir recours à un hack: J'ai configuré IIS pour écouter sur le port 81 au lieu de 80, et lorsqu'une requête arrivait à www.leddt.com, j'effectuais une redirection, grâce à EveryDNS.net, vers home.leddt.com:81. Encore une fois, il ne s'agit pas de la meilleure approche.

Malgré tous ces problèmes, m'occuper moi même de l'hébergement avait un avantage très important: le prix. Effectivement, ça ne me coûtait absolument rien pour héberger le site chez moi. Je ne voulais pas être pris avec des factures mensuelles pour un site qui ne reçoit pratiquement pas de trafic.

Aujourd'hui j'ai fait le grand saut, et j'ai transférer l'hébergement de leddt.com vers NearlyFreeSpeech.Net. Leur politique de prix correspond parfaitement à mes besoins: je paie pour ce que j'utilise, et pas un sous de plus.

Les prix pour la bande passante commencent à 1$ pour 1 Go, et vont en diminuant selon l'utilisation. L'espace disque est 0.01$ par Mo par mois. Vous pouvez avoir une base de données MySQL pour 0.01$ par jour. Mon site, pour le moment, totalise environ 500 Ko, n'utilise pas de base de données et ne reçoit presque pas de trafic, moins de 100 Mo par mois. Cette utilisation me coûtera donc moins de 0.10$ par mois.

10 sous... J'ai déposé 10$ dans mon compte sur NFSN, et ça devrait me suffire pour quelques années, si mon utilisation reste sensiblement la même. À ce prix, à quoi bon s'en passer?

NFSN offre aussi gratuitement le service de DNS. Ce service est complet et n'a pas de limite, le rendant encore plus intéressant que EveryDNS. Il n'est pas possible de l'utiliser pour gérer une adresse IP dynamique, comme avec eDNS, mais un simple CNAME pointant sur mon compte dyndns fait très bien l'affaire.

Le seul "problème", c'est qu'ils n'offrent pas l'hébergement .Net. C'est compréhensible puisque leurs serveurs sont évidement sous linux. En tant que développeur spécialisé en .Net, c'est dommage, mais pour le moment je n'en ai pas besoin. Mais si un jour j'ai une application asp.net à héberger, je devrai trouver une autre solution.

À part de cela, je n'ai eu aucune difficulté à utiliser ce service jusqu'à maintenant. Les serveurs sont rapides, l'interface d'administration est simple et la documentation est bien écrite. Si vous cherchez de l'hébergement abordable, je ne peux que vous conseiller NearlyFreeSpeech.Net.

Écrire des tests unitaires pour une application ASP.NET

S'il y a une méthodologie de développement qui a gagné beaucoup de popularité ces dernières années, c'est l'écriture de tests unitaires.

De bons tests unitaires sont indispensables puisqu'ils offrent un filet de sureté dans le cadre de la maintenance d'applications. Si votre couverture de code est suffisante, et que vos tests sont correctement conçus, vous pourrez faire des modifications au code sans avoir peur de briser d'autres fonctionnalités par la même occasion.

Il existe de nombreux Framework de tests unitaires pour .NET, tel NUnit, xUnit ou MSTest. Chacun ont leurs forces et faiblesses, mais une lacune commune à travers ces différents outils est la difficulté de tester des applications ASP.NET.

Le principal problème pour ce genre de test est l'absence du HttpContext dans le cadre d'un test unitaire. Admettons que vous avez créé des classes pour écrire et lire des valeurs dans la session d'un usager, comment tester cela si HttpContext.Current est null lors des tests?

J'ai rencontré ce problème pour le projet sur lequel je travail présentement. Après quelques essais infructueux à créer moi même une instance de HttpContext, j'ai trouvé une solution simple et élégante. HttpSimulator, par Phil Haack, est une composante très bien faite qui permet de simuler l'état d'une application pendant une requête ASP.NET.

Son usage est extrêmement simple :

// Cet exemple utilise MSTest

[TestMethod]
public void SetAndRetreiveBasketID()
{
    string expected = "Sample value";
    string actual;

    using (new HttpSimulator().SimulateRequest())
    {
        SessionHelper.BasketID = expected;
        actual = SessionHelper.BasketID;
    }

    Assert.AreEqual(expected, actual);
}

Bref, tout le code situé à l'intérieur du using peut utiliser HttpContext.Current. Il est aussi possible de définir des paramètres afin de spécifier une URL particulière, ou encore pour simuler le POST d'un formulaire.

Malheureusement, certaines propriétés du HttpContext demeurent null même en utilisant HttpSimulator, et donc il se peut que vous ne puissiez pas tester toutes les fonctionnalités. Dans certains cas, il est possible de modifier légèrement HttpSimulator pour inclure ce dont vous avez besoin, mais dans d'autres cas, ça peut être plus compliqué.

Malgré tout, ce simulateur devrait vous aider à tester une bonne partie de votre code. Notez que cet outil n'est pas conçu pour tester vos pages ASPX. Il sert à tester le code qui a besoin d'un HttpContext pour fonctionner. Pour tester vos pages, il existe d'autres outils.