Archives par mot-clé : programmation

Actualité Google : Google Trusted Store et Dart

Google est prolifique en ce moment ;).

Google vient de sortir Google Trusted Store.

C’est un label, spécialisé pour le e-commerce.

Pour le client, c’est une marque de confiance.

Pour obtenir le label, le commerçant doit offrir un bon niveau de service (délai avant expédition, …) et s’y tenir.

C’est un concurrent de Fia-Net ou Trusted Shop, qui proposent déjà ce type de service.

Comme prévu, Google a également lancé son nouveau langage : Dart.

Comme je le disais hier, je suis de près ce qui se passe à ce niveau, parce que j’ai la conviction qu’il y a beaucoup à faire.

Mais, à ce stade, je n’ai pas été convaincu par Dart. C’est un langage qui ressemble à du Java (rien de mal jusque là 😉 ), et qui, pour être utilisé côté client, peut être « traduit » en Javascript. Je n’ai pas vu, dans les éléments fondamentaux du langage, quoi que ce soit de révolutionnaire. Je ne vois pas bien ce que peut apporter ce langage, à part pour Google qui pourrait être tenté par une stratégie qui nous rappelle Microsoft des années 2000 : avoir des éléments spécifiques dans le navigateur, pour avoir des clients captifs.

A vor également sur le sujet :

Evolution du modèle de programmation du web – Retour vers le futur

Au début, avant Internet, il y avait des ordinateurs qui fonctionnaient en mode client serveur.

Le serveur gérait principalement les données, et l’applicatif tournait sur le client.

Après, il y a eu Internet.

Comme les premieres versions du HTML étaient très pauvres, l’application c’est naturellement déportée vers le serveur. C’est ce qu’on appelle le serveur d’appication.
Dans ce modèle, le serveur fournit à peu près tout : il livre au client une page complète, que le client n’a qu’à afficher. L’intelligence côté client est très légère.
Cela ressemble à ce qu’on fait sur les gros système (CICS par exemple : vous savez, ces écrans textes avec les caractères en vert qu’on voit si on regarde les écrans des vendeurs dans pas mal de boites…).

Mais le web s’est enrichi, avec le Javascript, et la possibilité de développer des applications bien plus intelligentes, bien plus sophistiquées, et surtout bien plus agréables à utiliser.
Cela veut dire que, dans ce modèle, l’intelligence est répartie entre le serveur et le client. Plus la couche Javascript est évoluée, et plus l’intelligence est déportée vers le client.

Avec les évolutions actuelles du web, on peut légitimement penser que c’est bien le sens de l’évolution pour les prochaines années : revenir en fait à un modèle ou l’intelligence applicative est principalement sur le poste client.
Côté serveur, on gère principalement la couche des données.
Sur un modèle en trois couches MVC (modèles / vue / contrôleur), les deux autres couches, vue et contrôleur sont donc déployée sur les postes clients.

Prenons un exemple : un site e-commerce au hasard 😉

Ce que doit gérer le serveur, c’est bien l’ensemble des données du système :

Le catalogue, avec l’ensemble des produits, et toutes les informations associées à ce catalogue : description, prix, stock, …
La base des clients
La base des commandes

Certaines de ces données peuvent, pour des raisons de performance, être gardées sur le poste client. Exemple : la hiérarchie des produits. Mais les données qui « bougent » doivent absolument être stockées côté serveur. Exemple : le stock produit.
Tout le reste pourrait très bien être géré côté client.

Avantages de ce modèle :

L’application peut être bien plus évoluée que ce qu’on fait en web classique. On peut avoir une bonne idée de ce modèle, avec, par exemple, la navigation dans un catalogue en Ajax : quand on applique un filtre, la page n’est pas raffraichie, seuls les produits changent. C’est un peu la préhistoire du modèle que je présente.

Autre avantage : la consommation, en bande passante, est bien plus optimisée. Une fois l’applicatif chargé sur le poste client, on n’échange que les données nécessaires. Pas besoin de renvoyer l’ensemble de la template du site à chaque page.

Les technologies sont assez développées pour permettre de mettre en oeuvre ce modèle dès aujourd’hui.

En fait, ça ne serait pas une bonne idée ;).

Pourquoi ?

Parce que ce modèle n’est pas très « SEO friendly ». Comment google peut il indexer un truc pareil ?

La réponse est connue, c’est la même que pour le Flash : il faut faire deux versions du site. Une « dynamique » et une sans javascript. C’est accepté par Google, car la version sans Javasript est bien accessible à ceux qui le souhaitent, et c’est en particulier le cas pour les mal et non voyants.

L’autre problème, c’est que, même si les technologies permettent « théoriquement » de mettre en oeuvre ce modèle, les outils, les frameworks ne proposent pas encore les bons outils pour faire ça sans avoir à tout réinventer.

Donc, c’est un peu tôt pour se lancer à fond là dedans, mais cela donne, je pense, une bonne idée de « là ou l’on va ».

(article issu d’une discussion passionnante avec Pieroxy)

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 😉

Conception Modèle – Vue – Contrôleur

Je vous propose plusieurs billets, sur la conception logicielle de qualité.

Une bonne pratique, quand on veut faire du logiciel de qualité, c’est de séparer les fonctions en « couches ».

Ainsi, on a l’habitude, pour un système de publication web (e-commerce ou autre CMS) de séparer les choses en trois couches :

Couche Présentation
Couche « applicative »
Couche d’accès aux données

C’est ce qu’on appelle le modèle MVC : Modèle Vue Contrôleur.

La première couche est simple à définir : c’est tout ce qui touche à la génération de la page HTML. Normalement, le code HTML doit être exclusivement regroupé dans cette couche.

Le dernière couche est également simple à comprendre : elle doit couvrir l’ensemble des accès au système de stockage des données : la base de données quoi. Elle regroupe donc, si le système est basé sur une base de données relationnelles, l’ensemble des accès SQL (il ne doit donc pas y en avoir sur les autres couches).

A partir de ces deux définitions, on peut déduire que la couche du milieux contient… le reste.

L’avantage de cette approche :

On ne mélange pas tout. Programmer l’accès à une base de données, ou programmer une interface HTML, ce n’est pas du tout la même chose.

Normalement, cela doit permettre de faire évoluer le site plus vite, d’améliorer sa qualité (moins de bugs).

Je dis normalement, parce qu’il faut bien savoir que… un mauvais programmeur fera du mauvais travail, quelque soit les règles qu’on peut mettre en place.

Autre paradoxe : programmer comme cela, en couche, cela augmente mécaniquement la taille du code.

Le programme le plus court sera celui ou vous mélangez tout…

Et pourtant, là aussi mécaniquement, moins il y a de code, et moins il y a risque de bug.

On est donc à la recherche d’un juste milieu.

Bon, ceci dit, personne de vraiment sérieux ne remet en cause le modèle de ces trois couches.

D’ailleurs, la plupart des plate formes e-commerce respectent cette structure : Magento, Prestashop, …

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…

Programmation graphique ?

Cela fait des années qu’on oppose programmation graphique à programmation textuelle.

A mon sens, c’est le même sujet, quand il s’agit de programmation ou d’analyse.

On peut faire de l’analyse avec des textes clairs, ou avec de joli schémas.

Donc, est-ce une bonne idée de faire de jolis dessins ?

Les dessins permettent-ils de complètement définir un sujet, plus facilement qu’avec du texte ?

Certains le pensent, comme ces solutions UML, qui promettent « la fin de la programmation » : Vous faites les différents schémas, et hop, un générateur de code va tout générer, et c’est fini.

Je dois dire que je ne suis pas en phase avec cette approche… Je n’y crois pas, et je pense que, quand on rentre dans les détails, les schémas finissent par être trop complexes.

Cela n’empêche pas que, pour moi, certains schémas sont très bien pour clarifier les échanges.

J’utilise principalement deux diagrammes UML : le diagramme de classe et les scénarios.

Le diagramme de classe est une bonne façon pour montrer la structure des données. C’est un modèle bien plus intuitif qu’un schéma relationnel.

Sa limite est qu’il intègre des données très différentes : l’héritage est une notion associée aux classes (ce sont les classes qui héritent les une des autres) alors que les liens sont en fait des liens entre les objets. Mais c’est pas grâve, on s’en sort très bien ;). Pour ma part, quand je peux, je sépare les schémas d’héritage des liens entre les objets.

L’autre schéma, les scénarios d’usages, permet de montrer un « exemple d’échanges » entre plusieurs objets.

C’est un schéma sympa, qui permet de comprendre la dynamique entre plusieurs objets.

Sa limite est de ne montrer qu’une option, parmi un ensemble de possible beaucoup plus vaste.

En particulier, il ne faut surtout pas utiliser de tels schémas pour les cas d’erreurs.

Sinon, je trouve qu’on fait de belles analyses avec… word.

Après pas mal d’années d’expérience, je trouve que le plus efficace, pour décrire un sujet, c’est de décrire, avec du texte donc, les différents cas.

Pour simplifier ces textes, je rajoute, en entête du « cas », un ensemble d’hypothèses.

C’est une manière, un peu artificielle, de simplifier le traitement d’un cas donné.

Exemple pour le e-commerce : processsus achat.

Et bien avec ma méthode, au lieu d’avoir un seul flux d’analyse, je découpe, en prenant les différentes hypothèses :

Compte existant et déjà identifié
Compte existant et non identifié
Nouveau client

L’énorme avantage est que cela permet de simplifier énormément la lecture de chaque cas.

Autre point : j’ai pris l’habitude, quand c’est possible, de séparer l’analyse « normale » de l’analyse des cas d’erreurs.

Là aussi, c’est un peu artificiel, mais ça permet de « séparer les variables » : on commence par s’intéresser au cas « normal », puis on s’intéresse aux cas « limites ».

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

Les idées innovantes de Aspectize

Ce qui est intéressant, à mon avis, dans cette solution, c’est la « remise à plat » des concepts, pour bien programmer.

L’équipe s’est libérée des dogmes et paradigmes actuels, pour proposer ce qui leur semble le mieux.

Ainsi, la solution n’est pas « purement » objet, puisque la partie programmation est décorellée de la partie données.

Finalement, le modèle proposé est assez critique par rapport à l’approche objet…

Par contre, la solution part d’un modèle « MVC » : Modèle / Vue / Contrôleur, c’est à dire un modèle ou on sépare les activités de développement en trois couches distinctes :

Modèle : représentation des données ;
Vue : programmation de l’interface ;
Contrôleur : tout le reste 😉 .

Si je devais refaire le monde…

Bon, on est vendredi, c’est bientôt le WE, on peut se lâcher un peu, non ?

(billet un brin technique, je m’en excuse auprès de mes lecteurs non programmeurs)

Maintenant, le sujet n’est pas si loin que ça des sujets habituels de ce blog, puisque mon idée, c’est de parler langage de programmation.

Donc, quand on veut programmer sur Internet, on a le choix, pour faire simple, entre deux options :

Soit vous utilisez PHP, ou un autre langage de script.
Soit vous utilisez Java, ou autre .NET

Il y a bien sûr tout un tas d’autres solutions, le propos de ce billet n’est surement pas de faire un dictionnaire des langages de programmations.

A mon avis, tout ça est loin d’être abouti.

Les langages de type script permettent de développer rapidement un service, mais l’idée même de ne pas être compilé et faiblement typé, fait que le risque de découvrir des erreurs « en ligne » est important.

De l’autre côté, les langages de type « java » débouchent bien souvent sur des systèmes lourds, complexes à mettre au point et à maintenir.

Tout cela n’est pas très satisfaisant.

Alors, si on devait refaire « ce monde là », on ferait quoi ?

Voici ma « shopping list » pour un langage idéal pour le web « de demain » :

De bons fondamentaux

A mon sens, un bon langage devra être :

Objet
Fortement typé
Compilé

Donc, à ce stade, c’est plus Java que PHP ;).

Gestion native des sessions

L’une des caractéristique du Web, c’est la double contrainte, entre la nécessité de gérer de véritables applications en ligne, et un protocole « state less » : le serveur répond à une requête, et ne fait pas nativement le lien entre deux appels d’un même client (affichages de deux pages successives d’un même service, deux étapes du processus achat par exemple).

Ce point, hyper basique, n’est pas traité nativement par les langages. On se « débrouille » avec des couches applicatives, qui permettent de mettre en oeuvre des notions de sessions.

Mais le résultat ne simplifie pas les choses. A chaque appel, pour chaque page, le programmeur doit aller chercher les éléments de contexte, pour servir les bonnes informations au client. C’est compliqué, et c’est bien dommage de devoir repartir de si bas…

A mon sens, ce problème devrait être complètement « encapsulé » dans le langage.

Gestion native de la persistance des données

Bon, puisqu’on refait le monde, on peut bien bousculer le paradigme de la base de données.

La séparation entre le langage de programmation et la base de données est, à mon sens, complètement artificiel.

Et cette séparation pose des problèmes, de modèle (les langages sont objets, et la base de données est relationnelle), et de performance : la communication entre le langage de programmation et la base passe par des interfaces textes :

On transmet des ordres SQL en format texte à la base, et on récupère des chaînes de caractères en sortie. Tout cela est très peu performant.

Donc, la vrai bonne solution serait d’intégrer les deux.

Orienté Web, pour de vrai de vrai

C’est bien ce qu’à fait le PHP, qui, à la base, permet juste d’insérer quelques éléments dynamique dans du HTML.

Mais là encore, je ne suis pas convaincu par cette approche, qui consiste à considérer que le Web, c’est du texte HTML.

Pour moi, le Web, c’est plutôt un arbre (DOM). De loin, ça peut sembler être la même chose, mais en fait, en prenant un peu plus de hauteur, cela permet de manipuler des choses beaucoup plus intelligentes. Puisqu’on est au niveau des concepts, on peut avoir une manipulation intelligente de ces concepts, alors que le texte, il n’y a aucune chance de faire quelque chose d’intelligent !

Le langage manipulerait donc des arbres, et bien sûr, au moment de sortir la page, on génèrerait bien le texte HTML.

Traitement des erreurs multi vues

Si vous avez déjà programmé, vous savez qu’un programme, c’est 10% pour traiter les cas normaux, et 90% pour traiter les erreurs.

Et en plus, les erreurs, il y en a de tous types.

Mon idée, que je n’ai réellement vue nul part, c’est de permettre de programmer « en couche » (qui a dit culotte ?).

Intuitivement, l’idée, c’est de programmer comme on faisait un dessin annimé : on dessine le fond, puis, sur chaque calque, on rajoute des informations. On rajouterait donc un calque par type de traitement d’erreurs.

Quelle avenir pour une telle idée ?

Probablement aucun…

Mais je trouve ça sympa, de remuer les concepts, ça permet de « sortir du cadre » et de se poser tout un tas de questions passionnantes !

Compilez vos Javascript pour augmenter le taux de transformation !

Google vient de mettre à disposition des outils, pour mieux coder les applications Web.

Essayez le compilateur javascript.

Bon, c’est pas un vrai compilateur. Pour info, un compilateur permet de passer d’un langage à un autre.

Ici, c’est plutôt un programme qui nettoie le code, l’optimise, pour que le transfert sur le réseau soit plus rapide, et que l’interprétation soit boosté également : il faut savoir que quand le javascript arrive dans le navigateur, le temps pour passer du format texte au format exécutable est bien souvent ce qui prend le plus de temps. Réduire le nombre de caractères, c’est réduire ce temps.

J’ai fait quelques essais, ça a l’air assez efficace !

Cela permet d’avoir des pages plus légères, qui seront donc plus rapide à s’afficher… Facteur clé pour optimiser le taux de transformation !

(vu sur Silicon.fr)