3 frameworks de développement : Ruby on Rails, Snap et Lamson

Posté par (page perso) . Modéré par tuiu pol.
Tags :
13
25
mai
2010
Internet
Ce week-end, la version 2.3.6 de Ruby on Rails est sorti, suivi de peu par la version 2.3.7. Ces versions apportent un bon nombre de correctifs pour divers problèmes, mais surtout préparent le terrain pour Rails 3. Certaines API vont être supprimées dans Rails 3, et la version 2.3.6 permet d'être averti si votre application Rails utilise une de ces API.

La version 3 va également apporter un grand plus au niveau de la sécurité en échappant par défaut toutes les chaînes de caractères pouvant être sujettes à une attaque XSS. La version 2.3.6 devait permettre de tester ce comportement en installant le greffon Rails XSS. Mais, certains commits n'ont pas été backportés depuis Rails3, rendant ainsi cette protection non seulement inefficace mais aussi source de plantages. Heureusement, la version 2.3.7 est sortie juste après pour réparer ça. Au final, si vous êtes un utilisateur de Rails, vous êtes encouragés à sauter la version 2.3.6 et à passer directement à la version 2.3.7.

Mise à jour : Rails 2.3.8 vient de sortir pour corriger un problème lorsque l'on n'utilise pas le greffon Rails XSS. C'est donc vers cette version qu'il faut migrer.

Et si vous préférez la programmation fonctionnelle, sachez que le développement web vous est aussi ouvert. Par exemple, Snap est un framework web en Haskell sous licence MIT. Snap se décompose en trois parties :
  • Une bibliothèque serveur HTTP très rapide, qui s'appuie sur la boucle événementielle de la libev ;
  • Une monade particulièrement bien adaptée au développement web ;
  • Un moteur de templating XML qui permet de générer entre autres du HTML.
Snap est encore très jeune, mais ses performances sont déjà impressionnantes : plus rapide qu'apache !

Enfin, Lamson est un framework de développement en Python sous la double licence BSD et GPL. Sa particularité est d'être un framework pour les mails. Il propose une approche similaire à celle de Django ou Ruby on Rails, mais pour développer des applications qui gèrent des mails. Vous avez ainsi la possibilité de router des mails entrants, d'utiliser le modèle MVC, d'utiliser des données en provenance de différentes bases de données (relationnelles ou non), d'utiliser un ORM si vous le souhaitez, ou encore d'écrire des tests unitaires. Bref, Lamson permet enfin d'écrire facilement des applications qui gèrent des mails, que ce soient des filtres anti-spams, des mailing-listes, ou des applications très spécifiques.
  • # Parallèle Snap / Ocsigen

    Posté par . Évalué à 3.

    C'est amusant:
    Haskell et Ocaml ont un certain nombre de points communs au niveau langages.

    On a bien un environnement Ocaml avec un serveur web, un framework web, etc. (Ocsigen)
    Et je découvre qu'on a à peu près la même chose sous Haskell.

    Est-ce un choix historique de l'une des deux équipes (le syndrôme "moi aussi je peux!"), une pure coïncidence, ou une sorte d'évolution logique du framework seul offert grâce aux langages?
    • [^] # Re: Parallèle Snap / Ocsigen

      Posté par . Évalué à 4.

      le syndrôme "moi aussi je peux!"
      Quand je vois ce qu'on trouve sur la toile, à mon avis il doit y avoir un rapport avec ça...
      http://www.webtoolkit.eu/wt
      http://code.google.com/p/frothkit/
      http://g-framework.org/

      et il y en a qui ont pas froid aux yeux... http://weblocks.viridian-project.de/

      Allez, demain j'écris mon framework web en whitespace ! Des amateurs ?
      • [^] # Re: Parallèle Snap / Ocsigen

        Posté par . Évalué à 2.

        Et dans les trucs un peu plus « sérieux », il y a quand même Lift qui fait pas mal parlé de lui dans la communauté Scala et qui parait-il (perso j'y crois, mais loin de moi l'idée de l'imposer) réinvente la programmation web :
        http://liftweb.net/
        • [^] # Re: Parallèle Snap / Ocsigen

          Posté par . Évalué à 6.

          Oui, ben je te renvoie sur les descriptions d'Ocsigen: "une nouvelle approche de la programmation web".

          Dans la description de Lift, un peu plus bas que la courte description de la révolution, il y a écrit qu'il reprend le meilleur des autres frameworks...

          En même temps, ça parait logique: tous les développeurs semblent avoir un langage préféré, avec une logique particulière propre. Du coup, on finit toujours par trouver des développeurs convaincus que "leur" langage est le meilleur pour la programmation web!

          Ceci dit, qui s'en plaindra?

          M'en vais me faire un framework web codé en assembleur qui va déchirer sa race à sa mère!!

          ----------------> [ ]
  • # Lamson

    Posté par . Évalué à 4.

    Très bon, j'ignorais jusqu'à son existence, mais ça "fait ma journée". Merci à l'auteur de la dépêche.
    • [^] # Re: Lamson

      Posté par (page perso) . Évalué à 2.

      Je ne connais pas Lamson mais j'utilise personnellement QPSMTPD et c'est assez génial à utiliser.

      http://smtpd.develooper.com/

      C'est un serveur SMTP modulaire en Perl. Je ne sais pas ce qui les rapproche et/ou les éloigne. Si quelqu'un connaît les deux, ce serait intéressant d'avoir un avis la dessus.
  • # Pourquoi ?

    Posté par (page perso) . Évalué à 4.

    >> Une monade particulièrement bien adaptée au développement web ;

    Ha ? Et précisément en quoi est-elle particulièrement adaptée ?
    Parce qu'une monade, c'est rien d'autre qu'un design-pattern avec quelques contraintes...


    >> Snap est encore très jeune, mais ses performances sont déjà impressionnantes : plus rapide qu'apache !

    Ca aussi, c'est impressionnant et très rapide : http://john.freml.in/teepeedee2-c10k avec du bon Common Lisp dedans.
    Et comme c'est des S-Expressions, on peut generer le code HTML/XML a partir du code lisp lui meme...
    • [^] # Re: Pourquoi ?

      Posté par . Évalué à 2.

      Parce qu'une monade, c'est rien d'autre qu'un design-pattern avec quelques contraintes...
      Mais il faut quand même y mettre quelque chose dans ce design-pattern :)

      Et c'est ce quelque chose qui est particulièrement bien adaptée au développement web

      Je pense qu'elle permet d'abstraire et « purifier » les effets de bords que tu vas faire sur le résultat du traitement de la requête histoire que ce soit sûr et élégant… (souvent on fait ce genre de trucs avec les monades donc je ne risque pas trop de me tromper :)
      • [^] # Re: Pourquoi ?

        Posté par (page perso) . Évalué à 4.

        >> Mais il faut quand même y mettre quelque chose dans ce design-pattern :)

        Oui, enfin, c'est pas lié au concept de monade lui-même.
        Il serait bien plus sensé d'écrire « des structures de données et algorithmes adaptés au développement web avec un langage fonctionnel. »
        Par exemple, du « message passing » au lieu de plein d'effets de bords, c'est super agréable à utiliser avec un tas de langages fonctionnels.


        >> Je pense qu'elle permet d'abstraire et « purifier » les effets de bords que tu vas faire sur le résultat du traitement de la requête histoire que ce soit sûr et élégant…

        Abstraire, oui. C'est d'ailleurs la force des langages fonctionnels de permettre un raisonnement de haut niveau.
        Purifier, non. Ça ne purifie rien une monade. Ça dit que ce qui est dedans ne « déborde » pas, ce qui est complétement différent. Ensuite, ce n'est pas parce que la monade IO utilisée pour justifier les effets de bords est nécessaire à tout programme non trivialement évaluable (car si on ne fait pas d'IO, on a pas besoin d'évaluer le programme !) que toutes les monades servent à ça !
        On fait souvent des continuations avec des monades, du passage implicite d'arguments, du backtracking, et même des listes toutes connes sans aucun effet de bord.


        Bon, d'après le code, c'est une combinaison d'environnements (passage implicite d'argements), de traitement des données (ou de son échec) et d'effets de bords. Une belle abstraction, en effet.
        Mais une monade, c'est aussi *nécessairement* la vérification de lois (comme l'associativité). Et peu sont ceux qui prouvent que ces lois sont vérifiées quand ils créent (ou croient créer) une monade. On peut tout à fait en Haskell écrire un programme avec un truc qui ressemble à une monade, qui utilise la formule magique "instance Monad" et qui n'est pas une monade.


        Bref, encore une victoire des langages fonctionnels (pour l'élégance du code) et du buzz (pour le côté « oh ! c'est grâce à une monade [lien vers un article imbitable pour le commun des mortels sur les catégories pour donner un semblant d'autorité à la déclamation] que c'est cool. »)
        • [^] # Re: Pourquoi ?

          Posté par . Évalué à 2.

          Oui, ton analyse est plus juste que la mienne, merci pour les précisions :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.