Une démarche naïve de réalisation de tests de performance est d’effectuer des améliorations successives sur un système donné, donc d’avoir un processus pseudo-itératif. Donc, pourquoi ne pas se baser sur les processus développés dans les méthogologie Agiles, voir même d’utiliser les cycles d’améliorations continues issue du Lean.

En effet, on peut très facilement se rapprocher de la roue de Deming, appelée plus communément la démarche PDCA : Plan, Do, Check, Act.

Le but des tests de charge est de trouver les points faibles d’une architecture dans le but de l’améliorer : performance, stabilité sous charge, coût, etc. On rapproche donc les étapes du PDCA avec un processus de tests de charge :

• Le P (ou plan) a pour but d’établir, préparer et de planifier un plan d’action. Que doivent mesurer, améliorer nos tests pour cette itération.
• Le D (ou do) est la phase de faire, celle où on effectue les tests à proprement parler.
• Le C (ou check) est le moment où l’on vérifie les résultats renvoyés par nos tests. C’est aussi dans cette phase que l’on se préoccupe du rapprochement et de l’agrégation des métriques recueillies dans la phase précédente.
• Le A (ou act) sert à améliorer le système que l’on test. C’est la phase d’optimisation.

(Lire la suite…)

La délégation de tâches en asynchrone est un moyen efficace d’alléger la charge que subissent nos systèmes. En effet, de nombreux cas d’utilisation ne nécessitent pas d’être exécutés de façon synchrone lorsqu’un utilisateur effectue une action ou qu’un événement extérieur intervient.

Par exemple, lorsqu’il n’est pas nécessaire de restituer la dernière version des données et que le traitement avant restitution est coûteux en ressources, il est possible de renvoyer des données préalablement mises en cache et de déporter en asynchrone une tâche de rafraîchissement de ce cache.

Un autre exemple concerne les systèmes qui mêlent des requêtes fortement consommatrices en ressources (CPU, mémoire, …) et des requêtes peu consommatrices pour lesquelles on va vouloir garantir une latence faible même lorsque des requêtes consommatrices sont en cours de traitement. Pour cela, déléguer les traitements coûteux à des workers via une file de messages peut aider à garantir des temps de réponse faibles pour les autres requêtes. Cette séparation est d’autant plus importante sur des systèmes qui s’appuient sur des technologies monothreadées telles que Ruby ou NodeJS (ce dernier a néanmoins l’avantage de ne pas consommer de ressources/process lorsqu’il effectue des I/O).

Pour résoudre cette problématique de délégation de tâches, on utilise habituellement une solution comme ActiveMQ ou RabbitMQ. Seulement, lorsqu’il est nécessaire :

• d’être tolérant à la panne
• d’être scalable que ce soit en ajoutant des publishers (qui soumettent les tâches asynchrones) ou des workers (qui consomment et exécutent ces tâches)
• de pouvoir intégrer des systèmes hétérogènes s’exécutant sur différentes plateformes (Java, Ruby, NodeJS, C, …)

aucune de ces deux solutions ne permet de satisfaire l’ensemble de ces critères. Cet article présente une solution possible à base de ZeroMQ, écrite en NodeJS et utilisée pour traiter les deux exemples précédents.
(Lire la suite…)

La tendance des bus de messagerie est aujourd’hui de proposer des modes de déploiement distribués au delà de l’architecture master/slave qui se veulent simple à mettre en oeuvre et dynamique.
ActiveMQ n’est pas en reste et offre la possibilité de créer un cluster de brokers qui savent intégrer un nouveau broker et détecter la perte d’un broker. Ces informations peuvent ensuite être transmises aux clients connectés pour se reconnecter sur un autre broker du cluster pour mieux répartir la charge ou tout simplement car ils étaient connectés à un broker qui vient de tomber.

Nous verrons comment ces fonctionnalités permettent d’obtenir un système tolérant à la panne et quels sont les limites à prendre en considération.

Voyons tout d’abord la gestion du cluster entre brokers.
(Lire la suite…)

Dans une première partie, nous avons abordé la notion d’index et la différence entre une branche locale et une branche distante. Une fois les notions d’index et de branches locales et distantes bien comprises, il est possible d’aborder des fonctionnalités plus avancées de Git.
(Lire la suite…)

Nous avons déjà parlé de Git sur ce blog, sur la notion de DVCS, sur son utilisation pour réaliser un build incassable, et sur ces formidables outils de merge que sont les DVCS. Mais qu’en est-il des « Git va vous sauver la vie », « Git c’est trop cool, comment je faisais avant ? » ou des « Git c’est trop compliqué, j’comprends rien, pourquoi on n’utilise pas Subversion ? ». Qu’en est-il de l’utilisation de Git dans un projet ou Subversion aurait pu « faire l’affaire » (ie. un dépôt centralisé, une seule équipe de développeurs dans un même bureau) ?
(Lire la suite…)

Après la démocratisation d’Ajax (ie. requêtes HTTP asynchrones en Javascript), plusieurs techniques ont été élaborées afin de permettre le push de données depuis le serveur toujours en utilisant HTTP. C’est grâce à ces techniques que l’on reçoit nos mails dans une application web sans avoir à cliquer sur le bouton « Refresh », que les applications de chat sont possibles sans plugin tierce (Flash, Java, …), etc. Le W3C et l’IETF ont spécifié une API Javascript et un protocole nommé Websocket. Ce protocole connecté est adapté à l’envoi de données dans les deux sens et évite de détourner HTTP de son usage initial (ie. un protocole déconnecté sans état).
(Lire la suite…)

Le framework Flex permet d’écrire très rapidement des IHM fonctionnelles, notamment grâce au langage MXML. Celui-ci permet effectivement de décrire l’interface avec peu de lignes de code.

Seulement, voilà, une fois l’étape du POC passée, les fichiers MXML s’accumulent, le code ActionScript s’insinue petit à petit dans le code MXML pour implémenter les handlers d’événements, les appels de services, la logique métier. Après quelques temps, il devient de plus en plus difficile de savoir d’où viennent les données affichées (ie. quel code a mis à jour la donnée ?), d’où provient un appel de service (surtout d’où proviennent les valeurs des arguments de cet appel).

Dans cet article, nous verrons quelques bonnes pratiques permettant d’assurer la maintenabilité d’une application Flex.
(Lire la suite…)

Alors que Hibernate est très largement répandu dans les projets Java pour accéder à une base de données relationnelle, il arrive que l’utilisation en direct de l’API JDBC reste pertinente.
En effet, il demeure intéressant de rester en SQL « pur » plutôt que de sortir la grosse artillerie lorsque :

• les données de la base sont plutôt pensées tuple qu’objet : le modèle de données ne présente pas de relations complexes entre
  elles.
• lors de la reprise d’un existant, il arrive que du code métier soit implémenté en PL/SQL par exemple. Les requêtes peuvent alors faire régulièrement appel à ces fonctions.

Lorsque nous sommes arrivés sur un projet de migration d’une application existante qui cumulait les contraintes précédentes (surtout beaucoup de procédures stockées), JDBC nous semblait une bonne idée. Seulement voilà, lorsqu’il a fallu écrire la requête à 60 critères de recherche qui étaient présents selon les critères que l’utilisateur avait entré sur sa belle IHM, je me suis posé la question de comment faire pour construire ladite requête.
Fallait-il faire des tas de « if » pour tester la présence d’une valeur dans chacun des critères de recherche ? Faire les jointures nécessaires selon les critères fournis ? J’ai entraperçu quelque chose de pas très sympa à écrire et à maintenir.

Pourquoi ne pas encapsuler le choix d’ajouter les clauses SQL à ma requête derrière une API qui le ferait selon les valeurs que je lui donne ? Et puis pourquoi pas faire ressembler cette API à du SQL pour pas inventer une nouvelle API ?
(Lire la suite…)

Alors que Macromedia (racheté en 2005 par Adobe) était parti seul devant, début 2004, dans le développement d’applications RIA en sortant la première version de Flex, voilà que fin 2006 (plus de 2 ans après donc), Microsoft dévoile une première version de sa réponse à Flex nommée Silverlight. Seulement, cette première version n’était là que pour « occuper le terrain » car elle restait encore très loin derrière Flex qui passait à peu près au même moment en version 2. D’ailleurs, à peine cette première version de Silverlight sortie, Microsoft annonçait déjà les premières versions Alpha de la v2 qui viendrait avec une machine virtuelle plus performante, une version allégée de la CLR .Net, en lieu et place du moteur Javascript de la v1. Alors que la v2 est sortie en fin d’année dernière, la v3 sort seulement un peu plus de 6 mois après. Il semble donc que malgré son retard, Microsoft produit à un rythme impressionnant de nouvelles versions de Silverlight en apportant à chaque fois un nombre non négligeable de nouvelles fonctionnalités. Même si Adobe continue de faire évoluer sa plateforme et s’apprête à sortir la version 4 d’ici la fin de l’année, les deux technologies sont aujourd’hui au coude à coude.
Dans cet article, nous ferons un tour panoramique de ces deux technologies afin de pointer leurs similitudes et différences.

(Lire la suite…)

Ces derniers temps, il ne se passe pas un mois sans que l’on entende parler d’un nouveau framework destiné au développement d’application Flex. Parmi ceux-ci, deux d’entre eux retiennent notre attention puisqu’ils sont hébergés au sein de Spring. Ces deux projets sont Spring Actionscript (en incubation pour le moment) et Spring Flex.

Spring Flex n’est qu’une extension au projet Spring que les développeurs Java connaissent bien. Il permet d’exposer des classes Java sous forme de services BlazeDS depuis la configuration Spring.

Spring ActionScript par contre, est un conteneur IoC destiné à la partie cliente d’une application Flex. C’est sur celui-ci que nous nous attarderons dans cet article.

(Lire la suite…)