snuxoll.com

    I've been doing a lot of event-driven programming in ruby lately, and it's involved a lot of repeating to generate methods for each and every event my application can fire off, and I can only support one handler per event with my current methods. Since I'm a big believer in DRY (Don't Repeat Yourself), and I was also spoiled by the excellent event handling in C# and Vala (Gobject, really), I decided to write something similar to ruby. This, is ruby-event.

    Today's Ruby on snuxoll's post shows you how to overcome a not-so-apparant issue with dealing ruby's Hash class, namely, using the Enumerable#collect method.

    I've been watching the Vala project very closely for the past while. The goal is to make a nice high level language built on top of the existing GLib/GObject type system. The advantage is, vala code compiles down to standard C/GLib code, so it maintains the speed and interoperability of C without dealing with the suckiness of GObject copypasta. The issue in paradise? The only build system that remotely supports vala is autotools, which can go die in a fire as far as I'm concerned.

    See, there's a reason I don't enable things on production sites without checking them, because people make silly mistakes, see the following code:

    I've recently found myself needing a simple and clean way to handle
2D arrays in ruby, so I created a Matrix class for that purpose. It's certainly not abiding by a lot of ruby style guidelines, but it's the cleanest way I can think of to handle 2D arrays.