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

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

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

La sérialisation est une des bases de la transmission de données entre systèmes. Certains langages proposent d’ailleurs une méthode de sérialisation en standard, qui leur est souvent propre.

L’interopérabilité entre systèmes hétérogènes nécessite que le format de sérialisation soit compréhensible par différents langages et plates-formes. De nombreux standards utilisent le mécanisme d’IDL (Interface Description Language) pour répondre à ce besoin : ASN.1, CORBA ou encore SOAP.

Depuis quelques années, de nouveaux frameworks basés sur un IDL ont vu le jour pour l’interopérabilité de technologies hétérogènes dans une optique d’économie de bande passante. Parmi eux, on trouve Thrift et Protocol Buffers. Ce premier article présente les deux frameworks sous l’angle de la sérialisation des messages et détaille leur utilisation en Java.
(Lire la suite…)

Les connections réseaux sont une source fréquente de lenteur des applications mobiles. Remplacer 10 téléchargements de 1Mo par 1 de 10Mo peut améliorer le fonctionnement de votre application.

L’utilitaire unix Tar permet justement de regrouper des fichiers en un seul package. Malheureusement aucune implémentation sous iOS de tar n’est satisfaisante : trop lourde et surdimensionnée par rapport aux besoins d’une simple application.

Pourtant une librairie qui décompresserait simplement des fichier tar n’est pas trop compliquée à développer.

La suite en anglais: http://blog.octo.com/en/untar-on-ios-the-pragmatic-way/

J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

La crise économique, une opportunité à ne pas rater !
L’actualité financière et les perspectives économiques mettent sous pression les budgets des DSI. Les coups de rabot budgétaires ont le mérite de mettre en évidence les sujets perçus comme les plus importants et urgents.
Arbitrer entre maintenir à flot l’activité métier ou la transformer est un choix difficile pour chaque Direction : « run the business or change the business » ? Les investissements SI sont soumis également à ce dilemme.
Néanmoins, les entreprises qui sauront mettre à profit cette période troublée pour se transformer sauront en bénéficier plus tôt. Alors que celles, qui ne le feront pas, n’auront pas eu le temps de le faire avant la prochaine crise, qui les paralysera à nouveau.
Dans une logique de recentrage des investissements SI, la question est donc de bien identifier les sujets qui permettent d’obtenir une réduction significative des coûts opérationnels et de rentabiliser à court terme la transformation des activités. Il faut bien l’admettre, cet exercice nécessite une bonne dose de créativité et d’innovation.
(Lire la suite…)