vendredi 30 mai 2008

Google Reader pour Lefty

Les flux RSS sont vraiment un moyen très puissant de se tenir au courant à moindre coût : c'est une application "assez" récente d'Internet, qui à mon avis est encore mal maîtrisée par l'internaute moyen (ce qui n'est pas le cas de Lefty, puisque celui-ci a un blog - waow ! -).


Présentation :

L'intérêt des flux RSS réside dans un principe très simple :

"Chercher une information qui vous intéresse sur le web est en soi une perte de temps : c'est l'information qui vous intéresse qui doit arriver à vous."

D'où ces flux qui vous tiennent au courant des dernières entrées du blog de votre pote qui joue de la gratte, des dernières nouvelles concernant les JO ou d'une réponse à votre message sur un forum de discussion.
La question est comment ? Comment profiter de ces outils le plus simplement et naturellement possible ?

Il existe grosso-modo 3 méthodes :

  • Via son navigateur web
  • Via un agrégateur de flux offline et/ou son logiciel de messagerie
  • Via un agrégateur de flux online
La plupart des navigateurs web modernes intègrent des outils de lecture de flux RSS/ATOM. Mais dans l'ensemble je les trouve reltivement peu pratiques. Le modèle de Safari est assez peu intuitif, avec un rendu assez médiocre. Opera est un peu mieux sur ce point, mais j'accroche pas. Firefox (v2, j'attends la suite...) par contre, propose les marque-pages dynamiques qui peuvent être intéressants : ceux-ci se présentent comme des favoris classiques qui se déroulent pour révéler les dernières entrées du flux. C'est surtout pratique pour les flux souvent mis à jour (tumblelog, blogger hyperactif ou site d'informations), mais là encore, il faut faire l'effort de cliquer dessus pour être tenu au courant (monde de feignants...).


Les agrégateurs de flux, eux, se présentent davantage comme des logiciels de messagerie, recevant les entrées comme des messages. D'ailleurs, différents logiciels de messagerie proposent cette fonctionnalité, Mozilla ThunderBird notamment.

Mais il existe une méthode qui paraît plus "logique" : les agrégateurs de flux online comme Google Reader, NetVibes (qui est en fait un peu plus qu'un simple agrégateur : plus proche d'iGoogle peut-être...) ou BlogLines (et bien d'autres...).

Google Reader :

Je vais m'intéresser maintenant plus particulièrement à Google Reader. (Non, je n'ai pas d'action chez Google : je ne leur fais pas de pub... juste de la propagande. On en reparlera...)

L'intérêt, à mon sens, de Google Reader, c'est qu'il se présente quasiment comme Gmail : si on utilise cette messagerie, on ne sera pas dépaysé.
Pour ajouter des abonnements, rien de plus simple : on peut entrer l'URL du flux désiré (via "ajouter un abonnement"), ou importer une liste de flux (fichier au format OPML) dans "Gestion des abonnement/Importer" ou encore lancer une recherche et attendre les propositions du moteur. Si en plus on possède un navigateur profondément bon (comme, je sais pas moi... Firefox ?), celui-ci vous propose de l'y ajouter lorsque vous cliquez l'icône d'abonnement sur un site.

En dehors des fonctionnalités de base, comme tagger ses articles, assurer un suivi, ajout à iGoogle et quelques stats, Google Reader permet également de "partager" des items. C'est à dire que suite à la lecture d'un très bon article sur l'un de vos flux, vous pouvez cliquer sur "Partager" pour l'ajouter à votre page de partage. Cette page web est "publique" et est donc accessible à quiconque en connait l'adresse : à fournir à vos amis par exemple.


Mais allons un peu plus loin. Il existe évidemment un widget pour ajouter vos derniers coups de cœur à votre site ou à votre blog (painless, surtout chez Blogger). Du coup, on obtient quasiment un "Tumblelog" (blog avec messages très courts, le plus souvent un simple lien vers une page intéressante).
Attention, maintenant grosse manip' bien technique : dans "Paramètres", passer la langue en Anglais et là "KABOOM"* : vous pouvez à présent ajouter des notes qui seront partagées par défaut (décocher la case "Share" sinon) et la possibilité de changer l'apparence de votre page de partage (d'où les petits ninjas sur la mienne**). Du coup, on a effectivement un Tumblelog à pas cher...

Je suis sûr que ça va intéresser Lefty...



* : Si vous ne parvenez pas à effectuer cette manipulation, merci de contacter notre équipe d'assistance au 080808, 44€55/s...
** : Dans la colonne de droite, juste en dessous de la pub sur laquelle vous ne cliquez jamais bande de rats !
*** : Les images de cet article appartiennent à leurs propriétaires respectifs. Pas à moi donc...

mercredi 21 mai 2008

Typage statique pour Ruby

Via cet article sur Segment7, voici le lien vers une publication sur le développement de DRuby (DiamondBack Ruby) [:en, :pdf] : un outil (codé en OCaml) visant à autoriser le typage statique en Ruby. Le code source de cette application devrait être publié dans les mois à venir.

J'ai un avis assez mitigé sur ce genre de projet : d'un côté, j'apprécie la possibilité de choisir (cf. article précédent sur le typage en Groovy), et je reconnais tout à fait beaucoup des avantages du typage statique. Parmi eux, une certaine fiabilité et la détection précoce d'erreurs de développement.
Mais en Ruby (Perl, Python, etc...) ? L'un des avantages de ces langages dynamiques n'est-il pas d'"éluder" au maximum les contraintes de type pour un développement plus rapide et libre ? En Ruby en tout cas, la "philosophie" veut que l'on s'intéresse davantage au comportement d'un objet (no primitive type here !) qu'à sa classe (principe du "Duck Typing"). On croise donc plus souvent des foo.respond_to? :a_method que des foo.is_a? A_Class.

Il est cependant intéressant de se poser la question suivante (et pas seulement en Ruby !) :

Comment et/ou avec quelles techniques, assurer la fiabilité d'un programme dans un langage dynamique ?

Je vais essayer de bientôt placer quelques petits exemples de code sur ce sujet.

jeudi 15 mai 2008

Ruby : Création dynamique de méthodes

Ola Bini vient de publier un article très bien fait sur les différentes façons disponibles en Ruby pour la création dynamique de méthodes.


Pour cela, il envisage trois voies : le def classique, la méthode define_method ou l'une de ces deux dans un eval. Plusieurs paramètres importants dans le choix de la méthode utilisée :

De façon assez amusante, il recommande pour des questions de vitesse, surtout, d'utiliser en priorité le def classique. Juste pour l'exemple, voici le code d'une définition par def, dans un eval :

class Foo
end

bar = Foo.new
method_name = :something

eval "def bar.#{method_name}; puts 'Hi !'; end"

bar.method(method_name).call
#=> Hi !