[C#] Bulk Insert

Voici la problématique que j’ai eu récemment : pour mes tests automatisés, j’ai besoin d’insérer des données.
Jusque là, tout va bien.
Pour des tests de charge, j’ai besoin de beaucoup de données.

Sur le ring, j’ai donc :
Côté droit, ma table, près de 70.000.000 de lignes, plus de 80 colonnes.
Côté gauche, mes données, presque 5.000 lignes à insérer.

A la base, mon moteur de gestion de base de données gère les insertions ligne par ligne (il n’a pas été fait, à l’origine, pour du test de charge).
Du coup, pour plusieurs lignes, c’est géré via une basique boucle.
Mais voilà, avec cette méthode, j’ai un rythme d’environ 500 lignes par minute.
Pas terrible, terrible…

Alors, comment faire ?
Le Bulk Insert à la rescousse !

Legacy Applications

COBOL : Fousa – flickr

Depuis que j’ai commencé à travailler (en SSII, qu’il faut nommer ESN, pour rappel), j’ai souvent rencontré des applications assez vieilles.
Au début, je ne savais pas, mais j’ai appris par la suite que l’on nommait ça "legacy application" (ou Legacy system, ou Système hérité en français).

Autrement dit, des applications très vieilles sur lesquelles sont passés un nombre de développeurs parfois impressionnant, avec des normes de codages qui varient en fonction des époques, des personnes, du chef de projet courant, du sens du vent et de l’humeur du jour.
Autrement dit bis, c’est une application…bordélique et surtout qui va coûter immensément cher à maintenir ou même à migrer.

Dans ce billet, on va voir un peu quelques risques d’avoir un tel système. Ce n’est pas exhaustif, mais à minima issue de ma propre expérience (donc un potentiel point de départ).
Il est en effet très important de connaître les risques de garder une telle application pour décider de la garder ou de la changer.

[TFS 2010] Lancer un exécutable durant une build

Il y a quelques jours, je devais faire fonctionner une build, pour générer un package zip.
Jusque là, tout va bien.
Avec IIS Express (voir billet précédent : Les différents serveurs Web pour développer).
Et là, c’est le drame.

Déjà, je vais faire un gros spoil sur le reste du billet : ça marche pas.
Une histoire de communication difficile entre MSDeploy et IIS Express, de ce que j’en ai vu (je reviendrais peut être sur le sujet).

Mais cela m’a permit d’apprendre plusieurs choses : comment fonctionne une build sous TFS, comment modifier sa définition et son processus de génération et enfin, comment lancer un exécutable qui écoute (comprendre qui attend une action utilisateur pour s’arrêter), comme IIS Express.
C’est cette dernière partie que je vais traiter ici.
En effet, il y a une petite finesse quand le processus lancé écoute : il attend une réaction de l’utilisateur pour s’arrêter, ce qui empêche la build de passer à une autre étape.
Cela peut être utile, par exemple dans le cadre d’une build lançant des tests sur une application client/serveur.

En prérequis, pour comprendre le billet, c’est de savoir ce qu’est une build TFS et un workflow (et donc d’en avoir le vocabulaire, mais ce n’est réellement pas compliqué).
Pour cela, je vous invite à regarder directement sur la MSDN Team Development with Visual Studio Team Foundation Server : Chapter 7 – Team Build Explained et Chapter 13 – Process Templates Explained.

Les différents serveurs Web pour développer

Aujourd’hui, on va un peu parler des différents serveurs Web pour développer.
Enfin, de trois en particuliers : le serveur de développement ASP.Net (aka Cassini), IIS et IIS Express.

Il est possible de paramétrer les serveurs Web pour un projet (*.csproj) à partir des propriétés de ce dernier, dans l’onglet "Web".
Cependant, il faut bien garder en mémoire que ce paramétrage est totalement indépendant de la configuration de compilation. Il est donc parfaitement impossible d’utiliser Cassini en développement et IIS en release ! (et ça, c’est bien dommage !).

Il est par contre possible que le paramétrage soit stocké par utilisateur, dans le fichier *.csproj.user qui accompagne le projet.
Ceci dit, ce n’est pas viable en conjonction avec les builds TFS (mais ça, j’en reparlerais dans d’autre(s ?) billet(s)).

TechDays 2013 – Vidéos

Un petit billet rapide pour dire que les vidéos de 299 sessions sont présentes sur le site des TechDays.
Il est possible de les retrouver ici : TechDays – Recherchez les vidéos des sessions 2013

IIS – WebDeploy

Ça change un peu du codage pur et dur, mais cette semaine, j’ai du faire d’autres opérations.
Les opérations en question, c’est d’installer différents sites Web : répéter les opérations utiles et faire une documentation à destination de l’exploitation.

Du coup, on a un peu tâtonner sur différentes sujets (Build sous TFS, génération d’un package de déploiement…).
Dans le présent billet, je vais uniquement parler de l’installation des sites Web via Web Deploy, sous IIS et les pré-requis pour que ça se passe bien.

Déjà, pour les outils que j’ai utilisé à cette occasion :

• Visual Studio 2010
• IIS 7.5
• Web Deploy

Pour IIS 7.5 et Web Deploy, il faut aller voir sur le site officiel de IIS. Ce sont bien sûr des pré-requis.

 

[C# RavenDB] Overview

Comme pour le billet sur MongoDB que j’avais écris, il y a un temps certain, voici le pendant pour RavenDB.

Pour le coup, je ne vais pas refaire l’introduction sur ce qu’est une base de données NoSQL, je vous laisse relire celle du billet mentionné.
Je ne vais pas non plus m’étendre sur les avantages de RavenDB, je vais laisser le discours "commercial" au site officiel le faire : RavenDB – Features.

Du coup, dans ce billet, nous allons plutôt aborder la mise en route de RavenDB.
Et au fil du billet, je comparerais avec MongoDB.