Pour le bulletin de cette semaine, je vous propose les sujets suivants :
Maîtriser votre dette technique
La dette technique est généralement introduite à cause de raccourcis
pris lors d'un développement pour tenter de gagner du temps, en lieu
et place d'une conception propre, simple et évolutive. L'évolution et
la maintenance de ce code se feront au prix d'efforts supplémentaires
que l'on peut assimiler à des intérêts financiers.
Dans Monetizing the technical debt, Vikas Hazarati nous explique que
la dette technique doit être maîtrisée faute de quoi, l'application risque de péricliter. En effet, au delà d'une certaine dette
technique, la modification du code risque d'entraîner des
comportements hasardeux (régressions) dans l'application. La
diminution de la dette (capital) se fera en refactorant le code avant
d'atteindre un niveau de dette trop élevé. L'article nous explique les
bénéfices de monétiser notre dette technique et donne quelques
éléments pour déterminer le niveau d'endettement (notamment via
l'emploi d'un plugin Sonar).
La détermination d'un montant de dette technique pertinent semble
difficile à mettre en œuvre et la détermination d'un seuil de maîtrise
semble aussi particulièrement subjective. Le ressenti de l'équipe de
développement sur le niveau (qualitatif) de la dette technique semble plus pertinent.
Comme l'explique Ward Cunningham, l'introduction d'une petite dette
technique peut accélérer le développement à condition que celle-ci
soit remboursée rapidement après sa souscription. Une bonne pratique
pour vous aider à maîtriser votre dette technique est d'identifier le
code à améliorer au moment où vous l'introduisez et de planifier les
corrections nécessaires lors des itérations suivantes.
Monetizing the Technical Debt
Vague de départs chez Sun/Oracle
Le rachat de Sun par Oracle constitue un changement de politique et
d'identité majeur pour l'entreprise qui avait créé Java. On pouvait
donc s'attendre à un certain nombre de départs de quelques personnes
clé de Sun. Ces dernières semaines ont vu notamment les démissions de :
• James Gosling : le créateur du langage Java. Après avoir passé 20
ans chez Sun, James Gosling quitte Sun/Oracle. Son départ a
logiquement fait beaucoup de bruit au sein de la communauté Java.
• Simon Phipps : le directeur de la stratégie Open Source de Sun. Il
avait rejoint Sun 10 ans auparavant et était devenu Chief Open Source
Officer il y a 5 ans.
• Tim Bray : le co-rédacteur de la spécification XML et directeur des
technologies Web chez Sun. Il rejoint Google dès à présent.
Ces départs retentissants, accompagnés de disparitions de produits et
de changements de politiques, marquent bien la fin d'une époque…
Code Contracts in C#
This article is taken from the book C# in Depth, Second Edition. The author explains different approaches to using Code Contracts.
According to the author, to some developers contracts indicate the expected input states under which the method guarantees to operate correctly. To others, he says, contracts are a firmer guarantee, ensuring also that the code won't execute at all if they fail. The author then describes how to get started with contracts. Lastly, the author discusses failure mode options and contract types based on the needs and context of code use, rounding up the article with a brief overview of validation.
Unless you happen to have used a language supporting Design by Contract before, you may sometimes find yourself unsure of how to proceed with Code Contracts. If you're using it in conjunction with Test Driven Development, what should you write first - the contract or the implementation? Should you write unit tests for the contracts? When is it appropriate to let ContractException be thrown, and when you should throw a standard .NET exception such as ArgumentNullException? Should your release builds check contracts or not?
Visual Studio 2010 and .NET Framework 4.0 arrive
As expected, Microsoft today announced the general availability of Visual Studio 2010 and .NET Framework 4. To celebrate, the company is hosting a launch consisting of more than 150 developer-focused events around the world. In
time for the release, Microsoft made sure that developers have access to popular partner extensions earlier than before; approximately 50 partners already announced availability of products and solutions built on the two technologies.
Coming back to .NET Framework, version 4 adds additional support for industry standards, inclusion of the Dynamic Language Runtime for more language choice, new support for high-performance middle-tier applications (including parallel programming, workflow, and service-oriented applications), and side-by-side installation with .NET Framework 3.5. With the .NET Framework 4 Client Profile, the size of the runtime has been decreased by over 80 percent, making it easier for developers to get applications, and therefore users, up and running faster.
Model Driven Development Misperceptions and Challenges
After many years, it still seems that the level of adoption of MDD is not what would be expected. There are a number of inhibiting factors that limit the usage of MDD, such as the lack of awareness of practical MDD success stories, doubts on how it can be used on a daily basis, lack of funding model for up-front investment, or lack of focus for strategic initiatives.
1 - Challenge: The method was not in place and not consumable
2 - Challenge: The right infrastructure and tools weren't in place to reap the benefits of MDD
3 - Misperception: MDD == UML?
4 – Misperception: MDD is a one size fits all solution.
5 – Misperception: The diagrams are the model
6 – Misperception: The code is the model and the model is the code
7 – Challenge: Platform independence is challenging
8 – Challenge: Keep coders creative
9 – Challenge: There was no content to be leveraged
10 – Misperception: MDD is just for Development
The class design checklist
Given the good reception of the TDD checklist [1], I've decided to put together a similar one with suggestions for the generic class and interface design. These entities are the basic artifacts of object-oriented programming, thus this checklist is used at a lower level than the TDD one.
Difference between HashMap and IdentityHashMap
Most of the time I use HashMap whenever a map kinda object is needed. When reading some blog I came across IdentityHashMap [1]in Java. It is good to understand the differences between the two because you never know when you will see them flying across your code and you trying to find out why is this kinda Map is used here. IdentityHashMap as name suggests uses the equality operator(==) for comparing the keys. So when you put any Key Value pair in it the Key Object is compared using == operator.
ForkJoin : Bienvenue dans les mondes parallèles
L'API ForkJoin issue de la JSR166y, menée par Doug Lea, sera intégrée à la prochaine version majeure de Java (Java 7) dont la date de sortie devrait être en 2010. Elle va apporter aux développeurs un ensemble de classes permettant à moindre coût de tirer partie des architectures multi cores et/ou multi processeurs sur lesquelles les développements sont exécutés. Ce tutoriel va présenter quelques cas d'utilisation mettant en avant forces et faiblesses de la chose.
- un article au sujet de la gestion de la dette technique : il vaut mieux la payer au plus tôt plutôt que de la payer plus tard plus chère, avant que l'application s'écroule.
- Une vague de départ de chez SUN après la convergence avec ORACLE.
- La programmation par contact en C# : vous avez dit contrat ? Comment éviter l'interprétation d'une interface.
- La sortie de Visual Studio 10 par Microsoft : en synchrone avec DotNet 4.
- Le challenge du Model Driven Developpement et les erreurs de compréhensions.
- Une check liste pour le codage d'une classe.
- La différence (parfois pas très connue) entre une HashMap et une IdentityHashMap.
- un article très technique sur la classe ForkJoin du JDK 7 : sur la longue route de la programmation concurrente.
Maîtriser votre dette technique
La dette technique est généralement introduite à cause de raccourcis
pris lors d'un développement pour tenter de gagner du temps, en lieu
et place d'une conception propre, simple et évolutive. L'évolution et
la maintenance de ce code se feront au prix d'efforts supplémentaires
que l'on peut assimiler à des intérêts financiers.
Dans Monetizing the technical debt, Vikas Hazarati nous explique que
la dette technique doit être maîtrisée faute de quoi, l'application risque de péricliter. En effet, au delà d'une certaine dette
technique, la modification du code risque d'entraîner des
comportements hasardeux (régressions) dans l'application. La
diminution de la dette (capital) se fera en refactorant le code avant
d'atteindre un niveau de dette trop élevé. L'article nous explique les
bénéfices de monétiser notre dette technique et donne quelques
éléments pour déterminer le niveau d'endettement (notamment via
l'emploi d'un plugin Sonar).
La détermination d'un montant de dette technique pertinent semble
difficile à mettre en œuvre et la détermination d'un seuil de maîtrise
semble aussi particulièrement subjective. Le ressenti de l'équipe de
développement sur le niveau (qualitatif) de la dette technique semble plus pertinent.
Comme l'explique Ward Cunningham, l'introduction d'une petite dette
technique peut accélérer le développement à condition que celle-ci
soit remboursée rapidement après sa souscription. Une bonne pratique
pour vous aider à maîtriser votre dette technique est d'identifier le
code à améliorer au moment où vous l'introduisez et de planifier les
corrections nécessaires lors des itérations suivantes.
Monetizing the Technical Debt
Vague de départs chez Sun/Oracle
Le rachat de Sun par Oracle constitue un changement de politique et
d'identité majeur pour l'entreprise qui avait créé Java. On pouvait
donc s'attendre à un certain nombre de départs de quelques personnes
clé de Sun. Ces dernières semaines ont vu notamment les démissions de :
• James Gosling : le créateur du langage Java. Après avoir passé 20
ans chez Sun, James Gosling quitte Sun/Oracle. Son départ a
logiquement fait beaucoup de bruit au sein de la communauté Java.
• Simon Phipps : le directeur de la stratégie Open Source de Sun. Il
avait rejoint Sun 10 ans auparavant et était devenu Chief Open Source
Officer il y a 5 ans.
• Tim Bray : le co-rédacteur de la spécification XML et directeur des
technologies Web chez Sun. Il rejoint Google dès à présent.
Ces départs retentissants, accompagnés de disparitions de produits et
de changements de politiques, marquent bien la fin d'une époque…
Code Contracts in C#
This article is taken from the book C# in Depth, Second Edition. The author explains different approaches to using Code Contracts.
According to the author, to some developers contracts indicate the expected input states under which the method guarantees to operate correctly. To others, he says, contracts are a firmer guarantee, ensuring also that the code won't execute at all if they fail. The author then describes how to get started with contracts. Lastly, the author discusses failure mode options and contract types based on the needs and context of code use, rounding up the article with a brief overview of validation.
Unless you happen to have used a language supporting Design by Contract before, you may sometimes find yourself unsure of how to proceed with Code Contracts. If you're using it in conjunction with Test Driven Development, what should you write first - the contract or the implementation? Should you write unit tests for the contracts? When is it appropriate to let ContractException be thrown, and when you should throw a standard .NET exception such as ArgumentNullException? Should your release builds check contracts or not?
- Philosophy: what's in a contract?
- How do I get started?
- Unit testing contracts
- Code contracts in C#: Rewriting binaries with ccrewrite and ccrefgen
- Simple rewriting
- Contract inheritance
- Contract reference assemblies
- Failure behavior
- Options, options everywhere
- Choosing a failure mode
- Contract types
- Build configurations
- Why not validate everything?
- Summary and prospects
Visual Studio 2010 and .NET Framework 4.0 arrive
As expected, Microsoft today announced the general availability of Visual Studio 2010 and .NET Framework 4. To celebrate, the company is hosting a launch consisting of more than 150 developer-focused events around the world. In
time for the release, Microsoft made sure that developers have access to popular partner extensions earlier than before; approximately 50 partners already announced availability of products and solutions built on the two technologies.
Coming back to .NET Framework, version 4 adds additional support for industry standards, inclusion of the Dynamic Language Runtime for more language choice, new support for high-performance middle-tier applications (including parallel programming, workflow, and service-oriented applications), and side-by-side installation with .NET Framework 3.5. With the .NET Framework 4 Client Profile, the size of the runtime has been decreased by over 80 percent, making it easier for developers to get applications, and therefore users, up and running faster.
Model Driven Development Misperceptions and Challenges
After many years, it still seems that the level of adoption of MDD is not what would be expected. There are a number of inhibiting factors that limit the usage of MDD, such as the lack of awareness of practical MDD success stories, doubts on how it can be used on a daily basis, lack of funding model for up-front investment, or lack of focus for strategic initiatives.
1 - Challenge: The method was not in place and not consumable
2 - Challenge: The right infrastructure and tools weren't in place to reap the benefits of MDD
3 - Misperception: MDD == UML?
4 – Misperception: MDD is a one size fits all solution.
5 – Misperception: The diagrams are the model
6 – Misperception: The code is the model and the model is the code
7 – Challenge: Platform independence is challenging
8 – Challenge: Keep coders creative
9 – Challenge: There was no content to be leveraged
10 – Misperception: MDD is just for Development
The class design checklist
Given the good reception of the TDD checklist [1], I've decided to put together a similar one with suggestions for the generic class and interface design. These entities are the basic artifacts of object-oriented programming, thus this checklist is used at a lower level than the TDD one.
- Naming
- Structure
- Length
Difference between HashMap and IdentityHashMap
Most of the time I use HashMap whenever a map kinda object is needed. When reading some blog I came across IdentityHashMap [1]in Java. It is good to understand the differences between the two because you never know when you will see them flying across your code and you trying to find out why is this kinda Map is used here. IdentityHashMap as name suggests uses the equality operator(==) for comparing the keys. So when you put any Key Value pair in it the Key Object is compared using == operator.
ForkJoin : Bienvenue dans les mondes parallèles
L'API ForkJoin issue de la JSR166y, menée par Doug Lea, sera intégrée à la prochaine version majeure de Java (Java 7) dont la date de sortie devrait être en 2010. Elle va apporter aux développeurs un ensemble de classes permettant à moindre coût de tirer partie des architectures multi cores et/ou multi processeurs sur lesquelles les développements sont exécutés. Ce tutoriel va présenter quelques cas d'utilisation mettant en avant forces et faiblesses de la chose.
Aucun commentaire:
Enregistrer un commentaire