Le modèle relationnel est né à une époque où l’espace était rare, et fut donc conçu pour minimiser le niveau de redondance des données: il était plus économique de stocker une indirection vers une chaine de caractères que de stocker cette chaine deux fois.
Aujourd’hui, cette contrainte d’espace ne tient plus. On achète un Teraoctet pour 100 dollars, la RAM est abondante, et les disques flash aux performances élevées vont bientôt rejoindre le prix des disques durs rotatifs.

Deux limitations fondamentales du stockage ont donc disparu: le coût de la redondance et le coût de la non-localité pour le traitement de structures de données complexes. Il est maintenant possible de concevoir de nouvelles bases de données plus riches et plus sûres.

(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…)

Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.
(Lire la suite…)

Suite de notre cycle d’ateliers dédiés aux praticiens agiles, avec une nouvelle session au format Open Space le 14 Février de 14h à 18h dans les locaux d’OCTO. 3 bonnes raisons d’y participer :

  (Lire la suite…)

Agenda :

• Introduction aux enjeux d’analyse de données en temps réel
• Présentation des architectures d’analyse de données
• Présentation de la solution Open Source ESPER
• Présentation de la solution ActivePivot Sentinel (Quartet FS)
• Questions/Réponses

Une date à retenir ? Oui !  Le mardi 31/01/2012 pour nous faire part de vos idées sur les sujets IT, techniques, métiers ou liés aux aspects managériaux de la DSI !

Pas d’idée de session ? Aucun problème ! Vous pouvez élire votre session préférée en votant pour elle !  D’ailleurs vous pouvez aussi la partager  pour augmenter le nombre de vote !

Pour rappel : la qualité du résumé de session proposé (fond et forme) sera le critère de sélection principal pour l’équipe USI. Merci donc d’en tenir compte lors du remplissage de ce formulaire.

L’équipe programme étudiera toutes les propositions et sélectionnera les sessions qui lui paraîtront les plus intéressantes. Vous serez peut-être invité à venir présenter votre session lors d’une journée dédiée : mi février et nous informerons de notre décision finale fin mars 2012.

Cliquez ici pour soumettre votre session à l’USI

On attend vos candidatures avec impatience ! (Lire la suite…)

OCTO organise le mardi 07 février 2012 à partir de 8h45 un petit-déjeuner gratuit, aux Salons Wagram  « L’agilité à grande échelle » : retour d’expérience en partenariat avec Strator.

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

Qui a dit que l’agile n’était pas adapté aux gros projets ?

Strator et OCTO Technology se proposent de partager avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…

(Lire la suite…)

Pour la troisième fois cette semaine, Edouard, votre Product Owner, vous a demandé sur quoi vous pouviez vous engager pour cette itération ?

Vous souhaitez annoncer à Sophie du Marketing dans combien de temps votre fonctionnalité principale sera réalisée, mais vos indicateurs actuels vous donnent le vertige ?

Lors du sprint planning, 10 écrans ont dû être estimés. Vous êtes dubitatif : quel écran doit porter le coût de développement du premier ?

Dans un autre registre, vous démarrez un projet Agile sur un lourd existant. Comment concilier le manque de tests unitaire avec des itérations rapides ?

L’équipe mainframe n’est pas Agile, et demande des commandes trois mois à l’avance. Est il possible de faire de l’Agile dans ces conditions ?

Je suis manager. Avant, je rédigeais des plannings, et j’attribuais des tâches à chacun. Quel sera mon rôle dans la nouvelle organisation ?

Vous avez envie d’en parler, venez le mardi 31 janvier à l’Apéro Agile dans les locaux d’OCTO !

Autours d’un verre, nous discuterons de pilotage, d’intéractions avec des projets non agiles, ainsi que de postes et de carrière. Nous parlerons de pratiques, de techniques, et de vos réussites.

Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

L’inscription est ouverte aux 20 premiers : http://aperoagile2.eventbrite.com/

Edit : Je suis impressionné ! Les 20 places sont parties en une soirée ! Du coup, j’ai ouvert une liste d’attente. Inscrivez vous si vous le souhaitez, vous serez contactés en cas de désistement.

Derrière cette formulation humoristique se cache un des fondements de l’industrialisation des développements : le fait de pouvoir tester de manière automatisée tout ou partie d’un système informatique.

Aussi bien dans les architectures complexes que dans les applications les plus simples, il est pertinent de pouvoir tester un composant logiciel unitairement (indépendamment des autres composants duquel il dépend) : les dépendances sont donc « mockées » ou simulées en français.

Il est aussi nécessaire de pouvoir créer un contexte favorable au scénario de test en injectant un jeu de données particulier via un automate de tests ou un injecteur.

Le développement d’applications Kinect n’échappe pas à cette nécessité. Voici comment simuler une Kinect avec la librairie MocKinect.
(Lire la suite…)

Introduction

Depuis que les sites web sont devenus des applications riches, le besoin de push s’est largement manifesté. Il est présent sur des sites de mails, de feeds d’information, de partage de documents, de réservation de billets avec choix des places… Le push web permet de notifier le client d’une certaine information directement depuis le serveur, sans nécessiter de recharger la page du client. C’est typiquement un paradigme qu’on peut utiliser sur un site de messagerie instantanée.

Plusieurs technologies permettent d’implémenter ce genre de comportement, les plus connues étant probablement les WebSockets, les server-sent events (tous deux inclus dans les spécifications HTML5), ou encore le long polling, du web pull simulant du web push, utile sur certains navigateurs des moins récents.
(Lire la suite…)