Archives de catégorie : Software

Le futur des applications en ligne / Lancement d’AIR demain

Demain soir a lieu le lancement officiel d’AIR d’Adobe (vous y serez ? Moi, oui !).

L’occasion de se reposer la question : quel est l’avenir des applications en ligne ?

On peut utiliser une application qui va se jouer dans le navigateur (un service Internet quoi).

Avantages :

L’utilisateur n’a rien à installer, donc un accès rapide à l’application, un accès depuis n’importe quel ordinateur, et pas de problème de mise à jour ;
On bénéficie de facto de toute les fonctions autour des URL (bookmark, copier / coller, et les effets viraux, en avec la transmission très facile de l’adresse du site) ;
L’utilisateur est (normalement) en sécurité, l’application en ligne ne peut pas accéder aux ressources locales de l’ordinateur : ni les fichiers sur le disque dur, ni les périphériques (micro, caméra, …). Rien excepté la zone graphique contenu dans la fenêtre du navigateur, la souris et le clavier pour entrer des données ;
L’interface est assez bien balisée (là aussi, normalement 😉 ), et l’utilisateur a des repères, il sait ce que c’est qu’un formulaire, qu’un lien, une page, …
L’application est la même, quelque soit l’ordinateur, le système d’exploitation, le navigateur (ok, je simplifie 😉 ).

Inconvénients :

Avec les applications évoluées, le navigateur est « décalé » : le bouton back est inutilisable, l’application a besoin d’accéder à plus de ressources (caméra, …) et l’interface est un peu limité ;
L’application n’est accessible que quand il y a une connexion Internet (a modérer, avec les propositions de Google).

C’est donc pour donner « plus d’air » aux applications en ligne qu’Adobe a développé son AIR.

L’idée est d’avoir le beurre et l’argent du beurre.

En fait, c’est évidement pas si simple :

L’utilisateur doit installer l’application AIR (ok, très peu de clics) ;
Les mises à jour sont pratiquement transparentes : comme il y a une application locale, il faut bien mettre à jour l’application. Mais cette mise à jour est automatisée (comme la plupart des applications, aujourd’hui) ;
L’interface n’est plus du tout banalisée. Ce n’est pas une critique, puisque justement c’est le but, de sortir des limites du navigateur. Le résultat sera dépendant de ce que feront les éditeurs… On verra le meilleur et le pire !
L’application est bien la même, quelque soit la plate-forme, c’est ce qu’apporte le moteur AIR.
L’application peut fonctionner en mode off-line, cela dépend de l’application (l’application eBay en mode off-line n’est pas opérationnelle) ;
On peut bien sûr se passer l’url qui pointe vers la page d’installation de l’application, mais il est certain qu’on n’aura pas le même niveau de viralité par rapport aux URL…
La sécurité : ah, je suis impatient d’en savoir plus demain. Adobe devait y travailler, c’est évidement un sujet clé.

Dans une application AIR, le runtime AIR n’est pas visible, seule l’application apparait sur le bureau de l’ordinateur.

La gestion des applications est donc laissée au gestionnaire de fichier de l’ordinateur.

C’est là que je reviens avec mon idée, d’un navigateur sans bord de fenêtre… C’est peut être un compromis plus intéressant : garder la notion de navigateur, d’URL, mais avec certaines applications en ligne, qui prendraient la main sur la fenêtre du navigateur.

Pourquoi ?

Pour garder justement la notion d’URL et tous les avantages associés ;
Pour avoir le double mode : service Internet ou service « application » ;
Pour simplifier encore plus les processus d’installation ;

Mais voilà, Adobe ne me demande pas mon avis pour spécifier ses produits. Microsoft non plus remarquez !

La troisième voie pour le logiciel

Au début, c’était simple.

Le logiciel est édité par des éditeurs, qui vendent leur logiciel le prix qu’ils veulent.

Microsoft, Oracle, SAP…

Tous ces acteurs se sont ainsi « goinfrés » avec des prix sans rapport avec les coûts de fabrication, et des abus de tous ordres, comme une maintenance soit disant évolutive, pratiquement obligatoire et cher (en général 20% du prix d’achat), qui n’a d’évolutive que le nom, car l’éditeur ne se gênait pas pour sortir une nouvelle version du logiciel, non couverte par la maintenance (obligé de tout repayer donc si on veut la dernière version)….

Ces abus ont ouvert la voie au logiciel libre.

Des « étudiants chevelus » se sont associés pour travailler ensemble sur des logiciels, qui marchent, qui sont gratuits, et qui sont livrés avec le code source, modifiable donc par les utilisateurs.

Je pense que ce modèle est très bien dans certains cas, mais ne peut pas être généralisé. A mon sens, c’est réducteur. Pourquoi une entreprise qui investi dans du logiciel ne pourrait elle pas en vivre, en vendant son logiciel ?

Je sais que cette discussion peut générer des passions, l’open-source, c’est parfois une religion 😉

Pourquoi l’entreprise qui a développé un logiciel devrait elle obligatoirement livrer son code source, alors qu’elle a éventuellement déployé de gros efforts pour avoir un système innovant, plus performant pour l’utilisateur.

Aujourd’hui, on navigue entre les deux modèles, la licence d’un côté et le libre de l’autre.

Je pense donc que les éditeurs de logiciels payent pour leurs « parents abusifs ».

Je pense qu’il existe une troisième voie. Je cherche un nom, j’appelle ça le « logiciel éthique » (un amis me disait que ça collait pas, parce que éthique fait référence à d’autres valeurs, …).

Bref, cette troisième voie, c’est une voie ou on fait du logiciel, pas open-source, pas gratuit, mais avec des garanties pour le client.

La principale garantie, c’est de tout mettre en œuvre pour que le client ne soit pas bloqué avec une solution unique, qu’il puisse changer de fournisseur si un fournisseur fait défaut, ou abuse de sa position.

Un logiciel, c’est un programme qui « discute » avec son entourage.

L’idée serait donc de définir très précisément les interfaces des logiciels.

Cette idée est parfaitement en phase avec ma conviction que l’avenir (ok moyen/long terme) du logiciel passe par le SAAS.

Des Composants SAAS discutent avec d’autres composants via des web services. Normaliser les échanges, c’est donc normaliser les services web des composants…

Les dernières news sur Microsoft me semblent aller dans ce sens là, mais on ne change pas de culture comme ça !

Nouvelle rechute ;)

Comme vous le savez sans doute, je suis en pleine préparation de notre p’tit dej Rich commerce.

On a clairement choisi avec Fred une orientation plutôt « non technologique ».

J’ai pas pu m’empêcher, j’avais préparé tout un tas de slides sur l’architecture MVC adéquate pour décliner les interfaces riches…

En relisant notre présentation, on s’est rendu compte que c’était décallé !

Zut !

Alors je publie une image sur ce blog, et vous ne la verrez pas demain lors de la présentation !

Architecture MVC et interfacs riches

Compréhensible sans explication de texte ?

Organiser les développements : suite avec Laurent

Laurent a publié un commentaire, suite à mon billet sur l’organisation des développements.

J’ai pensé que ce commentaire « méritait » d’être « remonté » au niveau billet.

Voici donc les recommandations d’Ysance pour organiser les développements :

Lorsqu’on développe à plusieurs (ou même tout seul), les outils d’organisation de travail et groupe sont cruciaux, mais ne doivent pas nuire à la productivité ( combien de fois j’ai vu des plates-formes où il fallait plusieurs minutes pour mettre à jour un fichier, compiler, tester, tout ca parce qu’il était interdit de ‘travailler sur son PC’ !). Je vais me permettre de donner/compléter (succintement) quelques pistes :

La plate-forme de développement : principalement sur les postes de développeurs et un SVN, mais mutualisant généralement la base de données pour éviter les désagréments d’évolution des modèles. La base de données étant sous la responsabilité d’une (et d’une seule) personne. Chaque développeur produit des tests unitaires pour ses dévleoppements.

Une plate-forme d’intégration continue (de type CruiseControl ou autre) : Dès qu’une mise à jour de SVN est détectée, update de la branche, recompilation, déploiement scripté de la totalité du projet, et lancement des tests unitaires. Ainsi, pas besoin d’attendre plusieurs jours avant de détecter des problèmes d’intégration. C’est un peu long à mettre en place, mais ces techniques ont largement prouvé leur efficacité sur le moyen/long terme.

Une plate-forme de recette : Elle sert à valider fonctionnellement les développements. Celle-ci peut aussi être déployée à l’aide des scripts d’intégration continue pour faciliter. Je demande à mes équipes de mettre en ligne généralement deux ou trois fois par semaine. Cela permet aussi de suivre l’avancement général des développements et de ne pas être surpris la veille de la livraison

Une plate-forme de pré-production : A l’identique “techniquement” (mais en version réduite pour limiter les coûts) de la plate-forme de production. L’objectif ici est de mettre en situation réelle (chez l’hébergeur, avec firewalls, DNS…) l’application avant déploiement pour réaliser une recette technique.

Une plate-forme de production : Pour limite la casse, dupliquer la production sur la pré-production avant recette technique. Préparer des scripts de retour en arrière (ca c’est la théorie, mais le jour où on en a besoin, on est bien content d’en disposer). Et enfin… faire les installation en production de préférence le lundi ou le mardi, jamais le vendredi (c’est toujours bon de le rappeler) !

Ca fait beaucoup d’environnements, certes, mais si la plate-forme est bien paramétrables (URL, DNS, adresses IP de chaque service) dans des fichiers de configuration, quasimment un seul fichier (web.config, config.php, autre…) peut permettre de paramétrer l’ensemble de la plate-forme.

Tout cela ne sont que des principes d’organisation et doivent être bien entendu couplés à l’organisation de l’équipe et les méthodes de développement (développement itératif, scrum, …)

Laurent

Rechute…

Demain, je retourne à « mes premiers amours » : PROGRAMMER !

Je vais à une formation Flex, organisée par Baao et sponsorisé par Adobe.

J’ai commencé ma vie professionnelle en développant des applications… en programmant quoi.

Je dois vous avouer : même si j’adore mon métier (à la frontière du marketing et de la technique), j’éprouve un grand plaisir à reprendre la programmation.

Pour tout dire, je me sens comme un gamin, qui « fait des légos en cachette alors qu’il a pleins de devoirs ». Vous voyez ce que je veux dire ?

Légo !

Organiser les développements

Quand on développe un site marchand, il est très important de bien organiser les développements.

En particulier, il faut très rapidement aller vers plusieurs plate-formes informatiques :

La plate-forme de développement

C’est sur cette plate-forme que les développeurs… développent.

Après avoir testé le bout de service qu’ils développent en local, sur leur machine, ils peuvent migrer le nouveau programme sur la plate-forme de développement et faire des tests, avec les programmes des autres.

La plate-forme de production

C’est la plate-forme en ligne, celle qui est visible par les clients, les Internautes.

La plate-forme de pré-production

C’est un sas, entre le développement et la production.

Cette plate-forme est tout à fait fondamentale, car elle permet de garantir que les nouveaux développements n’impliquent pas de régression.

Quand l’équipe estime que la version courante de développement est stable, on fait une migration, vers la pré-production, pour tout tester, dans tous les sens. Si les tests passent, on peut alors migrer, de la plate-forme de « pré-prod » vers la prod.

Simple, non ?

Mon avis sur l’affaire de la Société Générale : de la fragilité des systèmes d’information

Un traider serait donc la cause de 5 Milliards de perte pour la SG…

Pour arriver à ce niveau de perte, il aurait spéculer sur 50 Milliards d’euros !

Au début, je ne pensais pas que c’était possible, je penchais donc pour une maneuvre pour charger un bouc émissaire de tous les mauvais placements… Puis mes différentes lectures (ici par exemple) m’ont fait douté : oui, il semblerait que cela soit possible !

Pourtant, la SG dépense des sommes colossales pour son système d’information, dont pas mal de millions d’euros pour la sécurité et le contrôle.

Que peut on en conclure ?

A mon sens, ce qui est marquant, c’est la non maîtrise de ces systèmes d’information.

La pyramide

Pour arriver à un tel résultat, il faut que le système ne soit pas compris par les personnes qui l’analysent.

Et le prix que l’on paye une armée de consultants n’est pas un outil de mesure de qualité…

D’où mon image : la pyramide est inversée, le système est gros et lourd, mais quelques grains de sable peuvent tout faire tomber.

Update de 20h35

En relisant mon billet, je me suis dit que j’étais pas assez explicite.

Petit complément donc.

Un système d’information, c’est du code qui s’exécute. Ce n’est pas une abstraction.

Pour analyser un système, il faut analyser le code. C’est donc pas un travaille ou on manipule des abstractions…

J’ai travaillé dans les banques dans ma jeunesse. Les documents d’analyses ne correspondent pas à ce que font les programmes… Quand il y a des documents d’analyse ! Je me souviens d’une très grosse banque, qui avait un programme très important, au coeur du système. Le programme avait été écrit avec PAC, un générateur de programmes Cobol. Quand je suis arrivé, le programme PAC était perdu, il n’y avait aucun document d’analyse… Donc, la seule façon de comprendre les règles métiers, c’était d’analyser le code généré par PAC… C’est une illustration de la pyramide inversée. Dans un tel contexte, tout peut arriver !

Flash ou Flex ?

Quand on parle d’interfaces riches, il faut parler des technologies permettant de les mettre en oeuvre.

L’une des technologies phare, c’est le Flash.

On connait tous plus ou moins Flash, mais on parle de plus en plus de Flex.

Quelle est la différence ?

Qu’apporte Flex par rapport à Flash ?

Flash recouvre plusieurs choses :

Un format de fichier, le SWF, qui contient le média animé proprement dit (les images, les annimations, les films, …) ;
Un éditeur : c’est une application Mac ou PC, qui permet de créer des fichier Flash (SWF donc). L’éditeur est orienté design. On pose des images, des objets graphiques, sur une time -line, et on déplace les objets graphiques sur l’échelle de temps ;
Un player : c’est l’application qui permet de lire le Flash. On peut lire un fichier SWF avec une application spécifique, mais le plus souvent, on utilise un plug-ins, intégré au navigateur. C’est donc le navigateur qui joue le rôle de player Flash.
Un langage de programmation : ActionScript. On écrit ses programmes depuis l’éditeur, et le langage est interprété par le player.

Flash est donc un ensemble permettant de réaliser des interfaces riches et animées. Flash est orienté design.
Et Flex alors ?

Flex, c’est la déclinaison Flash pour les programmeurs.

Quand on fait du Flex, on travaille en fait sur le même format qu’avec Flash : le SWF.

Pour le client, le résultat est donc exactement le même : c’est un contenu Flash qui apparait dans le navigateur Internet.

La différence, c’est sur la façon dé générer ce fichier SWF.

Flex introduit un nouveau langage, le MXML.

C’est un langage qui permet de décrire l’application Flash que l’on souhaite, et les comportements associés.

On se retrouve donc à faire du Flash, sans l’éditeur graphique, mais plutôt depuis un environnement de développement (Eclipse, …).

Donc, si le résultat est le même, la façon de le faire est complètement différente, et complémentaire.

Dans la réalité d’un projet, les deux approches doivent cohabiter : la partie graphique pourra être réalisée avec l’éditeur Flash, et la partie dynamique pourra être réalisée avec Flex.

Interface riche avec Sylverlight

Microsoft préfère utiliser ses produits pour présenter ses évènements… et c’est bien normal.

Pour présenter les Techdays 2008, Microsoft a développé ce site :

Dans ce site, Microsoft met en avant la force de Sylverlight, à savoir la manipulation de video dans des contenus rich-media. Chaque « pola » est une video, et un clic sur l’une des image lance le petit film. On peut bien entendu déplacer, redimensionner, tourner chaque imagette en toute liberté. sympa.

Cerise sur le gateau, ça marche très très bien sur Mac (installation en deux ou trois clics, puis comportement très fluide).

C’est Brainsonic qui a développé ce petit site.

(Merci Manu pour le lien)

Sun rachète MySQL

Je viens de tomber sur cette news (ici).

Cette aquisition est complètement logique : MySQL est l’une des base de données les plus utilisées, quand on choisi de développer un service sur une architecture sur des logiciels libres. C’est donc un moyen pour Sun d’avoir plus de poids dans le business des services webs.
Le prix d’acquisition serait de 800 millions $ : logiciel libre et gratuit, mais pas sans valeur !

Pour info, le « libre et gratuit » est également au coeur de la stratégie d’IBM, et depuis longtemps. IBM gagne beaucoup d’argent sur le Hard, sur les développements « à façon » (le service quoi), et « donne » le logiciel. C’est une stratégie très forte qui permet à IBM de proposer une solution global (Hard, soft + intégration).

IBM injecte ainsi, par exemple, plusieurs millions $ par ans sur Eclipse, un environnement de développement libre et gratuit.