Le blog de la société Scub

Bien que je constate que de plus en plus de partenaires investissent dans les infrastructures (salles blanches, serveurs, ingénieurs, monitoring, licences, clims...), je suis de plus en plus perplexe ! Je continue de croire que la valeur ajoutée n'est pas dans les infrastructures. Les clients ne sont pas prêt à payer plus cher pour avoir une salle blanche plus proche, plus grande, avec plus d'extincteurs, des serveurs avec plus de ram... les clients veulent des applications qui fonctionnent un point c'est tout et ils sont prêt à mettre la main au portefeuille pour s'offrir des fonctionnalités qui vont les aider à être plus éfficace. Une société voudra bien mettre quelques euros de plus pour que sa CRM puisse envoyer des emailings avec images et avec avoir une statistique sur le taux de lecture des emails MAIS je ne vois pas cette société mettre de l'argent sur la table pour que sa salle blanche soit plus "prêt" de chez lui ou pour qu'elle ait plus d'extincteurs. Les gens veulent mettre de l'argent dans ce qu'il leur rapporte !

Pour moi, il faut se concentrer sur les applications et leurs fonctionnalités et tout ce qui permet de s'affranchir des infrastructures est un plus ! Les infrastructures doivent être des commodités comme l'est Internet. Aujourd'hui, qui payerait plus pour avoir un fournisseur local ? tout les FAI offrent Internet, ce qui compte, ce sont les options qu'on rajoute et ce qui fait que les clients vont vers un FAI ou un autre (si on occulte l'historique et les peurs des migrations). Si Free est une si belle boite, c'est bien grâce à ça !

Dans de domaine de la transformation en commodité des infrastructures, Google a fait un pas important avec Google App Engine (ok c'est sorti il y a un petit moment mais j'ai pas eu le temps de blogger le mois dernier). L'idée est simple, vous développez avec le kit de dev fourni et vous déployez en production directement sur l'infrastructure de Google. En utilisant leurs technologies, votre application peut ainsi passer de un utilisateur à un million sans les coûts énormes que cela engendrerait en temps normal. Concrètement, vous externalisez complètement l'infrastructure chez Google ! Rien à gérer, vous payez juste à l'utilisation, c'est pas formidable ça ?

Bon, mauvais point maitenant, le développement, pour le moment, doit être réalisé en Python et on est encore un peu limité Mais bon, gardons espoir, un jour viendra où nous n'aurons qu'à nous concentrer sur une seule chose : développer des fonctionnalités

L'année dernière, afin de répondre aux besoins de nos clients en "Business Intelligence", nous avons suivi une formation sur le décisionnel Open Source (auprès de la société http://www.bpm-conseil.com/). A la base, j'étais surtout intéressé par OLAP et la mise à disposition des cube via JPivot. Mais je dois bien dire que le produit qui m'a le plus impressionné a été Kettle, l'ETL libre de la suite Pentaho et c'est l'outil qui m'a fait le plus gagné de temps depuis un an (bien devant maven...). Alors, pour ceux qui ne savent pas ce qu'est un ETL, le principe est de graphiquement manipuler les données, les prendre dans des endroits très variés et de les mettre dans d'autres endroits tout aussi variés. Par exemple, si je devais faire une jointure entre deux bases de données différentes, enlever les doublons, rajouter un champs calculé, traduire des champs grâce à une table de correspondance dans un fichier excel, insérer le tout dans une base, puis dans un fichier et mettre celui-ci sur un ftp... je compte trois jours de dev en Java, avec un ETL, trois heures Malgré cela, je croise encore des dizaines de gens qui réalisent des applications dès qu'ils doivent manipuler des données.. Résultat temps perdu et maintenances complexe. Bref, pour ceux qui ne connaissent pas, jeter vous sur Kettle (ou talend qui est aussi open source mais français ;)). La très très bonne nouvelle, c'est que ce genre d'outil se prend en main en moins d'une heure.

Nos amis de Techcrunch ont fait un petit article intéressant qui rappelle les principes de base d'une société "durable" tels qu'ils ont été listés par les fameux investisseurs Sequoia Capital. Ce point de vue est très intéressant et je me suis amusé à faire un petit parallèle avec Scub.

Clarté de l'objectif

Le métier d'une entreprise doit pouvoir s'écrire sur le dos d'une carte de visite. Pour Scub : "Conception, réalisation et mise en oeuvre du système d'information des entreprises". Bien sûr, dans la réalité, on fait beaucoup de choses : SOA, Open Source, SaaS, architecture... Mais je trouve que cette phrase résume bien les choses.

Gros marchés

Lorsque l'on vise un marché très important, le nombre de clients potentiels existants permet de faire quelques erreurs et laisse un peu de temps pour faire des corrections. Nous visons les grandes entreprises et les grandes administrations du département, cela nous laisse pas mal de clients potentiels. __ Des clients riches__

Ces clients là seront prêts à payer plus cher pour un très bon produit. C'est pour cela que nous visons les grands comptes en priorité La course aux prix n'est pas notre objectif et depuis mon retour du Vietnam, j'ai bien compris que c'était une course perdue d'avance.

Focus

Les clients achèteront des produits simple offrant une valeur singulière. Dans notre cas, Architecture orientée service en Java.

Résoudre un problème

Choisissez un problème que vos clients ont et résolvez ce problème de manière simple et élégante. Pour nous, le problème : des systèmes d'information lourd et qui ne répondent pas aux défis de l'entreprise. Notre solution : une architecture orientée service en Java avec un maximum de composants libres.

Penser différemment

Il faut constamment essayer de trouver de nouvelles voies. C'est bien pour cela que nous nous lançons dans les applications SaaS.

L'équipe

Chaque membre de l'équipe doit être le meilleur dans le domaine qu'il exerce. Nous sommes aujourd'hui 9 et nous essayons toujours de permettre aux gens de faire ce qu'ils aiment et ce pour quoi ils sont bons. Nous avons 5 ans cette année et je suis fier d'annoncer que nous n'avons jamais eu de départs dans l'équipe !

Agilité

L'agilité et la rapidité permettent de battre les grosses sociétés. Tous les trois mois, nous réévaluons notre Business Plan et nous voyons quelles nouvelles technologies nous pouvons intégrer à notre socle technique. Nous évoluons constamment et nous changeons très souvent d'outils. Grâce à cela, je n'ai pas peur de me retrouver face à des SQLi et des Cap Gemini.

Frugalité

Concentrez vos dépenses sur l'essentiel. A Scub, de grandes tables, de bonnes chaises, de très bons PC portables sous Linux et d'excellentes conditions de travail (salaires importants, mutuelle, plan d'épargne entreprise, intéressement aux bénéfices...). A part ça, pas vraiment de dépenses !

Inferno

Commencer avec peu d'argent, cela force la discipline et la concentration. Exactement ce que je fais depuis le début Mais d'un autre côté, j'ai pas trop eu le choix !

Avec l'arrivée en force du Software as a Service, on voit tranquillement arriver le Hardware as a Service avec notamment les fameux service Amazon :

• Amazon Simple Storage Service (Amazon S3)
• Amazon Simple Queue Service (Amazon SQS)
• Amazon Elastic Compute Cloud (Amazon EC2)
• Amazon SimpleDB

Le principe est simple, Amazon met à votre disposition une architecture extensible que vous utilisez selon vos besoins. Concrètement, pour EC2, vous pouvez démarrer/arrêter autant de serveurs que vous voulez. Imaginez, vous déployez votre application sur un serveur pour commencer et vous avez un succès fou, pas besoin de commander d'autres serveurs et d'attendre qu'ils soient prêt, vous utilisez tous simplement les webservices d'EC2 pour démarrer les 20 autres serveurs dont vous avez besoin.

Vous avez le choix entre trois types d'instance de serveurs :

• 1.7 GB memory, 1 EC2 Compute Unit, 160 GB de stockage et archiecture 32-bits.
• 7.5 GB memory, 4 EC2 Compute Units, 850 GB de stockage et archiecture 64-bits.
• 15 GB memory, 8 EC2 Compute Units, 1690 GB GB de stockage et archiecture 64-bits.

Les tests réalisés par RightScale ont l'air plutôt concluant.

Amazon fournit des Amazon Machine Images (AMIs) qui fonctionne sur le même principe que les virtual appliances de VMWare (que nous utilisons ici à Scub). Ceci évite de se faire ses propres images from scratch et permet ainsi de gagner un peu de temps, il y en a même une AMI pré configurée avec Tomcat.

En ce moment, nous sommes en train de bâtir une application SaaS dont le nombre d'utilisateurs final n'est bien sûr pas connu. Nous avions pensé à migrer de Spring vers EJB3 pour éviter les limitations des singletons Spring et donc supporter plus d'utilisateurs. Mais du coup, nous nous posons la question de garder notre architecture telle quelle et juste ajouter des serveurs au cluster quand nous arriverons à la limite d'un serveur. Il y a justement un article très intéressant sur la mise en place d'un cluster J2EE avec AWS. A noter qu'il y a aussi un ensemble de plugin maven pour gérer la plateforme AWS.

Joli cadeau que nous fait là Google en nous offrant (enfin) un avant gout de la version 1.5 de son très bon framework Google Web Toolkit.

Parmi les nouveautés / améliorations qui nous tardent le plus, citons :

• le support de Java 5 qui va nous apporter :
  • les génériques : fini les @gwt.typeArgs dans la javadoc (des alertes encourageront d'ailleurs à utiliser les génériques)
  • les annotations (même si @SuppressWarning qui aurait été utile avant, ne servira pas tellement maintenant avec le support des listes typées)
  • l'autoboxing qui permet la conversion automatique entre un type primitif et l'objet qui s'y rapporte (ex : int <-> Integer) [même si ça peut inciter à un manque de rigueur et entrainer quelques erreurs (pour des cas précis) dans des tests d'égalité]
• l'ajout d'une méthode setDebugId() qui permet de donner un id à un element sans passer par le DOM. Voila une alternative bien pratique pour que l'on puisse se tourner à nouveau vers Selenium pour tester nos interfaces graphiques, l'utilisation excessive du DOM pour affecter un id à chaque élément testable ne nous convenant pas tellement. De plus, cette fonction sera ensuite ignoré dans le code final pour ne pas le surcharger inutilement, à la façon de GWT.log().

Cette nouvelle version s'est vraiment fait attendre mais je pense qu'elle va vraiment valoir le coup ! Je vais essayer de trouver le temps de tester cette preview mais on attendra la release finale avant d'envisager migrer notre socle vers la version 1.5.

En attendant, on va pouvoir commencer à imaginer les futurs évolutions que Google nous apportera dans la prochaine version (génération automatique des services asynchrones à partir des interfaces, ...).

Voici un bon article d'introduction à OSGi ! J'ai un peu honte mais j'avais pas encore eu le temps de me renseigner là dessus alors que j'en entends parler très souvent. Voilà, c'est fait, je sais ce qu'est OSGi est c'est franchement pas mal même si ce n'est pas non plus une grosse révolution. A Scub nous utilisons déjà pas mal l'injection de dépendance pour éviter les couplages trop fort. Nous n'en sommes pas encore à utiliser OSGi, pour le moment, nous nous concentrons sur la nouvelle version de notre socle technique qui commence vraiment à être très efficace ! Pour info tout de même, le fameux serveur d'applications JOnAS a une architecture basée sur OSGi.

Voici une liste de mes applications préférées (elles sont toutes en ligne bien sur ;))

• Gmail : Ma boite email professionnelle et personnelle.
• Google Calendar : Mon agenda. Partagé avec mes employés, synchronisé avec mon palm grâce à GooSync.
• Google Docs : Tous les documents de la société sont là dessus.
• Google Reader : Pour lire les actualités et les blogs.
• Google Notes : Toute les notes que je prends et que j'ai la flemme de pas entrer comme document classique dans Google Docs.
• Dotclear : Notre blog
• Rememberthemilk : Outil fantastique pour traquer toutes les tâches que j'ai à réaliser (vraiment génial comme outil).
• SugarCRM : Ma gestion de clientèle. Elle sert essentiellement de carnet d'adresses et d'outil de tracking d'opportunités.
• Google sites : Notre intranet !
• Mantis : Outil de gestion des bugs. Utilisé pour tracer les incidents clients et leur gestion.

Finalement, à part les outils Java et firefox, j'ai tout en ligne ! Si vous avez des suggestions, n'hésitez pas à laisser vos commentaires, je suis preneur

Et voilà une des applications Ajax les plus impressionnantes que j'ai jamais vu : http://www.editgrid.com/untitled ! Qu'on ne vienne pas me dire que les applications web sont loin d'être aussi ergonomique que les applications bureaux classiques. Quand je vois des tableurs comme ça, je me dis que Microsoft est face à un terrible dilemme :

• Ne pas faire de tableur web mais risquer de voir les gens se tourner vers des produits comme editgrid.
• Faire un tableur web et perdre la vache à lait extraordinaire qu'est Office.

Bref, dans les deux cas, ils perdent et les utilisateurs gagnent Enfin une bonne nouvelle !

Lorsque l'on est développeur et que l'on est face à un problème de développement, on utilise les designs patterns (Facade, Observer, DTO...) pour y répondre élégamment. Par contre, lorsque le programmeur réalise le design de l'interface graphique, alors là, on fait comme on le sent et le problème, c'est que ce que l'on réalise est parfois assez éloigné de ce qui est bien pour l'utilisateur. Nos amis de chez Yahoo ont donc eu la généreuse idée de crée une Design Pattern Library. Le principe est très simple, vous choisissez le problème, par exemple "L'auto completion" et vous accédez à une page détaillant le problème et la solution à apporter. La librairie n'est pas encore très riche mais à mon avis, ça vaut le coup d'y jeter un coup d'oeil quand on fait un peu de design d'interface !

Au fur et à mesure qu'une société se développe, elle a de plus en plus besoin de structurer l'information dont elle dispose, que ce soit l'annuaire des employés, les agendas de production ou les formulaires administratifs. Avec 9 personnes et des documents/procédures en pagaille, je ressentai depuis quelques temps le besoin de structurer un peu les choses et c'est là que Google a annoncé la sortie de Google sites qui permet de batir facilement des sites web collaboratifs (et donc des intranets). Alors je me suis lancé et je n'ai pas été déçu ! Un peu à la façon wiki, on peut créer de nouvelles pages, y rajouter du texte, des listes structurées, des documents google docs, des présentations, des calendriers partagés... J'ai donc crée l'intranet de la société en 30 minutes (ça a été assez facile car nous avions déjà tous nos documents dans Google Docs) et le résultat est pas mal du tout! J'y ai mis les éléments suivants.

• Le planning de la production : Calendrier indiquant le travail que chacun doit réaliser ainsi que les dates de livraison prévues.
• La liste des projets et leurs états : Liste de tous les projets des clients.
• La base de connaissances : Trucs, astuces et informations communes sur les sujets les plus courants (Linux, PostgreSQL...).
• Plan d'amélioration de la société : La liste des améliorations à apporter à la société dans le courant de l'année.
• L'annuaire de l'entreprise : Nom / Prénom / Fonction / Adresse email / Ligne / Portable et profil des employés de Scub.
• Divers formulaires administratifs : Notes de frais, Demandes de congés...

Globalement, je trouve que google sites est vraiment un bon produit Google : Simple, Sans fioritures, puissant. Cela en fait un très beau concurrent de Microsoft Sharepoint à un coût qui n'a absolument rien à voir ! D'autant plus qu'il est possible de créer des formulaires que l'on met à disposition dans Google sites et qui vont remplir des fichiers tableur Google Docs.

Voici deux (voir trois) évolutions majeures que nous allons certainement intégrer dans nos applications Ajax. La première : gwt-ext. Si vous ne connaissez pas, courrez voir la démonstration ! Ce produit me rassure énormément sur la capacité du web à devenir la plateforme de développement/déploiement/utilisation des applications métiers. Les démos de Flex que j'ai vu m'avait vraiment fait douter à l'époque mais après avoir vu ext-gwt, je me dis que HTML/Javascript, bien qu'ayant des limitations, peuvent offrir tout ce dont les développeurs ont besoin pour développer les applications qu'on leur demande. Deuxième chose que j'avais déjà survolé mais que j'ai pu voir en détail : Comet. C'est LA solution qui nous manquait, surtout pour développer des applications collaboratives. Le principe de comet est simple : il permet au serveur web d'envoyer des données vers le browser. On peut donc facilement développer des applications qui vont réagir en cas d'évènement serveur. Cas classique : vous travaillez sur une fiche prospect de la CRM et un utilisateur ouvre la même que vous. Comet est capable d'envoyer un message vers votre navigateur et on pourra donc afficher un message du style « machin est en train de travailler sur cette fiche prospect ». Dernier élément assez vieux maintenant mais sur lequel on a pas encore faire de tests, c'est Google Gears qui permet de faire des applications offline (il s'agit d'un plugin qui embraque une base de données locales). Bien que cette fonctionnalité soit intéressante, j'essaye généralement de convaincre les gens de ne pas la développer pour deux raisons, la première, ça coûté très cher ! et la deuxième, avec la multiplication des cartes 3G, nous serons bientôt tous toujours connectés.

Suite à la sortie de Postgresql 8.3, je suis tombé sur un article très très intéressant : Pourquoi préférer PostgreSQL à MySQL ?. Cet article est vraiment très bien et on y apprend même quelques astuces intéressantes pour les fans de Postgresql ! (comme moi ;)).

A chaque fois que je veux installer Web Tools Platform sur Eclipse, c'est la même galère : impossible de me souvenir comment j'avais fait la fois précédente et de résoudre les problèmes de dépendances. Ce billet servira donc de pense-bête et j'espère qu'il servira également à certains d'entre vous.

Lire la suite

Il y a quelques semaines, j'ai eu à rajouter une fonctionnalité à une des applications que nous avions développée pour un client. Il s'agissait d'enregistrer dans une table de la base de données des informations concernant quelques actions de l'appli. Les consignes étaient de faire quelquechose qui serait simple et rapide à mettre en place. Juan m'a donc aiguillé sur l'utilisation de l'API de journalisation log4j, que nous employons régulièrement dans nos projets. Je ne m'étais cependant pas vraiment penché dessus en dehors des logs "console" que nous utilisons lors des phases de développement, de tests ou de production. J'ai donc pu m'intéresser à cette très bonne API, largement reconnue et employée dans le monde Java.

Lire la suite

La version 8.3 de PostgreSQL vient de sortir ! A scub, nous utilisons PostgrSQL chez la plupart de nos clients et, franchement, c'est un produit fantastique. Des performances remarquables, et une robustesse impressionnante !