Erlang… nom étrange pour bête sympa // 3 février 2010 // 7 commentaires »

Catégorie : Geekeries webmasteriennes // Tags : • •

Attention, ce post est ultra-geek.

J’ai quelque peu fait allusion précédemment à ce langage un peu exotique. Il faut dire que mon côté geek aime bien tout ce qui est langages de programmations. J’ai très tôt apprécié Ruby et Rails, et l’approche agréable du «tout objet» de Ruby.

Mais l’aventure YesOrNow version 1, entièrement en Rails + JS, il m’est apparu des choses toutes bêtes, et j’ai cherché comment y remédier.

Ces «choses toute bêtes» sont à mon sens des facteurs clef de succès dans le web. Car c’est un chose d’avoir une bonne proposition de valeur, un bon marketing mix, une bonne interface. Il faut que derrière, cela tienne, et que cela soit performant.

L’approche Rails / 37 Signals / désinvolte, c’est en deux mots : si vous avez des problèmes de scaling, cool, c’est que ça cartonne ! En effet, mais autant ne pas avoir de problème de scaling, car préserver l’expérience en cas de forte exposition est justement primordiale : c’est tout d’un coup l’occasion de faire connaître ce que l’on fait à de nombreuses personnes… autant que la première impression soit bonne.

Aussi, pour 37 Signals, leur business model uniquement par abonnement, sans partage entre comptes clients, limite ces problème de scalabilité car le coût a moins à jouer.

L’argument, c’est aussi qu’une architecture scalable, c’est complexe. Cela veut dire systèmes de cache (mais cela, même quand on a pas à scaler, c’est nécessaire car améliore immensément les performances et soulage le server…. d’autant que NGinx l’intègre dans son coeur), systèmes genre memcached de distribution, cache et partage d’objets, réplication de bases MySql et structures Master-Slaves ou autre… Enfin, tout le tintouin.

PHP n’est pas bien différent. La seule différence avec PHP, c’est que ce language est tellement souple qu’il est un peu trop facile de mal coder… Et comme tous les développeurs web font du PHP, il est plus difficile de séparer le bon grain du mauvais grain.

Et donc… Erlang.

Erlang, c’est d’abord un monsieur, un mathématicien. Mais ça on s’en moque.

Erlang, c’est maintenant un language. Un truc un peu fou inventé chez Ericsson pour leurs besoins propres, afin d’avoir des PABX et autres machineries des telecoms qui soit stables, performantes, etc… Enfin, un truc pour gérer des telecoms au niveau d’un pays quoi.

Donc, quelques mecs se sont réunis, dont un certain Joe Armstrong, qui est un peu le DHH d’Erlang, version père de famille, je fais pas de surf des neiges, mais je suis brillant et marrant, et ont réfléchi.

Ils ont pondu Erlang, qui est un langage fonctionnel.

Pour ceux qui se demandent, un langage fonctionnel c’est ça (Wikipedia) :

La programmation fonctionnelle est un paradigme de programmation qui considère le calcul en tant qu’évaluation de fonctions mathématiques et rejette le changement d’état et la mutation des données. Elle souligne l’application des fonctions, contrairement au modèle de programmation impérative qui met en avant les changements d’état.

En gros, ici, pas d’objet, des fonctions. Que des fonctions, dans des modules. On ne partage aucune donnée, on se passe des messages entre fonctions. Moi, personnellement, ça me plaisait bien, parce que je codais intuitivement un peu comme cela : la programmation objet me faisait mal à la tête, car je savais jamais où en était mes objets à chaque moment. Là je sais.

Après, Erlang a d’autres caractéristiques, qui elles sont intéressantes pour nous, personnes du Web.

1. C’est un langage concurrent. C’est à dire que les process fonctionnent en même temps en utilisant toutes les ressources des processeurs multicoeurs. Cela est possible car la mémoire n’est pas partagée : les fonctions s’envoient des messages. Mais là où ça devient génial, c’est qu’Erlang fonctionne par noeuds : c’est à dire que ma fonction trucmuche, sur mon Mac, peut envoyer un message à la fonction bidule sur le PC de mon pote australien, qui à son tour envoie un message à machin etc… Scalabilité vous avez dit ?

2. C’est un langage rapide, qui se compile à la volée. En gros, plus de deux fois plus rapide que PHP5 et 4 fois plus rapide que Ruby.

3. C’est un langage qui supporte nativement le versionning. C’est à dire qu’on peut faire une rollout de nouvelles fonctionnalités ou corriger des bugs sans downtime, le language intègrera de lui même les nouvelles versions intelligemment.

4. C’est un langage qui incorpore sa base de donnée, Mnesia, elle même distribuée sur plusieurs noeuds, on peut fragmenter les tables, etc… et les performances sont excellentes.

5. Plusieurs serveurs web existent pour Erlang : Yaws, Mochiweb principalement. Les deux ont des performances superbes, surtout derrière un Nginx. Yaws est célèbre pour tenir à plus de 80 000 connexions simultanées quand Apache meurt à 4000….

6. Quelques frameworks web commencent à poindre leur nez, dont Nitrogen. Et aussi, niveau CMS, Zotonic apparaît. Au programme,… je vous laisse découvrir.

7. Dernier point : la possibilité de bundler son applicatif, erlang compris. Vous l’uploader sur le serveur, vous configurer votre NGinx pour qu’il pointe sur le bon port de votre mochiweb, vous faites un petit ./start.sh, et hop, c’est live, database incluse. C’est pas beau ça ?

Sinon, niveau syntaxe, au début, ça surprend…. Surtout quand on sait qu’une variable ne peut changer de valeur… mais son scope est limité à sa fonction. En fait, il faut vraiment plonger dedans pour comprendre (je commence à peine) comment ça marche, mais ça va assez vite.

En fait, ce qui me plaît dans ce langage, c’est qu’il semble résoudre la plupart des contraintes techniques du Web : performance, stabilité, scalabilité.

Petit détail en passant : 37 Signals, Facebook et Meetic utilisent Erlang pour leurs systèmes de chat.

Et bien sûr, le gros inconvénient d’Erlang c’est de trouver des développeurs en Erlang !

Donc voilà, c’était le post ultra-geek pour commencer février. Promis, je ne parlerai pas d’Haskell ni d’OCaml !

Quel CMS choisir pour quel site & pour quel client ? La réponse en 5 minutes. // 11 janvier 2010 // 16 commentaires »

Catégorie : Geekeries webmasteriennes // Tags : • • • • • • • • •

C’est une question dont on discute souvent entre webmasters, webdesigners, webmarketers, etc… : l’architecture technique. Il faut que nos choix:

  • répondent au maximum aux besoins du client en terme de fonctionnalité (pour éviter au maximum le développement sur mesure),
  • qu’ils soient simples d’usage pour le client (même si facturer de la formation peut-être tentant, c’est un mauvais calcul, car ce sera un mauvais souvenir et pour le client qui se sent bête et ne sait pas s’il pourra se débrouiller tout seul et au final le site ne vivra pas, et pour vous, parce que la formation, c’est pas votre coeur de mêtier),
  • qu’ils soit sur des plateformes génériques (PHP/MySql // même si je vais vous parler de quelques perles à la fin de l’article je pense)
  • et que vous vous sentiez à l’aise à les manipuler.

En types de sites, je vais aborder les sites généralistes, les blogs, les sites e-commerce et les sites plus « sur-mesure ».

Je ne vais pas faire un tour de tout ce qui existe (il y en a trop). Je vais parler des principaux et de ceux moins connus qui ont retenus mon attention. En gros, je vais aborder :

Ceux que je voudrais tester, mais pas eu l’occasion :

D’emblée, j’écarte les solutions pré-hebergées, courantes. Je pense qu’en tant que professionnel du web, notre devoir est de proposer du dur, c’est à dire du serveur + solution clef en main, et qu’on ait le loisir de toucher le code de la bête.

Je vais faire le tour par type de site / client.

Première Catégorie : Le site « je présente mon business » et le client « n’a pas trop le temps de s’y consacrer ».

Là, ma réponse est directe, rapide : Concrete5.

Pour plusieurs raisons : d’abord, le moteur de templating est un véritable régal, plus encore que WordPress, c’est dire. Faites votre HTML / CSS / JS, testez le en cross-browser, faites vos variantes, puis remplacez vos zones de contenu par des marqueurs que vous inventez, autant que vous voulez par page. L’édition, pour le client, se fait en wysiwyg, sur la page même. Un vrai régal et pour vous, et pour le client, et les performances sont correctes. Cela convient parfaitement pour le client qui se dit au bout de quinze ans, tiens, il me faudrait un site quand même.

Deuxième Catégorie : Le site d’entreprise avec de l’actualité fréquente voire un blog.

Réponse : WordPress.

WordPress est d’une souplesse impressionnante, et plus je l’utilise, plus je me rends compte que l’on peut presque gérer des catalogues de produits (sans vente bien sûr). De plus, c’est une véritable merveille en terme de référencement si on fait bien son template (je me souviendrai toujours avec émotion du jour où DatingWatch, le blog que je tenais à l’époque, s’était classé en troisième position sur le mot clef Meetic, juste après Meetic.fr et Meetic.fr).

Son moteur de template est super souple. Je lui reproche juste parfois, dans l’intégration des plugins, d’interférer avec les javascripts que l’on installe soi même. Donc, bien débugguer, surtout sous IE 6…

Troisième Catégorie : Le petit site e-commerce sympa et le web commerçant qui n’en veut.

Réponse : PrestaShop.

Simple d’utilisation pour le client, le templating est standard (Smarty). Un avantage, c’est qu’il est français, donc s’adapte à merveille à nos chers petits clients. Exemple, le module de paiement Atos est intégré. PrestaShop est souple et léger, et certaines des boutiques que j’adore tournent dessus, c’est ce qui m’a fait l’adopter.

Quatrième Catégorie : Le bon gros site e-commerce.

Réponse : Magento.

Une usine à gaz simple, mais la solution la plus puissante au niveau marketing. La référence, mais nécessite un hébergement à la hauteur (un dédié !). Il s’interface aussi désormais avec WordPress & Drupal. Je n’ai pas eu la chance pour l’instant de mener un projet en entier dessus, me suis contenté de le tester et le templater. Mais dieu, pour le marketing, que c’est beau (on peut créer des promotions complexes comme on aime)

Cinquième élement : Le big site.

Réponse : Drupal.

Et bien là, soit un développé totalement dédié, soit Drupal. Surtout qu’il s’interface avec Magento s’il faut de l’ecommerce en plus. Une usine à gaz modulaire… on peut juste tout faire avec Drupal, ou presque… Dans tous les cas, il faut pas mal de développement et de connaissances. Mais à vous la dimension communautaire sur votre site et les fonctionnalités avancées !

Le recalé n°1 : Joomla & Joomla/Virtuemart

Certes une référence, mais l’administration n’est pas du tout appréciée des clients, et personnellement, j’ai toujours trouvé ce package ni assez généraliste ni assez spécialisé, bien que très puissant. Mais c’est une affaire de goût, j’en conviens. De plus, le code source est un peu une usine à gaz à l’heure actuelle. Egalement, je n’ai jamais compris la gestion de l’arborescence chez Joomla (enfin, si, je l’ai comprise, mais dieu que ce n’est pas ergonomique — tiens, ça fait deux fois que je dis dieu dans cet article, bizarre ce lundi matin).

Le recalé n°2 : OsCommerce

Je travaille à la refonte d’un site OsCommerce depuis ce matin… et je m’arrache les cheveux, car il n’y a aucun moteur de templating… le code et la présentation sont totalement imbriqués, et TOUT est en table… une HORREUR à fuir absolument…

Ceux qui m’ont tapé dans l’oeil (mais pas forcément gratuits) :

Expression Engine : à priori pour du bon gros site, un peu moins riche que Drupal, mais avec une interface d’admin ma-gni-fique et apparemment des super performances et super puissant. J’ai hâte.

EzPublish : a l’air d’être la référence en terme de fonctionnalités. Il faut que j’aille jeter un oeil.

Les Atypiques

Là dedans, je vais vous parler de choses qui ne sont pas en PHP MySql, mais qui semblent prometteur.

En fait, je ne vais vous parler que d’un seul.

C’est du early-stage (0.2), mais juste un petit tour de ce qui m’a fait flasher :

  • 10x plus rapide qu’un CMS php.
  • Comet included
  • Le modèle de donnée est totalement flexible (catégories de données & relations)
  • Template en ETL
  • Orienté évènement

Ca s’appelle Zotonic, c’est en Erlang + Postgres. Et en plus l’admin est magnifique… Je parlerai bientôt de pourquoi Erlang me fascine.

Petit Tableau Récapitulatif.

Conclusion Importante

Ce qu’il faut noter, c’est que si on est là pour faire des sites, conseiller en tant que performances, optimiser, nous avons surtout un rôle de diagnostic humain. Trop de fois, j’ai vu des clients me demander un site e-commerce, pour au final qu’ils n’aient pas le temps de s’en occuper, à part deux trois fois par an pour changer les produits. Plus le site est complexe, important, plus le client doit s’y impliquer. N’hésitez jamais à prévenir qu’un site ne vit pas seul, il faut un travail quotidien pour le faire vivre et pour que ça marche.