Conférence Microsoft sur Windows 10 à suivre en direct aujourd’hui

Comme vous le savez certainement, Microsoft fait une conférence de présentation de tout ce que l’on peut attendre sur Windows 10 ce soir, mercredi 21 Janvier 2015 à 18h (heure française).

Pour suivre la conférence en direct, rendez-vous sur http://news.microsoft.com/windows10story/.

Ici chez Soft’it, on attend beaucoup de cette conférence et des nouveautés de Windows 10 :

  • Le retour du menu démarrer
  • Les Universal Apps
  • Les « Modern » Apps qui ne sont plus obligatoirement en plein écran
  • Les améliorations faites pour les entreprises

Et vous, qu’attendez-vous de cette conférence ?

[ASP.NET MVC] Requêtes GET très longues sur arterySignalR (Browser Link)

Récemment, lors du développement d’un site ASP.NET MVC 5 interrogeant une Web API 2.2 OData, nous avons constaté que nos processeurs tournaient à 100% lorsque nous exécutions le site en local.
Le problème ne se posait pas en debug, ni sur les plateformes d’intégration mais uniquement sur des sites IIS locaux.

En étudiant la trace Réseau avec les outils développeurs de Chrome et IE, nous avons remarqué qu’il y avait des milliers de requêtes GET sur http://localhost:<port>/<guid>/arterySignalR/send?transport=longPolling

IE
arterysignalr-IE

Chrome
arterysignalr-Chrome

Il s’avère que « arterySignalR » n’est autre que l’appel à Browser Link. C’est une fonctionnalité de Visual Studio 2013 permettant d’établir une connexion temps-réelle avec l’ensemble des navigateurs exécutant une application actuellement ouverte dans VS.
Toutes les interactions que vous faites dans votre code peuvent être répercutées via Visual Studio sur tous les navigateurs ouverts sur l’application en question.
Cela vous permet aussi de rafraîchir automatiquement vos feuilles de styles par exemple, sans avoir à faire un F5 sur votre navigateur.

Il s’avère que dans notre cas, l’appel à notre Web API derrière le site MVC plombait les perfs. Il a été plus judicieux de le désactiver en attendant de trouver une solution de contournement.

Si vous désirez faire de même, il vous suffit dans Visual Studio de cliquer sur le bouton de rafraîchissement à côté du bouton de Debug en navigateur, puis de décocher « Activer le lien de navigateur » :

arterysignalr-VS

Voilà !

En espérant que ça puisse vous aider autant que nous.

Source : http://stackoverflow.com/questions/19917595/net-localhost-website-consistantly-making-get-arterysignalr-polltransport-long

[Mobile Dev Day] « Vers un design multiplateforme » de Benjamin Launay

Durant les Mobile Dev Day 2014, nous avons suivi une conférence particulièrement intéressante sur le design multiplateformes : comprendre les contraintes ergonomiques et design du multiplateformes, et savoir comment prendre la décision du 100% natif, 100% original (custom) ou « Terre du milieu ».

Le speaker, Benjamin Launay, a publié un très bon résumé de sa conférence sur son site AieAieEye :

Vers un design multiplateforme (Mobile Dev Day 2014)

DevOps, le monitoring des applications Web comme point d’entrée


De nos jours, les applications web connaissent un boom incroyable. Tout le monde a compris qu’internet est un outil business très efficace qui permet d’augmenter la visibilité de l’entreprise (Marketing), étendre ses marchés (boutique en ligne),…etc.

Voici quelques chiffres sur la situation du commerce en ligne en 2013 :

  • Le nombre des acheteurs en ligne a augmenté de 5% en 2013.
  • La fréquence des achats en ligne est en progression avec une moyenne de 18 transactions par an et par acheteur, contre 16 en 2012.
  • Le nombre de sites marchands actifs a dépassé les 138 000.

* Statistiques avancées par  Elioweb (http://www.elioweb.com/statistiques-e-commerce-france.html)

Donc, contrairement aux débuts d’internet qui étaient constitués de sites vitrines essentiellement. On se retrouve, aujourd’hui, avec des applications Web capables de récolter et de capter les actions des utilisateurs.

Cette révolution a considérablement complexifié les applications Web : logique métier complexe, sécurité, performances…etc.

En outre, de plus en plus d’entreprises abandonnent le développement d’applications lourdes et les remplacent par des applications Web. Cela permet de réduire, voir d’éliminer, les processus de déploiement des applications et des mises à jour sur les postes utilisateurs.
De ce fait, les applications Web apportent un gain de temps considérable et une réactivité presque immédiate quand il s’agit de résoudre des bugs ou de déployer de nouvelles versions.

Du point de vue des équipes informatiques, l’enjeu est énorme. Les applications sont plus complexes, plus sensibles et ont un réel impact financier. Il faut donc avoir un niveau de qualité très élevé en même temps qu’une productivité accrue.

En général, les équipes informatiques sont organisées en plusieurs sous-équipes : les développeurs d’un côté et les opérationnels (administrateurs système, réseau, base de données, messagerie, etc…) d’un autre côté.
Les développeurs ont pour rôle de créer l’application et de la faire évoluer au fil du temps. Ils sont aussi responsables de la correction des éventuels bugs détectés. Les opérationnels, quant à eux, sont responsables de la mise en place des environnements techniques, du déploiement de l’application et du monitoring de l’infrastructure.

Chaque équipe possède ses propres méthodes de travail, ses propres priorités et ses propres métriques.
Cette organisation pose un réel souci pour la collaboration des équipes. Il n’est pas rare de rencontrer l’analyse suivante suite à un problème de performance, par exemple :

  • Admin réseau : « Pas de congestion, tous les routeurs fonctionnent ».
  • Admin système : « Les serveurs ont suffisamment de CPU et de mémoire ».
  • Devs : « Le code de l’application est bon, le même code fonctionne correctement sur l’environnement de pré-production ».

Au lieu de travailler ensemble pour identifier le problème, chaque équipe va analyser le problème de son point de vue et tenter de démontrer que « ça ne vient pas de chez nous »; voire dans certaines cas, essayer de mettre en cause les autres équipes. Mais, malheureusement, il y a bien un problème du point de vue des utilisateurs.

Ce genre de situation peut coûter cher à l’entreprise : perte de clients pour un site e-commerce, planification de stock erronée pour une usine, etc….

Afin d’éviter de tomber dans ce type de situation, une entreprise doit faire évoluer sa culture pour se concentrer sur l’humain, l’organisation du travail et le bon choix des outils de gestion du cycle de vie des applications et des infrastructures.

Cette culture est le cœur même de la philosophie DevOps visant à rapprocher les équipes Dev et Ops. Ce rapprochement permettra aux équipes de communiquer plus efficacement, de partager les mêmes objectifs et de réfléchir continuellement aux différentes pistes d’améliorations de leur travail.

La Journée DevOps Day, qui a eu lieu le 25 novembre 2014 à Paris, s’est penchée sur la problématique de mise en place du processus DevOps dans les projets informatique (voir l’article Tour d’horizon du Microsoft DevOps Day – « Infrastructure as Code » pour avoir une idée sur le contenu de cette journée).

La mise en place d’une culture DevOps au sein d’une entreprise nécessite un travail de sensibilisation et de conviction des équipes. Il ne s’agit pas d’installer un outil, mais de changer complètement les mentalités, la façon de travailler des collaborateurs voire même l’organisation des équipes. Toute tentative de mise en place d’une culture DevOps par simple décision émanant de la direction subira inévitablement un échec et engendrera plus de méfaits que de bienfaits ; la conduite du changement a une place prépondérante ici.

La notion de DevOps est une notion vaste qui couvre tout le cycle de vie d’une application, de son développement à sa mise en production en passant par les différents environnements techniques. Il est vital de mettre en place le processus DevOps de façon graduelle. Vouloir adopter ce processus dans tous les aspects du cycle de vie applicatif en même temps peut s’avérer complexe, voire même périlleux.

Un point d’entrée intéressant pour la mise en place de DevOps est le monitoring des applications déjà en production. Les équipes Dev et Ops pourront coopérer pour mieux réagir aux problèmes rencontrés sur les applications en production.
Le monitoring est, en fait, un bon point de coopération pour les Dev et les Ops. Un mauvais comportement d’une application engagera la responsabilité des Dev et des Ops en même temps. Si les deux parties sont convaincues qu’ils forment la même équipe, ils mettront toutes leurs compétences et leur énergie pour améliorer le processus de monitoring :

  • Choix des bons outils qui reflètent le réel état des applications.
  • Mettre à disposition des Devs des rapports afin qu’ils puissent anticiper les éventuels problèmes lors des prochaines versions.
  • Collaborer en temps réel pour la résolution des problèmes urgents
  • …etc

Se baser sur le monitoring pour une première mise en place de DevOps a pour avantage de démontrer l’intérêt de cette approche (applications plus stable, réaction plus efficace aux problèmes de production…etc.) et, donc, de faciliter son adoption pour les autres étapes du cycle de vie applicatif.

Cela-dit, il faut garder à l’esprit que le DevOps n’est pas un objectif en soi, mais une quête vers une amélioration continue de la collaboration des équipes Devs et des Ops.
La façon de mettre en place DevOps varie inévitablement d’une entreprise à une autre, voire même, d’un service à un autre au sein d’une seule et même entreprise. C’est un processus lent qui nécessite beaucoup de patience et une implication sans failles des différents acteurs.

Cependant, une fois sur les rails, DevOps apportera énormément à l’entreprise: des équipes soudées, un environnement de travail sain et des livrables de meilleur qualité, donc, des utilisateurs satisfaits [et il faut malheureusement trop souvent rappeler que c’est ce pourquoi nous travaillons tous].  

Soft’it monte en compétence sur AngularJS !

Chez Soft’it, la connaissance est bien plus qu’un simple mot. En tenant compte aussi bien de notre Expertise .Net, Coaching qualité ou encore de nos formations, les collaborateurs de Soft’it se mettent régulièrement à jour en matière de nouvelles technologies.

Force est de constater que le nouveau framework JavaScript de Google (AngularJS) s’immisce dans tous les nouveaux projets Web actuels; l’équipe estime que cette technologie doit être impérativement maîtrisée par tous les membres pour garantir des applications Web de plus en plus robustes et puissantes.

Pour la toute première fois sur Paris, le site ng-workshop propose une formation AngularJS du 3 au 5 décembre incitant les développeurs à s’appliquer sur la qualité plus que sur la quantité dans leurs projets.
Pour vous donner un avant-goût des futurs articles que nous ferons autour d’AngularJS, nous aborderons durant la formation des sujets tels que  :

Construire et tester une
application
Communiquer avec un serveur backend
Sécuriser votre application
Internationaliser une application
AngularJS
Packager et déployer son application AngularJS

 Trois membres de l’équipe Soft’it vont participer à cette formation :

Bien évidemment, ces trois personnes se feront un plaisir de vous rédigez plusieurs articles sur cette formation pour vous donner l’envie de découvrir ce framework indispensable à l’avenir du développement Web 🙂

Introduction à la gestion des cycles de vie des applications (ALM)

Introduction à la gestion des cycles de vie des applications

(Application Lifecycle Management – ALM)

       ….

Evidemment, dit comme cela, cela peut paraître un peu abrupte voire déconcertant … Cycles de vie des applications  – Application Lifecycle Management. Mais sous ce nom se cache en réalité l’une des meilleures pratiques logicielles dont l’objectif est de fournir un logiciel de haute valeur et de haute qualité, et ce d’une manière très efficace, rapide et fiable

Quelles sont les différentes étapes de l’ALM ? 

D’un point de vue du développeur, il est courant de penser que le cycle de vie d’un logiciel commence et s’arrête lors du checkout et du commit des modifications du code. 

La réalité est tout autre, comme nous le voyons tous les jours, et couvre beaucoup plus. 

Le cycle de vie des applications commence à partir de la création du projet jusqu’à la livraison en production, comprenant plusieurs étapes dont le développement n’est qu’une petite partie parmi, entre autres, les tests, les documentations et la génération d’installateurs. 

L’ensemble de ces opérations permet de livrer un logiciel de haute valeur et de haute qualité pour le client.

Ce schéma montre le pipeline de déploiement idéal. On y retrouve l’ensemble des opérations automatisées à mettre en place lorsqu’on parle d’ALM.
Le processus est entièrement automatisé, capable de fournir un feedback détaillé de son statut et de celui de ses opérations, et de s’interrompre à chaque étape en cas de détection d’anomalies.
Bien loin de ce déroulement idéal, le plus souvent, il est fréquent que la plupart de ces opérations soient manuelles, partielles et sans fournir de réel feedback.
Même si maintenant il est largement admis que le code source doit être hébergé dans un outil de contrôle de version, et que chaque développeur doit faire des check-out et commit réguliers, il est encore très rare de trouver une plateforme d’intégration continue réelle automatisée, qui gère ne serait-ce que la compilation automatique et le déroulement des tests unitaires. 
A la place, il est fréquent qu’il y ait des flux allant dans toutes les directions, sources de risques et de problèmes à venir, comme le montre le schéma ci-dessous  : 

Quel est le problème avec la livraison de logiciels ? 


  1. Les opérations sont nombreuses, souvent manuelles et sur différents environnements techniques mal maitrisés,
    • Le corollaire est que ces opérations dépendent de quelqu’un (responsable déploiement, chef de projet, expert quelconque). La question est donc : que se passe t’il lorsque cette personne est absente
    • extrêmement répétitives, ces tâches sont une plaie sur le long terme,
    • la réalisation d’une documentation souvent lourde est nécessaire,
    • une courbe d’apprentissage lente pour l’ajout de nouveaux membres à l’équipe,
    • des besoins humains supplémentaires sont nécessaires à l’équipe

  2. Le code source et les paramétrages ne sont pas nécessairement stockés dans le même endroit, mais peuvent être générés à partir de partout et par n’importe qui, n’importe quand : qui contrôle quoi ?
  3. Aucune vraie traçabilité,
  4. Des délais de livraison très long : il peut se passer des jours entre la validation et le déploiement,
  5. Des erreurs sont plus enclines à apparaître. 
En bref : lorsqu’il y a des opérations manuelles, il devient vraiment difficile de répéter, de cadencer et de mesurer la livraison. 

Quels sont les objectifs de l’ALM ? 

Comme vous l’aurez compris maintenant : implémenter l’ALM c’est principalement se concentrer sur l’automatisation de la grande majorité (sinon la totalité) des opérations ; afin d’assurer la création de valeur et des livraisons fiables, rapides et cadencées.
L’idée maîtresse est de réduire les temps de cycle.
Plus le temps de cycle est court, plus le client pourra être satisfait (par plus de fonctionnalités ou même par des corrections de bugs). L’objectif est de favoriser les feedbacks rapides.

Comment? 

Etant donné que cet article est seulement une (très) courte introduction, nous ne plongerons pas plus à fond dans les détails ici. 
Nous énumérerons simplement les différents sujets à couvrir. Ceux-ci seront expliqués plus en détails dans de prochains articles :
  1. Configuration et installation d’un outil d’intégration continue (TFS, Hudson, CruiseControl), 
  2. Mettre au cœur de l’outil l’analyse de qualité (règles de gestion, Sonar, FxCop) ainsi que les tests, le tout avec de l’automatisation, 
  3. Mettre sous contrôle de source tous les paramètres ou fichiers de configuration pour tous les hôtes cibles, 
  4. Lister toutes les autres opérations manuelles, les automatiser et les chaîner entre elles,
  5. Modifier le processus de développement pour s’appuyer davantage sur les tests d’acceptation,
  6. Réduire les délais de feedback (testeurs, clients ….). 

Conclusion 

Cet article n’est que le premier d’une série d’articles introduisant les principes de ALM (intégration continue, déploiement continu…etc). Il vise à présenter simplement ce qui est en jeu tout en abordant les grands principes du cycle de vie des applications.
Dans les prochains articles, nous expliquerons plus en détail avec de cas concrets d’utilisation et d’implémentation, les scénarios de mise en place de l’ALM.

Liens utiles

ALM (sur wikipedia) : pour une explication simplifiée.
Intégration Continuela définition par M. Martin Fowler
Déploiement Continu : la définition par M. Martin Fowler

[MVC] Utilisation de jQuery DataTables en mode serveur

Note: le projet est disponible sur GitHub : https://github.com/MarienMonnier/softit-jquerydatatables-demo

Dans cet article, nous allons voir comment le plus simplement possible, vous allez pouvoir utiliser jQuery DataTables (version 1.10 minimum) en mode serveur, pour récupérer vos données via ASP.Net MVC 5.

Il existe déjà plusieurs projets qui montrent comment utiliser ASP.Net MVC avec jQuery DataTables, mais au final, dans tous les exemples que j’ai trouvé, ils utilisaient tous un custom IModelBinder pour pouvoir faire le binding des différentes propriétés avec un View Model. Sauf qu’en utilisant MVC 5 et jQuery DataTables 1.10 (et supérieur), ce custom binding n’est pas nécessaire, et il enlève une bonne épine du pied.

La mise en place d’une DataTables en mode serveur avec ASP.Net MVC va se faire en plusieurs étapes :

  1. Création des View Models
  2. Création de la vue
  3. Création du Controller et des services

Et parce qu’il est toujours intéressant de pouvoir ajouter des filtres personnalisés, nous finirons par :

  1. Ajout de filtres supplémentaires

Création des View Models

DataTables envoie et récupère des données sous un certain format qui lui est spécifique. À partir des informations fournies par la documentation, nous récréons d’abord les View Models.

Le View Model pour le résultat global :

public class DTResult<T>
{
    public int draw { getset; }
    public int recordsTotal { getset; }
    public int recordsFiltered { getset; }
    public List<T> data { getset; }
}

Et le View Model des paramètres qui sont envoyés par DataTables à la requête AJAX. La seule propriété qui ne fait pas partie de la requête est « SortOrder », qui est une propriété maison permettant de faire un tri sur nos données via la méthode d’extension SortBy<T> de l’objet IQueryable<T>.

public class DTParameters
{
    public int Draw { getset; }
    public DTColumn[] Columns { getset; }
    public DTOrder[] Order { getset; }
    public int Start { getset; }
    public int Length { getset; }
    public DTSearch Search { getset; }
    public string SortOrder
    {
        get
        {
            return Columns != null && Order != null && Order.Length > 0
                ? (Columns[Order[0].Column].Data + (Order[0].Dir == DTOrderDir.DESC ? " " + Order[0].Dir : string.Empty))
                : null;
        }
    }
}

Création de la vue

Dans le cadre de cet exemple, nous allons afficher une liste de produits de la base Northwind récupérés avec les différents appels AJAX de DataTables.

Tout d’abord la partie HTML (« bootstrapée »):

<div class="panel panel-default">
    <div class="panel-heading">Product Search</div>
    <table class="table table-striped table-hover table-bordered table-responsive" id="dt" width="100%">
        <thead>
            <tr>
                <th data-column="ID" data-order="desc">ID</th>
                <th data-column="Name">Name</th>
                <th data-column="UnitPrice">UnitPrice</th>
            </tr>
        </thead>
    </table>
</div>

Ensuite, la partie JavaScript qui fait appel à DataTables. Il n’y a rien de particulier dans ce code, c’est la configuration de base de DataTables pour :

  • faire les appels en mode serveur (processing: true et serverSide: true)
  • lui indiquer que la page à appeler est notre méthode GetData de notre HomeController
  • configurer les colonnes à afficher.
<script type="text/javascript">
    $(function() {
        var table = $('#dt');
        var dt = table.dataTable({
            ajax: {
                type: 'POST',
                url: '@Url.Action("GetData""Home")'
            },
            columns: [
                { data: 'ID' },
                { data: 'Name' },
                { data: 'UnitPrice' }
            ],
            order: [0, 'desc'],
            processing: true,
            serverSide: true,
            orderMulti: false
        });
    });
</script>

Création du Controller et des services

La table est maintenant configurée pour appeler l’action GetData du HomeController.

Notre contrôleur a une méthode GetData qui :

  • prend en paramètre le View Model DTParameters que nous avons écrit et qui contient tous les paramètres que DataTables nous envoie
  • fait appel à un service (GetProducts) pour récupérer les produits en fonction de ces paramètres
  • fait appel à un second service (Count) pour récupérer le nombre d’éléments suivant ces paramètres (pour la pagination)
  • retourne les données au format JSON telles qu’attendues par DataTables (un DTResult<Product>).
public JsonResult GetData(DTParameters dtModel)
{
    try
    {
        List<Product> data = new ProductService().GetProducts(dtModel.Search.Value, dtModel.SortOrder, dtModel.Start, dtModel.Length);
        int count = new ProductService().Count(dtModel.Search.Value);
        DTResult<Product> result = new DTResult<Product>
                            {
                                draw = dtModel.Draw,
                                data = data,
                                recordsFiltered = count,
                                recordsTotal = count
                            };
        return Json(result);
    }
    catch (Exception ex)
    {
        return Json(new { error = ex.Message });
    }
}

Et les méthodes de service associées :

public class ProductService
{
    private static readonly List<Product> Products;
 
    static ProductService()
    {
        Products = new List<Product>
                    {
                        new Product(1, "Chai", 18.0000m),
                        new Product(2, "Chang", 19.0000m),
                        // ...
                        new Product(76, "Lakkalikööri", 18.0000m),
                        new Product(77, "Original Frankfurter grüne Soße", 13.0000m)
                    };
    }
 
    public List<Product> GetProducts(string search, string sortOrder, int start, int length)
    {
        return FilterProducts(search).SortBy(sortOrder).Skip(start).Take(length).ToList();
    }
 
    public int Count(string search)
    {
        return FilterProducts(search).Count();
    }
 
    private IQueryable<Product> FilterProducts(string search)
    {
        IQueryable<Product> results = Products.AsQueryable();
 
        if (!string.IsNullOrWhiteSpace(search))
            results = results.Where(p => p.Name.Contains(search));
 
        return results;
    }
}

Les services sont plutôt simples :

  • une méthode pour récupérer une liste de produits suivant une recherche, un tri, et une pagination
  • une méthode qui permet de compter le nombre d’éléments suivant le filtre donné (pour que la pagination soit effective côté jQuery DataTables).

Nous avons à présent une démo fonctionnelle qui nous permet de lister les produits de manière paginée, de changer le nombre d’éléments par page, et de rechercher un produit par son nom :

Ajout de filtres supplémentaires

Il peut toujours être intéressant de passer des données supplémentaires à vos appels AJAX qui sont faits par DataTables, ne serait-ce que pour ajouter des filtres, passer un ID supplémentaire, etc…

Toutes ces données sont à ajouter dans le paramètre data de DataTables.

On va modifier un peu la vue et le JavaScript pour ajouter un panel de filtre sur nos prix minimum et maximum; et un bouton pour lancer la recherche.

<div class="panel panel-default">
    <div>...</div>
    <div class="panel-body">
        <div class="well">
            <div class="row">
                <div class="col-xs-4">
                    <label for="minPrice">Minimum Price</label>
                    <input type="text" name="minPrice" id="minPrice" value="" class="form-control" />
                </div>
                <div class="col-xs-4">
                    <label for="maxPrice">Maximum Price</label>
                    <input type="text" name="maxPrice" id="maxPrice" value="" class="form-control" />
                </div>
                <div class="col-xs-2">
                    <button id="search" class="btn btn-primary"><span class="glyphicon glyphicon-search"></span></button>
                </div>
            </div>
        </div>
    </div>
    <table>...</table>
</div>

Nous passons les filtres dans la fonction data de DataTables, et rafraîchissons la table lorsque l’on clique sur le bouton de recherche :

var dt = table.dataTable({
    ajax: {
        type: 'POST',
        url: '@Url.Action("GetData""Home")',
        data: function(d) {
            d.MinPrice = $('#minPrice').val();
            d.MaxPrice = $('#maxPrice').val();
        }
    },
    columns: [ ... 
});
$('#search').click(function(e) {
    e.preventDefault();
    dt.fnDraw();
});

Nous avons maintenant une vue qui nous permet de sélectionner un prix minimum et maximum. Mettons à jour le Controller et les services pour prendre en compte ces nouvelles données.

Nous passons dans l’appel AJAX deux nouvelles propriétés (MinPrice et MaxPrice), que nous allons mettre dans une classe FilterViewModel très simple :

public class FilterViewModel
{
    public decimal? MinPrice { getset; }
    public decimal? MaxPrice { getset; }
}

Et nous faisons évoluer notre méthode GetData du Controller pour prendre aussi un FilterViewModel en paramètre, et passer les valeurs à nos deux méthodes de service :

public JsonResult GetData(DTParameters dtModelFilterViewModel filterModel)
{
    try
    {
        List<Product> data = new ProductService().GetProducts(dtModel.Search.Value, dtModel.SortOrder, dtModel.Start, dtModel.Length, filterModel.MinPrice, filterModel.MaxPrice);
        int count = new ProductService().Count(dtModel.Search.Value, filterModel.MinPrice, filterModel.MaxPrice);
        DTResult<Product> result = new DTResult<Product>
                            {
                                draw = dtModel.Draw,
                                data = data,
                                recordsFiltered = count,
                                recordsTotal = count
                            };
        return Json(result);
    }
    catch (Exception ex)
    {
        return Json(new { error = ex.Message });
    }
}

Faisons évoluer nos méthodes de service pour y ajouter un filtre sur le prix minimum et maximum :

public List<Product> GetProducts(string search, string sortOrder, int start, int lengthdecimal? minPrice, decimal? maxPrice)
{
    return FilterProducts(search, minPrice, maxPrice).SortBy(sortOrder).Skip(start).Take(length).ToList();
}
 
public int Count(string searchdecimal? minPrice, decimal? maxPrice)
{
    return FilterProducts(search, minPrice, maxPrice).Count();
}
 
private IQueryable<Product> FilterProducts(string searchdecimal? minPrice, decimal? maxPrice)
{
    IQueryable<Product> results = Products.AsQueryable();
 
    if (!string.IsNullOrWhiteSpace(search))
        results = results.Where(p => p.Name.Contains(search));
 
    if (minPrice.HasValue)
        results = results.Where(p => p.UnitPrice >= minPrice.Value);
 
    if (maxPrice.HasValue)
        results = results.Where(p => p.UnitPrice <= maxPrice.Value);
 
    return results;
}

Et voilà !

Nous avons maintenant une démo qui nous permet avec jQuery DataTables 1.10 de faire des requêtes serveur sur notre site MVC 5 en ajoutant des filtres personnalisés, tout cela en quelques minutes seulement.

Pour rappel, ce projet se trouve sous GitHub à l’adresse suivante : https://github.com/MarienMonnier/softit-jquerydatatables-demo

Et, comme je le signalais au début de l’article, il existe déjà plusieurs projets qui ont été faits pour MVC / jQuery DataTables; projets qui peuvent vous intéresser si vous utilisez des versions précédentes de MVC et/ou jQuery DataTables :

Le chemin vers la qualité est-il unique ? (Part 1 : la Méthodologie)

le chemin 1

Scrum, Crystal Clear, eXtreme Programming (XP) … De plus en plus, nous nous éloignons du cycle en V. Ou en tout cas, nous essayons de le faire.

Pourtant, si l’on se rappelle la conférence « Petite histoire d’une méthodologie agilement établie » donnée à Paris Web, ce n’est pas si vrai que ça. A la question « Combien d’entre vous n’appliquent pas d’agilité dans leur entreprise ?« , un bon nombre de mains se sont levées.

Incidemment, la question qu’on a pu entendre était « Quelle est la vraie bonne méthodologie à appliquer ?« .

Et Alexandre Jakubiak tout comme Julien Oger -tenant la conférence citée plus haut- se sont bien gardés de donner une réponse toute faite. Ils ont même prévenus l’audience qu’ils nous présenteraient « la solution qui leur correspondait le mieux ». Ce qui remet beaucoup de choses en perspectives.

Tout d’abord, ils ont voulu bien évidemment éviter le cycle en V. On comprend très vite ses limites avec la fameuse phrase client : « C’est bien ce que j’ai demandé, ce n’est plus ce que je veux. » (i.e. la lenteur de cette méthodologie fait que les besoins du client vont évoluer avant qu’il ait pu mettre la main sur la solution).
Mais rejeter cette méthodologie en bloc n’est pas nécessairement productif non plus : son approche prédictive (bien que trop orientée projet) a ses vertus.

Opposées, la ou les méthodologies agiles, considérée plus réactive intégrant notamment le client plus tôt au processus de développement. Son principal inconvénient reste le nombre de solutions déjà existantes.

Première chose : éviter à tout prix le Big Bang. Mettre en place Scrum -par exemple- dans son ensemble (outils et pratiques) d’un coup au sein de son équipe est suicidaire. Au mieux, on retournera au cycle en V (plus rassurant car déjà connu) en un sprint. Au pire, l’équipe implosera.

La solution choisie a été d’y aller progressivement. Surtout de préalablement faire un tour de l’existant, regarder ce qui serait le plus simple, qui apporterait le plus… et le plus simplement en interne.
Leur conclusion fut de partir de Crystal Clear puis de piocher dans toutes les méthodologies existantes ce qui leur correspondait et les implémenter au fur et à mesure.

Tout ne fut pas simple de l’aveux même de ces messieurs. La méthodologie parfaite n’est qu’utopie. Il faut, dans la mesure du possible, rester souple et ouvert à l’évolution. De même, chaque équipe, chaque société a des besoins différents.
Cela peut être lié à la taille de l’équipe, des projets, des langages utilisés ou même de l’expérience (on fera passer plus facilement de jeunes développeurs à une nouvelle méthodo que des seniors habitués au bon vieux V).

Chez Soft’it, nous utilisons Scrum en interne, notre Scrum. Nous avons dû adapter certaines règles pour que notre fonctionnement soit plus limpide : il n’y a pas de Scrum Master fixe par exemple, il change à chaque Sprint. Cela permet de responsabiliser chaque personne travaillant sur les projets et en plus de ne pas laisser cette pression toujours sur les épaules d’une même personne.

Nous appliquons également plusieurs pratiques de l’eXtreme Programming (XP) : le « Pair Programming« , par exemple, pour les nouveaux arrivants et sur des phases un peu complexes; ou la revue de code (« Code Review ») après chaque story réalisée.
Nous faisons également du testing et avons une usine logicielle pour l’intégration continue. Cependant, la TDD (« Test Driven Development », également part d’XP) n’est pas une obligation chez nous.

S’arrêter à une méthodologie et l’appliquer « By the book », même le cycle en V, est impossible. Le faire est source de frustration ou de goulot d’étranglement bien plus que de facilités dans un projet.

Savoir écouter les besoins en interne et externe, tirer le meilleur de ses retours d’expérience heureux et surtout malheureux, vous guidera bien plus vers votre méthodologie qu’un livre à appliquer à la lettre.

L’agilité contient un principe fondamental : l’amélioration continue. Pensez à réserver du temps pour prendre du recul sur votre organisation, et à construire ensemble la méthodologie qui vous correspond.