Il vend avec du free, il a tout compris

“Le meilleur moyen de gagner de l’argent ? Tout proposer gratuitement ! C’est la thèse surprenante de Chris Anderson, rédacteur en chef de Wired, le magazine de référence du web et du numérique. Idéaliste ou visionnaire ?” Source : ECO89

ECO89 a publié il y a un mois un article sur la sortie de livre “FREE!” de Chris Anderson qui présente une nouvelle économie qui consiste à proposer ses services ou produits gratuitement pour mieux vendre ensuite. Ironie, le livre ne sera pas distribué gratuitement en France …

L’article nous en offre un extrait, « les dix principes du raisonnement d’abondance ». Voici 5 de ces principes (les 5 autres m’interesse moins):

1. Si c’est numérique, c’est que cela peut-être gratuit.
2. On ne peut pas concurrencer le gratuit.
3. On achète lorsqu’on est obligé ou lorsque ceci nous simplifie la vie
4. Si cela peut être gratuit, tôt ou tard quelqu’un le proposera gratuitement.
5. Pour vendre avec du gratuit, il est nécessaire des redéfinir son marché.

Après quelques exemples cités dans les commentaires et quelques “Ah bah non on ne peut pas tout proposer gratuitement ! C’est pas possible !”, un lecteur réagit et dit :

Il ne faut pas confondre low cost, gratuit avec de la pub, et gratuit [...]. Le gratuit avec de la pub, comme « 20 minute », ce n’est pas du gratuit. On paye tous les jours le 20 minutes dans les produits que l’on achète tous les jours. 20 minute ce n’est juste qu’un journal pour lier consomateurs et annonceurs, avec quelques informations autour des pubs pour faire croire qu’on lit un journal d’information [...].
Enfin, le vrai gratuit, c’est celui où le produit est gratuit, qu’il n’y a ni pub, ni de marge arrière et où il ne sera pas associer à un tas de service exorbitant [...]. Le plus belle exemple sont les logiciels libres. Les logiciels libres, ne comportent aucune pub, peuvent être modifiés et copiés à volonté. Il n’y a aucun service ou produits associés.

STOP ! Les logiciels libres sont donc des produits distribués gratuitement par de gentils développeurs qui travaillent très dure dans l’unique but d’être gentil. Linux et Apache ont peut-être démarré dans cette esprit. Mais si ces deux projets sont ce qu’ils sont aujourd’hui, c’est bien qu’un portefeuille invisible y met des sous de temps en temps …

Au même titre que le “20 minutes”, l’open source est un investissement. Le quotidien déplace les frais vers ses annonceurs, le  logiciel libre déplace les frais de l’achat des licences vers le service (1). Il est proposé gratuitement mais avec tout “un tas de services exorbitants” (intégration, support, évolution). Qui offre ces services ? La société éditrice ou les sociétés de services spécialistes de cette solution.

Enfin l’entreprise utilisatrice qui investi dans une solution open-source bénéficiera gratuitement des corrections et des évolutions que la communauté apportera.

Agile, intégration et … Rock’n'roll ?

Je suis actuellement en mission dans une équipe d’intégration pour la refonte d’un SI vers des applications Java/J2EE (principalement). Le périmètre d’intervention de mon équipe se situe à la fois au niveau du développement, de la qualification et de la recette client. Nous sommes donc décrit comme une équipe transverse.

Notre quotidien :

• Livrer aux équipes de qualification puis au client, les releases de nos équipes de développement,
• Maintenir les différents environnements de qualification et de développements opérationnels

Mais aussi :

• Etre un garant de la cohérence des environnements applicatifs pour les différents acteurs du projet
• Assister dans la mise en oeuvre des différents éléments de l’architecture globale du SI (je pense notamment aux éléments de sécurité)

Et enfin :

• Toujours améliorer nos processus pour fournir à nos “clients” un service efficace, réactif mais aussi constant.

L’organisation globale du projet possède des caractéristiques des méthodes agiles. Je pense aux releases fréquents des équipes de dévelopement (1 fois par semaine en moyenne pour chaque application du SI) et à l’implication du client dans la recette de chaque version qui lui ait livré (1 fois toutes les 2 semaines en moyenne). En revanche le périmètre des fonctionnalités est definit au démarage du projet sous forme de contrat : c’est un projet au forfait. Notre équipe d’intégration maintient en quelque sorte l’infrastructure d’une usine de développement applicatif.

J’ai pu lire sur différents blogs que des méthodes agiles tel que SRUM ne sont pas adaptés aux projets de type TMA (dont le mode de travail est très proche de celui de l’intégration). Or les valeurs supportés par agile, sont des valeurs qui pourrait s’intégrer parfaitement à notre mode et améliorer énormément nos processus :

(de wikipédia)

• L’équipe (« Personnes et interaction plutôt que processus et outils ») : Pour assurer une qualité de service constante il faut que chaque membre de l’équipe entretienne un niveau de compétence uniforme. La communication est primordiale (ce n’est pas nouveau en même temps).
• L’application (« Logiciel fonctionnel plutôt que documentation complète ») : Ça je vais avoir du mal à l’expliquer à mes chefs de projet ! Le problème de la documentation c’est qu’elle devient néfaste si elle n’est pas à jour. Combien de temps perdons-nous à corriger les problèmes survenus lors de l’application d’une documentation obsolète ? S’il faut vérifier la pertinence de la documentation crée par ses collègues, où est l’intérêt de la documentation ?
• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Dans notre cas ce n’est pas LE client mais LES clients : le client du projet, les équipes de développement et de qualification. “Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes”. Pour nous il faut que chaque acteur se contente de la valeur qu’il percoie dans le service que nous offrons : en gros il faut que tout le monde soit content. Ainsi il est necessaire d’adapter constamment nos services aux besoins de nos clients. Voici un billet sur le concept de la valeur.
• L’acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : Il n’est pas facile de faire accepter les changements aux autres, alors pourquoi ne pas tout mettre en œuvre pour que le changement soit aisé chez nous, et qu’il devienne moteur d’innovation et de satisfaction pour nous et nos clients.

Qu’est ce qui pose problème à l’application de SCRUM dans notre contexte ?

Twitter : le crowdsourcing de l’actu

Récemment j’ai lu un article présentant twitter comme le possesseur de la recherche dite temps réel du web. L’article ajoutait que google est le moteur de recherche du passé et twitter  celui du présent. En effet Google référence des données indexées,  de l’archive, tandis que twitter référence le “What’s going on — Right now !”, ce qui se passe maintenant sur le web (et dans le monde).

twitter bird

Twitter est un outil efficace pour être spammé suivre en temps réel l’activité de ses amis. Potentiellement ils peuvent tous  devenir témoins de l’actualité. En imaginant avoir beaucoup d’amis, twitter devient un outil de crowdsourcing de l’actualité.

C’est ce qui est arrivé après la tragique fusillade en Allemagne où la rédaction de  France 24 a pu retrouver un témoin gràce à twitter. D’après cet article, les premières infos sur certains événements arrivent de plus en plus souvent sur Twitter avant d’être traitées dans les dépêches d’agences de presse.

Réalité augmentée

Voici une vidéo qui nous vient tout droit du futur : un bel exemple de ce que pourrait être la réalité augmentée de demain. La vidéo est néanmoins quelque peu alarmiste. Je vous laisse découvrir :

Il y a quelques mois j’avais rencontré des personnes de Total Immersion, un éditeur de logiciel spécialisé dans la réalité augmentée. Leurs solutions ne sont pas comparables à ce que vous avez pu voir dans la vidéo précédente, mais elles restent impressionnantes !

REST, framework & pattern

Après un article sur les mashups, il est normal que je me sois intéressé un peu plus au services web dit RESTful.

Qu’est ce qu’un service RESTful, et plus particulièrement l’architecture REST ?

Plutôt que de répondre à la question, voici une selection d’articles :

• RESTful Web Services
• Pour ne plus être en REST, comprendre cette architecture
• How to create a REST protocol

Mais voilà dans tous ce que j’ai pu lire sur REST, quelquechose m’a manqué… J’ai besoin de toucher les choses, il me fallait voir de plus près la Technique.  Et je ne suis pas le seul, la question revient souvent dans les commtaires de blogs : “Concretement, si je veux que mon site soit en REST, je fais quoi ?”.

C’est ainsi que j’ai commencé mes recherches sur les différents frameworks disponibles en PHP ou en Java. Je me suis arrêté sur le framework Konstrukt en PHP.
En voici les grands principes, retrouvés dans d’autres frameworks comme Restlet en Java :

1. Une uri = un controlleur.

L’uri ou l’url est l’adresse qui identifie ma ressource. Le controlleur est l’objet qui va traiter ma requête. Il vient du pattern MVC. Chacune de mes requêtes, c’est à dire l’uri demandé, est traitée par un contolleur sélectionné en fonction de celle -ci.
Cas pratique 1 : je suis une agence de voyage, et je souhaite que l’on accède à la liste de tous les aéoports par mon site. Je saisis www.monagence.com/aeroports dans la bar d’adresse de mon navigateur et j’obtiens la liste comme demandé. Nommons le controlleur qui traite ma requête “aeroports_list_controller”.
Cas pratique 2 : je suis toujours mon agence de voyage et je souhaite afficher les détails du vol 816 aux départ d’Orly. Je saisis alors l’url www.monagence.com/aeroports/orly/vols/816. Nommons le controlleur “vols_show_controller” qui affiche les détails du vol 816.

Voila pour le premier Principe.

2. Un controlleur possède deux comportements.

Le premier est celui décrit en 1. Le second est un comportement de routeur. En réalité dans le cas pratique 2 ce n’est pas 1 controlleur qui traite ma requête mais 5. Le premier qui entre en jeu est le controlleur racine “root_controller” qui me redirige vers “aeroports_list_controller”. Pourquoi? Car le premier éléments de mon uri est “aeroports”.

De la même manière “aeroports_list_controller” me redirige vers “aeroport_show_controller” pour traiter “orly”. Enfin en passant par “vols_list_controller”, j’arrive à “vols_show_controller” qui affiche les détails du vol 816 au départ d’Orly.

3. Un controller connaît le contexte dans lequel il est appelé.

Le controlleur “vols_list_controller” est commun à tous les aéroports. Les données mises à disposition par celui sont fonctions de l’aéroport qui l’appelle.

Enfin il ne reste plus qu’a implémenter dans chaque controlleur les méthodes GET, POST, PUT et DELETE de REST.

Voici avec le framework Konstrukt ce que donne le code d’un controlleur :


class components_aeroports_List extends k_Component {
function map($name) {
return 'components_aeroports_Show';
}
function GET() {
global $aeroports;
$this->document->setTitle("aeroports");
$t = new k_Template("templates/aeroports-list.tpl.php");
return $t->render(
$this,
array(
'aeroports' => $aeroports->all()));
}
}


Nous avons donc une fonction map qui permet de rediriger vers le controller aeroports_Show lorsque il y a un éléments dans l’adresse après “aéroports”,  ”orly” par exemple.  Puis on peut remarquer l’implémentation de la méthode GET faisant appel à un template pour afficher la liste des aéroports.

Pour résumer le schéma général de l’implémentation d’une architecture REST peut se faire avec un pattern Chain of Responsibility. Car finalement c’est pratiquement le pattern que je décris ici.

Comprendre comment était implémenté un des frameworks m’a aidé à mieux comprendre REST. Et c’est comme ca que je me suis confronté à la difficulté de concevoir une architecture orienté ressources plutôt qu’une architecture orienté services.

Google Earth 5.0

Google vient de sortir une nouvelle version de son désormais très populaire Google Earth. Par ici la vidéo, tout simplement WOW !

Meet Hudson

Voilà, cela fait quelques mois que j’ai rencontré Hudson. Depuis on ne se sépare plus.

Hudson est un outil d’intégration continue que j’avais mentionné dans ce précédent billet, mais je ne l’avais pas testé à l’époque. Et bien c’est chose faite maintenant.

Auparavant nous travaillions avec Cruise Control, un outil similaire. Alors pourquoi avoir changer ?

La liste est longue et vous trouverez les arguments facilement sur google, mais j’en retiendrai 3 :

1. La facilité d’installation et de paramétrage. Un simple war à déployer sur un tomcat par exemple. La documentation est très bien faite sur le site.
2. Le telechargement et l’installation de plugin directement sur l’outil.
3. La publication de flux RSS en natif.
4. Parce que c’est amusant

Autre chose vraiment bien avec Hudson, c’est qu’il n’est pas seulement un outil d’integration continue, son extensibilité lui permet d’être outil polyvalent et efficace dans presque toutes les tâches d’integration d’un projet.

Ainsi je peux gérer :

1. le déploiement automatique de mes applications sur mon environnement cible,
2. le passage de patchs sur les bases de données,
3. la planification de routines sur mes serveurs.

Un point négatif tout de même  : les plugins. Et oui c’est à la fois un des points forts d’Hudson et son point faible. Je m’explique : Hudson propose une multitude de plugin pour étendre l’outil. Ces plugins sont développé par vous et  moi. En effet Hudson est un produit open-source. Ainsi on trouve des plugins inachevés (donc bugués) ou encore qui ont l’air fantastiques, mais dont la documentation est quasi-inexistante, donc inutilisables !

Hudson est un produit encore jeune, les première versions datent de 2007, mais il évolue très rapidement (94 releases en 1 an 1/2). Aujourd’hui je vois beaucoup de projet en entreprise l’utiliser, ca mérite d’y jeter un oeil.

L’integration Continue

L’intégration continue est une pratique en génie logiciel qui consiste à intégrer fréquemment le développement des différents membres d’une équipe de projet. Techniquement, à chaque fois que l’un des membres de l’équipe publie ses modifications du code source (“commit”) sur l’outil de gestion de version (comme CVS ou subversion), l’outil d’intégration continue compile le code source et très souvent publie un rapport destiné aux développeurs. Un tel outil peut aussi déployer la version compilé du projet/application vers un serveur d’application et soumettre l’application à des tests unitaires et de non-régressions.

Pour bien comprendre ce qu’est l’intégration continue, je conseil cet article “Continuous Integration” par Martin Folwer dont la version original date de 2000.

Les bénéfices d’une telle pratique sont les suivants :
Estimation de charge, correction de bogues et contribution du client/utilisateur :
Dans un processus d’intégration différé (càd une fois que les développements sont terminés ) il est souvent difficile de prédire la charge effective. En effet lors de l’intégration c’est une multitude de bogues qui vont se superposer et en cacher d’autres. Il devient alors difficile d’estimer combien de bogues on aura à corriger et combien de temps mettront ces corrections.
Avec l’intégration continue, si j’introduis un bogue dans mon code, je m’en apercevrais rapidement (voir immédiatemment) et il sera alors plus facile à corriger (car il n’y aura pas ou peu d’accumulation). De plus il n’y a plus besoin d’estimer la charge du processus d’intégration car il fait parti du processus de développement.
Enfin l’intégration continue permet aussi de pouvoir estimer facilement l’état fonctionnel de notre application. En effet le but est d’avoir à tout moment une application déployée qui marche (et dont l’utilisateur pourra faire un retour).

En ce moment je travaille sur un projet utilisant le principe d’intégration continue. Nous utilisons l’outil CruiseControl. Je sais qu’un outil plus performant est récemment sorti, Hudson, mais je ne l’ai pas encore étudié.

Le pouls de l’opinion

RTGI est une jeune entreprise innovante qui développe un ensemble de solutions technologiques de repérage, de suivi et d’analyse du web social : blogs, forums, wiki, réseaux sociaux, moteurs de recherche, médias traditionnels en ligne et leurs espaces participatifs.

Une de leur solution est particulièrement intéressante : linkfluence.

Ils proposent “d’écouter et d’analyser l’ensemble du web social, ses médias (blogs, sites de presse), ses discussions (forums, nano-publications, …), ses lieux d’interaction et de mobilisation (réseaux)”. Rien que ca …

Je vous propose de jeter un oeil sur cet exemple couvrant l’évènement des élections américaines. Ca vaut le détour …

Créez votre propre Google Map

MapLib.net est un service qui vous permettra de créer gratuitement et rapidement une carte interactive de n’importe quelle image. Comment ça marche ? MapLib.net superpose l’interface de Google Map sur votre image. La carte ainsi construite pourra être héberger sur le site de MaLib.net ou directement sur votre serveur.

Je me suis posé la question de savoir comment MapLib a-t-il réussi cet exploit, et dans l’API javascript de Google Map j’ai trouvé ceci :
Une méthode addOverlay et une classe GGroundOverlay permettant d’ajouter une image sur le sol d’une carte Google Map.
Voila ce qu’on peut obtenir avec cette méthode :