Pour le bulletin de cette semaine, je vous propose les sujet suivants :
What's and What's Old? The History of the Tutorial
17 March 2011
Travaillons ensemble à votre contractualisation Agile
L'Agile est aujourd'hui un outil puissant d'amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d'information. Si la méthode commence à être connue, sa mise en oeuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.
Ainsi, dans les organisations où les pratiques d'achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu'à l'aide d'avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les
principes fondamentaux de l'Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l'avancement du projet pour répondre mieux aux besoins des utilisateurs. Alors que faire ?
The Conway's Law
This concept is known as Conway's Law, named after Mel Conway, who published a paper called "How Do Committees Invent?". Fred Brooks cited Conway's paper in his classic "The Mythical Man Month", and invented the name "Conway's Law". Here's the definition from Conway's own website (which also has the original paper in full):
Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.
ConwaysLaw appears in MythicalManMonth, citing an earlier article by Conway from Datamation.
Conway's Law
Over the years I've heard a number of creative derivations of ConwaysLaw, including
Conway's Law and the Impact to Product Development
Think about your product and it’s strengths and weaknesses. Can these strengths and weaknesses be mapped to the strengths and weaknesses of the communication paths in your organization? Component-based teams and human relationships are at the core of this idea.
What is Software Architecture?
It's what software architects do / create / make! :-)
But still . . . . we've asked probably the hardest question in the world of software development.
What is a software architecture?
Architecture is the first of a four-part series on "architecting" in general. The author begins by defining the discipline's key terms and goes on to explore what a well-designed architecture contributes to the environment in which it is deployed.
Ehcache: Distributed Cache or NoSQL Store?
Is Ehcache a NoSQL store? No, I would not characterise it as that, but I have seen it used for some NoSQL use cases. In these situations it compared very well — with higher performance and more flexible consistency than the well-known NoSQL stores. Let me explain.
Ehcache is the de facto open source cache for Java. It is used to boost performance, offload databases and simplify scalability. Backed by the Terracotta Server Array, Ehcache becomes a linearly scalable distributed cache. It is a schema-less, key-value, Java-based distributed cache. It provides flexible
consistency control, data durability, and with the release of Ehcache 2.4, search by key, value and
attribute indexes.
Clean Code: Four Simple Design Rules – Obligatory Read
Posted by theholyjava on February 14, 2011 consider the Clean Code book to be obligatory for every programmer. And if you currently haven't the time to read it all at once then you should read – and take deep into your heart at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck's Four Simple Design Rules and explains thoroughly what they mean and why they're so important. The rules, in the order of importance, are:
- une mise à jour du tutorial Java est sortie le 17 mars 2011 avec déjà les évolutions du JDK 7
- Un article au sujet de l'agilité et la contractualisation
- La loi de Conway : comment une organisation qui construit un système peut finir par le concevoir comme le reflet de sa propre structure.
- Deux articles sur l'architecture logicielle : un terme qui n'est pas strictement défini.
- Le produit EHCache qui propose un système de requête sur des objets en Java.
- Les quatre règles minimum pour écrire du code.
What's and What's Old? The History of the Tutorial
17 March 2011
Travaillons ensemble à votre contractualisation Agile
L'Agile est aujourd'hui un outil puissant d'amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d'information. Si la méthode commence à être connue, sa mise en oeuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.
Ainsi, dans les organisations où les pratiques d'achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu'à l'aide d'avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les
principes fondamentaux de l'Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l'avancement du projet pour répondre mieux aux besoins des utilisateurs. Alors que faire ?
The Conway's Law
This concept is known as Conway's Law, named after Mel Conway, who published a paper called "How Do Committees Invent?". Fred Brooks cited Conway's paper in his classic "The Mythical Man Month", and invented the name "Conway's Law". Here's the definition from Conway's own website (which also has the original paper in full):
Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.
ConwaysLaw appears in MythicalManMonth, citing an earlier article by Conway from Datamation.
Conway's Law
Over the years I've heard a number of creative derivations of ConwaysLaw, including
- The architecture of a system is a copy of the architecture of the organization
- The structure of a system is determined by the structure of the team.
- To understand the team, look at the software they're producing. If it's slow and bloated, the team is slow and bloated. If it's lean and quick, the team is lean and quick.
- More precisely, The structure of a system reflects the .status and power relationships of the people and organizations involved.
Conway's Law and the Impact to Product Development
Think about your product and it’s strengths and weaknesses. Can these strengths and weaknesses be mapped to the strengths and weaknesses of the communication paths in your organization? Component-based teams and human relationships are at the core of this idea.
What is Software Architecture?
It's what software architects do / create / make! :-)
But still . . . . we've asked probably the hardest question in the world of software development.
What is a software architecture?
Architecture is the first of a four-part series on "architecting" in general. The author begins by defining the discipline's key terms and goes on to explore what a well-designed architecture contributes to the environment in which it is deployed.
Ehcache: Distributed Cache or NoSQL Store?
Is Ehcache a NoSQL store? No, I would not characterise it as that, but I have seen it used for some NoSQL use cases. In these situations it compared very well — with higher performance and more flexible consistency than the well-known NoSQL stores. Let me explain.
Ehcache is the de facto open source cache for Java. It is used to boost performance, offload databases and simplify scalability. Backed by the Terracotta Server Array, Ehcache becomes a linearly scalable distributed cache. It is a schema-less, key-value, Java-based distributed cache. It provides flexible
consistency control, data durability, and with the release of Ehcache 2.4, search by key, value and
attribute indexes.
Clean Code: Four Simple Design Rules – Obligatory Read
Posted by theholyjava on February 14, 2011 consider the Clean Code book to be obligatory for every programmer. And if you currently haven't the time to read it all at once then you should read – and take deep into your heart at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck's Four Simple Design Rules and explains thoroughly what they mean and why they're so important. The rules, in the order of importance, are:
Aucun commentaire:
Enregistrer un commentaire