Accueil InfoQ Architecture sur InfoQ
-
/articles/nuodb-architecture-2/fr/smallimage/logoNuodb.jpg)
A la découverte de l'architecture de la base de données NuoDB, Partie 2
Dans la première partie, nous avons introduit NuoDB et couvert ses principales fonctionnalités : Architecture 3-tiers, les noeuds sont des pairs identiques, l'Atom, unité de données fondamentales, et le système de gestion des versions.
-
/articles/apm-maturity-model/fr/smallimage/logo3.jpg)
Modèle de Maturité sur la Gestion des Performances Applicatives
Comme ceux qui ont travaillé dans un service informatique en entreprise le savent, les bons outils sont trop souvent gaspillés.
-
/articles/json-yoga/fr/smallimage/logo.jpg)
Ajouter de la flexibilité à votre implémentation REST avec Yoga
Les APIs REST sont très attractives de par l'élégance de leur conception. Vous obtenez quelque chose qu'Adam Bosworth de Google décrit comme "simple, décontracté, souplement extensible", mais vous n'obtenez pas quelque chose de construit pour des performances constantes.
-
/articles/evaluating-agile-software-methodologies/fr/smallimage/logo.jpg)
Évaluation de l'Agilité et Scrum par rapport à d'autres méthodes de développement logiciel
Les données historiques sont clés pour l'évaluation de l'efficacité des méthodes d'amélioration des processus de développement logiciel ainsi que pour calibrer la précision des estimations. Dans cet article, Capers Jones compare Agile et Scrum avec d'autres méthodes de développement logiciel contemporaines en utilisant plusieurs métriques standards.
-
/articles/BigDataPlatform/fr/smallimage/logo-2.jpg)
L’embarras du choix - Comment choisir la bonne plate-forme pour Big Data / Hadoop ?
Cette année, le big data est devenu un sujet pertinent dans beaucoup d’entreprises. Bien qu'il n’y ait pas de définition standard du terme “big data”, Hadoop est de facto un standard pour le traitement big data. Presque tous les grands éditeurs de logiciels tels que IBM, Oracle, SAP et même Microsoft utilisent Hadoop.
-
/articles/real-question-why/fr/smallimage/logo.jpg)
La vraie question est Pourquoi ?
Dans les années 90, nous étions au plus bas jamais atteint dans l'industrie du développement logiciel. La programmation commençait à devenir une profession courante et nous étions majoritairement très mauvais.
-
/articles/managing-technical-debt/fr/smallimage/logo.jpg)
Gérer la dette technique
La dette technique est décriée par les développeurs et source d'incompréhensions entre les acteurs décisionnels et techniques. Cet article pose des bases pour permettre de mieux la comprendre et discute des manières de la traiter au sein d'une entreprise.
-
/articles/nuodb-architecture-1/fr/smallimage/logoNuodb.jpg)
A la découverte de l'architecture de la base de données NuoDB, Partie 1
Dans la Partie 1 du présent article, l'auteur introduit NuoDB et certaines de ses caractéristiques principales: l'architecture à 3 niveaux, Atomes, le versioning et le système de concurrence.
-
/articles/eai-with-apache-camel/fr/smallimage/image_camel_apache.jpg)
Croissance des EAI avec Apache Camel
Cet article comprend des exemples concrets de problèmes typiques d'intégration et explore comment Apache Camel peut relever ces défis. Ces exemples sont présentés dans le cadre d'une solution d'intégration qui commence simple mais qui, au fil du temps, se développe avec l'apparition de nouveaux besoins d'intégration.
-
/articles/contract-model-failure/fr/smallimage/logo2.JPG)
Développement logiciel : Comment les contrats traditionnels augmentent le risque d'échec
Susan Atkinson et Gabrielle Benefield soutiennent que le modèle de contrat standard pour le développement de logiciels contribue aux taux élevés d'échec des projets informatiques et a besoin d'une refonte totale.
-
/articles/graph-databases-book-review/fr/smallimage/graphdatabaselogo.jpg)
Les bases de données graphe - revue du livre et interview
Le livre sur les bases de données graphes, écrit par Ian Robinson, Jim Webber et Emil Eifrém, couvre les bases de données NoSQL basées sur les graphes et les différentes possibilités disponibles pour stocker des “données connectées” dans le monde réel.
-
/articles/cap-twelve-years-later-how-the-rules-have-changed/fr/smallimage/logo.jpg)
CAP douze ans plus tard : comment les "règles" ont changées
Le théorème CAP affirme que tout système à état partagé en réseau ne peut avoir que deux des trois propriétés désirables. Néanmoins, en gérant explicitement les partitions, les concepteurs peuvent optimiser la cohérence et la disponibilité, atteignant ainsi un compromis des trois.