Comme je lis régulièrement ces journaux bookmarks avec plaisir, je vais en profiter pour aussi donner quelques infos sur slide'em up.
Historiquement, j'ai commencé par utiliser showoff pour faire mes slides, mais j'avais quelques problèmes avec : des images qui ne se chargeaient pas dans le bon ordre, difficile de modifier la CSS par défaut, etc. Du coup, j'ai voulu contribuer. J'ai donc été voir le code et j'ai découvert que c'est un empilement de gros hacks les uns par dessus les autres et que j'allais avoir bien du mal à comprendre précisément comment ça marche. Je ne jette pas la pierre à schacon, il a écrit ça en vitesse pour ses propres besoins, puis ça a commencé à avoir du succès et il a intégré des patchs pas toujours très propres mais qui ajoutaient des fonctionnalités, et il n'a jamais trop pris le temps de nettoyer le code.
De mon coté, j'étais en train de préparer une conf sur Goliath et pour mieux appréhender la bête, j'en ai profité pour recoder un mini showoff-like avec Goliath. Puis, comme ça marchait pas mal, j'ai ajouté des fonctionnalités et des themes. Et depuis, je ne me sers plus de showoff mais uniquement de slide'em up pour faire mes présentations (enfin, sauf celles que je fais à plusieurs où j'utilise ce que l'autre personne veut utiliser, je ne suis pas très difficile pour ça tant que ça permet d'avoir un fichier dans un format ouvert à la fin).
À propos de Sinatra et Goliath, ils ne sont pas tout à fait équivalent. Pour comprendre la différence, je vais commencer par introduire un troisième larron : Rack. C'est un petit bout de code qui fait l'interface entre les serveurs applicatifs et les frameworks dans le monde Ruby. En gros, le serveur applicatif va recevoir du texte venant du réseau, l'interpréter comme du HTTP et ainsi construire un tableau des headers HTTP et éventuellement un body. Il va passer les deux au framework sous une forme convenue (celle décrite par l'interface Rack) qui lui va regarder le chemin et en déduire du code à appeler. Ce code va construire une réponse que le framework retournera au serveur applicatif, à nouveau sous une forme convenue par Rack (un triplet code de retour, headers et body). Le serveur applicatif peut alors envoyer ses informations sur le réseau.
Sinatra est un framework tel que décrit ci-dessus. Par contre, la position de Goliath est plus floue : il fait à la fois serveur applicatif, rack et framework. Rack permet de décrire des échanges de type une requête -> une réponse. Mais c'est un modèle qui ne convient plus quand on veut faire des WebSockets ou streaming HTTP. Il existe des modifications de Rack pour faire ça sous diverses formes. Goliath implémente une de ses modifications et elle a l'inconvénient de lier très fortement la partie serveur applicatif de la partie framework. Du coup, jusqu'il y a peu, utiliser Goliath voulait dire que l'on utilisait rien d'autre. Ça a changé un peu récemment : il y a des gens qui utilisent Goliath comme serveur applicatif avec un autre framework (Grape), mais ça se limite aux échanges classiques 1 requête -> 1 réponse (pas de WebSockets ou de streaming HTTP dans ce cas).
Bref, tout ça pour dire que Goliath n'a pas forcément un intérêt monstrueux pour slide'em up, c'est juste qu'il passait par là quand j'ai codé slide'em up et qu'il m'a permis d'éviter le bug des images qui se chargent dans le mauvais ordre.
# Quelques infos sur slide'em up
Posté par Bruno Michel (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 10.
Comme je lis régulièrement ces journaux bookmarks avec plaisir, je vais en profiter pour aussi donner quelques infos sur slide'em up.
Historiquement, j'ai commencé par utiliser showoff pour faire mes slides, mais j'avais quelques problèmes avec : des images qui ne se chargeaient pas dans le bon ordre, difficile de modifier la CSS par défaut, etc. Du coup, j'ai voulu contribuer. J'ai donc été voir le code et j'ai découvert que c'est un empilement de gros hacks les uns par dessus les autres et que j'allais avoir bien du mal à comprendre précisément comment ça marche. Je ne jette pas la pierre à schacon, il a écrit ça en vitesse pour ses propres besoins, puis ça a commencé à avoir du succès et il a intégré des patchs pas toujours très propres mais qui ajoutaient des fonctionnalités, et il n'a jamais trop pris le temps de nettoyer le code.
De mon coté, j'étais en train de préparer une conf sur Goliath et pour mieux appréhender la bête, j'en ai profité pour recoder un mini showoff-like avec Goliath. Puis, comme ça marchait pas mal, j'ai ajouté des fonctionnalités et des themes. Et depuis, je ne me sers plus de showoff mais uniquement de slide'em up pour faire mes présentations (enfin, sauf celles que je fais à plusieurs où j'utilise ce que l'autre personne veut utiliser, je ne suis pas très difficile pour ça tant que ça permet d'avoir un fichier dans un format ouvert à la fin).
À propos de Sinatra et Goliath, ils ne sont pas tout à fait équivalent. Pour comprendre la différence, je vais commencer par introduire un troisième larron : Rack. C'est un petit bout de code qui fait l'interface entre les serveurs applicatifs et les frameworks dans le monde Ruby. En gros, le serveur applicatif va recevoir du texte venant du réseau, l'interpréter comme du HTTP et ainsi construire un tableau des headers HTTP et éventuellement un body. Il va passer les deux au framework sous une forme convenue (celle décrite par l'interface Rack) qui lui va regarder le chemin et en déduire du code à appeler. Ce code va construire une réponse que le framework retournera au serveur applicatif, à nouveau sous une forme convenue par Rack (un triplet code de retour, headers et body). Le serveur applicatif peut alors envoyer ses informations sur le réseau.
Sinatra est un framework tel que décrit ci-dessus. Par contre, la position de Goliath est plus floue : il fait à la fois serveur applicatif, rack et framework. Rack permet de décrire des échanges de type une requête -> une réponse. Mais c'est un modèle qui ne convient plus quand on veut faire des WebSockets ou streaming HTTP. Il existe des modifications de Rack pour faire ça sous diverses formes. Goliath implémente une de ses modifications et elle a l'inconvénient de lier très fortement la partie serveur applicatif de la partie framework. Du coup, jusqu'il y a peu, utiliser Goliath voulait dire que l'on utilisait rien d'autre. Ça a changé un peu récemment : il y a des gens qui utilisent Goliath comme serveur applicatif avec un autre framework (Grape), mais ça se limite aux échanges classiques 1 requête -> 1 réponse (pas de WebSockets ou de streaming HTTP dans ce cas).
Bref, tout ça pour dire que Goliath n'a pas forcément un intérêt monstrueux pour slide'em up, c'est juste qu'il passait par là quand j'ai codé slide'em up et qu'il m'a permis d'éviter le bug des images qui se chargent dans le mauvais ordre.