"blogpro" via Aurélien Pelletier

Representational State Transfer (REST) has gained widespread acceptance across the Web as a simpler alternative to SOAP- and Web Services Description Language (WSDL)-based Web services. Key evidence of this shift in interface design is the adoption of REST by mainstream Web 2.0 service providers -- including Yahoo, Google, and Facebook -- who have deprecated or passed on SOAP and WSDL-based interfaces in favor of an easier-to-use, resource-oriented model to expose their services. In this article, Alex Rodriguez introduces you to the basic principles of REST.

Il n’y a pas de secret la réussite des projets RIA passe par les méthodes agiles

ect that failed to meet its estimates, the management saw the project as a failure, but the technical participants saw it as the most successful project they had ever worked on! This illustrates the disconnect regarding the role of estimation, and project success, between management and technologists.

October 2008

Java Productivity Primer

Twelve guidelines to boost your productivity with a software factory

J’ai trouvé la métaphore ultime pour expliquer à un client le fonctionnement des Sprints de Scrum.

Comme vous le savez le Client, le Scrum Master et l’Equipe se réunissent au début de chaque Sprint au cours d’une réunion de 2 heures afin de fixer la liste des développements pour le prochain Sprint. Autour de la liste des fonctionnalités à développer (le product backlog) l’objectif en 2 heures est que le Client finalise avec l’Equipe la liste des développements à venir pour le prochain Sprint. Ensuite un des principes de Scrum est que lorsque l’équipe développe, elle ne doit pas être interrompue. Ce principe permet à l’équipe de travailler efficacement sans être perturbée en permanence par ce que j’appelle des “fausses urgences”. Le Client est en quelque sorte tenu de respecter cette règle. Et croyez-moi, au final cela fonctionne mieux que d’interrompre en permanence une équipe de développement.

Revenons au titre de ce billet. Comment expliquer à un Client que l’équipe ne peut produire qu’une quantité limitée d’éléments dans les 2 semaines à venir ? Comment lui expliquer qu’il doit alors faire un choix et donner une priorité pour chaque élément ? Comment lui expliquer qu’il ne pourra pas changer le contenu du sprint ?

Prenez une machine à laver le linge.

Vous avez un tas de linge sale : voici votre Product Backlog. Votre famille “alimente” en permanence ce Product Backlog chaque jour. De la même façon en Scrum les clients peuvent mettre à jour le product backlog en permanence.

Ensuite prenons notre lave-linge : il ne peut laver qu’une certaine quantité de linge à chaque programme. Par exemple 5 Kg. Et bien de la même façon, une équipe ne peut produire qu’une certaine quantité de fonctions par itération. Un Sprint de Scrum est donc égal à un lavage en machine. Pour expliquer à un client pourquoi l’équipe refuse de prendre plus d’éléments, je me sers de cette image. Je peux aussi lui dire que sa voiture n’a que 40 litres d’essence dans le réservoir. Il doit s’en contenter. Il faut donc que le client comprenne que “la capacité de production est limitée” et que c’est l’équipe qui annonce cette capacité.

Ensuite regardons ensemble ce que fait quelqu’un qui prépare une nouvelle machine : il prend le tas de linge sale et ensuite il va le trier en prenant soin de laver en premier les vêtements qu’il lui faut pour le lendemain, et il écartera les vêtements qui peuvent attendre la prochaine machine. C’est de la gestion de priorité. Tout comme Scrum. Je pousserai bien le vice jusqu’à expliquer qu’un Sprint de callibrage où l’on recherche une solution, un Sprint de release où l’on prépare une version, me font penser à un programme “Coton” et un programme “Blanc Programme Long”…

Enfin vient le temps du lavage, ce qui nous permet d’expliquer 2 notions : la non-modification d’un sprint et la durée fixée.

Tout d’abord il n’est pas possible d’arrêter un programme en cours de lavage pour y ajouter une chemise oubliée. Tant pis pour vous, elle sera lavée avec la prochaine machine. Même pire, je pense que si vous pouviez mettre en pause un programme, cela serait un risque pour l’ensemble du linge déjà en cours de lavage : risque de surcharge de la machine, risque que la chemise ne soit pas bien lavée finalement…
Durant un Sprint de Scrum il n’est pas possible de changer le contenu du Sprint. Vous devez laisser l’équipe terminer son travail. La gestion des patches et des bugs urgents doit être prévue en dehors du temps alloué à Scrum. Si votre activité de correction de bug représente 4 jours sur 10 en moyenne, alors votre équipe ne doit “faire du scrum” que sur une base de 6 jours, même si le sprint dure bien 10 jours.

La durée fixée en Scrum est aussi très importante car elle permet par observation de suivre l’activité de l’équipe et de créer des statistiques afin de pouvoir ensuite fonctionner de mieux en mieux.

Enfin je ne pousse pas plus loin la métaphore, pensez à Scrum lorsque vous lancerez votre prochain programme en “Coton délicat 40 degrés avec essorage”

If you’re in the SaaS (Software as a Service) business, and are following the Cloud Computing trends, you really need to understand the difference between the offers. Of course, I’m not talking about Cloud, like Apple’s Mobile :), but only Cloud Computing.

As of today, we have at least 3 big players (Amazon, Google and Microsoft) and some other ones from smaller players (like GoGrid, Flexiscale and Mosso to name a few of them). What is really important when choosing a Cloud Computing Platform is to understand what they offer and how they are different from each others. Of course the pricing models can vary quite a lot, with some providers offering SLAs, some offering virtualized hardware whereas some others one mean real hardware, etc.

But more than that, what really matters is do you need an infrastructure or a plaform, or if you’re fond of acronyms, are you the IaaS guy or the PaaS one?

That question is really important as it’s not easy to switch from one to the other.

Let’s explain the difference by analyzing the Cloud Computing offers from the 3 big players named above.

Google, through it’s App Engine offer, enable you to host your websites and your data on the Cloud and enable you to use some of their successful services like BigTable. What is important to understand is their pricing model and their APIs/Services. Two things are important to note :

• You can only host Python applications (erh… web applications) as of today and you pay per bandwidth, storage and CPU used for hosting this web application,
• You can easily integrate with other Google Services and Google Accounts.

Microsoft, offers a way to host your .Net applications on the Cloud with a pricing model yet to be officially announced, and offers integration with some Microsoft services/applications.

Amazon on the other end, does not offer a way to host your web applications out-of-the-box on the Cloud, but simply provide virtualized hardware on which you can do whatever you’d like to (well, as usual it’s it a bit more complex than that, but that’s pretty much it).

So basically, Google and Microsoft offers are PaaS solutions: they offer a Platform on which you can deploy your applications. On the other end, Amazon offers an IaaS solution: an Infrastructure which you can use.

So your choice has to be made carefully and need to analyze:

• Vendor Lock-in: if you deploy on Google or Microsoft Clouds, you make a choice on both technologies and with which services you’d like to integrate,
• Ease of Use: deploying a web application is easier to do than deploying and managing a complete infrastructure,
• PaaS or IaaS: do you want the Cloud Provider to offer you a way to host your applications (if you can accomadate with their technical restrictions) or an infrastructure allowing you to host your applications (without restrictions) the way you want?

I guess, it must be quite clear from this blog post that I’m not really fond of PaaS. Surely IaaS means more work for the customer, but you’re the one in charge of that virtualized infrastructure, allowing you to deploy complex applications on the Cloud, something I guess most of the time you won’t be able to do with the PaaS approach.

On the other end, if your goals are integration with Google and Microsoft services and you want to make sure you Gadget (don’t know the word for Microsoft sites) can scale, then it makes sense to deploy on those platforms.