On yesterday I announced Sashimi and now it’s already time of tasteful updates.

Changes

First, thanks to all the people that appreciated my work. Second, new commands and options are avaliable for Sashimi.

Update all plugins in your repository:
$ sashimi update --all

Install a plugin to your Rails app:
$ sashimi install --rails click-to-globalize
NOTE this is an alias for the add command.

Update a plugin of a Rails app:
$ sashimi update --rails click-to-globalize
NOTE If your application is versioned with Svn or Git, Sashimi will automatically schedules for add/remove the added/removed files.

I have a really, really bad memory: each time I need to install a Rails plugin, I Google to find the repository, then try to download the code. Often, I remember the url, but the server is down. Damn!

All this annoying issues kill the Rails rapidity on application prototyping. But, what if all the plugins which I need are available offline on my notebook? I can forget about all that urls, and I should stop to worry about the server status.

SAX is an event-driven parser for XML.

It sequentially reads the xml and generates special events. So, if you want to use SAX, you should implement the code to handle them. It’s quite different from the DOM model, where the whole xml is parsed and loaded in an tree. As you can see, the first approach is more difficult than the DOM one. Why we should use it? Depends. If you want to extract certain informations from a big file, probably you should choose a SAX implementation, in this way you can avoid the initial DOM loading overhead.

The Ruby XML Library

The Ruby core library has a built-in XML parser (both DOM and SAX) called REXML, but it’s terribly slow, it’s highly advisable to use libxml. It’s a binding to the popular library from Gnome and it was released as gem.

I’m writing this post as contribution to the Campagna Anti-IF (Anti-IF Campaign).

Problem

I’m developing an internal Rails plugin for widgets, it provides a class called Widget (really unconventional :-P), and each widget should inherit from it. The actual implementation provides a callback called before_render, that allows to add some logic to a widget, if implemented it’s called before the widget rendering.

Ruby doesn’t have abstract methods, so I have to check if the subclass has the implementation of mentioned method:
# Rendering code.. before_render if respond_to? :before_render # ...

This snippet shows how to read a file and puts all the lines into an array.

f = *open('file.txt').map {|l| l.rstrip} # => ["Hi, from the", "txt file."]

Explanation

The open method returns an IO object, that include the Enumerable module, now we can just use #map (or #collect).

The splat operator is only a sugar syntactical shortcut for map.