Archives par mot-clé : Système d’information

Programmation performante des serveurs web

La performance des serveurs web est un vrai sujet : on a besoin de sites qui répondent vite, pour vendre plus 😉

Et un serveur web peut être amené à répondre à « pleins » de requêtes simultannées.

On peut palier de manière superficielle à ces problèmes avec du cache. Bonne idée… mais les sites doivent de plus en plus être personnalisés, dynamiques. On peut donc « cacher » certaines ressources, mais pour les parties dynamiques, il faut faire autrement.

Au coeur des serveurs web se pose donc la question de la programmation parallèle : faire tourner plusieurs programmes en parallèles pour répondre en même temps à plusieurs utilisateurs.

Quand on programme avec les technologies « normales », on ne se rend pas compte de tout ça : c’est le serveur web qui gère, de manière transparente pour le programmeur. en fait, à chaque appel au serveur web, un fork est créé. Un fork, c’est une unité d’exécution indépendante. Chaque programme, pour chaque appel, est donc « dans son coin ».

C’est une bonne idée, parce que on masque ce problème technique… Sauf que la gestion des forks n’est pas très optimisée, et qu’à créer trop de forks, on fait rapidement tomber les serveurs.

D’ou l’idée de faire autrement. C’est en particulier ce que propose certains environnements, tel node.js, basés sur des serveurs webs spécifiques (autre que apache donc).

Dans ces environnements alternatifs, les différents programmes ne sont pas exécutés dans des forks indépendants.

Pour gérer la continuité entre les différentes fonction, le programmeur doit mettre en place des procédures de call back, …

Bref, je ne veux pas trop rentré dans les détails (d’ailleurs, je ne suis plus programmeur, j’atteints vite mes limites 😉 ).

Mon sentiment sur cette histoire :

Je comprends le chemin emprunté par ces solutions, c’est pragmatique : puisque les serveurs web rament avec les technos de forks, on descend d’un niveau, et on gère la programmation parallèle directement.

Mais sur le fond, je suis convaincu que la solution n’est pas là. Cela me semble complètement indispensable de masquer ces problématiques au programmeur, qui a déjà bien de quoi s’occuper. Et si la programmation parallèle n’est pas efficace, et bien il faut revoir l’architecture du système !

Formation « Les bases techniques du Web pour les non-techniciens » le 17 Septembre

Comme vous le savez sans doute, je donne des formations, en particulier avec le CCM Benchmark Group.

J’ai monté une nouvelle formation avec eux, sur les bases techniques du web, pour les non techniciens.

La formation s’adresse à toutes les personnes qui se retrouvent dans la situation de piloter des projets web, e-commerce ou autre.

On doit échanger avec les équipes techniques, et le dialogue n’est pas toujours simple 😉

La formation a lieu le 17 septembre donc,

il reste quelques places !

Pour en savoir plus, c’est par ici.

Architecture du système d’information e-commerce

Je vous propose plusieurs billets, sur l’architecture du système e-commerce.

D’abord, de quoi parle-t-on ?

Quand on lance le e-commerce, à la mode « garage », le système d’information est réduit à sa plus simple expression : on prend une solution SAAS type Oxatis, Rentashop, Wizishop, … et c’est tout.

La solution est composé, nativement, d’un front office : la boutique e-commerce.

Pour piloter l’activité, la solution propose un accès back office.
Ce back office permet de consulter ou modifier l’ensemble des données du site :

Catalogue : On peut modifier l’arborescence du catalogue, et mettre à jour les produits.
Client : On a accès à la base des clients, qui se sont inscrits sur le site.
Commande : On peut consulter les commandes passées par les clients, et les traiter.

Alors, heureux 😉 ?

Pourquoi parler d’un système d’information, quand on a tout sous la main dans une seule solution ?

En fait, même à ce stade, on peut déjà parler de système d’information e-commerce, avec différentes briques : vous avez nécessairement une compta, vous travaillez peut être avec un logisticien qui utilise un WMS et TMS, vous expédiez vos coli via un transporteur qui propose un logiciel, … Bref, vous avez de fait plusieurs briques. Simplement, elles ne sont pas inter connectés.

Encore une fois, pour se lancer, c’est une très bonne approche, pas de problème avec ça.

Les questions se posent soit quand on veut aller plus loin, soit quand le volume de commande dépasse un certain volume, soit si on est au sein d’une entreprise et qu’on doit synchroniser le système e-commerce avec le système d’information de l’entreprise.

Exemple : on veut réduire la charge lié à la comptabilité.

Avec notre premier système, composé d’une seule solution, on doit reporter à la main les commandes dans la comptabilité.
Quand on a 20 commandes par mois, la charge est raisonnable. A 200, c’est déjà une autre histoire.

On va donc développer une connexion entre le moteur e-commerce, et un module comptable.
On pourra ainsi charger automatiquement les commandes passées, du e-commerce vers la comptabilité.

Bien sûr, la charge comptable ne sera pas pour autant réduite à 0 : il restera toujours quelques opérations à entrer à la main, en particulier sur les cas « hors norme » : retour d’un produit, colis perdu, …

Là dessus, mon conseil est de partir sur des automatisations partielles.

Vouloir tout automatiser n’est en général pas une bonne idée : ça coûte cher, et ce n’est pas utile.
Ce qu’il faut, c’est automatiser les éléments les plus courants. Les cas limites doivent pouvoir être traités à la main.

Dans l’exemple du e-commerce et de la compta, on traitera donc à la main, dans la compta, les cas limites.

La suite au prochain épisode 😉

T’as quoi dans le cloud ?

C’est le cloud du spectacle.

Bon, ok, j’arrête 😉

Le cloud, le nuage, c’est l’idée de déporter des services sur Internet.

Plus besoin de mettre ses applications en locale, plus besoin d’avoir des serveurs chez un hébergeur :

vos applications sont accessibles, depuis votre ordinateur, en général via le navigateur, mais pas toujours.

Bon, l’exemple que tout le monde connait, c’est GMail, ou tout autre service de messagerie en ligne. Personne ne s’occupe ni de l’application, ni des serveurs ni des données. La boite qui met à disposition le service Cloud s’ocupe de tout.

Un autre exemple intéressant de service Cloud, c’est DropBox.

Je ne sais pas si vous connaissez, c’est un service assez bien fait, de partage de dossiers en mode cloud justement.

Le service est accessible depuis internet, mais également via une application, qui permet d’étendre les fonctions natives du système d’exploitation.

Une fois qu’un dossier est partagé, l’ensemble des fichiers du dossier partagé sont mis à jour, sur tous les ordinateurs de tous les utilisateurs ayant une vue sur ce dossier.

Super commode pour travailler à plusieurs, et bien plus évolué qu’un simple FTP.

Mais on peut voir les choses différemment : finalement, Dropbox propose un service d’assez bas niveau : le partage de dossiers.

D’autres services proposent de partager une application. Exemple : Wimi.

Wimi est un service dans le nuage donc, qui propose tout un tas d’outils pour travailler sur des projets partagés.

On peut gérer les dossiers des projets, les documents, les calendriers, les listes des tâches, le reporting du temps passé…

J’ai un peu joué avec, ça a l’air plutôt bien fait.

Bon, pour revenir à mon article, vous voyez maintenant ce que je veux dire : pour un même problème, on peut voir le cloud de différentes façons. Pour gérer un projet par exemple, on peut juste se servir de Dropbox, et partager différents documents ; Ou alors on peut se servir d’une application en ligne, comme Wimi.

Système d’information – Démêler le « plat de nouille »

Dès qu’une boite a une certaine taille, qu’elle a plusieurs canaux de distributions, un « historique » informatique, nécessairement, le système d’information vieilli, devient de plus en plus compliqué et de plus en plus cher à maintenir et à faire évoluer.

Ce système est pratiquement toujours composé de briques différentes, ERP, Compta, Caisse, Logistique, … et e-commerce 😉

Les connections entre les systèmes se sont faites au fil du temps.

Assez rapidement, on se retrouve avec plusieurs problèmes :

Les briques, individuellement, ont vieilli
L’interconnection du système est devenu anarchique, n’importe quel brique effectuant des échanges avec n’importe quel autre composant.

Comment faire évoluer un tel système ?

Comment sortir de cette logique infernale ?

On peut se dire : on va remplacer tel brique, par une autre plus moderne. Au fil du temps, on pourra remplacer toutes les briques et avoir un système « comme neuf ».

Cela ne va pas vraiment régler le problème, et le cout de cette greffe va être très élevé.

Et on sait bien que tout remettre à plat, c’est d’une part tellement cher qu’on ne le fera jamais, et d’autre part, même si on avait le budget, ça ne serait un pas une bonne idée, car le projet serait trop gros, avec tous les risques associés à ce type de « big bang ».

Alors, que faire docteur ?

Mon avis est que la seule solution raisonnable est de passer par une approche SOA.

Il faut, déjà, mettre fin aux échanges anarchiques entre les différentes briques.

Il faut donc définir des couches d’échanges, des API, qui déinissent des objets et méthodes métiers.

Les briques ne doivent dialoguer qu’au travers ces nouveaux composants.

Ces couchent doivent être bien faites : il s’agit de modéliser, le plus proprement possible, les objets métiers.

Exemple classique : les informations sur un client.

Dans bien des boites, la logique « full CRM » n’est pas en place (c’est un « graal », en ce sens que ce n’est jamais complètement possible de toute façon), et les infos sur le client sont en fait réparties dans différentes briques : e-commerce, ERP, solution d’emailing, application de call center…

Dans notre approche, on défini une couche abstraite permettant de modéliser le client, et toutes les informations associées à ce client.

En tant qu’utilisateur de cette couche, j’aurais une vision propre, un référentiel unique, cohérent

En fait, c’est cette couche qui doit « se débrouiller » avec l’existant, et aller piocher les infos là ou elles sont

Jusqu’au jour ou l’entreprise décidera de fair évoluer la couche CRM, qui pourra alors se brancher simplement « sous » cette couche.

L’avantage de l’approche, c’est qu’une fois une telle couche en place, les briques utilisatrices sont réellement indépendantes des couches sous jacentes, et les problèmes de modélisations « du dessous » ne remontent plus.

Toute la difficulté de l’approche est qu’il faut définir des objet avec le bon niveau d’abstraction, « comme si » les autres éléments étaient nickel.

Les difficultés de cette approche, c’est qu’elle n’est pas immédiatement rentable : on a un cout supplémentaire, pour définir, développer et utiliser cette couche, ce qui est bien plus long que d’aller chercher l’information directement à sa source.

C’est en fait toujours le cas avec les approches ou l’on recherche la qualité.

Prenons un simple développement web, pour une application quelconque. C’est bien plus rapide de faire un petit développement, sans aucune approche qualité, un petit programme qui pourra allègrement mélanger la couche présentation, les logiques métiers et la couche de données. bien plus rapide à développer (je dirais un facteur 3, pour fixer les idées). Le surcout vien ensuite : le petit programme est rapidement impossible à maintenir.

A mon sens, deux cas de figures : soit les responsables sont « convaincus », et on va pouvoir y aller, vendre cette approche.

Soit ce n’est pas le cas, les responsables n’ont pas de culture SOA. Dans ce cas, je pense qu’on peut quand même avancer, mais par étapes, et sans mettre en avant ce travail. Simplement, à chaque demande d’évolution, on prend un peu de temps pour définir et mettre en oeuvre une couche d’échange.

Bien sûr, le plus simple, c’est quand cette approche est sponsorisée par les chefs 😉

Un excellent article sur le sujet, par un gars qui a bossé chez Amazon, Google ;).

Guide de l’open source Smile

Smile est une société de service, spécialisée depuis sa création sur les technologies open source.

Dans notre domaine du e-commerce, c’est une société qui a réalisé quelques beaux sites, comme le Furet du Nord.

Depuis toujours, Smile est connu pour ses livres blancs, gratuit et très riches.

Et bien smile vient de sortir un pavé, un guide de l’open source.

Cela a du représenter un très gros travail, bravo et merci aux équipes.

Les sujets traités sont très variés.

Exemples « infra » :

VoIP
Accelérateur HTTP
Workflow, BPM (gestion des processus)
Bases de données
Test, intégration continue
Framework de développement

Exemples « applicatifs »

e-commerce
ERP
CRM
ETL

Bref, 260 pages !

Les langages de programmation : aujourd’hui et demain ?

J’ai trouvé cette image sur un blog :

Je ne sais pas comment est calculé le graphique ci dessus.

Un autre copain m’a envoyé un lien vers un autre article, qui parle de l’avenir des langages de programmation.

Mon point de vue est le suivant :

Les langages de programmation n’évoluent pas beaucoup ces derniers temps. Il y a des framework qui sortent, mais pas grand chose d’innovant au niveau langages.

La programmation est, et restera encore quelques décennies, un métier. Je ne crois pas du tout que le développement de nouveaux paradigmes de programmation peuvent rendre la programmation tellement simple qu’elle devient accessible à tous. Pourquoi ? Parce que ce qu’on doit faire, quand on programme, c’est prévoir une grande combinaisons de cas, et que, intrinsèquement, c’est complexe.

Je n’ai jamais été fan de la programmation graphique. C’est une idée sympathique, mais je ne crois pas que ça soit une vrai solution industrielle. Ca peut par contre être un bon moyen pour appendre.

Par contre, je crois en l’intérêt d’un « package » complet et cohérent : un framework.

L’enjeu n’est donc pas d’écrire un langage, mais de proposer une solution complète. Ce qu’à plutôt bien fait Microsoft avec .Net.

Ce qui manque, à mon avis aujourd’hui :

Un langage résolument orienté Web. Je pense que le web est suffisamment spécifique pour nécessiter un langage, et tout ce qui va avec, spécifique. Considérer que n’importe quel langage peut faire n’importe quoi n’est pas, à mon sens, la bonne approche.
Une programmation par couche : c’est une idée qui me trotte dans la tête depuis bien longtemps. L’idée est de découper la programmation en plusieurs couches, en se disant qu’un même programme doit résoudre des aspects différents d’un problème. En fait, quand on programme, on commence par aller très vite pour régler le ‘cas normal’. Ensuite, on passe beaucoup de temps à traiter tout le reste : les cas limites, les cas d’erreurs, … Et tout cela est mélangé ce qui fait, qu’au bout du compte, on ne sait plus ce que fait le programme dans le cas normal. Mon idée, que je n’ai jamais vue mise en oeuvre, est de proposer une programmation « par calques », comme sur Phtotoshop. Chaque calque traite un aspect du problème.
Considérer les formats du web (html, css, js) non comme du texte, mais comme un arbre (DOM) dans lequel on peut naviguer. Le langage de programmation pourrait manipuler cet arbre, pour ajouter des bouts, en supprimer d’autres… Le texte ne serait que le résultat final. Avantage : on peut complètement optimiser le flux de sorti, pour avoir des temps de chargement beaucoup plus court. Quand j’étais étudiant en informatique, des chercheurs travaillaient sur un langage dont la structure de base est un arbre (dérivé de l’idée du lisp, ou la structure fondamentale est une liste. Je ne sais pas ce que ça a donné.
Considérer que certains aspects doivent être traités par le framework et pas par le programmeur : les sessions et le garbage collector par exemple.
Un système intégrant nativement la persistance des données, et pas via un SGBD relationnel, mais plutôt avec une modélisation fondamentalement objet.

Tout cela devrait permettre :

Beaucoup moins de ressource côté serveur. Je suis toujours impressionné par les besoins en ressources serveurs avec les solutions actuelles.
Une programmation plus facile, plus propre, et donc plus facile à maintenir, plus évolutive.

Si j’avais du temps, je bosserais bien là dessus 😉

500 fois plus rapide…

Je lisais dans un doc qu’entre un programme écrit en PHP et un programme écrit en C, il y avait une différence d’un facteur 500 : le programme écrit en C est 500 fois plus rapide que le même programme écrit en PHP.

C’est, comment dire, énorme, monstrueux, incroyable… Bon, vous avez compris l’idée ;).

C’est avec ce type d’infrastructure qu’on se retrouve à devoir aligner des serveurs, comme les petits pains chez le boulanger… Sauf que le prix d’un petit pain n’est pas exactement celui d’un serveur…

Je suis pragmatique, et le PHP est bien souvent un bon choix pour l’entreprise… Mais cela me conforte dans l’idée qu’il y a un vrai chaînon manquant, un système de développement d’application Web réellement efficace, un environnement « green » et économique, parce que très performant.

Bon, de gros acteurs travaillent sur ce type de sujets : Google, Facebook…

Barycentre des applications e-commerce

Drôle de titre, non ?

Je passe pas mal de temps à rencontrer des éditeurs de solutions e-commerce.

C’est, je dois bien le dire, tout à fait passionnant.

C’est un peu comme une enquête : il faut chercher à comprendre de que fait le produit, et en quoi il est différent des autres solutions.

Chaque solution a ses spécificités, et, objectivement, ce n’est pas simple du tout de comprendre où sont réellement les différences, au delà des discours marketing et de l’image des marques.

Le barycentre d’une application, c’est une manière imagée de mettre en avant le « coeur de valeur » d’une application.

Une bonne façon de comprendre ce point est de se renseigner sur l’histoire du produit et de l’éditeur associé.

Si certains produits ont une origine purement web (Magento, Prestashop), d’autres ont des origines différentes : ERP pour certains, PIM pour d’autres.

Ainsi, Hybris est à historiquement un moteur de PIM, construit pour permettre la vente multi canal des produits.

D’autres, comme Octave, Dotsoft ou Netwave viennent de l’ERP.

Une solution orientée Web sera axée sur toutes les options liées à l’affichage et l’annimation du site.

Une solution orientée PIM sera axée sur le produit, et toute la richesse de sa « composition » et des présentations suivant les canaux.

Une solution orienté ERP sera axée aussi sur le produit, mais plus en amont : lien avec les fournisseurs, …

C’est un axe d’analyse qui me semble tout à fait fondamental pour le choix d’une brique e-commerce :

De quoi avez vous besoin, et quelles solutions allez vous choisir pour combler ce besoin ?

Au fait : espérer une solution qui fait tout très bien, c’est croire au père Noël ;).

Part de marché des langages de programmation

Quels sont les langages de programmation les plus utilisés dans le monde ?

On m’a donné cette info :

Intéressant !

Ce qu’on peut voir :

La concurrence est rude !

Le java est en pleine décroissance, et ce n’est probablement pas prêt de s’arrêter avec le rachat par Oracle…

Le C est en pleine croissance ( !!! ).

(Merci Patrice)

UPDATE : Suite aux commentaires, j’ai intégré le tableau suivant (issu de la page sur tiobe)

Position Jul 2010	Position Jul 2009	Programming Language	Ratings Jul 2010	Delta Jul 2009	Status
1	1	Java	18.673%	-1.78%	A
2	2	C	18.480%	+1.16%	A
3	3	C++	10.469%	+0.05%	A
4	4	PHP	8.566%	-0.70%	A
5	6	C#	5.730%	+1.19%	A
6	5	(Visual) Basic	5.516%	-2.27%	A
7	7	Python	4.217%	-0.22%	A
8	8	Perl	3.099%	-1.10%	A
9	21	Objective-C	2.498%	+1.99%	A
10	9	JavaScript	2.432%	-1.08%	A
11	11	Delphi	2.323%	+0.33%	A
12	10	Ruby	1.982%	-0.59%	A
13	12	PL/SQL	0.772%	-0.12%	A
14	13	SAS	0.701%	-0.09%	A
15	15	Pascal	0.639%	-0.07%	A–
16	17	Lisp/Scheme/Clojure	0.622%	+0.01%	B
17	20	MATLAB	0.581%	+0.07%	B
18	16	ABAP	0.548%	-0.15%	B
19	19	Lua	0.535%	+0.00%	B
20	28	PowerShell	0.493%	+0.17%	B