L’utilité des tests unitaires et de l’intégration continue n’est plus à prouver. En revanche, l’association des deux peut demander un peu de gymnastique. En l’occurrence, il m’a fallu mettre les mains dans le cambouis pour lancer un projet de test via Jenkins (ex-Hudson), puis pour qu’il soit reconnu par Sonar.
Nous allons donc voir ici comment créer un projet de test, puis comment l’exécuter sous Jenkins.
Vous avez déjà probablement fait face à ce problème : un simple composant Button, un traitement long attaché au bouton, un utilisateur impatient qui clique plusieurs fois sur ce même bouton… et là, c’est le drame : les données produites par le traitement sont créées plusieurs fois, les relations en base de données deviennent incohérentes, le site plante de toutes parts…
Heureusement, il a plusieurs moyens de remédier à ce problème, dont cette petite technique que je vous présente, qui consiste à cacher un bouton (ou le bloc qui le contient) lorsque l’on clique dessus, et à le remplacer par une animation de chargement. Elle est plutôt rapide à mettre en œuvre et se base en partie sur du JavaScript.
Le Framework .Net permet de lire facilement et rapidement un fichier texte grâce à la fonction ReadAllLines().
Facilement, oui, mais il peut y avoir de mauvaises surprises au niveau du codage des caractères (j’utiliserai le mot « encodage » dans la suite de cet article). En effet, les caractères de la phrase « Le garçon ne pouvait être là cet été » peuvent vite devenir « Du Le garçon ne pouvait être là cet été » si le codage n’a pas été bien précisé à la lecture.
La fonction ReadAllLines() propose en effet deux prototypes, dont l’un demande en argument l’encodage du contenu du fichier (argument de la classe System.Text.Encoding). Et ce fameux encodage n’est pas simple à déterminer.
Nous allons donc voir comment détecter, ou plutôt « déduire » l’encodage des caractères d’un fichier texte, et ce grâce à la bibliothèque « nuniversalchardet », issue de la bibliothèque « universalchardet » de Mozilla.
Lors du développement de votre site web, vous serez probablement amenés à utiliser l’objet Session pour y stocker des variables. Et, pour augmenter les performances de votre site, vous pourriez augmenter le nombre de processus de travail dans IIS (Web garden).
Cependant, par défaut, ces deux paramètres sont incompatibles.
En effet, pour résumer de façon simple, on peut dire que les variables de session seront parfois stockées dans l’objet Session de l’un des processus, puis parfois dans l’objet Session d’un autre processus.
Exemple :
MonObjet monObjet = (MonObjet)(Session[MOT_CLE]); // Va être null « une fois sur deux » si vous avez deux processus de travail.
Pour éviter ce problème, il faut changer le mode d'état de session (sessionState) et le mettre en mode « StateServer », puis réaliser quelques opérations supplémentaires.
Parmi les contrôles serveurs fournis par ASP.NET, on a à notre disposition le dénommé FileUpload, qui permet à l’utilisateur d’enregistrer (uploader) un fichier sur le serveur.
Seulement, ce contrôle serveur manque de clarté en ce qui concerne la taille maximale d’un fichier autorisée. En effet, d’une part, cette limite est faible par défaut (4 Mo), et d’autre part, les messages d’erreur ou d’avertissement sont peu explicites, ni pour l’utilisateur, ni pour le développeur. Par exemple, sous Firefox, on obtient le message suivant :
La connexion a été réinitialisée
La connexion avec le serveur a été réinitialisée pendant le chargement de la page.
...
Nous allons donc voir comment maîtriser d’avantage la taille limite des fichiers à uploader et comment en avertir l’utilisateur.
Lors de la première partie de cet article, nous avons vu comment importer et compiler un projet .NET sous Linux grâce à Mono et son interface de développement, MonoDevelop.
Dans cette seconde partie, nous aborderons la migration d'une base de données Microsoft SQL Server (abrégée MS SQL) vers une base PostgreSQL, avant d'effectuer la mise en ligne du projet avec Apache le module adéquat, baptisé « mod_mono ».
Ces exemples permettront de tirer une conclusion ; non seulement sur l'intérêt de Mono, mais également sur la migration d'une application Web provenant d'un environnement Windows vers un environnement Linux.
En règle générale, lorsque l’on évoque un « projet .NET », on pense à Windows Server, Visual Studio ou encore SQL Server. Soit un environnement de travail et de production assez coûteux.
Pourtant, depuis 2004 (soit environ deux ans après la sortie de la première mouture du Framework .NET), un framework libre et gratuit permettant de développer des projets .NET existe : il s'agit de Mono. Outre le fait qu'il soit libre et gratuit, Mono permet de développer et d'exécuter ces projets sur des systèmes d’exploitation tels que Linux ou Mac OS X, que le langage utilisé soit du C# ou du VB.NET, ou encore, que le projet soit un logiciel ou un site Web. Actuellement disponible en version 2.10.1 (2.6.7 dans les paquets Ubuntu), Mono ne cesse d'être mis à jour, afin de suivre logiquement les évolutions apportées au .NET originel de Microsoft.
Nous verrons donc ici comment « porter » une application Web évoluant dans un environnement Windows vers un environnement Linux, tel qu'Ubuntu.
