Super soirée Beler Soft pour Noël

Par Ionut le 20/12/2011

Cette année Beler a fêté Noël au Berestroika, un pub-restaurant dans le centre du Bucarest, réputé pour sa bonne ambiance. Si on ajoute comme ingrédients une soixantaine de collègues et d’amis extraordinaires, une musique de qualité, un directeur plein de vie, un buffet suédois et beaucoup de bière faite maison selon une recette ancestrale, on obtient comme résultat une soirée inoubliable.

Personnellement, je ne me considère pas bon danseur, mais ce soir, grâce à l’atmosphère, j’ai dansé et j’ai beaucoup dansé, et j’ai passé un hyper bon moment … tous ensemble … et c’était extraordinaire. J’attend avec impatience la fête de Pâques et le prochain Noël, et peut-être qu’on va trouver d’autres raisons pour passer des soirées ensemble, on en trouve toujours.

En attendant, je vous souhaite une bonne santé et « à la votre ! »

Soyez le premier à commenter
 TOP

Faut-il migrer vers .NET 4 ?

Par Tania le 27/10/2011 - Développeur .NET certifié MCP

Première approche

A première vue, .NET 4 ne présente pas un gap significatif par rapport à .NET 3.5. La plupart des grandes nouveautés technologiques ont déjà été introduites dans .NET 3.0 et 3.5.
Je mentionnerai ici en particulier WCF, WPF, WF pour 3.0, et LINQ ainsi que ADO.NET Entity Framework dans .NET 3.5, quand le petit monde du développement a été étonné par les nouvelles possibilités de manipulation des structures de données depuis un langage orienté objet, et par la facilité de générer une couche d’accès à la base de données.
Mais .NET 4 a apporté de nombreuses améliorations de performances. L’une des plus immédiatement visibles est la dimension des fichiers d’installation de la plate-forme .NET sur le poste client (.NET Client Profile). Alors que pour exécuter une application écrite sous .NET 3.5, un utilisateur devait télécharger et installer 255 MB, il suffit maintenant d’installer 29 MB pour une application sous .NET 4.

Calcul parallèle

Des extensions introduites dans cette version de .NET offrent un support performant pour le calcul parallèle, en ciblant les systèmes multi-core et les architectures distribuées. Ont été ainsi inclues des technologies telles que PLINQ, une implémentation parallèle du moteur LINQ, et Task Parallel Library, un composant dont les fonctions permettent de gérer le parallélisme beaucoup plus facilement.

Faciliter le SEO

Concernant ASP.NET on trouve, entre autres, des améliorations pour le SEO (Search Engine Optimisation). Du fait qu’une grosse part du trafic d’un site vient des moteurs de recherche, en optimisant l’adéquation d’un site aux recherches des internautes, on draine plus de visiteurs qualifiés amenés par les moteurs. De même, dans ASP.NET Web Forms, ont été ajoutés quelques contrôles utiles pour l’affichage de graphes.

Remonter le temps

Dans le domaine de l’aide aux développeurs, Visual Studio 2010 qui a été lancé avec .NET 4, offre plusieurs outils améliorant la productivité. Parmi ceux qui me paraissent les plus significatifs, Intelli Trace, simplifie fortement le processus de débuggage. Alors que dans Visual Studio 2008, lors du débuggage, un développeur connaissait le contexte d’un programme à un instant donné et pouvait seulement continuer ou arrêter l’exécution, dans Visual Studio 2010, il peut « remonter le temps » pour analyser les variables et les événements précédant le point de départ du débug.

Tester des projets qui impliquent beaucoup de calcul parallèle est également plus facile, grâce aux outils qui permettent la visualisation des tâches parallèles et des stacks correspondants.
Un point qui peut paraître mineur mais qui se révèle intéressant pour la maintenance : Il est possible de configurer un projet pour cibler une autre version de .NET, c’est-à-dire 2.0, 3.0 , 3.5.

Des templates bien pensés

On trouve dans aussi dans .NET 4 des modèles pour différents types d’applications, par exemple en technologie ASP.NET MVC, ou celles qui intègrent du développement de composants Office ou Sharepoint.

Première conclusion

Quoique les améliorations apportées à .NET 4 ne puissent pas être considérées comme révolutionnaires, elles apportent une grande aide dans divers scénarios qui sont justement ceux qui nous font aimer le métier de développeur. Sans aucun doute, .NET 4 est , pour les nouveaux projets, la technologie à retenir.

Soyez le premier à commenter
 TOP

Services Web : REST face à SOAP

Par cmanole le 04/10/2011 - Analyste - Chef de Projet

Introduction

Rest vs SoapLes services Web sont devenus, depuis quelque temps, la norme de facto pour intégrer des applications internes ou offrir une interface externe aux clients. Il est plus facile de transmettre des données entre différentes plates-formes en utilisant ce moyen; plus facile de composer le message, plus facile à déboguer, plus facile à comprendre. Ainsi vous pouvez intégrer des parties du système écrites en Java, .NET, PHP etc. en utilisant un protocole bien connu et des messages textes (généralement en XML). Les codages binaires (c’est à dire spécifiques, non-textuels) sont véhiculés plus rapidement, mais elles sont réservées à certaines plateformes. Vous ne pouvez pas utiliser des formats binaires .NET pour communiquer avec une application Java. Voici ce dont il s’agit avec RPC et, plus récemment, avec SOA1 : l’intégration de modules via des services Web.

Points communs

Les deux protocoles2 fonctionnent parfaitement avec HTTP3 , le protocole de transfert de données entre clients et serveurs utilisé sur le Web. HTTP est un protocole simple, bien connu, donc cela peut être considéré comme un avantage : facile à comprendre, implémenté sur la plupart des plateformes, il n’est pas d’habitude bloqué par les pare-feu.

Les messages sont dans le format XML4 , un format texte facile à comprendre.

Pourquoi choisir REST ?

REST est léger et simple : les messages sont courts, faciles à décoder par le navigateur et par le serveur d’application.

REST est auto-descriptif) : vous pouvez naviguer à travers ses ressources comme vous le feriez avec une page Web. Il y a une URL intuitive unique pour chaque ressource. On peut facilement en déduire la structure des ressources sans avoir besoin de beaucoup de documentation.

REST est « stateless » (il n’est pas adapté aux transactions longues et complexes) : il est parfait pour les opérations simples (créer, lire, mettre à jour, effacer).

REST peut être géré en cache (antémémoire) : les ressources simples, identifiables sont aussi faciles à mettre en cache qu’un article sur un site Internet. L’adaptation aux variations de charge et la performance que cela apporte ne doivent pas être négligées.

Pourquoi ne pas choisir REST ?

REST est généralement critiqué pour son manque de complexité exigée pour les transactions d’affaires : sécurité, support transactionnel.

REST est considéré en quelque sorte comme un artifice du « web 2.0″ plutôt qu’une vraie solution d’entreprise.

Pourquoi choisir SOAP ?

SOAP a été conçu comme un mécanisme d’appel de procédure distante. On utilisera SOAP en toute confiance pour appeler une méthode sur un autre serveur et recevoir la réponse dans un mode contractuel.

SOAP supporte le transactionnel : il supporte les transactions ACID, de sorte qu’il peut gérer un commit à deux phases sur des ressources transactionnelles distribuées (WS – Atomic Transactions ).

SOAP a quelques caractéristiques de sécurité supplémentaires : il supporte l’identification à travers des intermédiaires, plus que SSL ne peut offrir.5

SOAP est formel : les méthodes à distances et leurs résultats sont bien spécifiées via des contrats.

SOAP est fiable : il dispose des mécanismes pour garantir la fiabilité de la transmission et de la réception de données.

SOAP offre de nombreux outils : étant donné qu’il a d’abord été publié par Microsoft en 1998, beaucoup de fournisseurs ont créé des outils au fil des années. Aussi la plupart des plates-formes de développement sont pourvues d’un moyen facile d’exploiter une fonction distante via SOAP.

Pourquoi ne pas choisir SOAP ?

SOAP a été à l’origine imaginé pour faire un protocole RPC qui passe les pare-feu (remplaçant donc le DCOM de Microsoft avec XML sur HTTP).

SOAP est considéré trop complexe et verbeux pour les besoins ordinaires.

SOAP est d’habitude utilisé dans des framework propriétaires. Bien que cela fournisse un point d’entrée apparemment plus facile (quelquefois basé sur un assistant) pour créer des services Web, sa complexité rend ardu le débogage des messages, donc tout l’avantage du XML lisible par l’utilisateur est perdu assez vite.

SOAP nécessite une compréhension claire des APIs spécifiques au site. Son utilisation est comparable à l’utilisation d’un nouveau framework. Il demande du temps et de la documentation.

L’interopérabilité de SOAP a diminuée au fil des années, avec des normes différentes et les implémentations des fournisseurs de logiciels. Désormais il est certain que REST est de loin plus interopérable.

Dernières réflexions

Il est généralement admis que l’objectif de SOAP était seulement d’aller à mi-chemin dans l’utilisation du Web comme un modèle pour la distribution de données : protocole HTTP et format XML. REST a poursuivi le chemin en ajoutant le dernier élément qui manquait à SOAP : le simple et efficace schéma d’adressage URL au sein de l’espace de nommage global du Web. N’importe qui sachant utiliser le Web peut utiliser REST. C’est aussi simple que cela.

Une tendance claire dans l’industrie est l’augmentation des APIs REST (les géants du Web, Yahoo, Google, Amazone et eBay offrent à leurs clients des APIs REST). SOAP a commencé à s’effondrer sous son propre poids et restera probablement comme une solution réservée à certains scénarios d’entreprises spécifiques (tels que les transactions bancaires).

Beaucoup de caractéristiques pour lesquelles SOAP est préféré existent en fait dans REST (bien que cela prenne un peu plus d’effort initial pour les mettre en oeuvre) : la sécurité via HTTPS, l’authentification via basic auth, les sessions via les cookies. Cependant, jusqu’à ce que ces besoins et leurs solutions deviennent bien connus et faciles à aborder par les développeurs, SOAP aura sans aucun doute sa place.

Dans la plupart des scénarios, REST est la voie à prendre. Considérez seulement SOAP si vous avez besoin (ou si vous croyez que vous avez besoin) de certaines fonctions WS-* spécifiques (transactions distribuées, fédération d’identification, routage de message).


1 Il y a une différence subtile: alors que RPC traite de l’appel de fonctions distantes, SOAP s’occupe plutôt de transférer des messages.

2 Techniquement, REST est seulement une architecture, pas réellement un protocole alors que SOAP est un Framework de protocole, plutôt qu’un protocole concret.

3 SOAP peut travailler aussi sur d’autres protocoles, tels que SMTP, bien que ce soit rarement vu en pratique. REST fonctionne seulement sur HTTP.

4 REST n’est pas limité à XML: beaucoup d’implémentations utilisent JSON, un format encore plus léger, moins verbeux.

5 Bien qu’Open ID devienne une alternative pour la fédération d’identification dans le monde de REST.

Soyez le premier à commenter
 TOP

Apple Push Notification sur iPhone : informez instantanément vos cibles

Par Philippe le 03/10/2011 - Dirigeant Associé


Pensez au Push pour vos apps d’entreprise

Promotions, agendas, alertes …. votre système d’information gère de nombreux événements qui intéressent vos collaborateurs, vos clients ou vos partenaires. Vous souhaitez leur en faire part de façon efficace et rapide, pour autant, vous ne voulez pas être contraints de collecter leur numéro de téléphone. La solution ? Une app iPhone intégrant les notifications Push !

Notification Push : principe et réalité

Une notification Push est une fonctionnalité de votre application mobile, gérée sur un serveur spécifique qui est mis en liaison avec l’infrastructure du fabricant de l’appareil, telle que l’Apple Push Notification System.

Concrètement, quand un utilisateur reçoit une notification Push, il voit apparaître sur son mobile une pastille semblable à celle d’un SMS, contenant un résumé de l’information, avec deux boutons supplémentaires : un bouton de type « Ignorer » et un bouton de type « Accéder ».
Le bouton « Accéder » lance l’application associée au message. Généralement il s’ensuit une connexion à un serveur permettant de récupérer les données annoncées dans le message : mise à jour d’un agenda, présentation d’un tableau de bord, graphique montrant une opportunité immédiate sur un marché boursier, …

Notification Push : plus direct que le mail et le SMS

La notification Push est une alternative plus que séduisante, à l’envoi de mail ou de SMS.

Parce que le mail est rarement utilisé en temps réel : dans son utilisation la plus courante, il nécessite d’ouvrir une boite de réception et de prendre connaissance d’un message noyé dans une pile. Au mieux il est lu tardivement, au pire il est bloqué dans la boîte anti-spams.

Quant au SMS, il peut servir d’alerte, certes, mais il est perçu comme intrusif car le destinataire ne peut pas le bloquer sélectivement, et surtout, sa réception nécessite d’être connecté à un réseau mobile. Ce qui n’est pas toujours le cas.

Notification Push : les avantages

  • Le Push s’adresse à un numéro d’appareil et non à un numéro de téléphone. Il est donc reçu même en absence de réseau GPRS, du moment que le mobile est connecté à Internet. C’est particulièrement intéressant pour les iPad, qui sont largement utilisés en Wifi, sans carte SIM. Même remarque pour les iPod Touch.
  • Le Push n’est pas intrusif puisque l’utilisateur doit avoir accepté sa réception pour l’application considérée, et peut le suspendre à son gré.
  • Le Push permet d’alerter même lorsque l’application associée est fermée ou qu’une autre app, ou un appel téléphonique, sont actifs.
  • La pastille de  Push peut inclure une petite image spécifique à l’application; très pratique pour saisir immédiatement le sens du message et son urgence.
  • L’envoi de notifications Push est gratuit, contrairement aux SMS.
  • Le Push permet une réaction contextuelle rapide : l’utilisateur touche simplement la pastille du message pour accéder à la totalité de l’information.

Apple Push Notification System (APNS) :  quelques limitations

  • Les notifications Push ne conviennent pas pour les alertes de sécurité critiques, car Apple ne garantit pas l’acheminement. Le message doit essentiellement prévenir que des informations fraiches sont disponibles, sans les véhiculer intégralement lui-même. Notons qu’il en est de même pour les SMS : livraison du message non garantie, basée sur la politique du best effort.
  • Le contenu visible du message est limité à environ 230 caractères (256 moins des identifiants).
  • Du fait que le Push est géré par le fournisseur de l’OS, l’APNS est limité aux possesseurs d’iPhone, iPad, iPod Touch. Donc pour s’adresser à plusieurs marques de mobiles, il est nécessaire de développer une application et son serveur de Push pour chaque OS cible (Android, Blackberry, Windows Mobile 7).

Interface avec le Système d’Information

Apple : Push notification depuis un provider jusqu'à l'app

Apple : Push notification depuis un provider jusqu'à l'app


En tant que spécialiste de développements sur iPhone et Android, Beler Ingénierie met en oeuvre votre système de Push Notification, en assurant les trois niveaux de développement :

  • l’application iPhone ou Android, bien évidement
  • le développement spécifique d’interfaçage avec votre Système d’Information
  • la programmation du serveur de Push, encore appelé « provider », et l’intégration de sa base de données dans votre architecture.

Le rôle du provider de Push consiste à enregistrer les appareils supportant l’application mobile et à assurer la liaison avec les serveurs du fabricant : Apple, ou Google pour Android, … Nous le développons dans le langage utilisé sur les serveurs Web de l’entreprise, en général PHP ou C#, et il est personnalisé selon le type d’application.

Soyez le premier à commenter
 TOP

Le développement 3-tiers en ASP.NET 4 : une approche moderne

Par cmanole le 04/08/2011 - Analyste - Chef de Projet

Séparer les problématiques : intêret principal du développement 3-tiers

3-tiersPourquoi ? Parce qu’il est plus facile de gérer le développement d’un grand projet en divisant l’application en modules; et donc une équipe de développeurs en sous-équipes, chacune se voyant confier la responsabilité d’un module de l’application.

On peut se passer de cette organisation dans le cadre de petites applications. En revanche, les applications moyennes ou importantes sont pratiquement impossibles à gérer sans appliquer des règles claires.

Avec le temps, on a vu émerger certaines tendances adoptées par l’industrie et dont le but est précisément de gérer la complexité au sein des applications ASP.NET. Mais l’architecture et le développement d’applications ASP.NET modernes et professionnelles ne peuvent être menés à bien sans utiliser les expériences accumulées au fil du temps par la communauté.

WCSF (Web Client Software Factory) : l’alternative

Microsoft a monté une équipe dédiée à la création de modèles pour les architectes d’applications et les développeurs. Le groupe Modèles et Méthodes fournit à la communauté des développeurs ASP.NET professionnels deux frameworks qui capitalisent des années d’expérience des meilleures sociétés de développement au niveau mondial : La Web Client Software Factory (WCSF) et l’Enterprise Library. La façon dont ces deux librairies s’utilisent dans une conception 3-tiers dépend du type de projet. Elles sont en fait complémentaires au modèle 3-tiers, et participent à la tendance actuelle de dépasser une approche purement 3-tiers, vu que la logique d’interface devient de plus en plus encombrée.

Web Client Software Factory propose une alternative à l’organisation induite par ASP.NET MVC, sur les aspects de la testabilité et de la séparation approfondie des problématiques. En prenant en considération le classique ASP.NET (WebForms), on peut parvenir à une modularité raisonnable, en suivant les modèles WCSF, surtout pour les sites Web transactionnels métier (à l’opposé de MVC qui convient mieux aux sites Web orientés contenu).

Le point majeur de la technologie ASP.NET MVC est le concept Model View Controller : il permet de diviser l’interface utilisateur en modules à l’intérieur de couches logiques, supprimant ainsi les fichiers source d’interface utilisateur volumineux, caractéristiques des projets ASP.NET classiques et connus pour la lourdeur de leur maintenance.

Bien que cela ne soit pas aussi simple qu’ASP.NET MVC, l’utilisation du classique ASP.NET conjointement au modèle MVP (Model View Presenter) présente beaucoup d’avantages qui ne doivent pas être négligés pour les projets importants.

S’ils conjuguent cet atelier et leur savoir, les développeurs professionnels ASP.NET en entreprise n’ont plus d’excuse si l’organisation de leurs projets présente des failles : finies les interfaces utilisateurs lourdes, compliquées (où l’essentiel de la logique est intégrée aux fichiers cachés derrière le code des pages aspx) !

C’est ainsi que les efforts faits au début pour structurer le code source deviendront payants : il est désormais possible d’avoir une base de code gérable, comprise par tous les nouveaux développeurs qui viendront rejoindre l’équipe. Elle assure également la cohérence entre projets, où chaque application reposera sur un socle commun.

Comment est-ce lié au 3-tiers ?

3 tiers et MVP (Model View Presenter) sont des modèles complémentaires que l’on retrouve ensemble dans la plupart des projets ASP.NET. Pour obtenir une idée de MVP, voici une cartographie des objectifs des modules dans trois architectures ; 3 tiers physique, 3 tiers logique (du point de vue de l’application) et MVP (le modèle utilisé dans WCSF).

3-Tier physique
3-Tier Logique
MVP module
Navigateur Web
Couche de présentation
View (V)
Serveur d’applications
Couche business
Presenter (P)
Serveur de BD
Couche d’accès aux données
Model (M)

Attention : ce tableau est simplifié à l’extrême afin d’avoir une idée simple du fonctionnement 3-tiers.

Enterprise Library : pour suivre les best practices

Au-delà de la simple séparation de modules en composants 3 tiers, il existe également un autre besoin.
L’autre outil incroyablement utile pour organiser les aspects de l’application réside dans l’utilisation des blocs applicatifs standards offerts par Microsoft. L’équipe Patterns et Practices a mis au point la 5ème version de la librairie destinée au développement des applications d’entreprise sous Windows : Enterprise Library. Ainsi, la couche métier et la couche d’accès à la base de données (les niveaux 2 et 3 de l’architecture 3 tiers) suivent solidement les bonnes pratiques de l’industrie pour que rien ne soit laissé sans surveillance. En outre, la « plomberie » de chaque application peut être développée de manière standard et appropriée, en utilisant les autres blocs :

• Le bloc de cache qui optimise le temps de réponse en gérant les données les plus souvent utilisées, pour diminuer les pics de trafic de la base de données
• Le bloc de cryptographie, qui gère efficacement le cryptage des informations sensibles
• Le bloc de journalisation qui aide les développeurs et les équipes IT lors des diagnostics
• Le bloc de validation, la manière commune pour créer et utiliser des règles de validation pour les objets métiers.

Il existe également des blocs, spécialisés pour les architectures et les scénarios professionnels : Unity for DI (Dependency Injection)/IoC (Inversion of Control), Policy Injection for AOP (Aspect Oriented Programming – implémentant des notions transverses – sécurité, cache, journalisation – dans toute l’application).
Ces blocs agissent comme des plugin : ils peuvent être configurés, remplacés, modifiés en fonction des scénarios métiers envisagés par le client et l’équipe de développement.

Conclusion

ASP.NET 4.0, conjointement à Visual Studio 2010 et au framework .NET 4.0 bénéficient des dernières versions, modernisées du groupe Modèles et Méthodes de Microsoft. En tirant parti de ces solutions, les équipes de développeurs seront sûres de suivre les meilleures pratiques de l’industrie lors du développement d’applications Web structurées, évolutives, et faciles à maintenir.

Beler Ingénierie : ne pas laisser de place au hasard.
Les développeurs de Beler essaient en permanence d’améliorer leurs connaissances autour des dernières technologies. C’est d’autant plus important que les architectures et les tendances s’empilent au gré des itérations des nombreuses technologies applicatives.

Soyez le premier à commenter
 TOP

Intêret des contrôles tierce partie

Par Malkom le 12/06/2011 - Chef de projet certifié MCP sur .NET

Diriger des projets de développement de logiciel consiste souvent à évaluer des risques.

Il n’est pas facile de planifier un projet et, en général, les équipes de développement rencontrent des retards à cause de certains aspects qu’elles ont oublié de prendre en compte pour diverses raisons. On peut dire que dans l’évaluation d’une tâche, on doit toujours intégrer le risque de difficultés imprévisibles : facteurs techniques, dialogue entre individus, etc… La plupart du temps une bonne idée consiste à opérer un transfert de risque, c’est-à-dire à éviter les aléas du développement, et donc supprimer autant que possible les nombreux facteurs qui peuvent aller de travers et causer des retards coûteux.

C’est ainsi qu’en cours de développement d’une application, les programmeurs et les responsables se retrouvent confrontés à ce choix : développer from scratch ou acheter des composants. Quelques aspects sont à prendre en compte lors d’une telle décision : l’expérience de l’équipe, la difficulté du problème technique, la connaissance du domaine fonctionnel, etc…

Actuellement, il y a plusieurs sociétés spécialisées dans la création de composants : DevExpress, Telerik, Infragistics, pour ne citer que celles dont j’ai déjà eu l’occasion d’expérimenter les produits. Leurs composants permettent de réaliser avec une énergie raisonnable des graphiques, des tableaux, des menus, des agendas, des barres d’outils, des listes, et tout un tas d’autres fonctionnalités qu’une application se doit de présenter.  Ces composants ciblent toutes les technologies Microsoft : ASP.NET, ASP.NET MVC, Windows Forms, WPF, Silverlight. DevExpress propose même des contrôles pour Delphi et C++ Builder.

Aussi le client s’attend-il à ce que toute demande spécifique sur l’interface utilisateur puisse être résolue soit avec les contrôles par défaut, soit avec un composant tiers. Et il est vrai que la plupart des commodités d’interface comme les vues de détail, les tris, l’auto-remplissage, les filtres, les changements de perspective, ont déjà été pris en charge dans plusieurs versions de contrôles.

Avantages :

  • La phase d’apprentissage et plutôt légère puisque les développeurs accoutumés à travailler avec des contrôles standard comprennent rapidement comment utiliser des contrôles de tierce partie.
  • On trouve des exemples de code pour chaque composant afin d’aider les utilisateurs à tirer bénéfice des produits le plus rapidement possible.
  • Fréquentes mises à jour des bibliothèques.
  • Plusieurs sociétés (en particulier DevExpress) sont renommées pour la qualité de leur support technique.
  • Moyennant un coût supplémentaire, les développeurs peuvent disposer du code source, grâce auquel il est plus facile de résoudre rapidement un bug ou de modifier certains comportements sans les délais inhérents au support technique du fournisseur.

Avec un peu d’expérience, il devient vite évident qu’il vaut mieux fouiller dans les sites Web des fournisseurs de composants plutôt que tout développer de zéro. C’est assurément moins coûteux que documenter une analyse, développer, débugger, tester encore et encore. En utilisant des contrôles tiers, il est plus facile de se focaliser sur les fonctionnalités métier du projet, de passer du temps à développer les caractéristiques originales de l’application, plutôt que de travailler à résoudre les innombrables difficultés techniques sous-jacentes à chaque demande fonctionnelle.

En conclusion, si vous trouvez un contrôle tiers qui semble répondre à votre besoin, téléchargez la version de démonstration, testez-la, et réalisez un petit prototype pour le présenter au client. Si ça correspond à peu de choses prés à sa demande, ce sera à coup sûr meilleur marché de l’acquérir au lieu de développer vous-même la fonctionnalité.
D’un autre côté, si vous arrivez à la conclusion que le contrôle nécessite de sérieuses adaptations pour répondre au besoin, il vaut certainement mieux développer entièrement la fonction en s’appuyant éventuellement sur un simple contrôle par défaut du framework .NET.

La prochaine fois, j’approfondirai l’intêret du data grid de DevExpress.

Soyez le premier à commenter
 TOP

HTML 5 – Mon standard du Web !

Par Daniel le 10/06/2011 - Directeur Associé de Beler Soft

Les jeux sont faits !

Le W3C a tranché : il existe enfin un standard, et même un bon, pour le Web, le HTML 5.

html5-gamesIl y a de plus en plus de normes dans tous les domaines : des pneus automobiles jusqu’aux chargeurs de téléphones portables. Il eût été dommage que le développement échappe à cette tendance : voila des années que la communauté des développeurs demandait une normalisation pour l’affichage des pages Web.
Mais face à l’explosion de l’Internet, les géants de l’édition ont toujours essayé d’imposer leur interprétation du HTML, espérant ainsi rallier le maximum d’internautes à leur navigateur et surtout donner l’impression qu’il s’agissait du meilleur possible.

Les différences entre les navigateurs, telles que l’alignement des éléments, l’ordre d’affichage des objets superposés, le déclenchement des évènements… transformaient parfois la programmation Web en cauchemar : « Ça marche un IE 8 et pas sur Firefox !?». Résultat : duplication de code, fonctions spécifiques selon les navigateurs cibles, avec les temps et les coûts associés.

Ces jours-ci, plus de 15 ans après sa création, le consortium W3C a établi deux dates clés : mai 2011 «the last Call » et juillet 2014, la recommandation officielle du langage, pour tous les dispositifs, systèmes d’exploitation et navigateur. Même si 2014 peut paraître encore éloigné, on peut examiner la réaction impressionnante des géants du marché.

Les géants s’adaptent : HTML 5 est de toutes les releases

Déjà en 2010, Google avait sorti plus de cinq versions de Chrome autour de HTML 5 culminant avec la version 10 du 8 mars 2011, qui intègre deux petits jeux sympatiques en HTML 5.

Le 14 mars 2011, Microsoft a officiellement lancé Internet Explorer 9, avec d’importantes améliorations sur les performances Java Script, le rendu des pages et surtout, sur la compatibilité et les performances en HTML 5.

Quelques jours après, Mozilla sort la version 4.0 de son Firefox (avec HTML 5 évidement !) qui fait exploser les compteurs : 40 millions de téléchargements dans moins d’une semaine.
Conclusion : cette fois, on a bien un standard et c’est HTML 5.

HTML 5 : au-delà du standard, des nouveautés très intéressantes

- Support natif audio / vidéo par des tags spécifiques
- Stockage local des données (localStorage) : plus facile a utiliser et plus rapide que les cookies !
- HTML5 Embedded SQLite Database (aussi connu sous le nom de Web SQL Database) : ou comment manipuler des données comme dans un SQL classique à partir de JavaScript !
- Les CANVAS, pour designer à volonté : des points, des lignes, des graphiques, transformer et manipuler des images directement dans le code HTML/JavaScript (Attention Flash et Silverlight !)

Toutes ces nouvelles fonctionnalités donnent la possibilité de créer de véritables applications en HTML 5, qui fonctionnent même en mode offline.
Chez Beler nous avons déjà développé des Web app pour iPhone en HTML 5 dans le domaine médical, dont une dédiée au suivi d’une pathologie rare. L’intêret est que le même code tourne sur iPhone (Web App) et peut être accédé depuis le serveur par d’autres smartphones via leur navigateur. Les mises à jour sur les évolutions des critères de diagnostic sont immédiates et ne font pas l’objet d’une nouvelle version sur l’App Store.

HTML 5 serait-il donc le gagnant face à Flash et Silverlight ?

En effet, pourquoi encore installer un add-on alors que le browser lui-même est devenu suffisamment puissant pour faire le travail ? Même si cela parait tout-à-fait possible, l’affirmation semble prématurée. D’autant qu’Apple refuse catégoriquement d’intégrer le support de Flash/Silverlight  sur les iPhone/iPad, alors que HTML 5 est déjà géré par Safari.

Et la communauté .NET ?
Elle a aussi réagi très rapidement pour ne pas manquer ce rendez-vous avec HTML 5 : avec Visual Studio 2010/2008 équipé de l’outil HTML 5 Intellisense, on dispose avec  .NET 4 Framework et le ASP.NET MVC HTML5 Toolkit, d’une très bonne trousse à outils pour créer des applications Web puissantes, robustes et riches.

Alors lançez-vous en HTML 5 !

Soyez le premier à commenter
 TOP

ASP.NET: Web Forms, ou MVC?

Par Vlad le 29/05/2011 - Chef de projet - Architecte Web

Ca y est, votre entreprise veut créer son prochain produit pour navigateurs et vos développeurs vous affirment dans un premier temps «On devrait utiliser ASP.NET» pour vous asséner ensuite «non plutôt MVC». >

Sachant que les deux solutions sont des technologies .NET publiées non moins toutes les deux par Microsoft, c’en est à se demander si la question est légitime : est-ce qu’on ne devrait pas simplement utiliser celle dont on peut tirer le meilleur parti chaque fois que c’est possible ?

Pourquoi utiliser Web Forms ?

ASP.NET Web Forms est livré avec .NET, et pratiquement tout le monde l’appelle, à juste titre, ASP.NET.
Contrairement à l’ASP classique il est composé de contrôles, et il imite le développement Windows Forms. Avec tous ses avantages et ses inconvénients.

Vous pouvez concevoir votre application comme une application bureautique événementielle et dynamique, et vous le ferez rapidement en utilisant les contrôles existant ou en intégrant ceux des parties tierces.
ASP.NET est recommandé pour les applications professionnelles traitant des volumes important de données, car vous passerez l’essentiel de votre temps à coder en C# ou en VB.NET côté serveur, développement qui n’exige pas de peaufinage en Javascript.

ASP.NET Web Forms convient donc très bien, pour la migration d’applications bureautiques en mode saas.

Inconvénients : perte de contrôle et abstractions

La perte de contrôle sur l’affichage du code HTML a pour conséquence un support médiocre des standards à venir (par exemple, des balises dégradées en HTML 5 seraient toujours affichées par les contrôles existants), et l’existence de contrôles dans les pages peut rebuter certains concepteurs de sites web.

L’abstraction dynamique impliquant une baisse de performance (des volumes importants Viewstate transférés entre le client et le serveur à chaque clic), ces applications conviennent mieux aux développements Intranet. Si vous ne le souhaitez pas, il vous faudra travailler activement autour de Viewstate.

L’abstraction « événementielle » induit qu’il y a peu de chance de trouver, sur votre page web, des éléments à mettre en favoris (des éléments possédant leur propre URL), et si c’est le cas, l’URL peut ne pas fonctionner plus tard en cas de perte de son état dynamique.

Et ASP.NET MVC ?

ASP.NET MVC (Modèle Vue Controleur) n’est pas le premier framework pour ASP.NET [1] et il est la preuve qu’ASP.NET est une plate-forme très extensible. Il est cependant le seul qui soit intégralement supporté par Microsoft, intégré dans Visual Studio.

Model-View-Controller est le nom d’un modèle logiciel utilisé pour les développements d’interfaces graphiques, capable d’analyser très convenablement le modèle requête/réponse passif HTTP.

Pourquoi utiliser ASP.NET MVC ?

Les URL : Vous pouvez démarrer le site en concevant des URL optimisées pour les moteurs de recherche, sans extension et non liées à la manière dont vos fichiers sont stockés sur le serveur. Elles peuvent servir de signets, à moins que vous vous y opposiez de manière active.

Les Vues : Elles sont beaucoup plus faciles à concevoir car elles ne contiennent aucune référence à des contrôles (pas de balises cachées).

En même temps que les vues faciles à concevoir, vous pouvez choisir votre framework Javascript : Microsoft Ajax, jQuery ou tout autre framework maitrisé par vos développeurs. Vous avez les mains libres.

C’est pourquoi MVC parait être le meilleur choix pour les sites Internet grand public qui ne contiennent pas des formulaires importants à traiter avec des règles métier, ou qui ne demandent pas d’analyser, trier et filtrer des jeux de données.

Inconvénients : code à écrire et absence de contrôles

Pouvoir utiliser tout type de framework Javascript signifie qu’en fait aucun n’est intégré : il vous faudra écrire du code, ce qui vous prendra plus de temps.

Ne pas posséder de notion de « contrôles » signifie également qu’il vous faudra plus de temps pour développer une application événementielle. Dans ce cas, Web Forms est un meilleur choix.

Conclusion

Etudiez les deux, utilisez celui qui conviendra le mieux !

[1] http://www.castleproject.org/monorail/
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

Soyez le premier à commenter
 TOP

(English) 3 tier architecture: What is it? Do we need it?

Par cmanole le 05/05/2011 - Analyste - Chef de Projet

Désolé, cet article est seulement disponible en English.

Soyez le premier à commenter
 TOP
QR Code Business Card