14861 items (14272 unread) in 65 feeds
BlogspersosFR
(997 unread)
BlogsEntreprisesFR
(1215 unread)
JavaJEE
(3851 unread)
Diversdev
(4335 unread)
Videos
(175 unread)
Agiles
(1491 unread)
divers
(661 unread)
Wicket
(47 unread)
Spring
(31 unread)
Architecture
(242 unread)
BlogspersosAutre
(417 unread)
BlogsEntreprisesAutre
(810 unread)
As you may have noticed in the Executable Specification and build integration post, build system integration is an area where GreenPepper shines. Most teams having good automated build practices also use a continuous integration (CI) server. We provide more comfort to those teams by allowing them to look at their GreenPepper execution results directly from their CI server user interface, we have developed integration with two major CI servers: Bamboo and Hudson.
Bamboo Build View :

Hudson Build View :

If you would like us to develop an integration with your favourite CI server, let us know.
J’ai reçu il y a environ une semaine ma copie du premier bouquin au sujet de scrum en français. Scrum : Le guide pratique de la méthode agile la plus populaire a été écrit par Claude Aubry. Claude nous offre un regard pratique et lucide au sujet de scrum et de sa mise en oeuvre dans les organisations.
Ayant été en contact à quelques reprises avec Claude depuis quelques années, c’est avec grand plaisir que j’ai signé la préface du bouquin et fait quelques commentaires lors de la lecture du manuscrit.
À quand le prochain bouquin en français au sujet de l’agilité en développement logiciel?
_agilely Timer permet aux praticiens de l’Agilité ayant un iPhone ou un iPod Touch de gérer efficacement les blocs de temps, les mêlées quotidiennes et les tables rondes. Dans quelques jours l’application sera gratuite. Cela veut dire qu’il ne vous reste que peu de temps pour vous procurer l’application et ainsi faire un don à FIAN, une ONG internationale travaillant au respect et à la réalisation du droit à l’alimentation.
Merci de soutenir cette initiative!
~françois
Le backlog produit est la liste des fonctionnalités du produit à développer. Chaque élément de cette liste est composé au minimum de trois attributs :
La finalité du backlog produit est d'avoir de la visibilité sur l'état du projet et de prioriser les développements.
Le backlog produit est de la responsabilité du product owner.
Valeur métier
La valeur métier d'un item est estimée par le product owner.
C'est la valeur métier des items qui doit diriger la priorisation des développements. Pour aider à la mise en perspective entre l'accessoire et le fondamental, il est conseillé d'utiliser la suite de Fibonacci en s'efforçant d'utiliser des valeurs très disparates.
Effort ou complexité
L'effort nécessaire à la réalisation d'un item est estimé par les personnes qui seront en charge de la réalisation. Cette valeur est fixe dans le temps.
Plus un effort est important, plus son estimation est imprécise. C'est pourquoi il est conseillé d'utiliser la suite de Fibonnaci pour estimer les efforts.
Métriques
Les métriques issues des données du backlog produit donnent de la visibilité sur l'état actuel du projet et aide à définir les prochaines étapes.
Le backlog produit est un outil évolutif (ajout, suppression, modification d'items). Par conséquent, il est souvent intéressant de suivre ces métriques en points et en pourcentage.
Ci-dessous, deux exemples de métrique que nous pouvons extraire du backlog produit.
Vélocité
La vélocité est l'effort qu'une équipe peut adresser en un sprint. Cette mesure s'affine au fil des itérations.
La vélocité ne doit pas être utilisé pour assurer le suivi de la productivité d'une équipe mais pour réaliser des projections (e.g. estimer la date de fin du projet). Une mauvaise utilisation de cette métrique entraine une inflation des points d'effort et/ou une "course à la vélocité" au détriment de la qualité.
Il est également déconseillé de comparer les vélocités de deux équipes du fait des estimations réalisées sur des échelles différentes. Les estimations sont relatives, pas absolues.
Par contre, il est intéressant de suivre l'évolution de la vélocité d'une équipe. Une diminution de la vélocité traduit souvent un manque d'évolutivité du produit développé ou l'apparition de nombreux bugs.
Valeur métier acquise
Cette métrique détermine la valeur des développements réalisés.
Si le backlog est correctement priorisé, l'évolution de la valeur métier acquise doit diminuer au cours des itérations car les items de plus grande valeur sont traités en premier.
Quelques liens
Dans SCRUM mon backlog de produit est DEEP
Le backlog
produit
Des user
stories de qualité
Valeur métier
en pratique
Comment mieux
prioriser en agile
Suite de
Fibonacci
Mon livre est sorti depuis presque un mois. La publication est une étape importante et je pensais être libéré une fois que ce serait fait. Mais non, il reste l'inquiétude de savoir s'il sera bien reçu. Je suis à l'affût de tout ce qui pourrait me donner la tendance.
Comme indicateur, il y a bien sûr les commentaires et critiques qui sont publiés. Les avis sont plutôt positifs et cela est déjà un bon indicateur, mais qu'en est-il des ventes ? Je me doute que mon livre intéresse en majorité des personnes qui sont dans les technologies de l'information, comme on dit, et que la majorité des ventes se fera sur... Lire Fluctuation des indicateurs
Le backlog produit est la liste des fonctionnalités du produit à développer. Chaque élément de cette liste est composé au minimum de trois attributs :
La finalité du backlog produit est d'avoir de la visibilité sur l'état du projet et de prioriser les développements.
Le backlog produit est de la responsabilité du product owner.
Valeur métier
La valeur métier d'un item est estimée par le product owner.
C'est la valeur métier des items qui doit diriger la priorisation des développements. Pour aider à la mise en perspective entre l'accessoire et le fondamental, il est conseillé d'utiliser la suite de Fibonacci en s'efforçant d'utiliser des valeurs très disparates.
Effort ou complexité
L'effort nécessaire à la réalisation d'un item est estimé par les personnes qui seront en charge de la réalisation. Cette valeur est fixe dans le temps.
Plus un effort est important, plus son estimation est imprécise. C'est pourquoi il est conseillé d'utiliser la suite de Fibonnaci pour estimer les efforts.
Métriques
Les métriques issues des données du backlog produit donnent de la visibilité sur l'état actuel du projet et aide à définir les prochaines étapes.
Le backlog produit est un outil évolutif (ajout, suppression, modification d'items). Par conséquent, il est souvent intéressant de suivre ces métriques en points et en pourcentage.
Ci-dessous, deux exemples de métrique que nous pouvons extraire du backlog produit.
Vélocité
La vélocité est l'effort qu'une équipe peut adresser en un sprint. Cette mesure s'affine au fil des itérations.
La vélocité ne doit pas être utilisé pour assurer le suivi de la productivité d'une équipe mais pour réaliser des projections (e.g. estimer la date de fin du projet). Une mauvaise utilisation de cette métrique entraine une inflation des points d'effort et/ou une "course à la vélocité" au détriment de la qualité.
Il est également déconseillé de comparer les vélocités de deux équipes du fait des estimations réalisées sur des échelles différentes. Les estimations sont relatives, pas absolues.
Par contre, il est intéressant de suivre l'évolution de la vélocité d'une équipe. Une diminution de la vélocité traduit souvent un manque d'évolutivité du produit développé ou l'apparition de nombreux bugs.
Valeur métier acquise
Cette métrique détermine la valeur des développements réalisés.
Si le backlog est correctement priorisé, l'évolution de la valeur métier acquise doit diminuer au cours des itérations car les items de plus grande valeur sont traités en premier.
Quelques liens
Dans SCRUM mon backlog de produit est DEEP
Le backlog
produit
Des user
stories de qualité
Valeur métier
en pratique
Comment mieux
prioriser en agile
Suite de
Fibonacci

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
RIA
Le coin de la technique
Agilité Convaincre votre MOA de passer aux méthodes AgilesDans un récent article, Alexandre Boutin explique comment convaincre une MOA de s’intéresser à l’agilité.
La démarche d’Alexandre a été de demander à la MOA de répondre à un questionnaire reprenant les divers problèmes habituellement rencontrés :
Ce questionnaire ayant permis à la MOA de mettre le doigt sur des problèmes récurrents, Alexandre présente les avantages que vont apporter l’utilisation des méthodes agiles dans leur travail :
Alexandre termine par préconiser un accompagnement pour se former et passer aux méthodes agiles le plus rapidement et le plus efficacement possible.
L’adoption d’une méthode de travail (agile ou non) par l’ensemble des acteurs d’un projet est fondamentale. Il est en effet compliqué pour une MOA de travailler avec des méthodes différentes de celles employées par la MOE. Cela génèrera immanquablement des problèmes de communication entre les deux parties.
Convaincre une MOA de changer ses habitudes de travail n’est pas chose aisée, et le questionnaire proposé par Alexandre Boutin (potentiellement agrémenté en fonction des spécificités du contexte du projet) peut-être un bon moyen de déclencher le besoin de changement.
L’adoption d’une méthode agile n’est pas sans contrainte, mais un bon coach agile saura mettre en avant les bénéfices de l’agilité pour combler les lacunes de l’ancienne méthode.
Les frameworks HTML5 continuent de se mettre à jour. Et après 52framework, c’est au tour de SproutCore de sortir en release majeure (version 1.0, information relayée ici).
InfoQ a récemment réalisé une interview de Charles Jolley (CEO de Sproutit) concernant SproutCore.
On y apprend ainsi que le framework gère certaines fonctionnalités d’HTML5 (comme l’offline storage ou le nouveau tag video) et qu’il est possible d’intégrer du code existant jQuery, ExtJS, YUI ou bien encore Prototype.
Il explique aussi les raisons principales de la migration, côté vue, de Ruby à JavaScript. La première est l’arrivée prochaine d’un Drag & Drop UI Designer (facilitée par les APIs JavaScript) et la seconde pour des raisons de performances (jusqu’à 10 fois plus rapide que la version précédente !).
Rendez-vous sur cette page pour une petite démonstration de SproutCore et sur celle-ci pour le téléchargement.
Le coin de la technique Commenter son code: jusqu’où aller ?Rebondissant sur une discussion qu’ont eu des programmeurs .Net de Seattle, InfoQ publie un article sur l’intérêt de commenter (ou non) son code. Le sujet, tel un éternel serpent de mer, donne toujours matière à discussion. A tel point que les interventions des lecteurs, à la suite de l’article, sont des plus intéressantes !
Le consensus semble être que les commentaires sont à éviter au maximum car le code se doit de s’auto-documenter: sans commentaires, et seulement avec le nom des méthodes et des variables, nous devons être capable de le comprendre. Ainsi, pour Thiébaut Champenier, il y a 2 types de commentaires:
Alex Suvorov ajoute qu’une suite de plusieurs opérations successives nécessitant un commentaire devrait plutôt être extraite en une fonction nommée de manière explicite. Tim Linquist, lui va même plus loin en souhaitant disposer d’une fonctionnalité lui permettant de sortir les commentaires du code une fois la documentation (javadoc) générée. Pour contrebalancer ces avis, la palme du meilleur commentaire revient à Pete Haidinyak. Celui-ci se permet une suggestion amusante destinée à toutes les personnes « qui ne commentent pas leur code ou qui pensent qu’un commentaire toutes les 10000 lignes est suffisant ». Il leur demande de rajouter un en-tête dans leur code spécifiant: « A toute personne chargée de maintenir ce code: si vous ne comprenez pas mon code ou êtes troublé par mon style, n’hésitez pas à m’appeler à toute heure, nuit et jour, au numéro suivant: { numéro_de_téléphone_du_développeur }. Je vous expliquerai ce que j’avais en tête lorsque j’ai écrit ce code ». L’idée est bonne, avec un tel en-tête, les développeurs risqueraient de se soucier un peu plus de la façon dont les autres peuvent comprendre leur code !
Où l’on reparle de la JSR-310La JSR-310 (Date and Time API) était initialement prévue pour le JDK 7 mais il y a un an, la roadmap de Sun l’en excluait. Cette spécification était pourtant attendue par tous ceux qui étaient lassés par les défauts de java.util.Date et qui voyaient en Jodatime (dont la JSR-310 est largement inspirée) une échappatoire tentante. L’API proposée par cette JSR est en effet beaucoup plus riche et permet de représenter tous les concepts d’instants et de durées.
Lors de l’annonce du report du JDK 7 en novembre dernier, Mark Reinhold avait laissé la porte ouverte aux fonctionnalités qui avaient été abandonnées faute de temps ; la JSR-310 en faisait partie. Courant février, questionné sur cette spécification par un spectateur d’un webcast, il disait regretter qu’elle n’ait pu être finalisée dans les temps. Dans le même temps, Stephen Colebourne, spec lead de la JSR-310, expliquait sur son blog qu’il disposait désormais de temps libre pour travailler sereinement sur cette spécification. Quelques semaines plus tard une early draft review voyait le jour. Enfin, il y a quelques jours, Stephen Colebourne répondait à un commentaire en disant que l’inclusion de la JSR-310 dans le JDK 7 dépendrait de sa finalisation et de la volonté de Sun/Oracle.
La saga de la JSR-310 semble donc renaître de ses cendres et la possibilité de son intégration au prochain JDK est bien réelle. L’affaire est donc à suivre…
A lot of people experiment GlassFish for the first time via an IDE (most likely NetBeans, but maybe also with Eclipse) and feel a bit lost when it comes to use GlassFish without the tool driving it for them. So here are a few (mostly basic) CLI asadmin hints for GlassFish v3 :
* Start/Stop *
Start GlassFish (need this to access the admin console on default port [localhost:4848]) :
% GLASSFISH_HOME/bin/asadmin start-domain (assumes there's only one domain)
% asadmin start-domain domain1 (explicitly reference a given domain)
% asadmin start-domain -v domain (will cause the log to be dumped to the standard output)
% java -jar modules/glassfish.jar (may be useful in certain circumstance (explicit java version for instance)
Stop GlassFish :
% asadmin stop-domain {domain1}
List existing instances (including stopped/started status)
% asadmin list-domains
You can also create additional domains with % asadmin create-domain ... (and I would suggest using the -portbase option).
* Resources *
If the IDE has created connection pools and datasources, you will certainly find the following create-jdbc-connection-pool and create-jdbc-resource commands useful. Note also that asadmin has a "closest match" feature for misspelled commands and extensive online documentation :
% ~/glassfishv3/bin/asadmin create
CLI001 Invalid Command: create
Closest matching local and remote command(s):
create-admin-object
create-audit-module
create-auth-realm
create-connector-connection-pool
create-connector-resource
create-connector-security-map
create-connector-work-security-map
create-custom-resource
create-domain
create-file-user
create-http
create-http-listener
create-iiop-listener
create-javamail-resource
create-jdbc-connection-pool
create-jdbc-resource
create-jms-host
create-jms-resource
create-jmsdest
create-jndi-resource
create-jvm-options
create-lifecycle-module
create-message-security-provider
create-network-listener
create-password-alias
create-profiler
create-protocol
create-resource-adapter-config
create-resource-ref
create-service
create-ssl
create-system-properties
create-threadpool
create-transport
create-virtual-server
Almost every bits of configuration is located in the glassfish/domains/domain1/config/domain.xml config file but you really should be using asadmin or the admin console and not edit this by hand.
* (auto)deployment *
The explicit deployment is based on the asadmin deploy app.{ear|war|jar} command. Listing deployed applications is as easy as asadmin list-application (notice how GlassFish tells you which containers are at work for a given app), and undeployment simply requires a asadmin undeploy app-name.
While these commands have lots of options (asadmin deploy --help for details), you may find it convenient to simply drop your application in the domain1/autodeploy directory. Deleting the file will trigger the undeployment.
All the details for the asadmin CLI can be found in the official "Using the asadmin Utility" documentation.
This new release includes a new plugin for Hudson (a continuous integration server), support for Jira4, a better use of accented characters in specifications, many improvements to the core and much more…
See the release notes for more details…
Est-ce que vous vous souvenez de l’époque où l’on répondait sans hésiter « PocketPC » ou « Palm » lorsque l’on nous parlait de PDA ?
Nous appelions cela des assistants personnels. Ils nous permettaient de lire et écrire des documents, de synchroniser des fichiers, d’écouter de la musique, de jouer à des jeux, de télécharger des applications variées que nous trouvions sur des sites encore plus variés.
L’eau a beaucoup coulé depuis, ainsi que les ventes. Aujourd’hui l’iPhone est sur toutes les lèvres et dans presque toutes les poches. Parce que l’iPhone est un produit accessible et qui intègre un bon nombre d’innovations (certaines moins récentes que d’autres) beaucoup d’entreprises l’ont choisi comme plateforme cible numéro 1 sans avoir vraiment envisagé de numéro 2.
Je ne vais pas essayer de vous faire pleurer en vous jouant un air nostalgique 8bits ou de vous faire croire que « iPhone is evil », je vais plutôt vous présenter les possibilités d’une autre plateforme que l’on met parfois trop vite au placard : Windows Mobile.
Pour ceux qui ne connaissent pas cette plateforme, ce sera une bonne façon de découvrir ses possibilités. Pour ceux qui l’ont connu et qui sont passés à autre chose, il est toujours intéressant de se rafraîchir les idées. Pour les autres (ceux qui connaissent déjà), vous pouvez au moins faire une lecture pour vérifier que je ne dis pas de bêtise.
(un téléphone Windows Mobile sera nommé Windows Phone dans le reste de l’article)
La plateforme matérielleIl n’est pas vraiment possible de citer des spécifications matérielles précises pour les plateformes Windows Mobile. Ce sont les fabricants (« hardware vendors ») comme HTC, Samsung, Sony Ericsson ou Motorola qui définissent eux-mêmes les caractéristiques de leurs Windows Phone.
En se basant sur les contraintes du marché (cible et coût), ils choisissent :
Et Microsoft dans tout ça ?En 2002, 50 fabricants à travers le monde ont produit des appareils équipés de Windows Mobile aussi bien en B2C qu’en B2B.
Motorola (anciennement Symbol) ou Monarch Instrument ont produit une quantité impressionnante d’appareils Windows Mobile adaptés à des usages en environnement à risque (humidité, pression atmosphérique, chute, température) et intégrant une grande quantité de périphériques (imprimante, lecteur, détecteur, convertisseur numérique…)
Evidement la société Microsoft guide et valide dans une certaine mesure les choix technologiques afin de pouvoir apposer un label sur le produit mais sans forcement imposer des contraintes fortes. Les contraintes viennent plutôt de la conception du système d’exploitation Windows Mobile.
La manière dont a été conçu Windows Mobile oriente certains choix mais apporte à la fois une grande flexibilité. Les fabricants doivent contrebalancer les défauts de l’OS (interface graphique, performances, usage mémoire…) par des choix de composants judicieux (CPU plus puissant, stockage plus rapide) et éventuellement des développements spécifiques (souvent une surcouche graphique).
Prise en charge de nouveaux composantsL’architecture basée sur des standards industriels permet une prise en charge native d’un très grand nombre de composants et de périphériques connectables par IrDA, Bluetooth, port série virtuel… De plus cette architecture est suffisamment ouverte pour permettre aux fabricants de développer les pilotes ou les couches logicielles nécessaires pour tirer partie de nouveaux composants non-standardisés qui ne seraient pas pris en charge nativement par l’OS (ex : l’accéléromètre, capteur de luminosité…).
Cette souplesse permet de mettre sur le marché des produits très variés en termes de conception (adaptés à des usages spécifiques) et de fournir des fonctionnalités parfois en avance de phase par rapport à la définition de standards.
Les logicielsLe cycle de développement des OS Mobile de Microsoft est assez lent et n’intègre pas la notion de mises à jour mineures. Si un nouveau composant est à prendre en charge ou un correctif spécifique est à déployer, ce sera aux fabricants de l’intégrer et de le mettre à disposition des utilisateurs via une mise à jour du « firmware ».
Les Windows Phone sont issus d’une stratégie orientée bureautique héritée de la version PC. L’ergonomie s’en inspire aussi et l’on retrouve des scrollbars, popup, liste déroulante, glissière… ce choix d’ergonomie était louable dans la mesure où il réduisait le besoin d’adaptation de l’utilisateur lors du passage du bureau au mobile. En pratique, l’utilisateur subit cette ergonomie et l’utilisation de composants peu intuitifs ou complexes à manipuler avec un écran tactile.
Les Windows Phone ont tout de même eu leurs heures de gloire et cela n’a pas empêché les entreprises et les professionnels de les adopter. L’intégration par défaut de logiciels pour l’entreprise et sa compatibilité avec la suite Office a surement pesé en leur faveur.
Les Windows Phone sont équipés nativement de :
* Pocket Internet Explorer 5 était très en retard par rapport à ses concurrents à cause de problèmes de performance et de compatibilité JavaScript / CSS.
Internet Explorer Mobile 6 (livré avec les nouveaux Windows Phone depuis fin 2009) est censé éviter l’installation d’un navigateur alternatif et faciliter le développement d’applications Web riches grâce à une meilleure prise en charge des standards du Web. En pratique les performances et la compatibilité ne sont pas toujours au rendez-vous et nécessite de développements spécifiques.
Une nouvelle version d’Internet Explorer Mobile devrait voir le jour avec la sortie de Windows Phone 7 et contiendra un moteur de rendu hybride entre IE7 et IE8 sur PC.
Les fabricants et les distributeurs (opérateurs mobiles) ont la possibilité de personnaliser l’OS et de choisir les applications mises à disposition sur leurs appareils. La présence d’applications dépend en général de plusieurs facteurs :
La plateforme Windows Mobile (anciennement Windows CE ou PocketPC) existe depuis maintenant presque 10 ans, le nombre d’applications gratuites ou payantes est conséquent mais il faut s’armer de patience pour trouver la perle rare. Le manque de catalogue unifié et surtout de certification des applications entraînent un niveau de qualité et de sécurité très variable d’une application à l’autre.
En 2004, il y avait (officiellement) 20 000 applications commerciales Windows Mobile dont seulement 2 000 certifiées Mobile2Market
Microsoft tente depuis quelques mois de s’aligner sur ses concurrents en développant une solution B2C nommée Marketplace (anciennement Mobile2Market) qui est l’équivalent de l’AppStore d’Apple ou de la boutique Ovi de Nokia. Le catalogue d’applications validées est actuellement assez faible (pour diverses raisons dont la faible popularité des Windows Phone et le coût de certification des applications). Il atteint tout juste les 100 applications sur le catalogue français et environ 300 pour le catalogue américain.
Quelles sont les possibilités des logiciels ?D’un point de vue technique les possibilités des applications sont presque aussi étendues que sur PC. Il est possible d’installer des Services Windows (application sans interface s’exécutant en tâche de fond), d’installer un mini-SGBD tel que SQL Server Compact Edition (pouvant se synchroniser automatiquement avec un SQL Server d’entreprise) ou de faire des applications consommant des WebServices.
Les applications ont nativement un accès « libre » aux données stockées sur le Windows Phone. Via des API standards (telles que Pocket Outlook Object Model, il est par exemple possible de modifier un contact ou de créer un évènement dans le calendrier de l’utilisateur. Cette liberté peut être considérer comme un risque lorsque l’on ne maîtrise pas les applications installées mais c’est aussi un gain énorme en terme de possibilités fonctionnelles et de productivité des développements.
Comment créer ses propres applications pour Windows Phone ?Les Windows Phone (tout comme les PC) peuvent exécuter des applications développées dans différents langages. On peut citer : .Net (C#, VB.Net, C++), Embedded Visual Basic, Java, Javascript (pour les widgets), Windev, Delphi, C++…
L’environnement de développement le plus souvent utilisé est Visual Studio 2008. Déjà très utilisé pour le développement d’applications PC, il offre les mêmes fonctionnalités End-to-End (de la conception au déploiement) pour le développement mobile. Le développeur profite donc par exemple d’un framework de tests unitaires, d’un debugger avancé et d’une solution de packaging d’application.
Dans le cadre du développement mobile, Visual Studio intègre en plus un émulateur assez complet et très fidèle à la plateforme cible (à la vitesse d’exécution près), il permet entre autres d’émuler :
L’un des principaux avantages d’utiliser Visual Studio est la réutilisation de compétences et des ressources. Ainsi un développeur déjà initié aux développements .Net n’aura (presque) rien à apprendre pour réaliser ses premières applications et pourra éventuellement mutualiser des ressources (fichiers sources, fichiers de données ou couches logicielles) entre les applications PC et Mobile.
Et le nouveau Windows Phone 7 dans tout ça ?Je profite que nous parlions actuellement de développement et que vous sachiez déjà ce qu’est Windows Marketplace, pour vous signaler que la boîte à meuh Octo iDailyScrum vient de dépasser les 10 000 téléchargement. iDailyScrum est téléchargeable gratuitement sur le Windows Marketplace et est aussi disponible sur iPhone.
Windows Phone 7 aurait dû sortir en 2009, mais suite à plusieurs retards Microsoft a préféré sortir à la place un Windows Mobile 6.5 afin de tenter de conserver ses parts de marché face à l’iPhone et à Android. Ce Windows Mobile 6.5 essaye de rendre un OS en retard ergonomiquement plus attractif pour l’utilisateur lambda. Ce « nouvel » OS ajoute une surcouche graphique « finger-friendly » au noyau Windows Mobile 6.1, il est de plus équipé d’Internet Explorer Mobile 6 et de Windows Marketplace. Malgré tout l’OS 6.5 peine à convaincre les fabricants et le grand public qui se tournent vers les plateformes concurrentes, les parts de marché ont ainsi dégringolé de 11% à 8% entre 2009 et 2010 (soit 30% de parts de marché en moins pour Microsoft).
Windows Phone 7 est prévu pour l’automne 2010. Il est assez difficile de savoir ce que Microsoft nous réserve réellement. Les arguments marketing et les spécifications techniques restent confus. Toutefois il est possible d’affirmer que Windows Phone prendra en charge Silverlight Mobile (framework RIA), XNA (environnement d’exécution pour les jeux) et évidement le .Net Compact Framework.
Microsoft semble vouloir suivre une voie similaire à l’iPhone en imposant des spécifications techniques strictes aux fabricants. Ceci afin d’harmoniser l’écosystème des appareils présents sur le marché pour faciliter les développements et fournir une expérience utilisateur homogène (« We want innovation without fragmentation » dit Andy Lees, senior vice président de Microsoft’s Mobile Communications Business). Les fabricants devront donc équiper leurs appareils :
Microsoft souhaite de plus accroître la visibilité de la marque Microsoft auprès des utilisateurs en limitant les possibilités de personnalisation (branding) des fabricants/distributeurs et en fournissant des services mobiles (tels que MyPhone et Marketplace) directement aux utilisateurs finaux.
ConclusionAvec Windows Phone 7, Microsoft choisit une stratégie très « consumer oriented » et souhaite proposer un appareil communiquant ludique faisant le pont entre la téléphonie, le social, le multimédia (Zune) et le videoludique (intégration Xbox Live).
Qui se osera dire Windows iPhone 7 ?
En conclusion, les Windows Phone représentent des plateformes très complètes mais qui souffrent d’une mauvaise image auprès des utilisateurs (lenteur et ergonomie). Ces remarques sont pour la plupart justifiées mais sont bien entendues à mettre en perspective avec les gains apportés par ces plateformes (productivité des développements, évolutivité, gestion de flotte).
A l’époque où ils s’appelaient encore Pocket PC, les Windows Phone ont largement été utilisés par les entreprises des secteurs industriels. Les coques renforcées et les périphériques en faisaient et en font toujours des plateformes de choix.
L’arrivée des Windows Phone 7 devrait permettre à Microsoft de se positionner en concurrent de l’iPhone, mais il est encore trop tôt pour savoir si le marché des entreprises profitera lui aussi d’innovations structurantes. Le fameux Mix10 qui aura lieu à la mi-mars devrait nous fournir des réponses claires sur la nouvelle stratégie Microsoft. Patience …
Voici quelques liens qui vous permettrons de mieux connaître les Windows Phone :
En fonction de vos remarques et de vos demandes, un ou plusieurs articles seront publiés sur les sujets suivants :

As a follow up to my previous post, this second post in a series of 4 short articles written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, addresses the impact an Agile transition typically has on some of the traditional software development roles: the project manager, the architect, the business analyst, and the QA specialist.
One of the first obstacle we routinely encounter in coaching teams through their Agile transition is the mapping of the Scrum roles to the traditional roles. Since Scrum only has three roles (product owner, scrum master, and scrum team), what happens to the project manager, to the architect, to the business analyst, and to the QA specialist after the transition?Based on our experience, here are possible strategies to properly map the traditional roles to the three roles defined by Scrum.
The Project ManagerTraditionally, the project manager is responsible for determining who, what, and when activities need to be performed and then to ensure the team complies with the plan that was prepared to meet the budget, time and scope constraints.
With the traditional approach, project management is based on compliance with the plan while Agile and Scrum propose a different approach where maximizing the business value is the main vector of project management. Under this new approach, the product manager needs to collaborate with the team members and delegate to them some of his traditional responsibilities since they will determine who does what, and when within the constraints of the project.
In this context, the role of the Scrum Master is to enforce the process and seeks to build an efficient self-organized team. To the question “do we still need a project manager in Agile?”, experience shows us that in most organizations, the answer is yes.
The need for accountability, regulatory compliance and alignment with the framework and IT governance are not covered by the role of the Scrum Master and as such remain the responsibility of the project manager.
However, the project manager needs to adapt its management style and use leadership rather than authority with the team to get things done. In the context of a multi-team organizational structure, the presence of a project manager is also valuable, where he is coordinating the teams and the synchrony between them and between entities external to the project teams.
From our experience, some project managers are more willing to become product owners while others will feel challenged by the role of Scrum Master. In the end, it will be the responsibility of the organization to determine how to redefine the roles and their associated responsibilities.
The ArchitectSimilar to the project manager, the architect is known to play a different role post-transition compared to that required in traditional development teams. He must act as a consultant to the teams and provide them with the necessary support instead of dictating the rules and guidelines to be followed. The architect should also be familiar with the concepts of emerging architecture, where just enough architecture is planned to allow the team to innovate and find the optimal solutions.
The architect then acts as a catalyst for sharing best practices within the organization. Here is a list of practices summarizing the changes of behavior for the architect:
Once again, although the role of the architect does change after an agile transition, it remains an important role to be filled.
The Business AnalystThe business analyst is another role that seems neglected by Scrum. To ensure close collaboration between the team and the Product Owner, Scrum ensures that the necessary elements are effectively communicated directly to the team without a formal and complex documentation. However, to ensure continuity of information, we know that functional documentation that is adequate and representative of the software to be developed is essential.
The business analyst becomes a valuable contributor to the Product Owner. The responsibilities of the business analyst are as follows:
In a multi-team context, the business analyst may be called upon to play the role of Product Owner. He then becomes responsible for core components of the product within the various sub-teams.
The Quality Assurance SpecialistQuality is a fundamental concern in Agile project management and each iteration should produce an increment of quality software. To do this, we recommend incorporating a quality assurance specialist within the Scrum teams, and right from the start of the project. A QA specialist assigned to a Scrum team has the following responsibilities:
As will be presented next week in “Part 3: Impact on the functional and people managers”, managers also get impacted by an Agile transition.
You might be interested in these related posts:

Je profite d’un peu de temps entre 2 missions pour me former à Scala depuis quelques temps. J’ai vraiment beaucoup de plaisir à apprendre et à travailler avec ce nouveau langage. Proche de Java, il est pourtant bien différent, et vraiment intéressant comme nous allons le voir ensemble.
James Gosling, l’un des inventeurs de Java, a dit à propos de Scala la phrase suivante :
« If I were to pick a language to use today other than Java, it would be Scala »
Plus suprenant, James Strachan qui a initié le langage Groovy en 2004, a dit aussi à propos de Scala :
« I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy. »
Le langage a été initié en 2003. Scala (pour Scalable Language) a été pensé pour la programmation multi-threads, avec un niveau de qualité assez impressionnant. J’aime ce langage car au final, ce sera toujours du bytecode dans une machine virtuelle Java.
C’est un langage orienté objet avec une teinte de programmation fonctionnelle. Créé en 2003 par Martin Odersky, Scala est supporté par l’EPFL (Ecole Polytechnique Fédérale de Lausanne). Typé statiquement, il propose par exemple une inférence de type très puissante, qui rend la programmation Java « old-school » dès lors que l’on débute en Scala.
Scala est concis
Le langage est très concis. Prenons par exemple un BVOJTP (Bon Vieil Objet Java Tout Pourri) et voyons ce que cela donne dans sa version Scala. Je prends par exemple un simple Bean « Person » avec quelques attributs.
La version Java
public class PersonInJava {
private String firstName;
private String lastName;
private Date dateOfBirth;
public PersonInJava(String firstName, String lastName, Date dateOfBirth) {
this.firstName = firstName;
this.lastName = lastName;
this.dateOfBirth = dateOfBirth;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public Date getDateOfBirth() {
return dateOfBirth;
}
public void setDateOfBirth(Date dateOfBirth) {
this.dateOfBirth = dateOfBirth;
}
}
La version Scala :
class PersonInScala(val firstName: String, val lastName: String, val dateOfBirth: Date)
Et oui… par défaut il n’est pas nécessaire de déclarer les getters/setters, ni de constructeur par exemple.
Inférence de types
Scala est capable de deviner les types associés à des expressions automatiquement (voir la définition del’inférence de types). Cela permet de conserver un type fort en interne, tout en allégeant le code source.
var year: Int = 2010
var anotherYear = 2010
var helloBuddy = "Salut !"
var builder = new StringBuilder("Bonjour")
println(builder.getClass())
La première variable est définie comme étant de type Int. Remarquez ensuite que la variable anotherYear est définie sans spécifier de type. Scala infère le type en Int automatiquement grâce à la valeur que nous avons assignée à cette variable. Ce type est définitif, il s’agit bien d’un type statique.
Si par exemple j’essaye d’affecter une String un peu plus tard à ma variable anotherYear alors Scala me signale à la compilation qu’il y a un souci :
var anotherYear=2010
anotherYear="This is a String"
(je compile le code...)
!!!
discarding
(fragment of TypeInference.scala):7: error: type mismatch;
found : java.lang.String("Test")
required: Int
anotherYear="Test"
Pour revenir un peu plus haut, la variable helloBuddy est inférée en java.lang.String automatiquement, et la variable builder en StringBuilder. Dans la pratique, pour un développeur Java il n’y a pas grand chose à faire. Il reste possible de typer ses variables, mais cela ne devient plus indispensable. Enfin la vérification à la compilation nous épargne les soucis de transtypage à la Java et certainement quelques soucis comme avec un langage dynamique.
Programmation fonctionnelle
Je ne vous donnerai qu’un aperçu car c’est un sujet vaste. En Scala il est possible de créer des fonctions à l’intérieur de fonctions, de passer des méthodes en paramètres à d’autres méthodes, bref les fonctions en Scala sont des Objets à part entière. Nous retrouvons la notion de pointeur de fonctions en quelques sortes.
La programmation fonctionnelle sera présenté en Avril au Paris JUG, ainsi que Scala d’ailleurs. Cela vous donnera l’occasion de voir un peu ce que cela peut vous apporter en tant que vieux Java-iste.
Prenons un exemple tiré du livre « Programming Scala » écrit par V.Subramaniam. Ecrivez une fonction qui effectue la somme d’une suite de nombre sur une plage passée en argument. Voici la version Java :
public int sum(int number) {
int result = 0;
for(int i = 1; i
Comment feriez-vous si je vous demande maintenant de faire l'addition des nombres pairs uniquement ? En Java vous feriez une copie de cette méthode, pour en créer une nouvelle, avec votre algo. En Scala, il est possible de passer une méthode en paramètre. Nous allons donc extraire la logique de la sélection des valeurs, et la définir à l'extérieur.
Des fonctions qui prennent en paramètre d'autres fonctions sont appelées "higher-order function". En Scala vous pouvez créer des fonctions à l'intérieur d'autres fonctions, les passer en paramètre et les assigner à des références.
Voici une version en Scala pour itérer sur une plage de valeur. Pour chaque valeur nous allons appeler la fonction référencée par codeBlock qui retourne un Int.
def totalResultOverRange(number: Int, codeBlock: Int => Int) : Int = {
var result = 0
for (i
Donc pour effectuer la somme de valeur, nous pourrons appeler la fonction en spécifiant une fonction d'addition très simple :
// Sum up to 10 println(totalResultOverRange(11, i => i))
Le premier argument, 11, est la limite supérieure de notre série. Le second argument est une fonction anonyme qui prend en argument un type et qui le retourne sans modification. Notez qu’ici nous ne précisons pas le type Int, il sera inféré par Scala au moment voulu en examinant la signature de la méthode totalResultOverRange.
Si je vous demande maintenant d’effectuer la somme des nombres pairs uniquement dans la série, voici comment nous écrirons en Scala cet appel:
println(totalResultOverRange(11, i => if (i % 2 == 0) 1 else 0))
Si le modulo 2 du compteur courant est égal à 0, alors nous retournons 1 pour vrai, sinon 0.
Il est bien entendu possible de définir des Closures. Ici nous définissons une variable closure qui sera un pointeur vers une méthode.
def loopThrough(number: Int)(closure: Int => Unit) {
for (i
Voici un exemple d'utilisation :
var result = 0
val addIt = { value:Int => result += value }
Dans ces quelques lignes ci-dessus je crée une variable « addIt » qui est un bout de code pour effectuer l’accumulation de deux valeurs. Notez que la variable result n’est pas définie dans ce bloc ni comme paramètre. En fait cette variable est branchée à la variable result en dehors du bloc de code. Je pense qu’un exemple sera plus parlant pour expliquer cette subtilité :
var result = 0
val addIt = { value:Int => result += value }
loopThrough(10) { addIt }
println("Total of values from 1 to 10 is " + result)
result = 0
loopThrough(5) { addIt }
println("Total of values from 1 to 5 is " + result)
// Execution
Total of values from 1 to 10 is 55
Total of values from 1 to 5 is 15
Comprenez qu’une Closure est un bloc de code qui s’exécute dans un contexte, tout en étant capable de modifier des variables externes. Lorsque j’appelle la méthode loopThrough() en spécifiant une closure, la variable result est vue comme une variable globale. Lorsque je remet à 0 la variable, la closure le « voit » aussi et débute à nouveau l’itération de 0. Il est possible aussi de n’utiliser que des variables locales pour ne pas avoir cet effet bien entendu. C’est la vraie notion de Closure, où les variables d’une portée plus importante sont vues localement au sein de la fonction.
Conclusion de cette première partie
Scala est donc un langage fortement typé, capable de faire de l’inférence de types, avec une manipulation des fonctions très puissante, et la possibilité d’utiliser des Closures.
En Scala, tout est objet. Un nombre comme « 2″ est un objet sur lequel il est possible d’appeler une fonction. Les fonctions sont des objets, que vous passez en paramètre, afin d’exécuter des traitements fonctionnels.
Nous verrons la prochaine fois les Traits et les Collections, puis nous parlerons de programmation concurrente avec les Actors.
Je vous recommande la lecture de « Programming Scala » écrit par V.Subramaniam. Ce livre a été pensé pour des développeurs Java qui souhaitent apprendre rapidement Scala.
Je pense qu’il ne faut que quelques semaines pour être opérationnel. Il y a le risque de faire du « Java-like » avec Scala, comme nous faisions du C à la place du C++. Mais je pense cependant que vu la maturité du langage, la quantité de documentations et de livres disponibles, nous pouvons éviter de tomber dans ce piège.
Alexandre Bertails a préparé la version Scala de mon article sur le XML et Groovy. Vous verrez différentes versions d’ici quelques jours, le temps de terminer les 2 autres articles sur Scala.
Bon, je pose le crayon deux secondes, j’ai besoin de toute votre attention. Eteignez Twitter, fermez Gmail, écoutez-moi : vous allez apprendre Scala. C’est un ordre. Si vous ne voulez pas être sur le côté de la route lorsque les petits jeunes roulant en Scala Bac+5 passerons à côté de vous, bougez-vous. Achetez un livre, prenez le temps de vous former à nouveau.
Etre bon en Spring, Hibernate, GWT c’est bien. Maintenant ce qui va faire la différence, ce sera la capacité à proposer sur le marché d’autres langages pour répondre aux clients. N’oubliez pas ce que j’ai dit au début : Scala c’est du bytecode qui tourne dans une JVM. Donc pas d’excuses, vous me ferez 2 séries d’abdos, et ensuite vous filez en formation Scala.
Non mais !
JESS3 / The State of The Internet from JESS3 on Vimeo. Vous pouvez maintenant éteindre votre ordinateur et reprendre une activité normale. Edit : apparemment, le 10 milliardième twitt vient d'être atteint. On n'arrête pas le progrès !... Lire State of the Internet '09
J'ai fait la connaissance de Bruno Sbille en mai de l'année dernière, à l'occasion de la circulation sur Internent de la vidéo "Scrum in the real world". J'en avais parlé dans un billet court, mais enthousiaste et j'avais demandé à Bruno s'il pouvait traduire les sous-titres en français[1]. Quelques mois plus tard Bruno m'a proposé de publier un... Lire Scrum, post-it et rock'n roll
Watch the following video. It will convince you that we have to do something about the horrible state of software engineering.
Bad Code from unclebob on Vimeo.
How could any team of disciplined professionals have produced a wretched mess like that? Clearly they were ignorant of good practices. Clearly they were inexperienced novices. Clearly their priorities and values were all wrong. If only they had been taught good coding practices, and good development skills. If only we could have gotten to them before they made such a horrible mess.
What we need to do is create a certification program that provides developers with the knowledge and skills that they need. This program will involve a course that teaches good development practice, and a certification that they are now knowledgeable developers. They can use that certification to prove to their employers and their fellow professionals that they are worthy of being considered true and clean software developers.
That’s what we need. Right?....
Eagle’s Entrails! Deer Droppings! and Elephant Phlatulence!I’m sorry, am I being vague? Is my opinion not clear enough? All right then, allow me to elaborate.
What Problem does Certification solve?Certainly there are certification organizations who have the problem of dwindling revenues. A new developer certification program would likely solve their problem.
And just as certainly there are tin-men who need hearts, lions who need courage, scarecrows who need brains, and developers who need self-esteem. A new developer certification program might just help those lackluster developers.
But who else is served by a developer certification program? Employers?
The Trials of Hercules.Consider Doctors and Lawyers. When a medical student earns an M.D., or a law student passes the Bar, that’s an achievement. The certification, in those cases is deeply meaningful because the certification is not easily won. To get it you have to spend many years, and many tens of thousands of dollars. What’s more, you have to acquire in-depth knowledge and at least a modicum of provable skill. You have to do something significant.
If we had a developer certification like that, then employers might find it useful. But I know of no developer certification program (except for one that I’ll mention later) that offers proof that the developer has accomplished anything of significance. Most certification programs prove little more than that the “developer” paid to attend a 3-5 day course. As an employer, I’m not particularly interested in the ability of a developer to pay to attend a 3-5 day course. As an employer I want to know what the developer can do.
Michaelangelo’s Apprentice.If you were hiring a guitarist for your band, you might be very impressed with someone who toured with Clapton. You don’t get to tour with Clapton unless you are talented. But more than just talented, you have to show up every day, you have to work well with others, you have to be willing to get the job done under pressure. Clapton doesn’t work with slouches!
A signed letter of recommendation from Clapton is a certification of significance! Not just anyone can get one of those. That letter will impress potential employers forever after.
As an employer, I want to hire people who have succeeded at working with others in the past. The more I trust those others, the better! No developer certification program that I know of (except for one that I’ll mention later) provides that kind of credible reference.
Over-promise and Under-deliver.The certification programs that I know of (except for one that I’ll mention later) make implicit promises that they can’t hope to begin to deliver. The implied promise is that the certificant has been shown to have some significant skill, ability, or knowledge. The reality is that you have to look at the word “significant” through the wrong end of some very powerful binoculars before it matches the truth. Indeed, there are certification programs that show absolutely nothing about the certificant except that they bought a seat in a class.
Notice that I said that the promises were implicit. That’s the whole key to making lightweight certifications profitable. The goal is to imply that the benefits of certification are so huge that people will pay to get the certification. Often that implication can be as simple and subtle as the choice of words used to name the certification.
Consider, for example, the title of “Certified Development Chief” imprinted on the certificate of someone who just took a “Development Chief” course. Who wouldn’t want to be a Certified Development Chief? And if you aren’t a Certified Development Chief, then what kind of Development Chief are you?
A course, a card, and a Bridge to sell.What significant accomplishment can a developer make by paying to attend (or even actually attending) an 3-5 day course? How credible a recommendation about any of the 20-odd students could an instructor of such a course make? I can answer both questions in two words, with apologies to SNL. “Jack” and “Cheese”. The accomplishment is miniscule, and the recommendation is meaningless.
So as an employer of developers I think you can take your course and card and show it to some other sucker. It don’t impress me much. Go away and come back later when you’ve accomplished the trials of Hercules and apprenticed under Michaelangelo. And make sure you bring letters of reference. NEXT!
The one I said I’d mention later.I’ve got an idea for a certification program that just might work. Now, bear with me because this is a little complicated. It’s an idea so revolutionary, so different, so incredibly new that I’m getting giddy just thinking about it.
What if we asked young graduates to actually get jobs as “interns” for awhile. What if we gave out responsibility to them in small incremental measures. What if they gradually learned more and more things while working for us. What if we guided them to ever greater accomplishments. What if we slowly gave them trials of Hercules to follows, and had them work with Michaelangelos.
Of course some of our people might leave and go to greener pastures. We’ll need to replace them. Also, our company might succeed and grow, so we’ll need to hire more good developers. So what if we…
OK, now hold on to your hat because this is where it gets really tricky. You might want to get up and walk around a bit, get a diet coke, eat a twinkie, or something to get your brain working.
Ready? OK, here we go…
So what if we… interviewed ... candidate developers? What if we asked them what accomplishments they’d achieved in previous employment. What if we asked them who they used to work with. And… ok, this is even wilder ... what if we called those references and checked them out?
Are you still with me?
What if we….
Naaaaahhhhh. Dumb idea.
Honestly, I think I’ve wasted your time. It’s a stupid idea. Never mind. We should all just go get certified instead.
Dans la droite lignée des Barcamps, le premier KawaCamp s'organise le 23 mars au Quigley's Point. Mais concrètement, un KawaCamp, c'est quoi ? C'est tout simplement un regroupement spontané et informel de développeurs Java, qui ont envie de discuter et de partager leurs dernières trouvailles. Contrairement à un JUG, il n'y a pas vraiment d'ordre... Lire Venez au KawaCamp le 23 mars !
Le Paris JUG se réunit de nouveau le mardi 9 mars à l'ISEP pour donner la parole à Emmanuel Bernard.
De 19h30 à 20h25 puis de 21h05 à 22h00, l'un dse principaux contributeurs d'Hibernate donnera les dernières nouvelles du célèbre framework de persistance, et présentera les différents algorithmes de recherche disponibles dans Hibernate Search.
Ceux qui ne pourront y assister en personne pourront toujours suivre la Wave en temps réel sur ce billet, ou depuis leur compte Wave à cette adresse : Wave Paris JUG "Emmanuel Bernard".
Elle sera retranscrite par la suite au format texte, pour ceux de mes lecteurs qui n'auraient pas de compte Wave.
// Styling var uiConfig = new WavePanel.UIConfig(); uiConfig.setFooterEnabled(true); uiConfig.setHeaderEnabled(true); uiConfig.setToolbarEnabled(true); uiConfig.setBgcolor('#FFF'); uiConfig.setColor('#000'); uiConfig.setFont('verdana'); uiConfig.setFontSize('12px'); // Wave embedding var wavePanel =... Lire Paris JUG "Emmanuel Bernard"
Assist in identifying, recruiting and hiring additional full-time Web development staff, emphasizing open-source framework expertise.
- Timeframe: ongoing, throughout the six-month engagement
- Deliverable: targeting 2-3 quality leads/hires
Since this was a local gig and I always like a good challenge, I asked my client to raise the number from 2-3 to 4-5. Shortly after signing that contract, my project began. Almost immediately, I began spreading the word on Twitter.
When TWC hired me, it was just the beginning of a larger initiative. They were making a number of large changes:
To help with the move to Agile, I contacted a good friend, Brad Swanson. Brad is the founder of Propero Solutions and has always had a passion for agile coaching and making teams more efficient. At the beginning of the year, we setup 2-day training class in Herndon, VA to kick-off the Agile Initiative. There were 15 existing developers on the team when I started and 40 people showed up to that initial training. Most of these additional folks were from Product and QA. Brad's message of working together quickly resonated with the group and you could see their eyes light up with their new-found knowledge.
After the success of Brad's training, we leveraged his network to help us find some very impressive coaches to assist with our efforts. We hired two Agile Coaches to start working with us at the end of January.
While our agile movement was progressing in January, I started contacting friends, former colleagues and referrals about coming to work for us. For friends and former colleagues, my e-mail simply outlined the positions available, the exciting opportunity of the project and that TWC was willing to pay very competitive salaries for strong engineers. While it didn't happen immediately, I did manage to convince 4 former co-workers to join me, including the team I built at LinkedIn and worked with at Evite.
Following those 4, most of the candidates we interviewed were referrals or folks that contacted me directly after seeing my tweet. I'm amazed that I never had to write a blog post to advertise the positions.
Once we identified potential candidates, we executed the following process:
This process turned out to be a great way to hire a kick-ass team very quickly. You might notice that HR was not involved at all in this process. While we did use them to post jobs and such, we found that our recommendation-based process of identifying high-quality candidates worked much better. HR was able to bring in folks with lots of buzzwords on their resume, but no one knew them or what they were capable of.
Once a person passed the screening questions, our interview focused more on a person's social skills than their technical ability. The first half of the interview was all about their career experiences and what they enjoyed/disliked about employers and projects. The second half consisted of a handful of very technical, hard questions that we expected people to struggle with. If they answered correctly, we were impressed. If they didn't, we examined how they handled explaining they didn't know the answer. It was interesting to see how many people didn't simply answer "I don't know".
One of my most interesting observations of the process was our question about "what was your most enjoyable employment experience and why?" Most folks responded with something very early on in their career, and often it was their first job. This caused me to reflect on our industry and careers as a whole and wonder if people get more miserable as they keep working. It's a shame there's not more folks happy with their current jobs.
By mid-February, we managed to fill most of our open headcounts. We'd successfully hired 2 Agile Coaches and 8 Developers in a little over 2 months. While everyone hasn't started yet, there's several of us now working in my Denver office. We pretty much caught everyone off-guard with our success and we've moved onto our next biggest problem - were do we put everyone? The TWC Broomfield office is building out space for us, but it'll likely take them a few months to complete the project. My office that fits 4 comfortably had 8 of us in their last week. I had to sit on a garbage can when pairing because we'd run out of chairs.
To solve our short-term space constrains, I've successfully negotiated additional space upstairs from our landlady and we've ordered a number of new desks for folks. Our desks arrive Monday and we're setting up pairing stations upstairs next week. All-in-all, it's been a wild ride with a fair amount of stress. Interviewing folks wasn't that stressful, but trying to hire folks while writing code and trying to deliver features for our project was challenging.
We've been emphasizing pair programming and hiring process required a lot of e-mail communication. When we were pairing, we'd ignore our e-mails for most of the day and then have to catch up at night. Once people started on-boarding, we had to figure out the best way to get them started and slinging code. We established an on-boarding plan and we've been able to get everyone running our app on their machines before lunch. We've even had a couple folks committing code by the end of the first day.
This week, we on-boarded 3 of our final 4 developers. I breathed a big sigh of relief that the hiring was over and we could get back to slinging code and making things happen. As luck would have it, I received an e-mail from my boss on Tuesday that the hiring engine is starting up again and we need to hire 6 more developers. While I'm not anxious to start the Hiring Engine again, I am glad to know it works well and it has helped us build a great team. I'm not going to post the positions as part of this blog entry, but there's a good chance you'll hear more about the gigs if you follow me on Twitter.
Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l'avenir qu'une seule JVM, qui tirerait le meilleur des deux que la firme s'est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s'est exprimé sur le sujet. Cette fusion n'est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l'une ou l'autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d'avoir l'occasion de l'étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c'est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l'ébauche d'une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l'intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l'angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l'avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l'OpenJDK.
Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : "We, at Sun..."
Jigsaw, les modules du pauvre ?
Adam Bien est l'un des Java champions les plus visibles et les plus lus d'internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C'est peut-être l'occasion de faire le point sur ce que propose Jigsaw.
Le projet Jigsaw proposera une implémentation permettant la mise en place d'un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.
Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d'aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu'OSGi en aborderait 90% ? La simplicité et la souplesse d'utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s'est ailleurs attiré les foudres des défenseurs d'OSGi, mais reste complètement défendable
Declaring Final Variables Elegantly Using The Assigner Design Pattern
A final variable is used to define a constant value and reference, and can only be defined once. In most cases, declaring a final variable is just a matter of assigning to a primitive value or an object reference directly. However, in some cases, declaring a final class/instance variable may be more involving especially it gets assigned from a method that throws an Exception (eg API for database access, web access), or it may involve multiple statements.
Java Quiz #33
La classe ci-dessous part d'une bonne intention, mais où est le problème ?

Je viens de découvrir une fonctionnalité méconnue d'Eclipse : les catégories.
Grâce à l'annotation javadoc @category, il est possible de définir des groupes virtuels de méthodes et de propriétés au sein des classes Java. Il est ensuite possible de les filtrer dans les vues Outline et Members, afin de n'afficher que ce qui vous intéresse.
Cette astuce peut être très pratique lorsque vous naviguez dans une classe imposante, et que vous cherchez à en comprendre la structure.
Pour peu que le code soit mal organisé, il se peut très bien que des méthodes métiers soient perdues au milieu des accesseurs, et que vous passiez à côté par inadvertance.
Un exemple, un exemple ! Puisque vous insistez, prenons l'exemple d'un simple POJO décrivant une Personne. Il est composé de deux constructeurs, trois propriétés et leurs six accesseurs, et une méthode métier pour calculer l'âge de la personne. Voici ce que propose la vue Outline par défaut : Avez-vous remarqué la méthode métier... Lire Eclipse : organiser son code avec les Catégories
So…. you’ve been developing serious Java applications for quite a few years now, and while it was fun and enjoyable to discover the best practices, the misc. tools, how the messy fragmented ecosystem of frameworks and libraries hardly wonderfully integrates thanks to amazing JEE-whatever integration stacks (Spring, no pun intended), you now feel that the platform has become pretty much boring, and you want to try something else..
Of course, you still love Java (it pays more) and think it is still the best way to write serious applications (currently waiting for Scala to get decent IDE support ?). You do not want to hear about this over-hyped language that is supposedly perfect because you simply don’t like languages that use half of the keyboard’s non-letter keys as metacharacters. But you definitely want to hack a little bit using some dynamic language (maybe because you feel like an idiot when these dynamic-language lovers tell you they get a 10x productivity boost by using XXX instead of Java – replace XXX by whatever trendy, over-hyped popular language of the moment).
Anyways.. for some reason, your choice is Python (if not, then the rest of this post is of no interest to you). You have read a book or two online, and since you’re not an idiot, you already know how to code basic stuff (still need to lookup some stuff here and there, not sure of what is idiomatic yet, but you have definitely grasped the basic concepts). However, you feel a little bit alone in this new world, wondering what the best practices are, which tools are generally used.. etc. And nobody on the internet really helps you because when it comes to giving technological advice, people are either of the “mine is bigger than yours” type, or the “everything depends on your needs/preference/[...]” BS.
So, here are a few things I learned while developping pymager, a RESTful image conversion/rescaling service (hopefully, it will help you to find your way):
Fin février s'est tenue la session londonienne de la conférence OSGi DevCon. Le support de la session d'ouverture est consultable sur le site de son auteur. Cette présentation est intéressante car elle est se concentre exclusivement sur le problème de la complexité des logiciels pour démontrer l'importance de la notion de modularité.
Le premier slide attaque fort avec cette phrase: "OSGi is a disruptive technology that will transform how enterprise Java applications are designed, developed and managed !".
La littérature consacrée à OSGi s'étoffe progressivement avec la sortie notable du livre 'OSGi and Equinox'. Deux chapitres sont librement consultables.
Le KawaCampParis 1 est prévu le mardi 23 mars à partir de 19h00 au Quigley’s Point à Paris. Les inscriptions s’effectuent via le Wiki directement, après avoir créé un compte. Si vous n’avez pas vécu l’expérience BarCamp au moins une fois, venez voir ce que cela donne. C’est l’occasion de débattre de sujets à la mode dans notre monde de Geek Java en ce moment. Le mot HTML 5 semble être le sujet le plus demandé pour l’instant.
Rendez-vous le mardi 23 mars 2010 à 19h00.
Voilà je m’appelle Nicolas, je prépare une présentation sur les communautés et les tribus dans le monde informatique, plus particulièrement dans notre univers à nous, les Geeks.
Là c’est là que tu entres sur scène, car j’ai besoin de toi. Je cherche à faire un maximum de bruit afin de diffuser ce sondage à des développeurs, à des salariés de SSII, à des équipes logicielles chez des éditeurs, afin d’évaluer les attentes de chacun par rapport à l’esprit communautaire.
Je n’en dis pas plus pour ne pas vous influencer, mais je vous ferai part des résultats du sondage bien entendu.
Donc voici ce que je te demande : peux-tu exceptionnellement diffuser cet article à tes connaissances afin qu’elles y répondent ? Alors je ne parle pas de tes copines sur Facebook, mais bien de tes VRAIS amis, ces barbus avec un teeshirt Linux qui codent jusqu’au petit matin, un carton de Pizza Hut posé sur le bureau.
Je compte sur toi,
Nicolas Martignole
URL du formulaire : [https:]
—————–
Tu peux aussi répondre en ligne directement ci-dessous :
Chargement…

Bonjour à tous,
Après la venue de Gildas Cuisinier (encore merci à lui) au mois de Février (voir les photos), nous attendons la venue de Guillaume Laforge le Jeudi 11 Mars.
Guillaume Laforge dirige le projet de langage dynamique Groovy depuis de nombreuses années. Il travaille pour SpringSource / VMWare, il a coécrit un livre intitulé Groovy in Action, chez Manning, et vous pouvez rencontrer Guillaume sur le circuit des conférences internationales où il prend plaisir à évangéliser les foules en délire sur Groovy, Grails, et compagnie.
Guillaume présentera Groovy, sous trois angles d'attaque :
Nous nous réunirons à :
Technopôle Marseille Provence
Château Gombert
Les Baronnies, Bâtiment B, RDC
Rue Paul Langevin
13013 MARSEILLE
(le bâtiment rouge que l'on aperçoit ici)
N'hésitez donc pas à venir nombreux le jeudi 11 mars à 19h.
Comment puis-je ne rien rater du MarsJUG ?
Vous pouvez suivre son twitter
Suivre les évenement sur le site
Merci de vous inscrire à cette conférence et à la mailing list
Pourquoi venir au MarsJUG ?
Comme tous les JUGs le MarsJug permet de rester à la pointe de ce qui se fait en Java en participant à des conférences et rencontrer des speakers reconnus dans le monde.
Vous pouvez venir par curiosité pour découvrir les JUGs, par amour des JUGs parce que vous êtes habitués, pour vous tenir au courant de se qui se fait de nouveau ou alors pour boire un coup avec nous après le JUG ![]()
A quelle fréquence le JUG se réunira ?
Un jeudi tous les mois ! (dans la mesure du possible)
à bientôt,
Alain Defrance.
Aaaah l’Esprit d’équipe.
Cet ingrédient vendu dans toutes les bonnes boutiques de formation en Managment. Des coachs déversent des litres de savoir stéréotypés, en vous promettant monts et merveilles… Mais après avoir cramé vos 30 jours de DIF, le constat est amère : vous n’êtes pas fichu de motiver votre équipe. En fait vous avez même un fichu mal à comprendre comment motiver vos développeurs.
Ce qui frappe aujourd’hui c’est avant tout le changement de génération dans le monde du développeur. Je pense qu’il y a eu un creux sur le nombre de développeurs en France il y a quelques années. J’ai entendu que le développement était sale, que les jeunes diplômés délaissaient la voie sacrée du Développeur pour prendre d’autres chemins. Cela donne, et moi le premier, de jeunes trentenaires dans la force de l’âge, aveuglé comme des moustiques autour d’un lampadaire, d’un néon où il y aurait marqué « Chef de Projet ». Passé les quelques mois, combien d’entre vous découvrent la dur réalité de cette tâche ? Gérer un projet c’est facile. Gérer des hommes, ça c’est amusant.
La difficulté du jeune manager, et qui veut piloter une équipe, c’est avant vous, les 25-35 ans, que l’on appelle « Génération Y« . Or je me demande si les méthodes de gestion et de management ont évolué aussi vite que nous.
La génération Y est cette tranche d’âge de 25-35 ans, qui débarque dans le monde du travail, bien déterminé à faire sa place. Basé sur la méritocratie, cette génération ne respecte ses pères que lorsque ceux-ci sont légitimes. Que ce soit avec un charisme, de l’expérience, ou une réelle capacité à mener des personnes, il n’est pas rare de voir quelques oiseaux capable de gérer correctement une équipe.
Et puis il y a les autres…
Alors disons qu’il y a ceux qui se sont pris un coup de foudre. Un matin je me réveille et je décide de grimper dans la chaîne alimentaire de l’entreprise. Les motivations les plus diverses font que les gens veulent devenir « chef de… ». C’est parfois pour masquer un lourd handicap et une réelle incompétence technique. C’est parfois pour payer le crédit du Citronault Picasso. C’est parfois une fuite en avant… Mais sont-ils heureux pour autant ?
Le management de premier niveau, les premiers « chefs », sont parait-il les responsables du Stress de premier niveau (source). A quand en effet, non pas un Bonus indexé sur votre capacité à délivrer un logiciel, mais un bonus social voté par votre équipe selon votre performance de manager ? Mince alors. Après tout, délivrer un logiciel, c’est ce pour quoi vous êtes payé. Ensuite, être capable de gérer des personnes, de les aider sans les stresser, c’est sacrément plus dur que de faire mumuse avec Microsoft Project non ? A quand une nouvelle application dans Microsoft Office pour suivre le stress de vos collaborateurs ?
L’Esprit d’équipe… Si chaque équipe avait un budget illimité, bien entendu que la vie serait plus facile. Mais pourtant il existe un bon nombre de moyens simples pour transformer une équipe qui dort en une équipe qui s’amuse, qui se marre et qui avance.
Prenez les méthodes Agiles. Il y a ceux qui hésitent à changer et qui veulent d’abord comprendre si l’Agilité est faite pour eux. Et il y a les autres, qui changent de méthode, et qui ensuite comprennent qu’il fallait changer pour avancer. C’est l’exemple type où il faut se jeter dans le grand bain, boire une bonne tasse, et ensuite seulement commencer à avancer et à reconstruire quelque chose. Mettre en place une nouvelle méthode c’est bien. Mais si vous n’avez pas d’Esprit d’équipe, c’est dangereux.
J’avais parlé il y a longtemps de la difficulté à créer une équipe de développement. Il est important de mélanger les types de développeurs. Dans la réalité il faut composer avec un existant, avec un capital humain. Allez je le dis… il faut gérer le « Legacy Humain« . Mais cela n’empêche pas d’apprendre quelques techniques pour qu’une équipe marche.
Trouver de bons développeurs c’est d’abord la cooptation. Donnez 3000 EUR si l’un de vos gars trouve la perle rare, et que celle-ci passe le cap de la période d’essai. Ce n’est que 5 semaines d’annonces sur un site de recherche d’emploi… Une paille.
Le développeur est un animal grégaire, qui migre de sociétés en sociétés tous les 3 ans en moyenne. Des personnes avec 10 ans d’expérience en Java ont au moins fait 2 voir 3 sociétés. Elles ont rencontré du monde. Et elles ont des amis. Une sorte de FaceBook, mais en vrai. Et ce qui devient intéressant, c’est aussi leur capacité à vous proposer de bons profils. Un peu comme une équipe où chacun connaît ses points forts et ses faiblesses, les +10 ans se baladent avec un réseau de connaissance assez important.
C’est un réseau qui dort. Si vous n’êtes pas inscrit sur Viadeo ou LinkedIn, je ne peux rien pour vous. Comme un bon petit jardinier, vous devez cultiver votre réseau d’amis. N’acceptez pas non plus le tout venant. Ces réseaux professionnels ne sont pas des réseaux de « copains » comme FaceBook ou « Copains d’avant ». Avoir 13450 amis c’est stupide. En avoir aucun, c’est dommage.
Là où je voulais en venir au départ, c’était de vous parler d’Esprit d’équipe car je prépare un sujet de conférence sur les Communautés, comme catalyseur pour l’Entreprise. Comment les groupes d’utilisateurs dynamisent le marché ? Comment un esprit communautaire peut-il se créer entre les consultants d’une entreprise ? Comment les développeurs Java d’un éditeur de 650 personnes peuvent-ils créer une communauté ?
Esprit es-tu là ?
Es-tu quelqu’un ou non ?

Une carte bloquée dans le tableau Kanban, c'est du gaspillage
« Cette carte est bloquée car il nous manque un contenu, un fichier sans lequel le site ne peut être mis en ligne. On sait que ça va prendre plusieurs jours. En fait, on ne sait même pas quand est-ce que ce fichier sera disponible. En plus, cette carte n’est vraiment plus prioritaire ».
Voilà ce que j’ai entendu il y a quelques jours. L’équipe a déjà travaillé sur cette carte, le site est bien avancé. En fait, il ne manque qu’un fichier, mais cela bloque sa livraison et, par effet de bord, une case dans le tableau Kanban, réduisant la capacité à réaliser d’autre demandes.
La première réaction est de dire « le Kanban ne fonctionne pas, ce n’est pas assez flexible ». Il suffit de pousser la carte sur le bord et de laisser la place aux autres items à réaliser.
Holà! Doucement, doucement! Un des objectifs de la mise en place d’un système Kanban, est de rendre visible les gaspillages et de permettre ainsi de prendre des actions pour les endiguer et améliorer le processus.
Donc nous avons un succès, un beau succès, Kanban fonctionne bien! Maintenant qu’est-ce qu’on fait?
Nous pouvons identifier plusieurs gaspillages dont les suivants :
Ces constatations m’amènent à poser les questions suivantes :
Dans les jours et semaines à venir, je vais aider l’équipe à trouver ses réponses à ces questions et réduire les gaspillages.
For many years, we have been using Java Threads for developing numerous Client-Server based applications. While it's always desirable to have a highly responsive Client application, handling a high volume of client requests has always been a prime goal of any Server application. However, designing a highly-scalable server requires lots of analysis. Without careful design and adherence to a well thought out underlying policy, a thread based system can fail to produce the desired outcome.
In this article, we'll discuss certain design principles that should be followed when the objective is to build an efficient, thread-safe application.
Thread Safety lies in DomainAs a design principle of thread safety, the vital point to look into is "Domain First." After all, the whole structure of an application lies on the Domain itself. If you get your domain model right, most of the problems are automatically taken care of. A model represents certain aspects of business logic consisting of various constraints and invariants. Understanding the pre and post conditions of a model are much needed in order to make the realized application thread-safe.
Let's imagine an travel agency that arranges budgeted cars for their traveler guests. They need an interactive car rental application that allows them to book multiple cars at different tourist locations on different dates within a specified price range. As they keep making multiple rental requests, at the same time if the system fails to find a car at particular location within price range, they want to be notified with suggested locations on the same screen.
We can think of this as a booking Requester taking the renal requests and putting them in a thread safe collection CarBookings that would be read
concurrently by an actual CarFinder process to provide suggested locations. If CarFinder succeeds, it forwards this via the booking engine to the booking rental location. If CarFinder does not succeed, it tries to find the cars based on the price range and nearest location. Once found, it adds the info to another thread safe collection
CarBookingAdvices.
There are many thread safe data structures available, but if you're sure about the Thread Safety policy that you want to adhere to, it's best to create a domain model on your own. For example:
class CarBookings{
private final Set bookings = new HashSet();
public synchronized void putCar(CarBooking booking){
bookings.add(booking);
}
public synchronized Set getBookings(){
return Collections.unmodifiableSet(bookings);
}
}
Since the methods putCar() and getBookings() provide a secure way of accessing the non-thread-safe instance variable bookings, the CarBookings can be used
safely by both the BookingRequester and CarFinder process running in different threads. This meets our simple thread safety requirement.
//Defining BookingAdvice
class BookingAdvice{
private final String bookingId="";
private final BigDecimal rate=new BigDecimal("");
private final String location="";
//Getter and Setter ommited
}
class BookingAdvices{
private final Set<BookingAdvice> advices = new HashSet<BookingAdvice>();
public synchronized void putAdvice(BookingAdvice advice){
advices.add(advice);
}
public synchronized Set<BookingAdvice> getAdvices(){
return Collections.unmodifiableSet(advices);
}
}
//Defining Requester
class BookingRequester{
private CarBookings bookings;
private BookingAdvices advices;
public void requestBooking(CarBooking booking){
bookings.putCar(booking); //Line 1
displayAdvice(advices.getAdvices()); //Line 2
}
private void displayAdvices(Set<BookingAdvice> advices){
//Displays the advices on the same screen
}
}
//Defining Finder
class CarFinder{
private BookingAdvices advices;
private CarBookings bookings;
public void processAdvice(){
List<BookingAdvice> adviceList = getGeneratedAdvices();
for(BookingAdvice advice: adviceList)
advices.putAdvice(advice); //Line 3
findAndProcessBookings(bookings.getBookings()); //Line 4
}
private List<BookingAdvice> getGeneratedAdvices(){
//Generate advice based on requests
}
private void findAndProcessBookings(Set<CarBooking> bookings){
//Finds advice for the booking if required
}
}
Hiding Model State
But, there is a caveat: if the CarBooking class is mutable, then there is a possibility of modifying each CarBooking instance in the set returned by getBookings(). Does it make our model brittle? Well, as long as we can make sure that it won't be modified later on, we'll be fine with that. But, sometimes it's easier get thread safety by hiding the model state and blocking the access to it thereafter. Here, we make CarBooking immutable and add a copy constructor:
class CarBooking{
private final String bookingId;
private final String location;
private final BigDecimal rate;
//Copy constructor
public CarBooking(CarBooking booking){
this.bookingId= booking.getBookingId();
this.location= booking.getLocation();
this.rate= booking.getRate();
}
//public Getter methods below
}
class CarBookings{
//Modified version
public synchronized Set getBookings(){
Set newBookings = new HashSet();
for(CarBooking b : bookings){
CarBooking newBooking = new CarBooking(b);
newBookings.add(newBooking);
}
return Collections.unmodifiableSet(newBookings);
}
}
So, when getBookings() returns, it returns a copy of the CarBooking, thus not allowing modification of the original state--which makes it purely thread safe.
Sometimes you might find yourself being overburdened with handling the thread safety in your domain model; in that case you can simply delegate it to a range
of Java built-in data structures that are already proven and tested to be thread safe. Like in our example, if we had to use bookings as HashMap<String, CarBooking>, where String could represent bookingId, we could have easily replaced that with ConcurrentHashMap--which is a thread safe HashMap. Likewise there are many other data structures available (under the java.util.concurrent package) like CopyOnWriteArrayList and ConcurrentLinkedQueue, to name a few.
To coordinate multiple threads in a lock-based application, the OS and JVM have to burn fair amount of CPU cycles for context switching and thread scheduling--making the system less responsive sometimes.
This can be avoided by allowing only one thread to gain access to work on a unit model (either CarBooking or BookingAdvice) at a time, and also making sure that same unit model should not be re-worked by the same thread. To make this happen, we can employ bounded BlockingQueues (BookingQ and AdviceQ) that would act
as a mediator between Requester and CarFinder.
So, for a rental request, the Requester would just create a CarBooking and put it in the BookingQ queue, and on the other hand, CarFinder would take that
off of the queue. The same thing will be done by the CarFinder to return a BookingAdvice in the AdviceQ queue. This way, multiple Requesters and CarFinders can work
asynchronously, making the system highly responsive.
While synchronized lock provides an easy way to work with multiple threads, improper usage of the lock may cause unpredictable results. This becomes obvious when multiple locks are acquired to perform an atomic operation where the first lock is held until last lock operation is performed. Let's consider our BookingRequester and CarFinder that are using simple java Sets instead of CarBookings and BookingAdvices. Here two operations: putting request and getting
advices for Requester (vice versa for CarFinder, lines 5,6,7 and 8) become implicitly atomic under the same lock:
class BookingRequester{
private final Set bookings = new HashSet();
private final CarFinder finder;
public BookingRequester(CarFinder cf){
finder = cf;
}
public synchronized void requestBooking(CarBooking booking){
bookings.add(booking); //Line 5
displayAdvice(finder.getAdvices()); //Line 6
}
public synchronized Set getBookings(){
return bookings;
}
}
class CarFinder{
private final Set advices = new HashSet();
private BookingRequester bookings;
public CarFinder(BookingRequester br){
bookings = br;
}
public synchronized void processAdvice(){
List adviceList = getGeneratedAdvices();
for(Advice advice: adviceList
advices.add(advice); //Line 7
findAndProcessBookings(bookings.getBookings()); //Line 8
}
public synchronized Set getAdvices(){
return advices;
}
}
Now, a problem starts to creep in when two threads T1 and T2 try to call Requester requestBooking() and CarFinder processAdvice() respectively at the
same time. During requestBooking, before T1 calls getAdvices() on CarFinder (Line 6), it has to wait for T2 to complete processAdvice. But to complete processAdvice, T2 needs to call getBookings() on Requester (Line 8), which won't happen until T1 completes requestBooking()--leading to a deadlock situation.
In our previous implementation of BookingRequester and CarFinder, we have already delegated the two operations to be handled independently under different locks (one for CarBookings and another for BookingAdvices, lines 1, 2, 3 and 4) to avoid any deadlock.
But, here we can simply resolve it by moving synchronized from the entire method to only the time required to put the booking (Line 5) and advice (line 7).
Another important point regarding deadlocks would be the order in which the resources are accessed in an atomic operation. If two threads work on an operation with two resource locks being held in a different order, it can lead to a deadlock situation too. So, make sure all threads calling an atomic operation get all resource locks in the same order.
ConclusionDesigning and improvising a thread based application is a challenge. But by following certain design principles and guidance, this can be easily overcome. At the same time, clear understanding of thread safety policy is also essential as it helps you simplify the design. There are many other techniques available that we couldn't cover here. However, the principles presented here will always assist you in overcoming some of the thread safety related hurdles you might be facing as you develop thread-safe applications intended for operation on modern multicore and multiprocessor computers.
![]() |