blog.name.nil? - blog

RubyZip vs Zip

Ayant besoin dans un projet de créer des archives zip depuis un code ruby, j'ai cherché dans un premier temps du côté de gems ou librairies purement ruby pour faire cela. Je n'ai pu trouver que quelques librairies dont certains semblent obsolètes ou non maintenues.

Décidant tout de même de tester une de ces librairies (rubyzip), je me suis posé la question des performances de ces librairies en comparaison d'une implémentation en C. Etant donné que je n'ai que l'archivage d'un répertoire à effectuer, sans contrôle d'erreur fin, pourquoi ne pas créer l'archive en passant par un bon vieux binaire zip disponible de facto sur pratiquement tous les systèmes.

Flickraw: client flickr en moins de 300 lignes

Encore une librairie cliente pour flickr, mais enfin une implémentation vraiment différente cette fois-ci : aucun des appels ou presque n'est implémenté dans la librairie, tout est créé dynamiquement.

Dans un premier temps, il ne faut pas oublier 2 choses : flickr offre une API très bien construite permettant ce genre de chose et ruby de part son dynamisme permet de l'utiliser pleinement.

Console en ruby + readline

Ayant besoin d'une petite console effectuant des appels sur un webservice, je me suis lancé à la découverte de readline. Cependant, la documentation officielle est totalement innexistante.

Après quelques recherches, j'ai pu trouver un tutoriel donnant les principales fonctions de readline.

L'idée derrière readline est simple : fournir une librairie permettant simplement d'éditer des lignes de commandes au moment de leur frappe. La gestion des racourcis ctrl+a et ctrl+e, ainsi que l'historique sont des exemples des fonctions supportées par readline.

Ruby: blocks, to_proc, &

Les blocks représentent une fonctionnalité puissante de Ruby. Mais comment sont ils traités d'un point de vue langage ?

Ruby étant totalement objet, derrière les blocks se cache en fait une classe Ruby : Proc. De la déclaration en utilisant les accolades '{}' ou l'ensemble do..end resulte une instance de la classe Proc :

class MyClass
  def envelope(myblock)
    myblock.call
  end
end

m = MyClass.new
p = Proc.new { puts 'test' }
m.envelope p

Ruby: blocks

Les blocks en Ruby est une des fonctions incontournables qui rendent ce langage si attrayant. En simplifié, il s'agit d'un boût de code que l'on peut passer à des fonctions. Ce code peut prendre des paramètres si nécessaire. On les appelle plus communément fonction annonyme.

Une des utilisations principales de ces blocks est fait lors de l'itération d'éléments Enumerable :

[1,2,3].each do |item|
  puts item + 5
end

Ruby: method_missing

Une des grandes forces du Ruby, c'est son côté dynamique. Si vous utilisez Rails, vous devez être familier avec les méthode de recherche sur les modèles telles que find_by_xxx. Ces méthodes ne sont pas directement présentes dans le code et sont en fait ajoutées dynamiquement à la demande en fonction des colonnes de la table correspondant au modèle.

La technique est relativement simple : une méthode spécifique est appelée dès qu'une méthode n'a pas été trouvée. Ce mécanisme est fourni par le langage lui même.

Le prototype de la méthode method_missing doit respecter une certaine norme : method_missing(method, *args). En premier argument, le nom de la méthode initialement appelée. En second argument, l'ensemble des arguments passés à la méthode initialement appelée.

Apple AppStore API / gem

Aimant jouer avec les API et surtout les non officielles, mais principalement à cause d'un projet en tête, je me suis décidé à observer et décortiquer les transferts de données entre un client iTunes et l'AppStore d'Apple.

Petite précision pour commencer : j'ai dans un premier temps cherché si il n'existait pas d'API officielle ou non, avec une éventuelle implémentation dans tout language informatique existant. Visiblement, c'est une denrée rare (Apple y veillerait-il ?).

Je me suis donc lancé dans la création d'un gem permettant de consulter l'AppStore directement depuis un bout de code ruby. Ayant assemblé quelques bouts ensembles, j'ai maintenant une petite librairie permettant de faire des opérations de base sur l'AppStore : recherche d'application, consultation des commentaires/notes/prix, listing des categories et de leurs applications ...

Le code source du gem se trouve hébergé sur mon compte github. Je vous invite à consulter le code source si vous êtes interessés par le fonctionnement interne de l'AppStore, le code est relativement bien documenté et les remarques seront toujours les bienvenues.

GemWatch, équivalent d'apticron pour rubygems

Ayant quelques serveurs Linux à gérer, je dois être sur que les paquets sont toujours à jour, ne serait-ce que pour les mises à jour de sécurité.

Sur un système comme Debian, il est simple de mettre en place une tache quotidienne récupérant les paquets mis à jour et envoyant un mail à l'administrateur le prévenant des paquets à mettre à jour. Un paquet permet de réaliser ces actions sans configuration complexe : apticron.

Seulement, il n'y a pas vraiment d'équivalent pour ruby. J'ai tenté dans un premier temps d'écrire un équivalent d'apticron en shell script, mais j'ai réalisé qu'il était plus simple d'utiliser du ruby ayant un peu d'expérience avec gem.

Test::Unit is not dead (yet)

Test::Unit est un ensemble de classes facilitant l'écriture de tests unitaires en Ruby. Historiquement, il s'agit d'une des premières librairies de tests intégrée à Ruby. Elle était distribuée directement avec les sources Ruby jusqu'à la version 1.9.

Cette librairie est maintenant boudée par une grande partie de la communauté qui préfère se tourner vers d'autres solutions telles que shoulda, cucumber ou encore rspec.

Pourtant, cette librairie est loin d'être morte puisque la version 2.0.3 vient d'être releasée.